MoEとは？
巨大LLMに必要なGPUメモリと推論速度の仕組みを解説【2026年】

ローカルLLMのモデルを探していると、「Qwen3-30B-A3B」や「Qwen3-235B-A22B」、「DeepSeek-V3（671B / 活性37B）」のように、2種類のパラメータ数が併記されたモデルを頻繁に目にするようになりました。

これらはMoE（Mixture of Experts：混合エキスパート）と呼ばれる構造を採用した言語モデルです。

MoEモデルについて調べると、「30Bの知識を持ちながら3B相当の軽さで動く」「235Bの巨大モデルなのに1トークンあたり22Bしか計算しない」といった説明を見かけます。すると、これからローカルLLM用のPCやGPUを導入しようとする人ほど、次の疑問に突き当たります。

「毎回使うパラメータが3.3Bや22Bだけなら、小さなVRAMのGPUでも動かせるのではないか？ なぜ128GBや192GBといった大容量メモリの話になるのか？」

結論から言えば、「1トークンごとに計算するパラメータ量（活性パラメータ）」が少ないことと、「メモリ上に保持しなければならないモデル全体の重み容量（総パラメータ）」が小さいことは全く別の話です。

この2つを混同したままGPUやPCを選ぶと、「軽いと聞いて買ったのにVRAM不足（Out of Memory）で起動すらしない」、あるいは逆に「大容量メモリ機に載せたのに期待したほど生成速度が出ない」というミスマッチが起きます。

※本記事は2026年10月19日時点のモデル公開仕様（Qwen3・DeepSeek-V3）および推論ランタイム公式ドキュメント（llama.cpp・vLLM）に基づく技術解説です。理論計算値と実配布ファイルサイズ・実行時メモリ要件を厳密に区別して記載しています。

この記事では、まず以下の3つの概念を混同しないことを出発点にします。

1. MoEとは何か？ Denseモデルとの違い

現在のTransformerベースの大規模言語モデル（LLM）は、アーキテクチャ上大きく「Dense（高密度）モデル」と「MoE（Mixture of Experts：スパースMoE）モデル」の2つに分類されます。

DenseとMoEの基本構造の違い

誤解を避けるために正確に整理すると、DenseモデルもMoEモデルも、トークン埋め込み（Embedding）や文脈の関係性を計算するAttention（自己注意機構）層、正規化層などを上から下へ層（Layer）ごとに順番に通過していく点は共通しています。つまり、Denseモデルであっても「モデル内の全パラメータを物理的に同じ瞬間に一斉計算している」わけではなく、各層の処理が順次実行されます。

両者の決定的な違いは、各Transformerブロックの中でパラメータ容量の大部分を占めるFFN（Feed-Forward Network：順伝播ネットワーク）層の構造にあります。

• DenseモデルのFFN層：各層に単一（共通）の大きなFFNブロックが存在し、どの入力トークンに対しても、その層にあるFFNパラメータのすべてを使って計算を行います。そのため、モデルが持つ総パラメータ数と、1トークンを生成する間に各層を通過して使われるパラメータ数がほぼ一致します。
• MoEモデルのFFN層：1つの巨大なFFNの代わりに、複数の小さなFFNである「Expert（エキスパート）」が並列に配置され、その手前に振り分け役である「Router（ルーター／ゲーティングネットワーク）」が置かれます。

Router・Top-K・共有層が動く仕組み

MoE層の内部では、トークンが流れてくるたびに次のステップが高速に実行されます。

1. 共有層（Shared Layers / Attention）の処理：入力されたトークンはまず、すべてのトークンで共通して使われるAttention層（およびDeepSeek-V3等では常時稼働する「共有Expert（Shared Expert）」）を通過します。
2. Routerによるスコア計算：次にRouter（軽量な線形層＋SoftmaxやSigmoid関数）が、そのトークンの特徴ベクトルを見て「並んでいる多数のExpertのうち、どのExpertに処理させるのが最適か」の重みスコアを計算します。
3. Top-K Expertの選択と計算：スコア上位の K 個のExpert（Top-K）だけが活性化（Activate）して演算を行い、残りの選ばれなかったExpertはそのトークンに対する演算をスキップします。たとえばQwen3のMoEモデルでは、各層にある128個のExpertのうち上位8個（Top-8）だけが選ばれます。
4. 重み付き合算：選ばれた K 個のExpertの出力がRouterのスコアに応じて合算され、次の層へと渡されます。

なぜ「使わないExpert」もメモリに載せておく必要があるのか

初心者が最も陥りやすい誤解が、「MoEは一部のパラメータしか使わないのだから、メモリ（VRAM/RAM）も活性パラメータ分だけで足りるはずだ」という考えです。

しかし、Routerが選ぶExpertは「モデルの起動時に1回だけ決まる」のではありません。生成される1トークンごと、かつ通過する各層ごとに、ミリ秒単位で全く別のExpertが動的に選択されます。

たとえば1つの文章を生成するとき、1つ目の単語（トークン）ではExpert #3と#14が呼ばれ、直後の2つ目の単語ではExpert #8と#99が呼ばれ、3つ目の単語ではコード生成に関わる別のExpert群が呼ばれる、という切り替えが毎秒何十回も連続して発生します。

もし選ばれなかったExpertをSSD（ストレージ）に置いたままにし、トークンごとに必要なExpertだけをSSDからメモリへ読み出そうとすれば、毎秒数GB程度のSSD転送速度がボトルネックとなり、推論速度は実用にならないレベルまで落ち込みます。そのため、実用的な速度でMoEモデルを動かすには、「今この瞬間のトークンでは計算しないExpert」も含めた総パラメータ全体の重みを、高速にアクセスできるメモリ（VRAM・ユニファイドメモリ・システムRAM）上に展開しておく必要があるのです。

2. 代表的なMoEモデルの総パラメータ数と活性パラメータ数

実際の主要オープンウェイトMoEモデルでは、総パラメータ数と活性パラメータ数にどれほどの差があるのでしょうか。公開されている公式モデルカード・技術仕様（2026年10月19日確認）をもとに、代表的なMoEモデルの構造を比較します。

※出典：Hugging Face『Qwen/Qwen3-30B-A3B-Base』『Qwen/Qwen3-235B-A22B』公式モデルカード、GitHub『deepseek-ai/DeepSeek-V3』公式READMEおよびconfig.json、OpenAI『Introducing gpt-oss』およびHugging Face『openai/gpt-oss-120b』（いずれも2026年10月19日確認）。

モデルの公開定義を見るときの注意点（Non-EmbeddingとMTPモジュール）

一次情報のスペック表を読む際は、開発元によって「総パラメータ数」の内訳表記に細かな違いがある点にも注意が必要です。

• Embedding（埋め込み層）を含むか否か：Qwen3シリーズでは、語彙トークンの入出力埋め込み層を含めた「Total Parameters（30.5B / 235B）」と、埋め込み層を除いた純粋なTransformerブロック部の「Non-Embedding Parameters（29.9B / 234B）」が併記されています。メモリ上には当然Embedding層も展開されるため、必要メモリ容量を考える際はTotal側の数値を基準にします。
• 補助モジュール（MTP等）を含むか否か：DeepSeek-V3では、メインモデルのパラメータ数は671Bですが、Hugging Faceで配布されているリポジトリ全体の重み総量は685Bと明記されています。これは推論高速化（投機的デコーディング等）にも使われるMulti-Token Prediction（MTP）モジュールの重み（14B）が含まれているためです。
• 共有Expert（Shared Expert）の有無：Qwen3-MoEが「128個のRouted Expertから8個を選ぶ」純粋なTop-K構造をとるのに対し、DeepSeek-V3（DeepSeekMoE）は「どのトークンでも必ず通る1個のShared Expert」＋「256個から選ばれる8個のRouted Expert」を組み合わせ、さらに先頭の3層（Layer 0〜2）はMoEではなく通常のDense FFN層（first_k_dense_replace: 3）として設計されています。

3. MoEに必要なGPUメモリ容量はどう決まるのか

「このMoEモデルを動かすには、結局何GBのVRAMやユニファイドメモリが必要なのか？」を判断するとき、総パラメータ数に単純な係数を掛けただけの概算でPCを選ぶと失敗します。実際の実行時に消費されるメモリは、次の6つの要素の合計で決まるからです。

なぜ「235Bの4bit＝約117.5GBだから128GB PCで確実に動く」と言えないのか

ここで最も重要な具体例として、Qwen3-235B-A22Bのメモリ計算を見てみましょう。

もし「4bit量子化なら1Bあたり0.5GB」という単純な理論式だけを当てはめると、235B × 0.5GB ＝ 117.5GB となります。この数字だけを見ると、「117.5GBなら、128GBのユニファイドメモリPCに収まるではないか」と思えるかもしれません。

しかし、現実は異なります。

• 実配布ファイルサイズとの差：Qwen公式がHugging Face（Qwen/Qwen3-235B-A22B-GGUF）で公開している Q4_K_M 量子化モデルの実際のファイルサイズは合計約142GBです。量子化のスケール情報や重要テンソルの精度維持により、単純な4bit理論値（117.5GB）よりも約24.5GB大きくなっています。
• 実行時メモリの加算：約142GBの重みに加えて、32K等のコンテキスト長に対するKVキャッシュ、推論ランタイムの計算バッファ、そしてOS自体が動くためのメモリ領域が必要です。
• 物理容量とGPU割り当ての壁：128GB搭載PCでは、そもそも約142GBのQ4_K_Mファイル単体すら物理メモリ容量を超過します。128GB機に収めるには、さらにビット幅を削った3bit〜2bit系の低ビット量子化（IQ3 / IQ2等）へ落とすか、ストレージへのページングを伴う極端な速度低下を受け入れる必要があります。また、192GB搭載PCであっても、GPU専用領域（VGM最大160GB等）やコンテキスト長の設定次第で上限に迫るため、無条件に余裕があるわけではありません。

4. MoEの推論速度はなぜ活性パラメータ数だけでは決まらないのか

モデルの重みがメモリに収まったとして、次に問題になるのが「どのくらいの推論速度（tokens/sec）で動くか」です。

「Qwen3-235B-A22Bの活性パラメータは22Bだから、22BのDenseモデルと全く同じ速度で動く」「Qwen3-30B-A3Bは活性3.3Bだから、3Bモデルと同じ速度が出る」と考えるのも、半分は正しく、半分は誤りです。MoEの実効推論速度は、次の5つの観点（メモリ帯域、Prefill/Decodeの差、Routerオーバーヘッド、バッチ処理、長文KVキャッシュとランタイム最適化）によって大きく変動します。

① Decode時の重み読み出しとメモリ帯域（Memory-bound）

1人のユーザーがローカルLLMと対話し、1文字ずつ返答を生成していくDecode（トークン生成）フェーズでは、GPUやCPUの演算能力（FLOPs）よりも、メモリからプロセッサへ重みデータを転送する「メモリ帯域幅（Memory Bandwidth：GB/s）」が支配的なボトルネックになります。

ここでMoEの強みが活きます。たとえば総235B・活性22BのMoEモデルでは、1トークンを生成するたびにメモリから読み出す必要がある重みは、235B全体ではなく活性化された約22B分（4bit量子化なら約11〜13GB相当）＋KVキャッシュで済みます。もしこれが235BのDenseモデルであれば、1トークンごとに約117GB以上の重みを読み出す必要があるため、単一ユーザーのDecode速度においてMoEは同規模のDenseモデルよりはるかに有利になります。

ただし裏を返せば、活性パラメータが22Bある以上、1トークンごとに十数GBの重みを読み出すメモリ帯域は必要です。メモリ帯域が1,792GB/sある専用GDDR7（RTX 5090等）や1.2TB/sのMac Studio（M5 Ultra）と、約256〜273GB/sのLPDDR5X共有メモリ機、さらに約70〜90GB/s前後の一般的なデュアルチャネルDDR5システムRAMとでは、同じ活性パラメータ数でもトークン生成速度に明確な差が生まれます。

② Prefill（入力処理）とDecode（出力生成）の負荷構造の違い

LLMの推論は、入力プロンプトを一括処理するPrefill（Prompt Processing）と、1トークンずつ出力を紡ぐDecode（Token Generation）の2段階に分かれます。

• Decode（1トークン逐次生成）：1回につき1トークン分のTop-K Expertだけを読み出すため、メモリ帯域（GB/s）が効きやすく、MoEの「活性パラメータの小ささ」が直接スピードの恩恵になります。
• Prefill（数千〜数万トークンのプロンプト一括処理）：大量の入力トークンをまとめて処理するため、プロセッサの演算性能（Compute：TFLOPS / TOPS）が強く効きます。ここでも1トークンあたりに選択されるExpert数はTop-Kのまま（1トークンあたりの演算量は活性パラメータ分）ですが、プロンプト内の多数のトークンがそれぞれ異なるExpertを選ぶため、プロンプト全体で見ると利用されるExpertの種類数が増え、読み出す重みの範囲と合計演算量（FLOPs＝1トークンあたりの活性演算×トークン数）がともに大きくなる点に注意が必要です。

③ RouterとExpert選択・不連続メモリアクセスのオーバーヘッド

同じ3.3Bの計算量であっても、「単一の連続した3.3B Denseモデル」を計算するのと、「128個に分かれたExpertの中からRouterで8個を選び、メモリ上の飛び飛びのアドレスから重みを集めて（Gather）計算し、再び統合する（Scatter）」のとでは、後者（MoE）にルーティング計算とメモリアクセスのオーバーヘッドが加わります。特に層数が多いモデル（Qwen3-235B-A22Bは94層）では、1トークン生成する間に94回のRouter判定と分岐が発生します。

④ バッチサイズと同時リクエスト数（単一ユーザー vs 多人数サービング）

個人利用（Batch Size = 1）と、複数エージェントの並列実行やチーム共有サービング（Batch Size > 1）では、MoEの負荷構造が変化します。ただし「バッチサイズが増えると全Expertが活性化して総パラメータ分の演算が発生する」と短絡的に捉えるのは不正確であり、次の5つの概念を区別して理解する必要があります。

• 1トークンで選択されるExpert数：バッチサイズが増えても、各トークンが通過するExpert数は常にTop-K（例：128個中8個）で変わりません。
• 1バッチ全体で利用されるExpertの種類数：バッチ内の複数トークンが別々のExpertを選ぶため、バッチサイズが大きくなるほど、そのステップで1回以上呼び出されるユニークなExpertの「種類数」が増えます（実際にどれだけ分散するかはバッチサイズとRouterの選択分布に依存します）。
• 重みのメモリアクセス量：バッチ全体で選ばれるExpertの種類数が増えるため、1ステップあたりにメモリから読み出す重み総量はBatch Size = 1のときより増加します。一方で、同じExpertを選んだ複数トークン間では1回読み出した重みを共有して再利用できるため、トークンあたりのメモリアクセス効率はバッチサイズと選択の重なり具合によって変化します。
• 総演算量（FLOPs）：1トークンあたりの演算量はあくまで活性パラメータ分であり、バッチ全体の総演算量は「1トークンあたりの活性パラメータ演算 × バッチ内トークン数」に比例します（1トークンあたりに総パラメータ分の演算が発生するわけではありません）。
• バッチ処理の実効性能：最終的なスループットとレイテンシは、バッチサイズ、Routerの選択分布の偏り、および推論ランタイム（vLLM / SGLang / llama.cpp等）のGrouped GEMM・融合カーネル最適化によって決まります。

⑤ 長文コンテキストとKVキャッシュ・バックエンド・ランタイム最適化

さらに、コンテキスト長が数万トークンに伸びると、毎トークン生成時にExpertの重みだけでなく肥大化したKVキャッシュ全体もメモリから読み出す必要があります。Qwen3のようにGQA（Grouped-Query Attention：KVヘッドを4個に削減）を採用したり、DeepSeek-V3のようにMLA（Multi-head Latent Attention：潜在ベクトルへの低ランク圧縮）を採用したりしているモデルはKVキャッシュの膨張を抑えていますが、それでも長文処理ではメモリ帯域とAttention演算最適化（FlashAttention等）の差が顕著に出ます。

加えて、同じハードウェアでもバックエンド（CUDA / ROCm / Metal / Vulkan / CPU AVX-512・AMX）と推論ランタイム（llama.cpp、vLLM、SGLang、MLX等）がMoE専用の融合カーネル（Fused MoE Kernel）や量子化形式にどこまで最適化されているかによって、実効速度は大きく変わります。

5. MoEに適した計算環境をどう選ぶか（4つの構成パターン）

ここまでの「重み保持容量」と「推論速度の仕組み」を踏まえると、MoEモデルを動かすための計算環境は大きく4つのパターン（A〜D）に整理できます。

パターンA：RTX 5090など32GB専用VRAMで中規模MoEを高速に回す

Qwen3-30B-A3B（総30.5B・活性3.3B）のように、4bit〜5bit量子化時のモデル重みが約16〜20GB前後に収まるMoEモデルを扱う場合、32GBのGDDR7専用VRAMを持つGeForce RTX 5090は極めて強力な選択肢になります。

32GBのVRAM内に全48層のExpert重みと長文のKVキャッシュを丸ごと収容できれば、PCIeバスを介したシステムRAMへのアクセスが一切発生しません。1,792GB/sという広いメモリ帯域と活性3.3Bの軽さが組み合わさることで、30Bクラスの知識量を持つモデルでありながら、非常に高速なレスポンスでコーディング支援やエージェント処理を行えます（16GB〜96GBまでのGPU別の選び方は「ローカルLLM向けGPUおすすめ比較｜16GB・24GB・32GB・96GBで選ぶ」も参照してください）。

パターンB：RTX PRO 5000 / 5500 / 6000で「単一GPU専用VRAM」の上限を引き上げる

「CUDA環境と高速なGDDR7専用VRAMを維持したまま、32GBでは収まらないモデルや長大コンテキスト、複数リクエストの並列サービングを行いたい」という業務・研究用途では、NVIDIA Blackwell世代のプロフェッショナルGPU（RTX PROシリーズ）が選択肢に入ります。ここで重要なのは、型番によって実際のVRAM容量と性格が異なることです。

• RTX PRO 5000 Blackwell（48GB / 72GB GDDR7 ECC）：300Wの省電力設計で、32GBでは不足する中規模MoEの高精度量子化（Q8/FP8）＋長大コンテキストや、複数モデルの同時常駐に対応するステップアップ構成です（詳細は「RTX PRO 5000とRTX 5090はどっちを選ぶ？」を参照）。
• RTX PRO 5500 Blackwell（84GB GDDR7 ECC）：最大600W級・MIG（2×42GB分割）に対応する84GBモデルです（※2026年10月時点でNVIDIA公式は「近日リリース予定」と案内しており、国内完成品WSの価格・発売日は各社発表の確認が必要です）。
• RTX PRO 6000 Blackwell（96GB GDDR7 ECC）：単一GPUで96GBの高速ECC VRAMを提供し、OpenAIが「単一80GB GPUで実行可能」と案内するgpt-oss-120b（MXFP4量子化）クラスや、70B級モデルをCPUオフロードなしで高速運用できるフラッグシップです（詳細は「RTX 5090とRTX PRO 6000を比較」を参照）。

パターンC：Ryzen AI Max / RTX Spark / DGX Spark / Mac Studioの大容量共有メモリ

単一GPUのVRAM上限（32GB〜96GB）を超える大型MoEモデルの重みを、1台のマシンでメモリ内に保持したい場合に注目されるのが、CPUとGPUが巨大なメモリプールを共有するユニファイドメモリ／共有メモリ環境です。

ただし、「共有メモリが128GBや192GBある」という数字だけで一括りにしてはいけません。

• 128GB共有メモリの現実（Ryzen AI Max+ 395 / RTX Spark / DGX Spark / Mac Studio M5 Max 128GB）：70B級（Q4で約40〜43GB）や120B級の4bitモデル（gpt-oss-120b等）を保持するには有力ですが、先述の通りQwen3-235B-A22BのQ4_K_M（約142GB）は128GBの物理容量自体を超えます。したがって「128GB機なら235Bの4bitモデルが必ず収まる」と断定することはできません。
• 192GB共有メモリの現実（Ryzen AI Max+ PRO 495搭載機など）：192GBあれば約142GBの重みファイルを物理メモリに収める余地が生まれますが、GPU側への割り当て上限（例：最大160GB設定）、KVキャッシュ、ランタイム作業領域によって実行条件が変わるため、コンテキスト長や設定を含めた検証が必要です（128GBと192GBの詳細な境界は「128GBと192GB Unified Memory、動かせるLLMはどう変わる？」で解説しています）。
• 671B級（DeepSeek-V3等）の現実：総671Bのモデルは4bitの単純理論値だけでも約335GB以上となるため、128GBや192GBのPCで無条件に動かせると考えるのは誤りです。単一筐体で4bitクラスの重みを保持しようとすればMac Studio（M5 Ultra 最大512GB構成：Apple公式案内で2026年10月後半提供予定）のような超大容量環境や、複数ノード分散構成の領域になります。
• プラットフォームごとの差：同じ128GBクラスでも、Windows 11 on ArmのRTX Spark、Ubuntuベース（Linux Arm64）のDGX Spark、macOS（Metal / MLX）のMac Studio、x86_64（ROCm / Vulkan）のRyzen AI Maxでは、メモリ帯域幅（約256GB/s〜1.2TB/s）も対応ソフトウェアも大きく異なります（6環境の総合比較は「あなたの仕事ならRTX 5090・RTX PROか、RTX Spark・DGX Spark・Mac Studio・Ryzen AI Maxか」を参照）。

パターンD：GPU専用VRAM＋システムRAM（llama.cpp --cpu-moe による役割分担）

「手元にはRTX 5090（32GB VRAM）やRTX 5080（16GB VRAM）があり、メインメモリ（システムRAM）は64GB〜128GB以上積んでいる」というデスクトップPCで、VRAM容量を超えるMoEモデルを動かす非常に実践的な手法が、共有層・AttentionとExpert重みの配置を分けるハイブリッド実行です。

現行の llama.cpp 公式CLI仕様（2026年10月19日確認）には、従来の単純なレイヤー単位オフロード（-ngl / --n-gpu-layers）に加えて、MoE構造に特化した以下のオプションが用意されています。

なぜこの方式がMoEで有効なのでしょうか。理由はシンプルです。MoEモデルでは、メモリ容量の80〜90%近くを「毎トークンでは一部（Top-K）しか使われないExpert FFN層」が占めている一方、毎トークン必ずフル稼働して計算が重くなる「Attention層とKVキャッシュ」の容量は比較的小さいからです。

したがって、-ngl all --cpu-moe（またはVRAM残量に応じた --n-cpu-moe N）を使うと、重たいAttention計算とKVキャッシュ参照を高速なGPU（CUDA）で処理しつつ、VRAMに入りきらない巨大なExpert群だけをシステムRAM＋CPUで処理する分業が成立します。

ただし、このハイブリッド方式にも明確な物理的制約があります。CPU側に置いたExpertを計算・転送する際、システムRAMのメモリ帯域幅（一般的なデュアルチャネルDDR5では実効70〜90GB/s前後）とPCIeバスの同期レイテンシがボトルネックになるため、全層をGPUのGDDR7 VRAM内に収めた場合と比べればトークン生成速度は低下します（VRAMとシステムRAMの帯域差・オフロードの仕組みは「RAM 128GBでVRAM不足は補える？ メインメモリとGPUメモリの違い・オフロードの限界」で詳しく解説しています）。

6. MoEのために大容量GPUを買うべきか？ 用途別の判断基準

ここまで見てきた通り、MoEモデルを扱うからといって、全員が同じPCや大容量GPUを買う必要はありません。自分の用途にどの計算資源が必要かは、次の6つのチェック項目で判断できます。

7. まとめ：MoEは小容量GPUで巨大モデルを動かす魔法ではない

※VRAMとシステムRAMの帯域差やPCIeバス経由のCPUオフロード限界を詳しく確認したい場合は「RAM 128GBでVRAM不足は補える？ メインメモリとGPUメモリの違い・オフロードの限界」もあわせて参照してください。

よくある質問