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

Multi-Token-Prediction in Produktion ist ein Akzeptanzraten-Problem. Dieser Beitrag sind unsere Tuning-Notizen aus dem Betrieb eines GLM-MoE auf 8x B300 (SM120): was Spekulationstiefe bringt, wenn man die kumulative Akzeptanzmathematik anwendet, und das NVLink-SHARP-Problem (NVLS), dessen Diagnose eine Woche kostete.

Das Setup

Der MTP-Head von GLM liegt im Checkpoint - eine zusaetzliche Praediktions- Schicht, kein separater Draft-Modell-Download. LMSYS dokumentiert die GLM-4.5-Architektur mit nativem MTP-Head fuer Speculative Decoding¹; vLLM (speculative_config={"method": "mtp", "num_speculative_tokens": k}) und SGLang (--speculative-algorithm NEXTN) konsumieren ihn direkt².

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:

Mit Akzeptanz pro Position von 85%, 67%, 51%, 36%, 31% (T+1..T+5, gemeinschaftlich gemessen an GLM-Quantisierungen auf vLLM) kumuliert die Kette brutal:

k=2 liefert also bereits 1,42 der letztlich 1,85 akzeptierten Tokens - k=2 faengt rund 77 % des k=5-Maximums ein, k=3 rund 92 %. 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 starten².

Unser Fazit fuer Produktion: Workloads mit strukturierten Ausgaben (vorhersagbare Grammatik) akzeptieren tiefere Ketten und vertragen hoeheres k; Prosa nicht. Die Tiefe ist eine per-Workload-Entscheidung, getrieben von gemessenen Akzeptanzraten - erst messen, dann k setzen.

Die verlorene Woche: NVLS auf SM120

Die zweite Geschichte ist ein Fabric-Problem. Beim Bring-up lief der knotenlokale All-Reduce deutlich langsamer, als die Bandbreiten-Mathematik vorhersagt. Ursache: Die Kollektive fielen lautlos vom NVLink SHARP (NVLS) zurueck - und herauszufinden, dass der Fehler lautlos war, kostete rund eine Woche.

Der Mechanismus:

• 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 neuer³.
• 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 eleganten Fallback hinzu, mit NCCL_NVLS_ENABLE=1 bleibt das alte laute Fehlerverhalten⁴.
• Ausloeser war eine Driver-/Fabric-Manager-Fehlanpassung: Pakete, die einzeln funktionierten, aber zusammen nicht passten, liessen die NVLS- Initialisierung lautlos fehlschlagen. Das Kollektiv lief weiter - nur langsamer. Das Symptom war ein Durchsatz-Faktor, kein Crash.

Die Arbeitsregeln, die wir behalten haben:

1. Driver + Fabric-Manager + NCCL als Set pinnen, nicht als drei unabhaengige Versionen.
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 der 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 - die Qualitaet bleibt per Konstruktion erhalten, bei MTP-Head genauso wie bei separaten EAGLE-Draft-Modellen.