AIモデルの性能指標として長らく使われてきた「パラメータ数」ですが、MoE（Mixture of Experts：専門家モデルの組み合わせ）アーキテクチャの登場によって、その意味合いは劇的に変化しました。カタログスペックをそのまま鵜呑みにすることが、なぜシステム設計において危険なのか。まずは、その構造的なパラドックスから論理的に紐解いていきましょう。
DenseモデルとSparseモデルの決定的な違い
これまで主流だったDense（密）モデルは、非常にシンプルなルールで動いています。かつて基準とされたLlama 2はすでに廃止され、現在は128kコンテキストに対応したLlama 3.3や、さらに大規模な次世代アーキテクチャへと進化していますが、Denseモデルとしての基本原理は共通しています。
- Denseモデルの鉄則: 入力された1つのトークン（単語の断片）に対し、モデル内のすべてのパラメータが計算に参加する。
つまり、70B（700億）パラメータのモデルであれば、1トークンを処理するために毎回700億個のパラメータすべてをメモリから読み出し、演算を行う必要があります。ここでは「パラメータサイズ ≒ 計算量 ≒ メモリ使用量」という等式が概ね成立していました。
しかし、MoEのようなSparse（疎）モデルは仕組みが異なります。
- Sparseモデル（MoE）の鉄則: 入力されたトークンに対し、条件に合う一部の専門家（Expert）パラメータだけが計算に参加する。
これは、巨大な図書館に例えると分かりやすいでしょう。Denseモデルが「質問に答えるために図書館の本を全部読む」アプローチだとすれば、MoEは「質問に関連する専門書だけを数冊選んで読む」アプローチです。図書館全体の蔵書数（総パラメータ）がどれだけ多くても、一度に読む本（有効パラメータ）が少なければ、回答速度は速くなります。
「総パラメータ」対「有効パラメータ」のパラドックス
ここでシステム要件の定義を難しくさせるのが、「保存に必要な容量」と「計算に必要な容量」の不一致です。
- ストレージ / VRAM容量: 図書館の蔵書すべてを保管するスペースが必要です。つまり、総パラメータ数（Total Parameters）に依存します。
- 推論速度 / FLOPs（計算量）: 実際に読む本の量で決まります。つまり、有効パラメータ数（Active Parameters）に依存します。
リリース当時、「Mixtral 8x7BはGPT-3.5レベルの性能だが、推論はLlama 2 13B並みに速い」と業界で大きな話題になったのはこのためです。現在ではGPT-3.5の提供は終了し、ChatGPTは適応的推論を強化したGPT-5系へと移行しています。また比較対象だったLlama 2 13Bも廃止され、より高性能なLlama 3.3や日本語に強いQwen3などの最新モデルが主流となっています。
しかし、モデルが世代交代してもMoEの構造的な罠は健在です。有効パラメータ数の少なさを見て「小さなモデル用のGPUで動く」と勘違いすると、システムはメモリ不足でクラッシュしてしまいます。推論速度は速くても、VRAM（ビデオメモリ）には47B分（Mixtral 8x7Bの場合）の巨大なデータを展開しなければならないからです。
コスト試算における見積もりミスを防ぐ
「パラメータ数」という言葉が、「ディスク上のサイズ」を指しているのか、「実行時の計算量」を指しているのか。この定義を明確に区別しない限り、正確なコスト試算は不可能です。
近年では、RTX 50シリーズの登場により、RTX 5090で32GB、RTX 5080や5060 Tiでも16GBのVRAMが標準化されつつあります。さらに、新たなデータフォーマット（NVFP4やFP8）によるVRAM消費の削減技術も進展し、大規模モデルをローカル環境で実行するハードルは下がりつつあります。
それでも、MoEモデルを導入する際は「総パラメータ数を保持できる十分なVRAM容量があるか」と「有効パラメータ数に基づいた高速な推論スループットを活かせるか」という2つの軸でハードウェア要件を評価する必要があります。表面的なパラメータ数だけで判断せず、実際のメモリフットプリント（占有量）と計算負荷を正確に把握することが、プロジェクトを成功に導く鍵となります。
解剖：MoEアーキテクチャの構成要素とパラメータ定義
では、具体的にどの部分が「総パラメータ」に含まれ、どの部分が「有効パラメータ」としてカウントされるのでしょうか。MoEの内部構造を分解して解説します。
MoEといっても、モデル全体がバラバラのExpertになっているわけではありません。一般的に、TransformerベースのMoEモデルは、「全トークンで共有される部分」と「Expertごとに分割される部分」のハイブリッド構造を持っています。
近年のHugging Face Transformersなどの主要ライブラリの動向を見ると、内部設計がモジュール型アーキテクチャへと刷新されており、この「共有部分」と「分割部分」の境界や管理がより明確になっています。
共有パラメータ：Attention層とゲートネットワーク
まず、どのトークンが来ても必ず使われる「共有パラメータ（Shared Parameters）」が存在します。
- Self-Attention層: 文脈を理解するための核心部分です。ここは通常、MoE化されず、Denseモデルと同様にすべてのトークンに対して計算が行われます。
- Layer Normalization / Embedding: 入出力の正規化や、データをベクトル化する埋め込み層も共有されます。
- Router (Gate) Network: どのExpertを使うかを決める「司令塔」となる小さなニューラルネットワークです。
これらは常に「Active（有効）」であり、計算コストのベースラインを形成します。
なお、実装面での重要な注意点として、最新のTransformers環境ではPyTorchを中心に最適化が進んでおり、これまで利用可能だったTensorFlowやFlaxのサポートは終了（廃止）しています。そのため、これからMoEモデルの共有レイヤーをカスタマイズしたり、独自モデルを学習させたりする場合は、PyTorchエコシステムへの完全な移行が前提となります。公式の移行ガイドを参照し、PyTorchベースのコードへ書き換えるアプローチが推奨されます。
分割パラメータ：Expert（FFN）層の独立性
MoEの最大の特徴が現れるのは、主にFeed-Forward Network (FFN) 層です。Transformerブロック内のFFN層が、複数の「Expert」に分割されています。
- Experts: 通常のFFNと同じ構造ですが、並列に複数（例えば8個や16個）存在します。
- Sparse Activation: トークンごとに、この中からTop-k個（例えば上位2個）だけが選ばれます。
ここで重要なのは、Attention層のパラメータは1セットしかないが、FFN層のパラメータはExpertの数だけ存在するという点です。
最新のモジュール型アーキテクチャでは、このAttentionやMLP（Expert）などのコンポーネントが独立したモジュールとして扱われるようになり、コンポーネントの差し替えや重複の削減が極めて容易になりました。
さらに、巨大なパラメータを持つExpert群を効率よくメモリに載せるため、8bitや4bitの量子化（データ圧縮技術）モデルが第一級のサポートを受けています。これにより、重みのロード処理が再設計され、限られたGPUリソースでも巨大なMoEモデルを動かすハードルが大きく下がっています。
Router（Gate）の役割とTop-k選択の仕組み
Routerは、入力トークンを見て「このトークンはExpert AとExpert Cに処理させよう」と判断します。このルーティング処理自体にも計算コストはかかりますが、モデル全体のパラメータ数から見れば誤差レベル（通常は全パラメータの0.1%未満）です。
したがって、パラメータ計算においてRouterのサイズは無視しても大勢に影響はありません。重要なのは「いくつのExpertが選ばれるか（k値）」です。
また、推論時の効率化という観点では、vLLMやSGLangといった外部ツールとの連携が強化されています。KVキャッシュ（過去の計算結果の保存）管理の標準化によって、Routerが複数のExpertへトークンを振り分ける際のメモリ効率が劇的に向上しています。さらに、transformers serveなどのデプロイ機能を利用すれば、これらの複雑なTop-kルーティング処理を内包したMoEモデルを、OpenAI互換APIとしてシンプルに提供し、他のシステムから手軽に呼び出すことも可能です。
実践：有効パラメータ数の算出ロジック
概念が整理できたところで、実際に計算してみましょう。実証データや数式をベースに考えることで、より確実な理解につながります。
計算式の導出：Shared + (Top-k × Expert_Size)
MoEモデルのパラメータ数は、以下の簡易式で表現できます。
まず、変数を定義します。
P_total: 総パラメータ数P_active: 有効パラメータ数（推論時の計算量に相当）P_shared: Attention層など、共有部分のパラメータ数P_expert: 1つのExpert（FFNブロック）あたりのパラメータ数N: Expertの総数（Mixtral 8x7Bなら8）k: トークンごとに選択されるExpertの数（Mixtral 8x7Bなら2）
【総パラメータ数の計算式】
P_total=P_shared+ (N×P_expert)
【有効パラメータ数の計算式】
P_active=P_shared+ (k×P_expert)
非常にシンプルです。しかし、この式には「8x7B」という名称の罠が潜んでいます。
Mixtral 8x7Bの実例計算（総数47B vs 有効13B）
「Mixtral 8x7B」という名前を見ると、「7Bのモデルが8個あるから、7 × 8 = 56Bだ」と思いがちです。しかし、これは間違いです。
もし56Bだとすれば、それは「Attention層も含めた7Bモデル全体」を8個コピーしていることになります。しかし実際には、Attention層は共有されており、コピーされているのはFFN層だけです。
実際のMixtral 8x7Bの構成（概算）を見てみましょう。
- 1ブロックあたりの共有パラメータ（Attention等）: 約0.9B相当
- 1ブロックあたりのExpertパラメータ（FFN）: 約5.6B相当
- ※正確には層ごとの合計ですが、概念化しています。
これを踏まえて計算すると、なぜ「47B」になるのかが見えてきます。
1. なぜ56Bではなく47Bなのか？
本来コピーされない「共有部分」を重複してカウントしてしまうと56Bになりますが、実際には共有部分は1つしかありません。Expert部分だけが8倍になっています。
P_total≈P_shared+ (8 ×P_expert)
解析によれば、Mixtral 8x7Bの総パラメータ数は約46.7Bです。56Bよりも約9B少ないのは、共有されているAttention層などの分が重複カウントされていないからです。
2. 有効パラメータ数（Active Parameters）は？
Mixtralでは、トークンごとに2つのExpertを使用します（k=2）。
P_active≈P_shared+ (2 ×P_expert)
これを計算すると、約12.9Bになります。これが「Llama 2 13B相当の速さ」と言われる数学的根拠です。
Grok-1など超巨大モデルにおける計算事例
xAIが公開したGrok-1も良い例です。
- 総パラメータ数: 314B
- 有効パラメータ数: 86B
ここでも、総量は300B超えという怪物級ですが、実行時はその1/4近い86B程度の計算コストで動いています（それでも巨大ですが）。
このように、N（総Expert数）とk（Active数）の比率が開けば開くほど、総パラメータと有効パラメータの乖離は大きくなります。この「スパース率」こそが、MoEの効率性の源泉です。
リソース設計への展開：VRAM容量と帯域幅の要件定義
計算式で数値が出せたら、次はそれを物理的なハードウェア要件に落とし込みます。理論上の「軽さ」を実際のシステム構成でどう活かすか、具体的な選定基準を見ていきましょう。
メモリ容量は「総パラメータ」で決まる理由
まずVRAM容量ですが、これは問答無用でP_total（総パラメータ数）で決まります。
いくら計算に使わないパラメータがあっても、それらはいつ呼ばれるか分かりません。Routerが「次はExpert #5を使う」と判断した瞬間に、そのパラメータがGPUメモリ（VRAM）上に存在していなければ計算できないからです。
- Mixtral 8x7B (FP16精度) の必要VRAM:
- 47B params × 2 bytes (FP16) = 94 GB
- これにKV Cache（コンテキスト長に依存）や推論用バッファを加えると、安定動作には100GB以上のVRAMが必要です。
「計算量は13Bクラスだから、24GBのGPU（GeForce RTX 4090等）1枚でいけるのでは？」という淡い期待はここで打ち砕かれます。モデルのウェイト（重み）をロードするだけでメモリが溢れてしまうからです。
推論速度は「有効パラメータ」とメモリ帯域で決まる理由
一方、トークン生成速度（Tokens/sec）はどうでしょうか。ここで初めてP_active（有効パラメータ数）が効いてきます。
GPUの計算コア（CUDA Core/Tensor Core）が行う演算量は、Activeな約13Bパラメータ分だけです。したがって、計算負荷自体はLlamaなどの同規模Denseモデルと同等であり、非常に軽量です。
しかし、ここで重大なボトルネックになるのがメモリ帯域幅（Memory Bandwidth：データ転送の太さ）です。
MoEモデルは、トークンごとに異なるExpertをメモリのあちこちから読み出す必要があります。計算量が少ない割に、広大なメモリ空間からデータを転送する量が多いため、「Memory Bound（メモリ帯域律速）」になりやすい特性があります。
- Denseモデル: パラメータ全体を順次計算するため、演算性能と転送性能のバランスが取りやすい。
- MoEモデル: 計算量は少ないが、パラメータ全体から必要な部分をランダムアクセス的に転送するため、メモリ帯域が直接的に速度を左右する。
つまり、MoE用のハードウェアを選ぶ際は、単にVRAM容量が大きいだけでなく、メモリ帯域幅が広いハイエンドGPU（NVIDIA H100/H200や、広帯域ユニファイドメモリを持つMac Studio Ultraなど）を選ばないと、モデルが持つ真の速度性能を引き出せない可能性があります。
量子化（Quantization）適用時の計算補正
現実的な運用、特にローカル環境やコスト制約のあるプロジェクトでは、GGUF形式などで用いられる4bit量子化（Q4_K_Mなど）を使うことが一般的です。この場合の要件定義も補正しましょう。
- 容量計算:
P_total× 0.5 bytes (4bit) + オーバーヘッド- Mixtral 8x7B (4bit) ≈ 47B × 0.5 + α ≈ 26〜30 GB
- このサイズ感であれば、24GB GPU×2枚の構成や、48GB以上のVRAMを持つワークステーションGPU、あるいはMac Studio（Unified Memory 64GB以上）で現実的に動作します。
量子化を行えばVRAM容量の壁は突破しやすくなりますが、前述の「メモリ帯域幅」の重要性は変わりません。むしろ、圧縮されたデータを高速に展開・転送する能力が問われるため、帯域幅の確保は依然として最重要課題となります。
結論：数値に基づいたモデル選定戦略
MoEアーキテクチャは非常に優れた技術ですが、物理法則を無視できるわけではありません。「パラメータ数」という言葉の定義を正しく理解し、導入環境に合わせて再計算するプロセスが不可欠です。
「見せかけのデカさ」を見抜くチェックリスト
モデルを選定する際は、以下のステップで評価を行ってください。特に推論エンジンの進化により、評価軸はより多角的になっています。
- カタログ値の確認: 「8x7B」のような表記から、単純な掛け算をしない。
- 構成情報の入手: Hugging Faceの
config.json等を確認し、num_local_experts（総数）とnum_experts_per_tok（k値）を特定する。 - 有効パラメータの算出: 本記事の計算式を用いて、実効的なモデルサイズを割り出す。
- ボトルネックの特定: VRAM容量が制約になるのか（総パラメータ）、推論レイテンシが重要なのか（有効パラメータ＋帯域幅）を見極める。この際、vLLMなどの最新推論ライブラリにおけるAWQ/GPTQ（Marlinカーネル最適化）の対応状況も考慮に入れると、より正確なリソース見積もりが可能です。
導入環境に最適なk値（Active Experts）の考え方
最近の研究トレンドは二極化しています。一つはExpertを細かく大量に分割して精度を上げる手法（DeepSeek-V3など）。もう一つは、Liquid AIのLFMシリーズのようにINT4精度でのQAT（Quantization-Aware Training）を採用し、低精度量子化でも高速かつ高精度に動作させるアプローチです。
これにより、従来の「パラメータ数」だけでなく、「どの量子化ビット数（4bit/8bit等）で実用的な精度が出るか」も重要な選定基準となります。パラメータ数の定義は今後も進化していくでしょう。しかし、「リソース（コスト）」と「計算量（性能）」を分けて考えるエンジニアリングの基本は変わりません。
コメント