So leiten Sie LLM-Anfragen für jede Aufgabe an das richtige Modell weiter

Kurze Antwort: Routen Sie Anfragen in Ihrer Anwendung und verwenden Sie dann einen CometAPI-Schlüssel sowie die OpenAI-kompatible Basis-URL https://api.cometapi.com/v1, um das ausgewählte Modell aufzurufen. Senden Sie sich wiederholende, leicht überprüfbare Arbeiten an eine kostengünstige Stufe; latenzkritische Kundeninteraktionen an eine schnelle Stufe; und mehrdeutige oder geschäftskritische Arbeiten an eine Stufe mit hoher Genauigkeit. Behalten Sie die Labels als Ihre eigene Richtlinie – nicht als universelles Modellranking – und messen Sie jede Stufe auf demselben Testset.

Dieser Leitfaden baut diesen Drei-Stufen-Router mit einem kompakten Python-Beispiel, begrenztem Fallback und einem Kostenmodell auf, das erneute Versuche und abgelehnte Ausgaben berücksichtigt. Das Beispiel verwendet aktuelle Modell-IDs aus dem CometAPI-Katalog, doch die Routing-Logik bleibt separat, sodass Modelle ersetzt werden können, ohne die Anwendung neu zu schreiben.

Was ist LLM-Routing?

LLM-Routing ist der Prozess, jede Anfrage an das Modell oder die Servicestufe zu senden, die am besten zur Aufgabe, Latenzvorgabe, Qualitätsanforderung und zum Budget passt.

Wie sollten Sie LLM-Anfragen nach Aufgabe routen?

Stand 20. August 2026 waren die folgenden Modell-IDs und Katalog-Preisfelder über die öffentliche CometAPI Models API verfügbar. Die geschätzten Endkundenpreise unten wenden den aktuellen ratio-Wert des Katalogs auf die Basistarife für Eingabe- und Ausgabetokens an, gemäß dem CometAPI pricing guide. Bestätigen Sie vor der Produktivnutzung den endgültigen Tarif für Ihr Konto.

„Schnell“ bedeutet, dass diese Route eine Latenzvorgabe hat; „Hohe Genauigkeit“ bedeutet, dass sie eine strengere Qualitätsvorgabe hat. Keines der Labels beweist, dass ein Modell immer am schnellsten oder am genauesten ist. Messen Sie p50- und p95-Latenz, Aufgaben-Erfolgsrate und Kosten pro akzeptierter Ausgabe auf Ihrem eigenen Traffic, bevor Sie die Zuordnung fest verankern.

Wie richten Sie CometAPI für einen LLM-Router ein?

Sie benötigen einen CometAPI API-Schlüssel, Python 3.10 oder neuer, und das OpenAI-Python-Paket. Speichern Sie den Schlüssel serverseitig statt im Quellcode.

pip install openaiexport COMETAPI_KEY="your-key-here"

Das Beispiel verwendet POST /v1/chat/completions. CometAPI dokumentiert dies als gemeinsame Schnittstelle für mehrere Anbieter, aber das Parameterverhalten kann je nach Modell variieren. Prüfen Sie den aktuellen Modelleintag und die Chat Completions reference, bevor Sie anbieterspezifische Felder hinzufügen.

Was brauchen Sie, um einen LLM-Router zu bauen?

Stabile Aufgaben Servicestufen zuordnen. Bitten Sie kein anderes LLM, jede Anfrage zu klassifizieren, es sei denn, einfache Anwendungssignale reichen nicht. Ein Support-Tag ist vorhersagbar günstige Arbeit; eine Live-Antwort ist latenzkritisch; eine Richtlinienprüfung verdient die strengste Qualitätskontrolle.

Ausgabe validieren. Ein erfolgreicher HTTP-Status bedeutet nicht, dass das Ergebnis nutzbar ist. Übergeben Sie dem Router einen aufgabenspezifischen Validator. Ein Klassifikationsvalidator kann ein erlaubtes Label prüfen; ein Kundenantwort-Validator kann Länge und verbotene Aussagen erzwingen; ein strukturierter Workflow kann ein JSON-Schema validieren.

Fallback eng fassen. Versuchen Sie die nächste freigegebene Route nach einem Timeout, 408, 429, temporären 5xx oder einem begrenzten Qualitätsgate-Fehler. Verwenden Sie kein anderes Modell, um fehlerhafte Eingaben, einen ungültigen Schlüssel oder nicht unterstützte Parameter zu verdecken.

Wie bauen Sie einen LLM-Router in Python?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

Wie begrenzen Sie Retries vor einem Fallback?

Halten Sie SDK-Retries bei Null und kapseln Sie jeden Modellaufruf mit einem expliziten Limit. Der folgende Helper wiederholt nur einmal bei wiederholbaren API-Fehlern und wirft dann eine Ausnahme, sodass die äußere Route zur nächsten freigegebenen Stufe wechseln kann.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

Ersetzen Sie in route() den direkten Aufruf client.chat.completions.create(...) durch call_model(model, prompt). Mit drei Stufen endet eine Anfrage nach maximal sechs Anbieteraufrufen; Validierungsfehler eskalieren weiterhin einmal pro Stufe, anstatt dieselbe Ausgabe erneut zu versuchen.

Führen Sie es mit python3 llm_task_router.py aus. Um später Anbieter oder Modellgenerationen zu ändern, aktualisieren Sie MODELS; die Aufgabenrichtlinie und der Response-Vertrag bleiben an einem Ort.

Das Beispiel verwendet nur Parameter, die von den ausgewählten Modellen geteilt werden. Fügen Sie modell­spezifische Token-Kontrollen über eine Adapter-Schicht hinzu, nachdem Sie die Modellkompatibilität geprüft haben.

Wie testen Sie eine LLM-Routing-Richtlinie?

Prüfen Sie zuerst, dass die deterministische Richtlinie die beabsichtigte primäre Stufe auswählt. Das sind Routing-Erwartungen, keine Anbieterleistungsresultate:

Ein erfolgreicher Live-Smoke-Test liefert die Antwort plus die ausgewählte Stufe, die Modell-ID, den Tokenverbrauch und alle Versuche. Tatsächliche Token- und Latenzwerte variieren:

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Für einen echten Vergleich führen Sie dieselben gelabelten Anfragen durch alle drei Modelle. Erfassen Sie Aufgaben-Erfolgsrate, p50- und p95-Latenz, Fehlerrate, Eingabe- und Ausgabetokens, Fallback-Rate und Human-Review-Rate. Die relevante Kennzahl ist meist die Kosten pro akzeptierter Ausgabe, nicht die Kosten pro API-Aufruf.

Wie viel kostet Multi-Model-Routing?

Verwenden Sie eine einheitliche Lastform für einen fairen Vergleich. Gehen Sie von insgesamt 1 Million Tokens aus: 800.000 Eingabetokens und 200.000 Ausgabetokens. Mit den am 20. August 2026 geprüften katalogbasierten Tarifen:

Wenn 60% des Traffics günstig, 30% schnell und 10% mit hoher Genauigkeit sind, liegt die projizierte gemischte Token-Kostenrate bei etwa $1.19 pro 1 Million Gesamttokens. Den gleichen Mix vollständig an die Route „Hohe Genauigkeit“ zu senden, läge unter diesen Annahmen bei etwa $7.20. Dies ist eine Preiskalkulation, kein Beweis, dass die gemischte Richtlinie Ihr Qualitätsziel erfüllt.

Retries und Ablehnungen verändern das Ergebnis. Eine einmalige Retry-Rate von 5% erhöht die $1.19-Projektion auf etwa $1.25. Wenn eine kostengünstige Ausgabe die Validierung nicht besteht und die gesamte Anfrage auf der Stufe „Hohe Genauigkeit“ wiederholt wird, zählen Sie beide Aufrufe. Verfolgen Sie akzeptierte Ausgaben, damit ein scheinbar günstiges Modell Review- oder Regenerationskosten nicht verschleiert.

Was sind die häufigsten LLM-Routing-Fehler?

Der error and retry guide empfiehlt, Rate Limits und temporäre Plattformfehler mit Backoff zu wiederholen, während fehlerhafte Anfragen und Authentifizierungsfehler behoben werden sollten. Der fallback guide hält Modell-Fallbacks ebenfalls geordnet und explizit.

Application Routing vs. CometAPI Auto: Was sollten Sie verwenden?

Verwenden Sie Application Routing, wenn Kontrolle und Reproduzierbarkeit wichtig sind. Behalten Sie die Entscheidung in Ihrem Code, wenn Aufgaben stabil sind und Sie feste Modellidentitäten, stufenspezifische Budgets, benutzerdefinierte Validatoren und eine auditierbare Fallback-Reihenfolge benötigen. Dieser Ansatz erleichtert auch den Vergleich derselben Modellzuordnung über Releases hinweg.

Verwenden Sie CometAPI Auto , wenn die Reduktion des Routing-Aufwands wichtiger ist. Setzen Sie model=auto für einen ausgewogenen Standard oder model=auto-high, wenn die Qualität höhere Priorität hat. CometAPI wählt dynamisch ein geeignetes Modell basierend auf den Anfrageeigenschaften und dem aktuellen Routing-Pool; dadurch kann das zugrunde liegende Modell variieren. Das macht Auto weniger geeignet, wenn jeder Lauf dasselbe Modell oder modell­spezifische Parameter verwenden muss.

Wie betreiben Sie LLM-Routing in der Produktion?

Modellregister aktualisieren. Rufen Sie GET https://api.cometapi.com/api/models während der Bereitstellung oder beim Start auf und schlagen Sie die Veröffentlichung fehl, wenn eine konfigurierte ID oder ein erforderlicher Endpunkt fehlt. Modell-IDs, Preise und Fähigkeiten können sich ändern.

Anbieterspezifische Optionen aus dem Router heraushalten. Eine gemeinsame Chat Completions-Oberfläche macht nicht jeden Parameter identisch. Zum Beispiel können Unterstützung für logprobs, Reasoning-Kontrollen oder mehrere Kandidaten variieren. Legen Sie diese Unterschiede in getestete Adapter.

Traffic und Ausgaben begrenzen. Begrenzen Sie die Parallelität, bevor Anfragen die Anwendung verlassen, verwenden Sie exponentielles Backoff mit Jitter für 429, und setzen Sie eine Obergrenze für Ausgabetokens. Der rate-limit guide von CometAPI empfiehlt dieselben anwendungsseitigen Kontrollen.

Die Entscheidung protokollieren. Zeichnen Sie Aufgabentyp, Richtlinienversion, gewählte Stufe, Modell-ID, Latenz, Tokenverbrauch, Validierungsergebnis, Retry-Zahl, Fallback-Grund und Kostenschätzung auf. Vermeiden Sie das Protokollieren von Geheimnissen oder unnötigen Kundendaten.

Routen evidenzbasiert befördern. Halten Sie ein gelabeltes Evaluationsset für jede Aufgabe vor. Rollen Sie Zuordnungsänderungen schrittweise aus, vergleichen Sie sie mit der vorherigen Richtlinie und erhalten Sie einen schnellen Rollback-Pfad.

Häufig gestellte Fragen

Entscheidet CometAPI automatisch, welches Modell günstig, schnell oder genau ist?

Dieses Tutorial hält diese Richtlinie im Anwendungscode. CometAPI stellt den gemeinsamen Schlüssel, die Basis-URL, den Modellkatalog, die Chat Completions-Schnittstelle und dokumentierte Fallback-Bausteine bereit. Ihr Team definiert, was jede Stufe bedeutet und welches Modell seine Tests bestanden hat.

Kann ein CometAPI-Schlüssel Modelle verschiedener Anbieter aufrufen?

Ja. Für OpenAI-kompatible Text-Routen verwenden Sie https://api.cometapi.com/v1 und ändern den model-Wert. Der aktuelle Katalog sollte vor der Bereitstellung geprüft werden.

Warum nicht jede Anfrage an das günstigste Modell senden?

Der niedrigste Tokenpreis kann teuer werden, wenn Ausgaben die Validierung nicht bestehen, Retries nötig sind oder human Review verursachen. Vergleichen Sie die Kosten pro akzeptiertem Ergebnis und halten Sie hochwirksame Aufgaben hinter strengeren Qualitätskontrollen.

Sollte ein Qualitätsfehler einen Fallback auslösen?

Nur, wenn der Fehler maschinell erkennbar ist und die Eskalation begrenzt bleibt. Ein Schemafehler, ein fehlendes Pflichtfeld oder ein verbotenes Versprechen kann eine einmalige Eskalation rechtfertigen. Vage Unzufriedenheit sollte zu Evaluationsdaten werden, nicht zu einer unbegrenzten Retry-Schleife.

Wie oft sollte sich die Modellzuordnung ändern?

Ändern Sie sie, wenn aktuelle Katalogdaten und eine wiederholbare Evaluation einen besseren Trade-off zeigen. Rotieren Sie Modelle nicht nur, weil ein neuer Name im Katalog auftaucht.

Kann ich später ein OpenAI-Modell hinzufügen?

Ja. Fügen Sie eine aktuelle OpenAI-kompatible Modell-ID zu MODELS hinzu, testen Sie denselben Request-/Response-Vertrag und ordnen Sie sie in der Route ein. Client, Schlüssel und Basis-URL bleiben unverändert.

Wie halten Sie eine LLM-Routing-Richtlinie wartbar?

Der einfachste Multi-Provider-Router ist keine autonome Blackbox. Es ist eine kurze, versionierte Aufgabenrichtlinie, gestützt durch gemeinsamen API-Zugang, aktuelle Modelldaten, einen Qualitätsvalidator und eine schmale Fallback-Kette. CometAPI reduziert die Verbindungsarbeit auf einen Schlüssel und eine OpenAI-kompatible Basis-URL; Ihre Anwendung behält die Kontrolle über Kosten-, Latenz- und Qualitätsentscheidungen.