लेख
मल्टी-नोड दीपसीक डिप्लॉयमेंट द्वारा कम विलंबता और अधिक थ्रूपुट
अधिकांश प्रणालियों में, विलंबता और थ्रूपुट अक्सर विरोधी लक्ष्य होते हैं जिनके लिए डिज़ाइन और परिनियोजन के दौरान समझौते की आवश्यकता होती है। उदाहरण के लिए, घने बड़े भाषा मॉडल में, बैच आकार बढ़ाने से थ्रूपुट में सुधार हो सकता है लेकिन इसके साथ विलंबता भी बढ़ जाती है; एकल मशीन के भीतर टेंसर पैरेललिज़्म बढ़ाने से विलंबता घट सकती है लेकिन प्रतिकृतियों की संख्या कम हो जाती है, जिससे थ्रूपुट कम होता है।
दीपसीक-वी3/आर1 जैसे विशेषज्ञों के मिश्रण (MoE) मॉडल ने हाल ही में उत्कृष्ट मॉडल क्षमताएं और संचालन क्षमता का प्रदर्शन किया है। उदाहरण के लिए, दीपसीक-वी3/आर1 मॉडल में कुल 671B पैरामीटर हैं, लेकिन अनुमान के दौरान प्रत्येक टोकन केवल 37B पैरामीटर उपयोग करता है। यह मॉडल आर्किटेक्चर अनुमान प्रणालियों के लिए दोनों चुनौतियाँ और अवसर पेश करता है।
यह लेख दर्शाता है कि, पारंपरिक प्रणालियों के विपरीत, दीपसीक-वी3/आर1 जैसे MoE मॉडल अधिकांश परिदृश्यों में कई नोड तैनाती में अधिक जीपीयू का उपयोग करते समय उच्च थ्रूपुट और कम विलंबता एक साथ प्राप्त कर सकते हैं।
तैनाती आर्किटेक्चर
मॉडल में छोटे विशेषज्ञों की बड़ी संख्या के कारण, तैनातियों को कई उपकरणों में फैलाना आवश्यक है। हमने 8xH200 GPUs के साथ एकल नोड पर तैनाती और 8xH100 GPUs पर बहु-नोड तैनातियों दोनों को विचार किया।
दोनों तैनाती आर्किटेक्चर डेटा पैरेललिज़्म का लाभ उठाते हैं, जो हमारे इन-हाउस अनुरोध शेड्यूलर के माध्यम से समन्वित होता है। डेटा पैरेललिज़्म कार्यान्वयन में कई अनुमान इंजन इंस्टेंस लॉन्च करना शामिल है, प्रत्येक स्वतंत्र रूप से अनुरोधों को सेवा देने और बनाए रखने के लिए कार्य करता है। अनुरोध शेड्यूलर, जो इंजन के साथ GRPC के माध्यम से बातचीत करता है, अनुरोधों को जितना संभव हो समान रूप से फैलाने के लिए जिम्मेदार होता है, साथ ही KV पुन: उपयोग को भी सुविधा प्रदान करता है, आंशिक मेल वाले पूर्वसर्ग के साथ अनुरोधों को कैश वाले सर्वरों को भेजता है। इंजन इंस्टेंस कई नोड्स में नहीं फैलते। वे विकल्प के तौर पर टेंसर पैरेललिज़्म का उपयोग कर सकते हैं ताकि ध्यान को कई उपकरणों में विभाजित किया जा सके। इंस्टेंस एकल-नोड मामले में NVLink के माध्यम से या बहु-नोड मामले के लिए InfiniBand के माध्यम से इंटर-कनेक्ट होते हैं, विशेषज्ञों को भेजने और एकत्र करने के लिए।
एकल-नोड तैनाती विन्यास छोटे बैच आकारों के साथ बेहतर विलंबता प्रदान करता है; हालांकि, प्रदर्शन बढ़ते भार की स्थिति में तेजी से बिगड़ जाता है।
सेवा इंजन को तैनात करने के लिए, हम कई इंजन इंस्टेंस होस्टिंग प्रत्येक नोड पर एक पॉड लॉन्च करते हैं। PyTorch वितरित संचार स्थापित करने और NVSHMEM प्रारंभिक वार्ता के लिए उत्तरदायी है। संचार के लिए, हम पहले बनाए गए ब्लॉग पोस्ट में वर्णित कस्टम CUDA कर्णेल्स पर भरोसा करते हैं। इन दो तैनातियों का कार्यान्वयन व्यावहारिक रूप से समान है, मॉडल द्वारा सही कर्णेल्स का चयन किया जाता है जो विशेषज्ञ पैरेललिज़्म को लागू करने वाले तंतु के आधार पर उपयोग करते हैं।
पैरेललिज़ेशन तकनीकें
हमारे प्र desempeño तुलना में आने से पहले, यह महत्वपूर्ण है कि गहरी पैरेललिज़ेशन रणनीतियों को समझना आवश्यक है जो विशाल MoE मॉडल जैसे दीपसीक-वी3/आर1 को तैनात करने को संभव बनाती हैं।
टेंसर पैरेललिज़्म
LLM अनुमान में, टेंसर पैरेललिज़्म (TP) आमतौर पर मेमोरी उपयोग और प्रत्येक GPU प्रति गणना को घटाने के लिए उपयोग किया जाता है, जिससे विलंबता कम होती है। आम तौर पर, हम अटेन्शन और MLP परतों में लीनियर प्रोजेक्शन को रो या कॉलम आयाम के साथ विभाजित कर सकते हैं, और अटेन्शन ऑपरेशनों को अटेन्शन हेड आयाम के साथ विभाजित कर सकते हैं।
TP के साथ, Llama-3 आर्किटेक्चर में GPU में लीनियर प्रोजेक्शन और अटेन्शन ऑपरेशनों के लिए कोई दोहराई गणना नहीं होती है, जो कि आदर्श विभाजन विधि है। हालांकि, दीपसीक-वी3/आर1 मॉडल में, TP इसे प्राप्त नहीं कर सकता।
दीपसीक-वी3/आर1 मॉडल मल्टी-लटेंट अटेन्शन (MLA) का उपयोग करते हैं। एक MLA परत पहले एक लीनियर प्रोजेक्शन kv_a_proj का उपयोग करके लटेंट वेक्टर को गणना करता है, फिर इसे प्रत्येक अटेन्शन हेड के स्पेस में बदलने के लिए एक और लीनियर प्रोजेक्शन kv_b_proj का उपयोग करता है। जब सभी अटेन्शन हेड एक ही लटेंट वेक्टर साझा करते हैं, TP लटेंट वेक्टर को विभाजित नहीं कर सकता, इसलिए सभी TP रैंक kv_a_proj और kv_b_proj के पैरामीटर और गणना को दोहराना चाहिए। इसी प्रकार, चूंकि MLA लटेंट वेक्टर को KV कैश में स्टोर करता है, प्रत्येक TP रैंक KV कैश की एक समान प्रति रखता है।
MLA में कुछ दोहराव के बावजूद, टेंसर पैरेललिज़्म अभी भी गणना मांगों में आंशिक कमी प्रदान करता है, जिससे यह उन परिदृश्यों के लिए मूल्यवान बनता है जिनके लिए उच्च आउटपुट गति की आवश्यकता होती है।
विशेषज्ञ पैरेललिज़्म
दीपसीक-वी3/आर1 मॉडल MLP परतों को MoE परतों के साथ बदलते हैं। एक MoE परत में 256 रूटेड विशेषज्ञ होते हैं और एक साझा विशेषज्ञ होता है। प्रत्येक टोकन को 8 विभिन्न रूटेड विशेषज्ञों को गणना के लिए भेजा जाता है, और परिणाम वेटेड सम जोड़ दिए जाते हैं। प्रत्येक टोकन साझा विशेषज्ञ में भी गणना करता है, और परिणाम रूटेड विशेषज्ञों के परिणाम में जोड़ दिया जाता है।
विशेषज्ञ पैरेललिज़्म (EP) MoE परतों के लिए सामान्य विभाजन दृष्टिकोण के रूप में कार्य करता है, प्रत्येक GPU 256 / EP रूटेड विशेषज्ञों को प्रबंधित करता है जबकि साझा विशेषज्ञ की प्रति को बनाए रखता है। TP की तुलना में, EP का लाभ यह है कि यह गणना को अधिक GPUs में वितरित कर सकता है, जिससे प्रत्येक GPU प्रति गणना और मेमोरी उपयोग कम हो जाता है।
विशेषज्ञ गणना करने से पहले सभी GPUs को वह GPUs जहाँ संबंधित विशेषज्ञ स्थित होते हैं उन्हें टोकन भेजने के लिए AllToAll संचार करना चाहिए; विशेषज्ञ गणना के बाद, विभिन्न GPUs से गणना परिणाम एकत्र करने और वेटेड सम करने के लिए एक और AllToAll संचार आवश्यक है। हमने NVSHMEM के उपयोग से इन दो AllToAll कम्युनिकेशन कर्णेल्स, Dispatch और Combine का एक अनुकूलित संस्करण लागू किया है। हमारे पिछले ब्लॉग पोस्ट में, हमने कार्यान्वयन का विवरण दिया है, और हमारे कर्णेल्स को GitHub पर ओपन-सोर्स कर दिया गया है।
डेटा पैरेललिज़्म
EP के साथ, हम MoE गणना को 128 या अधिक GPUs में वितरित कर सकते हैं। हालाँकि, 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 GPUs में रूटेड विशेषज्ञों को वितरित करना है, जिसमें प्रत्येक 4 GPUs एक DP समूह बनाते हैं, कुल 32 स्वतंत्र DP समूहों के लिए।
एकल-नोड बनाम बहु-नोड
दीपसीक के 671B पैरामीटर एकल 8-GPU H100 मशीन (80 GB * 8) की मेमोरी क्षमता से अधिक हैं, लेकिन एकल 8-GPU H200 मशीन में पूरे मॉडल को पूरी तरह से रखा जा सकता है (141 GB * 8)। EP8 DP8 TP1 विन्यास का उपयोग करते समय, मॉडल लगभग 100 GB मेमोरी प्रति GPU का उपयोग करता है, लगभग 40 GB KV कैश और अन्य मध्यवर्ती परिणामों के लिए छोड़ता है। एक टोकन 70,272 बाइट्स KV कैश का उपयोग करता है। मान लेते हैं प्रत्येक अनुरोध में 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 विन्यास के लिए भिन्न रंग की लाइनों के साथ पारेटो फ्रंटियर को चिह्नित किया है।
अत्यधिक उच्च आउटपुट गति आवश्यकताओं वाले परिदृश्यों में, EP8 DP1 TP8 के साथ एकल-नोड का उपयोग करते समय बैच आकार 1 से आउटपुट गति 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 विन्यास 128 के बैच आकार तक प्रति GPU नहीं पहुँच सकता है, नहीं पहुँच सकता है, इसलिए उच्च थ्रूपुट का पीछा करते हुए परिदृश्यों में बहु-नोड तैनाती अभी भी बेहतर विकल्प है।
गणना और संचार ओवरलैपिंग
जैसा कि ऊपर विशेषज्ञ पैरेललिज़्म के बारे में संक्षेप में पेश किया गया है, GPUs MoE परत संचार के दौरान निष्क्रिय रहते हैं। अपव्यय को कम करने और विलंबता को घटाने के लिए, हमें इस निष्क्रिय समय को भरने के लिए डेटा-अस्वतंत्र गणना कार्यों का पता लगाना होगा।
उपरोक्त चित्र का ऊपरी भाग एक परत के एक गणना प्रवाह को दिखाता है। MoE गणना डिस्पैच पर निर्भर करती है, और अगली परत की गणना कॉम्बाइन के परिणाम पर निर्भर करती है।
हमने प्रत्येक GPU पर साझा विशेषज्ञ को रखा है। इस प्रकार, साझा विशेषज्ञ गणना को डिस्पैच भेजने के तुरंत बाद किया जा सकता है, फिर डिस्पैच रसीव समाप्त तक प्रतीक्षा की जाती है। हम इस ओवरलैप स्कीम को "डिस्पैच ओवरलैप" कहते हैं।
डिस्पैच ओवरलैप सरल कार्यान्वयन और व्यापक अनुप्रयोगीयता प्रदान करता है। यह तकनीक सभी EP आकारों और बैच आकारों में साझा विशेषज्ञ गणना समय को छुपाती है।
गणना और संचार ओवरलैप को और बढ़ाने के लिए, हमने माइक्रो बैचिंग का उपयोग किया जैसा कि दीपसीक तकनीकी रिपोर्ट में उल्लेखित किया गया है जिससे डेटा निर्भरता का इलेकहान हो। जैसा कि चित्र के निचले भाग में दिखाया गया है, हमने एक ट्रांसफार्मर परत की गणना को 5 चरणों में विभाजित किया:
चरण 1: इनपुट नॉर्म, QKV प्रोज, अपरंड KV, BMM
चरण 2: BMM, अटेन्शन, O प्रोज, पोस्ट नॉर्म, गेट
चरण 3: डिस्पैच भेजें, साझा विशेषज्ञ
चरण 4: डिस्पैच रसीव, MoE, कॉम्बाइन भेजें
चरण 5: कॉम्बाइन रसीव
पहले 3 घने ट्रांसफार्मर परतों में, हम पूरे बैच का उपयोग करते हैं। निम्नलिखित 58 MoE ट्रांसफार्मर परतों में, हम बैच को दो माइक्रो बैचों में समान रूप से विभाजित करते हैं। दो माइक्रो बैच वैकल्पिक रूप से चलाए जाते हैं, 3 चरणों में ऑफसेट करते हुए। चूंकि इन दो माइक्रो बैचों के बीच कोई डेटा निर्भरता नहीं है, डिस्पैच भेजने के बाद और कॉम्बाइन भेजने के बाद हमें दूसरे माइक्रो बैच की गणना पर स्थानांतरित हो सकते हैं।
विलंबता ब्रेकडाउन
अगला, हम ओवरलैपिंग के प्रभावों की तुलना करते हैं और एकल-नोड तैनातियों EP8 और बहु-नोड तैनातियों EP128 के प्रदर्शन भिन्नताओं की तुलना करते हैं। तुलना को आसान बनाने के लिए, हम निम्नलिखित प्रयोग के लिए H100 GPUs का उपयोग करते हैं। हमने TP1, प्रति GPU 128 के बैच आकार, प्रति अनुरोध 2 की क्वेरी लंबाई, और 5000 की KV कैश लंबाई का उपयोग किया।
ऊपर का चित्र एक MoE ट्रांसफार्मर परत पर खर्च किए गए कुल समय और विभिन्न प्रकार के कर्णेलों की विलंबता अनुपात दिखाता है। डिस्पैच, कॉम्बाइन, और ग्रुपGEMM के अलावा, अन्य कर्णेलों का निष्पादन समय प्रति बैच आकार समान होना चाहिए चाहे EP8, EP128 नोओवरलैप, या EP128 डिस्पैच ओवरलैप श्रृंखला हों।
ओवरलैपिंग
आइए पहले तीन ओवरलैपिंग विधियों के प्रभावों की तुलना करें। नोओवरलैप ने कुल 2667µs लिया, डिस्पैच ओवरलैप ने 2651µs लिया, जिससे 16µs की बचत होती है या केवल 0.6%। माइक्रोबैच ने एक बहुत महत्वपूर्ण सुधार प्रदर्शन किया, जिसमें 1896µs लगा, 29% की गति में सुधार। दोनों डिस्पैच और कॉम्बाइन समय को बहुत कम किया गया। डिस्पैच 593µs से 367µs तक घट गया, और कॉम्बाइन 1012µs से 237µs तक।
हालाँकि, गणना कर्णेल के लिए, 128 के बैच आकार को दो बैचों में विभाजित करना कुल निष्पादन समय बढ़ाता है। इसी कारण, हालांकि संचारित समय में 1001µs की कमी हुई, कुल समय में केवल 771µs की कमी आई। हम निम्नलिखित अनुभाग में रूफलाइन मॉडल का उपयोग करके कारण को समझाएंगे।
इसी कारण, माइक्रोबैचिंग हमेशा प्रदर्शन में सुधार नहीं करता है।
ऊपर का चित्र माइक्रोबैचिंग के प्रदर्शन सुधार को बैच आकार 4-128 के लिए डिस्पैच ओवरलैप की तुलना में दर्शाता है। जब बैच आकार 32 से कम होता है, माइक्रोबैच प्रदर्शन को 5%-40% तक घटाता है। जब बैच आकार 32 से अधिक या बराबर होता है, माइक्रोबैच प्रदर्शन को 10%-35% तक सुधार सकता है।
EP8 बनाम EP128
आइए पहले के चित्र पर लौटते हैं और EP8 और EP128 माइक्रोबैच की तुलना करते हैं। EP8 ने कुल 1802µs ले लिया, जो EP128 के 1896µs से थोड़ा कम है। इसके अलावा माइक्रोबैच द्वारा लाया गया बढ़ा हुआ कर्णेल निष्पादन समय, मुख्य भिन्नता ग्रुपGEMM का इस्तेमाल MoE गणना के लिए है, और दो संचारित कर्णेल, डिस्पैच और कॉम्बाइन।
EP8 का ग्रुपGEMM 555µs लगा, जबकि EP128 का ग्रुपGEMM 270µs लगा, इसे आधा कर दिया गया। यह बहु-नोड तैनातियों का मुख्य लाभ है।
दुर्भाग्यवश, संचार के समय में 213µs की वृद्धि की गई, जिसने ग्रुपGEMM के लाभ को बहुत हद तक ऑफसेट किया। हमारे संचारित कर्णेल के अलग प्रदर्शन परीक्षण में, हमने पाया कि वे केवल इन्फिनीबैंड बैंडविड्थ का आधा प्राप्त कर सकते हैं। हम अपने संचारित कर्णेल को अधिक सुधारने के लिए काम करते रहेंगे।
एक और कर्णेल जो अत्यंत पीछे लगती है वह है GEMM। माइक्रोबैच ने GEMM में 95µs की वृद्धि कर दी। हम अगले अनुभाग में रूफलाइन मॉडल का उपयोग करके GEMM की अधिक गहराई में विश्लेषण करेंगे। हमें विश्वास है कि वर्तमान GEMM कार्यान्वयन अभी तक इष्टतम प्रदर्शन तक नहीं पहुंचा है।
रूफलाइन
रूफलाइन मॉडल कर्णेल प्रदर्शन का विश्लेषण करने के लिए एक अच्छा उपकरण है। इसकी क्षैतिज धुरी गणितीय तीव्रता है, मेमोरी I/O बाइट्स के FLOP के अनुपात। क्षैतिज धुरी मूल्य सीधे कर्णेल के भाव से गणना की जा सकती है। लंबवत धुरी प्राप्त प्रदर्शन का प्रतिनिधित्व करती है, FLOP को बेंचमार्क विलंबता से विभाजित करके गणना की जाती है।
कर्णेल प्रदर्शन की सैद्धांतिक ऊपरी सीमा सीधे GPU की विशेषताओं द्वारा निर्धारित होती है। H100 की FP8 शिखर प्रदर्शन 1979 TFLOP/s है, रूफलाइन मॉडल में ऊर्ध्वाधर रेखा के रूप में प्रतिनिधित्व किया जाता है। H100 की मेमोरी बैंडविड्थ 3.35 TB/s है, इसे उत्पत्ति से निकलने वाली रेखा की ढलान के रूप में प्रतिनिधित्व किया जाता है। ये दो रेखाएं गणना-सीमित और मेमोरी-सीमित कर्णेल के लिए प्रदर्शन सीमाओं को देती हैं, क्रमशः।
नीचे, हम ग्रुपGEMM और GEMM कर्णेल के प्रदर्शन पर चर्चा करते हैं।
ग्रुपGEMM
MoE में ग्रुपGEMM कर्णेल निम्नलिखित गणना करता है: कुल g समूह होते हैं, i-th समूह में m_i टोकन होते हैं, एक मैट्रिक्स गुणन [m_i, k] x [k, n] -> [m_i, n] करता है। प्रदर्शन परीक्षण में, हम मान लेते हैं कि प्रत्येक समूह में टोकन की संख्या समान है, जिसे m_i = m के रूप में दर्शाया जाता है। फिर ग्रुपGEMM का 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 की ग्रुपGEMM कार्यान्वयन का उपयोग किया। परीक्षण बिंदुओं ने EP8, EP16, EP32, EP64, EP128 विन्यास के TP1 और बैच आकारों 1-128 के संयोजन को शामिल किया।
ऊपर का चित्र विभिन्न EP विन्यासों के लिए ग्रुपGEMM के लिए रूफलाइन मॉडल को दर्शाता है। विभिन्न EP के अनुसार विभिन्न समूहों की संख्या होती है। चित्र लगभग ओवरलैपिंग प्रदर्शन रेखाएं दर्शाता है, यह दिखाते हुए कि ग्रुपGEMM प्रदर्शन मुख्य रूप से कुल टोकन गणना (जिसे g * m के रूप में दर्शाया जाता है) द्वारा निर्धारित होता है।
सितारे प्रत्येक EP विन्यास के लिए प्रति GPU 128 बैच आकार के लिए डेटा बिंदुओं को चिह्नित करते हैं। इन स्टारित डेटा बिंदुओं की तुलना करते हुए, हम देखकर सकते हैं कि जैसे-जैसे EP बढ़ता है (और DP समान समय बढ़ता है), प्रति विशेषज्ञ टोकनों की संख्या m भी बढ़ती है। EP8 पर, म=128, जबकि EP128 पर, म=2048।
जैसे-जैसे म बढ़ता है, गणितीय तीव्रता भी बढ़ती है। अधिकांश विन्यासों में, ग्रुपGEMM मेमोरी बैंडविड्थ द्वारा सीमित होता है, इसलिए म बढ़ाने से प्रदर्शन में सुधार होता है।
GEMM
GEMM कर्णेल मॉडल में लीनियर प्रोजेक्शन्स के लिए समर्पित होता है, जैसे कि Q/K/V/O प्रोजेक्शन। एक मैट्रिक्स गुणन [म, क] x [क, न] -> [म, न] के लिए, FLOP गणना 2 * म * क * न है और मेमोरी I/O बाइट्स म * क + न * क + म * न है। हम प्रति बैच आकार 1-128 के लिए विलंबता का भी परीक्षण कर सकते हैं।
ऊपर का चित्र GEMM के लिए रूफलाइन मॉडल को दर्शाता है विभिन्न EP विन्यासों के तहत। हम देख सकते हैं कि GEMM प्रदर्शन मेमोरी बैंडविड्थ द्वारा सीमित होता है। जैसे-जैसे बैच आकार बढ़ता है, गणितीय तीव्रता भी बढ़ती है, जिससे प्रदर्शन में सुधार होता है।
माइक्रोबैच
माइक्रोबैचिंग का उपयोग करते समय, हम बैच को समान रूप से दो भागों में विभाजित करते हैं। ऊपर के दोनों चित्रों से, हम देख सकते हैं कि जब म म/2 बन जाता है, तो मैट्रिक्स गुणन की दक्षता घट जाती है। इसलिए, म आकार के एक मैट्रिक्स गुणन को निष्पादित करने की तुलना में म/2
आकार के दो मैट्रिक्स गुणन निष्ादित करने में अधिक समय लगता है।
मल्टी-टोकन भविष्यवाणी
इस पूरे लेख में, हमने अनुमान लगाने के लिए मल्टी-टोकन भविष्यवाणी (MTP) के उपयोग को मान लिया है। MTP अनुमान स्पेक्युलेबल डिकोडिंग के लिए प्रश्न लंबाई को 1 से 2 में बदलता है। मैट्रिक्स गुणन के लिए, यह म को म * 2 में बदलने के समतुल्य है, जिससे मैट्रिक्स गुणन दक्षता बढ़ती है। दूसरी ओर, अगर हम MLA के लिए रूफलाइन मॉडल को खींचते हैं, तो हम पाएंगे कि क्वेरी लंबाई को बढ़ाने से MLA कर्णेल दक्षता में महत्वपूर्ण रूप से वृद्धि होती है।
इसलिए, MTP के उपयोग से मॉडल दक्षता पर महत्वपूर्ण भूमिका निभाती है।
कार्यान्वयन और अनुकूलन
इस अनुभाग में, हम कुछ कार्यान्वयन और अनुकूलन विवरणों को प्रस्तुत करेंगे हमारे दीपसीक-वी3/आर1 मॉडल के लिए।
क्वांटाइजेशन
दीपसीक-वी3/आर1 को मूल रूप से FP8 परब्लॉक क्वांटाइजेशन योजना का उपयोग करके प्रशिक्षित किया गया था, जिसमें वज़न स्थिर रूप से क्वांटाइज किया गया था और सक्रियता फ्लाई-ऑन द फ्लाई क्वांटाइज की गई थी। परमस्क चैनल या परमैट्रिक्स स्थिर रूप से स्रोत प्रॉजेक्ट करके स्केलिंग कारक की गणना करने के बजाय, सक्रियता के लिए स्केलिंग कारक 128-तत्व वेक्टरों के लिए गणना की जाती हैं और मैट्रिक्स के लिए 128x128 तत्व टाइल्स में क्वांटाइजेशन उत्पत्ति की सटीकता की सीमित होती है।
Perplexity में, हम अनुमान समर्थन के लिए CUDA और Triton कर्णेल्स के मिश्रण का उल्लेख करते हैं, जिसमें CUDA सबसे प्रदर्शन-संवेगात्मक और कभी-कभी बदले जा सकने वाले कर्णेल्स (जैसे कि अटेंशन और GEMM) का उपयोग होता है, Triton व्यापकता स्तर, सामान्यकरण और उपयोगिता प्रकारों की लागू करता है। Triton हमें कर्णेल्स को ब्लॉक क्वांटाइजेशन योजना के लिए अत्यधिक रूपांतरित करने की अनुमति देता है।
लिनियर और MoE परतों के लिए, हम दीप GEMM प्रकारों के साथ हमारे Triton GEMM प्रकारों को मिलाते हैं, क्योंकि हमने देखा है कि कुछ मैट्रिक्स आयामों और निम्न बैच आकारों के लिए Split-K से कम विलंबता मिलती है। यदि अनक्वांटाइज्ड परत (M, K) x (K, N) गुणन करती है, तो इसे (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) की आवश्यकता होती है ब्लॉक क्वांटाइजेशन के लिए स्केलिंग कारक। ब्लॉक क्वांटाइजेशन के लिए, सक्रियता के लिए स्केलिंग कारक फ्लाई-ऑन-द-फ्लाई गणना किए जाते हैं, उन्हें पूर्व-कैलिब्रेटेड नहीं किया जाता। चूंकि सक्रियता स्केलिंग कारक केवल K के साथ एकत्रित होते हैं और M आयामों के साथ नहीं, कर्णेल्स को योजना का समर्थन करने के लिए केवल आंशिक बदलाव की आवश्यकता होती है।
दीपसीक-वी3/आर1 द्वारा उपयोग की गई SiLU सक्रियण कार्य को CUDA ग्राफ्स, ब्लॉक क्वांटाइजेशन और गतिशील रूप से रूटेड टोकन गणना की समर्थन के लिए महत्वपूर्ण बदलाव की आवश्यकता होती है। ब्लॉक क्वांटाइजेशन समस्यात्मक हो सकता है क्योंकि यह क्षेतिज कमियाँ प्रदान करता है, हालांकि कर्णेल पहले से ही छिपे हुए आयाम के साथ 1024 तत्वों के ब्लॉकों में सक्रियताएँ विभाजित करता है। एक ब्लॉक के भीतर, क्वांटाइज करने के लिए टेंसर का आगे 128 के ब्लॉकों में विभाजित होता है सबसे बड़ा मान गणना करने के लिए, Triton ने कुशल क्रॉस-वॉर्प अधिकतम कमी का निर्माण किया, जिससे न्यूनतम अतिरिक्त भार जोड़कर।
CUDA ग्राफ्स के तहत MoE राउडिंग समर्थन करने के लिए, कर्णेल्स को राउडिंग जानकारी के प्रति सजग होना चाहिए जो विशेषज्ञ प्रति टोकन गणना की संख्या को दर्शाता है, बजाय कि उन बफ़र्स के आकार के अनुसार जो टोकन गणना की ऊपरी सीमा को समायोजित करने के लिए आवंटित किए जाते हैं। हम इनपुट टेंसर आयामों के अनुसार समस्या को विभाजित नहीं कर सकते हैं, इसलिए हम समयबद्ध प्रकारों की एक निश्चित संख्या लॉन्च करते हैं जो राउडिंग जानकारी को पढ़ते हैं ताकि उनके बीच सक्रियताएं के प्रसंस्करण कार्य को गतिशील रूप से विभाजित करें।
हमने FlashInfer परियोजना में कुछ प्रकारों को पहले ही अपलोड किया है और भविष्य में हम अधिक कोड को ओपन-सोर्स करेंगे।
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() का उपयोग किया। यह ऑपरेशन सभी GPUs के लिए समान बैच आकार की आवश्यकता होती है। हालांकि, विभिन्न DP समूह भिन्न बैच आकार चला सकते हैं।
हम सुनिश्चित करने के लिए कि all_to_all_single() विभिन्न DP समूहों के लिए उनके बैच आकार की अनुकूलता के लिए काम करता है, हमने पहले प्रत्येक मॉडल रन से पहले एक allreduce() ऑपरेशन का उपयोग करके सभी DP समूहों के लिए अधिकतम बैच आकार प्राप्त किया। फिर हम सभी DP समूहों को यह बैच आकार का उपयोग करने के लिए बनाते हैं।
हालांकि, यह दृष्टिकोण सुनिश्चित करता है कि हम CUDA ग्राफ का उपयोग कर सकते हैं, इसके तीन परिसीमा हैं। पहले, इसमें एक अतिरिक्त allreduce() ऑपरेशन की आवश्यकता होती है। दूसरे, छोटे बैच आकारों के DP समूहों को मजबूर किया जाता है। तीसरे, यह हमारे कार्यान्वयन कोड को जटिल बनाता है।
हमारे AllToAll कर्णेल के कार्यान्वयन के बाद, हमें सभी GPUs को समान बैच आकार का उपयोग करने की आवश्यकता नहीं है। इसलिए, हमें अतिरिक्त allreduce() ऑपरेशन या बैच आकारों को पट्टना करने की आवश्यकता नहीं है।
MoE राउटर
MoE राउटर Triton में कार्यान्वित है, जो मानक पुस्तकालय से व्युत्पन्न एक संशोधित सॉर्ट पर निर्भर करता है जो साथ ही क्रमबद्ध तत्वों के सूचकांक का ट्रैक रखता है। कार्यान्वयन सभी MoE मॉडल्स के साथ साझा किया जाता है, जैसा कि मिकस्ट्रल राउडिनग एक विशेष मामला है जहां दीपसीक मार्गों के साथ शीर्ष-K समूह सभी विशेषज्ञों की तुलना में समान है। स्पार्स कर्णेल सीधे Top-K संकेतकों और स्कोर को खपत करते हैं, जबकि घनी डिस्पैच/कॉम्बाइन स्कीम्स जो सभी-में-से-सभी पर निर्भर करती हैं उन्हें प्रति विशेषज्ञ के अलावा प्रति-टोकन आधार की राउडिंग जानकारी की आवश्यकता होती है।
भविष्य का कार्य
भविष्य के कार्य में, हम दीपसीक मॉडल के प्रदर्शन के लिए काउंत्तिन ज़ारी कार्य योजना बनाते हैं।
अगले सबसे महत्वपूर्ण अनुकूलन के रूप में प्रीफिल विसगणन है। दीपसीक-वी3/आर1 मॉडल का प्रीफिल चरण और डिकोड चरण का विभिन्न गणना लिमिट्स होता है। दोनों के लिए विभिन्न अनुकूलन रणनीतियाँ और तैनात योजनाएँ है।
डिकोड चरण में MLA परत के लिए, हम MLA गणना की FLOP गणना को कम करने के लिए मैट्रिक्स अवशोषण का उपयोग करते हैं। प्रीफिल चरण में, पहले लटेंट वेक्टर को K/V स्थान में प्रोजेक्ट करना और फिर मल्टी-हेड अटेंशन (MHA) रूप में प्रदर्शन करना बेहतर होगा।
यदि प्रीफिल और डिकोड एक ही GPU पर चलते हैं, डिकोड आउटपुट गति पर प्रीफिल के प्रभाव को कम करने के लिए, हम आम तौर पर अंशित प्रीफिल का उपयोग करते हैं क्वेरी को प्रीफिल के लिए कई अंशों में डिवाइड करने के लिए। क्योंकि KV कैश लटेंट वेक्टर को संग्रहीत करता है, MLA को MHA रूप में बदलना मुश्किल होता है।
MoE परत के लिए, डिकोड चरण में, हम जितना हो सके बड़ा EP और DP का उपयोग करते हैं विशेषज्ञ पर इनपुट टोकनों की संख्या को बढ़ाने के लिए, जिससे ग्रुपGEMM प्रदर्शन में सुधार होता है। प्रीफिल चरण में, क्योंकि टोकनों की संख्या पहले से ही पर्याप्त रूप से बड़ी होती है, ग्रुपGEMM पहले से ही गणना-सीमित होता है। इसलिए, प्रीफिल के लिए, हम छोटे EP और DP का उपयोग कर सकते हैं।
यदि प्रीफिल और डिकोड एक ही GPU पर चलाते हैं, जबतक कोई DP समूह पारफिल करता है, सभी GPUs पर MoE परतों की विलंबता बढ़ती है, डिकोड आउटपुट गति पर महत्वपूर्ण रूप से प्रभाव डालता है।
प्रीफिल विसगणन के अलावा, हम निम्न पहलुओं को और अनुकूलित करने की योजना बनाते हैं:
AllToAll प्रदर्शन: हमारा AllToAll कर्णेल इन्फिनीबैंड बैंडविड्थ का 1/3 ही प्राप्त कर सकता है। हम इस कर्णेल को और अनुकूलित करने के लिए काम करेंगे।
EAGLE शैली स्पेक्यूलेटिव डिकोडिंग: ऊपर दिए गए डेटा में हमने 1 टोकन को स्पेक्यूलेटिव डिकोडिंग द्वारा पूर्वानुमान करने का अनुमान लिया है। EAGLE एक टोकन पर पूर्वानुमान लंबाई बढ़ाने के लिए एक पेड़ संरचना का उपयोग कर सकता है, जिससे स्वीकार्यता दर बढ़ जाती है, जो आउटपुट गति को काफी बढ़ा सकती है।
GEMM कर्णेल: पहले दिखाए गए रूफलाइन मॉडल में हम पाते हैं कि GEMM कर्णेल की दक्षता अभी तक सैद्धांतिक सीमा से दूर है। हम इस कर्णेल को अधिक अनुकूलित करने के लिए काम करेंगे।
GB200 NVL72: NVIDIA के नवीनतम GB200 NVL72 समाधान में, 72 ब्लैकवेल GPUs उच्च गति NVLink के माध्यम से इंटरकनेक्ट होते हैं। MoE आर्किटेक्चर मॉडल्स के लिए यह एक बड़ी अवसर और चुनौती है।
निष्कर्ष
बहु-नोड तैनातियों के साथ दीपसीक MoE मॉडल्स वह चीज़ हासिल करते हैं जो घने LLMs के साथ आमतौर पर असंभव होती है: थ्रूपुट और विलंबता में असमान सुधार। अधिक GPUs पर विशेषज्ञ वितरित करके, हम प्रति उपकरण मेमोरी बैंडविड्थ दबाव को कम करते हैं, जिससे तेज प्रसंस्करण और उच्च प्रणाली थ्रूपुट सक्षम होता है। हमारे प्रयोग EP128 विन्यास को प्रदर्शित करते हैं जो एकल-नोड तैनातियों की तुलना में समकक्ष आउटपुट गति पर 5x तक उच्च थ्रूपुट प्राप्त करते हैं।
गणना-संचार ओवरलैपिंग तकनीकें जैसे कि माइक्रोबैचिंग मल्टी-नोड संचार ओवरहेड को महत्वपूर्ण रूप से कम करती हैं, हमारी कार्यान्वयन ने 40% तक गति में सुधार दिखाया है। हमारे कस्टम AllToAll संचार कर्णेल्स और अनुकूलित कर्णेल कार्यान्वयन ने 671B पैरामीटर मॉडल की कुशल तैनाती को सक्षम किया है।
जैसे ही MoE आर्किटेक्चर क्षमता के लिए लोकप्रियता प्राप्त करते हैं, ये तैनाती रणनीतियाँ ऐसे मॉडल्स को कुशलतापूर्वक स्केल करने के लिए मूल्यवान अंतर्दृष्टि प्रदान करती हैं।