Zum Hauptinhalt springen

Kosten- & Latenz-Abwägungen

Fortgeschritten
What you'll learn
  • Das Dreieck aus Kosten/Qualität/Geschwindigkeit — warum du nie alle drei gleichzeitig maximieren kannst
  • Die sechs größten Hebel, um dort zu investieren, wo es zählt, und überall sonst zu sparen
  • Wie eine „billig-zuerst“-Kaskade 90 % des Volumens an ein kleines Modell leitet und die Kosten um ~70 % senkt, ohne die Qualität bei den harten Fällen zu verlieren
  • Die latenzspezifischen Gewinne (Streaming, Parallelität, Caching, Async), die die gefühlte Geschwindigkeit neu formen
  • Warum „blind optimieren“ die Qualität verbrennt — zuerst messen, dann mit Evals absichern

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)​

Guided walkthrough1 of 6
  1. Führe Opus nicht für Klassifizierung aus. Beginne mit Sonnet, wechsle für einfache/hochvolumige Schritte zu Haiku, reserviere Opus für die schwierigen Teile. Der größte Einzelhebel — siehe /docs/api/choosing-a-model.

Ausgearbeitetes Beispiel: eine „billig-zuerst“-Kaskade​

Kaskadierung ist der Hebel, den man überspringt, weil er vage klingt. Machen wir ihn konkret. Angenommen, du musst 100.000 Support-E-Mails triagieren. Der naive Ansatz schickt jede E-Mail durch dein stärkstes Modell. Eine Kaskade leitet den Großteil des Volumens an ein günstiges Modell und eskaliert nur die harten Fälle:

Nehmen wir an, das günstige Modell löst 90 % der Fälle allein und ein stärkeres Modell kostet etwa das 5-Fache pro Token. Rechnen wir in relativen Kosteneinheiten (1 = ein günstiger Durchgang über eine E-Mail):

  • Alles-stark: 100k × 5 = 500k Kosteneinheiten.
  • Kaskade: 100k × 1 (jede E-Mail bekommt den günstigen Durchgang) + 10k × 5 (die 10 %, die eskalieren) = 150k Kosteneinheiten.

Das ist etwa eine 70 %-Ersparnis, und die wirklich harten Fälle bekommen weiterhin dein bestes Modell. Die Multiplikatoren und die Aufteilung sind exemplarisch — setze deine eigenen Token-Zahlen und Preise ein und miss die echte Eskalationsrate mit Evals. Die Lehre gilt unabhängig: Die Ersparnis kommt daher, wie selten du den teuren Satz zahlst, nicht vom Satz selbst.

Latenzspezifische Gewinne​

Pro tip
  • Streame Antworten — Nutzer sehen die ersten Tokens sofort, die gefühlte Geschwindigkeit steigt sprunghaft, auch wenn die Gesamtzeit unverändert bleibt (/docs/api/streaming).
  • Parallelisiere unabhängige Teilaufrufe — eine Anfrage, die auf drei Tools verzweigt, endet in max(latency), nicht in sum(latency).
  • Cache wiederholte Arbeit und berechne vor, wo du kannst — die schnellsten Tokens sind die, die du nicht generieren musst.
  • Wähle ein kleineres Modell für den interaktiven Pfad; verschiebe schwere Arbeit asynchron, damit der Nutzer nicht darauf wartet.
  • Reduziere max_tokens für interaktive Endpunkte — lange Generierungen sind die dominante Quelle für Tail-Latenz.

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.

Selbstkontrolle

0/4
  1. Welcher Hebel ist MEISTENS der größte einzelne Kostenhebel?
  2. Woher kommt die Ersparnis in einer „billig-zuerst“-Kaskade tatsächlich?
  3. Du willst, dass sich eine Antwort für den Nutzer schneller anfühlt. Welcher Hebel hilft AM MEISTEN, ohne die Modellwahl zu ändern?
  4. Du hast Kosten gesenkt, indem du bei einem Workflow von Sonnet auf Haiku gewechselt bist. Was ist der nötige nächste Schritt?
Key takeaways
  • Das Dreieck ist real: Qualität, Kosten und Geschwindigkeit ziehen gegeneinander — Engineering heißt, jede Aufgabe an den richtigen Punkt zu leiten, nicht alle drei zu maximieren.
  • Das richtige Dimensionieren des Modells ist der größte Einzelhebel; Kaskaden multiplizieren ihn, indem du Flagship-Preise nur bei der harten Minderheit zahlst.
  • Prompt-Caching, straffe max_tokens und RAG-getriebenes Kürzen der Eingabe verstärken sich mit der Modellwahl.
  • Die Latenzwahrnehmung ist eine eigene Achse — Streaming, parallele Teilaufrufe und asynchrone Schwerarbeit formen die UX neu, ohne die reinen Kosten zu ändern.
  • Jede Kostensenkung muss durch Evals abgesichert werden — ein günstigeres Setup, das falsch ist, ist nicht günstiger.

Weiter​