Inferenz-Laufzeit & Eigenbetrieb
Der Pod läuft, doch das Modell ist noch nicht geladen; wenig später füllt der KV-Cache und die Queue wächst trotz freier Recheneinheiten. Wer Inferenz selbst betreibt, muss andere Engpässe und Bereitschaftssignale beherrschen als bei einem gewöhnlichen HTTP-Dienst.
Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04
Zwei Phasen mit gegensätzlichem Verhalten
Ein Generierungsaufruf zerfällt in zwei Phasen. In der Prefill-Phase wird der gesamte Eingabekontext verarbeitet — viel Rechenarbeit auf einmal, gut parallelisierbar. In der Decode-Phase entsteht Token für Token die Ausgabe; jeder Schritt hängt vom vorigen ab und ist im Wesentlichen durch Speicherzugriffe begrenzt, nicht durch Rechenleistung. Die Laufzeit macht diese Grenzen über Größen wie max_num_seqs, KV-Cache-Belegung und eine echte readinessProbe steuerbar.
Daraus folgen die zwei wichtigsten Betriebsregeln dieses Moduls: Lange Eingaben kosten vor allem Zeit vor dem ersten Token. Lange Ausgaben kosten Zeit pro Token und binden dabei durchgehend Speicher und einen Platz im Server.
Betriebsprobe: SELFHOST-TRADEOFF
Szenario
Ein internes Feature nutzt eine Anbieter-API. Die Last ist stark schwankend: werktags mittags eine kurze Spitze, sonst nahe null. Die Monatsrechnung ist niedrig, aber sichtbar. Ein Team schlägt Eigenbetrieb vor: „Dann zahlen wir nur die Hardware, das ist auf Dauer billiger.“ Datenschutzanforderungen bestehen nicht über das übliche Maß hinaus.
Anforderungen
- Wie bewertest du den Vorschlag?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Ablehnen: Bei schwankender, überwiegend niedriger Last zahlt eine eigene Beschleuniger-Flotte die Leerlaufzeit mit, und der Betriebsaufwand kommt obendrauf — ohne Kontroll- oder Datenanforderung fehlt der zweite Grund. Richtig. Eigenbetrieb rechnet sich über hohe, gleichmäßige Auslastung oder über Kontroll- und Datenanforderungen. Hier fehlt beides; das Nutzungsprofil ist genau das, wofür nutzungsabhängige Abrechnung existiert.
- Plausibler Fehlweg: Zustimmen: Auf mehrere Jahre gerechnet ist eigene Hardware fast immer günstiger als nutzungsabhängige Abrechnung. Das gilt nur bei hoher Auslastung. Bei nahe null in den meisten Stunden bezahlt ihr fast durchgehend ungenutzte Beschleuniger — die Rechnung dreht sich um.
- Plausibler Fehlweg: Zustimmen, aber die Flotte nachts auf null skalieren, dann entstehen keine Leerlaufkosten. Beim Skalieren auf null trifft die Mittagsspitze auf kalte Instanzen mit langer Ladezeit für die Gewichte — genau dann, wenn die Last kommt. Es tauscht Kosten gegen ein Verfügbarkeitsproblem.
- Plausibler Fehlweg: Zustimmen, weil Eigenbetrieb das Anbieterrisiko beseitigt. Es verlagert das Risiko nur: An die Stelle der Anbieterverfügbarkeit treten eigene Hardware, Treiber, Kapazität und Bereitschaftsdienst — bei kleinem Team meist das größere Risiko, nicht das kleinere.
Merksatz: Die Entscheidung zwischen Eigenbetrieb und fremdem Dienst hängt am Auslastungsprofil und am Kontrollbedarf, nicht am Stückpreis. Feste Kosten gewinnen bei hoher, gleichmäßiger Nutzung — variable Kosten bei schwankender. + Kein Aufbau einer Betriebsfähigkeit, die kein fachliches Ziel trägt; das Team bleibt bei seinem Produkt. − Ihr bleibt von Preis-, Quoten- und Abkündigungsentscheidungen des Anbieters abhängig und braucht dafür Pinning, Beobachtung und einen Wechselplan.
Batching: warum Durchsatz und Latenz gegeneinander stehen
Ein Inferenz-Server verarbeitet mehrere Anfragen gemeinsam, weil die Hardware bei einer einzelnen Anfrage schlecht ausgelastet ist. Statisches Batching wartet, bis genug Anfragen zusammengekommen sind — das erhöht den Durchsatz und verschlechtert die Latenz der ersten wartenden Anfrage. Moderne Server arbeiten stattdessen kontinuierlich: fertige Sequenzen verlassen den Batch, neue rücken nach, ohne dass alle auf die längste warten.
- Größerer Batch
- Mehr Durchsatz pro Beschleuniger, höhere und streuende Einzel-Latenz.
- Kleinerer Batch
- Niedrigere Latenz, schlechtere Auslastung und höhere Kosten pro Anfrage.
- Kontinuierliches Nachrücken
- Vermeidet, dass kurze Anfragen auf die längste im Batch warten.
Betriebsprobe: WEIGHT-ARTIFACT
Szenario
Eure Inferenz-Instanzen laden die Modellgewichte beim Start direkt aus einem öffentlichen Repository, referenziert über einen beweglichen Zweignamen. Zweimal ist der Start bereits fehlgeschlagen, weil die externe Quelle nicht erreichbar war. Zusätzlich fiel auf, dass zwei Instanzen unterschiedlich alte Gewichte geladen hatten.
Anforderungen
- Wie stellst du den Bezug der Gewichte um?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Die Gewichte einmal in einen eigenen Speicher unter eurer Kontrolle spiegeln, über eine feste Version mit geprüftem Hash referenzieren und die geladene Version in der Telemetrie führen. Richtig. Das entkoppelt den Start von fremder Verfügbarkeit, macht alle Instanzen identisch und erlaubt, eine Antwort einer konkreten Gewichtsversion zuzuordnen — dieselben Anforderungen wie an jedes andere Release-Artefakt.
- Plausibler Fehlweg: Die Gewichte im Container-Image mitliefern — als einheitlicher Flottenstandard über alle Modellgrößen und Lastprofile hinweg ausgerollt und bei jedem Runtime-Upgrade unverändert als alleinige Kapazitätsregel übernommen. Löst Verfügbarkeit und Festlegung, koppelt aber Gewichte und Anwendungscode zu einem einzigen, sehr großen Artefakt: Jeder Code-Fix erzwingt dann das erneute Ausrollen mehrerer Gigabyte, und der Modellwechsel wird an den Code-Release-Zyklus gekettet.
- Plausibler Fehlweg: Eine Wiederholung mit Wartezeit beim Start einbauen, falls die externe Quelle nicht antwortet. Das behandelt nur die Verfügbarkeitsseite und macht den Start langsamer. Die unterschiedlichen Versionen zwischen Instanzen — die gefährlichere Beobachtung — bleiben, weil der bewegliche Zweigname bestehen bleibt.
- Plausibler Fehlweg: Die Gewichte auf ein geteiltes Netzlaufwerk legen, das alle Instanzen einhängen. Bequem, aber es macht den Speicher zum gemeinsamen Ausfallpunkt im Startpfad und liefert weiterhin keine Version, keinen Hash und keinen Rückweg auf einen früheren Stand.
Merksatz: Alles, was die Ausgabe bestimmt, braucht eine unveränderliche Version, eine kontrollierte Bezugsquelle und eine Integritätsprüfung. Ein beweglicher Verweis auf eine fremde Quelle erfüllt keine dieser drei Bedingungen. + Reproduzierbare Starts, identische Instanzen, zuordenbare Antworten und ein möglicher Rückweg. − Ihr betreibt einen eigenen Artefaktspeicher und müsst Aktualisierungen aktiv nachziehen — Sicherheits- oder Qualitätsverbesserungen der Quelle kommen nicht mehr von allein an.
Der Aufmerksamkeits-Cache ist deine eigentliche Kapazitätsgrenze
Während der Decode-Phase hält der Server für jede laufende Sequenz Zwischenergebnisse vorheriger Token im Speicher (üblich: KV-Cache). Dieser Speicher wächst mit der Kontextlänge und mit der Zahl gleichzeitiger Sequenzen. In der Praxis ist damit nicht die Rechenleistung, sondern der Beschleuniger-Speicher die Grenze für die Nebenläufigkeit.
Betrieblich heißt das: Die maximale Zahl paralleler Anfragen ist keine frei wählbare Konfigurationszahl, sondern folgt aus Kontextlänge mal Nebenläufigkeit. Steigt die durchschnittliche Kontextlänge — etwa weil das Retrieval mehr Passagen liefert — sinkt die mögliche Nebenläufigkeit, ohne dass jemand eine Einstellung geändert hat.
Betriebsprobe: WARMUP-COLDSTART
Szenario
Ein selbst gehostetes Modell skaliert nachts auf null, um Kosten zu sparen. Jeden Morgen zur ersten Nutzungswelle laufen mehrere Minuten lang Anfragen in Fehler, bis Instanzen bereit sind — das Laden der Gewichte dauert deutlich länger als ein üblicher Container-Start. Die Lastkurve ist über Wochen stabil und gut vorhersagbar.
Anforderungen
- Wie gehst du mit dem morgendlichen Ausfallfenster um?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Vor der bekannten Welle geplant hochfahren und eine Mindest-Grundkapazität halten, statt rein reaktiv auf eintreffende Last zu skalieren. Richtig. Wenn die Bereitstellungszeit über der Reaktionszeit liegt, muss die Kapazität vor der Nachfrage da sein — bei vorhersagbarer Last ist das planbar und billiger als eine dauerhafte Überprovisionierung.
- Plausibler Fehlweg: Den Autoscaler empfindlicher einstellen, damit er schneller reagiert — als einheitlicher Flottenstandard über alle Modellgrößen und Lastprofile hinweg ausgerollt. Die Verzögerung liegt nicht in der Erkennung, sondern im Laden der Gewichte. Ein empfindlicherer Auslöser startet nur früher einen gleich langen Startvorgang — und neigt zusätzlich zum Pendeln.
- Plausibler Fehlweg: Die fehlgeschlagenen Anfragen im Client aggressiv wiederholen, bis der Dienst antwortet. Das legt eine Retry-Welle auf die gerade startenden Instanzen — die erste bereite Instanz wird sofort überrollt. Retries brauchen mindestens Backoff und Jitter, lösen die fehlende Kapazität aber ohnehin nicht.
- Plausibler Fehlweg: Rund um die Uhr die volle Tageskapazität vorhalten. Das beseitigt das Problem, zahlt aber die teuerste Rechnung: Nachts steht die gesamte Beschleuniger-Kapazität ungenutzt. Bei vorhersagbarer Last ist geplante Vorwärmung die deutlich günstigere Antwort.
Merksatz: Reaktives Skalieren funktioniert nur, wenn neue Kapazität schneller bereitsteht, als die Nachfrage steigt. Ist die Bereitstellungszeit lang, wird Kapazitätsplanung zur Vorhersage — nicht zur Regelung. + Die Welle wird ohne Fehlerfenster bedient, ohne dauerhaft zu überprovisionieren. − Ein Zeitplan ist eine Annahme über die Zukunft: Eine unerwartete Spitze außerhalb des Fensters trifft weiterhin auf kalte Kapazität und braucht zusätzlich Queue und Degradation.
Nebenläufigkeitsgrenze und Warteschlange
Ohne ausdrückliche Obergrenze nimmt ein Dienst unter Last mehr Arbeit an, als er sinnvoll bearbeiten kann. Das Ergebnis ist keine faire Verlangsamung, sondern eine Sättigung, in der alle Anfragen zu spät kommen und ein wachsender Anteil ohnehin schon abgelaufen ist.
Deshalb gehört zu jedem Inferenz-Pfad eine explizite Nebenläufigkeitsgrenze plus eine begrenzte Queue mit Alter-Prüfung: Was länger wartet, als der Aufrufer noch akzeptiert, sollte gar nicht erst ausgeführt werden.
Betriebsprobe: BATCHING-THROUGHPUT
Szenario
Ihr betreibt einen eigenen Inferenz-Server für zwei Arbeitsklassen auf derselben Flotte: interaktive Chat-Anfragen mit strengem TTFT-Ziel und eine nächtliche Massenklassifikation, die nur ein Tagesfenster einhalten muss. Um die teure Hardware auszulasten, wurde die Batch-Größe global erhöht. Seitdem verfehlt der Chat sein TTFT-Ziel, die Auslastung ist gut.
Anforderungen
- Wie löst du den Konflikt?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Die Arbeitsklassen trennen — eigene Warteschlangen beziehungsweise Instanzen mit latenzorientierter Konfiguration für den Chat und durchsatzorientierter für die Massenlast. Richtig. Die beiden Klassen wollen dieselbe Stellschraube in entgegengesetzte Richtungen. Eine gemeinsame Einstellung kann nur eine von beiden bedienen; die Trennung macht die Entscheidung pro Klasse statt global.
- Plausibler Fehlweg: Die Batch-Größe global wieder senken, bis der Chat sein Ziel hält. Damit bezahlt die Massenlast die Latenzanforderung des Chats mit Auslastung und Kosten, obwohl sie gar kein Latenzziel hat. Die globale Einstellung bleibt der Fehler.
- Plausibler Fehlweg: Mehr Instanzen hinzufügen und die Batch-Größe hoch lassen. Zusätzliche Kapazität verkürzt die Wartezeit auf einen Platz, ändert aber nichts daran, dass eine große Batch-Konfiguration die Latenz innerhalb der Ausführung anhebt — du kaufst Hardware gegen ein Konfigurationsproblem.
- Plausibler Fehlweg: Für den Chat ein Timeout setzen und bei Überschreitung auf ein kleineres Modell ausweichen. Das ist eine Degradationsstrategie für den Störfall, kein Fix für einen dauerhaft falsch konfigurierten Normalbetrieb — der Chat liefe dann regelhaft auf dem Notpfad und verlöre Qualität ohne Not.
Merksatz: Batch-Größe ist ein Tausch von Latenz gegen Durchsatz. Sobald Arbeitsklassen mit gegensätzlichen Zielen dieselbe Stellschraube teilen, ist die richtige Antwort Isolation, nicht ein Kompromisswert. + Jede Klasse bekommt die Konfiguration, die zu ihrem Ziel passt. − Getrennte Pools kosten Verwaltungsaufwand und lassen im Zweifel Kapazität ungenutzt, weil sie nicht mehr frei zwischen den Klassen wandert.
Startzeiten: Gewichte sind groß
Eine neue Inferenz-Instanz ist nicht sofort nutzbar: Gewichte müssen geladen und in den Beschleuniger-Speicher gebracht werden, dazu kommen Aufwärmeffekte. Diese Startdauer liegt typischerweise um Größenordnungen über der eines gewöhnlichen Anwendungscontainers.
Betriebliche Folge: Reaktives Autoscaling auf einen Lastsprung kommt zu spät. Wer Lastspitzen bedienen will, braucht Vorhaltekapazität, vorgewärmte Instanzen oder eine Queue, die die Zeit bis zur Bereitstellung überbrückt — und muss akzeptieren, dass „Skalierung auf null“ die erste Anfrage teuer macht.
Was davon gilt bei einer fremden API?
Nutzt du eine gehostete Anbieter-API, gehören Batching, Cache-Verwaltung und Nebenläufigkeit dem Anbieter. Du siehst die Effekte trotzdem — als schwankende Latenz unter fremder Last und als harte Quotengrenze.
- Was dir bleibt: Eingabelänge, Ausgabelänge, eigene Nebenläufigkeitsgrenze, Queue, Timeouts, Retry-Verhalten und Arbeitsklassen.
- Was dir nicht bleibt: Batch-Größe, Cache-Politik und Auslastung des fremden Servers.
- Was du daraus folgerst: Behandle die Anbieterkapazität wie eine externe Abhängigkeit mit eigenem Ausfall- und Sättigungsverhalten, nicht wie eine unendliche Ressource.
Die ehrliche Ausgangsfrage
Selbst hosten heißt: Du tauschst eine Rechnung gegen Verantwortung. Sinnvolle Gründe dafür sind Datenaufenthalt und Vertraulichkeit, planbare Kosten bei hoher, gleichmäßiger Last, Unabhängigkeit von Anbieter-Abkündigungen und die Möglichkeit, das Modell selbst anzupassen. Kein Grund ist „billiger“ als pauschale Annahme — bei schwankender oder niedriger Auslastung ist eine eigene Beschleuniger-Flotte in der Regel teurer, weil sie auch im Leerlauf bezahlt wird.
- Du übernimmst
- Hardware und Treiber, Gewichte als Artefakt, Laufzeit-Upgrades, Kapazität, Verfügbarkeit, Sicherheitsaktualisierungen.
- Du gewinnst
- Kontrolle über Daten, Version, Zeitpunkt und Konfiguration; keine fremde Quote.
- Du verlierst
- Elastizität und die Möglichkeit, Betriebsprobleme an einen Anbieter zu delegieren.
Gewichte sind ein Artefakt, kein Download
Modellgewichte sind große, unveränderliche Binärdateien — betrieblich verhalten sie sich wie Container-Images, nicht wie Konfiguration. Daraus folgen dieselben Anforderungen: eine Registry oder ein Objektspeicher unter eigener Kontrolle, eine feste Version, ein überprüfbarer Hash und ein reproduzierbarer Bezugsweg.
- Aus einer eigenen Quelle beziehen, nicht bei jedem Start aus dem öffentlichen Internet — sonst hängt dein Start an einer fremden Verfügbarkeit.
- Integrität prüfen: Ein Gewichtsartefakt ist ausführbarer Einfluss auf dein Produkt und gehört in die Lieferkettenbetrachtung.
- Version und Herkunft in der Telemetrie führen, damit Antworten einer konkreten Gewichtsversion zuordenbar bleiben.
- Lizenz- und Nutzungsbedingungen prüfen: Sie sind bei offenen Gewichten unterschiedlich und nicht automatisch uneingeschränkt.
Beschleuniger sind eine besondere Ressource
Beschleuniger unterscheiden sich in drei Punkten von gewöhnlicher Rechenkapazität: Sie sind knapp und teuer, sie sind meist nicht sinnvoll überbuchbar, und sie brauchen eine Treiber- und Laufzeitumgebung, die zur Hardware passen muss. Ein Knoten kann deshalb technisch gesund und trotzdem für dein Modell unbrauchbar sein.
Betrieblich heißt das: Planung muss die Beschleuniger explizit als Ressource kennen, ein Modell darf nur auf passende Knoten kommen, und die Bereitschaftsprüfung eines Dienstes muss die Modellbereitschaft einschließen — nicht nur, dass der Prozess einen Port geöffnet hat. Sonst schickt der Lastverteiler Verkehr auf eine Instanz, die die Gewichte noch lädt.
Laufzeit-Upgrades: zwei Achsen, die man trennen muss
Im Eigenbetrieb ändern sich zwei Dinge unabhängig voneinander: die Gewichte und die Inferenz-Laufzeit samt Treibern. Beide können die Ausgabe verändern — die Laufzeit etwa über andere numerische Details, geänderte Standardparameter oder eine andere Umsetzung der Dekodierung.
Wer beide gleichzeitig anfasst, kann eine Qualitätsänderung nicht mehr zuordnen — und muss im Zweifel beides zurückrollen. Dass die Laufzeit die Ausgabe überhaupt beeinflussen kann, ist der Punkt, den Teams am häufigsten übersehen: Ein Treiber-Update ist im Eigenbetrieb kein reines Infrastruktur-Ereignis.
Verfügbarkeit ohne Elastizität
Bei einer fremden API ist Kapazität eine Quote; im Eigenbetrieb ist sie ein Stapel Hardware. Fällt ein Knoten aus, ist die Kapazität weg, bis Ersatz da ist — und Ersatz für Beschleuniger ist selten sofort verfügbar. Verfügbarkeitsplanung heißt hier: genug Knoten, um den Ausfall eines Teils zu tragen, sinnvolle Verteilung über Ausfalldomänen, und ein vorbereiteter Degradationspfad.
Ein besonders nützlicher Degradationspfad ist eine Ausweichmöglichkeit auf eine externe API für den Notfall — sie kehrt die übliche Richtung um und macht den Eigenbetrieb weniger spröde. Der Preis ist, dass du beide Wege qualitativ und rechtlich abgesichert haben musst, sonst ist der Notfallpfad im Ernstfall nicht benutzbar.
Was die Checks prüfen
- Wann Eigenbetrieb die begründete Wahl ist — und wann nicht
- Wie Gewichte als versioniertes, überprüfbares Artefakt betrieben werden
- Warum Bereitschaftsprüfungen die Modellbereitschaft abdecken müssen
- Wie du Laufzeit- und Modell-Änderungen trennst
Jetzt anwenden
Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.
Zum Modul →