Zum Inhalt springen
Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.
flozi00 Logoflozi00 TechHub
ENDE

Wie wir GLM auf B300 in Produktion betreiben: MTP k=5-Tuning

Produktionsnotizen aus dem Betrieb eines GLM-MoE auf 8x B300: die Akzeptanzraten-Mathematik hinter Speculative Decoding, was die gemessene log_stats-Kette ueber k=2-k=3 sagt, und warum NVLS-Fehler default lautlos bleiben.

5 Min. Lesezeitflozi00
llm-inferenzspeculative-decodingmtpb300ncclproduktion

Multi-Token-Prediction in Produktion ist ein Akzeptanzraten-Problem. Dieser Beitrag sind unsere Tuning-Notizen aus dem Betrieb eines GLM-MoE auf 8x B300 (Blackwell Ultra, sm_103)1: was Spekulationstiefe bringt, wenn man die kumulative Akzeptanzmathematik anwendet - gemessen auf unserem eigenen Knoten - und warum NVLink-SHARP (NVLS)-Fehler default lautlos bleiben und wie man sie sichtbar macht.

Das Setup

Der MTP-Head von GLM liegt im Checkpoint - eine zusaetzliche Praediktions- Schicht, kein separater Draft-Modell-Download. Z-AIs Model Card fuer GLM-5.3 (744B/40B-aktiv Sparse-Attention-MoE GlmMoeDsaForCausalLM, 1M-Kontext, eine MTP-Schicht) dokumentiert den nativen MTP-Head2; auf unserem Knoten liegt er physisch als eigene mtp_bf16-*.safetensors- Dateien neben den Trunk-Gewichten. vLLM (speculative_config={"method": "mtp", "num_speculative_tokens": k})3 und SGLang (--speculative-algorithm NEXTN)4 konsumieren ihn direkt: Das vLLM-Rezept fuer GLM-5.3 empfiehlt exakt das Setup, das dieser Knoten faehrt - TP=8, MTP k=5 mit --kv-cache-dtype fp8_e4m3; Blackwell- Knoten nutzen den NVFP4-experten-quantisierten Checkpoint (nur die gerouteten Experten sind NVFP4; Attention, Shared Experts und Dense-Layer bleiben BF16)5.

Die Akzeptanzmathematik, die Ihren Speedup vorhersagt

Nur die Akzeptanzraten pro Position zaehlen. Die erwarteten Tokens pro Decoding-Schritt sind nicht k plus eins - sie folgen der Wahrscheinlich- keitskette der gemeinsamen Akzeptanz (das Framework ist Speculative Decoding, wie Leviathan, Kalman und Matias es eingefuehrt haben: Draft-Tokens werden gegen das Zielmodell verifiziert, akzeptierte Tokens unter der Zielverteilung resampelt)6:

E[Tokens pro Schritt]=1+∑i=1k∏j=1iaj\mathbb{E}[\text{Tokens pro Schritt}] = 1 + \sum_{i=1}^{k} \prod_{j=1}^{i} a_j

vLLM schreibt diese Zahlen periodisch in die log_stats-Zeilen - sichtbar unter echter Last: Mean acceptance length, akzeptierte vs. gedraftete Token und die Per-position acceptance rate fuer jede Draft-Position. Auf unserem B300-Knoten (GLM-5.3-Klasse-MoE, TP=8 ueber 8x B300, MTP k=5, fp8-KV-Cache, vLLM v0.30.0) sieht die gemessene Kette so aus:

kgemessene Kette (B300-Knoten)E[akzeptiert]Tokens/SchrittAnteil von k=5
10,720,721,7248 %
20,72, 0,581,302,3064 %
30,72, 0,58, 0,481,782,7877 %
40,72, 0,58, 0,48, 0,442,223,2289 %
50,72, 0,58, 0,48, 0,44, 0,402,623,62100 %

Ketten kumulieren brutal: k=2 faengt auf unserer gemessenen Kette rund 64 % des k=5-Maximums ein, k=3 rund 77 %. Aber der Anteil, den man eingefangen hat, ist eine Funktion der Raten, die der eigene Workload wirklich produziert: dasselbe Checkpoint auf 8x RTX PRO 6000 Blackwell Server Edition als einer unserer Produktions-Pools zeigt eine steiler abfallende gemessene Kette (0,77 / 0,56 / 0,40 / 0,30 / 0,23 ueber einen 22-Stunden-Scrape mit 663 Fenstern) - der k=2-Anteil steigt auf ~71 %, und k=5 erreicht nur eine Mean Acceptance Length von 3,3. Gleiches Modell, gleiches k - eine steilere Kette laesst tiefe Spekulation noch weniger zahlen, eine flachere zahlt k=4 und k=5 zurueck. Oeffentliche Messungen zeigen dieselbe Spreizung ueber Hardware und Workloads bei GLM-MTP-Modellen; das vLLM-Rezept fuer das kleinere GLM-4.5 empfiehlt auf jenem Modell weiterhin num_speculative_tokens 1 fuer optimalen Durchsatz7, das GLM-5.3-Rezept fuehrt k=5 als Flaggschiff-Default5.

Tiefere Spekulation kauft marginale Tokens, waehrend jede Draft-Position Kosten verursacht:

  • Verlorene Verify-Arbeit: ein abgelehnter Draft belegte trotzdem einen Verify-Slot.
  • Ablehnungs-Latenz: Das korrigierte Token muss propagieren, bevor der naechste Draft starten kann - tiefere Ketten blockieren pro Ablehnung laenger.
  • KV-Cache-Druck: num_speculative_tokens reserviert KV-Eintraege pro Anfrage fuer Draft-Positionen; die vLLM-Doku empfiehlt, klein zu starten3.

Die Tiefe ist eine per-Workload-Entscheidung, getrieben von gemessenen Akzeptanzraten - oeffentliche Benchmarks finden, dass Akzeptanz ueber Datensaetze, Anfragen und Positionen hinweg stark variiert7. Erst messen, dann k setzen - die log_stats-Zeilen von oben sind die Messung.

Der stille Fehlermodus: NVLS auf sm_103

Das zweite Thema ist eine dokumentierte Fehlermodus-Eigenschaft des Fabric-Pfads: Wenn die NVLS-Initialisierung fehlschlaegt, laeuft NCCL default einfach ohne weiter - kein Fehler, kein Crash, nur ein langsameres Kollektiv.

Der Mechanismus, aus der Dokumentation:

  • NVLS ist NVLink SHARP: In-Network-Reduction, ausgelagert in die NVSwitch-Domaene; NCCL unterstuetzt es seit 2.17 auf NVSwitch der dritten Generation mit Hopper oder neuer8.
  • Der Default ist lautlos: NCCL_NVLS_ENABLE steht default auf 2 (Auto-Detection). Wenn NVLink-SHARP-Ressourcen nicht allokiert werden koennen, faellt NCCL ohne Fehler auf einen langsameren Algorithmus zurueck; NCCL 2.27.3 fuegte den grazilen Fallback hinzu, mit NCCL_NVLS_ENABLE=1 bleibt das alte laute Fehlerverhalten9.
  • Die Stille hat im Grossen Gebissen - auf NVIDIAs eigenem Tracker: Der grazile Fallback verursachte einen Hang in einem Trainings-Job groszen Masstabs, weil nicht alle Ranks denselben NVLS-Zustand sahen - einige glaubten, NVLS sei aktiv, waehrend andere lautlos zurueckgefallen waren. Das NCCL-Team schrieb, dass es genau diese Inkonsistenz substantial debuggte, und drehte den Kurs: neuere NCCL-Versionen werfen einen harten Fehler, wenn NVLS aktiviert, aber defekt ist; NCCL_NVLS_ENABLE=0 ist der explizite Opt-out. Ein dokumentierter Ausloeser ist die Erschoepfung der NVSwitch-Multicast-Slots: Die Hardware begrenzt Multicast auf 128 Slots, allokiert pro Sub-Communicator und freigegeben erst mit der Zerstoerung des Communicators10.
  • Der Stack unter NCCL ist version-gebunden: Der Fabric Manager prueft beim Start den geladenen Kernel-Driver-Stack und bricht bei Fehlanpassung ab; HGX-B200/B300-Knoten (NVSwitch der vierten Generation) benoetigen zusaetzlich den NVLSM-Service aus den driver-branch-gematchten nvidia-open- und nvlink5-Paketen11. Der Fabric-Stack bewegt sich als Set - so will es NVIDIAs eigene Paketierung.

Die Arbeitsregeln, die aus der Dokumentation folgen:

  1. Driver + Fabric-Manager + NCCL als Set pinnen - FM ist per Design an die Driver-Version gebunden11.
  2. Mit einem Mini-All-Reduce-Benchmark pruefen, bevor man dem Serving-Stack die Schuld gibt.
  3. NCCL_DEBUG=INFO nennt den Algorithmus, der tatsaechlich lief - dem gemessenen Praefix vertrauen, nicht der angenommenen Topologie.

Die uebertragbare Regel: Auf neuer Silizium-Generation zuerst pruefen, ob der schnelle Pfad aktiv ist - Stille ist ein dokumentierter Fehlermodus des Fabrics.

Anmerkungen zur Ausgabequalitaet

Speculative Decoding mit Verifikation veraendert den Durchsatz, nicht die Ausgabeverteilung: Akzeptierte Tokens sind exakt die Tokens, die das Trunk-Modell produziert haette. Das urspruengliche Speculative-Decoding- Resultat zeigt, dass die Ausgabeverteilung unveraendert bleibt6 - bei MTP-Head genauso wie bei separaten EAGLE-Draft-Modellen.

  • GLM-5.3-Model-Card: 744B/40B-aktiv GlmMoeDsaForCausalLM, Sparse Attention (DSA), 1M-Kontext, eine MTP-Schicht; NVFP4-Checkpoint fuer Blackwell: https://z.ai/blog/glm-5.3

Footnotes

  1. NVIDIA CUDA-GPU-Compute-Capability-Tabelle - B300 (Blackwell Ultra) ist Compute Capability 10.3 (sm_103); SM120 ist die separate Consumer-/Workstation-Blackwell-Familie (RTX-50-Serie, 12.0): https://developer.nvidia.com/cuda/gpus ↩

  2. Z-AI, "GLM-5.3: Frontier Coding with Emergent Cyber Capabilities" ↩

  3. vLLM-MTP-Dokumentation (speculative_config, num_speculative_tokens): https://docs.vllm.ai/en/latest/features/speculative_decoding/mtp/ ↩ ↩2

  4. SGLang-Spekulationsparameter-Referenz - --speculative-algorithm NEXTN (ein Alias von EAGLE): https://docs.sglang.io/docs/advanced_features/speculative_decoding ↩

  5. vLLM Recipes, zai-org/GLM-5.3 - Flaggschiff-FP8-B200-Rezept: TP=8, MTP k=5, fp8_e4m3-KV; NVFP4-Blackwell-Variante (nur Experten NVFP4): https://recipes.vllm.ai/zai-org/GLM-5.3 ↩ ↩2

  6. Yaniv Leviathan, Matan Kalman, Yossi Matias, "Fast Inference from Transformers via Speculative Decoding" (arXiv:2211.17192, ICML 2023) - Speculative-Decoding-Framework; Verifikation laesst die Ausgabeverteilung unveraendert: https://arxiv.org/abs/2211.17192 ↩ ↩2

  7. Xiaoxuan Liu, Jiaxiang Yu, Jongseok Park, Ion Stoica, Alvin Cheung, "Speculative Decoding: Performance or Illusion?" (arXiv:2601.11580) - MTP auf GLM-4.5-Air-106B: k=3-Speedup 1,3-1,8x auf H100; Akzeptanz variiert stark ueber Positionen, Anfragen und Datensaetze; vLLM-Rezept fuer zai-org/GLM-4.5 - num_speculative_tokens 1 fuer optimalen Durchsatz auf GLM-4.5: https://specdecode-bench.github.io/ https://recipes.vllm.ai/zai-org/GLM-4.5 ↩ ↩2

  8. NVIDIA-NCCL-User-Guide - NCCL_NVLS_ENABLE (Default 2, Auto-Detection): https://docs.nvidia.com/deeplearning/nccl/archives/nccl_2283/user-guide/docs/env.html ↩

  9. NCCL-2.27.3-Release-Notes - graziler NVLS-Fallback: https://docs.nvidia.com/deeplearning/nccl/release-notes/rel_2-27-3.html ↩

  10. NCCL-Issue #2077 (NVIDIA/nccl-Tracker) - 128 NVSwitch-Multicast- Slots; NCCL-Team-Kommentar: Der grazile Fallback verursachte einen Hang im grossen Masstab ueber rank-inkonsistenten NVLS-Zustand, daher der harte Fehler bei aktivem, aber defektem NVLS; NCCL_NVLS_ENABLE=0 als Opt-out: https://github.com/NVIDIA/nccl/issues/2077 ↩

  11. NVIDIA Fabric Manager User Guide - FM prueft beim Start den geladenen Kernel-Driver-Stack und bricht bei Inkompatibilitaet ab; HGX B200/B300 (NVSwitch der vierten Generation) benoetigt den NVLSM-Service aus nvidia-open/nvlink5-Paketen: https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html ↩ ↩2