LLM సిస్టమ్‌ల కోసం RDMA పాయింట్-టు-పాయింట్ కమ్యూనికేషన్

శిక్షణ మరియు అనుమితిలో నిర్మాణాత్మక సమాంతర నమూనాల కోసం LLM సిస్టమ్‌లు సాంప్రదాయకంగా సమిష్టి కమ్యూనికేషన్‌లపై ఆధారపడ్డాయి. అయినప్పటికీ, డిస్‌గ్రిగేటెడ్ అనుమితి, మిక్చర్-ఆఫ్-ఎక్స్‌పర్ట్స్ (MoE) రూటింగ్ మరియు అసਿੰక్రోనస్ రీఇన్‌ఫోర్స్‌మెంట్ లెర్నింగ్ ఫైన్-ట్యూనింగ్ వంటి ఉద్భవిస్తున్న వర్క్‌లోడ్‌లకు పాయింట్-టు-పాయింట్ కమ్యూనికేషన్ యొక్క సౌలభ్యం అవసరం.

మా తాజా పరిశోధనా పత్రం TransferEngineని పరిచయం చేస్తుంది, ఇది NVIDIA ConnectX-7 మరియు AWS Elastic Fabric Adapter (EFA)తో సహా వివిధ నెట్‌వర్క్ ఇంటర్‌ఫేస్ కంట్రోలర్‌లలో (NICలు) పనిచేసే పోర్టబుల్ RDMA-ఆధారిత కమ్యూనికేషన్ లైబ్రరీ. Perplexity AIలోని మూడు ప్రొడక్షన్ సిస్టమ్‌లలో మేము దాని ప్రభావాన్ని ప్రదర్శిస్తాము:

డిస్‌గ్రిగేటెడ్ ప్రిఫిల్ మరియు డికోడ్: పేజ్డ్ రైట్స్ మరియు UVM వాచర్‌లను ఉపయోగించి లేయర్-బై-లేయర్ KvCache బదిలీ, ప్రిఫిల్ మరియు డికోడ్ ఇన్‌స్టాన్స్‌లు స్వతంత్రంగా స్కేల్ చేయడానికి అనుమతిస్తుంది.

2 సెకన్లలోపు RL పోస్ట్-ట్రైనింగ్ కోసం వెయిట్ బదిలీ: శిక్షణ మరియు అనుమితి నోడ్‌ల మధ్య చాలా వేగంగా వెయిట్ సింక్రొనైజేషన్.

AWS EFAలో ట్రిలియన్-పారామీటర్ మోడళ్లను ప్రారంభించడం: స్క్యాటర్ మరియు బారియర్ ప్రిమిటివ్‌లను ఉపయోగించి తక్కువ-లేటెన్సీ MoE డిస్పాచ్ మరియు కంబైన్ ఆపరేషన్‌లు, ConnectX-7పై స్టేట్-ఆఫ్-ఆర్ట్ లేటెన్సీని మరియు AWS EFAకి అనుకూలంగా ఉండే మొట్టమొదటి ఆచరణాత్మక అమలును సాధించడం.

ఈ వ్యాసం TransferEngineపై దృష్టి పెడుతుంది, ఈ సిస్టమ్‌లకు శక్తినిచ్చే కమ్యూనికేషన్ లైబ్రరీ. arXivలో పూర్తి పరిశోధనా పత్రాన్ని చదవండి మరియు GitHubలో కోడ్‌ను అన్వేషించండి.

Collective communications Tensor Parallelism మరియు Data Parallelism వంటి నిర్మిత సమాంతర నమూనాల్లో అద్భుతంగా పనిచేస్తాయి, కానీ అవి కొత్త వర్క్‌లోడ్‌లకు వాటి వర్తింపును పరిమితం చేసే నియంత్రణలను విధిస్తాయి:

స్థిర సభ్యత్వం: Collectives ప్రారంభ సమయంలో గ్లోబల్ కమ్యూనికేషన్ ప్రపంచాన్ని ఏర్పాటు చేయడం అవసరం, ఇందులో అన్ని పాల్గొనేవారిలో సమన్వయిత సెటప్ ఉంటుంది. disaggregated inference కోసం, prefill మరియు decode instances సంఖ్య ట్రాఫిక్ నమూనాలకు అనుగుణంగా డైనమిక్‌గా స్కేల్ కావాల్సి ఉండడం వల్ల ఇది సమస్యాత్మకం.

యూనిఫాం టెన్సర్ ఆకారాలు: పాల్గొనే వారందరూ ఒకే విధమైన ఆకారాలు మరియు డేటా రకాలతో టెన్సర్‌లను మార్పిడి చేసుకుంటారని సమిష్టిలు భావిస్తాయి. MoE రూటింగ్‌లో, ప్రతి నిపుణుడికి పంపబడిన టోకెన్‌ల సంఖ్య డేటా-ఆధారితమైనది మరియు రన్‌టైమ్‌లో కనుగొనబడుతుంది, ఇది దట్టమైన ఆల్-టు-ఆల్ కలెక్టివ్‌లను చెత్త-కేస్ బఫర్ పరిమాణాలకు ప్యాడ్ చేయవలసి వస్తుంది.

ఆపరేషన్ ఆర్డరింగ్: అప్లికేషన్‌లకు ఆపరేషన్‌ల సమితి పూర్తయిందని మాత్రమే తెలిస్తే చాలు, సమిష్టి APIలు సమకాలీకరించబడిన సెమాంటిక్స్‌ను అమలు చేస్తాయి. ఉదాహరణకు, KvCache బదిలీలో, ప్రిఫిల్ ఇన్‌స్టాన్స్ నుండి డికోడ్ ఇన్‌స్టాంటికి అన్ని పేజీలు ఏ క్రమంలోనైనా రావచ్చు. అదేవిధంగా, RL వెయిట్ అప్‌డేట్‌లలో, అన్ని వెయిట్ టెన్సర్‌లు ఆర్డరింగ్ పరిమితులు లేకుండా స్వతంత్రంగా బదిలీ చేయబడతాయి.

RDMA-ఆధారిత పాయింట్-to-పాయింట్ కమ్యూనికేషన్ ఈ పరిమితులను సహజంగా పరిష్కరిస్తుంది, అయితే మూడు అడ్డంకులు దాని స్వీకరణను నిరోధించాయి:

లైబ్రరీ పరిమితులు: torch.distributed మరియు NCCL Send/Recv వంటి పాయింట్-టు-పాయింట్ APIలను అందిస్తున్నప్పటికీ, ఈ ఆపరేషన్‌లు ఇప్పటికీ కలెక్టివ్ సెమాంటిక్స్ మరియు పరిమితులను వారసత్వంగా పొందుతాయి.

హార్డ్‌వేర్ వైవిధ్యం: రిలయబుల్ కనెక్షన్ (RC) ట్రాన్స్‌పోర్ట్‌తో కూడిన NVIDIA ConnectX NICలు అత్యంత సాధారణ RDMA సెటప్, ఇది ఆర్డర్‌లో డెలివరీకి హామీ ఇస్తుంది. AWS వంటి క్లౌడ్ ప్రొవైడర్‌లు వేర్వేరు హార్డ్‌వేర్‌లను ఉపయోగిస్తాయి, స్కేలబుల్ రిలయబుల్ డాగ్రామ్ (SRD) ట్రాన్స్‌పోర్ట్‌తో కూడిన ఎలాస్టిక్ ఫ్యాబ్రిక్ అడాప్టర్ (EFA) సందేశాలను ఔట్-ఆఫ్-ఆర్డర్‌లో అందిస్తుంది. 400 Gbps బ్యాండ్‌విడ్త్‌ను సాధించడానికి EFAకి నాలుగు 100 Gbps NICలు (లేదా రెండు 200 Gbps NICలు) ఏకీకృతం చేయడం కూడా అవసరం.

సాఫ్ట్‌వేర్ పోర్టబిలిటీ: ఇప్పటికే ఉన్న RDMA లైబ్రరీలు విక్రేత లాక్-ఇన్ నుండి బాధపడుతున్నాయి. DeepEP ConnectXలో మాత్రమే అందుబాటులో ఉండే GPU-ప్రారంభించబడిన RDMA (IBGDA) అవసరం. NVSHMEM EFAలో తీవ్రమైన పనితీరు క్షీణతను ప్రదర్శిస్తుంది. Mooncake మరియు NIXL వంటి లైబ్రరీలకు EFA మద్దతు లేదు లేదా ప్రారంభ అభివృద్ధి దశలోనే ఉన్నాయి. ఫలితంగా, LLM అనుమితి కోసం క్రాస్-ప్రొవైడర్ పరిష్కారం ఏదీ లేదు.

TransferEngine నాలుగు ప్రధాన సామర్థ్యాల ద్వారా ఈ అడ్డంకులను పరిష్కరిస్తుంది:

సాధారణ రవాణా ఊహలు: నిర్దిష్ట NICని లక్ష్యంగా చేసుకోవడానికి బదులుగా, అంతర్లీన రవాణా నమ్మదగినది కానీ ఆర్డర్ చేయబడలేదు, అనగా RC మరియు SRD రవాణా రెండూ అందించే హామీల ఖండన అని TransferEngine ఊహిస్తుంది.

ImmCounter సమకాలీకరణ: మెసేజ్ ఆర్డరింగ్‌పై ఆధారపడకుండా పనిచేసే పూర్తి నోటిఫికేషన్ కోసం ఒక నూతన ప్రిమిటివ్, అదే కోడ్ ఆర్డర్ చేయబడిన (RC) మరియు ఆర్డర్ చేయని (SRD) ట్రాన్స్‌పోర్ట్‌లపై రన్ కావడానికి వీలు కల్పిస్తుంది.

మల్టీ-NIC మద్దతు: GPUకి బహుళ NICల పారదర్శక నిర్వహణ, బ్యాండ్‌విడ్త్‌ను పెంచడానికి స్వయంచాలకంగా బదిలీలను షార్డ్ చేయడం.

కనిష్ట API ఉపరితలం: సంక్లిష్టమైన కమ్యూనికేషన్ నమూనాలను నిర్మించడానికి సరిపోయే చిన్న ఆపరేషన్ల సమితి.

ట్రాన్స్‌ఫర్‌ఎంజిన్ వ్యవస్థ రూపకల్పన; రెండు GPU/NUMA డొమైన్‌లలో అభ్యర్థన మరియు కాల్‌బ్యాక్ మార్గాలు, CPU వర్కర్లు, UVM బఫర్లు, GPUలు, మరియు NICలను చూపిస్తుంది.

TransferEngine ప్రతి GPUకి ఒక వర్కర్ థ్రెడ్ను సృష్టిస్తుంది. ప్రతి వర్కర్ DomainGroupను నిర్వహిస్తుంది, ఇది హార్డ్‌వేర్ ప్లాట్‌ఫారమ్‌ను బట్టి 1 నుండి 4 RDMA NICలను సమన్వయం చేస్తుంది (ఒక একক ConnectX-7 400 Gbpsని అందిస్తుంది, అయితే EFAకి నాలుగు 100 Gbps అడాప్టర్లు లేదా రెండు 200 Gbps అడాప్టర్లు అవసరం). DomainGroup లోపల, ప్రతి Domain హార్డ్‌వేర్-నిర్దిష్టమైనది మరియు ఒకే NICని నిర్వహిస్తుంది, క్యూ జత నిర్వహణ, పని సమర్పణ మరియు పూర్తి పోలింగ్‌ను నిర్వహిస్తుంది.

ప్రతి TransferEngine instance పీర్ గుర్తింపు మరియు అన్వేషణ కోసం ఒకే ఒక ప్రధాన చిరునామాను అందిస్తుంది. రిమోట్ peers నెట్‌వర్క్ చిరునామాలను ఎన్‌కోడ్ చేసే మరియు out-of-band కమ్యూనికేషన్ కోసం సీరియలైజ్ చేయగల NetAddr structs‌ను మార్పిడి చేసుకుంటాయి. సిస్టమ్‌లోని అన్ని peers ప్రతి GPUకి ఒకే సంఖ్యలో NICs‌ను ఉపయోగించాలి. ఈ ఏకరీతి కాన్ఫిగరేషన్ TransferEngine‌కు transfers‌ను తెలివిగా shard చేయడానికి అనుమతిస్తుంది: transfer‌ను ప్రారంభించేటప్పుడు, source మరియు destination రెండూ ఏ NICs అందుబాటులో ఉన్నాయో ఖచ్చితంగా తెలుసుకుంటాయి, తద్వారా అన్ని adapters‌లో ఆటోమేటిక్ load balancing సాధ్యమవుతుంది.

TransferEngine అంతర్లీన RDMA ఇంటర్‌ఫేసెస్ యొక్క సంక్లిష్టతను సంగ్రహించే కనిష్ట APIని బహిర్గతం చేస్తుంది.

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: పీర్‌లన్నింటికీ తక్షణ-మాత్రమే నోటిఫికేషన్‌ను పంపుతుంది (జీరో-బైట్ బదిలీ)

ఈ operations అంతర్గత data structures‌ను cache చేయడం మరియు RDMA work requests‌ను template చేయడం ద్వారా తక్కువ latency కోసం ఆప్టిమైజ్ చేయబడ్డాయి, దీనివల్ల పునరావృత setup overhead నివారించబడుతుంది.

LLM సిస్టమ్‌లలో ఒక ప్రధాన సవాలు ఏమిటంటే RDMA బదిలీలను GPU పురోగతితో సమన్వయం చేయడం. ఆదర్శవంతంగా, 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 NICలలో (RC ట్రాన్స్‌పోర్ట్ ద్వారా ఇన్-ఆర్డర్ డెలివరీకి హామీ ఇస్తుంది) మరియు EFA NICలలో (SRD ట్రాన్స్‌పోర్ట్ ద్వారా ఔట్-ఆఫ్-ఆర్డర్‌లో సందేశాలను అందిస్తుంది) సమానంగా బాగా పనిచేస్తుంది.

TransferEngine రస్ట్‌లో అమలు చేయబడింది, లేటెన్సీని తగ్గించడానికి మరియు అధిక త్రూపుట్‌ను సాధించడానికి కేటాయింపులు, థ్రెడింగ్ మరియు సమకాలీకరణను జాగ్రత్తగా ఆప్టిమైజ్ చేస్తుంది. ఇంజిన్ ప్రతి DomainGroupకి ఒక వర్కర్ థ్రెడ్‌ను సృష్టిస్తుంది, ప్రతి ఒక్కటి పరికరాలు జోడించబడిన NUMA నోడ్‌లోని CPU కోర్‌కు పిన్ చేయబడుతుంది, షెడ్యూలింగ్ మరియు మెమరీ యాక్సెస్ లేటెన్సీ రెండింటినీ తగ్గిస్తుంది. సరైన NUMA నోడ్‌లో మెమరీ రిజర్వు చేయబడిందని నిర్ధారించడానికి పిన్నింగ్ తర్వాత డొమైన్‌కు నిర్దిష్టమైన డేటా నిర్మాణాలు కేటాయించబడతాయి. ఒక వర్కర్ థ్రెడ్ గరిష్టంగా 4 Domainలను నిర్వహిస్తుంది (ప్రతి ఒక్కటి ఒకే NICని నిర్వహిస్తుంది), మరో అంకితమైన థ్రెడ్ UVM వాచర్‌లను నవీకరించడానికి GPUని పోల్ చేస్తుంది. క్రాస్-థ్రెడ్ కమ్యూనికేషన్ లాక్-ఫ్రీ క్యూల ద్వారా చేయబడుతుంది.

API, తగిన device‌ను సేవలందించే DomainGroupకు requests‌ను ఫార్వర్డ్ చేస్తుంది, మొదటి one host‌కూ సేవలందిస్తుంది. ఒక tight loop‌లో, domain worker కొత్త work కోసం poll చేస్తూ, కొత్త requests submission‌కు ప్రాధాన్యం ఇస్తాడు. hardware మరియు configuration‌పై ఆధారపడి, requests అందుబాటులో ఉన్న Domains‌లో shard చేసి load-balanced చేయబడతాయి. composite request‌లోని మొదటి Write వెంటనే NIC యొక్క send queueకు post చేయబడుతుంది. కొత్త requests ముగిసిన తర్వాత, worker pending operations‌ను progress చేయడానికి కొనసాగి, hardware pipeline‌ను నింపడానికి writes‌ను post చేస్తాడు. తరువాత, completion queues‌ను poll చేసి పూర్తైన transfers మరియు immediate counter increments‌ను query చేస్తారు. ప్రతి transfer‌కు సంబంధించిన Notifications‌ను అందించడానికి events‌ను aggregate చేస్తారు, transfer‌ను అన్ని groups‌కు shared అయిన dedicated callback థ్రెడ్‌కు hand off చేస్తారు.

DomainGroup లోపల షార్డింగ్ సౌకర్యవంతంగా ఉంటుంది. బదిలీలు సూచిక ద్వారా నిర్దిష్ట NICలను లక్ష్యంగా చేసుకోవచ్చు. ఒకే రైట్ విభజించబడవచ్చు. బహుళ రైట్‌లుగా అనువదించే పేజ్డ్ బదిలీలు, స్క్యాటర్ మరియు బారియర్ ఆపరేషన్‌లు అన్ని NICలలో షార్డ్ చేయగలవు.

TransferEngine లోపలి Domainలు ప్రత్యేకమైనవి మరియు వాటి నియంత్రణలో ఉన్న హార్డ్‌వేర్ కోసం ఆప్టిమైజ్ చేయబడ్డాయి:

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 ద్వారా ఆర్డర్-స్వతంత్ర సమకాలీకరణను ప్రవేశపెట్టడం ద్వారా, 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 డిజైన్

మెమరీ రిజిస్ట్రేషన్

రెండు-వైపుల Send/Recv

ఒకవైపు వ్రాయండి

పీర్ గ్రూప్‌లు మరియు బల్క్ ఆపరేషన్‌లు

UVM వాచర్: GPU-నుండి-CPU సిగ్నలింగ్

పూర్తి నోటిఫికేషన్

అమలు

హార్డ్‌వేర్-నిర్దిష్ట ఆప్టిమైజేషన్‌లు

ముగింపు

ఉదాహరణ