मल्टि-नोड DeepSeek उपयोजनासह कमी लेटन्सी आणि उच्च थ्रूपुट

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

DeepSeek-V3/R1 सारख्या मिक्सचर ऑफ एक्सपर्ट्स (MoE) मॉडेल्सनी अलीकडेच उत्कृष्ट मॉडेल क्षमता आणि कार्यक्षमता दर्शवली आहे. उदाहरणार्थ, DeepSeek-V3/R1 मॉडेलमध्ये एकूण 671B पॅरामीटर्स आहेत, परंतु इन्फरन्स दरम्यान प्रत्येक टोकन केवळ 37B पॅरामीटर्स वापरते. ही मॉडेल आर्किटेक्चर इन्फरन्स सिस्टीमसाठी आव्हाने आणि संधी दोन्ही प्रस्तुत करते.

हा लेख दर्शवतो की, पारंपारिक सिस्टीमच्या विपरीत, बहुतांश परिस्थितींमध्ये मल्टी-नोड उपयोजनांमध्ये अधिक GPU वापरताना DeepSeek-V3/R1 सारखी MoE मॉडेल्स एकाच वेळी उच्च थ्रूपुट आणि कमी लेटन्सी साध्य करू शकतात.

उपयोजन आर्किटेक्चर

विस्तृत करा

विस्तृत करा

मॉडेलमधील मोठ्या संख्येने असलेल्या लहान तज्ञांमुळे (experts), उपयोजना अनेक उपकरणांवर पसरवली पाहिजेत. आम्ही 8xH200 GPU सह एकाच नोडवर सिंगल-नोड उपयोजन आणि 8xH100 GPU सह मल्टि-नोड उपयोजन या दोन्हीचा विचार केला.

दोन्ही उपयोजन आर्किटेक्चर डेटा पॅरालेलिझमचा लाभ घेतात, ज्यांचे नियंत्रण आमच्या इन-हाउस रिक्वेस्ट शेड्युलरद्वारे केले जाते. डेटा पॅरालेलिझमच्या अंमलबजावणीमध्ये अनेक इन्फरन्स इंजिन इन्स्टन्स लाँच करणे समाविष्ट असते, जे प्रत्येक विनंत्या पूर्ण करण्यासाठी आणि राखण्यासाठी स्वतंत्रपणे कार्य करतात. रिक्वेस्ट शेड्युलर, जो GRPC द्वारे इंजिनशी संवाद साधतो, विनंत्या शक्य तितक्या समान रीतीने पसरवण्याचे काम करतो, तसेच KV पुन-वापर सुलभ करतो, कॅशे असलेल्या सर्व्हरना अंशतः जुळलेल्या प्रिफिक्ससह विनंत्या पाठवतो. इंजिन इन्स्टन्स अनेक नोड्सवर पसरलेले नसतात. ते पर्यायीपणे अनेक डिव्हाइसवर अटेंशन शार्ड करण्यासाठी टेन्सर पॅरालेलिझम वापरू शकतात. एकल-नोडच्या बाबतीत इन्स्टन्स NVLink द्वारे किंवा मल्टि-नोडच्या बाबतीत InfiniBand द्वारे परस्पर जोडलेले असतात, जे तज्ञांना पाठवतात आणि गोळा करतात.

सिंगल-नोड उपयोजन कॉन्फिगरेशन लहान बॅच आकारांसह उत्कृष्ट लेटन्सी प्रदान करते; तथापि, वाढलेल्या लोड परिस्थितीमध्ये कार्यक्षमता वेगाने कमी होते.

सर्व्हिंग इंजिन उपयोजित करण्यासाठी, आम्ही एकाधिक इंजिन इन्स्टन्स होस्ट करणारी प्रति नोड एक पॉड लाँच करतो. डिस्ट्रिब्युटेड कम्युनिकेशन सेट अप करण्यासाठी आणि NVSHMEM इनिशलायझेशनवर वाटाघाटी करण्यासाठी PyTorch जबाबदार आहे. संवादासाठी, आम्ही आधीच्या ब्लॉग पोस्ट मध्ये वर्णन केलेल्या कस्टम CUDA कर्नलवर अवलंबून असतो. दोन उपयोजनांची अंमलबजावणी व्यावहारिकदृष्ट्या एकसारखी आहे, ज्यामध्ये मॉडेल एक्स्पर्ट पॅरालेलिझम लागू करणाऱ्या फॅब्रिकवर आधारित वापरण्यासाठी योग्य कर्नल निवडते.

समानांतरकरण तंत्रे

आमच्या कार्यक्षमतेच्या तुलनेत जाण्यापूर्वी, DeepSeek-V3/R1 सारख्या प्रचंड MoE मॉडेल्सची अंमलबजावणी शक्य करणाऱ्या प्रमुख पॅरालेलायझेशन धोरणांना समजून घेणे आवश्यक आहे.

टेन्सर पॅरालेलिझम

LLM इन्फरन्समध्ये, प्रति GPU मेमरी वापर आणि संगणन कमी करण्यासाठी सामान्यतः टेन्सर पॅरालेलिझम (TP) वापरला जातो, ज्यामुळे लेटन्सी कमी होते. सहसा, आपण रो किंवा कॉलम परिमाणांसह अटेंशन आणि MLP लेयर्समधील Linear प्रोजेक्शन शार्ड करू शकतो आणि अटेंशन हेड परिमाणासह अटेंशन ऑपरेशन्स शार्ड करू शकतो.

TP सह, Llama-3 आर्किटेक्चरमध्ये GPU वर Linear प्रोजेक्शन आणि अटेंशन ऑपरेशन्ससाठी कोणतीही डुप्लिकेट संगणना नसते, जी एक आदर्श शार्डिंग पद्धत आहे. तथापि, DeepSeek-V3/R1 मॉडेल्समध्ये, TP हे साध्य करू शकत नाही.

DeepSeek-V3/R1 मॉडेल्स मल्टी-लॅटेंट अटेंशन (MLA) वापरतात. MLA लेयर प्रथम लॅटेंट वेक्टरची गणना करण्यासाठी kv_a_proj Linear प्रोजेक्शन वापरते, नंतर प्रत्येक अटेंशन हेडच्या स्पेसमध्ये रूपांतरित करण्यासाठी दुसरे kv_b_proj Linear प्रोजेक्शन वापरते. सर्व अटेंशन हेड एकच लॅटेंट वेक्टर सामायिक करत असल्यामुळे, TP लॅटेंट वेक्टर शार्ड करू शकत नाही, त्यामुळे सर्व TP रँक्सना kv_a_proj आणि kv_b_proj च्या पॅरामीटर्स आणि संगणनाची प्रतिकृती तयार करणे आवश्यक आहे. त्याचप्रमाणे, MLA KV कॅशेमध्ये लॅटेंट वेक्टर साठवत असल्याने, प्रत्येक TP रँक KV कॅशेची एकसारखी प्रत साठवतो.

MLA मधील काही डुप्लिकेशन असूनही, टेन्सर पॅरालेलिझम अद्याप संगणन मागण्यांमध्ये अंशतः घट प्रदान करते, ज्यामुळे उच्च आउटपुट गती आवश्यक असलेल्या परिस्थितीसाठी ते मूल्यवान बनते.

एक्सपर्ट पॅरालेलिझम

DeepSeek-V3/R1 मॉडेल्स MLP लेयर्सना MoE लेयर्सने बदलतात. एका MoE लेयरमध्ये 256 रूटेड एक्स्पर्ट्स आणि एक सामायिक एक्स्पर्ट असतो. संगणनासाठी प्रत्येक टोकन 8 वेगवेगळ्या रूटेड एक्स्पर्ट्सकडे पाठवले जाते, आणि परिणाम भारित बेरीज केले जातात. प्रत्येक टोकन सामायिक एक्स्पर्टमध्ये देखील संगणन करते, आणि परिणाम रूटेड एक्स्पर्ट्सच्या निकालामध्ये जोडला जातो.

Expert Parallelism (EP) हे MoE Layers साठीचे सामान्य sharding दृष्टिकोन आहे, ज्यामध्ये प्रत्येक GPU 256 / EP routed experts हाताळतो आणि shared expert ची एक प्रत ठेवतो. TP च्या तुलनेत, EP चा फायदा असा आहे की तो computation अधिक GPUs वर वितरित करू शकतो, ज्यामुळे प्रत्येक GPU वरील computation आणि memory usage कमी होते.

एक्सपर्ट संगणन करण्यापूर्वी, सर्व GPU ला ज्या GPU वर संबंधित एक्स्पर्ट्स स्थित आहेत त्यांना टोकन पाठवण्यासाठी AllToAll संवाद करणे आवश्यक आहे; एक्स्पर्ट संगणनानंतर, विविध GPU वरून संगणन परिणाम गोळा करण्यासाठी आणि भारित बेरीज करण्यासाठी आणखी एक AllToAll संवाद आवश्यक आहे. आम्ही NVSHMEM वापरून या दोन AllToAll संवाद कर्नल, डिस्पॅच आणि कंबाईनची ऑप्टिमाइझ केलेली आवृत्ती लागू केली आहे. आमच्या मागील ब्लॉग पोस्ट मध्ये, आम्ही अंमलबजावणीचा तपशील दिला आहे, आणि आमचे कर्नल GitHub वर ओपन-सोर्स केले गेले आहेत.

डेटा पॅरालेलिझम

EP सह, आम्ही 128 किंवा त्याहून अधिक GPU मध्ये MoE संगणन वितरित करू शकतो. तथापि, MLA संगणन EP सह विभागले जाऊ शकत नाही. या टप्प्यावर, आम्ही डेटा पॅरालेलिझम (DP) ओळखू शकतो. प्रत्येक DP ग्रुपकडे MLA लेयरची संपूर्ण प्रत असते. प्रत्येक DP ग्रुप विविध इनपुट स्वीकारतो आणि स्वतंत्रपणे MLA लेयर संगणन करतो.

MLA लेयरचे DP आणि TP एकत्र केले जाऊ शकतात, एक DP ग्रुप अनेक TP रँक्समध्ये विभागला गेला आहे. MoE लेयरचे EP हे MLA लेयरच्या DP/TP सह एकत्र केले जाऊ शकते. EP = DP * TP. उदाहरणार्थ, 16 मशीन्सवर, EP128 DP32 TP4 म्हणजे 128 GPU वर रूटेड एक्स्पर्ट्स वितरीत करणे, दर 4 GPU एक DP ग्रुप तयार करणे, एकूण 32 स्वतंत्र DP ग्रुप्ससाठी.

सिंगल-नोड विरुद्ध मल्टि-नोड

DeepSeek चे 671B पॅरामीटर्स एकाच 8-GPU H100 मशीन (80 GB * 8) च्या मेमरी क्षमतेपेक्षा जास्त आहेत, परंतु एकच 8-GPU H200 मशीन संपूर्ण मॉडेल (141 GB * 8) पूर्णपणे सामावून घेऊ शकते. EP8 DP8 TP1 कॉन्फिगरेशन वापरून, मॉडेल प्रति GPU सुमारे 100 GB मेमरी वापरते, ज्यामुळे KV कॅशे आणि इतर मध्यवर्ती परिणामांसाठी अंदाजे 40 GB शिल्लक राहते. एक टोकन KV कॅशेचे 70,272 बाइट्स व्यापते. समजा प्रत्येक विनंतीमध्ये 5,000 टोकन्स आहेत, प्रत्येक GPU अंदाजे 100 विनंत्या सामावून घेऊ शकतो.

आम्हाला वेगवेगळ्या कॉन्फिगरेशन अंतर्गत सिंगल-नोड आणि मल्टि-नोड उपयोजनांमधील कार्यक्षमतेतील फरक समजून घ्यायचा होता. आम्ही सिंगल-नोड उपयोजनासाठी एक H200 मशीन आणि मल्टि-नोड उपयोजनांसाठी 16 H100 मशीन्सपर्यंत वापरल्या. प्रत्येक उपयोजन वातावरणासाठी, आम्ही TP 1, 2, 4, 8 चे संयोजन आणि प्रति GPU 1, 2, 4, 8, 16, 32, 64, 128 च्या बॅच आकार वापरले. आम्ही गृहीत धरले की प्रत्येक विनंतीमध्ये 5,000 टोकन्सची KV कॅशे लांबी होती. आम्ही असेही गृहीत धरले की मल्टि-टोकन प्रेडिक्शन (MTP) अतिरिक्त 1 टोकनचा अंदाज लावते (म्हणजेच, प्रत्येक विनंतीची क्वेरी लांबी 2 आहे), आणि पुराणमतवादीपणे 60% स्वीकारार्ह दर गृहीत धरला. खालील आकृती वेगवेगळ्या कॉन्फिगरेशनसाठी थ्रूपुट आणि आउटपुट गती दर्शवते.

विस्तृत करा

क्षितिज समांतर अक्ष टोकन्स/से मध्ये प्रति विनंती आउटपुट गती दर्शवतो. उभ्या अक्षावर टोकन्स/से मध्ये प्रति मशीन थ्रूपुट दर्शवण्यासाठी लॉगरिदमिक स्केल वापरले जाते. आम्ही वेगवेगळ्या रंगांच्या रेषांसह प्रत्येक EP कॉन्फिगरेशनसाठी पॅरेटो फ्रन्टिअर चिन्हांकित केले आहे.

अत्यंत उच्च आउटपुट गती आवश्यकता असलेल्या परिस्थितींमध्ये, 1 च्या बॅच आकारासह सिंगल-नोड EP8 DP1 TP8 वापरल्याने 100 टोकन्स/से पेक्षा जास्त आउटपुट गती मिळू शकते, परंतु थ्रूपुट अत्यंत कमी आहे, आउटपुट गतीच्या समतुल्य. या परिदृश्यात, संपूर्ण बॅचमध्ये फक्त 2 टोकन्स आहेत, जे जास्तीत जास्त 2*8=16 एक्स्पर्ट्सकडे पाठवले जाऊ शकतात, एकूण जास्तीत जास्त 57B पॅरामीटर्स सक्रिय करतात.

80-40 टोकन्स/से आउटपुट गती श्रेणीमध्ये, थ्रूपुट वाढल्याप्रमाणे, आउटपुट गती लक्षणीयरीत्या कमी होते. याउलट, समान आउटपुट गतीवर सिंगल-नोड उपयोजनापेक्षा EP128 कडे सुमारे 5x उच्च थ्रूपुट आहे.

सिंगल-नोड डिप्लॉयमेंट कसे वागते याचे परीक्षण करून ही घटना समजावून सांगता येते: बॅच आकार वाढवल्यास सक्रिय झालेल्या तज्ज्ञांची संख्या थेट वाढते. बॅच आकार 1 असताना, प्रति GPU सक्रिय तज्ज्ञांची सरासरी संख्या 2 * 8 / 8 = 2 असते. बॅच पुरेसा मोठा असताना, सर्व तज्ज्ञ सक्रिय होतात, म्हणजे प्रत्येक GPU 256 / 8 = 32 तज्ज्ञ सक्रिय करतो. अधिक तज्ज्ञ सक्रिय करण्याचा अर्थ GPU ला मेमरीमधून अधिक पॅरामीटर्स वाचावे लागतात, ज्यामुळे मेमरी बँडविड्थवरील दाब लक्षणीयरीत्या वाढतो. मोठ्या भाषा मॉडेल्सच्या डिकोड टप्प्यात संगणन कार्यक्षमतेपेक्षा मेमरी बँडविड्थ आधीच मर्यादक घटक असल्यामुळे, सिंगल-नोड डिप्लॉयमेंटमध्ये बॅच आकार वाढवल्याने आउटपुट वेग लक्षणीयरीत्या कमी होतो.

चार मल्टी-नोड डिप्लॉयमेंट संरचनांची (EP16, EP32, EP64, आणि EP128) तुलना दर्शवते की उच्च EP मूल्ये थ्रूपुट आणि आउटपुट वेग यांमध्ये एकाच वेळी सुधारणा घडवत पारेतो फ्रंटियर पुढे नेतात.

उच्च EP क्रमांक वापरल्यास प्रत्येक GPU ला कमी तज्ज्ञ नेमले जातात. उदाहरणार्थ, EP128 म्हणजे प्रत्येक GPU 256 / 128 = 2 तज्ज्ञांसाठी जबाबदार असतो, त्यामुळे मेमरी बँडविड्थवरील दाब लक्षणीयरीत्या कमी होतो. दुसऱ्या शब्दांत, मोठा EP क्रमांक वापरून आपण प्रभावीपणे अधिक मेमरी बँडविड्थ मिळवतो. प्रति-GPU बॅच आकार 64 पेक्षा कमी असताना, बॅच आकार वाढवल्याने तज्ज्ञांच्या संगणन वेगावर लक्षणीय परिणाम होत नाही, कारण इनपुट्सची संख्या वाढवल्याने मेमरी बँडविड्थवरील दाब लक्षणीयरीत्या वाढत नाही. त्यामुळे, EP128 वापरताना बॅच आकार वाढवल्याने आउटपुट वेगावर इतका लक्षणीय परिणाम होत नाही, असे आम्ही पाहतो.

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

मेमरी क्षमतेच्या मर्यादांमुळे, EP8 DP8 TP1 कॉन्फिगरेशन प्रति GPU 128 च्या बॅच आकारापर्यंत पोहोचू शकत नाही, त्यामुळे उच्च थ्रूपुटचा पाठपुरावा करणाऱ्या परिस्थितीमध्ये मल्टि-नोड उपयोजन हा अजूनही एक चांगला पर्याय आहे.

संगणन आणि संवाद ओव्हरलॅपिंग

वर थोडक्यात Expert Parallelism संदर्भात सांगितल्याप्रमाणे, MoE Layer संप्रेषणादरम्यान GPUs निष्क्रिय असतात. हा अपव्यय कमी करून विलंब कमी करण्यासाठी, या निष्क्रिय वेळेत भर घालण्यासाठी डेटा-स्वतंत्र संगणन कार्ये शोधणे आवश्यक आहे.

विस्तृत करा

वरील आकृतीचा वरचा भाग एका लेयरचा संगणन प्रवाह दर्शवितो. MoE संगणन डिस्पॅचवर अवलंबून असते, आणि पुढील लेयरचे संगणन कंबाईनच्या निकालावर अवलंबून असते.

आम्ही प्रत्येक GPU वर सामायिक एक्स्पर्ट ठेवतो. अशा प्रकारे, सामायिक एक्स्पर्ट संगणनाला AllToAll संवादाची आवश्यकता नसते. म्हणून, आपण डिस्पॅच पाठवल्यानंतर लगेचच सामायिक एक्स्पर्ट संगणन करू शकतो, नंतर डिस्पॅच प्राप्त पूर्ण होण्याची प्रतीक्षा करू शकतो. आम्ही या ओव्हरलॅप योजना "डिस्पॅच ओव्हरलॅप" म्हणतो.

डिस्पॅच ओव्हरलॅप सरळ अंमलबजावणी आणि व्यापक लागू करण्याची ऑफर देते. हे तंत्र सर्व EP आकारांमध्ये आणि बॅच आकारांमध्ये सामायिक एक्स्पर्ट संगणन वेळ लपवते.

संगणन आणि संवाद ओव्हरलॅप आणखी वाढवण्यासाठी, डेटा अंमलबजावणी खंडित करण्यासाठी आम्ही DeepSeek तांत्रिक अहवालात नमूद केलेले मायक्रो बॅचिंग वापरले. आकृतीच्या खालच्या भागात दर्शवल्याप्रमाणे, आम्ही एका ट्रान्सफॉर्मर लेयरचे संगणन 5 टप्प्यांत विभागले:

टप्पा 1: InputNorm, QKVProj, AppendKV, BMM

टप्पा 2: BMM, Attn, OProj, PostNorm, Gate

टप्पा 3: डिस्पॅच पाठवा, सामायिक एक्स्पर्ट

टप्पा 4: डिस्पॅच प्राप्त करा, MoE, कंबाईन पाठवा

टप्पा 5: कंबाईन प्राप्त करा

पहिल्या 3 डेंस ट्रान्सफॉर्मर लेयर्समध्ये, आम्ही संपूर्ण बॅच वापरतो. खालील 58 MoE ट्रान्सफॉर्मर लेयर्समध्ये, आम्ही बॅच समान रीतीने दोन मायक्रो बॅचमध्ये विभाजित करतो. दोन मायक्रो बॅच पर्यायीपणे कार्यान्वित होतात, 3 टप्प्यांनी ऑफसेट केले जातात. या दोन मायक्रो बॅचमध्ये कोणताही डेटा अंमलबजावणी नसल्यामुळे, आम्ही डिस्पॅच पाठवल्यानंतर आणि कंबाईन पाठवल्यानंतर इतर मायक्रो बॅचच्या संगणनावर स्विच करू शकतो.

लेटन्सी ब्रेकडाऊन

पुढे, आम्ही प्रयोगाद्वारे ओव्हरलॅपिंगचे परिणाम तुलना करतो, तसेच सिंगल-नोड उपयोजन EP8 आणि मल्टि-नोड उपयोजन EP128 मधील कार्यक्षमतेतील फरक तुलना करतो. तुलना सुलभ करण्यासाठी, आम्ही खालील प्रयोगासाठी H100 GPU वापरले. आम्ही TP1, प्रति GPU 128 चा बॅच आकार, प्रति विनंती 2 ची क्वेरी लांबी आणि 5000 ची KV कॅशे लांबी वापरली.

विस्तृत करा

वरील आकृती एका MoE ट्रान्सफॉर्मर लेयरवर खर्च केलेली एकूण वेळ आणि विविध प्रकारच्या कर्नलचे लेटन्सी प्रमाण दर्शवते. डिस्पॅच, कंबाईन आणि GroupGEMM वगळता, EP8, EP128 NoOverlap, आणि EP128 DispatchOverlap मालिकांमध्ये इतर कर्नलची अंमलबजावणी वेळ समान असावी कारण बॅचचा आकार समान आहे.

ओव्हरलॅपिंग

चला प्रथम तीन ओव्हरलॅपिंग पद्धतींच्या प्रभावांची तुलना करूया. NoOverlap ला एकूण 2667µs लागले, DispatchOverlap ला 2651µs लागले, 16µs किंवा फक्त 0.6% वाचवले. मायक्रोबॅचने खूप महत्त्वपूर्ण सुधारणा दर्शविली, 1896µs घेतले, 29% स्पीडअप. डिस्पॅच आणि कंबाईन दोन्ही वेळ लक्षणीयरीत्या कमी झाले. डिस्पॅच 593µs वरून 367µs पर्यंत कमी झाला, आणि कंबाईन 1012µs वरून 237µs पर्यंत कमी झाला.

लक्षात ठेवा की संगणन कर्नलसाठी, 128 आकाराची बॅच 64 आकाराच्या दोन बॅचमध्ये विभाजित केल्याने एकूण अंमलबजावणी वेळ वाढते. म्हणून, संवादावर खर्च केलेली वेळ 1001µs ने कमी झाली असली तरी, एकूण वेळ फक्त 771µs ने कमी झाली. आम्ही खालील विभागात रूफलाइन मॉडेल वापरून याचे कारण स्पष्ट करू.

या कारणास्तव, मायक्रोबॅचिंग नेहमीच कार्यक्षमता सुधारत नाही.

विस्तृत करा

वरील आकृती बॅच आकार 4-128 साठी DispatchOverlap च्या तुलनेत मायक्रोबॅचची कार्यक्षमता सुधारणा दर्शवते. जेव्हा बॅचचा आकार 32 पेक्षा कमी असतो, तेव्हा मायक्रोबॅच कार्यक्षमता 5%-40% ने कमी करतो. जेव्हा बॅचचा आकार 32 पेक्षा जास्त किंवा समान असतो, तेव्हा मायक्रोबॅच कार्यक्षमता 10%-35% ने सुधारू शकतो.

EP8 विरुद्ध EP128

मागील आकृतीकडे परत जाऊया आणि EP8 आणि EP128 मायक्रोबॅचची तुलना करूया. EP8 ला एकूण 1802µs लागले, EP128 च्या 1896µs पेक्षा थोडे कमी. वरील नमूद केलेल्या मायक्रोबॅचद्वारे आणलेल्या वाढीव कर्नल अंमलबजावणी वेळेव्यतिरिक्त, मुख्य फरक MoE संगणनासाठी वापरल्या जाणाऱ्या GroupGEMM मध्ये आणि दोन संवाद कर्नल, डिस्पॅच आणि कंबाईनमध्ये आहेत.

EP8 चे GroupGEMM ला 555µs लागले, तर EP128 च्या GroupGEMM ला 270µs लागले, अर्ध्याने कमी झाले. हे मल्टि-नोड उपयोजनाचा मूळ फायदा आहे.

दुर्दैवाने, संवादावर खर्च केलेली वेळ 213µs ने वाढली, ज्यामुळे GroupGEMM च्या फायद्याची मोठ्या प्रमाणात भरपाई झाली. आमच्या संवाद कर्नलच्या स्वतंत्र कार्यप्रदर्शन चाचण्यांमध्ये, आम्हाला आढळले की ते केवळ इन्फिनिबँड बँडविड्थच्या अर्धे साध्य करू शकतात. आम्ही आमचे संवाद कर्नल ऑप्टिमाइझ करणे सुरू ठेवू.

आणखी एक कर्नल जो लक्षणीयरीत्या मागे पडतो तो GEMM आहे. मायक्रोबॅचने GEMM 95µs ने वाढवले. खालील रूफलाइन विभागात आम्ही GEMM चे अधिक तपशीलात विश्लेषण करू. आमचा विश्वास आहे की सध्याची GEMM अंमलबजावणी अद्याप इष्टतम कार्यक्षमता साध्य करू शकलेली नाही.

रूफलाइन

कर्नल कार्यक्षमतेचे विश्लेषण करण्यासाठी रूफलाइन मॉडेल एक उत्तम साधन आहे. त्याचा क्षितिज समांतर अक्ष अंकगणित तीव्रता (Arithmetic Intensity), FLOP चे मेमरी I/O बाइट्सचे गुणोत्तर आहे. कर्नलच्या सिमेंटिक्सवरून क्षितिज समांतर अक्षाचे मूल्य थेट मोजले जाऊ शकते. उभा अक्ष साध्य कार्यक्षमता दर्शवतो, बेंचमार्क लेटन्सीद्वारे FLOP विभाजित करून मोजले जाते.

कर्नल कार्यक्षमतेची तात्विक वरची मर्यादा GPU च्या वैशिष्ट्यांद्वारे थेट ठरवली जाते. H100 ची FP8 पीक कार्यक्षमता 1979 TFLOP/s आहे, जी रूफलाइन मॉडेलमध्ये क्षितिज समांतर रेषा म्हणून दर्शवली जाते. H100 ची मेमरी बँडविड्थ 3.35 TB/s आहे, जी मूळ बिंदूमधून जाणाऱ्या रेषेचा उतार म्हणून दर्शवली जाते. दोन रेषा अनुक्रमे संगणन-बाउंड आणि मेमरी-बाउंड कर्नलसाठी कार्यप्रदर्शन मर्यादा देतात.

खाली, आम्ही GroupGEMM आणि GEMM कर्नलच्या कार्यक्षमतेवर चर्चा करतो.

GroupGEMM

MoE मधील GroupGEMM कर्नल खालील संगणन करते: एकूण g ग्रुप्स आहेत, i-व्या ग्रुपमध्ये m_i टोकन्स आहेत, [m_i, k] x [k, n] -> [m_i, n] चे मॅट्रिक्स गुणाकार करते. कार्यप्रदर्शन चाचणीमध्ये, आम्ही गृहीत धरतो की प्रत्येक ग्रुपमधील टोकन्सची संख्या समान आहे, m_i = m म्हणून दर्शवली जाते. नंतर GroupGEMM साठी FLOP संख्या 2 * g * m * k * n आहे, आणि मेमरी I/O बाइट्स g * (m * k + n * k + m * n) आहे.

DeepSeek-V3/R1 मॉडेलमध्ये, 256 एक्स्पर्ट्स आहेत, आणि संगणनासाठी प्रत्येक टोकन 8 एक्स्पर्ट्सकडे पाठवले जाते. 128 चा बॅच आकार, 2 ची क्वेरी लांबी, EP128 DP128 कॉन्फिगरेशन वापरून गृहीत धरून, प्रत्येक एक्स्पर्टला मिळालेल्या टोकन्सची सरासरी संख्या (म्हणजेच, m) 128 * 2 * 8 * 128 / 256 = 1024 आहे. त्याचप्रमाणे, आपण इतर कॉन्फिगरेशन आणि बॅच आकारांसाठी m मोजू शकतो.

आम्ही कार्यप्रदर्शन चाचणीसाठी DeepGEMM ची GroupGEMM अंमलबजावणी वापरली. चाचणी बिंदूंमध्ये TP1 आणि बॅच आकार 1-128 सह EP8, EP16, EP32, EP64, EP128 कॉन्फिगरेशनचे संयोजन समाविष्ट होते.

विस्तृत करा

वरील आकृती वेगवेगळ्या EP कॉन्फिगरेशन अंतर्गत GroupGEMM साठी रूफलाइन मॉडेल दर्शवते. भिन्न EP भिन्न ग्रुप्सच्या संख्येशी संबंधित आहे. आकृती जवळजवळ ओव्हरलॅप होणाऱ्या कार्यप्रदर्शन रेषा स्पष्ट करते, जे दर्शवते की GroupGEMM कार्यक्षमता प्रामुख्याने एकूण टोकन संख्येने ठरवली जाते (g * m म्हणून दर्शवली जाते).

तारे प्रत्येक EP कॉन्फिगरेशनसाठी प्रति GPU 128 च्या बॅच आकाराशी संबंधित डेटा बिंदू चिन्हांकित करतात. या तारांकित डेटा बिंदूंची तुलना करून, आपण पाहू शकतो की जसे EP वाढते (आणि DP समकालिकपणे वाढते), प्रति एक्स्पर्ट टोकन्सची संख्या m देखील वाढते. EP8 वर, m=128, तर EP128 वर, m=2048.

जसे m वाढते, अंकगणित तीव्रता देखील वाढते. बहुतेक कॉन्फिगरेशनमध्ये, GroupGEMM मेमरी बँडविड्थ द्वारे मर्यादित आहे, त्यामुळे m वाढवल्याने कार्यक्षमता सुधारते.

GEMM

GEMM कर्नल मॉडेलमधील Linear प्रोजेक्शनशी संबंधित आहे, जसे की Q/K/V/O प्रोजेक्शन. [m, k] x [k, n] -> [m, n] च्या मॅट्रिक्स गुणाकारासाठी, FLOP संख्या 2 * m * k * n आहे, आणि मेमरी I/O बाइट्स m * k + n * k + m * n आहे. आम्ही बॅच आकार 1-128 साठी लेटन्सी देखील तपासू शकतो.

विस्तृत करा

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

मायक्रोबॅच

मायक्रोबॅचिंग वापरताना, आम्ही बॅच समान रीतीने दोन भागांमध्ये विभाजित करतो. वरील दोन आकृत्यांवरून, आपण पाहू शकतो की जेव्हा m हे m/2 होते, तेव्हा मॅट्रिक्स गुणाकाराची कार्यक्षमता कमी होते. म्हणून, m/2 आकाराचे दोन मॅट्रिक्स गुणाकार कार्यान्वित करणे m आकाराचे एक मॅट्रिक्स गुणाकार कार्यान्वित करण्यापेक्षा जास्त वेळ घेतो.

मल्टी-टोकन प्रेडिक्शन

या संपूर्ण लेखात, आम्ही स्पेक्युलेटिव्ह डिकोडिंगसाठी मल्टि-टोकन प्रेडिक्शन (MTP) वापरल्याचे गृहीत धरले आहे. MTP प्रति विनंती क्वेरी लांबी 1 वरून 2 मध्ये बदलते. मॅट्रिक्स गुणाकारासाठी, हे m ला m * 2 मध्ये बदलण्यासारखे आहे, ज्यामुळे मॅट्रिक्स गुणाकार कार्यक्षमता वाढते. दुसरीकडे, जर आपण MLA साठी रूफलाइन मॉडेल काढले, तर आपल्याला आढळेल की क्वेरी लांबी वाढवल्याने MLA कर्नल कार्यक्षमता लक्षणीयरीत्या वाढते.

म्हणून, मॉडेल कार्यक्षमतेमध्ये MTP चा वापर महत्त्वपूर्ण भूमिका बजावतो.

अंमलबजावणी & इष्टतमता

या विभागात, आम्ही आमच्या DeepSeek-V3/R1 मॉडेलसाठी काही अंमलबजावणी आणि ऑप्टिमायझेशन तपशील सादर करू.

क्वांटायझेशन

DeepSeek-V3/R1 प्रति-ब्लॉक क्वांटायझेशन योजना वापरून FP8 वर मूळतः प्रशिक्षित केले गेले होते, ज्यामध्ये वजने स्थिरपणे क्वांटायझ्ड केली गेली होती आणि सक्रियकरणे ऑन-द-फ्लाय क्वांटायझ्ड केली गेली होती. प्रति चॅनेल किंवा प्रति मॅट्रिक्स स्थिरपणे स्केलिंग फॅक्टर मोजण्याऐवजी, सक्रियकरणांसाठी 128-घटक सदिशांवर आणि मॅट्रिक्ससाठी 128x128 घटक टाइल्सवर स्केलिंग फॅक्टर मोजले जातात, ज्यामुळे क्वांटायझेशनमुळे अचूकता निकृष्टता मर्यादित होते.

Perplexity येथे, आम्ही इन्फरन्सला समर्थन देण्यासाठी CUDA आणि Triton कर्नलच्या मिश्रणावर अवलंबून असतो, ज्यामध्ये CUDA सर्वाधिक कार्यप्रदर्शन-संवेदनशील आणि क्वचितच सुधारित कर्नलसाठी (जसे की अटेंशन आणि GEMM) वापरले जाते, ज्यामध्ये ट्रिटन विस्तृत श्रेणीतील सक्रियकरण, नॉर्मलायझेशन आणि युटिलिटी कर्नल लागू करतो. ट्रिटनने आम्हाला ब्लॉक क्वांटायझेशन योजनेशी कर्नल त्वरीत जुळवून घेण्याची परवानगी दिली.

Linear आणि MoE layers साठी, आम्ही Deep GEMM kernels ना आमच्या स्वतःच्या Triton GEMM kernels सोबत एकत्र करतो, कारण आम्ही लक्षात घेतले आहे की काही matrix dimensions आणि कमी batch sizes साठी Split-K कमी latency देते. जर unquantized layer ने (M, K) x (K, N) multiplication केले, तर block quantization साठी त्याला (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) scaling factor आवश्यक असतो. Block quantization साठी, activations चे scaling factors पूर्व-कॅलिब्रेटेड न ठेवता प्रत्यक्ष वेळेत computed केले जातात. कारण activation scaling factors फक्त K वर एकत्रित केले जातात, M dimension वर नाही, त्यामुळे या योजनेला समर्थन देण्यासाठी kernels ला फक्त किरकोळ बदलांची आवश्यकता असते.

विस्तृत करा

DeepSeek-V3/R1 द्वारे वापरले जाणारे SiLu सक्रियकरण कार्य CUDA आलेख, ब्लॉक क्वांटायझेशन आणि गतिशीलपणे रूटेड टोकन गणनेला समर्थन देण्यासाठी महत्त्वपूर्ण बदलांची आवश्यकता असते. ब्लॉक क्वांटायझेशन समस्याप्रधान असू शकते कारण ते क्षैतिज कपात करते, तथापि कर्नलने आधीच त्यांच्या लपलेल्या परिमाणा along activations 1024 घटकांच्या ब्लॉकमध्ये चन केले होते. एका ब्लॉकमध्ये, सर्वात मोठा निरपेक्ष मूल्य मोजण्यासाठी क्वांटायझ्ड करायचे असलेले टेन्सर 128 च्या ब्लॉकमध्ये पुढे चन केले गेले, ज्यामध्ये ट्रिटनने किमान ओव्हरहेड जोडत कार्यक्षम क्रॉस-वार्ड कमाल कपात तयार केली.

CUDA आलेखा अंतर्गत MoE रूटिंगला समर्थन देण्यासाठी, कर्नलना प्रति एक्स्पर्ट टोकन्सची संख्या दर्शवणारी रूटिंग माहिती माहित असणे आवश्यक आहे, टोकन गणनेची वरची मर्यादा धारण करण्यासाठी वाटप केलेल्या बफरच्या आकारावर आधारित कार्य वेळापत्रक करण्याऐवजी. आम्ही इनपुट टेन्सर परिमाणांवर आधारित समस्या विभाजित करू शकत नाही, त्यामुळे आम्ही पर्झिस्टंट कर्नलची निश्चित संख्या लाँच करतो जी कति टोकन्स भरले आहेत हे ठरवण्यासाठी रूटिंग माहिती वाचतात आणि त्यांच्यामध्ये सक्रियकरणे प्रक्रिया करण्याचे कार्य गतिशीलपणे विभाजित करतात.

आम्ही आमच्या काही kernels आधीच FlashInfer प्रोजेक्टमध्ये upstream केले आहेत आणि भविष्यात आम्ही आमचा अधिक कोड open-source करणार आहोत.

MLA लेयर

आम्ही MLA संगणनासाठी FlashInfer वापरतो. FlashInfer लवचिक पेज टेबल सेटिंग्ज आणि अत्यंत उच्च कार्यक्षमतेला समर्थन देते.

आम्ही q_a_proj आणि kv_a_proj एकाच qkv_a_proj मध्ये फ्यूज केले. लेटन्सी 15.4 µs + 14.8 µs = 30.2 µs वरून 16.7 µs पर्यंत कमी झाली.

आम्ही kv_b_proj चे दोन मॅट्रिक्समध्ये विघटन केले, k_b_proj आणि v_b_proj. या दोन मॅट्रिक्सशी संबंधित संगणनासाठी आम्ही FP8 ब्लॉक क्वांटायझ्ड BMM कर्नल लिहिले.

Cuda आलेख

Cuda आलेख कर्नल लाँचिंग ओव्हरहेड लक्षणीयरीत्या कमी करू शकतो, जे कार्यक्षमतेसाठी अत्यंत महत्त्वाचे आहे. आम्ही प्रत्येक बॅच आकारासाठी Cuda आलेख तयार करतो.

आमचे AllToAll कर्नल विकसित करण्यापूर्वी, आम्ही AllToAll संवादासाठी torch.all_to_all_single() वापरले. या ऑपरेशनसाठी सर्व GPU ला समान बॅच आकार वापरण्याची आवश्यकता असते. तथापि, भिन्न DP ग्रुप्स भिन्न बॅच आकार चालवू शकतात.

all_to_all_single() हे भिन्न बॅच आकार वापरणाऱ्या भिन्न DP ग्रुप्सशी सुसंगत आहे याची खात्री करण्यासाठी, सर्व DP ग्रुप्समधील कमाल बॅच आकार मिळवण्यासाठी आम्ही प्रत्येक मॉडेल चालवण्यापूर्वी प्रथम allreduce() ऑपरेशन वापरले. नंतर आम्ही सर्व DP ग्रुप्सना चालवण्यासाठी हा बॅच आकार वापरण्यास सांगितले.

जरी हा दृष्टिकोन आम्हाला Cuda आलेख वापरू शकतो याची खात्री देतो, तरी त्याचे तीन तोटे आहेत. प्रथम, त्याला अतिरिक्त allreduce() ऑपरेशनची आवश्यकता असते. दुसरे, लहान बॅच आकार असलेले DP ग्रुप्स पॅड करण्यास भाग पाडले जातात. तिसरे, यामुळे आमची अंमलबजावणी कोड जटिल होतो.

आमचे स्वतःचे AllToAll कर्नल लागू केल्यानंतर, आम्हाला सर्व GPU ला समान बॅच आकार वापरण्याची आवश्यकता नाही. म्हणून, आम्हाला आता अतिरिक्त allreduce() ऑपरेशन करण्याची किंवा बॅच आकार पॅड करण्याची आवश्यकता नाही.

MoE रूटर

MoE रूटर ट्रिटनमध्ये लागू केला जातो, मानक पुस्तकातून व्युत्पन्न केलेल्या सुधारित क्रमवारीवर अवलंबून असतो जो क्रमवारी लावलेल्या घटकांचे इंडेक्स देखील ट्रॅक ठेवतो. अंमलबजावणी सर्व MoE मॉडेल्समध्ये सामायिक केली जाते, कारण Mixtral रूटिंग हे DeepSeek रूट्सचे विशेष प्रकरण आहे जिथे टॉप-के ग्रुप सर्व एक्स्पर्ट्सच्या ग्रुपसारखाच असतो. स्पार्स कर्नल थेट टॉप-के इंडेक्स आणि स्कोअर वापरतात, तर सर्व-ते-सर्व वर अवलंबून असलेले डेंस डिस्पॅच/कंबाईन योजनांना प्रति-टोकन आधाराऐवजी प्रति-एक्स्पर्ट रूटिंग माहिती एकत्रित करणे आवश्यक असते.

भविष्यातील काम

भविष्यातील कामात, आम्ही DeepSeek मॉडेलची कार्यक्षमता आणखी ऑप्टिमाइझ करण्याची योजना आखत आहोत.

सर्वात महत्त्वाची पुढील ऑप्टिमायझेशन प्रिफिल डिॲग्रिगेशन आहे. DeepSeek-V3/R1 मॉडेलचा प्रिफिल टप्पा आणि डीकोड टप्प्यात खूप भिन्न संगणकीय वैशिष्ट्ये आहेत. दोन्ही भिन्न ऑप्टिमायझेशन धोरणे आणि उपयोजन योजना वापरू शकतात.

MLA लेयरसाठी, डीकोड टप्प्यात, आम्ही MLA संगणनाची FLOP संख्या कमी करण्यासाठी मॅट्रिक्स अब्जॉर्प्शन वापरतो. प्रिफिल टप्प्यात, प्रथम लॅटेंट वेक्टरला K/V स्पेसमध्ये प्रोजेक्ट करणे आणि नंतर मल्टि-हेड अटेंशन (MHA) फॉर्ममध्ये संगणन करणे अधिक चांगले कार्य करेल.

जर प्रिफिल आणि डीकोड एकाच GPU वर चालत असतील, तर प्रिफिलचा डीकोड आउटपुट गतीवर होणारा प्रभाव कमी करण्यासाठी, आम्ही सामान्यतः प्रिफिलसाठी क्वेरी अनेक डंक्समध्ये विभाजित करण्यासाठी डंक प्रिफिल वापरतो. कारण KV कॅशे लॅटेंट वेक्टर साठवतो, MLA ला MHA फॉर्ममध्ये रूपांतरित करणे कठीण होते.

MoE लेयरसाठी, डीकोड टप्प्यात, प्रति एक्स्पर्ट इनपुट टोकन्सची संख्या वाढवण्यासाठी आम्ही शक्य तितके मोठे EP आणि DP वापरतो, ज्यामुळे GroupGEMM कार्यक्षमता सुधारते. प्रिफिल टप्प्यात, टोकन्सची संख्या आधीपासूनच पुरेशी मोठी असल्यामुळे, GroupGEMM आधीपासूनच संगणन-बाउंड आहे. म्हणून, प्रिफिलसाठी, आम्ही लहान EP आणि DP वापरू शकतो.

जर प्रिफिल आणि डीकोड एकाच GPU वर चालत असतील, जोपर्यंत कोणतीही DP ग्रुप प्रिफिल करत आहे, सर्व GPU वर MoE लेयर्सची लेटन्सी वाढेल, ज्यामुळे डीकोड आउटपुट गतीवर लक्षणीय परिणाम होईल.

प्रिफिल डिॲग्रिगेशन व्यतिरिक्त, आम्ही खालील पैलू देखील ऑप्टिमाइझ करण्याची योजना आखत आहोत:

AllToAll कार्यप्रदर्शन: आमचे AllToAll कर्नल सध्या केवळ इन्फिनिबँड बँडविड्थच्या 1/3 साध्य करू शकते. आम्ही हे कर्नल ऑप्टिमाइझ करणे सुरू ठेवू.

EAGLE-शैलीचे स्पेक्युलेटिव्ह डिकोडिंग:वरील डेटामध्ये, आम्ही 1 टोकनचा अंदाज लावण्यासाठी स्पेक्युलेटिव्ह डिकोडिंग वापरल्याचे गृहीत धरले आहे. EAGLE अनेक टोकन्सचा अंदाज लावण्यासाठी झाड संरचना वापरू शकतो, स्वीकार लांबी सुधारू शकतो, ज्यामुळे आउटपुट गती लक्षणीयरीत्या वाढू शकते.

GEMM कर्नल: पूर्वी दर्शवलेल्या रूफलाइन मॉडेलमध्ये, आपण शोधू शकतो की GEMM कर्नलची कार्यक्षमता अद्याप तात्विक मर्यादेपासून दूर आहे. आम्ही हे कर्नल ऑप्टिमाइझ करणे सुरू ठेवू.

GB200 NVL72: NVIDIA च्या नवीनतम GB200 NVL72 सोल्यूशनमध्ये, 72 ब्लॅकवेल GPU उच्च-गती NVLink द्वारे परस्पर जोडलेले आहेत. MoE आर्किटेक्चर मॉडेल्ससाठी, हे एक खूप मोठे आव्हान आणि संधी आहे.

निष्कर्ष

DeepSeek MoE मॉडेल्सचे मल्टि-नोड उपयोजन ते साध्य करते जे सहसा डेंस LLMs सह अशक्य असते: थ्रूपुट आणि लेटन्सी दोन्ही एकाच वेळी सुधारणे. अधिक GPU मध्ये एक्स्पर्ट्स वितरीत करून, आम्ही प्रति डिव्हाइस मेमरी बँडविड्थचा ताण कमी करतो, जलद प्रक्रिया आणि उच्च सिस्टीम थ्रूपुट सक्षम करतो. आमचे प्रयोग दर्शवतात की सिंगल-नोड उपयोजनांच्या तुलनेत समतुल्य आउटपुट गतीवर EP128 कॉन्फिगरेशन 5x पर्यंत उच्च थ्रूपुट साध्य करतात.

मायक्रो-बॅचिंग सारख्या संगणन-संवाद ओव्हरलॅपिंग तंत्रे मल्टि-नोड संवाद ओव्हरहेड लक्षणीयरीत्या कमी करतात, आमची अंमलबजावणी 40% पर्यंत स्पीडअप दर्शवते. आमचे कस्टम AllToAll संवाद कर्नल आणि ऑप्टिमाइझ केलेल्या कर्नल अंमलबजावणीने 671B पॅरामीटर मॉडेलचे कार्यक्षम उपयोजन सक्षम केले आहे.

MoE आर्किटेक्चर त्यांच्या क्षमतेसाठी लोकप्रिय होत असल्याने, या उपयोजन धोरणे अशा मॉडेल्सना कार्यक्षमतेने स्केल करण्यासाठी मौल्यवान अंतर्दृष्टी प्रदान करतात.

संदर्भ

DeepSeek-V3 तांत्रिक अहवाल

DeepSeek-V3/R1 इन्फरन्स सिस्टीम विहंगावलोकन

Megatron-LM: मॉडेल पॅरालेलिझम वापरून मल्टी-बिलियन पॅरामीटर भाषा मॉडेल्सचे प्रशिक्षण

EAGLE: स्पेक्युलेटिव्ह सॅम्पलिंगसाठी वैशिष्ट्य अनिश्चिततेचा पुनर्विचार करणे आवश्यक आहे

उद्धरण

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}