NVIDIA schlägt ein Reshard-Kollektiv für das Refit der Gewichte beim Reinforcement Learning vor: Eigene Benchmarks senken die Refit-Latenz um das 2,7- bis 5,7-Fache, messen aber nur Refit und kein Ende-zu-Ende-Training, und die NeMo-RL-Funktion ist experimentell und braucht das Megatron-Trainings-Backend

Am 6. November 2026 haben NVIDIA-Ingenieure einen technischen Beitrag zum Reshard-Kollektiv veröffentlicht, einem Kommunikationsaufruf, der einen Schritt des Nachtrainings per Reinforcement Learning (RL) beschleunigen soll: das Kopieren frischer Modellgewichte von den Trainings-GPUs auf die Inferenz-GPUs. Die Autoren nennen diesen Schritt Refit. Der Beitrag stellt außerdem NCCL M2N Reshard vor, eine quelloffene Referenzimplementierung im Repository NVIDIA/nccl-extensions, und einen Weg dafür im Framework NeMo RL. Alle Zeiten stammen von NVIDIA selbst und wurden auf eigenen Systemen gemessen.

Das Problem ist die Größe. In einem getrennten RL-Aufbau laufen Training und Inferenz auf verschiedenen GPUs, und die Inferenzseite muss die aktualisierte Policy oft erhalten. Beide Seiten teilen das Modell unterschiedlich auf, mit verschiedener Daten-, Tensor-, Experten- und Pipeline-Parallelität. Üblich ist Sammeln und Verteilen: Die Trainings-GPUs sammeln jeden vollständigen Parameter, verteilen ihn, und jede Inferenz-GPU behält nur den Anteil, den sie braucht. NVIDIA schätzt, dass dabei etwa die doppelte Größe der Modellgewichte bewegt wird. Für BF16-Gewichte nennt es 5,6 TB für Kimi K3 (2,8 Billionen Parameter) und 4,8 TB für Qwen 3.8 2.4T A95B, also grob 11,2 TB und 9,6 TB logischen Verkehr, der laut Beitrag bei jedem Trainingsschritt anfällt.

Die Idee ist, beide Anordnungen als PyTorch-DTensor zu beschreiben, als Gerätegitter plus Platzierungen, und Refit als Umverteilung eines DTensors in einen anderen zu behandeln. Reshard sendet dann nur die überlappenden Teile zwischen Quell- und Zielanteilen. NCCL M2N Reshard gruppiert außerdem Ziel-Replikate nach NVLink-Domäne: Im gezeigten Fall mit vier Ziel-GPUs in einer NVLink-Domäne überquert jeder Anteil das Netzwerk einmal und die empfangenden GPUs tauschen den Rest über NVLink aus; bei mehreren Domänen wird je Domäne eine Kopie weitergeleitet, wobei beide Schritte überlappend laufen. In NeMo RL wendet NVIDIA einen hybriden Entwurf an. Feed-Forward-Projektionsgewichte, die laut Beitrag in neueren Modellen etwa 95 % der Parameter ausmachen, nehmen den Reshard-Weg, kleinere Gewichte wie die QKV-Projektion oder Mamba-Gewichte behalten das Sammeln und Verteilen, damit die Abdeckung vollständig bleibt.

Die berichteten Ergebnisse sind vier in NeMo RL gemessene Refit-Latenzen. Auf NVIDIA DGX H100 fällt Qwen 3 235B von 6,4 s auf 1,9 s und DeepSeek v3 671B von 14,9 s auf 2,6 s. Auf NVIDIA DGX GB200 fällt DeepSeek v3 671B von 6,1 s auf 2,3 s und Nemotron Ultra v3 von 8,2 s auf 2,3 s. Der Beitrag nennt eine Beschleunigung von 2,7x bis 5,7x, und die Tabelle stimmt mit dieser Spanne überein. Ein separater reiner Refit-Mikrobenchmark bewegte das BF16-Modell Qwen3.8 2.4T in 4,3 Sekunden, doch der Beitrag nennt für dieses Modell keine Zeit für Sammeln und Verteilen, also gibt es dafür kein Verhältnis. Die Trainings→Inferenz-Anordnungen der Tabelle lauten: H100 NVL8 Qwen 3 235B TP4×PP8×EP16→TP8×DP16 (6,4→1,9 s); H100 NVL8 DeepSeek v3 PP16×EP16→TP32×DP8 (14,9→2,6 s); GB200 NVL72 DeepSeek v3 mit derselben Anordnung (6,1→2,3 s); GB200 NVL72 Nemotron Ultra v3 TP8×EP32×PP2→TP8×DP8 (8,2→2,3 s).

Die Zahlen sind so zu lesen, wie sie gemessen sind. Es sind Refit-Latenzen, kein Trainingsdurchsatz und keine Zeit bis zu einer Zielbelohnung, und der Beitrag sagt nicht, welchen Anteil jeder RL-Schritt auf Refit entfällt; wir können 2,7x bis 5,7x daher nicht in eine Ende-zu-Ende-Beschleunigung umrechnen. Verglichen wird mit NVIDIAs eigenem herkömmlichem Weg, nicht mit anderen Refit-Methoden in anderen Frameworks. Vier Konfigurationen auf zwei NVIDIA-Systemen sind eine kleine Menge, der Beitrag nennt keine Streuung zwischen Läufen, und wir haben nichts davon nachgemessen.

Die NeMo-RL-Dokumentation ergänzt die Grenzen. Sie kennzeichnet `nccl_reshard_refit` als experimentell. Die Einstellung ist `refit_transport: nccl_reshard` mit `policy.generation.colocated.enabled` auf false, weil sie nur in einem nicht gemeinsam platzierten Aufbau funktioniert. Sie verlangt das Trainings-Backend Megatron und ein Generierungs-Backend vLLM oder Megatron und sagt, SGLang und TRTLLM würden noch nicht unterstützt. Ein vLLM-Ziel braucht weiterhin die Experten-Tensor-Parallelgröße 1. Der Beitrag fügt hinzu, dass NeMo RL bei Knotenänderungen während der Fehlerbehebung derzeit die Kommunikationsgruppe zerstört und neu erstellt; die Nutzung der NCCL-APIs shrink und grow ist für später geplant.

Unsere Einschätzung: Das ist eine glaubwürdige technische Idee mit echten Zahlen, und die Abstraktion ist nützlich, weil die Refit-Kosten mit der Modellgröße wachsen. Teams, die sehr große Mixture-of-Experts-Modelle mit Megatron und vLLM mit getrennt platzierten Trainings- und Generierungsressourcen trainieren, könnten es ausprobieren, beginnend mit dem experimentellen Schalter. Andere sollten auf breitere Backend-Unterstützung warten, messen, welchen Anteil ihrer Schrittzeit Refit ausmacht, und die Schlagzeilen-Beschleunigung als Hinweis auf den Bestfall statt als Garantie behandeln.