Was ist ein Query-Pricing-Rechner? Leitfaden zu LLM-API-Kosten

Ein Query-Pricing-Rechner ist ein Werkzeug, das die API-Kosten eines einzelnen Aufrufs an ein großes Sprachmodell (LLM) schätzt. Sie geben die Anzahl der Eingabe-Tokens (Prompt, Kontext und abgerufene Dokumente), die erwartete Anzahl der Ausgabe-Tokens (die Antwort des Modells) und das Zielmodell an. Der Rechner multipliziert beide mit dem veröffentlichten Preis pro Token des Anbieters und liefert Kosten pro Abfrage - plus eine Monatsprognose auf Basis Ihres erwarteten Aufrufvolumens.

Der Kerngedanke ist, KI-Kosten planbar zu machen. Ohne Rechner unterschätzt man leicht, wie schnell Token-Kosten in großem Maßstab auflaufen. Eine Abfrage für 0,012 $ wirkt vernachlässigbar - bei 10.000 Aufrufen pro Tag sind das jedoch 120 $ pro Tag oder 3.600 $ pro Monat aus einem einzigen API-Endpunkt. Query-Pricing-Rechner zeigen das vor dem Deployment, nicht danach.

Was ein Query-Pricing-Rechner anzeigt

• Kosten pro Abfrage - der exakte Betrag für einen API-Aufruf mit Ihren Token-Zahlen und Ihrem Modell.
• Tages- und Monatsprognosen - überträgt die Kosten pro Abfrage auf Ihr erwartetes Aufrufvolumen.
• Aufteilung Eingabe und Ausgabe - zeigt, welcher Anteil der Kosten aus dem Prompt und welcher aus der Antwort stammt, da Ausgabe-Tokens teurer sind.
• Modellvergleich - manche Rechner vergleichen die Kosten derselben Abfrage gleichzeitig über mehrere Modelle.

LLM-Anbieter rechnen nach Tokens ab - einer Texteinheit, die im Englischen etwa 0,75 Wörtern (oder rund 4 Zeichen) entspricht. Die Preise werden pro Million Tokens ($/M) angegeben, getrennt für Eingabe und Ausgabe. Eingabe-Tokens umfassen alles, was Sie senden: System-Prompt, Gesprächsverlauf, Nutzernachricht, abgerufene Dokumentabschnitte aus RAG-Pipelines sowie Funktions- oder Tool-Schemata. Ausgabe-Tokens sind die vom Modell generierte Antwort.

Eingabe- und Ausgabe-Tokens werden getrennt berechnet. Ausgabe-Tokens kosten 3-5× mehr als Eingabe-Tokens, weil die Textgenerierung rechenintensiver ist als die Kontextverarbeitung.

Warum Ausgabe-Tokens mehr kosten

Bei der Inferenz erfordert die Verarbeitung der Eingabe-Tokens einen einzigen Vorwärtsdurchlauf durch das Modell. Die Generierung von Ausgabe-Tokens benötigt eine autoregressive Schleife: Das Modell erzeugt jeweils ein Token, wobei jeder Schritt vom vorherigen abhängt. Dieser sequenzielle Prozess ist pro Token deutlich GPU-intensiver, weshalb Anbieter einen deutlichen Aufschlag auf die Ausgabe erheben. Bei GPT-4o-Preisen kosten Eingabe-Tokens 2,50 $/M und Ausgabe-Tokens 10,00 $/M - ein Faktor 4. Das hat eine direkte praktische Folge: Wortreiche, lange Antworten kosten überproportional mehr als knappe.

Wie Token-Zahlen echten Prompt-Längen entsprechen

• Kurzer Prompt + kurze Antwort (z. B. „Diesen Text klassifizieren"): insgesamt ~50-200 Tokens.
• Systemnachricht + Nutzeranfrage mit Kontext: ~500-2.000 Eingabe-Tokens, 100-500 Ausgabe-Tokens.
• RAG-Abfrage mit Dokumentabschnitten: ~2.000-8.000 Eingabe-Tokens, 300-1.000 Ausgabe-Tokens.
• Agentischer Workflow mit Tool-Ergebnissen und Verlauf: ~8.000-32.000 Eingabe-Tokens pro Aufruf.
• Lange Textgenerierung (Artikel, Code): ~1.000-4.000 Eingabe-Tokens, 1.000-4.000 Ausgabe-Tokens.

Eine genaue Kostenschätzung pro Abfrage erfordert drei Zahlen: die durchschnittliche Eingabe-Token-Zahl pro Aufruf, die durchschnittliche Ausgabe-Token-Zahl pro Aufruf und Ihr tägliches Aufrufvolumen. Die ersten beiden lassen sich am besten empirisch mit dem Token-Zähler des Anbieters oder dem Feld `usage` in den API-Antworten messen - nicht über Wortzahlen schätzen.

Schritt 1 - Tatsächliche Token-Nutzung in der Entwicklung messen

Jede LLM-API-Antwort enthält ein `usage`-Objekt mit `prompt_tokens`, `completion_tokens` und `total_tokens`. Protokollieren Sie diese Werte während der Entwicklung über eine repräsentative Stichprobe von 50-100 echten Abfragen. Berechnen Sie Mittelwert und 95. Perzentil für Ein- und Ausgabe. Für die Kostenplanung nutzen Sie das 95. Perzentil der Eingabe und den Mittelwert der Ausgabe - so berücksichtigen Sie große Kontext-Ausreißer, ohne den typischen Aufruf zu überschätzen.

Schritt 2 - Monatsvolumen schätzen

Für Produktionsanwendungen gilt: täglich aktive Nutzer × durchschnittliche Abfragen pro Sitzung × API-Aufrufe pro Abfrage. Ein Chatbot mit 1.000 täglichen Nutzern, 5 Nachrichten pro Sitzung und 1 API-Aufruf pro Nachricht erzeugt 5.000 Aufrufe pro Tag. Multiplizieren Sie die Kosten pro Aufruf mit dem Tagesvolumen und dann mit 30 für die Monatsprojektion. Planen Sie 30-50 % Puffer für Verkehrsspitzen und Iterationen im Prompt-Engineering ein.

Schritt 3 - Modellstufen vergleichen

Lassen Sie dieselben Token-Zahlen durch mehrere Modellstufen laufen, um zu sehen, wo die Qualitätsanforderungen ein günstigeres Modell zulassen. Viele Aufgaben - Klassifikation, Entitätsextraktion, einfache Zusammenfassung, FAQ-Antworten - erreichen mit einem kleineren, günstigeren Modell akzeptable Qualität. Frontier-Modelle (GPT-4-Klasse, Claude-3.5-Sonnet-Klasse) für die Teilmenge der Aufgaben zu reservieren, die sie wirklich benötigen, und einfachere Aufgaben an günstigere Modelle zu routen, ist meist die wirksamste Kostensenkung.

Modellpreise ändern sich häufig - Anbieter haben sie angesichts des wachsenden Wettbewerbs deutlich gesenkt. Die folgende Tabelle zeigt repräsentative Preisstufen Mitte 2026, um die Kostenstruktur zu veranschaulichen. Prüfen Sie stets die aktuellen Preise auf der offiziellen Preisseite des jeweiligen Anbieters, bevor Sie Produktions-Kostenprognosen erstellen.

Der Kostenunterschied zwischen der günstigsten und der teuersten Stufe umfasst zwei Größenordnungen. Eine Anwendung mit 10.000 Abfragen pro Tag auf einem o1-Klasse-Modell kostet etwa 60-240 $ pro Tag; dieselbe Anwendung mit GPT-4o Mini kostet 1,50-20 $ pro Tag. Routing-Entscheidungen nach Aufgabenkomplexität - ein Query-Klassifikator, der jeden Aufruf zur passenden Modellstufe leitet - können die gesamten API-Ausgaben in Pipelines mit gemischter Komplexität um 60-80 % senken.

Kontextfenster-Größe und Kostenabwägung

Größere Kontextfenster erlauben mehr Informationen pro Abfrage - aber mehr Tokens im Prompt bedeutet höhere Eingabekosten. Ein Kontextfenster mit 100.000 Tokens lohnt sich nur, wenn der zusätzliche Kontext die Antwortqualität für diese Aufgabe wirklich verbessert. Bei den meisten RAG-Anwendungen (Retrieval-Augmented Generation) liefern 2.000-4.000 Tokens abgerufener Kontext nahezu so gute Ergebnisse wie 20.000 Tokens bei 5- bis 10-fachen Eingabekosten. Vergleichen Sie immer Qualität und Kontextlänge, bevor Sie große Prompts in der Produktion festlegen.

Die Optimierung der Abfragekosten hat zwei Hebel: weniger Tokens pro Abfrage und ein niedrigerer Preis pro Token. Die folgenden Strategien adressieren beide und sind ungefähr nach Umsetzungsaufwand von gering bis hoch geordnet.

• Eingabedaten vor der Injektion komprimieren - wandeln Sie JSON-, CSV- oder YAML-Payloads vor dem Einfügen in Prompts in das TOON-Format um. Der JSON-zu-TOON-Konverter senkt die Token-Zahl um 30-60 % ohne Informationsverlust.
• Das günstigste Modell nutzen, das die Anforderungen erfüllt - testen Sie jeden Aufgabentyp auf kleineren Modellstufen, bevor Sie ein Frontier-Modell annehmen. Viele Extraktions-, Klassifikations- und Zusammenfassungsaufgaben laufen gut mit GPT-4o Mini oder Gemini Flash.
• System-Prompts kürzen und straffen - prüfen Sie Ihren System-Prompt auf redundante Anweisungen, lange Formatierungsbeispiele und wiederholte Hinweise. Jedes eingesparte Token spart Geld bei jedem einzelnen API-Aufruf.
• Ausgabelänge mit max_tokens begrenzen - fordern Sie knappe Antworten und setzen Sie ein hartes max_tokens-Limit. Ausgabe-Tokens kosten 3-5× so viel wie Eingabe-Tokens, weshalb kürzere Antworten direkt den teuersten Posten senken.
• Prompt-Caching aktivieren - nutzen Sie das anbietereigene Caching für statische System-Prompts und Few-Shot-Beispiele. Gecachte Tokens kosten bei OpenAI und Anthropic 50-90 % weniger als ungecachte.
• Häufige Abfragen zwischenspeichern - bei deterministischen oder nahezu deterministischen Abfragen speichern Sie die LLM-Antwort und liefern sie für wiederholte identische Eingaben ohne API-Aufruf aus.

Token-Kompression: der schnellste Weg zur Ersparnis

Für Anwendungen, die strukturierte Daten an LLMs übergeben - Produktkataloge, Nutzerdatensätze, Analyse-Exporte, API-Antworten -, bietet die Kompression der Eingabe-Tokens die schnellste und verlässlichste Kostensenkung. Ein JSON-Payload mit 2.000 Tokens schrumpft im TOON-Format auf etwa 800-1.400 Tokens. Bei 3,00 $/M Eingabe-Tokens und 50.000 täglichen Abfragen spart diese einzige Änderung 0,09-0,18 $ pro Tag - rund 33-66 $ pro Monat ohne Qualitätseinbußen. Für CSV-Daten erzielt der CSV-zu-TOON-Konverter 40-60 % Token-Einsparung bei tabellarischen Datensätzen, und der YAML-zu-TOON-Konverter übernimmt Konfiguration und strukturierte Daten im YAML-Format.

Für einzelne Entwickler und kleine Projekte sind Token-Kosten selten relevant - 5-20 $ pro Monat für Experimente und Entwicklung. Zum Problem werden sie, wenn ein Feature auf Produktionsvolumen skaliert, wenn Prompt-Designs große Kontext-Payloads enthalten oder wenn eine Pipeline mehrere API-Aufrufe pro Nutzerinteraktion verkettet. In genau diesen Szenarien werden Query-Pricing-Berechnungen kritisch.

Agentische und mehrstufige Pipelines

Agentische Workflows, die mehrere LLM-Aufrufe verketten - Planung, Tool-Nutzung, Reflexion, Zusammenfassung -, können über eine einzige Nutzeranfrage hinweg 10.000-100.000 Tokens ansammeln, obwohl sie wie eine Interaktion wirkt. Jedes Tool-Ergebnis und jeder Gesprächsschritt wird als Kontext für den nächsten Aufruf erneut injiziert, wodurch die Token-Zahl quadratisch mit der Zahl der Schritte wächst. Für solche Pipelines erfordert die Kostenschätzung pro Anfrage, die Kosten pro Abfrage mit der durchschnittlichen Zahl der LLM-Aufrufe pro Ausführung zu multiplizieren.

RAG-Anwendungen mit großen Dokumentabschnitten

RAG-Pipelines injizieren abgerufene Dokumentabschnitte in jeden Prompt. Wenn die Chunking-Strategie große Abschnitte erzeugt (1.000-4.000 Tokens je Abschnitt) und drei bis fünf Abschnitte pro Abfrage abruft, können die Eingabe-Tokens 5.000-20.000 pro Aufruf erreichen, noch bevor die Frage der Nutzerin oder des Nutzers enthalten ist. Abgerufene Abschnitte in einem Format wie TOON zu komprimieren - oder ihre Größe in der Embedding-Pipeline zu verringern - senkt die Kosten pro Abfrage direkt, ohne die Retrieval-Qualität zu verändern. Wie die Validierung strukturierter Ausgaben in eine solche Pipeline passt, beschreibt der Guardrails-AI-Leitfaden mit der Validierungsschicht nach dem Retrieval.