Die Intelligenz-Leiter - LLM-Kosten senken, ohne Qualität zu verlieren

Stellen Sie sich vor, Sie verarbeiten 50.000 eingehende Dokumente pro Tag - Rechnungen, Verträge, Formulare. Klassifizieren, Daten extrahieren, weiterleiten. Mit GPT-5.4 oder Claude Opus zahlen Sie dafür mehrere tausend Euro im Monat. Mit dem richtigen Open-Weight-Modell bleibt eine niedrige dreistellige Summe - bei gleicher Qualität. Dieser Artikel zeigt, wie Sie dahin kommen - entlang von drei Ebenen, die wir die Intelligenz-Leiter nennen.

Inhalt

1. Die Rechnung, die niemand sehen wollte
2. Die These
3. Die Intelligenz-Leiter
4. Ebene 1: Architektur
5. Ebene 2: Prompt
6. Ebene 3: Reliability
7. Fazit

Die Rechnung, die niemand sehen wollte

Unternehmens-LLM-Spending hat sich laut Menlo Ventures in sechs Monaten mehr als verdoppelt - von 3,5 auf 8,4 Milliarden US-Dollar.^[1] Einzelne Modelle werden zwar pro Jahr um den Faktor 10 günstiger, aber die Rechnungen sinken nicht: Teams migrieren die Ersparnis sofort in das nächste Frontier-Modell.^[1] Das eigentliche Problem ist selten der Token-Verbrauch. Es ist die Modellwahl.

Die These

Das teuerste Modell ist das, das Sie zu oft anrufen.

Zurück zu Ihren Dokumenten. Der erste Reflex in jedem Projekt: das beste verfügbare Modell nehmen, damit die Demo läuft. Verständlich - in der Demo. In Produktion bei 50.000 Requests pro Tag wird daraus eine sechsstellige Jahresrechnung. Und oft wird die Qualität sogar schlechter: Überdimensionierte Modelle brauchen länger, erzeugen mehr Tokens und arbeiten bei eng umrissenen Aufgaben weniger deterministisch als ein sauber instruiertes kleineres Modell.

Die Lösung ist keine zusätzliche Abstraktion, sondern eine Architekturentscheidung: das richtige Modell für die richtige Aufgabe, zur richtigen Zeit. Dafür brauchen Sie eine Karte des Terrains.

Die Intelligenz-Leiter

Die Leiter hat drei Ebenen - und die meisten Teams optimieren heute nur auf einer davon, meistens auf Ebene 2.

Sie steigen von oben nach unten: erst die Architektur, dann die Prompts für das gewählte Modell, dann die Reliability. Wer andersherum arbeitet, optimiert lokal und verschwendet global.

Ebene 1: Architektur

Der wirksamste Hebel. Drei Tiers haben sich am Markt etabliert: Frontier-Modelle (GPT-5.4, Claude Opus, Gemini 2.5 Pro) mit vollem Reasoning und höchstem Preis. Efficient Tier (GPT-5.4 mini, Claude Sonnet und Haiku, Gemini Flash) - destillierte Frontier-Varianten, entsprechend positioniert. SLMs und Open-Weight-Modelle (GPT-5.4 nano, Llama, Qwen, gpt-oss) - die letztgenannten meist Apache-2.0 oder MIT, über Provider wie OpenRouter, Fireworks oder Groq beziehbar.

Preise Stand April 2026, gerundet.^[2]

Für Ihre Dokumente heißt das: Eine Rechnung auf 20 Felder zu extrahieren oder einen Vertrag in 15 Kategorien einzusortieren ist keine offene Reasoning-Aufgabe. Es ist eine gut umrissene Extraktions- oder Klassifikationsaufgabe - und der Output-Tarif ist auf GPT-5.4 nano 20-fach günstiger als auf Claude Opus, 12-fach günstiger als auf GPT-5.4. Auf einem Open-Weight-SLM können es zwei Größenordnungen mehr werden. Kein Reasoning-Uplift der Welt rechtfertigt das.

Das Muster ist nicht auf Dokumente beschränkt. Es passt überall, wo hohes Volumen auf klar umrissene Entscheidungen trifft - Support-Tickets routen, Log-Anomalien filtern, Produktdaten normalisieren, Compliance-Texte gegen Regeln prüfen. Die konkreten Zahlen ändern sich, die Logik nicht.

Eine zweite Architekturfrage: Reasoning-Modell oder Chain-of-Thought-Prompt? Ein gut instruiertes Efficient-Tier-Modell mit strukturiertem CoT schlägt ein schlecht gepromptetes Frontier-Modell mit Extended Thinking in vielen Fällen - bei einem Bruchteil der Kosten.

Nicht jeder Use Case gehört nach unten. Bei offenem Reasoning ohne klare Heuristik, bei hoher Correctness-Anforderung mit niedrigem Volumen oder ohne Trainingsset für Optimierung bleibt das Frontier-Modell richtig. Das beste Beispiel ist gerade Agentic Coding mit Claude Code oder Codex: hier braucht es genau das offene Reasoning, das die kleinen Modelle nicht liefern - ein günstigeres Modell scheitert nicht etwas schlechter, sondern wird praktisch unbrauchbar.

Und der Hebel kippt: Bei Volumen-Aufgaben rechnet sich Modell-Ersparnis × Anzahl Requests. Bei Coding macht ein Entwickler vielleicht 50 Anfragen pro Tag - der Token-Preis ist nicht der dominierende Kostenfaktor, die Entwicklerzeit ist es. Hier ist ein teureres Modell oft die wirtschaftlichere Wahl.

Ebene 2: Prompt

Prompt Engineering für kleine Modelle ist nicht dasselbe wie für große. GPT-5.4 oder Claude Opus verzeihen schwammige Formulierungen, GPT-5.4 nano oder ein Open-Weight-SLM tun das nicht. Der Prompt, der mit GPT-5.4 zu 95 % funktioniert, fällt mit GPT-5.4 nano auf 60 %. Das ist kein Argument gegen das kleine Modell - es ist eines für besseres Prompting. "Besser" heißt nicht "länger", sondern: systematisch, evaluiert, optimiert.

Hier setzen Frameworks wie DSPy (Stanford, Apache-2.0)^[3] an. Die Kernidee: Prompts werden nicht handgeschrieben, sondern kompiliert. Sie definieren Signatur, Metrik und ein kleines Trainingsset - etwa 500 manuell annotierte Dokumente - und ein Optimizer probiert automatisch hunderte Varianten aus. Eine Fallstudie aus 2025 dokumentiert, wie DSPy-Optimierung GPT-4o-mini bei einem Topic-Assignment-Task von 10,8 % auf 47,6 % Accuracy brachte.^[4] Die Zahlen variieren je nach Task, aber der Mechanismus ist robust: Was vorher nur mit dem Efficient Tier ging, läuft nach Optimierung oft auf einem Open-Weight-SLM - mit der vollen Kostendifferenz.

Wann lohnt sich der Aufwand? Wenn drei Bedingungen zusammenkommen: hohes Volumen, eine objektiv messbare Erfolgsmetrik und eine stabile, wiederkehrende Aufgabe. Bei einmaligen Anwendungen, schwer messbarer Qualität oder Use Cases ohne Trainingsdaten bleibt klassisches Prompt Engineering der pragmatischere Weg.

Ebene 3: Reliability

Kleine Modelle sind günstiger, aber auch unzuverlässiger. Ohne Reliability-Engineering führt der Wechsel von GPT-5.4 auf GPT-5.4 nano zu mehr Incidents und am Ende zu höheren Gesamtkosten als vorher. Drei Patterns tragen den Abstieg:

Structured Output. JSON Mode, Tool Calling, Response Schemas. In Ihrem Dokumenten-Beispiel: Rechnungsnummer, Betrag, Datum, Lieferant als erzwungenes JSON-Schema - keine Freitext-Antworten, keine "Halluzinationen" über erfundene Felder.

Validation Layer. Pydantic, Guardrails, JSON Schema. Jeder Output wird gegen erwartete Strukturen geprüft, bevor er ins nächste System fließt.

Retry mit Escalation. Wenn GPT-5.4 nano fehlschlägt, eskaliert das System automatisch auf GPT-5.4 mini oder Claude Haiku. Failt das auch, auf GPT-5.4 oder Claude Opus. 95 % der Dokumente zahlen den günstigen Tarif, die restlichen 5 % bekommen die Robustheit des teuren - und Ihre Rechnung bleibt trotzdem zweistellig niedriger als vorher.

Ohne diese Patterns ist der Abstieg riskant. Mit ihnen wird er der Default.

Fazit

Die Intelligenz-Leiter ist kein Framework und kein Tool – sie ist eine Denkweise. Wenn Sie die drei Ebenen für Ihre Use Cases durchgehen, finden Sie in den meisten Architekturen zweistelliges Einsparpotenzial ohne Qualitätsverlust.

Wenn Sie wissen möchten, wo in ihrer Architektur das größte Potenzial liegt, hilft ein strukturierter Blick: Zuerst eine Inventur der laufenden LLM-Calls – welches Modell für welche Aufgabe, in welchem Volumen? Dann eine Bewertung entlang der drei Ebenen – wo ist die Diskrepanz zwischen Anforderung und gewähltem Modell am größten? Und schließlich ein Pilot am Use Case mit dem höchsten Hebel, der zum Muster für weitere wird.

Genau diese Begleitung bieten wir bei iteratec – LLM-Architekturen entwerfen, evaluieren und betriebsfest bauen.

Haben Sie Fragen oder benötigen Sie Unterstützung?

Mehr zu den Möglichkeiten von IT-Security und Resilienz für Ihr Unternehmen finden Sie auf unserer Webseite. Nehmen Sie jetzt Kontakt mit uns auf.

Quellen:

[1] Menlo Ventures, 2025 Mid-Year LLM Market Update (Juli 2025). https://menlovc.com/perspective/2025-mid-year-llm-market-update/

[2] Preise laut offiziellen Pricing-Seiten der Anbieter (Anthropic, OpenAI, Google) bzw. via OpenRouter für Open-Weight-Modelle. Open-Weight-Preise variieren je nach Provider (Fireworks, Together.ai, Groq u. a.) und Batch- oder Caching-Discounts. Stand April 2026.

[3] Khattab et al., DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines, Stanford NLP, 2023. https://github.com/stanfordnlp/dspy

[4] Is It Time To Treat Prompts As Code? A Multi-Use Case Study For Prompt Optimization Using DSPy, arXiv:2507.03620 (2025). https://arxiv.org/abs/2507.03620