Ökonomie, Modellwahl & Betriebsmodell

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.

Unit Economics — Kosten und Nutzen pro fachlicher Einheit, etwa pro gelöstem Ticket oder akzeptierter Extraktion — nicht nur pro Modellrequest.

Ein billiger Request kann teuer sein, wenn er oft wiederholt oder manuell korrigiert wird. Ein teureres Modell kann wirtschaftlicher sein, wenn es ein Qualitätsgate häufiger besteht. Rechne deshalb Kosten pro akzeptiertem Ergebnis: Modell- und Infrastrukturkosten plus Retrieval, Tool-Aufrufe, Retry, Review und Fehlerfolgen, geteilt durch nutzbare Ergebnisse. Nachteil: Diese Kennzahl braucht Ende-zu-Ende-Telemetrie; reine Provider-Rechnungen reichen nicht.

Kosten werden gemeinsam mit Qualität berichtet. Eine Einsparung von 40 Prozent ist bedeutungslos, wenn dadurch die Quote akzeptierter Ergebnisse stärker sinkt oder kritische Fehler zunehmen. Umgekehrt muss ein besseres Modell zeigen, welchen fachlichen Zusatznutzen der Aufpreis kauft. Stelle deshalb eine Pareto-Sicht aus Qualität, Latenz und Vollkosten her. Nachteil: Es gibt nicht mehr automatisch einen einzigen Testsieger; die Auswahl wird pro Fallklasse und SLO getroffen.

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

Tokenpreise sind anbieter- und modellspezifisch und ändern sich. Evergreen ist die Trennung der Mengen: Eingabetokens, Ausgabetokens, gegebenenfalls gecachte Präfixe und zusätzliche Aufrufe. Lange Ausgaben sind autoregressiv und belegen Decode-Zeit; ein kleines max_tokens begrenzt Kosten, kann aber Antworten abschneiden. Optimiere zuerst den gemessenen dominanten Anteil. Preis: Kürzere Kontexte oder Antworten können Qualität verlieren und müssen gegen das Eval-Gate laufen.

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.

Bei Multi-Turn-Anwendungen wird Historie häufig erneut als Eingabe verarbeitet. Zehn kurze Turns können daher mehr Tokens verbrauchen als eine einzelne lange Frage. Trenne stabilen Systemkontext, abrufbare Fakten, kompakten Gesprächszustand und rohe Historie. Prefix- oder KV-Caching kann wiederholte Präfixe beschleunigen, ist aber kein kostenloser semantischer Speicher und bindet an konkrete Serving-Eigenschaften.

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.

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.

TTFT — Time to First Token: Zeit vom Request bis zum ersten ausgegebenen Token. Sie ist von der gesamten Generierungsdauer und der Zeit zwischen Folgetokens zu unterscheiden.

Streaming verbessert die wahrgenommene Reaktionszeit, nicht zwingend die Gesamtzeit oder Rechenkosten. Ein langes Prefill durch großen Kontext erhöht TTFT; lange Ausgabe belastet Decode. Sarathi-Serve beschreibt diese unterschiedlichen Phasen und den Durchsatz-Latenz-Trade-off beim Batching. Miss p50 und Tail-Werte getrennt. Nachteil: Aggressives Batching erhöht Durchsatz, kann aber interaktive Tail-Latenz verschlechtern.

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.

Interaktive und asynchrone Last haben verschiedene Ziele. Chat braucht begrenzte TTFT und vorhersehbare Tail-Latenz. Nachtverarbeitung kann Requests sammeln, besser auslasten und länger warten. Lege getrennte Queues, Concurrency-Limits und Budgets fest. Ein gemeinsamer Pool ist einfacher, erlaubt aber, dass ein großer Batch den Nutzerpfad verdrängt. Preis der Trennung: Reservierte Kapazität kann in ruhigen Phasen ungenutzt bleiben.

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

Right-Sizing beginnt mit einem Qualitätsfloor auf dem eigenen Eval-Set. Unterhalb des Floors ist ein Modell ungeeignet, auch wenn es billig ist. Oberhalb vergleichst du Kosten, Latenz, Kontextbedarf, Ausgabestruktur und Betriebsrisiko. Routing kann einfache Fälle an ein kleineres Modell und schwierige an ein stärkeres senden. Hybrid-LLM-Forschung zeigt dieses Optimierungsprinzip; der Router selbst wird jedoch zu einem zusätzlichen Modell mit Fehlerrate.

Ein sicherer Router darf Hochrisikofälle nicht nur nach vermuteter Schwierigkeit herunterstufen. Risikoklasse, Datenregion oder Toolrechte sind harte Policy-Inputs. Nachteil: Routing spart im Mittel, vergrößert aber Matrix und Debuggingraum aus Router-, Modell- und Fallversionen.

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.

Wähle den Adaptionshebel nach Fehlerursache. Fehlende aktuelle Fakten sprechen für Retrieval oder Tool, unklare Aufgabe für Contract und Beispiele, stabile wiederkehrende Form möglicherweise für Fine-Tuning. Ein größeres Modell ist eine weitere Hypothese, keine Universalstufe. Jeder Hebel wird als Kandidat gegen dieselbe Baseline getestet. Preis: Ursachenorientierte Experimente dauern länger als ein spontaner Modellswitch, liefern aber eine übertragbare Entscheidung.

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.

Eine Migration verändert mehr als einen Namen: Tokenizer, Kontextgrenze, Systempromptverhalten, Tool-Auswahl, Ausgabeformat und Sicherheitsprofil können abweichen. Führe Shadow-Traffic oder Replay auf minimierten, zulässigen Testdaten aus, vergleiche kritische Fehlerklassen und plane Rollback. Pinne ein konkretes Modellartefakt oder eine Anbieterrevision, sofern verfügbar. Nachteil: Parallelbetrieb kostet doppelt und kann Datenschutzprüfung für zwei Pfade verlangen.

Auslastung schlägt Stückpreis

Der häufigste Rechenfehler: Man vergleicht den Preis pro Million Tokens mit den Stundenkosten einer GPU und übersieht die Auslastung. Eine API kostet nur, wenn sie genutzt wird. Eine reservierte GPU kostet rund um die Uhr — auch nachts, auch am Wochenende, auch wenn niemand fragt.

Bei stoßweiser interner Last — Bürozeiten, wenige hundert Anfragen am Tag — liegt die Auslastung typischerweise im niedrigen einstelligen Prozentbereich. Der Eigenbetrieb rechnet sich erst bei hoher, gleichmäßiger Grundlast oder wenn eine Auflage keine Alternative lässt.

Eigenbetrieb hat hohe Fixkosten in Hardware, Kapazität, Bereitschaft und Updates; eine API verwandelt vieles in variable Kosten und Lieferantenabhängigkeit. Die Break-even-Rechnung hängt von nutzbarer Auslastung, nicht nur vom theoretischen Tokendurchsatz ab. Spitzen, Redundanz und Wartung senken die produktive Quote eigener Hardware. Preis der API: Marge, Daten- und Vertragsprüfung sowie weniger Kontrolle über Serving. Preis des Eigenbetriebs: dauerhaftes SRE-Thema.

Die ehrliche Betriebslast

Wer selbst betreibt, betreibt auch: Hardwarebeschaffung mit Lieferzeiten, Treiber- und Laufzeitumgebung, Kapazitätsplanung, Lastspitzen, Aktualisierungen, Monitoring, Bereitschaft und die Modellpflege selbst. Das ist ein Plattformprodukt, kein Server.

• Verfügbarkeit ist eure Zusage — es gibt keine Anbieter-Statusseite mehr, hinter der man sich sammelt.
• Neue Modellgenerationen kommen nicht automatisch; Auswahl, Test und Migration sind eigene Arbeit.
• Kapazität ist endlich: Eine Lastspitze bedeutet Warteschlange statt automatischer Skalierung.
• Für den Einstieg ist die Zwischenform — offene Gewichte bei einem Hoster — oft die ehrlichere Antwort auf Datenanforderungen als ein eigener GPU-Betrieb.

Plane nicht mit Benchmark-Durchsatz allein. Berücksichtige reale Promptlängen, Outputverteilung, Quantisierung, Batchmix, p95-Latenz, Ausfälle und die Zeit für Treiber, Serving, Monitoring und Security-Fixes. Ein GPU-Pool, der für den Peak dimensioniert ist, kann im Mittel schlecht ausgelastet sein. Nachteil einer kleineren Reserve: Queue und Tail-Latenz steigen bei Lastspitzen; das muss zum fachlichen SLO passen.

Abhängigkeit und Ausstieg

Anbieterabhängigkeit ist real, aber sie sitzt selten dort, wo man sie vermutet. Der Aufruf selbst ist meist schnell umgestellt. Teuer sind die Dinge, die sich am Anbieter ausgerichtet haben: auf ein Modell hin getunte Prompts, Auswertungen ohne eigene Vergleichsbasis, Fachlogik in anbieterspezifischen Funktionen.

Der wirksamste Ausstiegsschutz ist deshalb kein Abstraktionsframework, sondern eine eigene Evaluationsbasis: Wer ein Testset mit Zielgrößen hat, kann jeden Kandidaten in Tagen bewerten. Wer keines hat, bleibt beim Anbieter, weil ein Wechsel unbewertbar wäre.

Exit-Fähigkeit bedeutet nicht, jeden Anbieter hinter die kleinste gemeinsame API zu verstecken. Definiere stattdessen eigene fachliche Contracts, exportierbare Prompts und Eval-Sets, Datenformate, Telemetrie und einen getesteten Ersatzpfad für kritische Funktionen. Anbieterfeatures dürfen bewusst genutzt werden, wenn ihr Nutzen den Wechselpreis rechtfertigt. Nachteil: Ein echter Exit-Test kostet; eine perfekte Abstraktion kostet jeden Tag und kann wertvolle Features blockieren.

Ein Exit-Runbook nennt Trigger, Datenexport, Ersatzendpunkt, kompatible Tool- und Output-Contracts, notwendige Re-Evaluation und Verantwortliche. Teste es in ruhiger Zeit mit einem begrenzten Traffic-Anteil. Eine bloße Liste alternativer Anbieter beweist keine Wechselbarkeit. Preis: Der Test verbraucht doppelte Integrations- und Eval-Kapazität. Er verwandelt Vendor-Risiko dafür von einer Folie in eine gemessene Wiederanlaufzeit.

Modelle sind vergänglich

Unabhängig vom Bezugsweg gilt: Modellversionen werden abgekündigt oder verlieren Unterstützung. Migrationsfähigkeit ist deshalb keine Kür, sondern eine Betriebsanforderung — dieselbe Kategorie wie das Aktualisieren einer Datenbankversion.

• Modellname und Version als Konfiguration führen, nicht im Code verstreuen.
• Testset und Zielgröße vorhalten, damit ein Wechsel bewertbar ist.
• Ein Zeitfenster für Migrationen einplanen, statt auf die Abkündigungsfrist zu warten.
• Bei Eigenbetrieb dasselbe: Auch selbst gehostete Gewichte veralten, nur ohne Anbieter, der dich erinnert.

Modelle und Endpunkte werden abgekündigt oder verändert. Ein Inventar verbindet Anwendung, Modellkennung, Eigentümer, Datenklasse, Eval-Gate, Ablaufdatum und Ersatzkandidat. Degradation wird geplant: Queue, kleineres Modell, eingeschränkter Funktionsumfang oder manueller Prozess. „Provider ist down“ darf nicht automatisch unkontrollierten Fallback auf ein ungeprüftes Modell bedeuten.

Gleich im Check entscheidest du deshalb nicht nach einem einzelnen Listenpreis. Du ordnest Kostenanteile, Latenzphase, Lastklasse, Qualitätsfloor, Routing, Migration, Auslastung und Exit-Fähigkeit zu einem Betriebsmodell. Jede Ersparnis wird gegen ihren Preis geprüft: weniger Qualität, höhere Tail-Latenz, mehr Plattformarbeit oder stärkere Abhängigkeit.