பல-முனை DeepSeek வரிசைப்படுத்தலுடன் குறைந்த தாமதம் மற்றும் அதிக செயல்திறன்

பெரும்பாலான அமைப்புகளில், தாமதம் மற்றும் செயல்திறன் ஆகியவை பெரும்பாலும் முரண்பட்ட இலக்குகளாகும், அவை வடிவமைப்பு மற்றும் வரிசைப்படுத்தலின் போது பரிமாற்றங்கள் தேவைப்படுகின்றன. உதாரணமாக, அடர்த்தியான பெரிய மொழி மாதிரிகளில், தொகுதி அளவை அதிகரிப்பது செயல்திறனை மேம்படுத்தலாம் ஆனால் தாமதத்தையும் அதிகரிக்கிறது; ஒரே கணினியில் டென்சார் இணைத்திறனை அதிகரிப்பது தாமதத்தைக் குறைக்கும் ஆனால் பிரதிகளின் எண்ணிக்கையைக் குறைக்கும், இதனால் குறைந்த செயல்திறனுக்கு வழிவகுக்கும்.

DeepSeek-V3/R1 போன்ற நிபுணர்களின் கலவை (MoE) மாதிரிகள் சமீபத்தில் சிறந்த மாதிரி திறன்கள் மற்றும் செயல்பாட்டு செயல்திறனைக் காட்டியுள்ளன. உதாரணமாக, DeepSeek-V3/R1 மாதிரி மொத்தத்தில் 671B அளவுருக்களைக் கொண்டுள்ளது, ஆனால் அனுமானத்தின் போது ஒவ்வொரு டோக்கனும் 37B அளவுருக்களை மட்டுமே பயன்படுத்துகிறது. இந்த மாதிரி கட்டமைப்பு அனுமான அமைப்புகளுக்கு சவால்களையும் வாய்ப்புகளையும் அளிக்கிறது.

பாரம்பரிய அமைப்புகளுக்கு மாறாக, பெரும்பாலான காட்சிகளில் பல முனைகளில் வரிசைப்படுத்தும்போது DeepSeek-V3/R1 போன்ற MoE மாதிரிகள் அதிக செயல்திறன் மற்றும் குறைந்த தாமதத்தை ஒரே நேரத்தில் அடைய முடியும் என்பதை இந்தக் கட்டுப்பாடு நிரூபிக்கிறது.

NVLink மூலம் ஒற்றை-நோடு நிறுவல்; அதில் attention மற்றும் expert computation ஆகியவை GPUs முழுவதும் பகிர்ந்தளிக்கப்படுகின்றன.

InfiniBand மூலம் பல-நோடு நிறுவல்; இதில் GPU குழுக்கள் நோடுகளுக்குள் மற்றும் நோடுகளுக்கிடையே இணைக்கப்பட்டுள்ளன.

மாதிரியின் அதிக எண்ணிக்கையிலான சிறிய நிபுணர்கள் காரணமாக, வரிசைப்படுத்தல்கள் பல சாதனங்களில் பரப்பப்பட வேண்டும். 8xH200 ஜிபியுகளைக் கொண்ட ஒற்றை முனையில் ஒற்றை முனைய வரிசைப்படுத்தல்களையும், 8xH100 ஜிபியுகளில் பல முனைய வரிசைப்படுத்தல்களையும் நாங்கள் பரிசீலித்தோம்.

இரண்டு வரிசைப்படுத்தல் கட்டமைப்புகளும் தரவு இணைத்திறனைப் பயன்படுத்துகின்றன, இது எங்கள் சொந்த கோரிக்கை திட்டமிடுபவர் மூலம் நிர்வகிக்கப்படுகிறது. தரவு இணைத்திறன் செயல்படுத்தலில் பல அனுமான எஞ்சின் நிகழ்வுகளைத் தொடங்குவது அடங்கும், ஒவ்வொன்றும் கோரிக்கைகளுக்குச் சேவை செய்ய மற்றும் பராமரிக்க சுயாதீனமாக இயங்குகின்றன. GRPC மூலம் எஞ்சினுடன் தொடர்பு கொள்ளும் கோரிக்கை திட்டமிடுபவர், கோரிக்கைகளை முடிந்தவரை சமமாகப் பரப்புவதற்குப் பொறுப்பாகும், அதே நேரத்தில் KV மீள் பயன்பாட்டை எளிதாக்குகிறது, தற்காலிக சேமிப்பைக் கொண்ட சேவையகங்களுக்குப் பகுதி பொருந்தக்கூடிய முன்னொட்டைக் கொண்ட கோரிக்கைகளை அனுப்புகிறது. எஞ்சின் நிகழ்வுகள் பல முனைகளில் பரவாது. கவனத்தை பல சாதனங்களில் பிரிக்க அவை விருப்பமாக டென்சார் இணைத்திறனைப் பயன்படுத்தலாம். ஒற்றை முனைய வழக்கில் NVLink வழியாகவும் அல்லது பல முனைய வழக்கில் InfiniBand வழியாகவும் நிகழ்வுகள் ஒன்றோடொன்று இணைக்கப்பட்டு, நிபுணர்களை அனுப்பவும் சேகரிக்கவும் செய்கின்றன.

ஒற்றை முனைய வரிசைப்படுத்தல் கட்டமைப்பு சிறிய தொகுதி அளவுகளுடன் சிறந்த தாமதத்தை வழங்குகிறது; இருப்பினும், அதிகரித்த சுமை நிலைமைகளின் கீழ் செயல்திறன் விரைவாகக் குறைகிறது.

சேவை செய்யும் எஞ்சினை வரிசைப்படுத்த, பல எஞ்சின் நிகழ்வுகளை வழங்கும் ஒவ்வொரு முனையத்திற்கும் ஒரு பாடலைத் தொடங்குகிறோம். விநியோகிக்கப்பட்ட தொடர்புகளை அமைப்பதற்கும் NVSHMEM துவக்கத்தை பேச்சுவார்த்தை நடத்துவதற்கும் PyTorch பொறுப்பாகும். தொடர்புக்கு, முந்தைய வலைப்பதிவு இடுகையில் விவரிக்கப்பட்டுள்ள தனிப்பயன் CUDA கர்னல்களை நம்பியுள்ளோம். நிபுணர் இணைத்திறனை செயல்படுத்தும் துணியின் அடிப்படையில் பயன்படுத்த சரியான கர்னல்களைத் தேர்ந்தெடுக்கும் மாதிரியுடன், இரண்டு வரிசைப்படுத்தல்களின் செயலாக்கமும் கிட்டத்தட்ட ஒரே மாதிரியாகும்.

எங்களின் செயல்திறன் ஒப்பீடுகளுக்குள் நுழைவதற்கு முன், DeepSeek-V3/R1 போன்ற பெரிய MoE மாதிரிகளை வரிசைப்படுத்தக்கூடிய முக்கிய இணைப்படுத்தல் உத்திகளைப் புரிந்துகொள்வது அவசியம்.

LLM அனுமானத்தில், நினைவக பயன்பாடு மற்றும் ஒவ்வொரு ஜிபியுக்கான கணக்கீட்டைக் குறைக்க டென்சார் இணைத்திறன் (TP) பொதுவாகப் பயன்படுத்தப்படுகிறது, இதன் மூலம் தாமதத்தைக் குறைக்கிறது. பொதுவாக, கவன மற்றும் MLP அடுக்குகளில் உள்ள Linear கணிப்புகளை வரிசை அல்லது நிரல் பரிமாணங்களுடன் பிரிக்கலாம், மற்றும் கவன செயல்பாடுகளை கவன தலை பரிமாணத்துடன் பிரிக்கலாம்.

TP உடன், Llama-3 கட்டமைப்பில் Linear கணிப்பு மற்றும் ஜிபியுக்களில் கவனம் செலுத்தும் செயல்பாடுகளுக்கு நகலெடுக்கப்பட்ட கணக்கீடு இல்லை, இது ஒரு சிறந்த பிரிக்கும் முறையாகும். இருப்பினும், DeepSeek-V3/R1 மாதிரிகளில், TP இதை அடைய முடியாது.

DeepSeek-V3/R1 மாதிரிகள் மல்டி-லேட்டன்ட் அசென்ஷன் (MLA) ஐப் பயன்படுத்துகின்றன. ஒரு MLA அடுக்கு முதலில் மறைமுக திசையனை கணக்கிட Linear கணிப்பு kv_a_proj ஐப் பயன்படுத்துகிறது, பின்னர் அதை ஒவ்வொரு கவன தலையின் ஸ்பேஸ் ஆக மாற்ற மற்றொரு Linear கணிப்பு kv_b_proj ஐப் பயன்படுத்துகிறது. அனைத்து கவன தலைகளும் ஒரே மறைமுக திசையனைப் பகிர்வதால், TP ஆல் மறைமுக திசையனைப் பிரிக்க முடியாது, எனவே அனைத்து TP ரேங்குகளும் kv_a_proj மற்றும் kv_b_proj இன் அளவுருக்கள் மற்றும் கணக்கீட்டை நகலெடுக்க வேண்டும். இதேபோல், MLA மறைமுக திசையனை KV தற்காலிக சேமிப்பில் சேமிப்பதால், ஒவ்வொரு TP ரேங்கும் KV தற்காலிக சேமிப்பின் ஒரே மாதிரியான நகலைச் சேமிக்கிறது.

MLA இல் சில நகல்கள் இருந்தாலும், டென்சார் இணைத்திறன் கணக்கீட்டு தேவைகளில் பகுதி குறைப்பை வழங்குகிறது, இதனால் அதிக வெளியீட்டு வேகங்கள் தேவைப்படும் காட்சிகளுக்கு இது மதிப்புமிக்கதாக அமைகிறது.

DeepSeek-V3/R1 மாதிரிகள் MLP அடுக்குகளை MoE அடுக்குகளால் மாற்றுகின்றன. ஒரு MoE அடுக்கு 256 அனுப்பப்பட்ட நிபுணர்களையும் ஒரு பகிரப்பட்ட நிபுணரையும் கொண்டுள்ளது. ஒவ்வொரு டோக்கனும் கணக்கீட்டிற்காக 8 வெவ்வேறு அனுப்பப்பட்ட நிபுணர்களுக்கு அனுப்பப்படுகிறது, மேலும் முடிவுகள் எடையிடப்பட்டு கூட்டுத்தொகை செய்யப்படுகின்றன. ஒவ்வொரு டோக்கனும் பகிரப்பட்ட நிபுணரிலும் கணக்கிடப்படுகிறது, மேலும் முடிவு அனுப்பப்பட்ட நிபுணர்களின் முடிவில் சேர்க்கப்படுகிறது.

நிபுணர் இணைத்திறன் (EP) என்பது MoE அடுக்குகளுக்கான வழக்கமான பிரிப்பு அணுகுமுறையாகச் செயல்படுகிறது, ஒவ்வொரு ஜிபியும் 256 / EP அனுப்பப்பட்ட நிபுணர்களை நிர்வகிக்கிறது, அதே நேரத்தில் பகிரப்பட்ட நிபுணரின் நகலைப் பராமரிக்கிறது. TP உடன் ஒப்பிடும்போது, EP இன் நன்மை என்னவென்றால், இது கணக்கீட்டை அதிக ஜிபியுக்களுக்கு விநியோகிக்க முடியும், ஒவ்வொரு ஜிபியுக்கான கணக்கீடு மற்றும் நினைவக பயன்பாட்டைக் குறைக்கிறது.

நிபுணர் கணக்கீட்டைச் செய்வதற்கு முன், அனைத்து ஜிபியுக்களும் தொடர்புடைய நிபுணர்கள் அமைந்துள்ள ஜிபியுகளுக்கு டோக்கன்களை அனுப்ப AllToAll தொடர்பைச் செய்ய வேண்டும்; நிபுணர் கணக்கீட்டிற்குப் பிறகு, பல்வேறு ஜிபியுக்களிலிருந்து கணக்கீட்டு முடிவுகளைச் சேகரிக்கவும் எடையுள்ள கூட்டுத்தொகையைச் செய்யவும் மற்றொரு AllToAll தொடர்பு தேவைப்படுகிறது. NVSHMEM ஐப் பயன்படுத்தி இந்த இரண்டு AllToAll தொடர்பு கர்னல்களின் உகந்த பதிப்பான Dispatch மற்றும் Combine ஐ நாங்கள் செயல்படுத்தினோம். எங்கள் முந்தைய வலைப்பதிவு இடுகையில், செயலாக்கத்தை விரிவாக விவரித்துள்ளோம், மேலும் எங்கள் கர்னல்கள் GitHub இல் திறந்த மூலமாக வெளியிடப்பட்டுள்ளன.

EP உடன், MoE கணக்கீட்டை 128 அல்லது அதற்கு மேற்பட்ட ஜிபியுக்களில் விநியோகிக்கலாம். இருப்பினும், 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 ஜிபியுக்களில் விநியோகிப்பதைக் குறிக்கிறது, ஒவ்வொரு 4 ஜிபியுக்களும் ஒரு DP குழுவை உருவாக்குகின்றன, மொத்தம் 32 சுயாதீனமான DP குழுக்கள் உள்ளன.

DeepSeek இன் 671B அளவுருக்கள் ஒற்றை 8-GPU H100 இயந்திரத்தின் நினைவக திறனை மீறுகின்றன (80 GB * 8), ஆனால் ஒற்றை 8-GPU H200 இயந்திரம் முழு மாதிரியையும் முழுமையாக இடமளிக்க முடியும் (141 GB * 8). EP8 DP8 TP1 உள்ளமைவைப் பயன்படுத்தி, மாதிரி ஒவ்வொரு ஜிபியுவிற்கும் சுமார் 100 ஜிபி நினைவகத்தைப் பயன்படுத்துகிறது, KV தற்காலிக சேமிப்பு மற்றும் பிற இடைநிலை முடிவுகளுக்கு தோராயமாக 40 ஜிபி விடுகிறது. ஒரு டோக்கன் 70,272 பைட்டுகள் KV தற்காலிக சேமிப்பை ஆக்கிரமித்துள்ளது. ஒவ்வொரு கோரிக்கையும் 5,000 டோக்கன்களைக் கொண்டுள்ளது என்று வைத்துக் கொண்டால், ஒவ்வொரு ஜிபியுவும் ஏறக்குறைய 100 கோரிக்கைகளுக்கு இடமளிக்க முடியும்.

विभिन्न विन्यासों के तहत एकल-नोड और बहु-नोड परिनियोजन के बीच प्रदर्शन अंतर को समझना चाहते थे। हमने एकल-नोड परिनियोजन के लिए एक H200 मशीन और बहु-नोड परिनियोजन के लिए 16 H100 मशीनों का उपयोग किया। प्रत्येक परिनियोजन वातावरण के लिए, हमने TP 1, 2, 4, 8 के संयोजनों और प्रति GPU बैच आकारों 1, 2, 4, 8, 16, 32, 64, 128 का उपयोग किया। हमने माना कि प्रत्येक अनुरोध की KV कैश लंबाई 5,000 टोकन थी। हमने यह भी माना कि बहु-टोकन भविष्यवाणी (MTP) 1 अतिरिक्त टोकन की भविष्यवाणी करती है (यानी, प्रत्येक अनुरोध की क्वेरी लंबाई 2 है), और रूढ़िवादी रूप से 60% की स्वीकृति दर मान ली। नीचे दी गई आकृति विभिन्न विन्यासों के लिए थ्रूपुट और आउटपुट गति को दर्शाती है।

வெவ்வேறு expert-parallel அமைப்புகளுக்கான latency–throughput Pareto எல்லைகள்.

கிடைமட்ட அச்சு டோக்கன்கள்/s இல் ஒரு கோரிக்கைக்கான வெளியீட்டு வேகத்தைக் குறிக்கிறது. செங்குத்து அச்சு டோக்கன்கள்/s இல் ஒரு இயந்திரத்திற்கான செயல்திறனைக் காட்ட மடக்கை அளவைப் பயன்படுத்துகிறது. வெவ்வேறு வண்ண கோடுகளுடன் ஒவ்வொரு EP உள்ளமைவுக்கும் பரேட்டோ எல்லையைக் குறித்துள்ளோம்.

மிக உயர்ந்த வெளியீட்டு வேகத் தேவைகளைக் கொண்ட காட்சிகளில், 1 என்ற தொகுதி அளவைக் கொண்ட ஒற்றை முனை EP8 DP1 TP8 ஐப் பயன்படுத்துவது 100 டோக்கன்கள்/s ஐ விட அதிகமான வெளியீட்டு வேகத்தை அடையலாம், ஆனால் செயல்திறன் மிகக் குறைவு, வெளியீட்டு வேகத்திற்கு சமம். இந்த காட்சியில், முழு தொகுதியும் 2 டோக்கன்களை மட்டுமே கொண்டுள்ளது, இது அதிகபட்சமாக 2*8=16 நிபுணர்களுக்கு அனுப்பப்படலாம், மொத்தம் அதிகபட்சமாக 57B அளவுருக்களை செயல்படுத்துகிறது.

80-40 டோக்கன்கள்/s வெளியீட்டு வேக வரம்பில், செயல்திறன் அதிகரிக்கும் போது, வெளியீட்டு வேகம் கணிசமாகக் குறைகிறது. இதற்கு மாறாக, அதே வெளியீட்டு வேகத்தில் ஒற்றை முனை வரிசைப்படுத்தலை விட EP128 சுமார் 5 மடங்கு அதிக செயல்திறனைக் கொண்டுள்ளது.

ஒற்றை முனைய வரிசைப்படுத்தல்கள் எவ்வாறு செயல்படுகின்றன என்பதை ஆராய்வதன் மூலம் இந்த நிகழ்வை விளக்கலாம்: தொகுதி அளவை அதிகரிப்பது செயல்படுத்தப்பட்ட நிபுணர்களின் அதிகரிப்புடன் நேரடியாக தொடர்புடையது. தொகுதி அளவு 1 ஆக இருக்கும்போது, ஒரு ஜிபியுவிற்கு செயல்படுத்தப்பட்ட நிபுணர்களின் சராசரி எண் 2 * 8 / 8 = 2 ஆகும். தொகுதி போதுமானதாக இருக்கும்போது, அனைத்து நிபுணர்களும் செயல்படுத்தப்படுகிறார்கள், அதாவது ஒவ்வொரு ஜிபியுவும் 256 / 8 = 32 நிபுணர்களை செயல்படுத்துகிறது. அதிக நிபுணர்களை செயல்படுத்துவது என்பது நினைவகத்திலிருந்து அதிக அளவுருக்களை ஜிபியு படிக்க வேண்டும் என்பதாகும், இது நினைவக அலைவரிசை அழுத்தத்தை கணிசமாக அதிகரிக்கிறது. பெரிய மொழி மாதிரிகளின் டிகோட் கட்டம் ஏற்கனவே கணினி செயல்திறனை விட நினைவக அலைவரிசையால் தடுக்கப்படுவதால், ஒற்றை முனைய வரிசைப்படுத்தலில் தொகுதி அளவை அதிகரிப்பது வெளியீட்டு வேகத்தை கணிசமாகக் குறைக்கிறது.

நான்கு பல முனைய வரிசைப்படுத்தல் உள்ளமைவுகளின் (EP16, EP32, EP64 மற்றும் EP128) ஒப்பீடு, அதிக EP மதிப்புகள் பரேட்டோ எல்லையை செயல்திறன் மற்றும் வெளியீட்டு வேகத்தின் ஒரே நேரத்தில் மேம்பாடுகளை நோக்கி மாற்றுவதை வெளிப்படுத்துகிறது.

அதிக EP எண்ணைப் பயன்படுத்துவது என்பது ஒவ்வொரு ஜிபியுவிற்கும் குறைவான நிபுணர்கள் ஒதுக்கப்படுகிறார்கள் என்பதாகும். உதாரணமாக, EP128 என்பது ஒவ்வொரு ஜிபியுவும் 256 / 128 = 2 நிபுணர்களுக்கு பொறுப்பாகும் என்பதாகும், எனவே நினைவக அலைவரிசை அழுத்தம் கணிசமாகக் குறைக்கப்படுகிறது. வேறு வார்த்தைகளில் கூறுவதானால், பெரிய EP எண்ணைப் பயன்படுத்துவதன் மூலம், நாங்கள் திறம்பட அதிக நினைவக அலைவரிசையைப் பெறுகிறோம். प्रति-GPU बैच आकार 64 से कम होने पर, बैच आकार बढ़ाने से विशेषज्ञ की गणना गति काफी प्रभावित नहीं होती है क्योंकि इनपुट की संख्या बढ़ाने से मेमोरी बैंडविड्थ का दबाव काफी नहीं बढ़ता है। எனவே, EP128 ஐப் பயன்படுத்தும் போது, தொகுதி அளவை அதிகரிப்பது வெளியீட்டு வேகத்தை பெரிதும் பாதிக்காது என்பதை நாங்கள் கவனிக்கிறோம்.

சுவாரஸ்யமாக, பெரிய தொகுதி அளவுகளில் (ஒரு ஜிபியுவிற்கு 64 கோரிக்கைகள்), நாங்கள் ஒரு புதிய நிகழ்வைக் கவனித்தோம்: ஒற்றை முனைய வரிசைப்படுத்தல் செயல்திறன் பல முனைய வரிசைப்படுத்தலை விட சற்று அதிகமாக உள்ளது. இதற்குக் காரணம் முனையத்திற்குள்ளான NVLink ஆனது முனையங்களுக்கு இடையேயான InfiniBand ஐ விட அதிக அலைவரிசையைக் கொண்டிருப்பதாகும். மற்றொரு பகுதி எங்கள் செயலாக்கத்தின் வரம்புகள் காரணமாகும். இந்த நிகழ்வை நாங்கள் பின்னர் இன்னும் விரிவாக பகுப்பாய்வு செய்வோம்.

நினைவக திறனின் வரம்புகள் காரணமாக, EP8 DP8 TP1 உள்ளமைவு ஒரு ஜிபியுவிற்கு 128 தொகுதி அளவை அடைய முடியாது, எனவே அதிக செயல்திறனைத் பின்தொடரும் காட்சிகளில் பல முனைய வரிசைப்படுத்தல் இன்னும் சிறந்த தேர்வாகும்.

நிபுணர் இணைத்திறன் தொடர்பாக மேலே சுருக்கமாக அறிமுகப்படுத்தப்பட்டபடி, MoE அடுக்கு தொடர்பின் போது ஜிபியுக்கள் செயலற்ற நிலையில் இருக்கும். வீணாவதைக் குறைக்கவும் தாமதத்தைக் குறைக்கவும், இந்த செயலற்ற நேரத்தை நிரப்ப தரவு-சுயாதீனமான கணக்கீட்டு பணிகளைக் கண்டறிய வேண்டும்.

கணக்கீடு மற்றும் தொடர்பு ஒருங்கிணையாத அட்டவணைகள், dispatch overlap, மற்றும் ஐந்து-நிலை pipeline.

மேலே உள்ள படத்தின் மேல் பகுதி ஒரு அடுக்கின் கணக்கீட்டு ஓட்டத்தைக் காட்டுகிறது. MoE கணக்கீடு Dispatch ஐப் பொறுத்தது, மேலும் அடுத்த அடுக்கின் கணக்கீடு Combine இன் முடிவைப் பொறுத்தது.

ஒவ்வொரு ஜிபியுவிலும் பகிரப்பட்ட நிபுணரை வைக்கிறோம். இந்த வழியில், பகிரப்பட்ட நிபுணர் கணக்கீட்டிற்கு AllToAll தொடர்பு தேவையில்லை. எனவே, Dispatch Send முடிந்த உடனேயே பகிரப்பட்ட நிபுணர் கணக்கீட்டைச் செய்யலாம், பின்னர் Dispatch Recv முடிவடையும் வரை காத்திருக்கலாம். இந்த ஒன்றுடன் ஒன்று சேரும் திட்டத்தை "Dispatch Overlap" என்று அழைக்கிறோம்.

Dispatch Overlap நேரடியான செயலாக்கத்தையும் பரந்த பயன்பாட்டையும் வழங்குகிறது. இந்த நுட்பம் அனைத்து EP அளவுகள் மற்றும் தொகுதி அளவுகளில் பகிரப்பட்ட நிபுணர் கணக்கீட்டு நேரத்தை மறைக்கிறது.

கணக்கீடு மற்றும் தொடர்பு ஒன்றுடன் ஒன்று சேர்வதை மேலும் அதிகரிக்க, தரவு சார்புநிலையை உடைக்க DeepSeek தொழில்நுட்ப அறிக்கையில் குறிப்பிடப்பட்டுள்ள மைக்ரோ பேட்ச்சிங்கைப் பயன்படுத்தினோம். படத்தின் கீழ் பகுதியில் காட்டப்பட்டுள்ளபடி, ஒரு டிரான்ஸ்ஃபார்மர் அடுக்கின் கணக்கீட்டை 5 நிலைகளாகப் பிரித்தோம்:

நிலை 1: InputNorm, QKVProj, AppendKV, BMM

நிலை 2: BMM, Attn, OProj, PostNorm, Gate

நிலை 3: Dispatch Send, Shared Expert

நிலை 4: Dispatch Recv, MoE, Combine Send

நிலை 5: Combine Recv

முதல் 3 அடர்ந்த டிரான்ஸ்ஃபார்மர் அடுக்குகளில், முழு தொகுதியையும் பயன்படுத்துகிறோம். பின்வரும் 58 MoE டிரான்ஸ்ஃபார்மர் அடுக்குகளில், தொகுதியை சமமாக இரண்டு மைக்ரோ தொகுதிகளாகப் பிரிக்கிறோம். இரண்டு மைக்ரோ தொகுதிகளும் மாற்றி மாற்றி இயங்குகின்றன, 3 நிலைகள் ஆஃப்செட் செய்யப்படுகின்றன. இந்த இரண்டு மைக்ரோ தொகுதிகளுக்கு இடையே தரவு சார்பு இல்லை என்பதால், Dispatch Send க்குப் பிறகும் Combine Send க்குப் பிறகும் மற்றொரு மைக்ரோ தொகுதியின் கணக்கீட்டிற்கு மாறலாம்.

அடுத்து, ஒரு பரிசோதனையின் மூலம் ஒன்றுடன் ஒன்று சேரும் விளைவுகளை ஒப்பிடுகிறோம், மேலும் ஒற்றை முனைய வரிசைப்படுத்தல் EP8 மற்றும் பல முனைய வரிசைப்படுத்தல் EP128 ஆகியவற்றுக்கு இடையேயான செயல்திறன் வேறுபாடுகளையும் ஒப்பிடுகிறோம். ஒப்பீட்டின் எளிமைக்காக, பின்வரும் பரிசோதனைக்கு H100 ஜிபியுக்களைப் பயன்படுத்தினோம். நாங்கள் TP1, ஒரு ஜிபியுவிற்கு 128 தொகுதி அளவு, ஒரு கோரிக்கைக்கு 2 வினவல் நீளம் மற்றும் 5000 KV தற்காலிக சேமிப்பு நீளத்தைப் பயன்படுத்தினோம்.

ஒப்பிடப்பட்ட expert-parallel மற்றும் overlapping அமைப்புகளுக்கான kernel அடிப்படையிலான layer latency.

மேலே உள்ள படம் ஒரு MoE டிரான்ஸ்ஃபார்மர் அடுக்கில் செலவிடப்பட்ட மொத்த நேரத்தையும் வெவ்வேறு வகையான கர்னல்களின் தாமத விகிதத்தையும் காட்டுகிறது. Dispatch, Combine மற்றும் GroupGEMM ஐத் தவிர, தொகுதி அளவு ஒரே மாதிரியாக இருப்பதால் EP8, EP128 NoOverlap மற்றும் EP128 DispatchOverlap தொடர்களில் பிற கர்னல்களின் செயலாக்க நேரம் சமமாக இருக்க வேண்டும்.

முதலில் மூன்று ஒன்றுடன் ஒன்று சேரும் முறைகளின் விளைவுகளை ஒப்பிடுவோம். NoOverlap மொத்தம் 2667µs ஆனது, DispatchOverlap 2651µs ஆனது, 16µs அல்லது 0.6% மட்டுமே சேமிக்கிறது. MicroBatch மிகவும் குறிப்பிடத்தக்க மேம்பாட்டைக் காட்டியது, 1896µs எடுத்தது, இது 29% வேக அதிகரிப்பாகும். Dispatch மற்றும் Combine நேரம் இரண்டும் கணிசமாகக் குறைக்கப்பட்டன. Dispatch 593µs இலிருந்து 367µs ஆகக் குறைந்தது, மற்றும் Combine 1012µs இலிருந்து 237µs ஆகக் குறைந்தது.

கணக்கீட்டு கர்னல்களுக்கு, 128 அளவுள்ள தொகுதியை 64 அளவுள்ள இரண்டு தொகுதிகளாகப் பிரிப்பது மொத்த செயலாக்க நேரத்தை அதிகரிக்கிறது என்பதை நினைவில் கொள்க. எனவே, தொடர்புக்கு செலவிடப்பட்ட நேரம் 1001µs குறைக்கப்பட்டாலும், மொத்த நேரம் 771µs மட்டுமே குறைந்தது. பின்வரும் பிரிவில் Roofline மாதிரியைப் பயன்படுத்தி அதற்கான காரணத்தை விளக்குவோம்.

இந்த காரணத்திற்காக, மைக்ரோபேட்சிங் எப்போதும் செயல்திறனை மேம்படுத்துவதில்லை.

micro-batching உடன் output speed மற்றும் ஒவ்வொரு node-க்கும் throughput இல் ஏற்படும் மாற்றங்கள், per-GPU batch size-க்கு எதிராக plotted செய்யப்பட்டுள்ளது.

4-128 தொகுதி அளவுகளுக்கு DispatchOverlap உடன் ஒப்பிடும்போது Microbatch இன் செயல்திறன் மேம்பாட்டை மேலே உள்ள படம் காட்டுகிறது. தொகுதி அளவு 32 ஐ விட குறைவாக இருக்கும்போது, Microbatch செயல்திறனை 5%-40% குறைக்கிறது. தொகுதி அளவு 32 ஐ விட அதிகமாகவோ அல்லது சமமாகவோ இருக்கும்போது, Microbatch செயல்திறனை 10%-35% வரை மேம்படுத்தலாம்.

முந்தைய படத்திற்குத் திரும்பி EP8 மற்றும் EP128 Microbatch ஐ ஒப்பிடுவோம். EP8 மொத்தம் 1802µs எடுத்தது, இது EP128 இன் 1896µs ஐ விட சற்று குறைவு. மேலே குறிப்பிட்டுள்ள Microbatch ஆல் கொண்டு வரப்பட்ட அதிகரிக்கப்பட்ட கர்னல் செயலாக்க நேரத்தைத் தவிர, முக்கிய வேறுபாடுகள் MoE கணக்கீட்டிற்குப் பயன்படுத்தப்படும் GroupGEMM மற்றும் இரண்டு தொடர்பு கர்னல்களான Dispatch மற்றும் Combine ஆகியவற்றில் உள்ளன.

EP8 இன் GroupGEMM 555µs எடுத்தது, அதே நேரத்தில் EP128 இன் GroupGEMM 270µs எடுத்தது, பாதியாகக் குறைந்தது. இது பல முனைய வரிசைப்படுத்தலின் முக்கிய நன்மையாகும்.

துரதிருஷ்டவசமாக, தொடர்புக்காக செலவழித்த நேரம் 213µs அளவுக்கு அதிகரித்தது, இதனால் GroupGEMM இன் நன்மை பெரிதும் குறைந்தது. எங்கள் தொடர்பு கர்னல்களின் தனிப்பட்ட செயல்திறன் சோதனைகளில், அவை Infiniband பாண்ட்வித் இன் பாதியை மட்டுமே எட்ட முடியும் என்பதை கண்டறிந்தோம். எங்கள் தொடர்பு கர்னல்களை மேலும் மேம்படுத்துவதைத் தொடருவோம்.

மந்தமாக இருக்கும் மற்றொரு கர்னல் GEMM ஆகும். Microbatch GEMM ஐ 95µs அதிகரித்தது. கீழே உள்ள Roofline பிரிவில் GEMM ஐ இன்னும் ஆழமாக பகுப்பாய்வு செய்வோம். தற்போதைய GEMM செயலாக்கம் இன்னும் உகந்த செயல்திறனை அடையவில்லை என்று நாங்கள் நம்புகிறோம்.

கர்னல் செயல்திறனை பகுப்பாய்வு செய்வதற்கு ரூஃப்லைன் மாதிரி ஒரு நல்ல கருவியாகும். இதன் கிடைமட்ட அச்சு எண்கணித தீவிரம், நினைவக I/O பைட்டுகளுக்கு FLOP இன் விகிதமாகும். கர்னலின் சொற்பொருளிலிருந்து கிடைமட்ட அச்சு மதிப்பை நேரடியாக கணக்கிடலாம். செங்குத்து அச்சு அடைந்த செயல்திறனைக் குறிக்கிறது, இது பெஞ்ச்மார்க் தாமதத்தால் FLOP ஐ வகுப்பதன் மூலம் கணக்கிடப்படுகிறது.

கர்னல் செயல்திறனின் தத்துவார்த்த மேல் வரம்பு ஜிபியுவின் விவரக்குறிப்புகளால் நேரடியாக தீர்மானிக்கப்படுகிறது. H100 இன் FP8 உச்ச செயல்திறன் 1979 TFLOP/s ஆகும், இது ரூஃப்லைன் மாதிரியில் கிடைமட்ட கோடாக குறிக்கப்படுகிறது. H100 இன் நினைவக அலைவரிசை 3.35 TB/s ஆகும், இது தோற்றத்தின் வழியாக செல்லும் கோட்டின் சாய்வாக குறிக்கப்படுகிறது. இரண்டு கோடுகள் முறையே கணக்கீடு-கட்டுப்படுத்தப்பட்ட மற்றும் நினைவக-கட்டுப்படுத்தப்பட்ட கர்னல்களுக்கான செயல்திறன் வரம்புகளை வழங்குகின்றன.

கீழே, GroupGEMM மற்றும் GEMM கர்னல்களின் செயல்திறனைப் பற்றி விவாதிக்கிறோம்.

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 உள்ளமைவுகளின் கலவைகளை உள்ளடக்கியது.

கணக்கீடு மற்றும் memory-bandwidth rooflines-க்கு ஒப்பான GroupGEMM செயல்திறன்.

மேலே உள்ள படம் வெவ்வேறு EP உள்ளமைவுகளின் கீழ் GroupGEMM க்கான ரூஃப்லைன் மாதிரியைக் காட்டுகிறது. வெவ்வேறு EP வெவ்வேறு எண்ணிக்கையிலான குழுக்களுடன் ஒத்திருக்கிறது. படம் கிட்டத்தட்ட ஒன்றுடன் ஒன்று சேரும் செயல்திறன் கோடுகளை விளக்குகிறது, இது GroupGEMM செயல்திறன் முக்கியமாக மொத்த டோக்கன் எண்ணிக்கையால் (g * m என குறிக்கப்படுகிறது) தீர்மானிக்கப்படுகிறது என்பதைக் குறிக்கிறது.

நட்சத்திரங்கள் ஒவ்வொரு EP உள்ளமைவுக்கும் ஒரு ஜிபியுவிற்கு 128 தொகுதி அளவுக்கு ஒத்திருக்கும் தரவுப் புள்ளிகளைக் குறிக்கின்றன. இந்த நட்சத்திரக் குறிக்கப்பட்ட தரவுப் புள்ளிகளை ஒப்பிடும்போது, EP அதிகரிக்கும் போது (மற்றும் DP ஒத்திசைவாக அதிகரிக்கும் போது), ஒவ்வொரு நிபுணருக்கும் உள்ள டோக்கன்களின் எண்ணிக்கை m கூட அதிகரிக்கிறது என்பதைக் காணலாம். EP8 இல், m=128, அதே நேரத்தில் EP128 இல், m=2048.

m அதிகரிக்கும் போது, எண்கணித தீவிரமும் அதிகரிக்கிறது. பெரும்பாலான உள்ளமைவுகளில், GroupGEMM நினைவக அலைவரிசையால் வரம்பிடப்படுகிறது, எனவே m ஐ அதிகரிப்பது செயல்திறனை மேம்படுத்துகிறது.

GEMM கர்னல் மாதிரியில் Q/K/V/O ப்ரொஜெக்ஷன் போன்ற Linear கணிப்புகளுக்கு ஒத்திருக்கிறது. [m, k] x [k, n] -> [m, n] இன் மேட்ரிக்ஸ் பெருக்கத்திற்கு, FLOP எண்ணிக்கை 2 * m * k * n ஆகும், மற்றும் நினைவக I/O பைட்டுகள் m * k + n * k + m * n ஆகும். தொகுதி அளவுகள் 1-128 க்கான தாமதத்தையும் சோதிக்கலாம்.

கணக்கீடு மற்றும் memory-bandwidth rooflines-க்கு ஒப்பான GEMM செயல்திறன்.

மேலே உள்ள படம் வெவ்வேறு EP உள்ளமைவுகளின் கீழ் GEMM க்கான ரூஃப்லைன் மாதிரியைக் காட்டுகிறது. GEMM செயல்திறன் நினைவக அலைவரிசையால் வரம்பிடப்பட்டுள்ளது என்பதைக் காணலாம். தொகுதி அளவு அதிகரிக்கும் போது, எண்கணித தீவிரமும் அதிகரிக்கிறது, இதனால் செயல்திறன் மேம்படுகிறது.

மைக்ரோபேட்சிங் பயன்படுத்தும்போது, நாம் பேட்சை சமமாக இரண்டு பகுதிகளாகப் பிரிக்கிறோம். மேலே உள்ள இரண்டு படங்களிலிருந்து, m என்பது m/2 ஆகும்போது, matrix multiplication இன் செயல்திறன் குறைகிறது என்பதை காணலாம். ஆகவே, m/2 அளவுடைய இரண்டு matrix multiplication-களை இயக்குவது, m அளவுடைய ஒரு matrix multiplication-ஐ இயக்குவதைவிட அதிக நேரம் எடுத்துக்கொள்கிறது.

இந்தக் கட்டுரை முழுவதும், அனுமான டிகோடிங்கிற்கான மல்டி-டோக்கன் பிரடிக்ஷன் (MTP) ஐப் பயன்படுத்துவதாக நாங்கள் கருதியுள்ளோம். MTP ஒரு கோரிக்கைக்கான வினவல் நீளத்தை 1 இலிருந்து 2 ஆக மாற்றுகிறது. மேட்ரிக்ஸ் பெருக்கத்திற்கு, இது m ஐ m * 2 ஆக மாற்றுவதற்கு சமம், இதன் மூலம் மேட்ரிக்ஸ் பெருக்க செயல்திறனை அதிகரிக்கிறது. மறுபுறம், MLA க்கான ரூஃப்லைன் மாதிரியை வரைந்தால், வினவல் நீளத்தை அதிகரிப்பது MLA கர்னல் செயல்திறனை கணிசமாக அதிகரிக்கிறது என்பதைக் கண்டுபிடிப்போம்.

따라서 MTP का उपयोग मॉडल दक्षता में एक महत्वपूर्ण भूमिका निभाता है।

இந்தப் பிரிவில், எங்கள் DeepSeek-V3/R1 மாதிரிக்கு சில செயலாக்கம் மற்றும் உகப்பாக்க விவரங்களை அறிமுகப்படுத்துவோம்.

DeepSeek-V3/R1 ப்ளாக் வாரியான குவாண்டமைசேஷன் திட்டத்தைப் பயன்படுத்தி FP8 இல் இயற்கையாகப் பயிற்றுவிக்கப்பட்டது, எடைகள் நிலையாகக் குவாண்டமைஸ் செய்யப்பட்டன மற்றும் செயல்பாடுகள் ஆன்-The-Fly இல் குவாண்டமைஸ் செய்யப்பட்டன. சேனல் வாரியாக அல்லது மேட்ரிக்ஸ் வாரியாக அளவிடுதல் காரணியைக் கணக்கிடுவதற்குப் பதிலாக, செயல்பாடுகளுக்கு 128-கூறு திசையன்கள் மற்றும் மெட்ரிகளுக்கு 128x128 கூறு ஓடுகள் முழுவதும் அளவிடுதல் காரணிகள் கணக்கிடப்படுகின்றன, இது குவாண்டமைசேஷன் காரணமாக துல்லியச் சிதைவைக் கட்டுப்படுத்துகிறது.

Perplexity இல், அனுமானத்தை ஆதரிக்க CUDA மற்றும் Triton கர்னல்களின் கலவையை நாங்கள் நம்பியுள்ளோம், மிகக் கடுமையான செயல்திறன் மற்றும் அரிதாக மாற்றப்படும் கர்னல்களுக்கு CUDA பயன்படுத்தப்படுகிறது (கவனம் மற்றும் GEMM போன்றவை), Triton பரந்த அளவிலான செயல்படுத்தல், இயல்பாக்கம் மற்றும் பயன்பாட்டு கர்னல்களை செயல்படுத்துகிறது. பிளாக் குவாண்டமைசேஷன் திட்டத்திற்கு கர்னல்களை விரைவாக மாற்ற Triton எங்களை அனுமதித்தது.

நேரியல் மற்றும் MoE அடுக்குகளுக்கு, Deep 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)) அளவிடுதல் காரணி தேவைப்படுகிறது. பிளாக் குவாண்டமைசேஷனுக்கான செயல்பாடுகளுக்கான அளவிடுதல் காரணிகள் முன்கூட்டியே அளவீடு செய்யப்படுவதற்கு பதிலாக ஆன்-the-fly இல் கணக்கிடப்படுகின்றன. செயல்படுத்தும் அளவிடுதல் காரணிகள் K பரிமாணத்தில் மட்டுமே திரட்டப்படுகின்றன மற்றும் M பரிமாணத்தில் அல்ல என்பதால், திட்டத்தை ஆதரிக்க கர்னல்களுக்கு சிறிய மாற்றங்கள் மட்டுமே தேவைப்படுகின்றன.

Batched SiLU-and-multiply கணக்கீடு; இதில் expert input tensors, output tensors, மற்றும் scaling factors காட்டப்பட்டுள்ளன.

DeepSeek-V3/R1 ஆல் பயன்படுத்தப்படும் SiLU செயல்படுத்தும் செயல்பாட்டிற்கு CUDA வரைபடங்கள், பிளாக் குவாண்டமைசேஷன் மற்றும் dinamically routed token counts ஆகியவற்றை ஆதரிக்க குறிப்பிடத்தக்க மாற்றங்கள் தேவைப்பட்டன. பிளாக் குவாண்டமைசேஷன் சிக்கலாக இருக்கலாம் ஏனெனில் இது கிடைமட்ட குறைப்புகளை அறிமுகப்படுத்துகிறது, இருப்பினும் கர்னல் ஏற்கனவே அதன் மறைமுக பரிமாணத்தின் entlang உள்ள செயல்படுத்தல்களை 1024 கூறுகளின் தொகுதிகளாக துண்டாக்கியுள்ளது. ஒரு தொகுதிக்குள், குவாண்டமைஸ் செய்யப்பட வேண்டிய டென்சார் மிகப்பெரிய முழுமையான மதிப்பைக் கணக்கிடுவதற்காக 128 தொகுதிகளில் மேலும் துண்டாக்கப்பட்டப்பட்டது, Triton திறமையான கிராஸ்-வார்ப் அதிகபட்ச குறைப்புகளை உருவாக்குகிறது, குறைந்தபட்ச மேலதிகத்தைச் சேர்க்கிறது.

CUDA வரைபடங்களின் கீழ் MoE ரூட்டிங் ஆதரிக்க, டோக்கன் எண்ணிக்கையின் மேல் வரம்பைக் ধারণ செய்ய ஒதுக்கப்பட்ட பஃபர்களின் அளவின் அடிப்படையில் வேலைகளை திட்டமிடுவதற்கு பதிலாக, நிபுணருக்கு டோக்கன்களின் எண்ணிக்கையைக் குறிக்கும் ரூட்டிங் தகவலை கர்னல்கள் அறிந்திருக்க வேண்டும். உள்ளீட்டு டென்சார் பரிமாணங்களின் அடிப்படையில் சிக்கலைப் பிரிக்க முடியாது, எனவே டோக்கன்கள் எவ்வளவு நிரப்பப்பட்டுள்ளன என்பதைத் தீர்மைக்க ரூட்டிங் தகவலைப் படிக்கும் மற்றும் அவற்றுக்கிடையே செயலாக்கத்தின் வேலையைப் பிரிக்கும் நிலையான எண்ணிக்கையிலான நிலையான கர்னல்களைத் தொடங்குகிறோம்.

எங்கள் சில கர்னல்களை ஏற்கனவே FlashInfer திட்டத்திற்கு அப்ஸ்ட்ரீம் செய்துள்ளோம், மேலும் எதிர்காலத்தில் எங்கள் குறியீட்டின் மேலும் பலவற்றை திறந்த மூலமாக வெளியிடுவோம்.

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 வரைபடத்தை உருவாக்குகிறோம்.

எங்கள் AllToAll கர்னலை உருவாக்குவதற்கு முன், AllToAll தொடர்புக்கு torch.all_to_all_single() ஐப் பயன்படுத்தினோம். இந்த செயல்பாட்டிற்கு அனைத்து ஜிபியுக்களும் ஒரே தொகுதி அளவைப் பயன்படுத்த வேண்டும். இருப்பினும், வெவ்வேறு DP குழுக்கள் வெவ்வேறு தொகுதி அளவுகளை இயக்கலாம்.

all_to_all_single() வெவ்வேறு தொகுதி அளவுகளைப் பயன்படுத்தும் வெவ்வேறு DP குழுக்களுடன் இணக்கமாக இருப்பதை உறுதி செய்ய, அனைத்து DP குழுக்களிலும் அதிகபட்ச தொகுதி அளவைப் பெற ஒவ்வொரு மாதிரி இயக்கத்திற்கும் முன்பு allreduce() செயல்பாட்டைப் பயன்படுத்தினோம். பின்னர் அனைத்து DP குழுக்களையும் இந்த தொகுதி அளவைப் பயன்படுத்தி இயக்கச் செய்தோம்.

இந்த அணுகுமுறை Cuda வரைபடத்தைப் பயன்படுத்தலாம் என்பதை உறுதி செய்தாலும், இதற்கு மூன்று தீமைகள் உள்ளன. முதலாவதாக, இதற்கு கூடுதல் allreduce() செயல்பாடு தேவைப்படுகிறது. இரண்டாவதாக, சிறிய தொகுதி அளவுகளைக் கொண்ட DP குழுக்கள் பேட் செய்ய கட்டாயப்படுத்தப்படுகின்றன. மூன்றாவதாக, இது எங்கள் செயலாக்க குறியீட்டை சிக்கலாக்குகிறது.

எங்கள் சொந்த AllToAll கர்னலை செயல்படுத்திய பிறகு, அனைத்து ஜிபியுக்களும் ஒரே தொகுதி அளவைப் பயன்படுத்த வேண்டும் என்ற அவசியமில்லை. எனவே, கூடுதல் allreduce() செயல்பாடுகளைச் செய்யவோ அல்லது தொகுதி அளவுகளை பேட் செய்யவோ தேவையில்லை.

MoE ரவுட்டர் Triton இல் செயல்படுத்தப்பட்டுள்ளது, இது நிலையான நூலகத்திலிருந்து பெறப்பட்ட மாற்றியமைக்கப்பட்ட வரிசையை நம்பியுள்ளது, இது வரிசைப்படுத்தப்பட்ட கூறுகளின் குறியீடுகளையும் வைத்திருக்கிறது. Mixtral ரூட்டிங் என்பது DeepSeek ரூட்களின் சிறப்பு வழக்கு என்பதால் இந்த செயலாக்கம் அனைத்து MoE மாதிரிகளிலும் பகிரப்படுகிறது, அங்கு Top-K குழு அனைத்து நிபுணர்களின் குழுவிற்கும் ஒத்ததாக இருக்கும். ஸ்பேஸ் கர்னல்கள் Top-K குறியீடுகள் மற்றும் மதிப்புகளை நேரடியாக நுகரும், அதே நேரத்தில் ஆல்-டு-ஆல்லை நம்பியிருக்கும் அடர்ந்த டிஸ்பாட்ச்/கம்பைன் திட்டங்களுக்கு ஒரு டோக்கன் அடிப்படையில் அல்லாமல் ஒரு நிபுணர் அடிப்படையில் ரூட்டிங் தகவல் திரட்டப்பட வேண்டும்.

எதிர்கால வேலையில், DeepSeek மாதிரியின் செயல்திறனை மேலும் மேம்படுத்த திட்டமிட்டுள்ளோம்.

மிக முக்கியமான அடுத்த உகப்பாக்கம் பிரிஃபில் பிரிப்பு (Prefill Disaggregation) ஆகும். DeepSeek-V3/R1 மாதிரியின் பிரிஃபில் கட்டம் மற்றும் டிகோட் கட்டம் மிகவும் வேறுபட்ட கணக்கீட்டு பண்புகளைக் கொண்டுள்ளன. இரண்டும் வெவ்வேறு உகப்பாக்கம் உத்திகள் மற்றும் வரிசைப்படுத்தல் திட்டங்களைப் பயன்படுத்தலாம்.

MLA அடுக்கைப் பொறுத்தவரை, டிகோட் கட்டத்தில், MLA கணக்கீட்டின் FLOP எண்ணிக்கையைக் குறைக்க மேட்ரிக்ஸ் உறிஞ்சுதலைப் பயன்படுத்துகிறோம். பிரிஃபில் கட்டத்தில், மறைமுக திசையனை முதலில் K/V ஸ்பேஸ் ஆக திட்டமிட்டு பின்னர் மல்டி-ஹெட் அசென்ஷன் (MHA) வடிவத்தில் கணக்கிடுவது சிறப்பாக செயல்படும்.

பிரிஃபில் மற்றும் டிகோட் ஒரே ஜிபியுவில் இயங்கினால், டிகோட் வெளியீட்டு வேகத்தில் பிரிஃபில் இன் தாக்கத்தைக் குறைக்க, பிரிஃபிலை பல துண்டுகளாகப் பிரிக்க நாம் வழக்கமாக சன்க்ட் பிரிஃபில்லைப் பயன்படுத்துகிறோம். KV தற்காலிக சேமிப்பு மறைமுக திசையனைச் சேமிப்பதால், MLA ஐ MHA வடிவமாக மாற்றுவது கடினமாகிறது.

MoE அடுக்கைப் பொறுத்தவரை, டிகோட் கட்டத்தில், ஒவ்வொரு நிபுணருக்கும் உள்ளீட்டு டோக்கன்களின் எண்ணிக்கையை அதிகரிக்க முடிந்தவரை பெரிய EP மற்றும் DP ஐப் பயன்படுத்துகிறோம், இதன் மூலம் GroupGEMM செயல்திறனை மேம்படுத்துகிறோம். பிரிஃபில் கட்டத்தில், டோக்கன்களின் எண்ணிக்கை ஏற்கனவே போதுமானதாக இருப்பதால், GroupGEMM ஏற்கனவே கணினி-கட்டுப்படுத்தப்பட்டதாக உள்ளது. எனவே, பிரிஃபில் செய்ய, சிறிய EP மற்றும் DP ஐப் பயன்படுத்தலாம்.

பிரிஃபில் மற்றும் டிகோட் ஒரே ஜிபியுவில் இயங்கினால், எந்தவொரு DP குழுவும் பிரிஃபிலைச் செய்யும் வரை, அனைத்து ஜிபியுக்களிலும் MoE அடுக்குகளின் தாமதம் அதிகரிக்கும், இது டிகோட் வெளியீட்டு வேகத்தை கணிசமாகப் பாதிக்கும்.

பிரிஃபில் பிரிப்பு தவிர, பின்வரும் அம்சங்களையும் மேம்படுத்த திட்டமிட்டுள்ளோம்:

AllToAll செயல்திறன்: எங்களின் AllToAll கர்னல் தற்போது இன்ஃபினிபேண்ட் அலைவரிசையில் 1/3 பங்கை மட்டுமே அடைய முடியும். இந்த கர்னலை தொடர்ந்து மேம்படுத்துவோம்.

EAGLE-பாணி அனுமான டிகோடிங்: மேலே உள்ள தரவுகளில், 1 டோக்கனை கணிக்க அனுமான டிகோடிங்கைப் பயன்படுத்துவதாக நாங்கள் கருதியுள்ளோம். EAGLE பல டோக்கன்களைக் கணிக்க ஒரு மர கட்டமைப்பைப் பயன்படுத்தலாம், ஏற்பு நீளத்தை மேம்படுத்தலாம், இது வெளியீட்டு வேகத்தை கணிசமாக அதிகரிக்கும்.

GEMM கர்னல்: முன்பு காட்டப்பட்ட ரூஃப்லைன் மாதிரியில், GEMM கர்னலின் செயல்திறன் தத்துவார்த்த வரம்பிலிருந்து இன்னும் வெகு தொலைவில் இருப்பதைக் காணலாம். இந்த கர்னலை தொடர்ந்து மேம்படுத்துவோம்.

GB200 NVL72: NVIDIA இன் சமீபத்திய GB200 NVL72 தீர்வில், 72 பிளாக்வெல் ஜிபியுக்கள் அதிவேக NVLink வழியாக ஒன்றோடொன்று இணைக்கப்பட்டுள்ளன. MoE கட்டமைப்பு மாதிரிகளுக்கு, இது ஒரு மிகப்பெரிய வாய்ப்பும் சவாலுமாகும்.

DeepSeek MoE மாதிரிகளின் பல முனைய வரிசைப்படுத்தல் அடர்ந்த LLMகளுடன் பொதுவாக சாத்தியமில்லாததை அடைகிறது: செயல்திறன் மற்றும் தாமதம் இரண்டையும் ஒரே நேரத்தில் மேம்படுத்துகிறது. அதிக ஜிபியுக்களில் நிபுணர்களை விநியோகிப்பதன் மூலம், சாதனத்திற்கு நினைவக அலைவரிசை அழுத்தத்தைக் குறைக்கிறோம், வேகமான செயலாக்கம் மற்றும் அதிக அமைப்பு செயல்திறனை செயல்படுத்துகிறோம். ஒற்றை முனைய வரிசைப்படுத்தல்களுடன் ஒப்பிடும்போது சமமான வெளியீட்டு வேகத்தில் EP128 உள்ளமைவுகள் 5 மடங்கு அதிக செயல்திறனை அடைவதை எங்கள் பரிசோதனைகள் காட்டுகின்றன.

மைக்ரோ-பேட்ச்சிங் போன்ற கணக்கீடு-தொடர்பு ஒன்றுடன் ஒன்று சேரும் நுட்பங்கள் பல முனைய தொடர்பு மேலதிகத்தைக் கணிசமாகக் குறைக்கின்றன, எங்கள் செயலாக்கம் 40% வரை வேக அதிகரிப்பைக் காட்டுகிறது. எங்கள் தனிப்பயன் AllToAll தொடர்பு கர்னல்கள் மற்றும் உகந்த கர்னல் செயலாக்கங்கள் 671B அளவுரு மாதிரியை திறம்பட வரிசைப்படுத்த உதவியுள்ளன.

MoE கட்டமைப்புகள் அவற்றின் திறனுக்காக பிரபலமடைந்து வருவதால், இந்த வரிசைப்படுத்தல் உத்திகள் அத்தகைய மாதிரிகளை திறம்பட அளவிடுவதற்கான மதிப்புமிக்க நுண்ணறிவுகளை வழங்குகின்றன.

DeepSeek-V3 தொழில்நுட்ப அறிக்கை

DeepSeek-V3/R1 அனுமான அமைப்பு கண்ணோட்டம்

Megatron-LM: மாதிரி இணைத்திறனைப் பயன்படுத்தி பல-பில்லியன் அளவுரு மொழி மாதிரிகளைப் பயிற்றுவித்தல்

EAGLE: அனுமான மாதிரிக்கு அம்ச நிச்சயமற்ற தன்மையை மறுபரிசீலனை செய்ய வேண்டும்

BibTeX

@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}
}

வரிசைப்படுத்தல் கட்டமைப்புகள்

இணை செயலாக்க நுட்பங்கள்

டென்சார் இணைத்திறன்

நிபுணர் இணைத்திறன்

தரவு இணைத்திறன்

ஒற்றை முனை மற்றும் பல முனை

கணக்கீடும் தொடர்பாடலும் மேலோட்டமாக நடைபெறுதல்

தாமத முறிவு

மேலோட்டமாக நடைபெறுதல்

EP8 மற்றும் EP128

ரூஃப்லைன்

GroupGEMM

GEMM

மைக்ரோபேட்ச்

பல்-டோக்கன் கணிப்பு

செயல்படுத்தல் & உகப்பாக்கங்கள்

அளவுத் திருத்தம்

MLA அடுக்கு

Cuda வரைபடம்

MoE ரவுட்டர்

எதிர்கால வேலை

முடிவுரை

குறிப்புகள்

மேற்கோள்