Kosten, Latenz und LLMOps

Token-Ökonomie

Gehostete Modelle werden pro Token abgerechnet, meist pro Million Tokens angegeben, mit getrennten Preisen für Eingabe-Tokens (alles, was gesendet wird: System-Prompt, Tool-Definitionen, abgerufene Dokumente, Gesprächsverlauf und die Nachricht des Nutzers) und Ausgabe-Tokens (alles, was erzeugt wird). Ausgabe-Tokens kosten in der Regel ein Mehrfaches der Eingabe-Tokens, weil die Eingabe parallel in einem Durchgang verarbeitet wird (dem Prefill), während die Ausgabe Token für Token erzeugt wird und jedes Token einen eigenen Durchlauf durch das Modell braucht (das Decode). Reasoning-Modelle (Abschnitt 12.1) rechnen außerdem ihre internen Reasoning-Tokens als Ausgabe ab, auch wenn diese nicht angezeigt werden, sodass dieselbe Frage je nachdem, wie lange das Modell nachdenkt, sehr unterschiedlich viel kosten kann.

Die Kosten eines Aufrufs sind einfach Eingabe-Tokens × Eingabepreis + Ausgabe-Tokens × Ausgabepreis. Die architektonischen Überraschungen liegen darin, was die Token-Zahlen treibt. In einem Chat wird normalerweise bei jeder Runde der gesamte Verlauf erneut gesendet, sodass die Eingabe mit jeder Runde wächst und die Summe über eine Unterhaltung ungefähr mit dem Quadrat ihrer Länge zunimmt. Tool-Definitionen und ein langer System-Prompt werden bei jedem Aufruf bezahlt. Retrieval fügt pro Frage Tausende Tokens hinzu, und Agenten, die in Schleifen Tools aufrufen (Abschnitt 12.4), machen pro Nutzeranfrage mehrere Aufrufe. In den meisten produktiven Assistenten dominieren die Eingabe-Tokens die Rechnung, obwohl jedes einzelne günstiger ist.

Ein Open-Weight-Modell selbst zu hosten verändert die Form der Kosten, statt sie zu beseitigen: Sie zahlen für GPU-Zeit, ob sie genutzt wird oder nicht, sodass die Kosten pro Token von der Auslastung abhängen und davon, wie viele Anfragen der Server gemeinsam verarbeiten kann. Die FinOps-Gewohnheiten aus Abschnitt 10.8 gelten unmittelbar: Drücken Sie Kosten pro Einheit Geschäftswert aus (pro Unterhaltung, pro gelöstem Ticket, pro verarbeitetem Dokument), vergleichen Sie sie mit der Alternative (den Bearbeitungskosten eines menschlichen Mitarbeiters) und ordnen Sie sie Funktionen und Teams zu. Die Preise in diesem Abschnitt sind beispielhafte Werte, gewählt für einfaches Rechnen, keine aktuellen Listenpreise; reale Preise unterscheiden sich zwischen Anbietern und sind im Lauf der Zeit stark gefallen.

Latenz: Time to First Token und Generierungsgeschwindigkeit

Die Latenz einer Modellantwort hat zwei Hauptteile. Die Time to First Token (TTFT) umfasst alles, bevor das erste Ausgabe-Token ankommt: Ihre eigene Vorverarbeitung (Eingabeprüfungen, Retrieval, Re-Ranking), das Netzwerk, die Warteschlange beim Anbieter und das Prefill, das mit der Zahl der Eingabe-Tokens wächst. Danach kommt die Ausgabe mit der Generierungsgeschwindigkeit des Modells, gemessen in Ausgabe-Tokens pro Sekunde, sodass die Gesamtzeit ungefähr TTFT + Ausgabe-Tokens ÷ Tokens pro Sekunde beträgt. Reasoning-Modelle schieben vor das erste sichtbare Token eine Denkphase, die Sekunden oder Minuten dauern kann.

Daraus folgt zweierlei. Erstens ist die Ausgabelänge meist der größte Hebel für die Latenz: Eine Antwort mit 400 Tokens zu halbieren spart mehr Zeit als jede Netzwerkoptimierung. Knappe Antworten anzufordern, eine maximale Ausgabelänge festzulegen und strukturierte Ausgaben statt Fließtext zu verwenden hilft. Zweitens ist jeder Tool-Aufruf ein vollständiger zusätzlicher Roundtrip mit eigenem Prefill und Decode, sodass ein Agent, der vor der Antwort vier Tool-Aufrufe macht, viermal so langsam ist wie ein einzelner Aufruf, unabhängig von der Geschwindigkeit des Modells. Spezifizieren und überwachen Sie die Latenz als Perzentile, nicht als Durchschnitt (Abschnitt 2.4): p95-TTFT und p95-Gesamtzeit pro Runde, weil die Warteschlangen der Modellanbieter den Tail zu Stoßzeiten viel länger machen als den Median.

Streaming

Streaming sendet Tokens an den Client, sobald sie erzeugt werden, typischerweise als Server-Sent Events über HTTP. Die Antwort ist dadurch nicht früher fertig, aber Nutzer beurteilen die Reaktionsfähigkeit weitgehend danach, wann etwas zu passieren beginnt, sodass sich eine Antwort von 4 Sekunden, die nach 1 Sekunde beginnt, viel schneller anfühlt als eine, die auf einmal erscheint. Streaming hat architektonische Kosten. Jeder Proxy, jedes Gateway und jeder Load Balancer auf dem Weg muss den Stream ohne Pufferung durchreichen und langlebige Verbindungen offen halten. Ausgabe-Guardrails (Abschnitt 12.6) können nicht mehr die ganze Antwort prüfen, bevor der Nutzer sie sieht; sie prüfen also entweder die Teile im Vorbeigehen (und müssen womöglich bereits angezeigten Text zurückziehen) oder halten den Stream etwa um einen Satz zurück. Strukturierte Ausgaben, die Aktionen auslösen, können erst umgesetzt werden, wenn sie vollständig und validiert sind; streamen Sie also den Fließtext an den Nutzer und heben Sie die Aktionen für das Ende auf. Abrechnung, Logging und Tracing müssen mit Streams zurechtkommen, die der Client mittendrin abbricht.

Prompt-Caching und semantisches Caching

Prompt-Caching (auch Prefix-Caching oder Context-Caching genannt) verwendet den vom Anbieter berechneten internen Zustand für ein identisches Prompt-Präfix wieder, das kürzlich verarbeitet wurde. Gecachte Eingabe-Tokens werden mit einem hohen Rabatt abgerechnet (manche Anbieter verlangen etwa ein Zehntel des normalen Eingabepreises, andere gewähren weniger Rabatt, und manche berechnen einen Aufschlag für das Schreiben in den Cache), und das Prefill für diesen Teil entfällt, was auch die TTFT senkt. Es ist die mit Abstand wirksamste Kostenoptimierung für Assistenten mit langen, stabilen Anweisungen. Es funktioniert nur, wenn das Präfix Byte für Byte identisch ist; damit wird der Aufbau des Prompts zu einem architektonischen Anliegen: statische Inhalte zuerst (System-Prompt, Tool-Definitionen, Richtlinien, Few-Shot-Beispiele), dann sich langsam ändernde Inhalte (der Gesprächsverlauf) und anfragespezifische Inhalte zuletzt (abgerufene Dokumente, die neue Nachricht). Ein Zeitstempel oder Nutzername am Anfang des System-Prompts hebelt den Cache unbemerkt aus. Selbst gehostete Inferenzserver wie vLLM bieten dieselbe Technik unter dem Namen Automatic Prefix Caching.

Semantisches Caching ist etwas anderes: Es speichert ganze Antworten mit der Bedeutung der Frage als Schlüssel, ermittelt über Embeddings, und liefert eine gespeicherte Antwort, wenn eine neue Frage ähnlich genug ist, ganz ohne Modell. Bei sich wiederholenden, nicht persönlichen Fragen (Wann liefern Sie?) kann es viel sparen, ist aber riskanter, als es aussieht. Ähnliche Fragen können unterschiedliche Antworten brauchen (Kann ich meine Bestellung stornieren? und Storniere meine Bestellung), der Ähnlichkeitsschwellenwert wägt Trefferquote gegen falsche Antworten ab, und die Regeln aus Abschnitt 7.6 gelten weiterhin: Der Schlüssel muss alles enthalten, was die Antwort verändert, gecachte Antworten veralten, wenn sich Richtlinien ändern, und Persönliches darf nie aus einem gemeinsamen Cache ausgeliefert werden. Messen Sie die Quote falscher Treffer an einer gelabelten Stichprobe, bevor Sie sich darauf verlassen. Ein einfacher Cache mit exakter Übereinstimmung für deterministische Aufrufe, etwa eine Klassifikation bei Temperature 0, ist einfacher und sicher.

Batching

Nicht jeder Modellaufruf braucht eine Antwort in Sekunden. Nächtliche Zusammenfassungen, das Verschlagworten eines Rückstaus von Tickets, das Erzeugen von Embeddings für eine Neuindizierung und das Ausführen von Evaluierungssuiten können alle warten. Die meisten großen Anbieter bieten Batch-Schnittstellen, die eine Datei mit Anfragen annehmen und die Ergebnisse asynchron innerhalb eines angegebenen Zeitfensters (häufig bis zu 24 Stunden) mit einem deutlichen Rabatt zurückgeben, oft etwa zum halben Normalpreis und mit getrennten, höheren Rate Limits. Architektonisch ist das die queuebasierte, asynchrone Verarbeitung aus Abschnitt 9.3: Gestalten Sie den Job idempotent, verfolgen Sie den Status jeder Anfrage und behandeln Sie Teilausfälle.

Bei selbst gehosteten Modellen findet das Batching im Inferenzserver statt: Continuous Batching verschränkt die Decode-Schritte vieler gleichzeitiger Anfragen auf einer GPU und vervielfacht so den Durchsatz. Die Abwägung ist die bekannte zwischen Durchsatz und Latenz: Größere Batches bedeuten günstigere Tokens, aber langsamere einzelne Antworten, daher werden interaktiver und Offline-Verkehr oft von getrennten Pools mit unterschiedlichen Einstellungen bedient.

Modellauswahl und Kaskaden für die Kosten

Die größte Kostenentscheidung ist, welches Modell welche Aufgabe übernimmt, und die Antwort lautet meist das kleinste, das die Evaluierungssuite für diese Aufgabe besteht (Abschnitt 12.5). Die Preise kleiner und großer Modelle unterscheiden sich häufig um den Faktor zehn oder mehr, während viele Aufgaben (die Absicht klassifizieren, eine Bestellnummer extrahieren, eine Statusfrage aus strukturierten Daten beantworten) kein großes Modell brauchen. Routing schickt jede Anfrage aufgrund einer günstigen Klassifikation an ein geeignetes Modell; eine Modellkaskade versucht zuerst ein kleines Modell und eskaliert an ein größeres, wenn die Ausgabe die Validierung nicht besteht oder das kleine Modell geringe Konfidenz signalisiert (Abschnitt 12.2). FrugalGPT (Chen, Zaharia und Zou, 2023) zeigte auf den dort verwendeten Benchmarks Kaskaden, die die Qualität des stärksten Modells zu einem Bruchteil der Kosten erreichten.

Die erwarteten Kosten einer zweistufigen Kaskade sind die Kosten des kleinen Modells plus die Eskalationsrate mal die Kosten des großen Modells. Kaskaden lohnen sich daher nur, wenn die meisten Anfragen beim kleinen Modell bleiben, und sie haben einen Haken bei der Latenz: Eskalierte Anfragen bezahlen beide Versuche, sodass der Tail langsamer wird, auch wenn sich der Durchschnitt verbessert. Vorgelagertes Routing vermeidet den doppelten Versuch, hängt aber von der Genauigkeit des Routers ab. Andere Token-Einsparungen sind oft noch günstiger: den System-Prompt kürzen, weniger, aber bessere Chunks abrufen, ältere Gesprächsrunden zusammenfassen, die Ausgabelänge begrenzen, bei Reasoning-Modellen für leichte Aufgaben den Reasoning-Aufwand senken und für eine einzelne Aufgabe mit sehr hohem Volumen Fine-Tuning oder Destillation eines kleinen Modells erwägen.

Kontingente, Rate Limits und Fallback-Kaskaden

Modellanbieter setzen Rate Limits durch: Anfragen pro Minute, Eingabe- und Ausgabe-Tokens pro Minute, gleichzeitige Anfragen und manchmal Tageslimits, signalisiert durch HTTP-429-Antworten, meist mit einem Retry-After-Header. Ihr eigenes Gateway sollte ebenfalls Kontingente durchsetzen, pro Nutzer, pro Mandant und pro Funktion, sowohl um Kapazität fair zu verteilen als auch um sich gegen das Risiko unbegrenzten Verbrauchs aus Abschnitt 12.6 zu schützen. Die Resilienzmuster aus Abschnitt 9.4 lassen sich übertragen: Timeouts bei jedem Aufruf, Wiederholungen mit exponentiellem Backoff und Jitter nur bei wiederholbaren Fehlern, Circuit Breaker, Bulkheads, die verhindern, dass eine laute Funktion das gemeinsame Kontingent aufbraucht, und Graceful Degradation (eine vorbereitete Antwort und ein Link zum menschlichen Support sind besser als ein Ladekreisel).

Eine Fallback-Kaskade listet alternative Modelle und Anbieter, die der Reihe nach versucht werden, wenn die erste Wahl ausfällt, durch Rate Limits gebremst wird oder ein ungültiges Ergebnis liefert. Gute Kaskaden haben ein Gesamtzeitbudget, damit der Nutzer nicht durch jede Stufe hindurch warten muss, lassen eine Stufe nach einer 429 so lange ruhen, wie der Anbieter verlangt, statt sie weiter zu bombardieren, behandeln eine nicht parsebare oder schemawidrige Antwort als Fehlschlag, der zur nächsten Stufe führt, und halten Prompts zwischen Modellen portabel. Jede Stufe muss die Evaluierungssuite bestehen: Ein ungetestetes Fallback-Modell bedeutet einen stillen Qualitätsverlust genau dann, wenn das System unter Last steht. Die KI-Funktionen dieses Kurses arbeiten selbst so. ArchitectBot und die Testbewertung probieren eine Kaskade gehosteter Open-Weight-Modelle mit einem Timeout pro Modell und einem Gesamtzeitbudget, pausieren ein Modell nach einer Rate-Limit-Antwort für die vom Anbieter verlangte Zeit und weichen als letztes Mittel auf einen zweiten Anbieter aus; Websuchen haben Tages- und Monatslimits, und Besucher unterliegen einem Rate Limiting.

LLMOps: Versionierung, Tracing und Kostenüberwachung

LLMOps ist die Gesamtheit der Praktiken, um Anwendungen auf Basis großer Sprachmodelle zu bauen, auszuliefern und zu betreiben; es überträgt MLOps und DevOps auf Komponenten, deren Verhalten ebenso durch Prompts, Modelle und Daten bestimmt wird wie durch Code. Seine erste Regel lautet, dass alles, was das Verhalten prägt, ein versioniertes Artefakt ist: Prompt-Vorlagen (im Repository oder in einer Prompt-Registry mit unveränderlichen Versionskennungen), Modellkennungen, die auf datierte Versionen statt auf veränderliche Aliase festgelegt sind, Tool-Schemas, Retrieval-Einstellungen, das Embedding-Modell und die Indexversion (ein Wechsel des Embedding-Modells bedeutet, den ganzen Korpus neu einzubetten), Guardrail-Regeln und die Evaluierungsdatensätze. Ein Release ist eine bestimmte Kombination davon, ausgerollt über dieselbe Pipeline, dieselben Feature-Flags und Canaries wie Code (Abschnitt 10.5), mit beigefügten Evaluierungsergebnissen.

Die zweite Regel lautet, dass jeder Modellaufruf getracet wird. Jeder Aufruf wird zu einem Span im Distributed Trace der Nutzeranfrage (Abschnitt 9.6), der Modell, Prompt-Version, Zahl der Eingabe- und Ausgabe-Tokens, Latenz, TTFT, Kosten und Ergebnis trägt, mit Child-Spans für Retrieval und Tool-Aufrufe, sodass sich eine langsame oder falsche Antwort Schritt für Schritt nachverfolgen lässt. Die semantischen Konventionen von OpenTelemetry für generative KI standardisieren die Namen, etwa gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model und gen_ai.usage.input_tokens, zusammen mit Metriken für Operationsdauer und Token-Verbrauch. Stand Oktober 2026 haben diese Konventionen noch den Status Development und sind kürzlich in ein eigenes Repository umgezogen; Namen haben sich zwischen Versionen geändert (aus gen_ai.system wurde zum Beispiel gen_ai.provider.name, und die Token-Metriken werden neu geordnet), legen Sie also die Version fest, die Ihre Instrumentierung ausgibt. Das Aufzeichnen der Texte von Prompts und Completions ist in den Konventionen aus gutem Grund optional (Opt-in): Es erfasst personenbezogene Daten und braucht deshalb die Aufbewahrungs- und Zugriffskontrollen aus Abschnitt 12.8.

Die dritte Regel lautet, dass Kosten wie Latenz überwacht werden. Ordnen Sie die Token-Ausgaben Funktion, Mandant, Modell und Prompt-Version zu; setzen Sie Budgets mit Alarmen sowohl auf die absoluten Ausgaben als auch auf die Stückkosten (Kosten pro Unterhaltung); und achten Sie auf die typischen Anzeichen von Problemen: eine Prompt-Änderung, die die Eingabe-Tokens verdoppelt hat, ein Agent, der in einer Tool-Schleife festhängt, eine Cache-Trefferquote, die nach einem Deployment eingebrochen ist, oder ein einzelnes Konto, das ein Zehntel des gesamten Verkehrs erzeugt. Schließlich läuft die Evaluierung in der Pipeline (Abschnitt 12.5), sodass Kosten, Latenz und Qualität für jedes Release gemeinsam beurteilt werden.

from opentelemetry import trace

tracer = trace.get_tracer("support-assistant")

def ask_model(client, messages, model="medium-2026-05", prompt_version="refund-v14"):
    with tracer.start_as_current_span(f"chat {model}") as span:
        span.set_attribute("gen_ai.operation.name", "chat")
        span.set_attribute("gen_ai.provider.name", "example-provider")
        span.set_attribute("gen_ai.request.model", model)
        span.set_attribute("app.prompt.version", prompt_version)  # our own attribute
        reply = client.chat(model=model, messages=messages, max_tokens=300)
        span.set_attribute("gen_ai.usage.input_tokens", reply.usage.input_tokens)
        span.set_attribute("gen_ai.usage.output_tokens", reply.usage.output_tokens)
        return reply