Der vLLM- und Triton-Stack von Netflix: 7 Produktionslektionen
Die virale Version der Geschichte ist simpel: Netflix bezahle keinen KI-Anbieter mehr und habe alles selbst gebaut. Die nützliche Version ist präziser. Die AI-Platform-Teams von Netflix beschrieben einen internen LLM-Serving-Pfad mit NVIDIA Triton und vLLM. Sie erklären, warum er zu ihren Workloads passt, wo er unter Produktionslast brach und was sie rundherum ergänzen mussten.
Diese Abgrenzung zählt, wenn du eine Inferenzarchitektur auswählst. Wer nur die Komponenten kopiert, bekommt Software. Wer die Entscheidungsgrenzen kopiert, bekommt ein Betriebsmodell. Dieser Artikel konzentriert sich auf diese Grenzen. Kosten, EU-Datenresidenz und den allgemeinen Break-even besitzt weiterhin unser Leitfaden dazu, wann sich LLM-Self-Hosting in der EU rechnet.
Nutzt Netflix OpenAI?
Die Aussage, Netflix nutze OpenAI nie, ist nicht haltbar. In einem anderen Netflix-System namens MediaFM verwendete das Team OpenAIs text-embedding-3-large für Untertitel und Titelmetadaten. Der In-House-Artikel belegt einen internen vLLM- und Triton-Pfad für ausgewählte Workloads. Er belegt kein unternehmensweites Verbot von Hosted Models.
Die Käuferlektion ist stärker als der absolute Claim: Eine reife KI-Landschaft darf verschiedene Inferenzwege für verschiedene Aufgaben verwenden. Hosted APIs passen zu schnellen Experimenten oder teuer reproduzierbaren Fähigkeiten. Internes Serving passt zu eigenen Modellen, proprietären Decoding-Regeln, planbarer Last oder engerer Kontrolle. Die Workload-Grenze entscheidet, nicht ein Slogan für das ganze Unternehmen.
Wie ist die LLM-Serving-Architektur von Netflix aufgebaut?
Das öffentliche Design hat vier Ebenen. Bestehende Anwendungen rufen ein einheitliches JVM-Serving-System über gRPC auf. Dort bleiben Routing, A/B-Zuteilung, Feature Fetching sowie Vor- und Nachverarbeitung. Große Modelle werden an den Model Scoring Service delegiert, das gemeinsame Inferenz-Backend von Netflix. Darunter verwaltet NVIDIA Triton Model Loading und GPU-Ausführung. vLLM ist der bevorzugte Engine-Pfad für LLM-Workloads.
- Consumer-Vertrag: Bestehende Services verwenden dieselbe Scoring-Abstraktion für klassisches ML und LLMs.
- Serving-Workflow: Routing, Experimente und Datenvorbereitung bleiben außerhalb der Inferenz-Engine.
- Control Plane: Deployments, Health, Autoscaling, Modellversionen und Multi-Region-Rollouts bleiben Plattformaufgaben.
- Inference Plane: Triton hostet die Backends, vLLM übernimmt Scheduling, Batching und Decoding.
Neuere LLM-Anwendungen können zusätzlich ein OpenAI-kompatibles HTTP-Frontend verwenden. Das ist eine Protokollentscheidung und kein Beleg für ein bei OpenAI gehostetes Modell. Wenn du Protokoll und Anbieter trennst, behalten Aufrufer ihren vertrauten Client, während die Plattform die Engine dahinter austauscht.
Warum wählte Netflix vLLM statt TensorRT-LLM?
Netflix startete mit TensorRT-LLM. Bis Sommer 2025 hatte sich die Performance-Lücke für den eigenen Workload-Mix laut Team weitgehend geschlossen. Damit wurde der operative Fit entscheidend. vLLM lud eigene Architekturen ohne den früheren mehrstufigen Compile-Pfad, bot Hooks für Custom Decoding, machte Zwischenzustände leichter sichtbar und war den ML-Researchern bereits vertraut.
| Entscheidungsfaktor | Warum er zählte | Frage an dein Team |
|---|---|---|
| Änderungsrate der Architektur | Eigene Modelle erreichten Serving ohne getrennten kompilierten Artefakt-Workflow | Wie oft ändern sich Modellformen oder eigene Layer? |
| Debuggability | Engine-Zustand und Fehler waren für Praktiker leichter prüfbar | Wer diagnostiziert um 02:00 Uhr einen fehlgeschlagenen Load? |
| Decoding-Erweiterung | Eigene Logits-Verarbeitung war zentral für die Constraints | Brauchst du Regeln jenseits einer üblichen Structured-Output-API? |
| Teamwissen | Researcher kannten vLLM bereits | Können Modellautoren Produktionsverhalten vor dem Handover reproduzieren? |
| Spitzen-Benchmark | Wichtig, aber isoliert nicht mehr entscheidend | Passt der Benchmark zu Modellen, Batch-Größen und Constraints? |
Das ist kein ewiges Urteil über vLLM gegen TensorRT-LLM. Beide Projekte entwickeln sich weiter. Es ist eine wiederholbare Auswahlmethode: Benchmarke deinen echten Workload und bepreise danach den Engineering-Pfad zwischen Research, Deployment, Debugging und Rollback. Ein paar zusätzliche Tokens pro Sekunde gleichen keine Plattform aus, die dein Team nicht sicher ändern kann.
Warum traf Constrained Decoding auf den Python GIL?
Constrained Decoding verhindert ungültige Tokens bereits während der Generierung, statt fehlerhafte Ausgaben danach zu validieren. Netflix modellierte jeden Constraint als Zustandsmaschine, die bei jedem Schritt eine Maske erlaubter Tokens erzeugte. In vLLM V0 lief der eigene Python-Prozessor pro Request. Die GPU erzeugte Logits für den ganzen Batch, danach bearbeitete die CPU die Constraints der Requests nacheinander. Mit der Batch-Größe stieg die CPU-Zeit, weil der Python Global Interpreter Lock den parallelen Hot Path verhinderte.
vLLM V1 bot ein Batch-Level-Modell. Netflix stellte den Prozessor auf Batch-Datenstrukturen um und verschob den Hot Path in multi-threaded C++. Auch die aktuelle vLLM-Dokumentation definiert ein Batch-Level-Interface für Logits Processors, dessen apply-Methode den Logits-Tensor des Batches erhält.
Die Komplexität verschwand nicht. Dynamische Batches brauchen explizite State Updates. Chunked Prefills können mehrere Engine-Schritte dauern. Unter Speicherdruck kann Preemption den KV Cache eines Requests entfernen und ihn später mit kürzerer Token-Historie neu einplanen. Netflix ergänzte Tracking für partielle Prefills und setzte die Zustandsmaschine zurück, wenn die Historie schrumpfte. Flache Verarbeitungszeit kam aus einem neuen Zustandsmodell, nicht aus einem kostenlosen Versionswechsel.
Sieben Produktionslektionen, die sich übertragen lassen
1. Wähle nach operativem Fit und benchmarke danach
Verwende repräsentative Modelle, Concurrency, Prompt- und Output-Längen sowie echte Constraints. Miss Time to First Token, Inter-Token-Latenz, Durchsatz und Tail Latency. Rechne Packaging, Diagnose und Upgrades hinzu. Eine Engine ist Teil eines Release-Systems, keine isolierte Benchmark-Binary.
2. Halte den Consumer-Vertrag oberhalb der Engine
Netflix zwang nicht jeden Aufrufer, vLLM zu verstehen. Die bestehende Serving-Schicht behielt Routing, Experimente und Workflow-Logik. Ein stabiler interner Vertrag lässt dich die Engine wechseln, ohne jede Produktintegration neu zu schreiben. Dasselbe Prinzip steckt in unserer Produktionsarchitektur für stateful LLM-Plattformen: Dauerhaftes Produktverhalten darf nicht von einer Model Runtime abhängen.
3. Pinne das gesamte Kompatibilitätsset
Tritons vLLM-Backend hängt von einer bestimmten vLLM-API ab. Netflix berichtete von einem Backend, das bei Versionsdrift nicht mehr lud. NVIDIA veröffentlicht inzwischen eine Kompatibilitätsmatrix für Triton und vLLM. Behandle Triton-Image, vLLM-Version, CUDA, Treiber und Plugins als eine getestete Einheit. Ein Model Package darf keinen Teil davon allein überschreiben.
4. Teste API-Semantik, nicht nur Statuscodes
Netflix stellte fest, dass Tritons OpenAI-kompatibles Frontend response_format akzeptierte, aber vor vLLM verwarf. Der Call war erfolgreich, während der versprochene Output-Constraint verschwand. Netflix patchte die Übersetzung. Die aktuelle Dokumentation des OpenAI-kompatiblen Triton-Frontends zeigt die Verbindung zum vLLM-Backend. Deine Contract Tests müssen trotzdem jedes produktrelevante Feld semantisch prüfen.
5. Passe den Rollout an das Interface-Risiko an
Netflix nutzt Red-Black, wenn das Modell-Interface stabil bleibt. Die neue Version startet neben der alten, besteht Health Checks und übernimmt schrittweise Traffic. Neue Tensorformen erzeugen ein Koordinationsproblem, weil alte Consumer und neue Modelle überlappen. Dafür halten versionierte Deployments beide Interfaces parallel am Leben. Die zeitweise zusätzliche GPU zahlt für ein sicheres Migrationsfenster.
6. Lege Modellgewichte auf einen bezahlbaren Startpfad
Große Downloads aus Object Storage machten Cold Starts zu langsam. Deshalb materialisierte Netflix angekündigte Modelle auf Amazon FSx. AWS dokumentiert, dass eine mit S3 verbundene FSx-for-Lustre-Datei beim ersten Zugriff Latenz verursacht, sofern Teams die benötigten Inhalte nicht vorab in das Dateisystem laden. Die allgemeine Regel ist providerneutral: Weight Placement gehört ins Deployment und muss vor Readiness geprüft werden. Miss Cold Starts auf einem leeren Node, nicht auf einem warmen Entwicklergerät.
7. Verbinde Engine- und Server-Observability
Tritons Bridge zeigte nur einen Teil der vLLM-Metriken, die Netflix brauchte. Das Team kombinierte Triton-Metriken und vLLM-Prometheus-Dateien hinter einem Endpoint. Dein minimales Dashboard sollte Request Rate, Queue Time, Time to First Token, Inter-Token-Latenz, Token-Durchsatz, KV-Cache-Nutzung, Prefix-Cache-Hits, Preemption, Model-Load-State, Fehler und GPU-Auslastung verbinden. Ein grüner GPU-Graph kann neben einem kaputten CPU-Logits-Pfad existieren.
Soll dein Unternehmen Netflix kopieren oder eine Hosted API nutzen?
| Signal | Hosted oder Managed Inference | Interne vLLM- und Triton-Plattform |
|---|---|---|
| Nachfrage | Gering, unklar oder sprunghaft | Stetig genug für GPU-Kapazitätsplanung |
| Modellbedarf | Standardmodelle und übliche API-Features | Eigene Architekturen, Plugins oder Decoding-Regeln |
| Änderungsbesitz | Provider soll Upgrades betreiben | Plattformteam kann pinnen, testen und zurückrollen |
| Datengrenze | Vertraglich geregeltes Hosting ist akzeptabel | Inferenz muss in kontrollierter Infrastruktur bleiben |
| Observability | Provider-Metriken reichen für das Serviceziel | Token-, Cache- und Scheduler-Evidenz ist nötig |
| Fehlerbudget | Provider-Failover ist sinnvoller | Multi-Version-GPU-Rollouts und On-Call sind betreibbar |
Wähle eine interne Plattform erst, wenn mindestens eine differenzierende Anforderung eine ernsthafte Managed-Service-Prüfung überlebt. Eigenes Constrained Decoding kann reichen. Eine stabile Hochlast kann reichen. Eine harte Datengrenze kann reichen. Abneigung gegen Token-Rechnungen ist allein noch keine Architektur.
Ein praktischer Validierungsplan für 90 Tage
- Woche 1 bis 2, Vertrag definieren: Repräsentative Prompts, Response-Schemas, Latenzziele, Quality Evals und Fehlerverhalten fixieren. Hosted Baseline festhalten.
- Woche 3 bis 5, echten Pfad benchmarken: Engines mit produktionsnaher Concurrency, Constraints und Modellvarianten testen. CPU-Arbeit und Cold Starts einschließen.
- Woche 6 bis 8, Betrieb beweisen: Images pinnen, Weights vorladen, Metriken vereinheitlichen, fehlgeschlagenen Model Load und Rollback üben.
- Woche 9 bis 10, Shadow Traffic: Qualität, Latenz und Schema-Compliance ohne sichtbare Antworten vergleichen.
- Woche 11 bis 13, kommerziell entscheiden: Vollkosten der Plattform mit der Hosted-Rechnung vergleichen, inklusive Engineering, Redundanz, Support und Upgrades.
Wenn Latenz dein Hauptproblem ist, trenne Serving-Architektur von Model Ownership. Unsere Analyse eines gemeinsamen KV Cache für deutlich schnellere erste Tokens zeigt, wie eine gezielte Infrastrukturänderung wirken kann, ohne den ganzen Inferenzpfad zu ersetzen.
FAQ zu Netflix, vLLM und Triton
Betreibt Netflix jede LLM-Inferenz selbst?
Warum bevorzugte Netflix vLLM gegenüber TensorRT-LLM?
Was verursachte den Constrained-Decoding-Bottleneck?
Braucht vLLM zwingend NVIDIA Triton?
Wann sollte ein kleineres Unternehmen LLM-Inferenz selbst hosten?
Besitze die richtige Betriebsgrenze
Die stärkste Netflix-Lektion ist keine Liste von Markennamen. Es ist die Reihenfolge des Ownerships: stabiler Consumer-Vertrag, Auswahl gegen echte Workloads, gepinnte Runtime, semantische API-Tests, risikogerechter Rollout, vorbereitete Weights und gemeinsame Sicht auf CPU, Cache, Scheduler und GPU.
Wavects AI Enablement und Inferenzarchitektur deckt diese Prüfung vom Workload-Benchmark bis zum Produktions-Handover ab. Die Twinsoft-AI-Fallstudie zeigt, wie wir KI-Entscheidungen in einen getesteten Produktworkflow übersetzen. Nutze unseren Leitfaden vom Prototyp zur Produktion für den weiteren Plattformumfang oder fordere einen Review deiner Inferenzarchitektur an, abgestimmt auf Traffic, Daten und Modelle.