LLM அமைப்புகளுக்கான RDMA பாயிண்ட்-டூ-பாயிண்ட் தொடர்பு

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

எங்களின் சமீபத்திய ஆராய்ச்சித் தாள், NVIDIA ConnectX-7 மற்றும் AWS Elastic Fabric Adapter (EFA) உள்ளிட்ட பல்வேறு நெட்வொர்க் இடைமுகக் கட்டுப்படுத்திகளில் (NICகள்) வேலை செய்யும் போர்ட்டபிள் RDMA-அடிப்படையிலான தொடர்பு நூலகமான TransferEngine-ஐ அறிமுகப்படுத்துகிறது. Perplexity இல் உள்ள மூன்று தயாரிப்பு அமைப்புகளில் இதன் செயல்திறனை நாங்கள் நிரூபிக்கிறோம்:

பிரிக்கப்பட்ட ப்ரீஃபில் மற்றும் டிகோட்: பக்கப்படுத்தப்பட்ட எழுத்துகள் மற்றும் UVM கண்காணிப்பாளர்கள் (watchers) மூலம் லேயர்-பை-லேயர் KvCache பரிமாற்றம், ப்ரீஃபில் மற்றும் டிகோட் நிகழ்வுகளைத் தனித்தனியாக அளவிட அனுமதிக்கிறது.

2 வினாடிகளுக்குள் RL பிந்தைய பயிற்சிக்கான எடைப் பரிமாற்றம்: பயிற்சி மற்றும் அனுமான முனைகளுக்கு இடையே மின்னல் வேக எடை ஒத்திசைவு.

AWS EFA இல் டிரில்லியன்-பாராமீட்டர் மாதிரிகளை இயக்குதல்: ஸ்கேட்டர் மற்றும் பேரியர் பிரிமிடிவ்களைப் பயன்படுத்தி குறைந்த தாமத MoE டிஸ்பாட்ச் மற்றும் இணைத்தல் செயல்பாடுகள், ConnectX-7 இல் அதிநவீன தாமதத்தை அடைகிறது மற்றும் AWS EFA உடன் இணக்கமான முதல் சாத்தியமான செயலாக்கமாகும்.

இந்தக் கட்டுப்பாடு TransferEngine-ஐ மையமாகக் கொண்டது, இந்த அமைப்புகளை இயக்கும் தொடர்பு நூலகம். முழுமையான ஆராய்ச்சித் தாளை arXiv இல் படித்து, GitHub இல் குறியீட்டை ஆராயுங்கள்.

டென்சார் பேரலலிசம் மற்றும் டேட்டா பேரலலிசம் போன்ற கட்டமைக்கப்பட்ட இணை வடிவங்களில் கூட்டுத் தொடர்புகள் சிறந்து விளங்குகின்றன, ஆனால் அவை வளர்ந்து வரும் பணிச்சுமைகளுக்கு அவற்றின் பொருந்தக்கூடிய தன்லைக் கட்டுப்படுத்தும் கட்டுப்பாடுகளை விதிக்கின்றன:

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

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

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

RDMA-அடிப்படையிலான பாயிண்ட்-டூ-பாயிண்ட் தொடர்பு இயற்கையாகவே இந்த வரம்புகளை நிவர்த்தி செய்கிறது, ஆனால் மூன்று தடைகள் அதன் ஏற்றுக்கொள்ளலைத் தடுத்துள்ளன:

நூலக வரம்புகள்: torch.distributed மற்றும் NCCL ஆகியவை Send/Recv போன்ற பாயிண்ட்-டூ-பாயிண்ட் APIகளை வழங்கினாலும், இந்த செயல்பாடுகள் இன்னும் கூட்டு சொற்பொருள் மற்றும் வரம்புகளைப் பெறுகின்றன.

வன்பொருள் பன்முகத்தன்மை: நம்பகமான இணைப்பு (RC) போக்குவரத்து கொண்ட NVIDIA ConnectX NICகள் மிகவும் பொதுவான RDMA அமைப்பாகும், இது வரிசைப்படி விநியோகத்தை உறுதி செய்கிறது. AWS போன்ற கிளவுட் வழங்குநர்கள் வெவ்வேறு வன்பொருளைப் பயன்படுத்துகின்றனர், ஸ்கேலபிள் ரிலேயபிள் டேட்டாகிராம் (SRD) போக்குவரத்து கொண்ட Elastic Fabric Adapter (EFA) செய்திகளை வரிசையின்றி வழங்குகிறது. 400 Gbps அலைவரிசையை அடைய EFA நான்கு 100 Gbps NICகளை (அல்லது இரண்டு 200 Gbps NICகளை) ஒருங்கிணைக்க வேண்டும்.

மென்பொருள் பெயர்வுத்திறன்: ஏற்கனவே இருக்கும் RDMA நூலகங்கள் விற்பனையாளர் பூட்டுதல்களால் பாதிக்கப்படுகின்றன. DeepEP ஆனது ConnectX இல் மட்டுமே கிடைக்கும் GPU-துவக்கப்பட்ட RDMA (IBGDA) தேவைப்படுகிறது. NVSHMEM ஆனது EFA இல் கடுமையான செயல்திறன் சிதைவைக் காட்டுகிறது. Mooncake மற்றும் NIXL போன்ற நூலகங்களில் EFA ஆதரவு இல்லை அல்லது ஆரம்ப வளர்ச்சியிலேயே உள்ளன. இதன் விளைவாக, எல்எல்எம் அனுமானத்திற்கு வழங்குநர்களுக்கு இடையேயான சாத்தியமான தீர்வு எதுவும் இல்லை.

TransferEngine இந்த தடைகளை நான்கு முக்கிய திறன்கள் மூலம் நிவர்த்தி செய்கிறது:

பொதுவான போக்குவரத்து அனுமானங்கள்: குறிப்பிட்ட NIC ஐ குறிவைப்பதை விட, அடிப்படை போக்குவரத்து நம்பகமானதாக ஆனால் வரிசைப்படுத்தப்படாததாக இருக்கும் என்று TransferEngine கருதுகிறது, அதாவது RC மற்றும் SRD போக்குவரத்துகள் இரண்டாலும் வழங்கப்படும் உத்தரவாதங்களின் குறுக்குவெட்டு.

ImmCounter ஒத்திசைவு: செய்தி வரிசைப்படுத்தலை நம்பாமல் வேலை செய்யும் நிறைவு அறிவிப்புக்கான ஒரு புதிய பிரிமிடிவ், இது வரிசைப்படுத்தப்பட்ட (RC) மற்றும் வரிசைப்படுத்தப்படாத (SRD) போக்குவரத்துகள் இரண்டிலும் ஒரே குறியீட்டை இயக்க உதவுகிறது.

பல-NIC ஆதரவு: அலைவரிசையை அதிகரிக்க இடமாற்றங்களை தானாகவே துண்டு துண்டாக மாற்றுவதன் மூலம், ஒவ்வொரு GPU க்கும் பல NICகளின் வெளிப்படையான மேலாண்மை.

குறைந்தபட்ச API மேற்பரப்பு: சிக்கலான தொடர்பு வடிவங்களை உருவாக்க போதுமான சிறிய செயல்பாடுகளின் தொகுப்பு.

TransferEngine அமைப்பு வடிவமைப்பு, இரண்டு GPU/NUMA டொமைன்களைக் கடந்து கோரிக்கை மற்றும் callback பாதைகள், CPU workers, UVM buffers, GPUs, மற்றும் NICs ஆகியவற்றைக் காட்டுகிறது.

TransferEngine ஒவ்வொரு GPU க்கும் ஒரு பணியாளர் த்ரெட்டை (worker thread) உருவாக்குகிறது. ஒவ்வொரு பணியாளரும் வன்பொருள் தளத்தைப் பொறுத்து 1 முதல் 4 RDMA NICகளை ஒருங்கிணைக்கும் DomainGroup-ஐ நிர்வகிக்கிறது (ஒற்றை ConnectX-7 ஆனது 400 Gbps-ஐ வழங்குகிறது, அதே நேரத்தில் EFA க்கு நான்கு 100 Gbps அடாப்டர்கள் அல்லது இரண்டு 200 Gbps அடாப்டர்கள் தேவைப்படுகின்றன). ஒரு DomainGroup-க்குள், ஒவ்வொரு Domain-ம் வன்பொருள்-குறிப்பிட்டது மற்றும் ஒற்றை NIC-ஐ நிர்வகிக்கிறது, கியூ ஜோடி மேலாண்மை, பணி சமர்ப்பிப்பு மற்றும் நிறைவு வாக்களிப்பு ஆகியவற்றைக் கையாளுகிறது.

ஒவ்வொரு TransferEngine நிகழ்வும் பியர் அடையாளம் மற்றும் கண்டறிதலுக்காக ஒற்றை முக்கிய முகவரியை வெளிப்படுத்துகிறது. ரிமோட் பியர்கள் நெட்வொர்க் முகவரிகளை என் கோட் செய்யும் NetAddr கட்டமைப்புகளைப் பரிமாறிக்கொள்கின்றன மற்றும் அவுட்-ஆஃப்-பேண்ட் தொடர்புக்காக சீரியலைஸ் செய்யப்படலாம். கணினியில் உள்ள அனைத்து பியர்களும் GPU க்கு ஒரே எண்ணிக்கையிலான NICகளைப் பயன்படுத்த வேண்டும். இந்த சீரான கட்டமைப்பு TransferEngine ஆனது இடமாற்றங்களை நுண்ணறிவுடன் துண்டு துண்டாக மாற்ற அனுமதிக்கிறது: பரிமாற்றத்தைத் தொடங்கும்போது, மூல மற்றும் இலக்கு இரண்டும் எந்த NICகள் உள்ளன என்பதைத் துல்லியமாக அறிந்துகொள்ளும், இதனால் அனைத்து அடாப்டர்களிலும் தானியங்கி சுமை சமநிலையை (load balancing) செயல்படுத்துகிறது.

அடிப்படை 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 பல முக்கிய கூறுகளைக் கொண்டுள்ளது:

தரவு பரிமாற்றத்திற்கு முன்பு RDMA செயல்பாடுகளுக்கு நினைவக பகுதிகள் NIC உடன் பதிவு செய்யப்பட வேண்டும். reg_mr செயல்பாடு ஒரு சுட்டி (pointer), நீளம் மற்றும் சாதனத்தை எடுத்துக்கொள்கிறது, இரண்டு கைப்பிடிகளை (handles) வழங்குகிறது:

MrHandle: இடமாற்றங்களுக்கான மூலமாகப் பயன்படுத்தப்படும் உள்ளூர் கைப்பிடி

MrDesc: பதிவுசெய்யப்பட்ட நினைவகத்தில் எழுத ரிமோட் பியர்களை இயக்க அவர்களுடன் பரிமாறிக்கொள்ளக்கூடிய சீரியலைஸ் செய்யக்கூடிய விளக்ககம்

MrDesc கட்டமைப்பில் நினைவக பகுதிக்கு ரிமோட் அணுகலை வழங்கும் ரிமோட் நெட்வொர்க் முகவரி மற்றும் ரிமோட் கீ (ஒவ்வொரு NIC க்கும் ஒன்று) பட்டியலைக் கொண்டுள்ளது. இந்த வடிவமைப்பு பல-NIC அமைப்புகளை இயற்கையாகவே கையாளுகிறது.

சிறிய செய்திகள் மற்றும் RPC-பாணி கட்டுப்பாட்டு விமான செய்திகளுக்கு, TransferEngine submit_send மற்றும் submit_recvs ஆகியவற்றை வழங்குகிறது:

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

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

மொத்த தரவு பரிமாற்றங்களுக்கு, TransferEngine ஜீரோ-காப்பி ஒருபக்க எழுதும் செயல்பாடுகளை வழங்குகிறது:

submit_single_write: மூலத்திலிருந்து இலக்குக்கு ஒரு தொடர்ச்சியான பகுதியை மாற்றுகிறது

submit_paged_writes: குறியீடுகள், ஸ்ட்ரைடுகள் மற்றும் ஆஃப்செட்களால் குறிப்பிடப்பட்ட தொடர்ச்சியற்ற பக்கங்களை மாற்றுகிறது

இரண்டு செயல்பாடுகளும் நிறைவடைந்தவுடன் பெறுநருக்கு அணுக்கமாக (atomically) வழங்கப்படும் விருப்பத்தேர்வு 32-பிட் உடனடி மதிப்பை ஏற்றுக்கொள்கின்றன.

அலைவரிசையை அதிகரிக்க எஞ்சின் தானாகவே பெரிய இடமாற்றங்களை பல NICகளில் துண்டு துண்டாக மாற்றுகிறது.

பல பியர்களை இலக்காகக் கொண்ட செயல்பாடுகளுக்கு (MoE ரூட்டிங்கில் பொதுவானது), TransferEngine உகந்ததாக்கப்பட்ட பிரிமிடிவ்களை வழங்குகிறது:

add_peer_group: விரைவான தேடலுக்காக பியர் முகவரிகளின் தொகுப்பை முன்பே பதிவு செய்கிறது

submit_scatter: குழுவில் உள்ள ஒவ்வொரு பியருக்கும் வெவ்வேறு தரவு துண்டுகளை அனுப்புகிறது

submit_barrier: அனைத்து பியர்களுக்கும் உடனடி-மட்டும் அறிவிப்பை அனுப்புகிறது (பூஜ்ஜிய-பைட் பரிமாற்றம்)

உள் தரவு கட்டமைப்புகளை தற்காலிக சேமிப்பில் (caching) சேமிப்பதன் மூலமும், RDMA பணி கோரிக்கைகளை டெம்ப்ளேட் செய்வதன் மூலமும், மீண்டும் மீண்டும் செய்யும் அமைவு ஓவர்ஹெட்டைத் தவிர்ப்பதன் மூலமும் இந்த செயல்பாடுகள் குறைந்த தாமதத்திற்காக உகந்ததாக்கப்பட்டுள்ளன.

எல்எல்எம் அமைப்புகளில் உள்ள ஒரு முக்கிய சவால், RDMA பரிமாற்றங்களை GPU முன்னேற்றத்துடன் ஒருங்கிணைப்பதாகும். மாடல் படி, GPU வெளியீட்டை உருவாக்கியவுடன் தரவு பரிமாற்றம் தொடங்க வேண்டும், ஆனால் CPU இலிருந்து GPU-ஐ வாக்களிப்பது திறமையற்றது.

TransferEngine இதை UVM வாட்சர்கள் மூலம் நிவர்த்தி செய்கிறது: ஒருங்கிணைந்த மெய்நிகர் நினைவக இடங்கள், GPU கர்னல்களால் (CUDA வரைபடங்களுக்குள்ளும் கூட) புதுப்பிக்கப்படலாம் மற்றும் GDRCopy ஐப் பயன்படுத்தி CPU ஆல் திறம்பட வாக்களிக்கப்படலாம். UVM வாட்சர் ஒதுக்கப்படும் போது, GPU மதிப்பைப் புதுப்பிக்கும் போதெல்லாம் அழைக்கப்படும் கால்பேக் பதிவு செய்யப்படுகிறது.

இது லேயர்-பை-லேயர் KvCache பரிமாற்றம் போன்ற வடிவங்களை இயக்குகிறது: ஒவ்வொரு டிரான்ஸ்பார்மர் லேயரும் முடிந்ததும், GPU வாட்சரை அதிகரிக்கிறது, அடுத்தடுத்த லேயர்கள் தொடர்ந்து கணக்கிடும்போது அந்த லேயரின் KvCache இன் RDMA பரிமாற்றத்தைத் தூண்டுகிறது.

TransferEngine துவக்கி தரப்பு (submit_write இன் அழைப்பாளர்) மற்றும் பெறுநர் தரப்பு (Write செயல்பாடுகளின் இலக்கு) இரண்டிற்கும் நிறைவு அறிவிப்பு வழிமுறைகளை வழங்குகிறது.

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

பெறுநர்-தரப்பு அறிவிப்பு: முக்கிய புதுமை ImmCounter ஆகும், இது 32-பிட் உடனடி எண்களால் குறியிடப்பட்ட கவுண்டர்களைக் கண்காணிக்கும் ஒரு கூறு ஆகும். எழுதும் செயல்பாடு உடனடி மதிப்பைச் சுமந்து செல்லும்போது, தரவு டெலிவரி ஆனதும் பெறுநரின் ImmCounter அணுக்கமாக அதிகரிக்கப்படுகிறது. குறிப்பிட்ட உடனடி மதிப்பு இலக்கு எண்ணிக்கையை எட்டும்போது செயல்படும் கால்பேக்கை பதிவு செய்ய expect_imm_count செயல்பாடு பெறுநரை அனுமதிக்கிறது. கவுண்டர்கள் GDRCopy வழியாக GPU உடன் வெளிப்படையாக ஒத்திசைக்கப்படலாம், நேரடியாக வாக்களிக்கப்படலாம் அல்லது கால்பேக்குகள் மூலம் கண்காணிக்கப்படலாம்.

இந்த பெறுநர்-தரப்பு பொறிமுறையானது செய்தி வரிசைப்படுத்தல் தேவையில்லாமல் நம்பகமான ஒத்திசைவை வழங்குகிறது. இது ConnectX NICகள் (RC போக்குவரத்து மீது வரிசைப்படி டெலிவரியை உறுதி செய்கிறது) மற்றும் EFA NICகள் (SRD போக்குவரத்து மீது வரிசையின்றி செய்திகளை வழங்கும்) இரண்டிலும் சமமாக நன்றாக வேலை செய்கிறது.

TransferEngine ரஸ்டில் (Rust) செயல்படுத்தப்பட்டுள்ளது, தாமதத்தைக் குறைக்கவும் உயர் த்ரூபுட்டை அடையவும் ஒதுக்கீடுகள், த்ரெட்டிங் மற்றும் ஒத்திசைவு ஆகியவற்றை கவனமாக உகந்ததாக்குகிறது. எஞ்சின் ஒவ்வொரு DomainGroup க்கும் ஒரு பணியாளர் த்ரெட்டை (worker thread) உருவாக்குகிறது, ஒவ்வொன்றும் சாதனங்கள் இணைக்கப்பட்டுள்ள NUMA முனையில் உள்ள CPU கோரில் பின் செய்யப்படுகிறது, இது திட்டமிடல் மற்றும் நினைவக அணுகல் தாமதம் இரண்டையும் குறைக்கிறது. நினைவகம் சரியான NUMA முனையில் ஒதுக்கப்படுவதை உறுதி செய்வதற்காக டொமைன்-குறிப்பிட்ட தரவு கட்டமைப்புகள் பின் செய்த பிறகு ஒதுக்கப்படுகின்றன. ஒரு பணியாளர் த்ரெட் 4 Domainகள் வரை கையாளுகிறது (ஒவ்வொன்றும் ஒரு NIC ஐ நிர்வகிக்கிறது), மற்றொரு அர்ப்பணிக்கப்பட்ட த்ரெட் UVM வாட்சர்களைப் புதுப்பிக்க GPU ஐ வாக்களிக்கிறது. த்ரெட்டுகளுக்கு இடையேயான தொடர்பு லாக்- இல்லாத கியூக்கள் மூலம் செய்யப்படுகிறது.

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

ஒரு DomainGroup க்குள் ஷார்டிங் நெகிழ்வானது. இடமாற்றங்கள் குறியீட்டின் மூலம் குறிப்பிட்ட NICகளை குறிவைக்கலாம். ஒற்றை Write ஐப் பிரிக்கலாம். பக்கப்படுத்தப்பட்ட இடமாற்றங்கள், ஸ்கேட்டர் மற்றும் பேரியர் செயல்பாடுகள், இவை அனைத்தும் பல Writes ஆக மொழிபெயர்க்கப்படுகின்றன, அனைத்து NICகளிலும் துண்டு துண்டாக மாறலாம்.

TransferEngine இல் உள்ள Domainகள் சிறப்பு வாய்ந்தவை மற்றும் அவற்றின் கட்டுப்பாட்டின் கீழ் உள்ள வன்பொருளுக்கு உகந்ததாக்கப்பட்டவை:

AWS EFA: EFA செயலாக்கம் libfabric ஐப் பயன்படுத்துகிறது, DomainGroupக்குள் ஒவ்வொரு NIC க்கும் ஒரு ஃபேப்ரிக் டொமைனை நிர்வகிக்கிறது. முக்கிய செயலாக்க முடிவுகள் மற்றும் உகந்ததாக்கல்கள் பின்வருவனவற்றை உள்ளடக்குகின்றன:

பூஜ்ஜிய-அளவு எழுத்துகள் (Zero-sized writes): பூஜ்ஜிய-அளவு எழுத்துகளுக்கு கூட செல்லுபடியாகும் இலக்கு விளக்ககங்கள் தேவைப்படுவதன் மூலம் EFA RDMA விவரக்குறிப்பிலிருந்து விலகுகிறது. எனவே, TransferEngine அனைத்து இடமாற்றங்களுக்கும் செல்லுபடியாகும் விளக்ககங்களை அமல்படுத்துகிறது.

பணி கோரிக்கை டெம்ப்ளேட்டிங் (Work request templating): இடுகையிடுவதற்கு முன் libfabric கட்டமைப்புகளின் பொதுவான புலங்களை முன்கூட்டியே நிரப்பி வைத்திருக்கிறது, மொத்த இடமாற்றங்கள் மற்றும் பியர் குழு செயல்பாடுகளுக்கான செயல்பாடு சார்ந்த ஓவர்ஹெட்டைக் குறைக்கிறது

NVIDIA ConnectX-7: ConnectX-7 செயலாக்கம் RC போக்குவரத்துற்றுடன் libibverbs ஐப் பயன்படுத்துகிறது. முக்கிய செயலாக்க முடிவுகள் மற்றும் உகந்ததாக்கல்கள் பின்வருவனவற்றை உள்ளடக்குகின்றன:

ஹேண்ட்ஷேக்குகளுக்கான UD கியூ ஜோடிகள்: ஒவ்வொரு Domain-ம் RC இணைப்பு ஹேண்ட்ஷேக்குகளைப் பரிமாறிக்கொள்ள அன்ரிலேயபிள் டேட்டாகிராம் (UD) கியூ ஜோதியைப் பயன்படுத்துகிறது.

தனித்தனி RC கியூ ஜோடிகள்: ஒவ்வொரு பியருக்கும் 2 RC கியூ ஜோடிகளை உருவாக்குகிறது, ஒன்று இருபக்க Send/Recv செயல்பாடுகளுக்கு மற்றொன்று ஒருபக்க Write மற்றும் WriteImm செயல்பாடுகளுக்கு. இந்தப் பிரிப்பு அவசியமானது, ஏனெனில் Recv மற்றும் WriteImm நிறைவுகள் இரண்டும் இடுகையிடும் வரிசையில் வேலை கோரிக்கைகளை நுகர்கின்றன, இது குறுக்கீடு இல்லாமல் WriteImm ஐ ஆதரிக்கும் அதே வேளையில் உயர் மட்ட Recv சொற்பொருளை அனுமதிக்கிறது.

பணி கோரிக்கை டெம்ப்ளேட்டிங்: மொத்த இடமாற்றங்கள் மற்றும் பியர் குழுக்களுக்கான பணி கோரிக்கை கட்டமைப்புகளின் பொதுவான புலங்களை முன்கூட்டியே நிரப்புகிறது.

பணி கோரிக்கை சங்கிலித் தொடர் (Work request chaining): ibv_send_wr இன் next சுட்டி மூலம் 4 வேலை கோரிக்கைகள் வரை இணைக்கிறது, NIC க்கு டோர்வெல் ரிங்குகளின் எண்ணிக்கையைக் குறைக்கிறது.

தளர்வான வரிசைப்படுத்தல் (Relaxed ordering): NIC மற்றும் GPU நினைவகத்திற்கு இடையே வரிசையின்றி PCIe பரிவர்த்தனைகளை அனுமதிக்க IBV_ACCESS_RELAXED_ORDERING ஐ இயக்குகிறது.

வெவ்வேறு RDMA போக்குவரத்துகள் முழுவதும் உத்தரவாதங்களின் குறுக்குவெட்டை குறிவைப்பதன் மூலமும், ImmCounter வழியாக வரிசை-சுயாதீன ஒத்திசைவை அறிமுகப்படுத்துவதன் மூலமும், எல்எல்எம் அமைப்புகளில் பாயிண்ட்-டூ-பாயிண்ட் தொடர்புக்கான போர்ட்டபிள் அடிப்படையை 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

ஒருபக்க எழுதுதல் (One-Sided Write)

பியர் குழுக்கள் மற்றும் மொத்த செயல்பாடுகள்

UVM வாட்சர்: GPU-முதல்-CPU சமிக்ஞை அனுப்புதல்

நிறைவு அறிவிப்பு

செயலாக்கம் (Implementation)

வன்பொருள்-குறிப்பிட்ட உகந்ததாக்கல்கள்

முடிவுரை

மேற்கோள்