CUDA 13 als Pflicht: vLLM 0.30.0 und llama.cpp 0.5.0 haben ihr Fundament umgezogen

Zwei Engine-Releases in einer Woche haben ihre Bauumgebung umgestellt, und beide drehen an derselben Schraube: CUDA 13 wird die Untergrenze, mit der man rechnet. vLLM v0.30.0 kam am 22. September, 762 Commits von 315 Mitwirkenden, Standardbau jetzt gegen CUDA 13.0. llama.cpp v0.5.0 folgte am 23. September, der erste Major-Release seit v0.4.0, die Release-Bauten inklusive Docker-Image laufen auf CUDA 13.4.1. Wer Inferenz-Hosts betreibt, prüft den NVIDIA-Treiber, bevor er Images zieht, nicht nachdem ein Container im Crashloop steht.

Beide Engines bauen gegen CUDA 13. Die Frage ist pro Host nur noch der Treiberstand, und der ist in einer Zeile gemessen. (Quelle: Simple Icons, Datei nvidia.svg (CC0))

Was an vLLM 0.30.0 hängt

Zwei Funktionen verdienen die Aufmerksamkeit, weil sie Betriebsprobleme adressieren, die jede Lane mit langsamen Disk-Starts kennt. Erstens der Weight-Cache-Daemon: Ein persistenter Daemon pro GPU hält post-quantisierte, TP-geshardete Gewichte im Grafikspeicher, Neustarts mappen sie per CUDA IPC über --load-format ipc_cache (#54921) statt von Disk zu lesen, inzwischen auch für FP4-Checkpoints (#55465) und Multi-Node-Tensorparallelität (#55468). Zweitens HiSparse: Ein Host-RAM-Tier für sparse-MLA-Decode lagert KV-Seiten unter Druck in gepinnten Arbeitsspeicher aus, über HiSparseConnector (#53781) mit Prometheus-Zählern (#56061). Auf 32-Gigabyte-Karten ist das der Unterschied zwischen Abbruch und Auslagern.

Die Brechstellen, alle aus den Release-Notes: Scale-out-Endpoints gibt es nur noch opt-in über --enable-scale-out (#54579/#55176), die Umgebungsvariable dafür ist weg. GPTQ verliert die Aktivierungsreihenfolge g_idx (#54809). Die für 0.29 angekündigten Deprecations sind entfernt, darunter VLLM_PREFIX_CACHE_RETENTION_INTERVAL und VLLM_MM_HASHER_ALGORITHM (#55353). gRPC läuft über vllm serve --grpc (#56746). Und YaRN skaliert max_model_len nicht mehr nach (#56446), Kontextlängen, die man sich mit YaRN gebogen hat, biegen sich beim Update zurück.

Was an llama.cpp 0.5.0 hängt

CUDA-conv2d als implicit GEMM (#29135). Multi-Address-Binding: --host akzeptiert kommagetrennte Adressen und UNIX-Sockets (#28690). Vulkan-MMQ-Kernels für IQ4_XS und IQ3_S, ROCm-AllReduce wieder aktiv, Tensor-Parallel-Fix gegen Kapazitätsunterbietung bei fused QKV (#29160). Für geteilte Setups der wichtigste Bugfix: Kinderprozesse bekommen das --api-key-file nicht mehr durchgereicht (#29279), der API-Key liegt nicht mehr halbweltoffen in jeder Kindprozess-Kommandozeile. RPC-Protokoll major v7 und ggml 0.25 stehen darunter, das ist die Zeile, die Version-Mischen über Hosts hinweg beendet.

Bei uns nachgemessen

Am 29.09. um kurz vor elf gemessen: Unsere Fallback-Lane meldet auf Port 8080 {"version":"0.30.0"}, der Host steht auf Treiber 610.57.04, geleast über nvidia-smi --query-gpu=driver_version. Läuft grüne, der Image-Tag dahinter ist mit CUDA-13-Basis gebaut. Der zweite Inferenz-Host meldet einen Nightly-Stand 0.1.dev20073+g8e685d198, das ist kein Release und mit keiner Versionslinie vergleichbar, er bleibt in dieser Rechnung außen vor. Empfehlung für die eigene Flotte: Treiberstand pro Host in einer Zeile messen (nvidia-smi), dann pullen. Bei llama.cpp über mehrere Hosts eine Update-Runde fahren statt schrittweise, seit RPC v7 ist Mischen ein Funktionsfehler, kein Graubereich. Und die Scale-out-Endpoints, die jetzt opt-in sind: Wo niemand sie braucht, ist das Update ein kleiner Zugewinn an Angriffsfläche.

Weiterführende Quellen

vLLM-Releases, v0.30.0 vom 22.09.2026
llama.cpp v0.5.0, Release-Notes vom 23.09.2026
llama.cpp tagesbuilds, CUDA-13.4-Umstellung
Der FP8-KV-Vergleich auf unserer Lane: vLLM-Nightly mit FP8-KV

Fragen?

Läuft vLLM 0.30.0 noch unter CUDA 12.9?+

Als Imagevariante ja, der cu129-Bau wird als explizites Extra-Tag mitgeliefert, Standard ist CUDA 13.0. Wer den Treiber nicht anfassen will, greift zum Tag. Das ist eine Überbrückung für ein Update-Fenster, keine Perspektive, die Extra-Tags altern mit.

Bringt NVFP4 etwas auf einer RTX 5090?+

Diese Woche nichts. Der neue FlashInfer-Pfad, der Marlin als Default ersetzt, gilt laut Release-Notes nur für SM100 und SM103. Die RTX 5090 ist SM120 und bleibt beim Marlin-Pfad. Die NVFP4-Erfolgsmeldungen dieser Woche gelten für unsere Karten ausdrücklich nicht.

Warum interessiert die RPC-Protokollversion bei llama.cpp?+

RPC major ist auf v7 gezogen. Betriebene Hosts mischen heißt dann: neue und alte Bauten sprechen auf diesem Pfad nicht mehr miteinander. Wer llama.cpp-server über mehrere Maschinen verteilt, muss sie in einer Runde aktualisieren.