LLM प्रणालियों के लिए RDMA पॉइंट-टू-पॉइंट संचार

LLM प्रणालियाँ पारंपरिक रूप से प्रशिक्षण और अनुमान में संरचित समानांतर पैटर्न के लिए सामूहिक संचार पर निर्भर रही हैं। हालाँकि, उभरते वर्कलोड, जैसे कि पृथक अनुमान (disaggregated inference), मिक्सचर-ऑफ़-एक्सपर्ट्स (MoE) राउटिंग, और एसिंक्रोनस सुदृढीकरण शिक्षण फाइन-ट्यूनिंग, पॉइंट-टू-पॉइंट संचार के लचीलेपन की मांग करते हैं।

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

डिसेग्रेगेटेड प्रीफिल और डिकोड: पेजेड राइट्स और UVM वॉचर्स का उपयोग करके लेयर-दर-लेयर KvCache ट्रांसफर, जो प्रीफिल और डिकोड इंस्टेंस को स्वतंत्र रूप से स्केल करने की अनुमति देता है।

2 सेकंड से कम समय में RL पोस्ट-ट्रेनिंग के लिए वेट ट्रांसफर: प्रशिक्षण और अनुमान नोड्स के बीच अत्यंत तेज़ वेट सिंक्रोनाइज़ेशन।

AWS EFA पर ट्रिलियन-पैरामीटर मॉडल को सक्षम करना: स्कैटर और बैरियर प्रिमिटिव्स का उपयोग करके लो-लेटेंसी MoE डिस्पैच और कंबाइन ऑपरेशन्स, जो ConnectX-7 पर अत्याधुनिक लेटेंसी और AWS EFA के साथ संगत पहला व्यवहार्य कार्यान्वयन प्राप्त करता है।

यह लेख TransferEngine पर केंद्रित है, जो इन प्रणालियों को संचालित करने वाली संचार लाइब्रेरी है। arXiv पर पूर्ण शोध पत्र पढ़ें और GitHub पर कोड देखें।

सामूहिक संचार संरचित समानांतर पैटर्न जैसे कि टेंसर पैरलेलिज़्म और डेटा पैरलेलिज़्म में उत्कृष्ट है, लेकिन वे ऐसी बाधाएँ लागू करते हैं जो उभरते वर्कलोड के लिए उनकी प्रयोज्यता को सीमित करती हैं:

निश्चित सदस्यता: कलेक्टिव्स को आरंभीकरण के समय एक वैश्विक संचार विश्व स्थापित करने की आवश्यकता होती है, जिसमें सभी प्रतिभागियों के बीच सिंक्रनाइज़्ड सेटअप होता है। डिसेग्रेगेटेड अनुमान के लिए, यह समस्याग्रस्त है क्योंकि प्रीफिल और डिकोड इंस्टेंस की संख्या को ट्रैफ़िक पैटर्न के जवाब में गतिशील रूप से स्केल किया जाना चाहिए।

समान टेंसर आकार: कलेक्टिव्स यह मानते हैं कि सभी प्रतिभागी समान आकार और डेटा प्रकार के टेंसर का आदान-प्रदान करते हैं। MoE राउटिंग में, प्रत्येक विशेषज्ञ को भेजे गए टोकन की संख्या डेटा पर निर्भर करती है और रनटाइम पर खोजी जाती है, जिससे सघन ऑल-टू-ऑल कलेक्टिव्स को खराब से खराब बफ़र आकार में पैड करने के लिए मजबूर होना पड़ता है।

ऑपरेशन ऑर्डरिंग: कलेक्टिव एपीआई सिंक्रनाइज़्ड सिमेंटिक्स को लागू करते हैं, तब भी जब एप्लिकेशन को केवल यह जानने की आवश्यकता होती है कि ऑपरेशन्स का एक सेट पूरा हो गया है। उदाहरण के लिए, KvCache ट्रांसफर में, प्रीफिल इंस्टेंस से डिकोड इंस्टेंस तक सभी पेज किसी भी क्रम में आ सकते हैं। इसी तरह, RL वेट अपडेट में, सभी वेट टेंसर को ऑर्डरिंग बाधाओं के बिना स्वतंत्र रूप से स्थानांतरित किया जा सकता है।

RDMA-आधारित पॉइंट-टू-पॉइंट संचार स्वाभाविक रूप से इन सीमाओं को संबोधित करता है, लेकिन तीन बाधाओं ने इसे अपनाने से रोका है:

लाइब्रेरी सीमाएँ: हालाँकि torch.distributed और NCCL सेंड/रिसीव जैसे पॉइंट-टू-पॉइंट एपीआई प्रदान करते हैं, लेकिन ये ऑपरेशन्स अभी भी सामूहिक सिमेंटिक्स और सीमाओं को विरासत में लेते हैं।

हार्डवेयर विविधता: रिलायबल कनेक्शन (RC) ट्रांसपोर्ट वाले NVIDIA ConnectX NICs सबसे सामान्य RDMA सेटअप हैं, जो इन-ऑर्डर डिलीवरी की गारंटी देते हैं। AWS जैसे क्लाउड प्रदाता अलग-अलग हार्डवेयर का उपयोग करते हैं, स्केलेबल रिलायबल डेटाग्राम (SRD) ट्रांसपोर्ट के साथ इलास्टिक फैब्रिक एडाप्टर (EFA) संदेशों को आउट-ऑफ-ऑर्डर डिलीवर करता है। EFA को 400 Gbps बैंडविड्थ प्राप्त करने के लिए चार 100 Gbps NICs (या दो 200 Gbps NICs) को एग्रीगेट करने की भी आवश्यकता होती है।

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

TransferEngine चार मुख्य क्षमताओं के माध्यम से इन बाधाओं को संबोधित करता है:

सामान्य ट्रांसपोर्ट धारणाएँ: एक विशिष्ट NIC को लक्षित करने के बजाय, TransferEngine केवल यह मानता है कि अंतर्निहित ट्रांसपोर्ट विश्वसनीय है लेकिन क्रमबद्ध नहीं है, यानी RC और SRD ट्रांसपोर्ट दोनों द्वारा प्रदान की गई गारंटी का प्रतिच्छेदन।

ImmCounter सिंक्रोनाइज़ेशन: पूर्णता अधिसूचना के लिए एक नया प्रिमिटिव जो संदेश ऑर्डरिंग पर निर्भर किए बिना काम करता है, जो एक ही कोड को ऑर्डर किए गए (RC) और अनऑर्डर (SRD) ट्रांसपोर्ट दोनों पर चलने में सक्षम बनाता है।

मल्टी-NIC समर्थन: प्रति GPU कई NICs का पारदर्शी प्रबंधन, बैंडविड्थ को अधिकतम करने के लिए स्वचालित रूप से ट्रांसफर को शार्ड करना।

न्यूनतम एपीआई सतह: जटिल संचार पैटर्न बनाने के लिए पर्याप्त ऑपरेशन्स का एक छोटा सेट।

TransferEngine सिस्टम डिज़ाइन, जिसमें अनुरोध और कॉलबैक पथ, CPU वर्कर्स, UVM बफ़र्स, GPUs, और NICs दो GPU/NUMA डोमेन के बीच दिखाए गए हैं.

TransferEngine प्रति GPU एक वर्कर थ्रेड उत्पन्न करता है। प्रत्येक वर्कर एक DomainGroup का प्रबंधन करता है जो हार्डवेयर प्लेटफॉर्म के आधार पर 1 से 4 RDMA NICs का समन्वय करता है (एक सिंगल ConnectX-7 400 Gbps प्रदान करता है, जबकि EFA को चार 100 Gbps एडाप्टर या दो 200 Gbps एडाप्टर की आवश्यकता होती है)। एक DomainGroup के भीतर, प्रत्येक Domain हार्डवेयर-विशिष्ट होता है और एक सिंगल NIC का प्रबंधन करता है, जो क्यू पेयर प्रबंधन, कार्य सबमिशन और कंप्लीशन पोलिंग को संभालता है।

प्रत्येक TransferEngine इंस्टेंस पीयर पहचान और खोज के लिए एक सिंगल मुख्य पता (main address) उजागर करता है। रिमोट पीयर्स NetAddr स्ट्रक्ट्स का आदान-प्रदान करते हैं जो नेटवर्क पतों को एनकोड करते हैं और आउट-ऑफ़-बैंड संचार के लिए सीरियलाइज़ किए जा सकते हैं। सिस्टम में सभी पीयर्स को प्रति GPU NICs की समान संख्या का उपयोग करना चाहिए। यह समान कॉन्फ़िगरेशन TransferEngine को बुद्धिमानी से ट्रांसफर शार्ड करने की अनुमति देता है: ट्रांसफर शुरू करते समय, स्रोत और गंतव्य दोनों जानते हैं कि कौन से NICs उपलब्ध हैं, जिससे सभी एडाप्टरों पर स्वचालित लोड बैलेंसिंग सक्षम होती है।

TransferEngine एक न्यूनतम एपीआई उजागर करता है जो अंतर्निहित 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>;
}

एपीआई में कई प्रमुख घटक शामिल हैं:

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: इंडेक्स, स्ट्राइड्स और ऑफसेट द्वारा निर्दिष्ट गैर-सन्निहित पेजों को स्थानांतरित करता है

दोनों ऑपरेशन्स एक वैकल्पिक 32-बिट तत्काल मूल्य स्वीकार करते हैं जो पूरा होने पर रिसीवर को परमाणु रूप से दिया जाता है।

इंजन बैंडविड्थ को अधिकतम करने के लिए स्वचालित रूप से कई NICs पर बड़े ट्रांसफर को शार्ड करता है।

कई पीयर्स को लक्षित करने वाले ऑपरेशन्स के लिए (MoE राउटिंग में सामान्य), TransferEngine अनुकूलित प्रिमिटिव्स प्रदान करता है:

add_peer_group: तेज़ लुकअप के लिए पीयर पतों के एक सेट को पूर्व-पंजीकृत करता है

submit_scatter: समूह में प्रत्येक पीयर को अलग-अलग डेटा स्लाइस भेजता है

submit_barrier: सभी पीयर्स को केवल-तत्काल अधिसूचना भेजता है (ज़ीरो-बाइट ट्रांसफर)

ये ऑपरेशन्स आंतरिक डेटा संरचनाओं को कैश करके और RDMA कार्य अनुरोधों को टेम्प्लेट करके कम लेटेंसी के लिए अनुकूलित हैं, जो दोहराव वाले सेटअप ओवरहेड से बचते हैं।

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

TransferEngine इसे UVM वॉचर्स के साथ संबोधित करता है: एकीकृत वर्चुअल मेमोरी स्थान जिन्हें GPU कर्नलों द्वारा (CUDA ग्राफ के भीतर भी) अपडेट किया जा सकता है और GDRCopy का उपयोग करके CPU द्वारा कुशलतापूर्वक पोल किया जा सकता है। जब एक UVM वॉचर आवंटित किया जाता है, तो एक कॉलबैक पंजीकृत किया जाता है जो GPU द्वारा मान अपडेट करने पर लागू होता है।

यह लेयर-दर-लेयर KvCache ट्रांसफर जैसे पैटर्न को सक्षम बनाता है: प्रत्येक ट्रांसफार्मर लेयर पूरी होने के बाद, GPU वॉचर को बढ़ाता है, जिससे उस लेयर की KvCache का RDMA ट्रांसफर शुरू होता है जबकि बाद की लेयर गणना करना जारी रखती हैं।

TransferEngine इनिशिएटर साइड ( submit_write के कॉलर) और रिसीवर साइड (राइट ऑपरेशन्स का लक्ष्य) दोनों के लिए पूर्णता अधिसूचना तंत्र प्रदान करता है।

इनिशिएटर-साइड अधिसूचना: जब एक राइट ऑपरेशन सबमिट किया जाता है, तो कॉलर कॉलबैक फ़ंक्शन या परमाणु ध्वज के माध्यम से पूरा होने पर अधिसूचित होने का विकल्प चुन सकता है। यह अधिसूचना पुष्टि करती है कि डेटा सफलतापूर्वक स्रोत बफ़र से स्थानांतरित कर दिया गया है।

रिसीवर-साइड अधिसूचना: मुख्य नवाचार ImmCounter है, एक घटक जो 32-बिट तत्काल संख्याओं द्वारा अनुक्रमित काउंटरों को ट्रैक करता है। जब एक राइट ऑपरेशन में एक तत्काल मूल्य होता है, तो रिसीवर का ImmCounter डेटा डिलीवरी पर परमाणु रूप से बढ़ जाता है। expect_imm_count फ़ंक्शन रिसीवर को एक कॉलबैक पंजीकृत करने की अनुमति देता है जो तब फायर होता है जब एक विशिष्ट तत्काल मूल्य लक्ष्य गणना तक पहुंच जाता है। काउंटरों को GDRCopy के माध्यम से GPU के साथ पारदर्शी रूप से सिंक्रनाइज़ किया जा सकता है, सीधे पोल किया जा सकता है, या कॉलबैक के माध्यम से मॉनिटर किया जा सकता है।

यह रिसीवर-साइड तंत्र संदेश ऑर्डरिंग की आवश्यकता के बिना विश्वसनीय सिंक्रनाइज़ेशन प्रदान करता है। यह ConnectX NICs (जो RC ट्रांसपोर्ट पर इन-ऑर्डर डिलीवरी की गारंटी देते हैं) और EFA NICs (जो SRD ट्रांसपोर्ट पर संदेशों को आउट-ऑफ-ऑर्डर डिलीवर करते हैं) दोनों पर समान रूप से अच्छी तरह से काम करता है।

TransferEngine को Rust में कार्यान्वित किया गया है, जो लेटेंसी को कम करने और उच्च थ्रूपुट प्राप्त करने के लिए आवंटन, थ्रेडिंग और सिंक्रनाइज़ेशन को सावधानीपूर्वक अनुकूलित करता है। इंजन प्रति DomainGroup एक वर्कर थ्रेड उत्पन्न करता है, प्रत्येक NUMA नोड पर एक CPU कोर से जुड़ा होता है जिससे डिवाइस जुड़े होते हैं, जिससे शेड्यूलिंग और मेमोरी एक्सेस लेटेंसी दोनों कम हो जाती हैं। डोमेन के लिए विशिष्ट डेटा संरचनाओं को यह सुनिश्चित करने के लिए पिन करने के बाद आवंटित किया जाता है कि मेमोरी सही NUMA नोड में आरक्षित है। एक वर्कर थ्रेड 4 Domain तक संभालता है (प्रत्येक एक सिंगल NIC का प्रबंधन करता है), जबकि एक अन्य समर्पित थ्रेड UVM वॉचर्स को अपडेट करने के लिए GPU को पोल करता है। क्रॉस-थ्रेड संचार लॉक-फ्री कतारों के माध्यम से किया जाता है।

एपीआई अनुरोधों को उचित डिवाइस की सेवा देने वाले DomainGroup को अग्रेषित करता है, जिसमें पहला होस्ट की भी सेवा करता है। एक टाइट लूप में, डोमेन वर्कर नए काम के लिए पोल करता है, नए अनुरोधों के सबमिशन को प्राथमिकता देता है। हार्डवेयर और कॉन्फ़िगरेशन के आधार पर, अनुरोधों को उपलब्ध Domains में शार्ड और लोड-बैलेंस किया जाता है। एक समग्र अनुरोध का पहला राइट तुरंत NIC की सेंड क्यू में पोस्ट किया जाता है। एक बार नए अनुरोध समाप्त हो जाने के बाद, वर्कर लंबित ऑपरेशन्स को आगे बढ़ाता है, हार्डवेयर पाइपलाइन को भरने के लिए राइट्स पोस्ट करता है। इसके बाद, पूर्ण किए गए ट्रांसफर और तत्काल काउंटर वृद्धियों के लिए पूछताछ करने के लिए कंप्लीशन क्यू को पोल किया जाता है। इवेंट्स को प्रति-ट्रांसफर अधिसूचनाएं देने के लिए एग्रीगेट किया जाता है, जो ट्रांसफर को सभी समूहों द्वारा साझा किए गए एक समर्पित कॉलबैक थ्रेड को सौंप देता है।

एक DomainGroup के भीतर शार्डिंग लचीली है। ट्रांसफर इंडेक्स द्वारा विशिष्ट NICs को लक्षित कर सकते हैं। एक सिंगल राइट को विभाजित किया जा सकता है। पेजेड ट्रांसफर, स्कैटर और बैरियर ऑपरेशन्स, जो सभी कई राइट्स में अनुवाद करते हैं, सभी NICs में शार्ड कर सकते हैं।

TransferEngine के भीतर Domains उनके नियंत्रण में हार्डवेयर के लिए विशिष्ट और अनुकूलित हैं:

AWS EFA: EFA कार्यान्वयन libfabric का उपयोग करता है, DomainGroup के भीतर प्रति NIC एक फैब्रिक डोमेन का प्रबंधन करता है। प्रमुख कार्यान्वयन निर्णय और अनुकूलन में शामिल हैं:

ज़ीरो-साइज़्ड राइट्स: EFA RDMA विनिर्देश से भिन्न है क्योंकि इसके लिए ज़ीरो-साइज़्ड राइट्स के लिए भी वैध लक्ष्य डिस्क्रिप्टर की आवश्यकता होती है। इसलिए, TransferEngine सभी ट्रांसफर के लिए वैध डिस्क्रिप्टर लागू करता है।

कार्य अनुरोध टेम्प्लेटिंग: बल्क ट्रांसफर और पीयर ग्रुप ऑपरेशन्स के लिए प्रति-ऑपरेशन ओवरहेड को कम करते हुए, पोस्ट करने से पहले libfabric स्ट्रक्ट्स के सामान्य क्षेत्रों को पहले से पॉप्युलेट और बनाए रखता है

NVIDIA ConnectX-7: ConnectX-7 कार्यान्वयन RC ट्रांसपोर्ट के साथ libibverbs का उपयोग करता है। प्रमुख कार्यान्वयन निर्णय और अनुकूलन में शामिल हैं:

हैंडशेक के लिए UD क्यू पेयर: प्रत्येक Domain RC कनेक्शन हैंडशेक का आदान-प्रदान करने के लिए एक अनरिलायबल डेटाग्राम (UD) क्यू पेयर का उपयोग करता है।

अलग RC क्यू पेयर: प्रति पीयर 2 RC क्यू पेयर बनाता है, एक टू-साइडेड सेंड/रिसीव ऑपरेशन्स के लिए और दूसरा वन-साइडेड राइट और WriteImm ऑपरेशन्स के लिए। यह पृथक्करण आवश्यक है क्योंकि Recv और WriteImm पूर्णता दोनों पोस्टिंग ऑर्डर में कार्य अनुरोधों का उपभोग करते हैं, जो हस्तक्षेप के बिना WriteImm का समर्थन करते हुए उच्च-स्तरीय Recv सिमेंटिक्स की अनुमति देते हैं।

कार्य अनुरोध टेम्प्लेटिंग: बल्क ट्रांसफर और पीयर ग्रुप्स के लिए कार्य अनुरोध संरचनाओं के सामान्य क्षेत्रों को पहले से पॉप्युलेट करता है।

कार्य अनुरोध चेनिंग: NIC पर डोरबेल रिंग की संख्या को कम करते हुए, ibv_send_wr के next पॉइंटर के माध्यम से 4 कार्य अनुरोधों तक लिंक करता है।

शिथिल ऑर्डरिंग (Relaxed ordering): 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

एपीआई डिज़ाइन

मेमोरी पंजीकरण

टू-साइडेड सेंड/रिसीव

वन-साइडेड राइट

पीयर ग्रुप्स और बल्क ऑपरेशन्स

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

पूर्णता अधिसूचना

कार्यान्वयन

हार्डवेयर-विशिष्ट अनुकूलन

निष्कर्ष

उद्धरण