LLM【スケール則：最適配分戦略C-4】

前回の C3 では、どれだけのデータを、どの品質で、どの順序で使うかを整理しました。C4 では、その前提を受けて「そのデータをどのアーキテクチャで最も活かすか」を考えます。

データセット戦略が整っても、アーキテクチャの選択を誤ると、学習効率も推論効率も伸びません。逆に、用途に合う構造を選べば、同じ予算でも性能の出方が変わります。この記事では、Transformer と MoE を中心に、Scaling Law の見方、判断基準、実務での選び方を順番に整理します。

1. なぜ C4 でアーキテクチャ選択を扱うのか？

前回の C3 で見たのは、データの量と質の話でした。しかし実務では、そこからすぐに次の問いが出てきます。

• そのデータ量なら、どのアーキテクチャが最も素直に伸びるのか？
• 学習効率を優先するのか、推論効率を優先するのか？
• 研究用途と商用用途で、同じ構成を選んでよいのか？

この章の役割は、理論を新しい記号で増やすことではなく、C3 で整えたデータを、どの構造に載せると無駄が少ないかを判断できるようにすることです。

言い換えると、データが十分でも、モデル構造が合っていなければ性能は伸びません。たとえば一般用途のモデルに対しては Transformer が安定ですが、巨大モデルや推論時の計算効率を重視する場面では MoE が候補になります。ここを曖昧にしたまま進むと、後から「データはあるのに伸びない」「モデルは大きいのに推論が重い」という形で詰まりやすくなります。

2. Scaling Law から見ると何が分かるのか？

Scaling Law は、モデルサイズと性能の関係を比較するための考え方です。ただし、実務でそのまま使うときは、まず「何を基準にした法則なのか」を押さえる必要があります。

2-1. 基本は Transformer を基準にしている

Scaling Law の多くは、Transformer 系のモデルを前提に議論されています。つまり、研究論文で見かける係数や改善率は、Transformer を中心とした実験結果であることが多いです。

そのため、別のアーキテクチャにそのまま数値を当てはめると、見かけ上は比較できても、前提がずれていることがあります。ここは注意点です。

2-2. α の見方を整理する

アーキテクチャ比較でよく出てくるのが、スケーリング係数の α です。

$$ L(N) = L_0 \times N^{-\alpha} $$

この式は、モデルサイズ $N$ を増やしたときに損失 $L$ がどう下がるかを表しています。ここで重要なのは、α が大きいほど、サイズを増やしたときの改善が大きく見えやすいという点です。

ただし、これは「常に大きい α のモデルが優秀」という意味ではありません。学習条件、推論条件、運用制約が違えば、同じ α でも実務上の価値は変わります。

2-3. 代表的な比較を並べる

この表で見たいのは、優劣ではなく役割の違いです。Scaling Law の観点では、Transformer が基準になりやすく、MoE は大規模化したときの選択肢として浮上します。

3. Transformer と MoE は何が違うのか？

アーキテクチャ選択で最も迷いやすいのは、Transformer と MoE のどちらを選ぶかです。ここは「何を得たいか」で整理すると判断しやすくなります。

3-1. Transformer は何が強いのか？

Transformer の強みは、構造が分かりやすく、学習が安定しやすく、実装・運用の前提を揃えやすいことです。

特に次のような場面では、Transformer を選ぶ合理性が高いです。

• 最初に作る基盤モデルで失敗コストを抑えたい
• 学習パイプラインをシンプルに保ちたい
• チーム全体で再現しやすい構成にしたい

要するに、Transformer は「最初の標準案」として強いです。

3-2. MoE は何が違うのか？

MoE は、複数の Expert を用意し、入力に応じて一部だけを使う構造です。すべてのパラメータを毎回使うのではなく、必要な部分にだけ計算を寄せられるため、大規模モデルで効率を出しやすくなります。

MoE のイメージは次のように捉えると分かりやすいです。

1. 入力が入る
2. Gate がどの Expert を使うかを判断する
3. 選ばれた Expert だけが計算する
4. 出力が返る

この構造の利点は、見かけ上のモデルサイズを大きくしても、毎回の計算量を抑えやすいことです。たとえば Mixtral 8x7B のように、総パラメータは大きくても、実際の計算は Top-2 Expert に絞られるため、推論コストの見え方が変わります。

ただし、MoE は万能ではありません。ゲートの設計、Load Balancing、希少性の制御など、運用上の難所が増えます。性能が出ても、安定運用が難しければ採用しづらいです。

3-3. 比較すると何が見えるのか？

結論だけを先に言うと、迷うなら Transformer、巨大化と効率化を同時に狙うなら MoE です。

4. どういう基準で選べばよいのか？

アーキテクチャは、機能一覧よりも判断基準で選んだほうが失敗しにくいです。ここでは、実務で使いやすい 4 つの観点に絞って整理します。

4-1. モデル規模で見る

小〜中規模の段階では、Transformer のほうが素直です。規模が大きくなるほど、MoE のような疎な構造が候補に入りやすくなります。

目安としては次のように考えると整理しやすいです。

4-2. GPU メモリと運用制約で見る

理論上よい構造でも、GPU メモリが足りなければ運用できません。特に MoE は、計算の一部を抑えられても、構成全体の管理コストは上がることがあります。

ここでの判断は単純です。

• メモリに余裕があり、構造も複雑にできるなら MoE を検討する
• メモリや運用体制に余裕がないなら Transformer を選ぶ

4-3. 推論コストで見る

学習時にうまく見えても、推論時に重すぎると商用利用では厳しくなります。MoE は、毎回の計算を絞れる点で有利ですが、レイテンシや分散実装の難しさは別途見ないといけません。

ここでのポイントは、学習効率と推論効率は同じではないことです。C3 で整えたデータを活かすだけなら学習効率に目が行きやすいですが、実際のサービスでは推論コストのほうが長期的な制約になることがあります。

4-4. チームの経験値で見る

新しい構造ほど、導入時の学習コストは上がります。MoE に経験がないチームが、最初から大規模 MoE を採用すると、実装の難所よりも運用の難所で止まりやすいです。

判断基準は次の通りです。

• 初期立ち上げや研究立ち上げなら Transformer
• 既存の運用知見があり、大規模効率を狙うなら MoE
• チームで再現性を優先するなら、まず Transformer で基盤を固める

5. 実例で見るとどう考えればよいのか？

5-1. Mixtral 8x7B はなぜよく引き合いに出されるのか？

MoE の例として Mixtral 8x7B がよく挙がるのは、見かけの総パラメータと実際の計算量の差が分かりやすいからです。

• 総パラメータは 54B 規模
• 実際の計算は Top-2 Expert により 12.9B 相当と説明されることが多い
• Transformer 13B と比較すると、規模感と計算感が分かれやすい

ここで重要なのは、「大きいから強い」ではなく、「大きいけれど全部を毎回使わないから効率が出る」という点です。

5-2. マルチモーダルでは何が変わるのか？

画像を含むモデルでは、テキストだけの設計と同じ発想では足りません。テキスト Encoder とビジョン Encoder の配分を考える必要があります。

このときの注意点は、単純な 50:50 が常に最適とは限らないことです。入力の主役がどちらかで、必要な容量配分は変わります。

5-3. 旧世代構造はどう扱うのか？

RNN や LSTM は、今でも理論的な意味はありますが、新規の LLM 設計では第一候補になりにくいです。長文処理で有利な場面があったとしても、Transformer 以降の標準的な実装・運用の流れと比べると、採用理由を作りにくいからです。

つまり、ここでは「選択肢として知っておく」ことが重要であって、「積極的に採用する」ことが主眼ではありません。

6. どういう順番で決めると失敗しにくいのか？

アーキテクチャ選択は、最初から結論を固定すると失敗しやすいです。先に制約を並べてから、構造を選ぶほうが安全です。

6-1. まず用途を固定する

最初に決めるべきなのは、学習したモデルを何に使うかです。研究用なのか、プロダクト用なのか、画像を含むのか、推論レイテンシが厳しいのかで、選ぶ構造は変わります。

6-2. 次に制約を並べる

次の 3 つを先に確認すると、判断しやすくなります。

1. 利用できる GPU 規模
2. 学習と推論のどちらを重く見るか
3. チームにその構造を運用する経験があるか

6-3. 最後に候補を絞る

ここまで来ると、候補はかなり絞れます。

• 用途が一般的で、まず安定性を優先するなら Transformer
• 大規模化したい、推論効率も重視したいなら MoE
• 画像も含むマルチモーダルに広げたいなら、Transformer 系を軸にしつつ ViT 系の比較を入れる

この順序にすると、「面白そうだから採用する」という判断を避けやすくなります。

7. よくある失敗は何か？

アーキテクチャ選択でよくある失敗は、だいたい次の 3 つです。

• モデルの大きさだけで判断する
• 学習時の性能だけを見て、推論コストを後回しにする
• チームの運用経験より、話題性を優先する

特に多いのは、MoE の「効率が良さそう」という印象だけで採用してしまうケースです。実際には、ゲート制御や分散運用が難しく、実装と保守の負荷が上がります。

逆に、Transformer は地味に見えても、実装しやすさと再現性の高さが武器です。最初の一歩としては、こちらのほうが失敗しにくいです。

8. 次に進む前に何を確認すべきなのか？

本番設計に入る前に、少なくとも次を確認したほうがよいです。

• 目的は学習効率か、推論効率か、それとも両方か？
• 想定モデル規模に対して、Transformer と MoE のどちらが現実的か？
• GPU メモリと運用体制は十分か？
• マルチモーダル化の予定はあるか？
• チームにそのアーキテクチャの運用経験があるか？
• C3 で整えたデータと、構造の相性はよいか？

ここで大切なのは、最初から「最強構成」を狙わないことです。理論上よく見える構成と、実際に回る構成は違います。小さく試して、学習と推論の両方で見てから決めるほうが安全です。

この確認は、設計を止めるためではありません。後戻りのコストが高くなる前に、見落としやすい前提を先に潰すためのものです。ここを通しておくと、次の C5 で環境別のデプロイメント戦略を考えるときに、どの構成が運用しやすいかがはっきりします。

9. まとめ

C4 の重要な教訓は、アーキテクチャ選択を「好み」ではなく、データ、規模、推論コスト、運用体制の組み合わせで決めることです。同じデータでも、載せる構造が違えば結果は変わります。

今回の要点は次の通りです。

• Scaling Law は Transformer を基準に見ると理解しやすい
• α はスケール効率の目安だが、単独で優劣を決める指標ではない
• Transformer は安定性と再現性で強く、MoE は大規模化と効率化で強い
• マルチモーダルでは、テキストとビジョンの配分を別に考える必要がある
• 実務では、モデル規模、GPU、推論コスト、チーム経験をまとめて見るべきである

最適なアーキテクチャ選択とは、流行の構造を追うことではありません。自分たちのデータと運用条件に合う構造を選び、無理なく回せる形に落とし込むことです。

10. 今回のブログの考察

C4 の本質は、データ戦略で整えた材料を、どの構造に載せると最も無駄が少ないかを見極めることです。C3 でデータを増やすだけでは十分ではなく、そのデータをどう使うかで、性能の伸び方も運用のしやすさも変わります。

この章で見たように、アーキテクチャ選択は単なる実装選定ではなく、モデル性能と運用効率を左右する意思決定です。特に、Transformer で始めるのか、MoE に進むのか、あるいはマルチモーダル前提で配分を組み直すのかは、後続のデプロイ戦略にもそのまま影響します。

次の C5 では、このアーキテクチャ前提を受けて、どの環境にどう展開すれば無理が少ないのかを見ていきます。

参考文献

1. Jiang, A., et al. (2024). “Mixtral of Experts.” Mistral AI.
2. Fedus, W., et al. (2022). “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.”

このシリーズの案内

• C-3: データセット戦略
• C-5: 環境別デプロイメント戦略