啟用引數

3 秒看懂

啟用引數（Active Parameters）指在稀疏混合專家（MoE）模型中，處理單次輸入（一個 token）時實際參與計算的那一部分引數數量。它直接決定推論的計算量、視訊記憶體頻寬需求與延遲，因此比“總引數”更真實地反映模型的執行成本與部署門檻。一個典型例子：DeepSeek‑V2 總引數 236B，啟用引數僅約 21B——單次推論僅約 9% 的權重被使用。

關鍵結論：啟用引數是 MoE 時代評估大型模型“實際大小”和推論效率的第一性指標。

3 分鐘產業解釋

在大語言模型（LLM）競賽中，單純增加稠密（Dense）模型的總引數量會帶來平方級增長的算力和視訊記憶體開銷，難以持續。混合專家模型（MoE）通過“稀疏啟用”突破這一瓶頸：它將前饋網路子層（FFN）複製為多份“專家”（Expert），每次推論僅啟用其中少數幾個。這樣一來，總引數量可膨脹到數千億甚至萬億，但每次推論實際使用的引數被控制在百億甚至幾十億級別。

從產業視角看，啟用引數的意義有兩層：

推論成本錨點：部署一臺模型所需的 GPU 數量、視訊記憶體佔用、批處理吞吐量主要取決於啟用引數，而非總引數。
能力與效率的平衡點：更大的總引數帶來更強的知識與推論能力，而較小的啟用引數保證推論速度與成本可控。

因此，在模型選型、採購算力、評估推論服務定價時，啟用引數已經成為比總引數更重要的技術經濟指標。

技術原理

為什麼需要啟用引數

稠密 Transformer 中，每個 token 在每一層都會遍歷全部引數，引數量與計算量嚴格正比。MoE 則將部分子層（通常是 FFN）替換為一組並行的“專家”模組，通過一個路由網路（Gating/Router）為每個 token 選擇一個或幾個專家。這使模型總容量急劇擴大，但單個 token 的路徑只經過被選中的專家，出現了“總引數”與“實際使用引數”的分離，啟用引數概念由此誕生。

啟用引數的實際構成

以典型 MoE 層為例，一個 token 的啟用引數包含：

共享部分：注意力層的 Q/K/V/O 投影、LayerNorm、嵌入查詢（僅對應 token 的行向量，引數量 hidden_size）、路由網路本身（通常很小）。
被啟用的專家引數：每個專家通常包含兩個線性層（及門控線性單元變體所需的引數），只計算被路由器選中的 top‑k 個專家。
其他固定開銷：如偏置項（如果存在）。

因此，啟用引數 ≈ 非專家部分引數量 + top‑k ×（單個專家引數量）。在 top‑k 路由策略固定、共享專家與路由結構已確定的前提下，該數量可按照每個 token 的靜態計算路徑精確統計，通常可由模型的 config.json 中的欄位推導得出。

啟用引數的計算方法

稀疏 MoE 模型的啟用引數可通過其配置檔案推導。以公開模型為例，配置中會明確 hidden_size、intermediate_size、num_experts、num_experts_per_tok 等關鍵欄位。啟用引數構成包括：共享的注意力層引數、啟用的專家 FFN 引數、嵌入查詢的對應行（引數量 hidden_size）等。由於不同模型的 FFN 結構差異，精確計算需結合具體變體，但原理一致：啟用引數 = 非專家部分引數量 + top_k × 單個專家引數量。

每層自注意力引數

Q、K、V 投影：各有權重 [hidden_size, hidden_size]，引數量 hidden_size²
輸出投影：同樣 hidden_size²
總計注意力部分：4 × hidden_size²

每層 MoE‑FFN 啟用引數

若專家使用 SwiGLU 變體，其內部通常包含門控投影與兩個線性變換，精確引數量取決於實現。
每 token 啟用 top‑k 個專家，故每層啟用的專家引數 ≈ top_k ×（單個專家實際引數量）。

嵌入層與最終層歸一化

詞嵌入查詢：每個 token 只啟用嵌入矩陣的一行，啟用引數量為 hidden_size（非完整矩陣）。
輸出頭：若與嵌入層共享權重則不額外增加。

總啟用引數估算

依據具體模型的 config 統計即可得到總引數與啟用引數。以 DeepSeek‑V2 為例，總引數 236B，啟用引數約 21B，佔比約 9%（2024 年公開資料，來源：DeepSeek‑V2 技術報告與模型卡）。

啟用引數與總引數的分離機制

路由網路的選擇機制會影響不同專家的工作負載均衡，但與啟用引數量本身無關。啟用引數只關心“有多少個引數會被某次前向/反向傳播觸及”，而不管資料被分發到哪個專家。因此啟用引數是架構級的剛性指標。

硬體負荷對映

一個 token 推論：
┌──────────────────────┐
│ 嵌入查詢 (共享)      │
├──────────────────────┤
│ 第1層：              │
│  注意力 QKV/O (共享)│
│  路由選擇 → 專家i,j  │
│  專家i FFN 計算      │
│  專家j FFN 計算      │
├──────────────────────┤
│  ... 重複多層 ...    │
├──────────────────────┤
│ 輸出頭 (共享)        │
└──────────────────────┘
實際需要讀取的總權重即模型的啟用引數量。

計算量 FLOPs ≈ 2 × 啟用引數量（前向），視訊記憶體佔用則由啟用引數的半精度副本和 KV Cache 等決定。因此啟用引數所對應的延遲和硬體需求與同等規模的稠密模型大致相當，但仍有路由、All‑to‑All 通訊等額外開銷。

關鍵引數

啟用引數量（Active Parameters）：單 token 前向所涉及的引數總數，以 B（十億）為單位。
啟用/總參之比（Activation Ratio）：啟用引數 ÷ 總引數，值越小代表“稀疏度”越高，通常 2%～20%。
專家利用率（Expert Utilization）：實際訓練/推論中各專家被選中的頻率分佈是否均衡，影響計算效率和模型質量。
每 token FLOPs：約 2 × 啟用引數量（前向，忽略 softmax 等），用於預估硬體算力需求。
記憶體頻寬需求：與啟用引數正相關，實際還受 KV Cache 大小、批大小影響。
專家數量與 top‑k：num_experts 和 num_experts_per_tok 直接決定稀疏度與啟用引數佔比。
單專家引數量：取決於 hidden_size 與 intermediate_size，以及 FFN 變體結構。

技術路線

技術演進脈絡

2017 – Transformer 誕生：所有引數對每個 token 全量啟用，總引數即啟用引數。
2020 – GShard：Google 將 MoE 引入大規模 Transformers，首次明確區分總引數與每次推論使用的引數。
2021 – Switch Transformer：提出 top‑1 路由，總引數可至萬億，啟用引數被控制在百億級別。
2021 – GLaM：Google 進一步平衡專家容量，啟用引數約 97B，約為總引數（約 1.2T）的 8%（來源：GLaM 論文，2022 年釋出）。
2023 – Mixtral 8×7B：Mistral AI 推出開源 MoE 模型，總引數 46.7B，啟用引數約 12.9B，引發開發者社群對啟用引數的廣泛討論（來源：Mistral AI 官方部落格，2023 年 12 月）。
2024 – DeepSeek‑V2：公開標識“236B‑A21B”，使啟用引數成為模型命名的標準欄位（來源：DeepSeek‑V2 技術報告，2024 年）。
2024 末至今：業界普遍將啟用引數列入模型卡核心資訊，推論最佳化架構專門針對啟用引數做運算元融合與通訊最佳化。

稠密模型與 MoE 模型對比

指標	稠密模型 (Dense)	稀疏混合專家模型 (MoE)
總引數量	數十億～數百億	數百億～數萬億
啟用引數	等於總引數	遠小於總引數（通常 1%～20%）
單 token 延遲	與總引數嚴格正比	主要由啟用引數決定，額外有路由器開銷與 All‑to‑All 通訊
訓練效率	較簡單，標準資料並行/張量並行	專家負載不均衡、通訊複雜，需專門最佳化
知識容量	受限於前饋層寬度	通過大量專家實現更高知識密度
視訊記憶體佔用	約等於總引數 × 精度 + 最佳化器狀態	總引數需全部駐留，但只部分被啟用；對視訊記憶體要求高，但計算訪存比更友好
推論成本	與總引數正相關	與啟用引數大致正比，但需考慮路由與通訊開銷
代表案例	GPT‑3 175B、LLaMA 65B（早期）	Mixtral、DeepSeek‑V2、GPT‑4（傳聞）

當前主流路線

細粒度專家路由：將單個 FFN 拆分為更多小專家，降低單個專家引數量，提升路由靈活性（如 DeepSeek‑V2 的 160 專家設計）。
共享專家機制：設定部分專家對所有 token 強制啟用，減少路由負載不均衡風險。
推論端最佳化：vLLM、TensorRT‑LLM 等架構引入專家快取、批次專家融合，降低因啟用引數而產生的延遲抖動。

上游

模型架構設計：路由器演算法（Top‑K、Expert Choice）、專家數量和容量、MoE 層在整個網路中的部署頻率，這些設計決策直接決定啟用引數的基礎值。
訓練架構與分散式系統：DeepSpeed‑MoE、Megatron‑LM、TorchMoE 等需高效支援稀疏計算與動態路由，提供專家並行（Expert Parallelism）能力，以容納總引數並穩定訓練。
資料集與令牌分配策略：訓練語料的分佈影響專家負載均衡。若語料分佈偏斜，可能導致部分專家“飢餓”，降低啟用引數的實際利用效率。
硬體設計與製造：HBM 容量、視訊記憶體頻寬、晶片間互聯頻寬構成物理約束。上游廠商（如 NVIDIA、AMD）的產品規劃直接影響 MoE 總引數的上限與啟用引數的吞吐能力。

下游

推論引擎與服務：vLLM、Text Generation Inference、TensorRT‑LLM 等通過動態批處理、專家快取、運算元融合與通訊重疊等技術，降低啟用引數帶來的實際延遲。
硬體適配與部署：高頻寬記憶體容量需容納全部專家權重，而計算單元主要服務啟用引數部分。HBM 頻寬成為推論瓶頸，推動對 H200、B200 等新一代 GPU 的需求。
應用開發者與模型選型：應用方根據啟用引數預估所需的 GPU 數量和成本，進行模型選型和服務定價。啟用引數已成為 API 定價的重要參考依據（如 Together AI、Fireworks 的 MoE 模型計費方案）。
雲端服務商與算力市場：啟用引數概念促使雲端運算廠商重新定義“模型大小”相關的計費單位，從按總引數規模轉向按實際啟用引數與計算量定價（2024 年起部分平台已實踐）。

受益公司

公司 / 組織	相關模型/產品	啟用引數的體現
DeepSeek	DeepSeek‑V2 (236B‑A21B)、DeepSeek‑V3	率先在模型命名中標註總引數與啟用引數，開創業界先河（來源：DeepSeek 技術報告，2024 年）
Mistral AI	Mixtral 8×7B、8×22B	公開強調啟用引數對推論價效比的影響（來源：Mistral AI 官方部落格，2023‑2024 年）
OpenAI	GPT‑4（傳聞為 MoE，總引數約 1.8T，啟用引數約 280B）	公開資料未見官方確認；相關數字為行業推算
阿里雲端	Qwen 系列 MoE 版本	模型卡中包含總引數與啟用引數說明（來源：Qwen 模型卡與官方文件，2024 年）
Google	GLaM、Switch Transformer	最早系統研究啟用引數與效率關係，技術沉澱至 PaLM 後代（來源：GLaM 論文，2022 年）
Meta	傳聞在訓練 MoE LLaMA 變體	具體啟用引數公開資料未見揭露
NVIDIA / AMD	高階 GPU（H100、B200）	HBM 容量和頻寬同時滿足“全部權重常駐”與“啟用引數高吞吐”需求，直接受益於 MoE 普及
Together AI / Fireworks / OctoAI	推論雲端服務	以啟用引數為基準最佳化 GPU 例項利用率，提供差異化定價競爭力

說明：上述列舉基於公開資訊整理，不構成任何投資建議。部分公司的 MoE 模型細節未經官方完全揭露，標註為“傳聞”或“公開資料未見”的部分僅供產業趨勢參考。

市場規模

（以下資料基於公開趨勢的定性描述，部分精確口徑的定量資料公開資料未見）

推論市場需求：自 2023 年底起，MoE 架構因其優越的推論成本‑能力曲線而迅速流行。推論 API 的價格常按每百萬 token 計費，MoE 模型的價格顯著低於同等總引數量稠密模型的估算水平。據多家雲端廠商公開定價頁面的橫向對比，同等效能等級下 MoE 模型的 token 單價約為稠密模型的 1/3 至 1/5（口徑：公開 API 定價，2024 年下半年資料）。
硬體市場規模：MoE 對視訊記憶體總容量的高需求推動高階 GPU 的部署密度。據 NVIDIA 2024 財年公開財報及多家第三方分析報告中的引用，H100 在 AI 雲端和資料中心的出貨量持續攀升，其中 MoE 訓練與推論場景成為重要增量需求來源。
行業滲透：頭部 AI 實驗室（OpenAI、DeepSeek、阿里 Qwen、Mistral 等）均推出標註啟用引數的 MoE 模型。開源社群也將啟用引數作為對比核心指標，Hugging Face 模型庫中 MoE 架構模型數量自 2024 年以來顯著增長（具體增長率公開資料未見精確統計）。
前瞻判斷：預計未來 1–2 年，單模型啟用引數將普遍突破 50B，而推論成本靠最佳化後仍可控制在較低水平。

玩家對比

已公開 MoE 模型關鍵引數對比（截至 2024 年底）

模型	總引數	啟用引數	啟用比	專家設計	資料來源
Mixtral 8×7B	46.7B	~12.9B	~27.6%	8 專家，top‑2	Mistral AI 官方技術部落格，2023 年 12 月
Mixtral 8×22B	~141B	~39B	~27.7%	8 專家，top‑2	Mistral AI 官方技術部落格，2024 年 4 月
DeepSeek‑V2	236B	~21B	~8.9%	160 專家，含共享專家	DeepSeek 技術報告，2024 年
Qwen2‑MoE	~57B（公開資料未見完整驗證）	公開資料未見精確數值	公開資料未見	公佈為 MoE 架構	阿里雲端 Qwen 團隊官方資料，2024 年
GPT‑4（傳聞）	約 1.8T	約 280B	~15.6%	8‑16 專家（外界推測）	公開資料未見官方確認，行業推算

對比分析：

稀疏度差異：DeepSeek‑V2 的啟用比僅為約 9%，明顯低於 Mixtral 系列的約 27%—28%，反映其更激進的稀疏設計。
設計哲學：Mistral 傾向於“較少但較大”的專家，DeepSeek 採用“較多但較小”的細粒度專家，路由靈活性更高。
行業現狀：國內模型（如 DeepSeek、Qwen）在啟用引數的公開透明度上表現突出，部分海外頭部模型（如 GPT‑4）仍未官方揭露細節。

說明：以上資訊來源於各模型官方技術報告、公開部落格及行業分析，不涉及對任何模型效能優劣的評價或投資建議。

風險

技術風險

專家負載不均衡：若路由器在訓練中坍塌至少數幾個專家，導致其餘專家“閒置”，實際有效啟用引數虛高，宣傳的價效比無法兌現。部分早期 MoE 實驗已在學術界報告此類問題。
通訊瓶頸：MoE 推論引入的 All‑to‑All 通訊在小 batch size 或低頻寬互聯場景下可能成為延遲的主要來源，削弱啟用引數帶來的理論優勢。
總視訊記憶體需求不降反升：啟用引數低不代表總視訊記憶體需求低。全部專家權重必須常駐視訊記憶體，對 HBM 容量提出更高要求，可能限制邊緣部署場景。
訓練穩定性：稀疏路由帶來梯度方差增大、負載均衡損失調參困難等問題，可能增加訓練成本與失敗風險。

市場與行業風險

架構同質化與創新停滯：若行業過度聚焦 MoE 稀疏化而忽視其他架構創新路徑，可能造成技術路線單一化風險。
“偽稀疏”營銷：部分模型可能以低啟用比為賣點，但實際有效引數因路由失效而遠高於宣稱值，導致開發者預期與實測表現出現偏差。
硬體供應依賴：MoE 對 HBM 的強依賴使產業受制於高階 GPU 供應鏈。若產能受限或地緣因素影響供應，推論基礎設施建設將受衝擊。

評估建議

關注第三方基準測試的實際推論吞吐與延遲資料，而非僅看啟用引數絕對值。
注意評估模型的路由均衡性與專家利用率，可通過不同領域資料集的推論表現一致性做初步判斷。

誤讀糾偏

❌ 誤讀 1：“啟用引數就是模型推論時用到的全部引數，所以 MoE 推論就和同等啟用引數的稠密模型一樣快。”

✅ 正解：啟用引數決定了主要計算量，但 MoE 推論還引入了路由器開銷、專家權重動態載入，以及 token 分發/收集產生的 All‑to‑All 通訊。這些額外因素使 MoE 的實際延遲通常高於同等啟用引數的稠密模型，尤其在 batch size 較小或通訊頻寬受限時。但啟用引數仍是最準確的一階近似。

❌ 誤讀 2：“MoE 模型的 config.json 裡寫了 `activation_function: silu`，所以這個模型的啟用引數就是使用 SiLU 的引數部分。”

✅ 正解：“啟用引數”（Active Parameters）與“啟用函式”（Activation Function）是完全不同的概念。config.json 中的 activation_function 欄位僅指神經元非線性變換函式（如 GeLU、SwiGLU），與用於衡量計算規模的啟用引數毫無關係。許多開發者因欄位相似而產生混淆。

❌ 誤讀 3：“啟用引數 = 總引數 ×（top_k / num_experts）”

✅ 正解：這個簡便公式忽略了共享的注意力層、嵌入層和路由網路等非專家引數。實際上啟用引數佔比會高於簡單的比例估算，尤其在總引數量較小、共享部分佔比可觀的時候。準確計算必須逐層統計。

❌ 誤讀 4：“啟用引數越小越好，追求極低啟用比就是終極目標。”

✅ 正解：啟用比降低通常意味著總引數膨脹，雖然單 token 計算量降低，但總視訊記憶體需求增加、通訊開銷增大。過度追求低啟用比可能犧牲模型質量或帶來部署上的隱性成本。最優啟用比取決於具體應用場景的算力‑視訊記憶體‑延遲綜合約束。

追蹤指標

新模型啟用比：關注新發布 MoE 模型的啟用引數與總引數比值，判斷行業稀疏度演進方向。源：各公司技術報告、模型卡。
推論延遲與吞吐：第三方基準測試（如 LMSYS Chatbot Arena 的推論效能評估、Artificial Analysis 的 LLM 推論速度排行榜）可提供啟用引數差異對應的實際部署表現。
專家利用率分佈：開源模型的推論日誌或技術報告中若揭露各專家呼叫頻率分佈，可幫助判斷路由機制是否健康。源：模型技術報告、開源社群分析。
硬體規格演進：HBM 容量、視訊記憶體頻寬、晶片間互聯頻寬的逐代提升速度，影響 MoE 部署的經濟可行性。源：NVIDIA、AMD 官方產品規格書。
推論 API 定價變化：各雲端廠商 MoE 模型與稠密模型的 token 單價變化，反映啟用引數概念對商業定價的實際滲透。源：Together AI、Fireworks、OpenAI、DeepSeek 等官方定價頁面。
開源架構支援進展：vLLM、SGLang、llama.cpp 等對 MoE 模型的量化、專家快取、通訊最佳化等功能的迭代速度。源：GitHub Release Notes 與社群討論。

信源

DeepSeek‑V2 技術報告：DeepSeek‑AI, “DeepSeek‑V2: A Strong, Economical, and Efficient Mixture‑of‑Experts Language Model,” 2024。模型架構部分詳述 236B‑A21B 引數體系與細粒度專家設計。
Mistral AI 官方部落格：Mixtral 8×7B（2023 年 12 月）與 Mixtral 8×22B（2024 年 4 月）釋出公告，公開總引數與啟用引數資料。
GLaM 論文：Du et al., “GLaM: Efficient Scaling of Language Models with Mixture‑of‑Experts,” ICML 2022。最早系統研究啟用引數與效率關係。
Switch Transformer 論文：Fedus et al., “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity,” JMLR 2022。提出 top‑1 路由，建立總引數與啟用引數分離範式。
阿里雲端 Qwen 官方文件：Qwen 系列模型卡，包含 MoE 版本的總引數與啟用引數說明（持續更新，截至 2024 年）。
知乎專欄“LLM 細節盤點”系列：鹹魚王，《LLM 細節盤點(1)：啟用函式》，列出主流 LLM 的啟用函式與 DeepSeek‑V2 (236B‑A21B) 等模型的標註，輔助概念區分。
CSDN 技術部落格：《如何根據 config.json 核對 MoE 模型的啟用引數》，詳述從 config 欄位推導總引數與啟用引數的完整過程。
vLLM 專案文件與原始碼：GitHub‑vllm‑project/vllm，包含 MoE 支援的設計文件與實現，展示推論架構如何以啟用引數為導向最佳化排程。
NVIDIA 官方產品資料：H100、B200 規格書與公開技術白皮書，涉及 HBM 容量/頻寬與 MoE 部署場景的匹配。
Artificial Analysis 推論速度排行榜：獨立第三方對公開 LLM API 的推論延遲與吞吐持續監控，可用於驗證啟用引數與實際效能的關係。

宣告：本文所涉及的財務資料、市場價格、市場份額及產能數字，除明確標註年份、口徑與來源者外，均採用定性描述。不確定之處已標註“公開資料未見”，未進行任何編造。本文不構成任何投資建議、買賣建議或漲跌預測，亦不出現“值得買”等推薦性措辭。