GRPO トレーニング用の新しいツールチェーンが、今回は ModelScope コミュニティから利用可能になりました。

DeepSeek-R1の広範な成功により、同アルゴリズムで使用されるGRPOアルゴリズムは業界で大きな注目を集めています。GRPOトレーニングはPPOアルゴリズムの改良版であり、サンプリング原理を用いて価値モデルを簡素化することで、トレーニングの安定性と保守性を向上させることを目的としています。

現在、Hugging FaceのOpen-R1や、veRL、OpenRLHFといった強化学習フレームワークなど、R1モデル技術のオープンソース実装がコミュニティ内にいくつか存在します。しかし、ほとんどのソリューションは、GRPO学習において、学習速度の遅さ、複雑なクラスタ構成、マルチモーダルスケーリング能力の不足、学習後の評価の難しさなど、依然として多くの課題に直面しています。

オープンソース コミュニティの GRPO 方向への探求をサポートするために、ModelScope コミュニティは、MS-SWIFT トレーニング フレームワークと EvalScope 評価フレームワークに基づく、比較的完全で効率的な GRPO エンドツーエンド ソリューションを立ち上げ、コミュニティと共有しています。

GRPOトレーニングの高速化

GRPOの学習時間は、主にサンプリングと学習を含む複数の側面から生じます。中でも、サンプリング自体はPPOアルゴリズムの重要な要素です。特に、GRPOは値モデルではなくサンプリングを使用するため、学習中のサンプリングに費やされる時間の割合が大幅に増加します。さらに、GRPOではクエリあたりのサンプル数（つまりグループサイズ）が一般的に非常に大きく（DeepSeekMathの論文では64）、高いサンプリング頻度は推論エンジンにとって大きな課題となります。サンプリング効率の最適化は、GRPOの全体的な学習速度を向上させるための核心です。

これらの特性に基づいて、Moda コミュニティの SWIFT フレームワークは、ターゲットを絞った最適化が行われています。

複数インスタンスデータの並列サンプリング

GRPOアルゴリズムでは、単一インスタンスのサンプリングだけでは不十分な場合が多い。研究チームは、7Bモデルの学習中に、インスタンスあたりのサンプリング時間が約70%を占めていることを観察した。これは、実際の状況に基づいて、学習リソースをサンプリング計算に的を絞って割り当てる必要があることを示唆している。

特にサンプリング量とバッチサイズが大きい場合、サンプリング時間はトレーニング速度に大きな影響を与えます。そのため、SWIFTのvLLMとLMDeployにいくつかのパッチが適用され（また、vLLM/LMDeployの関連実装をネイティブサポートするための関連フレームワーク開発者との協議も行われています）、任意の割合のトレーニングカード上でサンプリングインスタンスを作成できるようになりました。例えば、8枚のカードを使用したトレーニングでは、4枚のカードをモデルトレーニング用に、4枚のカードをサンプリング用に構成できます。また、6枚のカードをトレーニング用に、2枚のカードをサンプリング用に構成することも可能です。

次の図は、同じ 8 枚のカードのトレーニング セットアップで、1 枚または 2 枚のカードを使用して推論エンジンをサンプリング用にデプロイし、残りのカードをトレーニングに使用した、vLLM/LMDeploy のサンプリング時間とトレーニング時間を示しています。

ご覧のとおり、LMDeployを2GPUでサンプリングに使用した場合、学習時間は1GPU使用時の約87%です。一方、vLLMを2GPUで使用した場合、学習時間は1GPU使用時の78%です。どちらの例でも、より多くのGPUをより合理的に割り当て、サンプリングリソースを優先することで、学習時間を効果的に短縮するという目標が達成されています。

非同期サンプリング

GRPOトレーニングでは、サンプリングとモデルのトレーニングを交互に実行する必要があります。つまり、トレーニング中はサンプリングGPUがアイドル状態になり、サンプリング中はトレーニングGPUがアイドル状態になります。この問題に対しては、フレームワークごとに異なる解決策が提供されています。

例えば、veRLでは、サンプリングとトレーニングを同じGPUにデプロイし、異なる段階で異なる重みをCPUにオフロードできます。また、LLMモデルでは、異なるレイヤーとテンソルを異種パーティショニングすることが可能です。このパーティショニングでは、重みをすべて集めるのではなく、一部の重みのみを集めて同期させるため、トレーニングモデルとサンプリングモデルの効率を最大化できます。ただし、小規模から中規模のモデルでは、このようなパーティショニングは最適ではない可能性があります。

モデルサイズとバッチサイズの増加に伴い、サンプリングとトレーニングにかかる​​時間が大幅に変化するため、SWIFTでは非同期サンプリング（リプレイバッファ）という異なるアプローチを採用しています。これは、トレーニング中に同時にサンプリングを行い、その結果を次のイテレータのトレーニングに使用します。サンプリングには古いポリシーモデルを使用するため、トレーニング中にロジット差分用のCLIPを追加する必要があります。古いポリシーモデルとポリシーモデルはイテレータが1つしか異なるため、トレーニングの安定性はほぼ変わりません。待機（またはストップザワールド）が必要なプロセスは、重みのロードのみです。

同じトレーニング設定での実験テストでは、LMDeploy を 1 枚のカードに展開した場合、非同期サンプリングのトレーニング時間は同期サンプリングの約 2/3 になることが示されています。

モデルの配置

SWIFTは、2つの別々のリソースグループを用いた非同期のトレーニングとロールアウトプロセスをサポートするだけでなく、同じリソースグループを用いた両方のプロセスもサポートします。つまり、アクターモデルのトレーニング中、vLLMはスリープモードを有効にしてGPUメモリの使用量を削減します。

これら 2 つのモードのアーキテクチャ図は次のとおりです。

さらに、SWIFT は vLLM の tensor_parallel (MP) モードもサポートしています。

LMDeploy推論フレームワークは以下をサポートします

LMDeployは、上海浦江研究所が開発した優れた推論加速フレームワークです。このフレームワークは、プレーンテキストモデルとマルチモーダルモデルの両方の推論加速をサポートするだけでなく、FasterTransformerをベースに独自開発されたTurbomind推論加速エンジンを搭載しています。推論速度に関しては、LMDeployは幅広いモデルにおいてvLLMよりも大幅な向上を示しています。実験は、AI-MO/NuminaMath-TIRデータセットを使用し、バッチサイズを7に設定し、クエリごとに24件の結果をサンプリングし、50ステップのトレーニングを行うという設定でQwen2.5-7B-Instructモデルを用いて実施しました。以下は、同一条件下でのvLLMフレームワークとLMDeployフレームワークの推論時間の比較です。

ご覧のとおり、LMDeploy をサンプリング推論エンジンとして使用すると、全体的なトレーニング速度が 44 分/50 ステップから 37 分/50 ステップに高速化され、約 16% の高速化が実現します。

注: 最後の 50 ステップのトレーニング時間には、モデルの重みの保存とテスト セットの評価が含まれます。

SWIFTフレームワークは、TRLフレームワークとvLLMサンプリングを基盤とし、LMDeployサンプリングのサポートも導入しています。推論と重みの読み込み速度の向上により、全体のサンプリング時間は基本実装の70%にまで短縮されます。

複数のアップデート

マルチラウンドアップデートの核となる考え方は、 1回のサンプリングで得られたデータを複数回利用できるようにすることです。これによりサンプリングの頻度が減り、サンプリングとトレーニングの間でよりバランスの取れたリソース配分が可能になります。

パラメータ「num_iterations」を設定することで、各ラウンドにおけるサンプリングデータの更新回数を指定できます。このパラメータ値を大きくすると、サンプリングデータを複数回使用できるようになり、サンプリング処理による学習速度への影響が軽減され、学習速度が向上します。この値が大きすぎない場合（例えば4以下）、モデルの学習効果に悪影響を与えることは通常ありません。ここでの更新ラウンド数は、論文中の「mu」値に対応しています。

マルチラウンド更新は TRL ライブラリによって提供されるメカニズムであり、このメカニズムをチームが提供する他のメカニズムと組み合わせると、より優れた加速結果が得られることが判明しました。

LMDeploy を単一の GPU にデプロイし、num_iterations 1 から 4 までのトレーニング時間を比較した完全な実験結果を以下に示します。

ご覧のとおり、複数回の更新ラウンドの回数を 4 (mu=4) に設定すると、全体的なトレーニング時間は単一更新ラウンドの約半分になります。

総合テスト

8枚のカード環境におけるSWIFT、veRL、およびtrlフレームワークの学習効率を比較しました。実験セットアップでは、前述の複数の学習加速技術を統合し、推論エンジンとしてLMDeployを選択しました。

具体的な構成としては、デュアルカード推論サンプリングを採用し、非同期サンプリング戦略と組み合わせ、多重更新ラウンド数を4ラウンドに設定しました。同時に、実際のトレーニングシナリオをより適切にシミュレートするために、バッチサイズを48（1ラウンドあたり6クエリ、勾配累積ステップは8）に調整し、グループサイズを24に設定しました。Qwen2.5-7B-InstructモデルとAI-MO/NuminaMath-TIRデータセット（1）に基づいて、複数のフレームワークにおけるGRPOのトレーニング速度を比較評価しました。

迅速：

veRL:

trl(mu=4):

trl(mu=1)

実験結果によると、SWIFTフレームワークのトレーニング時間は1ステップあたり約120秒であるのに対し、veRLフレームワークでは1ステップあたり約280秒です。TRLフレームワークでは、マルチステップ更新ありの場合、1ステップあたり約144秒、マルチステップ更新なしの場合、1ステップあたり約320秒かかります。複数のトレーニング加速技術を統合することで、SWIFTフレームワークはGRPOにおける小規模から中規模のクラスターのトレーニング効率を大幅に向上させます。下の図は、SWIFTフレームワークにおけるトレーニング報酬の傾向を示しており、モデルが報酬値を向上させることに成功したことを示しています。

マルチモーダルGRPOトレーニング

マルチモーダル GRPO トレーニング用のオープンソース ソリューションはすでにいくつか存在します (R1-V、open-r1-multimodal など)。これらはすべて Open-R1 の単純な拡張です。

SWIFTフレームワークは、マルチモーダルモデル（画像、動画、音声）のGRPOトレーニングをサポートするようになりました。データセット内の「images」/「videos」/「audios」フィールドが与えられた場合、GRPOはマルチモーダルコンテンツをマルチモーダルモデルに入力し、強化学習を行います。SWIFTは現在、ファインチューニングにおいて約200のマルチモーダルモデルをサポートしており、これらはすべてGRPOトレーニングを自然にサポートしています。R1-Vタスク設定を参考に、CLEVR-70k-Counting(2)データセットを用いて、マルチモーダルカウントタスクのトレーニングを実施しました。トレーニングには2つの報酬関数が選択されました。1つはDeepseek-R1で言及されているフォーマット報酬関数で、モデルの出力フォーマットの精度を評価するために使用されます。もう1つは、モデルの出力カウントが真の値と一致するかどうかを計算するために使用されるカスタム精度報酬関数です。これらの報酬関数は現在SWIFTフレームワークで定義されており、「--reward_funcs external_r1v_acc format」パラメータを使用して指定されます。トレーニングのベースモデルとしてQwen2.5-VL-3B-Instructを選択しました。ベースモデルではなくInstructモデルを選択した主な理由は、フォーマット報酬をより速く取得できるためです。実験全体は8GPUシステムで完了しました。現在のSWIFT GRPOトレーニングは、ロールアウトを高速化するためにマルチGPUモデルデプロイメントをサポートしているため、num_infer_workersを2に設定し、プロセス数を6に設定しました。つまり、vLLMデプロイメントサンプリングに2つのGPUを使用し、モデルトレーニングに6つのGPUを使用しました。モデルの最大出力は1024に設定され、学習率は1e-6に設定されました。その他のパラメータ設定については、ベストプラクティス(3)を参照してください。

実験結果を下の図に示します。

モデルは500エポックのトレーニングを経て収束しました。精度報酬（図中のClevrCountORM）とフォーマット報酬（図中のFormat）は継続的に増加しており、モデルがタスクの完了方法を学習したことを示しています。最終的なタスク成功率は、最初の0.4から約1に上昇しました。ステップ300付近では、reward_stdが約0.1に低下し、モデルが実質的に収束したことが証明されました。完了までの時間は最終的に60～80で安定し、モデルが学習したタスク推論パラダイムは、画像内のオブジェクトを1つずつリストすることです。トレーニング済みモデルの出力サンプルは次のとおりです。

 user: How many items are there in the image? assistant: Counting the number of items in the image:n1. Green matte spheren2. Large metallic yellow spheren3. Small metallic brown cubennThere are three distinct objects in total.n n3推論モデルの評価user: How many items are there in the image? assistant: Counting the number of items in the image:n1. Green matte spheren2. Large metallic yellow spheren3. Small metallic brown cubennThere are three distinct objects in total.n n3

EvalScopeフレームワークは、Modaコミュニティのオープンソースの大規模モデル評価ツール（4）であり、完全な大規模モデルの包括的な評価フレームワークを提供します。

O1/R1などの推論モデルの推論性能を評価する機能を提供するだけでなく、下図に示すように評価結果の可視化もサポートしています。

一方、チームはMATH-500、GPQA-Diamond、AIME-2024の3つのデータセットを1つのデータセットに統合し、modelscope/R1-Distill-Math-Testデータセット(5)に配置しました。ユーザーはこのデータセットのIDを直接評価に使用できます。具体的な使用手順については、「モデル推論能力評価のベストプラクティス」(6)を参照してください。

さらに、推論モデルには、思考不足 (思考不足。推論中にモデルが頻繁にアイデア間を飛び回り、正しいアイデアに集中できず、間違った答えにつながる) と思考過剰 (思考過剰。単純な問題に対してモデルが長すぎる思考の連鎖を生成し、計算リソースを無駄にする) の問題があります。

このフレームワークは、モデルの思考効率を評価することを可能にします。下図に示すように、DeepSeek-R1-Distill-Qwen-7B(7)などの推論モデルの思考効率を評価できます。このフレームワークは、トークン効率、思考長、サブ思考チェーンの数、精度の4つの側面から効率を測定します。これにより、短い出力で正しい答えを得るモデルの能力を評価および最適化できます。具体的な使用手順については、チュートリアル「モデル思考効率評価のベストプラクティス(8)」を参照してください。

効果

単純な数学的課題「カウントダウンゲーム」から始めて、SWIFTフレームワークにおけるGRPOの有効性が検証され、完全な実験手順が示されています（9）。

カウントダウンゲームの目的は、複数の与えられた数値と加算、減算、乗算、除算の4つの演算から目標数値を取得し、その演算式を提供することです。そのため、モデルの入力には、タスクの説明、与えられた数値、目標数値が含まれます。トレーニングには2つの報酬関数が選択されます。1つはモデルの出力形式の精度を評価する標準形式の報酬関数、もう1つはモデルの出力式が目標値を取得できるかどうかを評価するカスタム精度報酬関数です。どちらの報酬関数も現在SWIFTフレームワークで定義されており、`--reward_funcs external_countdown format`パラメータで指定されます。

フルパラメータGRPO学習にはQwen2.5-3B-Instructモデルを選択しました。具体的なパラメータ設定については、実験手順に詳細が記載されています。GRPO学習プロセスは比較的不安定であることが判明しました。学習率とベータ（KLダイバージェンスの重み）を大きくするとモデルの収束が速くなる可能性がありますが、勾配が過度に大きくなり、学習がクラッシュすることがよくあります。最終的に、学習率7e-5、ベータ0.001が選択されました。実験結果を下の図に示します。

合計2000ステップの学習が行われ、得られた曲線はSWIFT GRPOの有効性を証明しました。モデルの収束過程も実験結果から確認できます。

精度報酬 (CoundownORM) とフォーマット報酬 (Format) が着実に増加していることは、モデルがこのタスクをより適切に実行する方法徐々に学習していることを示しています。また、reward_std が最終的に 0.2 ～ 0.3 程度に落ち着いたという事実は、モデルにはまだ改善の余地があることも証明しています。

`completion_length` の変化は、モデルの思考プロセスの変化を明確に示しています。約500トークンから200トークンに減少し、その後300～400トークンに増加し、各段階におけるモデルの思考プロセスを明確に示しています。当初、モデルは結果から直接開始し、必要な数値を逆方向に推論していました。その後、モデルは逆方向推論プロセスを徐々に簡素化し、出力スペースを大幅に削減しました。最終的に、モデルはタスクを完了するための最良の方法は、既存の数値と演算の組み合わせをリスト化し、それらを段階的に実行することであることを発見し、出力パラダイムがほぼ収束しました。最終的な出力例を以下に示します。

 user: "Using the numbers [71, 92, 80], create an equation that equals 59. You can use basic arithmetic operations (+, -, *, /) and each number can only be used once. Show your work in tags. And return the final equation and answer in tags, for example (1 + 2) / 3 = 1 ." assistant: " nWe need to form an expression using the numbers 71, 92, and 80 which results in 59. Let's try some combinations:n(92 - 80) + 71 = 83 + 71 = 154 (too high)n(92 - 71) + 80 = 21 + 80 = 101 (too high)n(92 - 80) + 71 = 12 + 71 = 83 (too high)n(92 - 71) + 80 = 21 + 80 = 101 (too high)n(92 + 80) - 71 = 172 - 71 = 101 (too high)n(92 + 71) - 80 = 163 - 80 = 83 (too high)n(80 + 71) - 92 = 151 - 92 = 59nnSo our solution is: (80 + 71) - 92 = 59 nn(80 + 71) - 92 = 59 "

結論は

SWIFTは、大規模モデルのトレーニングに対応するため、vLLM MPモードを追加します。既存の優れたフレームワークの技術基盤を基盤とし、差別化された技術を通じて、小規模から中規模のクラスター向けのシンプルで高速なRLトレーニングソリューションを開発者に提供することを目指しています。これにより、開発者に新たな技術オプションが提供されます。現在、SWIFTは数学、ReACT構造エージェント、マルチモーダルVQAなどのトレーニング領域をサポートしており、コードサポートは継続的に更新されています。Megatron構造モデルについては、GRPOトレーニングだけでなく、SFTとPreTrainもサポートしています。

評価分野においては、EvalScopeは推論モデルの「思考効率」をさらに探求します。また、現在の動向から判断すると、マルチモーダル推論パラダイムは徐々に注目を集めており、チームはこの分野における最新の評価ベンチマーク、指標、手法を積極的に探求していきます。

[1] AI-MO/NuminaMath-TIRデータセット: https://www.modelscope.cn/mod... [2] CLEVR-70k-Counting: https://www.modelscope.cn/dat...\_cogen\_a\_train [3] マルチモーダルGRPOのベストプラクティス: https://github.com/modelscope... [4] 大規模モデル評価フレームワークEvalScope: https://github.com/modelscope... [5] modelscope/R1-Distill-Math-Testデータセット: https://modelscope.cn/dataset... [6] EvalScopeモデル推論機能を評価するためのベストプラクティス: https://evalscope.readthedocs...\_practice/deepseek\_r1\_distill.html [7] DeepSeek-R1-Distill-Qwen-7B: https://modelscope.cn/models/... [8] モデル思考効率を評価するためのベストプラクティス: https://evalscope.readthedocs...\_practice/think\_eval.html [9] 完全なGRPO実験ワークフロー: https://github.com/modelscope...