Wohin unsere LLM-API-Rechnung floss und welche Architekturänderungen sie senkten

Eine LLM-Rechnung kann hoch ausfallen, auch wenn die Modelle selbst nicht ungewöhnlich teuer sind. Hier lag es an Gewohnheiten: Derselbe System-Prompt mit 1.800 Tokens ging bei jedem Aufruf mit, Fehler wurden sofort und ohne Backoff wiederholt, und jeder Workflow-Schritt landete standardmäßig bei einem Frontier-Modell, ob er eines brauchte oder nicht. Für diese Last lautete die Schätzung, dass der ausgewiesene Tokenpreis etwa 20 % des Problems erklärte und die Architektur die übrigen 80 %. Diese Aufteilung gilt für genau dieses System und ist kein allgemeiner Benchmark. Die Lehre lässt sich trotzdem gut übertragen: Der Listenpreis pro Token nennt den Tarif, nicht, wie effizient Ihre App ihn nutzt.

Bevor der Anbieter gewechselt oder über Preise verhandelt wurde, bekamen die Ausgaben Messpunkte, sodass jede spätere Entscheidung auf Belegen beruhte und nicht auf Bauchgefühl. Was man nicht loggt, kann man nicht optimieren.

Tokens den Workflow-Schritten zuordnen

Die erste Voraussetzung ist eine Zuordnung auf Schrittebene. Erfassen Sie für jeden API-Aufruf den Workflow-Schritt, das Modell, die Input- und die Output-Tokens und aggregieren Sie nachts nach Schritt und Modell. Bei Preisen pro Million Tokens ergeben sich die Kosten eines Schritts so:

step cost =
number of calls × [
  (average input tokens ÷ 1,000,000 × input price per 1M tokens)
  +
  (average output tokens ÷ 1,000,000 × output price per 1M tokens)
]

Eine Woche Daten lieferte ein repräsentatives Bild für die Last eines Coding-Agents, und die wichtigste Erkenntnis war überraschend: Der Planungsschritt machte nur 8 % der Aufrufe aus, aber 41 % der Gesamtkosten. Teuer war er, weil er die längsten Kontexte mit dem teuersten Modell kombinierte. Vor der Messung galt die Code-Generierung als der teure Teil, und die Daten zeigten, dass das falsch war. Die reine Anzahl der Anfragen war nicht die richtige Kennzahl. Die Gesamtkosten pro Schritt waren es.

Eine minimale Umsetzung

Das erwies sich als einfach, weil API-Antworten die Token-Nutzung bereits mitliefern:

import logging
from openai import OpenAI

client = OpenAI(
    api_key="KEY",
    base_url="https://api.cometapi.com/v1",
)
def tracked_call(step_name, model, messages):
    response = client.chat.completions.create(
        model=model,
        messages=messages,
        temperature=0,
    )
    usage = response.usage
    logging.info(
        "llm_call step=%s model=%s prompt=%d completion=%d",
        step_name,
        model,
        usage.prompt_tokens,
        usage.completion_tokens,
    )
    return response

Mit diesen Logs ist der Kostenbericht im Grunde ein GROUP BY. Ziel ist keine aufwendige Observability-Plattform, sondern dass sich jeder Token einem Workflow-Schritt und einem Modell zuordnen lässt.

Den Gateway-Rabatt mitnehmen, aber als Untergrenze sehen

Die Anfragen laufen hier über CometAPI, und bei dieser Nutzung lagen die Kosten rund 20 % unter dem, was dieselbe Modellmischung direkt bei den Anbietern gekostet hätte. Das war eine Ersparnis mit wenig Aufwand: Client-Muster und Modellwahl blieben gleich, und die Rechnung sank über alle bereits genutzten Modelle hinweg. Sie wurde sofort umgesetzt, weil sie kaum Architekturarbeit verlangte.

Der größte Hebel war das Gateway allerdings nicht. Spätere Architekturänderungen sparten mehr, kosteten aber echte Engineering-Arbeit. Umsetzungsreihenfolge und finanzielle Wirkung decken sich nicht immer. Nehmen Sie günstige Preisvorteile also sofort mit und investieren Sie Engineering-Zeit in Modell-Routing, Prompt-Overhead und Retry-Verhalten. Es gibt keinen Grund, eine sofortige Ersparnis aufzuschieben, während man an etwas Raffinierterem baut, doch ein niedrigerer Tarif gleicht ein ineffizientes Anfragedesign nicht aus. Die Abrechnungsdetails stehen in der Preisdokumentation von CometAPI.

Jeden Schritt an die passende Modellstufe routen

Tiering bedeutet, verschiedenen Workflow-Schritten je nach benötigter Qualität verschiedene Modelle zuzuweisen. Die Planung brauchte tatsächlich ein Frontier-Modell. Sie hat wenig Volumen, aber große Wirkung, denn ein schlechter Plan kann jede folgende Aktion verderben. Massenänderungen und Lint-Fixes haben andere Bedürfnisse: hohes Volumen, eng begrenzt und leicht zu wiederholen oder zu prüfen. Die Routing-Logik wurde entsprechend angepasst:

def choose_model(step):
    if step in ("plan", "hard_refactor"):
        return "claude-sonnet-4-6"  # High-value reasoning steps

if step in ("bulk_edit", "lint_fix"):
        return "gemini-2.5-flash"  # Lower-cost, fast, retry failures
    return "gpt-5-mini"  # Middle-tier default

Damit wanderten 46 % der Aufrufe zu einem günstigeren, schnelleren Modell, während das teure für Planung und schwierige Generierung blieb. Tiering brachte die größte Einzelersparnis auf der Rechnung, weil es auf die volumenstarken Schritte zielte, statt kleinen Einsparungen bei seltenen hinterherzulaufen. Das Prinzip ist einfach: Das stärkste Modell gehört dorthin, wo Fehler weiter unten in der Kette am teuersten werden, nicht standardmäßig überallhin.

Den wiederholten Prompt-Overhead kappen

Der System-Prompt mit 1.800 Tokens fuhr bei jeder Anfrage mit. Ein Großteil davon war defensiver Boilerplate, der sich über Monate angesammelt hatte: Jede Anweisung wirkte beim Hinzufügen harmlos, zusammen bildeten sie aber hohe Fixkosten pro Aufruf. Die Lösung war, redundante Anweisungen zu streichen, nur die wesentlichen Vorgaben zu behalten und den stabilen Teil in ein gecachtes Präfix zu verschieben, wo immer der Anbieter Prompt Caching unterstützt.

Das Ausmaß wird leicht unterschätzt. Bei einer Million Aufrufen ergibt allein ein unveränderter System-Prompt mit 1.800 Tokens:

1,000,000 calls × 1,800 tokens
= 1.8 billion input tokens

und das noch vor jedem aufgabenspezifischen Kontext. Prompt-Tokens sind Tokens wie alle anderen. Der aufgeblähte Prompt erhöhte die API-Kosten und fraß zudem bei jeder Anfrage am Tokens-pro-Minute-Kontingent, sodass das Aufräumen doppelt half: Es senkte die wiederkehrenden Input-Kosten und ließ mehr nützliche Arbeit in dieselben Rate Limits passen. Gekürzt wurde vor dem Caching, denn überflüssigen Text zu cachen hätte das eigentliche Designproblem nur konserviert.

Wiederholen mit Backoff und Jitter

Wiederholungen machten 12 % der Aufrufe aus. Viele folgten auf eine HTTP-429-Antwort wegen Rate Limiting: Das System versuchte es sofort unter fast identischen Bedingungen erneut, bekam wieder einen 429 und schien die Sperrphase manchmal sogar zu verlängern. Exponentielles Backoff mit Jitter ersetzte die sofortige Wiederholung. Backoff vergrößert die Pause zwischen den Versuchen schrittweise, Jitter fügt etwas Zufall hinzu, damit parallele Anfragen nicht alle im selben Moment wiederholen. Das Volumen der Wiederholungen sank um mehr als die Hälfte.

Abgelehnte Anfragen werden nicht alle gleich abgerechnet, aber blinde Wiederholungen erhöhen trotzdem das Anfragevolumen und können wiederholte kostenpflichtige Arbeit auslösen, sobald eine Anfrage bis zur Modellausführung gelangt. Hier verbesserte die Retry-Steuerung die Zuverlässigkeit und hielt gleichzeitig die Kosten im Griff. Die allgemeine Regel: Eine Wiederholung sollte auf die Fehlerursache reagieren, und dieselbe Anfrage sofort erneut zu senden, ist keine Wiederherstellung.

Welche Änderung am meisten brachte

Die vier Änderungen setzten an verschiedenen Teilen der Kostengleichung an:

• Modell-Tiering brachte die größte Einzelersparnis: 46 % der Aufrufe wanderten zu einem günstigeren Modell, während das teure die wichtigste Arbeit behielt. Die Umsetzung dauerte etwa einen Tag.
• Gateway-Routing war die einfachste Sofortersparnis und senkte die Kosten derselben Modellmischung um etwa 20 %, fast ohne Engineering.
• Prompt-Kürzung und Caching beseitigten wiederkehrenden Input-Overhead, denn selbst die einfachste Aufgabe hatte den 1.800-Token-Prompt mitgeschleppt.
• Backoff und Jitter reduzierten unnötiges Anfragevolumen: Wiederholungen fielen von 12 % der Aufrufe auf weniger als die Hälfte davon.

Zusammen erreichten sie mehr als jede Änderung für sich. Addieren Sie die Einsparungen nicht, als wären es unabhängige Rabatte. Gateway-Preise verändern den Tarif pro Token, Tiering den gemischten Tarif über die Schritte, Prompt-Kürzung die Zahl der Input-Tokens und Retry-Steuerung die Zahl der Anfragen. Jede Änderung verschiebt zudem die Kostenbasis, auf der die nächste aufsetzt.

Monatliche Kosten berechnen

Angenommen, ein System verarbeitet eine Million Anfragen im Monat mit durchschnittlich 2.000 Input- und 500 Output-Tokens pro Anfrage. Das monatliche Tokenvolumen beträgt:

Input:
1,000,000 × 2,000
= 2 billion tokens

Output:
1,000,000 × 500
= 500 million tokens

Bei Preisen pro Million Tokens liegen die monatlichen Basiskosten bei:

monthly cost =
2,000 × input price per 1M tokens
+
500 × output price per 1M tokens

Hier senkte das Gateway diese Basis um etwa 20 %, noch bevor sich an der Architektur etwas änderte. Tiering drückte dann den gemischten Tokentarif, weil 46 % der Anfragen zu einem Modell wechselten, dessen Token nur einen Bruchteil kostet. Die Prompt-Kürzung verringerte die Input-Tokens jeder betroffenen Anfrage, und die Retry-Steuerung entfernte überflüssige Anfragen. Für eine korrekte Rechnung braucht es also vier Variablen: Anfragevolumen, das Verhältnis von Input- zu Output-Tokens, die Modellzuordnung pro Workflow-Schritt und die aktuellen Preise jedes Modells. Deshalb gibt es keine universelle Zahl à la „Sie sparen X %“. Eine brauchbare Schätzung ergibt sich nur aus Ihrer eigenen Last.

Drei Wege, wie Kostenarbeit schiefgeht

Seltene Schritte optimieren, weil es einfach ist. Es ist verlockend, bei einem kleinen Schritt Cent-Beträge herauszuholen, während ein volumenstarker Schritt den Großteil des Budgets verschlingt. Sortieren Sie die Ziele nach Gesamtkosten und nicht danach, wie leicht sie sich ändern lassen, und genau deshalb muss die Zuordnung zuerst kommen.

Kosten senken, ohne die Qualität zu testen. Ein Schritt wechselt auf ein günstigeres Modell, die Rechnung sinkt, und die Änderung sieht nach einem Erfolg aus. Drei Wochen später fällt jemandem die schlechtere Ausgabe auf. Sichern Sie jeden Modellwechsel mit einem Evaluationsset ab, einer repräsentativen Aufgabensammlung, die Regressionen aufdeckt. Eine Ersparnis, die die Qualitätshürde nicht nimmt, ist keine Optimierung.

Einen Cache bauen, bevor man die Wiederverwendung misst. Caching hilft nur dort, wo sich Inhalte wirklich wiederholen. Ein aufwendiger Cache, gebaut bevor die Wiederverwendung von Prompts geprüft wurde, kann Engineering-Zeit verbrennen, ohne den Hauptkostentreiber zu berühren. Prüfen Sie zuerst, wie viel Wiederholung es gibt, und cachen Sie erst dann die Präfixe oder Antworten, die tatsächlich wiederkehren. Kostenarbeit ohne Messung kann die Rechnung verbessern und dabei Qualität, Latenz oder Zuverlässigkeit verschlechtern.

Die Messung eingeschaltet lassen

Schalten Sie die Instrumentierung nach dem ersten Durchgang nicht ab, denn Kosten schleichen sich wieder ein. Der System-Prompt wird Stück für Stück länger, ein neuer Workflow-Schritt startet auf dem teuren Modell, ein alter Retry-Bug kehrt zurück, oder Traffic verlagert sich auf einen Schritt, der früher nebensächlich war. Das Dashboard, das das ursprüngliche Problem aufgedeckt hat, verhindert auch, dass es still zurückkommt. Eine monatliche Durchsicht der Kostentabelle pro Schritt dauert etwa zehn Minuten und hat bereits zwei Regressionen erwischt.

Architektur, nicht Preise

Ein Preis pro Token ist nur ein Tarif. Was Sie tatsächlich ausgeben, hängt von Ihrer Architektur ab: wie viele Tokens Sie kaufen, welche Modelle sie verarbeiten und wie viel Arbeit sich wiederholt. Für die Last dieses Coding-Agents war folgende Reihenfolge am wirksamsten:

1. Jeden Aufruf nach Workflow-Schritt und Modell instrumentieren.
2. Die aufwandsarme Gateway-Ersparnis mitnehmen.
3. Jeden Schritt an das günstigste Modell schicken, das seine Qualitätsanforderungen erfüllt.
4. Wiederholten Prompt-Overhead entfernen und stabile Präfixe cachen, wo das unterstützt wird.
5. Blinde Wiederholungen durch Backoff und Jitter ersetzen.
6. Das Monitoring dauerhaft beibehalten, damit sich die Kosten nicht wieder einschleichen.

Größter Gewinn: Tiering. Schnellster Gewinn: das Gateway mit knapp 20 %. Die Prompt-Kürzung nahm jeder Anfrage einen Fixkostenblock ab, und klügere Wiederholungen halbierten den Retry-Traffic und mehr. Die Jagd nach dem günstigsten beworbenen Tokenpreis zählt viel weniger als das Wissen, wohin Ihre eigenen Tokens fließen. Erst die Messung macht die Architektur sichtbar.