Pencapaian MoK Cursor Meningkatkan Prestasi Sebanyak 2.37x pada NVIDIA GB300 NVL72

Cursor membuka sumber MoK, menggabungkan penjadualan token, komunikasi lintas-GPU, dan pengiraan pakar ke dalam satu kernel GPU yang sama. Skema ini mencapai peningkatan prestasi hingga 2.37 kali untuk arah maju MXFP8 dan 1.78 kali untuk arah songsang pada GB300 NVL72, dengan peningkatan throughput latihan sebanyak 41% hingga 1070.2 token/s menggunakan 512 GPU GB300. Latensi Signaling berkurang dari 103μs menjadi 18μs. Analisis menunjukkan bahawa pada masa kini, apabila lebar pita NVLink telah mencapai 130 TB/s, masa yang dihabiskan untuk data di GPU menjadi bottleneck prestasi baru; terobosan ini menandakan bahawa persaingan AI telah memasuki tahap "kedaulatan penuh seluruh stak", di mana syarikat yang memiliki kod lebih dekat dengan memori GPU dan register akan memiliki kuasa penetapan harga yang lebih besar.

Penulis artikel, sumber: Leifengwang

Pada 21 Julai, NVIDIA mengumumkan keputusan terkini GB300 NVL72 dalam melatih DeepSeek-V3: pada 256 unit GPU, prestasi setiap unit mencapai 1,648 TFLOPS.

Kurang daripada dua minggu kemudian, Cursor membuka sumber Mixture-of-Kittens, disingkat MoK. Alih-alih terus memperbaiki pendaraban matriks yang lebih pantas, ia menulis semula satu lapisan pelaksanaan MoE dengan menggabungkan penjadualan token, komunikasi antara GPU, dan pengiraan pakar ke dalam satu kernel GPU yang sama.

Perkara ini agak bertentangan dengan intuisi. Kerana GB300 NVL72 telah memasukkan 72 keping GPU ke dalam domain NVLink yang sama, jumlah bandwidth NVLink keseluruhan rak mencapai 130 TB/s. Berdasarkan spesifikasi ini, penghantaran data antara GPU sepatutnya sudah cukup pantas.

Dalam latihan MoE berskala besar, komunikasi masih akan menjadi beban kepada pengiraan pakar.

Masalahnya terletak pada aliran data MoE. Setiap langkah, router akan menentukan semula token mana yang akan dihantar ke pakar mana, sementara pakar-pakar tersebut tersebar di GPU yang berbeza. Token perlu dihantar melintasi kad terlebih dahulu, dihitung, kemudian dihantar balik; sebelum penghantaran, posisi perlu disusun, dan selepas tiba, ia perlu menunggu sehingga data lengkap. Semakin lama MXFP8 dan Blackwell Tensor Core mempercepatkan pengiraan pakar, masa tunggu yang sebelumnya boleh disembunyikan di belakang pengiraan kini menjadi semakin jelas.

Cursor melakukan MoK, bermula dari sini. Ia tidak hanya mengejar seberapa pantas satu Dispatch boleh dihantar, tetapi menyusun semula bagaimana token sampai kepada pakar, bila permulaan pengiraan, serta bagaimana komunikasi dan pengiraan boleh menggunakan GPU secara serentak.

Pada hari ini, apabila sumber daya pengiraan telah didorong hingga maksimum oleh Blackwell dan NVLink, para pembangun mendapati: secepat apa pun peranti keras berjalan, ia tidak dapat menyelamatkan pengaturan perisian yang tidak cekap.

Pembukaan sumber MoK bukan sahaja kemenangan dalam inti, tetapi juga menandakan permulaan era "aplikasi menentukan operator": untuk mengekstrak 30% terakhir kekuatan pengiraan, syarikat AI sedang memulakan perang untuk merebut kedaulatan lapisan bawah.

Namun, untuk memahami mengapa reka bentuk Cursor ini berkesan, pertama-tama kita perlu melihat di mana MoE sebenarnya membayar “cukai komunikasi”.

01

「Cukai Komunikasi」MoE

Dalam FFN padat biasa, token melalui bobot yang pada dasarnya tetap. Setelah MoE menambahkan Router, setiap token secara sementara memilih beberapa pakar. Semasa menggunakan Expert Parallel, pakar-pakar tersebut dibahagikan ke banyak GPU, maka sekali penghantaran maju sekurang-kurangnya memerlukan dua putaran komunikasi antar-kad.

Putaran pertama dipanggil Dispatch, menghantar token ke GPU yang berada di tangan pakar; selepas pakar menyelesaikan pengiraan, hasilnya akan dikembalikan ke kedudukan asal token melalui Combine. Latihan juga melibatkan penyebaran balik, yang sepadan dengan dua putaran komunikasi berlawanan arah.

Jika hanya memindahkan sejumlah besar data berterusan dari A ke B, NVLink sudah cukup cepat. Masalah dengan MoE ialah, taburan data yang diberikan oleh Router setiap langkah berbeza.

Seorang pakar mungkin menerima banyak token pada langkah ini, tetapi sedikit pada langkah seterusnya. Sistem perlu mengira terlebih dahulu berapa banyak token yang dimiliki setiap pakar, kemudian menentukan di mana letak token-token tersebut pada GPU sasaran, serta mengumpulkan data daripada pakar yang sama sebanyak mungkin. GEMM yang dikelompokkan baru boleh menerima input yang teratur dan memberikan input secara efisien kepada Tensor Core.

Selepas komunikasi selesai, tidak boleh segera bermula pengiraan. GPU sasaran perlu mengesahkan bahawa penulisan jauh telah selesai sepenuhnya dan data benar-benar kelihatan. Beban pakar juga tidak seragam sepenuhnya; sebahagian GPU mungkin telah selesai lebih awal, tetapi masih perlu menunggu pakar yang paling sibuk untuk menyelesaikan tugasan mereka.

Jadi, dalam satu fasa “komunikasi”, sebenarnya terdapat beberapa perkara seperti pemindahan data, penghasilan susunan, penyegerakan, dan ketidakseimbangan beban. 130 TB/s menggambarkan lebar pita puncak yang boleh disediakan oleh keseluruhan rak, tetapi tidak bermakna setiap komunikasi MoE yang dinamik dan pecah-pecah boleh mengisi semua saluran tersebut secara serentak.

DeepEP telah mempercepat proses pemindahan data. Ia sendiri merupakan pustaka komunikasi berprestasi tinggi yang dirancang khusus untuk Expert Parallel, menyediakan kernel Dispatch dan Combine khusus, menyokong FP8, dan membolehkan pengawasan jumlah SM yang digunakan untuk komunikasi. Versi terkini bahkan mampu mengekalkan throughput komunikasi yang tinggi dengan jumlah SM yang jauh lebih sedikit.

Satu lapisan MoE masih perlu terus berpindah antara Dispatch, Grouped GEMM, dan Combine.

Pada masa ini, akan berlaku konflik yang sangat praktikal: jika menunggu cukup banyak token berkumpul sebelum mengira, matriks akan menjadi besar, dan Tensor Core beroperasi dengan selesa, tetapi pengiraan bermula lewat; jika mengira segera apabila token tiba, komunikasi dan pengiraan boleh lebih awal bertindih, tetapi matriks menjadi terlalu kecil, sehingga banyak SM GPU tidak mempunyai cukup kerja.

Beberapa CUDA Stream membolehkan komunikasi dan pengiraan berlaku secara serentak, tetapi sukar untuk sentiasa menjamin kedua-dua belah mendapat sumber GPU yang tepat.

Reka bentuk selepas MoK pada dasarnya menangani masalah "ritma" ini.

02

Salah satu perubahan paling menarik dalam MoK ialah mengubah Dispatch ke depan daripada Push kepada Pull.

Push tradisional sangat intuitif: apabila GPU sumber mempunyai token, ia secara aktif menulisnya ke GPU tujuan. Masalah timbul pada alamat tujuan. Sebuah GPU akan menerima banyak token serentak dari GPU lain.

Setiap penghantar perlu mengetahui terlebih dahulu di bahagian mana mereka harus menulis, tidak boleh saling menimpa; token daripada pakar yang sama sebaiknya juga disusun secara berterusan, jika tidak, GEMM yang berikutnya perlu disusun semula.

Semakin banyak GPU yang terlibat, proses penjadualan ini akan menjadi semakin berat. Pull mengubah cara ini: menyimpan target GPU pakar sendiri untuk membaca token yang diperlukan. Ia hanya perlu mengetahui di GPU sumber mana token berada dan di posisi mana dalam data sumber, sementara lokasi penyimpanan tempatan ditentukan sendiri.

Ini menghilangkan keperluan untuk mengkoordinasikan alamat tujuan antara banyak pihak penghantar. Data yang diterima juga boleh disusun secara langsung mengikut pakar tempatan.

Yang menariknya, Pull tidak menghantar data kurang. Dalam mikrobentuk Cursor, untuk blok data BF16 256×256 yang sama, Push menggerakkan sekitar 159.6 KB di atas NVLink, manakala Pull pula mencapai 172.0 KB, kerana pembacaan memerlukan penghantaran permintaan tambahan.

Kelebihan Pull ialah perkara lain: komunikasi MoE sangat terpecah dan beban tidak seimbang. Dua arah NVLink mempunyai saluran berasingan, membolehkan Pull memanfaatkan kedua-dua arah permintaan dan pengembalian data secara serentak. Dalam ujian beban pakar yang tidak seimbang, Cursor mengukur peningkatan penggunaan NVLink sehingga 29%.

Kesenjangan penyegeraan menjadi lebih jelas. Selepas Push selesai, GPU sasaran perlu menunggu isyarat penyelesaian daripada GPU lain; apabila skala Expert Parallel besar, satu rank mungkin melibatkan sehingga 71 rakan sebaya. Pull pula diinisiasikan secara tempatan oleh GPU itu sendiri, dan data boleh digunakan terus setelah ia kembali.

Dalam mikrobentuk banyak nod Cursor, latensi signaling ini turun dari sekitar 103 mikro saatian pada Push ke 18 mikro saatian pada Pull.

MoK juga tidak menggunakan Pull di semua tempat. Ke depan menggunakan Pull Dispatch dan Push Combine; ke belakang menggunakan Pull Reverse-Combine dan Push Reverse-Dispatch. Pada tahap Dispatch, perlu menyusun semula token dari banyak sumber menjadi input pakar, Pull lebih menjimatkan koordinasi; ketika Combine, sudah jelas hasil mana harus kembali ke token mana, jadi mendorongnya secara langsung lebih mudah.

Selepas mengubah arah komunikasi, MoK masih menyatukan komunikasi dan pengiraan pakar dalam satu Megakernel yang sama.

Ia membahagikan SM GPU kepada dua bahagian. Satu bahagian bertanggungjawab atas Dispatch, Combine, dan pengurusan status, manakala bahagian lain secara khusus menjalankan Expert FFN. Selepas pihak komunikasi menerima sekumpulan token lengkap, ia memberitahu pihak pengiraan melalui pengira tempatan GPU; selepas pengiraan selesai, ia memberitahu pihak komunikasi untuk menghantar semula hasilnya.

Ini membolehkan anda menentukan secara langsung berapa banyak SM yang digunakan untuk komunikasi dan berapa banyak SM yang digunakan untuk pengiraan, tanpa perlu membiarkan beberapa CUDA Stream bersaing sepenuhnya. Parameter paling penting di sini ialah minibatch, iaitu jumlah token yang diberikan kepada pakar untuk pengiraan sekali gus.

Ia tidak boleh terlalu besar. Terlalu besar bermakna pengiraan pertama akan menunggu lama. Ia juga tidak boleh terlalu kecil. GEMM pakar akhirnya perlu dipecahkan menjadi banyak tugas pengiraan yang dibahagikan kepada SM; jika token terlalu sedikit, jumlah tugas tidak mencukupi, dan banyak SM akan menganggur.

Cursor menggunakan gelombang untuk menentukan sempadan ini. Satu gelombang penuh boleh difahami secara ringkas sebagai semua pengiraan SM telah menerima tugas. MoK menghendaki satu minibatch sekurang-kurangnya membentuk dua gelombang penuh, supaya Tensor Core mempunyai tugas yang mencukupi untuk dilaksanakan secara berterusan.

Hasil sebenar sangat jelas. Pada bentuk Kimi 2.5 dengan Saiz Tersembunyi 7168 dan dimensi pertengahan pakar 2048, Cursor menganggarkan bahawa minibatch sekurang-kurangnya memerlukan sekitar 2368 token. Pada 512 token, masa maju MoK ialah 5.981 ms; apabila ditingkatkan kepada 2560 token, ia turun kepada 3.425 ms. Apabila ditingkatkan lagi, kelajuan tidak lagi menunjukkan peningkatan yang ketara.

Dengan kata lain, memotong komunikasi menjadi bahagian yang lebih kecil tidak selalunya membuatnya lebih pantas. Perlapikan yang berkesan benar-benar memerlukan komunikasi untuk menghantar data seawal mungkin, sambil tidak memotong GEMM terlalu kecil.

Namun, MoE mempunyai masalah lain: sebelum router selesai, ia tidak tahu berapa banyak token yang akan diterima oleh setiap GPU.

Jika menyiapkan buffer mengikut kes terburuk, banyak memori grafik akan terbuang. Jika membiarkan GPU mengira token dahulu, kemudian memberitahu CPU untuk mengalokasikan ruang yang sesuai, GPU perlu berhenti menunggu CPU.

MoK menggunakan Buffer Token Cincin berukuran tetap. Ruang pertama diisi dengan token yang dihantar, selepas pakar selesai mengira dan Combine menghantar hasilnya, ruang tersebut segera digunakan semula untuk siri token seterusnya. Combine bagi macrobatch sebelumnya boleh berlaku serentak dengan Dispatch bagi macrobatch seterusnya.

Ring Buffer di sini serupa dengan lapisan penyangga: komunikasi berjalan sementara lebih cepat, data terkumpul di dalamnya; pengiraan mengonsumsi lebih cepat, maka menunggu token seterusnya tiba. Keseluruhan proses didorong oleh keadaan di atas GPU, tanpa memerlukan CPU untuk masuk setiap kitaran untuk menentukan langkah seterusnya.

Cursor juga menyisipkan kuantisasi aktivasi MXFP8 ke dalam laluan data Dispatch, Grouped GEMM, dan SwiGLU, mengurangkan kernel kuantisasi yang berasingan serta sekali baca-tulis sementara di HBM.

Setelah Pull, minibatch, SM partition, dan Ring Buffer digabungkan, MoK benar-benar menjadi saluran MoE yang berterusan.

03

Benchmark Cursor mengukur lapisan MoE penuh, termasuk Jadual, Penghantaran, Expert FFN, Gabungan, dan penggabungan berbobot akhir, dengan perbandingan terhadap NCCL + PyTorch, DeepEP, TransformerEngine, serta HybridEP + Megatron.

Pada GB300 NVL72, MoK mencapai peningkatan maksimum 2.37 kali dalam arah maju dan 1.78 kali dalam arah terbalik dibandingkan baseline terbuka tercepat untuk setiap skenario; untuk BF16, peningkatan maksimum masing-masing adalah 1.92 kali dalam arah maju dan 1.58 kali dalam arah terbalik.

Lebih penting lagi ialah latihan end-to-end. Skema pengeluaran asal Cursor sudah menggunakan DeepEP. Dengan menukar kepada MoK pada 512 GPU GB300, throughput per kad meningkat dari 760.9 token per saat menjadi 1070.2 token per saat, meningkat sebanyak kira-kira 41%.

Hasil ini juga perlu diperhatikan batasannya. Cursor tidak mengumumkan ablasi terperinci secara lengkap, jadi tidak mungkin untuk menentukan dengan tepat berapa banyak dari 2.37 kali tersebut berasal dari Pull, berapa banyak dari Megakernel, dan berapa banyak dari Ring Buffer.

Yang boleh disahkan secara berasingan ialah peningkatan Pull terhadap penggunaan NVLink dan latensi signaling; manfaat lain lebih banyak datang daripada kombinasi keseluruhan cara pelaksanaan.

MoK juga sangat bergantung pada peranti keras. Ia dirancang untuk domain NVLink berkelajuan tinggi seperti Blackwell dan NVL72. Pemulihan bacaan jauh, komunikasi, dan pergantian halus pengiraan semuanya dibina atas dasar kemampuan GPU untuk mengakses memori video satu sama lain dengan latensi rendah. Saat saiz Tersembunyi model, Top-k, dan skala pakar berubah, ukuran minibatch dan jumlah SM komunikasi yang sesuai juga akan berubah.

Ini juga merupakan aspek paling menarik dalam MoK. Dalam perbincangan sebelumnya mengenai pengoptimuman MoE, orang mudah fokus hanya pada dua nombor: berapa TFLOPS GEMM, dan berapa GB/s All-to-All. Pada generasi GB300 ini, hanya mendorong dua nombor ini lebih tinggi lagi tidak lagi mampu menjelaskan semua prestasi.

Kapan token tiba, bagaimana menyusunnya mengikut susunan yang diperlukan oleh pakar, berapa banyak yang perlu dikumpulkan sebelum pengiraan bermula, berapa banyak SM yang diambil untuk komunikasi, dan kapan buffer dibebaskan—perincian pelaksanaan ini secara langsung menentukan kelajuan latihan.

Sebuah rak dengan bandwidth NVLink 130 TB/s masih memerlukan penulisan semula kernel GPU untuk MoE, kerana tautan sudah sangat pantas; yang perlu dijimatkan sekarang ialah masa GPU menunggu data.

Perilaku penulisan semula kernel GPU oleh Cursor menandakan persaingan di era AI 2.0 memasuki peringkat "kedaulatan penuh stak".

Dahulu, kita percaya bahawa "setiap bidang memerlukan keahlian khusus", jadi jika membuat aplikasi, buatlah aplikasi (Cursor), dan jika membuat infrastruktur asas, buatlah infrastruktur asas (NVIDIA). Tetapi persaingan AI hari ini telah memasuki peringkat baharu "penghapusan perantara", di mana Cursor tidak melakukan pembuatan teras kerana "ingin melakukannya", tetapi kerana "terpaksa melakukannya".

DeepSeek telah membuka era baru ekstraksi kejuruteraan, sementara Cursor membawa api ini ke lapisan aplikasi. Tren "menghilangkan perantara" ini sedang membentuk semula kuasa penetapan harga AI: di masa depan, yang menentukan penilaian syarikat AI bukan lagi berapa banyak Token yang dimilikinya, tetapi sejauh mana kodnya berdekatan dengan memori video dan pendaftar.

Syarikat AI yang tidak mampu menembusi kotak hitam asas akan tetap terperangkap dalam lumpur cukai kebiasaan.