LLM प्रणालींसाठी RDMA पॉइंट-टू-पॉइंट कम्युनिकेशन

पारंपारिकपणे एलएलएम (LLM) प्रणाली प्रशिक्षणातील आणि अनुमानातील (inference) संरचित समांतर नमुन्यांसाठी सामूहिक संवादांवर अवलंबून असतात. तथापि, उद्भवणारे वर्कलोड्स, जसे की विघटित अनुमान (disaggregated inference), मिक्सचर-ऑफ-एक्सपर्ट्स (MoE) रुटिंग, आणि असिंक्रोनस रिइंफोर्समेंट लर्निंग फाईन-ट्यूनिंग, यांना पॉइंट-टू-पॉइंट संवादाच्या लवचिकतेची आवश्यकता असते.

आमचा नवीन संशोधन पेपर TransferEngine सादर करतो, जे विविध नेटवर्क इंटरफेस कंट्रोलर (NICs) वर काम करणारे एक पोर्टेबल RDMA-आधारित कम्युनिकेशन लायब्ररी आहे, ज्यामध्ये NVIDIA ConnectX-7 आणि AWS Elastic Fabric Adapter (EFA) यांचा समावेश आहे. Perplexity मधील तीन उत्पादन प्रणालींमध्ये आम्ही याची प्रभावीता दाखवून देतो:

विघटित प्रिफिल आणि डिकोड: पेज केलेले राईट्स (paged writes) आणि UVM वॉचर्स वापरून लेयर-बाय-लेयर KvCache ट्रान्सफर, ज्यामुळे प्रिफिल आणि डिकोड इन्स्टन्सेसना स्वतंत्रपणे स्केल करण्याची परवानगी मिळते.

२ सेकंदांपेक्षा कमी वेळेत आरएल (RL) पोस्ट-ट्रेनिंगसाठी वेट ट्रान्सफर: ट्रेनिंग आणि इन्फरन्स नोड्स दरम्यान अत्यंत जलद वेट सिंक्रोनायझेशन.

AWS EFA वर ट्रिलियन-पॅरामिटर मॉडेल्स सक्षम करणे: स्कॅटर आणि बॅरियर प्रिमिटिव्ह वापरून कमी लेटन्सीचे MoE डिस्पॅच आणि कम्बाइन ऑपरेशन्स, ConnectX-7 वर अत्याधुनिक लेटन्सी साध्य करणे आणि AWS EFA शी सुसंगत पहिली व्यवहार्य अंमलबजावणी.

हा लेख TransferEngine वर लक्ष केंद्रित करतो, जो या प्रणालींना चालना देणारी कम्युनिकेशन लायब्ररी आहे. arXiv वर संपूर्ण संशोधन पेपर वाचा आणि GitHub वर कोड एक्सप्लोर करा.

सामूहिक संवाद हे टेन्सर पॅरालिझम आणि डेटा पॅरालिझम सारख्या संरचित समांतर नमुन्यांमध्ये उत्कृष्ट असतात, परंतु ते असे निर्बंध लादतात जे उद्भवणाऱ्या वर्कलोड्ससाठी त्यांची उपयुक्तता मर्यदित करतात:

निश्चित सदस्यत्व: कलेक्टिव्ह्सना आरंभीकरण (initialization) वेळी ग्लोबल कम्युनिकेशन वर्ल्ड स्थापित करणे आवश्यक असते, ज्यामध्ये सर्व सहभागींमध्ये समक्रमित (synchronized) सेटअप असतो. विघटित अनुमानासाठी, हे समस्येचे ठरू शकते कारण ट्रॅफिक नमुन्यांच्या प्रतिसादात प्रिफिल आणि डिकोड इन्स्टन्सेसची संख्या गतिशीलपणे स्केल करणे आवश्यक असते.

एकसारखे टेन्सर आकार: कलेक्टिव्ह्स असे गृहीत धरतात की सर्व सहभागी समान आकार आणि डेटा प्रकारांसह टेन्सरची देवाणघेवाण करतात. MoE रुटिंगमध्ये, प्रत्येक तज्ज्ञाला पाठवलेल्या टोकन्सची संख्या डेटा-अवलंबून असते आणि रनटाइमवर शोधली जाते, ज्यामुळे घट्ट ऑल-टू-ऑल कलेक्टिव्ह्सना सर्वात वाईट-केस बफर आकारांपर्यंत पॅड करण्यास भाग पाडले जाते.

ऑपरेशन क्रमवारी: कलेक्टिव्ह API समक्रमित सिमेंटिक्स लागू करतात, जरी अनुप्रयोगांना केवळ हे माहित असणे आवश्यक असते की ऑपरेशन्सचा संच पूर्ण झाला आहे. उदाहरणार्थ, KvCache ट्रान्सफरमध्ये, प्रिफिल इन्स्टन्सवरून डिकोड इन्स्टन्सपर्यंतची सर्व पृष्ठे (pages) कोणत्याही क्रमाने येऊ शकतात. त्याचप्रमाणे, RL वेट अपडेट्समध्ये, क्रमवारीच्या निर्बंधांशिवाय सर्व वेट टेन्सर स्वतंत्रपणे ट्रान्सफर केले जाऊ शकतात.

RDMA-आधारित पॉइंट-टू-पॉइंट कम्युनिकेशन नैसर्गिकरित्या या मर्यादांचे निराकरण करते, परंतु तीन अडथळ्यांनी त्याचा अवलंब रोखला आहे:

लायब्ररी मर्यादा: torch.distributed आणि NCCL Send/Recv सारख्या पॉइंट-टू-पॉइंट API प्रदान करत असले, तरी ही ऑपरेशन्स अजूनही सामूहिक सिमेंटिक्स आणि मर्यादा वारशाने प्राप्त करतात.

हार्डवेअर विविधता: रिलायबल कनेक्शन (RC) ट्रान्सपोर्टसह NVIDIA ConnectX NICs हे सर्वात सामान्य RDMA सेटअप आहेत, जे इन-ऑर्डर डिलिव्हरीची हमी देतात. AWS सारखे क्लाउड प्रदाते वेगवेगळ्या हार्डवेअरचा वापर करतात, स्केलेबल रिलायबल डेटाग्राम (SRD) ट्रान्सपोर्टसह Elastic Fabric Adapter (EFA) मेसेज आऊट-ऑफ-ऑर्डर डिलीवर करते. 400 Gbps बँडविड्स साध्य करण्यासाठी EFA ला चार 100 Gbps NICs (किंवा दोन 200 Gbps NICs) एकत्र करण्याची देखील आवश्यकता असते.

सॉफ्टवेअर पोर्टेबिलिटी: विद्यमान RDMA लायब्ररींना व्हेंडर लॉक-इनचा त्रास होतो. DeepEP ला केवळ ConnectX वर उपलब्ध असलेल्या GPU-initiated RDMA (IBGDA) ची आवश्यकता असते. NVSHMEM मध्ये EFA वर गंभीर कार्यप्रदर्शन घट होते. Mooncake आणि NIXL सारख्या लायब्ररीमध्ये EFA समर्थन नाही किंवा त्या अजून सुरुवातीच्या विकासात आहेत. परिणामी, LLM अनुमानासाठी कोणतेही व्यवहार्य क्रॉस-प्रदाता समाधान अस्तित्वात नाही.

TransferEngine चार मुख्य क्षमतांद्वारे या अडथळ्यांना दूर करते:

सामान्य वाहतूक गृहीतके: विशिष्ट NIC ला लक्ष्य करण्याऐवजी, TransferEngine असे गृहीत धरतो की केवळ अंतर्गत वाहतूक विश्वासार्ह पण अव्यवस्थित नाही, म्हणजेच RC आणि SRD या दोन्ही वाहतुकांनी दिलेल्या हमींचा छेद.

ImmCounter सिंक्रोनायझेशन: पूर्ण झाल्याची सूचना देण्यासाठी (completion notification) एक नवीन प्रिमिटिव्ह जे मेसेज क्रमवारीवर अवलंबून न राहता काम करते, ज्यामुळे ऑर्डर केलेल्या (RC) आणि अनऑर्डर केलेल्या (SRD) दोन्ही ट्रान्सपोर्ट्सवर समान कोड चालवणे शक्य होते.

मल्टी-एनआयसी (Multi-NIC) समर्थन: बँडविड्थ जास्तीत जास्त करण्यासाठी ट्रान्सफर स्वयंचलितपणे शार्ड करून, प्रति GPU एकाधिक NICs चे पारदर्शक व्यवस्थापन.

किमान API पृष्ठभाग: जटिल कम्युनिकेशन नमुने तयार करण्यासाठी पुरेसा ऑपरेशन्सचा एक छोटा संच.

ट्रान्सफरइंजन सिस्टम डिझाइन, ज्यामध्ये दोन GPU/NUMA डोमेनमध्ये विनंती आणि कॉलबॅक मार्ग, CPU वर्कर्स, UVM बफर्स, GPU आणि NICs दाखवले आहेत.

TransferEngine प्रत्येक GPU साठी एक थ्रेड तयार करते. हार्डवेअर प्लॅटफॉर्मनुसार (एक सिंगल ConnectX-7 400 Gbps प्रदान करते, तर EFA ला चार 100 Gbps अडॅप्टर किंवा दोन 200 Gbps अडॅप्टर लागतात) प्रत्येक वर्कर 1 ते 4 RDMA NICs चे समन्वय साधणाऱ्या DomainGroup चे व्यवस्थापन करतो. DomainGroup च्या मधील, प्रत्येक Domain हे हार्डवेअर-विशिष्ट असते आणि एकाच NIC चे व्यवस्थापन करते, क्यु पेअर व्यवस्थापन, कार्य सबमिशन आणि पूर्ण झाल्याची पोलिंग हाताळते.

प्रत्येक TransferEngine इन्स्टन्स पीअर ओळख आणि शोधासाठी एक सिंगल मुख्य पत्ता उघड करतो. रिमोट पीअर्स NetAddr स्ट्रक्सची देवाणघेवाण करतात जे नेटवर्क पत्ते एन्कोड करतात आणि आऊट-ऑफ-बँड कम्युनिकेशनसाठी सिरिअलाइझ केले जाऊ शकतात. प्रणालीतील सर्व पीअर्सनी प्रति GPU समान संख्या असलेल्या NICs वापरणे आवश्यक आहे. हे एकसारखे कॉन्फिगरेशन TransferEngine ला बुद्धिमत्तेने ट्रान्सफर शार्ड करण्याची अनुमती देते: ट्रान्सफर सुरू करताना, स्त्रोत आणि गंतव्यस्थान दोन्हीना नेमके कोणते NIC उपलब्ध आहेत हे माहीत असते, ज्यामुळे सर्व अडॅप्टरवर स्वयंचलित लोड बॅलन्सिंग शक्य होते.

TransferEngine एक किमान API उघड करतो जो अंतर्निहित RDMA इंटरफेसची जटिलता दूर करतो.

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 फंक्शन एक पॉइंटर, लांबी आणि डिव्हाइस घेते, आणि दोन हँडल परत करते:

MrHandle: ट्रान्सफरसाठी स्त्रोत म्हणून वापरले जाणारे स्थानिक हँडल

MrDesc: एक सिरिअलाइझ करण्यायोग्य डिस्प्रिप्टर जो नोंदणीकृत मेमरीमध्ये लिहू शकण्यासाठी रिमोट पीअर्ससह एक्सचेंज केला जाऊ शकतो

MrDesc संरचनेत रिमोट नेटवर्क पत्त्यांची सूची आणि रिमोट की (प्रत्येक NIC साठी एक) समाविष्ट असते जी मेमरी क्षेत्रावर रिमोट प्रवेश प्रदान करते. हे डिझाइन नैसर्गिकरित्या मल्टी-NIC सेटअप हाताळते.

लहान मेसेज आणि RPC-शैलीतील नियंत्रण विमान संदेशांसाठी, TransferEngine submit_send आणि submit_recvs प्रदान करते:

submit_send: NetAddr द्वारे ओळखल्या गेलेल्या रिमोट पीअरला मेसेज पाठवतो. मेसेज अंतर्गत कॉपी केला जातो, त्यामुळे कॉलर त्वरित बफर पुन्हा वापरू शकतो किंवा रिलीज करू शकतो.

submit_recvs: प्राप्त बफर्सचा पूल पोस्ट करतो. जेव्हा एखादा संदेश येतो, तेव्हा प्राप्त झालेल्या डेटासह कॉलबॅक कॉल केला जातो. कॉलबॅक पूर्ण झाल्यानंतर बफर आपोआप पुलावर परत केला जातो.

मोठ्या डेटा ट्रान्सफरसाठी, TransferEngine झिरो-कॉपी वन-साइड राईट ऑपरेशन्स प्रदान करते:

submit_single_write: स्त्रोतापासून गंतव्यस्थानापर्यंत एक सलग प्रदेश ट्रान्सफर करतो

submit_paged_writes: इंडेक्स, स्ट्राइड्स आणि ऑफसेट्सद्वारे निर्दिष्ट केलेली नसलग पृष्ठे ट्रान्सफर करतो

दोन्ही ऑपरेशन्स एक पर्यायी ३२-बिट तात्काळ मूल्य स्वीकारतात जे पूर्ण झाल्यावर रिसीव्हरला ॲटॉमिकली वितरित केले जाते.

बॅण्डविथ जास्तीत जास्त करण्यासाठी इंजिन आपोआप मोठ्या ट्रान्सफर अनेक NICs मध्ये शार्ड करते.

अनेक पीअर्सना लक्ष्य करणाऱ्या ऑपरेशन्ससाठी (MoE रुटिंगमध्ये सामान्य), TransferEngine अनुकूलित प्रिमिटिव्ह प्रदान करते:

add_peer_group: जलद शोध घेण्यासाठी पीअर पत्त्यांचा संच प्री-रजिस्टर करतो

submit_scatter: समूहातील प्रत्येक पीअरला वेगवेगळ्या डेटा स्लाईसेस पाठवतो

submit_barrier: सर्व पीअर्सना तात्काळ-केवळ सूचना पाठवतो (झिरो-बाइट ट्रान्सफर)

अंतर्गत डेटा संरचना कॅश करून आणि RDMA कार्य विनंत्या टेम्पलेट करून कमी लेटन्सीसाठी या ऑपरेशन्स अनुकूलित केल्या जातात, ज्यामुळे पुनरावृत्ती सेटअप ओव्हरहेड टाळता येतो.

LLM प्रणालींमधील एक मुख्य आव्हान म्हणजे GPU प्रगतीसह RDMA ट्रान्सफरचे समन्वय साधणे. आदर्शपणे, GPU आउटपुट तयार करताच डेटा ट्रान्सफर सुरू झाला पाहिजे, परंतु CPU मधून GPU पोल करणे अकार्यक्षम असते.

TransferEngine UVM वॉचर्स सह याचे निराकरण करतो: युनिफाइड व्हर्च्युअल मेमरी स्थाने जी GPU कर्नलद्वारे (कडा आकृत्यांमध्ये देखील) अपडेट केली जाऊ शकतात आणि GDRCopy वापरून CPU द्वारे कार्यक्षमतेने पोल केली जाऊ शकतात. जेव्हा UVM वॉचर वाटप केले जाते, तेव्हा एक कॉलबॅक नोंदणीकृत केला जातो जो GPU मूल्य अपडेट करतो तेव्हा प्रत्येक वेळी कॉल केला जातो.

हे लेयर-बाय-लेयर KvCache ट्रान्सफर सारखे नमुने सक्षम करते: प्रत्येक ट्रान्सफॉर्मर लेयर पूर्ण झाल्यानंतर, GPU वॉचर वाढवतो, त्यानंतरचे लेयर्स गणना करणे सुरू ठेवत असताना त्या लेयरच्या KvCache चे RDMA ट्रान्सफर ट्रिगर करतो.

TransferEngine इनिशिएटर बाजूसाठी (submit_write चा कॉलर) आणि रिसीव्हर बाजूसाठी (राईट ऑपरेशन्सचे लक्ष्य) दोन्हीसाठी पूर्ती सूचना यंत्रणा प्रदान करते.

इनिशिएटर-बाजूची सूचना: जेव्हा एखादे राईट ऑपरेशन सबमिट केले जाते, तेव्हा कॉलर कॉलबॅक फंक्शन किंवा ॲटॉमिक फ्लॅगद्वारे पूर्ण झाल्यावर सूचित करणे निवडू शकतो. ही सूचना पुष्टी करते की डेटा स्त्रोत बफरवरून यशस्वीरित्या ट्रान्सफर केला गेला आहे.

रिसीव्हर-बाजूची सूचना: मुख्य नवोपक्रम म्हणजे ImmCounter, हा एक घटक आहे जो ३२-बिट तात्काळ अंकांनी अनुक्रमित केलेल्या काऊंटर्सचा मागोवा घेतो. जेव्हा राईट ऑपरेशन तात्काळ मूल्य वाहून नेते, तेव्हा डेटा वितरणावर रिसीव्हरचा ImmCounter ॲटॉमिकली वाढवला जातो. expect_imm_count फंक्शन रिसीव्हरला एक कॉलबॅक नोंदणी करण्याची परवानगी देते जो विशिष्ट तात्काळ मूल्य लक्ष्यापर्यंत पोहोचल्यावर फायर होतो. काऊंटर्स GDRCopy द्वारे GPU सह पारदर्शकपणे सिंक्रोनाइझ केले जाऊ शकतात, थेट पोल केले जाऊ शकतात किंवा कॉलबॅकद्वारे मॉनिटर केले जाऊ शकतात.

ही रिसीव्हर-साइड यंत्रणा संदेश क्रमवारीची आवश्यकता न घेता विश्वासार्ह सिंक्रोनायझेशन प्रदान करते. हे ConnectX NICs (जे RC ट्रान्सपोर्टवर इन-ऑर्डर डिलिव्हरीची हमी देतात) आणि EFA NICs (जे SRD ट्रान्सपोर्टवर संदेश आऊट-ऑफ-ऑर्डर डिलीवर करतात) वर समान प्रमाणात कार्य करते.

TransferEngine रस्ट (Rust) मध्ये लागू केले गेले आहे, लेटन्सी कमी करण्यासाठी आणि उच्च थ्रुपुट साध्य करण्यासाठी वाटप (allocations), थ्रेडींग आणि सिंक्रोनायझेशन काळजीपूर्वक अनुकूलित करते. इंजिन प्रत्येक DomainGroup साठी एक वर्कर थ्रेड तयार करते, प्रत्येक डिव्हाइस जोडलेल्या NUMA नोडवरील CPU कोरशी पिन केलेले असते, ज्यामुळे शेड्युलिंग आणि मेमरी ऍक्सेस लेटन्सी दोन्ही कमी होतात. डोमेनसाठी विशिष्ट डेटा संरचना मेमरी योग्य NUMA नोडमध्ये आरक्षित असल्याची खात्री करण्यासाठी पिन केल्यानंतर वाटप केल्या जातात. एक वर्कर थ्रेड ४ Domain पर्यंत हाताळतो (प्रत्येक एक सिंगल NIC व्यवस्थापित करतो), तर दुसरा समर्पित थ्रेड UVM वॉचर्स अपडेट करण्यासाठी GPU पोल करतो. थ्रेड-पार कम्युनिकेशन लॉक-फ्री रांग (queues) द्वारे केले जाते.

API योग्य डिव्हाइसची सेवा देणाऱ्या DomainGroup वर विनंत्या फॉरवर्ड करते, पहिल्या एकासह होस्टची सेवा देखील देते. घट्ट लूपमध्ये, डोमेन वर्कर नवीन कामासाठी पोल करतो, नवीन विनंत्या सबमिट करण्याला प्राधान्य देतो. हार्डवेअर आणि कॉन्फिगरेशनवर अवलंबून, विनंत्या उपलब्ध Domain मध्ये शार्ड आणि लोड-बैलन्स केल्या जातात. संयुक्त विनंतीचा पहिला राईट तात्काळ NIC च्या सेंड रांगेत पोस्ट केला जातो. एकदा नवीन विनंत्या संपल्या की, वर्कर प्रलंबित ऑपरेशन्सच्या प्रगतीसाठी पुढे सरकतो, हार्डवेअर पाइपलाइन भरण्यासाठी राईट्स पोस्ट करतो. त्यानंतर, पूर्ण झालेले ट्रान्सफर आणि तात्काळ काऊंटर्स वाढवण्यासाठी पूर्ती रांगा (completion queues) पोल केल्या जातात. ट्रान्सफर-प्रति सूचना वितरीत करण्यासाठी इव्हेंट्स एकत्र केले जातात, सर्व समूहांद्वारे सामायिक केलेल्या समर्पित कॉलबॅक थ्रेडकडे ट्रान्सफर सुपूर्द केला जातो.

DomainGroup मधील शार्डिंग लवचिक आहे. ट्रान्सफर इंडेक्सद्वारे विशिष्ट NICs ला लक्ष्य करू शकतात. एक सिंगल राईट विभाजित केला जाऊ शकतो. पेज केलेले ट्रान्सफर, स्कॅटर आणि बॅरियर ऑपरेशन्स, जे सर्व अनेक राईट्समध्ये अनुवादित होतात, सर्व NICs मध्ये शार्ड करू शकतात.

TransferEngine मधील Domain हे त्यांच्या नियंत्रणाखालील हार्डवेअरसाठी विशेष आणि अनुकूलित आहेत:

AWS EFA: EFA अंमलबजावणी libfabric वापरते, DomainGroup मधील प्रत्येक NIC साठी एक फॅब्रिक डोमेन व्यवस्थापित करते. मुख्य अंमलबजावणी निर्णय आणि ऑप्टिमायझेशनमध्ये हे समाविष्ट आहे:

झिरो-आकार राईट्स: 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 वर डोरबेल वाजत असलेल्यांची संख्या कमी करते.

रिलॅक्स्ड ऑर्डरिंग: NIC आणि GPU मेमरी दरम्यान आऊट-ऑफ-ऑर्डर PCIe ट्रॅन्झाक्शन्सना अनुमती देण्यासाठी IBV_ACCESS_RELAXED_ORDERING सक्षम करते.

विविध RDMA ट्रान्सपोर्ट्समधील हमींच्या छेदनबिंदूला लक्ष्य करून आणि ImmCounter द्वारे ऑर्डर-स्वतंत्र सिंक्रोनायझेशन सादर करून, TransferEngine LLM प्रणालींमध्ये पॉइंट-टू-पॉइंट संवादासाठी एक पोर्टेबल पाया प्रदान करते. लायब्ररी ओपन सोर्स आहे आणि 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 डिझाइन

मेमरी नोंदणी (Memory Registration)

दुहेरी-बाजूची पाठवा/स्वीकारा

वन-साइड राईट (One-Sided Write)

पीअर ग्रुप्स आणि बल्क ऑपरेशन्स

UVM वॉचर: GPU-ते-CPU सिग्नलिंग

पूर्ती सूचना (Completion Notification)

अंमलबजावणी

हार्डवेअर-विशिष्ट ऑप्टिमायझेशन

निष्कर्ष

उद्धरण