Cursor 的 MoK 在 NVIDIA GB300 NVL72 上實現 2.37 倍效能提升

Cursor 開源 MoK，將 token 調度、跨 GPU 通信和專家計算整合至同一 GPU 核心中。該方案在 GB300 NVL72 上實現 MXFP8 前向最高 2.37 倍、反向 1.78 倍的性能提升，512 張 GB300 GPU 訓練吞吐量提升 41% 至 1070.2 tokens/s。信號延遲從 103 μs 降至 18 μs。分析指出，在 NVLink 帶寬已達 130 TB/s 的今天，GPU 等待數據的時間成為新的性能瓶頸，這一突破標誌著 AI 競爭進入「全棧主權」階段，代碼離顯存和寄存器越近的公司將擁有更大的定價權。

文章作者、來源：雷峰網

7月21日，NVIDIA 公布了 GB300 NVL72 訓練 DeepSeek-V3 的最新成績：在 256 張 GPU 上，單卡性能達到 1,648 TFLOPS。

不到兩週後，Cursor 開源了 Mixture-of-Kittens，簡稱 MoK。它沒有繼續優化更快的矩陣乘法，而是直接重寫了 MoE 的執行方式，將 token 調度、跨 GPU 通信和專家計算整合到同一個 GPU 核心中。

這件事有點反直覺。因為 GB300 NVL72 已經將 72 張 GPU 放入同一個 NVLink 域，整個機架的 NVLink 總頻寬達到 130 TB/s。按這個規格來看，GPU 之間傳輸數據應該已經足夠快。

在大規模 MoE 訓練中，通信仍會拖慢專家計算。

問題出現在 MoE 的數據流。Router 在每一步都會重新決定 token 去哪個專家，而專家分散在不同的 GPU 上。token 必須先跨卡傳送過去，計算完畢後再傳回；傳送前還需整理位置，到達後還需等待數據完整。隨著 MXFP8 和 Blackwell Tensor Core 將專家計算時間壓得越來越短，這些原本能隱藏在計算背後的等待時間開始變得越來越明顯。

Cursor 做 MoK，就是從這裡下手。它沒有只追求一次 Dispatch 能傳多快，而是重新安排 token 怎麼到達專家、什麼時候開始計算，以及通信和計算怎樣同時佔用 GPU。

在算力資源被 Blackwell 和 NVLink 堆到極致的今天，開發者發現：硬體跑得再快，也救不了低效的軟體編排。

MoK 的開源不僅是核心的勝利，更標誌著「應用層定義運算子」時代的開始：為了榨取最後 30% 的算力，AI 創業公司正在發起一場底層主權的奪權戰爭。

但要理解 Cursor 這套設計為何有效，首先得看清 MoE 到底在哪裡交了「通信稅」。

01

MoE 的「通信稅」

在普通的稠密 FFN 中，token 所經過的權重基本上是固定的。MoE 加入 Router 後，每個 token 會臨時選擇幾個專家。採用 Expert Parallel 時，專家又被拆分到多個 GPU 上，因此一次前向傳播至少要發生兩輪跨卡通信。

第一輪叫 Dispatch，將 token 傳送到專家所在的 GPU；專家計算完成後，再透過 Combine 將結果送回 token 原來的位置。訓練還包含反向傳播，對應再執行兩輪反方向的通信。

如果只是將一大塊連續數據從 A 搬到 B，NVLink 已經足夠快。MoE 的麻煩在於，Router 每一步提供的數據分佈都不同。

某位專家在這一步可能收到大量 token，下一步卻很少。系統需先統計每位專家有多少個 token，再決定這些 token 應放置於目標 GPU 的何處，並盡量將同一專家的數據排列在一起。唯有如此，Grouped GEMM 才能獲得規整的輸入，高效地供應給 Tensor Core。

通信結束後也不能立即開始計算。目標 GPU 必須確認遠端寫入已全部完成，數據確實可見。專家負載又不完全均勻，部分 GPU 可能早已結束，但仍需等待最忙碌的專家完成。

因此，在一個「通信」階段中，實際上混雜了數據搬移、佈局生成、同步和負載不均等幾件事。130 TB/s 描述的是整個機架能夠提供的峰值頻寬，並不代表每一次動態且零碎的 MoE 通信都能同時將這些鏈路跑滿。

DeepEP 已經將其數據搬運做得非常快速。它本身就是為 Expert Parallel 設計的高性能通信庫，提供專門的 Dispatch 和 Combine 核心，支援 FP8，並允許控制通信所佔用的 SM 數量。最新版本甚至能以明顯更少的 SM 保持高通信吞吐量。

可擴展 MoE 仍需在 Dispatch、Grouped GEMM 和 Combine 之間不斷交接。

這時會遇到一個很實際的矛盾：如果等到足夠多的 token 齊全再計算，矩陣會很大，Tensor Core 跑得舒服，但計算啟動得晚；如果 token 一到就計算，通信和計算能更早重疊，但矩陣又太小，GPU 的許多 SM 沒有足夠的工作量。

多個 CUDA Stream 可讓通信與計算並發，卻很難始終確保雙方都能獲得恰到好處的 GPU 資源。

The design after MoK primarily addresses this “rhythm” issue.

02

MoK 最有意思的一項改動，是將前向 Dispatch 從 Push 改為 Pull。

傳統 Push 很直觀：源 GPU 手裡有 token，就主動把它寫進目標 GPU。麻煩出在目標地址。一張 GPU 會同時收到很多其他 GPU 發來的 token。

每個發送方都必須提前知道自己應該寫入哪一段，不能互相覆蓋；同一專家的 token 最好還需連續排列，否則後面的 GEMM 又要重新整理。

隨著參與的 GPU 越來越多，這個調度過程會變得越來越繁重。Pull 採用了另一種方式：讓專家的目標 GPU 自行讀取所需的 token。它只需知道 token 位於哪張源 GPU、以及在源數據中的什麼位置，本地存儲位置則由自身安排。

這一下省去了多個發送方之間對目標地址的協調。收到的數據也可以直接按照本地專家排好。

有趣的是，Pull 並未傳輸較少的數據。在 Cursor 的微基準測試中，同一個 256×256 BF16 數據塊，Push 在 NVLink 上移動約 159.6 KB，而 Pull 反而達到 172.0 KB，因為讀取時還需額外發送請求。

Pull 的優勢在於另一點：MoE 的通信較為碎片化，且負載不均衡。NVLink 的兩個方向擁有獨立通道，Pull 能同時利用請求和數據返回兩個方向。在專家負載不均衡的測試中，Cursor 測得 NVLink 利用率最高提升 29%。

同步上的差距更明顯。Push 寫入完成後，目標 GPU 需要等待其他 GPU 的完成信號，當 Expert Parallel 規模較大時，一個 rank 最多可能涉及另外 71 個 peer。Pull 是本地 GPU 自行發起讀取，數據回來後就能直接使用。

在 Cursor 的多節點微基準中，這段 signaling 延遲從 Push 的約 103 微秒降至 Pull 的 18 微秒。

MoK 也沒有在所有地方都使用 Pull。前向使用 Pull Dispatch 和 Push Combine；反向則使用 Pull Reverse-Combine 和 Push Reverse-Dispatch。在 Dispatch 階段，需要將來自多個來源的 token 重新組織為專家輸入，Pull 更省去協調；在 Combine 時，每個結果應返回到哪個 token 已經很清楚，直接 Push 回去更簡單。

改變通信方向後，MoK 還將通信和專家計算放入同一個 Megakernel。

它將 GPU 的 SM 分成兩部分。一部分負責 Dispatch、Combine 和狀態管理，另一部分專門執行 Expert FFN。通信端在取得一批完整 token 後，透過 GPU 本地計數器通知計算端；計算完成後，再通知通信端將結果傳回。

這樣可以直接決定通信用多少 SM、計算用多少 SM，無需完全交由多個 CUDA Stream 自行競爭。這裡最關鍵的參數稱為 minibatch，也就是一次交給專家計算多少 token。

它不能太大。太大意味著第一批計算得等很久。也不能太小。專家 GEMM 最終要拆成大量計算任務分給 SM，如果 token 太少，任務數量不夠，很多 SM 會閒著。

Cursor 使用 wave 來判斷這個邊界。一個完整 wave，可以簡單理解為所有計算 SM 都分到了工作。MoK 希望一個 minibatch 至少能夠形成兩個完整 wave，讓 Tensor Core 有足夠的任務持續執行。

實際結果非常能說明問題。在 Hidden Size 為 7168、專家中間維度為 2048 的 Kimi 2.5 形狀上，Cursor 評估 minibatch 至少需要約 2368 個 token。當為 512 token 時，MoK 前向耗時為 5.981 ms；增加至 2560 token 後，下降至 3.425 ms。再繼續增加，速度已無明顯改善。

換句話說，將通信切得更碎並不總會變快。真正高效的重疊，需要讓通信盡早交出數據，同時又不能把 GEMM 切得太小。

但 MoE 還有一個麻煩：在 Router 跑完之前，根本不知道每張 GPU 最後會收到多少 token。

如果按照最壞情況準備 buffer，會浪費很多顯存。如果先讓 GPU 數完 token，再通知 CPU 分配對應空間，GPU 又得停下來等 CPU。

MoK 使用固定大小的 Ring Token Buffer。一塊空間先裝入 Dispatch 進來的 token，專家計算完成、Combine 將結果傳走後，這塊空間立即重新用於下一組 token。前一個 macrobatch 的 Combine，還可以與下一個 macrobatch 的 Dispatch 同時進行。

環形緩衝區在這裡很像一個緩衝層：通信暫時跑得更快時，數據就會在裡面累積；計算消費得更快時，就等下一批 token 到達。整個過程靠 GPU 上的狀態推進，不需要 CPU 每一輪都進來決定下一步。

Cursor 還將 MXFP8 激活的量化嵌入了 Dispatch、Grouped GEMM 和 SwiGLU 的數據路徑中，減少了獨立的 quantize kernel，也減少了一次中間結果在 HBM 中的來回讀寫。

將 Pull、minibatch、SM 分區和 Ring Buffer 放在一起後，MoK 才真正變成了一條連續的 MoE 流水線。

03

Cursor 的基準測試涵蓋完整的 MoE 層，包括排程、分派、專家 FFN、結合以及最終的加權合併，對比對象包括 NCCL + PyTorch、DeepEP、TransformerEngine 和 HybridEP + Megatron。

On GB300 NVL72, compared to the fastest public baselines for each scenario, MoK's MXFP8 achieves a maximum forward improvement of 2.37x and a maximum backward improvement of 1.78x; BF16 achieves maximum forward and backward improvements of 1.92x and 1.58x, respectively.

更重要的是端到端訓練。Cursor 原有的生產方案已使用 DeepEP。在 512 張 GB300 GPU 上，換成 MoK 後，單卡吞吐量從每秒 760.9 個 token 提升至 1070.2 個，提升約 41%。

這組結果也要看清邊界。Cursor 沒有公開完整的逐項消融，所以無法準確說 2.37 倍裡面有多少來自 Pull、多少來自 Megakernel、多少來自 Ring Buffer。

可以單獨確認的是 Pull 對 NVLink 利用率和 signaling 延遲的改善，其餘收益更多來自整套執行方式組合後的結果。

MoK 對硬體的依賴也很強。它面向 Blackwell 和 NVL72 這樣的高速 NVLink Domain。遠端讀取、通信與計算的細粒度交錯，都建立在 GPU 之間能低延遲存取彼此顯存的基礎上。模型的 Hidden Size、Top-k、專家規模一變，合適的 minibatch 和通信 SM 數量也會跟著改變。

這也是 MoK 最值得關注的地方。過去討論 MoE 優化時，很容易只盯著兩個數字：GEMM 有多少 TFLOPS，All-to-All 有多少 GB/s。到了 GB300 這一代，單單把這兩個數字繼續往上推，已經無法解釋全部性能。

token 何時到達、如何排列成專家所需的佈局、累積多少才開始計算、通信獲取多少 SM、buffer 何時釋放，這些執行細節開始直接決定訓練速度。

一個擁有 130 TB/s NVLink 帶寬的機架，最終仍需為 MoE 重寫 GPU 核心，原因就在於：鏈路已經足夠快，接下來要節省的是 GPU 等待數據的時間。

Cursor 重寫 GPU 核心的行為，標誌著 AI 2.0 時代的競爭進入了「全棧主權」的新階段。

過去，我們深信「術業有專攻」，做應用就該做應用（Cursor），做底層就該做底層（NVIDIA）。但如今的 AI 競爭已進入「去中間商化」的新階段，Cursor 不是因為「想做」而去做核心，而是因為「不得不做」。

DeepSeek 開啟了工程榨取的新紀元，而 Cursor 則將這把火燒到了應用層。這種「去中間商化」的趨勢正在重塑 AI 的定價權：未來，決定 AI 公司估值的，不再是它擁有多少 Token，而是它的代碼離顯存和寄存器到底有多近。

那些無法穿透底層黑盒的 AI 公司，最終將會留在「平庸稅」的泥潭裡。