Rollplex、VLM強化学習のプレフィックス計算をrolloutの空き時間に組み込み、32基のH800で最大1.30倍の学習高速化

視覚言語モデルの強化学習ワークロードは、テキストのみの場合とは異なる。論文で評価された4種類の動画タスクでは、サンプル内のtokenに占めるpromptの割合の中央値が79%〜98%に達し、視覚エンコードとprefillはもはや小さな前処理コストではない。従来の同期パイプラインでは、rollout、参照モデルによるスコアリング、actorのforward／backward pass、重み更新を依然として順番に実行するため、デコード中に十分活用されていない演算ユニットへ後続処理を割り当てられない。

[Rollplexの論文](https://arxiv.org/abs/2608.14498)では、各モデルフェーズを、生成結果に依存しないprefixと、response tokenを待つ必要があるsuffixに分割する。参照モデルと学習用actorのprefixはrollout decodeと同時に実行でき、生成完了後は、保持しておいた境界のKV stateからsuffixの処理を再開する。すべての計算には同一のactor snapshotが使われ、古いpolicyや推測されたresponseは使用しないため、同期on-policy更新の順序は緩和されない。

単純なコロケーションは実現できない。Qwen2.5-VL-32Bでは、重み、勾配、Adam state、学習用activation、3組のKV cache、workspaceを合わせると、GPU 1基当たり約165 GiBが必要となり、H800の80 GBを超える。RollplexはCUDA Virtual Memory Managementを使って仮想アドレスを予約し、データのproducerから最後のconsumerまでの期間に限ってHBMの物理ページを割り当てる。activationはoffloadまたは再計算が可能で、FP32 optimizer stateはチャンク単位でストリーミング処理する。もう一つの仕組みでは、重みをtensor layout別に分類する。同一の分割形式なら直接aliasし、転置可能なものは論理viewとして共有する。コピーと再配置が必要なのは、fused QKVなど互換性のないlayoutだけだ。これにより、学習ではTP=8、rolloutではTP=4を採用しながら、actorの完全な複製を別途保持する必要がない。

著者らは、32基のH800、Qwen2.5-VL-32B、4種類の動画推論タスクを用いた評価で、逐次コロケーション構成に対して1.23〜1.30倍、分離デプロイ構成に対して1.57〜2.24倍の高速化を報告している。[ROLL](https://github.com/alibaba/ROLL)自体はすでにオープンソース化され、Megatron-Core、vLLM、Rayと統合されているが、現時点の公開main branchには、Rollplexの完全な実装をそのまま再現できることを示す明確な記載がない。エンジニアリングチームは今後、コードの公開状況、host offloadのPCIe／NUMAに対する感度、さらにモデルサイズ、動画の長さ、より高速なデコードkernelによってオーバーラップ可能な時間枠が変化した場合にも、効果を維持できるかを注視する必要がある。