LLM-Token-Kosten 2026 senken: Routing, Caching, Kompression und das richtige Modell

Die Token-Preise sind eingebrochen, und trotzdem zahlen viele Teams heute mehr für LLM-Nutzung als noch vor einem Jahr. Der Grund ist einfach. Der Preis pro Token ist gefallen, aber agentische Produkte machen heute Dutzende bis Hunderte Modell-Calls pro Aufgabe, und die meisten dieser Tokens sind Kontext, den das Modell nie gebraucht hat. Günstige Tokens mal hohes Call-Volumen ergeben immer noch eine hohe Rechnung. Das ist der Plan, mit dem wir sie senken, ohne die Qualität zu opfern, und in der Reihenfolge, in der wir ihn anwenden.

Engineering-Perspektive, kein Vendor-Pitch. Die Preis- und Benchmark-Punkte unten sind Richtwerte aus öffentlichen 2026er-Preistrends, keine herstellerspezifischen Quotes. Die Referenzpunkte stammen aus Wavects Arbeit an KI-Produkten.

Warum ist deine LLM-Rechnung hoch, obwohl die Token-Preise eingebrochen sind?

In einer hohen Rechnung verstecken sich drei Dinge, und keines davon ist der plakative Preis pro Token:

• Call-Volumen. Ein Agent-Loop mit 50 bis 200 Modell-Calls pro Aufgabe macht aus einem günstigen Preis pro Token einen teuren Preis pro Aufgabe. Du zahlst pro Aufgabe, nicht pro Token.
• Verschwendeter Kontext. Ein großer Teil der Input-Tokens eines typischen Calls ist Kontext, den das Modell für diesen Schritt nicht braucht. Fachbeiträge schätzen die Verschwendung bei unoptimierten agentischen Workflows auf 40 bis 60 Prozent. Du zahlst für jeden dieser Tokens bei jedem Call.
• Das falsche Modell für die falsche Aufgabe. Jede Anfrage "sicherheitshalber" an ein Frontier-Modell zu routen, ist die häufigste Art, zu viel zu zahlen. Die meisten Anfragen brauchen nicht dein teuerstes Modell.

Behebe das in dieser Reihenfolge. Die günstigsten Gewinne kommen zuerst, und sie brauchen kein Modell-Retraining und keinen Architektur-Umbau.

Was ist der schnellste Gewinn? Prompt-Caching und Batching.

Bevor du deine Architektur anfasst, nimm die zwei Rabatte mit, die dir die Provider gratis schenken.

• Prompt-Caching. Wenn aufeinanderfolgende Calls einen stabilen Prefix teilen (System-Prompt, Instruktionen, abgerufener Kontext), kann der Provider die erneute Verarbeitung überspringen. Gecachter Input ist bei Anthropic rund 90 Prozent günstiger, bei OpenAI etwa halber Preis, und Google berechnet bei Cache-Hits rund 10 Prozent des Basispreises. Der Engineering-Hebel ist die Reihenfolge: stabile Inhalte zuerst, volatilen User-Input zuletzt, damit der Cache-Prefix über Calls hinweg intakt bleibt.
• Batch-Verarbeitung. Jeder große Provider bietet einen Batch-Endpoint zu rund halbem Live-Preis im Tausch gegen ein asynchrones Zeitfenster. Alles, was keine Sub-Sekunden-Antwort braucht, Evaluationen, Enrichment, Klassifikation, Summarization-Jobs, gehört in den Batch.

Diese Rabatte stapeln sich. Cache-Hit plus Batch auf demselben Workload landet gecachten Input rund 95 Prozent unter dem Standardpreis. Ein Team, das monatlich Hunderttausende Dokumente verarbeitet, kann eine vierstellige Monatsrechnung auf einen Bruchteil senken, indem es nichts ändert außer dem Endpoint und der Prompt-Reihenfolge.

"Die meisten Teams greifen zum Modellwechsel, wenn der günstigste Gewinn darin liegt, den Prompt so umzusortieren, dass der Cache überhaupt greift."

Wie senkt Model-Routing die Kosten, ohne die Qualität zu treffen?

Routing heißt: ein günstiges Modell erledigt die einfache Mehrheit, ein teures die schwere Minderheit. Blind gemacht senkt es die Qualität. Mit einem Confidence-Check nicht.

• Günstiger Default plus Eskalation. Lass zuerst ein Mid-Tier- oder kleines Modell laufen. Fällt ein strukturierter Confidence-Check durch, ist die Antwort unsicher, schema-invalide oder von einem Verifier markiert, eskaliere zum Frontier-Modell. Tracke die Eskalationsrate als Produkt-KPI. Eine steigende Rate sagt dir, dass das günstige Modell zu viel leisten soll.
• Router und Gateways. Offene Frameworks wie RouteLLM veröffentlichen harte Zahlen: rund 95 Prozent der Frontier-Qualität bei nur 14 bis 26 Prozent der Calls ans starke Modell, was als 75 bis 85 Prozent Kostensenkung auf dem gerouteten Traffic landet. Ein LLM-Gateway vor mehreren Providern gibt dir zudem einen Ort für Caching, Fallback und Spend-Limits.

Wir nutzen das Eskalations-Muster in produktiver KI-Arbeit, darunter Engagements wie Twinsoft AI. Was es sicher macht, ist dieselbe Disziplin wie überall hier: ein Eval-Harness, der dir sagt, ob der günstige Pfad die Qualität wirklich gehalten hat.

Welche Frontier-Modelle solltest du 2026 wirklich nutzen?

Es gibt kein einzelnes bestes Modell. Es gibt ein bestes Modell pro Aufgabe, und die Spanne bei Preis-Leistung ist inzwischen groß genug, dass die Modellwahl einer deiner größten Kostenhebel ist. Die 2026er-Landschaft teilt sich in zwei Lager.

• Westliche Frontier. Claude, GPT und Gemini führen weiterhin bei den härtesten Reasoning- und Coding-Aufgaben und bei den tiefsten Agent-Loops. Wenn eine falsche Antwort teuer ist, gewinnt das Frontier-Modell meist auf Gesamtkosten, sobald du die Entwicklerzeit fürs Korrigieren schlechter Outputs mitrechnest.
• Chinesische Open-Weight-Frontier. DeepSeek, Qwen, Kimi und GLM haben den Qualitätsabstand bei echtem Coding und Reasoning weitgehend geschlossen, zu Preisen, die häufig 15 bis 30 Mal niedriger pro Token liegen als die westliche Frontier. Für hochvolumige, kostensensible Workloads verschieben sie die Rechnung.

Richtwerte nach Klasse, normiert pro 1M Tokens. Als Momentaufnahme öffentlicher Trends behandeln, nicht als Quote, und vor dem Commit erneut prüfen.

Der Haken für ein EU-Team ist nicht die Qualität, sondern die Governance. Wo die Inferenz läuft und wo die Daten landen, ist für Datenresidenz und Compliance entscheidend. Nutze ein chinesisches Open-Weight-Modell self-hosted auf EU-Infrastruktur, und du behältst den Preisvorteil, ohne Daten ins Ausland zu senden. Nutze es über eine Nicht-EU-API, und du hast zuerst eine Compliance-Frage zu klären. So oder so: führe deinen eigenen Eval aus, bevor du wechselst. Ein günstigeres Modell, das 1 von 10 Aufgaben verfehlt, ist nicht günstiger.

Hybrid lokal plus Frontier: Wann zahlt sich Self-Hosting von Open Weights aus?

Das Hybrid-Muster ist ein kleines oder Open-Weight-Modell für den Großteil des Volumens, eine Frontier-API für den schweren Rest. Die Frage ist, wann man den Großteil ins Haus holt. Die ehrliche Antwort 2026: später, als die meisten Teams denken.

• Der Break-even wird durch Entwicklerzeit bestimmt, nicht durch GPU-Rack-Preise. Das Modell ist günstig im Betrieb. Ops, Eval-Disziplin und Upgrade-Kadenz sind es nicht.
• Für die meisten Produkte bleiben Hosted APIs günstiger, bis du ernsthaftes Volumen fährst, oft mit rund 50 Millionen Tokens pro Tag oder mehr beziffert, oder bis eine Datenresidenz-Anforderung lokales Hosting unabhängig von den Kosten erzwingt.
• Wenn du self-hostest, ist eine Inference-Engine wie vLLM plus quantisierte Open Weights (Llama-, Qwen-, DeepSeek-, Mistral-Klasse) der Standard-Produktions-Stack.

Default auf Hosted APIs für frühe Produkte. Self-Hosting wieder aufgreifen, sobald Volumen oder Compliance die Frage erzwingen. Tiefer in die Architektur-Implikationen gehen wir in was günstige Tokens an deiner KI-Architektur ändern.

Wie hörst du auf, für Tokens zu zahlen, die das Modell nicht braucht?

Hier wird das Problem des verschwendeten Kontexts gelöst, und hier liegen nach dem Caching die größten strukturellen Einsparungen.

• Semantisches Caching. Speichere Request-Response-Paare und gib bei einer semantisch ähnlichen Anfrage eine gecachte Antwort zurück. Bei einem Hit sparst du den Modell-Call komplett. Tools wie GPTCache und Redis-basierte Caches berichten von Kostensenkungen um rund 70 Prozent bei Workloads mit hoher Wiederholung.
• Kontext-Kompression. Agentische und Coding-Workflows senden dieselben Dateien, Logs und History bei jedem Call erneut. Eine Kompressionsschicht reduziert das auf das, was der Schritt braucht. Offene Tools in diesem Bereich, etwa lean-ctx und RTK (Rust Token Killer), sitzen zwischen Agent und Modell und kürzen Input-Tokens, bevor du dafür zahlst. Das Prinzip zählt mehr als das konkrete Tool: schicke dem Modell den kleinsten korrekten Kontext, nicht deinen ganzen Workspace.
• KV-Cache-Kompression auf Inferenz-Ebene. Wenn du self-hostest, senken KV-Cache-Eviction und Quantisierung die Speicher- und Rechenkosten langer Kontexte. Das ist ein Hebel für Self-Hosting-Teams, nicht für API-Nutzer.

In welcher Reihenfolge solltest du das machen?

Die Prioritätenliste, die wir abarbeiten, das Günstigste und Risikoärmste zuerst:

1. Prompt-Caching. Prompts stabil-Prefix-zuerst umsortieren. Kein Qualitätsrisiko, große Einsparung.
2. Async-Arbeit batchen. Alles Latenz-tolerante zum halben Preis in den Batch-Endpoint.
3. Routing mit Eskalation. Günstiger Default, confidence-gesteuerte Eskalation zur Frontier. Eskalationsrate tracken.
4. Modell richtig dimensionieren. Open-Weight- und chinesische Frontier-Modelle gegen deine Aufgabe evaluieren. Auf bewiesenem Eval wechseln, nicht auf Benchmark-Schlagzeile.
5. Kontext komprimieren. Wiederholungen semantisch cachen, Per-Call-Kontext komprimieren.
6. Self-Hosting nur bei Volumen. Den Großteil ins Haus holen, wenn Volumen oder Compliance es erzwingen, nicht vorher.
7. Eval-Harness bauen. Nichts davon ist ohne ihn sicher auszuliefern. Er sagt dir, dass ein günstigerer Pfad die Qualitätslatte gehalten hat. Siehe SDLC.

Schritte eins bis drei liefern meist den Großteil der Einsparung schon in der ersten Woche, ohne Architektur-Änderung. Schritte vier bis sechs sind, wo du sie verstärkst.