LLM-Kostenrechner 2026: Rechne pro Aufgabe, nicht pro Token

Die nützliche Einheit für eine LLM-Rechnung ist nicht eine Million Tokens. Gemeint ist eine erledigte Aufgabe: ein beantwortetes Support-Ticket, eine extrahierte Rechnung, ein geprüfter Pull Request, eine gelöste interne Frage. Der Preis pro Token ist nur die Preisliste. Cost per Task ist die Rechnung nach Retries, Tool-Calls, Kontext, Cache-Hits, Routing, Batch-Rabatten und schlechten Outputs. Das ist der Rechner, den wir vor jeder Kostenoptimierung nutzen.

Engineering-Perspektive, keine Preisberatung. Vollständig geprüft am 2. September 2026; Providerpreise und Modelleignung können sich ändern. OpenAI nennt für Batch 50% niedrigere Kosten und Abschluss binnen 24 Stunden. Beim Prompt Caching gelten 1.024 sichtbare Input-Tokens Mindestlänge für GPT-5.6 und neuer, 2.048 für ältere Modelle; ab GPT-5.6 kosten Writes 1,25x und Reads 0,1x. Anthropic bepreist 5-Minuten-Writes mit 1,25x, 1-Stunden-Writes mit 2x, Reads mit 0,1x und Batch mit 50% der Standardpreise. Gemini aktiviert implizites Caching für 2.5 und neuere Modelle mit modellspezifischen Mindestlängen. Prüfe Primärquellen und Rechnung vor dem Budget.

Der Rechner in einer Formel

Starte mit einer Aufgabe, nicht mit einem API-Call. Eine Aufgabe kann mehrere Modellaufrufe, Retrieval, Tools, einen Verifier und manchmal einen Retry enthalten. Die Gesamtkosten sind:

Kosten pro erfolgreiche Aufgabe = (initiale Modell-Calls + Retries und Fallbacks + Retrieval und Infrastruktur + menschliche Nacharbeit) / erfolgreiche Aufgaben.

Genau deshalb haben wir über Cost per Token vs Cost per Task geschrieben. Ein günstigeres Modell, das mehr Schleifen braucht, längere Outputs erzeugt oder häufiger scheitert, kann teurer sein als das Modell mit der schmerzhaften Preisliste.

Welche Eingaben gehören in den Rechner?

Wenn dein Sheet nur Input-Tokens, Output-Tokens und Modellpreis enthält, zählt es zu wenig. Nimm diese Felder auf:

• Aufgabenvolumen. Zähle echte Geschäftseinheiten: Tickets, Dokumente, Angebote, Pull Requests, Checks, Research-Briefings.
• Calls pro Aufgabe. Agentische Workflows verbrennen die Rechnung oft in Schleifen: Klassifikation, Retrieval, Entwurf, Tool-Call, Verifier, Rewrite, Audit-Log.
• Input pro Call. Trenne stabilen Prefix, Retrieval-Kontext, Verlauf, Tool-Schemas und volatile Nutzerdaten. Hier zeigen sich Caching und Kontext-Kompression.
• Output pro Call. Reasoning- und Coding-Agenten sind oft outputlastig. Billiger Input hilft wenig, wenn das Modell tausende Output-Tokens schreibt.
• Cache-Hit-Rate. Messe gecachte Tokens, nicht nur gecachte Requests. OpenAI liefert `cached_tokens`, Gemini cached Token Counts, Anthropic trennt Cache Write und Cache Read.
• Batchbarer Anteil. Alles, was warten kann, gehört zuerst in Batch: Evals, Offline-Extraktion, Enrichment, Klassifikation, Zusammenfassungen.
• Eskalationsrate. Wenn ein günstiges Modell den ersten Pass macht und ein starkes Modell die schweren Fälle übernimmt, ist die Eskalationsrate ein Produkt-KPI.
• Qualitätsgrenze. Stelle die Pass-Rate deines Eval-Harness neben die Kosten. Sonst vergleichst du Rechnungen und ignorierst, ob die Arbeit noch funktioniert.

"Wenn dein Rechner nicht zeigt, was eine erfolgreiche Aufgabe kostet, ist er kein KI-Kostenrechner. Er ist ein Token-Beleg."

Beispiel: Support-Triage

Ein Support-Workflow liest ein Ticket, holt Policy-Auszüge, schreibt eine Antwort und lässt prüfen, ob die Antwort belegt ist. Das naive Sheet sagt: ein Answer-Call, vielleicht 4.000 Input-Tokens und 600 Output-Tokens. Der Production Trace sagt etwas anderes:

Die Modellkosten sind nicht der Answer-Call. Im Schnitt sind es 3,18 Calls plus Retrieval plus Retry-Tail. Wenn 60% des Draft-Inputs stabiler System-Prompt, Policy-Rahmen und Tool-Schema sind, zählt Prompt Caching mehr als ein Modellwechsel. Wenn nur 20% der Tickets das starke Modell brauchen, zählt Routing mehr als ein paar Cent beim Default-Modell. Das ist unser LLM-Kosten-Playbook als Rechner.

Wo Prompt Caching in die Rechnung kommt

Prompt Caching ist der erste Hebel, weil es wiederholten Input günstiger macht, ohne Modell oder Antwort zu ändern:

Input-Kosten = (uncached_input_tokens / 1M × normal_input_price) + (cache_read_tokens / 1M × cache_read_price) + (cache_write_tokens / 1M × cache_write_price).

Stabiler Inhalt gehört vor volatile Daten. OpenAI dokumentiert modellspezifische Mindestlängen: 1.024 sichtbare Input-Tokens für GPT-5.6 und neuer, 2.048 für ältere Modelle. Ab GPT-5.6 kosten Writes 1,25x und Reads 0,1x; ältere Modelle haben andere Regeln. Anthropic berechnet 1,25x für 5-Minuten-Writes, 2x für 1-Stunden-Writes und 0,1x für Reads. Gemini aktiviert implizites Caching für 2.5 und neuer; gelistete Mindestlängen reichen derzeit von 2.048 bis 4.096 Tokens. Berechne immer mit den gemeldeten Usage-Kategorien.

• Guter Cache-Prefix: System-Instruktion, Tool-Definitionen, Output-Schema, Produktpolicy, stabiler Retrieval-Kontext.
• Schlechter Cache-Prefix: Timestamp, User-ID, zufällige Trace-ID, aktuelles Dokument, Ticket-Body.
• Metrik: gecachte Input-Tokens geteilt durch gesamte Input-Tokens, je Feature und Modell.

Primärquellen: OpenAI Prompt Caching, Anthropic Prompt Caching und Gemini Context Caching.

Wo Batch APIs in die Rechnung kommen

Batching ist kein Latenztrick. Es ist ein Preis- und Durchsatzhebel für Arbeit, die warten kann:

Gesamte Modellkosten = synchrone Modellkosten + Σ tatsächliche Batch-Kosten nach Input-, Cache-Write-, Cache-Read- und Output-Kategorie.

OpenAI dokumentiert 50% niedrigere Batch-Kosten und Abschluss binnen 24 Stunden. Anthropic berechnet 50% der Standardpreise; die meisten Batches enden binnen einer Stunde, unvollständige laufen nach 24 Stunden ab. Batch ist für wartbare Evals, Enrichment und Offline-Jobs geeignet. Verwende tatsächliche Batch-Input-, Output- und Cachepreise je Kategorie statt einen bereits rabattierten Gesamtwert blind zu multiplizieren.

Batch keine Live-UX, wenn Nutzer warten. Batch dein Eval-Harness. Viele Teams zahlen laufend für Prompt- und Modelltests und vergessen, dass diese Tests keine Live-Latenz brauchen. Warum sich das rechnet, steht in wann sich ein LLM-Eval bezahlt macht.

Primärquellen: OpenAI Batch API und Anthropic Batch Processing.

Routing: der Hebel mit Qualitätsfalle

Routing verändert den Modellmix pro Aufgabe. Der Rechner braucht daher einen Anteil fürs starke Modell:

Routing-Kosten = cheap_path_cost * (1 - escalation_rate) + strong_path_cost * escalation_rate + verifier_cost.

Das RouteLLM-Projekt beschreibt das Prinzip gut: einfache Queries gehen an günstigere Modelle, stärkere Modelle übernehmen die schwierigen Fälle, und der Threshold wird auf echtem Traffic kalibriert. Die README berichtet bis zu 85% Kostenreduktion bei 95% GPT-4-Performance auf Benchmarks. Behandle das als Forschungsreferenz, nicht als deine Produktionszahl. Dein Traffic kann anders routen, besonders bei domänenspezifischen Edge Cases.

1. Günstiger Default. Starte mit dem billigsten Modell, das die einfache Mehrheit besteht.
2. Verifier. Prüfe Schema, Grounding, Policy und Confidence.
3. Eskalation. Unsichere, teure oder fehlgeschlagene Fälle gehen an ein stärkeres Modell.
4. Eval-Gate. Vergleiche günstigen Pfad, starken Pfad und Routing auf echten Beispielen.
5. Monitoring. Steigt die Eskalationsrate, hat sich Traffic verändert oder das billige Modell ist überfordert.

Hier helfen LLM-Gateways und Router. LiteLLM, Portkey, OpenRouter oder eine eigene RouteLLM-Schicht bündeln Logs, Modellmix, Fallback, Budgets und Routing. Der Rechner ist der Grund für diese Schicht; das Gateway ist, wie du sie misst.

Forschung und Tools: RouteLLM, RouteLLM Paper, Batch-Level Query Routing und Routing mit Batch Prompting.

Lokale Modelle und Self-Hosting

Self-Hosting macht Inference nicht kostenlos. Es tauscht variable Tokenkosten gegen GPU-Kosten, Auslastungsrisiko, Ops, Redundanz und Eval-Pflege:

Self-Host-Kosten pro erfolgreiche Aufgabe = (amortized_compute_per_hour + ops_per_hour + redundancy_per_hour + monitoring_per_hour + eval_upkeep_per_hour) / successful_tasks_per_hour.

Der Nenner entscheidet. Eine GPU mit 80% Auslastung kann lokale Inference rational machen. Eine GPU mit 12% Auslastung, weil dein Traffic spiky ist, wird zum teuren Souveränitäts-Symbol. Deshalb beginnt unser EU-Self-Hosting-Kosten-Guide mit Volumen und Datenresidenz, nicht mit GPU-Specs.

• Datenresidenz oder Governance zwingt dich. Dann ist Kostenoptimierung die zweite Frage.
• Hohes, stabiles Volumen füllt die Hardware. Gegen günstige Hosted Open-Weight-APIs brauchst du anhaltende Last, nicht gelegentliche Peaks.

Die Modellwahl kommt danach. Unser Open-Weight-LLM-Vergleich behandelt DeepSeek, Qwen, Kimi, GLM und Llama aus europäischer Deployment-Sicht. Dein Rechner muss die Pass-Rate auf deinem Eval enthalten, nicht nur Tokens pro Sekunde.

Kontext-Kompression und Semantic Caching

Nach Prompt Cache, Batch und Routing kommt die Frage, ob das Modell den Kontext überhaupt brauchte:

• Semantic Caching. Ist eine neue Anfrage nah genug an einer früheren, gibst du die alte Antwort oder eine leicht angepasste Antwort zurück. Das spart stark bei repetitivem Support und internen Assistenten, kann aber stale oder unberechtigte Antworten leaken, wenn Permissions und Invalidation schwach sind.
• Kontext-Kompression. Schicke den kleinsten korrekten Kontext: Zusammenfassungen, File Maps, relevante Snippets und bereinigte Tool-Ausgaben statt den ganzen Workspace in jedem Turn.

Das hängt direkt mit warum Coding-Agenten an Kontext scheitern und unserem Text über Text-as-Image Token Savings zusammen. Kompression ist stark, aber exakte Werte, IDs, Beträge, Hashes, Vertragsklauseln und Permissions müssen exakt bleiben. Ist die Optimierung verlustbehaftet, braucht der Rechner eine Fehlerkosten-Zeile.

Ein Sheet-Layout zum Kopieren

Lege eine Zeile pro Aufgabentyp an, nicht pro Modell:

In welcher Reihenfolge optimierst du?

1. Cost per Task instrumentieren. Logge Task-ID, Modell, Tokens, Cache-Hits, Retries, Latenz, Status und Eval-Urteil.
2. Caching ernst nehmen. Stabiler Prefix zuerst, volatile Daten zuletzt, gecachte Tokens je Feature messen.
3. Offline-Arbeit batchen. Evals und Enrichment sollten keine Live-Preise zahlen.
4. Mit Verifier routen. Günstiger Default, starker Fallback, überwachte Eskalationsrate.
5. Modell richtig dimensionieren. Teste Open Weights und kleinere Modelle auf deinem Eval-Set.
6. Kontext komprimieren. Entferne irrelevante History und wiederholten Workspace-Kontext.
7. Self-host nur bei Volumen oder Governance. Bepreise Auslastung und Engineers, nicht nur GPU-Stunden.

Wenn genau diese Zahl der Grund ist, warum ein Projekt steht, liegt die Lösung meist in der Architektur und nicht in der Rechnung. Die Kosten zu instrumentieren und dann Routing, Caching und Retrieval so lange umzubauen, bis sich die Kosten pro erledigter Aufgabe bewegen, macht unser KI Setup Service. Hyperstate AI ist ein veröffentlichter Fall, in dem das Aufteilen eines GPU-lastigen Monolithen Latenz und Kosten gesenkt hat, und unser Guide zur Technologieauswahl behandelt die Entscheidung, bevor die Rechnung existiert.