LLM-Kosten optimieren: Tokens, Caching, Batching
Wie du API-Kosten fuer LLMs senkst: Tokens richtig zaehlen, Modellwahl, Prompt Caching, Batching und laufende Kostenkontrolle.
Warum LLM-Kosten schnell aus dem Ruder laufen
Ein einzelner API-Call zu einem Sprachmodell kostet Bruchteile eines Rappens. Genau das ist die Falle: Weil jede einzelne Anfrage so billig wirkt, bauen Teams Features, die Hunderte oder Tausende Calls pro Tag ausloesen — ein Chatbot, der bei jeder Nachricht den ganzen Verlauf neu verschickt, ein Skript, das jede Zeile einer Excel-Tabelle einzeln durchs Modell schickt, ein Agent, der bei jedem Schritt den kompletten Systemprompt erneut mitschleppt. Am Ende des Monats steht dann eine Rechnung, die niemand erwartet hat.
Die gute Nachricht: Bei den grossen Anbietern (Anthropic, OpenAI, Google) gibt es eingebaute Mechanismen, die genau dieses Problem adressieren — Prompt Caching, Batch-APIs, kleinere Modelle fuer einfache Aufgaben. Wer sie kennt und nutzt, zahlt oft nur einen Bruchteil dessen, was eine naive Implementierung kosten wuerde. Dieser Artikel baut auf Tokens und Kontextfenster verstehen auf und zeigt die konkreten Hebel, mit denen du eine LLM-Integration wirtschaftlich betreibst.
Wie sich der Preis zusammensetzt
Fast alle Anbieter berechnen getrennte Preise pro 1 Million Tokens für:
- Input-Tokens — alles, was du ans Modell schickst: Systemprompt, Chatverlauf, Dokumente, Tool-Definitionen, Tool-Ergebnisse.
- Output-Tokens — was das Modell zurückliefert, inklusive interner “Denk”-Tokens bei Modellen mit Extended Thinking / Reasoning.
Output ist praktisch immer deutlich teurer als Input — oft um den Faktor 4 bis 6 — weil das Generieren von Text rechenintensiver ist als das reine Verarbeiten. Das hat eine wichtige Konsequenz: Bei Aufgaben mit langem Input und kurzem Output (z.B. “fasse dieses 50-Seiten-PDF in drei Saetzen zusammen”) dominiert der Input-Preis die Rechnung. Bei Aufgaben mit kurzem Input und langem Output (z.B. “schreib mir einen 2000-Woerter-Artikel ueber X”) dominiert der Output-Preis.
Tokens zaehlen, bevor du zahlst
Der wichtigste erste Schritt: Nicht raten, sondern zaehlen. Alle grossen Anbieter stellen dafuer kostenlose Werkzeuge bereit:
| Anbieter | Werkzeug | Hinweis |
|---|---|---|
| Anthropic | POST /v1/messages/count_tokens (API-Endpoint) | Rechnet modellgenau, kein eigener Tokenizer noetig |
| OpenAI | Bibliothek tiktoken (Python) | Lokal nutzbar, kein API-Call noetig |
| Google Gemini | countTokens-Methode in der Gemini API | Analog zu Anthropic ueber die API |
# Beispiel: Anthropic count_tokens vor dem eigentlichen Call
import anthropic
client = anthropic.Anthropic()
count = client.messages.count_tokens(
model="claude-sonnet-5",
messages=[{"role": "user", "content": long_document_text}],
)
geschaetzte_kosten_usd = count.input_tokens * 3 / 1_000_000 # Beispielpreis
print(f"Input-Tokens: {count.input_tokens}, ca. {geschaetzte_kosten_usd:.4f} USD")
Token-Zaehlung lohnt sich nicht nur zur Kostenschaetzung vorab, sondern auch, um teure Ausreisser zu finden: Ein Prompt-Template, das ungewollt ein komplettes JSON-Schema oder eine riesige Tool-Liste bei jedem Call mitschickt, faellt beim Zaehlen sofort auf.
Modellwahl: nicht jede Aufgabe braucht das teuerste Modell
Der groesste Hebel ist oft der einfachste: das richtige Modell fuer die Aufgabe waehlen, statt reflexartig das leistungsfaehigste zu nehmen. Anbieter staffeln ihre Modelle typischerweise in drei bis vier Klassen:
| Klasse | Typischer Einsatz | Kostenprofil |
|---|---|---|
| Flaggschiff (z.B. Opus-, GPT-Flaggschiff-, Gemini-Pro-Klasse) | Komplexe Analysen, mehrstufige Agenten, schwierige Coding-Aufgaben | Am teuersten, oft 5-10x das Basismodell |
| Mittelklasse (z.B. Sonnet-, GPT-Mainline-, Gemini-Standard-Klasse) | Die meisten produktiven Anwendungsfaelle: Chatbots, Zusammenfassungen, Extraktion | Guter Kompromiss aus Qualitaet und Preis |
| Klein/schnell (z.B. Haiku-, Mini-, Flash-Klasse) | Klassifikation, einfache Extraktion, Routing, hohe Volumen | Deutlich guenstiger, oft auch schneller |
Ein haeufiges Muster in der Praxis: ein kleines, schnelles Modell entscheidet zuerst, ob eine Anfrage ueberhaupt komplex ist (“Routing”), und nur die wirklich schwierigen Faelle werden an das teurere Flaggschiff-Modell weitergereicht. Das kann die Durchschnittskosten pro Anfrage massiv senken, ohne dass komplexe Faelle an Qualitaet verlieren.
Zusaetzlich bieten manche Anbieter innerhalb eines Modells regelbare “Denktiefe” (z.B. ueber einen Effort- oder Reasoning-Parameter): mehr interne Verarbeitung vor der Antwort erhoeht Qualitaet und Tokenverbrauch gleichzeitig. Fuer Routineaufgaben lohnt es sich, diesen Regler niedrig zu stellen und nur bei wirklich schwierigen Anfragen hochzuschalten.
Prompt Caching: nicht zweimal fuer denselben Kontext zahlen
Viele Anwendungen schicken bei jedem einzelnen Call denselben grossen, unveraenderten Textblock mit — einen langen Systemprompt, ein Firmenhandbuch, eine Tool-Definition, den bisherigen Chatverlauf. Ohne Caching wird dieser Block bei jeder Anfrage komplett neu zum vollen Preis verarbeitet.
Prompt Caching loest das: Der Anbieter merkt sich einen bereits verarbeiteten Textabschnitt fuer eine begrenzte Zeit (typischerweise 5 Minuten, teils mit Option auf 1 Stunde). Schickst du innerhalb dieser Zeit erneut denselben Abschnitt, wird er nicht neu verarbeitet, sondern aus dem Cache gelesen — zu einem Bruchteil des Normalpreises.
Wichtig zu verstehen: Caching funktioniert als Praefix-Treffer. Das bedeutet, jede Aenderung — und sei es nur ein einziges Zeichen — irgendwo im gecachten Textabschnitt macht den Cache fuer alles danach ungueltig. Praktische Konsequenz fuer den Prompt-Aufbau:
Reihenfolge, die Caching begünstigt:
1. Stabiler Teil zuerst (Systemprompt, Tool-Definitionen, Firmenhandbuch)
2. Session-spezifisch (User-ID, gewaehlte Sprache — aendert sich selten)
3. Variabler Teil zuletzt (die eigentliche Frage, Zeitstempel, Zufalls-IDs)
// Beispiel: Anthropic API mit Cache-Marker auf dem stabilen Systemprompt
{
"model": "claude-sonnet-5",
"system": [
{
"type": "text",
"text": "<sehr langer, stabiler Systemprompt / Firmenhandbuch>",
"cache_control": { "type": "ephemeral" }
}
],
"messages": [
{ "role": "user", "content": "Wie viele Urlaubstage habe ich noch?" }
]
}
Ob der Cache tatsaechlich greift, laesst sich in der API-Antwort ueberpruefen: Anthropic liefert dafuer die Felder cache_read_input_tokens und cache_creation_input_tokens in der usage-Antwort mit. Stehen die konstant auf null, obwohl derselbe Kontext wiederholt geschickt wird, steckt meist ein sich staendig aenderndes Detail im vermeintlich stabilen Teil des Prompts.
Batching: Geduld gegen Rabatt
Nicht jede Anfrage braucht eine Antwort in Echtzeit. Wer grosse Mengen an Anfragen verarbeitet, die nicht sofort beantwortet werden muessen — nächtliche Datenauswertung, Massen-Klassifikation von Support-Tickets, Uebersetzung eines ganzen Dokumentenarchivs — kann die Batch-API nutzen, die praktisch alle grossen Anbieter anbieten.
Das Prinzip: Statt einzelner synchroner Calls schickst du eine Sammlung von Anfragen auf einmal ein. Der Anbieter verarbeitet sie asynchron im Hintergrund (typischerweise innerhalb weniger Stunden, maximal innert 24 Stunden) und liefert die Ergebnisse gesammelt zurueck — zu einem deutlich reduzierten Preis, meist rund 50 % Rabatt auf den regulaeren Token-Preis (Stand: 2026-07).
# Beispiel: Anthropic Batch API fuer 1000 Support-Tickets zur Klassifikation
import anthropic
client = anthropic.Anthropic()
anfragen = [
{
"custom_id": f"ticket-{ticket['id']}",
"params": {
"model": "claude-haiku-4-5",
"max_tokens": 50,
"messages": [{"role": "user", "content": f"Kategorisiere: {ticket['text']}"}],
},
}
for ticket in support_tickets # z.B. 1000 Tickets
]
batch = client.messages.batches.create(requests=anfragen)
# Ergebnis spaeter abrufen, sobald batch.processing_status == "ended"
Die Kehrseite: Batch-Ergebnisse kommen nicht sofort. Fuer alles, was der Nutzer live sieht (Chat, interaktive Assistenten), ist die Batch-API ungeeignet — dort bleibt es bei normalen, synchronen Calls, ggf. kombiniert mit Prompt Caching.
Weitere Hebel: Kontext kuerzen, Streaming, strukturierte Ausgaben
Neben Modellwahl, Caching und Batching gibt es kleinere, aber oft unterschaetzte Stellschrauben:
- Kontext aktiv kuerzen: Nicht bei jedem Chat-Turn den kompletten Verlauf mitschicken, wenn aeltere Nachrichten fuer die aktuelle Frage irrelevant sind. Zusammenfassen oder abschneiden alter Turns spart Input-Tokens bei jeder einzelnen Folgeanfrage.
max_tokensrealistisch setzen: Ein zu hoch gesetztes Output-Limit kostet zwar nicht automatisch mehr (abgerechnet wird nur, was tatsaechlich generiert wird), aber unstrukturierte, zu offene Prompts fuehren oft zu laengeren, ausschweifenderen Antworten als noetig. Eine praezise Anweisung (“Antworte in maximal drei Saetzen”) reduziert Output-Tokens direkt.- Strukturierte Ausgaben statt Fliesstext: Wenn du ohnehin nur ein JSON-Feld extrahieren willst, liefert ein Modell mit “structured output” oder Tool-Use meist kompakter als eine ausformulierte Antwort in ganzen Saetzen.
- Bilder/Dokumente vorher verkleinern: Bild-Tokens skalieren mit Aufloesung. Ein Screenshot in voller 4K-Aufloesung verbraucht deutlich mehr Tokens als dieselbe Information in einer kleineren, aber noch lesbaren Aufloesung.
- Streaming nutzen: Kostet nicht weniger, verbessert aber die gefuehlte Reaktionszeit bei langen Antworten deutlich — relevant, wenn Nutzer sonst auf teure, lange Outputs warten muessen und abbrechen.
Kosten ueberwachen: Budgets, Alerts, Dashboards
Die beste Kostenoptimierung nuetzt nichts, wenn niemand merkt, wenn etwas aus dem Ruder laeuft. Jeder grosse Anbieter stellt dafuer Bordmittel bereit:
| Massnahme | Wo | Zweck |
|---|---|---|
| Ausgabenlimit / Budget-Alarm | Konsole des Anbieters (z.B. Anthropic Console, OpenAI Platform) | Warnung oder harter Stopp bei Ueberschreiten eines monatlichen Budgets |
| Nutzung nach Modell/Projekt filtern | Nutzungs-Dashboard des Anbieters | Erkennen, welches Feature oder Team die Kosten treibt |
usage-Feld in jeder API-Antwort auswerten | Eigener Code | Programmatisches Tracking pro Anfrage, z.B. in Logs oder einer eigenen Datenbank |
| Rate Limits pruefen | API-Dokumentation | Verhindert, dass ein Bug in einer Schleife unbemerkt Tausende Calls ausloest |
# Beispiel: eigenes Kosten-Logging in einem PowerShell-Wrapper-Skript
# (vereinfachtes Prinzip, nicht anbieterspezifisch)
$response = Invoke-RestMethod -Uri $apiUrl -Method Post -Body $body -Headers $headers
$inputTokens = $response.usage.input_tokens
$outputTokens = $response.usage.output_tokens
$geschaetzteKosten = ($inputTokens * 0.000003) + ($outputTokens * 0.000015)
Add-Content -Path "kosten-log.csv" -Value "$(Get-Date -Format o),$inputTokens,$outputTokens,$geschaetzteKosten"
Entscheidungsbaum: Welcher Hebel zuerst?
Wo entstehen die Kosten hauptsaechlich?
├─ Viele Anfragen mit demselben grossen Kontext (Systemprompt, Handbuch)?
│ → Prompt Caching einrichten (Praefix stabil halten, Cache-Marker setzen)
│
├─ Grosse Menge an Anfragen ohne Echtzeit-Anspruch?
│ → Batch-API nutzen (ca. 50 % Rabatt, Ergebnis nicht sofort noetig)
│
├─ Einfache, repetitive Aufgabe (Klassifikation, Routing, Extraktion)?
│ → Kleineres/schnelleres Modell testen, ggf. mit Routing-Logik
│
├─ Lange Chatverlaeufe oder unnoetig grosse Prompts?
│ → Kontext kuerzen, Verlauf zusammenfassen, praezisere Anweisungen
│
└─ Unklar, wo genau die Kosten entstehen?
→ Zuerst Token-Zaehlung + Nutzungs-Dashboard einrichten,
dann gezielt optimieren statt zu raten
Kurz zusammengefasst
- Input- und Output-Tokens werden getrennt abgerechnet, Output ist meist 4-6x teurer als Input.
- Zaehle Tokens mit dem anbieterspezifischen Werkzeug (nie
tiktokenfuer Claude oder Gemini verwenden). - Waehle das kleinste Modell, das die Aufgabe zuverlaessig loest — nicht automatisch das leistungsfaehigste.
- Prompt Caching spart bei wiederholt gleichem Kontext oft rund 90 % auf den gecachten Teil, funktioniert aber nur bei stabilem Praefix.
- Batch-APIs bringen bei nicht-zeitkritischen Massenanfragen rund 50 % Rabatt.
- Ohne laufende Kostenueberwachung (Budgets, Dashboards, eigenes Logging) bleiben alle anderen Massnahmen Zufall statt Kontrolle.
Weiterlernen
- Anthropic: Pricing — offizielle, stets aktuelle Preisliste
- Anthropic: Prompt caching — Funktionsweise und Implementierung
- Anthropic: Batch processing — Batch-API im Detail
- OpenAI: Pricing — offizielle Preisliste fuer GPT-Modelle
- OpenAI: Prompt caching — Caching-Mechanismus bei OpenAI
- Google: Gemini API pricing — Preisliste fuer Gemini-Modelle
Verwandte Themen: Tokens und Kontextfenster verstehen · LLM-APIs: Grundlagen · KI-Agents und Tool-Use · KI-Kosten und Lizenzen im KMU
Kommentare
Frage, Verbesserungsvorschlag oder eigene Erfahrung zu diesem Artikel? Schreib einen Kommentar. Neue Beiträge erscheinen nach kurzer Moderation.
- Lade Kommentare …