なぜ重み同期が「1兆パラメタの壁」になっていたのか

RLHFやRLAIFのような強化学習ベースのポストトレーニングでは、ポリシー（学習対象モデル）が更新されるたびに、rolloutを担う推論ワーカー群へ最新重みを配布する必要がある。モデルが1兆パラメタ級になると、この重み同期そのものがクラスタ内のネットワークとI/Oを支配し、GPU稼働率を押し下げる主因となっていた。従来のNCCL等によるノード間直結の同期は、学習ノードとrolloutノードを密結合に保つ前提でしか成立せず、両者の台数比を柔軟に変えづらいという制約も抱えていた。

Delta Weight SyncとHub Bucketという設計選択

今回TRLに導入された Delta Weight Sync は、フル重みではなく差分（delta）をHugging Face Hub上のバケットに書き出し、rollout側がそこから取得する構成を取る。ストレージを介した非同期配信に振り切ることで、学習側と推論側を疎結合化し、台数比・地理配置・更新頻度を独立に設計できるようにする狙いだ。OSSの標準スタックであるTRLにこの配信パスが組み込まれた意味は大きく、これまで自前で同期基盤を組んでいたチームにとっては、内製を続ける合理性が問われる転換点になる。

落とし穴: Hub依存と配信経路の可視化

一方で、重み配信の経路がHugging Face Hubに寄る構成は、帯域コスト・ストレージ費用・障害時の代替経路を運用設計に織り込む必要を生む。重みの所在管理が必要な組織では、配信ログの取得可否や、社内ミラーへのフォールバック条件を事前に定義しておかないと、ポストトレーニング基盤が単一の外部依存に縛られる。導入時はまず、現行RLHFパイプラインの同期所要時間と帯域実測を取り、Delta方式に置換した場合の境界条件を測ることから始めるのが現実的だ。