MoE 混合專家模型：為什麼 35B 等級的大模型也能在小顯示卡上跑（前提是系統記憶體夠大）

你在模型清單裡看到「30B-A3B」「235B-A22B」這類名字，很容易以為「A3B 就只要 3B 的顯存」，或是「30B、35B 等級的模型竟然能在小顯示卡上跑」。這篇要講的 MoE 混合專家模型，確實讓大模型有機會在小顯示卡上跑，但這句話要有條件才成立：MoE 省的是每個 token 的運算量與讀取量，不省「權重放在哪裡」的空間。 讀完這篇，你會知道 MoE 到底是什麼、怎麼從模型檔案判斷它是不是 MoE、怎麼用幾個算式估出需要多少顯存與系統記憶體，以及為什麼速度只能做定性的推論。

MoE 混合專家模型是什麼？

MoE 是 Mixture of Experts 的縮寫，中文叫「混合專家模型」。先交代兩個基本詞：參數（parameter），也常叫權重（weight），是模型訓練出來、存在檔案裡的數字，模型的大小就是這些數字的數量。它的做法是：在模型的每一層裡，不是只放一個大的前饋網路（feed-forward network，每一層裡負責做非線性轉換、佔掉大部分參數的那一塊，Hugging Face 文件稱為 MLP），而是放多個結構相同的「專家」（expert）子網路，再加上一個「路由器」（router），由路由器決定每個 token 要交給哪幾個專家處理。token 是模型處理文字的最小單位，詳見術語表。沒被選到的專家，在這個 token 上就不參與運算。

這個說法有官方文件可以對照。Hugging Face Transformers 的 Mixtral 說明文件寫到：Mixtral 是一個 MoE 模型，每個 MLP 有 8 個專家，總共 45 billion（450 億）參數；每個 token 的隱藏狀態會被派送兩次（文件稱 top 2 routing，也就是挑兩個專家）。文件並且說明，雖然模型有 45 billion 參數，單次前向運算（forward pass）所需的運算量卻與一個 14 billion 參數的模型相當。文件開頭引用的發表文字則把這類模型稱為稀疏混合專家模型（sparse mixture of experts，SMoE）。路由器在 GGUF 格式規格裡也有對應：規格列出一種叫 ffn_gate_inp 的張量，說明是「MoE 模型中前饋網路的專家路由層」。

這裡出現了兩個一定要分開的數字：

• 總參數量（total parameters）：模型所有專家加上共用部分的參數總數。它決定模型檔案有多大、權重總共要佔多少空間。
• 啟用參數量（activated parameters）：處理一個 token 時實際用到的參數數量。它決定每個 token 的運算量，以及每個 token 需要從記憶體讀多少權重。

相對地，每個 token 都會用到全部參數的一般模型，這篇稱為「稠密（dense）模型」，英文常直接寫 Dense。Dense 模型的總參數量與啟用參數量是同一個數字，所以平常談模型大小時，沒有人需要區分兩者；MoE 模型才必須分開看。

模型名稱裡的 A3B 是什麼

Qwen3 的 README 把模型分成密集與 MoE 兩類，列出的 MoE 模型是 30B-A3B 與 235B-A22B；後來更新的 2507 版本則提供 235B-A22B、30B-A3B 與 4B 三種大小。README 本身沒有逐字解釋名稱裡的 A。不過 Qwen3 技術報告在描述旗艦模型時寫得很明確：Qwen3-235B-A22B 是 MoE 模型，總共 235B 參數，每個 token 啟用 22B。照這個對應，名稱「總參數-A啟用參數」的讀法就很自然：A 後面的數字是每個 token 啟用的參數量。（這是從技術報告的描述對應出來的讀法，不是 README 的原文，不同廠商的命名習慣也未必一致，遇到不熟悉的名稱請回到模型頁面確認。）

技術報告還寫了這兩個 Qwen3 MoE 模型的專家設計：共 128 個專家，每個 token 啟用 8 個，並且與前一代 Qwen2.5-MoE 不同，沒有共享專家（shared experts，一種每個 token 都會經過的專家）。不同 MoE 模型的專家數與每次啟用的數量不同，Mixtral 是 8 選 2，Qwen3 是 128 選 8，所以不能拿一個模型的比例套到另一個模型。

為什麼 8x7B 不是 56B

Mixtral 常被稱為「8x7B」，容易讓人算成 8 × 7 = 56B。但上面引用的 Mixtral 文件寫的總參數是 45 billion，並不是 56。原因是專家只取代每一層裡的 MLP（文件寫法是「8 experts per MLP」），注意力層等其他部分是所有專家共用的，並沒有複製八份。GGUF 的命名規範也把「專家數」與「每個專家的參數量」放在檔名的尺寸標籤裡，格式是「專家數 x 參數量」，所以看到 8x7B 這種標示，請把它讀成「8 個專家、每個標稱 7B」，而不是總量等於 8 乘 7。

先講清楚：MoE 省了什麼，沒省什麼

這是整篇最重要的一段，請對照 Mixtral 文件的原話來讀。文件說：雖然模型有 45 billion 參數，單次前向運算的運算量與 14 billion 參數的模型相同，「因為每個專家都必須載入 RAM」（原文：even though each of the experts have to be loaded in RAM），而每個 token 只被派送到兩個專家，所以運算量才會少。換句話說，MoE 做了兩件完全不同的事：

面向	MoE 有沒有幫上忙	依據
每個 token 的運算量	有，看啟用參數而不是總參數	Mixtral 文件：45B 的模型，單次運算量相當於 14B 的模型
每個 token 需要讀取的權重量	有，只需讀到被選中的專家，加上共用部分	由「啟用參數 × 位元數 ÷ 8」推出，見下方估算方法
權重總共要放在哪裡、佔多少空間	沒有，所有專家都要存在某處	Mixtral 文件：每個專家都必須載入 RAM；該文件在量化一節也以 45 billion 參數來估算 fp16 需要約 90GB
模型檔案大小	沒有，仍由總參數與位元數決定	同上，由總參數計算

所以「MoE ＝ 小模型」是錯的。它是一個很大、但每次只動用一小部分的模型：大，所以要有地方放；小部分，所以每個 token 算得少、讀得少。

「35B 也能在小顯示卡上跑」到底要滿足什麼條件

既然所有專家的權重都要放在某處，那小顯示卡的顯存（VRAM，顯示卡上專用的記憶體）放不下的時候，唯一的辦法就是放到系統記憶體（RAM，電腦主機板上的一般記憶體）。這正是 MoE 特別適合這種做法的原因：專家權重佔了總量的絕大部分，但每個 token 只會用到其中一小部分；而注意力層等「每個 token 都會用到」的共用部分相對很小，可以常駐在顯存裡。

llama.cpp 是一套常見的本地推論程式（可以執行 GGUF 格式的模型）。它的官方伺服器說明裡，啟動參數表直接有針對 MoE 的選項。該文件的內容整理如下（旗標名稱與行為以官方文件為準，版本不同可能改名，這裡只為說明原理）：

旗標	官方文件的描述（中文轉述）
--cpu-moe（簡寫 -cmoe）	把所有 MoE 專家的權重留在 CPU 端
--n-cpu-moe N（簡寫 -ncmoe）	只把前 N 層的 MoE 專家權重留在 CPU 端
--n-gpu-layers（簡寫 -ngl）	最多有多少層存放在顯存
--override-tensor（簡寫 -ot）	依張量名稱的樣式，覆蓋該張量要放的緩衝區類型
--moe-cache-mib	為「留在 CPU 的專家」在 GPU 上建立的快取大小（MiB），預設為 0（停用）

這幾行文件有三個地方值得注意。第一，MoE 專家被獨立成一個設定，不跟「放幾層到顯存」的一般設定混在一起，這和 GGUF 規格裡專家權重本來就是獨立張量（ffn_up_exp、ffn_down_exp、ffn_gate_exp，與注意力的 attn_q、attn_output 等分開命名）互相呼應。第二，--n-cpu-moe 是「前 N 層」，也就是你可以只把一部分的專家留在系統記憶體，其餘仍放顯存，這是在顯存與系統記憶體之間取捨的旋鈕。第三，官方文件對這些旗標只有一句話的描述，沒有給出速度數字，也沒有說「放哪些設定最好」，所以這篇也不會給。

把上面整理成條件，「35B 等級的 MoE 能在小顯示卡上跑」大致要同時滿足：

1. 共用部分放得進顯存：注意力層等每個 token 都會用到的權重，加上 KV 快取（KV cache，模型為了不重複計算前面內容而存下的中間結果，會隨上下文變長而變大），要放得進你的顯存。怎麼估 KV 快取與顯存，請看依顯存選模型與顯存估算方法。
2. 系統記憶體夠大：專家權重總量要放得進系統記憶體，還要留空間給作業系統與其他程式。llama.cpp 說明裡的載入模式也提到，可以要求系統把模型鎖在記憶體裡（mlock），避免被換出到硬碟（swapping）；一旦記憶體不夠，這件事就沒有辦法成立。顯存、記憶體、硬碟各自的角色，見顯存、記憶體、硬碟各扮演什麼角色。
3. 接受速度取決於記憶體頻寬：頻寬（bandwidth）是記憶體每秒能傳送多少資料。專家在系統記憶體時，每個 token 要讀專家權重，就會受那一塊記憶體的頻寬限制。這點在後面的算式裡會看得更清楚。

少了任何一條，「也能在小顯示卡上跑」這句話就不成立。

怎麼看一個模型是不是 MoE

不必靠名稱猜。GGUF 是 llama.cpp 使用的模型檔案格式，檔案裡除了權重，還帶有 metadata（描述模型的欄位）。GGUF 規格在 LLM 的欄位裡定義了兩個與 MoE 有關的欄位，其中 [llm] 要替換成架構名稱：

metadata 欄位	規格上的意思
[llm].expert_count	MoE 模型的專家總數（非 MoE 架構可以沒有，規格標示為 optional）
[llm].expert_used_count	每個 token 評估時使用的專家數（同樣是 optional）

架構名稱是什麼，要看實際的檔案。llama.cpp 的量化工具說明裡就有一個例子，使用 qwen3moe.expert_used_count 這個名稱來覆寫該欄位，可以看出欄位前面確實是「架構名稱加句點」的形式。你拿到一個 GGUF 檔案時，能列出 metadata 的工具都可以確認這兩個欄位；如果完全沒有專家相關欄位，多半就是稠密模型。

另一個線索是張量名稱。GGUF 規格列出的 MoE 專用張量有 ffn_gate_inp（專家路由層）以及逐專家的 ffn_gate_exp、ffn_up_exp、ffn_down_exp。看得到這些名稱，就表示該層有路由器與多個專家。

至於檔名，GGUF 的命名規範把尺寸標籤寫成「專家數 x 參數量」，像規範範例裡的 Mixtral-8x7B-v0.1，專家數為 8、參數量為 7B。不過並不是所有模型檔名都照這個規範，像 Qwen3 的 30B-A3B 就是另一種寫法，所以檔名只能當第一個線索，最後仍以 metadata 與模型說明為準。

另外，專家數與每次啟用的數量有一個直接的用途：它們告訴你「啟用比例」，也就是每一層裡只有 expert_used_count ÷ expert_count 的專家權重會被用到。後面的估算方法會用到這個比例。

估算方法：總權重、每 token 讀取量、顯存與系統記憶體

下面所有算式都是估算，用來判斷「放不放得下」與「大致誰比誰重」，不是精確的量測結果。單位上，算式裡的 1 GB 取 10⁹ 位元組；llama.cpp 量化工具說明的表格使用的是 GiB（約 1.074 × 10⁹ 位元組），兩者有一點差距。

先備資料

符號	意思	從哪裡取得
N_total	總參數量	模型頁面、模型名稱（如 30B）
N_active	每個 token 啟用的參數量	模型頁面、名稱裡 A 後面的數字
E	專家總數	GGUF 的 expert_count
k	每個 token 啟用的專家數	GGUF 的 expert_used_count
b	平均每個參數用幾位元存放	由量化格式決定（量化是把權重改用更少的位元儲存），見量化是什麼

關於 b，要注意標稱和實際不同。llama.cpp 量化工具說明針對 Llama-3.1-8B 列出各種量化格式的每權重位元數（bits/weight）：Q4_K_M 是 4.8944，Q8_0 是 8.5008，F16 是 16.0005。也就是說，標稱「4 位元」的格式，實際平均會略高於 4 位元，因為還要存縮放係數等資訊。這是特定模型的量測值，換成別的模型會略有出入，只當量級參考。

公式

總權重大小 W_total = N_total × b ÷ 8
每個 token 需讀取的權重量 W_token = N_active × b ÷ 8

÷ 8 是把位元換算成位元組。兩個公式的差別只有一個：前者用總參數，後者用啟用參數。稠密模型兩者相同；MoE 模型 W_token 遠小於 W_total。

如果你想進一步知道「共用部分」與「專家部分」各佔多少（決定顯存放什麼、系統記憶體放什麼），可以用專家數與啟用數倒推。假設所有專家一樣大、沒有其他會隨選擇改變的部分，則：

N_active = N_shared + (N_total − N_shared) × (k ÷ E)

移項得：N_shared = (N_active − N_total × k ÷ E) ÷ (1 − k ÷ E)
專家部分 N_experts = N_total − N_shared

N_shared 是每個 token 一定會用到的參數（注意力層、把文字轉成向量的嵌入層、路由器等），N_experts 則是所有專家的參數總和。顯存的需求大致是：

顯存 ≈ N_shared × b ÷ 8 ＋ KV 快取 ＋ 其他開銷
系統記憶體 ≈ N_experts × b ÷ 8 ＋ 作業系統與其他程式

這兩個式子假設專家全部放在系統記憶體。如果你只把前 N 層的專家放到系統記憶體，就按比例扣掉放在顯存的那部分即可。

示範計算 A：一個假設的「35B、啟用 3B」模型

以下的 35B 與 3B 是為了算式而假設的數字，不是任何真實模型的規格。

面向	以標稱 4 位元（b = 4）估算	以 Q4_K_M 的 4.8944 位元估算
總權重 W_total	35 × 10⁹ × 4 ÷ 8 ＝ 17.5 GB	35 × 10⁹ × 4.8944 ÷ 8 ≈ 21.4 GB
每 token 讀取量 W_token	3 × 10⁹ × 4 ÷ 8 ＝ 1.5 GB	3 × 10⁹ × 4.8944 ÷ 8 ≈ 1.8 GB
同總量的稠密 35B，每 token 讀取量	17.5 GB	≈ 21.4 GB
稠密與 MoE 每 token 讀取量比	35 ÷ 3 ≈ 11.7 倍	35 ÷ 3 ≈ 11.7 倍

從這張表可以直接讀出兩個重點。第一，總權重不會因為是 MoE 而變小：17.5 GB 到 21.4 GB 的權重，還是得放得進顯存加系統記憶體的總和，所以「35B 只要 3B 的記憶體」是誤解。第二，每個 token 要讀的量從 17.5 GB（稠密）降到 1.5 GB，這才是 MoE 的好處所在。

示範計算 B：用 Qwen3-30B-A3B 的公開資料倒推共用部分

已知（Qwen3 技術報告）：128 個專家、每次啟用 8 個，所以 k ÷ E = 8 ÷ 128 = 1/16。名稱給出 N_total ≈ 30B、N_active ≈ 3B。這兩個名稱數字是四捨五入的，所以結果只能看量級。

N_total × k ÷ E = 30 × 1/16 = 1.875 (B)
N_shared = (3 − 1.875) ÷ (1 − 1/16) = 1.125 ÷ 0.9375 = 1.2 (B)
N_experts = 30 − 1.2 = 28.8 (B)

以 b ＝ 4.8944 估算：

共用部分 ≈ 1.2 × 10⁹ × 4.8944 ÷ 8 ≈ 0.73 GB
專家部分 ≈ 28.8 × 10⁹ × 4.8944 ÷ 8 ≈ 17.6 GB
合計     ≈ 30 × 10⁹ × 4.8944 ÷ 8 ≈ 18.3 GB

意思是：假如這個粗估大致成立，那麼專家約佔總權重的 28.8 ÷ 30 ＝ 96%（每種參數用同樣的位元數時，位元組比例等於參數比例），每次只用其中 1/16；每個 token 都會用到的共用部分只佔約 4%。這正是「把共用部分放顯存、專家放系統記憶體」這個做法可行的原因。再次提醒，1.2B 是由四捨五入的名稱數字倒推的，實際的共用參數量要看模型官方資料。

示範計算 C：用 Mixtral 說明文件的數字

文件給的是：總參數 45 billion，單次運算量相當於 14 billion 的模型，且文件在量化一節寫到 45 billion 參數在半精度（float16，每參數 2 位元組）需要約 90GB。

fp16 總權重：45 × 10⁹ × 16 ÷ 8 = 90 GB（與文件一致）
fp16 每 token 讀取量（以「相當於 14B」近似啟用參數）：14 × 10⁹ × 16 ÷ 8 = 28 GB
同樣 45B 的稠密模型，每 token 讀取量：90 GB

文件接著說，量化成 4 位元後大約需要 27 GB。如果直接套公式，45 × 10⁹ × 4 ÷ 8 ＝ 22.5 GB，比文件寫的 27 GB 小。這個差距正好示範了一件事：公式算出的是下限，實際格式還有額外開銷，所以估算要留餘裕。另外文件的 14 billion 是「運算量相當於」的說法，不是逐字的「啟用參數量」，所以上面第二行只是近似。

速度的上限分析（只做算式，不給數字）

在逐個 token 生成文字的時候，每生成一個 token，就要把這個 token 用到的權重從記憶體讀進處理器。如果瓶頸在「讀權重」（這是一個簡化假設，實際還有計算、其他資料搬移等因素），那麼：

每秒能生成的 token 數 ≤ 記憶體頻寬 ÷ 每個 token 需讀取的權重量

這是一個「上限」的算式，不是預測值。套用到 MoE 上，有三點可以做定性的推論：

1. 其他條件相同，W_token 越小，上限越高。MoE 的 W_token 比同總量的稠密模型小，所以上限的算式比較有利。

2. 若專家全在顯存，分母用顯存頻寬；若專家在系統記憶體，專家那部分的讀取量要除以系統記憶體頻寬。時間大致是兩段相加：

   每個 token 的時間 ≳ 讀取自顯存的量 ÷ 顯存頻寬 ＋ 讀取自系統記憶體的量 ÷ 系統記憶體頻寬

   哪一項大，就是瓶頸。如果你的系統記憶體頻寬比顯存頻寬低很多（請查自己電腦的規格，這篇不列任何型號的數字），專家那一項就會主導。

3. 上限算式忽略了很多實務因素，所以它只能用來比較方向，例如「專家全放顯存」與「專家放系統記憶體」哪個上限比較高，而不是算出你的機器會跑幾 tokens/s。要知道實際速度，請自己測，方法見 Token/s 怎麼看與正確的速度測試方法。

llama.cpp 的 llama-bench 說明裡，--n-cpu-moe 與 -ot 也列在可以調整並比較的參數裡，這代表你可以用同一套測試方法，比較不同「放哪裡」的設定。但具體結果因硬體而異，本文不引用任何數字。

Dense 與 MoE 比較表

下面的每一格，都來自前面讀到的文件，或是由前面的算式推出來的說法。「Dense」指稠密模型。

比較項目	Dense 模型	MoE 模型
總權重放在哪裡	全部放在顯存，或其中一部分放在系統記憶體	所有專家都要存在某處（Mixtral 文件：每個專家都必須載入 RAM）；可選擇把專家留在系統記憶體（llama.cpp 有相關旗標，以官方文件為準）
每個 token 的運算量	與總參數量對應	與啟用參數量對應（Mixtral：45B 的模型，單次運算量相當於 14B）
每個 token 需讀取的權重量	N_total × b ÷ 8	N_active × b ÷ 8，比同總量的稠密模型小
總權重大小	N_total × b ÷ 8	同樣由 N_total × b ÷ 8 決定，不因 MoE 而縮小
對顯存的要求	全放顯存時，約為總權重＋KV 快取＋額外開銷	專家全放顯存時與稠密模型同量級；專家放系統記憶體時，約降為共用部分＋KV 快取＋額外開銷
對系統記憶體的要求	全放顯存時要求較低	專家放系統記憶體時，約為專家部分的權重大小，再加上作業系統與其他程式
速度主要受什麼限制	讀取全部權重的記憶體頻寬（由上限算式推得）	讀取啟用權重的記憶體頻寬；專家在系統記憶體時，受系統記憶體頻寬影響（由上限算式推得）
適合的情況	顯存足夠放下整個模型、想要行為單純、好估算	顯存不足但系統記憶體很大，願意用較複雜的設定，換取能使用更大的總參數量

最後一列是依前面推導的條件所下的判斷：MoE 的好處需要「有一塊夠大的記憶體放專家」，而且你得接受設定較複雜、速度與頻寬有關。如果你的顯存本來就夠放下整個模型，用 Dense 或 MoE 的取捨就會回到模型品質與用途，而不是記憶體。

常見誤解

誤解 1：「MoE 就是小模型。」 MoE 的總參數量是大的，檔案也是大的。它的特點是「每個 token 只用一部分」，不是「整個模型比較小」。

誤解 2：「A3B 就只要 3B 的顯存。」 A 後面是啟用參數，決定每個 token 的運算與讀取量，不決定權重要放多少空間。總權重仍由總參數決定，見示範計算 A 與 B。

誤解 3：「8x7B 就是 56B。」 Mixtral 文件寫的是 45 billion。專家只取代每層的 MLP，其餘共用，所以總量不是 8 乘 7。

誤解 4：「把專家放到系統記憶體，速度就跟全放顯存差不多。」 本文引用的文件沒有這樣說。從算式看，專家那一段的讀取會受系統記憶體頻寬限制。實際差多少，要用自己的機器測。

誤解 5：「既然啟用參數少，量化可以省略或隨便選。」 量化決定的是 b，影響 W_total 與 W_token 兩個算式，與是否為 MoE 無關。標稱的位元數與實際每權重位元數也不同，見前面 Q4_K_M 的例子。

誤解 6：「公式算出放得下，就一定載得進去。」 公式給的是權重本身的下限。Mixtral 文件的 4 位元估算（約 27 GB）就比直接套公式（22.5 GB）大。還要再加上 KV 快取、執行時的額外開銷與作業系統占用，估算時請留餘裕。

這套估算什麼時候不適用

• 只適用於權重大小與逐個 token 生成的粗估。 上下文很長、一次處理很多 token 的情況，哪些專家會被用到、讀取量怎麼變，這篇沒有查到文件說明，所以不做推論。
• 名稱裡的數字是四捨五入的。 30B、3B 這種數字用來算量級可以，用來算精確的位元組數不行。
• 不同模型的專家設計不同。 專家數、每次啟用數、有沒有共享專家都不一樣（Qwen3 技術報告提到它沒有共享專家），套公式前先查 expert_count 與 expert_used_count。
• 旗標與預設值會變。 這篇引用的是 llama.cpp 說明文件的內容，實際使用時請以你手上版本的官方文件為準。
• 這篇不比較模型的好壞。 MoE 與 Dense 的回答品質如何，不在這篇範圍，也沒有從文件中查到可以引用的結論。

如果你不想自己下啟動參數，可以先看Strata 與 PolyStrata 的比較，了解現成的本地大模型工具各自的定位。這些工具是否提供「把專家放到系統記憶體」的選項，要看它們自己的說明。

延伸閱讀

• 依顯存選模型與顯存估算方法：KV 快取與顯存怎麼估，是本篇「共用部分要放進顯存」的前置知識。
• 顯存、記憶體、硬碟各扮演什麼角色：專家放系統記憶體時，系統記憶體與硬碟分別扮演什麼角色。
• 量化是什麼（Q4、Q8、GGUF）：b 這個數字怎麼來。
• Token/s 怎麼看與正確的速度測試方法：想知道專家放不同位置的實際速度，需要正確的測試方法。
• Strata 與 PolyStrata 的比較：用現成工具跑本地大模型的選擇。
• 術語表：LLM、token 等名詞的簡短定義。