AWS EFA ನಲ್ಲಿ ಟ್ರಿಲಿಯನ್-ಪ್ಯಾರಾಮೀಟರ್ ಮಾದರಿಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು

Perplexity ನಲ್ಲಿ, ನಾವು ನಮ್ಮ ಉತ್ಪನ್ನ, ನಮ್ಮ API ಗಳು ಮತ್ತು ನಮ್ಮ ಸಂಶೋಧನಾ ತಂಡಗಳಿಗಾಗಿ ಅತ್ಯುತ್ತಮ ಮಾದರಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. Kimi-K2 ನಂತಹ ದೊಡ್ಡ ಓಪನ್ ಸೋರ್ಸ್ ಮಿಕ್ಚರ್-ಆಫ್-ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ (Mixture-of-Experts) ಮಾದರಿಗಳು ನಿರ್ದಿಷ್ಟ ಸವಾಲುಗಳನ್ನು ಒಡ್ಡುತ್ತವೆ, ಏಕೆಂದರೆ 8x NVIDIA H200 GPU ಗಳನ್ನು ಹೊಂದಿರುವ ಅತಿ ದೊಡ್ಡ ಇನ್ಫೆರೆನ್ಸ್ ನೋಡ್‌ಗಳು ಅವುಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಸ್ಥಳಾವಕಾಶ ಕಲ್ಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇದರಿಂದಾಗಿ ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಅಗತ್ಯವಾಗುತ್ತವೆ. ಕನೆಕ್ಟ್ಎಕ್ಸ್-7 (ConnectX-7) ನಲ್ಲಿ ಅತ್ಯಾಧುನಿಕ ಸುಪ್ತತೆಗಳನ್ನು (latencies) ಸಾಧಿಸುವ ಎಕ್ಸ್‌ಪರ್ಟ್ ಪ್ಯಾರಲಲಿಸಮ್‌ಗಾಗಿ ನಾವು ಕೆಲವು ಕರ್ನಲ್‌ಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ, ಇದು DeepEP ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೀರಿದೆ. AWS ಎಲಾಸ್ಟಿಕ್ ಫ್ಯಾಬ್ರಿಕ್ ಅಡಾಪ್ಟರ್ (EFA) ನಲ್ಲಿ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸಿದ ಮೊದಲ ಕರ್ನಲ್‌ಗಳು ಇವಾಗಿವೆ, ಇದು ಟ್ರಿಲಿಯನ್-ಪ್ಯಾರಾಮೀಟರ್ ಮಾದರಿ ನಿಯೋಜನೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

GitHub ನಲ್ಲಿ ನಮ್ಮ ಕರ್ನಲ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು arXiv ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಸಂಶೋಧನಾ ಪ್ರಬಂಧವನ್ನು ಓದಿ.

ಪರಿಚಯ

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

torch.distributed ಮತ್ತು NCCL ನಂತಹ ಕಲೆಕ್ಟಿವ್ ಕಮ್ಯುನಿಕೇಷನ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಿ ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಟೆನ್ಸೋರ್ ಪ್ಯಾರಲಲಿಸಮ್ (TP) ಮತ್ತು ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್ (DP) ನಂತಹ ಇತರ ರೂಪಗಳ ಪ್ಯಾರಲಲಿಸಮ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿ, MoE ರೂಟಿಂಗ್ ಸ್ಪಾರ್ಸ್ ಪೀರ್-ಟು-ಪೀರ್ ಸಂವಹನವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಡಿಸ್ಪ್ಯಾಚ್ ಕರ್ನಲ್ ಒಳಬರುವ ಟೋಕನ್‌ಗಳ ಸೆಟ್ ಅನ್ನು ವಿಭಜಿಸಬೇಕು ಮತ್ತು ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ರ‍್ಯಾಂಕ್‌ಗಳಿಗೆ ಅವುಗಳನ್ನು ಕಳುಹಿಸಬೇಕು, ಆದರೆ ಅದರ ವಿಲೋಮ ಸಮಸ್ಯೆಯಾದ ಕಂಬೈನ್ ಕರ್ನಲ್, ಅವುಗಳ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಪ್ರತಿರೂಪಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಅವುಗಳ ತೂಕದ ಸರಾಸರಿಯನ್ನು ಲೆಕ್ಕ ಹಾಕಬೇಕು. ಈ ವರ್ಗಾವಣೆಗಳು ಕಲೆಕ್ಟಿವ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಆಗುವುದಿಲ್ಲ ಮತ್ತು ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ಸಾಧಿಸಲು ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಕರ್ನಲ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ.

Perplexity ನಲ್ಲಿ, ನಾವು ಪೋರ್ಟಬಲ್ ಇಂಟರ್-ನೋಡ್ ಕರ್ನಲ್‌ಗಳು ಮತ್ತು ವಿಶೇಷ ಇಂಟ್ರಾ-ನೋಡ್ ಕರ್ನಲ್‌ಗಳು ಎರಡನ್ನೂ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ, MoE ಸಂವಹನ ಕುರಿತ ಹಿಂದಿನ ಲೇಖನದಲ್ಲಿ ನಮ್ಮ ಕೆಲಸವನ್ನು ಹೆಚ್ಚಿನ ಆಳದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತಿದ್ದೇವೆ. ಬಹು-ನೋಡ್ ನಿಯೋಜನೆ ದೊಡ್ಡ MoE ಮಾದರಿಗಳಿಗೆ ಕಡಿಮೆ ಸುಪ್ತತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ ಅನ್ನು ತರಬಹುದು ಎಂದು ನಾವು ಮತ್ತೊಂದು ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ತೋರಿಸಿದ್ದೇವೆ.

ಈ ಲೇಖನದಲ್ಲಿ, ನಮ್ಮ ಹೊಸ ಇಂಟರ್-ನೋಡ್ kernelsಗಳ ಅನುಷ್ಠಾನವನ್ನು ನಾವು ಆಳವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ; ಇದು ನಮ್ಮ NVSHMEM ಆಧಾರಿತ ಹಿಂದಿನ ಕೆಲಸದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಹಳವಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ. ConnectX-7 ಮೇಲೆ ಅತ್ಯಾಧುನಿಕ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದರ ಜೊತೆಗೆ, ನಮ್ಮ inference runtime ಒಳಗೆ, ಈ kernelsಗಳನ್ನು ಅತಿದೊಡ್ಡ open-source modelsಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ serve ಮಾಡಲು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದನ್ನೂ ನಾವು ತೋರಿಸುತ್ತೇವೆ.

ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಮೂಲಕ ಇನ್ಫೆರೆನ್ಸ್

NVLink ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳ ಸುಪ್ತತೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ (900GB/s) ಅನ್ನು ಒದಗಿಸುವುದರಿಂದ, ಟೆನ್ಸೋರ್ ಪ್ಯಾರಲಲಿಸಮ್ ಮತ್ತು ಎಕ್ಸ್‌ಪರ್ಟ್ ಪ್ಯಾರಲಲಿಸಮ್ ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸ್ಕೇಲ್ ಮಾಡಬಹುದು. NVIDIA GB200 ಮತ್ತು GB300 ಸಿಸ್ಟಮ್‌ಗಳು ಟ್ರಿಲಿಯನ್-ಪ್ಯಾರಾಮೀಟರ್ ಮಾದರಿಗಳ ತೂಕ ಮತ್ತು KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಹಿಡಿದಿಡಲು ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿದ್ದರೂ, 8 H200 GPU ಗಳವರೆಗೆ AWS p5en ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಲ್ಲಿನ ನಿಯೋಜನೆಗಳು 1120GB HBM ಗೆ ಸೀಮಿತವಾಗಿವೆ, ಇದನ್ನು ಮಾದರಿ ತೂಕಗಳು ಮತ್ತು KV ಕ್ಯಾಶ್‌ಗಳು ಎರಡರ ನಡುವೆ ವಿಭಜಿಸಬೇಕು. ಪರಿಣಾಮವಾಗಿ, ಕೆಲವು ಮಾದರಿಗಳಿಗೆ ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಮೂಲಕ ಇಂಟರ್-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಅಗತ್ಯವಿರುತ್ತವೆ.

ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಇನ್ನೂ ಅತ್ಯಂತ ವೇಗವಾಗಿದ್ದರೂ, ಇದು ಕೇವಲ 400Gbps (50GB/s) ಥ್ರೋಪುಟ್ ಅನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ, ಇದು MoE ರೂಟಿಂಗ್‌ಗೆ ಹತ್ತಾರು ನೂರಾರು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳ ಸುಪ್ತತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅದೃಷ್ಟವಶಾತ್, ಸ್ಪರ್ಧಾತ್ಮಕ ವೆಚ್ಚದಲ್ಲಿ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಥ್ರೋಪುಟ್ ಅನ್ನು ತಲುಪಿಸಲು ಹಂಚಿದ ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳು, ಮೈಕ್ರೋ-ಬ್ಯಾಚಿಂಗ್ ಮತ್ತು ಕಂಪ್ಯೂಟೇಶನ್-ಕಮ್ಯುನಿಕೇಷನ್ ಓವರ್‌ಲ್ಯಾಪಿಂಗ್ ಬಳಕೆಯ ಮೂಲಕ ಹೆಚ್ಚುವರಿ ಸುಪ್ತತೆಗಳನ್ನು ಮರೆಮಾಚಬಹುದು. DeepSeek-R1 ಮೂಲಕ DeepSeek ಈ ತಂತ್ರಗಳಿಗೆ ಮುನ್ನುಡಿ ಬರೆಯಿತು, ಇದನ್ನು H800 GPU ಗಳು ಮತ್ತು NVIDIA ConnectX-7 ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಅಡಾಪ್ಟರ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ.

AWS ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ, ಅವುಗಳ ಕಸ್ಟಮ್ ಎಲಾಸ್ಟಿಕ್ ಫ್ಯಾಬ್ರಿಕ್ ಅಡಾಪ್ಟರ್‌ಗಳ (EFA) ಬಳಕೆಯಿಂದಾಗಿ ಪರಿಸ್ಥಿತಿಯು ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ತರಬೇತಿ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಕಲೆಕ್ಟಿವ್‌ಗಳ ಮೇಲೆ ಇವು 400Gbps ಪೀಕ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ತಲುಪಿಸಿದರೂ, MoE ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಸಮಯದಲ್ಲಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ಸಂದೇಶ ಗಾತ್ರಗಳಲ್ಲಿ ಇವು ConnectX-7 ಗಿಂತ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಬರುತ್ತವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, EFA GPUDirect Async ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ವರ್ಗಾವಣೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು GPU ಅನ್ನು NIC ಗೆ ಸೇತುವೆ ಮಾಡುವ CPU ಪ್ರಾಕ್ಸಿ ಥ್ರೆಡ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ಸಂಕೀರ್ಣತೆಯ ಹೊರತಾಗಿ, ಹೆಚ್ಚುವರಿ PCIe ವಹಿವಾಟುಗಳು ಎಲ್ಲಾ ವರ್ಗಾವಣೆಗಳಿಗೆ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳಷ್ಟು ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತವೆ. NVSHMEM ನಂತಹ ಫ್ರೇಮವರ್ಕ್‌ಗಳು ಕರ್ನಲ್ ಬರಹಗಾರರಿಗೆ ಸಾಧನ-ಸ್ವತಂತ್ರ ಅನುಷ್ಠಾನಗಳನ್ನು ಒದಗಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದಾಗ್ಯೂ ಜೆನೆರಿಕ್ API ಗಳು ವೆಚ್ಚ ಮತ್ತು ಸುಪ್ತತೆ ಎರಡರ ದೃಷ್ಟಿಯಿಂದ ನಿಯೋಜನೆಗಳನ್ನು ನಿಷ್ಫಲಗೊಳಿಸುವ ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

NVSHMEM-ಆಧಾರಿತ pplx-kernels

ನಮ್ಮ ಹಿಂದಿನ ಕರ್ನಲ್‌ಗಳು NVSHMEM ಮೂಲಕ ಆಧಾರವಾಗಿರುವ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅನುಷ್ಠಾನವನ್ನು ಅಮೂರ್ತಗೊಳಿಸಿದವು. ಅವು ಸಿಂಕ್ ಮಾಡಲು ಅಟಾಮಿಕ್ ಕೌಂಟರ್‌ಗಳನ್ನು ಬಳಸಿ, ಒಂದೊಂದಾಗಿ ಟೋಕನ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಲು nvshmemx_putmem_signal_nbi_warp ಅನ್ನು ಅವಲಂಬಿಸಿವೆ. IBGDA ನೊಂದಿಗೆ ConnectX-7 NIC ಗಳಲ್ಲಿ ಇದು ಸಮಂಜಸವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡಿದರೂ, ಪ್ರಾಕ್ಸಿ-ಆಧಾರಿತ ConnectX-7 IBRC ಅನುಷ್ಠಾನವು ಗಮನಾರ್ಹವಾಗಿ ನಿಧಾನವಾಗಿತ್ತು, ಆದರೆ EFA ಅನುಷ್ಠಾನವು ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಿಂತ ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ತಲುಪಿಸುವಲ್ಲಿ ವಿಫಲವಾಯಿತು.

ಅಡಿಪಾಯದ hardware ಅನ್ನು ಪರೀಕ್ಷಿಸುವ testbed ಆಗಿ ನಾವು ಈ kernelsಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ, ಜೊತೆಗೆ ನಮ್ಮ modelsಗಳಿಗೆ expose ಮಾಡಲು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ interface ಅನ್ನು ಕೂಡ ನಿರ್ಧರಿಸಿದ್ದೇವೆ. kernels ಮತ್ತು NICs ಅಥವಾ proxy threads ನಡುವಿನ ಆಗಾಗ್ಗೆ ನಡೆಯುವ transfers ಮತ್ತು interactions ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಂಠಿತಗೊಳಿಸುತ್ತಿವೆ ಎಂದು ನಾವು ಊಹಿಸಿದ್ದೆವು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಮ್ಮ implementation ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೊರತುಪಡಿಸಿ hardware‌ನ ಯಾವುದೇ guarantees‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಲಿಲ್ಲ; ಇದರಿಂದ synchronization primitives‌ನ overhead ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ ನಾವು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಎಂಬ ಸೂಚನೆ ದೊರಕಿತು.

ಈ ಅವಲೋಕನಗಳ ನಂತರ, ಅದೇ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುವ ನಮ್ಮ EFA-ಆಧಾರಿತ ಕರ್ನಲ್‌ಗಳನ್ನು ನಾವು ರೂಪಿಸಿದ್ದೇವೆ, ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಹುಡ್ ಅಡಿಯಲ್ಲಿ ಸಾಧನ ಕರ್ನಲ್ - ಹೋಸ್ಟ್ ಪ್ರಾಕ್ಸಿ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಿದ್ದೇವೆ.

EFA ಮೇಲೆ MoE ಆಲ್-ಟು-ಆಲ್

ವಿಸ್ತರಿಸಿ

ಹೊಸ ಕರ್ನಲ್‌ಗಳು ಹೈಬ್ರಿಡ್ CPU-GPU ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಇಲ್ಲಿ GPU ಕರ್ನಲ್‌ಗಳು ಸಾಧನದಲ್ಲಿರುವ ಮಾದರಿಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಮತ್ತು ಹೋಸ್ಟ್ CPU ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಾಕ್ಸಿ ಥ್ರೆಡ್ NIC ನೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಹೊಸ ಕರ್ನಲ್‌ಗಳು ನಾವು KV ಕ್ಯಾಶ್ ವರ್ಗಾವಣೆಗಳಿಗಾಗಿ ನಿರ್ಮಿಸಿದ ಅದೇ TransferEngine ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತವೆ.

MoE ರೂಟಿಂಗ್ ಅನ್ನು ಡಿಸ್ಪ್ಯಾಚ್ ಕರ್ನಲ್ ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಮಾದರಿಯಿಂದ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ರೂಟ್ ಮಾಡಲು ಪ್ರತಿ-ಟೋಕನ್ ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ರ‍್ಯಾಂಕ್‌ಗಳಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಅವುಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಗುಂಪು ಮಾಡಲಾದ GEMM ಕರ್ನಲ್‌ಗಳು ಟೋಕನ್‌ಗಳನ್ನು ಎಕ್ಸ್‌ಪರ್ಟ್ ತೂಕಗಳೊಂದಿಗೆ ಗುಣಿಸಿದ ನಂತರ, ಕಂಬೈನ್ ಕರ್ನಲ್ ಟೋಕನ್‌ಗಳನ್ನು ಅವುಗಳ ಮೂಲ ರ‍್ಯಾಂಕ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ ಮತ್ತು ಮಾದರಿಗೆ ಹಿಂತಿರುಗಿಸುವ ಮೊದಲು ಅವುಗಳ ತೂಕದ ಸರಾಸರಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.

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

ಕರ್ನಲ್‌ಗಳು ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ದೃಢವಾಗಿ ಜೋಡಿಸಲ್ಪಟ್ಟಿವೆ, ಏಕೀಕೃತ ಮೆಮೊರಿ (unified memory) ಮತ್ತು GDRCopy ಎರಡರ ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. CUDA ಏಕೀಕೃತ ಮೆಮೊರಿಯು ಸಾಧನ ಮೆಮೊರಿ ಅಥವಾ ಹೋಸ್ಟ್ ಮೆಮೊರಿಯನ್ನು ಎರಡರ ವಿಳಾಸ ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, PCIe ಮೂಲಕ ಸಂವಹನವನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ.

ಏಕೀಕೃತ ಮೆಮೊರಿಯು ಬಲ್ಕ್ ವರ್ಗಾವಣೆಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದ್ದರೆ, ಕಡಿಮೆ ಸುಪ್ತತೆಯ ಪೋಲಿಂಗ್ ಅನ್ನು GDRCopy ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ. GDRCopy ಯು ಮೈಕ್ರೋಸೆಕೆಂಡ್ ಸುಪ್ತತೆಯಲ್ಲಿ GPU ಮೆಮೊರಿಯಿಂದ ಓದಲು ಮತ್ತು ಬರೆಯಲು GPUDirect RDMA ಅನ್ನು ಬಳಸುತ್ತದೆ.

RDMA ಜೊತೆಗೆ, ಒಂದು ನೋಡ್ ಒಳಗೆ ಕರ್ನಲ್‌ಗಳು ಟೋಕನ್‌ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು NVLink ಅನ್ನು ಸಹ ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ. ಇದು ಗಮನಾರ್ಹವಾದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಆಫ್‌ಲೋಡ್ ಮಾಡಬಹುದು, EP32 ಗೆ ಕಾಲು ಭಾಗದಷ್ಟು ಮತ್ತು EP64 ಗೆ ಎಂಟನೇ ಭಾಗದಷ್ಟು, ಒಟ್ಟಾರೆ ಕಡಿಮೆ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸಬಹುದು.

ಕಳುಹಿಸಿ ಮತ್ತು ಸ್ವೀಕರಿಸಿ ಬಫರ್‌ಗಳು

ಹೋಸ್ಟ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಒಳಗೊಂಡಿರುವ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸುವಲ್ಲಿ ಡಿಸ್ಪ್ಯಾಚ್ ಕರ್ನಲ್‌ಗಾಗಿ ಕಳುಹಿಸುವ ಬಫರ್‌ಗಳ ವಿನ್ಯಾಸವು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಪ್ರತಿ ರ‍್ಯಾಂಕ್ T ಟೋಕನ್‌ಗಳನ್ನು ಡಿಸ್ಪ್ಯಾಚ್ ಮಾಡುವ N ರ‍್ಯಾಂಕ್‌ಗಳಿದ್ದರೆ, ಪ್ರತಿಯೊಂದೂ E ರ ಹೊರಗೆ R ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳಿಗೆ ರೂಟ್ ಮಾಡಲ್ಪಟ್ಟಿದ್ದರೆ, ಎಲ್ಲವನ್ನೂ ಅದಕ್ಕೆ ರೂಟ್ ಮಾಡಿದರೆ, ಒಂದು ರ‍್ಯಾಂಕ್ ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ N * T * max(R, E / N) ಟೋಕನ್‌ಗಳವರೆಗೆ ಸ್ವೀಕರಿಸಬಹುದು. ಮೇಲಾಗಿ, ಕಳುಹಿಸುವವರು ತಮ್ಮ ಬರವಣಿಗೆಗಳನ್ನು ನಿರಂತರವಾಗಿ (contiguously) ಇರಿಸಿದಾಗ ಮಾತ್ರ ಈ ಕನಿಷ್ಠ ಮಿತಿಯನ್ನು ಸಾಧಿಸಬಹುದು, ಏಕೆಂದರೆ ಖಾಸಗಿ ಸ್ವೀಕರಿಸುವ ಬಫರ್‌ಗಳು ಹೆಚ್ಚು ಮೆಮೊರಿಯನ್ನು ಬಳಸುತ್ತವೆ. ಕಳುಹಿಸುವವರು ಯಾವುದೇ ಸಂಘರ್ಷಗಳಿಲ್ಲದೆ ತಮ್ಮ ಬರವಣಿಗೆಗಳನ್ನು ಸತತವಾಗಿ ಇರಿಸಲು ಸಾಧ್ಯವಾಗಲು, ರೂಟಿಂಗ್ ಮಾಹಿತಿಯ ಸಂಪೂರ್ಣ ಜ್ಞಾನವನ್ನು ಪ್ರತಿ ರ‍್ಯಾಂಕ್‌ಗೆ ವಿತರಿಸಬೇಕು. ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ಡಿಸ್ಪ್ಯಾಚ್ ಕರ್ನಲ್‌ಗಳು ಮೊದಲು ಪ್ರತಿ-ಎಕ್ಸ್‌ಪರ್ಟ್ ಟೋಕನ್ ಎಣಿಕೆಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ, ಅದರ ನಂತರ ಅವು ತಮ್ಮ ಬರವಣಿಗೆಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಯಾವ ಆಫ್‌ಸೆಟ್‌ನಿಂದ ಅವು ಪ್ರತಿ ರ‍್ಯಾಂಕ್‌ನಿಂದ ಟೋಕನ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು.

routing information ಅನ್ನು ಸರಳವಾಗಿ ವಿನಿಮಯ ಮಾಡಿದರೆ ಅನಗತ್ಯವಾಗಿ ಹೆಚ್ಚಿನ latencies ಉಂಟಾಗುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು rank ತನ್ನದೇ ಬರವಣಿಗೆಗಳನ್ನು dispatch ಮಾಡುವ ಮೊದಲು writes ಬಂದುವರೆಗೆ ಕಾಯಬೇಕಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಬದಲಾಗಿ, ನಾವು ಪ್ರತಿಯೊಂದು receiver rank ಮೇಲೆ sender ಪ್ರತಿ ಕೆಲವು private space ಅನ್ನು ಕಾಯ್ದಿರಿಸಿ, routing information‌ನ writes ಜೊತೆಗೆ ಕೆಲವು tokensಗಳನ್ನು ಕೂಡ dispatch ಮಾಡುತ್ತೇವೆ. ಇದರಿಂದ dispatch ಪ್ರಕ್ರಿಯೆಯ ಬಹುತೇಕ ಭಾಗದಲ್ಲಿ ಪೂರ್ಣ bandwidth utilization ಖಚಿತವಾಗುತ್ತದೆ. routes ವಿನಿಮಯವಾದ ನಂತರ, ಉಳಿದ tokensಗಳನ್ನು ಪ್ರತಿ remote peer‌ಗೆ ಒಂದೇ write ಮೂಲಕ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. routing information‌ನ exchange ಮತ್ತು ಸ್ಥಿರ-ಗಾತ್ರದ buffers, ಜೊತೆಗೆ ಅವುಗಳನ್ನು ತುಂಬುವ transfers, ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ.

ವಿಸ್ತರಿಸಿ

ಕಂಬೈನ್ ಕರ್ನಲ್‌ಗಳು ಗಣನೀಯವಾಗಿ ಸರಳವಾಗಿವೆ, ಏಕೆಂದರೆ ಡಿಸ್ಪ್ಯಾಚ್ ಹಂತದಿಂದ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯು ಈಗಾಗಲೇ ಅವರಿಗೆ ಲಭ್ಯವಿದೆ. ಅವರು ಪ್ರತಿ ಪೀರ್‌ಗೆ ಒಂದೇ ಬರವಣಿಗೆಯಲ್ಲಿ ಟೋಕನ್‌ಗಳನ್ನು ನಕಲಿಸಬಹುದು, ಅದರ ನಂತರ ಅವರು ಔಟ್‌ಪುಟ್ ಟೆನ್ಸೋರ್‌ಗಳಿಗೆ ಟೋಕನ್‌ಗಳ ತೂಕದ ಸರಾಸರಿಯನ್ನು ಲೆಕ್ಕಹಾಕಲು ಸ್ವೀಕರಿಸುವ ಬಫರ್‌ನಿಂದ ಓದುತ್ತಾರೆ.

NVLink ಗಾಗಿ, ಒಂದು ನೋಡ್ ಒಳಗೆ ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬಫರ್‌ಗಳನ್ನು ಪೀರ್‌ಗಳಲ್ಲಿ ಮ್ಯಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಇದರಿಂದ ಅವು ಹಕ್ಕಿಪಕ್ಕದ ರ‍್ಯಾಂಕ್‌ಗಳಿಂದ ನೇರವಾಗಿ ಟೋಕನ್‌ಗಳನ್ನು ಪುಶ್ ಮಾಡಲು ಅಥವಾ ಪುಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್

ಮಾಡೆಲ್‌ನ ಕರ್ನಲ್‌ಗಳೊಂದಿಗೆ ಇಂಟರ್ಲೀವ್ ಮಾಡಲಾದ ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್‌ನ ಒಂದು ಪುನರಾವರ್ತನೆಯನ್ನು ತೋರಿಸುತ್ತಾ, ಕೆಳಗಿನ ಚಿತ್ರಗಳು ಸಮಯ ಮತ್ತು GPU, CPU ಮತ್ತು NIC ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತವೆ.

ಕೆಲಸವು ಡಿಸ್ಪ್ಯಾಚ್ ಕಳುಹಿಸುವಿಕೆಯಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಕರ್ನಲ್ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಹಂಚಿದ ಮೆಮೊರಿಯಲ್ಲಿ ಅಟಾಮಿಕ್ ಅಕ್ಯುಮುಲೇಷನ್ ಮೂಲಕ ಪ್ರತಿ-ಎಕ್ಸ್‌ಪರ್ಟ್ ಟೋಕನ್ ಎಣಿಕೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತದೆ. ಟೋಕನ್ ಎಣಿಕೆಗಳು ಲಭ್ಯವಾದ ತಕ್ಷಣ, ಅವುಗಳನ್ನು ಹೋಸ್ಟ್ ಮೆಮೊರಿಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಇತರ ಪೀರ್ ರ‍್ಯಾಂಕ್‌ಗಳಿಗೆ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಾಕ್ಶಿಗೆ ತಕ್ಷಣವೇ ಸೂಚನೆ ನೀಡಲಾಗುತ್ತದೆ. ಸಮಾನಾಂತರವಾಗಿ, ಡಿಸ್ಪ್ಯಾಚ್ ಟೋಕನ್ ಎಣಿಕೆಗಳ ಸಂಚಿತ ಮೊತ್ತವನ್ನು ಲೆಕ್ಕಹಾಕುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತದೆ, ನಿರಂತರ ಪ್ರತಿ-ಪೀರ್ ಕಳುಹಿಸುವ ಬಫರ್‌ಗಳಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಪ್ಯಾಕ್ ಮಾಡಲು ಅಗತ್ಯವಾದ ಆಫ್‌ಸೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಆಫ್‌ಸೆಟ್‌ಗಳು ಲಭ್ಯವಾದ ತಕ್ಷಣ, EFA ಮೂಲಕ ಕಳುಹಿಸಬೇಕಾದ ಎಲ್ಲಾ ಟೋಕನ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಬಫರ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ. ಇಂಟರ್-ನೋಡ್ ಪೀರ್‌ಗಳ ಕಳುಹಿಸುವ ಬಫರ್‌ಗಳಲ್ಲಿ ಬರವಣಿಗೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಪ್ರಾಕ್ಶಿಗೆ ಸೂಚನೆ ನೀಡಲಾಗುತ್ತದೆ. ಇಂಟ್ರಾ-ನೋಡ್, ಕರ್ನಲ್‌ಗಳು NVLink ಮೂಲಕ ಅದೇ ನೋಡ್‌ನಲ್ಲಿರುವ ಖಾಸಗಿ ಬಫರ್‌ಗಳಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ತಕ್ಷಣವೇ ತಳ್ಳುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

ವಿಸ್ತರಿಸಿ

ಒಂದು ರ‍್ಯಾಂಕ್ ಎಲ್ಲಾ ಪೀರ್‌ಗಳಿಂದ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಅದು ಅದನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಮಾಡಲು ಟೋಕನ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಅಗತ್ಯವಿರುವ ವಿವಿಧ ಆಫ್‌ಸೆಟ್‌ಗಳನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತದೆ. ವರ್ಗಾವಣೆಗಳು ಈಗಾಗಲೇ ಬಾಕಿ ಇರುವಾಗ ಈ ಕೆಲಸವನ್ನು CPU ನಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಸುಪ್ತತೆ-ನಿರ್ಣಾಯಕವಲ್ಲ. ತರುವಾಯ, ಎಲ್ಲಾ ಆಫ್‌ಸೆಟ್‌ಗಳು ತಿಳಿದ ನಂತರ, ಖಾಸಗಿ ಬಫರ್ ಗಾತ್ರವನ್ನು ಮೀರುವ ಉಳಿದ ಟೋಕನ್‌ಗಳಿಗೆ ಬರವಣಿಗೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಪ್ಯಾಚ್‌ನ ಕಳುಹಿಸುವ ಹಂತವು ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.

receiver ಕಡೆ, kernel ಮೊದಲು private buffers‌ನ capacity ಮೀರಿರುವ ಅದೇ node‌ನಿಂದ tokensಗಳನ್ನು NVLink ಮೂಲಕ ಎಳೆಯುತ್ತದೆ. ನಂತರ, host proxy ಎಲ್ಲಾ transfersಗಳ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು signal ಮಾಡುವವರೆಗೆ ಅದು ಬ್ಲಾಕ್ ಆಗಿರುತ್ತದೆ. signal ಬಂದ ನಂತರ, tokensಗಳನ್ನು receive buffers‌ನಿಂದ group GEMM‌ಗೆ ಪಾಸ್ ಮಾಡಲಾದ output tensor‌ಗೆ shuffle ಮಾಡಲಾಗುತ್ತದೆ. dispatch ಮತ್ತು combine ನಡುವೆಯೇ buffers ಮರುಬಳಕೆಯಾಗಿರುವುದರಿಂದ, ಮುಂದಿನ kernel ಅವುಗಳ ಮೇಲೆ ಬರೆಯಲು ಅನುಮತಿಸುವ ಮೊದಲು receiver buffers ಓದಲ್ಪಟ್ಟಿವೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಲು NVLink ಮತ್ತು RDMA barriers ಎರಡೂ ಸಹ ಸಹಾಯ ಮಾಡುತ್ತವೆ.

ಕಂಬೈನ್ ಕರ್ನಲ್‌ಗಳು ಸ್ಥೂಲವಾಗಿ ಒಂದೇ ರೀತಿಯ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಟೋಕನ್‌ಗಳನ್ನು ಶಫಲ್ ಮಾಡುವುದು, ಪ್ರಾಕ್ಸಿಗೆ ಸಂಕೇತಿಸುವುದು ಮತ್ತು ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುವುದು. ಆದಾಗ್ಯೂ, ಅವುಗಳ ಬರವಣಿಗೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಮೆಟಾಡೇಟಾ ಸಿದ್ಧವಾಗಿ ಲಭ್ಯವಿದೆ ಮತ್ತು ಎಲ್ಲಾ ರಿಮೋಟ್ ಆಫ್‌ಸೆಟ್‌ಗಳು ತಿಳಿದಿವೆ, ಹೀಗಾಗಿ ಇಂಟ್ರಾ-ನೋಡ್ ವರ್ಗಾಯಿಸಲಾದ ಎಲ್ಲಾ ಟೋಕನ್‌ಗಳನ್ನು NVLink ಮೂಲಕ ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಇಂಟರ್-ನೋಡ್ ಟೋಕನ್‌ಗಳನ್ನು ಒಂದೇ ಬರವಣಿಗೆಯ ಮೂಲಕ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ ಮೊದಲು, ಕರ್ನಲ್ ಸ್ವೀಕರಿಸುವ ಬಫರ್‌ಗಳಿಂದ ಟೋಕನ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಔಟ್‌ಪುಟ್ ಟೆನ್ಸೋರ್‌ಗಳಿಗೆ ಬರೆಯುತ್ತದೆ.

MoE ರೂಟಿಂಗ್‌ಗಾಗಿ TransferEngine

ನಮ್ಮ ಅನುಷ್ಠಾನವನ್ನು ಮೂಲರೂಪ ಮಾಡಲು, RDMA ಬರವಣಿಗೆಗಳನ್ನು ನೀಡಲು ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಾವು ಆರಂಭದಲ್ಲಿ ಡಿಸ್ಅಗ್ರಿಗೇಟ್ ಪ್ರೀಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್‌ಗಾಗಿ ನಿರ್ಮಿಸಲಾದ Transfer Engine ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಡಿಸ್ಅಗ್ರಿಗೇಟೆಡ್ ಡಿಕೋಡಿಂಗ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಇಲ್ಲಿ ಪ್ರತಿ ನೋಡ್ ಒಂದೇ ಪೀರ್‌ಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬರವಣಿಗೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ, MoE ಡಿಸ್ಪ್ಯಾಚ್ ಎಲ್ಲಾ ಪೀರ್‌ಗಳಿಗೆ ಒಂದೇ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಸಣ್ಣ ವರ್ಗಾವಣೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ. ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ, ಕಾರ್ಯಕ್ಷಮತೆಯು ಅತ್ಯುತ್ತಮವಾಗಿರಲಿಲ್ಲ ಮತ್ತು ನಮ್ಮ ಅನುಷ್ಠಾನವು ConnectX-7 ನಲ್ಲಿ DeepEP ಗಿಂತ ಸುಮಾರು 20us ಹಿಂದೆ ಇತ್ತು. ಪರಿಣಾಮವಾಗಿ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪೀರ್‌ಗಳೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಸ್ಕ್ಯಾಟರ್ (scatter) ಮತ್ತು ಬ್ಯಾರಿಯರ್ (barrier) ಎಂಬ ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬೆಂಬಲಿಸಲು ನಾವು TransferEngine ಅನ್ನು ವಿಶೇಷಗೊಳಿಸಿದ್ದೇವೆ.

ಸ್ಕ್ಯಾಟರ್ ಮತ್ತು ಬ್ಯಾರಿಯರ್ ಎರಡೂ ಕಾರ್ಯಾಚರಣೆಗಳು ಪೀರ್ ಗುಂಪುಗಳನ್ನು ಬಹಿರಪಡಿಸುತ್ತವೆ, ಇವು ಆಧಾರವಾಗಿರುವ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅನುಷ್ಠಾನದಿಂದ ಬಳಸಲಾಗುವ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಪೂರ್ವ-ಜನಸಂಖ್ಯೆಗೊಳಿಸಲು ಪೂರ್ವ-ನೋಂದಾಯಿಸಲ್ಪಡಬಹುದು (Work Request (WR) ಟೆಂಪ್ಲೇಟಿಂಗ್). ಸ್ಕ್ಯಾಟರ್ ಅದೇ ಮೂಲ ಬಫರ್‌ನಿಂದ ವಿವಿಧ ಸ್ಲೈಸ್‌ಗಳನ್ನು ಪೀರ್ ಗುಂಪಿನ ಎಲ್ಲಾ ಸದಸ್ಯರ ಮೇಲೆ ವಿವಿಧ ಆಫ್‌ಸೆಟ್‌ಗಳಿಗೆ ನಕಲಿಸುತ್ತದೆ. ಬ್ಯಾರಿಯರ್ ತಕ್ಷಣದ ಮೂಲಕ ಎಲ್ಲಾ ಪೀರ್‌ಗಳಿಗೆ ಸಂಕೇತ ನೀಡುತ್ತದೆ. ಈ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಲ್ಕ್‌ನಲ್ಲಿ ಎನ್‌ಕ್ಯೂ ಮಾಡುವುದು ಮತ್ತು ನಿರ್ವಹಿಸುವುದು ಕ್ರಿಟಿಕಲ್ ಪಾತ್‌ನಲ್ಲಿ ಅಮೂಲ್ಯವಾದ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ಉಳಿಸುತ್ತದೆ. EFA ನಲ್ಲಿ, ಎರಡು 200Gbps NIC ಗಳು 400Gbps ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಒದಗಿಸಲು ಒಟ್ಟುಗೂಡಿಸುತ್ತವೆ, ಪ್ರತಿ ವರ್ಗಾವಣೆಯ ಬೈಟ್‌ಗಳನ್ನು ಶಾರ್ಡ್ ಮಾಡುವುದಕ್ಕಿಂತ ನಾವು ಎರಡು NIC ಗಳಾದ್ಯಂತ ಗ್ರೂಪ್ ಪೀರ್‌ಗಳನ್ನು ಶಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ.

ಆರಂಭದಲ್ಲಿ ನಾವು libfabric ಬಳಸಿ ಕೇವಲ EFA ನಲ್ಲಿ TransferEngine ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದರೂ, MoE ಕರ್ನಲ್‌ಗಳು libibverbs ಬಳಸಿ TransferEngine ನಲ್ಲಿ ConnectX-7 ಬೆಂಬಲವನ್ನು ಸೇರಿದ ನಂತರ ಒಂದೇ ಒಂದು ಸಾಲಿನ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸದೆ ConnectX-7 ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಸ್ಕೇಲೆಬಲ್ ರಿಲಯಬಲ್ ಡಾಟಾಗ್ರಾಮ್ (SRD) ಆಧಾರಿತ EFA ಗೆ ಹೋಲಿಸಿದರೆ, ConnectX-7 ಗೆ ಕನೆಕ್ಷನ್ ಸೆಟಪ್ ಮತ್ತು ಪೀರ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ಗಾಗಿ ಹೆಚ್ಚುವರಿ ಕೆಲಸದ ಅಗತ್ಯವಿದೆ. ರಿಲಯಬಲ್ ಕನೆಕ್ಷನ್ (RC) ಅನ್ನು ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮಾಡಲು ನಾವು ಅನ್‌ರಿಲಯಬಲ್ ಡಾಟಾಗ್ರಾಮ್ (UD) ಕ್ಯೂ ಜೋರಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಪ್ರತಿ ರಿಮೋಟ್ ಪೀರ್‌ಗೆ ಎರಡು ಕ್ಯೂ ಜೋರಿಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ, ಒಂದು ದ್ವಿಮುಖ SEND/RECV ಗಾಗಿ ಮತ್ತು ಒಂದು ಏಕಮುಖ WRITE_IMM ಗಾಗಿ, ಏಕೆಂದರೆ RECV ಮತ್ತು WRITE_IMM ಎರಡೂ ಕ್ರಮವಾಗಿ RECV ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಳಸುತ್ತವೆ ಆದರೆ ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ವಿಭಿನ್ನ ಬಫರ್ ಗಾತ್ರಗಳು ಬೇಕಾಗುತ್ತವೆ. ಇದಲ್ಲದೆ, ನಾವು ConnectX-7 ಮತ್ತು GPU ಮೆಮೊರಿ ನಡುವಿನ PCIe ವಹಿವಾಟು ಆದೇಶವನ್ನು ಸಡಿಲಗೊಳಿಸುತ್ತೇವೆ. EFA ನಂತೆ, ನಾವು WR ಟೆಂಪ್ಲೇಟಿಂಗ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದೇ ಪೀರ್‌ಗೆ ಅನೇಕ ಸಣ್ಣ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವಾಗ, ಸಂದೇಶ ದರವನ್ನು ಸುಧಾರಿಸಲು ನಾವು WR ಚೈನಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

GPU-ಸೈಡ್ ಕೆಲಸವು ಎರಡೂ ಅಡಾಪ್ಟರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರುವುದರಿಂದ, EFA ಮತ್ತು ConnectX-7 MoE ರೂಟಿಂಗ್ ನಡುವಿನ ಅಂತರವು ಆಧಾರವಾಗಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ಸಾಮರ್ಥ್ಯಗಳಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದನ್ನು ಹೈಲೈಟ್ ಮಾಡಲು DeepEP ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೀರಲು ನಾವು ಆಧಾರವಾಗಿರುವ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅನುಷ್ಠಾನವನ್ನು ಅದರ ಮಿತಿಗಳಿಗೆ ತಳ್ಳಿದ್ದೇವೆ.

ಮೌಲ್ಯಮಾಪನ

ಡಿಸ್ಪ್ಯಾಚ್/ಕಂಬೈನ್ ಸುಪ್ತತೆ

ಸ್ಟ್ಯಾಂಡರ್ಡ್ DeepSeek-V3 ಮತ್ತು Kimi-K2 ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ 7168 ರ ಹಿಡನ್ ಡೈಮೆನ್ಶನ್, ಬ್ಲಾಕ್-ಸ್ಕೇಲ್ಡ್ fp8 ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು bf16 ಕಂಬೈನ್‌ನೊಂದಿಗೆ ConnectX-7 ಮತ್ತು EFA ಅಡಾಪ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ H200 ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ನಾವು ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಸುಪ್ತತೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇವೆ. ನಾವು ಡಿಸ್ಪ್ಯಾಚ್‌ಗಾಗಿ 128 ಮತ್ತು ಕಂಬೈನ್‌ಗಾಗಿ 4096 ರ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ. ConnectX-7 ನಲ್ಲಿ, GPUDirect Async (IBGDA) ಮತ್ತು ಹೋಸ್ಟ್ ಪ್ರಾಕ್ಸಿ (IBRC) ಎರಡನ್ನೂ ಬಳಸಿ ನಾವು DeepEP ಮತ್ತು ನಮ್ಮ ಹಿಂದಿನ NVSHMEM-ಆಧಾರಿತ pplx-kernels ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತೇವೆ. ನಾವು EP16, EP32 ಮತ್ತು EP64 ನಲ್ಲಿ ಕ್ರಮವಾಗಿ 459us, 582us ಮತ್ತು 692us ಸಂಯೋಜಿತ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸುತ್ತೇವೆ. 519us, 966us ಮತ್ತು 1159us ಸಾಧಿಸುವ UCCL-EP ನಂತಹ ಜೆನೆರಿಕ್ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಇತರ EFA-ಆಧಾರಿತ ಕರ್ನಲ್‌ಗಳನ್ನು ನಾವು ಮೀರಿಸುತ್ತೇವೆ.

ವಿಸ್ತರಿಸಿ

ಡಿಕೋಡ್‌ನಲ್ಲಿ, ನಮ್ಮ ಕರ್ನಲ್‌ಗಳು DeepEP ಗಿಂತ ಕೆಲವು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು ನಿಧಾನವಾಗಿದ್ದರೂ, ನಮ್ಮ ಕಂಬೈನ್ ಕರ್ನಲ್‌ಗಳು ಗಣನೀಯವಾಗಿ ವೇಗವಾಗಿರುವುದರಿಂದ ನಾವು ಒಟ್ಟಾರೆ ಕಡಿಮೆ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸುತ್ತೇವೆ. ನಾವು ಹೋಸ್ಟ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸಿದರೂ, ನಮ್ಮ ಬಲ್ಕ್ ವರ್ಗಾವಣೆಗಳಿಂದಾಗಿ ನಾವು ಎಲ್ಲಾ IBGDA-ಆಧಾರಿತ ಪ್ರಾಕ್ಸಿಲೆಸ್ ಅನುಷ್ಠಾನಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೀರಿದ್ದೇವೆ. ನಮ್ಮ ಹೆಚ್ಚು ವಿಶೇಷವಾದ ಪ್ರಾಕ್ಸಿಯು ಜೆನೆರಿಕ್ NVSHMEM ಅನುಷ್ಠಾನಕ್ಕಿಂತ ಒಂದು ಕ್ರಮದಷ್ಟು ವೇಗವಾಗಿರುವುದರಿಂದ, ಪ್ರಾಕ್ಸಿ ಅನುಷ್ಠಾನವು ಮುಖ್ಯವಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ. MoE ರೂಟಿಂಗ್‌ನಿಂದ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ವಿಶಿಷ್ಟ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಕ್ಕೆ ಹತ್ತಿರವಿರುವ 256KB ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸುವಾಗ EFA ConnectX-7 ಗಿಂತ ಎರಡು ಪಟ್ಟು ನಿಧಾನವಾಗಿದ್ದರೂ, ಎರಡು ಅಡಾಪ್ಟರ್‌ಗಳ ನಡುವಿನ ಅಂತರವು ಒಟ್ಟಾರೆಯಾಗಿ ಕಡಿಮೆ ಗಣನೀಯವಾಗಿದೆ.

ವಿಸ್ತರಿಸಿ

ನಮ್ಮ decode-optimized kernels ಯಾವುದೇ ಹೆಚ್ಚುವರಿ tweaks‌ಗಳಿಲ್ಲದೆ prefill batch sizes‌ಗೆ scale ಆಗಬಹುದಾದರೂ, performance DeepEPಗಿಂತ ಹಿಂದಿದೆ. ಇದಕ್ಕೆ ಮುಖ್ಯ ಕಾರಣ combine‌ನ receiver side‌ನಲ್ಲಿ ಮಾತ್ರ ನಾವು tokensಗಳನ್ನು accumulate ಮಾಡುವುದು; DeepEP data ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಲು sender‌ನಲ್ಲಿ accumulate ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ optimization accuracy implications‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, kernels data ಅನ್ನು ಒಂದೇ write‌ನಲ್ಲಿ transfer ಮಾಡುವುದರಿಂದ, send ಮತ್ತು receive buffers‌ಗಾಗಿ ನಾವು ಹೆಚ್ಚು memory ಬಳಸುತ್ತೇವೆ.

Kimi-K2 / DeepSeek-V3 ಥ್ರೋಪುಟ್

ನಮ್ಮ kernelsಗಳ ಕಾರ್ಯಸಾಧ್ಯತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಲು, ನಾವು Elastic Fabric Adapters (EFA) ಮತ್ತು H200 GPUs ಹೊಂದಿರುವ ಹಲವು p5en instances‌ಗಳಲ್ಲಿ DeepSeek-V3 (671B parameters) ಮತ್ತು Kimi-K2 (1T parameters) ಅನ್ನು serve ಮಾಡುವ ನಮ್ಮ in-house inference engine‌ನ end-to-end performance ಅನ್ನು benchmark ಮಾಡುತ್ತೇವೆ. ನಾವು model ಅನ್ನು draft verification mode‌ನಲ್ಲಿ run ಮಾಡಿ, ಒಂದೇ MTP layer ಬಳಸಿ 80% acceptance rate ಊಹಿಸಿ latency ಅನ್ನು ವರದಿ ಮಾಡುತ್ತೇವೆ.

DeepSeek-V3 ನಲ್ಲಿ, ಸಮರ್ಥ NVLink-ಮಾತ್ರ ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಕರ್ನಲ್‌ಗಳನ್ನು ರನ್ ಮಾಡುವ EP=8 ಇಂಟ್ರಾನೋಡ್ ಬೇಸ್‌ಲೈನ್‌ ವಿರುದ್ಧ ನಾವು ಹೋಲಿಸುತ್ತೇವೆ. ಇಂಟರ್-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಒಟ್ಟಾರೆಯಾಗಿ ಏಕ-ನೋಡ್ ನಿಯೋಜನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡುತ್ತವೆ ಅಥವಾ ಮೀರುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಮಧ್ಯಮ ಗಾತ್ರದ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ, ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು ಒಟ್ಟಾರೆ ಥ್ರೋಪುಟ್‌ಗೆ ಸುಧಾರಣೆಗಳನ್ನು ತರುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

Kimi-K2 ನಲ್ಲಿ, ಕರ್ನಲ್‌ಗಳು ಸೇವೆ ಸಲ್ಲಿಸುವುದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ. ಅದರ ಗಾತ್ರದಿಂದಾಗಿ, ಮಾದರಿಯು H200 ನೋಡ್‌ನಲ್ಲಿ ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್ (DP) ಬಳಸಿ ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಾದರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಇಂಟರ್-ನೋಡ್ ನಿಯೋಜನೆ ಅಗತ್ಯವಿದೆ. ಮಾದರಿಯು ಕಡಿಮೆ ಗಮನದ ಮುಖ್ಯಸ್ಥರನ್ನು (attention heads) ಹೊಂದಿರುವುದರಿಂದ, ನಾವು DeepSeek-V3 ಗಿಂತ ಉತ್ತಮ ಸುಪ್ತತೆಗಳನ್ನು ಸಾಧಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಸುಪ್ತತೆಯಲ್ಲಿ EFA ನಲ್ಲಿ ಮಾದರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದು.

ವಿಸ್ತರಿಸಿ

ವಿಸ್ತರಿಸಿ

ನಾವು ಮೈಕ್ರೋ-ಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ಸಹ ಪರಿಗಣಿಸಿದ್ದೇವೆ, ಆದರೂ ಇದು ಬಹಳ ಹೆಚ್ಚಿನ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಲ್ಲಿ ಅಥವಾ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಡ್ರಾಫ್ಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸುವಾಗ ಮಾತ್ರ ಸುಪ್ತತೆಗಳನ್ನು ಸುಧಾರಿಸಿತು. ಗುಂಪು ಮಾಡಲಾದ GEMM ಸಮಸ್ಯೆಗಳನ್ನು ಎರಡಾಗಿ ವಿಭಜಿಸುವುದರಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯಲು, ಟೋಕನ್ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳು ಸಾಕಷ್ಟು ದಟ್ಟವಾಗಿರಬೇಕು. ಬಹುಪಾಲು ಸಮಯವನ್ನು ಇನ್ನೂ MoE ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್‌ನಲ್ಲಿ ಕಳೆಯಲಾಗುತ್ತದೆ, ಕರ್ನಲ್‌ಗಳಿಗೆ ಯಾವುದೇ ಹೆಚ್ಚಿನ ಸುಧಾರಣೆಗಳು ಪರಿಣಾಮವಾಗಿ ಸುಪ್ತತೆಗಳನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಮೈಕ್ರೋ-ಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಸೂಚಿಸುತ್ತದೆ.

ಭವಿಷ್ಯದ ಕೆಲಸ

EFA ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ನಾವು AWS ಇಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ನಿಕಟವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ನಮ್ಮ ಕಡೆಯಿಂದ, ಡೇಟಾ ಪ್ಲೇನ್ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವ libfabric ನ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ನಾವು ಅನುಸರಿಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬಳಕೆದಾರರ ಸ್ಥಳದ ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ಮತ್ತಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಇಂಟರ್‌ಫೇಸ್ ಮಾಡಲು ನಾವು efa-direct ನೊಂದಿಗೆ ಪ್ರಯೋಗಿಸುತ್ತೇವೆ.

ಉಲ್ಲೇಖಗಳು

DeepSeek R1 ತಾಂತ್ರಿಕ ವರದಿ

Kimi K2 ತಾಂತ್ರಿಕ ವರದಿ

DeepEP

UCCL-EP

NVIDIA Magnum IO NVSHMEM ಮತ್ತು GPUDirect Async ಬಳಸಿ HPC ಸಿಸ್ಟಮ್‌ಗಳ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವುದು

ಉಲ್ಲೇಖ

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}