MoK Cursor mencapai peningkatan kinerja 2,37x pada NVIDIA GB300 NVL72

Cursor mengopen-source MoK, menggabungkan penjadwalan token, komunikasi lintas GPU, dan komputasi pakar ke dalam satu kernel GPU yang sama. Solusi ini mencapai peningkatan kinerja hingga 2,37 kali untuk forward dan 1,78 kali untuk backward pada MXFP8 di GB300 NVL72, serta meningkatkan throughput pelatihan dengan 512 GPU GB300 sebesar 41% menjadi 1070,2 token/detik. Latensi signaling turun dari 103 μs menjadi 18 μs. Analisis menunjukkan bahwa saat ini bandwidth NVLink telah mencapai 130 TB/s, waktu pengiriman data ke GPU menjadi hambatan kinerja baru; terobosan ini menandai masuknya persaingan AI ke tahap "kedaulatan penuh stack", di mana perusahaan yang semakin dekat dengan memori GPU dan register memiliki daya tawar lebih besar.

Penulis artikel, sumber: Leifengwang

Pada 21 Juli, NVIDIA mengumumkan hasil terbaru pelatihan DeepSeek-V3 dengan GB300 NVL72: pada 256 GPU, kinerja per kartu mencapai 1.648 TFLOPS.

Kurang dari dua minggu kemudian, Cursor melepaskan Mixture-of-Kittens, disingkat MoK. Alih-alih terus memperbaiki perkalian matriks yang lebih cepat, mereka langsung menulis ulang satu lapisan eksekusi MoE, menggabungkan penjadwalan token, komunikasi antar-GPU, dan perhitungan ahli ke dalam satu kernel GPU.

Ini agak kontraintuitif. Karena GB300 NVL72 sudah memasukkan 72 GPU ke dalam satu Domain NVLink yang sama, total bandwidth NVLink seluruh rak mencapai 130 TB/s. Berdasarkan spesifikasi ini, transfer data antar GPU seharusnya sudah cukup cepat.

Dalam pelatihan MoE berskala besar, komunikasi tetap akan menjadi hambatan bagi perhitungan ahli.

Masalahnya terletak pada aliran data MoE. Setiap langkah, router memutuskan ulang ke mana token akan dikirim ke ahli, sementara para ahli tersebar di berbagai GPU. Token harus dikirim lintas kartu terlebih dahulu, dihitung, lalu dikembalikan; sebelum pengiriman, posisi harus diatur ulang, dan setelah sampai, harus menunggu data lengkap. Seiring MXFP8 dan Blackwell Tensor Core memperpendek waktu komputasi ahli, penundaan yang sebelumnya tersembunyi di balik komputasi kini semakin terlihat.

Cursor melakukan MoK dengan pendekatan ini. Ia tidak hanya berfokus pada seberapa cepat satu Dispatch dapat dikirimkan, tetapi mengatur ulang bagaimana token sampai ke ahli, kapan perhitungan dimulai, serta bagaimana komunikasi dan perhitungan dapat memanfaatkan GPU secara bersamaan.

Di hari ini, ketika sumber daya komputasi telah didorong hingga batas maksimal oleh Blackwell dan NVLink, para pengembang menyadari: semakin cepat perangkat keras berjalan, tidak akan menyelamatkan pengaturan perangkat lunak yang tidak efisien.

Keterbukaan MoK bukan hanya kemenangan bagi intinya, tetapi juga menandai dimulainya era di mana "lapisan aplikasi mendefinisikan operator": untuk mengekstraksi 30% daya komputasi terakhir, perusahaan rintisan AI sedang memulai perang merebut kedaulatan lapisan dasar.

Namun, untuk memahami mengapa desain Cursor ini efektif, pertama-tama kita harus melihat di mana MoE sebenarnya membayar "pajak komunikasi".

01

Pajak Komunikasi MoE

Dalam FFN padat biasa, bobot yang dilalui token pada dasarnya tetap. Setelah MoE menambahkan Router, setiap token secara sementara memilih beberapa ahli. Saat menggunakan Expert Parallel, para ahli dibagi ke banyak GPU, sehingga setidaknya diperlukan dua putaran komunikasi antar-GPU dalam satu propagasi maju.

Putaran pertama disebut Dispatch, yang mengirim token ke GPU tempat para ahli berada; setelah perhitungan ahli selesai, hasilnya dikembalikan ke posisi asal token melalui Combine. Pelatihan juga melibatkan backpropagation, yang sesuai dengan dua putaran komunikasi arah sebaliknya.

Jika hanya memindahkan sejumlah besar data kontinu dari A ke B, NVLink sudah cukup cepat. Masalah dengan MoE adalah bahwa distribusi data yang diberikan oleh Router setiap langkahnya berbeda.

Seorang pakar mungkin menerima banyak token pada langkah ini, tetapi sedikit pada langkah berikutnya. Sistem perlu terlebih dahulu menghitung berapa banyak token yang dimiliki setiap pakar, lalu menentukan di mana token-token tersebut ditempatkan pada GPU tujuan, serta mengelompokkan data dari pakar yang sama sebanyak mungkin. GEMM yang dikelompokkan baru dapat menerima input yang teratur dan memberikan input secara efisien ke Tensor Core.

Setelah komunikasi selesai, tidak bisa langsung mulai menghitung. GPU tujuan harus memastikan bahwa penulisan jarak jauh telah selesai seluruhnya dan data benar-benar terlihat. Beban ahli juga tidak sepenuhnya merata, sebagian GPU mungkin selesai lebih awal, tetapi tetap harus menunggu ahli yang paling sibuk menyelesaikan tugasnya.

Jadi, dalam satu fase "komunikasi", sebenarnya terdapat beberapa hal yang bercampur: pemindahan data, generasi tata letak, sinkronisasi, dan ketidakseimbangan beban. 130 TB/s menggambarkan bandwidth puncak yang dapat disediakan oleh seluruh rak, bukan berarti setiap komunikasi MoE yang dinamis dan terfragmentasi dapat mengisi seluruh saluran secara bersamaan.

DeepEP telah membuat proses pemindahan data sangat cepat. Ini sendiri adalah pustaka komunikasi berperforma tinggi yang dirancang untuk Expert Parallel, menyediakan kernel Dispatch dan Combine khusus, mendukung FP8, dan memungkinkan pengendalian jumlah SM yang digunakan untuk komunikasi. Versi terbaru bahkan dapat mempertahankan throughput komunikasi yang tinggi dengan jumlah SM yang jauh lebih sedikit.

Satu lapis MoE tetap harus terus berpindah antara Dispatch, Grouped GEMM, dan Combine.

Pada saat ini akan muncul kontradiksi yang sangat praktis: jika menunggu cukup banyak token terkumpul sebelum menghitung, matriksnya besar, Tensor Core berjalan dengan nyaman, tetapi komputasi dimulai terlambat; jika menghitung segera saat token datang, komunikasi dan komputasi dapat lebih awal tumpang tindih, tetapi matriksnya terlalu kecil, sehingga banyak SM pada GPU tidak memiliki cukup pekerjaan.

Beberapa CUDA Stream dapat memungkinkan komunikasi dan komputasi berjalan secara paralel, tetapi sulit untuk selalu menjamin kedua sisi mendapatkan sumber daya GPU yang tepat.

Desain di belakang MoK pada dasarnya menangani masalah "ritme" ini.

02

Salah satu perubahan paling menarik di MoK adalah mengubah Forward Dispatch dari Push menjadi Pull.

Push tradisional sangat intuitif: jika GPU sumber memiliki token, ia secara aktif menulisnya ke GPU tujuan. Masalah muncul pada alamat tujuan. Sebuah GPU akan menerima banyak token secara bersamaan dari GPU lainnya.

Setiap pengirim harus tahu terlebih dahulu di bagian mana mereka harus menulis, agar tidak saling menimpa; token dari ahli yang sama sebaiknya juga disusun secara berurutan, jika tidak, GEMM berikutnya harus mengatur ulang.

Seiring dengan semakin banyaknya GPU yang terlibat, proses penjadwalan ini akan menjadi semakin berat. Pull mengubah cara kerjanya: menyimpan target GPU ahli untuk membaca token yang dibutuhkan sendiri. Ia hanya perlu mengetahui token berada di GPU sumber mana dan di posisi mana dalam data sumber, sedangkan lokasi penyimpanan lokal ditentukan sendiri.

Ini menghemat koordinasi antara banyak pihak pengirim terhadap alamat tujuan. Data yang diterima juga dapat langsung diurutkan oleh ahli lokal.

Yang menarik, Pull tidak mengirimkan lebih sedikit data. Dalam microbenchmark Cursor, untuk blok data BF16 256×256 yang sama, Push memindahkan sekitar 159,6 KB di NVLink, sementara Pull justru mencapai 172,0 KB, karena pembacaan memerlukan pengiriman permintaan tambahan.

Keunggulan Pull terletak pada hal lain: komunikasi MoE sangat terfragmentasi dan beban tidak seimbang. Dua arah NVLink memiliki saluran terpisah, memungkinkan Pull memanfaatkan kedua arah permintaan dan pengembalian data secara bersamaan. Dalam pengujian beban ahli yang tidak seimbang, Cursor mengukur peningkatan pemanfaatan NVLink hingga 29%.

Kesenjangan sinkronisasi lebih jelas. Setelah Push selesai, GPU tujuan harus menunggu sinyal selesai dari GPU lain; pada skala Expert Parallel, satu rank dapat melibatkan hingga 71 peer lainnya. Pull diinisiasi secara lokal oleh GPU itu sendiri, sehingga data dapat langsung digunakan setelah diterima.

Dalam mikro-benchmark multi-node Cursor, latensi signaling ini turun dari sekitar 103 mikrodetik pada Push menjadi 18 mikrodetik pada Pull.

MoK juga tidak menggunakan Pull di semua tempat. Pada arah maju, menggunakan Pull Dispatch dan Push Combine; pada arah mundur, menggunakan Pull Reverse-Combine dan Push Reverse-Dispatch. Pada tahap Dispatch, perlu mengatur ulang token dari banyak sumber menjadi input ahli, Pull lebih hemat koordinasi; pada tahap Combine, sudah jelas hasil mana yang harus kembali ke token mana, sehingga lebih sederhana untuk langsung mendorongnya kembali dengan Push.

Setelah mengubah arah komunikasi, MoK masih menggabungkan komunikasi dan komputasi ahli dalam satu Megakernel.

Ia membagi SM GPU menjadi dua bagian. Satu bagian bertanggung jawab atas Dispatch, Combine, dan manajemen status, sementara bagian lainnya secara khusus mengeksekusi Expert FFN. Setelah sisi komunikasi menerima sekelompok token lengkap, ia memberi tahu sisi komputasi melalui counter lokal GPU; setelah komputasi selesai, sisi komputasi memberi tahu sisi komunikasi untuk mengirimkan hasil kembali.

Dengan cara ini, Anda dapat secara langsung menentukan berapa banyak SM yang digunakan untuk komunikasi dan berapa banyak SM yang digunakan untuk komputasi, tanpa harus sepenuhnya menyerahkannya kepada beberapa CUDA Stream yang bersaing. Parameter paling kunci di sini disebut minibatch, yaitu jumlah token yang diberikan kepada para ahli sekaligus untuk dihitung.

It cannot be too large. Too large means the first batch of computations will take a long time to wait. It also cannot be too small. The expert GEMM ultimately needs to be split into numerous computation tasks assigned to SMs; if there are too few tokens, there won't be enough tasks, and many SMs will remain idle.

Cursor menggunakan gelombang untuk menentukan batas ini. Satu gelombang lengkap dapat dipahami secara sederhana sebagai semua perhitungan SM telah mendapatkan tugas. MoK menginginkan satu minibatch setidaknya dapat membentuk dua gelombang lengkap, agar Tensor Core memiliki cukup tugas untuk dieksekusi secara terus-menerus.

Hasil nyata sangat jelas. Pada bentuk Kimi 2.5 dengan Hidden Size 7168 dan dimensi tengah ahli 2048, Cursor memperkirakan bahwa minibatch memerlukan setidaknya sekitar 2368 token. Pada 512 token, waktu forward MoK adalah 5,981 ms; ketika ditingkatkan menjadi 2560 token, waktu turun menjadi 3,425 ms. Jika ditambah lagi, kecepatan tidak lagi menunjukkan perbaikan yang signifikan.

Dengan kata lain, memotong komunikasi menjadi lebih kecil tidak selalu membuatnya lebih cepat. Overlap yang efisien benar-benar memerlukan pengiriman data secepat mungkin, tanpa memotong GEMM terlalu kecil.

Namun, MoE masih memiliki masalah: sebelum router selesai, sama sekali tidak diketahui berapa banyak token yang akan diterima setiap GPU.

Jika menyiapkan buffer berdasarkan skenario terburuk, akan terjadi pemborosan memori GPU. Jika membiarkan GPU terlebih dahulu menghitung token, lalu memberi tahu CPU untuk mengalokasikan ruang yang sesuai, GPU harus berhenti dan menunggu CPU.

MoK menggunakan Ring Token Buffer dengan ukuran tetap. Ruang pertama diisi dengan token yang didispatch, setelah ahli selesai menghitung dan Combine mengirimkan hasilnya, ruang tersebut langsung digunakan kembali untuk token berikutnya. Combine dari macrobatch sebelumnya dapat berjalan bersamaan dengan Dispatch dari macrobatch berikutnya.

Ring Buffer di sini seperti lapisan penyangga: komunikasi berjalan sementara lebih cepat, data terakumulasi di dalamnya; komputasi mengonsumsi lebih cepat, maka menunggu token berikutnya tiba. Seluruh proses didorong oleh status di GPU, tanpa perlu CPU masuk setiap siklus untuk menentukan langkah selanjutnya.

Cursor juga menyisipkan kuantisasi MXFP8 ke dalam jalur data Dispatch, Grouped GEMM, dan SwiGLU, mengurangi kernel kuantisasi independen serta sekali pembacaan dan penulisan ulang hasil sementara di HBM.

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

03

Benchmark Cursor mengukur lapisan MoE lengkap, termasuk Schedule, Dispatch, Expert FFN, Combine, dan penggabungan terakhir yang tergewakan, dengan membandingkannya terhadap NCCL + PyTorch, DeepEP, TransformerEngine, serta HybridEP + Megatron.

Pada GB300 NVL72, MoK mencapai peningkatan maksimum 2,37 kali pada forward dan 1,78 kali pada backward dibandingkan baseline publik tercepat untuk setiap skenario; untuk BF16, peningkatan maksimum masing-masing adalah 1,92 kali pada forward dan 1,58 kali pada backward.

Yang lebih penting adalah pelatihan end-to-end. Solusi produksi asli Cursor sudah menggunakan DeepEP. Dengan mengganti ke MoK pada 512 GPU GB300, throughput per kartu meningkat dari 760,9 token per detik menjadi 1.070,2 token per detik, meningkat sekitar 41%.

Hasil ini juga harus diperhatikan batasannya. Cursor tidak mempublikasikan ablasi rinci secara lengkap, sehingga tidak mungkin mengatakan secara akurat berapa banyak dari 2,37 kali tersebut berasal dari Pull, berapa banyak dari Megakernel, dan berapa banyak dari Ring Buffer.

Yang dapat dikonfirmasi secara terpisah adalah peningkatan Pull terhadap pemanfaatan NVLink dan latensi signaling; manfaat lainnya lebih banyak berasal dari kombinasi seluruh pendekatan eksekusi.

MoK juga sangat bergantung pada perangkat keras. Ia dirancang untuk domain NVLink berkecepatan tinggi seperti Blackwell dan NVL72. Pembacaan jarak jauh, komunikasi, dan interleave komputasi halus semuanya didasarkan pada kemampuan GPU untuk mengakses memori GPU satu sama lain dengan latensi rendah. Ukuran Hidden, Top-k, dan skala pakar model akan memengaruhi ukuran minibatch dan jumlah SM komunikasi yang sesuai.

Ini juga merupakan bagian paling menarik dari MoK. Dalam diskusi sebelumnya tentang optimasi MoE, orang cenderung hanya fokus pada dua angka: berapa TFLOPS GEMM, dan berapa GB/s All-to-All. Pada generasi GB300 ini, hanya mendorong dua angka tersebut lebih tinggi tidak lagi bisa menjelaskan seluruh kinerja.

Kapan token tiba, bagaimana menyusunnya sesuai tata letak yang dibutuhkan ahli, berapa banyak yang harus dikumpulkan sebelum dimulai perhitungan, berapa banyak SM yang diambil untuk komunikasi, dan kapan buffer dilepaskan—detail eksekusi ini secara langsung menentukan kecepatan pelatihan.

Sebuah rak dengan bandwidth NVLink 130 TB/s tetap memerlukan penulisan ulang kernel GPU untuk MoE, karena alasan ini: tautannya sudah sangat cepat, yang perlu dihemat sekarang adalah waktu GPU menunggu data.

Perilaku penulisan ulang kernel GPU oleh Cursor menandai persaingan di era AI 2.0 memasuki tahap baru "kedaulatan penuh stack".

Dulu, kita percaya bahwa "setiap bidang memiliki keahliannya masing-masing", sehingga membuat aplikasi harus fokus pada aplikasi (Cursor), dan membuat infrastruktur dasar harus fokus pada infrastruktur dasar (NVIDIA). Namun, persaingan AI saat ini telah memasuki tahap baru "penghapusan perantara", di mana Cursor tidak melakukan pengembangan inti karena "ingin melakukannya", tetapi karena "harus melakukannya".

DeepSeek membuka era baru ekstraksi teknis, sementara Cursor membawa api ini hingga ke lapisan aplikasi. Tren "menghilangkan perantara" ini sedang membentuk ulang kekuatan penetapan harga AI: di masa depan, yang menentukan valuasi perusahaan AI bukan lagi seberapa banyak token yang dimilikinya, tetapi seberapa dekat kodenya dengan memori video dan register.

Perusahaan AI yang tidak dapat menembus kotak hitam dasar pada akhirnya akan terjebak dalam lumpur "pajak mediocrity".