--- title: 'モデルアーキテクチャ: DenseとMoE' url: https://doc.liz6.com/ja/ai/01-models-and-context/03-model-architecture-dense-vs-moe locale: ja area: ai tags: - ai - models-and-context date: 2026-06-30 modified: 2026-07-19 description: 現代のLLMのほとんどはTransformerデコーダーです。MoEは過去数年で最も重要なアーキテクチャのトレードオフとなりました——モデルは「パラメータ数は大きいものの、トークンごとに使用するのは一部のみ」とし、容量とトークンあたりの演算コストを分離します。 --- # モデルアーキテクチャ: DenseとMoE > 現代のLLMのほとんどは **Transformerデコーダー** です。MoEは過去数年で最も重要なアーキテクチャのトレードオフとなりました——モデルは「パラメータ数は大きいものの、トークンごとに使用するのは一部のみ」とし、容量とトークンあたりの演算コストを分離します。 ## 概要現代のLLMのほとんどは **Transformerデコーダー** です。違いは主に **規模、そしてその規模をどう使うか** にあります。パラメータ数が多いほど一般的に性能は向上しますが、トークンあたりの推論コスト、VRAM使用量、レイテンシも比例して増加します。**MoE(Mixture of Experts: 専門家の混合)** は過去数年で最も重要なアーキテクチャのトレードオフ——モデルが「**パラメータ数は大きいものの、トークンごとに使用するのは一部のみ**」とし、「容量」と「トークンあたりの演算コスト」を分離します。DenseとMoEのメカニズムを理解することは、以下の3つの実務に直結します: ローカルデプロイの選定とVRAM予算の確保（[ローカルLLMデプロイ](/homelab/local-llm.md)参照）、推論スループット、そしてQwen-AgentWorldのような最先端モデルカードの読み解き方です。まず境界線を明確にします:**クローズドソースモデル（Claude、GPTなど）はアーキテクチャを公開していません**——MoEかどうか、層数、パラメータ数は、公式に明かされていません。本稿では**一般的なメカニズムと、オープンソースモデルで検証可能な事実**を扱います。クローズドソースモデルについては、推測された内部構造ではなく、**Models API** で報告された能力に依存します。以下、Claudeに関する記述は能力の照会のみを行い、構造については言及しません。 ## Transformerデコーダーの動作原理 ```mermaid flowchart TD E["トークン埋め込み + 位置エンコーディング"] --> R["残差流 residual stream"] R --> L1["レイヤー 1"] subgraph L1["各レイヤー (×N)"] direction TB A["自己注意機構
(Q・K → 重み, Vに重み付け)"] --> F["FFN
(次元拡張→活性化→次元圧縮)"] end L1 --> LN["... レイヤー N"] LN --> O["出力ロジット
(次のトークン分布)"] ``` ポイント（デコーダー専用、つまりGPT系統）: - **残差流(residual stream)**: 各レイヤーの出力 = 入力 + そのレイヤーの増分。情報がこの「メインパス」を流れ、各レイヤーが読み書きを行います。 - **自己注意機構(self-attention)**: 各トークンは **Q/K/V** の3つのベクトルに射影されます。Q・Kを用いて「どこに注目すべきか」の重みを計算し、Vに重み付けして合計します。**マルチヘッド**は、異なる関係性を捉えるために複数のQ/K/Vペアを並列に実行します。**因果マスク(causal mask)** は、1つのトークンがそれ以前のトークンのみを見られるようにし、自己回帰生成を可能にします。注意機構は ~O(n²) のコストと **KVキャッシュ** の源となります（[コンテキストエンジニアリング](/ai/01-models-and-context/01-context-engineering.md)参照）。 - **FFN(順伝播ネットワーク)**: 各位置に対して独立して「次元拡張→非線形変換→次元圧縮」（典型的に4倍）を行います。**モデルの大部分のパラメータはFFNに含まれます**——これがMoEが介入する箇所です。 ## Dense vs MoE: メカニズム - **Dense(稠密)**: 各トークンは**全**FFNパラメータを通過します。70BのDenseモデルでは、各トークンが70Bのパラメータを使用します。 - **MoE**: 各レイヤーのFFNを **N個のエキスパート(expert) + 1つのルーター(router/gating)** に置き換えます。ルーターは各トークンに対して「どのエキスパートを使うべきか」の分布を計算し、**top-k** 個のエキスパートのみをアクティブにし、他は計算に参加しません。ルーターのメカニズム（現代のMoEを例とする）: 各トークンに対して、ゲイティングネットワークがN個のエキスパートに対するスコアを出力し、softmax後に **top-k** を選択し、ゲイト重みで選ばれたエキスパートの出力を加重結合します。2つの重要なエンジニアリングポイント: - **ロードバランシング(負荷分散)**: 制約を加えない場合、ルーターは少数のエキスパートを好む傾向があり（「勝者総取り」）、他のエキスパートは訓練不足になります。訓練時には**負荷分散補助損失**を加え、均等なルーティングを促します。 - **共有エキスパート(shared expert)**: 一部の設計（DeepSeekMoE、Qwen）では、汎用能力を担う**常にアクティブな**共有エキスパートを1つ残し、他のルーティングエキスパートは専門化を担当します——これが「8 routed + 1 shared」といった表現の由来です。命名における `35B-A3B` はこの意味です:**35Bの総パラメータ、トークンごとに約3Bのみをアクティブ化**。 ## なぜMoEなのか: 容量/演算コストの分離（とその代償） | | Dense | MoE | |---|---|---| | トークンあたりの計算 | 全パラメータ | アクティブなtop-kエキスパートのみ → **アクティブパラメータで決定** | | 推論速度/スループット | 総パラメータに比例して遅くなる | **速い** (演算コスト ∝ アクティブパラメータ) | | VRAM | 総パラメータを収める必要がある | **全エキスパートを収める必要がある** (いずれも選択される可能性があるため) | | スケーリング方法 | パラメータ追加 = 演算コスト増加 | **エキスパート追加 ≈ 容量増加だが、トークンあたりの演算コストはほぼ増加しない** | | 代償 | シンプル | ルーティングの偏り、訓練の複雑さ、VRAMの逼迫、バッチ内でのエキスパートのヒット分散 | 一言で言えば:**MoEは「全エキスパートをVRAMに常駐させる」ことで「トークンごとに一部のみを計算する」を実現する**——大きくて節約（演算コスト/スループープ）、ただし**VRAMは節約しない**。 ### VRAMと演算コストの計算（ローカル視点）ローカルに常駐しているQwen 35B-A3Bを例とする（[ローカルLLMデプロイ](/homelab/local-llm.md)）: - **VRAM**: 35Bの全エキスパートが常駐する必要がある。FP16では約70GB必要で、24GBのカードには収まらない → 量子化が必要: Q3_K_XLで重みを約17GBに圧縮、64kのQ8_0 KVキャッシュで約2.85GB、さらに約1.7GBのランタイム計算バッファを加えて、合計約21.5GB、デスクトップ用に約3GBの余裕を残す。**VRAMは「総パラメータ + KVキャッシュ」で決まり、MoEはこの点で何も節約しない。** - **演算コスト**: トークンごとに約3Bのみをアクティブ化するため、スループットは3BのDenseモデルに近くなる——MTPドラフトヘッダーを併用して実測すると約111 t/s。**速度は「アクティブパラメータ」で決まり、これがMoEの恩恵である。** これがローカルでMoEを選ぶ理由: 使えるVRAMの中に高容量モデルを詰め込み、かつ高速に動作させる——ただし、量子化によって「総パラメータ」をカードに収めることが前提。**ただし代償として、トークンあたりの推論深度はアクティブパラメータによって決まる**（次節参照）、エージェント/ツール呼び出しなど多段階の推論チェーンが必要なタスクでは、選定時にこの代償を考慮に入れること。 ### MoEの隠れた代償: トークンあたりの推論深度上記ではVRAMとスループットのみを計算したが、第三の次元がある:**トークンあたりの推論深度は、総パラメータではなくアクティブパラメータによって決まる。** Transformerの構造を思い返そう: 注意機構層は完全——モデルは入力のどのトークンに注目すべきかを知っている。しかしFFNは注目された情報を加工・推論する役割を担い、MoEではトークンごとにFFNパラメータのごく一部のみがアクティブ化される。**総パラメータ35B / アクティブ3Bのモデルでは、各推論ステップの「思考の深さ」は約3BのDenseモデルに相当する。** つまり:**注意機構は「どこを見るか」を決定し、アクティブ化されたFFNは「何を見たか、次に何をするか」を決定する**——MoEの目は見えていないが、各ステップで働く脳細胞はアクティブパラメータの数だけしかない。これは単一ステップのタスク（分類、要約、簡単な質問応答）では大きな影響はない——3Bの加工能力で十分である。しかし**多段階の直列推論**——典型的にはエージェントのツール呼び出しチェーン: 各ステップでFFNの推論予算を消費している。アクティブパラメータが3Bの場合、2ステップ目で既に1ステップ目の意図を「忘れ」、結果として `` テキストを出力するが、ツール呼び出しトークンを生成すべきところで注意が散漫になり、テキストとして続けて生成してしまう——考えてはいるが、行動していない。 **経験的な閾値**: 安定した単一ステップのツール呼び出しには約7–10Bのアクティブパラメータが必要、安定した多段階のエージェントループには約20B+のアクティブパラメータが必要。これがDeepSeek V3(MoE、総パラメータ671Bだがアクティブ37B)のツール呼び出しが安定している理由——アクティブパラメータが十分に大きいからである。24GBのVRAM制約下では、エージェントタスクにはDenseモデル（Qwen 2.5 14B/32B、Qwen 3 32Bなど）を優先し、それらのアクティブパラメータは総パラメータと等しく、同規模の低アクティブMoEよりも多段階推論チェーンがはるかに信頼性が高い。 ## 実例: ローカルから最先端へ - **ローカル常駐**: Qwen 35B-A3B（総35B / 活3B）—— 標準的なMoE、上記計算参照。 - **最先端のバリエーション**: [Qwen-AgentWorld-35B-A3B](https://huggingface.co/Qwen/Qwen-AgentWorld-35B-A3B) も同様に35B-A3Bだが、より積極的:**256個のエキスパート、トークンごとに8 routed + 1 sharedをアクティブ化**；さらに**ハイブリッドアーキテクチャ**——40層のうち大部分で **Gated DeltaNet**（**線形注意機構**の一種で、長文脈注意の ~O(n²) をほぼ線形にまで低下させ、長文脈のコストを削減）、各反復ブロックの最後の層のみでGated Attention（40層中10層のみ）を使用し、**256Kコンテキスト**をサポートする。これは「MoEによる容量の分離」と「線形注意機構による長文脈」の2つのラインを重ね合わせ、world-modelの目標（エージェント環境のシミュレーションには長文脈 + 強力な容量が必要、[エージェントループとツール使用](/ai/02-Agent/01-the-agent-loop-and-tool-use.md)の最先端セクション参照）に貢献している。 > これらの数字は検証可能なオープンソースのモデルカードに基づく。Claudeには適用しないこと——公式にはMoEかどうか、パラメータ規模、注意機構のバリエーションは公開されていない。 ## 選定: 能力を見よ、構造を推測するなアプリケーション開発者にとって、本当に問うべきは「それがMoEかどうか」ではなく、**能力とコスト**である。クローズドソースモデルはModels APIでリアルタイムに照会し、推測するな: ```python m = client.models.retrieve("claude-opus-4-8") m.max_input_tokens # コンテキストウィンドウ m.max_tokens # 最大出力 m.capabilities # image_input / thinking / effort / structured_outputs ... # client.models.list() で能力別にフィルタリングも可能 ``` オープンソース/ローカルモデルの場合は、モデルカードの**総パラメータ / アクティブパラメータ / 層数 / コンテキスト / 注意機構の種類**を読み、VRAM予算（[ローカルLLMデプロイ](/homelab/local-llm.md) の量子化とVRAMの駆け引き）と組み合わせて選定する。 ## ベストプラクティス - **クローズドソースモデルは能力を照会し、構造を推測するな。** Models APIで `max_input_tokens`/`max_tokens`/`capabilities` をリアルタイムに取得し、MoEかどうか、パラメータ数がいくつかなどを推測するな。 - **MoEのVRAMは「総パラメータ + KVキャッシュ」で見積もれ。** アクティブパラメータが小さいからといってVRAMが小さいわけではない——全エキスパートが常駐する必要があり、量子化で総パラメータをカードに収める。 - **MoEのスループットはアクティブパラメータで見よ、総パラメータではない。** 35B-A3Bは3Bのように動作する、これがMoEの恩恵である。 - **エージェントへの適応性をアクティブパラメータで評価し、総パラメータではない。** 安定した単一ステップのツール呼び出しには約7–10Bのアクティブ、安定した多段階エージェントには約20B+必要；24GB下でエージェントタスクを行う場合はDenseまたは高アクティブMoEを優先。 - **オープンソース選定はモデルカードの4点セットを読め。** 総パラメータ / アクティブパラメータ / 層数 / 注意機構の種類、VRAM予算（[ローカルデプロイ](/homelab/local-llm.md)）と組み合わせて決定。 ## トレードオフと失敗パターン - **「アクティブパラメータが小さい」を「VRAMが小さい」と誤解する**: MoEのVRAMは総パラメータで決まり、カードが溢れる → 総パラメータ + KVキャッシュでVRAMを見積もり、量子化で圧縮。 - **Denseの直感でMoEのスループットを見積もる**: MoEが速いのはアクティブパラメータが小さいからであり、「小さい」からではない → アクティブパラメータを見よ。 - **バッチ内でのエキスパートの分散**: 並列リクエストが異なるエキスパートにルーティングされ、実際の演算コスト利用率が理論より劣る可能性がある → サーバーサイドのスケジューリング/エキスパート並列化のエンジニアリング課題。 - **MoEでエージェントのツール呼び出しを行い、チェーンが頻繁に断絶する**: アクティブパラメータが小さすぎる（例: 3B）、多段階推論中に意図が漂移し、thinkテキストを出力するが実際のtool callトークンを生成しない → エージェントシーンではDenseまたは高アクティブMoEを選択し、総パラメータではなくアクティブパラメータで評価。 - **クローズドソースアーキテクチャを推測する**: 根拠なし → Models APIの能力フィールドのみを使用。 ## 参考文献 - **論文**: 「Attention Is All You Need」(Vaswani 2017)、「Switch Transformers」(Fedus 2021)、「DeepSeekMoE」(2024、共有エキスパート)、「GShard」(負荷分散) - **モデルカード**: [Qwen-AgentWorld-35B-A3B](https://huggingface.co/Qwen/Qwen-AgentWorld-35B-A3B) - **クローズドソース能力照会**: Anthropic Models API (platform.claude.com) *Keywords: Transformer, decoder-only, residual stream, self-attention, QKV, multi-head, causal mask, FFN, KV cache, dense, MoE, Mixture of Experts, router, gating, top-k, shared expert, load balancing, 総パラメータ, アクティブパラメータ, active parameters, 35B-A3B, スループット, Gated DeltaNet, linear attention, Qwen-AgentWorld, Models API, 量子化, クローズドソースアーキテクチャ*