0. はじめに
対象読者：LLMの事後学習に興味がある人・推論モデルの学習に興味がある人・その他の理由でこの記事を開いてみようと思った人
内容：100B超えLLMの学習を行う際に知っておきたい学習を支える手法とツールの知識
1. 記事執筆の経緯
この記事では、松尾研LLMコンペ2025に優勝チームのモデル班のリーダーとして参加した際の経験をもとにノウハウを共有しようと思います。
今回参画したコンペにおける目標はオープンソースLLMの事後学習を行うことでHLE (Humanity’s Last Exam) のSOTAを更新することでした。HLEとは現行のベンチマークの中で最も難易度が高いとされている推論タスク用のベンチマークです。
プロジェクト開始時点（2025/07/21）でオープンソース最高性能のモデルはdeepseek-ai/DeepSeek-R1-0528。次点でQwen/Qwen3-235B-A22Bが高い評価ということが分かっており、これらのモデルをベースモデルとして学習を行うことが最初のステップになりました。
しかしながら、DeepSeek-R1-0528の学習実行は難航しました。理由はいくつかありますが、突き詰めればLLM学習手法やツールに対する知見不足。それに尽きると思います。
最終的には次点の候補だったQwen3-235B-A22Bの学習を実行することに成功し、予選突破を果たしました。
そして、コンペの決勝開始時点ではQwen/Qwen3-235B-A22B-Thinking-2507がDeepSeek-R1-0528の性能を上回っていたことから同じアーキテクチャのモデルを学習することになりました。
今回のコンペを通して、LLMの構造の理解だけでなく学習を支える手法の理解もとても重要だと感じました。
この記事では、開発の予備知識としてあったら良かったと思う知識を整理してお伝えしようと思います。
2. 学習における並列化
最近の大規模言語モデルはパラメータ数が100Bを超えることも少なくありません。そのため、単一のGPUメモリでは処理が遅かったり、OOM（メモリ不足）に陥る可能性が高くなります。
このような問題を避けるために複数のGPUメモリを同時に使うことで、処理できる計算量を大幅に上げることが出来ます。このような手法を並列化と呼び、主にData ParallelとModel Parallelという分類に分けられます。
Data Parallel (DP)
Data Parallelの主な目的は複数GPUにおいて並列で学習を行うことで学習を高速化することです。
この方法では単純に複数GPUに渡ってモデルのコピーを保持し、分割したデータセットの一部をそれぞれのGPUが学習します。この学習の結果をあとから一つに集約することで重みの更新を行います。
Data Parallelという場合には一般的に一つのマシン上のマルチGPUを想定しており、複数マシンを想定する場合はDistributed Data Parallel (DDP) と呼びます。
ZeRO
Data Parallelを発展させた手法として、ZeRO (Zero Redundancy Optimizer)と呼ばれるものがあります。この手法では、Data Parallelの中でさらにオプティマイザ、勾配、パラメータをそれぞれ分割して保持することでメモリの使用率を大幅に下げることができます。また、追加でCPUやNVMeのメモリへのオフロードを行うことで更なるメモリの節約を行える枠組みが整えられました。
Model Parallel (MP)
Model Parallelの主な目的は巨大なモデルの重みを分割して保持することで学習を可能にすることです。
更に細かい分類として、Tensor Parallel、Pipeline Parallel、Expert Parallelが存在しています。
Tensor Parallel (TP)
Tensor Parallelでは一つのテンソルを特定の方向にスライスして分割し、その分割ごとの計算を最終的に結合することでテンソル全体の計算を行う方法です。
言葉で言ってもわかりにくいと思うので以下の図を見てください。図ではQKVそれぞれのテンソルを二つに分割して入力Xに対して演算を行っています。最終的には計算結果を結合することで通常と同じ結果Zを得ることができます。
引用元：Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM
また、Tensor Parallelに追加してSequence Parallelと呼ばれる手法もあり、この手法ではTensor Parallelを適用できない非線形の演算に対して長いテキストデータを区切って処理する方法になっています。
Pipeline Parallel
Pipeline Parallelは層単位でモデルを分割して各GPUに割り当てることで順番にモデルの学習を進めていく方法です。ただし、各層の順番的な制約のために空白の時間が生まれてしまうという点では非効率な手法といえるでしょう。
引用元：GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism
Expert Parallel
Expert ParallelはMoEモデルにおけるエキスパートを複数のGPUに分散して保持する方法です。エキスパートの層以外は分散しないため、Routerの学習が競合することもありません。
引用元：NVIDIA NeMo Framework User Guide
複合的な並列化
並列化の手法をここまでいくつか見てきましたが、これらの手法は実際には独立して使われているばかりでなく、組み合わせて使うことで更に効率化を行うことができます。
3D Parallelism
Data Parallel、Tensor Parallel、Pipeline Parallelの3つの並列化手法を組み合わせることでメモリ効率と計算効率の両面で最適化を行います。基本的にはマルチノードを用いた学習ではこの方法を取ることが推奨されています。
Tensor ParallelとPipeline Parallelを使うことでモデルの層内での分割と層ごとの分割を同時に行い、より大きなモデルでも細かく分割することが可能になります。
ZeROを活用したData Parallelを使うことでそれぞれのGPUではオプティマイザ、勾配、パラメータの一部しか保持しないため、必要なノード間通信が最小限に抑えられます。
実用上は限られたGPU数の中で並列数を適切な値に設定することでモデルの処理をメモリ効率と計算効率の両面から最適化することが必要になります。
3. LLM学習ツール
ここまでに紹介してきた並列化手法は多くのツールによってサポートされています。LLMの学習を補助してくれるツールたちについてもここで紹介しておこうと思います。
Hugging Face TRL
基本となるツールをほぼ全て提供しているAIコミュニティ。モデルの訓練から推論までをカバーするtransformers、データセット、PEFTなどのツールを提供しています。
学習のフレームワークとしてはTRLが有名ですが、これをベースとして他のフレームワークが作られているので比較的シンプルな機能性になっているように感じられると思います。
参考リンク：https://github.com/huggingface/trl
Axolotl
事後学習・ファインチューニングに特化したツールで、有力な訓練手法やデータセットのクラウドサービス連携・実行環境のDockerイメージを提供するなどの特色があります。
参考リンク：https://github.com/axolotl-ai-cloud/axolotl
LLaMA-Factory
充実したモデルのラインアップと新しいモデルへの対応速度の速さなどに加えて、モデル学習のためのプラットフォームサービスも展開しています。ただし、一部英語ドキュメントが中国語のままになっているなど、中国語での提供速度が優先されている印象を受けました。
参考リンク：https://github.com/hiyouga/LLaMA-Factory
ms-swift
ModelScopeのコミュニティが開発するフレームワークであり、中国版Hugging Faceに相当するコミュニティとしてAlibaba Cloudが展開しているものになります。
最新の手法もかなり網羅されており、事前学習・事後学習・推論などあらゆる工程をサポートするツールとして存在感を増しているように感じます。
参考リンク：https://github.com/modelscope/ms-swift
Unsloth
より高速でメモリ効率の良い学習のために様々な最適化を施しているツール。単純に推論用にモデルを動かすためには非常に手軽に使えますが、学習時にはバグが比較的多い印象を受けました。
参考リンク：https://github.com/unslothai/unsloth
verl
事後学習の中でも特に強化学習に力を入れているツール。ByteDanceが提供しており、基本的な強化学習を行うだけならドキュメントも充実しています。ただ、開発のスピードなどは主要なツールに比べると遅いと思います。
参考リンク：https://github.com/volcengine/verl
フレームワークの選定
ここまで各種ツールを紹介してきましたが、実際はどれを使えば良いのかということを知りたい方もいるでしょう。個人的な意見としては、基本的にAxolotlかLLaMA-Factoryを選ぶのが無難だと思います。個人的に成功体験があるのはms-swiftとverlなのですが、傍から見てもドキュメントの量や外部記事の数などはAxolotlやLLaMA-Factoryが多いように感じます。
まずはこの二つのライブラリで必要な機能がないかを確認した上で他のツールを検討するような流れで良いと思います。
どうしても満足できずにメモリを効率化したい場合はUnsloth、Megatron-LMとの連携の容易さでms-swift、といった形でケースによっては他のツールを選択するのが良いでしょう。
4. GPUメモリの要件
先のセクションでは学習ツールについて触れましたが、実際にモデルの学習を行う際に一番気になるのはどれだけGPUメモリが必要なのか？ということでしょう。
フルパラメータでモデルのファインチューニングを行う際にFP32形式でデータを保持するなら、ざっくりとした計算で
- モデルの重み：32 bit × パラメータ数
- オプティマイザの状態：32 bit × 2 × パラメータ数
- 通常のAdamWでは2つの状態を保持
- 勾配計算：32bit × パラメータ数
- その他の一時的なメモリ
を同時に保持することが必要になります。
例えば100Bのモデルを想定するなら、これだけでも1600GBのメモリが必要ということになります。
LoRAを使うのであれば99％程度のパラメータを凍結させることになるので、オプティマイザや勾配の情報が1％まで減るという計算であれば412GB程度まで減らすことができます。
更にQLoRAを用いてモデルの重み自体も8 bitなどで保持すると考えれば103GBまでメモリの使用を抑えることも可能になります。
このようにしてベースとしてどの程度のメモリが必要になるのかを見積もり、自前のリソースと相談しながら学習方法を検討することで適切な学習手法を選定できると考えられます。
ただし、これはシンプルなファインチューニングのケースであり、強化学習の手法を用いる場合にはいくつかのモデルの推論を要求されることもあります。これによって更に計算が複雑になることが想定されますが、その場合でもざっくりとしたオーダーを間違えないように見積もりを行うことが大切になるでしょう。
5. 終わりに
ここまでお読みいただきありがとうございました。実際に100B超えのLLMをファインチューニングしたという経験をもとに、自身が学んだノウハウを還元してみました。
これで全てではないですが、あとは他のチームメンバーに譲ろうと思います。
適切なメンター等に師事しているわけではないため、間違っている箇所も多々あるかもしれません。その際はコメントにて有識者の方の意見・訂正等をいただければと思います。
もし学びになることがあったらいいねを付けてもらえると喜びます！
参考文献
本プロジェクトは、国立研究開発法人新エネルギー・産業技術総合開発機構(以下「NEDO」)の「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」における基盤モデルの開発プロジェクトの一環として行われます。