Ökonomie & Modellwahl — die Ressourcen-Entscheidungen
Einführung · 9 Abschnitte · ~8 Min Lesezeit · Stand
Warum die Ressourcen-Sicht?
In Produktion optimierst du drei Ziele: Kosten, Latenz und Qualität. Welcher Hebel trägt, entscheidet nicht eine allgemeine Rangliste, sondern eure gemessene Last, das Qualitätsziel und die konkrete Anbieter- oder Deployment-Konfiguration.
Technisch verarbeitet der Prefill viele Positionen der Eingabe weitgehend parallel; der autoregressive Decode erzeugt Ausgabepositionen nacheinander. Das prägt Rechen- und Latenzprofile, legt aber weder Preise noch Modellrangfolgen fest.
Token-Ökonomie: Input ist nicht Output
Eine Kostenrechnung multipliziert gemessene Mengen mit den Sätzen des gewählten Anbieters, Modells oder eigenen Deployments. Input, Output, Cache-Nutzung und weitere Rechenanteile können unterschiedlich abgerechnet werden; aus Prefill und Decode folgt keine universelle Preisrelation.
Wenn die Abrechnung zeigt, dass lange Antworten den größten Kostenanteil verursachen, ist Output-Kürzung der erste Kandidat. Dominiert dagegen ein großer Kontext, setzt du dort an. Die sequenzielle Ausgabe macht die Antwortlänge zusätzlich zu einem Latenzhebel — wie stark, muss die Ende-zu-Ende-Messung zeigen.
| Input (Prompt, Kontext, Historie) | Menge × anbieter-/deploymentabhängiger Satz; Prefill weitgehend parallel |
|---|---|
| Output (erzeugte Antwort) | Menge × anbieter-/deploymentabhängiger Satz; Decode autoregressiv und sequenziell |
Multi-Turn: der Verlauf wächst mit
Bei einer stateless Integration, die bei jedem Aufruf die vollständige Historie mitsendet und keinen serverseitigen Gesprächszustand nutzt, wächst der Input pro Zug mit dem Verlauf. Das ist eine Eigenschaft dieser Integration — nicht aller APIs oder Betriebsformen.
Sind die Züge ungefähr gleich lang, wird die Historie immer vollständig erneut gesendet und greift kein Cache, summiert sich der wiederholte Input grob quadratisch mit der Zugzahl. Fenster und Summary ändern die Menge; unterstütztes Caching kann Wiederverarbeitung oder Abrechnung des stabilen Präfixes verändern.
- Verlauf kürzen — nur aufgabenrelevante Züge oder ein begrenztes Fenster mitsenden.
- Zusammenfassen — ältere Züge verdichten und den Informationsverlust im Eval prüfen.
- Prefix-/Prompt-Caching — wiederholte Präfixe nur dann wiederverwenden, wenn Anbieter oder eigenes Deployment dies unterstützt; Wirkung und Abrechnung messen.
Latenz: TTFT, Gesamtzeit und Streaming
Time-to-First-Token (TTFT) misst aus Sicht des gewählten Messpunkts bis zum ersten Token. Clientseitig können darin Netzwerk, Queueing, Vorverarbeitung, Retrieval oder Tool-Schritte und Prefill stecken. Die Gesamtzeit umfasst zusätzlich Decode und spätere Pipeline-Schritte. Deshalb beide Größen am relevanten Systemrand instrumentieren.
- Client sendet Request
- Netzwerk, Queue und Vorverarbeitung
- Prefill → erstes Token
- Decode und weitere Schritte
- vollständige Antwort
Streaming kann den ersten sichtbaren Fortschritt vor die vollständige Antwort ziehen. Ob Nutzer das als schneller oder hilfreicher erleben, ist eine testbare UX-Hypothese. Streaming verkürzt weder automatisch die Gesamtzeit noch erhöht es automatisch den Durchsatz.
Interaktiv vs. Batch: der richtige Pfad
Interaktive Last hat ein Nutzer-Latenzbudget; nicht-interaktive Massenarbeit hat meist ein Fertigstellungsfenster. Teilt beides denselben synchronen Pfad, konkurrieren Requests um Threads, Queues, Quoten und Serving-Kapazität.
Eine Queue, ein Worker-Pool oder eine unterstützte Batch-Schnittstelle entkoppelt die Lasten. Batching kann Auslastung verbessern und je nach Anbieter oder eigenem Deployment eine andere Kostenstruktur haben; ein Preisvorteil ist aber keine Universalität. Auch Modellgröße allein sagt weder Tempo noch Kosten voraus.
Right-Sizing und Routing: Qualität ist die Schranke
Beim Right-Sizing gewinnt das kleinste Kandidatenmodell, das definierte Qualitäts- und Zuverlässigkeitsschwellen in einem repräsentativen, gelabelten Eval erfüllt. Ein kleines Modell kann genügen; Größe allein beweist weder Qualität noch Latenz oder Kosten.
Bei heterogener Last kann Capability-Routing einfache Fälle an einen ressourcenärmeren Kandidaten und schwierige Fälle an einen stärkeren Kandidaten geben. Das lohnt nur, wenn eine extern gelabelte, kalibrierte Qualitätsprognose die Zielqualität im Eval hält. Rohe Selbstconfidence des antwortenden Modells ist kein unabhängiges Routing-Signal.
| Ein Modell für alles | Einfacher Betrieb; akzeptabel, wenn es die Schwelle zu tragbaren Kosten erfüllt |
|---|---|
| Routing | Zusätzlicher Router und Fallback; nur bei validiertem Qualitäts-/Kostenvorteil |
| Mittelgroßer Kompromiss | Faire Option, wenn er selbst die Schwelle erfüllt — sonst keine automatische Lösung |
Adaption: Ursache statt Universal-Leiter
Prompting, Retrieval und Fine-Tuning sind keine universell sortierte Kostenleiter. Zuerst diagnostizierst du die Eval-Lücke; dann vergleichst du Kandidaten am Qualitätsziel sowie an Einführungs- und Betriebskosten. Beginne mit dem kleinsten reversiblen Experiment, das die vermutete Ursache prüft.
| Prompt, Beispiele, Schema | Kandidat bei unklarer Anweisung, fehlenden Demonstrationen oder Ausgabegrenzen |
|---|---|
| RAG / Retrieval | Kandidat für dynamisches Wissen oder einen großen, variablen Bestand an Fakten und Beispielen |
| Fine-Tuning | Kandidat für wiederkehrendes Zielverhalten, wenn Nutzen, Trainingsdaten, Eval und Modell-Lifecycle den Zusatzaufwand rechtfertigen |
Veränderliche Fakten gehören nicht als alleinige Aktualisierungsstrategie ins Fine-Tuning. Bleibt eine gemessene Verhaltenslücke nach kleineren Experimenten bestehen, kann Fine-Tuning sinnvoll sein — mit eigenem Daten-, Evaluations- und Betriebszyklus.
Modell-Migration: nicht blind tauschen
Öffentliche Benchmarks und Kostenprognosen sind Kandidatensignale, keine Freigabe. Für die Basismodell- und Pipeline-Wahl vergleichst du Alt und Neu auf einem repräsentativen, gelabelten Eval mit euren Qualitäts-, Zuverlässigkeits-, Latenz- und Kostenzielen.
Diese Achse endet bei der Entscheidung über Basismodell und Pipeline. Fällt sie positiv aus, prüft der Prompt-Track anschließend Portabilität und gezieltes Re-Tuning des Prompts. So vermischst du die Modellwahl nicht vorab mit einer zweiten Änderung.
Gleich im Check
Du entscheidest gleich alle acht Achsen: gemessener Input-/Output-Kostenanteil, vollständig mitgesendete Chat-Historie, TTFT und Streaming, Batch vs. interaktiv, Right-Sizing, validiertes Capability-Routing, ursachengerechte Adaption und Basismodell-/Pipeline-Migration.