NVIDIAが強化学習の重み再配置（refit）向けにReshardコレクティブを提案：自社ベンチマークでrefit遅延は2.7〜5.7倍短縮、ただし測ったのはrefitのみでエンドツーエンドの学習ではなく、NeMo RLでは実験的機能でMegatron学習バックエンドが必要

2026年11月6日、NVIDIAのエンジニアは、Reshardコレクティブに関する技術記事を公開しました。強化学習（RL）の後学習のうち、新しいモデルの重みを学習用GPUから推論用GPUへコピーする1つの段階を速めるための通信呼び出しです。著者はこの段階をrefitと呼んでいます。記事はあわせて、NVIDIA/nccl-extensionsリポジトリにあるオープンソースの参考実装NCCL M2N Reshardと、NeMo RLフレームワークでの利用経路も紹介しています。すべての所要時間はNVIDIA自身の数字で、同社の環境で測ったものです。

問題は規模です。学習と推論を分けるRL構成では、学習と推論が別のGPUで動き、推論側は更新されたポリシーを頻繁に受け取らなければなりません。両者はデータ、テンソル、エキスパート、パイプラインの並列化が異なり、モデルの分割の仕方が違います。通常の方法はギャザーしてブロードキャストする方式で、学習GPUが各パラメーター全体を集めて配り、各推論GPUは必要なシャードだけを残します。NVIDIAの見積もりでは、これでモデルの重みサイズの約2倍が動きます。BF16の重みでは、Kimi K3（2.8兆パラメーター）が5.6 TB、Qwen 3.8 2.4T A95Bが4.8 TBで、論理的な通信量はそれぞれ約11.2 TBと9.6 TBになり、記事は、これが学習の各ステップで必要になると述べています。

発想は、両方のレイアウトをPyTorchのDTensor（デバイスメッシュと配置）として記述し、refitを1つのDTensorから別のDTensorへの再分割として扱うことです。Reshardは、元と先のシャードが重なる部分だけを送ります。NCCL M2N Reshardはさらに、送り先のレプリカをNVLinkドメインごとにまとめます。図の4つの送り先GPUが同じNVLinkドメインにある例では、各シャードがネットワークを1回通って受信GPUが残りをNVLinkで交換します。複数ドメインにまたがる場合はドメインごとに転送し、2つの段階はパイプライン化されます。NeMo RLでNVIDIAはハイブリッド設計を採っています。最近のモデルでパラメーターの約95%を占めるとされるフィードフォワード投影の重みはreshardの経路を通り、QKV投影やMambaの重みのような小さな重みは、網羅性を保つためギャザーしてブロードキャストする方式のままです。

報告された結果は、NeMo RLで測った4つのrefit遅延です。NVIDIA DGX H100では、Qwen 3 235Bが6.4秒から1.9秒に、DeepSeek v3 671Bが14.9秒から2.6秒に下がります。NVIDIA DGX GB200では、DeepSeek v3 671Bが6.1秒から2.3秒に、Nemotron Ultra v3が8.2秒から2.3秒に下がります。記事は2.7倍から5.7倍の高速化を述べ、表の数字もこの範囲に合っています。別のrefitのみのマイクロベンチマークでは、Qwen3.8 2.4TのBF16モデルを4.3秒で移しましたが、そのモデルについてギャザーしてブロードキャストする方式の時間は示されておらず、比は出せません。 原表の学習→推論レイアウトは、H100 NVL8のQwen 3 235BがTP4×PP8×EP16→TP8×DP16（6.4→1.9秒）、H100 NVL8のDeepSeek v3がPP16×EP16→TP32×DP8（14.9→2.6秒）、GB200 NVL72のDeepSeek v3が同じ配置（6.1→2.3秒）、GB200 NVL72のNemotron Ultra v3がTP8×EP32×PP2→TP8×DP8（8.2→2.3秒）です。

数字は、何を測っているかを踏まえて読む必要があります。これはrefitの遅延であり、学習のスループットや目標報酬に達するまでの時間ではなく、RLの各ステップでrefitが占める割合も示されていないため、2.7倍から5.7倍をエンドツーエンドの高速化に換算できません。比較対象はNVIDIA自身の従来の経路で、他のフレームワークの他のrefit手法ではありません。2つのNVIDIAシステム上の4構成は小さな集合で、実行ごとのばらつきも示されておらず、当方はそのいずれも再現していません。

NeMo RLのドキュメントは制限を補います。`nccl_reshard_refit`は実験的と表示されています。設定は`refit_transport: nccl_reshard`で、同居しない構成でのみ動くため`policy.generation.colocated.enabled`をfalseにします。Megatronの学習バックエンドと、vLLMまたはMegatronの生成バックエンドが必要で、SGLangとTRTLLMはまだ非対応とされています。vLLMが送り先の場合は、エキスパートのテンソル並列サイズが1である必要があります。記事は、障害復旧中にノードが加わったり抜けたりすると、NeMo RLは現在は通信グループを破棄して作り直し、NCCLのshrinkとgrow APIを使う対応は今後の予定だと付け加えています。

当方の見方では、これは実際の数字を伴う信頼できる技術的な発想で、refitのコストはモデルが大きくなるほど増えるため、この抽象化は有用です。MegatronとvLLMを使い、学習と生成のリソースを同居させない構成で非常に大きなMixture-of-Expertsモデルを学習するチームは、実験的フラグから試せます。それ以外のチームは、より広いバックエンドの対応を待ち、自分のステップ時間のうちrefitが占める割合を測り、見出しの高速化の数字は保証ではなく最良の場合のヒントとして扱うべきです。