LLM-API-Kosten sind 2026 um 80 % gefallen: Was sich in deiner KI-Architektur ändert

Wenn du 2024 ein KI-Produkt architektiert hast, hast du die halbe Engineering-Zeit damit verbracht, den Preis von Tokens zu verstecken. Aggressives Retrieval, brüchige Summarisation, Model-Routing für jeden Call. 2026 ist der Frontier-Klasse-Modell-Preis pro Million Tokens grob ein Fünftel dessen, was er vor zwei Jahren war. Das ändert die Mathematik fast jeder Designentscheidung, die wir gemacht haben. Dieser Post ist das, was wir jetzt tatsächlich in Kundenarchitekturen umverdrahten, mit einer Seite-an-Seite-Kostentabelle und einer Liste konkreter Moves.

Geschrieben aus Wavects Engagement-Historie über KI-Produktbuilds hinweg. Zahlen in der Tabelle sind illustrativ basierend auf öffentlichen Preistrends, keine anbieter-spezifischen Commitments.

Ist Inferenz wirklich 80 % günstiger geworden?

Für Frontier-Klasse-Modelle bei den großen Providern liegt der Per-Token-Listenpreis 2026 grob 70 bis 85 % unter der äquivalenten Klasse 2024, je nach Tier. Mid-Tier-Modelle sind weiter gefallen. Cached-Input-Preise sind noch stärker gefallen. Was nicht gefallen ist: Latenz bei hoher Concurrency, Egress, Vektor-Datenbank-Hosting und die menschlichen Kosten zum Bau von Evals. Deine Rechnung sank also, dein Architektur-Hebel stieg, aber dein Engineering-Urteil zählt mehr, nicht weniger.

Wie sieht die neue Kostenkurve tatsächlich aus?

Grobe illustrative Zahlen, normalisiert pro 1M Tokens, Frontier- und Mid-Tier-Klassen. Behandle als richtungsweisend, nicht als Quote.

Die interessante Zeile ist "Frontier Reasoning". Ein tiefer Agent-Loop, der 2024 0,40 $ pro Task kostete, kostet heute eher 0,08 $. Das ändert, welche Produkte tragfähig sind.

Was haben wir aufgehört zu tun?

Wir haben aufgehört, Retrieval für kleine Korpora überzu-engineeren. Wir haben aufgehört, jeden Call durch einen "günstigen Default" zu routen, wenn die Qualitätslücke zählte. Wir haben aufgehört, Custom-Summarisierer für winzige Kontextfenster zu schreiben.

• Unter grob 500k bis 1M Tokens Korpus erwägen wir jetzt Long-Context-Prompts vor einer RAG-Pipeline. Günstiger zu warten, einfacher zu evaluieren.
• Wir haben aufgehört, Modelle voreilig downzugraden. Wenn Qualität zählt und der Task weniger als 100k mal pro Tag läuft, gewinnt das Frontier-Modell meist bei den Gesamtkosten, sobald du Entwicklerzeit für das Fixen schlechter Outputs einrechnest.
• Wir haben aufgehört, Prompt-Caches hand-zu-rollen. Die anbieter-seitige Cache-Preisgestaltung ist jetzt ein First-Class-Architektur-Hebel, kein Nachgedanke.

Welche Architektur-Moves machen wir jetzt?

Acht konkrete Moves, die wir 2026 in Kundenarbeit anwenden.

1. Long Context first, RAG second. Für Korpora unter etwa 1M Tokens, versuche einen strukturierten Long-Context-Prompt, bevor du Retrieval baust. Miss Qualität. Füge RAG nur hinzu, wenn Kontextgröße, Aktualität oder Kosten es erzwingen.
2. Provider-Prompt-Caching als Architektur-Primitiv. Stabiler System-Prompt oben, stabile Instruktionen als nächstes, volatile User-Inputs zuletzt. Cache-Hit-Raten über 80 % senken Input-Kosten um eine Größenordnung.
3. Günstiger Default plus Eskalation, kein blindes Routing. Lass Mid-Tier zuerst laufen. Wenn eine strukturierte Confidence-Prüfung fehlschlägt, eskaliere zu Frontier. Tracke Eskalationsrate als Produkt-KPI. Wir sehen das in unserer Arbeit an Twinsoft AI.
4. Eval-getriebenes Modell-Swapping. Pro Task, Qualität und Kosten gemeinsam tracken. Wenn ein neues Modell ausgeliefert wird, lass die Eval neu laufen. Swappe, wenn das Verhältnis sich verbessert. Behandle Modellwahl als Konfiguration, nicht als Code.
5. Tiefere Agent-Loops. Ein Reasoning-Loop mit 6 bis 10 Tool-Calls war für die meisten B2C-Produkte früher unbezahlbar. 2026 ist er es nicht. Bau für Tiefe, nicht für Token-Sparsamkeit. Siehe KI-Agenten.
6. Batch-Verarbeitung für alles Async. Batch-Endpoints sitzen bei grob der Hälfte der Live-Rate. Alles, was keine Sub-Sekunden-Antwort braucht, sollte in Batch laufen.
7. Behandle MCP-Tools als First-Class-Kontext. Günstige Tokens machen tool-reiche Agenten tragfähig. Der Engpass hat sich von Kosten zu Tool-Design und Observability verschoben.
8. Bau das Eval-Harness vor dem zweiten Feature. Die größte Verschwendung 2026 ist, eine Modelländerung auszuliefern, die du nicht messen kannst. Evals sind die neue Test-Suite. Siehe SDLC.

"Deine KI-Architektur sollte die Preiskurve tracken, nicht am Tag einfrieren, an dem du angefangen hast zu bauen."

Zählt RAG noch?

Ja, aber die Schwelle hat sich verschoben. RAG ist immer noch die richtige Antwort, wenn der Korpus groß ist (mehrere Millionen Tokens), wenn Aktualität zählt (Wissen, das täglich wechselt), wenn Access Control Row-Level-Enforcement braucht oder wenn du eine klare Zitat-Spur brauchst. Für alles andere ist Long Context meist einfacher. Wir haben 2026 ein Wissensprodukt umgebaut, indem wir den Großteil des Retrieval-Layers gelöscht und auf strukturierte Long-Context-Prompts gewechselt sind. Die Eval-Scores stiegen und die Wartungslast sank. Engagements wie PromptID und Quivr haben geprägt, wie wir diese Linie ziehen.

Wo geht das Geld jetzt tatsächlich hin?

2024 dominierte Inferenz die Rechnung. 2026 verteilt sie sich gleichmäßiger auf Inferenz, gehostete Vektor- oder Such-Infrastruktur, Observability- und Eval-Runs und einen nicht-trivialen Posten für Human-Review bei Agent-Produkten. Ein typisches mittelgroßes KI-Produkt, an dem wir arbeiten, hat Inferenz bei 30 bis 45 % der Gesamt-Run-Kosten, runter von 70 bis 80 % vor zwei Jahren. Die Implikation: Inferenz weiter zu optimieren hat abnehmenden Ertrag. Optimiere stattdessen den Eval-Loop und die Tool-Fläche.

Was ist mit Open Weights?

Open-Weight-Modelle haben 2026 viel der Qualitätslücke geschlossen. Für High-Volume-, Latenz-sensitive oder Daten-Residency-sensitive Workloads sind selbst gehostete Open Weights jetzt ehrlich wettbewerbsfähig. Der Haken: Du übernimmst die Ops-Last, die Eval-Last und den Upgrade-Cadence. Wir defaulten zu gehosteten APIs für frühe Produkte und überdenken Self-Hosting, sobald das Volumen es rechtfertigt, meist nördlich von 50 Millionen Tokens pro Tag.

Wie bepreisen wir KI-Builds 2026?

Wir nutzen immer noch agilen Festpreis für gescopte Deliverables. Was sich geändert hat, ist die Run-Cost-Prognose. Wir modellieren erwartetes Token-Volumen, Cache-Hit-Verhältnis, Eskalationsrate und Batch-Anteil. Ein modernes KI-Feature für einen Mid-Market-Kunden läuft typischerweise bei 30 bis 60 % der Inferenz-Kosten, die wir 2024 für dieselbe Qualitätslatte angeboten hätten. Der Engineering-Aufwand hat sich vom Kostenverstecken zu Quality Engineering verschoben.