部署混合專家模型

混合專家（MoE）模型會把部分密集前饋子層（feed-forward sublayer）換成多個專家前饋網路，並加入經過訓練的路由器（router）。每個 token 只會啟用部分路由專家（routed expert），共享層（有些模型還包括共享專家）則仍會處理每個 token。稀疏啟用因此把儲存的總參數量與單一 token 啟用的參數量區分開來。

模型架構並不決定唯一的部署方式。專家可以用張量平行切分、整個分配給專家平行（EP）的 rank，或直接複製；每種做法都能再搭配注意力層的資料平行或張量平行，以及管線平行或上下文平行。最佳配置取決於精度、並行量、批次形狀、集體通訊、拓撲與專家偏斜。

A 層：MoE 模型

專家是前饋路徑，不是完整模型

在常見的 Transformer MoE 區塊中，注意力仍是共享子層，密集前饋網路則換成 N 個專家前饋網路。路由器替每個 token 評分，並啟用 k 個路由專家。有些架構另有一或多個永遠啟用的共享專家，或讓密集區塊與 MoE 區塊交替出現。

稀疏閘控（sparsely gated）MoE 層的出現早於現代 LLM 推論服務（Shazeer et al., 2017）。Switch Transformers 後來示範了 top-1 路由，並回報在相同運算資源下，預訓練達到 T5 基準模型品質的速度最高快 7 倍。這是訓練結果，不是推論服務的延遲結果（Fedus, Zoph, and Shazeer, 2022）。

總參數量與啟用參數量

Mixtral 8×7B 有 46.7B 總參數、12.9B 啟用參數，每個 MoE 層有八個專家，採 top-2 路由。這些參數量出自 Mistral 發布說明。啟用參數量只能粗略代表運算量；延遲仍取決於權重存取、硬體利用率、分派與通訊。架構與路由分析見技術報告。

DeepSeek-V3 有 671B 總參數、37B 啟用參數；每個 MoE 層有 256 個路由專家加上一個共享專家，每個 token 選用八個路由專家（DeepSeek-V3 Technical Report）。說它「運算起來就像 37B 的密集模型」言過其實：成本仍包含注意力與共享層、專家分派、grouped GEMM、負載失衡與通訊。

路由函數因模型而異

教科書式的路由器會計算線性分數、套用 softmax、選出 top-k 個專家，再求加權總和。DeepSeek-V3 證明這套做法並不通用：它用 sigmoid 計算親和度分數，只在挑選 top-k 專家時加上負載平衡用的偏差項，再把選中專家的原始分數（未加偏差項）正規化，作為閘控值。路由細節要依據各模型自己的架構，不能套用通用示意圖（DeepSeek-V3 Technical Report）。

專家的專精方向也不保證對得上「旅行」或「數學」這類人類標籤。Mixtral 的路由分析只看到有限的主題專精，以及一些語法與位置上的模式。

B 層：部署策略

完整副本

完整的 MoE 模型若能以支援的精度放得下，而且就目標工作負載而言，彼此獨立的副本比通訊密集的分片配置有更高的請求吞吐量，就可以直接複製。每個副本都要存放全部權重和自己的 KV 容量，但一般推論不需要跨副本的集體通訊。「複製不適用於 MoE」這個說法是錯的；複製是記憶體與效能之間的取捨。

張量平行專家

每個專家的矩陣都可以切分到多個 TP rank。每個 rank 持有所有專家的一部分，再透過 TP 集體通訊合併部分輸出。路由目的地因此留在 TP 群組內，但 activation 的部分結果必須在群組內反覆傳遞。

專家平行

專家平行把完整的路由專家分配給各個 EP rank。每個 token 的 activation 會分派到持有其選定專家的 rank，結果再傳回來合併。概念上是先分派、再合併，但引擎實作時可能用 all-to-all、all-gather 加 reduce-scatter、all-reduce，或融合式點對點運算核心（fused point-to-point kernel）。

GShard 奠定了大規模條件式運算（conditional computation）的分片做法；DeepSpeed-MoE 則為大型專家模型發展出訓練與推論技術（Lepikhin et al., 2020；Rajbhandari et al., 2022）。這兩項成果都不代表某個 EP 平行度在現今硬體上就是最佳選擇。

注意力層 DP/TP 搭配 EP

常見的「複製注意力、切分專家」只是一種配置，不是定律。目前 vLLM 的行為取決於 TP 與 DP：TP=1 時，注意力權重會複製到所有 DP rank；TP>1 時，注意力會在每個 DP 群組內的各 TP rank 之間以張量平行切分。兩種情況下，專家都分布在同一個大小為 EP = TP × DP 的 EP 群組（vLLM Expert Parallel Deployment）。

注意力權重複製到多個 rank，不代表每個 token 都會經過每一份副本。不同 DP rank 通常用相同權重處理不同的請求與 token 分區。共用同一個 EP 群組的 DP rank 會透過專家運算彼此綁定，因此它們既不是獨立的完整模型副本，也不是獨立的失效域。

單一 MoE 區塊的集體通訊流程

在常見的「注意力層 DP、專家層 EP」設計下，一批 token 的流程如下：

local tokens
  -> local shared attention
  -> router scores and top-k selection
  -> dispatch selected token activations to expert owners
  -> grouped expert GEMMs
  -> combine/return expert outputs
  -> weighted expert sum + residual

若 B 個 token 均勻路由到 N 個專家中的 k 個，每個專家的平均分配數為：

expected assignments per expert = B × k / N

均勻情況下的平均值只是期望值，不是保證。熱門專家可能造成落後者（straggler）、拉長尾端延遲，並讓其他 rank 閒置；實際影響取決於專家配置、執行容量與重疊程度。專家平行負載平衡（expert-parallel load balancing，EPLB）、熱門專家的冗餘副本、容量策略，以及訓練階段的負載平衡，各自處理問題的不同面向。

容量檢查失敗：單張 80 GiB GPU 上的 BF16 Mixtral

只計權重的需求為：

BF16 bytes = 46.7 billion × 2
           = 93.4 billion bytes

BF16 GiB   = 93,400,000,000 / 2^30
           = 86.99 GiB

光是權重就超過 80 GiB，還沒算 KV 快取、activation、記憶體配置器（allocator）狀態與執行期緩衝區，因此 BF16 權重不可能全部常駐在這張 GPU 上。權重卸載（weight offloading）是另一種設計，有自己的傳輸與延遲成本。

理想化、每個權重只占一個位元組的檢查點（checkpoint）為：

FP8 weight GiB = 46,700,000,000 / 2^30 = 43.49 GiB

在明確宣告執行期與 KV 預留量的前提下，這可能放得下；但量化中繼資料的實際大小、運算核心支援、輸出品質，以及是否支援該檢查點格式，都必須另外驗證。BF16 放不下，並不證明一定需要專家平行：TP2、記憶體更大的 GPU，或受支援的低精度副本，都是替代方案。

完整範例：透明的假設性 MoE

這個刻意簡化的參數計算範例，讓每個配置數字都能自行推導。把八個專家視為大小相同、跨越所有已建模 MoE 層的參數組；分派量則只計算一層。真實架構必須逐層加總專家與共享參數。這裡的「啟用參數」是名目上的路徑參數量，不是精確的 FLOPs 或記憶體流量；例如 embedding 查表時，並不會為每個 token 讀取全部 embedding 權重：

假設採用 BF16 權重、EP8，並在每張 GPU 預留 20 GiB 給 KV 與執行期。每個 EP rank 都持有全部 8B 共享參數，外加一個 8B 專家：

per-rank parameters = 8B + 8B = 16B
per-rank BF16 GiB   = 16,000,000,000 × 2 / 2^30
                    = 29.80 GiB
with reserve        = 29.80 + 20
                    = 49.80 GiB < 80 GiB

256 個路由 token、top-2、八個專家時：

mean assignments/expert = 256 × 2 / 8 = 64

若某個 rank 一開始有 32 個 token，隱藏維度為 4,096，activation 採 BF16，並使用 top-2：

logical dispatch bytes/rank = 32 × 2 × 4,096 × 2
                            = 524,288 bytes
                            = 0.5 MiB

部分選定專家就在本地 rank 上，最佳化的運算核心也可能合併訊息，所以 0.5 MiB 是尚未計入路由局部性與協定開銷的邏輯 activation 量，不是實際量測到的傳輸流量。

建立配置計算器

存為 model_moe_placement.py：

import json

GIB = 2**30
GPU_GIB = 80
RESERVE_GIB = 20

mixtral_total_parameters = 46_700_000_000
mixtral_bf16_gib = mixtral_total_parameters * 2 / GIB
mixtral_fp8_gib = mixtral_total_parameters * 1 / GIB

shared_parameters = 8_000_000_000
experts = 8
expert_parameters_each = 8_000_000_000
top_k = 2
ep_size = 8
if not 1 <= top_k <= experts:
    raise ValueError("top_k must be between 1 and experts")
if ep_size <= 0 or experts % ep_size:
    raise ValueError("this equal-placement fixture requires experts divisible by ep_size")

total_parameters = shared_parameters + experts * expert_parameters_each
active_parameters = shared_parameters + top_k * expert_parameters_each
experts_per_rank = experts // ep_size
parameters_per_ep_rank = shared_parameters + experts_per_rank * expert_parameters_each
weight_gib_per_ep_rank = parameters_per_ep_rank * 2 / GIB

batch_tokens = 256
expected_assignments_per_expert = batch_tokens * top_k / experts
if batch_tokens % ep_size:
    raise ValueError("this even-token fixture requires batch_tokens divisible by ep_size")
local_tokens = batch_tokens // ep_size
hidden_size = 4096
activation_bytes = 2
logical_dispatch_bytes_per_rank = local_tokens * top_k * hidden_size * activation_bytes

artifact = {
    "mixtral_fit_check": {
        "total_parameters": mixtral_total_parameters,
        "bf16_weight_gib": mixtral_bf16_gib,
        "fp8_weight_gib_idealized": mixtral_fp8_gib,
        "bf16_fits_80gib_before_overhead": mixtral_bf16_gib <= GPU_GIB,
        "reserve_gib": RESERVE_GIB,
        "fp8_fits_with_reserve": mixtral_fp8_gib + RESERVE_GIB <= GPU_GIB,
    },
    "hypothetical_ep_model": {
        "total_parameters": total_parameters,
        "active_parameters_per_token": active_parameters,
        "experts_per_rank": experts_per_rank,
        "bf16_weight_gib_per_rank": weight_gib_per_ep_rank,
        "bf16_weight_plus_reserve_gib": weight_gib_per_ep_rank + RESERVE_GIB,
        "expected_assignments_per_expert": expected_assignments_per_expert,
        "logical_dispatch_bytes_per_rank": logical_dispatch_bytes_per_rank,
    },
}
serialized = json.dumps(artifact, indent=2)
with open("moe-placement.json", "w", encoding="utf-8") as handle:
    handle.write(serialized + "\n")
print(serialized)

預期檢查結果：

Mixtral BF16 weight ≈ 86.99 GiB, single-80-GiB fit=false
Mixtral idealized FP8 weight ≈ 43.49 GiB, fit with 20-GiB reserve=true
hypothetical total=72B, active=24B
EP8 experts/rank=1
BF16 weight/rank ≈ 29.80 GiB
weight+reserve ≈ 49.80 GiB
expected assignments/expert=64
logical dispatch/rank=524288 bytes

標註查核日期的開放模型概況

下表選列的已發布架構，已於 2026-11-02 對照第一方來源查核；這張表不是完整清單，也不是效能排名。專家數量指每個 MoE 層或區塊，參數量則指整個模型：

這張表列出幾個已公開的 MoE 應用實例。選定的樣本無法說明 MoE 有多普遍，也無法揭露所有前沿架構；專有模型的架構，除非開發者證實，否則應視為未知。

刻意破壞的案例

單張 80 GiB GPU 上的 BF16 Mixtral

光是權重就需要 86.99 GiB，還沒計入任何執行期記憶體就已失敗。縮小批次或分頁管理 KV 快取，都無法讓 BF16 權重全部放進 GPU 記憶體；權重卸載會改變常駐假設，必須另外做基準測試。

把「複製注意力、切分專家」當成通則

強制複製注意力的計畫，忽略了 TP 群組、上下文平行與引擎行為。目前 vLLM 可以在專家橫跨 TP×DP 的同時，以張量平行切分注意力；計畫必須寫明這兩種群組結構。

假設 All-to-All 永遠最好

AMD 的 vLLM MoE playbook 指出，交叉點取決於硬體與工作負載：在其測試路徑中，DP+EP 以 all-to-all 通訊，TP+EP 則只使用 all-reduce；在那套 MI300X 環境中，極度稀疏的 Llama 4 Maverick 不開 EP 旗標，效能反而比開啟時高 7% 至 12%（AMD ROCm MoE playbook）。這項由供應商在 2025 年 11 月 24 日發布的測試，使用 Llama-4-Maverick-17B-128E-Instruct-FP8、8 張 MI300X、每筆請求 8,192 個輸入 token 與 1,024 個輸出 token、640 筆請求、啟用 AITER、vLLM 0.11.1rc3.dev69+g269c4db0a 與 ROCm 7.0.51831。文中沒有說明快取是否已暖機。請把這個結果視為特定條件下由供應商回報的比較，而不是經獨立重現的增益，也不是通用門檻。

忽略專家偏斜

若某個專家收到 160 次分配，而均勻情況下的平均值是 64，在各 rank 的專家執行容量相近時，該專家所在的 rank 可能成為落後者。平均啟用參數量看不出這種尾端效應。

動手實作

1. 分別以 12 GiB 與 24 GiB 的預留量，重算 Mixtral BF16／FP8 的容量檢查。

2. 把假設性模型從 EP8 改成 EP4，計算每個 rank 的專家數，以及權重加預留量的 GiB。

3. 先改回 EP8，再針對 256 個 token 比較 top-1、top-2、top-4 路由，計算每個專家的平均分配數與邏輯分派位元組數。

4. 建立總和等於 256 × top_k 的偏斜分配向量，回報最大值與平均值之比，以及超載的 rank。

5. 在八張 GPU 上畫出 TP2×DP4 的注意力群組，以及 EP8 的專家歸屬。

6. 做部署決策之前，在相同硬體與工作負載上，至少對一個偏重 TP 的配置與一個 DP+EP 配置做基準測試。沒有 GPU 可用時，先完成計算器與基準測試計畫，並把部署選擇標為「待量測」。

假設性模型在 EP4 下的預期記憶體：

experts/rank = 8 / 4 = 2
parameters/rank = 8B shared + 2×8B experts = 24B
BF16 weight/rank = 24B × 2 / 2^30 ≈ 44.70 GiB
weight + 20 GiB reserve ≈ 64.70 GiB

在 EP8 下，top-1／top-2／top-4 的每個專家平均分配數分別是 32／64／128，每個 rank 的邏輯分派位元組數分別是 262,144／524,288／1,048,576。在 EP4 下平分 256 個 token，每個 rank 一開始各有 64 個 token。Top-2 的偏斜範例 [160, 64, 64, 64, 48, 40, 40, 32] 總和為 512，最大值與平均值之比為 2.5；每個 rank 一個專家時，rank 0 的分配數最多。TP2×DP4 的注意力群組是 {0,1}、{2,3}、{4,5}、{6,7}，EP 群組則涵蓋 {0,…,7}。這些都是教學範例的計算，不是實測延遲。

可量測的完成標準

符合以下所有條件，本教學才算通過：

• 把 MoE 模型內部的路由與部署層的請求路由當成兩個不同的概念；

• 路由函數依模型而定，並納入 DeepSeek 的 sigmoid 閘控作為反例；

• Mixtral BF16 只計權重的記憶體約為 86.99 GiB，並在單張 80 GiB GPU 上遭到否決；

• 從不把總參數量或啟用參數量當成完整的記憶體或延遲代理指標；

• 注意力層要複製還是切分，由 TP／DP 群組推導；

• 集體通訊的選擇取決於引擎、拓撲、訊息大小與工作負載；

• 假設性 EP8 的計算得出每個 rank 29.80 GiB 權重，加上預留量為 49.80 GiB；

• 失效分析納入專家分配偏斜；以及

• 所有模型概況的陳述都標註查核日期，並經第一方來源確認。

提取練習

1. MoE 的總參數量與啟用參數量有何不同？

2. 為什麼 softmax top-k 不能用來描述所有路由器？

3. 完整複製 MoE 模型有可能是正確選擇嗎？

4. 為什麼注意力權重有副本，不代表每個 token 都會經過每個副本？

5. 專家平行分散了記憶體，換來的代價是什麼？

6. 為什麼均勻情況下的「每個專家平均分配數」公式，不能保證延遲平衡？

解答

1. 總參數量決定需要儲存的全部權重；啟用參數量計算的是單一 token 會用到的共享與選定路徑。

2. DeepSeek-V3 使用 sigmoid 親和度、加上偏差項的專家選擇，以及選定分數的正規化；其他模型也各有不同設計。

3. 可以，前提是檢查點加上執行期與 KV 放得下，而且就目標工作負載而言，獨立副本的表現優於通訊密集的分片配置。

4. DP rank 通常用相同權重處理不同的請求與 token 分區；除非另一個平行維度搬動它，token 會留在所屬的副本或群組內。

5. 它降低並重新分配每個 rank 的專家權重記憶體，也把各 rank 的記憶體頻寬加總起來，但會增加分派／合併通訊與負載失衡的風險。

6. 經過訓練的路由取決於資料；熱門專家收到的分配可能遠高於平均值，成為落後者。

本文不涵蓋的內容

本篇假設你已具備 I-06 的密集模型平行化基礎。I-07 提供在候選 MoE 配置之間做選擇所需的基準測試、SLO、可觀測性與失效分析方法。訓練階段的路由器損失函數，只在影響部署行為時才會提到。

來源與延伸閱讀

• Shazeer, N., Mirhoseini, A., Maziarz, K., et al. "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer." ICLR, 2017。稀疏閘控 MoE 的奠基來源。arxiv.org/abs/1701.06538

• Fedus, W., Zoph, B., and Shazeer, N. "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity." JMLR, 2022。top-1 路由與限定範圍之預訓練速度結果的第一手來源。arxiv.org/abs/2101.03961

• Lepikhin, D., Lee, H., Xu, Y., et al. "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding." 2020。條件式運算分片的第一手來源。arxiv.org/abs/2006.16668

• Rajbhandari, S., Li, C., Yao, Z., et al. "DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale." ICML, 2022。專家模型推論與分片的第一手來源。arxiv.org/abs/2201.05596

• Jiang, A. Q., Sablayrolles, A., Roux, A., et al. "Mixtral of Experts." 2024。Mixtral 架構、參數量、路由與利用率注意事項的第一手來源。arxiv.org/abs/2401.04088

• DeepSeek-AI. "DeepSeek-V3 Technical Report." 2024。671B/37B 架構、sigmoid 路由、負載平衡與部署的第一手來源。arxiv.org/abs/2412.19437

• vLLM Project. "Expert Parallel Deployment." 現行文件，查閱日期 2026-11-02。現行 TP/DP/EP 注意力與專家配置行為的第一方說明。docs.vllm.ai

• AMD ROCm. "The vLLM MoE Playbook: A Practical Guide to TP, DP, PP and Expert Parallelism." 2025-11。特定硬體的供應商基準測試，保留作為有條件成立的部署證據。rocm.blogs.amd.com