Was KI wirklich kostet (über Anbieter hinweg)
„Wie viel kostet KI?" hat keine einzelne Antwort — es hängt davon ab, welchen Preis-Archetyp du kaufst und wie viel du ihn tatsächlich nutzt. Die Dollarbeträge ändern sich alle paar Monate; die Struktur der Kosten bewegt sich kaum. Diese Seite vermittelt die dauerhafte Form: die drei Arten, wie KI bepreist wird, wie man eine Arbeitslast schätzt, bevor man sie baut, die Hebel, die die Rechnung senken, und die echte Weggabelung zwischen dem Mieten einer API und Self-Hosting.
- Die drei Kosten-Archetypen auseinanderhalten: Per-Token-API, Pauschal-Abonnement und offen/selbst gehostet
- Die Kosten jeder Arbeitslast aus Tokens × Rate × Volumen schätzen — bevor du sie ausrollst
- Die großen Hebel ziehen, die Ausgaben senken, ohne die Qualität zu beeinträchtigen
- Wissen, wann offen/selbst gehostet die API bei den Kosten schlägt, und wann die API gewinnt
- Wissen, welche Zahlen schnell veralten — und wo man die heutige Wahrheit prüft
Die drei Kosten-Archetypen
Fast jede Art, wie du für KI bezahlen kannst, lässt sich auf eine von drei Formen reduzieren. Lerne die Formen, nicht die Preise.
- Per-Token-API (nutzungsbasiert). Du rufst ein gehostetes Modell über eine API auf und zahlst pro Token — und Eingabe und Ausgabe werden getrennt bepreist, wobei die Ausgabe fast immer die teurere von beiden ist. Größere/intelligentere Modelle kosten mehr pro Token; kleinere Modelle kosten weit weniger. Die meisten Anbieter bieten außerdem Rabatte: eine reduzierte Rate für zwischengespeicherte Eingabe, die du erneut sendest, und einen pauschalen Batch-Rabatt für nicht dringende asynchrone Jobs. So bezahlst du, wenn du ein Produkt auf Claude, GPT oder Gemini aufbaust. Die Kosten skalieren direkt mit der Nutzung — Pfennige im kleinen Maßstab, der dominierende Posten im großen Maßstab.
- Pauschales Verbraucher-/Platz-Abonnement. Eine feste monatliche Gebühr für eine Chat-App oder einen IDE-Assistenten (die Verbraucher-Pläne von Claude / ChatGPT / Gemini, Copilot-artige Plätze). Du siehst keine Tokens; du bekommst ein Nutzungskontingent und Rate-Limits. Vorhersehbar und günstig für einen Menschen an einer Tastatur — aber es skaliert nicht für programmatische/hochvolumige Arbeit, und die Kosten pro Platz summieren sich über ein Team hinweg.
- Offen / lokal (selbst gehostet). Du betreibst ein Open-Weight-Modell (Llama, Mistral, Qwen, DeepSeek) auf eigener Hardware oder einer gemieteten GPU. Es gibt keinen Preis pro Aufruf — du zahlst für die Hardware (oder stündliche GPU-Miete) + Strom + Betrieb, egal ob das Modell ausgelastet oder im Leerlauf ist. Die Grenzkosten eines weiteren Aufrufs sind im großen Maßstab praktisch nahe null, aber du trägst Fixkosten und operative Last. Siehe Modelle lokal mit Ollama betreiben.
- Die zentrale Trennung: API und Abonnements sind GRENZKOSTEN (du zahlst pro Nutzung); Self-Hosting ist überwiegend FIXKOSTEN (du zahlst, um die Kapazität bereitzuhalten, ob genutzt oder nicht).
- Bei der API ist die größte Überraschung, dass AUSGABE-Tokens meist mehrere Male so viel kosten wie Eingabe — wortreiche Antworten kosten echtes Geld.
- Ein Pauschal-Abonnement ist das richtige Werkzeug für einen chattenden Menschen; die Per-Token-API ist das richtige Werkzeug für eine App, die das Modell in einer Schleife aufruft.
Wie man die Kosten einer Arbeitslast schätzt
Du kannst eine API-Rechnung dimensionieren, bevor du eine Zeile Produktionscode schreibst. Das gesamte Modell ist eine Formel:
Kosten ≈ (Eingabe-Tokens × Eingaberate) + (Ausgabe-Tokens × Ausgaberate), pro Aufruf × Anzahl der Aufrufe
Raten werden pro Million Tokens angegeben, und Eingabe und Ausgabe haben unterschiedliche Raten — schätze also die beiden Hälften getrennt und addiere sie. Eine grobe Token-Faustregel: ~1 Token ≈ 4 Zeichen Englisch oder ~0,75 Wörter. Für genaue Zählungen nutze den Bereich Token-Schätzer und lies Tokens & Preisgestaltung. Die vollständige Mechanik, wo Tokens sich verstecken, findest du in Die Token-Ökonomie.
- Addiere die Eingabe: System-Prompt + Tools + abgerufener Kontext + Verlauf + die Nutzereingabe. Schätze dann die Ausgabe, die du anforderst. Zähle Eingabe und Ausgabe getrennt — sie werden unterschiedlich bepreist.
- Eingabe-Tokens × Eingaberate, plus Ausgabe-Tokens × Ausgaberate. Verwende die heutigen Pro-Million-Zahlen von der Preisseite des Anbieters (vertraue keiner Zahl, die du dir gemerkt hast — siehe VerifyNote).
- Multipliziere die Kosten pro Aufruf mit Aufrufen pro Tag × Tagen. Kosten, die pro Aufruf trivial sind (Bruchteile eines Cents), werden bei Millionen von Aufrufen zu deinem Hauptposten — modelliere deinen TATSÄCHLICHEN Traffic, nicht eine einzelne Anfrage.
- Wenn sich ein großer Teil der Eingabe bei jedem Aufruf wiederholt, bepreise ihn mit der ZWISCHENGESPEICHERTEN Rate, nicht der vollen Eingabe. Wenn der Job offline ist, wende den BATCH-Rabatt an. Diese verändern das Ergebnis im großen Maßstab dramatisch.
- Vergleiche deine Per-Token-Annahmen mit einem unabhängigen Tracker und unserem Kostenrechner, dann gehe die Rechnung mit den Hebeln unten an.
Überschlagsrechnung (heutige Raten einsetzen)
Per call:
input_tokens = system + tools + context + history + user_turn
output_tokens = the answer you ask for
call_cost = (input_tokens * input_rate_per_million / 1e6)
+ (output_tokens * output_rate_per_million / 1e6)
Per month:
monthly_cost = call_cost * calls_per_day * 30
Then adjust:
- cached repeated input -> use the (lower) cache-read rate for that slice
- offline / non-urgent -> apply the batch discount to the whole job
Rates change monthly — pull today's numbers from the provider's pricing page.Die großen Hebel zur Kostensenkung
Die meisten realen Arbeitslasten tragen totes Gewicht mit sich. Diese Hebel, grob nach Wirkung geordnet, senken die Ausgaben, ohne die Qualität anzutasten — ziehe die günstigen strukturellen zuerst.
- Das Modell richtig dimensionieren. Zahle keine Flaggschiff-Rate für einen Job, den ein kleines/günstiges Modell problemlos erledigt. Klassifizierung, Extraktion, Routing und einfache Formatierung laufen meist hervorragend auf der kleinsten Stufe zu einem Bruchteil des Per-Token-Preises. Reserviere das große Modell für wirklich schwieriges Reasoning und erwäge Routing: das günstige Modell erledigt die einfache Mehrheit, eskaliere nur die schwierigen Fälle. Siehe Ein Modell wählen.
- Den gesendeten Kontext kürzen. Das günstigste Token ist das, das du nie sendest. Beschneide aufgeblähte System-Prompts, verdichte lange Verläufe zu einer laufenden Zusammenfassung und stelle nur die Tools bereit, die die Aufgabe braucht — jedes ist Eingabe, die du bei jedem Aufruf erneut bezahlst.
- RAG statt riesigen Kontext vollzustopfen. Ein 50-seitiges Dokument einzufügen, um eine Frage zu beantworten, bezahlt 50 Seiten bei jedem Aufruf. Retrieval holt nur die wenigen relevanten Passagen — weit weniger Eingabe-Tokens für dieselbe (oft bessere) Antwort. Greife nur dann zu einem riesigen Kontextfenster, wenn du wirklich den gesamten Korpus auf einmal im Blick brauchst.
- Prompt-Caching. Wenn viele Aufrufe ein großes unveränderliches Präfix teilen (System-Prompt, Tool-Katalog, Referenzdokument), verarbeitet Caching es einmal und liefert es bei jedem späteren Aufruf zu einem steilen Rabatt erneut aus. Die strukturelle Änderung mit der höchsten Hebelwirkung für Chat- und Agenten-Arbeitslasten, weil sie sich bei jeder Runde auszahlt.
- Das Nicht-Dringende batchen. Evals, Massen-Labeling, das Zusammenfassen eines Archivs — alles, wo du die Antwort nicht in Sekunden brauchst — läuft bei den meisten Anbietern über einen asynchronen Batch-Pfad zu einem pauschalen Rabatt. Tausche Unmittelbarkeit gegen eine deutlich niedrigere Rechnung.
- Die Ausgabe kürzen. Die Ausgabe ist die teurere Seite. Fordere JSON oder ein straffes Schema an statt eines geschwätzigen Absatzes: weniger Ausgabe-Tokens und kein nachgelagertes Parsing-Rätselraten.
- Kleinere / offene Modelle für die einfache Scheibe. Für die hochvolumige Mehrheit der Aufrufe mit geringer Schwierigkeit kann ein offenes oder kleines Modell pro Aufruf dramatisch günstiger sein — manchmal nahezu kostenlos, wenn du ohnehin selbst hostest. Behalte das Frontier-Modell für die Fälle, die es wirklich brauchen.
- Diese stapeln sich multiplikativ: zwischengespeicherte Eingabe × richtig dimensioniertes Modell × knappere Ausgabe × Batch-Rabatt summieren sich bei einer einfachen Aufgabe zu einer großen Gesamtkürzung — bei unveränderter Qualität.
- Ziehe die strukturellen Hebel (richtig dimensionieren, cachen, RAG, batchen), bevor du an der Formulierung mikro-optimierst — sie bewegen die Rechnung weit mehr.
- MISS die Veränderung immer an der echten Rechnung, nicht an einer Vermutung. Das tiefe Playbook ist Die Token-Ökonomie.
Wann offen/selbst gehostet die API schlägt — und wann die API gewinnt
Das ist die Entscheidung, die dein KI-Budget tatsächlich bewegt. Es ist ein Übergang zwischen Fix- und Grenzkosten, und das Volumen ist die Variable, die ihn entscheidet.
- Offen / selbst gehostet gewinnt bei HOHEM, gleichmäßigem Volumen. Sobald du genug Aufrufe ausführst, um eine GPU die meiste Zeit auszulasten, schlagen die nahezu null Grenzkosten pro Aufruf das ewige Bezahlen pro Token. Du amortisierst die fixen Hardware-/Mietkosten über eine riesige Anzahl von Aufrufen, gewinnst Datenschutz und volle Anpassbarkeit — und akzeptierst die operative Last (Bereitstellung, Skalierung, Verfügbarkeit, MLOps) als Eintrittspreis.
- Die API gewinnt bei NIEDRIGEM oder SPRUNGHAFTEM Volumen oder ohne Infrastruktur. Wenn der Traffic klein, stoßweise oder unvorhersehbar ist, bedeutet das Bezahlen pro Token, dass du nur für das zahlst, was du nutzt und nichts im Leerlauf — keine GPU, die um 3 Uhr morgens warm dasteht. Du sparst dir außerdem den gesamten Betrieb. Für die meisten Teams, die ein Produkt ausliefern, prototypisieren oder deren Traffic in Spitzen kommt, ist die API sowohl günstiger als auch weit weniger Arbeit.
- Self-Hosting ist selten ‚kostenlos'. Die Modellgewichte mögen kostenlos sein, aber GPUs, Strom und die Ingenieursstunden, um es am Laufen zu halten, sind es nicht — zähle sie ehrlich, bevor du eine Ersparnis behauptest.
- GPUs im Leerlauf sind reiner Verlust: Fixkosten-Infrastruktur schlägt Per-Token-Preise nur, wenn die Auslastung HOCH ist. Niedriger oder sprunghafter Traffic begünstigt jedes Mal die API.
- Der Übergangspunkt verschiebt sich, sobald API-Preise fallen oder Hardware günstiger wird — rechne die Mathematik periodisch neu, entscheide nicht einmal und vergiss es.
Überprüfe dich selbst
0/3- Drei Archetypen: Per-Token-API (nutzungsbasiert, Eingabe vs. Ausgabe getrennt bepreist), Pauschal-Abonnement (vorhersehbar, skaliert nicht für hohes Volumen) und offen/selbst gehostet (Fixkosten, nahe null pro Aufruf).
- Schätze, bevor du baust: (Eingabe × Eingaberate) + (Ausgabe × Ausgaberate), pro Aufruf × Volumen — dann wende Cache- und Batch-Rabatte an.
- Größte Hebel: das Modell richtig dimensionieren, Kontext kürzen, RAG statt riesigem Kontext, Prompt-Caching, das Nicht-Dringende batchen, die Ausgabe kürzen.
- Self-Hosting gewinnt bei HOHEM gleichmäßigem Volumen (Fixkosten amortisieren); die API gewinnt bei NIEDRIGEM/sprunghaftem Volumen oder ohne Infrastruktur (nur für Nutzung zahlen).
- Jeder Dollarbetrag veraltet schnell — verifiziere auf der Preisseite des Anbieters und einem Tracker und rechne deine eigenen Zahlen im Kostenrechner durch.
Quellen & weiterführende Literatur
- Anthropic — Pricing — aktuelle Per-Token-Raten von Claude, Cache- und Batch-Rabatte.
- OpenAI — API Pricing · OpenAI — Pricing overview — aktuelle Per-Token-Raten und Stufen von GPT.
- Google — Gemini API Pricing — aktuelle Gemini-Raten, kostenlose Stufe und kostenpflichtige Stufen.
- Mistral — Pricing — Open-Weight- + API-Preise, ein effizienzorientierter Referenzpunkt.
- Artificial Analysis — unabhängige, häufig aktualisierte Preis-/Geschwindigkeits-/Qualitätsvergleiche über Anbieter hinweg (der Tracker, um jede genannte Zahl zu plausibilisieren).
- Ollama — Open-Weight-Modelle lokal betreiben, um den Preis pro Aufruf im großen Maßstab gegen null zu bringen.
Weiter
- Das richtige (und richtig bepreiste) Modell wählen → Ein Modell wählen
- Finden, wo Tokens tatsächlich versickern → Die Token-Ökonomie
- Die Per-Token-Mechanik im Detail → Tokens & Preisgestaltung
- Deine eigenen Zahlen durchrechnen → Kostenrechner