ब्लॅकवेलवर Qwen होस्ट करत आहे

मॉडेलची अचूकता राखून इन्फरन्स खर्च कमी करून, NVIDIA GB200 NVL72 रॅक्सवर Qwen3 235B कसे सर्व्ह करावे.

लेखकPerplexity Research

NVIDIA GB200 NVL72 रॅक्स, ज्यामध्ये 72-वे NVLink द्वारे जोडलेले NVIDIA Blackwell GPUs आहेत, ते मोठ्या मिक्स्चर-ऑफ-एक्सपर्ट्स (MoE) मॉडेल्सच्या उपयोजनासाठी अत्यंत योग्य आहेत. या ब्लॉग पोस्टमध्ये, आम्ही Perplexity च्या ट्रॅफिकचा एक भाग सांभाळणाऱ्या पोस्ट-ट्रेन केलेल्या Qwen3 235B मॉडेल्सना सेवा देणाऱ्या इन्फरन्स सेटअपचे वर्णन करतो. NVIDIA Blackwell GPU चे प्रगत टेन्सर कोअर्स आणि हाय-स्पीड इंटरकनेक्टचा वापर करण्यासाठी आम्ही आमच्या इन-हाउस इन्फरन्स इंजिनमध्ये कशी जुळवाजुळव केली हे आम्ही दाखवतो. या हार्डवेअरसह, आम्ही मूळ मॉडेल्सच्या अचूकतेचा बळी न देता कमी खर्चात अधिक ट्रॅफिक हाताळतो.

GB200 NVL72 वर उपयोजन करत आहे

GB200 NVL72 रॅक्स 18 नोड्सचे बनलेले असतात, ज्यामध्ये 2 ARM-आधारित NVIDIA Grace CPUs आणि 4 Blackwell-आधारित GPUs असतात; प्रत्येकात 180GB HBM सुसज्ज असते. 72 GPUs NVLink आणि 18 NVLink Switch ASICs द्वारे परस्पर जोडलेले आहेत, ज्यामुळे कोणत्याही दोन peers दरम्यान 1800 GB/s बँडविड्थ मिळते आणि ट्रिलियन-parameter मॉडेल्स होस्ट करण्यासाठी पुरेशी memory share केली जाते. याशिवाय, ConnectX-7 InfiniBand adapters रॅकच्या नोड्समध्ये तसेच शेजारील रॅक्समध्ये अतिरिक्त 400 Gb/s बँडविड्थ पुरवतात.

ट्रॅफिक हाताळण्यासाठी, आम्ही Qwen मॉडेल्स पोस्ट-ट्रेन करणे आणि सर्व्ह करणे निवडले. या ब्लॉग पोस्टमध्ये, आम्ही Qwen3 235B वर लक्ष केंद्रित करतो, परंतु चर्चा केलेल्या अनेक सर्व्हिंग तंत्रे आणि कार्यप्रदर्शन वैशिष्ट्ये नवीन Qwen3.5 397B आणि 122B मॉडेल्ससारखीच आहेत ज्यावर आम्ही स्थलांतर करत आहोत. समांतरतेच्या बाबतीत, रेखीय लक्ष (linear attention) हे पूर्ण स्व-लक्ष (full self attention) सारखेच आहे आणि विद्यमान MoE थर अंमलबजावणी नवीन गेट अटी सामावून घेण्यासाठी सहजपणे अनुकूल केली जाऊ शकते. थ्रुपुट जास्तीत जास्त असताना सुसंगत डिकोडिंग दर राखण्यासाठी, आम्ही प्रीफिलला डिकोडपासून विलग करणे निवडले आहे, दोन्ही प्रकारच्या नोड्ससाठी भिन्न समांतरता धोरणे उपयोजित करत आहोत. प्रीफिलर-ते-डिकोडर संप्रेषण InfiniBand वर हाताळले जाते, तर NVLink बँडविड्थ प्रीफिलर्स आणि डिकोडर्समधील संप्रेषणासाठी आरक्षित आहे. या ब्लॉग पोस्टमध्ये शोधलेल्या मॅट्रिक्स गुणाकार आणि डिव्हाइस-दरम्यानचे संप्रेषण करताना ब्लॅकवेल उपकरणांची कार्यप्रदर्शन वैशिष्ट्ये, वापरलेली शार्डींग धोरणे निर्धारित करतात. NVIDIA Hopper GPU च्या तुलनेत, आम्हाला उच्च संख्येने स्ट्रीमिंग मल्टीप्रोसर्स, वाढलेली मेमरी बँडविड्थ आणि कमी पीअर-टू-पीअर लेटन्सीमुळे कर्नल-बाय-कर्नल सुधारणा दिसून येतात.

विखंडित prefill आणि decode, prefillers आणि decoders दरम्यान InfiniBand सह आणि प्रत्येक deployment मध्ये NVLink.

आमचे TransferEngine, जे विलग केलेले प्रीफिल अंमलात आणते, प्रीफिलर्स आणि डिकोडर्समध्ये मनमानी आणि संभाव्य जुळत नसलेले शार्डींग हाताळले. KV कॅशे मेमरीमध्ये HND क्रमाने मांडले जातात, ज्यामध्ये अग्रगण्य मितीमध्ये हेड असतात आणि टोकन्स सलग ठेवले जातात, जेणेकरून प्रीफिलरवरील शार्डेड KV कॅशे डिकोडर नोडला हस्तांतरित करताना आणखी विभाजित किंवा जोडले जाऊ शकतात.

प्रीफिलर्स

प्रीफिलर नोड्स विनंतीचे इनपुट टोकन्स प्राप्त करतात, KV कॅशे पॉप्युलेट करतात आणि मजकूर पिढी सुरू ठेवण्यासाठी त्यांना डिकोडर्सना हस्तांतरित करतात. प्रीफिल संगणकीयदृष्ट्या सघन आहे, कारण अनुक्रमाशी संबंधित हजारो टोकन्स एकाच वेळी प्रक्रिया केले जातात.

परिणामी, आम्हाला आढळले की टेन्सर समांतर उपयोजन योग्य आहे, एकाच GB200 नोडमधील 4 GPUs मध्ये मॉडेल शार्डेड केलेले आहे आणि प्रोजेक्शन आणि एक्सपर्ट्स शार्डेड केलेले आहेत (TP=4, EP=4). ध्यान (attention) आणि MLP दोन्ही कॉम्प्युट-बाउंड असल्याने, दोन्ही समांतरतेचा फायदा घेतात, स्वतंत्र रँकवर तज्ञ आणि ध्यान हेड वितरित करतात. अधिक समांतरतेमुळे कमी परतावा मिळाला असता, कारण प्रत्येक रॅकवर (16 विरुद्ध 32) कमी तज्ञ होस्ट करण्या from थ्रुपुट सुधारणा 8-वे सर्व-रिड्यूसच्या अतिरिक्त खर्चाची आणि इथरनेटवर संप्रेषण आवश्यक असलेल्या दोन नोड्समध्ये होस्ट-साइड कोड विभाजित करण्याच्या ओव्हरहेडची भरपाई करू शकली नसती.

Qwen3 235B मध्ये फक्त 4 की-व्हॅल्यू हेड आहेत, जर 8 उपकरणे वापरली तर k आणि v प्रोजेक्शन रँकच्या जोड्यांवर प्रतिकृती बनवणे आवश्यक आहे. प्रत्येक रॅकवर वजन साठवण्यासाठी आवश्यक असलेली मेमरी कमी करण्यासाठी, KV कॅशेमधील अधिक टोकन्ससाठी जागा मोकळी करण्यासाठी आम्ही अधिक आक्रमक शार्डींगचा विचार करू शकलो असतो. तथापि, आम्हाला आढळले की विस्तृत उपयोजन फायदेशीर नाही.

अंदाजे 6000 टोकन्सची इनपुट लांबी गृहीत धरून, 128 तज्ञांपैकी प्रत्येकजवळ 6000 * 8 / 128 = 375 टोकन्स मार्गस्थ आहेत, जे MoE GEMM साठी दाट समस्या सुनिश्चित करतात. हे आधीच उपकरणाचे संगणकीय थ्रुपुट संपृक्त करत असल्याने, प्रीफिलसाठी डेटा समांतरतेची आवश्यकता नाही.

attention चा खर्च quadratically वाढत असला तरी, prefillers सुसंगत throughput देतात, ज्यामुळे एका node ने एका second मध्ये process करू शकणाऱ्या input tokens चा साधारण अंदाज मिळतो. requests मधून येणाऱ्या input tokens च्या एकूण संख्येचा मागोवा घेणाऱ्या metrics वर अवलंबून, एकूण prefill throughput तदनुसार आकारण्यासाठी prefiller nodes ची संख्या वाढवता येते. queueing टाळण्यासाठी, prefiller replicas ची संख्या प्राप्त झालेल्या input tokens च्या एकूण संख्येशी जुळवली जाते.

डिकोडर्स

डिकोडर नोड्स प्रीफिलर्सकडून KV कॅशे प्राप्त करतात आणि एक-एक करून टोकन्स जनरेट करतात. डिकोड सामान्यतः मेमरी बाउंड असतो: काही इनपुट टोकन्ससह, मॅट्रिक्स गुणाकार पूर्णपणे HBM मधून Tensor Cores मध्ये वजन लोड करण्याच्या खर्चाद्वारे बांधलेला असतो. एक भिन्न शार्डींग धोरण नियोजित करण्याव्यतिरिक्त, संगणन आणि मेमरी प्रवेश अधिक चांगल्या प्रकारे समांतर करण्यासाठी अनेक कर्नल ट्वीक करावे लागतात.

प्रीफिलच्या विपरीत, शार्डींग अटेंशन आता फायदेशीर नाही: अनेक उपकरणांमध्ये अटेंशन हेड विभाजित करण्याचा अर्थ असा होईल की एकाच डिव्हाइसमध्ये समांतरतेसाठी कमी संधी आहेत. परिणामी, केवळ डेटा समांतरता आणि तज्ञ समांतरता वापरली जाते: तज्ञ अनेक उपकरणांवर शार्डेड केले जातात, परंतु प्रत्येक डिव्हाइस स्वतःचे KV कॅशे आणि विनंत्या व्यवस्थापित करते. टेन्सर समांतरतेशिवाय, डिव्हाइसवर प्रति-टोकन KV कॅशे आकार मोठा असतो. तथापि, एकाच नोडवर कमी तज्ञ शोधून मेमरीमध्ये जागा मोकळी केली जाते. हॉपरच्या विपरीत, जिथे आम्ही 8-GPU नोडमधील एकाच NVLink डोमेनमध्ये टेन्सर समांतरता मर्यादित केली, ब्लॅकवेलवर आम्हाला आढळले की डोमेनमध्ये अनेक नोड्सवर विस्तार करणे, 16 पर्यंत उपकरणे वापरणे फायदेशीर आहे.

थ्रुपुट जास्तीत जास्त करण्यासाठी, डिकोडर्स मोठ्या संख्येने विनंत्या एकाच वेळी प्रक्रिया करतात. अतिरिक्त विनंत्या MoE थरांमध्ये आणि इतर प्रोजेक्शनमध्ये किमान ओव्हरहेड करत असतानाही, त्या लक्ष्याचा खर्च असमीप्रमाण (disproportionately) वाढवतात. एक वाजवी किमान डिकोडिंग वेग राखण्यासाठी, प्रति-डिकोडर बॅच आकारांना एका विशिष्ट उंबरठ्याखाली ठेवण्यासाठी डिकोडर नोड्सचे प्रमाण मोजले जाते.

मागील हॉपर उपयोजनांप्रमाणेच, आम्ही डिकोडिंग दर वाढवण्यासाठी घरच्या घरी प्रशिक्षित MTP थरांसह सट्टेबाज डिकोडिंग (speculative decoding) वापरतो. सुदैवाने, मूळ हार्डवेअर आणि प्रोग्रामिंग फ्रेमवर्क दोन आर्किटेक्चरमधील अंमलबजावणी पूर्णपणे सामायिक करण्यासाठी पुरेसे समान आहेत.

नोड-अंतर्गत आणि नोड-दरम्यानचे संप्रेषण

GB200 NVL72 आणि मागील हॉपर नोड्समधील मुख्य फरक म्हणजे मोठा NVLink डोमेन, जो 8 उपकरणांच्या मागील मर्यादेच्या पलीकडे पीअर-टू-पीअर संप्रेषण सक्षम करतो. जरी ब्लॅकवेल उपकरणे 8-GPU नोड्समध्ये उपयोजित केली गेली असली, तरी धीम्या InfiniBand नेटवर्कच्या तुलनेत NVLink वर अनेक नोड्समध्ये स्केल करण्यात बरेच मूल्य आहे.

प्रीफिलर नोड्सवर, आम्ही अटेंशन लेयर्समधील ऑल-रिड्यूस संप्रेषणावर आणि ऑल-रिड्यूसशी अगदी जुळणाऱ्या तज्ञ समांतर रिडक्शनवर अवलंबून असतो. 4 GPUs वर, आम्ही NVLink आणि NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) दोन्हीचा लाभ घेतो: पीअर-टू-पीअर बँडविड्थ व्यतिरिक्त, आम्ही लेटन्सी आणखी कमी करण्यासाठी आणि जलद ब्रॉडकास्ट लागू करण्यासाठी NVLink स्विचमधील रिडक्शनचा देखील फायदा घेतो. डिकोडर नोड्सवर, NVLink वर एक सानुकूल सर्व-ते-सर्व (all-to-all) डिस्पॅच आणि कम्बाइन अंमलबजावणी वापरली जाते. कर्नल CuTeDSL आणि cuMem मॅपिंग किंवा मल्टीकॅस्ट मॅपिंग वापरून इन-हाउस लागू केले गेले आहेत.

सर्व-रिड्यूस (All-Reduce)

प्रीफिलर्स अटेंशन लेयरच्या आउटपुट प्रोजेक्शनमध्ये ऑल-रिड्यूस ऑपरेशन करतात, सहभागी रँकवर शार्डेड केलेल्या हेड्सचे योगदान जोडतात. जेव्हा लहान मॅट्रिक्स गुणाकार समस्येच्या कमी लेटन्सीद्वारे ऑल-रिड्यूस ओव्हरहेडचा खर्च भरून काढला जातो तेव्हाच टेन्सर समांतरता प्रभावी असते. हे गृहीतके सहसा प्रीफिलसाठी लागू होते.

Datacenter-ग्रेड NVIDIA HGX H200 आणि GB200 NVL72 systems वर, GPUs सहसा NVLink Switches द्वारे जोडलेले असतात. routing व्यतिरिक्त, switches SHARP द्वारे connected devices वर reduction operations करू शकतात. CUDA APIs वापरून memory mappings तयार करून आणि त्यांना multicast group मध्ये register केल्यानंतर, kernels switches द्वारे values aggregate आणि broadcast करण्यासाठी multicast.ld_reduce आणि multicast.st वापरू शकतात. इतर kernels मध्ये fuse करता येतील अशा foundation आणि reusable components तयार करण्यासाठी, आम्ही अंतर्गतपणे या primitives वापरून CuTeDSL all-reduce kernel maintain करतो.

B बाइट्स कमी करणाऱ्या N GPUs असलेल्या सिस्टीममध्ये, एका साध्या अंमलबजावणीमध्ये सर्व इतर पिअर्सकडून पिअर्स लोड व्हॅल्यू असतील, ज्या एकूण N * (N - 1) * B बाइट्स वाचण्यासाठी ट्रॅफिक असतील. अधिक कार्यक्षम अंमलबजावणी कमी करण्यासाठी डेटा पिअर्समध्ये विभाजित करेल, प्रत्येक इनपुटचा एक तुकडा कमी करेल, नंतर तो बाकीच्यांवर ब्रॉडकास्ट करेल. यामुळे पीअरमध्ये (N - 1) * (B / N) बाइट्स वाचले जातात आणि बाकीच्यांवर ब्रॉडकास्ट केले जातात, एकूण (N - 1) * B * 2 वाचले आणि लिहिले जातात, ज्यामुळे स्विचवर ट्रॅफिक कमी होते.

GPU-आधारित accumulation आणि switch-सहाय्यित reduction सह NVSwitch all-reduce traffic.

SHARP सह, रिडक्शन आणि ब्रॉडकास्ट अधिक कार्यक्षमतेने केले जाऊ शकतात: स्थानिक संचयासाठी डिव्हाइसमध्ये (N - 1) * (B / N) बाइट्स वाचण्याऐवजी, स्विचमधून फक्त B / N हलवले जातात, कारण तो पीअर्समधील डेटा वापरून स्वतः रिडक्शन करतो. ब्रॉडकास्टसाठी, अशीच सुधारणा आहे, कारण GPU आणि NVLink चॅनेलवरील स्विचमधील व्यवहारांची संख्या मोठ्या प्रमाणात कमी होते. SHARP शिवाय, संचयन करणारी डिव्हाइस स्विचसह NVLink वर (N - 1) * (B / N) व्यवहार करेल, स्विच पीअर्सकडून समान प्रमाणात डेटा वाचेल, एकूण 2 * (N - 1) * (B / N) व्यवहार. SHARP सह, GPU आणि स्विच दरम्यान B / N व्यवहार केले जातात आणि पिअर्ससह आणखी (N - 1) * (B / N), एकूण B व्यवहारांसाठी.

त्याच्या साधेपणा Jंमुळे, SHARP हे एक मौल्यवान साधन आहे, कारण ते अल्गोरिदमसाठी थेट हार्डवेअर अंमलबजावणी प्रदान करते. जरी हस्तांतरण सैद्धांतिक N / (2 * (N - 1)) अंशाने कमी झाले असले (जे 4 पिअर्ससह 33% मोजले जाते), व्यवहारात आम्हाला H200 आणि GB200 NVL72 दोन्ही सिस्टीमवर प्रीफिल आणि डिकोड लेटन्सी दोन्हीमध्ये 10% सुधारणा दिसून येते.

TP=4 आणि 16K tokens सह H200 आणि GB200 वर NVLink आणि NVLS dispatch latency.

MoE डिस्पॅच - कम्बाइन

MoE मॉडेल्ससाठी, डिस्पॅच आणि कम्बाइन कर्नल पिअर्समधील त्यानंतरच्या MoE GEMM समस्यांसाठी टोकन्स हलवतात आणि गटबद्ध करतात, त्यानंतर कम्बाइनमध्ये भारित संचय (weighted accumulation) करतात. आम्ही आमचे विद्यमान डिस्पॅच आणि कम्बाइन कर्नल CuTeDSL वर पोर्ट करून, ब्लॉक वाटप ट्वीक करून आणि प्रीफिल आणि डिकोड दरम्यान त्यांना आक्रमकपणे विशेष करून ब्लॅकवेलशी जुळवून घेतले आहेत.

तज्ञ समांतर (Expert Parallel)

तज्ञ समांतर (EP) कर्नल प्रीफिलर्समध्ये वापरला जातो. याचे इनपुट सर्व रँकवर प्रतिकृती बनवले जात असल्याने, डिस्पॅच कर्नलला सध्याच्या रँकवरील तज्ञांना रूट केलेले टोकन्स फक्त निवडणे आवश्यक आहे. हे रुटिंग माहिती एकत्रित करते आणि MoE GEMM साठी इनपुट म्हणून वापरल्या जाणाऱ्या बफरमध्ये टोकन्स तयार करते. कम्बाइन कर्नल प्रथम वर्तमान रँकवरील तज्ञांना रूट केलेल्या टोकन्सच्या योगदानादरम्यान स्थानिक संचय करतो, नंतर तो सर्व रँकवर ऑल-रिड्यूस करतो.

डिकोडसाठी, संपूर्ण कर्नल एकाचामध्ये फ्यूज केला जातो. प्रीफिल कर्नल अनेक कर्नलमध्ये विभाजित केला जातो, कारण रुटिंग आणि ऑल-रिड्यूससाठी स्थानिक कम्बाइन स्टेपपेक्षा कमी ब्लॉक्सची आवश्यकता असते. CuTeDSL सह, आम्ही SHARP आणि NVLink ऑल-रिड्यूस आणि पीअर-टू-पीअर सिंक्रोनायझेशन दोन्हीसाठी एक सामान्य लायब्ररी तयार करू शकतो, जी ऑल-रिड्यूस आणि तज्ञ समांतर कर्नल दोन्हीमध्ये कंपोझ करू शकतो.

विविध expert-parallel configurations मध्ये H200 आणि GB200 वर expert-parallel prefill dispatch आणि combine latency.

कार्यक्षमतेच्या बाबतीत, आम्हाला आढळले की सुधारित हस्तांतरण गती, उच्च मेमरी बँडविड्थ आणि चांगल्या संगणकीय थ्रुपुटमुळे ब्लॅकवेल हॉपरपेक्षा लक्षणीयरीत्या वेगवान आहे. GB200s (EP=8) वर 8 उपकरणांवर आणि अनेक नोड्सवर शार्डेड केलेले, कर्नल वेगवान होतात कारण स्थानिक संचय प्रत्येक डिव्हाइसवर खूप कमी टोकन्सवर चालतो आणि SHARP सह, अधिक रँक मधील रिडक्शनचा खर्च अधिक चांगला स्केल होतो. तथापि, प्रत्यक्षात, आम्ही समांतरता 4 उपकरणांपर्यंत मर्यादित करतो, कारण हे गतीवर्धन सर्व कर्नलमध्ये सार्वत्रिक नाहीत.

डेटा समांतर आणि तज्ञ समांतर

डेटा समांतर आणि तज्ञ समांतर (DP-EP) कर्नल डेटा समांतर डिकोडर्समध्ये वापरला जातो. हे सर्व रँकमधील विविध टोकन्स तज्ञांना ब्रॉडकास्ट करते, परिणाम मूळ रँकमध्ये हस्तांतरित करते आणि ते जमा करते. हे विरल (sparse) ऑल-टू-सर्व समस्या लागू करत असल्याने, हे केवळ NVLink वर अवलंबून असते.

हॉपरवर, हा कर्नल एकाच नोडच्या NVLink डोमेनमध्ये 8 उपकरणांपुरता मर्यादित आहे. तथापि, GB200 सिस्टमवर आम्ही ते संपूर्ण रॅकवर स्केल करू शकतो. बहुतेक कोड पुन्हा वापरला जातो. प्रारंभिक सेटअपसाठी IMEX वर पीअर माहितीची अदलाबदल करण्यासाठी fabric हँडलचा वापर करणे हाच एकमेव फरक आहे.

data-parallel आणि expert-parallel configurations मध्ये GB200 dispatch आणि combine latency.

डिकोड दरम्यान होणारे हस्तांतरण आकार लहान असल्याने, ते NVLink बँडविड्थ संपृक्त करण्यापासून दूर आहेत आणि त्याऐवजी लेटन्सी-मर्यादित आहेत. लेटन्सी दशकाणू मायक्रोसेकंदात आहेत आणि पिअर्सची संख्या वाढल्याप्रमाणे तुलनेने स्थिर राहतात, ज्यामुळे आम्हाला महत्त्वपूर्ण अतिरिक्त लेटन्सीशिवाय मोठ्या संख्येने उपकरणांवर उपयोजन पसरवता येते.

MoE GEMM

MoE मॉडेल्स तज्ञ समांतरतेचा फायदा घेतात, कारण सर्व तज्ञांसह सर्व टोकन्स गुणाकार करण्याचा खर्च अनेक उपकरणांवर सहजपणे समांतर केला जाऊ शकतो. प्रीफिलर्सवर टेन्सर समांतरतेसह, दाट समस्यांवर फायदा अगदी सोपा आहे, कारण प्रत्येक रँकला आता कमी संगणन करावे लागते. डिकोडच्या बाबतीत, डेटा समांतरता तज्ञ समांतरतेच्या वर एक अतिरिक्त फायदा प्रदान करते, कारण समांतर विनंत्यांची अधिक संख्या प्रत्येक तज्ज्ञाला अधिक टोकन्स मार्गस्थ करते, ज्यामुळे समस्या घन होतात.

आमच्या अंमलबजावणीमध्ये, आम्ही सध्या मॅट्रिक्स गुणाकारासाठी CUTLASS CUDA/C++ कर्नलवर अवलंबून आहोत. डिकोडर्ससाठी इष्टतम शार्डींग धोरण ठरवण्यासाठी आम्ही विविध प्रमाणीकरण योजना आणि समांतरतेच्या पातळीसह विरल डिकोड इनपुटवर त्यांचे बेंचमार्क केले. खालील बेंचमार्कवर, सर्व तज्ञ एकाच टोकनसह सक्रिय केले जातात.

H200 आणि GB200 वर विविध expert-parallel configurations आणि quantization schemes मध्ये grouped MoE GEMM latency.

आम्हाला आढळले की 16 पेक्षा जास्त रँकवर 128 तज्ञांचे स्केल केल्याने CUTLASS सह कमी परतावा मिळतो, कारण 2 तज्ञांचा गुणाकार करणे हे 4 च्या गुणाकारापेक्षा लक्षणीयरीत्या कमी नाही. उप-इष्टतम ब्लॉक स्केलिंग धोरणावरही हॉपरवर ब्लॅकवेलवर स्पष्ट सुधारणा आहे. डिस्पॅच/कम्बाइनच्या EP=8 आणि EP=16 मधील सुमारे 5 us च्या लेटन्सी वाढीची भरपाई GEMM च्या खर्चात 10 us पेक्षा जास्त घट झाल्यामुळे होत असल्याने, GB200 सिस्टमवर, डिकोडर्सना 16 रँकवर शार्डींग करणे न्याय्य आहे, ज्याची पुष्टी एंड-टू-एंड बेंचमार्कने देखील केली आहे.

प्रमाणीकरण (Quantization)

ब्लॅकवेल नवीन 8-बिट आणि 4-बिट प्रमाणीकरण योजनांसाठी हार्डवेअर समर्थन सादर करते. हॉपरच्या विपरीत, जे प्रति-टेन्सर किंवा प्रति-ब्लॉक स्केलिंग घटकांवर अवलंबून होते, ब्लॅकवेलला सर्वोत्तम प्रीफिल आणि डिकोड थ्रुपुट साध्य करण्यासाठी मायक्रोस्केलिंगची आवश्यकता असते. DeepSeek किंवा Kimi सारख्या मॉडेल्ससाठी वापरलेले ब्लॉक स्केलिंग धोरण उपलब्ध असताना, मायक्रोस्केलिंग अधिक कार्यक्षम आहे.

मोडेल फाईन-ट्यून केल्यानंतर स्टॅटिकली वजनाचे रूपांतर करून आम्ही MXFP8 प्रमाणीकरण योजनेस 235B Qwen3 उपयोजित केले आहे. अचूकतेचा प्रभाव स्टोचॅस्टिक प्रमाणीकरणासह ब्लॉक स्केलिंगच्या प्रभावासारखाच होता, परंतु प्रदान केलेले कार्यप्रदर्शन खूप सुधारले होते, जसे की MoE GEMM मायक्रोबेंचमार्कद्वारे स्पष्ट केले आहे. आम्ही MXFP4 आणि NVFP4 प्रमाणीकरण योजनांचा देखील विचार केला आहे, जरी क्वांटायझेशन-अव्वेअर ट्रेनिंगशिवाय अचूकतेचा प्रभाव हॉपरवरून ब्लॅकवेलच्या प्रारंभिक स्थलांतरासाठी खूप महत्त्वपूर्ण होता. भविष्यातील कामात या स्वरूपांचा अधिक कसून शोध घेण्याची हमारी योजना आहे.

एंड-टू-एंड कार्यप्रदर्शन

आम्ही ब्लॅकवेल Qwen3 235B उपयोजनांच्या डिकोडर्सचे बेंचमार्क केले आणि त्यांची आमच्या मागील हॉपर उपयोजनांशी तुलना केली. या सेटअपमध्ये, समांतरतेच्या प्रभावावर लक्ष केंद्रित करण्यासाठी आम्ही दोन्ही उपयोजनांमध्ये ब्लॉक स्केलिंगचा विचार केला. डिकोड कार्यप्रदर्शन वेगळे करण्यासाठी दोन्ही आर्किटेक्चरसाठी TP=4 प्रीफिलर्स वेगळे केले गेले. आमच्या MTP स्तरांद्वारे वितरीत केलेला वास्तववादी ड्राफ्ट स्वीकृति दर गृहीत धरून खालील आकृती डिकोडिंग थ्रुपुट स्पष्ट करते.

draft acceptance length 0.8 गृहीत धरून, H200 आणि GB200 expert-parallel configurations मध्ये Qwen3 235B FP8 decoding speed आणि प्रति GPU throughput.

हॉपरवर, 8 पेक्षा जास्त GPUs वर उपयोजन शार्डींग करणे शक्य नाही, कारण InfiniBand मधील लेटन्सी, विशेषतः EFA अडॅप्टर्सवर, लक्षणीयरीत्या धीमी आहे. तथापि, ब्लॅकवेलवर, मोठ्या NVLink डोमेनमुळे, आम्ही लक्षणीयरीत्या उच्च थ्रुपुट साध्य करतो.

विद्यमान हॉपर कर्नलचे सामान्यीकरण करून आणि NVLink-आधारित कर्नलचे कार्यप्रदर्शन वाढवून आम्ही प्रारंभिक ब्लॅकवेल अंमलबजावणी साध्य केली. प्रमाणीकरण सुधारून आणि पाइपलाइनमधील इतर कर्नलचे डिकोड कार्यप्रदर्शन आणि प्रीफिल थ्रुपुट फाईन-ट्यून करून आम्ही Qwen सेवा देण्याचा खर्च आणखी कमी करू.

संदर्भ

Transfer Engine blog post

CuTeDSL blog post

Prefill-Disagg blog post

Speculative Decoding blog post

CUTLASS

NVLink

उद्धरण

BibTeX
@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}