2026 年 8 月 4 日，Cursor Research 在官方部落格發布〈Mixture-of-Kittens: our open-source MoE megakernel for NVL72s〉，並把 Mixture-of-Kittens（MoK）以 Apache-2.0 授權公開。它的公開 functional layer 不是單 GPU 路徑，也不是 Cursor 完整的模型訓練堆疊；更精確地說，這是一個在 NVL72 多 GPU 系統上協作執行、把 MoE 最昂貴的跨 GPU 通訊與專家計算壓進同一條執行路徑的 CUDA megakernel。
這個發布很快引起注意。Cursor 官方 X 貼文截至 2026 年 8 月 5 日 15:43（台北）約有 36.4 萬次瀏覽、4,804 個讚；GitHub 專案同日下午約 289 stars。但注意力不等於效能驗證：最吸睛的 2.37× 是 Cursor 在 GB300 NVL72 上的廠商自測最高單點，而且只屬於 MXFP8 forward 的特定 shape。
先把原文放在桌上。點擊下面截圖會在新分頁打開 Cursor 技術文章；接下來我會先忠實整理它解了什麼問題，再拆開基準測試與程式碼邊界，最後給出獨立判讀。
一、Mixture-of-Kittens 原文到底公開了什麼？
MoE（Mixture-of-Experts，專家混合）模型不會讓每個 token 經過全部參數，而是由 router 挑選少數專家處理。這節省計算，卻產生新的麻煩：專家權重被分散在不同 GPU，token 在計算前要先送到對的 GPU（dispatch），算完再送回原本的 GPU（combine）。想先補齊 MoE 的白話背景，可以看 AlphaLab 的Kimi K3 架構拆解。
Cursor 自述，在 Composer 的部分工作負載中，MoE layer 會吃掉超過一半端到端訓練時間，瓶頸逐漸從矩陣乘法轉成通訊、同步與排程。原文把 MoK 的核心主張濃縮成一句：
“MoK fuses all MoE communication and computation into a single kernel, is fully deterministic, and achieves state-of-the-art performance against publicly available implementations.”
中文：「MoK 把所有 MoE 通訊與計算融合進單一 kernel，具備完全確定性，並在公開實作的比較中達到最佳效能。」
— Cursor Research，〈Mixture-of-Kittens〉
這句話的精神是對的，但範圍需要精確。MoK 把 pull-based dispatch、共享與路由專家的 FFN／SwiGLU、MXFP8 activation quantization，以及 push-based combine放進 forward 主 megakernel；backward 也把 reverse-combine、專家梯度計算與 reverse-dispatch 深度融合。它的創新重點不是「又寫了一個更快的 GEMM」，而是讓通訊和計算在 SM 層級彼此交錯。
為什麼是 pull dispatch、push combine？Cursor 的設計讓接收端直接把 token 拉進各專家需要的順序，減少跨 GPU 完成訊號；combine 再反向重用同一張 schedule，把結果推回原 rank。這是 MoK 不只「分批重疊通訊與計算」的關鍵差異，但頻寬與延遲優勢仍來自 Cursor 在 NVL72 上的自測。
MoK 再用兩層批次處理動態路由：minibatch 控制通訊與計算的重疊粒度，macrobatch 則是一個環形 token buffer，讓 GPU 不必每一步把 token 數送回 CPU、等 CPU 配出剛好的 buffer。這個設計特別迎合 GB300 NVL72：72 張 GPU 在同一個 NVLink domain 裡，能把整座機櫃當成一個共享通訊平面。
二、「單一 megakernel」不等於「單一 GPU」
這是最容易被頭條寫錯的地方。Mixture-of-Kittens 公開的 functional layer 不是單 GPU 路徑。固定到首發 commit 的 functional API 原始碼明定 expert-parallel group 只能是 4、8、16、32 或 64；Cursor 的 headline benchmark 用的是 EP=64。正確說法是：每張 GPU 執行一個互相協作的 megakernel，整體跨多 GPU 工作。
「單一 kernel」也有邊界。從公開的 functional path可以看到，router projection 位於 MoK 之外；build schedule、all-gather／barrier、buffer copy、最後的 router-weighted reduction 與部分 epilogue 仍是額外操作。更準確的描述是：MoK 把最昂貴的 dispatch → expert MLP → combine 核心路徑融合成 megakernel，而不是讓完整 MoE layer 從頭到尾只 launch 一次。
Cursor 所說的「deterministic」則是 operator 層級的 run-to-run 位元確定性：固定浮點運算順序，避免 block 或 instruction 的實際排程改變相同輸入的輸出。這對 ablation、debug 與 on-policy RL 很有價值；但它不等於跨 CUDA、PyTorch、driver、GPU 架構與完整訓練流程都能逐位元重現。PyTorch 官方重現性說明也明確限制在特定平台、裝置與版本內討論。
三、2.37× 是真的嗎？先看它量了什麼
Cursor 的 individual MoE layer 測試在一座 GB300 NVL72 機櫃內進行；72 張 GPU 位於同一 NVLink domain，這次 expert-parallel group 實際使用其中 64 個 rank，每張 GPU 在 routing 前有 2,048 tokens。測試包含 global scheduling、dispatch all-to-all、expert FFN、combine all-to-all 與最後 weighted sum，但不含 router projection；MXFP8 權重也先在計時區間外完成量化。
那個 2.37× 的精確案例，是 Qwen3.5-397B-A17B shape（512 experts、hidden 4,096、intermediate 1,024、top-k 10）的 MXFP8 forward：Cursor 公布 MoK 為 531.1 TFLOP/s，最快 baseline HybridEP + Megatron 為 224.4 TFLOP/s，比例約 2.37。這代表吞吐量達 2.37 倍、或高約 137%，不是「增加 2.37 倍」變成 3.37 倍。
公開 benchmark harness做了 500 次 warmup、100 次計時，每次先取所有 rank 中最慢的 latency，再取中位數，也會把 output 與 gradient 對 reference 做 tolerance 檢查；這是數值容差檢查，不是逐位元相等。這比只貼一張圖更可審計；但資料仍是 Cursor 自己選 shape、調參、執行與公布的廠商測試。
完整結果也不像 headline 那麼整齊：Cursor 公布的其他最高值為 MXFP8 backward 1.78×、BF16 forward 1.92×、BF16 backward 1.58×；在 DeepSeek V4 Pro 的 BF16 backward 圖中，MoK 還略低於 DeepEP + PyTorch。換句話說，這是一個很強的專用實作，不是每一種 precision、pass、shape 都固定快 2.37×。
端到端只有 1.41×，反而更接近經濟價值
Cursor 另外在 512 張 GB300 GPU、跨多座 NVL72 rack 的內部 production stack 上，只替換 MoE 實作，將每 GPU 每秒 tokens 從 760.9 提高到 1,070.2，也就是約 1.41×。這組 end-to-end 結果沒有放進公開 benchmark harness，目前可核對的資料提供者仍是 Cursor，因此本文把它視為廠商內部測試，不能當作獨立驗證。
2.37× 的 layer headline 與 1.41× 的 end-to-end 並不矛盾。若 MoE 原本剛好占一半 step time，而且那一半加速 2.37×，Amdahl 定律給出的理想整體加速就是約 1.41×。在 GPU 數固定、收斂步數完全相同的條件下，1.41× 吞吐相當於每 token 的 GPU-hours 約少 29%，不是少 41%。這組公開結果呈現的是吞吐量；要判斷實際訓練成本，仍需另量功耗與收斂／loss curve。
四、Mixture-of-Kittens 開源的價值：可審計，不等於容易使用
MoK 專案本身採 Apache-2.0，這是實質開放：你可以讀排程、檢查確定性設計、改 kernel，也能執行同一組 layer benchmark。可是「程式碼開放」和「多數團隊能原樣重跑」是兩回事。首發版要求 Linux、Python 3.12+、PyTorch 2.10 以上但低於 3.0、CUDA toolkit 13.x，且 PyTorch 所用 CUDA 必須和系統 toolkit 的主次版本相同；硬體則鎖定 Blackwell。最佳參數也會隨 shape、token 數、precision 與通訊／計算比例變動。
README 寫 SM100／SM103，高階 API 卻仍只接受 SM103
截至 2026 年 8 月 5 日，README 列出 SM100（例如 GB200 NVL72）與 SM103（GB300 NVL72），Makefile 也能編譯兩種架構；但同一首發 commit 的 functional API 會檢查 compute capability，非 10.3 就直接拋出「目前僅支援 SM103」錯誤。GitHub 上已有Issue #5 與尚待合併的草稿 PR #6處理這個落差。因此現在可以確認的是 GB300／SM103 的高階路徑；不能只看 README 就把 GB200 寫成同等即裝即用。
公開 microbenchmark 的 routing 由合成 Gaussian logits 取 top-k，形成相對平均的 expert 分布；真實訓練早期可能更失衡。README 也要求使用者調整 forward／backward communication SM、minibatch、macrobatch 與 schedule capacity。這讓 MoK 更像一個可改、可審計的系統工程起點，而不是 pip install 後自動得到 headline 數字的通用加速器。
這種張力正好呼應 AlphaLab 先前討論的開源 AI 與算力集中悖論：程式碼可以自由流通，但能提供 64 張 GB300、同一 NVLink domain 與 CUDA 13 工程團隊的機構仍很少。若你想理解為何 AI 系統愈來愈受「資料搬運」支配，也可接著看AI 推論的 HBM／記憶體瓶頸。
五、Cursor 為什麼做這件事？從 AI 編輯器走向垂直整合
把這次發布讀成「AI 編輯器公司突然跨進底層 kernel」並不準確。Cursor 在 2025 年已公開 MXFP8 MoE training kernels，之後又做過 MoE inference 的 warp decode；Mixture-of-Kittens 是它把垂直整合再往下推一層：模型能力不只取決於資料與演算法，也取決於能否把昂貴的 GPU 機櫃餵飽。這與 AlphaLab 先前整理的Cursor 公司與 AI coding 戰略是同一條線。
原文另一個耐人尋味的訊號，是 Cursor 說 agents 已接手許多單一 operator kernel 的苦工，並協助一個很小的團隊更快完成分散式 megakernel。這不等於 AI 自主設計了 MoK：人類仍提供通訊方向、warp specialization、PTX 指令與排程等設計判斷。但它確實是「AI 協助打造 AI 基礎設施」的具體案例，可以與當 AI 開始打造 AI放在一起讀。
公開程式碼也同時是人才訊號。Cursor 在文章結尾直接招募能優化數十萬張 GPU 工作負載的人。這個動機不會自動推翻 benchmark，卻提醒我們：技術揭露、開源社群、雇主品牌與 Composer 的成本優勢，可以同時存在於同一個發布裡。
六、AlphaLab 的判讀：真正的突破與真正的限制
我同意：NVL72 應該被當成一台機器
MoK 最有價值的觀念，是把 72 張 GPU 的 NVLink fabric 當成一個可程式化的 rack-scale computer，而不是 72 個各自算完、再用 library collective 搬資料的盒子。pull dispatch／push combine、compute SM／communication SM 分工、ring buffer 與固定累加順序，是一套彼此咬合的系統設計。它公開後，真正會擴散的未必是原始碼原封不動搬家，而是這套拆瓶頸的方法。
我存疑：2.37× 還不是通用 MoE 結論
最強而公平的反方是：MoK 可能是一個非常出色的 GB300 NVL72 point solution，但現有證據不足以把同樣幅度外推到其他 GPU、一般八卡伺服器、PCIe topology 或不同 routing 分布。它用高度特化換來峰值，代價是硬體、shape、版本與調參的可攜性。
通訊與計算重疊本身也有前例。2025 年的Comet 論文與 ByteDance 的Flux 程式庫已經公開細粒度 overlap；MoK 更突出的貢獻，是針對 Blackwell NVL72 整合 forward／backward、確定性與 production 使用。另一方面，Cursor 納入的 HybridEP 並非稻草人：NVIDIA 自己也建議 NVL72 優先測 HybridEP。
真正的門檻，從「看不到程式」移到「養不起環境」
Apache-2.0 讓外界能審計、學習與改造，這值得肯定；但 frontier training 的稀缺資產依然是 GPU、電力、網路、完整 stack 與懂 kernel 的工程師。MoK 降低的是知識門檻，不是機櫃門檻。約 36.4 萬次 X 瀏覽與約 289 個 GitHub stars，至少與「關注者遠多於具備 NVL72 環境者」這個現實相容；但兩者是不同平台的互動指標，不能單靠比率反推出實際可複現的人數。
七、誰該現在行動，誰該先觀察？
- 你有 GB300 NVL72 與 ML systems 團隊：先固定首發版本與 baseline，重跑一個公開 shape；再換成真實 router trace、不同 imbalance、token 數與 EP degree。最重要的是量 end-to-end tokens／second、記憶體、功耗與 loss curve，不只看 layer TFLOP/s。
- 你在做 MoE，但硬體不是 NVL72：把 MoK 當設計參考，優先研究通訊方向、overlap 粒度、ring buffer 與 deterministic accumulation；不要先假設移植後仍有 2.37×。
- 你在看 AI 公司競爭：追蹤應用公司是否持續往模型、kernel、網路與機櫃排程垂直整合。當產品公司開始自己改 training runtime，護城河已經不只在 UI。
- 你只想判斷這次發布是否站得住腳：後續可用四個訊號更新判斷——第三方依公開腳本複現、真實 routing trace、SM100 高階路徑修正、以及 Cursor 以外的 production adoption。
最後的結論：Mixture-of-Kittens 值得重視，因為它把 MoE 的問題從「GPU 算得夠不夠快」改寫成「整座機櫃能不能被當成一台電腦來排程」。2.37× 是醒目的入口，不是結論；真正能把它從漂亮的 vendor result 變成產業基礎設施的，會是外部複現、可攜性與長期維護。