MoE 與 Dense：權重容量、Active Parameters、Offload 與 KV Cache¶

狀態：已發布
領域：AI／Local LLM／容量規劃
理解確認：Kent 已於 2026-08-16 明確確認理解核心概念
內容核准：Kent 已於 2026-08-16 核准本文發布

這篇文章回答什麼問題？

MoE 模型每個 Token 只啟用少數 Experts，是否代表它需要的顯存比 Dense 模型少？本文分開分析 Total Parameters、Active Parameters、權重儲存、KV cache 與 Runtime overhead，並說明 RAM／CPU offload 為何能讓模型執行，卻不一定能維持高速度。

不要只比較模型名稱後面的 B 數

判斷 Local LLM 能否在特定硬體執行時，至少要同時確認 Total Parameters、Active Parameters、量化後權重、Context、Concurrency、Runtime 與 Offload 策略。Active Parameters 低，不代表全部權重只占相同大小的記憶體。

先看結論¶

Total Parameters
→ 決定需要保存多少模型權重

Active Parameters
→ 影響每個 Token 主要經過多少參數計算

Context／Concurrency
→ 主要增加 KV cache

Offload
→ 降低 VRAM 常駐權重，但可能把瓶頸轉到 RAM、CPU 或 PCIe

MoE 的核心優勢通常是：

使用較大的總參數容量，但每個 Token 只啟用其中一部分，降低相對於總模型規模的計算量。

它不是：

未被選中的 Experts 不需要保存，因此模型只占 Active Parameters 對應的記憶體。

一、Dense 與 MoE 的參數使用方式¶

Dense 模型¶

Dense 模型每次 forward pass 會使用幾乎所有主要權重：

Total Parameters ≈ Active Parameters

例如一個假想 Dense 模型：

Total： 32B
Active：32B

每個 Token 都會經過完整的 Dense 路徑。

MoE 模型¶

Mixture of Experts（MoE）將部分 Feed-Forward Network（FFN）替換成多個 Experts，並由 Router 依 Token 選擇少數 Experts：

Token
→ Router
→ 選擇 Top-k Experts
→ 合併 Expert 輸出

假想模型：

Total： 64B
Active：8B

意思是：

模型總共需要保存約 64B 參數。
每個 Token 的主要計算路徑只啟用約 8B 參數。
下一個 Token 可能選擇不同 Experts。

因此：

Total Parameters > Active Parameters

二、權重容量主要看 Total Parameters¶

忽略 Quantization metadata、對齊與 Runtime buffer，原始權重容量可近似為：

\[ M_{\mathrm{weights}} \approx N_{\mathrm{total}}\times\frac{b}{8} \]

其中：

\(N_{\mathrm{total}}\)：總參數量。
\(b\)：每個參數使用的 bits。
\(M_{\mathrm{weights}}\)：近似權重容量。

假想比較：

模型	Total	Active	4-bit 原始權重	FP16 原始權重
Dense	32B	32B	約 16 GB	約 64 GB
MoE	64B	8B	約 32 GB	約 128 GB

這些數字只用來說明比例。實際檔案與執行占用還會加入：

Quantization scales、zero points 與 metadata。
Tensor alignment。
Runtime compute buffer。
Activations 與 workspace。
KV cache。
CUDA graph 或其他 Backend overhead。

所以：

參數量 × bits ÷ 8

是容量估算起點，不是最終 VRAM 保證值。

三、「MoE 比 Dense 吃顯存」必須先定義比較基準¶

比較相同 Total Parameters¶

Dense：32B total
MoE：  32B total

若量化格式和其他條件相同，兩者的原始權重容量大致同級。MoE 不會因為只啟用少數 Experts，就讓未啟用權重從儲存空間消失。

比較相同 Active Parameters¶

Dense：8B total／8B active
MoE： 64B total／8B active

此時 MoE 保存的權重更多，但每個 Token 的主要 Expert 計算量可能接近較小 Dense 模型的量級。

比較相近品質¶

沒有固定公式能從 MoE／Dense 標籤推出品質等價關係。品質還受到：

Training data 與 Training compute。
Architecture 與 Router 設計。
Expert specialization 與 load balancing。
Distillation。
Post-training。
Quantization。
Prompt 與目標任務。

影響。

因此「某個 MoE 等於某個 Dense」只能在指定 Benchmark、任務、模型版本與執行條件下成立，不能作為普遍換算。

四、Active Parameters 影響計算，但不直接等於速度¶

較低 Active Parameters 通常意味著較少的主要矩陣運算，但實際速度還受到：

Router 計算。
Token dispatch／gather。
Expert load balance。
Memory bandwidth。
Runtime 的 MoE kernel 效率。
Batch size。
CPU／GPU Offload。
多 GPU Expert parallelism 與互連。

影響。

所以：

Active 8B
≠
速度必然等於 Dense 8B

正確說法是：

Active Parameters 是計算規模的重要指標，但不是完整的延遲或 Tokens Per Second 模型。

五、Experts 可以不全部放在 VRAM¶

「MoE 所有 Experts 都必須放在 VRAM」過於絕對。權重可以分布在：

單張 GPU VRAM。
多張 GPU。
系統 RAM。
CPU 可直接存取的記憶體。
Runtime 管理的 Cache／Offload 層。

但不論放在哪裡，總權重仍需被保存。Offload 改變的是權重位置與執行路徑，不會把 64B total 變成 8B total。

六、RAM／CPU Offload 為什麼能跑，但可能很慢？¶

假設：

MoE 4-bit 權重：約 32 GB
可分配給權重的 VRAM：約 10 GB
其餘權重：系統 RAM

模型仍可能執行，因為 Runtime 不要求所有權重同時常駐單張 GPU。

路徑一：RAM 權重搬到 GPU 執行¶

Expert 權重位於 RAM
→ 經系統記憶體與 PCIe
→ GPU／VRAM
→ GPU 執行矩陣運算

若傳輸時間遠大於 GPU 計算時間：

資料搬運時間 ≫ 計算時間

GPU 便會反覆等待權重，出現：

GPU utilization 偏低或忽高忽低。
PCIe／RAM bandwidth 成為瓶頸。
Tokens Per Second 降低。
計算單元無法持續被餵滿。

路徑二：RAM 中的 Expert 由 CPU 執行¶

RAM 中的權重
→ CPU 執行 Expert
→ 將 activation 與 GPU 路徑整合

此時瓶頸可能轉為：

CPU 算力。
RAM bandwidth。
CPU／GPU activation 傳輸。
Runtime 排程。

路徑三：Expert Cache／預取¶

Runtime 可以嘗試：

熱門 Experts → VRAM
冷門 Experts → RAM

若 Cache hit rate 高，能減少搬運；但 Router 會依 Token 動態選擇 Experts，命中率與收益取決於輸入分布和 Runtime 實作。

因此：

MoE 降低「需要算多少」，Offload 則可能限制「權重供應得多快」。

七、MoE 可能是 Memory／I/O Bound¶

當 GPU 等待權重時，系統瓶頸不是 GPU 峰值算力，而可能是：

RAM bandwidth
PCIe bandwidth
CPU compute
GPU 間互連
Expert dispatch

這種情況屬於 Memory／I/O bound。

評估時不能只看：

GPU 型號。
CUDA cores。
Active Parameters。

還要觀察：

權重實際放置位置。
CPU 與 RAM 規格。
PCIe 連線寬度與世代。
Runtime 是否支援 Expert-aware offload。
GPU utilization、CPU utilization 與記憶體頻寬。
TTFT 與 Decode TPS。

八、KV Cache 是另一筆記憶體預算¶

模型權重通常在載入後大致固定；KV cache 會隨 Request 動態增減。

在簡化條件下，KV cache 可概念性表示為：

\[ M_{\mathrm{KV}} \propto 2\times L\times H_{\mathrm{KV}}\times D\times S\times B\times P \]

其中：

\(L\)：Layer 數。
\(H_{\mathrm{KV}}\)：KV head 數。
\(D\)：每個 Head dimension。
\(S\)：Context／Sequence length。
\(B\)：Batch 或同時存在的 Sequences。
\(P\)：KV cache precision 對應的 bytes。

模型實作還需計入 Key 與 Value 兩份狀態，但重點是：

Context length ↑
→ KV cache ↑

Concurrency ↑
→ 多個 Sequence 的 KV cache ↑

KV cache 主要屬於 Attention path，不會因為 MoE 只選少數 FFN Experts，就自動按 Active Parameters 比例縮小。

九、模型檔案大小不是完整執行需求¶

模型檔案主要包含：

Quantized weights。
Tensor metadata。
Tokenizer／模型 metadata。

執行時還可能配置：

Weights
+ KV cache
+ Activations
+ Compute buffers
+ Runtime workspace
+ Backend overhead

因此：

模型檔案 10 GB
≠
12 GB VRAM 一定能完整執行

同一模型也可能出現：

4K Context：可執行
32K Context：VRAM 不足

原因不是權重變大，而是 KV cache 與 Runtime 配置增加。

十、12 GB VRAM 的判斷流程¶

第一步：確認 Total 與 Active Parameters¶

不要只看名稱中的 Active parameter 數字。找到：

Total Parameters。
Active Parameters。
每個 Token 選擇的 Experts 數量。

第二步：確認實際 Quantization 檔案¶

記錄：

GGUF／GPTQ／AWQ 等格式。
實際檔案大小。
Quantization type。
Runtime 是否原生支援該模型與 MoE 架構。

第三步：保留 Runtime 與 KV Cache 空間¶

不要把全部 12 GB VRAM 都預算給權重。先指定：

Context length。
Concurrent sequences。
KV cache precision。
Runtime buffer 需求。

第四步：決定 Offload 策略¶

確認：

多少權重常駐 GPU。
其餘權重由 CPU 執行還是動態搬運。
系統 RAM 是否足夠。
Runtime 是否支援 Expert-aware offload。

第五步：用實際任務測量¶

至少記錄：

指標	代表什麼
Load time	模型啟動與權重映射成本
TTFT	長 Prompt 的 Prefill 與排程體驗
Decode TPS	逐 Token 生成速度
Peak VRAM	權重、KV cache 與 Buffer 的合計峰值
Peak RAM	Offload 與 Memory mapping 成本
GPU utilization	GPU 是否持續工作或等待資料
CPU utilization	CPU Expert／Offload 是否成為瓶頸

模型「能載入」不等於「在目標 Context 與速度下可用」。

十一、修正原始討論中的說法¶

說法一：MoE 對顯存要求一定較高¶

修正：必須先指定比較基準。相同 Total Parameters 與量化下，權重容量大致同級；相同 Active Parameters 下，MoE 通常有更大的 Total Parameters，因此需要保存更多權重。

說法二：所有 Experts 都必須完整放在 VRAM¶

修正：Experts 可以放在 RAM、CPU 或其他 GPU。代價是可能增加資料搬運、CPU 計算或多 GPU 通訊成本。

說法三：MoE 的 KV Cache 跟總參數規模相當¶

修正：KV cache 主要由 Attention 架構、Context、Concurrency 與精度決定，不直接按 FFN Expert 總參數量成長。

說法四：Active 8B 就像執行 Dense 8B¶

修正：Active Parameters 只描述主要稀疏計算規模；Router、Expert dispatch、Memory bandwidth、Offload 與 Runtime kernel 都會影響實際速度。

說法五：只看模型檔案大小即可判斷 VRAM¶

修正：還必須加入 KV cache、Compute buffer、Activation 與 Runtime overhead。

理解確認紀錄¶

Kent 已能用自己的話說明：

權重容量主要由 Total Parameters 決定。
MoE 每個 Token 只動態選擇少數 Experts，因此 Active Parameters 與計算量較低。
Active 8B 不代表模型總大小只有 8B；未啟用 Experts 的權重仍需保存。
RAM 中的 Experts 仍可執行，但 GPU 可能大量等待權重搬運，使 RAM／PCIe 成為瓶頸。
Context 增加不會改變模型權重，但會增加 KV cache。
模型檔案通常不包含執行時動態成長的 KV cache，因此檔案大小不是完整 VRAM 需求。

來源¶

William Fedus, Barret Zoph, Noam Shazeer, “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity,” arXiv:2101.03961v3.
https://arxiv.org/abs/2101.03961v3
Albert Q. Jiang et al., “Mixtral of Experts,” arXiv:2401.04088v1.
https://arxiv.org/abs/2401.04088v1
Woosuk Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” arXiv:2309.06180v1.
https://arxiv.org/abs/2309.06180v1

來源與限制說明¶

本文由 Google Takeout 中的 MoE／Dense 問題線索，以及 Kent 與夏洛特於 2026-08-16 的逐題討論重新建構。原始 Gemini 回答只作為問題來源；其中未重新查證的特定模型名稱、發布時間、顯存數字與推薦均未納入本文。

實際記憶體與速度會依模型版本、Quantization、Runtime、GPU、CPU、RAM、PCIe、Context 與 Batch 改變。文章中的 32B／64B／8B 與容量數字是用於解釋比例的假想案例，不是特定模型的保證值。