LLM-API-Kosten halbieren: Ein Leitfaden zum Modell-Routing für Produktions-Workloads im Jahr 2026

Das Kostenproblem, das sich in Ihrer Rechnung verbirgt

Schauen Sie sich den Modellparameter in Ihrem Produktionscode an. Bei den meisten Teams, die einen LLM-Workload von der Prototypenphase in echten Traffic überführt haben, wird dieser Parameter einmal gesetzt (meist auf das stärkste Modell, auf das das Team beim Launch Zugriff hatte) und nie wieder überprüft. Jede Anfrage, unabhängig von ihrer Komplexität, geht an dasselbe Modell. Und genau dort versteckt sich die stille Kostenüberschreitung.

In jedem nicht-trivialen Produktions-Workload sind Anfragen nicht gleich schwer. Ein Kundensupport-Assistent sieht vielleicht 80 % Anfragen, die einfache Lookups, Klassifikationen oder kurze Follow-ups sind, und 20 %, die wirklich Spitzen-Reasoning erfordern. Ein Coding-Assistent bewältigt möglicherweise einen stetigen Strom kleiner Refactorings und einen langen Tail an architektonischen Änderungen über mehrere Dateien. Eine Content-Pipeline verarbeitet Hunderte Zusammenfassungsaufgaben auf jede, die strukturierte kreative Texte benötigt. Die Form der Arbeit ist ungleichmäßig, das Routing zum Modell jedoch nicht.

Wenn Sie heute 100M Tokens pro Monat auf GPT-5.5 ausführen und 70 % dieser Anfragen genauso gut von einem günstigeren Modell beantwortet würden, zahlen Sie grob $600 pro Monat für Fähigkeiten, die Sie nicht nutzen. Bei höheren Volumina wächst dasselbe Muster linear mit: Pro 1B Tokens beträgt die Lücke zwischen einem nicht gerouteten Setup und einem gerouteten mehrere tausend Dollar pro Monat.

Routing ist die technische Antwort auf diese Asymmetrie. Das Prinzip ist einfach: Senden Sie jede Anfrage an das günstigste Modell, das sie bewältigen kann, und eskalieren Sie nur dann auf ein leistungsfähigeres Modell, wenn es nötig ist. Die Implementierungen sind dort, wo die interessanten Trade-offs liegen, und die meisten veröffentlichten Leitfäden behandeln sie schlecht. Dieses Stück behandelt die drei Muster, die in der Produktion tatsächlich funktionieren, die Kostenrechnung, die den Fall untermauert, die Fehlermodi, die Ihnen in die Quere kommen werden, und ein Migrations-Playbook, mit dem Sie von einem Einzelmodell-Setup zu einem gerouteten wechseln, ohne Ihre Anwendung neu zu schreiben.

Die Preisdaten, auf die sich dieser Artikel stützt, stammen aus dem Begleitstück (dem LLM-API-Preisvergleich 2026), das die modellbezogenen Tarife festlegt, auf die durchgängig Bezug genommen wird. Wo dieser Leitfaden eine Kostenzahl zitiert, stammt sie aus diesen Daten.

Die drei Routing-Muster, die in der Praxis funktionieren

Es gibt drei etablierte Muster für das Routing von LLM-Traffic. Sie unterscheiden sich in Implementierungskomplexität, Latenz-Overhead und den Arten von Einsparungen, die sie ermöglichen. Die meisten produktiven Systeme verwenden schließlich eine Kombination aus allen drei; das Verständnis der Stärken jedes einzelnen hilft Ihnen, die Arbeit zu sequenzieren.

Muster 1: Statische Regeln

Das einfachste Muster. Sie schreiben Regeln, die Anfragen basierend auf beobachtbaren Eigenschaften der Anfrage an verschiedene Modelle routen: Eingabelänge, Nutzer-Tier, Anfrageart (falls Sie bereits einen Klassifikator haben), API-Endpunkt oder Business-Logik. Kurze Anfragen gehen an ein günstiges Modell; lange Anfragen an ein stärkeres. Free-Tier-Nutzer erhalten ein günstigeres Modell als zahlende Nutzer. Codegenerierungsanfragen gehen an ein code-getuntes Modell; alles andere an ein General-Purpose-Modell.

Statisches Routing ist vorhersehbar, debugbar und fügt praktisch keinen Latenz-Overhead hinzu: Die Routing-Entscheidung sind ein paar Zeilen Code, die lokal laufen. Die Decke ist ebenfalls niedriger: Sie routen anhand von Eigenschaften, die Sie vor dem Modelllauf beobachten können, d. h., Sie können nicht auf „wie schwierig die Anfrage tatsächlich ist“ routen, weil Sie das noch nicht wissen. Für Workloads, bei denen Eingabeeigenschaften gut mit der Schwierigkeit korrelieren (lange Dokumente sind üblicherweise schwerer; Code unterscheidet sich in der Regel von Prosa; zahlende Nutzer haben typischerweise anspruchsvollere Anfragen), können statische Regeln 30–50 % der möglichen Einsparungen mit sehr wenig Engineering-Aufwand heben.

Muster 2: Kaskade

Das am breitesten anwendbare Muster. Sie senden die Anfrage zuerst an ein günstiges Modell; wenn die Antwort eine Qualitätsgrenze erfüllt, geben Sie sie zurück; wenn nicht, eskalieren Sie zu einem leistungsfähigeren Modell und verwenden stattdessen dessen Antwort. Die Kosteneinsparung ergibt sich daraus, dass Sie für die Anfragen, die das günstige Modell bewältigen kann, nur dessen Preis zahlen.

Das Unterscheidungsmerkmal des Kaskadenmusters ist, dass die Routing-Entscheidung durch die Ausgabe des Modells informiert ist, nicht nur durch die Eingabe: Sie lassen das günstige Modell die Arbeit versuchen und beurteilen dann, ob der Versuch gut genug war. Die Beurteilung kann auf mehrere Arten implementiert werden: Konfidenzscores vom Modell selbst, Validierung strukturierter Ausgaben (parst die Antwort als erwartetes Schema?), Selbstevaluations-Prompts (ein kleines Modell fragen, ob die Antwort die Frage beantwortet), oder nachgelagerte Verhaltenssignale (hat der Nutzer die Antwort akzeptiert oder umformuliert und erneut gefragt?).

Kaskaden werden von den meisten produktiven Systemen schließlich übernommen, weil sie Einsparungen erfassen, die statische Regeln nicht können. Der Trade-off ist, dass Sie bei Anfragen, die eskalieren, sowohl den Aufruf des günstigen Modells als auch den des Flaggschiffs zahlen, sodass die Einsparung davon abhängt, welcher Anteil der Anfragen auf der günstigen Stufe erfolgreich ist. Dieses Muster arbeiten wir später in diesem Artikel im Detail durch.

Muster 3: Klassifikatorbasiertes Routing

Die höchste Decke und der größte Engineering-Aufwand. Ein kleines, schnelles Modell (oft eine feinabgestimmte Version eines Modells unterhalb der Spitzenklasse oder ein dedizierter Klassifikator) betrachtet jede eingehende Anfrage und sagt voraus, welches Downstream-Modell sie bearbeiten sollte. Der Klassifikator kann anhand der Anfrageart entscheiden („das sieht nach einer Codegenerierungsaufgabe aus; route zum code-getunten Modell“), anhand einer Schwierigkeitsschätzung („das sieht nach einer harten Reasoning-Anfrage aus; route zu GPT-5.5“) oder anhand einer gelernten Routing-Policy, trainiert auf historischem Traffic und Outcomes.

Klassifikatorbasiertes Routing kann Kaskaden übertreffen, weil die Routing-Entscheidung erfolgt, bevor ein teures Modell läuft, sodass Sie die „günstiges Modell“-Kosten bei Anfragen vermeiden, die ohnehin das Flaggschiff benötigen. Der Preis dafür ist die Ingenieursarbeit, den Klassifikator selbst zu bauen, zu trainieren und zu warten, plus der kleine Latenz-Overhead des Routing-Calls. Für sehr hochvolumige Workloads zahlt sich dieser Trade-off aus; für kleinere Workloads meist nicht.

Welche Vorgehensweise zuerst: Statische Regeln zuerst, wenn Ihr Workload offensichtliche Routing-Signale hat (Eingabelänge, Nutzer-Tier, Endpunkt). Kaskade, wenn nicht – oder sobald Sie die offensichtlichen statischen Regeln ausgeschöpft haben. Klassifikatorbasiert erst, nachdem sowohl statische Regeln als auch Kaskade implementiert sind und das Workload-Volumen die Ingenieursinvestition rechtfertigt. Direkt zum klassifikatorbasierten Routing zu springen, ist eine klassische Overengineering-Falle, die die meisten Teams bereuen.

Was Sie messen sollten, bevor Sie mit Routing beginnen

Sie können nicht optimieren, was Sie nicht messen. Bevor Sie irgendeine Routing-Logik in ein produktives System einführen, instrumentieren Sie den aktuellen Einzelmodell-Workload, damit Sie eine Basislinie zum Vergleich haben. Die Instrumentierung muss nicht aufwendig sein: Ein einfaches Log jeder Anfrage mit einem kleinen Set an Feldern reicht für den Anfang.

Die minimal sinnvolle Instrumentierung:

• Pro Anfrage: verwendetes Modell, Eingabe-Tokenanzahl, Ausgabe-Tokenanzahl, Kosten (aus Tokenzahlen und Preisliste berechnet), End-to-End-Latenz, Antwortstatus (Erfolg / Fehler / teilweise) sowie ein Anfrage-Typ-Label, falls vorhanden.
• Pro Konversation oder pro Nutzer: Sitzungsdauer, Anzahl der Retries (signalisiert, dass der Nutzer die erste Antwort nicht akzeptiert hat), Follow-up-Rate (signalisiert, dass die Antwort Klärung erforderte).
• Ein zurückgehaltenes Evaluationsset: 100–500 repräsentative Anfragen, die Sie auf jedem Modell erneut ausführen können, mit Referenzausgaben, denen Sie vertrauen. So messen Sie, ob ein potenziell günstigeres Modell auf Ihrem Workload akzeptable Qualität liefert. Ohne das ist jede Routing-Entscheidung ein Ratespiel.

Das Evaluationsset ist der Bereich, in den die meisten Teams zu wenig investieren, und es ist das mit Abstand wirkungsvollste Stück Infrastruktur für jedes Routing-Projekt. Leichte Tools wie Promptfoo oder Helicone Evals lassen sich schnell aufsetzen; für frühe Workloads reicht ein handkuratiertes Set aus 50 Anfragen mit manuell bewerteten Ausgaben völlig aus.

Sobald instrumentiert, lassen Sie den Workload mindestens eine Woche lang im aktuellen Zustand laufen, um die Basislinie zu etablieren. Die Form der Daten (wie schief ist Ihre Eingabelängenverteilung, welcher Anteil der Anfragen ist kurz und einfach, welcher Anteil sieht schwer aus) sagt Ihnen, mit welchem Routing-Muster Sie beginnen sollten.

Das Kaskadenmuster im Detail, mit Kostenrechnung

Das Kaskadenmuster verdient den meisten Platz, weil es am breitesten anwendbar ist und dasjenige, das die meisten Teams zuerst oder als zweites implementieren werden. Die Mathematik ist auch der Punkt, an dem der Fall für Routing konkret wird.

Betrachten Sie einen repräsentativen Produktions-Workload, der heute auf Claude Sonnet 4.6 läuft: 100 Millionen Tokens pro Monat, 80 % Input und 20 % Output, $475 Monatsrechnung zum Listenpreis. Nehmen wir an, wir schalten eine Kaskade davor: Anfragen treffen zuerst auf Claude Haiku 4.5 und eskalieren nur dann zu Sonnet 4.6, wenn Haikus Antwort eine Qualitätsprüfung nicht besteht. Haiku 4.5 hat einen Listenpreis von $1.00 für Input und $5.00 für Output pro Million Tokens, ein Drittel von Sonnets Rate.

Die Kostenrechnung hängt von zwei Parametern ab: wie viel Prozent der Anfragen auf der Haiku-Stufe erfolgreich sind (wir nennen das die Erfolgsrate) und wie sich das Input/Output-Verhältnis zwischen erfolgreichen und eskalierten Anfragen unterscheidet. Der Einfachheit halber nehmen wir an, dass das Input/Output-Verhältnis für beide gleich ist und dass die Erfolgsrate 70 % beträgt, d. h., Haikus Antwort ist bei 70 % der Anfragen gut genug und 30 % eskalieren zu Sonnet.

Was das aussagt. Selbst bei moderaten 70 % Erfolgsrate (Haiku liegt 7 von 10 Mal richtig) halbiert die Kaskade die Rechnung. Der Grund ist, dass der Aufruf des günstigen Modells so viel billiger ist als der des Flaggschiffs, dass es selbst dann noch deutlich günstiger ist, auf den 30 % eskalierenden Anfragen für beide zu zahlen, als auf jeder Anfrage für das Flaggschiff zu zahlen. Der Break-even-Punkt (an dem die Kaskade den gleichen Preis wie das Einzelmodell hat) liegt grob bei einer Erfolgsrate von etwa 33 %. Darunter fahren Sie direkt besser; darüber gewinnt die Kaskade.

Die minimal tragfähige Kaskadenimplementierung

Nachfolgend die einfachste Version des Musters, ausgedrückt in Python mit dem OpenAI-kompatiblen Client (funktioniert gegen jeden Anbieter, der einen OpenAI-kompatiblen Endpunkt bereitstellt, einschließlich Claude via Anthropics Kompatibilitätsschicht, Gemini und den einheitlichen Endpunkt von CometAPI). Die Struktur ist absichtlich schlank; produktive Implementierungen fügen Observability, Fehlerbehandlung und ausgefeiltere Qualitätsprüfungen hinzu.

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # oder ein Anbieter Ihrer Wahl
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Eine Abfrage durch eine Kaskade ausführen.
    Gibt (response, model_used, escalated) zurück.
    """

    # Schritt 1: günstiges Modell ausprobieren
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Schritt 2: beurteilen, ob die günstige Antwort gut genug ist
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Schritt 3: auf das Flaggschiff eskalieren
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Qualitäts-Gate.
    Gibt True zurück, wenn die Ausgabe des günstigen Modells ausreichend gut ist.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Strukturierte Ausgabe: Sie muss gegen das Schema parsebar sein
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # Für freie Textantworten eigene Qualitätssignale einstecken:
    # - Konfidenzscore vom Modell
    # - Selbstevaluation durch ein kleines Modell
    # - Regelbasierte Checks (Länge, Format, Verweigerungsmuster)

    return True

Das ist ein Startpunkt, keine fertige Implementierung. Drei Dinge sollten Sie für die Produktion ergänzen:

• Ein echtes Qualitäts-Gate. Die Funktion is_acceptable oben ist absichtlich minimal. In der Praxis ist das Gate das wichtigste Teil der Kaskade: zu großzügig und Sie liefern minderwertige Antworten aus; zu streng und Sie eskalieren zu oft und verlieren die Einsparungen. Die meisten produktiven Kaskaden kombinieren Validierung strukturierter Ausgaben, Verweigerungserkennung (das günstige Modell sagt „Ich kann das nicht beantworten“) und Selbstevaluation durch ein kleines Modell, das zur Bewertung der Antwort aufgefordert wird.
• Pro-Anfrage-Observability. Protokollieren Sie, welches Modell verwendet wurde, ob die Anfrage eskalierte, die Latenz auf jeder Stufe und die Kosten. So sehen Sie nach einer Woche Kaskadenbetrieb, ob die Erfolgsrate dem entspricht, was Sie angenommen haben.
• Ein Canary-Pfad zur Evaluation. Leiten Sie einen kleinen Prozentsatz des Traffics (z. B. 5 %) durchs Flaggschiff, selbst wenn die Kaskade auf der günstigen Stufe „besteht“. Vergleichen Sie die Antworten anhand einer zurückgehaltenen Bewertungsaufgabe. So fangen Sie stille Qualitätsdegradation ab; siehe nächsten Abschnitt.

Wo Routing scheitert

Die oben genannte Kostenrechnung ist real, aber sie ist auch der optimistische Fall. Drei Fehlermodi erwischen Teams regelmäßig; sie ehrlich zu benennen, trennt eine Routing-Implementierung, die Wert kumuliert, von einer, die das Produkt leise verschlechtert.

Latenz-Overhead bei eskalierten Anfragen

Wenn eine Anfrage eskaliert, zahlen Sie für den Aufruf des günstigen Modells, bevor der Aufruf des Flaggschiffmodells beginnt. Wenn das günstige Modell 800ms benötigt und das Flaggschiff 1.5s, dauert die eskalierte Anfrage 2.3s End-to-End. Für latenzsensitive Workloads ist das relevant. Abhilfen sind, ein schnelles günstiges Modell zu wählen (Haiku 4.5 und Gemini 3 Flash sind dafür ausgelegt), aggressive Timeouts auf dem günstigen Modell zu setzen und für Anfragen, die sehr wahrscheinlich eskalieren, parallele Aufrufe in Betracht zu ziehen. Manche Teams akzeptieren die Latenzkosten, weil die Dollar-Einsparung groß ist; andere nutzen statische Regeln, um offensichtlich harte Anfragen gar nicht durch die Kaskade zu schicken.

Schleichende Qualitätsverschlechterung

Der heimtückischste Fehlmodus. Das günstige Modell erzeugt Antworten, die Ihr Qualitäts-Gate bestehen, aber subtil schlechter sind als die Antworten des Flaggschiffs: etwas weniger genau, etwas weniger hilfreich, etwas anfälliger, Randfälle zu übersehen. Nutzer beschweren sich nicht sofort; die Metrik, die Sie beobachten (Antwortlatenz, Fehlerrate, Gate-Pass-Rate), sieht gut aus; aber nachgelagerte Metriken (Nutzerbindung, Conversion-Rate, Support-Eskalationen) driften. Wenn Sie es bemerken, haben Sie bereits wochenlang verschlechterte Qualität ausgeliefert.

Die Verteidigung ist der oben erwähnte Canary-Pfad: ein zurückgehaltener Prozentsatz des Traffics, der parallel zur Kaskade durchs Flaggschiff läuft und dessen Antworten anhand eines Bewertungsrubrics beurteilt werden. Die Bewertung kann durch ein Modell selbst erfolgen (LLM-als-Gutachter) oder durch stichprobenartige manuelle Prüfung. Der Punkt ist, ein kontinuierliches Qualitätssignal aufrechtzuerhalten, das unabhängig vom Gate der Kaskade ist, sodass Verschlechterung als Drift in diesem Signal sichtbar wird und nicht als nachgelagerte Überraschung.

Komplexitätskosten in Code und Observability

Jedes zusätzliche Modell im Routing-Graph ist ein weiteres Modell, das evaluiert, überwacht und aktualisiert werden muss, wenn sein Anbieter eine neue Version veröffentlicht. Eine zweistufige Kaskade ist beherrschbar; ein fünfmodelliger, klassifikatorbasierter Router mit separaten Pfaden für Code, RAG, Chat, Agents und Edge-Cases ist deutlich komplexer als das Einzelmodell-Setup, das er ersetzt hat. Die Komplexität lohnt sich, wenn das Workload-Volumen sie rechtfertigt; darunter kann die für die Wartung der Routing-Schicht aufgewendete Ingenieurszeit die Einsparungen übersteigen, die sie erzeugt. Seien Sie ehrlich zu Ihrer Volumenschwelle.

Wie Aggregatoren helfen (und wo nicht)

LLM-Aggregatoren (Services, die mehrere Modelle hinter einer einzigen OpenAI-kompatiblen API bereitstellen) interagieren in zwei unterschiedlichen Weisen mit Routing. Beide sind wichtig zu verstehen, denn die Antwort auf „Will ich einen Aggregator in meiner Routing-Architektur?“ hängt davon ab, welche Interaktion Ihnen wichtig ist.

Die echte Hilfe: den Integrationsaufwand abbauen

Eine Kaskade oder einen klassifikatorbasierten Router auf direkten Anbieter-APIs aufzubauen, bedeutet, mehrere SDKs, mehrere Authentifizierungsnachweise, mehrere Abrechnungsoberflächen und mehrere Sets an anbieterspezifischen Eigenheiten zu managen (Timeout-Verhalten, Fehlerformate, Ratenlimit-Semantik). Für ein Multi-Modell-Routing-Setup ist dieser Overhead real. Ein Aggregator wie CometAPI exponiert jedes Modell hinter einem einzigen OpenAI-kompatiblen Endpunkt, was bedeutet, dass die Codeänderung fürs Routing nur die Änderung des model-Parameters ist – ohne Anbieterwechsel, ohne separate Keys, ohne separate Observability-Schicht. Für Teams, deren primäres Hindernis fürs Routing der Integrationsaufwand und nicht die Qualitätsbewertung ist, ist das entscheidend.

Worauf man achten sollte: eingebaute Routing-Schichten

Manche Aggregatoren bieten ein „Smart Routing“ oder „Model Optimizer“-Feature, das das Modell basierend auf der Anfrage für Sie auswählt. Das kann fürs Prototyping nützlich sein, ist aber im Allgemeinen der falsche Default für die Produktion. Der Grund ist, dass die Routing-Entscheidung eine der workload-spezifischsten Dinge in Ihrem Stack ist: Was als „schwierig genug zum Eskalieren“ gilt, hängt von Ihren Bewertungskriterien, Ihrem Latenzbudget, Ihrer Qualitätsuntergrenze und Ihrer Kostenobergrenze ab. Eine generische Routing-Schicht kann keines davon wissen. Die meisten produktiven Systeme fahren besser mit einem dünnen, transparenten Aggregator (der dieselben Modelle exponiert, die Sie direkt ansprechen würden, mit einem Credential und einer Rechnung) plus eigener Routing-Logik obendrauf, als mit einer Blackbox-Routing-Schicht, die sie nicht feinjustieren können.

Das Migrations-Playbook

Ein sicherer, schrittweiser Weg von einem Einzelmodell-Produktions-Workload zu einem gerouteten. Das Prinzip ist durchgehend, Änderungen vorzunehmen, die jeweils reversibel sind, und die Wirkung jeder Änderung zu messen, bevor Sie die nächste vornehmen.

• Instrumentieren Sie den aktuellen Workload. Protokollieren Sie jede Anfrage mit Modell, Input/Output-Tokens, Kosten, Latenz und einem Anfrage-Typ-Label. Führen Sie das mindestens eine Woche aus, um eine Basislinie zu etablieren. Ohne das ist jeder weitere Schritt ein Ratespiel.
• Bauen Sie das Evaluationsset. Kuratieren Sie 100–500 repräsentative Anfragen mit Referenzausgaben, denen Sie vertrauen. Das ist das zurückgehaltene Set, mit dem Sie die Kaskade in jedem Schritt gegen die Einzelmodell-Basislinie vergleichen.
• Identifizieren Sie den volumenstärksten Anfragetyp. Finden Sie in den Instrumentierungsdaten die Kategorie, die den meisten Traffic ausmacht. Hier pilotieren Sie die Kaskade. Es muss nicht die einfachste Kategorie sein, nur die volumenstärkste, weil sich hier die Einsparungen konzentrieren.
• Bauen Sie einen Kaskadenprototyp für genau diesen Anfragetyp. Zwei Stufen: zuerst das günstige Modell, das Flaggschiff, falls das Qualitäts-Gate scheitert. Führen Sie ihn zuerst auf dem Evaluationsset aus. Vergleichen Sie Kosten und Qualität mit der Einzelmodell-Basislinie. Wenn die Qualität hält und die Kosten sinken, weiter; wenn die Qualität fällt, verschärfen Sie das Gate und versuchen Sie es erneut.
• Rollout hinter einem Traffic-Prozentsatz. Starten Sie mit 5–10 % des Produktionstraffics für den gewählten Anfragetyp. Führen Sie das mindestens eine Woche lang aus. Überwachen Sie die Eskalationsrate der Kaskade, die Kosten pro Anfrage, die Latenz auf jeder Stufe und den Qualitätsvergleich des Canary-Pfads. Wenn die Metriken der Vorhersage aus dem Prototyp entsprechen, erweitern Sie auf 25 %, dann 50 %, dann 100 %.
• Wiederholen Sie es für den nächsten Anfragetyp. Sobald der erste Anfragetyp vollständig migriert ist und die Einsparung realisiert wurde, gehen Sie zur nächsthöchstvolumigen Kategorie über. Jede Kaskade ist eine separate Entscheidung; nehmen Sie nicht an, dass ein Muster, das für einen Anfragetyp funktioniert hat, für einen anderen ebenfalls funktioniert.
• Richten Sie einen kontinuierlichen Qualitäts-Canary ein. Sobald mehrere Anfragetypen auf Kaskaden laufen, richten Sie den zurückgehaltenen Canary-Pfad dauerhaft ein, mit 5 % des Traffics, der zur Bewertung durchs Flaggschiff läuft. Das ist Ihr Frühwarnsystem für stille Degradation und hält die Routing-Schicht vertrauenswürdig, wenn sich Modelle ändern.

Wann sich Routing nicht lohnt

Ehrliche Anerkennung. Es gibt Workloads, bei denen sich die Ingenieursinvestition in Routing nicht auszahlt, und sie im Vorfeld zu erkennen spart Zeit:

• Einzelmodell-Workloads, bei denen ein Modell wirklich für alles die richtige Antwort ist. Wenn Ihr Evaluationsset auf der günstigen Stufe über den gesamten Workload einen spürbaren Qualitätsabfall zeigt, hat die Kaskade keine Grundlage. Ein Codegenerierungs-Workload, der durch Reasoning-Fähigkeiten limitiert ist, ist ein Beispiel: Haiku wird das Gate zu oft verfehlen, als dass die Kaskade Geld spart.
• Sehr niedrigvolumige Workloads. Unter ungefähr $200/Monat LLM-Ausgaben übersteigt die für Aufbau und Pflege der Routing-Schicht aufgewendete Ingenieurszeit typischerweise die Einsparungen. Die Schwelle ist workload-spezifisch, aber real. Seien Sie ehrlich, ob Ihre Ausgaben hoch genug sind, um die Arbeit zu rechtfertigen.
• Reglementierte Umgebungen, in denen der verantwortliche Anbieter (Vendor of Record) zählt. Wenn Ihre Compliance verlangt, dass aller Produktionstraffic über eine spezifische Anbieterbeziehung läuft, verkompliziert Multi-Modell-Routing diese Diskussion. Es kann weiterhin Routing-Optionen beim selben Anbieter geben (Sonnet → Opus bei Anthropic; GPT-5 nano → GPT-5.5 bei OpenAI), aber cross-provider Routing ist schwieriger zu rechtfertigen.

Die ehrliche Einordnung: Routing zahlt sich aus, wenn Ihr Workload hochvolumig ist, Ihre Anfragen nicht gleich schwer sind und Sie die Evaluationsinfrastruktur haben, um zu wissen, wann die Kaskade akzeptable Qualität liefert. Die meisten produktiven Workloads in signifikanter Größenordnung passen in diese Beschreibung; einige nicht – und liefern schneller, indem sie bei einem Einzelmodell bleiben. Beide Entscheidungen sind vertretbar.

Wie es weitergeht: Falls Sie die modellbezogene Preisliste, auf die sich dieser Artikel stützt, noch nicht durchgearbeitet haben: Das Begleitstück, Der LLM-API-Preisvergleich 2026: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash und DeepSeek V4, ist die Grundlage. Die dortigen Preisdaten machen die Kostenrechnung in diesem Leitfaden für Ihren spezifischen Workload konkret.