Wer lokale LLMs auf eigener Hardware betreibt, hat Mitte Juni 2026 aufgehorcht: Das vLLM-Projekt, Anyscale und das Google-Cloud-GKE-Team meldeten gemeinsam einen massiven Performance-Sprung beim Deployment-Stack Ray Serve LLM + vLLM. Laut den Veröffentlichungen von Anyscale und Google Cloud vom 18. Juni 2026 erreicht Ray Serve LLM nun „up to 4.4x higher throughput on prefill-heavy workloads and 24x on decode-heavy workloads" im Vergleich zu früheren Versionen des Stacks, laut Messungen auf Produktions-Infrastruktur mit acht GPU-Replicas.
Das ist kein Benchmark-Artefakt aus dem Labor. Die drei architektonischen Änderungen, die dahinterstecken, sind in Ray 2.56 und aktuellen vLLM-Releases enthalten und betreffen damit jeden, der diesen Stack produktiv betreibt.
Was genau wurde angekündigt?
Anyscale (das Unternehmen hinter Ray) und das Google-Cloud-Kubernetes-Engine-Team veröffentlichten am 18. Juni 2026 sowohl einen technischen Blogpost als auch Benchmark-Daten. Die Tests liefen auf Google-Cloud-A4-VMs mit NVIDIA-HGX-B200-Hardware, als Testmodell diente Gemma 4 E2B, gewählt, um Bottlenecks im Orchestrierungs- und Routing-Layer zu isolieren, nicht in der reinen Modell-Inferenz.
Für KMU mit kleinerem Hardware-Budget gilt: Die Software-Optimierungen sind in öffentlichen Releases verfügbar. Die absoluten Token-pro-Sekunde-Zahlen skalieren mit der Hardware, aber die prozentualen Verbesserungen zeigen sich auf jedem GPU-Setup.
Die drei Optimierungen im Detail
1. Direct Token Streaming
Bisher liefen Anfrage-Routing und Token-Streaming über denselben Codepfad durch den Ingress-Router. Ray 2.56 entkoppelt beides: Tokens streamen nun direkt vom Modell-Replica zurück zum Client und umgehen den Router auf dem Rückweg. Das reduziert die Time-to-First-Token (TTFT) und Inter-Token-Latenz (ITL) messbar, besonders bei langen Antworten und Chat-Workloads, wo jede Millisekunde Latenz im Streaming spürbar ist.
2. v2 Ray Executor Backend für vLLM
Die zweite Optimierung hebt Ray aus dem Inferenz-Datenpfad heraus. Statt dass Ray selbst Tensor-Operationen koordiniert, übernimmt vLLMs nativer Executor das Engine-Management. Ray bleibt für Orchestrierung und Fehlertoleranz zuständig, nicht für die heiße Inferenz-Schleife. Der praktische Effekt: Jede neue Engine-Optimierung im vLLM-Projekt (Flash Attention, paged KV-Cache, speculative Decoding) steht automatisch auch Ray-Serve-Deployments zur Verfügung, ohne separaten Integrations-Aufwand.
3. HAProxy-Integration
Ein integrierter HAProxy-Layer übernimmt das interne Load-Balancing zwischen den Modell-Replicas. Das verhindert, dass der Python-Laufzeit-Thread des Routers unter hoher Parallelität saturiert, ein bekannter Flaschenhals bei produktiven High-Concurrency-Setups. Laut Google Cloud Blog liefert die Kombination der drei Optimierungen bis zu 5x höheren Durchsatz und 8x niedrigere Latenz gegenüber der früheren Ray-Serve-Konfiguration.
Was bedeutet das konkret für lokale Deployments?
Der wichtigste Kennwert für On-Premise-Betrieb ist der Durchsatz pro GPU-Stunde: Wie viele Anfragen kann dieselbe Hardware beantworten? Wenn decode-heavy Workloads, langes Completion-Generieren, Dokument-Zusammenfassungen, mehrstufige Chat-Sessions, laut den berichteten Benchmarks bis zu 24x mehr Anfragen pro Sekunde durchsetzen, ergeben sich drei direkte Konsequenzen:
Dieselbe Hardware, drastisch mehr Kapazität. Ein Setup, das bisher 20 parallele Sessions bediente, kann potenziell ein Vielfaches davon bewältigen, ohne zusätzliche GPU-Kosten.
On-Premise konkurriert stärker mit Cloud-APIs. Dienste wie OpenAI, Anthropic oder europäische Pendants rechnen pro Token ab. Lokale Inferenz trägt feste Hardware-Kosten. Je höher der Durchsatz, desto mehr Anfragen teilen sich diese Fixkosten, und desto günstiger wird jede einzelne Anfrage im Betrieb.
DSGVO-Konformität bleibt vollständig erhalten. Bei Ray Serve + vLLM auf eigener Infrastruktur verlassen keine Daten das eigene Rechenzentrum. Für Kanzleien, Steuerberater, medizinische Einrichtungen und alle anderen datensensitiven Branchen ist das der entscheidende Vorteil, den keine Cloud-API replizieren kann, unabhängig von deren Performance-Zahlen. Mehr dazu auf unserer Seite zur lokalen KI und Datensouveränität.
Voraussetzungen und ehrliche Einschränkungen
Die Benchmark-Hardware ist Enterprise-Grade: NVIDIA HGX B200 auf Google Cloud A4 VMs, acht Replicas. Ein einzelner NVIDIA RTX 4090 oder ein Mac Studio M3 Ultra erreicht diese absoluten Zahlen nicht.
Trotzdem sind die Erkenntnisse direkt übertragbar:
- vLLMs v2 Executor Backend und Direct Streaming sind veröffentlichte Features, kein Prototyp-Code. Sie wirken auf jeder vLLM-Instanz, auch auf Single-GPU-Setups.
- HAProxy lässt sich manuell vor einem bestehenden Ollama- oder vLLM-Server konfigurieren, ohne Kubernetes.
- Ray Serve on-premise (ohne GKE) profitiert von Ray 2.56 identisch wie auf Google Cloud.
Fördermöglichkeiten für Hardware-Investitionen
Falls Sie über die Anschaffung einer GPU-Workstation oder eines kleinen On-Premise-Clusters für KI-Inferenz nachdenken: In Deutschland gibt es über BAFA und KfW verschiedene Digitalisierungsförderprogramme, die Hardware für produktive KI-Deployments mitabdecken können. Gemäß unserem Verständnis der aktuellen Förderrichtlinien ist KI-Hardware dann förderfähig, wenn sie konkrete betriebliche Prozesse digitalisiert, nicht nur für Experimente dient. Die genauen Bedingungen variieren je nach Bundesland und Unternehmensgröße; lassen Sie sich dazu von Ihrer Hausbank oder einem spezialisierten Förderberater individuell beraten.
Wenn Sie wissen möchten, welche Hardware für Ihren spezifischen Use-Case die richtige Stufe ist, helfen wir bei der Bedarfsanalyse, gerne im Rahmen eines Pilotprojekts.
Was Sie jetzt tun sollten
Wenn Sie bereits vLLM in Produktion betreiben:
- Update auf die aktuelle vLLM-Version, das v2 Ray Executor Backend ist enthalten.
- Direct Streaming aktivieren (Ray 2.56+), wenn Sie Ray Serve nutzen.
- Time-to-First-Token (TTFT) und Inter-Token-Latenz (ITL) monitoren, nicht nur Requests/Sekunde. Diese Metriken bestimmen die wahrgenommene Antwortgeschwindigkeit in Chat-Anwendungen.
Wenn Sie noch keinen lokalen LLM-Stack betreiben und wissen möchten, ob sich das für Ihren Betrieb rechnet: Schreiben Sie uns. Wir zeigen Ihnen, welcher Stack zu Ihrem Anwendungsfall passt, und was Sie realistischerweise gegenüber Cloud-API-Kosten einsparen können.
Quellen: vLLM Project auf X · Google Cloud Blog · Anyscale Blog