LLM-Kosten optimieren: Wie du bei API-Nutzung massiv sparst

Artikel-Übersicht

Du baust etwas Cooles mit einer LLM-API, alles läuft – und dann flattert die erste Monatsabrechnung herein. Autsch. Willkommen im Club! Die gute Nachricht: Bei den meisten Projekten lassen sich die Kosten um 50 bis 90 Prozent senken, ohne dass die Qualität spürbar leidet. Man muss nur wissen, an welchen Schrauben man dreht.

In diesem Beitrag schauen wir uns zuerst an, wie sich LLM-Kosten überhaupt zusammensetzen und warum das Token-Verständnis dein wichtigster Hebel ist. Danach gehe ich mit dir acht konkrete Optimierungsstrategien durch – von Prompt-Caching über Batch-APIs und Model-Routing bis zu Monitoring und Self-Hosting. Es gibt eine aktuelle Preistabelle (Stand 2026), eine Beispielrechnung zum Mitrechnen und kleine Code-Snippets, die du direkt übernehmen kannst. Los geht's!

Einleitung: Warum LLM-Kosten so schnell explodieren

LLM-APIs fühlen sich beim Prototyping fast geschenkt an. Ein paar Cent hier, ein paar Cent da – wen juckt's? Das Problem: Die Kosten skalieren linear mit der Nutzung, und zwar gnadenlos. Was im Test 10 Cent kostet, kostet bei 100.000 Nutzern eben 10.000 Euro. Es gibt keinen Mengenrabatt, der von allein einsetzt, und kein „das wird schon wieder günstiger".

Stell dir die LLM-Nutzung wie ein Taxi mit laufendem Taxameter vor. Jedes Wort, das du hineingibst, und jedes Wort, das herauskommt, lässt den Zähler weiterticken. Wer sinnlos durch die Stadt kurvt, riesige Kontexte mitschleppt oder bei jeder Mini-Aufgabe die teuerste Limousine bestellt, zahlt drauf. Wer clever plant, kommt für einen Bruchteil ans Ziel.

Das Schöne ist: Kostenoptimierung bei LLMs ist kein dunkles Geheimwissen. Es sind eine Handvoll Techniken, die zusammengenommen einen riesigen Unterschied machen. Und die meisten davon sind in wenigen Zeilen Code umgesetzt. Fangen wir mit den Grundlagen an.

Wie sich LLM-Kosten zusammensetzen: Input- und Output-Token

Fast alle LLM-Anbieter rechnen nach Tokens ab, nicht nach Wörtern oder Zeichen. Und sie unterscheiden dabei zwei Sorten:

Input-Tokens (auch „Prompt-Tokens"): Alles, was du an das Modell schickst – System-Prompt, Gesprächsverlauf, deine eigentliche Frage, angehängte Dokumente.
Output-Tokens (auch „Completion-Tokens"): Alles, was das Modell zurückgibt.

Die Preise werden üblicherweise pro 1 Million Tokens angegeben. Und jetzt kommt der erste wichtige Punkt: Output ist fast immer deutlich teurer als Input – oft um den Faktor 4 bis 6.

Warum eigentlich? Input-Tokens kann das Modell parallel verarbeiten – es liest den gesamten Prompt in einem Rutsch („Prefill"). Output-Tokens dagegen entstehen sequenziell: Das Modell erzeugt ein Token, hängt es an, erzeugt das nächste, und so weiter. Jeder Schritt erfordert einen kompletten Durchlauf durch das neuronale Netz. Das ist rechenintensiver, langsamer und damit teurer. Merke dir: Ein gesparter Output-Token ist mehr wert als ein gesparter Input-Token.

Bei Claude Opus 4.8 zum Beispiel kostet Input 5 US-Dollar pro Million Tokens, Output aber 25 US-Dollar – ein Faktor von 5. Bei OpenAIs GPT-5.5 ist das Verhältnis mit 5 zu 30 US-Dollar sogar 6:1. Wer also seine Ausgabelänge im Griff hat, spart überproportional. Dazu später mehr.

Tokens verstehen: Der wichtigste Kostenhebel

Bevor wir an die Strategien gehen, müssen wir kurz über Tokens selbst reden – denn ein gutes Token-Gefühl ist die Basis für jede Optimierung.

Ein Token ist ungefähr ein Wortbaustein. Als grobe Faustregel gilt für englischen Text: 1 Token ≈ 4 Zeichen ≈ 0,75 Wörter. Bei deutschem Text ist es etwas ungünstiger, weil unsere langen Komposita („Donaudampfschifffahrtsgesellschaft") und Umlaute in mehr Tokens zerlegt werden. Rechne für Deutsch eher mit 1 Wort ≈ 1,3 bis 2 Tokens. Code, JSON und Sonderzeichen fressen ebenfalls überproportional viele Tokens.

Ein paar Beispiele, damit du ein Gefühl bekommst:

„Hallo, wie geht es dir?" → etwa 7 Tokens
Ein typischer Absatz (100 Wörter Deutsch) → etwa 150 bis 180 Tokens
Eine A4-Seite Fließtext → etwa 600 bis 800 Tokens
Ein 20-seitiges PDF → schnell 12.000 bis 16.000 Tokens

Wichtig: Schätze Tokens nicht mit OpenAIs tiktoken, wenn du Claude nutzt – das ist der falsche Tokenizer und liegt bei deutschem Text und Code gern um 15 bis 20 Prozent daneben. Jeder seriöse Anbieter stellt einen eigenen Token-Counter bereit. Bei Anthropic ist das der count_tokens-Endpunkt:

from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("dokument.md").read()}],
)
print(resp.input_tokens)  # exakte Token-Zahl für dieses Modell

Warum ist das so zentral? Weil jede Kostenrechnung mit der Token-Zahl beginnt. Wenn du nicht weißt, dass dein hübscher System-Prompt 2.000 Tokens lang ist und bei jeder einzelnen Anfrage mitgeschickt wird, kannst du auch nicht erkennen, wo das Geld versickert. Token-Bewusstsein ist die Brille, durch die du deine ganze Pipeline plötzlich anders siehst.

Aktuelle Preise 2026 im Überblick

Hier eine Übersicht gängiger Modelle (Stand 2026, Preise pro 1 Million Tokens in US-Dollar, Standard-Tarif). Beachte: Preise ändern sich häufig – prüfe vor Produktivnahme immer die offiziellen Preisseiten (Links unten in den Ressourcen).

Modell	Anbieter	Input ($/1M)	Output ($/1M)	Verhältnis
Claude Haiku 4.5	Anthropic	1,00	5,00	1:5
Claude Sonnet 4.6	Anthropic	3,00	15,00	1:5
Claude Opus 4.8	Anthropic	5,00	25,00	1:5
Claude Fable 5	Anthropic	10,00	50,00	1:5
GPT-5.4-nano	OpenAI	0,20	1,25	1:6
GPT-5.4	OpenAI	2,50	15,00	1:6
GPT-5.5	OpenAI	5,00	30,00	1:6
Gemini 2.5 Flash-Lite	Google	0,10	0,40	1:4
Gemini 2.5 Flash	Google	0,30	2,50	1:8
Gemini 2.5 Pro	Google	1,25	10,00	1:8

Zwei Dinge fallen sofort auf. Erstens: Der Preisunterschied zwischen dem günstigsten und dem teuersten Modell beträgt locker das 50- bis 100-Fache. Zwischen einem Gemini 2.5 Flash-Lite und einem Claude Fable 5 liegen Welten. Zweitens: Innerhalb einer Modellfamilie gibt es fast immer eine günstige, eine mittlere und eine Premium-Stufe. Genau dieses Gefälle nutzen wir später beim Model-Routing aus.

Außerdem wichtig: Modelle mit sehr großem Kontextfenster (oft 1 Million Tokens) berechnen bei manchen Anbietern oberhalb einer bestimmten Schwelle – etwa 200.000 Tokens pro Prompt – einen Long-Context-Aufschlag, manchmal das Doppelte. Riesige Kontexte sind also doppelt teuer: mehr Tokens und ein höherer Tarif pro Token.

Eine Beispielrechnung: Vom Kostenschock zur Ersparnis

Schauen wir uns an, wie sich Optimierungen konkret auswirken. Nehmen wir einen Support-Chatbot mit 1 Million Anfragen pro Monat. Jede Anfrage hat:

2.500 Input-Tokens System-Prompt (Anweisungen, Tonalität, Beispiele) – immer gleich
500 Input-Tokens für die eigentliche Nutzerfrage und etwas Kontext
400 Output-Tokens für die Antwort

Variante A – naiv, alles auf Claude Opus 4.8:

Input: 3.000 Tokens × 1 Mio. = 3 Mrd. Tokens × 5 $/Mio. = 15.000 $
Output: 400 Tokens × 1 Mio. = 400 Mio. Tokens × 25 $/Mio. = 10.000 $
Gesamt: 25.000 $ pro Monat

Aua. Jetzt optimieren wir Schritt für Schritt:

Prompt-Caching für den 2.500-Token-System-Prompt. Gecachte Input-Tokens kosten nur noch rund 10 Prozent. Statt 2.500 × 5 $/Mio. zahlen wir für den gecachten Teil nur etwa 0,5 $/Mio. Ersparnis beim Input: ~11.250 $.
Model-Routing: 80 Prozent der Fragen sind simpel und gehen an Claude Haiku 4.5 (1 $ / 5 $), nur 20 Prozent an Opus.
Output-Begrenzung von 400 auf durchschnittlich 250 Tokens durch präzisere Prompts.

Variante B – optimiert:

Input (Haiku, 80 %): gecachte 2.500 Tokens (~0,1 $/Mio.) + 500 ungecachte Tokens (1 $/Mio.) → grob 0,65 Mrd. effektive „Vollpreis"-Tokens, Kosten ~700 $
Input (Opus, 20 %): analog mit Caching → ~900 $
Output gesamt (250 Tokens, gemischt Haiku/Opus) → ~3.000 $
Gesamt: rund 4.600 $ pro Monat

Von 25.000 $ auf unter 5.000 $ – das sind über 80 Prozent Ersparnis, ohne dass die Nutzer einen Qualitätsunterschied merken. Und wir haben noch nicht mal die Batch-API oder RAG ins Spiel gebracht. Jetzt verstehst du, warum sich das Thema lohnt. Gehen wir die Strategien einzeln durch.

Strategie 1: Prompt-Caching – wiederkehrenden Kontext zwischenspeichern

Prompt-Caching ist die Strategie mit dem oft besten Aufwand-Nutzen-Verhältnis. Die Idee: Wenn du bei vielen Anfragen denselben Textanfang wiederverwendest – einen großen System-Prompt, Few-Shot-Beispiele, ein Referenzdokument –, dann muss das Modell diesen Teil nicht jedes Mal neu „verstehen". Der Anbieter speichert die interne Repräsentation zwischen, und du zahlst für diesen Teil bei Folgeanfragen nur noch einen Bruchteil.

So funktioniert es bei den großen Anbietern:

Anthropic (Claude): Caching ist explizit – du setzt einen cache_control-Marker. Cache-Schreiben kostet das 1,25-Fache (5-Min-TTL) bzw. das 2-Fache (1-Stunde-TTL), Cache-Lesen nur noch rund 10 Prozent des normalen Input-Preises. Das macht bis zu 90 Prozent Ersparnis auf dem gecachten Teil.
OpenAI (GPT): Caching läuft automatisch für Prompts ab etwa 1.024 Tokens, ohne Code-Änderung. Gecachte Input-Tokens sind deutlich günstiger (bei GPT-5.4 z. B. 0,25 $ statt 2,50 $ pro Mio. – also 90 Prozent günstiger).
Google (Gemini): Bietet sowohl implizites als auch explizites Context-Caching, ebenfalls mit kräftigem Rabatt auf wiederholten Kontext.

Das Entscheidende, das viele übersehen: Caching ist ein Präfix-Match. Schon ein einziges geändertes Byte am Anfang macht den gesamten Cache dahinter ungültig. Das heißt: Stabiler Inhalt (eingefrorener System-Prompt, feste Beispiele) gehört nach vorn, alles Variable (Zeitstempel, Nutzer-ID, die konkrete Frage) ans Ende. Ein datetime.now() im System-Prompt killt deinen Cache zuverlässig bei jeder Anfrage.

So sieht explizites Caching mit Claude in Python aus:

from anthropic import Anthropic

client = Anthropic()
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=512,
    system=[{
        "type": "text",
        "text": GROSSER_SYSTEM_PROMPT,   # stabil, wird gecacht
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": nutzer_frage}],  # variabel, am Ende
)

# Cache-Treffer überprüfen:
print(response.usage.cache_read_input_tokens)   # aus dem Cache (~0,1x Preis)
print(response.usage.cache_creation_input_tokens)  # frisch geschrieben (~1,25x)
print(response.usage.input_tokens)              # ungecacht (voller Preis)

Wenn cache_read_input_tokens über mehrere Anfragen hinweg null bleibt, hast du irgendwo einen „stillen Cache-Killer" – meist ein Zeitstempel, eine UUID oder unsortiertes JSON im Präfix. Faustregel: Lohnt sich, sobald derselbe Präfix mindestens zwei- bis dreimal innerhalb der Cache-Lebensdauer (oft 5 Minuten) verwendet wird.

Strategie 2: Batching – Rabatt für asynchrone Verarbeitung

Nicht jede Aufgabe muss in Echtzeit beantwortet werden. Wenn du nachts 50.000 Produktbeschreibungen generierst, Tausende Dokumente klassifizierst oder eine Eval-Pipeline laufen lässt, ist es egal, ob die Antwort in 2 Sekunden oder in 2 Stunden kommt. Genau dafür gibt es Batch-APIs – und die belohnen deine Geduld mit einem satten Rabatt.

Sowohl Anthropic als auch OpenAI geben 50 Prozent Rabatt auf alle Tokens, wenn du Anfragen als Batch einreichst. Google bietet mit dem Batch-Modus ebenfalls 50 Prozent. Du reichst ein Paket von Anfragen ein (bei Anthropic bis zu 100.000 Stück oder 256 MB), bekommst eine Batch-ID und holst die Ergebnisse ab, sobald sie fertig sind. Garantiert wird die Fertigstellung meist innerhalb von 24 Stunden – in der Praxis sind die meisten Batches deutlich schneller durch.

Das Beste: Batching lässt sich mit Prompt-Caching kombinieren. Du bekommst also den Batch-Rabatt und den Cache-Rabatt, was die Kosten für asynchrone Massenverarbeitung auf einen Bruchteil drückt.

So sieht ein Batch mit Claude in Python aus:

from anthropic import Anthropic
from anthropic.types.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.messages.batch_create_params import Request

client = Anthropic()

batch = client.messages.batches.create(requests=[
    Request(
        custom_id=f"klassifikation-{i}",
        params=MessageCreateParamsNonStreaming(
            model="claude-haiku-4-5",
            max_tokens=50,
            messages=[{"role": "user",
                       "content": f"Klassifiziere als positiv/negativ/neutral: {text}"}],
        ),
    )
    for i, text in enumerate(meine_texte)
])

# Status pollen, später Ergebnisse abholen – Reihenfolge ist NICHT garantiert,
# also immer über custom_id zuordnen:
for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        print(result.custom_id, result.result.message.content[0].text)

Ein wichtiger Hinweis: Die Ergebnisse kommen in beliebiger Reihenfolge zurück. Ordne sie immer über die custom_id zu, niemals über die Position. Für alles, was nicht latenzkritisch ist, ist Batching der einfachste 50-Prozent-Rabatt, den du bekommen kannst.

Strategie 3: Model-Routing und Kaskaden – das richtige Modell für jede Aufgabe

Hier liegt oft das größte ungenutzte Sparpotenzial. Viele Teams jagen jede Anfrage durch ihr stärkstes (und teuerstes) Modell – egal ob es um eine knifflige Code-Migration oder um die Frage „Ist diese Bewertung positiv oder negativ?" geht. Das ist, als würdest du jeden Brief per Express-Kurier verschicken.

Es gibt zwei Spielarten:

Model-Routing: Du entscheidest vorab, welches Modell eine Anfrage bekommt. Einfache Klassifikation, Formatierung, kurze Antworten → günstiges Modell (Haiku, GPT-5.4-nano, Gemini Flash-Lite). Komplexe Analyse, langes Reasoning, Agenten-Workflows → Premium-Modell. Das Routing kann über simple Heuristiken (Textlänge, Schlüsselwörter) oder über einen kleinen Klassifikator laufen.

Kaskaden (Cascading): Du schickst die Anfrage zuerst an ein kleines, günstiges Modell. Nur wenn dessen Antwort nicht gut genug ist – erkennbar an einem niedrigen Confidence-Score, einer Selbsteinschätzung oder einer Validierungsregel –, eskalierst du an das große Modell. Bei gut gewählten Schwellen landen oft 70 bis 90 Prozent der Anfragen beim günstigen Modell.

def beantworte_frage(frage: str) -> str:
    # Stufe 1: günstiges Modell zuerst
    klein = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=400,
        messages=[{"role": "user", "content": frage}],
    )
    antwort = klein.content[0].text

    # Eskalieren, falls das kleine Modell unsicher ist
    if ist_unsicher(antwort):   # z. B. Confidence-Check, Validierung
        gross = client.messages.create(
            model="claude-opus-4-8",
            max_tokens=400,
            messages=[{"role": "user", "content": frage}],
        )
        return gross.content[0].text
    return antwort

Eng verwandt ist der Einsatz kleinerer oder distillierter Modelle. Ein „distilliertes" Modell ist eine kompakte Version, die von einem großen Lehrermodell trainiert wurde und für eng umrissene Aufgaben oft fast gleichauf liegt – bei einem Bruchteil der Kosten. Für klar definierte, wiederkehrende Aufgaben (Extraktion, Klassifikation, Routing) ist ein kleines Modell fast immer die richtige Wahl. Tipp: Wähle nicht reflexartig das größte Modell. Fang klein an und steige nur dann auf, wenn die Qualität es wirklich erfordert.

Strategie 4: Prompt-Kürzung und RAG statt riesiger Kontexte

Großzügige Kontextfenster von bis zu 1 Million Tokens verleiten dazu, einfach „alles reinzukippen" – die komplette Dokumentation, den gesamten Gesprächsverlauf, fünf PDFs. Bequem, aber teuer. Denn jeder Token im Kontext wird bei jeder Anfrage neu bezahlt, und oberhalb gewisser Schwellen kommt der Long-Context-Aufschlag obendrauf.

Die elegante Lösung heißt RAG – Retrieval-Augmented Generation. Statt dem Modell ein 200-Seiten-Handbuch mitzugeben, speicherst du das Wissen in einer Vektordatenbank und holst pro Anfrage nur die drei bis fünf relevantesten Absätze heraus. Aus 50.000 Kontext-Tokens werden vielleicht 1.500. Das ist nicht nur günstiger, sondern oft auch besser: Das Modell wird nicht von irrelevantem Ballast abgelenkt und findet die Nadel im Heuhaufen leichter.

Konkrete Hebel zur Prompt-Kürzung:

Nur relevanten Kontext laden (RAG statt Volltext).
Gesprächsverlauf zusammenfassen statt ihn unbegrenzt mitzuschleppen. Viele APIs bieten dafür eingebaute Compaction-/Context-Editing-Funktionen, die alte Tool-Ergebnisse zusammenfassen oder entfernen.
Verbose Formatierung vermeiden: Eingerücktes JSON kostet mehr Tokens als kompaktes. Whitespace und Wiederholungen raus.
Few-Shot-Beispiele eindampfen: Oft reichen zwei gute Beispiele statt zehn.
Dokumente vorab filtern, bevor sie ans Modell gehen.

Eine Analogie: Du würdest einem Experten ja auch nicht die gesamte Bibliothek auf den Tisch legen und sagen „die Antwort steht irgendwo da drin". Du gibst ihm die zwei relevanten Seiten. Genauso solltest du dein LLM behandeln – fokussiert füttern, nicht zuschütten.

Strategie 5: Output-Länge begrenzen

Erinnerst du dich an den Faktor 4 bis 6? Output-Tokens sind der teuerste Posten pro Token. Deshalb ist das Begrenzen der Antwortlänge eine der wirkungsvollsten und am leichtesten umzusetzenden Maßnahmen.

Drei Hebel:

max_tokens realistisch setzen. Das ist eine harte Obergrenze. Aber Vorsicht: Zu niedrig gesetzt, wird die Antwort mitten im Satz abgeschnitten – und du zahlst trotzdem für den abgeschnittenen Teil und musst eventuell neu anfragen. Setze sie so, dass vollständige Antworten passen, aber Ausuferung verhindert wird.
Im Prompt um Kürze bitten. Ein simples „Antworte in maximal drei Sätzen" oder „Gib nur das JSON zurück, ohne Erklärung" wirkt Wunder. Modelle neigen ohne Anweisung gern zu freundlichem Geschwafel mit Einleitung und Zusammenfassung.
Strukturierte Ausgaben nutzen. Wenn du nur ein Label oder ein JSON-Objekt brauchst, erzwinge genau das mit output_config.format (JSON-Schema). Das verhindert „Hier ist deine Klassifikation: ..."-Vorgeplänkel und spart jedes Mal Output-Tokens.

# Statt einer ausschweifenden Prosa-Antwort: nur das, was du brauchst
response = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=100,
    messages=[{"role": "user", "content": f"Extrahiere Name und E-Mail: {text}"}],
    output_config={"format": {
        "type": "json_schema",
        "schema": {
            "type": "object",
            "properties": {
                "name": {"type": "string"},
                "email": {"type": "string"},
            },
            "required": ["name", "email"],
            "additionalProperties": False,
        },
    }},
)

Ein weiterer Punkt am Rande: Bei Modellen mit „Reasoning" oder „Thinking" zählt auch der interne Denkprozess zu den Output-Tokens. Wenn du bei einfachen Aufgaben den Denkaufwand niedrig hältst (etwa über einen effort-Parameter), sparst du zusätzlich.

Strategie 6: System-Prompts strukturieren und wiederverwenden

Der System-Prompt ist der unscheinbare Dauerläufer in deiner Kostenrechnung. Er ist bei jeder Anfrage dabei, und wenn er 2.000 Tokens lang ist, summiert sich das bei Millionen Anfragen zu echtem Geld. Die gute Nachricht: Genau hier greifen Caching und gute Struktur ineinander.

Best Practices für günstige, cache-freundliche System-Prompts:

Stabilen Teil einfrieren. Halte den System-Prompt byte-identisch über Anfragen hinweg. Keine eingebauten Zeitstempel, keine Nutzer-IDs, kein „aktuelles Datum: ...". Solche dynamischen Infos gehören ans Ende der Nachrichtenliste, nicht in den Präfix.
Reihenfolge respektieren. Die Anbieter rendern in der Reihenfolge tools → system → messages. Setze deinen Cache-Marker auf den letzten stabilen Block, dann werden Tools und System-Prompt gemeinsam gecacht.
Werkzeuge und Modell nicht mitten in einer Konversation wechseln. Tools stehen ganz vorn im Präfix – ein hinzugefügtes oder umsortiertes Tool macht den kompletten Cache ungültig. Sortiere Tool-Listen deterministisch (z. B. nach Name).
Mehrfach genutzte Prompts zentral pflegen. Wenn du denselben System-Prompt an mehreren Stellen verwendest, halte ihn an einer einzigen Quelle, damit nicht durch eine kleine Abweichung der Cache pro Variante neu geschrieben werden muss.

Und ein Profi-Trick für interaktive Anwendungen mit langer Konversation: Wenn du mittendrin eine Anweisung einschleusen musst (Moduswechsel, neuer Kontext), häng sie als zusätzliche Nachricht ans Ende an, statt den System-Prompt zu editieren. So bleibt der gecachte Präfix intakt und du sparst dir das teure Neuverarbeiten der gesamten Historie.

Strategie 7: Self-Hosting – wann sich eigene Modelle lohnen

Irgendwann kommt bei wachsendem Volumen die Frage auf: Sollten wir nicht ein Open-Weight-Modell (etwa aus der Llama-, Mistral- oder Qwen-Familie) selbst hosten und die API-Kosten komplett umgehen? Die ehrliche Antwort lautet: kommt drauf an – und meistens lautet sie „noch nicht".

Self-Hosting tauscht variable Token-Kosten gegen fixe Infrastrukturkosten. Statt pro Anfrage zu zahlen, mietest oder kaufst du GPUs und zahlst sie rund um die Uhr – egal ob sie ausgelastet sind oder nicht. Das rechnet sich nur bei sehr hohem, gleichmäßigem Volumen.

Was bei der Abwägung wirklich auf die Rechnung kommt:

GPU-Kosten: Leistungsfähige GPUs (für große Modelle braucht es oft mehrere) sind teuer – ob gekauft oder gemietet.
DevOps und Betrieb: Inferenz-Server (vLLM, TGI o. ä.) aufsetzen, skalieren, überwachen, aktualisieren. Das ist ein eigenes kleines Team-Thema.
Auslastung: Eine GPU, die nachts leer dreht, kostet trotzdem. Bei schwankendem Traffic ist die Pay-per-Token-API oft günstiger.
Qualitätslücke: Open-Weight-Modelle sind stark geworden, aber die absolute Spitze bei komplexem Reasoning liegt häufig noch bei den großen Closed-Source-Modellen.

Faustregel: Self-Hosting wird interessant, wenn deine monatliche API-Rechnung deutlich vier- bis fünfstellig ist, dein Volumen stabil und hoch ist, du Datenschutz-/Compliance-Gründe für volle Datenhoheit hast und du das nötige Infrastruktur-Know-how mitbringst. Für die allermeisten Projekte – gerade in der Wachstumsphase – ist es schlauer, zuerst die Strategien 1 bis 6 auszureizen. Die holen meist mehr raus, als der Wechsel zu Self-Hosting auf absehbare Zeit einsparen würde, und das ohne den ganzen Betriebsaufwand.

Strategie 8: Monitoring und Kostentracking

Du kannst nicht optimieren, was du nicht misst. Diese Binsenweisheit gilt bei LLMs ganz besonders, weil die Kosten so leicht im Verborgenen wachsen. Eine einzige schlecht gebaute Pipeline, ein vergessener Debug-Loop oder ein versehentlich abgeschaltetes Caching kann deine Rechnung verdoppeln, ohne dass es jemand merkt – bis zum Monatsende.

Was du minimal tracken solltest:

Tokens pro Anfrage (Input, Output, gecacht, ungecacht) – das usage-Objekt jeder Antwort liefert dir genau diese Felder.
Kosten pro Feature oder Endpunkt, damit du weißt, welcher Teil deiner App das Geld frisst.
Cache-Trefferquote. Sinkt sie plötzlich, hat sich ein stiller Cache-Killer eingeschlichen.
Modellverteilung. Wandern Anfragen, die eigentlich an Haiku gehen sollten, heimlich an Opus?

# Nach jeder Anfrage die Nutzung mitloggen
u = response.usage
log.info(
    "tokens: in=%s out=%s cache_read=%s cache_write=%s | feature=%s",
    u.input_tokens, u.output_tokens,
    u.cache_read_input_tokens, u.cache_creation_input_tokens,
    feature_name,
)

Praktisch heißt das: Logge die usage-Daten jeder Anfrage in dein Monitoring (Grafana, ein Dashboard, notfalls eine simple Tabelle), richte Budget-Alerts im Anbieter-Dashboard ein und schau dir wöchentlich die Top-Kostentreiber an. Viele Anbieter bieten zudem getrennte API-Keys pro Projekt oder Workspace – nutze sie, um Kosten sauber zuzuordnen. Und: Setze vor dem Produktivgang mit dem Token-Counter eine Kostenschätzung auf, damit dich die erste Rechnung nicht kalt erwischt.

Zusammenfassung und praktische Tipps

LLM-Kosten zu senken ist keine Hexerei – es ist eine Kombination aus Token-Bewusstsein und einer Handvoll gezielter Techniken. Hier die wichtigsten Erkenntnisse auf einen Blick:

Output ist 4- bis 6-mal teurer als Input. Jeder gesparte Output-Token zählt doppelt – begrenze die Antwortlänge und erzwinge strukturierte Ausgaben.
Tokens sind die Maßeinheit. Nutze den richtigen Token-Counter deines Anbieters, niemals tiktoken für Nicht-OpenAI-Modelle.
Prompt-Caching spart bis zu 90 Prozent auf wiederkehrenden Kontext – stabilen Inhalt nach vorn, Variables nach hinten, und Cache-Treffer überprüfen.
Batching gibt 50 Prozent Rabatt für alles, was nicht in Echtzeit beantwortet werden muss – und lässt sich mit Caching kombinieren.
Model-Routing und Kaskaden: Kleines Modell zuerst, großes nur bei Bedarf. Hier liegt oft das größte Sparpotenzial.
RAG statt riesiger Kontexte: Nur die relevanten Absätze laden, nicht das ganze Handbuch – günstiger und besser.
Self-Hosting lohnt sich erst bei sehr hohem, stabilem Volumen – vorher die anderen Hebel ausreizen.
Monitoring ist die Grundlage für alles: Was du nicht misst, kannst du nicht optimieren.

Mein Rat für den Einstieg: Fang mit Model-Routing und Prompt-Caching an. Diese beiden bringen mit dem geringsten Aufwand meist die größte Ersparnis. Danach Output-Längen begrenzen und alles Asynchrone in die Batch-API verschieben. Wenn du diese vier Schritte sauber umsetzt, halbierst (oder drittelst) du deine Rechnung fast garantiert – und behältst trotzdem die volle Qualität. Viel Erfolg beim Sparen!

Der radikalste Kostenhebel: gar nicht bezahlen

Alle bisherigen Strategien senken den Preis je Anfrage. Es gibt einen Weg, ihn auf null zu bringen — ein Modell auf eigener Hardware. Das rechnet sich nicht immer, aber die Schwelle liegt niedriger, als viele annehmen: Bei konstanter Grundlast kippt die Rechnung zugunsten eigener Hardware, bei schwankender Nutzung bleibt die API günstiger.

Was dabei zu bedenken ist: Ein lokal betreibbares Modell ist kleiner als die Spitzenmodelle, es ist langsamer, und der Betrieb kostet Aufmerksamkeit. Für Klassifikation, Extraktion und Zusammenfassung reicht es oft; für Aufgaben mit mehrstufigem Schließen merkt man den Unterschied.

Der Einstieg steht in Ollama: lokale Sprachmodelle betreiben, die Rechnung für Speicher und Modellgröße in Welches Ollama-Modell?. Und weil das Kontextfenster einer der größten Kostentreiber ist, lohnt parallel ein Blick in Context Window und lange Kontexte bei LLMs.

Ressourcen

Anthropic – Pricing – Aktuelle Preise für alle Claude-Modelle
Anthropic – Prompt Caching – Funktionsweise, Rabatte und Code-Beispiele
Anthropic – Batch Processing – 50 % Rabatt für asynchrone Verarbeitung
Anthropic – Token Counting – Genaue Token-Zählung vor dem Request
OpenAI – API Pricing – Aktuelle GPT-Preise und Tarife
OpenAI – Prompt Caching – Automatisches Caching ab ca. 1.024 Tokens
OpenAI – Batch API – Asynchrone Verarbeitung mit 50 % Rabatt
Google – Gemini API Pricing – Preise für die Gemini-Familie
Google – Context Caching – Implizites und explizites Caching bei Gemini