302 Views
October 26, 26
スライド概要
東京大学松尾・研究室が運営する「松尾研LLMコミュニティ」でのイベント資料などを公開します。 ◾️ 松尾研LLMコミュニティとは 松尾研LLMコミュニティは、「大規模言語モデルについて知って学べるオンライン空間」として、東京大学松尾・岩澤研究室が運営するコミュニティです。 現在、学生を中心とした10,000名以上が、原則無償で参加しています。 また、本コミュニティでは様々なイベント等を定期的に開催しております。 是非下記のリンクより参加申し込みをお待ちしております。 ◾️ 松尾研LLMコミュニティの各種リンク ・今後のイベント開催情報/参加申込;https://tr.ee/7d_W4DsImD ・松尾研LLMコミュニティ参加フォーム;https://tr.ee/RyDfuRzS55 ・過去イベントアーカイブ;https://tr.ee/wqdbFJJZ25
チーム紹介 チームHOLONとは LLMコンペ2025の決勝チームである小野チームが、医療LLMに合流した時の名前 本チームとは別に、性能向上のための手法を検証するチーム。データ・学習・評価 分析の3班で活動 あわせて、本チームや他のコンペチームからの依頼で、データ作成や評価の一部も 引き受けている データ班 発表済み 学習班 今回 評価・分析班 次回 #102 データ編 #104 学習編 次回 評価・マネジメント編 合成データの生成。医療PDFの知識 化は本チームからの依頼 SFT / DPO / GRPO で巨大モデルを 学習する基盤 評価・分析(本チーム・他チーム分 も一部担当)と、チームのマネジメ ント
PAPER & HACKS #104 フレームワークが動くのを待つな、 FSDPを書け リリース8日後に397B MoEを学習した基盤を全公開 医療特化型LLMを作るには ― 学習編 小野克樹 | チームHOLON Paper&Hacks #104 / チームHOLON / 小野克樹 01 / 16
背景 フレームワークの定石が成立しない環境 共有クラスタでは、環境・相性の問題を解く作業が学習そのものより重くなることがある 日本の共有計算資源の制約 Slurmクラスタ 私が評価した範囲で起きたこと DeepSpeed MoEで集合通信が噛み合わずハング。エラーを吐かず に止まる ms-swift 並列設定がシビアで、ノード構成と噛み合わせるのに苦 労 凍結の表現力 「特定expertだけ学習」「凍結層の境界で活性化を切る 」が書きづらい 固定されたドライバ・CUDA root権限なし 想定外のノード構成・台数 ※ 2026年初頭の版での評価。フレームワークは進化が速いので現状は要確認 Paper&Hacks #104 / チームHOLON / 小野克樹 02 / 16
この発表の立場 一部の構成では、素のFSDPの方が早かった 01 02 03 学習班の1人として BF16で回したい 学習ループを一から チーム全体の方針ではない。私もmsswift・axolotlを使ったし、verl主軸の メンバーもいる LoRA・量子化よりも品質が読みやす い(もちろん最適な場面も多い) PyTorch標準のFSDPの上に書く。遠 回りに見えて、結果的に最短経路だっ た ハングは素のFSDPでも起きる。違いは「原因を特定して、自分で直せる」こと 例:ランク間で端数バッチの数がずれ、イテレーション数の不一致でハング → 端数バッチをdropして解決(修正は1か 所) Paper&Hacks #104 / チームHOLON / 小野克樹 03 / 16
成果物 構築した4つの学習基盤(すべてMITで公開) 基盤 モデル 手法 開発時期 qwen3-235b-fsdp Qwen3-235B-A22B (MoE) SFT / DPO / GRPO・GDPO・ GSPO 2025年12月頃 ← ベース qwen-3-5-fsdp Qwen3.5-397B-A17B SFT / DPO / GRPO (β) リリース8日後に完成 glm-5-fsdp GLM-5(744B, FP8運用) SFT / DPO SFTはリリース13日後 qwen-next-80b-fsdp Qwen3-Next-80B-A3B フルパラ SFT / DPO / GRPO (β) 3/4〜 横展開 いずれもH100クラスタ・Slurm運用・40〜96 GPU規模 以降、素のFSDPの強みを 01 依存 / 02 資産化 / 03 壁がない / 04 可観測性 の4つで紹介 Paper&Hacks #104 / チームHOLON / 小野克樹 04 / 16
01 依存 小さく、自分で制御できる PyTorch Transformers Accelerate SFT / DPO のスタックはこの3つ conda環境構築スクリプトは1ファイル Paper&Hacks #104 / チームHOLON / 小野克樹 足すものは少なく、見通せる GLM-5はtransformersのdev版、GRPOはvLLM nightlyが要る。それでも 入れるのはmodelingコードと数個のwheelだけ 依存の分離も自分で設計 vLLM nightlyはNCCL重み同期の専用ユーティリティ。モデルロードには 使わないので、学習側とtransformersの版がずれても問題ない 詰まる原因はクラスタとの不整合 モデル対応の遅れではない。だから既存モデルでも、相性デバッグが素 のループを書くコストを上回り得る 05 / 16
02 資産化 一度書けば、新モデルへの対応は「移植作業」になる 8 日 13 移植の中心作業は2つだけ 日 Qwen3.5-397B-A17B GLM-5(744B, FP8) リリース 2/16 → 学習スクリプト完成 2/24。同日中に最初のGRPOが回り始め た リリース 2/11 → SFT完成 2/24(DPOは 3/2) 1. auto_wrap_policy に渡す decoder layer クラスの差し替え 2. そのモデル固有の癖への対処 FSDPはnn.Moduleをラップするだ け。推論用modelingコードはリリー ス直後に出るので、公式の学習スク リプトを待たなくていい ハイブリッド注意機構・512 expertのMoE・ViT付きという、フレームワークが苦手 な構成でも同じ手順 Paper&Hacks #104 / チームHOLON / 小野克樹 06 / 16
02 資産化 235Bの基盤から、段階的に積み上げた 2025/12/9 2026/1/27 2/24 3/2 3/4〜 235B基盤の原型が稼 働 GRPO / GDPO / GSPO Qwen3.5・GLM-5 SFT完成 GLM-5 DPO完成 Qwen3-Next-80Bへ expert選択学習・ FSDP vLLM重み同期。 RLは9ノード、SFTは4ノ ード 3つの目的関数を比較。誤 答サブセットで正答率が 数%向上、全体スコアは 維持 Qwen3.5のGRPOも完成 。リリースの8日後 同系統のハイブリッド構 成なのでほぼ横展開 公開した4リポジトリは、この積み重ねを整理して切り出したもの Paper&Hacks #104 / チームHOLON / 小野克樹 07 / 16
03 壁がない ① FP8重みをFSDPに通す10行のパッチ(GLM-5) BF16だとRAMに乗らない rank 0でモデル全体をCPUに展開する段で溢れる FP8(約760GB)で動かす 今度はFSDP1のパディング生成が乗算で書かれて いてFP8非対応 import torch.distributed.fsdp._flat_param as flat _orig = flat._construct_padding_tensor def _fp8_safe(numel, dtype, requires_grad, device): if dtype in (torch.float8_e4m3fn, torch.float8_e5m2): # BF16でゼロを作ってからFP8へキャスト return torch.zeros(numel, dtype=torch.bfloat16, device=device).to(dtype) return _orig(numel, dtype, requires_grad, device) flat._construct_padding_tensor = _fp8_safe 該当関数を差し替えて解決 BF16でゼロを作ってからFP8にキャスト mul_cuda not implemented for Float8_e4m3fn を回避(FSDP1のprivate API) さらにall-gather直後のforward hookでFP8→BF16をブロック単位でdequant。重みはFP8のままシャーディングし、学習対象層だけ BF16化 Paper&Hacks #104 / チームHOLON / 小野克樹 08 / 16
03 壁がない ② どこを凍結し、どこでグラフを切るかを自由に設計する 凍結層の活性化を捨てる detach hook 凍結層 凍結層 学習層 MoEのexpertを選択的に学習(235B) 学習層 detach (layer, expert) をマスクで選び、残りは凍結 境界でforward-pre-hookがdetachし、autogradグラフを切断 LoRAなしで、BF16フルパラのまま学習対象を絞れる 凍結層は活性化を保持せずforwardを通るだけ → メモリはほ ぼゼロ FSDPはunit内でdtype統一を要求 → 凍結パラメータの扱いを調整 (GLM-5では凍結スケールをbuffer化) FSDPでwrapされたforwardの途中は torch.no_grad() では届か ない 凍結パターンが用意済みのフレームワークでは選択肢に入りにく い構成 ※ attnのみ学習する構成ではMoE出力もdetach。残差経路の勾配が近似になる、メモリ削減のための意図的なトレードオフ Paper&Hacks #104 / チームHOLON / 小野克樹 09 / 16
03 壁がない ③ 巨大MoEのメモリは、設計で削る 18 GiB 2.3 DPOはMoEに合わせて設計 GB 1層あたりのMoE重み 1回のforwardのsoftmax attnだけ学習するときはMoE出力も detach。backwardでこの重みをallgatherしない DPOの交差エントロピーをcheckpoint化 し、語彙全体のfloat32テンソルを保存し ない 1. chosenとrejectedを1回で流す 2. 参照モデルのlogpは事前に計算 別々に流すとexpertの振り分けがず れ、比較が公平でなくなる。参照モ デルを学習中に持たない分、メモリ も空く detach hookは勾配チェックポイントより軽い。チェックポイントはbackwardで全 層をall-gatherし直すが、detachなら凍結層のbackward自体が走らない(数値は GLM-5の構成) Paper&Hacks #104 / チームHOLON / 小野克樹 10 / 16
03 壁がない ④ GRPOのための FSDP 学習ノード群 vLLM リアルタイム重み同期 重み:unitごとにsummon_full_params → NCCL FSDP BF16フルパラメータ 推論ノード群 vLLM TP=16(Qwen3.5)/ TP=8 生成 → 報酬(LLM-as-Judge)→ 損失 同期の受け口 学習対象はフラグで 報酬と目的関数 TRLのWeightSyncWorkerExtensionをベー スに、送り出し側を自前実装 attention-only(層範囲指定可)か、(layer, expert)マスクのexpertのみ 医療精度+有用性の2段ジャッジ(ゲーテ ィング付き)。GDPO/GSPOへの差し替 えは数十行 注意 Qwen3.5 / Next への移植版GRPOはβ。重みがvLLMに渡らず静かに壊れるケースと、vLLMが落ちるケースがある Paper&Hacks #104 / チームHOLON / 小野克樹 11 / 16
03 壁がない ⑤ 踏んだ落とし穴も、自分のコードの中で直せた 初回のJITに40〜60分 Qwen3.5 同期ごとにprefix cacheを消す GRPO Gated DeltaNetのカーネルを初回にコンパイル。タイムア ウトを7200秒に延ばし、キャッシュを保存 重みを送った後も古いKVキャッシュが残ると、ハングや誤 った出力の原因になる transformersの版が衝突 assistantマスクが取れない 依存 vLLM nightlyは4系、学習側は5.1以上。conda環境を2つに 分け、TRLが読むAscend NPU用モジュールはスタブで回 避 SFT / DPO Qwen3.5のチャットテンプレートが非対応。文字位置から トークン位置を逆算 どれもフレームワークの奥ではなく、自分のスクリプトの中で原因が見えた Paper&Hacks #104 / チームHOLON / 小野克樹 12 / 16
04 可観測性 メモリと分散の制御点が、すべてスクリプトに見えてい る rank 0だけがCPUにロード CPU RAM all-gatherの同時実行数を制限 GPUメモリ sync_module_states=True で全rankへ配布。Qwen3.5は BF16で約794GBあり、これがないとノードのRAMが足り ない limit_all_gathers=True でピークメモリを削減(FSDP1) 端数バッチをdrop 保存時にCPUへoffload ハング rank間のイテレーション数のずれによるハングを防ぐ GPU OOM checkpoint保存で offload_to_cpu を使いGPU OOMを回避 40〜96 GPU規模を安定運用できたのは、この見通しの良さによるところが大きい Paper&Hacks #104 / チームHOLON / 小野克樹 13 / 16
よくある疑問 「全部自分で書く」のは大変では? たしかに、最初の1回は重い 900〜2,000 行 公開リポジトリなら、残るのはこれだけ 1 モデルパス・データパス・Slurm設定を自分 の環境に合わせる 2 必要なら decoder layer クラス名と学習対象 を差し替える SFT / DPO スクリプトそれぞれの規模 データローダー、sequence packing、checkpointのマ ージ、W&Bログまで自前 設定ファイルを書くのと大差ない手間で、フレームワークでは表現しにくい自由度が手に入る Paper&Hacks #104 / チームHOLON / 小野克樹 14 / 16
まとめ このクラスタで、このモデルを、 今すぐ好きなように学習する 01 02 03 依存が小さい 基盤は資産になる 壁の向こうも自分で 共有クラスタでは環境・相性問題が最 大のボトルネック。既存モデルでも一 から書く方が速いことがある 235Bの基盤から、Qwen3.5-397Bへ8日 、GLM-5(FP8)へ13日で移植 FP8パッチ、detach hook、expert選択 学習、vLLMへのNCCL重み同期 この数ヶ月で世界が変わった 当時より格段に優秀になったClaude Codeと、ms-swiftの相性問題を潰す方が良い可能性が高い Paper&Hacks #104 / チームHOLON / 小野克樹 15 / 16
付録 公開リポジトリ(いずれもMITライセンス) Qwen3-235B-A22B github.com/weblab-llm-m/qwen3-235b-fsdp Qwen3.5-397B-A17B github.com/weblab-llm-m/qwen-3-5-fsdp GLM-5-FP8 github.com/weblab-llm-m/glm-5-fsdp Qwen3-Next-80B-A3B github.com/weblab-llm-m/qwen-next-80b-fsdp 謝辞 この成果は、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)の委託業務(JPNP25006)の結果得られたものです。 Paper&Hacks #104 / チームHOLON / 小野克樹 16 / 16
PAPER & HACKS #104 GRPO(強化学習)のアドバンテージ崩壊を、 学習データの難易度フィルタで回避する 強化学習のGRPOで学習が進まない失敗と、それへの対処について 医療特化型LLMを作るには ― 学習編 遠藤祥子 | チームHOLON Paper&Hacks #104 / チームHOLON / 遠藤祥子 01 / 13
はじめに 課題:パラメータを更新したいのに、学習が進まないことがある Paper&Hacks #104 / チームHOLON / 遠藤祥子 02 / 13
GRPOとAdvantage GRPOは、同じ問題に対する複数の回答の報酬を比べて学習する Advantage:その回答が、同じ問題のほかの回答と比べて、どれだけ良かったか 注記 損失にはKL項(方策モデルが参照モデルから離れすぎないようにするペナルティ)も入るが、ここでは省略している。 報酬はルールベースの正誤判定(最終解答が正解なら1、不正解なら0)。図は8個中5個が正解の例。 [1] Zhihong Shao et al.: DeepSeekMath(Figure 4をもとに作図) Paper&Hacks #104 / チームHOLON / 遠藤祥子 03 / 13
GRPOとAdvantage Advantageは、各回答の報酬とグループの平均の差から求める Advantage Aᵢ = (rᵢ − 平均) / 標準偏差 (グラフは標準偏差で割る前の値) 正解数kを変えると(8回中) k 平均 正解の Advantage 不正解の Advantage 1 0.125 +0.875 −0.125 4 0.5 +0.5 −0.5 7 0.875 +0.125 −0.875 グループの中で少数派の回答ほど、 Advantageの絶対値(正負を除いた大き さ)が大きくなる ※k=4は正解と不正解が同数なので、絶対値も 同じ ※表はいずれも標準偏差で割る前の値 Paper&Hacks #104 / チームHOLON / 遠藤祥子 04 / 13
GRPOとAdvantage Advantageは、方策モデルのパラメータを更新するときの係数 注記 上の式は、KL項なし・SGDで、更新直前の方策で回答を生成した場合。実装では、損失(Jの推定値の符号を反転したもの)を勾配降下法で小さくする。 回答の長さで割る補正(1/|oᵢ|)や標準偏差で割る設定の補正が掛かるので、GRPOの更新は期待報酬の勾配そのものではなく、その推定量に補正を掛けたもの。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 05 / 13
GRPOとAdvantage Advantageがすべて0だと、θは更新されない 灰色の点線:係数Aᵢを掛ける前の ベクトル (各回答oᵢの生成確率を上げる方向) 注記 本実験の損失にはKL項(β≈0.05)がある。KL項にはAᵢが掛からないので、Aᵢがすべて0のグループの回答も、KL項を通じてθの更新に使われる(方策を参 照モデルに近づける向きに動かす)。また、オプティマイザは実際にはAdamWを用いていたので、勾配が0でも、直前までのモーメンタムでθが動く。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 06 / 13
アドバンテージ崩壊 8個の回答の報酬がすべて同じだと、Advantageは0になる Advantage Aᵢ = (rᵢ − 平均) / 標準偏差 グループ内の報酬がすべて同じで、Advantageがすべて0になること =「アドバンテージ崩壊」 注記 標準偏差で割る設定でも、8個の報酬がすべて同じなら標準偏差は0なので、分子の0を小さな値(ε)を足した分母で割り、Advantageは0になる。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 07 / 13
アドバンテージ崩壊 崩壊しやすいのは、難しすぎる問題と易しすぎる問題 バッチ:1回の生成でまとめて作る回答の単位(本実験では 96問 × 8回答 = 768回答 = 96グループ) 注記 ACRの式は、[2] Xixiang He et al.: Advantage Collapse in Group Relative Policy Optimization の定義4.1。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 08 / 13
動的サンプリング 崩壊したグループを除き、バッチを埋め直す 動的サンプリング:崩壊したグループをバッチから除き、別の問題を再サンプリングしてバッチを埋め直す方法(DAPO論文) [3] Qiying Yu et al.: DAPO Paper&Hacks #104 / チームHOLON / 遠藤祥子 09 / 13
動的サンプリング 崩壊が多すぎると、動的サンプリングは失敗する グラフの値:ms-swiftが記録する指標 frac_reward_zero_std(ACRとほぼ同じ定義。学習中はこの指標で崩壊を見ている) 注記 上限 1 − 1/R は、ms-swiftの実装から導いた期待値による近似(ACR論文の式ではない)。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 10 / 13
難易度フィルタリング 崩壊しやすい問題を、学習の前に取り除く [4] Che Liu et al.: Beyond Distillation(AlphaMed)。 注記 難易度分類に使ったモデルは、学習に使うモデル(Qwen3-235B-A22Bに医療ドメインの継続事前学習を行ったモデル)自身。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 11 / 13
難易度フィルタリング L1とL6を除くと、動的サンプリングが毎回成功した Paper&Hacks #104 / チームHOLON / 遠藤祥子 12 / 13
まとめ 難易度フィルタリングは動的サンプリングを補完する 注記 今回は医療問題で実験を行なったが、GRPOで、正解・不正解の報酬で学習するなら、どの分野でも崩壊は起きうる。数学でも、中くらいの難しさの問題 を選ぶと崩壊が減る可能性が示唆されている(ACR論文)。 謝辞:この成果は、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)の委託業務(JPNP25006)の結果得られたものです。 Paper&Hacks #104 / チームHOLON / 遠藤祥子 13 / 13
参考文献 Reference [1] Zhihong Shao et al. (2024), “DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models ”, arXiv:2402.03300 [2] Xixiang He et al. (2026), “Advantage Collapse in Group Relative Policy Optimization: Diagnosis and Mitigation”, arXiv:2605.21125 [3] Qiying Yu et al. (2025), “DAPO: An Open-Source LLM Reinforcement Learning System at Scale”, arXiv:2503.14476 [4] Che Liu et al. (2025), “Beyond Distillation: Pushing the Limits of Medical LLM Reasoning with Minimalist Rule-Based RL”, arXiv:2505.17952 Paper&Hacks #104 / チームHOLON / 遠藤祥子 14 / 14
PAPER & HACKS #104 Qwen3-235Bの事後学習を 1ノードで試す 4bit QLoRA+GRPOの実行構成と報酬設計 ― H100 80GB×8の1ノードで、235B級モデルの強化 学習を実行して分かったこと 医療特化型LLMを作るには ― 学習編 弓場亮介 | チームHOLON Paper&Hacks #104 / チームHOLON / 弓場亮介 01 / 11
はじめに 今回共有すること 235B級モデルの事後学習を1ノードで試すための構成と、医療問題に合わせた報酬設計 01 02 03 1ノードで実行した構成と所要 時間 医療の多肢選択問題にF1報酬 を使った理由 長時間の学習前に確認したい 採点の対応関係 H100 80GB×8の1ノードで、回答の生 成から重みの更新・保存まで実行。構 成と、100ステップ・約31.5時間とい う記録を共有します。 完全一致では同点になる回答に、部分 一致に応じた優劣をつけようと考えた 経緯を説明します。 問題・生成回答・正解・報酬の対応を 確認する必要があること。実験を通じ て整理した確認事項です。 Paper&Hacks #104 / チームHOLON / 弓場亮介 02 / 11
背景と目的 なぜ1ノードで試したか NEDO医療LLMプロジェクトで事後学習を担当。計算資源はチーム共有で、事前学習などが並行していた 状況 複数ノードをまとめて確保するより、空いている1ノード(H100 80GB×8)を1〜2日使うほうが調整しやすい状況でした。 当時、235B級モデルへのRL適用事例は限られており、小規模で試した手 法がこの規模でも動くのかを確かめたいという動機がありました。 量子化とLoRAで必要なメモリを抑え、ms-swiftでH100×8の1ノードに収 める構成を検討しました。手法は、後ほど示す小規模モデルでの事前検 討を踏まえてGRPO系を選びました。 取り組みの目的 ① 確保しやすい1ノードで、235B級モ デルのRLによる事後学習を実行する ② 医療の多肢選択問題に合わせたルー ルベース報酬で、精度改善が得られ るかを確認する 用語 Qwen3-235B-A22B:LLMのモデル系列Qwen3のモデルで、総パラメータ数は約2,350億。今回の出発点は、公開モデルではなくプロジェクト内で 追加学習したチェックポイント。モデル構造(MoE)は実行構成のスライドで説明 Paper&Hacks #104 / チームHOLON / 弓場亮介 03 / 11
強化学習による事後学習 回答を採点して学習する仕組み モデル(方策)が生成した回答を正解と照合して報酬を計算し、報酬の高い回答の確率を上げる SFT(教師あり微調整) RL(強化学習) 模範解答を与え、同じように書くことを学ぶ 生成した回答を正解と照合し、報酬を使って方策を更新 する 採点用の正解(例:a, c) 問題 回答A:a を選ぶ 状態(入力) 報酬関数 方策の更新(GRPO) 回答と正解を照合し、報酬( スコア)を返す 同じ問題の回答群の中で報酬が 高い回答の確率を上げる 回答B:b, d を選ぶ GRPO [2] は価値モデル(critic)を使わず、同じ問題に生成した複数回答の報酬の平均を基準にする。今回は1問につき2回答を生成した Paper&Hacks #104 / チームHOLON / 弓場亮介 04 / 11
事前検討 事前検討:GRPO系を選んだ理由 小規模モデルと数学の文章題で比較したところ、この事前検討ではGRPO・GSPOがPPOより少ないステップ で高い平均報酬に達した 条件 内容 モデル・タスク Llama系の小規模モデル、GSM8K(数 学の文章題) フレームワーク verl、1ノード8GPU 1問あたりの回答数 16 報酬 正解 1.0 / 形式のみ 0.1 / 抽出不能 0 学習ステップ 設定は500。グラフはGSPO約140、 GRPO・PPO約420ステップまでの表示 この結果から、GRPO系の手法で検証を進めることにしました。 横軸は学習ステップで、計算時間の比較ではありません。 Paper&Hacks #104 / チームHOLON / 弓場亮介 平均報酬の推移(critic/score/mean) GSPO GRPO PPO 詳細:Qiita「Qwen3-235Bに4bit量子化+GSPOを適用した経験談」(弓場、 2026年1月) 05 / 11
実行構成 1ノードで実行するための構成:3つのポイント Qwen3-235B-A22BはMoE。1トークンで使うのは一部のExpertでも、全Expertを含むモデル全体、約235Bの重 みを保持する必要がある 保持を軽く 更新対象を絞る 分けて載せる 4bit量子化(NF4) LoRAはAttentionのみ 8GPUに分割配置 重みは4bitで保持し、演算はbf16で 行う。bitsandbytesによる量子化を ms-swiftから指定。モデル全体の重 みを8GPUの合計メモリに収めるた めの選択 q/k/v/o_projにrank 8のLoRA。学習 対象は約25.4Mパラメータ(全体の 0.011%)で、勾配やOptimizer状態 のメモリを抑える。Expertの重みは 固定 1プロセスから device_map="auto" で層を8GPUに分割。GPUごとにモ デルを複製するデータ並列ではなく 、1つのモデルを分けて保持する フレームワークは ms-swift 3.8.1。回答生成と学習を同一ノードで実行し、vLLMは未使用。KL項(beta)は0。設定値の一覧は付録A1。 この構成は「1ノードに収める」ための構成で、8GPUを同時に効率よく使う構成ではない(次のスライド)。 Paper&Hacks #104 / チームHOLON / 弓場亮介 06 / 11
実行結果 約31.5時間で100ステップを実行 生成から重み更新、保存までを1ノードで実行できた(目的①)。精度改善(目的②)は明確には確認できず 、確認事項(10/11)で説明 18.9分 約31.5時間 252 GPU時間 400回答 1ステップあたり 100ステップの合計(113,522 秒) 8GPU × 約31.5時間 延べ200問 × 2回答(100ステ ップ) 処理量とメモリ 学習中の平均報酬の推移(記録) 平均出力長 約628トークン(最大3500で設定、打ち切り は400回答中1件) ピークメモリ 236.8 GiB。各GPUのPyTorch予約メモリの最 大値を合計した値で、GPU別の偏りは別途記 録が必要 保存 checkpoint-100(LoRAアダプタ) 速度面の制約:分割配置ではGPUが順に動く。推論エンジンは未使用。時 間内訳・GPU使用率は未計測で、要因別の影響は測れていない Paper&Hacks #104 / チームHOLON / 弓場亮介 細線は各ステップの平均報酬、太線は10ステップ移動平均。平均報酬は約0.34前 後で上下した。採点対応がずれていた可能性があるため、学習の進み具合を示す 値としては扱っていない 07 / 11
報酬設計① 何を採点するか 正解のある問題は、ルールで採点できる 先ほどの事前検討では正誤と形式を採点した。医療問題では、データ形式に合わせて採点対象と方法を決めた 学習データの形式 採点の方法 入力 日本語の医療問題と a〜e の5つの選択肢 正解 1〜3個の選択肢記号。「2つ選べ」のように 正解数が指定される 出力形式 考察の後に [ans]a,c[/ans] の形で選択肢を書 く(評価時と同じ形式) 採点対象 最終的に選んだ選択肢の集合。解説文は採 点しない 正解が分かっているので、選んだ選択肢と正解を照合するル ールで採点できます。採点用のLLMを使わないので、推論コ ストやプロンプト調整が要りません。 参考にしたのは DeepSeek-R1-Zero の報酬設計 [1] で、正解と 出力形式をルールで評価しています。 報酬の式 選択肢集合のF1 + 形式点(タグがあれば0.05) 最大1.05。形式点は回答抽出を安定させるための補助。F1を使 った理由は次のスライドで Paper&Hacks #104 / チームHOLON / 弓場亮介 08 / 11
報酬設計② なぜF1か 完全一致では同点になる回答に、F1で優劣をつける 正解が {a, c} の場合の採点例 完全一致 F1 過不足なく正解 1 1.000 a cを取りこぼしている 0 0.667 a, c, d 正解に加えて、余分なdを選んでいる 0 0.800 b, d 正解の選択肢を一つも選べていない 0 0.000 回答例 状態 a, c ※形式点は各回答で同じとし、表では省略。 完全一致では 同点だと F1なら なぜF1か 部分的に正しい回答も、全部 間違った回答も、同じ0点にな る 同じ問題への回答が同点では 、この2回答の比較からは、報 酬に基づく学習信号が得られ ない 部分的に正しい回答を高く採 点でき、その回答を増やす方 向の学習信号を作れる 正解した選択肢の数だけ数え ると全選択が有利になる。選 びすぎと取りこぼしの両方を 考慮するF1を選んだ F1は学習用の部分点であり、試験としての正答判定とは区別する Paper&Hacks #104 / チームHOLON / 弓場亮介 09 / 11
確認事項 長時間の学習前に確認したいこと 実行後の確認で、生成した回答を別の問題の正解で採点していた可能性が見つかった 明確な精度改善も確認できておらず、今回の結果からF1・GRPOの効果は判定していません。この経験から、長時間の学習前に確 認したい項目を整理しました。同様の実験を行う方への共有事項です。 1 対応関係の確認 問題ID・生成回答・正解・報酬を対応 づけて保存する。正解はデータの追加 列で報酬関数に渡し(ms-swiftは追加 列を報酬関数で受け取れる [3])、並 べ替えや複数回答への展開を含む実際 の受け渡し経路で確認する Paper&Hacks #104 / チームHOLON / 弓場亮介 2 同じ回答で採点方式を比較 保存した同じ生成回答に完全一致とF1 を適用し、同点の割合や回答の順位が どう変わるかを確認する。モデルを再 学習せずに調べられる 3 学習前の基準値 学習前のモデルを、学習時と同じ問題 ・プロンプト・生成条件で採点し、基 準値を持つ。学習中の平均報酬と比べ る基準になる 10 / 11
まとめ 1ノードでの実行構成と、報酬設計で得た知見 実行構成と記録 H100 80GB×8で、4bit量子化・AttentionへのLoRA・モデルの分割配置を組み合わせ、100ステップを 約31.5時間で実行した F1を採用した理由 完全一致では同点になる回答に、部分一致に応じた優劣を付けるため 実験前の確認 問題・生成回答・正解・報酬の対応を確認し、学習前の基準値を持つことが重要 参考文献 [1] DeepSeek-AI (2025) “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning” arXiv:2501.12948 [2] Zhihong Shao et al. (2024) “DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models” arXiv:2402.03300 [3] ModelScope (2025) “Reward Function — ms-swift 3.8 documentation” アクセス日:2026/10/26 詳細:Qiita「Qwen3-235Bの事後学習を1ノードで試す:4bit QLoRA+GRPOの実行構成と報酬設計」「Qwen3-235Bに4bit量子化+GSPOを適用した経験談」(弓場) 謝辞:この成果は、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)の委託業務(JPNP25006)の結果得られたものです。 Paper&Hacks #104 / チームHOLON / 弓場亮介 11 / 11
付録A1 主な設定値 100ステップ実行時の設定値 ms-swift 3.8.1。W&Bに記録された実行時の設定に基づく モデル Qwen3-235B-A22B(MoE、総235B)をベースにプロジェクト内で追加学習したチェックポイント GPU H100 80GB × 8、1ノード。1プロセスから device_map="auto" で層を分割配置 量子化 4bit NF4、double quantization、演算はbf16(bitsandbytes) LoRA q_proj / k_proj / v_proj / o_proj、rank 8、alpha 16、dropout 0.05。学習対象 約25.4Mパラメータ GRPO loss_type grpo、num_generations 2、beta 0(KL項なし)、scale_rewards True、num_iterations 1 生成 max_completion_length 3500、temperature 0.7、top_p 0.9、vLLM未使用 学習 学習率 1e-5、cosine、warmup_ratio 0.05、per_device_train_batch_size 1、gradient_accumulation_steps 4、100ステ ップ 報酬 選択肢集合のF1 + 形式点0.05([ans]…[/ans] タグ)。ルールベース コードで明示指定していない引数はms-swift 3.8.1のデフォルト値を記載。保存スクリプトは後の版(1000ステップ設定)のため、値は実行時の記録を基準に した Paper&Hacks #104 / チームHOLON / 弓場亮介 A1