AWS EFA இல் டிரில்லியன் அளவுள்ள மாதிரிகளை இயக்குகிறது

Perplexity-இல், எமது தயாரிப்பு, எமது API-கள் மற்றும் எமது ஆராய்ச்சி அணிகளுக்காக சிறந்த மாதிரிகளைப் பயன்படுத்துகிறோம். Kimi-K2 போன்ற பெரிய திறந்த மூல Mixture-of-Experts மாதிரிகள் குறிப்பிட்ட சவால்களை ஏற்படுத்துகின்றன, ஏனெனில் 8x NVIDIA H200 GPU-களைக் கொண்ட மிகப்பெரிய இன்ஃபரன்ஸ் முனைகளால் அவற்றை திறம்பட இடமளிக்க முடியாது, இதனால் பல முனை (multi-node) வரிசைப்படுத்தல்கள் அவசியமாகின்றன. ConnectX-7 இல் அதிநவீன தாமதங்களை அடையும், DeepEP-இன் செயல்திறனை மிஞ்சும் நிபுணர் இணையாக்கத்திற்கான (expert parallelism) கர்னல்களின் தொகுப்பை நாங்கள் வழங்குகிறோம். AWS எலாஸ்டிக் ஃபேப்ரிக் அடாப்டரில் (EFA) சாத்தியமான தாமதங்களை அடையும் முதல் கர்னல்களும் இவையே ஆகும், இது டிரில்லியன் அளவுள்ள (trillion-parameter) மாதிரி வரிசைப்படுத்தல்களை செயல்படுத்துகிறது.

GitHub-இல் எமது கர்னல்களை முயற்சித்து, arXiv-இல் முழுமையான ஆராய்ச்சி கட்டுரையைப் படிக்கவும்.

அறிமுகம்

Mixture-of-Experts (MoE) என்பது நூற்றுக்கணக்கான பில்லியன் அல்லது டிரில்லியன் அளவுள்ள அளவுருக்களுக்கு (parameters) அளவிடுவதற்கான நிலையான கட்டமைப்பாக உருவெடுத்துள்ளது, அதே நேரத்தில் இன்ஃபரன்ஸ் நேரத்தில் நியாயமான தாமதத்தையும் வழங்குகிறது. MoE மாதிரிகள் டிரான்ார்மரின் அடர்ந்த அடுக்கை (dense layer) பல நிபுணர்கள் மற்றும் ஒரு சிறிய நேரியல் ரூட்டிங் அடுக்குடன் மாற்றுகின்றன, இது டோக்கனை எந்த நிபுணருடன் பெருக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. ஒரே நிபுணருடன் தொடர்புடைய டோக்கன்களைக் தொகுப்பதன் மூலம், சிக்கல் ஸ்பார்ஸ் (sparse) ஆகிறது மற்றும் எளிதில் இணைக்கத்தக்கதாக மாறுகிறது, ஏனெனில் இப்போது வெவ்வேறு நிபுணர்களை பல முனைகளில் பரவியுள்ள வெவ்வேறு GPU-களில் ஹோஸ்ட் செய்ய முடியும்.

torch.distributed மற்றும் NCCL போன்ற கூட்டுத் தொடர்பு நூலகங்களைப் பயன்படுத்தி எளிதாக செயல்படுத்தக்கூடிய டென்சார் பேரலலிசம் (TP) மற்றும் டேட்டா பேரலலிசம் (DP) போன்ற பிற இணையாக்க வடிவங்களைப் போலல்லாமல், MoE ரூட்டிங் என்பது ஸ்பார்ஸ் பியர்-டூ-பியர் தகவல்தொடர்பை உள்ளடக்கியது. ஒரு டிஸ்பாட்ச் கர்னல் உள்வரும் டோக்கன்களின் தொகுப்பைப் பிரித்து அவற்றை நிபுணர்களை ஹோஸ்ட் செய்யும் ரேங்குகளுக்கு அனுப்ப வேண்டும், அதே நேரத்தில் அதன் இரட்டைச் சிக்கலான கம்பைன் கர்னல், அவற்றின் செயலாக்கப்பட்ட சகாக்களைப் பெற்று அவற்றின் எடையுள்ள சராப்பியைக் கணக்கிட வேண்டும். இந்த மாற்றங்கள் கூட்டமைப்புகளுக்கு வரைபடமாக்கப்படாது மற்றும் குறைந்த தாமதத்தை அடைய தனிப்பயனாக்கப்பட்ட கர்னல்கள் தேவைப்படுகின்றன.

Perplexity-இல், நாங்கள் இடையக-முடிச்சு கர்னல்கள் (portable inter-node kernels) மற்றும் முடிச்சுக்குள்-சிறப்பாக்கப்பட்ட கர்னல்கள் (specialized intra-node kernels) இரண்டையும் உருவாக்கி வருகிறோம்; முந்தைய ஒரு கட்டுரையில் MoE communication பற்றிய எங்கள் பணியை மேலும் ஆழமாகப் பகிர்ந்திருந்தோம். மேலும், மற்றொரு வலைப்பதிவு பதிவில் multi-node deployment பெரிய MoE மாதிரிகளுக்கு குறைந்த தாமதமும் அதிக throughput-உம் வழங்க முடியும் என்பதையும் நாங்கள் காட்டினோம்.

இக்கட்டுரையில், NVSHMEM-அடிப்படையிலான எங்களது முந்தைய பணியின் செயல்திறனை பெரிதும் மேம்படுத்தும் எங்களது புதிய இன்டர்-நோடு கர்னல்களின் செயலாக்கத்தை ஆழமாக ஆராய்கிறோம். ConnectX-7 இல் அதிநவீன முடிவுகளை வெளிப்படுத்துவதோடு, எங்கள் இன்ஃபரன்ஸ் ரன்டைமுக்குள், மிகப்பெரிய திறந்த மூல மாதிரிகளுக்கு திறம்பட சேவை செய்ய கர்னல்களைப் பயன்படுத்தலாம் என்பதையும் நாங்கள் நிரூபிக்கிறோம்.

InfiniBand மூலம் இன்ஃபரன்ஸ்

NVLink மைக்ரோசெகண்ட் தாமதத்தில் அதிக செயல்திறனை (900GB/s) வழங்குவதால், டென்சார் பேரலலிசம் மற்றும் எக்பர்ட் பேரலலிசம் ஆகியவை ஒற்றை முனிக்குள் திறம்பட அளவிட முடியும். NVIDIA GB200 மற்றும் GB300 அமைப்புகள் டிரில்லியன் அளவுள்ள மாதிரிகளின் எடைகள் மற்றும் KV கேச்-களை வைத்திருக்க போதுமான நினைவகத்துடன் பொருத்தப்பட்டிருந்தாலும், 8 H200 GPU-கள் வரை கொண்ட AWS p5en இன்ஸ்டன்ஸில் வரிசைப்படுத்தல்கள் 1120GB HBM-க்கு மட்டுப்படுத்தப்பட்டுள்ளன, இது மாதிரி எடைகள் மற்றும் KV கேச் ஆகிய இரண்டிற்கும் இடையில் பிரிக்கப்பட வேண்டும். இதன் விளைவாக, சில மாதிரிகளுக்கு InfiniBand மூலம் இன்டர்-நோடு வரிசைப்படுத்தல்கள் அவசியமாகின்றன.

InfiniBand இன்னும் மிக வேகமாக இருந்தாலும், இது 400Gbps (50GB/s) செயல்திறனை மட்டுமே வழங்குகிறது, இது MoE ரூட்டிங்கிற்கு பத்தூசி முதல் நூற்றுக்கணக்கான மைக்ரோசெகண்ட் தாமதங்களைச் சேர்க்கிறது. அதிர்ஷ்டவசமாக, பகிரப்பட்ட நிபுணர்கள், மைக்ரோ-பேட்சிங் மற்றும் கம்ப்யூட்டேஷன்-கம்யூனிகேஷன் ஓவர்லாப்பிங் ஆகியவற்றைப் பயன்படுத்துவதன் மூலம் கூடுதல் தாமதங்களை மறைக்க முடியும், இதன் மூலம் போட்டி விலையில் சாத்தியமான செயல்திறனை வழங்க முடியும். H800 GPU-கள் மற்றும் NVIDIA ConnectX-7 InfiniBand அடாப்டர்களின் கிளஸ்டர்களில் வரிசைப்படுத்தப்பட்ட DeepSeek-R1 மூலம் DeepSeek இந்த நுட்பங்களுக்கு முன்னோடியாக இருந்தது.

AWS கிளஸ்டர்களில், அவற்றின் தனிப்பயன் எலாஸ்டிக் ஃபேப்ரிக் அடாப்டர்களின் (EFA) பயன்பாடு காரணமாக நிலைமை வேறுபட்டது. பயிற்சி பணிச்சுமைகளில் பொதுவாகப் பயன்படுத்தப்படும் கூட்டமைப்புகளில் இவை 400Gbps உச்ச செயல்திறனை வழங்கினாலும், MoE டிஸ்பாட்ச் மற்றும் கம்பைனின் போது பரிமாறப்படும் செய்தி அளவுகளில் இவை ConnectX-7 ஐ விட சற்று குறைவாகவே உள்ளன. கூடுதலாக, EFA GPUDirect Async-ஐ ஆதரிக்காது, பரிமாற்றங்களைத் தொடங்க GPU-ஐ NIC உடன் இணைக்கும் ஒரு CPU ப்ராக்ஸி த்ரெட் தேவைப்படுகிறது. கூடுதல் சிக்கல்தன்மை தவிர, கூடுதல் PCIe பரிவர்த்தனைகள் அனைத்து பரிமாற்றங்களுக்கும் மைக்ரோசெகண்ட் மதிப்புள்ள மேல்நிலையைச் சேர்க்கின்றன. NVSHMEM போன்ற கட்டமைப்புகள் கர்னல் எழுத்தாளர்களை சாதனம்-சாராத (device-independent) செயலாக்கங்களை வழங்க அனுமதிக்கின்றன, இருப்பினும் பொதுவான API-கள் செலவு மற்றும் தாமதம் இரண்டின் அடிப்படையில் வரிசைப்படுத்தல்களை பயனற்றதாக்கும் மேல்நிலைகளை ஏற்படுத்துகின்றன.

NVSHMEM-அடிப்படையிலான pplx-kernels

எங்களது முந்தைய கர்னல்கள் NVSHMEM மூலம் அடிப்படை போக்குவரத்து செயலாக்கத்தை சுருக்கின. சகாக்களை ஒத்திசைக்க அணு கவுண்டர்களைப் பயன்படுத்தி, டோக்கன்களை ஒவ்வொன்றாக மாற்ற அவை nvshmemx_putmem_signal_nbi_warp -ஐ நம்பியிருந்தன. இது IBGDA உடன் ConnectX-7 NIC-களில் நியாயமான செயல்திறனை வழங்கினாலும், ப்ராக்ஸி-அடிப்படையிலான ConnectX-7 IBRC செயலாக்கம் கணிசமாக மெதுவாக இருந்தது, அதே நேரத்தில் EFA செயலாக்கம் ஒரு மில்லிசெகண்டுக்கு கீழ் தாமதங்களை வழங்குவதில் தோல்வியடைந்தது.

அடிப்படைக் ஹார்டுவேருக்கான சோதனைப் படுக்கையாக (testbed) கர்னல்களைப் பயன்படுத்தினோம், அதே நேரத்தில் எங்கள் மாதிரிகளுக்கு வெளிப்படுத்த மிகவும் பொருத்தமான இடைமுகத்தைக் கண்டறிந்தோம். கர்னல்களுக்கும் NIC-களுக்கும் அல்லது ப்ராக்ஸி த்ரெட்டுகளுக்கும் இடையிலான அடிக்கடி மாற்றங்கள் மற்றும் தொடர்புகள் செயல்திறனைத் தடுத்தன என்று நாங்கள் ஊகித்தோம். கூடுதலாக, எங்களது செயலாக்கம் நம்பகத்தன்மையைத் தவிர ஹார்டுவேரிடமிருந்து எந்த உத்தரவாதங்களையும் நம்பியிருக்கவில்லை, ஒத்திசைவு ப்ரிமிடிவ்களின் மேல்நிலையைக் குறைப்பதன் மூலம் விஷயங்களை விரைவுபடுத்தலாம் என்பதை இது பரிந்துரைக்கிறது.

இந்த அவதானிப்புகளுக்குப் பிறகு, உச்ச செயல்திறனுக்காக ஹூட் கீழ் உள்ள சாதன கர்னல் - ஹோஸ்ட் ப்ராக்ஸி தொடர்புகளை உகந்ததாக்கி, அதே இடைமுகத்தை வெளிப்படுத்தும் எங்களது EFA-அடிப்படையிலான கர்னல்களை வடிவமைத்தோம்.

EFA மீது MoE all-to-all

விரிவாக்கு

புதிய கர்னல்கள் ஒரு கலப்பின CPU-GPU கட்டமைப்பைப் பின்பற்றுகின்றன, இதில் GPU கர்னல்கள் சாதனத்தில் உள்ள மாதிரியுடன் தொடர்பு கொள்கின்றன மற்றும் ஹோஸ்ட் CPU இல் இயங்கும் ஒரு ப்ராக்ஸி த்ரெட் NIC உடனான தொடர்புகளைக் கையாளுகிறது. புதிய கர்னல்கள் நாங்கள் KV கேச் மாற்றங்கள்க்காக உருவாக்கிய அதே TransferEngine-ஐ மீண்டும் பயன்படுத்துகின்றன.

MoE ரூட்டிங் ஒரு டிஸ்பாட்ச் கர்னலால் செய்யப்படுகிறது, இது மாதிரியிலிருந்து டோக்கன்கள் மற்றும் அவற்றை ரூட் செய்ய வேண்டிய பெர்-டோக்கன் நிபுணர்களைப் பெறுகிறது, அவற்றை நெட்வொர்க் வழியாக நிபுணர்களை ஹோஸ்ட் செய்யும் ரேங்குகளுக்கு அனுப்புகிறது. குழுவாக்கப்பட்ட GEMM கர்னல்கள் டோக்கன்களை நிபுணர் எடைகளுடன் பெருக்கிய பிறகு, கம்பைன் கர்னல் டோக்கன்களை அவற்றின் மூல ரேங்குகளுக்கு மாற்றி, மாதிரியிடம் திரும்பப் பெறுவதற்கு முன்பு அவற்றின் எடையுள்ள சராப்பியைக் கணக்கிடுகிறது.

Dispatch மற்றும் combine கர்னல்கள் இரண்டும், overlap மற்றும் micro-batching-ஐ எளிதாக்க sender மற்றும் receiver என்ற இரண்டு பாதிகளாகப் பிரிக்கப்படுகின்றன. Sender, token-களை send buffers-க்குள் shuffle செய்து, அவற்றை single RDMA write operation மூலம் peers-க்கு எழுத முடிகிறது. Sender-ஐ இயக்கிய பிறகு, network வழியாக நடைபெறும் transfer-கள் பின்னணியில் நிலுவையில் இருக்கும் போது GPU மற்ற பணிகளை (shared expert multiplication போன்றவை) செய்ய முடியும். Receiver கர்னல்கள், அனைத்து transfer-களும் கிடைக்கும் வரை block ஆகும். பின்னணியில், host-side worker thread transfer-களை கையாளுகிறது: send buffers நிரப்பப்பட்டதும் GPU அதற்கு signal அளிக்கிறது; அதற்குப் பிறகு அது RDMA writes-ஐ dispatch செய்கிறது. NIC completion-ஐ signal செய்தவுடன், அது receiver-ஐ unblock செய்து, அது token-களை model-க்கு மீட்டளிக்கிறது.

கர்னல்கள் ஹோஸ்டுடன் இறுக்கமாக இணைக்கப்பட்டுள்ளன, ஒருங்கிணைந்த நினைவகம் (unified memory) மற்றும் GDRCopy இரண்டின் மூலமாகவும் ஒன்றுக்கொன்று தொடர்பு கொள்கின்றன. CUDA ஒருங்கிணைந்த நினைவகம் சாதனம் நினைவகம் அல்லது ஹோஸ்ட் நினைவகத்தை இரண்டின் முகவரி இடங்களிலும் மேப் செய்ய அனுமதிக்கிறது, PCIe வழியாக தகவல்தொடர்புகளை வெளிப்படையாகக் கையாளுகிறது.

ஒருங்கிணைந்த நினைவகம் மொத்த மாற்றங்களுக்குப் பொருத்தமானதாக இருந்தாலும், குறைந்த தாமதப் polling GDRCopy மூலம் செய்யப்படுகிறது. GDRCopy மைக்ரோசெகண்ட் தாமதத்தில் GPU நினைவகத்திலிருந்து படிக்கவும் எழுதவும் GPUDirect RDMA-ஐப் பயன்படுத்துகிறது.

RDMA தவிர, ஒரு முனிக்குள் கர்னல்கள் டோக்கன்களைப் பரிமாற NVLink-ஐயும் பயன்படுத்துகின்றன. இது போக்குவரத்தின் குறிப்பிடத்தக்க பகுதியை, EP32-க்கு கால் பகுதி வரை மற்றும் EP64-க்கு எட்டில் ஒரு பங்கு வரை ஆஃப்லோட் செய்ய முடியும், இது ஒட்டுமொத்த குறைந்த தாமதங்களை அடைகிறது.

அனுப்பு மற்றும் பெறு பஃபர்கள் (Send and Receive Buffers)

Host proxy-ஐ உள்ளடக்கியதாக சாத்தியமான latency-களை அடைவதில் dispatch kernel-க்கான send buffers-ன் வடிவமைப்பு மிக முக்கியமானது. N ranks ஒவ்வொன்றும் T token-களை dispatch செய்கிறதாகவும், அவை ஒவ்வொன்றும் E இல் இருந்து R experts-க்கு route செய்யப்படுவதாகவும் இருந்தால், அனைத்தும் அதற்கே route செய்யப்பட்டால், ஒரு rank மோசமான சூழலில் அதிகபட்சம் N * T * max(R, E / N) token-களைப் பெற முடியும். மேலும், senders தங்கள் writes-ஐ தொடர்ச்சியாக (contiguously) அமைத்தால் மட்டுமே இந்தக் குறைந்தபட்ச வரம்பை அடைய முடியும், ஏனெனில் private receive buffers அதிக நினைவகத்தை பயன்படுத்திவிடும். Senders எந்த மோதலும் இன்றி தங்கள் writes-ஐ தொடர்ந்து அமைக்க முடிவதற்காக, routing தகவலின் முழு அறிவும் ஒவ்வொரு rank-க்கும் பகிரப்பட வேண்டும். எனவே, எங்கள் dispatch kernels முதலில் per-expert token counts-ஐ பரிமாறிக் கொள்கின்றன; அதன் பின்னர் ஒவ்வொன்றும் தங்கள் writes எங்கே செல்ல வேண்டும் என்பதையும், ஒவ்வொரு rank-இலிருந்தும் எந்த offset-இல் token-களை பெறுகின்றன என்பதையும் தீர்மானிக்க முடிகிறது.

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

விரிவாக்கு

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

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

டிஸ்பாட்ச் மற்றும் கம்பைன் (Dispatch and Combine)

கீழே உள்ள figures, GPU, CPU மற்றும் NIC இடையேயான timing மற்றும் interactions-ஐ விவரிக்கின்றன; model-ன் kernels-உடன் இடைச்செருகப்பட்ட dispatch மற்றும் combine-ன் ஒரு iteration-ஐ காட்டுகின்றன.

டிஸ்பாட்ச் அனுப்புவதில் வேலை தொடங்குகிறது, கர்னல் ரூட்டிங் தகவலை ஒருங்கிணைத்து, ஒற்றை தொகுதிக்குள் பகிரப்பட்ட நினைவகத்தில் அணு குவிப்பு (atomic accumulation) மூலம் பெர்-எக்ஸ்பர்ட் டோக்கன் எண்ணிக்கையைக் கணக்கிடுகிறது. டோக்கன் எண்ணிக்கைகள் கிடைத்தவுடன், அவை ஹோஸ்ட் நினைவகத்திற்கு நகலெடுக்கப்படுகின்றன மற்றும் பிற அனைத்து பியர் ரேங்குகளுக்கும் ரூட்டிங் தகவலை அனுப்பத் தொடங்க ப்ராக்ஸி உடனடியாக அறிவிக்கப்படுகிறது. இணையாக, டிஸ்பாட்ச் டோக்கன் எண்ணிக்கைகளின் ஒட்டுமொத்த கூட்டுத்தொகையைக் கணக்கிடுவதைத் தொடர்கிறது, தொடர்ச்சியான பெர்-பேர் அனுப்பு பஃபர்களில் டோக்கன்களை பேக் செய்யத் தேவையான ஆஃப்செட்டுகளை அடையாளம் காட்டுகிறது. ஆஃப்செட்டுகள் கிடைத்தவுடன், EFA வழியாக அனுப்பப்பட வேண்டிய அனைத்து டோக்கன்களும் அனுப்பு பஃபர்களில் பேக் செய்யப்படுகின்றன. இன்டர்-நோடு பியர்களின் அனுப்பு பஃபர்களில் எழுத்துக்களை இடுகையிட ப்ராக்ஸி அறிவிக்கப்படுகிறது. இன்ட்ரா-நோடு, கர்னல்களும் NVLink மூலம் ஒரே முனிக்குள் உள்ள தனிப்பட்ட பஃபர்களுக்கு டோக்கன்களை உடனடியாகத் தள்ளுகின்றன.

விரிவாக்கு

விரிவாக்கு

ஒரு ரேங்க் அனைத்து பியர்களிடமிருந்தும் ரூட்டிங் தகவலைப் பெற்றவுடன், அது அதை மையப்படுத்தி, டிஸ்பாட்ச் மற்றும் கம்பைனுக்கான டோக்கன்களை அடையாளம் காணத் தேவையான பல்வேறு ஆஃப்செட்டுகளைக் கணக்கிடுகிறது. மாற்றங்கள் ஏற்கனவே நிலுவையில் இருக்கும்போது இந்த வேலை CPU இல் செய்யப்படுகிறது, எனவே இது தாமதக் கிரிட்டிகல் அல்ல. அதன் பிறகு, அனைத்து ஆஃப்செட்டுகளும் தெரிந்தவுடன், தனிப்பட்ட பஃபர் அளவைத் தாண்டிய மீதமுள்ள டோக்கன்களுக்கான எழுத்துக்கள் இடுகையிடப்பட்டு, டிஸ்பாட்ச்சின் அனுப்பு கட்டம் முடிவடைகிறது.

Receiver பக்கத்தில், kernel முதலில் private buffers திறனைக் கடந்த, அதே node-இலிருந்து வரும் token-களை NVLink மூலம் இழுத்துக்கொள்கிறது. அடுத்ததாக, host proxy அனைத்து transfer-களின் completion-ஐ signal செய்யும் வரை அது block ஆகிறது. Signal கிடைத்தவுடன், token-கள் receive buffers-இலிருந்து group GEMM-க்கு அனுப்பப்படும் output tensor-க்குள் shuffle செய்யப்படுகின்றன. Dispatch மற்றும் combine இடையே buffers மறுபயன்படுத்தப்படுவதால், அடுத்த kernel அவற்றை overwrite செய்ய அனுமதிப்பதற்கு முன் receiver buffers read செய்யப்பட்டிருப்பதை உறுதிசெய்ய NVLink மற்றும் RDMA barriers இரண்டும் பயன்படுகின்றன.

கம்பைன் கர்னல்கள் தோராயமாக ஒத்த வடிவத்தைப் பின்பற்றுகின்றன, டோக்கன்களைக் கலக்குகின்றன, ப்ராக்ஸிக்கு சிக்னல் செய்கின்றன மற்றும் நிறைவுக்காகக் காத்திருக்கின்றன. இருப்பினும், அவற்றின் எழுத்துக்களை இடுகையிடுவதற்கான மெட்டாடேட்டா உடனடியாகக் கிடைக்கிறது மற்றும் அனைத்து ரிமோட் ஆஃப்செட்டுகளும் அறியப்படுகின்றன, எனவே இன்ட்ரா-நோடு மாற்றப்பட்ட அனைத்து டோக்கன்களும் NVLink வழியாக பெறுநர்களுக்குத் தள்ளப்படுகின்றன மற்றும் இன்டர்-நோடு டோக்கன்கள் ஒற்றை எழுத்து மூலம் மாற்றப்படுகின்றன. முடிவுகளைத் திருப்புவதற்கு முன்பு, கர்னல் பெறுநர் பஃபர்களிலிருந்து டோக்கன்களைக் குவித்து, அவற்றை வெளியீட்டு டென்சர்களில் எழுதுகிறது.

MoE ரூட்டிங்கிற்கான TransferEngine

எங்களது செயலாக்கத்தை முன்மாதிரி செய்ய, RDMA எழுத்துக்களை வழங்க மற்றும் கண்காணிக்க டிஸ்செகிரிகேட் ப்ரீஃபில் மற்றும் டிகோடுக்காக உருவாக்கப்பட்ட Transfer Engine-ஐ ஆரம்பத்தில் மீண்டும் பயன்படுத்தினோம். இருப்பினும், ஒவ்வொரு முனேயும் ஒரே பியருக்கு அதிக எண்ணிக்கையிலான எழுத்துக்களை இடுகையிடும் டிஸ்செகிரிகேட்டட் டிகோடிங் போலல்லாமல், MoE டிஸ்பாட்ச் அனைத்து பியர்களுக்கும் ஒரே செயல்பாட்டில் சிறிய மாற்றங்களை இடுகையிடுகிறது. அவுட்-ஆஃப்-தி-பாக்ஸ், செயல்திறன் உகந்ததாக இல்லை மற்றும் எங்களது செயலாக்கம் ConnectX-7 இல் DeepEP ஐ விட சுமார் 20us பின்தங்கியிருந்தது. இதன் விளைவாக, அதிக எண்ணிக்கையிலான பியர்களுடனான தொடர்புகளை உகந்ததாக்க, ஸ்கேட்டர் மற்றும் பேரியர் என்ற இரண்டு செயல்பாடுகளை ஆதரிக்க TransferEngine-ஐ சிறப்புபடுத்தினோம்.

ஸ்கேட்டர் மற்றும் பேரியர் செயல்பாடுகள் இரண்டும் அடிப்படை போக்குவரத்து செயலாக்கத்தால் பயன்படுத்தப்படும் தரவு கட்டமைப்புகளை முன்கூட்டியே நிரப்ப முன்கூட்டியே பதிவு செய்யக்கூடிய பியர் குழுக்களை வெளிப்படுத்துகின்றன (Work Request (WR) டெம்ப்ளேட்டிங்). ஸ்கேட்டர் ஒரே மூல பஃபரிலிருந்து வெவ்வேறு துண்டுகளை ஒரு பியர் குழுவின் அனைத்து உறுப்பினர்களிலும் வெவ்வேறு ஆஃப்செட்டுகளுக்கு நகலெடுக்கிறது. பேரியர் ஒரு உடனடி (immediate) மூலம் அனைத்து பியர்களுக்கும் சிக்னல் செய்கிறது. இந்த செயல்பாடுகளை மொத்தமாக வரிசைப்படுத்துவதும் கையாளுவதும் கிரிட்டிகல் பாதையில் மதிப்புமிக்க மைக்ரோசெகண்டுகளை மிச்சப்படுத்துகிறது. 400Gbps அலைவரிசையை வழங்க இரண்டு 200Gbps NIC-கள் ஒன்றிணைக்கும் EFA இல், ஒவ்வொரு மாற்றத்தின் பைட்டுகளையும் ஷார்ட் செய்வதற்குப் பதிலாக இரண்டு NIC-களிலும் பியர் குழுக்களை ஷார்ட் செய்கிறோம்.

முதலில் நாங்கள் TransferEngine-ஐ libfabric பயன்படுத்தி EFA-வில் மட்டும் உருவாக்கியிருந்தாலும், TransferEngine-இல் libibverbs பயன்படுத்தி ConnectX-7 ஆதரவைச் சேர்த்த பிறகு, MoE kernels எந்த code வரியையும் மாற்றாமல் ConnectX-7-இல் செயல்படுகின்றன. Scalable Reliable Datagram (SRD) அடிப்படையிலான EFA-வுடன் ஒப்பிடும்போது, ConnectX-7 connection setup மற்றும் peer management-க்காக கூடுதல் பணியை தேவைப்படுத்துகிறது. Reliable Connection (RC)-ஐ bootstrap செய்ய நாங்கள் Unreliable Datagram (UD) queue pair-ஐ பயன்படுத்துகிறோம். ஒவ்வொரு remote peer-க்காகவும் இரண்டு queue pairs-ஐ உருவாக்குகிறோம்: ஒன்று two-sided SEND/RECV-க்காகவும், மற்றொன்று one-sided WRITE_IMM-க்காகவும், ஏனெனில் RECV மற்றும் WRITE_IMM இரண்டும் வரிசைப்படி RECV operation-ஐ பயன்படுத்துகின்றன; அதே நேரத்தில் இந்த இரண்டு operation-களுக்கும் வேறுபட்ட buffer sizes தேவை. கூடுதலாக, ConnectX-7 மற்றும் GPU memory இடையே PCIe transaction ordering-ஐ தளர்த்துகிறோம். EFA-வைப் போலவே, WR templating optimization-ஐ செயல்படுத்துகிறோம். மேலும, அதே peer-க்கு பல சிறிய messages அனுப்பும்போது, message rate-ஐ மேம்படுத்த WR chaining-ஐ பயன்படுத்துகிறோம்.

GPU-பக்க வேலை இரண்டு அடாப்டர்களிலும் ஒரே மாதிரியாக இருப்பதால், EFA மற்றும் ConnectX-7 MoE ரூட்டிங்கிற்கான இடைவெளி அடிப்படை ஹார்டுவேரின் திறன்களால் தீர்மானிக்கப்படுகிறது என்பதை முன்னிலைப்படுத்த DeepEP இன் செயல்திறனை மிஞ்ச அடிப்படை போக்குவரத்து செயலாக்கத்தை அதன் வரம்புகளுக்குத் தள்ளினோம்.

மதிப்பீடு (Evaluation)

டிஸ்பாட்ச்/கம்பைன் தாமதம்

7168 மறைக்கப்பட்ட பரிமாணம் (hidden dimension), பிளாக்-ஸ்கேல் செய்யப்பட்ட fp8 டிஸ்பாட்ச் மற்றும் bf16 கம்பைன் கொண்ட நிலையான DeepSeek-V3 மற்றும் Kimi-K2 உள்ளமைவில் ConnectX-7 மற்றும் EFA அடாப்டர்களுடன் பொருத்தப்பட்ட H200 அமைப்புகளில் டிஸ்பாட்ச் மற்றும் கம்பைன் தாமதங்களை மதிப்பீடு செய்தோம். டிஸ்பாட்சுக்கான தொகுதி அளவு 128 மற்றும் கம்பைனுக்கான தொகுதி அளவு 4096 எனக் கருதுகிறோம். ConnectX-7 இல், GPUDirect Async (IBGDA) மற்றும் ஹோஸ்ட் ப்ராக்ஸி (IBRC) இரண்டையும் பயன்படுத்தி, DeepEP மற்றும் எங்களது முந்தைய NVSHMEM-அடிப்படையிலான pplx-kernels உடன் ஒப்பிடுகிறோம். EP16, EP32 மற்றும் EP64 இல் முறையே 459us, 582us மற்றும் 692us ஒருங்கிணைந்த தாமதங்களை அடைகிறோம். 519us, 966us மற்றும் 1159us ஆகியவற்றை அடையும் UCCL-EP போன்ற பொதுவான ப்ராக்ஸிகளை நம்பியிருக்கும் பிற EFA-அடிப்படையிலான கர்னல்களை விட சிறந்த செயல்திறனை வெளிப்படுத்துகிறோம்.

விரிவாக்கு

டிகோடில், எங்களது கர்னல்கள் DeepEP ஐ விட சில மைக்ரோசெகண்டுகள் மெதுவாக இருந்தாலும், எங்களது கம்பைன் கர்னல்கள் கணிசமாக வேகமானவை என்பதால் ஒட்டுமொத்த குறைந்த தாமதங்களை அடைகிறோம். நாங்கள் ஒரு ஹோஸ்ட் ப்ராக்ஸியைப் பயன்படுத்தினாலும், எங்களது மொத்த மாற்றங்கள் காரணமாக அனைத்து IBGDA-அடிப்படையிலான ப்ராக்ஸியற்ற (proxyless) செயலாக்கங்களின் செயல்திறனை மிஞ்சுகிறோம். ப்ராக்ஸி செயலாக்கம் முக்கியமானது என்பதையும் நாங்கள் காட்டுகிறோம், ஏனெனில் எங்களது மிகவும் சிறப்பு வாய்ந்த ப்ராக்ஸி பொதுவான NVSHMEM செயலாக்கத்தை விட ஒரு ஆர்டர் அளவு (order of magnitude) வேகமானது. MoE ரூட்டிங்கால் மாற்றப்படும் வழக்கமான பாக்கெட் அளவை நெருங்கியுள்ள 256KB பாக்கெட்டுகளை மாற்றும்போது EFA ConnectX-7 ஐ விட இரண்டு மடங்கு மெதுவாக இருக்கும் என்ற உண்மையின் போதிலும், இரண்டு அடாப்டர்களுக்கு இடையிலான இடைவெளி ஒட்டுமொத்தமாக குறைவான முக்கியத்துவம் வாய்ந்தது.

விரிவாக்கு

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

Kimi-K2 / DeepSeek-V3 செயல்திறன் (Throughput)

எங்கள் kernels-ன் செயல்திறனை நிரூபிக்க, Elastic Fabric Adapters (EFA) மற்றும் H200 GPUs கொண்ட பல p5en instances-களில் DeepSeek-V3 (671B parameters) மற்றும் Kimi-K2 (1T parameters) ஆகியவற்றை இயக்கும் எங்கள் உள் inference engine-ன் end-to-end செயல்திறனை நாங்கள் benchmark செய்கிறோம். Model-ஐ draft verification mode-இல் இயக்கி, ஒரு single MTP layer-ஐ பயன்படுத்தி 80% acceptance rate என கருதி latency-ஐ அறிக்கையிடுகிறோம்.

DeepSeek-V3 இல், திறமையான NVLink-மட்டும் டிஸ்பாட்ச் மற்றும் கம்பைன் கர்னல்களை இயக்கும் EP=8 இன்ட்ரா-நோடு பேஸ்லைனுக்கு எதிராக ஒப்பிடுகிறோம். இன்டர்-நோடு வரிசைப்படுத்தல்கள் ஒட்டுமொத்தமாக ஒற்றை-நோடு வரிசைப்படுத்தலின் செயல்திறனுடன் பொருந்துகின்றன அல்லது மிஞ்சுகின்றன, குறிப்பாக நடுத்தர அளவுள்ள தொகுதிகளில், முனைகள் முழுவதும் அளவிடுவது ஒட்டுமொத்த செயல்திறனுக்கான மேம்பாடுகளைக் கொண்டுவருகிறது என்பதை நிரூபிக்கிறது.

Kimi-K2 இல், கர்னல்கள் சேவை செய்வதை செயல்படுத்துகின்றன. அதன் அளவு காரணமாக, மாதிரி ஒரு H200 முனையில் டேட்டா பேரலலிசத்தைப் (DP) பயன்படுத்தி அதே முனிக்குள் பொருந்த முடியாது, எனவே மாதிரிக்கு சேவை செய்ய இன்டர்-நோடு வரிசைப்படுத்தல் தேவைப்படுகிறது. மாதிரிக்கு குறைந்த கவனம் தலைகள் (attention heads) இருப்பதால், DeepSeek-V3 ஐ விட சிறந்த தாமதங்களை அடைகிறோம் மற்றும் சாத்தியமான தாமதத்தில் EFA இல் மாதிரிக்கு சேவை செய்ய முடியும்.

விரிவாக்கு

விரிவாக்கு

மிக்ரோ-பேட்சிங்கையும் நாங்கள் বিবেচনা செய்துள்ளோம், இருப்பினும் இது மிக உயர்ந்த தொகுதி அளவுகளில் அல்லது ஒன்றுக்கும் மேற்பட்ட டிராஃப்ட் டோக்கன்களைப் பயன்படுத்தும் போது மட்டுமே தாமதங்களை மேம்படுத்தியது. குழுவாக்கப்பட்ட GEMM சிக்கல்களை இரண்டாகப் பிரிப்பதன் மூலம் பயனடைய, டோக்கன் தொகுதி அளவுகள் போதுமான அளவு அடர்த்தியாக இருக்க வேண்டும். பெரும்பாலான நேரம் இன்னும் MoE டிஸ்பாட்ச் மற்றும் கம்பைனுக்காக செலவிடப்படுகிறது, இது கர்னல்களில் ஏதேனும் கூடுதல் மேம்பாடுகள் தாமதங்களை மேம்படுத்தும் மற்றும் மிக்ரோ-பேட்சிங்கை எளிதாக்கும் என்பதைக் குறிக்கிறது.

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

EFA இல் செயல்திறனை மேம்படுத்த AWS பொறியாளர்களுடன் நெருக்கமாகப் பணிபுரிந்து வருகிறோம். எங்கள் தரப்பில், டேட்டா பிளேன் மேல்நிலையைக் குறைக்கும் libfabric புதுப்பிப்புகளைப் பின்பற்றுவோம். கூடுதலாக, பயனரகம் மேல்நிலைகளை மேலும் குறைக்கவும் ஹார்டுவேருடன் நேரடியாகத் தொடர்பு கொள்ளவும் efa-direct உடன் பரிசோதனை செய்வோம்.

குறிப்புகள்

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

Kimi K2 தொழில்நுட்ப அறிக்கை

DeepEP

UCCL-EP

NVIDIA Magnum IO NVSHMEM மற்றும் GPUDirect Async ஐப் பயன்படுத்தி HPC அமைப்புகளின் பிணைய செயல்திறனை மேம்படுத்துதல்

மேற்கோள்

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}