DeepSeek悄悄更新：Mega MoE、FP4 Indexer來了

機器之心編輯部

昨天下午，沉寂許久的 DeepSeek 又有新動作了！

不過正如 DeepSeek 自己在 PR 中強調的，和模型沒關系，更新了一下 DeepGEMM 代碼庫。

不過，此次更新，我們看到了一個新東西：Mega MoE

鏈接：https://github.com/deepseek-ai/DeepGEMM/pull/304

Mega MoE 項目貢獻者來自 DeepSeek 基礎設施團隊的 Chenggang Zhao 等人。

Mega MoE 是什么？

如何理解 Mega MoE？先來看看 X 網友思維怪怪的解讀：

來源：https://x.com/0xLogicrw/status/2044720884066451645

簡單來說，Mega MoE 干的事情是把原本支離破碎的一整套 MoE 計算流程，揉成了一坨，一次性在 GPU 上跑完

過去的 MoE，有點像一個被拆成很多工位的流水線。token 先被分發（dispatch）到不同專家，然后做一層線性變換，再過激活函數（SwiGLU），再來一層線性，最后再把結果拼回去。聽起來沒問題，但現實是，每一步都要單獨起一個 kernel，中間還夾雜著 GPU 之間的數據通信。

于是你會看到一種很典型的低效：算一會兒，等一會兒；傳一會兒，再算一會兒。

Mega MoE 想做的是把這條流水線直接焊死：它把 dispatch、兩層線性、SwiGLU、combine 這些步驟全部 fuse 到一個 mega-kernel 里。更關鍵的是，它不只是「合并步驟」，還在做一件更狠的事情：讓數據通信和計算同時發生

也就是說，一邊在 Tensor Core 上算，一邊在 NVLink 上傳，不再是你等我、我等你。

此做法的影響很直接：GPU 不再頻繁停頓，利用率更高，尤其是在多卡、大規模 MoE 場景下，這種優化能被直接感受到。有點像把原來一群人在接力搬磚，變成了一臺連續運轉的傳送帶。

當然，DeepSeek 這次也沒打算只做一個「更快的 kernel」。你能明顯感覺到，他們是在往一個方向死磕：把 MoE 的效率壓到極限

比如他們開始嘗試 FP8 × FP4 這樣的組合精度，還搞了一個 FP4 的 indexer，用在 MQA logits 上。這種操作基本是在逼近「還能不能再省一點算力」的邊界。再加上一些 GEMM 的重構、JIT 編譯加速，似乎是想要把 DeepSeek 的 AI 打磨得更加強勁。

還有一個細節挺有意思：他們明確說，Mega MoE 還在開發中，性能數據「之后再說」。看起來，這種級別的優化，往往不是一版代碼就能定型的，而是要在不同規模、不同拓撲、不同 workload 下反復調。現在放出來，更像是在給社區一個信號：方向已經定了，我們開始往這條路狂奔了。

在此基礎上，DeepSeek 也對 DeepGEMM 的描述進行了一些調整：

DeepGEMM 是一個統一的高性能 Tensor Core 內核庫，將現代大語言模型的關鍵計算原語整合在一起，包括 GEMM（FP8、FP4、BF16）、具備通信重疊的融合 MoE（Mega MoE）、用于 lightning indexer 的 MQA 打分、HyperConnection（HC）等，全部匯聚到一個統一且一致的 CUDA 代碼庫中。所有內核通過一個輕量級的即時編譯（JIT）模塊在運行時編譯，安裝過程中無需進行 CUDA 編譯。

所以如果一定要給這次更新一個定位，大概可以這么說：這是一次基礎設施層的重構嘗試。DeepSeek 正在把 MoE 從一種「理論上很美好，但工程上很折騰」的架構，往「可以被大規模、高效率跑起來」的方向推進。

而 Mega MoE，很可能只是第一塊拼圖；就是不知道這塊拼圖是不是 DeepSeek-V4 的一部分？

根據 X 網友 St4r 的解讀，這也可能暗示了 DeepSeek 所使用的訓練卡還是包含了英偉達 AI 加速卡，還是最新、最頂級的 B 系列（而非幾個月以來一直傳言的，使用國產 AI 訓練卡）。