MoE 與 Dense——到底差在哪裏？

摘要（TL;DR）。 Dense 模型大致用整套參數去寫每一個 token。 Mixture-of-Experts（MoE） 可以宣傳很大的總「B」，卻只叫醒一部分專科網絡。 這正是兩個標題體型相近的模型，在成本、延遲與硬件需求上可以差很遠的原因。 先問清楚總體型與啟動體型——再用你的工作去測。

白話說 Dense

可以把 Dense 想成一支每次都全員到場的團隊。

模型寫下一個字時，那數十億參數大多會一齊出手。簡報上的「70B」因此大致反映 回答時做了多少功（通常也反映服務成本）。

接續姊妹篇：那個 B 是容量，不是智商。Dense 與 MoE 談的是容量怎樣接線， 不是誰比較「高級」。

白話說 MoE

Mixture-of-Experts 比較像一間有很多專科醫生、再加分流櫃檯的醫院。

• 大樓裏有龐大的總人力（總參數——標題上的 B）。
• 每位病人（每個 token），分流只叫少數專科（啟動專家／啟動參數）。
• 其餘專家待命，但不為每個個案全體 scrub in。

因此模型可以誠實地說「萬億級參數」，同時每個 token 只跑小得多的啟動集合。 標題 B 仍然真實——那是你要常駐的專家庫——但不是「每次全部開火」。

認真的規格卡有時會同時寫兩個數字：例如總體型 vs 每個 token 的啟動體型。 寧可看這種誠實，也不要單一吹噓數字。

為什麼買家要在意

問題	Dense（粗略）	MoE（粗略）
大大的「B」代表什麼？	接近每個 token 實際運行的量	往往是總專家數——啟動工作量可以更小
回答成本	隨整套堆疊上升	啟動 FLOPs 可能較低——但權重仍可能很吃顯存
運維感覺	心智模型較簡單	多了路由；服務大型稀疏模型需要真功夫
簡報風險	用體型誇大智商	用「超大 B」卻不說啟動了多少

實務上可以這樣問：

1. 總 vs 啟動——有沒有同時公佈？每個 token 啟動多少？
2. 顯存 vs 算力——即使只有少數專家開火，是否仍要足夠 GPU 記憶體裝下全部權重？
3. 延遲——路由與專家跳轉，對我們的回應時間預算是幫還是礙？
4. 我們的工作——用我們的文件與流程做短評測。架構標籤不能取代這一點。

2026 年中，稀疏 MoE 設計在開源／開放權重頭條很吵（很大的總參數量、稀疏專家啟動）。 把新聞當成問更好問題的提示——不是跳過評估的理由。

下次見到 MoE 簡報時，可以這樣讀

試在會議室說這句：

「總體型有意思。請告訴我每個 token 的啟動參數量、上線需要什麼硬件，以及在我們任務上的分數。」

這三點答得清楚，MoE 與 Dense 就變成有用的工程背景。答得含糊，更大的總 B 多半 只是行銷油漆——跟把任何「B」當成智商徽章是同一類陷阱。

這與我們做的事有什麼關係

在 AiHPC，我們更在意在管治之下、切合用途的模型，而不是贏得架構時尚競賽。 OrchAI 讓機構在自己的文件與流程上使用 AI——帶出處引用、可控與評估——底層是 Dense 還是 MoE 都可以。接線方式是旋鈕；信任層才是產品。

想看看實務上長怎樣？與我們聯絡 或 試用演示。

常見問題

什麼是 Dense 模型？ 粗略來說，產生下一個 token 時幾乎整套參數都會參與。標題 B 可大致反映運行工作量。

MoE 是什麼意思？ Mixture-of-Experts：許多專科子網絡，路由器為每個 token 只叫醒少數幾個。總「B」可以 遠大於啟動「B」。

MoE 一定更便宜或更好嗎？ 不一定。相對同樣總體型，它可能降低啟動算力，但顯存、路由與運維仍有成本。請用你的 任務、延遲與托管約束來判斷。