paper-qa gegen einen custom OpenAI-kompatiblen Endpoint betreiben.

Kurzantwort: ein Router-Dict mit api_base, pro Slot wiederverwendet.

paper-qas Settings-Objekt nimmt einen Modellnamen plus eine optionale LiteLLM-Router-Config pro Slot. Die Router-Config ist eine model_list, deren litellm_params api_base und api_key tragen, dasselbe dokumentierte Muster, das das README für lokal gehostete OpenAI-kompatible Server nutzt; ein Gateway ist einfach dieses Muster mit einer öffentlichen URL und einem echten Key. Setz llm und summary_llm auf den model_name, den du deklariert hast, häng die Config an beide Slots, und paper-qa routet über das Gateway. Der Modell-String innerhalb von litellm_params behält litellms Provider-Konvention: openai/<id> sagt litellm, Chat-Completions gegen deine api_base zu sprechen, und die ID nach dem Slash wird an den Endpoint durchgereicht, Claude-, GPT-, Gemini- und GLM-IDs sind also alle mit demselben Dict adressierbar.

gateway_config = dict(
    model_list=[
        dict(
            model_name="claude-sonnet-4-6",
            litellm_params=dict(
                model="openai/claude-sonnet-4-6",
                api_base="https://api.apisrouter.com/v1",
                api_key=os.getenv("APISROUTER_API_KEY"),
                temperature=0.1,
            ),
        )
    ]
)

Wo paper-qa Token ausgibt: drei Slots plus Embeddings.

paper-qa (Future-House auf GitHub, rund 9.000 Stars) macht Retrieval-Augmented Question Answering über wissenschaftliche PDFs mit einem agentischen Loop obendrauf: ein Agent entscheidet, wann er deine Bibliothek durchsucht, sammelt Evidenz-Chunks, fasst deren Relevanz zusammen und komponiert eine zitierte Antwort. Das bildet sich auf drei separat konfigurierbare LLM-Slots ab. summary_llm bewertet und verdichtet Evidenz pro abgerufenem Chunk, was ihn zum Volumen-Slot macht. llm schreibt die finale Antwort aus der zusammengetragenen Evidenz, der qualitätskritische Schritt. Und agent_llm (innerhalb der Agent-Einstellungen) trifft die Tool-Auswahl-Entscheidungen, die den Loop steuern. Alle drei defaulten auf ein OpenAI-Modell, und jeder hat ein passendes _config-Feld (llm_config, summary_llm_config, agent_llm_config), das dasselbe Router-Dict akzeptiert, ein Gateway-Config-Objekt kann also an jeden Slot gehängt werden, während der Modellname pro Slot unabhängig bleibt. Ein gängiger Split ist eine schnelle ID, die Evidenz zusammenfasst, und eine Frontier-ID, die Antworten schreibt, beide über einen Endpoint und Key. Embeddings sind die vierte Workload und bewusst getrennt: die Embedding-Einstellung (Standard text-embedding-3-small) baut den Vektorindex deiner Papers. Chat-Slots auf ein Gateway zu bewegen bewegt Embeddings nicht, und paper-qa unterstützt lokale sentence-transformers (das st--Präfix, via die local-Extras), falls du den Index komplett unabhängig von jedem entfernten Endpoint willst.

Vollständiges Setup: Settings mit Per-Slot-Configs.

Das vollständige Muster deklariert einen Router-Eintrag pro Modell, das du adressierbar haben willst, und hängt Configs Slot für Slot an. Zwei Einträge zu deklarieren, einen schnellen für Summaries und einen starken für Antworten, hält das ganze Setup in einem Dict. Dasselbe Routing funktioniert von der CLI aus, da pqa die Settings-Oberfläche exponiert, aber der Python-Pfad ist der reproduzierbare für Forschungsnutzung: das Settings-Objekt, das eine Antwort produziert hat, kann neben der Antwort selbst geloggt werden.

import os
from paperqa import Settings, ask
from paperqa.settings import AgentSettings

def entry(model_id, **params):
    return dict(
        model_name=model_id,
        litellm_params=dict(
            model=f"openai/{model_id}",
            api_base="https://api.apisrouter.com/v1",
            api_key=os.getenv("APISROUTER_API_KEY"),
            **params,
        ),
    )

gateway = dict(model_list=[
    entry("claude-sonnet-4-6", temperature=0.1),
    entry("claude-haiku-4-5-20251001", temperature=0.1),
])

answer = ask(
    "What is the evidence for LK-99 room-temperature superconductivity?",
    settings=Settings(
        llm="claude-sonnet-4-6",
        llm_config=gateway,
        summary_llm="claude-haiku-4-5-20251001",
        summary_llm_config=gateway,
        agent=AgentSettings(
            agent_llm="claude-sonnet-4-6",
            agent_llm_config=gateway,
        ),
        paper_directory="./papers",
    ),
)

Modelle pro Slot wählen.

Tune mit fixierter Evidenz-Pipeline: dieselbe Bibliothek, dieselben Fragen, tausch einen Slot nach dem anderen. Hinter einem Endpoint ist jeder Kandidat ein model_name-String, und das Nutzungslog pro Key bepreist jede Konfiguration pro Frage, die Zahl, die ein Labor tatsächlich budgetiert.

• summary_llm läuft einmal pro Evidenz-Chunk, bei jeder Frage. Bei einer ernsthaften Bibliothek ist das die überwältigende Mehrheit der Calls, eine schnelle ID (claude-haiku-4-5-20251001) setzt also den Kostenboden für das ganze System, während sie nur Relevanz beurteilen muss, keine Prosa schreiben.
• llm komponiert die zitierte Antwort aus zusammengetragener Evidenz. Hier passiert präzises, abgesichertes wissenschaftliches Schreiben oder eben nicht; claude-sonnet-4-6 und gpt-5.5 sind die verlässlichen Wahlen, und der Slot hat wenige Calls pro Frage, die Prämie ist also begrenzt.
• agent_llm steuert den Loop: ob erneut gesucht, mehr Evidenz gesammelt oder geantwortet wird. Schwache Entscheidungen hier verschwenden Token überall sonst, was eine Mid-Tier- oder bessere ID trotz des niedrigen Volumens des Slots zur ökonomischen Wahl macht.
• Long-Context-IDs wie gemini-3.1-pro-preview lohnen einen Test als Answer-Slot, wenn Fragen Evidenz aus vielen Papers gleichzeitig ziehen.

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.

Die Fehlerbilder speziell für paper-qa.

Ein Slot, der auf seinem Default bleibt. llm und llm_config zu setzen, aber nicht summary_llm_config, lässt Summarization auf dem Default-OpenAI-Modell, das dann OPENAI_API_KEY verlangt und scheitert (oder dein Routing still über zwei Endpoints splittet, falls dieser Key existiert). Jeder Slot hat sein eigenes _config-Feld; häng das Gateway-Dict an jeden Slot, den du bewegen willst, agent_llm_config eingeschlossen. Namen, die nicht zusammenpassen. Settings.llm muss gleich einem model_name in der model_list sein; litellm_params.model ist, was tatsächlich auf die Leitung geht. Verschieb den äußeren Namen, und der Router hat keine Route; verschreib die innere ID, und das Gateway gibt model-not-found zurück. Beim Debuggen prüf die zwei Strings separat, weil sie unterschiedlich scheitern. Embeddings, von denen angenommen wird, sie folgten. Der Embedding-Slot baut und befragt den Vektorindex und hat eigenen Default und eigene Config. Hast du keinen OpenAI-Key für das Default-Embedding, konfigurier embedding explizit, oder nutz lokale sentence-transformers über das st--Präfix. Embeddings später umzustellen bedeutet auch Reindexierung: Vektoren aus verschiedenen Embedding-Modellen mischen sich nicht. Fehlende Generierungslimits für lange Antworten. litellm_params akzeptiert max_tokens pro Eintrag, und die Upstream-Beispiele für lokale Endpoints setzen es bewusst. Ein Answer-Slot ohne sinnvolles Limit kann lange zitierte Antworten abschneiden, was wie Modellschwäche aussieht, aber ein Parameter ist. Routing für Parsing-Probleme verantwortlich machen. paper-qas Qualität hängt von PDF-Parsing und Chunking ab, bevor überhaupt ein Modell Text sieht. Zitieren Antworten nichts bei einer Bibliothek, die du für relevant hältst, inspizier den Indexierungsschritt; das Gateway sieht nur, was Retrieval ihm schickt.

Wer paper-qa über ein Gateway routet.

• Forschungsgruppen, die Literatur-QA über geteilte Bibliotheken laufen lassen, wo Nutzung pro Key "was gibt das Labor pro Frage aus" von einer Vermutung zu einem Report macht.
• Teams, die Claude-Qualitäts-wissenschaftliches Schreiben im Answer-Slot wollen, während sie das Summarization-Volumen auf einer schnellen ID halten, ein Key für beides.
• Builder, die paper-qa in interne Tools einbetten und ein Bündel Vendor-Secrets durch ein Gateway-Credential pro Umgebung ersetzen.
• Benchmarker, die Answer-Modelle an fixierten Evidenz-Pipelines vergleichen, wo jeder Kandidat ein Config-String ist statt einer Vendor-Integration.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und die erste Frage debuggen.

Bestätige, dass das Gateway die von dir deklarierten IDs bedient; der litellm_params.model-String nach openai/ muss exakt zu einer bedienten ID passen. Die Fehlerleiter bei einem ersten ask(): ein Fehler, der OPENAI_API_KEY verlangt, bedeutet, ein Slot ist noch auf seinem Default-Modell ohne angehängte Config; find heraus, welchen von llm, summary_llm und agent_llm du nicht bewegt hast. Ein 401 vom Gateway ist der api_key innerhalb von litellm_params. Ein Router-Fehler über ein unbekanntes Modell bedeutet, Settings.llm passt zu keinem model_name in der Liste. Fehlschläge während der Indexierung statt beim Antworten weisen auf die Embedding-Einstellung oder PDF-Parsing, nicht Chat-Routing. Eine Frage fächert in viele Summary-Calls plus Agent-Schritte plus die finale Antwort auf, nach dem ersten erfolgreichen Run zeigt die Per-Request-Ansicht der APIsRouter-Konsole also den Slot-Split in echten Token. Das ist die Zahl, die man beobachtet, während die Bibliothek wächst, weil Summary-Volumen mit abgerufener Evidenz skaliert, nicht nur mit der Fragenzahl.

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

Häufige Fragen