20 分で読了 #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 #throughput #Gated DeltaNet #linear attention #Qwen-AgentWorld #Models API #quantization #closed-source architecture #ai #モデルとコンテキスト
このページの目次

モデルアーキテクチャ: 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["Layer 1"]
    subgraph L1["各層 (×N)"]
        direction TB
        A["self-attention<br/>(Q·K → 重み, Vに重み付け)"] --> F["FFN<br/>(次元拡張→活性化→次元圧縮)"]
    end
    L1 --> LN["... Layer N"]
    LN --> O["出力ロジット<br/>(次のトークン分布)"]

ポイント（decoder-only、つまりGPT系統）:

  • 残差流（residual stream）: 各層の出力 = 入力 + その層での増分。情報がこの「メインストリーム」に沿って流れ、各層で読み書きを行います。
  • self-attention: 各トークンは Q/K/V の3つのベクトルに射影されます。Q·Kを用いて「どこに注目すべきか」の重みを計算し、Vに重み付けして合計します。multi-head は、異なる関係性を捉えるために複数のQ/K/Vペアを並列で実行します。⁠因果マスク（causal mask） は、1つのトークンがそれ以前のトークンのみを見られるように保証します——これにより自己回帰的生成が可能になります。注意機構は ~O(n²) のコストと KV cache の源です（コンテキストエンジニアリング参照）。
  • 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つの重要なエンジニアリングポイント:

  • load balancing（負荷分散）: 制約を加えない場合、ルーターは少数のエキスパートを好む傾向があり（「勝者総取り」）、他のエキスパートは訓練不足になります。訓練時には 負荷分散補助損失 を加え、均等なルーティングを促します。
  • 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 cacheで約2.85GB、さらに約1.7GBのランタイム計算バッファを加えると、合計約21.5GBとなり、デスクトップ用に約3GBの余裕を残す。VRAMは「総パラメータ + KV cache」で決まり、MoEでもここは節約にならない。
  • 演算コスト⁠: トークンあたりの活性化は約3Bのみなので、スループットは3BのDenseモデルに近い——MTPドラフトヘッダーを併用すると実測で約111 t/s。⁠速度は「活性化パラメータ」で決まり、ここがMoEの恩恵である。

これがローカルでMoEを選ぶ理由です：使えるVRAM内に高容量モデルを収め、かつ高速に動作させる——ただし、量子化によって「総パラメータ」をカードに収めることが前提です。⁠ただし代償として、トークンあたりの推論深度は活性化パラメータによって決まります⁠（次節参照）、エージェント/ツール呼び出しなど多段階の推論チェーンを必要とするタスクでは、この代償を考慮して選択してください。

MoEの隠れた代償: トークンあたりの推論深度

上記ではVRAMとスループットのみを計算しましたが、第3の次元があります：⁠トークンあたりの推論深度は総パラメータではなく、活性化パラメータによって決まるという点です。

Transformerの構造を思い出してください:

各層 = self-attention + FFN 注意（どこを見るか） パラメータ固定、完全 順伝播ネットワーク（情報の処理） MoEはtop-kのエキスパートのみを活性化する

attention層は完全です——モデルは入力のどのトークンに注目すべきかを知っています。しかし、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 cache」で見積もれ。 活性化パラメータが小さいからといってVRAMが小さいわけではない——全エキスパートが常驻する必要があり、量子化で総パラメータをカードに収める。
  • MoEのスループットは活性化パラメータで見よ、総パラメータではない。 35B-A3Bは3Bのように動作し、これがMoEの恩恵である。
  • エージェントへの適応性を活性化パラメータで評価し、総パラメータではない。 安定した単一ステップのツール呼び出しには約7–10Bの活性化、安定した多段階エージェントには約20B+が必要；24GB下でエージェントタスクを行う場合は、Denseまたは高活性化MoEを優先。
  • オープンソースの選択ではモデルカードの4点セットを読め。 総パラメータ / 活性化パラメータ / 層数 / 注意タイプ、VRAM予算（ローカルデプロイメント）と組み合わせて決定。

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

  • 「活性化パラメータが小さい」を「VRAMが小さい」と誤解する⁠: MoEのVRAMは総パラメータで決まり、カードが溢れる → 総パラメータ + KV cacheで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