AWS EFA-യിൽ ട്രില്യൺ-പാരാമീറ്റർ മോഡലുകൾ പ്രാപ്തമാക്കുന്നു

Perplexity-ൽ, ഞങ്ങൾ ഞങ്ങളുടെ ഉൽപ്പന്നം, API-കൾ, ഗവേഷണ ടീമുകൾ എന്നിവയ്ക്കായി മികച്ച മോഡലുകൾ ഉപയോഗിക്കുന്നു. Kimi-K2 പോലെയുള്ള വലിയ ഓപ്പൺ സോഴ്സ് മിക്സ്ചർ-ഓഫ്-എക്സ്പെർട്ട്സ് (MoE) മോഡലുകൾ പ്രത്യേക വെല്ലുവിളികൾ ഉയർത്തുന്നു, കാരണം 8x NVIDIA H200 GPU-കൾ ഉള്ള ഏറ്റവും വലിയ ഇൻഫറൻസ് നോഡുകൾക്ക് അവയെ കാര്യക്ഷമമായി ഉൾക്കൊള്ളാൻ കഴിയില്ല, ഇത് മൾട്ടി-നോഡ് വിന്യാസങ്ങൾ ആവശ്യമാക്കിതീർക്കുന്നു. ConnectX-7-ൽ അത്യാധുനിക ലേറ്റൻസി കൈവരിക്കുന്ന, DeepEP-ന്റെ പ്രകടനത്തെ കവച്ചുവെക്കുന്ന, എക്സ്പെർട്ട് പാരലലിസത്തിനായുള്ള ഒരു കൂട്ടം കർണലുകൾ ഞങ്ങൾ അവതരിപ്പിക്കുന്നു. ട്രില്യൺ പാരാമീറ്റർ മോഡൽ വിന്യാസങ്ങൾ സാധ്യമാക്കിക്കൊണ്ട് AWS എലാസ്റ്റിക് ഫാബ്രിക് അപ്ഡേറ്ററിലും (EFA) പ്രായോഗിക ലേറ്റൻസി കൈവരിക്കുന്ന ആദ്യത്തെ കർണലുകൾ കൂടിയാണ് ഇവ.

GitHub-ൽ ഞങ്ങളുടെ കർണലുകൾ പരീക്ഷിച്ച് arXiv-ൽ മുഴുവൻ ഗവേഷണ പ്രബന്ധവും വായിക്കുക.

ആമുഖം

നൂറുകണക്കിന് കോടിയോ ട്രില്യണോ കണക്കിന് പാരാമീറ്ററുകളിലേക്ക് സ്കെയിൽ ചെയ്യുന്നതിനുള്ള സ്റ്റാൻഡേർഡ് ആർക്കിടെക്ചറായി മിക്സ്ചർ-ഓഫ്-എക്സ്പെർട്ട്സ് (MoE) ഉയർന്നുവന്നിട്ടുണ്ട്, അതേസമയം ഇൻഫറൻസ് സമയത്ത് ന്യായമായ ലേറ്റൻസിയും വാഗ്ദാനം ചെയ്യുന്നു. MoE മോഡലുകൾ ഒരു ട്രാൻസ്ഫോർമറിന്റെ ഡെൻസ് ലെയറിന് പകരം ഒരു കൂട്ടം എക്സ്പെർട്ടുകളും ഒരു ചെറിയ ലീനിയർ റൂട്ടിംഗ് ലെയറും ഉപയോഗിക്കുന്നു, ഇത് ഒരു ടോക്കൺ ഏത് എക്സ്പെർട്ടുമായാണ് ഗുണിക്കണ്ടത് എന്ന് തീരുമാനിക്കുന്നു. ഒരേ എക്സ്പെർട്ടുമായി ബന്ധപ്പെട്ട ടോക്കണുകളെ ഗ്രൂപ്പുചെയ്യുന്നതിലൂടെ, പ്രശ്നം സ്പർസും എളുപ്പത്തിൽ പാരലലൈസ് ചെയ്യാവുന്നതുമായി മാറുന്നു, കാരണം വിവിധ എക്സ്പെർട്ടുകൾക്ക് ഇപ്പോൾ ഒന്നിലധികം നോഡുകളിലായി വ്യാപിച്ചുകിടക്കുന്ന വിവിധ GPU-കളിൽ ഹോസ്റ്റ് ചെയ്യാൻ കഴിയും.

torch.distributed, NCCL തുടങ്ങിയ കളക്ടീവ് കമ്മ്യൂണിക്കേഷൻ ലൈബ്രറികൾ ഉപയോഗിച്ച് എളുപ്പത്തിൽ നടപ്പിലാക്കാൻ കഴിയുന്ന ടെൻസർ പാരലലിസം (TP), ഡാറ്റാ പാരലലിസം (DP) തുടങ്ങിയ മറ്റ് പാരലലിസം രൂപങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, MoE റൂട്ടിംഗിൽ സ്പർസ് പിയർ-ടു-പിയർ കമ്മ്യൂണിക്കേഷൻ ഉൾപ്പെടുന്നു. ഒരു ഡിസ്പാച്ച് കർണൽ ഇൻകമിംഗ് ടോക്കണുകളുടെ സെറ്റ് വിഭജിച്ച് എക്സ്പെർട്ടുകളെ ഹോസ്റ്റ് ചെയ്യുന്ന റാങ്കുകളിലേക്ക് അയക്കണം, അതേസമയം അതിന്റെ എതിർ പ്രശ്നമായ കമ്പൈൻ കർണൽ അവയുടെ പ്രോസസ്സ് ചെയ്ത രൂപങ്ങൾ സ്വീകരിക്കുകയും അവയുടെ വെയിറ്റഡ് ആവറേജ് കണക്കാക്കുകയും വേണം. ഈ കൈമാറ്റങ്ങൾ കളക്ടീവുകളിലേക്ക് മാപ്പ് ചെയ്യുന്നില്ല കൂടാതെ കുറഞ്ഞ ലേറ്റൻസി കൈവരിക്കുന്നതിന് കസ്റ്റമൈസ്ഡ് കർണലുകൾ ആവശ്യമാണ്.

Perplexity-ൽ, ഞങ്ങൾ പോർട്ടബിൾ ഇൻ്റർ-നോഡ് കർണലുകളും സ്പെഷ്യലൈസ്ഡ് ഇൻട്രാ-നോഡ് കർണലുകളും വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്നു, ഞങ്ങളുടെ ജോലി MoE കമ്മ്യൂണിക്കേഷൻ-നെക്കുറിച്ചുള്ള മുൻ ലേഖനത്തിൽ കൂടുതൽ ആഴത്തിൽ അവതരിപ്പിക്കുന്നു. വലിയ MoE മോഡലുകൾക്ക് കുറഞ്ഞ ലേറ്റൻസിയും ഉയർന്ന ത്രൂപുട്ടും മൾട്ടി-നോഡ് വിന്യാസത്തിന് കൊണ്ടുവരാൻ കഴിയുമെന്ന് മറ്റൊരു ബ്ലോഗ് പോസ്റ്റിലും ഞങ്ങൾ കാണിച്ചുതന്നിട്ടുണ്ട്.

ഈ ലേഖനത്തിൽ, NVSHMEM- അടിസ്ഥാനമാക്കിയുള്ള ഞങ്ങളുടെ മുൻകാല ജോലിയുടെ പ്രകടനത്തെ വലിയ തോതിൽ മെച്ചപ്പെടുത്തുന്ന ഞങ്ങളുടെ പുതിയ ഇൻ്റർ-നോഡ് കർണലുകളുടെ നടപ്പാക്കലിലേക്ക് ഞങ്ങൾ ആഴത്തിൽ പരിശോധിക്കുന്നു. ConnectX-7-ൽ അത്യാധുനിക ഫലങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിന് പുറമേ, ഞങ്ങളുടെ ഇൻഫറൻസ് റൺടൈമിനുള്ളിൽ, വലിയ ഓപ്പൺ സോഴ്സ് മോഡലുകളെ കാര്യക്ഷമമായി സേവിക്കാൻ കർണലുകൾ ഉപയോഗിക്കാമെന്നും ഞങ്ങൾ തെളിയിക്കുന്നു.

ഇൻഫിനിബാൻഡിന് മുകളിലുള്ള ഇൻഫറൻസ്

NVLink ഉയർന്ന ത്രൂപുട്ടും (900GB/s) മൈക്രോസെക്കൻഡ് ലേറ്റൻസിയും വാഗ്ദാനം ചെയ്യുന്നതിനാൽ, ടെൻസർ പാരലലിസത്തിനും എക്സ്പെർട്ട് പാരലലിസത്തിനും ഒരു ഒറ്റ നോഡിനുള്ളിൽ ഫലപ്രദമായി സ്കെയിൽ ചെയ്യാൻ കഴിയും. NVIDIA GB200, GB300 സിസ്റ്റങ്ങളിൽ ട്രില്യൺ-പാരാമീറ്റർ മോഡലുകളുടെ വെയിറ്റുകളും KV കാഷെയും ഹോൾഡ് ചെയ്യാൻ മതിയായ മെമ്മറി സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിലും, 8 H200 GPU വരെയുള്ള AWS p5en ഇൻസ്റ്റൻസിലെ വിന്യാസങ്ങൾ 1120GB HBM-ൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, ഇത് മോഡൽ വെയിറ്റുകൾക്കും KV കാഷെകൾക്കും ഇടയിൽ വിഭജിക്കണം. ফলস্বরূপ, ചില മോഡലുകൾക്ക് ഇൻഫിനിബാൻഡിന് മുകളിലുള്ള ഇൻ്റർ-നോഡ് വിന്യാസങ്ങൾ ആവശ്യമാണ്.

ഇൻഫിനിബാൻഡ് ഇപ്പോഴും അതിവേഗത്തിലാണെങ്കിലും, ഇത് 400Gbps (50GB/s) ത്രൂപുട്ട് മാത്രമേ വാഗ്ദാനം ചെയ്യുന്നുള്ളൂ, ഇത് MoE റൂട്ടിംഗിനായി പത്തുമുതൽ നൂറുകണക്കിന് മൈക്രോസെക്കൻഡ് ലേറ്റൻസി ചേർക്കുന്നു. ഭാഗ്യവശാൽ, മത്സരച്ചെലവിൽ പ്രായോഗിക ത്രൂപുട്ട് നൽകുന്നതിന് ഷെയേർഡ് എക്സ്പെർട്ടുകൾ, മൈക്രോ-ബാച്ചിംഗ്, കമ്പ്യൂട്ടേഷൻ-കമ്മ്യൂണിക്കേഷൻ ഓവർലാപ്പിംഗ് എന്നിവയിലൂടെ ചേർത്ത ലേറ്റൻസികൾ മറയ്ക്കാൻ കഴിയും. H800 GPU-കളുടെ ക്ലസ്റ്ററുകളിലും NVIDIA ConnectX-7 ഇൻഫിനിബാൻഡ് അഡാപ്റ്ററുകളിലും വിന്യസിച്ച് DeepSeek-R1 വഴി DeepSeek ഈ സാങ്കേതികവിദ്യകൾക്ക് തുടക്കം കുറിച്ചു.

AWS ക്ലസ്റ്ററുകളിൽ, അവയുടെ കസ്റ്റം എലാസ്റ്റിക് ഫാബ്രിക് അപ്ഡേറ്ററുകളുടെ (EFA) ഉപയോഗം കാരണം സാഹചര്യം വ്യത്യസ്തമാണ്. പരിശീലന വർക്ക്ലോഡുകളിൽ സാധാരണയായി ഉപയോഗിക്കുന്ന കളക്ടീവുകളിൽ ഇവ 400Gbps പീക്ക് ത്രൂപുട്ട് നൽകുന്നുണ്ടെങ്കിലും, MoE ഡിസ്പാച്ചിലും കമ്പൈനിലും കൈമാറ്റം ചെയ്യപ്പെടുന്ന സന്ദേശ വലുപ്പങ്ങളിൽ അവ ConnectX-7-നേക്കാൾ അല്പം പിന്നിലാണ്. കൂടാതെ, EFA GPUDirect Async-നെ പിന്തുണയ്ക്കുന്നില്ല, കൈമാറ്റങ്ങൾ ആരംഭിക്കുന്നതിനായി GPU-നെ NIC-ലേക്ക് ബ്രിഡ്ജ് ചെയ്യുന്ന ഒരു CPU പ്രോക്സി ത്രെഡ് ആവശ്യമാണ്. ചേർത്ത സങ്കീർണ്ണതയ്ക്ക് പുറമേ, അധിക PCIe ട്രാൻസാക്ഷനുകൾ എല്ലാ കൈമാറ്റങ്ങൾക്കും മൈക്രോസെക്കൻഡുകളുടെ ഓവർഹെഡ് ചേർക്കുന്നു. NVSHMEM പോലെയുള്ള ഫ്രെയിംവർക്കുകൾ ഉപകരണ-സ്വതന്ത്രമായ നടപ്പാക്കലുകൾ നൽകാൻ കർണൽ എഴുത്തുകാരെ അനുവദിക്കുന്നു, എന്നിരുന്നാലും ജനറിക് API-കൾ ചെലവിന്റെയും ലേറ്റൻസിയുടെയും കാര്യത്തിൽ വിന്യാസങ്ങളെ ഫലപ്രദമല്ലാത്തതാക്കുന്ന ഓവർഹെഡുകൾ വരുത്തുന്നു.

NVSHMEM-അടിസ്ഥാനമാക്കിയുള്ള pplx-kernels

ഞങ്ങളുടെ മുൻകാല kernels, NVSHMEM വഴി അടിസ്ഥിത transport നടപ്പാക്കൽ അബ്സ്ട്രാക്റ്റ് ചെയ്തിരുന്നു. അവ atomic counters ഉപയോഗിച്ച് peers-നെ synchronize ചെയ്ത് tokens ഒന്ന് വീതം കൈമാറ്റം ചെയ്യാൻ nvshmemx_putmem_signal_nbi_warp ൽ ആശ്രയിച്ചിരുന്നു. ഇത് ConnectX-7 NICs-ൽ IBGDA സഹിതം യുക്തിസഹമായ പ്രകടനം നൽകിയിരുന്നെങ്കിലും, proxy-based ConnectX-7 IBRC നടപ്പാക്കൽ കാര്യമായി മന്ദമായിരുന്നു, EFA നടപ്പാക്കൽ ഒരു മില്ലിസെക്കൻഡിന് താഴെയുള്ള latencyകൾ നൽകുന്നതിൽ പരാജയപ്പെട്ടു.

അടിസ്ഥാന hardware-നെ പരീക്ഷിക്കാനുള്ള testbed ആയി ഞങ്ങൾ kernels ഉപയോഗിച്ചു, അതേസമയം ഞങ്ങളുടെ models-ിന് പുറത്തു വെക്കാൻ ഏറ്റവും അനുയോജ്യമായ interface ഏതാണ് എന്നും നിശ്ചയിച്ചു. kernels-നും NICs-നും അല്ലെങ്കിൽ proxy threads-നും ഇടയിലെ ആവർത്തിച്ച transfer-ുകളും interactions-ും പ്രകടനത്തെ തടസപ്പെടുത്തുന്നു എന്നു ഞങ്ങൾ അനുമാനിച്ചു. കൂടാതെ, reliability ഒഴികെയുള്ള hardware ഉറപ്പുകളൊന്നും ഞങ്ങളുടെ നടപ്പാക്കൽ ആശ്രയിച്ചിരുന്നില്ല; അതിനാൽ synchronization primitives-ന്റെ overhead കുറച്ച് കാര്യങ്ങൾ വേഗത്തിലാക്കാമെന്ന് സൂചിപ്പിച്ചു.

ഈ നിരീക്ഷണങ്ങളെ തുടർന്ന്, അതേ interface പുറത്തു വെക്കുന്ന ഞങ്ങളുടെ EFA-അധിഷ്ഠിത kernels ഞങ്ങൾ രൂപകൽപ്പന ചെയ്തു; ഉയർന്ന പ്രകടനത്തിനായി device kernel - host proxy ഇടപെടലുകൾ ആന്തരികമായി ഓപ്റ്റിമൈസ് ചെയ്തു.

EFA-ക്ക് മുകളിലുള്ള MoE ഓൾ-ടു-ഓൾ

വലുതാക്കുക

പുതിയ കർണലുകൾ ഒരു ഹൈബ്രിഡ് CPU-GPU ആർക്കിടെക്ചർ പിന്തുടരുന്നു, അവിടെ GPU കർണലുകൾ ഉപകരണത്തിലെ മോഡലുമായി സംവദിക്കുകയും ഹോസ്റ്റ് CPU-ൽ പ്രവർത്തിക്കുന്ന ഒരു പ്രോക്സി ത്രെഡ് NIC-ഉടൻ ഉള്ള ഇടപെടലുകൾ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു. പുതിയ കർണലുകൾ KV കാഷെ കൈമാറ്റങ്ങൾക്കായി ഞങ്ങൾ നിർമ്മിച്ച അതേ TransferEngine വീണ്ടും ഉപയോഗിക്കുന്നു.

MoE റൂട്ടിംഗ് നിർവഹിക്കുന്നത് ഒരു ഡിസ്പാച്ച് കർണലാണ്, ഇത് മോഡലിൽ നിന്ന് ടോക്കണുകളും റൂട്ട് ചെയ്യേണ്ട പെർ-ടോക്കൺ എക്സ്പെർട്ടുകളും സ്വീകരിക്കുകയും, എക്സ്പെർട്ടുകളെ ഹോസ്റ്റ് ചെയ്യുന്ന റാങ്കുകളിലേക്ക് നെറ്റ്‌വർക്ക് വഴി അവ അയക്കുകയും ചെയ്യുന്നു. ഗ്രൂപ്പ്ഡ് GEMM കർണലുകൾ ടോക്കണുകളെ എക്സ്പെർട്ട് വെയിറ്റുകൾ ഉപയോഗിച്ച് ഗുണിച്ചതിനു ശേഷം, കമ്പൈൻ കർണൽ ടോക്കണുകളെ അവയുടെ സോഴ്സ് റാങ്കുകളിലേക്ക് കൈമാറുകയും മോഡലിലേക്ക് തിരികെ നൽകുന്നതിന് മുമ്പ് അവയുടെ വെയിറ്റഡ് ആവറേജ് കണക്കാക്കുകയും ചെയ്യുന്നു.

ഓവർലാപ്പിങ്ങും മൈക്രോ-ബാച്ചിങ്ങും സുഗമമാക്കുന്നതിന് ഡിസ്പാച്ച്, കമ്പൈൻ കർണലുകൾ ഒരു സെൻഡർ, റിസീവർ പകുതികളായി വിഭജിച്ചിരിക്കുന്നു. ഒരു ഒറ്റ RDMA റൈറ്റ് ഓപ്പറേഷൻ വഴി പിയറുകളിലേക്ക് എഴുതാൻ കഴിയുന്ന തരത്തിൽ സെൻഡർ ടോക്കണുകളെ സെൻഡ് ബഫറുകളിലേക്ക് ഷഫിൾ ചെയ്യുന്നു. സെൻഡർ എക്സിക്യൂട്ട് ചെയ്ത ശേഷം, പശ്ചാത്തലത്തിൽ നെറ്റ്‌വർക്കിലൂടെയുള്ള കൈമാറ്റങ്ങൾ പെൻഡിംഗിൽ ആയിരിക്കുമ്പോൾ GPU-ന് മറ്റ് ജോലികൾ (ഷെയേർഡ് എക്സ്പെർട്ട് മൾട്ടിപ്ലിക്കേഷൻ പോലുള്ളവ) ചെയ്യാൻ കഴിയും. എല്ലാ കൈമാറ്റങ്ങളും ലഭിക്കുന്നത് വരെ റിസീവർ കർണലുകൾ ബ്ലോക്ക് ചെയ്യുന്നു. പശ്ചാത്തലത്തിൽ, ഹോസ്റ്റ്-സൈഡ് വർക്കർ ത്രെഡ് കൈമാറ്റങ്ങൾ കൈകാര്യം ചെയ്യുന്നു: സെൻഡ് ബഫറുകൾ പോപ്പുലേറ്റ് ചെയ്യുമ്പോൾ GPU ഇതിന് സിഗ്നൽ നൽകുന്നു, അതിനുശേഷം അത് RDMA റൈറ്റുകൾ ഡിസ്പാച്ച് ചെയ്യുന്നു. NIC പൂർത്തിയാക്കൽ സിഗ്നൽ നൽകിക്കഴിഞ്ഞാൽ, അത് റിസീവറെ അൺബ്ലോക്ക് ചെയ്യുന്നു, അത് ടോക്കണുകൾ മോഡലിലേക്ക് തിരികെ നൽകുന്നു.

കർണലുകൾ ഹോസ്റ്റുമായി ശക്തമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, യൂണിഫൈഡ് മെമ്മറി, GDRCopy എന്നിവയിലൂടെ പരസ്പരം ആശയവിനിമയം നടത്തുന്നു. CUDA യൂണിഫൈഡ് മെമ്മറി ഡിവൈസ് മെമ്മറിയെയോ ഹോസ്റ്റ് മെമ്മറിയെയോ രണ്ടിന്റെയും വിലാസ ഇടങ്ങളിലേക്ക് മാപ്പ് ചെയ്യാൻ അനുവദിക്കുന്നു, PCIe വഴി കമ്മ്യൂണിക്കേഷൻ സുതാര്യമായി കൈകാര്യം ചെയ്യുന്നു.

ബൾക്ക് കൈമാറ്റങ്ങൾക്ക് യൂണിഫൈഡ് മെമ്മറി അനുയോജ്യമാണെങ്കിലും, മൈക്രോസെക്കൻഡ് ലേറ്റൻസിയിൽ GPU മെമ്മറിയിലേക്ക് വായിക്കാനും എഴുതാനും GDRCopy GPUDirect RDMA ഉപയോഗിക്കുന്നു.

RDMA കൂടാതെ, ഒരു നോഡിനുള്ളിൽ ടോക്കണുകൾ കൈമാറാൻ കർണലുകൾ NVLink പ്രയോജനപ്പെടുത്തുന്നു. ഇത് ട്രാഫിക്കിന്റെ ഗണ്യമായ ഒരു ഭാഗം ഓഫ്‌ലോഡ് ചെയ്യാൻ കഴിയും, EP32-ന് കാൽഭാഗം വരെയും EP64-ന് എട്ടിലൊന്ന് വരെയും, മൊത്തത്തിൽ കുറഞ്ഞ ലേറ്റൻസി കൈവരിക്കുന്നു.

സെൻഡ്, റിസീവ് ബഫറുകൾ

ഹോസ്റ്റ് പ്രോക്സിയുമായി ബന്ധപ്പെട്ട പ്രായോഗിക ലേറ്റൻസികൾ കൈവരിക്കുന്നതിന് ഡിസ്പാച്ച് കർണലിനായുള്ള സെൻഡ് ബഫറുകളുടെ ഡിസൈൻ നിർണായകമാണ്. ഓരോന്നും T ടോക്കണുകൾ ഡിസ്പാച്ച് ചെയ്യുന്ന N റാങ്കുകൾ ഉണ്ടെങ്കിൽ, E-ൽ നിന്ന് ഓരോന്നും R എക്സ്പെർട്ടുകളിലേക്ക് റൂട്ട് ചെയ്യപ്പെടുന്നു, ബാഡ് കേസിൽ ഒരു റാങ്കിന് N * T * max(R, E / N) ടോക്കണുകൾ വരെ ലഭിക്കും, എല്ലാം അതിലേക്ക് റൂട്ട് ചെയ്യുകയാണെങ്കിൽ. കൂടാതെ, സ്വകാര്യ റിസീവ് ബഫറുകൾ വളരെ বেশি മെമ്മറി ഉപയോഗിക്കുന്നതിനാൽ, സെൻഡറുകൾ അവരുടെ റൈറ്റുകൾ തുടർച്ചയായി സജ്ജീകരിക്കുമ്പോൾ മാത്രമേ ഈ മിനിമം ബൗണ്ട് കൈവരിക്കാൻ കഴിയൂ. വൈരുദ്ധ്യങ്ങളില്ലാതെ സെൻഡറുകൾക്ക് തുടർച്ചയായി റൈറ്റുകൾ സജ്ജീകരിക്കാൻ കഴിയുന്നതിന്, റൂട്ടിംഗ് വിവരങ്ങളെക്കുറിച്ചുള്ള പൂർണ്ണ അറിവ് ഓരോ റാങ്കിലേക്കും വിതരണം ചെയ്യണം. फलस्वरूप, ഞങ്ങളുടെ ഡിസ്പാച്ച് കർണലുകൾ ആദ്യം പെർ-എക്സ്പെർട്ട് ടോക്കൺ കൗണ്ടുകൾ കൈമാറ്റം ചെയ്യുന്നു, അതിനുശേഷം അവ ഓരോന്നിനും അവരുടെ റൈറ്റുകൾ എവിടേക്കാണ് പോകുന്നത് എന്നും ഏത് റാങ്കിൽ നിന്നാണ് അവർ ടോക്കണുകൾ സ്വീകരിക്കുന്നത് എന്നും നിർണ്ണയിക്കാൻ കഴിയും.

റൂട്ടിംഗ് വിവരങ്ങൾ കൈമാറ്റം ചെയ്യുന്നത് അനാവശ്യമായി ഉയർന്ന ലേറ്റൻസിക്ക് കാരണമാകും, കാരണം ഓരോ റാങ്കും സ്വന്തമായി റൈറ്റുകൾ ഡിസ്പാച്ച് ചെയ്യുന്നതിന് മുമ്പ് റൈറ്റുകൾ എത്തിച്ചേരുന്നതിനായി കാത്തിരിക്കേണ്ടി വരും. പകരം, ഓരോ റിസീവർ റാങ്കിലും ചെറിയ അളവിലുള്ള പ്രൈവറ്റ് പെർ-സെൻഡർ സ്പേസ് ഞങ്ങൾ കരുതിവെക്കുകയും റൂട്ടിംഗ് വിവരങ്ങളുടെ റൈറ്റുകൾക്കൊപ്പം ചില ടോക്കണുകൾ ഡിസ്പാച്ച് ചെയ്യുകയും ചെയ്യുന്നു. ഇത് ഡിസ്പാച്ച് പ്രക്രിയയിലുടനീളം മുഴുവൻ ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗവും ഉറപ്പാക്കുന്നു. റൂട്ടുകൾ കൈമാറ്റം ചെയ്ത ശേഷം, ബാക്കി ടോക്കണുകൾ ഓരോ റിമോട്ട് പിയറിനും ഒരു റൈറ്റ് വീതം വഴി കൈമാറ്റം ചെയ്യപ്പെടുന്നു. റൂട്ടിംഗ് വിവരങ്ങളുടെയും ഫിക്സഡ്-സൈസ്ഡ് ബഫറുകളുടെയും കൈമാറ്റം, അവ പോപ്പുലേറ്റ് ചെയ്യുന്ന കൈമാറ്റങ്ങൾക്കൊപ്പം, താഴെയുള്ള ചിത്രത്തിൽ ചിത്രീകരിച്ചിരിക്കുന്നു.

വലുതാക്കുക

കമ്പൈൻ കർണലുകൾ വളരെ ലളിതമാണ്, കാരണം ഡിസ്പാച്ച് ഘട്ടത്തിൽ നിന്ന് റൂട്ടിംഗ് വിവരങ്ങൾ അവയ്ക്ക് ഇതിനകം ലഭ്യമാണ്. ഓരോ പിയറിനും ഒരു റൈറ്റ് വെച്ച് അവയ്ക്ക് ടോക്കണുകൾ കോപ്പി ചെയ്യാൻ കഴിയും, അതിനുശേഷം ഔട്ട്പുട്ട് ടെൻസറുകളിലേക്ക് ടോക്കണുകളുടെ വെയിറ്റഡ് ആവറേജ് കണക്കാക്കാൻ അവ റിസീവ് ബഫറിൽ നിന്ന് വായിക്കുന്നു.

NVLink-നായി, ഒരു നോഡിനുള്ളിലെ സെൻഡ്, റിസീവ് ബഫറുകൾ പിയറുകളിലേക്ക് മാപ്പ് ചെയ്യപ്പെടുന്നു, അങ്ങനെ അയൽ റാങ്കുകളിൽ നിന്ന് നേരിട്ട് ടോക്കണുകൾ പുഷ് ചെയ്യാനോ പുൾ ചെയ്യാനോ അവയ്ക്ക് കഴിയും.

ഡിസ്പാച്ചും കമ്പൈനും

ചുവടെയുള്ള ചിത്രങ്ങൾ GPU, CPU, NIC എന്നിവ തമ്മിലുള്ള സമയവും ഇടപെടലുകളും വിശദമാക്കുന്നു, മോഡലിന്റെ കർണലുകളുമായി ഇടകലർന്ന ഡിസ്പാച്ചിന്റെയും കമ്പൈന്റെയും ഒരു ആവർരണം കാണിക്കുന്നു.

dispatch send-ൽ നിന്നാണ് പ്രവർത്തനം ആരംഭിക്കുന്നത്; ഇവിടെ kernel routing വിവരങ്ങൾ സമാഹരിക്കുകയും, single block-ിനുള്ളിൽ shared memory-യിൽ atomic accumulation വഴി ഓരോ expert-നുമുള്ള token counts കണക്കാക്കുകയും ചെയ്യുന്നു. token counts ലഭ്യമായതിനുശേഷം, അവ host memory-യിലേക്ക് copy ചെയ്യുകയും, routing വിവരങ്ങൾ മറ്റ് എല്ലാ peer ranks-ിലേക്കും dispatch ചെയ്യാൻ തുടങ്ങാൻ proxy-യെ ഉടൻ അറിയിക്കുകയും ചെയ്യുന്നു. ഇതോടൊപ്പം, dispatch token counts-ന്റെ cumulative sum കണക്കാക്കുന്നതും തുടരുന്നു; tokens-നെ contiguous per-peer send buffers-ലേക്ക് pack ചെയ്യാൻ ആവശ്യമായ offsets തിരിച്ചറിയുന്നു. offsets ലഭ്യമായ ഉടൻ, EFA വഴി അയക്കേണ്ട എല്ലാ tokens-ഉം send buffers-ലേക്ക് pack ചെയ്യുന്നു. inter-node peers-ന്റെ send buffers-ലേക്ക് writes post ചെയ്യാൻ proxy-യെ അറിയിക്കുന്നു. intra-node ആയി, kernels ഉടൻ തന്നെ അതേ node-ലെ private buffers-ലേക്ക് NVLink വഴി tokens push ചെയ്യുകയും ചെയ്യുന്നു.

വലുതാക്കുക

വലുതാക്കുക

ഒരു rank എല്ലാ peers-ൽ നിന്നുമുള്ള routing വിവരങ്ങൾ സ്വീകരിച്ചാൽ, അത് അവയെ centralize ചെയ്ത്, dispatch-ക്കും combine-ക്കും tokens തിരിച്ചറിയാൻ ആവശ്യമായ വിവിധ offsets കണക്കാക്കുന്നു. ഈ പ്രവൃത്തി CPU-യിൽ നടത്തപ്പെടുന്നു, അതേസമയം transfers ഇതിനകം തന്നെ pending ആകുന്നതിനാൽ ഇത് latency-critical അല്ല. തുടർന്ന്, എല്ലാ offsets അറിയാവുന്ന ഉടൻ, private buffer size കവിയുന്ന ശേഷിച്ച tokens-നുള്ള writes post ചെയ്യപ്പെടുകയും, dispatch-ന്റെ send phase പൂർത്തിയാകുകയും ചെയ്യുന്നു.

റിസീവർ എൻഡിൽ, പ്രൈവറ്റ് ബഫറുകളുടെ ശേഷിക്ക് അപ്പുറമുള്ള ഒരേ നോഡിൽ നിന്നുള്ള ടോക്കണുകൾ കർണൽ ആദ്യം NVLink വഴി പുൾ ചെയ്യുന്നു. അടുത്തതായി, എല്ലാ കൈമാറ്റങ്ങളുടെയും പൂർത്തീകരണം ഹോസ്റ്റ് പ്രോക്സി സിഗ്നൽ ചെയ്യുന്നത് വരെ അത് ബ്ലോക്ക് ചെയ്യുന്നു. സിഗ്നൽ ലഭിച്ചുകഴിഞ്ഞാൽ, ഗ്രൂപ്പ് GEMM-ന് കൈമാറിയ ഔട്ട്പുട്ട് ടെൻസറിലേക്ക് റിസീവ് ബഫറുകളിൽ നിന്ന് ടോക്കണുകൾ ഷഫിൾ ചെയ്യപ്പെടുന്നു. ഡിസ്പാച്ചും കമ്പൈനും ഇടയിൽ ബഫറുകൾ വീണ്ടും ഉപയോഗിക്കുന്നതിനാൽ, അടുത്ത കർണലിനെ അവയെ ഓവർറൈറ്റ് ചെയ്യാൻ അനുവദിക്കുന്നതിന് മുമ്പ് റിസീവർ ബഫറുകൾ വായിച്ചിട്ടുണ്ടെന്ന് NVLink, RDMA തടസ്സങ്ങൾ ഉറപ്പാക്കുന്നു.

combine kernels ഏകദേശമായി സമാനമായ ഒരു പാറ്റേൺ പിന്തുടരുന്നു; tokens shuffle ചെയ്യുകയും, proxy-യെ signal ചെയ്യുകയും, completion-നായി കാത്തിരിക്കുകയും ചെയ്യുന്നു. എന്നിരുന്നാലും, അവരുടെ writes post ചെയ്യുന്നതിനുള്ള metadata ഉടൻ ലഭ്യമാണ്, കൂടാതെ എല്ലാ remote offsets-ഉം അറിയപ്പെടുന്നതാണ്; അതിനാൽ intra-node ആയി കൈമാറ്റം ചെയ്യുന്ന എല്ലാ tokens-ഉം receivers-ലേക്ക് NVLink വഴി push ചെയ്യപ്പെടുകയും inter-node tokens single write വഴി കൈമാറപ്പെടുകയും ചെയ്യുന്നു. ഫലങ്ങൾ മടക്കി നൽകുന്നതിന് മുമ്പ്, kernel receiver buffers-ലുള്ള tokens accumulate ചെയ്ത് output tensors-ലേക്ക് എഴുതുന്നു.

MoE റൂട്ടിംഗിനായുള്ള TransferEngine

ഞങ്ങളുടെ നടപ്പാക്കൽ പ്രോട്ടോടൈപ്പ് ചെയ്യുന്നതിന്, RDMA റൈറ്റുകൾ ഇഷ്യൂ ചെയ്യുന്നതിനും ട്രാക്ക് ചെയ്യുന്നതിനും ഡിസഗ്രിഗേറ്റ് പ്രീഫില്ലിനായി നിർമ്മിച്ച Transfer Engine-ഉം ഡീകോഡും ഞങ്ങൾ ആദ്യം വീണ്ടും ഉപയോഗിച്ചു. എന്നിരുന്നാലും, ഓരോ നോഡും ഒരേ പിയറിലേക്ക് ധാരാളം റൈറ്റുകൾ പോസ്റ്റ് ചെയ്യുന്ന ഡിസഗ്രിഗേറ്റഡ് ഡീകോഡിംഗിൽ നിന്ന് വ്യത്യസ്തമായി, MoE ഡിസ്പാച്ച് ഒരു പ്രവർത്തനത്തിൽ എല്ലാ പിയറുകളിലേക്കും ചെറിയ കൈമാറ്റങ്ങൾ പോസ്റ്റ് ചെയ്യുന്നു. ഔട്ട്-ഓഫ്-ദി-ബോക്സ്, പ്രകടനം ഒപ്റ്റിമൽ അല്ലായിരുന്നു കൂടാതെ ഞങ്ങളുടെ നടപ്പാക്കൽ ConnectX-7-ൽ DeepEP-നേക്കാൾ 20us പിന്നിലായിരുന്നു. फलस्वरूप, വലിയൊരു കൂട്ടം പിയറുകളുമായുള്ള ഇടപെടലുകൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന് സ്കാറ്റർ, ബാരിയർ എന്നീ രണ്ട് പ്രവർത്തനങ്ങളെ പിന്തുണയ്ക്കാൻ ഞങ്ങൾ TransferEngine-നെ സ്പെഷ്യലൈസ് ചെയ്തു.

scatter, barrier പ്രവർത്തനങ്ങൾ രണ്ടും peer groups-നെ പുറത്തുവിടുന്നു; അവ മുൻകൂട്ടി രജിസ്റ്റർ ചെയ്ത് അടിസ്ഥിത transport നടപ്പാക്കലിൽ ഉപയോഗിക്കുന്ന data structures മുൻകൂട്ടി populate ചെയ്യാം (Work Request (WR) templating). Scatter, ഒരേ source buffer-ിൽ നിന്നുള്ള വ്യത്യസ്ത slices peer group-ിലെ എല്ലാ അംഗങ്ങളിലേക്കും വ്യത്യസ്ത offsets-ലേക്ക് copy ചെയ്യുന്നു. Barrier എല്ലാ peers-നും ഒരു immediate വഴി signal ചെയ്യുന്നു. ഈ പ്രവർത്തനങ്ങളെ bulk ആയി enqueue ചെയ്യുകയും കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നത് critical path-ിൽ വിലയേറിയ microseconds സംരക്ഷിക്കുന്നു. EFA-യിൽ, രണ്ട് 200Gbps NICs ചേർന്ന് 400Gbps bandwidth നൽകുന്നിടത്ത്, ഓരോ transfer-ന്റെയും bytes shard ചെയ്യുന്നതിനുപകരം ഞങ്ങൾ group peers-നെ രണ്ട് NICs-ൽ shard ചെയ്യുന്നു.

ആദ്യത്തിൽ ഞങ്ങൾ TransferEngine-നെ EFA-യിൽ മാത്രം, libfabric ഉപയോഗിച്ച് വികസിപ്പിച്ചിരുന്നെങ്കിലും, TransferEngine-ിൽ libibverbs ഉപയോഗിച്ച് ConnectX-7 support ചേർത്തതിന് ശേഷം, MoE kernels ഒരു കോഡ് വരിയും മാറ്റാതെ തന്നെ 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 consume ചെയ്യുന്നു, എന്നാൽ ഈ രണ്ട് operations-നും വ്യത്യസ്ത 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-ന്റെ പ്രകടനത്തെ കവച്ചുവെക്കാൻ ഞങ്ങൾ അന്തർലീനമായ ട്രാൻസ്പോർട്ട് നടപ്പിലാക്കലിനെ അതിന്റെ പരിധികളിലേക്ക് തള്ളിവിട്ടു.

മൂല്യനിർണ്ണയം

ഡിസ്പാച്ച്/കമ്പൈൻ ലേറ്റൻസി

7168 hidden dimension, block-scaled fp8 dispatch, bf16 combine എന്നിവയുള്ള standard DeepSeek-V3, Kimi-K2 configuration-ൽ ConnectX-7, EFA adapters ഘടിപ്പിച്ച H200 systems-ിൽ ഞങ്ങൾ dispatch, combine latencies മൂല്യനിർണയം നടത്തി. dispatch-ക്കായി batch size 128-ഉം combine-ക്കായി 4096-ഉം ഞങ്ങൾ പരിഗണിക്കുന്നു. ConnectX-7-ൽ, DeepEP-യുമായും IBGDA-യും host proxy (IBRC)-ഉം ഉപയോഗിക്കുന്ന ഞങ്ങളുടെ മുൻകാല NVSHMEM-based pplx-kernels-ുമായും ഞങ്ങൾ താരതമ്യം ചെയ്യുന്നു. EP16, EP32, EP64 എന്നിവയിൽ യഥാക്രമം 459us, 582us, 692us എന്ന combined latencies ഞങ്ങൾ നേടുന്നു. പൊതുവായ proxies-ിൽ ആശ്രയിക്കുന്ന UCCL-EP പോലുള്ള മറ്റ് EFA-based kernels-നെ ഞങ്ങൾ മറികടക്കുന്നു; അവ 519us, 966us, 1159us എന്നിവ കൈവരിക്കുന്നു.

വലുതാക്കുക

ഡീകോഡിൽ, ഞങ്ങളുടെ കർണലുകൾ DeepEPയേക്കാൾ കുറച്ച് മൈക്രോസെക്കൻഡ് മന്ദഗതിയിലാണെങ്കിലും, ഞങ്ങളുടെ കമ്പൈൻ കർണലുകൾ വളരെ വേഗതയുള്ളതായതിനാൽ ഞങ്ങൾ മൊത്തത്തിൽ കുറഞ്ഞ ലേറ്റൻസി കൈവരിക്കുന്നു. ഞങ്ങൾ ഒരു ഹോസ്റ്റ് പ്രോക്സി ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും, ഞങ്ങളുടെ ബൾക്ക് കൈമാറ്റങ്ങൾ കാരണം എല്ലാ IBGDA-അടിസ്ഥാനമാക്കിയുള്ള പ്രോക്സിലസ് നടപ്പിലാക്കലുകളുടെയും പ്രകടനത്തെ ഞങ്ങൾ കവച്ചുവെക്കുന്നു. ജനറിക് NVSHMEM നടപ്പിലാക്കലിനേക്കാൾ പടമടക്കം വേഗതയുള്ളതാണ് ഞങ്ങളുടെ ഉയർന്ന സ്പെഷ്യലൈസ്ഡ് പ്രോക്സി എന്നത് പ്രോക്സി നടപ്പിലാക്കൽ പ്രധാനമാണെന്നും ഞങ്ങൾ കാണിക്കുന്നു. MoE റൂട്ടിംഗ് വഴി കൈമാറ്റം ചെയ്യപ്പെടുന്ന സാധാരണ പാക്കറ്റ് വലുപ്പത്തിന് അടുത്തുള്ള 256KB പാക്കറ്റുകൾ കൈമാറുമ്പോൾ EFA ConnectX-7-നേക്കാൾ ഇരട്ടി മന്ദഗതിയിലാണെന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും, രണ്ട് അഡാപ്റ്ററുകൾ തമ്മിലുള്ള വ്യത്യാസം മൊത്തത്തിൽ കുറവാണ്.

വലുതാക്കുക

ഞങ്ങളുടെ ഡീകോഡ്-ഒപ്റ്റിമൈസ് ചെയ്ത കർണലുകൾക്ക് അധിക ട്വീക്കുകൾ ഇല്ലാതെ പ്രീഫിൽ ബാച്ച് വലുപ്പങ്ങളിലേക്ക് സ്കെയിൽ ചെയ്യാൻ കഴിയുമെങ്കിലും, പ്രകടനം DeepEP-ന് പിന്നിലാണ്. കമ്പൈനിന്റെ റിസീവർ വയ്സിൽ മാത്രം ഞങ്ങൾ ടോക്കണുകൾ അക്യുമുലേറ്റ് ചെയ്യുന്നു എന്ന വസ്തുതയാണ് ഇതിന് പ്രധാന കാരണം, അതേസമയം കൈമാറ്റം ചെയ്യപ്പെടുന്ന ഡാറ്റയുടെ അളവ് കുറയ്ക്കാൻ DeepEP സെൻഡറിൽ അക്യുമുലേറ്റ് ചെയ്യുന്നു. എന്നിരുന്നാലും, ഈ ഒപ്റ്റിമൈസേഷന് കൃത്യതയുമായി ബന്ധപ്പെട്ട പ്രത്യാഘാതങ്ങൾ ഉണ്ടാകാം. കൂടാതെ, കർണലുകൾ ഒരു റൈറ്റിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതിനാൽ, സെൻഡ്, റിസീവ് ബഫറുകൾക്കായി ഞങ്ങൾ കൂടുതൽ മെമ്മറി ഉപയോഗിക്കുന്നു.

Kimi-K2 / DeepSeek-V3 ത്രൂപുട്ട്

ഞങ്ങളുടെ കർണലുകളുടെ പ്രായോഗികത തെളിയിക്കുന്നതിനായി, എലാസ്റ്റിക് ഫാബ്രിക് അപ്ഡേറ്ററുകളും (EFA) H200 GPU-കളും സജ്ജീകരിച്ചിരിക്കുന്ന ഒന്നിലധികം p5en ഇൻസ്റ്റൻസുകളിൽ DeepSeek-V3 (671B പാരാമീറ്ററുകൾ), Kimi-K2 (1T പാരാമീറ്ററുകൾ) എന്നിവ സേവിക്കുന്ന ഞങ്ങളുടെ ഇൻ-ഹൗസ് ഇൻഫറൻസ് എഞ്ചിന്റെ എൻഡ്-ടു-എൻഡ് പ്രകടനം ഞങ്ങൾ ബെഞ്ച്മാർക്ക് ചെയ്യുന്നു. ഞങ്ങൾ മോഡൽ ഡ്രാഫ്റ്റ് വെരിഫിക്കേഷൻ മോഡിൽ പ്രവർത്തിപ്പിക്കുകയും ഒരു ഒറ്റ MTP ലെയർ ഉപയോഗിച്ച് 80% സ്വീകാര്യത നിരക്ക് അനുമാനിച്ചുകൊണ്ട് ലേറ്റൻസി റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യുന്നു.

DeepSeek-V3-ൽ, കാര്യക്ഷമമായ NVLink-മാത്രമുള്ള ഡിസ്പാച്ച്, കമ്പൈൻ കർണലുകൾ പ്രവർത്തിപ്പിക്കുന്ന ഒരു EP=8 ഇൻട്രാനോഡ് ബെഞ്ച്മാർക്കുമായി ഞങ്ങൾ താരതമ്യം ചെയ്യുന്നു. ഇൻ്റർ-നോഡ് വിന്യാസങ്ങൾ ഒത്തൊരുമയോടെ ഒറ്റ-നോഡ് വിന്യാസത്തിന്റെ പ്രകടനവുമായി പൊരുത്തപ്പെടുന്നു അല്ലെങ്കിൽ കവച്ചുവെക്കുന്നു, പ്രത്യേകിച്ചും ഇടത്തരം വലിപ്പമുള്ള ബാച്ചുകളിലേക്ക്, ഇത് നോഡുകളിലുടനീളം സ്കെയിലിംഗ് മൊത്തത്തിലുള്ള ത്രൂപുട്ടിൽ മെച്ചപ്പെടുത്തലുകൾ കൊണ്ടുവരുന്നു എന്ന് തെളിയിക്കുന്നു.

Kimi-K2-ൽ, കർണലുകൾ സേവനം സാധ്യമാക്കുന്നു. അതിന്റെ വലിപ്പം കാരണം, ഒരു H200 നോഡിൽ ഡാറ്റാ പാരലലിസം (DP) ഉപയോഗിച്ച് മോഡലിന് ഒരേ നോഡിനുള്ളിൽ ഫിറ്റ് ചെയ്യാൻ കഴിയില്ല, അതിനാൽ മോഡൽ സേവിക്കാൻ ഒരു ഇൻ്റർ-നോഡ് വിന്യാസം ആവശ്യമാണ്. മോഡലിന് കുറഞ്ഞ അറ്റൻഷൻ ഹെഡുകൾ ഉള്ളതിനാൽ, 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}
}