20 分で読了
このページの目次

モデルアーキテクチャ: DenseとMoE

現代のLLMのほとんどは Transformerデコーダー です。MoEは過去数年で最も重要なアーキテクチャのトレードオフとなりました——モデルは「パラメータ数は大きいものの、トークンごとに使用するのは一部のみ」とし、容量とトークンあたりの演算コストを分離します。

概要

現代のLLMのほとんどは Transformerデコーダー です。違いは主に 規模、そしてその規模をどう使うか にあります。パラメータ数が多いほど一般的に性能は向上しますが、トークンあたりの推論コスト、VRAM使用量、レイテンシも比例して増加します。MoE(Mixture of Experts: 専門家の混合) は過去数年で最も重要なアーキテクチャのトレードオフ——モデルが「⁠パラメータ数は大きいものの、トークンごとに使用するのは一部のみ⁠」とし、「容量」と「トークンあたりの演算コスト」を分離します。DenseとMoEのメカニズムを理解することは、以下の3つの実務に直結します: ローカルデプロイの選定とVRAM予算の確保（ローカルLLMデプロイ参照）、推論スループット、そしてQwen-AgentWorldのような最先端モデルカードの読み解き方です。

まず境界線を明確にします:⁠クローズドソースモデル（Claude、GPTなど）はアーキテクチャを公開していません⁠——MoEかどうか、層数、パラメータ数は、公式に明かされていません。本稿では一般的なメカニズムと、オープンソースモデルで検証可能な事実を扱います。クローズドソースモデルについては、推測された内部構造ではなく、Models API で報告された能力に依存します。以下、Claudeに関する記述は能力の照会のみを行い、構造については言及しません。

Transformerデコーダーの動作原理

flowchart TD
    E["トークン埋め込み + 位置エンコーディング"] --> R["残差流 residual stream"]
    R --> L1["レイヤー 1"]
    subgraph L1["各レイヤー (×N)"]
        direction TB
        A["自己注意機構<br/>(Q・K → 重み, Vに重み付け)"] --> F["FFN<br/>(次元拡張→活性化→次元圧縮)"]
    end
    L1 --> LN["... レイヤー N"]
    LN --> O["出力ロジット<br/>(次のトークン分布)"]

ポイント（デコーダー専用、つまりGPT系統）:

  • 残差流(residual stream): 各レイヤーの出力 = 入力 + そのレイヤーの増分。情報がこの「メインパス」を流れ、各レイヤーが読み書きを行います。
  • 自己注意機構(self-attention): 各トークンは Q/K/V の3つのベクトルに射影されます。Q・Kを用いて「どこに注目すべきか」の重みを計算し、Vに重み付けして合計します。⁠マルチヘッドは、異なる関係性を捉えるために複数のQ/K/Vペアを並列に実行します。⁠因果マスク(causal mask) は、1つのトークンがそれ以前のトークンのみを見られるようにし、自己回帰生成を可能にします。注意機構は ~O(n²) のコストと KVキャッシュ の源となります（コンテキストエンジニアリング参照）。
  • FFN(順伝播ネットワーク): 各位置に対して独立して「次元拡張→非線形変換→次元圧縮」（典型的に4倍）を行います。⁠モデルの大部分のパラメータはFFNに含まれます⁠——これがMoEが介入する箇所です。

Dense vs MoE: メカニズム

  • Dense(稠密): 各トークンは全FFNパラメータを通過します。70BのDenseモデルでは、各トークンが70Bのパラメータを使用します。
  • MoE: 各レイヤーのFFNを N個のエキスパート(expert) + 1つのルーター(router/gating) に置き換えます。ルーターは各トークンに対して「どのエキスパートを使うべきか」の分布を計算し、top-k 個のエキスパートのみをアクティブにし、他は計算に参加しません。
Dense vs MoE: トークンはFFNをどのように通過するか Dense 全パラメータが参加 トークン FFN全体 ・ 全パラメータ 出力 総パラメータ = アクティブパラメータ MoE top-kのみが参加 トークン ルーター softmaxスコアリング → top-k エキスパート 7 エキスパート 23 加重合計 出力 残りの N−k 個のエキスパートはこのステップでは参加しない —— 総パラメータ ≫ アクティブパラメータ Denseはトークンごとに全パラメータを使用します。MoEはトークンごとにルーターが選んだtop-kエキスパートのみが参加し、他のエキスパートは計算しません—— これが「総パラメータ = 容量」と「アクティブパラメータ = トークンあたりの演算コスト」が分離される理由です。

ルーターのメカニズム（現代のMoEを例とする）: 各トークンに対して、ゲイティングネットワークがN個のエキスパートに対するスコアを出力し、softmax後に top-k を選択し、ゲイト重みで選ばれたエキスパートの出力を加重結合します。2つの重要なエンジニアリングポイント:

  • ロードバランシング(負荷分散): 制約を加えない場合、ルーターは少数のエキスパートを好む傾向があり（「勝者総取り」）、他のエキスパートは訓練不足になります。訓練時には負荷分散補助損失を加え、均等なルーティングを促します。
  • 共有エキスパート(shared expert): 一部の設計（DeepSeekMoE、Qwen）では、汎用能力を担う常にアクティブな共有エキスパートを1つ残し、他のルーティングエキスパートは専門化を担当します——これが「8 routed + 1 shared」といった表現の由来です。

命名における 35B-A3B はこの意味です:35Bの総パラメータ、トークンごとに約3Bのみをアクティブ化⁠。

なぜMoEなのか: 容量/演算コストの分離（とその代償）

DenseMoE
トークンあたりの計算全パラメータアクティブなtop-kエキスパートのみ → アクティブパラメータで決定
推論速度/スループット総パラメータに比例して遅くなる速い (演算コスト ∝ アクティブパラメータ)
VRAM総パラメータを収める必要がある全エキスパートを収める必要がある (いずれも選択される可能性があるため)
スケーリング方法パラメータ追加 = 演算コスト増加エキスパート追加 ≈ 容量増加だが、トークンあたりの演算コストはほぼ増加しない
代償シンプルルーティングの偏り、訓練の複雑さ、VRAMの逼迫、バッチ内でのエキスパートのヒット分散

一言で言えば:MoEは「全エキスパートをVRAMに常駐させる」ことで「トークンごとに一部のみを計算する」を実現する⁠——大きくて節約（演算コスト/スループープ）、ただしVRAMは節約しない⁠。

VRAMと演算コストの計算（ローカル視点）

ローカルに常駐しているQwen 35B-A3Bを例とする（ローカルLLMデプロイ）:

  • 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はtop-kエキスパートのみをアクティブ化

注意機構層は完全——モデルは入力のどのトークンに注目すべきかを知っている。しかしFFNは注目された情報を加工・推論する役割を担い、MoEではトークンごとにFFNパラメータのごく一部のみがアクティブ化される。⁠総パラメータ35B / アクティブ3Bのモデルでは、各推論ステップの「思考の深さ」は約3BのDenseモデルに相当する。 つまり:⁠注意機構は「どこを見るか」を決定し、アクティブ化されたFFNは「何を見たか、次に何をするか」を決定する⁠——MoEの目は見えていないが、各ステップで働く脳細胞はアクティブパラメータの数だけしかない。

これは単一ステップのタスク（分類、要約、簡単な質問応答）では大きな影響はない——3Bの加工能力で十分である。しかし多段階の直列推論⁠——典型的にはエージェントのツール呼び出しチェーン:

タスクを理解 ツールを選択 パラメータを記入 結果を読む 次のステップを決定 各ステップでFFNの推論予算を消費する —— タスク完了またはチェーン断絶までループ

各ステップでFFNの推論予算を消費している。アクティブパラメータが3Bの場合、2ステップ目で既に1ステップ目の意図を「忘れ」、結果として <think> テキストを出力するが、ツール呼び出しトークンを生成すべきところで注意が散漫になり、テキストとして続けて生成してしまう——考えてはいるが、行動していない。

経験的な閾値⁠: 安定した単一ステップのツール呼び出しには約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 も同様に35B-A3Bだが、より積極的:256個のエキスパート、トークンごとに8 routed + 1 sharedをアクティブ化⁠；さらにハイブリッドアーキテクチャ⁠——40層のうち大部分で Gated DeltaNet（⁠線形注意機構の一種で、長文脈注意の ~O(n²) をほぼ線形にまで低下させ、長文脈のコストを削減）、各反復ブロックの最後の層のみでGated Attention（40層中10層のみ）を使用し、256Kコンテキストをサポートする。これは「MoEによる容量の分離」と「線形注意機構による長文脈」の2つのラインを重ね合わせ、world-modelの目標（エージェント環境のシミュレーションには長文脈 + 強力な容量が必要、エージェントループとツール使用の最先端セクション参照）に貢献している。

これらの数字は検証可能なオープンソースのモデルカードに基づく。Claudeには適用しないこと——公式にはMoEかどうか、パラメータ規模、注意機構のバリエーションは公開されていない。

選定: 能力を見よ、構造を推測するな

アプリケーション開発者にとって、本当に問うべきは「それがMoEかどうか」ではなく、⁠能力とコストである。クローズドソースモデルはModels APIでリアルタイムに照会し、推測するな:

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デプロイ の量子化と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予算（ローカルデプロイ）と組み合わせて決定。

トレードオフと失敗パターン

  • 「アクティブパラメータが小さい」を「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
  • クローズドソース能力照会⁠: 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, 量子化, クローズドソースアーキテクチャ

関連ページ

© 2026 liz's doc