LLM ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ RDMA ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಸಂವಹನ

LLM ಸಿಸ್ಟಮ್‌ಗಳು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ತರಬೇತಿ ಮತ್ತು ಅನುಮಾನದಲ್ಲಿ ರಚನಾತ್ಮಕ ಸಮಾನಾಂತರ ಮಾದರಿಗಳಿಗಾಗಿ ಸಾಮೂಹಿಕ ಸಂವಹನಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ. ಆದಾಗ್ಯೂ, ವಿಭಜಿತ ಅನುಮಾನ, ಮಿಕ್ಚರ್-ಆಫ್-ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ (MoE) ರೂಟಿಂಗ್ ಮತ್ತು ಅಸಿಂಕ್ರೋನಸ್ ರೀಇನ್‌ಫೋರ್ಸ್‌ಮೆಂಟ್ ಲರ್ನಿಂಗ್ ಫೈನ್-ಟ್ಯೂನಿಂಗ್‌ನಂತಹ ಹೊರಹೊಮ್ಮುತ್ತಿರುವ ಕೆಲಸದ ಹೊರೆಗಳು, ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಸಂವಹನದ ನಮ್ಯತೆಯನ್ನು ಬಯಸುತ್ತವೆ.

ನಮ್ಮ ಇತ್ತೀಚಿನ ಸಂಶೋಧನಾ ಪ್ರಬಂಧವು TransferEngine ಅನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಇದು NVIDIA 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 ಗಳನ್ನು ಒದಗಿಸಿದರೂ, ಈ ಕಾರ್ಯಾಚರಣೆಗಳು ಇನ್ನೂ ಸಾಮೂಹಿಕ ಶ್ಯಾಮ್ಟಿಕ್ಸ್ ಮತ್ತು ಮಿತಿಗಳನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತವೆ.

ಹಾರ್ಡ್‌ವೇರ್ ವೈವಿಧ್ಯತೆ: ವಿಶ್ವಾಸಾರ್ಹ ಸಂಪರ್ಕ (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 ಅನ್ನು ಗುರಿಯಾಗಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ, ಆಧಾರವಾಗಿರುವ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಆದರೆ ಕ್ರಮರಹಿತವಾಗಿದೆ ಎಂದು TransferEngine ಭಾವಿಸುತ್ತದೆ, ಅಂದರೆ RC ಮತ್ತು SRD ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್‌ಗಳೆರಡೂ ಒದಗಿಸುವ ಖಾತರಿಗಳ ಛೇದನವಾಗಿದೆ.

ImmCounter ಸಿಂಕ್ರೊನೈಸೇಶನ್: ಸಂದೇಶದ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯ ಸೂಚನೆಗಾಗಿ ಒಂದು ನವೀನ ಪ್ರಿಮಿಟಿವ್, ಇದು ಆರ್ಡರ್ ಮಾಡಿದ (RC) ಮತ್ತು ಆರ್ಡರ್ ಮಾಡದ (SRD) ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್‌ಗಳೆರಡರಲ್ಲೂ ಒಂದೇ ಕೋಡ್ ರನ್ ಆಗಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಮಲ್ಟಿ-ಎನ್‌ಐಸಿ ಬೆಂಬಲ: ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ವರ್ಗಾವಣೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಶಾರ್ಡ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರತಿ ಜಿಪಿಯುಗೆ ಬಹು ಎನ್‌ಐಸಿಗಳ ಪಾರದರ್ಶಕ ನಿರ್ವಹಣೆ.

ಕನಿಷ್ಠ API ಮೇಲ್ಮೈ: ಸಂಕೀರ್ಣ ಸಂವಹನ ಮಾದರಿಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಕುಪಡುವ ಸಣ್ಣ ಸೆಟ್ ಕಾರ್ಯಾಚರಣೆಗಳು.

TransferEngine ವ್ಯವಸ್ಥೆಯ ವಿನ್ಯಾಸ, ವಿನಂತಿ ಮತ್ತು callback ಮಾರ್ಗಗಳು, CPU workers, UVM buffers, GPUs, ಹಾಗೂ ಎರಡು GPU/NUMA domains ಅಕ್ರಮವಾಗಿ ತೋರಿಸಲಾಗಿದೆ.

TransferEngine ಪ್ರತಿ ಜಿಪಿಯುಗೆ ಒಂದು ವರ್ಕರ್ ಥ್ರೆಡ್ ಅನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ. ಪ್ರತಿಯೊಬ್ಬ ವರ್ಕರ್ DomainGroup ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ ಅದು ಹಾರ್ಡ್‌ವೇರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಅವಲಂಬಿಸಿ 1 ರಿಂದ 4 RDMA NIC ಗಳನ್ನು ಸಂಘಟಿಸುತ್ತದೆ (ಒಂದೇ ConnectX-7 400 Gbps ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ EFA ಗೆ ನಾಲ್ಕು 100 Gbps ಅಡಾಪ್ಟರ್‌ಗಳು ಅಥವಾ ಎರಡು 200 Gbps ಅಡಾಪ್ಟರ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ). DomainGroup ಒಳಗೆ, ಪ್ರತಿ Domain ಹಾರ್ಡ್‌ವೇರ್-ನಿರ್ದಿಷ್ಟವಾಗಿದೆ ಮತ್ತು ಒಂದೇ NIC ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಕ್ಯೂ ಜೋಡಿ ನಿರ್ವಹಣೆ, ಕೆಲಸ ಸಲ್ಲಿಕೆ ಮತ್ತು ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ ಪೋಲಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಪ್ರತಿ TransferEngine instance ಸಹಪಕ್ಷ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಅನ್ವೇಷಣೆಗಾಗಿ ಒಂದೇ ಒಂದು ಮುಖ್ಯ ವಿಳಾಸವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ದೂರದ ಸಹಪಕ್ಷಗಳು ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸಗಳನ್ನು ಸಂಕೇತಿಸುವ ಹಾಗೂ out-of-band ಸಂವಹನಕ್ಕಾಗಿ serialise ಮಾಡಬಹುದಾದ NetAddr structs ಅನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಸಹಪಕ್ಷಗಳು ಪ್ರತಿ GPUಗೆ ಒಂದೇ ಸಂಖ್ಯೆಯ NICಗಳನ್ನು ಬಳಸಬೇಕು. ಈ ಏಕರೂಪ ಸಂರಚನೆಯು TransferEngine ಗೆ transfers ಅನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ shard ಮಾಡಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ: transfer ಅನ್ನು ಆರಂಭಿಸುವಾಗ, ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಎರಡೂ ಯಾವ NICಗಳು ಲಭ್ಯವಿವೆ ಎಂದು ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತವೆ, ಇದರಿಂದ ಎಲ್ಲಾ adapters ಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ load balancing ಸಾಧ್ಯವಾಗುತ್ತದೆ.

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 ಗೆ ಒಂದು) ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದೆ. ಈ ವಿನ್ಯಾಸವು ಮಲ್ಟಿ-ಎನ್‌ಐಸಿ ಸೆಟಪ್‌ಗಳನ್ನು ಸ್ವಾಭಾವಿಕವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ.

ಚಿಕ್ಕ ಸಂದೇಶಗಳು ಮತ್ತು 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 ವಾಚರ್‌ಗಳೊಂದಿಗೆ ಇದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಜಿಪಿಯು ಕರ್ನೆಲ್‌ಗಳಿಂದ (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 ನೊಡ್‌ನಲ್ಲಿ ಸಿಪಿಯು ಕೋರ್‌ಗೆ ಪಿನ್ ಮಾಡಲ್ಪಟ್ಟಿರುತ್ತದೆ, ಇದು ವೇಳಾಪಟ್ಟಿ ಮತ್ತು ಮೆಮೊರಿ ಪ್ರವೇಶ ಸುಪ್ತತೆ ಎರಡನ್ನೂ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಮೆಮೊರಿಯನ್ನು ಸರಿಯಾದ NUMA ನೊಡ್‌ನಲ್ಲಿ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪಿನ್ ಮಾಡಿದ ನಂತರ ಡೊಮೇನ್‌ಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಒಂದು ವರ್ಕರ್ ಥ್ರೆಡ್ 4 Domain ಗಳವರೆಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ (ಪ್ರತಿಯೊಂದೂ ಒಂದೇ NIC ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ), ಆದರೆ ಮತ್ತೊಂದು ಸಮರ್ಪಿತ ಥ್ರೆಡ್ UVM ವಾಚರ್‌ಗಳನ್ನು ನವೀಕರಿಸಲು GPU ಅನ್ನು ಪೋಲ್ ಮಾಡುತ್ತದೆ. ಕ್ರಾಸ್-ಥ್ರೆಡ್ ಸಂವಹನವನ್ನು ಲಾಕ್-ಫ್ರೀ ಕ್ಯೂಗಳ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.

API ವಿನಂತಿಗಳನ್ನು ಸೂಕ್ತವಾದ ಸಾಧನಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸುವ DomainGroup ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮೊದಲನೆಯದು ಹೋಸ್ಟ್‌ಗೂ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ. ಟೈಟ್ ಲೂಪ್‌ನಲ್ಲಿ, ಡೊಮೇನ್ ವರ್ಕರ್ ಹೊಸ ಕೆಲಸಕ್ಕಾಗಿ ಪೋಲ್ ಮಾಡುತ್ತದೆ, ಹೊಸ ವಿನಂತಿಗಳ ಸಲ್ಲಿಕೆಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ. ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿ, ವಿನಂತಿಗಳನ್ನು ಲಭ್ಯವಿರುವ Domain ಗಳಾದ್ಯಂತ ಶಾರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಸಂಯೋಜಿತ ವಿನಂತಿಯ ಮೊದಲ ಬರೆಯುವಿಕೆಯನ್ನು ತಕ್ಷಣವೇ NIC ಯ ಕಳುಹಿಸುವ ಕ್ಯೂಗೆ ಪೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ. ಹೊಸ ವಿನಂತಿಗಳು ಖಾಲಿಯಾದ ನಂತರ, ವರ್ಕರ್ ಬಾಕಿ ಉಳಿದಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮುಂದುವರಿಸಲು ಮುಂದುವರಿಯುತ್ತದೆ, ಹಾರ್ಡ್‌ವೇರ್ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ತುಂಬಲು ಬರೆಯುವಿಕೆಯನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ. ತರುವಾಯ, ಮುಗಿದ ವರ್ಗಾವಣೆಗಳು ಮತ್ತು ತಕ್ಷಣದ ಕೌಂಟರ್ ಹೆಚ್ಚಳಕ್ಕಾಗಿ ಪ್ರಶ್ನಿಸಲು ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ ಕ್ಯೂಗಳನ್ನು ಪೋಲ್ ಮಾಡಲಾಗುತ್ತದೆ. ಪ್ರತಿ-ವರ್ಗಾವಣೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ತಲುಪಿಸಲು ಈವೆಂಟ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ, ಎಲ್ಲಾ ಗುಂಪುಗಳು ಹಂಚಿಕೊಳ್ಳುವ ಸಮರ್ಪಿತ ಕಾಲ್‌ಬ್ಯಾಕ್ ಥ್ರೆಡ್‌ಗೆ ವರ್ಗಾವಣೆಯನ್ನು ಹಸ್ತಾಯಿಸಲಾಗುತ್ತದೆ.

DomainGroup ಒಳಗಿನ sharding ಲವಚಿಕವಾಗಿದೆ. Transfers ಅನ್ನು index ಮೂಲಕ ನಿರ್ದಿಷ್ಟ NICಗಳಿಗೆ target ಮಾಡಬಹುದು. ಒಂದೇ Write ಅನ್ನು split ಮಾಡಬಹುದು. Paged transfers, scatter, ಮತ್ತು barrier operations, ಇವೆಲ್ಲವೂ multiple Writes ಗೆ translate ಆಗುವುದರಿಂದ, ಎಲ್ಲಾ NICಗಳ across shard ಆಗಬಹುದು.

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 ಕ್ಯೂ ಜೋಡಿಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಒಂದು ಎರಡು-ಬದಿಯ ಕಳುಹಿಸು/ಸ್ವೀಕರಿಸಿ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಒಂದು-ಬದಿಯ ಬರೆಯುವಿಕೆ ಮತ್ತು WriteImm ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ. Recv ಮತ್ತು WriteImm ಎರಡೂ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಗಳು ಪೋಸ್ಟಿಂಗ್ ಕ್ರಮದಲ್ಲಿ ಕೆಲಸದ ವಿನಂತಿಗಳನ್ನು ಸೇವಿಸುವುದರಿಂದ ಈ ಪ್ರತ್ಯೇಕತೆಯು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ, ಇದು ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ WriteImm ಅನ್ನು ಬೆಂಬಲಿಸುವಾಗ ಉನ್ನತ ಮಟ್ಟದ Recv ಶ್ಯಾಮ್ಟಿಕ್ಸ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಕೆಲಸದ ವಿನಂತಿ ಟೆಂಪ್ಲೇಟಿಂಗ್: ಬಲ್ಕ್ ವರ್ಗಾವಣೆಗಳು ಮತ್ತು ಪೀರ್ ಗುಂಪುಗಳಿಗಾಗಿ ಕೆಲಸದ ವಿನಂತಿ ರಚನೆಗಳ ಸಾಮಾನ್ಯ ಕ್ಷೇತ್ರಗಳನ್ನು ಪೂರ್ವ-ಜನಸಂಖ್ಯೆ ಮಾಡುತ್ತದೆ.

ಕೆಲಸದ ವಿನಂತಿ ಚೈನಿಂಗ್: ibv_send_wr ನ next ಪಾಯಿಂಟರ್ ಮೂಲಕ 4 ಕೆಲಸದ ವಿನಂತಿಗಳನ್ನು ಲಿಂಕ್ ಮಾಡುತ್ತದೆ, NIC ಗೆ ಡೋರ್‌ಬೆಲ್ ರಿಂಗ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ರಿಲ್ಯಾಕ್ಸೆಡ್ ಆರ್ಡರಿಂಗ್: NIC ಮತ್ತು GPU ಮೆಮೊರಿ ನಡುವಿನ ಔಟ್-ಆಫ್-ಆರ್ಡರ್ PCIe ವಹಿವಾಟುಗಳನ್ನು ಅನುಮತಿಸಲು IBV_ACCESS_RELAXED_ORDERING ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

ವಿಭಿನ್ನ RDMA transports ಗಳಲ್ಲಿನ guaranteesಗಳ intersection ಅನ್ನು target ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ImmCounter ಮೂಲಕ order-independent synchronization ಅನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ, TransferEngine LLM systems ಗಳಲ್ಲಿ point-to-point communication ಗೆ portable foundation ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ library open source ಆಗಿದ್ದು GitHub ನಲ್ಲಿ ಲಭ್ಯವಿದೆ, ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದ machine learning systems ಗಳಲ್ಲಿ ಉದಯೋನ್ಮುಖ communication patterns ಗಳಿಗಾಗಿ community ಇದನ್ನು ಅನ್ವೇಷಿಸಿ ಇದರ ಮೇಲೆ ನಿರ್ಮಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತೇವೆ.

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 ವಿನ್ಯಾಸ

ಮೆಮೊರಿ ನೋಂದಣಿ

ಎರಡು-ಬದಿಯ ಕಳುಹಿಸು/ಸ್ವೀಕರಿಸಿ (Two-Sided Send/Recv)

ಒಂದು-ಬದಿಯ ಬರೆಯುವಿಕೆ (One-Sided Write)

ಪೀರ್ ಗುಂಪುಗಳು ಮತ್ತು ಬಲ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳು

UVM ವಾಚರ್: GPU ನಿಂದ CPU ಸಿಗ್ನಲಿಂಗ್

ಪೂರ್ಣಗೊಂಡ ಸೂಚನೆ

ಅನುಷ್ಠಾನ

ಹಾರ್ಡ್‌ವೇರ್-ನಿರ್ದಿಷ್ಟ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು

ತೀರ್ಮಾನ

ಉಲ್ಲೇಖ