Ang MoK ni Cursor ay nakamit ang 2.37x pagtaas sa performance sa NVIDIA GB300 NVL72

Ang Cursor ay nagbukas ng MoK, na nag-iisang magkakasama ang pag-schedule ng token, cross-GPU communication, at expert computation sa isang GPU kernel. Ang solusyong ito ay nakamit ang pinakamataas na performance improvement na 2.37x sa forward at 1.78x sa backward sa GB300 NVL72, na nagdulot ng 41% na pagtaas sa training throughput sa 512 na GB300 GPU patungo sa 1070.2 tokens/s. Ang signaling latency ay bumaba mula sa 103μs patungo sa 18μs. Ang pagsusuri ay nagpapakita na sa kasalukuyan kung saan ang NVLink bandwidth ay umabot na sa 130 TB/s, ang oras ng paghahanap ng data sa GPU ang naging bagong performance bottleneck. Ang pagbubukas na ito ay nagtuturo na ang kompetisyon sa AI ay pumasok na sa “full-stack sovereignty” stage, kung saan ang mga kumpanya na mas malapit ang code sa GPU memory at registers ay may mas malaking pricing power.

May-akda ng artikulo, pinagkukunan: Leifengwang

Hulyo 21, ipinahayag ng NVIDIA ang pinakabagong resulta ng GB300 NVL72 sa pagtrabaho sa DeepSeek-V3: sa 256 na GPU, ang performance ng bawat GPU ay umabot sa 1,648 TFLOPS.

Hindi pa nagmumula sa dalawang linggo, inilabas ni Cursor ang Mixture-of-Kittens, o MoK. Hindi ito nagpatuloy sa pagpapabuti ng mas mabilis na matrix multiplication, kundi diretso niyang isinulat muli ang isang layer ng MoE execution, kung saan isinama ang token scheduling, cross-GPU communication, at expert computation sa iisang GPU kernel.

Ang gawaing ito ay medyo kontrabuwan. Dahil ang GB300 NVL72 ay nakapaglagay na ng 72 na GPU sa iisang NVLink Domain, ang kabuuang bandwidth ng NVLink ng buong rack ay umabot sa 130 TB/s. Ayon sa spesipikasyong ito, dapat sapat na mabilis ang pagpapadala ng data sa pagitan ng mga GPU.

Sa malawakang pag-train ng MoE, ang komunikasyon ay patuloy na magiging hadlang sa pagkalkula ng mga eksperto.

Ang problema ay nasa data flow ng MoE. Sa bawat hakbang, binabago ng router kung saan pupunta ang token sa bawat eksperto, at ang mga eksperto ay nakalat sa iba’t ibang GPU. Dapat muna ipadala ang token sa ibang card, pagkatapos ay i-calculate, at balewain ito pabalik; bago ipadala, kailangan i-organisa ang posisyon, at pagkatapos makarating, kailangan maghintay hanggang sa mabuo ang data. Habang pinapabilis ng MXFP8 at Blackwell Tensor Core ang pagkalkula ng mga eksperto, ang mga paghihintay na dati ay nakatago sa loob ng pagkalkula ay nagsisimulang maging mas nakikita.

Ang Cursor ay gumagawa ng MoK sa pamamagitan ng paghahandle dito. Hindi ito naglalayon lamang na i-optimize kung gaano kalakas ang isang Dispatch, kundi binabago nito kung paano natutugunan ang mga token, kailan magsisimula ang pagkalkula, at kung paano magkakasabay ang komunikasyon at pagkalkula sa paggamit ng GPU.

Sa panahon na ang mga yunit ng computing power ay pinag-umpisan ng Blackwell at NVLink, natuklasan ng mga developer: kahit gaano katagal ang hardware, hindi ito makakatulong sa hindi epektibong software orchestration.

Ang pagbukas ng source code ng MoK ay hindi lamang isang tagumpay sa kernel; ito ay nagtatakda ng simula ng panahon ng “application-layer-defined operators”: upang makakuha ng huling 30% ng computing power, ang mga startup sa AI ay nagsisimula ng isang digmaan para sa pagkakaroon ng pagsasakop sa ilalim na layer.

Ngunit upang maunawaan kung bakit epektibo ang disenyo ng Cursor, kailangan muna nating makita kung saan eksaktong binabayaran ng MoE ang “tax sa komunikasyon”.

01

Ang "communication tax" ng MoE

Sa karaniwang dense FFN, ang mga token ay dumadaan sa mga timbang na halos fixed. Pagkatapos ng pagdaragdag ng Router sa MoE, bawat token ay pumipili ng ilang mga eksperto nang pansamantala. Kapag ginagamit ang Expert Parallel, ang mga eksperto ay hinati sa maraming GPU, kaya't kailangan ng hindi bababa sa dalawang pagkakataon ng cross-device communication sa isang forward pass.

Ang unang pagkakataon ay tinatawag na Dispatch, kung saan ipinapadala ang token sa GPU kung saan nasa tagapagsalita; pagkatapos ng pagkalkula ng tagapagsalita, ipinapadala muli ang resulta sa orihinal na posisyon ng token sa pamamagitan ng Combine. Ang pagtuturo ay may backward propagation, na tumutugon sa dalawang karagdagang pagkakataon ng komunikasyon sa reverse direction.

Kung ang tanging ginagawa ay ang paglipat ng isang malaking patuloy na data mula sa A patungo sa B, sapat na mabilis ang NVLink. Ang problema sa MoE ay ang iba’t ibang distribution ng data na ibinibigay ng Router sa bawat hakbang.

Maaaring makatanggap ang isang eksperto ng maraming token sa isang hakbang, at maraming kaunti sa susunod. Kailangan ng sistema na unang bilangin kung ilang token ang mayroon bawat eksperto, bago matukoy kung saan dapat ilagay ang mga token sa target GPU, at subukang i-arrange ang data ng parehong eksperto nang magkakatabi. Upang makakuha ng maayos na input para sa Grouped GEMM at makapagbigay nang epektibo sa Tensor Core.

Hindi agad maaaring magsimula ang pagkalkula pagkatapos ng komunikasyon. Dapat i-confirm ng target GPU na natapos na ang lahat ng remote write at na-access na ang data. Dahil hindi pantay ang expert load, maaaring matapos na ng ilang GPU, ngunit kailangan pa ring hintayin ang pinakamalakas na expert na matapos.

Kaya sa isang “komunikasyon” na yugto, nagkakasalungat ang paghahatid ng data, pagbuo ng layout, pag-sync, at load imbalance. Ang 130 TB/s ay naglalarawan sa pinakamataas na bandwidth na maaaring ibigay ng buong rack, at hindi ito nangangahulugan na bawat dinamiko at maliit na MoE communication ay makakapagpapagana ng lahat ng mga link nang sabay-sabay.

Ang DeepEP ay naging mabilis sa pag-transfer ng data. Ito ay isang high-performance communication library na disenyo para sa Expert Parallel, na nag-aalok ng mga espesyalisadong Dispatch at Combine kernels, sumusuporta sa FP8, at nagpapahintulot sa pagkontrol sa bilang ng SM na ginagamit sa komunikasyon. Ang pinakabagong bersyon ay kahit na gumagamit ng mas kaunting SM, ay nananatiling may mataas na communication throughput.

Ang isang layer na MoE ay patuloy na kailangang magpalitan sa pagitan ng Dispatch, Grouped GEMM, at Combine.

Nakakatok sa isang praktikal na kontradiksiyon: kung maghihintay ka hanggang sa sapat na dami ng token ay makakapag-iskedyul upang kalkulahin, malaki ang matrix, komportable ang Tensor Core, ngunit maaaring maubos ang pagpapatakbo; kung kalkulahin mo ang bawat token habang dumating ito, maaaring mas maagang magsalitang ang komunikasyon at kalkulasyon, ngunit maliit ang matrix, kaya walang sapat na trabaho ang maraming SM ng GPU.

Maaaring magbigay ng pagkakasunod-sunod ng komunikasyon at pagkalkula ng mga maraming CUDA Stream, ngunit mahirap panatilihin ang perpektong pagkakabahagi ng GPU resources sa parehong gilid.

Ang mga disenyo pagkatapos ng MoK ay pangunahing nag-aayos sa problema ng “ritmo”.

02

Isa sa pinakamagagandang pagbabago ng MoK ay ang pagbabago ng forward dispatch mula sa Push patungo sa Pull.

Ang tradisyonal na Push ay direktang maunawaan: kung may token ang source GPU, ito ay aktibong isusulat sa target GPU. Ang problema ay nasa target address. Isang GPU ay maaaring tumanggap ng maraming token mula sa iba't ibang GPU nang sabay-sabay.

Dapat malaman ng bawat tagapagpadala kung saang seksyon dapat isulat nila, at hindi dapat magkakasalungat; ang mga token ng parehong eksperto ay mas mabuti na magkakasunod, dahil kung hindi, ang susunod na GEMM ay kailangang muli ayusin.

Dagdagan ng pagkakaroon ng mas maraming GPU, lalong magiging mabigat ang proseso ng pagjadwal. Nagbago ang Pull ng paraan: ipinapag-iiwan ng expert ang kanilang target GPU upang sarili nilang basahin ang kailangang token. Sapat na alam nila kung saan ang token sa source GPU at saan ito nasa source data, at ang pagkakalagay nito sa lokal ay ipinapag-iiwan sa kanila.

Nakapag-iwas ito sa pagco-coordinate ng maraming tagapagpadala sa target address. Ang mga natanggap na data ay maaaring direktang ayusin ayon sa lokal na eksperto.

Kakaibang bagay ay ang Pull ay hindi nagpapalabas ng mas kaunting data. Sa microbenchmark ng Cursor, para sa parehong bloke ng data na 256×256 BF16, ang Push ay naglalakbay ng humigit-kumulang 159.6 KB sa NVLink, samantalang ang Pull ay umabot sa 172.0 KB dahil sa karagdagang pagpapadala ng kahilingan habang binabasa.

Ang pagpapalabas ay nananatiling mas mahusay sa isang ibang bagay: ang komunikasyon ng MoE ay maliit at hindi pantay ang load. Ang NVLink ay may magkakaibang channel sa parehong direksyon, kaya ang pagpapalabas ay maaaring gamitin nang sabay ang mga kahilingan at ang pagbabalik ng data. Sa pagsubok na may hindi pantay na load ng mga eksperto, natuklasan ni Cursor ang pagtaas ng paggamit ng NVLink hanggang 29%.

Mas malinaw ang pagkakaiba sa pag-sync. Pagkatapos ng pag-push, kailangan maghintay ang target GPU sa signal ng pagkumpleto ng iba pang GPU; kapag malaki ang Expert Parallel, maaaring kasangkot ng isang rank hanggang 71 pa pang peer. Ang pull ay nagsisimula ng sarili nitong pagbasa ng lokal na GPU, at agad itong gagamitin kapag nabalik ang data.

Sa maraming node microbenchmark ng Cursor, bumaba ang signaling latency mula sa halos 103 microsecond ng Push patungo sa 18 microsecond ng Pull.

Hindi ginagamit ng MoK ang Pull sa lahat ng lugar. Sa forward direction, gamit ang Pull Dispatch at Push Combine; sa backward direction, ginagamit ang Pull Reverse-Combine at Push Reverse-Dispatch. Kailangan ng Dispatch stage na muli ayusin ang maraming pinagmumulan ng token bilang input ng expert, at mas maliit ang koordinasyon kung gagamitin ang Pull; naiintindihan nang malinaw kung saan dapat bumalik bawat resulta sa Combine, kaya mas simple lang na i-Push ito pabalik.

Pagkatapos baguhin ang direksyon ng komunikasyon, pinanatili pa rin ni MoK ang komunikasyon at ekspertong kalkulasyon sa iisang Megakernel.

Ibinabahagi nito ang SM ng GPU sa dalawang bahagi. Ang isang bahagi ay nagtatrabaho sa Dispatch, Combine, at pamamahala ng estado, habang ang iba ay espesyalisado sa pagpapatupad ng Expert FFN. Pagkatapos makakuha ng isang bundle ng mga完整 token, binabati ng komunikasyon ang bahagi ng pagkalkula gamit ang lokal na counter ng GPU; pagkatapos matapos ang kalkulasyon, binabati naman nito ang komunikasyon upang ipadala ang resulta pabalik.

Nakakatulong ito upang diretsoang matukoy kung ilang SM ang gagamitin para sa komunikasyon at ilang SM ang gagamitin para sa pagkalkula, nang hindi dapat iwan sa pagkakalaban ng maraming CUDA Stream. Ang pinakamahalagang parameter dito ay ang minibatch, na nagpapakita kung ilang token ang ibibigay sa bawat eksperto para sa pagkalkula.

Hindi ito dapat masyadong malaki. Ang sobrang laki ay nangangahulugan na ang unang pagkalkula ay magkakaroon ng mahabang paghihintay. Hindi rin ito dapat masyadong maliit. Ang ekspertong GEMM ay kailangang hatiin sa malaking bilang ng mga gawain para sa SM; kung sobrang kaunti ang mga token, kulang ang bilang ng mga gawain, at maraming SM ang magiging walang gawain.

Ginagamit ng Cursor ang wave upang matukoy ang hangganan. Isang buong wave ay maaaring maunawaan bilang ang lahat ng mga computation sa SM ay nakatanggap ng trabaho. Gusto ng MoK na ang isang minibatch ay kahit na bumubuo ng dalawang buong wave, upang may sapat na mga gawain ang Tensor Core na maisasagawa nang tuloy-tuloy.

Ang mga aktuwal na resulta ay nagpapakita nang malinaw. Sa hugis ng Kimi 2.5 na may Hidden Size na 7168 at expert intermediate dimension na 2048, kinukwenta ng Cursor na kailangan ng minimbatch ng hindi bababa sa halos 2368 na token. Sa 512 na token, ang oras ng forward pass ng MoK ay 5.981 ms; nang umabot sa 2560 na token, bumaba ito sa 3.425 ms. Kapag pinagpatuloy pa ang pagtaas, hindi na may malinaw na pagpapabuti sa bilis.

Sa ibang salita, ang paghahati ng komunikasyon sa mas maliit na bahagi ay hindi laging nagdadala ng mas mabilis na pagganap. Ang tunay na epektibong pagpapalipat-tila ay nangangailangan ng pagpapadala ng data sa pinakamadaling panahon, samantalang hindi ito pinapaliit nang sobra ang GEMM.

Ngunit may isa pang problema ang MoE: bago matapos ng Router, hindi alam ng system kung ilang token ang tatanggap ng bawat GPU.

Kung ihahanda ang buffer batay sa pinakamasamang kaso, mawawala ang maraming GPU memory. Kung ipapagawa muna ng GPU ang pagbilang ng mga token bago i-notify ang CPU na mag-alok ng katumbas na espasyo, tatigil ang GPU habang umaasang sa CPU.

Gumagamit ang MoK ng fixed-size Ring Token Buffer. Agad na muling ginagamit ang isang espasyo para sa susunod na hanay ng token pagkatapos ma-dispatch ang token at matapos ng eksperto ang pagkalkula at ma-transfer ng Combine ang resulta. Ang Combine ng nakaraang macrobatch ay maaaring mag-eksekuta nang sabay sa Dispatch ng susunod na macrobatch.

Ang Ring Buffer dito ay parang isang buffer layer: ang komunikasyon ay tumatakbo nang mas mabilis, kaya nag-aakumula ang data dito; kung mas mabilis ang pag-consume ng computation, maghihintay lang sa susunod na token. Ang buong proseso ay hinahawakan ng estado sa GPU, kaya hindi kailangan ng CPU na pumasok sa bawat round para magdesisyon ng susunod na hakbang.

Isinama ng Cursor ang quantization ng MXFP8 sa mga data path ng Dispatch, Grouped GEMM, at SwiGLU, na nag-iwas sa paggamit ng hiwalay na quantize kernel at isang beses na pagbabalik-balik ng pagbasa at pagsulat ng intermediate result sa HBM.

Pagkatapos ilagay ang Pull, minibatch, SM partition, at Ring Buffer nang magkasama, maging tunay na tuloy-tuloy na MoE pipeline ang MoK.

03

Ang benchmark ng Cursor ay sinusukat ang buong MoE layer, kabilang ang Schedule, Dispatch, Expert FFN, Combine, at ang huling weighted combination, na ihahambing sa NCCL + PyTorch, DeepEP, TransformerEngine, at HybridEP + Megatron.

Sa GB300 NVL72, ang MoK ay nagtataglay ng pinakamataas na pagpapabuti ng 2.37 beses sa forward at 1.78 beses sa backward kumpara sa pinakamabilis na publikong baseline sa bawat skenario; ang BF16 ay nagtataglay ng pinakamataas na pagpapabuti ng 1.92 beses sa forward at 1.58 beses sa backward.

Mas mahalaga ang end-to-end training. Ang dating production setup ng Cursor ay gumagamit na ng DeepEP. Pagkatapos ilipat sa MoK sa 512 na GPU ng GB300, tumataas ang throughput per GPU mula sa 760.9 token bawat segundo hanggang 1070.2, isang pagtaas ng halos 41%.

Kailangan din mong malinaw ang mga hangganan ng mga resultang ito. Walang ipinakita ng Cursor ang kompletong ablation sa bawat elemento, kaya hindi makakapagsabi nang tumpak kung gaano karami sa 2.37x ang galing sa Pull, gaano karami sa Megakernel, at gaano karami sa Ring Buffer.

Ang tiyak na pagpapabuti sa paggamit ng NVLink at pagkakalat ng signaling ay mula sa Pull, habang ang iba pang benepisyo ay mas maraming nagmumula sa kombinasyon ng buong pagsasagawa.

Ang MoK ay may malakas na pagkakasalalay sa hardware. Ito ay nakatuon sa mga mabilis na NVLink Domain tulad ng Blackwell at NVL72. Ang remote read, komunikasyon, at pagkalkula ng Pull ay may malalim na pagkaka-ugnay na batay sa kakayahan ng mga GPU na makapag-access ng mababa ang latency sa memory ng isa't isa. Ang Hidden Size, Top-k, at laki ng mga eksperto ng modelo ay nagpapabago din ng angkop na minibatch at bilang ng communication SM.

Ito rin ang pinakamahalagang bahagi ng MoK. Noon, kapag pinag-uusapan ang pag-optimize ng MoE, madaling nakatutok sa dalawang numero: ilang TFLOPS ang GEMM, ilang GB/s ang All-to-All. Sa henerasyon ng GB300, hindi na kayang ipaliwanag ang buong performance sa pagpapataas lang ng dalawang numero na ito.

Kailan darating ang token, paano isayos sa tamang layout na kailangan ng eksperto, ilan ang kailangang ipon bago magsimula ang pagkalkula, ilan ang SM na kukunin sa komunikasyon, kailan babalewalaan ang buffer—ang mga detalye ng pagpapatupad na ito ay diretso nang nagsisimula sa pagtatakda ng bilis ng pagtuturo.

Isang rack na may 130 TB/s na bandwidth ng NVLink, ngunit kailangan pa rin ng pag-rewrite ng GPU kernel para sa MoE: ang link ay nasa mabilis na antas na, at ang dapat i-save ngayon ay ang oras ng GPU at iba pang data.

Ang pag-rewrite ng GPU kernel ng Cursor ay nagmarka ng pagpasok sa isang bagong yugto ng kompetisyon sa AI 2.0 na tinatawag na “full-stack sovereignty”.

dati, naniniwala tayo sa “bawat isa ay may sariling propesyon”—kung gagawa ka ng app, gawin mo lang ang app (Cursor); kung gagawa ka ng base, gawin mo lang ang base (NVIDIA). ngunit ngayon, ang kompetisyon sa AI ay nasa bagong yugto na “pag-alis sa mga gitnang nagbebenta”—hindi ginawa ni Cursor ang kernel dahil “gusto niya”, kundi dahil “kailangan niya”.

Inilunsad ng DeepSeek ang bagong yugto ng engineering extraction, habang sinisigla ng Cursor ang apoy na ito sa application layer. Ang trend na “pag-alis sa mga intermediate” ay nagrere-restructure sa pagkakaroon ng pagpapasya sa presyo ng AI: sa hinaharap, hindi na ang bilang ng mga token na may-ari ng isang AI company ang magdedesisyon sa kanyang valuation, kundi kung gaano kalapit ang kanyang code sa VRAM at registers.

Ang mga AI na kumpanya na hindi makapagpumasok sa ilalim na black box ay magtatira sa kuweba ng “tax ng karaniwan.”