Eine gemietete GPU statt der eigenen Produktion: der vLLM-Offload-Test für Qwen3.8-Flash-Next

Nach der Veröffentlichung von Qwen3.8-Flash-Next stand eine Frage offen, die sich nicht am Datenblatt beantworten ließ: Kann vLLM die riesige N-Gram-Embedding-Tabelle des Modells in den Hauptspeicher auslagern, so wie es die Konfigurationsvariable VLLM_PLE_CPU_OFFLOAD verspricht? Die zugehörigen Pull Requests waren offen, niemand hatte öffentlich bestätigt, dass die Kombination tatsächlich lädt und rechnet.

Den Test direkt auf der eigenen Produktionsmaschine zu fahren, hätte bedeutet, die laufende 27B-Spur für die Dauer des Versuchs abzuschalten, ohne zu wissen, ob am Ende überhaupt etwas Lauffähiges dabei herauskommt. Stattdessen haben wir bei Vast.ai eine Maschine mit demselben GPU-Typ und derselben PCIe-Generation gemietet wie die eigene.

Mehr Reibung bei der Miete als beim eigentlichen Test

Der erste Versuch scheiterte an einem Missverständnis in der Vast.ai-Oberfläche: Docker-Image und Tag sind getrennte Felder, und ein Kachel-Template setzt nicht automatisch das richtige Image. Der zweite Versuch hatte das richtige Image, aber ein zu kleines Overlay-Dateisystem für einen 170-GB-Checkpoint, weil die Felder für Datenträgergröße und Volume-Anbindung unabhängig voneinander sind und ein gespeichertes Template das Volume beim erneuten Auswählen eines Angebots nicht zwingend mitnimmt. Erst der dritte Versuch – eine Maschine in Schweden mit EPYC-9755-CPU, 773 GB RAM und PCIe 5.0 x16 – passte exakt zum gespeicherten Template.

Der erste Absturz lag tiefer als erwartet

Der NVFP4-Checkpoint lud sauber: Die GPU-Gewichte in 101 Sekunden, die Embedding-Tabelle wie vorgesehen in den Hauptspeicher, der Host-RAM stieg dabei von 42 auf 141 GB. Die eigentliche Offload-Frage war damit schon beim ersten Versuch beantwortet – sie funktioniert. Der Absturz kam einen Schritt später, beim Aufbau des Inferenz-Kernels:

NotImplementedError: ('Intermediate size padding for w1 and w3, for %s NvFp4 backend,
but this is not currently supported', 'FLASHINFER_CUTLASS')

vLLMs automatische Backend-Auswahl für NVFP4-MoE-Schichten probiert mehrere Kernel-Implementierungen der Reihe nach durch, landet für diese Kartengeneration bei FLASHINFER_CUTLASS – und genau der bricht bei dieser Tensor-Form ab, statt auf die nächste Option in der Kette auszuweichen.

Ein manueller Umweg, dann ein neuer Fehler

Ein Kommandozeilenparameter erlaubt es, die automatische Auswahl zu umgehen: --moe-backend marlin. Damit luden alle vier GPU-Worker sauber, der Offload registrierte sich auf jedem Rang – und ein neuer Fehler tauchte auf, ein echter Speicherüberlauf während der CUDA-Graph-Aufzeichnung. Die RTX 5090 wird von Marlins Prüfung auf native FP4-Unterstützung nicht erkannt, vermutlich weil die entsprechende Prüfung Consumer-Blackwell-Karten noch nicht kennt. Die Folge: Marlin fällt auf eine reine Software-Emulation von 4-Bit-Gewichten zurück, die pro Karte deutlich mehr Speicher belegt als ein echtes 4-Bit-Format – genug, um den verbleibenden VRAM für die Graph-Aufzeichnung aufzubrauchen.

Erst mit zusätzlich --enforce-eager, also ohne CUDA-Graph-Aufzeichnung, lief der Server durch: Health-Check mit Status 200, eine echte Chat-Antwort mit sichtbaren Denkschritten.

Funktioniert, aber langsam

Im direkten Vergleich mit der eigenen Produktionsspur auf derselben Aufgabe kam die gemietete Maschine auf rund 14 Token/s, die produktive 27B-Spur auf 85,7. Das ist erwartbar: --enforce-eager verzichtet vollständig auf den Geschwindigkeitsgewinn durch CUDA-Graphen, und die Software-Emulation von Marlin kostet zusätzlich. Eine zweite Miete mit derselben Konfiguration, aber auf PCIe 4.0 statt 5.0 begrenzt, lieferte noch einmal rund ein Drittel weniger Durchsatz – ein Hinweis darauf, dass die Anbindung bei diesem Modell tatsächlich zählt, nicht nur die reine Rechenleistung der Karte.

Der bestehende llama.cpp-Aufbau kam im gleichen Zeitraum auf rund 46 Token/s. Der Vergleich ist nicht ganz sauber, da unterschiedliche Quantisierungen und unterschiedliche Hardware beteiligt waren, aber der Abstand ist groß genug, um als vorläufiges Ergebnis zu gelten.

Was der Test gebracht hat

Die eigentliche Frage – lädt und rechnet die Kombination aus vLLM und PLE-Offload überhaupt – war schon nach dem ersten von drei Fehlversuchen beantwortet, und zwar positiv. Für die Produktionsreife braucht es noch einen funktionierenden nativen FP4-Kernel für diese Kartengeneration, ohne den Umweg über Marlin und ohne den Verzicht auf CUDA-Graphen. Bis dahin bleibt die eigene Produktion unangetastet auf der bewährten Konfiguration, und der nächste Test lässt sich wieder auf einer gemieteten statt der eigenen Maschine fahren.

Weiterführende Quellen

Fragen?

Was ist PLE-CPU-Offload und warum ist es bei diesem Modell wichtig?+

Qwen3.8-Flash-Next trägt neben den eigentlichen MoE-Gewichten eine 51 Milliarden Parameter große N-Gram-Embedding-Tabelle, die für den schnellen Zugriff eigentlich im GPU-Speicher liegen müsste. PLE-CPU-Offload verschiebt diese Tabelle in den Host-Arbeitsspeicher und hält nur die eigentlichen Rechengewichte auf der Karte – ohne das passt das Modell auf keiner uns verfügbaren Hardware in den VRAM.

Warum eine Cloud-GPU mieten statt lokal zu testen?+

Der Test hätte die produktive 27B-Spur für die Dauer des Versuchs offline genommen, und ob PLE-Offload überhaupt funktioniert, war zu diesem Zeitpunkt öffentlich unbestätigt. Eine gemietete Maschine mit demselben GPU-Typ und derselben PCIe-Anbindung ließ den Test unabhängig von der eigenen Produktion laufen.

Ist vLLM für dieses Modell inzwischen schneller als llama.cpp?+

Nein, noch nicht. In unserem Test kam die vLLM-Konfiguration auf rund 14 Token/s, unser bestehender llama.cpp-Aufbau auf etwa 46 Token/s. Der Vergleich ist nicht ganz sauber – unterschiedliche Quantisierung, unterschiedliche Hardware –, aber der Abstand ist groß genug, um als vorläufiges Ergebnis zu gelten.