LLMバッチサイズスケーリング（エルエルエムバッチサイズスケーリング）
LLM（大規模言語モデル）の学習においてバッチサイズを適切に拡大・縮小する手法の総称。バッチサイズは 1 回のパラメータ更新で処理するサンプル数を決定し、学習速度・GPU メモリ使用量・最終的なモデル品質のすべてに影響を与える。GPT-4 クラスの数千億パラメータモデルでは、バッチサイズのスケーリング戦略が学習コストを数十パーセント単位で左右するため、分散学習設計の中核技術となっている。
LLMバッチサイズスケーリングとは
LLMバッチサイズスケーリング（LLM Batch Size Scaling）とは、大規模言語モデルの事前学習・ファインチューニングにおいて、バッチサイズ（1回のパラメータ更新で処理するトークン数またはサンプル数）を体系的に制御・拡大する技術群を指す。2026年現在、GPT-4o・Claude 4・Gemini 2.5 といったフロンティアモデルの学習では、数百万トークン規模のグローバルバッチサイズが標準となっており、その制御はモデル品質とインフラコストの両面を決定づける。
バッチサイズの概念は深層学習の初期から存在するが、LLM の登場により根本的に重要性が変化した。従来の画像認識モデル（ResNet 等）ではバッチサイズ 256〜8,192 が典型的だったのに対し、LLM では 100 万〜1,000 万トークンのバッチが日常的に使用される。この桁違いのスケールでは、バッチサイズの選択が学習の安定性・収束速度・最終性能に非線形な影響を及ぼし、単純に「大きければ良い」とは言えない複雑なトレードオフが生じる。
バッチサイズが学習に与える影響
バッチサイズの変更は以下の4つの軸でモデル学習に影響する：
1. 勾配推定の精度：バッチサイズが大きいほど勾配の推定分散が小さくなり、パラメータ更新の方向が安定する。理論的には分散は 1/B（B はバッチサイズ）に比例して減少するため、バッチサイズを 4 倍にすると勾配ノイズは半分になる。ただし、ある閾値（クリティカルバッチサイズ）を超えると精度向上の恩恵は急速に逓減する。
2. 学習速度（壁時計時間）：バッチサイズを N 倍にすると理論上 N 倍のデータ並列性が得られ、同じステップ数をより短時間で処理できる。しかし実際には All-Reduce 通信やメモリバンド幅がボトルネックとなり、線形スケーリングは 64〜256 GPU 程度で頭打ちになることが多い。
3. GPU メモリ消費：バッチサイズの増加は活性化値（activation）のメモリ消費を比例的に増加させる。70B パラメータの LLM では、バッチサイズ 1 でもパラメータ自体が FP16 で 140GB を消費するため、限られた GPU メモリ内でのバッチサイズ最適化が不可欠。
4. 汎化性能：小さなバッチサイズは勾配ノイズが大きく、損失関数の「平坦な谷（flat minima）」に到達しやすいとされ、汎化性能に有利という実験的証拠がある。一方で LLM の事前学習では、データ量が十分に大きいため汎化ギャップが比較的小さく、バッチサイズの汎化への影響は従来の CV タスクほど顕著ではない。
スケーリング手法の全体像
LLM バッチサイズスケーリングには以下の主要手法が存在する：
| 手法 | 概要 | メモリ効率 | 通信コスト | 実装複雑度 | 代表的利用シーン |
|---|---|---|---|---|---|
| マイクロバッチング | 大バッチを小分割してGPU逐次処理 | 高 | なし（単GPU） | 低 | ファインチューニング |
| 勾配累積 | 複数フォワードパスの勾配を蓄積後に更新 | 高 | なし（単GPU） | 低 | メモリ制約下の学習 |
| データ並列（DDP） | 同一モデル複製を複数GPUで並列実行 | 中 | 高（All-Reduce） | 中 | 中規模事前学習 |
| ZeRO Stage 1-3 | オプティマイザ/勾配/パラメータを分散 | 非常に高 | 中〜高 | 高 | 大規模事前学習 |
| パイプライン並列 | モデルをレイヤー単位で分割し流れ作業 | 高 | 中（P2P） | 高 | 超大規模モデル |
| テンソル並列 | 個々のレイヤー内を分割 | 中 | 非常に高 | 非常に高 | 超大規模モデル |
| FSDP（Fully Sharded） | ZeRO Stage 3 の PyTorch ネイティブ実装 | 非常に高 | 高 | 中 | PyTorch エコシステム |
これらの手法は排他的ではなく、実際のフロンティアモデル学習では複数を組み合わせる「3D 並列化」（データ並列 × パイプライン並列 × テンソル並列）が一般的である。
バッチサイズウォームアップ
LLM の事前学習では、学習初期に小さなバッチサイズから開始し、徐々に拡大する「バッチサイズウォームアップ」が広く採用されている。この手法は Google の PaLM 論文（2022）で体系化され、以下のメリットがある：
- 学習初期の安定性向上：ランダム初期化直後はパラメータが不安定で、大バッチの安定した勾配よりも小バッチのノイジーな勾配のほうが良い探索を行える
- データ効率の改善：初期段階で少量のデータを何度も更新し、後半で大量のデータを効率的に処理する
- インフラ段階投入：学習開始時に全 GPU クラスタが準備完了していなくても、少数 GPU で開始して段階的にスケールアウトできる
典型的なウォームアップスケジュールでは、最初の 1〜5% のステップでバッチサイズを最終値の 1/8〜1/4 から開始し、線形または指数関数的に増加させる。Llama 3 の学習では初期バッチサイズ 400 万トークンから最終 1,600 万トークンまで段階的に拡大したことが報告されている。
学習率との連携（リニアスケーリングルール）
バッチサイズを変更する際、学習率も連動して調整する必要がある。最も広く用いられる指針が「リニアスケーリングルール」である：
ルール：バッチサイズを k 倍にしたら、学習率も k 倍にする。
これは Goyal et al.（2017）が ResNet の学習で実証し、その後 LLM にも適用された。直感的には、バッチサイズが k 倍になると 1 ステップで k 倍のデータを処理するため、同じ「距離」をパラメータ空間で移動するには k 倍大きなステップが必要になるという論理である。
ただし、この線形スケーリングには限界がある。バッチサイズが非常に大きくなると学習が不安定化するため、実際には平方根スケーリング（学習率を √k 倍にする）や、LAMB・LARS といったレイヤーごとに学習率を適応的に調整するオプティマイザが使用される。
| スケーリング方式 | 学習率調整 | 適用範囲 | 代表的オプティマイザ |
|---|---|---|---|
| リニアスケーリング | η × k | バッチサイズ ≤ 8K | SGD, Adam |
| 平方根スケーリング | η × √k | バッチサイズ 8K〜64K | Adam, AdamW |
| レイヤー適応型 | レイヤーごとに自動調整 | バッチサイズ 64K+ | LAMB, LARS |
LLM 事前学習における実践例
主要な LLM の事前学習で使用されたバッチサイズと関連設定を以下にまとめる：
| モデル | パラメータ数 | グローバルバッチサイズ | シーケンス長 | 総トークン数 | GPU 構成 |
|---|---|---|---|---|---|
| GPT-3 | 175B | 3.2M トークン | 2,048 | 300B | 約 1,024× V100 |
| PaLM | 540B | 4M トークン | 2,048 | 780B | 6,144× TPU v4 |
| Llama 2 | 70B | 4M トークン | 4,096 | 2T | 2,048× A100 80GB |
| Llama 3 | 405B | 16M トークン | 8,192 | 15T | 16,384× H100 |
| Mistral Large 2 | 123B | 8M トークン | 32,768 | 12T | 非公開 |
これらの実例から、モデルサイズの増大に伴いバッチサイズも拡大する傾向が明確に見られるが、クリティカルバッチサイズの制約により無制限に拡大できるわけではない。
コスト最適化の観点
バッチサイズのスケーリングは直接的に学習コストに影響する。2026 年時点の H100 GPU クラスタ（クラウド）の相場を基準にした試算：
- バッチサイズ 2 倍でステップ数半減の理想ケース：GPU 台数 2 倍 × 学習時間 1/2 = 総 GPU 時間同等。ただし通信オーバーヘッドで実際は 10〜20% 増
- クリティカルバッチサイズ超過ケース：バッチサイズ 2 倍でもステップ数は 30% 程度しか減らず、GPU 台数 2 倍のコストが丸ごと追加
このため、クリティカルバッチサイズ付近での運用が最もコスト効率が高い。Meta の Llama 3 学習では推定 3,000 万ドルの計算コストがかかっており、バッチサイズの最適化だけで数百万ドルの差が生じうる。
FAQ
Q: LLM のバッチサイズはなぜトークン数で表記するのですか？
A: LLM の入力はシーケンス（文章）であり、1 サンプルのトークン数がシーケンス長によって異なる。たとえばシーケンス長 4,096 でサンプル数 1,024 の場合、実際に処理するトークン数は約 420 万となる。計算コスト（FLOPs）はトークン数に比例するため、トークン数で表記するほうがモデル間の比較やコスト計算が容易になる。シーケンス長が異なるモデル（GPT-3 の 2,048 と Llama 3 の 8,192）を比較する際にはサンプル数ではなくトークン数でバッチサイズを統一して議論する。
Q: ファインチューニングでもバッチサイズスケーリングは重要ですか？
A: ファインチューニングでは事前学習ほど大きなバッチサイズを使わないが、スケーリング戦略は依然として重要である。LoRA や QLoRA を用いた PEFT（パラメータ効率的ファインチューニング）では、学習可能パラメータが少ないため勾配計算が軽く、比較的大きなバッチサイズ（32〜128）を単一 GPU で実行できる。一方で、フルファインチューニングではメモリ制約から勾配累積が必須となり、実効バッチサイズ 256〜1,024 を数ステップに分割して実現するのが一般的。SFT（教師ありファインチューニング）では小さなバッチサイズ（4〜16）のほうが汎化性能が良いという報告もある。
Q: バッチサイズを大きくしすぎるとどうなりますか？
A: クリティカルバッチサイズを大幅に超えると、追加のデータ並列化から得られる学習速度の向上が僅かになる一方、GPU の通信コストと電力消費が比例的に増大する。具体的には、勾配のシグナル対ノイズ比（SNR）が十分に高いため追加サンプルからの情報利得がほぼゼロとなり、「計算の無駄遣い」状態に陥る。また、大バッチの安定した勾配は損失関数の「鋭い谷（sharp minima）」に収束しやすく、汎化性能の低下（generalization gap の拡大）が観測されることがある。LLM の事前学習では汎化ギャップの影響は限定的だが、ファインチューニングでは顕著に現れることがある。
Q: バッチサイズのスケーリングに使えるオープンソースツールは何がありますか？
A: 主要なフレームワークとして PyTorch FSDP（Fully Sharded Data Parallel）、DeepSpeed ZeRO Stage 1-3、Megatron-LM、Colossal-AI がある。PyTorch FSDP は PyTorch 2.x 以降でネイティブサポートされ、勾配累積・混合精度・シャーディングを統合的に扱える。DeepSpeed は Microsoft が開発し、ZeRO-Infinity によるオフロード機能で単一 GPU でも大規模モデルの学習が可能。Megatron-LM は NVIDIA が開発し、3D 並列化のリファレンス実装として広く参照される。2026 年時点では PyTorch FSDP2（FSDPv2）が主流になりつつあり、既存の DDP コードからの移行が容易になっている。