7 月 21 日，輝達公佈了 GB300 NVL72 訓練 DeepSeek-V3 的最新成績：在 256 張 GPU 上，單卡效能達到 1,648 TFLOPS。不到兩週後，Cursor 開源了 Mixture-of-Kittens（簡稱 MoK），它沒有繼續追求更快的矩陣乘法，而是直接重寫了 MoE（混合專家）的執行方式，把 token 排程、跨 GPU 通訊和專家計算整合進同一個 GPU 核心。這一舉動看似反直覺，因為 GB300 NVL72 已將 72 張 GPU 放入同一 NVLink Domain，整機架 NVLink 總頻寬高達 130 TB/s，理論上 GPU 間資料傳輸已足夠快。然而，在大規模 MoE 訓練中，通訊依然成為拖累專家計算的關鍵瓶頸。

MoE 模型通過 Router 為每個 token 動態選擇專家，而專家分佈在不同的 GPU 上。一次前向傳播至少需要兩輪跨卡通訊：Dispatch 將 token 送到專家所在 GPU，Combine 將計算結果送回原位置。訓練時反向傳播還需額外兩輪通訊。問題在於，Router 每一步產生的資料分佈都不同，系統需要先統計每個專家的 token 數量，再決定其在目標 GPU 的存放位置，並儘量將同一專家的資料連續排列，以便 Grouped GEMM 高效利用 Tensor Core。通訊結束後，目標 GPU 還需確認遠端寫入完成，且專家負載不均導致部分 GPU 提前結束仍需等待。因此，所謂的“通訊”階段實際混合了資料搬運、佈局生成、同步和負載失衡等多個環節。130 TB/s 只是整機架峰值頻寬，並不代表每次動態、零碎的 MoE 通訊都能跑滿這些鏈路。

Cursor 的 MoK 設計核心之一是改變前向 Dispatch 的通訊方向，從傳統的 Push 改為 Pull。傳統 Push 模式中，源 GPU 主動將 token 寫入目標 GPU，但需要協調多傳送方之間的目標地址，且同一專家的 token 需連續排列，否則後續 GEMM 需重新整理。Pull 模式則讓儲存專家的目標 GPU 主動讀取所需 token，只需知道 token 在源 GPU 的位置，本地存放由自己安排，省去了多傳送方之間的地址協調，且收到的資料可直接按本地專家排好。雖然 Pull 並未減少資料傳輸量——在 Cursor 的微基準中，同一 256×256 BF16 資料塊，Push 移動約 159.6 KB，Pull 反而達 172.0 KB（因需額外發送請求）——但 Pull 能同時利用 NVLink 兩個方向的獨立通道，在專家負載不均衡的測試中，最高可提升 29% 的 NVLink 利用率。更關鍵的是同步延遲：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 階段結果歸屬明確，直接 Push 更簡單。此外，MoK 將通訊與專家計算整合進同一個 Megakernel，將 GPU 的 SM 分為兩部分：一部分負責 Dispatch、Combine 和狀態管理，另一部分執行 Expert FFN。通訊側通過 GPU 本地計數器通知計算側，計算完成後再通知通訊側傳回結果。這種方式可顯式控制通訊和計算各自佔用的 SM 數量，避免多個 CUDA Stream 競爭資源。關鍵引數 minibatch（一次交給專家計算的 token 數）需平衡：太大則首批計算等待久，太小則專家 GEMM 任務不足導致 SM 空閒。Cursor 用 wave 判斷邊界，希望 minibatch 至少形成兩個完整 wave。在 Hidden Size 7168、專家中間維度 2048 的 Kimi 2.5 形狀上，minibatch 至少需約 2368 個 token；512 token 時前向耗時 5.981 ms，增至 2560 token 後降至 3.425 ms，繼續增加無明顯改善。

MoE 的另一挑戰是 Router 跑完前無法預知每張 GPU 的 token 數量。若按最壞情況準備 buffer 會浪費視訊記憶體，若先數 token 再讓 CPU 分配空間則 GPU 需等待。MoK 採用固定大小的 Ring Token Buffer：空間先裝 Dispatch 進來的 token，專家算完、Combine 傳走結果後立即複用，前一個 macrobatch 的 Combine 可與下一個 macrobatch 的 Dispatch 同時進行。Ring Buffer 充當緩衝層，通訊快時資料積累，計算快時等待下一批 token，整個過程由 GPU 狀態推進，無需 CPU 每輪介入。此外，MoK 將 MXFP8 activation 的量化嵌入 Dispatch、Grouped GEMM 和 SwiGLU 資料路徑，省去獨立量化 kernel 及中間結果在 HBM 的來回讀寫。

Cursor 的 benchmark 測的是完整 MoE 層，包括 Schedule、Dispatch、Expert FFN、Combine 和加權合併，對比物件包括 NCCL + PyTorch、DeepEP、TransformerEngine 以及 HybridEP + Megatron。在 GB300 NVL72 上，相比每種場景最快的公開基線，MoK 的 MXFP8 前向最高提升 2.37 倍，反向最高提升 1.78 倍；BF16 前向和反向最高分別提升 1.92 倍和 1.58 倍。更關鍵的是端到端訓練：Cursor 原生產方案已用 DeepEP，在 512 張 GB300 GPU 上換成 MoK 後，單卡吞吐從每秒 760.9 個 token 提高到 1070.2 個，提升約 41%。不過，Cursor 未公開完整逐項消融，無法準確歸因 2.37 倍中各部分的貢獻，但 Pull 對 NVLink 利用率和 signaling 延遲的改善可單獨確認，其餘收益來自整套執行方式的組合。

MoK 對硬體依賴較強，面向 Blackwell 和 NVL72 這類高速 NVLink Domain，Pull 的遠端讀取和細粒度交錯依賴 GPU 間低延遲訪問彼此視訊記憶體。模型的 Hidden Size、Top-k、專家規模變化時，合適的 minibatch 和通訊 SM 數量也需調整。這反映出在 GB300 這一代，單純追求 GEMM TFLOPS 和 All-to-All GB/s 已不足以解釋全部效能，token 到達時間、佈局生成、計算啟動時機、SM 分配和 buffer 釋放等執行細節開始直接決定訓練速度。一個擁有 130 TB/s NVLink 頻寬的機架，仍需要為 MoE 重寫 GPU 核心，原因在於鏈路雖快，但省下的是 GPU 等待資料的時間。

Cursor 重寫 GPU 核心的行為，標誌著 AI 競爭進入“全棧主權”的新階段。過去應用層與底層分工明確，但如今競爭已到“去中間商化”階段，Cursor 因“不得不做”而深入核心。DeepSeek 開啟了工程榨取的新紀元，Cursor 則把這一趨勢帶到應用層。這種趨勢可能重塑 AI 公司的定價權：決定估值的或許不再是擁有多少 token，而是程式碼離視訊記憶體和暫存器有多近。無法穿透底層黑盒的 AI 公司，可能面臨“平庸稅”的困境。