Reihenfolge der LLM-Kostenoptimierung
Aktualisiert September 27, 2026 · erstveröffentlicht September 27, 2026
In einem r/LLMDevs-Thread vom September 2026 ging es darum, wie Teams LLM-Kosten in der Produktion tatsächlich steuern und was sie ohne Zeitdruck in der Entwicklung tun würden. Die meistbewertete Antwort enthielt einen wichtigen Hinweis: Die Reihenfolge ist viel wichtiger, als viele zugeben. Das Team begann mit Prompt-Caching und deutlich kürzeren System-Prompts. Der Versuch, ein kleines Modell für wiederkehrende Aufgaben feinzujustieren, scheiterte dagegen an hohem Wartungsaufwand und nachlassender Qualität.
Die sinnvolle Reihenfolge
- Prompt-Caching aktivieren. Kaum eine Entwicklungsstunde bringt schneller einen finanziellen Effekt. Bei Opus 5.5 kosten eine Million Cache-Lese-Token 0,20 $ statt 4,00 $ für neue Eingabe-Token. Das sind 95 % Rabatt auf diesen Kostenposten. Werden System-Prompt, Tool-Definitionen oder abgerufener Kontext wiederholt verwendet, beginnen Sie hier.
- System-Prompt kürzen. Auch das empfahl die Antwort im Thread. Ausführliche Anweisungen werden bei jedem Aufruf erneut berechnet. Hier ist vor allem präzises Schreiben gefragt.
- Ungenutzte Tools entfernen. Jede Tool-Definition wird bei jeder Anfrage als Kontext mitgesendet, unabhängig davon, ob das Modell das Tool aufruft. Das entspricht dem Overhead von MCP-Tool-Definitionen. Ein Eintrag weniger in der Konfiguration spart dauerhaft Kontext.
- Nach Aufgabe routen. Erst jetzt lohnt sich Model-Routing besonders. Ein Router, der nach dem Caching eingerichtet wird, startet bereits mit niedrigeren Kosten, bevor er auch nur ein Modell austauscht.
- In Batches verarbeiten oder verschieben. Eine Batch-API bietet einen direkten Preisnachlass für Aufgaben ohne unmittelbare Nutzerantwort. Geeigneter Traffic außerhalb der Produktion sollte von Anfang an darüber laufen.
- Fine-Tuning zuletzt prüfen. Viele Teams greifen zuerst dazu; im beschriebenen Fall scheiterte dieser Schritt. Wartung und Qualitätsverlust verursachen dauerhafte Betriebskosten für Einsparungen, die Caching und Routing möglicherweise bereits erzielen.
Warum die Reihenfolge entscheidend ist
Jeder Schritt verändert die Tokenmengen und Kosten, auf die der nächste wirkt. Wird der System-Prompt vor dem Routing gekürzt, kann ein günstigeres Modell mit derselben Routing-Logik mehr Anfragen übernehmen. Wird Caching vor dem Fine-Tuning aktiviert, muss sich dessen Budget nur noch gegenüber Cache-Fehlschlägen rechtfertigen. In der falschen Reihenfolge zahlen Sie doppelt: für ein Fine-Tuning, das ein umformulierter Prompt überflüssig gemacht hätte, oder für einen Router, der 60.000 Token Anweisungen an ein dafür ungeeignetes günstiges Modell schickt.
Das typische Fehlmuster
Im Thread sollte ein feinjustiertes kleines Modell wiederkehrende Arbeit übernehmen. Die geplante Ersparnis war nachvollziehbar, doch jede Veränderung dieser Arbeit erforderte ein neues Training. Zugleich entfernte sich die Qualität nach Aktualisierungen des Basismodells immer weiter von dessen Niveau. Der Betriebsaufwand machte das Fine-Tuning schwer wartbar. Vermutlich betraf die Arbeit nur 15 % des Volumens und 2 % der Ausgaben: eine kleine Ersparnis bei hohen laufenden Kosten.
Die Abfolge an einer Anfrage durchspielen
Nehmen Sie eine repräsentative Anfrage, wenden Sie die Schritte nacheinander an und erfassen Sie berechnete Token und Kosten:
| Schritt | Was sich ändert | Typische angegebene Senkung |
|---|---|---|
| Caching aktivieren | Wiederholtes Präfix wird aus dem Cache gelesen | 40–70 % |
| System-Prompt kürzen | Weniger nicht gecachte Token je Aufruf | 10–25 % |
| Ungenutzte Tools entfernen | Kleinerer Tool-Block | 5–15 % |
| Routing | Günstigeres Modell für die meisten Anfragen | 30–60 % |
| Batches außerhalb der Produktion | Vergünstigter Tarif | 25–50 % für diesen Traffic |
Diese Effekte bauen aufeinander auf. Im Beispiel kann dieselbe Anfrage so 80–90 % weniger kosten. Wer mit Fine-Tuning beginnt, kann dagegen bei einem angepassten Modell für nur 15 % des Volumens und einer nie rentablen Routing-Regel landen. Die Angaben zu Caching und Routing beziehen sich auf Kosten; Routing reduziert die Tokenzahl nicht automatisch.
Fazit
Caching, kürzere Prompts und das Entfernen ungenutzter Tools sind günstige, vergleichsweise risikoarme Schritte mit kumulativem Effekt. Danach folgen Routing und Batch-Verarbeitung. Fine-Tuning kommt zuletzt, falls es dann noch nötig ist. Entscheidend ist die Abfolge.
Weiterführend
- Kosten ausführlicher Prompts
- Overhead von MCP-Tool-Definitionen
- Gleichzeitige Ausführung von Subagenten
- Gratisstufen als Akquisekosten
- Drei Budgets für Agenten
Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen →