LLM സിസ്റ്റങ്ങൾക്കായുള്ള RDMA പോയിന്റ്-ടൂ-പോയിന്റ് ആശയവിനിമയം

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

ഞങ്ങളുടെ ഏറ്റവും പുതിയ ഗവേഷണ പ്രബന്ധം TransferEngine അവതരിപ്പിക്കുന്നു. എൻവിഡിയ ConnectX-7, AWS എലാസ്റ്റിക് ഫാബ്രിക് അഡാപ്റ്റർ (EFA) എന്നിവയുൾപ്പെടെ വിവിധ നെറ്റ്‌വർക്ക് ഇന്റർഫേസ് കൺട്രോളറുകളിൽ (NIC-കൾ) പ്രവർത്തിക്കുന്ന പോർട്ടബിൾ RDMA-അധിഷ്ഠിത ആശയവിനിമയ ലൈബ്രറിയാണിത്. Perplexity AI-ലെ മൂന്ന് പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളിൽ ഇതിന്റെ ഫലപ്രാപ്തി ഞങ്ങൾ തെളിയിക്കുന്നു:

ഡിസഗ്രിഗേറ്റഡ് പ്രീഫിൽ ആൻഡ് ഡീകോഡ്: പേജ് ചെയ്ത റൈറ്റുകളും UVM വാച്ചറുകളും ഉപയോഗിച്ച് ലെയർ-ബൈ-ലെയർ KvCache കൈമാറ്റം ചെയ്യുന്നു, ഇത് പ്രീഫിൽ, ഡീകോഡ് ഇൻസ്റ്റൻസുകളെ സ്വതന്ത്രമായി സ്കെയിൽ ചെയ്യാൻ അനുവദിക്കുന്നു.

2 സെക്കൻഡിനുള്ളിൽ RL പോസ്റ്റ്-ട്രെയിനിംഗിനായുള്ള വെയ്റ്റ് ട്രാൻസ്ഫർ: പരിശീലന, അനുമാന നോഡുകൾക്കിടയിൽ അതിവേഗ വെയ്റ്റ് സിൻക്രൊണൈസേഷൻ.

AWS EFA-യിൽ ട്രില്യൺ-പാരാമീറ്റർ മോഡലുകൾ പ്രവർത്തനക്ഷമമാക്കുന്നു: സ്കാറ്റർ, ബാരിയർ പ്രിമിറ്റീവുകൾ ഉപയോഗിച്ച് കുറഞ്ഞ ലേറ്റൻസിയുള്ള MoE ഡിസ്പാച്ച്, കമ്പൈൻ പ്രവർത്തനങ്ങൾ, ConnectX-7-ൽ മികച്ച ലേറ്റൻസിയും AWS EFA-യുമായി പൊരുത്തപ്പെടുന്ന ആദ്യത്തെ പ്രായോഗിക നടപ്പാക്കലും കൈവരിക്കുന്നു.

ഈ ലേഖനം TransferEngine-ൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, ഈ സിസ്റ്റങ്ങൾക്ക് കരുത്ത് പകരുന്ന ആശയവിനിമയ ലൈബ്രറിയാണിത്. arXiv-ൽ മുഴുവൻ ഗവേഷണ പ്രബന്ധവും വായിക്കുക, GitHub-ൽ കോഡ് പര്യവേക്ഷണം ചെയ്യുക.

ടെൻസർ പാരലലിസം, ഡാറ്റ പാരലലിസം തുടങ്ങിയ ഘടനാപരമായ സമാന്തര പാറ്റേണുകളിൽ കൂട്ടായ ആശയവിനിമയങ്ങൾ മികച്ചതാണ്, എന്നാൽ ഉയർന്നുവരുന്ന വർക്ക്ലോഡുകളിലേക്കുള്ള അവയുടെ ബാധകത പരിമിതപ്പെടുത്തുന്ന നിയന്ത്രണങ്ങൾ അവ ചുമത്തുന്നു:

സ്ഥിരമായ അംഗത്വം: ആരംഭിച്ച് സമയത്ത് ആഗോള ആശയവിനിമയ ലോകം സ്ഥാപിക്കുന്നതും എല്ലാ പങ്കാളികളിലുടനീളമുള്ള സമന്വയിപ്പിച്ച സജ്ജീകരണവും കൂട്ടായ്മകൾ ആവശ്യപ്പെടുന്നു. ഡിസഗ്രിഗേറ്റഡ് ഇൻഫറൻസിനെ സംബന്ധിച്ചിടത്തോളം ഇത് പ്രശ്നകരമാണ്, കാരണം ട്രാഫിക് പാറ്റേണുകൾക്ക് മറുപടിയായി പ്രീഫിൽ, ഡീകോഡ് ഇൻസ്റ്റൻസുകളുടെ എണ്ണം ചലനാത്മകമായി സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്.

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

പ്രവർത്തന ക്രമീകരണം: ആപ്ലിക്കേഷനുകൾക്ക് ഒരു കൂട്ടം പ്രവർത്തനങ്ങൾ പൂർത്തിയായി എന്ന് അറിയേണ്ടിവന്നാൽ പോലും, കൂട്ടായ API-കൾ സമന്വയിപ്പിച്ച സെമാന്റിക്സ് നിർബന്ധമാക്കുന്നു. ഉദാഹരണത്തിന്, KvCache കൈമാറ്റത്തിൽ, പ്രീഫിൽ ഇൻസ്റ്റൻസിൽ നിന്നുള്ള എല്ലാ പേജുകളും ഡീകോഡ് ഇൻസ്റ്റൻസിലേക്ക് ഏത് ക്രമത്തിലും എത്തിച്ചേരാം. അതുപോലെ, RL വെയ്റ്റ് അപ്ഡേറ്റുകളിൽ, ക്രമീകരണ നിയന്ത്രണങ്ങളില്ലാതെ എല്ലാ വെയ്റ്റ് ടെൻസറുകളും സ്വതന്ത്രമായി കൈമാറാൻ കഴിയും.

RDMA-അധിഷ്ഠിത പോയിന്റ്-ടൂ-പോയിന്റ് ആശയവിനിമയം സ്വാഭാവികമായും ഈ പരിമിതികളെ അഭിസംബോധന ചെയ്യുന്നു, എന്നാൽ മൂന്ന് തടസ്സങ്ങൾ ഇതിന്റെ സ്വീകാര്യത തടഞ്ഞിട്ടുണ്ട്:

ലൈബ്രറി പരിമിതികൾ: torch.distributed, NCCL എന്നിവ Send/Recv പോലെയുള്ള പോയിന്റ്-ടൂ-പോയിന്റ് API-കൾ നൽകുന്നുണ്ടെങ്കിലും, ഈ പ്രവർത്തനങ്ങൾ ഇപ്പോഴും കൂട്ടായ സെമാന്റിക്സും പരിമിതികളും പാരമ്പര്യമായി സ്വീകരിക്കുന്നു.

ഹാർഡ്‌വെയർ വൈവിധ്യം: Reliable Connection (RC) ട്രാൻസ്പോർട്ടോടെയുള്ള NVIDIA ConnectX NIC-കൾ ആണ് ഏറ്റവും സാധാരണമായ RDMA സജ്ജീകരണം, in-order ഡെലിവറി ഉറപ്പാക്കുന്നത്. AWS പോലുള്ള ക്ലൗഡ് പ്രൊവൈഡറുകൾ വ്യത്യസ്ത ഹാർഡ്‌വെയർ ഉപയോഗിക്കുന്നു; Scalable Reliable Datagram (SRD) ട്രാൻസ്പോർട്ടോടെയുള്ള Elastic Fabric Adapter (EFA) സന്ദേശങ്ങൾ out-of-order ആയി ഡെലിവർ ചെയ്യുന്നു. 400 Gbps ബാൻഡ്‌വിഡ്ത്ത് കൈവരിക്കാൻ EFAയ്ക്ക് നാല് 100 Gbps NIC-കൾ (അല്ലെങ്കിൽ രണ്ട് 200 Gbps NIC-കൾ) സമാഹരിക്കേണ്ടതുമുണ്ട്.

സോഫ്റ്റ്‌വെയർ പോർട്ടബിലിറ്റി: നിലവിലുള്ള RDMA ലൈബ്രറികൾ വെണ്ടർ ലോക്ക്-ഇൻ കാരണം ബുദ്ധിമുട്ടുന്നു. DeepEP-ന് ConnectX-ൽ മാത്രം ലഭ്യമായ GPU-ഇനീഷ്യേറ്റഡ് RDMA (IBGDA) ആവശ്യമാണ്. NVSHMEM EFA-യിൽ ഗുരുതരമായ പ്രകടന തകർച്ച കാണിക്കുന്നു. Mooncake, NIXL തുടങ്ങിയ ലൈബ്രറികൾക്ക് EFA പിന്തുണയില്ല അല്ലെങ്കിൽ പ്രാരംഭ വികസന ഘട്ടത്തിലാണ്.തൽഫലമായി, LLM അനുമാനത്തിനായി ക്രോസ്-പ്രൊവൈഡർ പരിഹാരങ്ങളൊന്നും നിലവിലില്ല.

TransferEngine നാല് പ്രധാന ശേഷികളിലൂടെ ഈ തടസ്സങ്ങളെ അഭിസംബോധന ചെയ്യുന്നു:

പൊതുവായ ട്രാൻസ്പോർട്ട് അനുമാനങ്ങൾ: ഒരു പ്രത്യേക NIC-നെ ലക്ഷ്യമാക്കുന്നതിന് പകരം, അടിസ്ഥാനപരമായ ട്രാൻസ്പോർട്ട് വിശ്വസനീയമാണെങ്കിലും ക്രമരഹിതമാണെന്ന് മാത്രമാണ് TransferEngine അനുമാനിക്കുന്നത്, അതായത് RC, SRD ട്രാൻസ്പോർട്ടുകൾ നൽകുന്ന ഗ്യാരണ്ടികളുടെ കവല.

ImmCounter സിൻക്രൊണൈസേഷൻ: സന്ദേശ ക്രമീകരണത്തെ ആശ്രയിക്കാതെ പ്രവർത്തിക്കുന്ന പൂർത്തീകരണ അറിയിപ്പിനായുള്ള ഒരു പുതിയ പ്രിമിറ്റീവ്, ക്രമീകരിച്ച (RC), ക്രമരഹിതമായ (SRD) ട്രാൻസ്പോർട്ടുകളിൽ ഒരേ കോഡ് പ്രവർത്തിക്കാൻ ഇത് പ്രാപ്തമാക്കുന്നു.

മൾട്ടി-NIC പിന്തുണ: ഓരോ GPU-വിനുമുള്ള ഒന്നിലധികം NIC-കളുടെ സുതാര്യമായ മാനേജ്മെന്റ്, ബാൻഡ്‌വിഡ്ത്ത് പരമാവധിയാക്കാൻ കൈമാറ്റങ്ങൾ സ്വയം വിഭജിക്കുന്നു.

കുറഞ്ഞ API ഉപരിതലം: സങ്കീർണ്ണമായ ആശയവിനിമയ പാറ്റേണുകൾ നിർമ്മിക്കാൻ പര്യാപ്തമായ ചെറിയൊരു കൂട്ടം പ്രവർത്തനങ്ങൾ.

രണ്ടു GPU/NUMA ഡൊമെയിനുകളിലായി അഭ്യർത്ഥന, callback പാതകൾ, CPU വർക്കറുകൾ, UVM ബഫറുകൾ, GPUകൾ, NICകൾ എന്നിവ കാണിക്കുന്ന TransferEngine സിസ്റ്റം ഡിസൈൻ.

TransferEngine ഓരോ GPU-വിനും ഒരു വർക്കർ ത്രെഡ് വീതം സൃഷ്ടിക്കുന്നു. ഓരോ വർക്കറും 1 മുതൽ 4 വരെ RDMA NIC-കളെ ഏകോപിപ്പിക്കുന്ന ഒരു DomainGroup കൈകാര്യം ചെയ്യുന്നു, ഇത് ഹാർഡ്‌വെയർ പ്ലാറ്റ്‌ഫോമിനെ ആശ്രയിച്ചിരിക്കുന്നു (ഒരു একক ConnectX-7 400 Gbps നൽകുന്നു, അതേസമയം EFA-യ്ക്ക് നാല് 100 Gbps അഡാപ്റ്ററുകൾ അല്ലെങ്കിൽ രണ്ട് 200 Gbps അഡാപ്റ്ററുകൾ ആവശ്യമാണ്). ഒരു DomainGroup-നുള്ളിൽ, ഓരോ Domain-ഉം ഹാർഡ്‌വെയർ-നിർദ്ദിഷ്ടമാണ് കൂടാതെ ഒ একক NIC കൈകാര്യം ചെയ്യുകയും ക്യൂ ജോടി മാനേജ്മെന്റ്, വർക്ക് സമർപ്പണം, പൂർത്തീകരണ പോളിംഗ് എന്നിവ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു.

ഓരോ TransferEngine ഇൻസ്റ്റൻസും പിയർ തിരിച്ചറിയലിനും കണ്ടെത്തലിനുമായി ഒ একক main address വെളിപ്പെടുത്തുന്നു. വിദൂര പിയറുകൾ നെറ്റ്‌വർക്ക് വിലാസങ്ങൾ എൻകോഡ് ചെയ്യുകയും ഔട്ട്-ഓഫ്-ബാൻഡ് ആശയവിനിമയത്തിനായി സീരിയലൈസ് ചെയ്യാൻ കഴിയുകയും ചെയ്യുന്ന NetAddr സ്ട്രക്റ്റുകൾ കൈമാറുന്നു. ഒരു സിസ്റ്റത്തിലെ എല്ലാ പിയറുകളും ഓരോ GPU-വിനും ഒരേ എണ്ണം NIC-കൾ ഉപയോഗിക്കണം. ഈ യൂണിഫോം കോൺഫിഗറേഷൻ TransferEngine-നെ കൈമാറ്റങ്ങൾ ബുദ്ധിപരമായി വിഭജിക്കാൻ അനുവദിക്കുന്നു: ഒരു കൈമാറ്റം ആരംഭിക്കുമ്പോൾ, ഉറവിടവും ലക്ഷ്യസ്ഥാനവും ഏതൊക്കെ NIC-കൾ ലഭ്യമാണെന്ന് കൃത്യമായി അറിയുന്നു, എല്ലാ അഡാപ്റ്ററുകളിലുടനീളം സ്വയമേവയുള്ള ലോഡ് ബാലൻസിങ് ഇത് സാധ്യമാക്കുന്നു.

അടിസ്ഥാനപരമായ RDMA ഇന്റർഫേസുകളുടെ സങ്കീർണ്ണത അമൂർത്തമാക്കുന്ന ഒരു ചെറിയ API TransferEngine നൽകുന്നു.

rust

#[serde] struct NetAddr(Bytes);
#[serde] struct MrDesc{ ptr: u64, rkeys: Vec<(NetAddr, u64)> }
struct MrHandle(NonNull<c_void>); type Offset = u64;
struct Pages{ indices: Vec<u32>, stride: u64, offset: Offset }
struct PeerGroupHandle(u64);
struct ScatterDst{ len: u64, src: Offset, dst: (MrDesc,Offset)}
enum OnDone { Callback(fn () -> ()), Flag(Atomic<bool>) }

trait TransferEngine {
  fn main_address() -> NetAddr;
  // Memory Region Management
  fn reg_mr(ptr, len, device) -> (MrHandle, MrDesc);
  // Two-sided Send/Recv
  fn submit_send(addr: NetAddr, msg: &[u8], cb: fn () -> ());
  fn submit_recvs(len: u64, cnt: u64, cb: fn (&[u8]) -> ());
  // One-sided Write
  fn expect_imm_count(imm: u32, count: u32, cb: fn () -> ());
  fn submit_single_write(len: u64, imm: Option<u32>
      src: (MrHandle, Offset), dst: (MrDesc, Offset), OnDone);
  fn submit_paged_writes(page_len: u64, imm: Option<u32>,
      src: (MrHandle, Pages), dst: (MrDesc, Pages), OnDone);
  // One-sided Write to a group of peers
  fn add_peer_group(addrs: Vec<NetAddr>) -> PeerGroupHandle;
  fn submit_scatter(h: Option<PeerGroupHandle>, OnDone,
      imm: Option<u32>, src: MrHandle, dst: Vec<ScatterDst>);
  fn submit_barrier(h: Option<PeerGroupHandle>, OnDone,
      imm: u32, dst: Vec<MrDesc>);
  // Watcher for CPU-GPU synchronization
  fn alloc_uvm_watcher(cb: fn(u64,u64) -> ()) -> NonNull<u64>;
}

API-യിൽ നിരവധി പ്രധാന ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

ഡാറ്റ കൈമാറ്റത്തിന് മുമ്പ് NIC-ൽ മെമ്മറി പ്രദേശങ്ങൾ രജിസ്റ്റർ ചെയ്യാൻ RDMA പ്രവർത്തനങ്ങൾക്ക് ആവശ്യമാണ്. reg_mr ഫംഗ്ഷൻ ഒരു പോയിന്റർ, നീളം, ഉപകരണം എന്നിവ സ്വീകരിക്കുന്നു, രണ്ട് ഹാൻഡിലുകൾ തിരികെ നൽകുന്നു:

MrHandle: കൈമാറ്റങ്ങൾക്ക് സോഴ്‌സായി ഉപയോഗിക്കുന്ന ഒരു ലോക്കൽ ഹാൻഡിൽ

MrDesc: രജിസ്റ്റർ ചെയ്ത മെമ്മറിയിലേക്ക് എഴുതാൻ വിദൂര പിയറുകളെ പ്രാപ്തമാക്കുന്നതിന് അവരുമായി കൈമാറ്റം ചെയ്യാൻ കഴിയുന്ന ഒരു സീരിയലൈസ് ചെയ്യാവുന്ന ഡിസ്ക്രിപ്റ്റർ

MrDesc ഘടനയിൽ മെമ്മറി പ്രദേശത്തേക്ക് വിദൂര ആക്സസ് നൽകുന്ന വിദൂര നെറ്റ്‌വർക്ക് വിലാസത്തിന്റെയും വിദൂര കീയുടെയും (ഓരോ NIC-നും ഒന്ന്) ഒരു ലിസ്റ്റ് അടങ്ങിയിരിക്കുന്നു. ഈ ഡിസൈൻ മൾട്ടി-NIC സജ്ജീകരണങ്ങൾ സ്വാഭാവികമായും കൈകാര്യം ചെയ്യുന്നു.

ചെറിയ സന്ദേശങ്ങൾക്കും RPC-ശൈലിയിലുള്ള നിയന്ത്രണ പ്ലെയിൻ സന്ദേശങ്ങൾക്കും, TransferEngine submit_send, submit_recvs എന്നിവ നൽകുന്നു:

submit_send: NetAddr വഴി തിരിച്ചറിഞ്ഞ ഒരു വിദൂര പിയറിലേക്ക് സന്ദേശം അയക്കുന്നു. സന്ദേശം ആന്തരികമായി പകർത്തപ്പെടുന്നു, അതിനാൽ കോളർക്ക് ഉടൻ തന്നെ ബഫർ വീണ്ടും ഉപയോഗിക്കാനോ റിലീസ് ചെയ്യാനോ കഴിയും.

submit_recvs: സ്വീകരിക്കൽ ബഫറുകളുടെ ഒരു പൂൾ പോസ്റ്റ് ചെയ്യുന്നു. ഒരു സന്ദേശം എത്തുമ്പോൾ, ലഭിച്ച ഡാറ്റയുമായി ഒരു കോൾബാക്ക് വിളിക്കപ്പെടുന്നു. കോൾബാക്ക് പൂർത്തിയായ ശേഷം ബഫർ സ്വയമേവ പൂളിലേക്ക് മടക്കിനൽകുന്നു.

ബൾക്ക് ഡാറ്റ കൈമാറ്റങ്ങൾക്കായി, TransferEngine സീറോ-കോപ്പി വൺ-സൈഡഡ് റൈറ്റ് പ്രവർത്തനങ്ങൾ നൽകുന്നു:

submit_single_write: ഉറവിടത്തിൽ നിന്ന് ലക്ഷ്യസ്ഥാനത്തേക്ക് ഒരു തുടർച്ചയായ പ്രദേശം കൈമാറുന്നു

submit_paged_writes: സൂചികകൾ, സ്ട്രൈഡുകൾ, ഓഫ്സെറ്റുകൾ എന്നിവ മുഖേന വ്യക്തമാക്കിയ തുടർച്ചയായല്ലാത്ത പേജുകൾ കൈമാറുന്നു

രണ്ട് പ്രവർത്തനങ്ങളും പൂർത്തിയാകുമ്പോൾ സ്വീകർത്താവിന് ആറ്റോമികമായി ഡെലിവർ ചെയ്യുന്ന ഓപ്ഷണലായ 32-ബിറ്റ് തൽക്ഷണ മൂല്യം സ്വീകരിക്കുന്നു.

ബാൻഡ്‌വിഡ്ത്ത് പരമാവധിയാക്കാൻ എഞ്ചിൻ സ്വയമേവ വലിയ കൈമാറ്റങ്ങൾ ഒന്നിലധികം NIC-കളിൽ വിഭജിക്കുന്നു.

ഒന്നിലധികം പിയറുകളെ ലക്ഷ്യമിടുന്ന പ്രവർത്തനങ്ങൾക്ക് (MoE റൂട്ടിംഗിൽ സാധാരണമാണ്), TransferEngine ഒപ്റ്റിമൈസ് ചെയ്ത പ്രിമിറ്റീവുകൾ നൽകുന്നു:

add_peer_group: വേഗത്തിലുള്ള ലുക്കപ്പിനായി പിയർ വിലാസങ്ങളുടെ ഒരു സെറ്റ് മുൻകൂട്ടി രജിസ്റ്റർ ചെയ്യുന്നു

submit_scatter: ഗ്രൂപ്പിലെ ഓരോ പിയറിലേക്കും വ്യത്യസ്ത ഡാറ്റ സ്ലൈസുകൾ അയക്കുന്നു

submit_barrier: എല്ലാ പിയറുകൾക്കും തൽക്ഷണ-മാത്രം അറിയിപ്പ് അയക്കുന്നു (സീറോ-ബൈറ്റ് കൈമാറ്റം)

ആന്തരിക ഡാറ്റാ ഘടനകൾ കാഷെ ചെയ്യുന്നതിലൂടെയും RDMA വർക്ക് അഭ്യർത്ഥനകൾ ടെംപ്ലേറ്റ് ചെയ്യുന്നതിലൂടെയും കുറഞ്ഞ ലേറ്റൻസിക്കായി ഈ പ്രവർത്തനങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യപ്പെട്ടിരിക്കുന്നു, ആവർത്തിച്ചുള്ള സജ്ജീകരണ ഓവർഹെഡ് ഒഴിവാക്കുന്നു.

LLM സിസ്റ്റങ്ങളിലെ ഒരു പ്രധാന വെല്ലുവിളി RDMA കൈമാറ്റങ്ങളെ GPU പുരോഗതിയുമായി ഏകോപിപ്പിക്കുക എന്നതാണ്. ആദർശപരമായി, GPU ഔട്ട്‌പുട്ട് ഉൽപ്പാദിപ്പിച്ച ഉടൻ തന്നെ ഡാറ്റ കൈമാറ്റം ആരംഭിക്കണം, എന്നാൽ CPU-ൽ നിന്ന് GPU പോൾ ചെയ്യുന്നത് അക്ഷമയളവുള്ളതാണ്.

TransferEngine UVM Watchers ഉപയോഗിച്ച് ഇതിനെ അഭിസംബോധന ചെയ്യുന്നു: GPU കർണലുകളാൽ (CUDA ഗ്രാഫുകൾക്കുള്ളിൽ പോലും) അപ്ഡേറ്റ് ചെയ്യാനും GDRCopy ഉപയോഗിച്ച് CPU കാര്യക്ഷമമായി പോൾ ചെയ്യാനും കഴിയുന്ന ഏകീകൃത വെർച്വൽ മെമ്മറി ലൊക്കേഷനുകൾ. ഒരു UVM വാച്ചർ അലോക്കേറ്റ് ചെയ്യുമ്പോൾ, GPU മൂല്യം അപ്ഡേറ്റ് ചെയ്യുമ്പോഴെല്ലാം വിളിക്കപ്പെടുന്ന ഒരു കോൾബാക്ക് രജിസ്റ്റർ ചെയ്യപ്പെടുന്നു.

ഇത് ലെയർ-ബൈ-ലെയർ KvCache കൈമാറ്റം പോലുള്ള പാറ്റേണുകൾ പ്രാപ്തമാക്കുന്നു: ഓരോ ട്രാൻസ്ഫോർമർ ലെയറും പൂർത്തിയായ ശേഷം, GPU വാച്ചർ വർദ്ധിപ്പിക്കുന്നു, തുടർന്ന് തുടർന്നുള്ള ലെയറുകൾ കണക്കുകൂട്ടുന്നത് തുടരുമ്പോൾ ആ ലെയറിന്റെ KvCache-ന്റെ RDMA കൈമാറ്റം ട്രിഗർ ചെയ്യുന്നു.

ഇനീഷ്യേറ്റർ വശത്തിനും (submit_write-ന്റെ കോളർ) സ്വീകർത്താവിന്റെ വശത്തിനും (Write പ്രവർത്തനങ്ങളുടെ ലക്ഷ്യം) TransferEngine പൂർത്തീകരണ അറിയിപ്പ് സംവിധാനങ്ങൾ നൽകുന്നു.

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

റിസീവർ-സൈഡ് അറിയിപ്പ്: പ്രധാന നവീകരണം ImmCounter ആണ്, 32-ബിറ്റ് immediate നമ്പറുകൾകൊണ്ട് ഇൻഡക്‌സ് ചെയ്ത കൗണ്ടറുകൾ ട്രാക്ക് ചെയ്യുന്ന ഒരു ഘടകം. ഒരു write ഓപ്പറേഷൻ ഒരു immediate മൂല്യം വഹിക്കുമ്പോൾ, ഡാറ്റ ഡെലിവറിയിൽ റിസീവറിന്റെ ImmCounter ആറ്റോമിക്കായി വർധിപ്പിക്കപ്പെടുന്നു. ഒരു നിർദ്ദിഷ്ട immediate മൂല്യം ലക്ഷ്യ കൗണ്ടിൽ എത്തുമ്പോൾ പ്രവർത്തിക്കുന്ന callback രജിസ്റ്റർ ചെയ്യാൻ expect_imm_count ഫങ്ഷൻ റിസീവറിനെ അനുവദിക്കുന്നു. കൗണ്ടറുകൾ GDRCopy വഴി GPU-യുമായി സുതാര്യമായി സമന്വയിപ്പിക്കാനോ, നേരിട്ട് പോൾ ചെയ്യാനോ, അല്ലെങ്കിൽ callbacks മുഖേന നിരീക്ഷിക്കാനോ കഴിയും.

സന്ദേശ ക്രമീകരണം ആവശ്യമില്ലാതെ ഈ സ്വീകർത്താവ്-വശത്തുള്ള സംവിധാനം വിശ്വസനീയമായ സമന്വയം നൽകുന്നു. ConnectX NIC-കളിലും (RC ട്രാൻസ്പോർട്ടിന് മുകളിൽ ഇൻ-ഓർഡർ ഡെലിവറി ഉറപ്പ് നൽകുന്നു) EFA NIC-കളിലും (SRD ട്രാൻസ്പോർട്ടിന് മുകളിൽ സന്ദേശങ്ങൾ ഔട്ട്-ഓർഡർ ആയി നൽകുന്നു) ഇത് ഒരുപോലെ നന്നായി പ്രവർത്തിക്കുന്നു.

TransferEngine Rust-ലാണ് നടപ്പാക്കിയിരിക്കുന്നത്; കുറഞ്ഞ latencyയും ഉയർന്ന throughputഉം നേടാൻ allocations, threading, synchronization എന്നിവ സൂക്ഷ്മമായി optimize ചെയ്തിരിക്കുന്നു. deviceകൾ attach ചെയ്തിരിക്കുന്ന NUMA node-യിലെ CPU core-ലേക്ക് pinned ചെയ്തുള്ള ഓരോ DomainGroup-നും ഒരു worker ത്രെഡ് വീതം engine spawn ചെയ്യുന്നു; ഇതിലൂടെ scheduling latencyയും memory access latencyയും രണ്ടും കുറയുന്നു. ഒരു domain-ന് പ്രത്യേകമായ data structures pin ചെയ്യുന്നതിന് ശേഷം allocate ചെയ്യപ്പെടുന്നു, അതുവഴി memory ശരിയായ NUMA node-ിൽ reserve ചെയ്യപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കാൻ. ഒരൊറ്റ worker ത്രെഡ് വരെ 4 Domain-കളെ കൈകാര്യം ചെയ്യുന്നു (ഓരോന്നും ഒരു NIC വീതം manage ചെയ്യുന്നു), അതേസമയം മറ്റൊരു സമർപ്പിത ത്രെഡ് GPU poll ചെയ്ത് UVM watchers അപ്‌ഡേറ്റ് ചെയ്യുന്നു. ത്രെഡുകൾക്കിടയിലെ ആശയവിനിമയം lock-free queues വഴിയാണ് നടക്കുന്നത്.

API അഭ്യർത്ഥനകൾ അനുയോജ്യമായ ഉപകരണത്തെ സേവിക്കുന്ന DomainGroup-ലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു; ആദ്യത്തേതു host-നെയും സേവിക്കുന്നു. ഒരു കർശനമായ loop-ൽ, domain worker പുതിയ ജോലികൾക്കായി poll ചെയ്യുകയും, പുതിയ അഭ്യർത്ഥനകളുടെ submission-ന് മുൻഗണന നൽകുകയും ചെയ്യുന്നു. hardware-നും configuration-നും അനുസരിച്ച്, അഭ്യർത്ഥനകൾ ലഭ്യമായ Domain-കളിലുടനീളം sharding ചെയ്ത് load-balance ചെയ്യപ്പെടുന്നു. ഒരു composite request-ന്റെ ആദ്യത്തെ Write ഉടൻതന്നെ NIC-ന്റെ send queue-ലേക്ക് പോസ്റ്റ് ചെയ്യപ്പെടുന്നു. പുതിയ അഭ്യർത്ഥനകൾ തീർന്നതിന് ശേഷം, worker pending operations മുന്നോട്ട് കൊണ്ടുപോകുന്നതിലേക്ക് കടക്കുന്നു, hardware pipeline നിറയ്ക്കാൻ writes പോസ്റ്റ് ചെയ്യുന്നു. തുടർന്ന്, completion queues പോൾ ചെയ്ത് പൂർത്തിയായ transfers-ഉം immediate counter increments-ഉം query ചെയ്യുന്നു. ഓരോ transfer-ിനുമുള്ള അറിയിപ്പുകൾ നൽകാൻ events aggregate ചെയ്യപ്പെടുന്നു, transfer എല്ലാ groups-ും പങ്കിടുന്ന ഒരു dedicated callback ത്രെഡിന് കൈമാറുന്നു.

ഒരു DomainGroup-നുള്ളിലെ ഷാർഡിംഗ് വഴക്കമുള്ളതാണ്. കൈമാറ്റങ്ങൾക്ക് സൂചിക പ്രകാരം നിർദ്ദിഷ്ട NIC-കളെ ലക്ഷ്യമിടാം. ഒരു റൈറ്റ് വിഭജിക്കാം. ഒന്നിലധികം റൈറ്റുകളിലേക്ക് വിവർത്തനം ചെയ്യുന്ന പേജ്ഡ് കൈമാറ്റങ്ങൾ, സ്കാറ്റർ, ബാരിയർ പ്രവർത്തനങ്ങൾ എന്നിവയ്ക്ക് എല്ലാ NIC-കളിലുടനീളം ഷാർഡ് ചെയ്യാം.

TransferEngine-ലുള്ള Domain-കൾ അവരുടെ നിയന്ത്രണത്തിലുള്ള hardware-നായി പ്രത്യേകവുമാണ്, optimize ചെയ്തവുമാണ്:

AWS EFA: EFA നടപ്പാക്കൽ libfabric ഉപയോഗിക്കുന്നു, DomainGroup-നുള്ളിൽ ഓരോ NIC-ക്കും ഒരു ഫാബ്രിക് ഡൊമെയിൻ കൈകാര്യം ചെയ്യുന്നു. പ്രധാന നടപ്പാക്കൽ തീരുമാനങ്ങളും ഒപ്റ്റിമൈസേഷനുകളും ഉൾപ്പെടുന്നു:

സീറോ-സൈസ്ഡ് റൈറ്റുകൾ: സീറോ-സൈസ്ഡ് റൈറ്റുകൾക്ക് പോലും സാധുവായ ലക്ഷ്യസ്ഥാന ഡിസ്ക്രിപ്റ്ററുകൾ ആവശ്യപ്പെട്ടുകൊണ്ട് EFA RDMA സ്പെസിഫിക്കേഷനിൽ നിന്ന് വ്യതിചലിക്കുന്നു. അതിനാൽ, എല്ലാ കൈമാറ്റങ്ങൾക്കും സാധുവായ ഡിസ്ക്രിപ്റ്ററുകൾ TransferEngine നിർബന്ധമാക്കുന്നു.

വർക്ക് അഭ്യർത്ഥന ടെംപ്ലേറ്റിംഗ്: പോസ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ് libfabric സ്ട്രക്റ്റുകളുടെ പൊതുവായ ഫീൽഡുകൾ മുൻകൂട്ടി നിറയ്ക്കുകയും നിലനിർത്തുകയും ചെയ്യുന്നു, ഇത് ബൾക്ക് കൈമാറ്റങ്ങൾക്കും പിയർ ഗ്രൂപ്പ് പ്രവർത്തനങ്ങൾക്കും പെർ-ഓപ്പറേഷൻ ഓവർഹെഡ് കുറയ്ക്കുന്നു

NVIDIA ConnectX-7: ConnectX-7 നടപ്പാക്കൽ RC ട്രാൻസ്പോർട്ടിനൊപ്പം libibverbs ഉപയോഗിക്കുന്നു. പ്രധാന നടപ്പാക്കൽ തീരുമാനങ്ങളും ഒപ്റ്റിമൈസേഷനുകളും ഉൾപ്പെടുന്നു:

ഹാൻഡ്ഷെയ്കുകൾക്കായുള്ള UD ക്യൂ ജോഡികൾ: ഓരോ Domain-ഉം RC കണക്ഷൻ ഹാൻഡ്ഷെയ്കുകൾ കൈമാറാൻ അൺറിലയബിൾ ഡാറ്റാഗ്രാം (UD) ക്യൂ ജോടി ഉപയോഗിക്കുന്നു.

പ്രത്യേക RC ക്യൂ ജോഡികൾ: ഓരോ പിയറിനും 2 RC ക്യൂ ജോഡികൾ സൃഷ്ടിക്കുന്നു, ഒന്ന് ടൂ-സൈഡഡ് Send/Recv പ്രവർത്തനങ്ങൾക്കും മറ്റൊന്ന് വൺ-സൈഡഡ് Write, WriteImm പ്രവർത്തനങ്ങൾക്കും. Recv, WriteImm പൂർത്തീകരണങ്ങൾ രണ്ടും പോസ്റ്റിംഗ് ക്രമത്തിൽ വർക്ക് അഭ്യർത്ഥനകൾ ഉപയോഗിക്കുന്നതിനാൽ ഈ വേർതിരിവ് ആവശ്യമാണ്, ഇത് ഇടപെടലില്ലാതെ WriteImm പിന്തുണയ്ക്കുമ്പോൾ ഉയർന്ന തലത്തിലുള്ള Recv സെമാന്റിക്സ് അനുവദിക്കുന്നു.

വർക്ക് അഭ്യർത്ഥന ടെംപ്ലേറ്റിംഗ്: ബൾക്ക് കൈമാറ്റങ്ങൾക്കും പിയർ ഗ്രൂപ്പുകൾക്കുമായി വർക്ക് അഭ്യർത്ഥന ഘടനകളുടെ പൊതുവായ ഫീൽഡുകൾ മുൻകൂട്ടി നിറയ്ക്കുന്നു.

വർക്ക് അഭ്യർത്ഥന ചെയിനിംഗ്: ibv_send_wr-ന്റെ next പോയിന്റർ വഴി 4 വർക്ക് അഭ്യർത്ഥനകൾ വരെ ബന്ധിപ്പിക്കുന്നു, NIC-ലേക്കുള്ള ഡോർബെൽ റിംഗുകളുടെ എണ്ണം കുറയ്ക്കുന്നു.

റിലാക്സ്ഡ് ഓർഡറിംഗ്: NIC-ക്കും GPU മെമ്മറിക്കും ഇടയിലുള്ള ഔട്ട്-ഓഫ്-ഓർഡർ PCIe ഇടപാടുകൾ അനുവദിക്കാൻ IBV_ACCESS_RELAXED_ORDERING പ്രാപ്തമാക്കുന്നു.

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

BibTeX

@online{perplexity2025RdmaPointToPointCommunicationForLlmSystems,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{RDMA point-to-point communication for LLM systems}},
  date = {2025-11-05},
  url = {https://www.perplexity.ai/hub/blog/rdma-point-to-point-communication-for-llm-systems}
}

പ്രചോദനം

TransferEngine

API ഡിസൈൻ

മെമ്മറി രജിസ്ട്രേഷൻ

ടൂ-സൈഡഡ് Send/Recv

വൺ-സൈഡഡ് റൈറ്റ്

പിയർ ഗ്രൂപ്പുകളും ബൾക്ക് പ്രവർത്തനങ്ങളും

UVM വാച്ചർ: GPU-ൽ നിന്ന് CPU-വിലേക്കുള്ള സിഗ്നലിംഗ്

പൂർത്തീകരണ അറിയിപ്പ്

നടപ്പാക്കൽ

ഹാർഡ്‌വെയർ-നിർദ്ദിഷ്ട ഒപ്റ്റിമൈസേഷനുകൾ

ഉപസംഹാരം

ഉദ്ധരണി