Agentenkosten senken, ohne das Ergebnis zu verschlechtern
Wenn eine Tokenrechnung jemanden überrascht, ist der Reflex, überall auf ein günstigeres Modell zu wechseln und Qualitätsverlust hinzunehmen. Das ist selten nötig. In den Systemen, die wir geprüft haben, entstand der Großteil der Ausgaben durch Kontext, der nicht dort sein musste, und durch Schritte, die kein teures Modell brauchten.
Die Methode unten ist langweilig und wirksam: erst messen, dann vier Änderungen nach Ertrag anwenden und dann entscheiden, ob überhaupt noch ein Problem besteht. Die meisten Teams hören nach der zweiten auf.
Erst pro Lauf messen#
Monatssummen sagen nichts Handlungsfähiges. Protokollieren Sie je Lauf: Eingabe- und Ausgabetokens, Anzahl Modellaufrufe, Modell je Aufruf und Aufgabentyp. Dann betrachten Sie die Kosten pro abgeschlossener Aufgabe, aufgeteilt nach Aufgabentyp. Fast immer dominieren ein oder zwei Typen, und darin ein Schritt. Alles andere zu optimieren ist Aufwand dort, wo das Geld nicht liegt.
Zählen Sie gescheiterte und abgebrochene Läufe im Nenner mit. Eine Retry-Schleife, die drei Versuche verbrennt, ist ein Kostenproblem in Qualitätsverkleidung.
Die vier Änderungen nach Ertrag#
| Änderung | Typische Einsparung | Risiko |
|---|---|---|
| Kontext kürzen: benutzte Dokumente verwerfen, Historie komprimieren | 20–40 % | Gering, solange das Ziel fixiert bleibt |
| Günstige Schritte auf kleineres Modell routen | 20–40 % | Gering, mit Evaluation je Schritt |
| Stabilen Prompt-Prefix cachen | 10–30 % bei wiederkehrendem Traffic | Gering |
| Schritte reduzieren: bessere Werkzeuge, weniger Retries | 10–25 % | Mittel — Werkzeugarbeit nötig |
Die Rechnung ist der Kontext#
Jeder Zug schickt den angesammelten Kontext erneut; ein Lauf mit acht Schritten kann dasselbe Dokument achtmal bezahlen. Drei Gewohnheiten lösen das meiste: abgerufene Passagen nach ihrem Schritt verwerfen; alte Züge zu kurzen Faktennotizen komprimieren; Werkzeugergebnisse auf genutzte Felder kürzen statt ganze API-Antworten weiterzureichen. Keine davon reduziert Fähigkeit — sie entfernt Text, den das Modell ohnehin nicht nutzte.
Nach Schritt routen, nicht nach Geschmack#
Extraktion, Klassifikation und Formatierung brauchen selten Ihr stärkstes Modell; Planung und Nutzerprosa oft schon. Legen Sie die erste Gruppe eine Stufe tiefer, lassen Sie das Eval-Set laufen und behalten Sie die Änderung nur, wenn die Zahlen halten. Genau das erlaubt, ein Drittel der Rechnung zu streichen, ohne dass jemand einen Unterschied bemerkt.
- Mit dem volumenstärksten, urteilsärmsten Schritt beginnen.
- Jeweils einen Schritt ändern und danach das Eval-Set laufen lassen.
- Protokollieren, welches Modell welche Entscheidung erzeugte.
- Ausgabengrenze pro Lauf setzen, damit ein pathologischer Fall nicht unbegrenzt ist.
Was Sie nicht tun sollten#
Kürzen Sie nicht das Retrieval, das Ihre Antworten belegt — halluzinierte Ausgaben sind weit teurer als Tokens, sobald jemand sie korrigieren muss. Streichen Sie nicht den Kritikerlauf vor unumkehrbaren Handlungen, um einen Aufruf zu sparen. Und jagen Sie keine Mikrooptimierungen in der Promptformulierung; der Effekt ist Rauschen neben dem Kontextkürzen.
Häufige Fragen
Lohnt sich Caching?
Wenn Ihre Läufe einen langen stabilen Prefix teilen — Systemanweisungen, Werkzeugdefinitionen, Richtlinientext — ja, und es ist einer der billigsten Gewinne. Bauen Sie den Prompt so, dass der stabile Teil vorn steht.
Sollte ich zum Sparen feinjustieren?
Nur für einen volumenstarken, engen, stabilen Schritt, in dem ein kleines Modell mit Tuning ein großes erreicht. Feintuning bringt Wartungspflicht und Retraining-Zyklus; bei geringem Volumen schlagen Routing und Kontextkürzen es klar.
Wie verhindere ich einen sehr teuren Einzellauf?
Schritte und Ausgaben pro Lauf deckeln, identische Wiederholungsaufrufe erkennen und mit Teilergebnis stoppen. Alarmieren Sie bei Läufen am Limit — meist ein Bug, nicht nur eine Ausgabe.
agenten kostenllm kosten optimierungtoken kosten senkenprompt cachingmodell routing
