CNCF: NetEase Games erreicht 30-Sekunden-LLM-Cold-Start auf Kubernetes über Fluid-Prefetching-Schichten

CNCF (Cloud Native Computing Foundation) veröffentlichte am 21. Mai 2026 eine technische Fallstudie von NetEase Games — einem der größten chinesischen Gaming-Unternehmen — die detailliert beschreibt, wie Ladezeiten für große LLM-Modelle in ihren Kubernetes-Serving-Stack von katastrophalen 42 Minuten auf unter 30 Sekunden gesenkt wurden. Die Autoren sind Haifeng Liao und Xiang Zhang aus dem Infrastruktur-Team von NetEase Games.

Was war das ursprüngliche Problem?

NetEase Games verwendet LLM-Modelle der 70B-Klasse (Llama 3, Qwen oder ähnlich) für mehrere Produktions-Anwendungsfälle — KI-NPC-Dialoge in Spielen, Content-Moderation und automatische Übersetzungen. Die Modelle sind zu groß, um sie im Speicher aller Cluster-Nodes zu halten — sie müssen bei jedem Skalierungsereignis oder Pod-Neustart on-demand geladen werden.

Der direkte Zugriff auf das Modell aus S3-kompatiblem Objektspeicher dauerte 42 Minuten für das vollständige Laden eines 70B-Modells in den GPU-Speicher. Für einen Produktions-Workload ist das inakzeptabel — jedes Skalierungsereignis verursacht einen 42-minütigen Ausfall für den neuen Pod.

Welche Optimierungsphasen wurden durchlaufen?

NetEase führte die Optimierung in mehreren Phasen durch:

Phase 1 — direkter S3-Zugriff: 42 Minuten. Baseline.

Phase 2 — Fluid Distributed Cache: 14 Minuten. Implementierung des CNCF Fluid-Projekts, das Modelle zwischen Cluster-Nodes über P2P-Transfers teilt. Statt dass jeder Pod direkt von S3 lädt, können neue Pods das Modell von benachbarten Nodes abrufen, die es bereits gecacht haben.

Phase 3 — Fluid mit lokalem SSD-Cache: 3 Minuten. Hinzufügen einer lokalen SSD-Caching-Schicht, die warme Kopien der am häufigsten genutzten Modelle vorhält. Bei einem neuen Skalierungsereignis ist das Modell bereits im lokalen Cache — der Netzwerktransfer entfällt.

Phase 4 — Pre-Warming + Predictive Scheduling: unter 30 Sekunden. Pre-Warming-Strategie — das System prognostiziert, wann ein neuer Pod benötigt wird (anhand historischer Last-Muster) und lädt das Modell vorab, bevor der Pod tatsächlich gebraucht wird. Kombiniert mit Predictive Scheduling, das neue Pods auf Nodes plant, die das Modell bereits im Speicher haben.

Was ist Fluid als CNCF-Projekt?

Fluid ist ein CNCF-inkubiertes Projekt mit Fokus auf Daten-Orchestrierung für Kubernetes. Der Hauptanwendungsfall ist die Beschleunigung des Zugriffs auf große Datensätze — ob LLM-Gewichte, Trainingsdatensätze oder wissenschaftliche Daten. Fluid abstrahiert den zugrunde liegenden Speicher (S3, GCS, HDFS, NFS) und bietet eine einheitliche Schicht mit integriertem Caching, Prefetching und Scheduling-Integration.

Speziell für den LLM-Anwendungsfall ermöglicht Fluid:

• Pod-Level-Affinity — der Kubernetes-Scheduler kann neue Pods bevorzugt auf Nodes planen, auf denen das Modell bereits gecacht ist
• Asynchrones Prefetch — das Modell kann vorab geladen werden, bevor der Pod es benötigt
• Geteilter Cache zwischen Teams — mehrere Teams können dasselbe Modell teilen, ohne es mehrfach zu kopieren

Was bedeutet dies für produktive LLM-Inferenz?

Cold-Start-Latenz ist ein kritisches Problem für serverless oder auto-skalierte LLM-Deployments. Industriestandards (OpenAI, Anthropic) erzielen Sub-Sekunden-Cold-Start-Zeiten für ihre proprietären Stacks — aber das ist das Ergebnis benutzerdefinierter Infrastruktur, die die Open-Source-Community nicht einfach replizieren kann.

Die NetEase-Fallstudie liefert einen konkreten Blueprint, dem andere Unternehmen mit Open-Source-Komponenten folgen können (Kubernetes + Fluid + vLLM). Unter 30 Sekunden Cold Start für ein 70B-Modell ist für die meisten Produktions-Workloads akzeptabel — vergleichbar mit der Zeit, die für ein Skalierungsereignis in einem typischen Microservice benötigt wird.

Für CNCF ist diese Fallstudie eine Validierung des Fluid-Projekts als produktionsreifes Werkzeug. Es bleibt abzuwarten, ob andere LLM-Serving-Betreiber (Replicate, Together AI, Anyscale) ähnliche Fluid-basierte Ansätze für ihre eigenen Multi-Tenant-LLM-Plattformen übernehmen.