GLM-5.3-MTP auf B300: Akzeptanzmathematik und NCCL NVLS

Multi-Token-Prediction (MTP) hängt von Akzeptanzraten und Kosten ab. Dieser Artikel nutzt ein GLM-5.3-Setup auf acht B300-GPUs (Blackwell Ultra, sm_103)¹ als Konfigurationsbeispiel. Die Raten in der Tabelle sind illustrative Eingaben, keine Messwerte. Außerdem beschreibt er das dokumentierte NVLink-SHARP-(NVLS-)Verhalten verschiedener NCCL-Versionen.

Das Setup

Der MTP-Head von GLM liegt im Checkpoint – eine zusätzliche Prädiktions- Schicht, kein separater Draft-Modell-Download. Die veröffentlichte Konfiguration von GLM-5.3 deklariert ein Sparse-Attention-MoE (GlmMoeDsaForCausalLM), ein Kontextlimit von 1.048.576 Tokens und eine MTP-Prädiktionsschicht². vLLM (speculative_config={"method": "mtp", "num_speculative_tokens": k})³ und SGLang (--speculative-algorithm NEXTN)⁴ können ihn nutzen. Das vLLM-Rezept für GLM-5.3 zeigt ein FP8-Setup mit acht GPUs, TP=8, MTP k=5 und --kv-cache-dtype fp8_e4m3. Eine separate NVFP4-Variante quantisiert die gerouteten Experten; Attention, Shared Experts und Dense- Layer bleiben BF16⁵. Das sind dokumentierte Konfigurationen, keine Benchmark-Ergebnisse aus diesem Repository.

Akzeptanzmathematik: Tokens pro Schritt, nicht Durchsatz

Akzeptanzwahrscheinlichkeiten bestimmen die erwartete Tokenzahl pro Verifikationsschritt; Draft- und Verifikationskosten bestimmen zusätzlich den Durchsatz. Wenn $a_j$ die Akzeptanzwahrscheinlichkeit an Position $j$ unter der Bedingung ist, dass alle vorigen Positionen akzeptiert wurden, ist $p_i=\prod_{j=1}^{i}a_j$ die Wahrscheinlichkeit, bis Position $i$ zu akzeptieren. Das Verfahren wurde von Leviathan, Kalman und Matias beschrieben; der Verifikator bewahrt die Zielverteilung⁶:

vLLM kann in log_stats die Mean acceptance length, akzeptierte und gedraftete Tokens sowie die Per-position acceptance rate ausgeben⁷. Die folgenden gemeinsamen Wahrscheinlichkeiten $p_i$ sind hypothetisch. Sie zeigen nur die Rechnung und belegen keine GLM-5.3-Leistung:

In diesem Beispiel liefert k=2 rund 64 % der Tokens pro Schritt von k=5, k=3 rund 77 %. Diese Anteile sind keine gemessenen Speedups. Sie hängen von den tatsächlichen Akzeptanzraten des Workloads ab. Öffentliche Messungen zeigen Unterschiede zwischen Datensätzen und Positionen bei GLM-MTP-Modellen; das vLLM-Rezept für das kleinere GLM-4.5 empfiehlt auf jenem Modell weiterhin num_speculative_tokens 1 für optimalen Durchsatz⁸, das GLM-5.3-Rezept führt k=5 als Konfigurationsbeispiel⁵.

Tiefere Spekulation liefert zusätzliche Tokens, während jede Draft-Position Kosten verursacht:

• Verlorene Verify-Arbeit: ein abgelehnter Draft belegte trotzdem einen Verify-Slot.
• Verworfene spätere Drafts: Wird eine Position abgelehnt, können spätere Positionen desselben Drafts nicht akzeptiert werden. Ihre Generierung und Verifikation kann Arbeit kosten, ohne Ausgabetokens hinzuzufügen.
• KV-Cache-Druck: num_speculative_tokens reserviert KV-Einträge pro Anfrage für Draft-Positionen; die vLLM-Doku empfiehlt, klein zu starten³.

Die Tiefe ist eine per-Workload-Entscheidung, getrieben von gemessenen Akzeptanzraten - öffentliche Benchmarks finden, dass Akzeptanz über Datensätze, Anfragen und Positionen hinweg stark variiert⁸. Erst messen, dann k setzen – die oben genannten log_stats-Werte dienen dazu.

NVLS-Fehlerverhalten hängt von der NCCL-Version ab

NVLS-Initialisierungsfehler hatten nicht in jeder NCCL-Version dieselbe Folge: Manche Versionen weichen auf ein anderes Kollektiv aus, andere geben einen Fehler zurück. Das Verhalten muss für die installierte Version geprüft werden.

Der Mechanismus, aus der Dokumentation:

• NVLS ist NVLink SHARP: In-Network-Reduction, ausgelagert in die NVSwitch-Domäne; NCCL unterstützt es seit 2.17 auf NVSwitch der dritten Generation mit Hopper oder neuer⁹.
• Fallback in NCCL 2.27.3: NCCL_NVLS_ENABLE steht standardmäßig auf 2 (automatische Erkennung). Diese Version führte einen Fallback bei fehlgeschlagener NVLS-Initialisierung ein; mit NCCL_NVLS_ENABLE=1 blieb ein Fehler die Folge¹⁰.
• Dokumentierter harter Fehler in NCCL 2.29.7: Issue #2077 beschreibt erschöpfte Multicast-Slots auf einem Acht-H200-System. Der Melder beobachtete einen fatalen ncclUnhandledCudaError mit NVLS und einen erfolgreichen Lauf mit NCCL_NVLS_ENABLE=0. Der Bericht nennt eine Hardwaregrenze von 128 Slots; daraus folgt kein allgemeines Verhalten für alle NVLS-Fehler oder NCCL-Versionen¹¹.
• Der Stack unter NCCL ist version-gebunden: Der Fabric Manager prüft beim Start den geladenen Kernel-Driver-Stack und bricht bei Fehlanpassung ab; HGX-B200/B300-Knoten (NVSwitch der vierten Generation) benötigen zusätzlich den NVLSM-Service aus den driver-branch-gematchten nvidia-open- und nvlink5-Paketen¹². 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 gebunden¹².
2. Mit einem Mini-All-Reduce-Benchmark pruefen, bevor man dem Serving-Stack die Schuld gibt.
3. NCCL-INFO-Logs einschließlich der passenden Debug-Subsysteme für Kollektive und NVLS zur Prüfung der Algorithmuswahl nutzen, soweit verfügbar¹³; den Pfad mit einem gemessenen Probelauf bestätigen.

Die übertragbare Regel: Schnellen Pfad und Fehlerverhalten mit der installierten NCCL-Version prüfen.

Anmerkungen zur Ausgabequalität

Exaktes Speculative Decoding mit passendem Verifikator und Rejection Sampling erhält die Ausgabeverteilung des Zielmodells⁶. Es garantiert bei stochastischem Sampling nicht dieselbe Tokenfolge wie ein separater Durchlauf des Zielmodells. Bei einer Serving-Implementierung müssen die Voraussetzungen für dieses Exaktheitsresultat geprüft werden.