Cursor का MoK NVIDIA GB300 NVL72 पर 2.37x प्रदर्शन वृद्धि प्राप्त करता है

Cursor ने MoK को ओपन सोर्स किया है, जिसमें टोकन स्केड्यूलिंग, क्रॉस-GPU कम्युनिकेशन और एक्सपर्ट कॉम्प्यूटिंग को एक ही GPU कर्नेल में एकीकृत किया गया है। इस समाधान ने GB300 NVL72 पर MXFP8 फॉरवर्ड के लिए अधिकतम 2.37x और बैकवर्ड के लिए 1.78x का प्रदर्शन वृद्धि प्राप्त की है, 512 GB300 GPU के साथ ट्रेनिंग थ्रूपुट 41% बढ़कर 1070.2 टोकन/सेकंड हो गया है। सिग्नलिंग लेटेंसी 103μs से घटकर 18μs हो गई है। विश्लेषण दर्शाता है कि आज NVLink बैंडविड्थ 130 TB/s तक पहुँच चुका है, इसलिए GPU पर डेटा का समय नया प्रदर्शन बाधा बन गया है; यह क्रांति AI प्रतिस्पर्धा को "पूर्ण स्टैक सार्वभौमिकता" के चरण में प्रवेश कराती है, जहाँ GPU के करीबतम कोड, मेमोरी और रजिस्टर के पास होने वाली कंपनियों को अधिक मूल्य निर्धारण शक्ति प्राप्त होगी।

लेखक, स्रोत: लेफेंगवेन

21 जुलाई को, NVIDIA ने DeepSeek-V3 के प्रशिक्षण के लिए GB300 NVL72 की नवीनतम उपलब्धि घोषित की: 256 GPU पर, प्रति GPU प्रदर्शन 1,648 TFLOPS तक पहुँच गया।

दो सप्ताह से कम समय में, Cursor ने Mixture-of-Kittens, जिसे MoK के नाम से जाना जाता है, को ओपन सोर्स कर दिया। इसने तेज़ मैट्रिक्स गुणन पर ध्यान देने के बजाय, MoE के निष्पादन को फिर से लिख दिया और token स्केड्यूलिंग, GPU के बीच संचार और विशेषज्ञ गणना को एक ही GPU कर्नेल में शामिल कर दिया।

यह थोड़ा अप्रत्याशित है। क्योंकि GB300 NVL72 ने 72 GPU को एक ही NVLink डोमेन में डाल दिया है, जिससे पूरे रैक की NVLink कुल बैंडविड्थ 130 TB/s हो गई है। इस स्पेसिफिकेशन के अनुसार, GPU के बीच डेटा ट्रांसफर पहले से ही पर्याप्त तेज होना चाहिए।

बड़े पैमाने पर MoE प्रशिक्षण में, संचार अभी भी विशेषज्ञ गणना को धीमा कर देता है।

समस्या MoE डेटा स्ट्रीम में है। राउटर प्रत्येक चरण में पुनः निर्णय लेता है कि कौन से टोकन किस विशेषज्ञ को भेजे जाएं, और विशेषज्ञ विभिन्न GPU पर बिखरे हुए होते हैं। टोकन को पहले क्रॉस-कार्ड पर भेजना पड़ता है, गणना के बाद वापस भेजना पड़ता है; भेजने से पहले स्थिति को संगठित करना पड़ता है, और पहुंचने के बाद डेटा की पूर्णता का इंतजार करना पड़ता है। जबकि MXFP8 और Blackwell Tensor Core विशेषज्ञ गणना को लगातार छोटा कर रहे हैं, ये प्रतीक्षाएं जो पहले गणना के पीछे छिपी हुई थीं, अब अधिक स्पष्ट हो रही हैं।

Cursor MoK कर रहा है, और यहीं से शुरू हो रहा है। यह केवल एक Dispatch में कितनी तेजी से डेटा भेजा जा सकता है, इसकी तलाश में नहीं है, बल्कि यह यह तय कर रहा है कि token कैसे विशेषज्ञों तक पहुँचें, कब गणना शुरू हो, और संचार और गणना कैसे GPU का साथ-साथ उपयोग करें।

आज, जब कैलकुलेशन संसाधनों को Blackwell और NVLink के साथ अधिकतम तक पहुंचा दिया गया है, डेवलपर्स को पता चला है: जितना भी हार्डवेयर तेज़ चले, कमजोर सॉफ़्टवेयर ऑर्केस्ट्रेशन को बचाने में असमर्थ है।

MoK का ओपन सोर्स केवल एक कर्नेल की जीत नहीं है, यह "एप्लिकेशन लेयर द्वारा ऑपरेटर की परिभाषा" के युग की शुरुआत को दर्शाता है: अंतिम 30% की कैलकुलेशन क्षमता को निकालने के लिए, AI स्टार्टअप्स एक नीचले स्तर की संप्रभुता के लिए एक अधिकार का युद्ध शुरू कर रहे हैं।

हालांकि, Cursor के इस डिज़ाइन को समझने के लिए, पहले यह स्पष्ट करना जरूरी है कि MoE वास्तव में कहाँ "संचार कर" देता है।

01

MoE का "संचार कर"

सामान्य घने FFN में, टोकन जिन वजनों से होकर गुजरते हैं, वे लगभग स्थिर होते हैं। MoE में राउटर को जोड़ने के बाद, प्रत्येक टोकन अस्थायी रूप से कुछ विशेषज्ञों का चयन करता है। Expert Parallel का उपयोग करते समय, विशेषज्ञों को कई GPU पर विभाजित कर दिया जाता है, इसलिए एक फॉरवर्ड पास में कम से कम दो बार क्रॉस-डिवाइस संचार होता है।

पहला चरण Dispatch है, जिसमें token को विशेषज्ञ के GPU तक भेजा जाता है; जब विशेषज्ञ गणना पूरी कर लेता है, तो Combine के माध्यम से परिणाम token के मूल स्थान पर वापस भेज दिए जाते हैं। प्रशिक्षण में प्रतिगामी प्रसारण भी होता है, जिसके अनुरूप दो और विपरीत दिशा में संचार चरण निष्पादित किए जाते हैं।

अगर आप केवल एक बड़ा निरंतर डेटा ब्लॉक A से B पर ले जा रहे हैं, तो NVLink पर्याप्त तेज़ है। MoE की समस्या यह है कि Router प्रत्येक कदम पर अलग-अलग डेटा वितरण देता है।

किसी विशेषज्ञ के इस चरण में बहुत सारे टोकन मिल सकते हैं, जबकि अगले चरण में कम। सिस्टम को पहले प्रत्येक विशेषज्ञ के पास कितने टोकन हैं, इसकी गिनती करनी होगी, फिर यह तय करना होगा कि ये टोकन लक्ष्य GPU पर कहाँ स्थित हों, और एक ही विशेषज्ञ के डेटा को एक साथ रखना चाहिए। Grouped GEMM को सुव्यवस्थित इनपुट प्राप्त हो सके, जिससे Tensor Core को कुशलतापूर्वक प्रदान किया जा सके।

संचार समाप्त होने के बाद भी तुरंत गणना शुरू नहीं की जा सकती। लक्ष्य GPU को पुष्टि करनी होगी कि दूरस्थ लिखना पूरी तरह पूरा हो गया है और डेटा वास्तव में दृश्यमान है। विशेषज्ञ लोड पूरी तरह समान नहीं होता, कुछ GPU जल्दी समाप्त हो सकते हैं, लेकिन सबसे अधिक व्यस्त विशेषज्ञ के समापन का इंतजार करना पड़ता है।

इसलिए, एक "संचार" चरण में, डेटा स्थानांतरण, लेआउट जनरेशन, सिंक्रनाइज़ेशन और लोड असमानता जैसी कई बातें मिली हुई हैं। 130 TB/s का वर्णन पूरे रैक द्वारा प्रदान किए जा सकने वाले शीर्ष बैंडविड्थ को करता है, लेकिन यह इस बात का प्रतिनिधित्व नहीं करता कि प्रत्येक गतिशील, टुकड़ा-टुकड़ा MoE संचार इन लिंक्स को एक साथ पूरी तरह से भर सकता है।

DeepEP ने डेटा माइग्रेशन को बहुत तेज़ बना दिया है। यह स्वयं Expert Parallel के लिए एक उच्च-प्रदर्शन संचार पुस्तकालय है, जो विशेष रूप से Dispatch और Combine कर्नेल प्रदान करता है, FP8 का समर्थन करता है, और संचार के लिए उपयोग किए जाने वाले SM संख्या को नियंत्रित करने की अनुमति देता है। नवीनतम संस्करण अब स्पष्ट रूप से कम SM के साथ भी उच्च संचार थ्रूपुट बनाए रख सकता है।

एकल स्तर MoE को अभी भी डिस्पैच, ग्रुप्ड GEMM और कॉम्बाइन के बीच लगातार हस्तांतरित करना पड़ता है।

इस समय एक वास्तविक विरोधाभास का सामना करना पड़ता है: यदि पर्याप्त टोकन एकत्रित होने का इंतजार किया जाता है, तो मैट्रिक्स बड़ा होता है, जिससे टेंसर कोर आराम से काम करता है, लेकिन गणना देर से शुरू होती है; यदि थोड़े-थोड़े टोकन आते ही गणना की जाती है, तो संचार और गणना जल्दी से ओवरलैप हो सकते हैं, लेकिन मैट्रिक्स बहुत छोटा होता है, जिससे GPU के कई SM पर पर्याप्त कार्य नहीं होता।

कई CUDA स्ट्रीम आपको संचार और गणना को समानांतर बनाने की अनुमति देते हैं, लेकिन दोनों ओर को सही GPU संसाधन प्राप्त होना सुनिश्चित करना कठिन होता है।

MoK के बाद के डिज़ाइन, आधारभूत रूप से इस "ताल" समस्या को सुलझाने में लगे हुए हैं।

02

MoK का सबसे दिलचस्प बदलावों में से एक, प्रतिक्रिया Dispatch को Push से Pull में बदलना है।

पारंपरिक Push सीधा होता है: जब स्रोत GPU के पास token होता है, तो वह उसे सक्रिय रूप से लक्ष्य GPU में लिख देता है। समस्या लक्ष्य पते में उत्पन्न होती है। एक GPU एक साथ कई अन्य GPU से token प्राप्त करता है।

प्रत्येक प्रेषक को पहले से जानना चाहिए कि वह किस अनुच्छेद में लिखना है, ताकि वे एक दूसरे को ओवरराइट न करें; एक ही विशेषज्ञ के टोकन को लगातार व्यवस्थित किया जाना चाहिए, अन्यथा बाद का GEMM फिर से व्यवस्थित होगा।

जैसे-जैसे भाग लेने वाले GPU बढ़ते हैं, यह शेड्यूलिंग प्रक्रिया भारी होती जाती है। पुल ने एक अलग तरीका अपनाया: विशेषज्ञ के लक्ष्य GPU को स्वयं आवश्यक टोकन पढ़ने के लिए सहेजा जाता है। इसे बस यह जानना होता है कि टोकन किस स्रोत GPU पर है और स्रोत डेटा में कहाँ स्थित है, जहाँ स्थानीय रूप से संग्रहीत किया जाएगा, इसकी व्यवस्था इसकी अपनी होती है।

इससे लक्ष्य पते के लिए कई भेजने वालों के बीच समन्वय की आवश्यकता कम हो जाती है। प्राप्त डेटा को सीधे स्थानीय विशेषज्ञों के अनुसार व्यवस्थित किया जा सकता है।

दिलचस्प बात यह है कि Pull ने कम डेटा नहीं भेजा। Cursor के माइक्रोबेंचमार्क में, एक ही 256×256 BF16 डेटा ब्लॉक के लिए, Push NVLink पर लगभग 159.6 KB स्थानांतरित करता है, जबकि Pull 172.0 KB तक पहुँच जाता है, क्योंकि पढ़ने के लिए अतिरिक्त अनुरोध भेजने पड़ते हैं।

Pull का फायदा एक और बात में है: MoE का संचार टुकड़ा-टुकड़ा है और लोड असमान है। NVLink के दोनों दिशाओं में अलग-अलग चैनल होते हैं, जिससे Pull एक साथ अनुरोध और डेटा लौटाने की दोनों दिशाओं का उपयोग कर सकता है। विशेषज्ञ लोड असमानता के परीक्षण में, Cursor ने NVLink के उपयोग में अधिकतम 29% की वृद्धि दर्ज की।

सिंक्रनाइज़ेशन का अंतर अधिक स्पष्ट होता है। Push के बाद, लक्ष्य GPU को अन्य GPU के पूरा होने के संकेत का इंतजार करना पड़ता है, Expert Parallel के बड़े पैमाने पर, एक rank अधिकतम 71 अन्य peer से संबंधित हो सकता है। Pull में, स्थानीय GPU स्वयं पढ़ना शुरू करता है, और डेटा वापस आने के बाद इसे सीधे उपयोग किया जा सकता है।

Cursor के मल्टी-नोड माइक्रोबेंचमार्क में, इस सिग्नलिंग लेटेंसी को Push से लगभग 103 माइक्रोसेकंड से घटाकर Pull पर 18 माइक्रोसेकंड कर दिया गया।

MoK भी सभी स्थानों पर Pull का उपयोग नहीं करता। फॉरवर्ड पथ पर Pull Dispatch और Push Combine का उपयोग किया जाता है; रिवर्स पथ पर Pull Reverse-Combine और Push Reverse-Dispatch का उपयोग किया जाता है। Dispatch चरण में कई स्रोतों से token को एक्सपर्ट इनपुट में पुनः संगठित करने की आवश्यकता होती है, जिसमें Pull समन्वय के लिए कम संसाधन लेता है; Combine के समय यह स्पष्ट होता है कि प्रत्येक परिणाम किस token में वापस जाना है, इसलिए इसे सीधे Push करना अधिक सरल है।

कम्युनिकेशन दिशा बदलने के बाद, MoK ने कम्युनिकेशन और एक्सपर्ट कॉम्प्यूटिंग को एक ही मेगाकर्नेल में रखा।

यह GPU के SM को दो हिस्सों में बांटता है। एक हिस्सा Dispatch, Combine और स्टेट प्रबंधन के लिए जिम्मेदार है, जबकि दूसरा हिस्सा केवल Expert FFN को निष्पादित करता है। संचार ओर एक पूर्ण token बैच प्राप्त करने के बाद, GPU स्थानीय गिनती के माध्यम से गणना ओर को सूचित करता है; गणना पूरी होने के बाद, यह संचार ओर को सूचित करता है कि परिणाम वापस भेजा जाए।

इससे सीधे निर्धारित किया जा सकता है कि संचार के लिए कितने SM और गणना के लिए कितने SM का उपयोग किया जाए, जिससे कई CUDA Stream के बीच प्रतिस्पर्धा पर पूरी तरह निर्भर नहीं रहना पड़ता। यहाँ सबसे महत्वपूर्ण पैरामीटर minibatch है, जो एक बार में विशेषज्ञों को कितने token दिए जाते हैं, इसे दर्शाता है।

यह बहुत बड़ा नहीं होना चाहिए। बहुत बड़ा होने का मतलब है कि पहली गणना के लिए लंबा इंतजार करना पड़ेगा। यह बहुत छोटा भी नहीं होना चाहिए। विशेषज्ञ GEMM को अंततः कई गणना कार्यों में विभाजित किया जाता है जिन्हें SM को दिया जाता है; यदि token कम हैं, तो कार्यों की संख्या पर्याप्त नहीं होगी और कई SM बेकार रहेंगे।

Cursor इस सीमा को निर्धारित करने के लिए wave का उपयोग करता है। एक पूर्ण wave को सरलता से इस प्रकार समझा जा सकता है कि सभी SM को कार्य मिल गया है। MoK चाहता है कि एक minibatch कम से कम दो पूर्ण wave बनाए, ताकि Tensor Core के पास लगातार कार्य करने के लिए पर्याप्त कार्य हो।

वास्तविक परिणाम बहुत स्पष्ट हैं। Kimi 2.5 के 7168 के छिपे हुए आकार और 2048 के विशेषज्ञ मध्यवर्ती आयाम पर, Cursor अनुमान लगाता है कि minibatch के लिए कम से कम लगभग 2368 टोकन की आवश्यकता होती है। 512 टोकन पर, MoK फॉरवर्ड का समय 5.981 मिलीसेकंड है; 2560 टोकन तक बढ़ाने पर, यह घटकर 3.425 मिलीसेकंड हो जाता है। इसे आगे बढ़ाने पर, गति में कोई स्पष्ट सुधार नहीं होता।

दूसरे शब्दों में, संचार को अधिक छोटे टुकड़ों में तोड़ने से हमेशा तेजी नहीं आती। वास्तविक रूप से कुशल ओवरलैपिंग के लिए, संचार को जल्द से जल्द डेटा देना चाहिए, लेकिन GEMM को बहुत छोटा नहीं करना चाहिए।

लेकिन MoE के पास एक और समस्या है: Router पूरा होने से पहले, यह नहीं जानता कि प्रत्येक GPU को अंततः कितने टोकन मिलेंगे।

अगर आप सबसे खराब स्थिति के लिए buffer तैयार करते हैं, तो बहुत सारा GPU मेमोरी बर्बाद हो जाएगी। अगर आप पहले GPU को token गिनने दें और फिर CPU को संकेत दें कि वह संबंधित स्थान आवंटित करे, तो GPU को CPU का इंतजार करना पड़ेगा।

MoK एक निश्चित आकार के Ring Token Buffer का उपयोग करता है। एक स्थान पहले Dispatch होने वाले token को संग्रहित करता है, और जब विशेषज्ञ गणना पूरी कर लेता है और Combine द्वारा परिणाम ले लिया जाता है, तो यह स्थान तुरंत अगले token समूह के लिए पुनः उपयोग किया जाता है। पिछले macrobatch का Combine, अगले macrobatch के Dispatch के साथ समानांतर रूप से हो सकता है।

रिंग बफर यहाँ एक बफर परत की तरह है: जब संचार अस्थायी रूप से तेज़ होता है, तो डेटा इसमें जमा हो जाता है; जब गणना तेज़ी से उपभोग होती है, तो अगले टोकन के आने का इंतजार किया जाता है। पूरी प्रक्रिया GPU पर स्थिति के आधार पर आगे बढ़ती है, जिससे CPU को हर चक्र में अगला कदम निर्धारित करने की आवश्यकता नहीं होती।

कर्सर ने MXFP8 एक्टिवेशन की क्वांटाइजेशन को डिस्पैच, ग्रुप्ड GEMM और स्विग्लू के डेटा पाथ में शामिल कर दिया है, जिससे अलग quantize kernel की आवश्यकता नहीं है और HBM में मध्यवर्ती परिणाम की एक बार के आवर्तन को भी कम कर दिया गया है।

पुल, मिनीबैच, SM पार्टीशन और रिंग बफर को एक साथ रखने के बाद, MoK वास्तव में एक निरंतर MoE पाइपलाइन बन जाता है।

03

कर्सर का बेंचमार्क पूर्ण MoE परत को मापता है, जिसमें स्केड्यूल, डिस्पैच, एक्सपर्ट FFN, कॉम्बाइन और अंतिम भारित संयोजन शामिल हैं, और इसकी तुलना NCCL + PyTorch, DeepEP, TransformerEngine और HybridEP + Megatron के साथ की गई है।

GB300 NVL72 पर, MoK का MXFP8 फॉरवर्ड में सबसे तेज़ खुले बेसलाइन की तुलना में अधिकतम 2.37 गुना तक बेहतर है और बैकवर्ड में अधिकतम 1.78 गुना तक; BF16 फॉरवर्ड और बैकवर्ड में क्रमशः अधिकतम 1.92 गुना और 1.58 गुना तक सुधार हुआ है।

अधिक महत्वपूर्ण बात यह है कि एंड-टू-एंड ट्रेनिंग। कर्सर के मूल उत्पादन समाधान में पहले से ही DeepEP का उपयोग किया जा रहा था। 512 GB300 GPU पर MoK में बदलने के बाद, प्रति GPU की थ्रूपुट 760.9 टोकन प्रति सेकंड से बढ़कर 1070.2 हो गई, जो लगभग 41% की वृद्धि है।

इस परिणाम समूह की सीमाओं को भी स्पष्ट रूप से देखना चाहिए। कर्सर ने पूर्ण अलग-अलग अपघटन को उजागर नहीं किया है, इसलिए 2.37 गुना में से कितना पुल, कितना मेगाकर्नेल और कितना रिंग बफर से आया है, यह सटीक रूप से कहा नहीं जा सकता।

एकमात्र स्पष्ट रूप से पुष्टि किया जा सकने वाला लाभ Pull द्वारा NVLink के उपयोग और संकेतन देरी में सुधार है; शेष लाभ अधिकांशतः पूरे कार्यान्वयन दृष्टिकोण के संयोजन से प्राप्त होते हैं।

MoK को हार्डवेयर पर भी बहुत अधिक निर्भरता है। यह Blackwell और NVL72 जैसे हाई-स्पीड NVLink डोमेन के लिए डिज़ाइन किया गया है। रिमोट रीड, संचार और कॉम्प्यूटेशन की सूक्ष्म अंतर्निहितता, GPU के बीच परस्पर वीडियो मेमोरी तक निम्न लेटेंसी के साथ पहुँच के आधार पर बनाई गई है। मॉडल के हिडन साइज़, Top-k और एक्सपर्ट स्केल के साथ, उपयुक्त minibatch और संचार SM संख्या भी बदल जाती है।

यही MoK का सबसे दिलचस्प पहलू है। पिछले MoE अनुकूलन पर चर्चा करते समय, लोग आमतौर पर केवल दो संख्याओं पर ध्यान केंद्रित करते थे: GEMM में कितने TFLOPS हैं, All-to-All में कितने GB/s हैं। GB300 पीढ़ी तक पहुँचकर, इन दोनों संख्याओं को आगे बढ़ाने से ही पूरी प्रदर्शन की व्याख्या नहीं हो पाती।

टोकन कब पहुँचेंगे, एक्सपर्ट की आवश्यकतानुसार कैसे व्यवस्थित किया जाए, कितना जमा करने के बाद गणना शुरू होगी, संचार के लिए कितना SM प्राप्त किया जाए, buffer कब रिलीज़ होगा—ये सभी निष्पादन विवरण प्रशिक्षण गति को सीधे निर्धारित करते हैं।

130 TB/s NVLink बैंडविड्थ वाला रैक, अंततः MoE के लिए GPU कर्नेल को पुनः लिखने की आवश्यकता होती है, क्योंकि लिंक पहले ही बहुत तेज है, अब बचाना है GPU और अन्य डेटा का समय।

Cursor द्वारा GPU कोर के व्यवहार को पुनः लिखना, AI 2.0 युग की प्रतिस्पर्धा को "पूर्ण स्टैक संप्रभुता" के नए चरण में ले जाता है।

पहले, हम मानते थे कि "प्रत्येक कार्य के लिए विशेषज्ञता होनी चाहिए", अर्थात् एप्लिकेशन बनाने वालों को केवल एप्लिकेशन (Cursor) बनाना चाहिए और नीचले स्तर के लिए नीचले स्तर (NVIDIA) का ध्यान रखना चाहिए। लेकिन आज की AI प्रतिस्पर्धा "मध्यस्थों को हटाने" के नए चरण में पहुँच गई है, Cursor ने "करना चाहता" होने के कारण नहीं, बल्कि "करना पड़ा" होने के कारण कोर बनाया।

डीपसीक ने इंजीनियरिंग एक्सट्रैक्शन के एक नए युग की शुरुआत की है, और कर्सर ने इस आग को एप्लिकेशन लेयर तक पहुंचा दिया है। इस "मिडिलमैन-हटाने" की प्रवृत्ति AI के मूल्यनिर्धारण को पुनर्गठित कर रही है: भविष्य में, AI कंपनियों के मूल्यांकन का निर्धारण नहीं होगा कि उनके पास कितने टोकन हैं, बल्कि यह होगा कि उनका कोड विस्मृति और रजिस्टर तक कितना करीब है।

जो AI कंपनियाँ नीचे के ब्लैक बॉक्स को नहीं तोड़ पाएंगी, वे अंततः "मामूली कर" की गंदगी में फँसी रहेंगी।