Kosten- & Latenz-Abwägungen
Qualität, Kosten und Geschwindigkeit ziehen gegeneinander. Du kannst nicht alle drei gleichzeitig maximieren — aber du kannst jede dort einsetzen, wo es darauf ankommt, und überall sonst sparen.
Das Dreieck
Ein größeres Modell ist klüger, aber langsamer und teurer; ein kleineres ist schnell und günstig, aber weniger leistungsfähig. Gutes Engineering bedeutet, jede Aufgabe an den richtigen Punkt dieses Dreiecks zu leiten.
Die größten Hebel (grob in Reihenfolge)
- Das Modell richtig dimensionieren. Verwende Opus nicht für Klassifizierung. Beginne mit Sonnet, wechsle für einfache/hochvolumige Schritte zu Haiku und reserviere Opus für die schwierigen Teile — Ein Modell auswählen.
- Modellabstufung / Kaskaden. Nutze zuerst ein günstiges Modell; eskaliere nur bei Bedarf zu einem stärkeren (z. B. bei Fällen mit geringer Konfidenz).
- Prompt-Caching. Verwende ein stabiles Prompt-Präfix über mehrere Aufrufe hinweg wieder — große Einsparungen bei wiederholten System-Prompts, RAG-Kontext oder Tool-Katalogen von Agenten.
- Eingabe-Tokens kürzen. Sende nur, was wichtig ist; RAG schlägt das Hineinstopfen der gesamten Wissensbasis. Kürzere Eingaben = günstiger und oft besser.
- Ausgabe begrenzen mit sinnvollen
max_tokensund straffen Formatanweisungen. - Batche Offline-Arbeit, bei der Latenz keine Rolle spielt.
Latenzspezifische Gewinne
- Streame Antworten, damit Nutzer die Ausgabe sofort sehen — enorm für die gefühlte Geschwindigkeit, selbst wenn die Gesamtzeit unverändert bleibt (Streaming).
- Parallelisiere unabhängige Teilaufrufe.
- Cache wiederholte Arbeit; berechne vor, wo du kannst.
- Wähle ein kleineres Modell für den interaktiven Pfad; erledige die schwere Arbeit asynchron.
Optimiere nicht blind
Miss zuerst: Wo gehen die Tokens und die Sekunden tatsächlich hin? Optimiere dann den größten Posten. Und prüfe die Qualität nach jeder Kostensenkung mit Evals erneut — ein günstigeres Setup, das falsch ist, ist nicht günstiger.