Anyscale、SkyRL で FP8 学習・ロールアウトをサポートし一貫性を維持

SkyRL は現在、オンポリシー重み同期を伴う FP8 によるトレーニングとロールアウトをサポートしています。長期の RL 実験において、FP8 設定は BF16 の収束曲線にほぼ追従しつつ、エンドツーエンドのステップ時間を最大 23% 短縮します。

TL;DR. SkyRL は、強化学習スタックのうち性能が重要な部分全体で FP8 をサポートしています。具体的には、トレーニング中の線形層 GEMM、ロールアウト時のモデル重みと KV キャッシュ、そしてトレーナーと vLLM の間の重み転送です。システム上の大きな変更点は、トレーナーから生成された FP8 ペイロードとブロックスケールをロールアウトエンジンへ直接転送する同期パスの実装です。これにより、ロールアウトポリシーが変化してしまう可能性のある「非量子化→再量子化」の境界線を回避しています。

長期 RL 実行では、FP8 設定は Qwen3.5-9B（8×H100）および Qwen3.5-35B-A3B（8×B200）において BF16 の収束にほぼ追従し、ブロックワイズ方式と MXFP8 レシピの両方に対応しています。評価された長期ロールアウト構成では、エンドツーエンドのステップ時間がそれぞれ最大約 19% と 23% 改善しました。また、FP8 パラメータの保存により、GPU ごとのトレーナー重みメモリ使用量は 39〜42% 削減されます。

精度のスコープ。 この記事における「FP8」とは、線形層計算の FP8 加速、主要な FP8 重み、ロールアウト用の FP8 重みと KV キャッシュ、そして FP8 対応の重み同期を指します。精度に敏感なテンソル（ノルムや埋め込みベクトルなど）、アテンション機構、およびオプティマイザの状態は BF16 または FP32 で維持されます。具体的には、Hopper アーキテクチャではブロックワイズレシピを、Blackwell アーキテクチャでは MXFP8 レシピを使用します。

モデル構成

本実験ではすべて Qwen3.5 シリーズ（Qwen3.5-4B、Qwen3.5-9B、Qwen3.5-35B-A3B）を使用しています。これらはハイブリッドアテンションモデルであり、一部の層にはゲート付きデルタネットワーク（GDN）線形アテンションが採用されています。

リンク：なぜ強化学習に FP8 が重要なのか

多くのオンポリシー RL ワークロードでは、ここで評価した構成を含め、ロールアウト生成がエンドツーエンドの処理時間の大きな割合を占めます。その後、トレーニングでは生成されたトークンに対して順伝播と逆伝播が行われます。

両フェーズとも、FP8 を採用することで異なるメリットを得られます。トレーニングでは低精度な GEMM（一般行列乗算）により演算スループットが向上し、ロールアウトではデータ表現サイズが小さくなるためメモリアクセス量や KV キャパシティの要件が軽減されます。

Hopper および Blackwell の Tensor Core において、FP8 は BF16 と比べて最大で 2 倍の行列乗算スループットを提供し、かつ各 FP8 値は記憶領域を半分しか消費しません。さらにメモリフットプリントを削減し、モデル重みの読み込み速度を向上させるため、トレーニング側のポリシーモデル重みに対して FP8 量子化を適用できます。これにより、BF16 のコピーを完全に排除し、FP8 モデルパラメータと FP32 マスターウェイトのみを保持します。この手法は一般的に *fp8_param* と呼ばれています。

最近の研究でも同様の結論が得られています。LMSYS の「Unified FP8」では、トレーニングと推論で一貫した FP8 スキームを使用することで、混合精度の強化学習（RL）で生じるトレーニングとロールアウト間の対数尤度差を削減できることが示されています。NVIDIA NeMo RL も、評価対象となった Hopper 設定において、精度をほぼ維持しつつステップ実行時間を 15〜25% 短縮できると報告しています。両者とも、DeepSeek-V3 で採用されている微細なブロックスケーリング手法を基盤としており、テンソル全体に単一のスケール値を適用するのではなく、重みに対して 128×128 のスケーリングブロックを使用しています。

私たちの実験では、FP8 をトレーニング側とロールアウトエンジン側で個別に有効化するだけでは不十分であることがわかりました。強化学習では、ポリシーを通じて両システムが密接に結合されています。つまり、サンプリングされた軌道（トラジェクトリ）を生成したのと同じポリシーを、許容範囲内の数値誤差の範囲内でトレーニング側も最適化しなければならないのです。

独立した量子化がポリシーの一貫性を崩す場合

最も単純な初期構成としては、Megatron で Transformer Engine (TE) の FP8 を有効化し、TE が推奨するテンソルごとの遅延スケーリング方式を採用し、vLLM では quantization="fp8" と設定することが考えられます。しかし、Qwen3.5-4B を DAPO で実行した際、この構成では 70 ステップ以内に不安定化してしまいます。報酬は BF16 ベースラインを下回り続け、ポリシーのエントロピーはゼロに近づき、平均の重要性サンプリング比は 1.0 ではなく 0.75 のままとなり、PPO クリップ比も BF16 実行時の 10 倍以上に達してしまいます。

図 1：Qwen3.5-4B における DAPO 使用時の Naive FP8 と BF16 の比較。FP8 設定では報酬の停止、エントロピーの低下、1 からかけ離れた重要性サンプリング比、そして著しく高いクリップ比率が観測されます。

*Figure 1 Naive FP8 and BF16 on Qwen3.5-4B with DAPO. The FP8 configuration exhibits stalled reward, declining entropy, an importance-sampling ratio far from 1, and a substantially elevated clip ratio.*

根本原因は、重みの同期における量子化のミスマッチです。この失敗は FP8 の計算パス単独の問題ではなく、2 つのエンジン間のインターフェースで発生しています。

Megatron と TE は、量子化された FP8 重みとスケーリングメタデータを用いてトレーニングを行います。ブロックワイズレシピでは 128×128 ブロックごとに、MXFP8 レシピでは 1x32 ブロックごとに 1 つのスケーラーが設定されます。

重みの同期中、従来のブリッジは重みを BF16 に復元し、BF16 の値のみを転送して、トレーニング側の FP8 スケーリングメタデータを破棄します。その結果、vLLM は受け取った BF16 値を独自に量子化して FP8 値に変換しますが、これは Megatron が使用していた FP8 重みとは異なるものになります。これは、両者が異なる量子化レシピを採用しているためです。

この一連の処理は、独立して選択されたスケーラーを用いた 2 つの可逆変換（ロスのある変換）から構成されています。その結果生じるロールアウト用の重みは、トレーニング側の量子化表現とも、高精度なチェックポイントとも完全に一致しません。これはオフポリシーな重みの同期であり、ロールアウトエンジンがサンプリングしているのは、トレーニング側が一度も保持したことがない方策です。

ブロックワイズレシピにおいて、4B モデルのすべての量子化された重みについて計算すると、トレーニング側とロールアウト側の FP8 重みの間の平均相対誤差は 0.038 です。これは、それぞれの表現が BF16 チェックポイントに対して持つ量子化誤差の約 1.4 倍に相当します。各エンジンの量子化誤差自体は許容範囲内ですが、問題となるのはエンジン間の不一致です。トレーニング側はある数値の方策を更新する一方で、ロールアウトエンジンは別の方策からサンプリングしており、これは重要性サンプリングやクリッピングの診断結果にも反映されています。

図 2：オフポリシー重み同期（元のパス）。ブリッジは、トレーナーのブロックスケールメタデータなしで BF16 値をエクスポートし、その後 vLLM が新しい FP8 表現を導出します。

*Figure 2 Off-policy weight sync, the original path. The bridge exports BF16 values without the trainer-s block-scale metadata, after which vLLM derives a new FP8 representation.*

LinkOn-Policy FP8 weight sync

SkyRL では重み同期の仕組みを再設計し、vLLM がトレーナーが生成した FP8 表現を直接利用できるようにしました。これをオンポリシー重み同期（OPWS）と呼びます。これは、ロールアウトエンジンが再量子化された近似値ではなく、トレーナーが更新しているのと同じ数値上のポリシーを実行することを意味します。

図 3：量子化されたパラメータはブロックスケール付きで FP8 ペイロードとして転送され、精度に敏感なテンソルは BF16 のまま維持されます。vLLM は独立した量子化器を呼び出すことなく、転送された表現をインストールします。

*Figure 3 Quantized parameters are transferred as FP8 payloads with their block scales, while precision-sensitive tensors remain in BF16. vLLM installs the transferred representation without invoking an independent quantizer.*

この手法により、同期後のトレーニング用重みとロールアウト用重みはビット単位で完全に一致します。つまり、ロールアウトエンジンが受け取る FP8 値とスケール係数は、トレーニング側から生成されたものと同一です。

残る学習・ロールアウト間の対数尤度差は、活性化関数の量子化やカーネルレベルの数値計算の違いに起因するものです。Qwen3.5-9B を対象とした 400 ステップのランでは、トークンあたりの平均絶対誤差が 0.02 から 0.03 の範囲で推移し、時間経過とともに拡大することはありません。これは、BF16 エンジンの二つのパス間で観測される誤差の約 3 倍に相当し、カーネルの違いだけで生じる実用的な下限値を示しています。

一方、FP8 に独立して量子化するロールアウトエンジンと BF16 トレーナーを組み合わせる場合、初期段階で誤差が大きく、400 ステップでは 0.05 を超えます。これは、同期のたびに発生する量子化の不整合が蓄積していることを示す傾向です。

Figure 4: Qwen3.5-9B におけるロールアウトエンジンとトレーニング間のトークンあたりの平均絶対対数尤度差。

*Figure 4 Mean absolute per-token log-probability difference between the rollout engine and trainer on Qwen3.5-9B.*

実験範囲

比較の核心は、シードとデータ順序を一致させた上で行われます。

DAPO の設定では、プロンプトを 32 個使用し、各プロンプトあたり 8 サンプルずつ生成します。バッチごとのオプティマイザーステップは 1 つで、学習率は AdamW を用いて 1e-6 に固定しています。また、勾配ノルムクリップの閾値は 1.0 です。ステップごとの比較では、応答長を一致させることで、ポリシー行動の違いがシステム測定結果に混入しないようにしています。

OPWS を有効にした状態で、FP8 学習における GEMM（行列積演算）、FP8 rollout 時の重みおよび KV キャッシュ、そして FP8 対応の重み転送について、400 ステップの一致したランで評価を行いました。

Qwen3.5-9B dense on 8xH100

Figure 5: Qwen3.5-9B on 8×H100. Reward and pass@8 track BF16 over 400 DAPO steps.

*Figure 5 Qwen3.5-9B on 8×H100. Reward and pass@8 track BF16 over 400 DAPO steps.*

Qwen3.5-35B-A3B MoE on 8xB200

Figure 6: Qwen3.5-35B-A3B on 8×B200. Reward and pass@8 track BF16 over 400 DAPO steps.

*Figure 6 Qwen3.5-35B-A3B on 8×B200. Reward and pass@8 track BF16 over 400 DAPO steps.*

両構成において、FP8 と BF16 の報酬曲線は 400 ステップの期間でほぼ重なり合っています。また、反復サンプリングによる pass@8 の軌道も同様の解決率に達しており、平均報酬とは異なる視点から補完する結果となっています。

レスポンス長はポリシーの乖離を示す敏感な指標であると同時に、ステップ時間にも影響を与えますが、両モデルとも FP8 と BF16 の実行間でほぼ整合しています。

図 7：両モデルの平均レスポンス長。FP8 と BF16 は整合しているため、ステップ時間の比較は生成長を一致させた状態で行われます。

*Figure 7 Mean response length for both models. FP8 and BF16 stay aligned, so the step-time comparison is made at matched generation lengths.*

LinkPerformance analysis

FP8 を採用しても自動的に RL のステップ時間が短縮されるわけではありません。量子化、スケーリング管理、ディスパッチにはオーバーヘッドが生じ、生成とトレーニングではこれらのコストに対する反応が異なります。

生成：メモリ転送量の低下がレイテンシ低減につながる

自己回帰的なデコーディングは、主にメモリ帯域幅に制約されます。各デコーディングステップでは、比較的小さな演算処理を行う一方で、モデルの重みを読み込み、アクティブな KV キャッシュをストリーミングします。FP8 を採用することで両者の表現サイズが削減され、同じ応答長において生成フェーズの効率が向上します。

OPWS（Online Policy Weight Synchronization）では、ロールアウト時の再量子化も不要になります。重みとスケールは次の同期まで固定されたままとなり、活性化の量子化は GEMM カーネルに統合されます。また、デコーディングはキャプチャされた CUDA グラフを通じて再生されるため、ホスト側のオーケストレーション経路は FP8 と BF16 のロールアウト構成間で同等になります。

図 8: Qwen3.5-9B の応答長を一致させた場合のステップ分解。"KL on"とラベルされた行には、参照モデルによる順方向パスが含まれています。

*Figure 8 Step decomposition at matched response lengths for Qwen3.5-9B. Rows labeled "KL on" include a reference-model forward pass.*

トレーニング：GPU の節約効果はホストのオーバーヘッドによって相殺される

トレーニングでは各重みが数千トークンにわたって再利用されるため、計測されたフェーズはデコードよりも計算集約度が高くなります。GPU カーネルは FP8 の恩恵を受け、GEMM 実行時間が 14.2 秒から 10.9 秒へ短縮され、FP8 パラメータの all-gather による NCCL 時間も 9.8 秒から 6.4 秒に削減されました。その結果、トレーニングフェーズあたりの総 GPU カーネル実行時間は 36.5 秒から 32.0 秒へと減少しました。

一方、オーバーヘッドはホスト側に発生します。ロールアウトの重みとは異なり、トレーニング用の重みはオプティマイザステップごとに更新されるため、TE はブロックスケールを算出しつつ、行方向の FP8 表現と逆伝播計算で用いられる転置表現の両方を維持する必要があります。この処理を当初 64 のマイクロバッチにわたって繰り返していたため、トレーナーはホスト割り当てがボトルネックとなるパスに陥っていました。マイクロバッチサイズを増大させ、割り当て最適化を適用したことで、ホスト側の処理時間が 52.9 秒から 16.9 秒へと大幅に短縮されました。

図 9：カテゴリ別トレーニングカーネル時間（FP8 と BF16 の比較）。FlashAttention および GDN の処理時間は変化しません。これは、評価されたブロック単位のレシピが線形層の GEMM にのみ FP8 を適用し、アテンション計算は両方の構成で BF16 のまま維持されるためです。

全体として、トレーニングフェーズの所要時間は 45.6 秒から 44.0 秒へと短縮され、現在の H100 実装ではトレーニングにかかる時間はほぼ同等となりました。したがって、全体の改善は主にロールアウト生成からの寄与によるものです。Qwen3.5-9B を 8 基の H100 で使用した場合、応答長を一致させた条件下で、ステップあたりの総所要時間は BF16 の 0.81〜0.90 倍となりました。観測された最も大きな短縮率は、長いロールアウトにおいて約 19% です。

図 10：Qwen3.5-9B を 8 基の H100 で使用した際のエンドツーエンドのステップ時間（応答長別）。ロールアウトが長くなるほど FP8 の優位性は高まります。

Qwen3.5-35B-A3B を 8 台の B200 GPU で実行した場合、観測されたエンドツーエンドの処理時間短縮率は最大約 23% です。この改善は主に生成プロセスによるものです。

SkyRL では、Hopper アーキテクチャではブロックごとの FP8（FP8）を、Blackwell アーキテクチャではサポートされている場合にネイティブな MXFP8 を選択するために fp8_recipe="auto" を使用します。

図 11: Qwen3.5-35B-A3B を使用した 8×B200 のエンドツーエンドステップ時間。

*Figure 11 End-to-end step time on 8×B200 with Qwen3.5-35B-A3B.*

LinkDeep dive: FP8 quantization with FP32 and power-of-two block scales

Hopper アーキテクチャでは、TE（Tensor Engine）のブロックごとの量子化手法で、完全精度の FP32 スケール値を使用するか、2 のべき乗に制約された FP32 値を使用することが可能です。一方、Blackwell ではテンコアがサポートするのは 2 のべき乗スケールのみです。後者の方式は指数部だけの有効表現となり、粒度が最大で 2 倍粗くなる可能性があります。

fp8_param を使用する場合、オプティマイザは FP32 マスターコピーを更新し、各ステップの後にこれを FP8 パラメータストレージへ再量子化します。強化学習（RL）における更新量は小さくなりがちであるため、より粗いスケールグリッドがこれらの更新を体系的に抑制していないか評価を行いました。

プロファイルされた DAPO の実行では、要素ごとのマスター重み更新の最大値は |ΔW| = 1.01 × 1e-6 で、設定された学習率に近い値でした。一方、オプティマイザステップあたりの平均相対更新 |ΔW|/|W| は 0.6–0.9 × 1e-4 です。

重み同期パス

Qwen3.5-9B の重みに対して、トレーナー側の TE 2.11 Float8BlockQuantizer 更新パスでアブレーション実験を行いました。長い RL オプティマイザステップを経た後、FP8 パラメータストレージの累積変位は、両方のスケール形式において FP32 マスター重みの変位とほぼ一致することが確認されました。

図 12: 左側は、長い RL ステップにわたる累積 FP8 重み変位を FP32 マスターの変位で正規化したものです。どちらのスケール形式も 1 に近い値を示しています。右側は、単一のマスター重みの更新と対応する FP8 ストレージの変化との余弦類似度を、更新の大きさに対してプロットしたグラフです。塗りつぶされた領域は、9B モデルでの実験で測定された更新の大きさを示しています。

*図 12: 左側は、長い RL ステップにわたる累積 FP8 重み変位を FP32 マスターの変位で正規化したものです。*

RL サイズの更新における低単一ステップのコサイン類似性は、それ自体がオプティマイザの更新が失われていることを意味するものではありません。t ステップでは、FP8 保存データは現在のマスター重みから Q(W_t) として再計算されます。したがって、マスターからのズレは、各先行ステップで独立して導入された丸め誤差の合計ではなく、現在の量子化誤差そのものです。長期ホライゾンの変位測定では、各ステップが有効な重み更新の一部しか発生させないにもかかわらず、更新が体系的に排除されていないことが示されています。

トレーニング比較

8×H100 環境で実行された一致した 200 ステップの DAPO ランでは、シードとデータ順序は同一であり、異なるのはスケール表現のみです。

図 13：fp8_param を使用した FP32 と 2 のべき乗ブロックスケールにおける報酬と pass@8。曲線は全体を通じてほぼ一致しています。

*Figure 13 Reward and pass@8 for FP32 and power-of-two block scales with -fp8 param-. The curves remain close throughout the run.*

トークンごとの学習時とロールアウト時の対数尤度差は、2 つの表現を区別する唯一の指標です。この差は、2 のべき乗による実行でより大きく（平均 0.034）、FP8 実行（平均 0.026）よりも粗い量子化の影響を受けています。両者の軌道は並行して推移し、その差が報酬や pass@8 の結果に現れることはありません。

図 14: 2 つのスケール表現におけるロールアウトエンジンとトレーナー間のトークンごとの対数尤度の平均絶対差。2 のべき乗による実行は、一貫して高いが安定した差を示します。

*Figure 14 Mean absolute per-token log-probability difference between the rollout engine and trainer under the two scale representations. The power-of-two run carries a consistently higher but equally stable gap.*

この構成では、2 つのスケール表現間に実質的な収束差は見られません。SkyRL では、Hopper のデフォルトとして FP32 スケールを採用しています。

別のプラットフォーム制約が存在します。テスト済みの TE 2.11 インテグレーションでは、fp8_param が Megatron の分散オプティマイザーを介して FP8 パラメータの保存を TE の replace_raw_data を通じてパッキングバッファへリダイレクトする必要があります。このパスは Hopper で使用されるブロック単位 FP8 テンサーに対して実装されていますが、ネイティブ Blackwell レシピで使用される MXFP8Tensor には対応していません。

そのインテグレーションが利用可能になるまでは、ネイティブ Blackwell パス上の主要なトレーニング重みは BF16 のままとなります。ただし、サポートされている GEMM（行列積演算）については FP8 が依然として加速を提供します。

メモリ削減効果

Hopper において、fp8_param を使用して主要な量子化可能な重みを 1 バイトの E4M3 形式で保存すると、Qwen3.5-9B のポリシーパラメータが GPU あたり 8.3 GiB から 5.1 GiB に削減され、容量は 39% 減になります。この効果は MoE モデルではさらに顕著です。MoE ではラウトされたエキスパートにパラメータの大部分が含まれており、これらはすべて量子化可能です。例えば、8 ウェイのエキスパート並列処理を持つ Qwen3.5-35B-A3B では、同じ手法により GPU あたりのパラメータ保存量が 12.1 GiB から 7.0 GiB に減り、42% の削減を実現します。どちらのモデルでも約 1.9 GiB は BF16 で保持されますが、これは前述の精度感度が高いテンソルセットに属しているためです。こうして節約された HBM は、より長いコンテキストや大きなマイクロバッチ、あるいは広いロールアウトバッチの処理に活用できます。

現在、fp8_param は Hopper のブロック別パスを必要とするため、これらの数値は Hopper デプロイメントに関するものです。一方、本記事で扱う B200 では、主重みに BF16 を使用してトレーニングを行います。

図 15: Hopper 上で -fp8 param を使用した場合と使用しない場合の、GPU ごとのポリシーパラメータ保存容量。BF16 で残存する部分は精度に敏感なテンソルセットです。

*Figure 15 Per-GPU policy parameter storage with and without -fp8 param- on Hopper. The BF16 remainder is the precision-sensitive tensor set.*

LinkCurrent スコープと制限事項

• パフォーマンスは、モデルのアーキテクチャ、応答長さ、バッチ形状、カーネル、およびハードウェアに依存します。本研究で最も大きな効果が見られるのは、ロールアウト生成がステップ時間の大部分を占める場合です。
• FP8 はすべての操作や状態をカバーするわけではありません。必要な箇所では、アテンション（Attention）、選択されたパラメータ、オプティマイザの状態、マスターウェイトはより高い精度で処理されます。

実践的な知見

• 重みの同期は数値的整合性の一部として扱うべきです。トレーニングとロールアウトのカーネルそれぞれが独立して安定していても、その接点での量子化がデータ生成ポリシーを変えてしまう可能性があります。
• パフォーマンスはフェーズごとに評価してください。FP8 のエンドツーエンドによる性能向上は、測定された構成において帯域幅に敏感なデコード処理から主に生じています。一方、ホスト側の作業が現在のところトレーニングフェーズの高速化を制限しています。
• 量子化表現をエンジン間で一貫して保ってください。値、スケール、テンソルの除外対象、レイアウト変換は、トレーナーとロールアウトエンジンがそれぞれ独立して推測するのではなく、単一の設定によって調整される必要があります。

再現に関するノート

コア構成：

# Trainer: FP8 linear-layer GEMMs with an architecture-aware recipe
# Apply the corresponding keys to trainer.ref when a reference model is used.
trainer.policy.megatron_config.transformer_config_kwargs.fp8=e4m3
trainer.policy.megatron_config.transformer_config_kwargs.fp8_recipe=auto
# Rollout: consume trainer-produced FP8 blocks and scales
generator.inference_engine.fp8_weight_sync_mode=auto
generator.inference_engine.engine_init_kwargs.kv_cache_dtype=fp8_e4m3

謝辞

本稿は SkyRL チームとの共同作業です。Eric Tang（etang@anyscale.com）、Sumanth Hegde（sumanthrh@anyscale.com）、Kourosh Hakhamaneshi（kourosh@anyscale.com）に特別感謝いたします。

リンク参照

• SkyRL — https://github.com/NovaSky-AI/SkyRL
• Qwen3.5 — https://qwen.ai/blog?id=qwen3.5
• Unified FP8 — https://www.lmsys.org/blog/2025-11-25-fp8-rl/
• NVIDIA NeMo RL: FP8 — https://docs.nvidia.com/nemo/rl/latest/fp8.html
• DeepSeek-V3 — https://arxiv.org/abs/2412.1943
• DAPO — https://arxiv.org/abs/2503.14476
• SkyRL PR #1898 — https://github.com/NovaSky-AI/SkyRL/pull/1898