Generic OpenAI로 AnythingLLM을 어떤 모델에서든 실행하기.

빠른 답: LLM Preference의 다섯 필드.

AnythingLLM의 설정을 열고 AI Providers 아래의 LLM 섹션(예전에는 LLM Preference라는 이름의 화면)으로 이동해, 프로바이더 목록에서 Generic OpenAI를 찾으세요. 선택하면 Base URL, API Key, Chat Model Name, Token Context Window, Max Tokens 다섯 필드가 나타납니다. 다음과 같이 채우세요: Base URL은 https://api.apisrouter.com/v1(이 필드에 /v1이 포함됩니다), 여러분의 키, 그리고 Chat Model Name에는 카탈로그의 정확한 id, 예를 들면 claude-sonnet-4-6. 그런 다음 숫자 두 개: Token Context Window는 모델의 전체 윈도우이고 Max Tokens는 단일 응답의 상한이므로, 추측하지 말고 모델 문서에서 둘 다 가져오세요. 저장하면 시스템 기본값을 따르는 모든 워크스페이스가 이제 게이트웨이를 통해 채팅합니다. 문서가 이 프로바이더를 개발자 중심이라고 표시하는 이유는 정확히 여러분의 입력을 신뢰하기 때문입니다; 사용하지 말라는 경고가 아니라 다섯 필드가 하나의 계약이라는 진술일 뿐입니다.

Base URL:              https://api.apisrouter.com/v1
API Key:               sk-YOUR-APISROUTER-KEY
Chat Model Name:       claude-sonnet-4-6
Token Context Window:  200000
Max Tokens:            8192

Generic OpenAI 프로바이더가 실제로 구동하는 것.

AnythingLLM(GitHub의 Mintplex Labs, 약 6.3만 스타)은 올인원 프라이빗 문서 어시스턴트입니다: 파일을 임베드하는 워크스페이스, 검색된 컨텍스트에 근거한 채팅, 툴 사용이 가능한 에이전트가 데스크톱 앱과 셀프 호스팅 서버로 제공됩니다. 위에서 설정한 LLM preference가 이 모든 것의 기본 두뇌입니다. 요청은 Chat Model Name을 model 문자열로 하는 표준 chat completions로 Base URL을 향해 나가므로 벤더는 상관없습니다: Claude id도 GPT id만큼 유효하며, 전환은 필드 하나만 편집하면 됩니다. 워크스페이스는 자체 프로바이더와 모델 설정으로 시스템 기본값을 오버라이드할 수도 있는데, 이것이 한 배포판이 법무 워크스페이스에는 claude-sonnet-4-6을, 엔지니어링에는 gpt-5.5를 서로 모르는 채로 실행하는 방식입니다. 두 토큰 필드는 존중받아 마땅합니다. AnythingLLM이 이를 사용해 컨텍스트를 예산 배정하기 때문입니다. 컨텍스트 윈도우 값은 검색된 문서 텍스트와 대화 기록이 각 요청에 얼마나 채워질지를 결정합니다; 과소평가하면 공들여 임베드한 문서가 정작 답변에서 잘려나가고, 과대평가하면 요청이 모델의 실제 한도에 튕겨나갑니다. 이 필드 쌍이 일반 엔드포인트에서 "RAG가 멍청하게 느껴진다"는 대부분의 리포트 배후에 있습니다.

임베딩은 별개의 결정입니다.

AnythingLLM은 LLM preference와 임베딩 preference를 분리하며, 이 분리는 중요한 의미를 가집니다. 채팅 모델은 질문에 답하고, 임베더는 업로드 시점에 문서를 벡터로 바꾸며 그 벡터는 계속 유지됩니다. 채팅 모델을 바꾸는 것은 언제든, 워크스페이스별로 자유롭습니다. 임베더를 바꾸는 것은 이미 임베드된 모든 것의 기하학적 구조를 무효화하고 문서 재임베딩을 의미합니다. 실용적인 설정은 이렇습니다: AnythingLLM은 오프라인에서 작동하고 비용이 들지 않는 내장 로컬 임베더를 제공하며, 많은 배포판이 그냥 이것을 유지합니다. 대신 임베딩 preference를 원격 엔드포인트로 지정한다면, 문서 베이스를 업로드하기 전에 그 엔드포인트가 특정 임베딩 id를 서빙하는지 확인하고, 이 선택을 벡터 스토어와 결혼한 것으로 취급하세요. 채팅 쪽에서 이것이 사주는 자유가 이 아키텍처의 핵심입니다: 임베딩이 정리되고 나면 Generic OpenAI 채팅 모델은 저위험 다이얼이 됩니다. 한 달 동안 대량 요약에 deepseek-v4-pro를 돌리다가, 분기 동안 클라이언트 작업에는 claude-sonnet-4-6으로 필드를 바꿔도 문서에 대해서는 아무것도 옮길 필요가 없습니다.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# Chat Model Name must match one of these ids exactly

문서 작업을 위한 모델 선택.

모든 id가 같은 키로 청구되므로, 비교 루프는 설정 편집일 뿐입니다: 같은 워크스페이스, 같은 문서, 각 후보에 2주씩, 그리고 APIsRouter 콘솔의 모델별 지출을 답변에 대한 여러분 자신의 판단과 나란히 놓고 보세요.

• 검색된 청크에 근거한 답변은 입력이 많은 작업입니다: claude-haiku-4-5-20251001과 gemini-3.5-flash는 인용을 따라가는 질문에 볼륨 가격으로 잘 답합니다.
• claude-sonnet-4-6은 답변이 사람에게 수정 없이 전달되는 곳, 즉 계약서 검토, 리포트 작성 등 결과가 중요한 곳에서 기본값이 될 자격이 있습니다.
• deepseek-v4-pro는 큰 문서를 기반으로 만들어진 워크스페이스를 위한 롱컨텍스트 워크호스입니다. 이런 곳에서는 윈도우와 입력 가격이 경험을 좌우합니다.
• 에이전트 워크스페이스는 신뢰할 수 있는 툴 콜링이 필요합니다; claude-sonnet-4-6으로 에이전트를 시작한 다음, 실제 플로우에서 더 가벼운 id가 버텨내는지 테스트하세요.
• 워크스페이스별 오버라이드를 정책처럼 사용하세요: 기본값은 빠르게 유지하고, 비싼 id는 그 비용을 정당화하는 작업이 있는 워크스페이스에서만 살게 하세요.

사용한 만큼 지불 · 공식 요금보다 저렴

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

AnythingLLM 특유의 실패 패턴.

토큰 필드가 미묘한 실패를 일으킵니다. 컨텍스트 윈도우를 너무 낮게 설정하면 검색된 컨텍스트가 조용히 잘려나가는데, 이는 모델이 문서를 무시하는 것처럼 보입니다; Chat Model Name의 id에 문서화된 윈도우를 설정하세요. Max Tokens를 모델에 비해 너무 높게 설정하면 긴 답변에서 하드 에러가 발생합니다; 모델이 실제로 허용하는 출력값으로 설정하세요. 하드 에러는 더 정직합니다. 인증 실패는 API Key 필드 문제입니다. Model-not-found는 Chat Model Name이 카탈로그 표기에서 벗어났다는 뜻입니다; 이 필드는 자유 텍스트이고 /v1/models 목록이 정답입니다. 데스크톱 앱의 연결 오류는 보통 앱과 엔드포인트 사이의 프록시나 방화벽을 뜻합니다; Docker 배포에서는 Base URL에 도달해야 하는 것이 브라우저가 아니라 컨테이너라는 점을 기억하세요. 채팅은 되는데 워크스페이스가 예상과 다르게 동작한다면 오버라이드 설정을 확인하세요; 워크스페이스 레벨 프로바이더 설정이 시스템 기본값을 이기며, 잊어버린 오버라이드는 전형적인 "같은 질문인데 다른 모델" 미스터리입니다. 문서의 개발자 중심 프레이밍은 위 모든 것을 요약합니다: 이 프로바이더는 다섯 필드가 말하는 그대로만 정확히 수행합니다.

어떤 사람들이 게이트웨이를 통해 AnythingLLM을 쓰는가.

• 모델 패밀리마다 벤더 계정을 두지 않고 프론티어급 답변 품질을 원하는 프라이빗 문서 어시스턴트 운영 팀.
• 개인 문서 베이스를 선불 잔액으로 Claude나 GPT id에 연결하려는 데스크톱 사용자 — 시작에 카드가 필요 없습니다.
• 내장 로컬 임베더를 유지하며 원격 채팅만 계량 대상 레인으로 취급하는 셀프 호스터 — 사용량 로그 하나로 모델별로 읽습니다.
• 워크스페이스별로 분리된 배포판 — 워크스페이스별 오버라이드와 키별 계량이 팀마다 자체 모델과 자체 청구서를 부여합니다.
• 고정된 문서 베이스에서 답변 모델을 비교하는 빌더 — 각 후보는 마이그레이션이 아니라 설정 편집 하나입니다.

엔드포인트 검증 및 첫 워크스페이스 채팅 디버깅.

Chat Model Name에 넣으려는 정확한 id로 모델 목록과 채팅 완성 하나를 먼저 curl로 확인하세요. 둘 다 통과하면 게이트웨이 쪽은 증명된 것이고 남은 모든 증상은 다섯 필드 안에 있습니다. 그런 다음 프로바이더 설정을 저장하고 잘 아는 문서가 있는 워크스페이스에서 질문 하나를 해보세요. 근거를 갖추고 인용하는 답변이 나오면 전체 파이프라인이 작동하는 것입니다. 문서를 무시하는 답변은 컨텍스트 윈도우 값이나 워크스페이스 자체의 검색 설정을 가리킵니다. 하드 에러는 깔끔하게 대응됩니다: 키, id 표기, Base URL 형태. 채팅이 흐르기 시작하면 APIsRouter 콘솔에서 요청별 모델, 토큰 수, 지출을 볼 수 있습니다. 문서 QA는 검색을 통해 입력 토큰을 곱하므로, 사용량 로그는 여러분의 문서 베이스가 모델별, 날짜별, 그리고 워크스페이스 키를 나눴다면 워크스페이스 키별로 질의당 실제로 얼마가 드는지 알려주는 곳입니다.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

자주 묻는 질문