커스텀 OpenAI 호환 엔드포인트로 Quivr의 RAG 브레인 실행하기.

빠른 답: LLMEndpointConfig 안의 llm_base_url.

현재 Quivr는 quivr-core, 즉 Python RAG 라이브러리이며, LLM 배선이 명시적입니다. LLMEndpointConfig는 supplier(기본값 openai), model, llm_base_url, llm_api_key를 담고, LLMEndpoint.from_config()가 이 필드들로 실제 클라이언트를 만듭니다. openai supplier의 경우 그 클라이언트는 여러분의 base URL로 구성된 LangChain의 ChatOpenAI입니다. llm_base_url을 https://api.apisrouter.com/v1로 설정하고, model을 카탈로그의 어떤 id로든 설정한 다음, 그 엔드포인트를 Brain에 넘기세요. 키는 설정 필드나 환경에서 올 수 있습니다: llm_api_key가 설정되지 않으면 quivr-core는 supplier 이름을 딴 환경 변수에서 이를 해석하는데, openai supplier의 경우 OPENAI_API_KEY입니다. 두 경로 모두 업스트림 동작이며, quivr_core/rag/entities/config.py와 quivr_core/llm/llm_endpoint.py에서 읽을 수 있습니다.

from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",          # any catalog id
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
))

Quivr가 지금 무엇인지, 그리고 LLM 슬롯이 앉는 자리.

Quivr(GitHub의 QuivrHQ, 약 3.9만 스타)는 완전한 세컨드 브레인 애플리케이션으로 시작해 quivr-core로 방향을 틀었습니다: 여러분 자신의 제품에 임베드하는 견해가 뚜렷한 RAG 라이브러리입니다. 파일을 먹이면 파싱하고 청킹한 다음 청크를 벡터 스토어(기본값 FAISS, PGVector도 지원)에 임베드하고, 설정 가능한 검색 워크플로우를 통해 그 위에서 질문에 답합니다. Brain 객체가 단위입니다: Brain.from_files()가 수집하고, brain.ask()가 검색하고 생성합니다. 생성이 채팅 모델을 필요로 하는 유일한 단계입니다. 검색 워크플로우가 여러분의 문서에서 컨텍스트를 조립하고, 여러분이 전달한 LLMEndpoint가 근거를 갖춘 답변을 씁니다. 그 엔드포인트는 LLMEndpointConfig로부터 한 번 만들어지므로, base URL 결정은 생성 시점에 내려지고 그 brain의 모든 ask()에 적용됩니다. ChatOpenAI가 model 필드를 /v1/chat/completions를 통해 순수 문자열로 전달하므로, llm_base_url 뒤 엔드포인트가 그것들을 서빙할 때 id는 Claude, DeepSeek, GPT, Gemini가 될 수 있습니다. 프로젝트 현황에 대한 솔직한 참고: 저장소는 2025년 중반부터 조용했으므로, quivr-core를 빠르게 변화하는 라이브러리가 아니라 안정된 라이브러리로 취급하세요. 여기서 설명한 설정 표면은 최신 main 브랜치와 일치하며, 조용한 이력은 여러분 아래서 갑자기 바뀔 가능성이 낮다는 뜻이기도 합니다; 이는 또한 은퇴한 풀스택 앱(백엔드 .env 파일, 호스팅된 프론트엔드)을 설명하는 오래된 튜토리얼이 더 이상 코드와 맞지 않는다는 뜻입니다.

전체 설정: 게이트웨이로 라우팅되는 LLM을 가진 brain.

전체 패턴은 설정된 LLMEndpoint를 Brain.from_files에 전달하는 것입니다. brain의 나머지(파싱, 청킹, FAISS 스토어, 검색 워크플로우)는 LLM 엔드포인트와 독립적이며 기본값을 유지합니다. 임베더를 유의하세요. 하나를 전달하지 않으면 quivr-core는 자체 기본값을 가진 LangChain의 OpenAIEmbeddings를 만드는데, 이는 OPENAI_API_KEY로 인증하고 스톡 OpenAI 엔드포인트를 대상으로 합니다. 이는 채팅 LLM과 별개의 클라이언트입니다: 생성을 게이트웨이로 라우팅해도 이것은 이동하지 않습니다. 임베딩 절반이 OpenAI 계정에 의존하지 않기를 원한다면 여러분 자신의 임베더(로컬 sentence-transformers 래퍼, 또는 여러분이 설정하는 어떤 LangChain Embeddings 인스턴스든)를 전달하세요.

import os
from quivr_core import Brain
from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
    max_output_tokens=2048,
    temperature=0.3,
))

brain = Brain.from_files(
    name="team-docs",
    file_paths=["handbook.pdf", "runbook.md"],
    llm=llm,
    # embedder=...  # separate component; see note above
)

print(brain.ask("What is the on-call escalation policy?").answer)

RAG 답변을 위한 생성 모델 선택.

후보 비교는 생성 시점의 변경입니다: 같은 base URL을 대상으로 두 개의 LLMEndpoint를 만들고, 같은 파일 위에 두 개의 brain을 만든 다음, 고정된 질문 세트에서 답변을 비교하세요. 키별 사용량 로그가 각 후보의 실행에 가격을 매기므로, 토큰당 품질은 논쟁이 아니라 측정됩니다.

• RAG 생성은 입력이 많습니다: 검색된 청크가 프롬프트를 지배합니다. 입력 토큰당 가격이 답변의 비용을 정하므로, 빠른 id는 검색 품질을 건드리지 않고도 청구서를 종종 절반으로 줄여줍니다.
• claude-sonnet-4-6은 검색된 컨텍스트를 존중하고 문서에 답이 없을 때 깔끔하게 거절하는, 근거를 갖춘 답변을 위한 믿을 만한 기본값입니다.
• 대용량 임베디드 제품(Quivr가 명시한 사용 사례)은 일상적인 질문 조합에서 claude-haiku-4-5-20251001, deepseek-v4-flash, gemini-3.5-flash에서 잘 작동합니다.
• 같은 설정의 max_context_tokens는 파이프라인이 얼마나 많은 검색 컨텍스트를 채울지 지배합니다; 이를 올리는 것은 롱컨텍스트 id와 자연스럽게 짝을 이루며 입력 지출을 비례해서 올립니다.
• 알 수 없는 모델 프리픽스는 예산 배정을 위한 범용 토크나이저로 폴백되는데, 이는 장식적일 뿐입니다; 요청 자체는 여러분의 id를 그대로 엔드포인트로 실어 나릅니다.

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

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

흔한 Quivr 전승에 대한 정정.

유통되는 가이드들은 Quivr가 더 이상 갖고 있지 않은 표면을 설명하므로, 현재 코드가 실제로 무엇을 하는지 명시할 가치가 있습니다. quivr-core는 LiteLLM 기반이 아니라 LangChain 기반입니다. supplier 열거형이 LangChain 채팅 클래스를 선택하며, openai는 여러분의 llm_base_url을 가진 ChatOpenAI로 매핑됩니다. 튜토리얼이 Quivr 안에서 LiteLLM 프록시나 api_base 설정을 하라고 한다면 그것은 더 오래된 아키텍처를 설명하는 것입니다; 현재 필드는 LLMEndpointConfig의 llm_base_url입니다. 풀스택 앱은 은퇴했습니다. 백엔드 .env, Supabase 설정, 앱 내 모델 선택기에 대한 지침은 피벗 이전 애플리케이션을 가리키며, 이는 더 이상 저장소가 제공하는 것이 아닙니다. 설정은 이제 여러분의 Python 코드(또는 라이브러리를 둘러싼 여러분 자신의 앱) 안에서 일어납니다. 키 환경 변수는 supplier에서 파생됩니다. supplier openai의 경우 OPENAI_API_KEY이며, 엔드포인트가 OpenAI가 아니어도 마찬가지입니다. 그 이름을 덮어쓰고 싶지 않다면 설정에 llm_api_key를 명시적으로 전달하세요. 이것이 우선하며 환경을 깨끗하게 유지해 줍니다. 임베더는 별개입니다. 생성 라우팅은 임베딩을 이동시키지 않습니다; 기본 임베더는 자체 자격 증명을 가진 OpenAIEmbeddings입니다. 두 절반을 독립적으로 결정하세요; 기존 스토어의 재임베딩은 임베딩 모델 자체를 바꿀 때만 필요합니다.

어떤 사람들이 게이트웨이를 통해 quivr-core를 쓰는가.

• 자신의 앱에 RAG를 임베드하며 생성 모델이 스택에 박혀 있는 벤더 약정이 아니라 설정 값이기를 원하는 제품 팀.
• 서로 다른 품질 티어로 많은 brain을 운영하는 개발자: 키 하나, 엔드포인트 하나, brain별 모델 id.
• 두 번째 SDK나 프로바이더 계정을 더하지 않고 OpenAI 형태의 설정 뒤에서 Claude급 근거 답변을 원하는 팀.
• 고정된 코퍼스에서 생성 모델을 벤치마킹하는 빌더 — 각 후보는 LLMEndpointConfig 변경 하나일 뿐입니다.
• 특정 벤더의 결제 수단에 접근할 수 없는 개발자. 카드 없이 충전만으로 사용할 수 있어 프로바이더별 가입 의존성이 사라집니다.

엔드포인트 검증 및 첫 ask() 디버깅.

무엇이든 수집하기 전에 게이트웨이가 여러분의 모델을 나열하는지 확인하세요; model 필드는 서빙되는 id와 정확히 일치해야 합니다. 첫 실행 실패는 예측 가능합니다. supplier openai의 API 키가 설정되지 않았다는 경고는 설정이 만들어질 때 llm_api_key도 OPENAI_API_KEY도 보이지 않았다는 뜻입니다; 경고는 생성 시점에, 실패는 첫 ask()에서 일어납니다. 401은 해석된 키가 llm_base_url의 엔드포인트에 속하지 않는다는 뜻입니다. Model-not-found 오류는 /v1/models에 대한 id 오타입니다. 그리고 Brain.from_files 중 임베딩 관련 인증 오류는 별개의 기본 임베더가 자체 OpenAI 자격 증명을 요구하는 것이며, 어떤 llm_base_url 설정으로도 고칠 수 없습니다; 여러분이 제어하는 임베더를 전달하세요. 답변이 흐르기 시작하면 APIsRouter 콘솔에서 요청별 모델, 토큰 수, 지출을 볼 수 있습니다. 모든 프롬프트에 검색된 청크를 싣는 라이브러리의 경우, 여러분의 실제 코퍼스에 대한 답변당 토큰 숫자가 모델 선택을 이끌어야 할 수치입니다.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

자주 묻는 질문