Token-Verbrauch (LLM) ist die Zahl der Tokens, die ein großes Sprachmodell für eine Anfrage verarbeitet: Input-Tokens für Prompt, Systemanweisungen, Verlauf und abgerufenen Kontext sowie Output-Tokens für die generierte Antwort. Er ist der wichtigste Kostentreiber bei LLMs, beeinflusst die Latenz stark und wird daher pro Aufruf, Funktion und Mandant gemessen.
Was ist Token-Verbrauch bei LLMs?
Sprachmodelle lesen keine Zeichen oder Wörter, sondern Tokens: Textfragmente, die ein Tokenizer erzeugt. Je nach Modell und Sprache ist ein Token ein kurzes Wort, ein Teil eines längeren Wortes oder ein Satzzeichen, und derselbe Satz kann bei verschiedenen Modellen unterschiedlich viele Tokens ergeben. Der Token-Verbrauch ist die Zahl dieser Tokens pro Anfrage, getrennt nach Input und Output.
Die meisten Modellanbieter liefern die Token-Zahlen in der API-Antwort mit und rechnen danach ab, in der Regel mit unterschiedlichen Preisen für Input- und Output-Tokens. Der Token-Verbrauch verbindet damit drei Dinge, die Teams interessieren: Kosten, Latenz und die Grenzen des Kontextfensters. Ihn zu messen, ist einer der ersten Schritte der LLM Observability.
Arten von Tokens
| Art | Inhalt | Warum relevant |
|---|---|---|
| Input-Tokens | Systemanweisungen, Nutzer-Prompt, Gesprächsverlauf, Tool-Definitionen, abgerufene Dokumente | Meist der größte Anteil in Chat- und RAG-Anwendungen |
| Output-Tokens | Die generierte Antwort, Argumente von Tool-Aufrufen | Werden nacheinander erzeugt und bestimmen die Antwortzeit |
| Gecachte Input-Tokens | Prompt-Präfixe aus einem Cache des Anbieters | Werden von vielen Anbietern günstiger abgerechnet |
| Reasoning-Tokens | Internes Schlussfolgern von Reasoning-Modellen, oft nicht sichtbar | Als Output abgerechnet, aber nicht Teil des zurückgegebenen Texts |
Welche Kategorien es gibt und wie sie abgerechnet werden, unterscheidet sich je nach Anbieter und Modell. Prüfen Sie daher immer die Dokumentation des Anbieters.
Token-Verbrauch mit OpenTelemetry messen
Die OpenTelemetry GenAI Semantic Conventions, derzeit im Status Development, definieren Span-Attribute für Token-Zahlen an jedem Modellaufruf:
gen_ai.usage.input_tokens: Input-Tokens einschließlich gecachter Tokensgen_ai.usage.output_tokens: Output-Tokensgen_ai.usage.cache_read.input_tokens: aus dem Cache bediente Input-Tokens
Attribute wie gen_ai.request.model, gen_ai.response.model und gen_ai.provider.name zeigen, wo die Tokens angefallen sind. Die Konventionen definieren außerdem Client-Metriken für den Verbrauch; frühere Versionen nutzten ein Histogramm namens gen_ai.client.token.usage, neuere Entwürfe definieren getrennte Zähler in der Familie gen_ai.client.inference.usage.*. Da sich die Konventionen noch weiterentwickeln, sollten Sie die Version Ihrer Instrumentierung festhalten und bei Updates die Release Notes prüfen.
Für Kostenauswertungen reichern Sie die Daten mit fachlichen Dimensionen wie Funktion, Mandant oder Agentenname an. Achten Sie dabei auf die Kardinalität: Nutzer-IDs oder Prompt-Hashes als Metrik-Labels erzeugen sehr viele Zeitreihen. Legen Sie solche Werte besser an Spans ab und aggregieren Sie später.
Beispiel: einen Kostentreiber finden
Ein illustratives Beispiel: Die Token-Ausgaben eines internen Assistenten verdoppeln sich innerhalb einer Woche, obwohl die Zahl der Anfragen etwa gleich bleibt. Gruppiert man die Input-Tokens pro Anfrage nach Funktion, zeigt sich, dass eine Chat-Funktion bei jeder Runde den vollständigen Gesprächsverlauf mitschickt. Die durchschnittlichen Input-Tokens pro Aufruf in dieser Funktion sind von etwa 2.000 auf etwa 9.000 gestiegen, die Output-Tokens sind unverändert.
Das Team begrenzt den Verlauf auf die letzten Runden plus eine kurze Zusammenfassung und stellt die statischen Systemanweisungen an den Anfang des Prompts, damit der Prompt-Cache des Anbieters greift. Das Dashboard zeigt danach wieder sinkende Input-Tokens pro Aufruf und einen steigenden Anteil gecachter Input-Tokens.
Best Practices zur Steuerung des Token-Verbrauchs
- Erfassen Sie Input- und Output-Tokens an jedem Modellaufruf, nicht nur über die Monatsrechnung des Anbieters.
- Beobachten Sie Tokens pro Anfrage und pro erfolgreichem Ergebnis, nicht nur Summen: Mehr Traffic ist normal, mehr Tokens pro Anfrage sind ein Signal.
- Kürzen Sie den Verlauf, entfernen Sie doppelte Chunks und begrenzen Sie die Zahl der Dokumente in RAG-Prompts.
- Legen Sie eine maximale Ausgabelänge fest, die zum Anwendungsfall passt.
- Strukturieren Sie Prompts mit einem stabilen Präfix, um vom Caching des Anbieters zu profitieren.
- Budgetieren Sie Agenten: Begrenzen Sie Schritte und Tokens pro Lauf, denn Schleifen vervielfachen den Verbrauch, wie unter KI-Agenten-Observability beschrieben.
- Alarmieren Sie bei sprunghaften Änderungen der Tokens pro Anfrage nach Deployments oder Prompt-Änderungen.
Typische Fehler
- Schätzen statt messen. Faustregeln auf Basis von Zeichen liegen oft deutlich daneben, insbesondere bei deutschen Texten, Quellcode und strukturierten Daten wie JSON.
- Versteckte Tokens übersehen. Tool-Definitionen, Systemanweisungen und Reasoning-Tokens fallen leicht unter den Tisch, zählen aber vollständig zum Verbrauch und zu den Kosten.
- Nur Summen betrachten. Eine stabile Monatssumme kann verbergen, dass der Verbrauch pro Anfrage in einer Funktion steigt, während er in einer anderen sinkt.
- Kein Bezug zum Ergebnis. Ein günstiger Aufruf, der eine unbrauchbare Antwort liefert, ist teurer als ein teurer Aufruf, der das Problem löst. Setzen Sie den Verbrauch daher ins Verhältnis zu erfolgreichen Ergebnissen.
Wie Obseria hilft
Obseria speichert GenAI-Spans und -Metriken, die per OTLP eingehen, und schlüsselt den Token-Verbrauch mit PromQL, OQL oder SQL nach Modell, Anbieter, Service, Funktion oder Mandant auf. Token-Metriken lassen sich mit Alerting und dem Cloud-Kostenmanagement kombinieren, sodass LLM-Ausgaben neben den Infrastrukturkosten sichtbar werden. Traces zeigen, welcher Schritt einer Anfrage die Tokens verbraucht hat.
