Quivrs RAG-Gehirn auf einem custom OpenAI-kompatiblen Endpoint betreiben.

Kurzantwort: llm_base_url in LLMEndpointConfig.

Aktuelles Quivr ist quivr-core, eine Python-RAG-Library, und seine LLM-Verdrahtung ist explizit. LLMEndpointConfig trägt supplier (openai standardmäßig), model, llm_base_url und llm_api_key; LLMEndpoint.from_config() baut den eigentlichen Client aus diesen Feldern, und für den openai-supplier ist dieser Client LangChains ChatOpenAI, konstruiert mit deiner Base URL. Setze llm_base_url auf https://api.apisrouter.com/v1, setze model auf jede Katalog-ID, und gib den Endpoint an deine Brain weiter. Der Key kann aus dem Config-Feld oder der Umgebung kommen: ist llm_api_key nicht gesetzt, löst quivr-core ihn aus einer nach dem Supplier benannten Umgebungsvariable auf, für den openai-supplier ist das OPENAI_API_KEY. Beide Pfade sind Upstream-Verhalten, lesbar in quivr_core/rag/entities/config.py und 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"],
))

Was Quivr heute ist, und wo der LLM-Slot sitzt.

Quivr (QuivrHQ auf GitHub, rund 39.000 Stars) begann als vollwertige Second-Brain-Anwendung und pivotierte zu quivr-core: eine eigenwillige RAG-Library, die du in dein eigenes Produkt einbettest. Du fütterst sie mit Dateien, sie parst und chunkt sie, bettet die Chunks in einen Vector Store ein (FAISS standardmäßig, PGVector unterstützt), und beantwortet Fragen darüber über einen konfigurierbaren Retrieval-Workflow. Das Brain-Objekt ist die Einheit: Brain.from_files() ingestiert, brain.ask() ruft ab und generiert. Generierung ist der einzige Schritt, der ein Chat-Modell braucht. Der Retrieval-Workflow stellt Kontext aus deinen Dokumenten zusammen, und der übergebene LLMEndpoint schreibt die verankerte Antwort. Dieser Endpoint wird einmal aus LLMEndpointConfig gebaut, also wird die Base-URL-Entscheidung zur Konstruktionszeit getroffen und gilt für jedes ask() auf dieser Brain. Weil ChatOpenAI das model-Feld als reinen String über /v1/chat/completions weiterreicht, kann die ID Claude, DeepSeek, GPT oder Gemini sein, wenn der Endpoint hinter llm_base_url sie bedient. Ein ehrlicher Hinweis zum Projektstatus: das Repository ist seit Mitte 2025 ruhig, behandle quivr-core also als stabile statt sich schnell bewegende Library. Die hier beschriebene Config-Fläche passt zum aktuellen main-Branch, und die ruhige Historie bedeutet, es wird sich vermutlich nicht unter dir verschieben; sie bedeutet auch, dass alte Tutorials, die die eingestellte Full-Stack-App beschreiben (Backend-.env-Dateien, ein gehostetes Frontend), nicht mehr zum Code passen.

Vollständiges Setup: eine Brain mit gateway-geroutetem LLM.

Das vollständige Muster übergibt den konfigurierten LLMEndpoint an Brain.from_files. Alles andere an der Brain (Parsing, Chunking, der FAISS-Store, der Retrieval-Workflow) ist unabhängig vom LLM-Endpoint und behält seine Defaults. Achte auf den Embedder. Übergibst du keinen, baut quivr-core LangChains OpenAIEmbeddings mit eigenen Defaults, die sich mit OPENAI_API_KEY authentifizieren und den Standard-OpenAI-Endpoint anpeilen. Das ist ein separater Client vom Chat-LLM: die Generierung übers Gateway zu routen bewegt ihn nicht. Übergib deinen eigenen Embedder (einen lokalen Sentence-Transformers-Wrapper, oder jede von dir konfigurierte LangChain-Embeddings-Instanz), wenn du nicht willst, dass die Embedding-Hälfte von einem OpenAI-Konto abhängt.

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)

Ein Generierungsmodell für RAG-Antworten wählen.

Kandidaten zu vergleichen ist eine Konstruktionszeit-Änderung: bau zwei LLMEndpoints gegen dieselbe Base URL, zwei Brains über dieselben Dateien, und diffe die Antworten an einem festen Fragenset. Das Nutzungslog pro Key bepreist den Run jedes Kandidaten, sodass Qualität pro Token gemessen statt argumentiert wird.

• RAG-Generierung ist input-lastig: abgerufene Chunks dominieren den Prompt. Der Preis pro Input-Token setzt die Kosten einer Antwort, weshalb eine schnelle ID die Rechnung oft halbiert, ohne die Retrieval-Qualität anzutasten.
• claude-sonnet-4-6 ist der verlässliche Default für verankerte Antworten, die den abgerufenen Kontext respektieren und sauber ablehnen, wenn die Dokumente die Antwort nicht enthalten.
• High-Volume-Embedded-Produkte (Quivrs erklärter Use Case) laufen gut auf claude-haiku-4-5-20251001, deepseek-v4-flash oder gemini-3.5-flash für den alltäglichen Frage-Mix.
• max_context_tokens in derselben Config regelt, wie viel abgerufenen Kontext die Pipeline packt; ihn zu erhöhen passt natürlich zu Long-Context-IDs und erhöht Input-Ausgaben proportional.
• Unbekannte Model-Präfixe fallen für Budgetierung auf einen generischen Tokenizer zurück, was kosmetisch ist; der Request selbst trägt deine ID unverändert zum Endpoint.

Nutzungsbasiert · unter offiziellem Preis

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

Korrekturen zu gängigem Quivr-Wissen.

Kursierende Guides beschreiben Flächen, die Quivr nicht mehr hat, es lohnt sich also festzuhalten, was der aktuelle Code tatsächlich macht. quivr-core ist LangChain-gestützt, nicht LiteLLM-gestützt. Das supplier-Enum wählt eine LangChain-Chat-Klasse, und openai mappt zu ChatOpenAI mit deinem llm_base_url. Sagt dir ein Tutorial, einen LiteLLM-Proxy oder eine api_base-Einstellung innerhalb von Quivr zu konfigurieren, beschreibt es eine ältere Architektur; das aktuelle Feld ist llm_base_url auf LLMEndpointConfig. Die Full-Stack-App ist eingestellt. Anleitungen zu einer Backend-.env, Supabase-Setup oder einem In-App-Model-Picker beziehen sich auf die Pre-Pivot-Anwendung, die das Repository nicht mehr ausliefert. Konfiguration passiert jetzt in deinem Python-Code (oder deiner eigenen App um die Library herum). Die Key-Env-Var ist supplier-abgeleitet. Für supplier openai ist es OPENAI_API_KEY, selbst wenn der Endpoint nicht OpenAI ist. Willst du diesen Namen nicht überladen, übergib llm_api_key explizit in der Config, was Vorrang hat und die Umgebung sauber hält. Der Embedder ist separat. Generierungs-Routing bewegt Embeddings nicht; der Default-Embedder ist OpenAIEmbeddings mit eigenen Credentials. Entscheide die zwei Hälften unabhängig, und Neu-Embedding eines bestehenden Stores ist nur nötig, wenn du das Embedding-Modell selbst änderst.

Wer quivr-core über ein Gateway routet.

• Produktteams, die RAG in ihre Apps einbetten und das Generierungsmodell als Config-Wert statt als in den Stack gegossenes Vendor-Commitment wollen.
• Entwickler, die viele Brains auf verschiedenen Qualitätsstufen betreiben: ein Key, ein Endpoint, Model-ID pro Brain.
• Teams, die Claude-Qualität verankerte Antworten hinter einer OpenAI-förmigen Config wollen, ohne ein zweites SDK oder Provider-Konto hinzuzufügen.
• Builder, die Generierungsmodelle an einem festen Korpus benchmarken, wo jeder Kandidat eine LLMEndpointConfig-Änderung ist.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und das erste ask() debuggen.

Bestätige, dass das Gateway dein Modell listet, bevor du irgendetwas ingestierst; das model-Feld muss exakt zu einer bedienten ID passen. First-Run-Fehler sind vorhersehbar. Eine Warnung, dass der API-Key für supplier openai nicht gesetzt ist, bedeutet, weder llm_api_key noch OPENAI_API_KEY waren sichtbar, als die Config konstruiert wurde; die Warnung passiert bei der Konstruktion, der Fehler beim ersten ask(). Ein 401 bedeutet, der aufgelöste Key gehört nicht zum Endpoint in llm_base_url. Ein model-not-found-Fehler ist ein ID-Tippfehler gegen /v1/models. Und ein Embedding-bezogener Authentifizierungsfehler während Brain.from_files ist der separate Default-Embedder, der nach eigenen OpenAI-Credentials fragt, was keine llm_base_url-Einstellung beheben wird; übergib einen Embedder, den du kontrollierst. Sobald Antworten fließen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Für eine Library, die abgerufene Chunks in jeden Prompt packt, ist die Token-pro-Antwort-Zahl an deinem echten Korpus die Kennzahl, die deine Modellwahl treiben sollte.

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

Häufige Fragen