最近更新的比較少，因為一直在打街霸6的天梯，我已經沖到鉆石了，離大師一步之遙。

然而...今天又被人問了MOE和dense到底區別在哪，但是他說的很多理解是完全錯的。其實我以前講過，但是可能沒那么細，所以我今天仔細澄清一下大家理解的誤區。

如果隨便答，其實什么推理省顯存，簡單的道理，因為activation 少了么，原來要激活整個MLP，現在激活的幾個expert之類的云答案，這種很好找的。

那么問題來了，激活experts（一般需要*N）就比你dense模型激活少么？

首先MOE的experts和dense的 MLP是什么關系？

估計大部分兄弟隨口一云，就會說per_expert_dim * expert_num= MLP

這對么？

看起來好像對的答案，其實是經不起推敲的。

我們知道transformer的layer的架構排布是下面這樣的。

圖片

因為我們為了簡單就用標準的causal LLM也就是右邊的這個來講。

首先MH attention 層要經過qkv矩陣之后算注意力然后由liner o 也就是output會產生出來送給MLP層的tensor，這個東西對mlp層計算的dim（維度）是和mlp層的input layer是相同的。

那就變了MOE就能不同？

想象都知道不可能得事嗎，維度不一樣，你怎么矩陣計算呢？

所以這個在互聯網上普及的看似正確的答案就是個純扯淡的意淫流答案。

那實際是怎么樣的呢？

我們分兩個思路來看

第一，假設你原有一個模型，你就想給它升級MOE

那你升級哪呢？

升級MLP么，對吧，基于我剛才講的，liner o出來的維度要和mlp維度等價，所以你如果有8個experts，就是相當于給你的整個MLP層擴大了8倍參數。

這么做的話呢，首先可以肯定的是，如果你會訓練，知道怎么穩定MOE梯度之類的操作，那么效果自然是好的，因為擴參數，想都不用想。

但是，你省資源了嗎？

那必然是沒省，因為你整個參數擴大了，對于transformer模型來講最大頭的參數肯定是MLP，也就是你放大了幾倍的參數，weight顯存，你占定了，同樣的激活，原來我激活一個mlp，哪怕你是最簡單的8 experts only激活2個，那也是2倍一樣的激活顯存，這個不管訓練還是推理，你都要投入對應的顯存容量來fulfill。

所以這個和你初始的要求不太一樣啊！

所以第二個思路，我重做一個，重頭design。

我們以qwen的32b和qwen 30B A3B來做一個對比。

圖片

這倆模型差不多大，對于weight顯存的占用肯定是差不多了。

那么我們現在來分析左邊的dense 32B 和右邊的MOE 30B-A3B的區別。

一、誰變了、變到哪

• 層數 L
  dense: num_hidden_layers=64
  MoE: num_hidden_layers=48
  MoE 版顯著減少了層數。因為在總參受限了，就30B左右，所以FFN（MLP）大點，地方就那么大，那前面attention層就要受擠壓，MoE 會讓骨干深度變淺，把參數預算讓給 experts。
• 模型隱維 d_model 與注意力dense: hidden_size=5120, num_attention_heads=64, head_dim=128（由圖左側 head_dim=128 可見）MoE: hidden_size=2048, num_attention_heads=32, head_dim=128MoE 版把 d_model 從 5120 降到 2048；注意力頭數也從 64 降到 32，但單頭寬度 head_dim 仍是 128。這意味著注意力與殘差主干被整體“瘦身”了，剛才把attention的層干淺了，這次把整個模型的dim寬度也干窄了，進一步為了維持30B左右的參數，繼續砍。?
• FFN/MLP 中間維（dense 的 intermediate_size）dense: intermediate_size=25600（≈5× d_model=5120）MoE: intermediate_size=6144（這是 MoE 層里每個 expert 的中間維度 d_ff_expert；≈3× d_model=2048）。關鍵點：MoE 不是把 dense 的中間維切片，而是每個 expert 自己一套、但更“瘦”。這里清楚顯示了業界常用策略：保持輸入輸出維為 d_model，降低專家的中間寬度來控參控算。當然有人也會杠，那為什么沒有人在liner o，也就是proj o 后面加一個降為的liner來和mlp的expert對齊，這個問題我不回答，大家自己琢磨琢磨，留個彩蛋，當然你想明白這個問題就自然會心一笑。
• MoE 相關字段"moe_intermediate_size": 768（圖右存在該字段，通常用于門控/共享投影等 MoE 內部維度，具體實現依賴庫）"num_experts": 128"num_experts_per_tok": 3（就是 top-k=3）還有 router/負載均衡的若干超參（如 router_aux_loss_coeff 等）這是一個較大 N 的 MoE（128 個專家），每個 token 激活 3 個。從訓練的角度這個確實省激活，其實推理就還好。別看好像省了125個experts，但是對于推理來講，它不是訓練，不用考慮反向。這種沒那么大的模型，activation的顯存能省，但是省不了你們想那么多，除非你input的seq特別長，batch太大。
• KV headsdense: num_key_value_heads=64（與總頭數一致）
  MoE: num_key_value_heads=4（顯著更少，采用 GQA：少量 KV 頭共享給多查詢頭）
  這進一步壓縮了注意力狀態與推理緩存（KV cache），降低顯存與帶寬壓力。

二、從這些變化得出的結論

• MoE 版把“共享、每 token 必算”的主干（d_model、注意力頭數、層數）都縮小了；把參數預算轉移到“稀疏激活”的專家集合上。在總參固定下，MoE 也沒有超能力，所以只能讓注意力/層數變小或變淺。
• 每個 expert 的中間維度被降了：dense 的 25600（≈5×5120）對比 MoE 每 expert 的 6144（≈3×2048），其實單個的mlp（一個expert）的表達能力是被降低了，我們知道mlp層的核心訴求就是需求隱空間的語義信息，那降低了怎么辦？用多experts來承載多樣性。
• 同時引入 GQA（num_key_value_heads 遠小于總頭數）來進一步節約注意力側的參數與 KV cache，適配大 N、top?k 的 MoE 設計，保障吞吐和顯存可行。

三、對訓練/推理與效果的含義

• 訓練/推理 FLOPs
  每 token 的 MoE 計算量主要隨 k=3 與 d_ff_expert=6144 走；N=128 對單 token FLOPs 影響不大（更多影響參數量與路由）。
  注意力側因 d_model 變小、頭數變少、GQA 化，計算與 KV cache 顯著下降，有利于吞吐。
• 表達力與路由
  雖然單個 expert 比 dense 的 FFN 更瘦，但有 128 個專家且 top?3 激活，整體表達多樣性提升；負載均衡和路由質量變得關鍵。
• 長上下文與注意力質量
  d_model 與頭數變小對注意力分辨率不利，但通過層數/專家多樣性、訓練策略與數據規模可以部分補償。具體效果要看實際評測。這個也是moe的一個弱點（同等參數下），當然如果你能給upset做到671B又做到1T，那當我沒說

四、可復制的設計要點（如果你要做同類改型）

• 保持子層輸入/輸出維一致為 d_model（方便殘差與實現），把“瘦身”放在 expert 的中間維 d_ff_expert。
• 通過減少 L、d_model、注意力頭數和使用 GQA 來為 MoE 挪參數預算。
• 選擇合適的 N 與 k，常見 k=1–2；這里采用 k=3，配合更強的路由/均衡與較瘦的 expert。
• 關注 router 正則（如 router_aux_loss_coeff）與 capacity 設置，保證均衡與穩定訓練。

好，那么我們總結一下！

看這兩個模型config.json的配置，并對比，非常清晰地展示了標準業界的 MoE 的典型取舍：在總參相近時，MoE 模型顯著縮小了主干（d_model、層數、注意力頭/GQA），并把 FFN 從 dense 的單路大寬度，改成多專家的中等寬度；每個 expert 的維度被刻意降了，以換取“多專家 + 稀疏激活”的表達力與性價比。

本文轉載自??熵減AI??，作者：周博洋