ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ಪೋರ್ಟಬಲ್ ಮಿಕ್ಶ್ಚರ್-ಆಫ್-ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ ಸಂವಹನ

ಪ್ರಮಾಣಿತ ಆಲ್-ಟು-ಆಲ್ ಸಂವಹನ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ 10 ಪಟ್ಟು ವೇಗದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುವ, ಮಿಕ್ಶ್ಚರ್-ಆಫ್-ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ (MoE) ಸಂವಹನಕ್ಕಾಗಿ ನಾವು ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ, ಪೋರ್ಟಬಲ್, ಓಪನ್ ಸೋರ್ಸ್ ಲೈಬ್ರರಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ.

ನಮ್ಮ ಅನುಷ್ಠಾನವು ಉತ್ತಮ MoE ಸಂವಹನ ದಕ್ಷತೆಯನ್ನು ನೀಡುವ ಹಲವಾರು ಪ್ರಮುಖ ತಾಂತ್ರಿಕ ನಾವೀನ್ಯತೆಗಳನ್ನು ಹೊಂದಿದೆ:

GPU-ಪ್ರಾರಂಭಿಸಿದ ಸಂವಹನ (IBGDA): ನೇರ GPU-ನಿಂದ-NIC ಸಂವಹನವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, CPU ಒಳಗೊಳ್ಳುವಿಕೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ ವಿಳಂಬವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ

ಸಂವಹನ ಮತ್ತು ಲೆಕ್ಕಾಚಾರದ ಅತಿಕ್ರಮಣ: ಪ್ರತ್ಯೇಕ ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಹಂತಗಳೊಂದಿಗೆ ವಿಭಜಿತ ಕರ್ನಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ನೆಟ್‌ವರ್ಕ್ ವರ್ಗಾವಣೆಗಳೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಲೆಕ್ಕಾಚಾರ ಮುಂದುವರಿಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ

ಏಕ-ನೋಡ್ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಅತ್ಯಂತ ವೇಗವಾದುದು: ಹಿಂದಿನ ಅತ್ಯಂತ ವೇಗವಾದ ಏಕ-ನೋಡ್ ಜಾರಿಗೆ ಹೋಲಿಸಿದರೆ 2.5x ಕಡಿಮೆ ವಿಳಂಬ

ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ಪೋರ್ಟಬಲ್ ಮಲ್ಟಿ-ನೋಡ್ ಕಾರ್ಯಕ್ಷಮತೆ: ನಮ್ಮ ಅನುಷ್ಠಾನವು ಪ್ರಮಾಣಿತ ಆಲ್-ಟು-ಆಲ್ ಸಂವಹನಕ್ಕಿಂತ 10x ವೇಗದ ವೇಗವನ್ನು ಸಾಧಿಸುತ್ತದೆ. ಹೆಚ್ಚು ವಿಶೇಷವಾದ ಅನುಷ್ಠಾನಗಳಿಗಿಂತ ಸುಮಾರು 2x ನಿಧಾನವಾಗಿದ್ದರೂ, ನಮ್ಮ ವಿಧಾನವು NVSHMEM ಆವೃತ್ತಿಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಪರಿಸರಗಳಲ್ಲಿ (NVLink, CX-7, ಮತ್ತು EFA) ಉತ್ತಮ ಪೋರ್ಟಬಿಲಿಟಿಯನ್ನು ನೀಡುತ್ತದೆ

ಲೈಬ್ರರಿಯು ಸಂಪೂರ್ಣವಾಗಿ ಓಪನ್ ಸೋರ್ಸ್ ಆಗಿದೆ ಮತ್ತು https://github.com/ppl-ai/pplx-kernels ನಲ್ಲಿ ಲಭ್ಯವಿದೆ.

ಈ ಲೇಖನದಲ್ಲಿ, ನಾವು ದೊಡ್ಡ ಪ್ರಮಾಣದ MoE ಮಾದರಿಗಳಲ್ಲಿನ expert parallelism‌ನ ಸವಾಲುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ವಿತರಿತ GPU ಪರಿಸರಗಳಲ್ಲಿ ದಕ್ಷ token dispatch ಹಾಗೂ combination ಗಾಗಿ ನಮ್ಮ ವಿಧಾನವನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

ಪರಿಚಯ

DeepSeek R1 ಮತ್ತು Mixtral 8x7B ನಂತಹ ಮಿಕ್ಶ್ಚರ್-ಆಫ್-ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ (MoE) ಮಾದರಿಗಳು, ಪ್ರತಿ ಟೋಕನ್‌ಗೆ ಸಕ್ರಿಯಗೊಳಿಸಲಾದ ತೂಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ದಟ್ಟವಾದ ಮಾದರಿಗಳನ್ನು ಸುಧಾರಿಸುತ್ತವೆ. ಪ್ರತಿ ಡಿಕೋಡರ್ ಲೇಯರ್‌ನ ಮಲ್ಟಿ-ಲೇಯರ್ ಪರ್ಸೆಪ್ಟ್ರಾನ್ (MLP) ನಲ್ಲಿ ಲೇಯರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದರ ಮೂಲಕ ಅಥವಾ ರೇಖೀಯ ಲೇಯರ್‌ಗಳ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಹೆಚ್ಚಿನ ನಿಯತಾಂಕ ಎಣಿಕೆಗಳನ್ನು ಸಾಧಿಸುವ ಬದಲು, MoE ಮಾದರಿಗಳು ಸಾಂಪ್ರದಾಯಿಕ MLP ಅನ್ನು ಬಹು ತಜ್ಞರು ಮತ್ತು ರೂಟರ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, DeepSeek R1 ನ 671B ನಿಯತಾಂಕಗಳಲ್ಲಿ, ಅನುಮಾನದ ಸಮಯದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಟೋಕನ್‌ನೊಂದಿಗೆ ಕೇವಲ 37B ಗುಣಿಸಲ್ಪಡುತ್ತವೆ. ಇದು ಟೋಕನ್ ಅನ್ನು ಡಿಕೋಡ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಲೆಕ್ಕಾಚಾರದ ಪ್ರಮಾಣವನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ದಟ್ಟವಾದ ಮಾದರಿಗೆ ಹೋಲಿಸಿದರೆ ವಿಳಂಬವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ದಟ್ಟವಾದ ಮಾದರಿಗಳಿಗೆ ಹೋಲಿಸಿದರೆ MoE ಮಾದರಿಗಳು ಅನುಮಾನಕ್ಕಾಗಿ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸವಾಲುಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತವೆ. ತಜ್ಞರೇ ಸಣ್ಣ MLP ಲೇಯರ್‌ಗಳಾಗಿದ್ದರೂ, ಪ್ರತಿ ಡಿಕೋಡರ್ ಲೇಯರ್ ರೂಟರ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಅದು ಟೋಕನ್ ಅನ್ನು ಯಾವ ತಜ್ಞರಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಪ್ರತಿ ಟೋಕನ್ ಅನ್ನು ಬಹು ತಜ್ಞರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ರೂಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವನೀಯತೆಯ ವಿತರಣೆಯನ್ನು ಉತ್ಪಾದಿಸುವ ಸಣ್ಣ ರೇಖೀಯ ಲೇಯರ್ ಆಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಟಾಪ್-ಕೆ ಅಂಕಗಳನ್ನು ಹೊಂದಿರುವ ತಜ್ಞರನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯನ್ನು ತಜ್ಞರ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ರೂಟರ್‌ನ ಸಂಭವನೀಯತೆ ವಿತರಣೆಯಿಂದ ಪಡೆದ ತೂಕದಿಂದ ಗುಣಿಸಿ ಒಟ್ಟುಗೂಡಿಸುವ ಮೂಲಕ ತೂಕದ ಸರಾಸರಿಯಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.

ವಿತರಿಸಲಾದ MoE ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಬಹು ಸಾಧನಗಳಲ್ಲಿ ಸಮಾಂತರತೆಯನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಇದು ಸಂವಹನ ಸವಾಲುಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. Mixtral 8x7B ಅಥವಾ Llama-70B ನಂತಹ ಮಾದರಿಗಳು ಒಂದೇ ನೋಡ್‌ನಾದ್ಯಂತ 8 ಸಾಧನಗಳಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ, ವೇಗದ ಮತ್ತು ಕಡಿಮೆ-ವಿಳಂಬದ NVLink ಇಂಟರ್‌ಕನೆಕ್ಷನ್‌ಗಳಿಂದ (900Gbps ವರೆಗೆ) ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತವೆ. ಆದಾಗ್ಯೂ, ದೊಡ್ಡ ಮಾದರಿಗಳಿಗೆ ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಬಳಸಿ ಬಹು ನೋಡ್‌ಗಳಲ್ಲಿ ತಜ್ಞರನ್ನು ಶಾರ್ಡ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ (400Gbps ನಲ್ಲಿ ಗರಿಷ್ಠ), ಇದು ಹೆಚ್ಚುವರಿ ವಿಳಂಬ ಸವಾಲುಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಈ ಲೇಖನದಲ್ಲಿ, ತಜ್ಞರ ಸಮಾಂತರತೆಯ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ, ನಿಯೋಜಿಸಲಾದ ತಜ್ಞರನ್ನು ಹೊಂದಿರುವ ಸಾಧನಗಳಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ರವಾನಿಸುವ ಮತ್ತು ತಜ್ಞರ ಔಟ್‌ಪುಟ್‌ಗಳ ತೂಕದ ಮೊತ್ತವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಮರಳಿ ಸಂಗ್ರಹಿಸುವ GPU ಕರ್ನಲ್‌ಗಳ ನಮ್ಮ ಅನುಷ್ಠಾನವನ್ನು ವಿವರಿಸುತ್ತೇವೆ. ನಿರ್ದಿಷ್ಟ ನೆಟ್‌ವರ್ಕ್ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಗುರಿಯಾಗಿಟ್ಟುಕೊಂಡು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಅನುಷ್ಠಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವಾಗ, ನಾವು NVSHMEM ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಕನಿಷ್ಠ ಗುಂಪನ್ನು ಅವಲಂಬಿಸಿರುವ ಆದರೆ ಪ್ರಮಾಣಿತ ಆಲ್-ಟು-ಆಲ್ ಸಂವಹನಕ್ಕಿಂತ 10x ವೇಗದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತಲುಪಿಸುವ ಹೆಚ್ಚು ಪೋರ್ಟಬಲ್ ಅನುಷ್ಠಾನವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ. ನಮ್ಮ ಅನುಷ್ಠಾನವು ವಿವಿಧ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸರಗಳಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಪೋರ್ಟಬಿಲಿಟಿಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವಾಗ ಸಿಂಗಲ್-ನೋಡ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಅತ್ಯಾಧುನಿಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುತ್ತದೆ.

ಶಾರ್ಡಿಂಗ್ ಮತ್ತು ಸಮಾಂತರತೆ

ಸಮರ್ಥ ಅನುಮಾನಕ್ಕಾಗಿ, ಮಾದರಿಯ ತೂಕಗಳನ್ನು ಸಾಧನ ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸಬೇಕು, ಜೊತೆಗೆ ಮಾದರಿಯ ಮೂಲಕ ಮುಂದಿನ ಪಾಸ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳು, KV ಕ್ಯಾಶ್‌ಗಳು ಮತ್ತು ಇತರ ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಸಾಕಷ್ಟು ಸ್ಥಳವನ್ನು ಬಿಡಬೇಕು. ಅತ್ಯಂತ ಸಮರ್ಥ ಮಾದರಿಗಳು ಅತ್ಯಂತ ಸಮರ್ಥ GPU ಗಳ ಸಾಮರ್ಥ್ಯವನ್ನು ಮೀರಿವೆ, ಆದ್ದರಿಂದ ಮಾದರಿಯ ತೂಕವನ್ನು ಸಾಮೂಹಿಕವಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದಾದ ಬಹು ಸಾಧನಗಳಲ್ಲಿ ಅನುಮಾನವನ್ನು ಹರಡಬೇಕು. ತೂಕದ ಶಾರ್ಡಿಂಗ್ ಯೋಜನೆಗಳ ಆಧಾರದ ಮೇಲೆ, ಲೆಕ್ಕಾಚಾರವನ್ನು ಆಫ್‌ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಸಾಧನಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ವಿವಿಧ ಸಂವಹನ ಮತ್ತು ಲೆಕ್ಕಾಚಾರದ ಯೋಜನೆಗಳನ್ನು ಬಳಸಬೇಕು.

ವಿಸ್ತರಿಸಿ

Expert Parallelism (EP), ಮೊದಲ ಆಕೃತಿಯಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ, ಕೇವಲ expert computation ಅನ್ನು parallelize ಮಾಡುತ್ತದೆ. ವಿಭಿನ್ನ experts‌ಗಳನ್ನು ವಿಭಿನ್ನ devices‌ಗೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅವು ತಮ್ಮ weights ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ. routing ನಂತರ, tokens‌ಗಳನ್ನು ಸಂಬಂಧಿತ device‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ accumulate ಮಾಡಲಾಗುತ್ತದೆ. routing‌ನ ಸಂಕೀರ್ಣತೆ ಮಾದರಿಯ ಇತರ ಭಾಗಗಳಲ್ಲಿನ parallelism‌ನ ಮಟ್ಟದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ: ಇತರ layers ಅನ್ನು replicate ಮಾಡಿದರೆ routing‌ನ ಅಗತ್ಯವೇ ಸಂಪೂರ್ಣವಾಗಿ ಇಲ್ಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ಪ್ರತಿ rank ಸ್ಥಳೀಯವಾಗಿ replicate ಮಾಡಲಾದ routing table‌ನಿಂದ tokens‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಆದರೆ, ಒಂದೇ rank ಮಾತ್ರ routing ನಡೆಸಿದರೆ, tokens, indices ಮತ್ತು weights ಅನ್ನು ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ experts‌ಗೆ dispatch ಮಾಡಲು broadcast ಅಗತ್ಯವಾಗುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, all-gather ಅಥವಾ all-to-all broadcast ಮಾದರಿಯ execution ಅನ್ನು ಮುಂದುವರಿಸುವ ಯಾವುದೇ rank‌ನೊಂದಿಗೆ output tokens‌ಗಳನ್ನು synchronize ಮಾಡುತ್ತದೆ. ಇಂತಹ implementation ತುಸು ಸರಳವಾಗಿದೆ, ಏಕೆಂದರೆ torch ಈಗಾಗಲೇ ಅಗತ್ಯ primitives ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ experts‌ನಿಂದ tokens‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ gather operation‌ನೊಂದಿಗೆ accumulation ಅನ್ನು fuse ಮಾಡುವ ಮೂಲಕ ಕೆಲವು ಲಾಭಗಳನ್ನು ಪಡೆಯಬಹುದು.

ವಿಸ್ತರಿಸಿ

ಮಾದರಿಯು ಗಮನ, ರೂಮ್ ಮತ್ತು ಸ್ಯಾಂಪ್ಲಿಂಗ್‌ನಂತಹ ತಜ್ಞರಲ್ಲದ ಲೇಯರ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತಿರುವಾಗ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನೋಡ್‌ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ ಎಕ್ಸ್‌ಪರ್ಟ್-ಮಾತ್ರ ಸಮಾಂತರತೆಯು ಆದರ್ಶವಾಗಿ ಅಳೆಯುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಈ ಲೇಯರ್‌ಗಳ ಲೆಕ್ಕಾಚಾರವು, ಪ್ರಾಥಮಿಕವಾಗಿ ಗಮನ, ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್ (TP) ನಿಂದಲೂ ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು. ಹೆಚ್ಚಿನ ಮಾದರಿಗಳು ಮಲ್ಟಿ-ಹೆಡ್ ಗಮನವನ್ನು ಅವಲಂಬಿಸಿವೆ, ಅಂದರೆ ಗಮನದ ಮುಖ್ಯಸ್ಥರು ಮತ್ತು ಅವುಗಳ ಅನುಗುಣವಾದ Q, K ಮತ್ತು V ಪ್ರೊಜೆಕ್ಷನ್‌ಗಳನ್ನು ಸಹ ಸಾಧನಗಳಲ್ಲಿ ಶಾರ್ಡ್ ಮಾಡಬಹುದು, ವಿಭಿನ್ನ ಲೇಯರ್‌ಗಳ ನಡುವೆ ತುಂಡುಗಳನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು ಅಥವಾ ಸಂಗ್ರಹಿಸಬಹುದು. ಗಮನವು ಎಲ್ಲಾ ಸಾಧನಗಳಲ್ಲಿ ಹರಡಿಕೊಂಡಿದ್ದರೆ, ಆಲ್-ಗ್ಯಾದರ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬಹುದು, ರೂಟಿಂಗ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಪರಿಣಾಮಕಾರಿ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ತಜ್ಞರ ಸಮಾಂತರತೆಯ ಪ್ರಕರಣಕ್ಕೆ ಹೋಲುವ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪ್ರಿಮಿಟಿವ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಈ ಮಟ್ಟದಲ್ಲಿ ಸಮಾಂತರತೆಗೆ ಮಿತಿಗಳಿವೆ, ಏಕೆಂದರೆ ಗಮನದ ಮುಖ್ಯಸ್ಥರ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಿಂತ ಕಡಿಮೆಗೊಳಿಸುವುದರಿಂದ ಕಡಿಮೆಯಾಗುವ ಆದಾಯವನ್ನು ನೀಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಎಲ್ಲಾ devices‌ಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಬಳಸಿ, 128 ಅಥವಾ 256 GPUs‌ಗಳವರೆಗೆ ಇರುವ ಅತ್ಯಧಿಕ ಮಟ್ಟದ expert parallelism ಅನ್ನು ಬೆಂಬಲಿಸಲು, Data Parallelism (DP) ಅಗತ್ಯವಿದೆ. ಈ ಯೋಜನೆಯಲ್ಲಿ, ಒಂದು model ಅನ್ನು ವಿಭಾಗಿಸಿರುವ devices‌ಗಳನ್ನು requests‌ಗಳನ್ನು concurrently ನಿರ್ವಹಿಸಲು ಗುಂಪು ಮಾಡಲಾಗುತ್ತದೆ, attention ಅನ್ನು ಗಣನೆ ಮಾಡುತ್ತಾ ಮತ್ತು ಅವರ local group‌ನಾದ್ಯಂತ sharded ಆಗಿರುವ KV caches ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಾ. ಈ parallel groups‌ನ ಹಲವು instances‌ಗಳು expert evaluation‌ನಲ್ಲಿ ಸಹಕರಿಸುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ expert weights‌ನ ವಿಭಿನ್ನ ಉಪಸಮೂಹವನ್ನು ಹೊಂದಿರುತ್ತದೆ. attention heads‌ಗಳ ಸಂಖ್ಯೆಯ ಆಧಾರದ ಮೇಲೆ, inter-node communication ವೇಗವಾಗಿರುವುದರಿಂದ, ಒಂದು group ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪೂರ್ಣ node‌ನ ಗಾತ್ರದವರೆಗೆ ವಿಸ್ತರಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಮೇಲಿನ ಆಕೃತಿಯಲ್ಲಿ, ಒಂದು DP rank ಸ್ವತಂತ್ರವಾಗಿ ಎರಡು requests, A ಮತ್ತು B, ಅನ್ನು ಸೇವಿಸಿ, ಅವುಗಳಿಗಾಗಿ attention, norm ಮತ್ತು ಇತರ ಯಾವುದೇ bookkeeping ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇನ್ನೊಂದು DP rank ವಿಭಿನ್ನ request C ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಆದರೆ, ಮೊದಲ node ಅರ್ಧ experts‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತೊಂದು node ಉಳಿದ ಅರ್ಧವನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ A ಮತ್ತು B ಯಿಂದ tokens‌ಗಳನ್ನು routing ನಂತರ ಎರಡನೇ node‌ಗೆ ಕಳುಹಿಸಬಹುದಾಗಿದೆ ಮತ್ತು vice-versa. ಇದು sparse communication problem‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ: ಪ್ರತಿ device ಯಾವುದೇ ಇತರ destination rank‌ಗೆ ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ tokens ಕಳುಹಿಸಬಹುದು. torch‌ನ ಈಗಿರುವ primitives, ಮುಖ್ಯವಾಗಿ all_to_all, ಇಂಥ ಸಂದರ್ಭದಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಸೂಕ್ತವಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳಿಗೆ padding ಅಥವಾ GPU-to-CPU synchronization ಹಾಗೂ metadata broadcast‌ನ ಯಾವುದೋ ರೂಪ ಅಗತ್ಯವಾಗಬಹುದು. communication ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲು, routing ಮಾಹಿತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ CPU ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ devices‌ನಿಂದಲೇ communication ಆರಂಭಿಸಲು custom kernels ಅಗತ್ಯವಿದೆ. routing ನಂತರ, dispatch kernel tokens‌ಗಳನ್ನು ಅವು routing ಆಗಿರುವ ranks‌ಗೆ ಕಳುಹಿಸಬೇಕು, ಮತ್ತು combine side‌ನಲ್ಲಿ current DP group‌ನ requests‌ಗಳಿಗೆ ಸೇರಿದ activations ಅನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮುಂದಿನ layers‌ಗಾಗಿ broadcast ಅನ್ನು ಕನಿಷ್ಠಗೊಳಿಸಿ ಎಲ್ಲಾ ranks‌ಗಳ ಮೇಲೆ tokens‌ಗಳನ್ನು ಸರಿಯಾಗಿ replicate ಮಾಡಲು, ಬಹು devices‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದಾದ DP group‌ನೊಳಗೆ work ಅನ್ನು balance ಮಾಡಬೇಕು.

NVSHMEM

NVSHMEM ಎನ್ನುವುದು NVIDIA-ನಿರ್ದಿಷ್ಟ OpenSHMEM ಅನುಷ್ಠಾನವಾಗಿದೆ, ಇದು ಆಧಾರವಾಗಿರುವ ಹಾರ್ಡ್‌ವೇರ್‌ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಅಮೂರ್ತಗೊಳಿಸುವ ಪೋರ್ಟಬಲ್ ಸಾಧನ-ನಡುವಿನ ಸಂವಹನ ಸೌಲಭ್ಯಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. API ಸಾಧನದಿಂದ ಸಾಧನಕ್ಕೆ ಓದುವಿಕೆ ಮತ್ತು ಬರೆಯುವಿಕೆಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಹುದು, ಇವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸಾರಿಗೆ ಲೇಯರ್‌ಗಳ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ. NVLink ಮತ್ತು RDMA ಎರಡನ್ನೂ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ, ಇದು ಪೋರ್ಟಬಿಲಿಟಿಯ ಮಟ್ಟವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು NVSHMEM ಕರ್ನಲ್‌ಗಳಿಗೆ ನೋಡ್ ಒಳಗೆ ಅಥವಾ ಬಹು ನೋಡ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ನಮ್ಮ ಕರ್ನಲ್‌ಗಳಲ್ಲಿ, ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಮತ್ತು ಭಾಗವಹಿಸುವ ಸಾಧನಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ನಾವು ದೂರಸ್ಥ ಮೆಮೊರಿ ಬರೆಯುವಿಕೆಗಳು ಮತ್ತು ಸಿಗ್ನಲಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.

NVSHMEM operations symmetric memory ಎಂಬ ಕಲ್ಪನೆಯ ಸುತ್ತ ನಿರ್ಮಿತವಾಗಿವೆ: ಅವು inter-device communication‌ನಲ್ಲಿ ಪಾಲ್ಗೊಳ್ಳುವ ಎಲ್ಲಾ devices‌ಗಳ ಮೇಲೆ allocate ಮಾಡಲಾದ buffers‌ಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಒಂದು local device ತನ್ನ own local buffer‌ನೊಳಗೆ ಹೊಂದಿದ address ಜೊತೆಗೆ target rank‌ನ index ಅನ್ನು ಬಳಸಿ ಕಾರ್ಯಾಚರಣೆಯ destination ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಕೆಳಗಿನ ಆಕೃತಿ ಈ ಕಲ್ಪನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ: ಎರಡೂ GPUs ಒಂದೇ ಗಾತ್ರದ symmetric buffers ಅನ್ನು allocate ಮಾಡುತ್ತವೆ, ಅವುಗಳಿಗೆ src pointers ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಮೊದಲ rank ಎರಡನೇ rank‌ಗೆ 3 integers ಕಳುಹಿಸಲು ಬಯಸುತ್ತದೆ, ಅವುಗಳನ್ನು buffer‌ನ ಆರಂಭದಲ್ಲಿ ಇಡುತ್ತದೆ: nvshmem_int_put_nbi local buffer‌ನಿಂದ start address ಅನ್ನು ಪಡೆಯುತ್ತದೆ, target device ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. ಎರಡನೇ rank ತನ್ನ own buffer‌ನಿಂದ offset ಅನ್ನು ಪಡೆಯುತ್ತದೆ, ಒಂದೇ element ಅನ್ನು ಮೊದಲ device‌ಗೆ ಕಳುಹಿಸಿ, ಒಂದರಿಂದ offset ಮಾಡುತ್ತದೆ. destination addresses ಯಾವಾಗಲೂ nvshmem_alloc ಬಳಸಿ allocate ಮಾಡಲಾದ symmetric buffers ಆಗಿರಬೇಕು, ಆದರೆ source buffers NVSHMEM‌ನೊಂದಿಗೆ ಪೂರ್ವ-ನೋಂದಾಯಿತವಾಗಿದ್ದರೆ, ಯಾವುದೇ device memory ಪ್ರದೇಶಗಳಾಗಿರಬಹುದು.

NVSHMEM ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆಯಾದರೂ, ನಮ್ಮ ಕರ್ನಲ್‌ಗಳು ಕೇವಲ 3 ಕಾರ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ, ಅವುಗಳ ಮೇಲೆ ಎಲ್ಲಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಫೆನ್ಸಿಂಗ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

nvshmemx_putmem_signal_nbi_warp: ರಿಮೋಟ್ ಸಾಧನದಲ್ಲಿ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸುವಾಗ, ಡೇಟಾದ ಬ್ಲಾಕ್ ಅನ್ನು ಒಂದು ಸಾಧನದಿಂದ ಮತ್ತೊಂದಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಕಾರ್ಯಾಚರಣೆಯು 64-ಬಿಟ್ ಸ್ಥಳವನ್ನು ಹೊಂದಿಸುತ್ತದೆ (NVSHMEM_SIGNAL_SET) ಅಥವಾ ಹೆಚ್ಚಿಸುತ್ತದೆ (NVSHMEM_SIGNAL_ADD). ಸಂಪೂರ್ಣ ಮೆಮೊರಿ ಬ್ಲಾಕ್ ವರ್ಗಾವಣೆಗೊಂಡ ನಂತರ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ರಿಮೋಟ್ ಸಾಧನವು ಫ್ಲ್ಯಾಗ್‌ನಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನು ಗಮನಿಸಿದರೆ, ಅದು ತನ್ನದೇ ಆದ ಮೆಮೊರಿಯಲ್ಲಿ ಬಫರ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು. ಈ ಕಾರ್ಯವು ಡೇಟಾ ವರ್ಗಾವಣೆ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು ಉಪಯುಕ್ತವಾಗಿದೆ.

nvshmemx_signal_op ಏಕ ಮೆಮೊರಿ ಸ್ಥಳದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 64-ಬಿಟ್ ಫ್ಲ್ಯಾಗ್, ಅದನ್ನು ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ಹೊಂದಿಸುತ್ತದೆ ಅಥವಾ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮೆಟಾಡೇಟಾವನ್ನು ಕಳುಹಿಸುವಲ್ಲಿ ಮತ್ತು ಸಾಧನಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದರಲ್ಲಿ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ.

nvshmem_uint64_wait_until ಅನ್ನು ಸಿಗ್ನಲ್ ಸ್ವೀಕರಿಸುವ ಕೊನೆಯಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ರಿಮೋಟ್ ಅದನ್ನು ನವೀಕರಿಸುವವರೆಗೆ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪೋಲ್ ಮಾಡಲು.

nvshmem_quiet ಅಥವಾ nvshmem_fence ಮೂಲಕ ಕಾರ್ಯಾಚರಣೆಗಳ ನಡುವಿನ ಯಾವುದೇ ರೀತಿಯ ಆದೇಶವನ್ನು ಖಚಿತಪಡಿಸುವುದು ದುಬಾರಿಯಾಗಿದೆ, ಆದ್ದರಿಂದ ನಮ್ಮ ಕರ್ನಲ್‌ಗಳ ಅನುಷ್ಠಾನವು ಯಾವುದೇ ಇತರ NVSHMEM ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಬಳಕೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಕಳುಹಿಸುವ-ಸ್ವೀಕರಿಸುವ ಜೋಡಿಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಅವಲಂಬನೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವಾಗ, ಸ್ಥಳೀಯ ಶ್ರೇಣಿಯಿಂದ ಡೇಟಾವನ್ನು ಹೊರಗೆ ಕಳುಹಿಸಲು ಕಾಯದೆ, ನಾವು ಯಾವಾಗಲೂ ಕಾರ್ಯಗಳ ನಾನ್-ಬ್ಲಾಕಿಂಗ್ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಕರ್ನಲ್‌ಗಳ ಗುಂಪಿನಾದ್ಯಂತ ಇತರ, ಸೂಚ್ಯವಲ್ಲದ ಸಿಂಕ್ರೊನೈಸೇಶನ್ NIC ಗಳಿಗೆ ಅವುಗಳಿಗೆ ಪ್ರವೇಶ ಬೇಕಾದಾಗ ಈ ಬಫರ್‌ಗಳನ್ನು ವಿನಾಶಕಾರಿಯಾಗಿ ಓವರ್‌ರೈಟ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

NVSHMEM GPUDirect RDMA ಅನ್ನು ಬಳಸುತ್ತದೆ ಇದರಿಂದ NIC CPU ಗಳನ್ನು involucrar ಮಾಡದೆ ಡೇಟಾ ವಿನಿಮಯಕ್ಕಾಗಿ ನೇರವಾಗಿ GPU ಮೆಮೊರಿಯನ್ನು ಓದಬಹುದು ಮತ್ತು ಬರೆಯಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ConnectX NIC ಗಳಲ್ಲಿ, NVSHEMEM GPU-ಪ್ರಾರಂಭಿಸಿದ ಸಂವಹನವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ (ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ GPUDirect Async ಅಥವಾ IBGDA ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ), ಇದು GPU ಗೆ ನೇರವಾಗಿ NIC ಗೆ RDMA ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಮತ್ತು ನೇರವಾಗಿ NIC ಯ ಪೂರ್ಣಗೊಳ್ಳುವ ಸರತಿಯನ್ನು ಪೋಲ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. GPU-ಪ್ರಾರಂಭಿಸಿದ ಸಂವಹನವನ್ನು ಬೆಂಬಲಿಸದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ, NVSHMEM ಸಂವಹನವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು GPU ಪರವಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವಿಕೆಯನ್ನು ಪೋಲ್ ಮಾಡಲು ಹೋಸ್ಟ್ CPU ನಲ್ಲಿ “ಪ್ರಕ್ಸಿ” ಥ್ರೆಡ್ ಅನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ. GPU-ಪ್ರಾರಂಭಿಸಿದ ಸಂವಹನವನ್ನು ಬೆಂಬಲಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದರ მიუხედავად NVSHMEM ಪ್ರೋಗ್ರಾಂ ಪೋರ್ಟಬಲ್ ಆಗಿದೆ. ಆದಾಗ್ಯೂ, GPU-ಪ್ರಾರಂಭಿಸಿದ ಸಂವಹನವು CPU ಗೆ ತಿರುಗಿಸುವಿಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುವುದರಿಂದ ವಿಳಂಬವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಪೋರ್ಟಬಲ್ ಕರ್ನಲ್‌ಗಳು

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

ಪ್ರತಿಯೊಂದು kernel pair ತನ್ನದೇ symmetric memory buffers ಅನ್ನು ಹೊಂದಿದೆ, ಪ್ರತಿ rank ಇತರ ಎಲ್ಲಾ ranks‌ಗಳಿಂದ data ಸ್ವೀಕರಿಸಲು private storage ಅನ್ನು allocate ಮಾಡುತ್ತದೆ. DP group‌ನಿಂದ dispatch ಮಾಡಬಹುದಾದ tokens‌ನ ಗರಿಷ್ಠ ಸಂಖ್ಯೆ ranks across fixed ಆಗಿರುತ್ತದೆ, ಇದು ಪ್ರತಿ local expert‌ಗೆ ಪ್ರತಿ DP rank‌ನಿಂದ ಎಷ್ಟು ಸ್ವೀಕರಿಸಬಹುದು ಎಂಬ ಮೇಲಿನ ಮಿತಿಯನ್ನೂ ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಇದು sender ranks‌ಗಳಿಗೆ ಯಾವುದೇ synchronization ಅಗತ್ಯವಿಲ್ಲದೆ, destination rank‌ನ ಮೇಲೆ ಬರೆಯಲು ಅನನ್ಯ address ಅನ್ನು ಪಡೆಯಲು ಅನುಮತಿಸುತ್ತದೆ. data ಸ್ವೀಕರಿಸಿದ ನಂತರ, kernels tokens‌ಗಳನ್ನು shuffle ಮಾಡಿ, ಅವುಗಳನ್ನು receiving kernels‌ಗೆ ಅಗತ್ಯವಿರುವ ಅತ್ಯುತ್ತಮ format‌ನಲ್ಲಿ memoryಯಲ್ಲಿ layout ಮಾಡುತ್ತವೆ. buffers ದೊಡ್ಡ dimension ಹೊಂದಿದ್ದರೂ, model‌ನ ಎಲ್ಲಾ sequential layers‌ಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಮೇಲಿನ ಆಕೃತಿಯಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ, global synchronization‌ನ ಏಕೈಕ ರೂಪವು combine-receive kernel‌ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲಾಗಿದೆ. send‌ನಿಂದ data dispatch ಆದ ನಂತರ, ಒಂದು rank ಇತರ ranks‌ನಿಂದ ಬೇಕಾದ ಎಲ್ಲಾ tokens‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿ combine send kernels‌ಗೆ ಅವರು process ಆದ ಕೂಡಲೆ ಪ್ರವೇಶಿಸಿದಾಗ ಮತ್ತೆ ಮುಂದುವರೆಯುತ್ತದೆ. combine-receive‌ನಲ್ಲಿನ barrier ಯಾವುದಾದರೂ ಇತರ rank ಇನ್ನೂ data ಸ್ವೀಕರಿಸಲು ಕಾಯುತ್ತಿರುವಾಗ ಯಾವುದೇ rank ಮುಂದೆ ಹೋಗಿ dispatch-send ಆರಂಭಿಸದಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ, ಇದರಿಂದ potentially destructive overlapping ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. synchronization ಅನ್ನು ಸರಳತೆಯಿಗಾಗಿ combine kernel‌ನಲ್ಲಿ ಮಾಡಲಾಗಿದೆ; optimization ಆಗಿ dispatch receive ಮತ್ತು combine send kernels ನಡುವೆ ಅದೇ barrier ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದಾಗಿತ್ತು, GPU ಇತರ kernels ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿರುವಾಗ NICs‌ಗಳಿಗೆ transfers settle ಆಗಲು ಹೆಚ್ಚು ಸಮಯ ನೀಡಿ latency ಅನ್ನು ಇನ್ನಷ್ಟು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಎರಡೂ ಕರ್ನಲ್‌ಗಳನ್ನು ಸಾಧನಗಳ ಎಲ್ಲಾ ಲಭ್ಯವಿರುವ SM ಗಳಾದ್ಯಂತ ವಿಂಗಡಿಸಲಾಗಿದೆ: ಡಿಸ್ಪ್ಯಾಚ್ ಸೆಂಡ್ ಮತ್ತು ಕಂಬೈನ್ ರಿಸೀವ್ ಕರ್ನಲ್‌ಗಳು ಪ್ರತಿ ಶ್ರೇಣಿಯ ಗರಿಷ್ಠ ಟೋಕನ್ ಎಣಿಕೆ (max_m) ಗಣನೆಗೆ ಸಮಾಂತರಗೊಳಿಸಬೇಕು, ಆದರೆ ಡಿಸ್ಪ್ಯಾಚ್ ರಿಸೀವ್ ಮತ್ತು ಕಂಬೈನ್ ಸೆಂಡ್ ಕರ್ನಲ್‌ಗಳು ಪ್ರತಿ ಶ್ರೇಣಿ ಮತ್ತು ಸ್ಥಳೀಯ ತಜ್ಞರಿಂದ ಅಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು, ಗರಿಷ್ಠ max_m * (num_experts // EP) * (EP // TP).

ರವಾನೆ

dispatch kernel tokens ಮತ್ತು block scaling factors ಅನ್ನು tokens were routed to hosted the experts ಹೊಂದಿರುವ peers‌ಗಳಿಗೆ dispatch ಮಾಡುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ. sender side warp specialization ಅನ್ನು ಅವಲಂಬಿಸಿ ಎರಡು ಕಾರ್ಯಗಳನ್ನು parallelize ಮಾಡುತ್ತದೆ: ಪ್ರತಿ rank‌ನಿಂದ ಎಷ್ಟು tokens ಕಳುಹಿಸಲಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸಲು routing ಮಾಹಿತಿಯನ್ನು aggregating ಮಾಡುವುದು ಮತ್ತು remote‌ಗೆ dispatch ಮಾಡಬೇಕಾದ messages‌ಗೆ tokens ಅನ್ನು packing ಮಾಡುವುದು. receiver side ಮೊದಲು ಎಲ್ಲಾ token counts ಸ್ವೀಕರಿಸಲ್ಪಡುವುದನ್ನು ಕಾಯುತ್ತದೆ, ನಂತರ ಅದು shared memory‌ನಿಂದ payloads ಅನ್ನು ಓದಿ unpack ಮಾಡಿ, downstream Grouped GEMM kernels‌ಗೆ ಸಾಗಿಸಲಾಗುವ tensors‌ಗಳಿಗೆ ಸೇರಿಸುತ್ತದೆ. ಅದು combine kernels‌ನೊಂದಿಗೆ ಹಂಚಿಕೊಂಡಿರುವ buffers‌ನಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ಕೂಡ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಪ್ರತಿ token ಅನ್ನು ಹಿಂದಕ್ಕೆ ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂದು ಸೂಚಿಸಲು. ಈ ಮಾಹಿತಿ ಅಗತ್ಯವಿದ್ದು, receive kernel ನಿರ್ಧಿಷ್ಟವಲ್ಲದ ಕ್ರಮದಲ್ಲಿ contiguous buffers‌ಗಳಲ್ಲಿ tokens‌ಗಳನ್ನು shuffle ಮಾಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಕಳುಹಿಸುವವರ ಭಾಗದಲ್ಲಿ, ಪ್ರತಿ ಬ್ಲಾಕ್‌ನಲ್ಲಿ 32 ಥ್ರೆಡ್‌ಗಳ ಒಂದೇ ವಾರ್ಪ್ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಓದುವ ಮತ್ತು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನದ ತಜ್ಞರು ಈ ಶ್ರೇಣಿಯಿಂದ ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ, nvshmem_signal_op ಬಳಸಿ ಎಣಿಕೆ ಮತ್ತು ಒಂದನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ರಿಮೋಟ್ ತುದಿಯಲ್ಲಿ ಶೂನ್ಯದಿಂದ ಶೂನ್ಯವಲ್ಲದಕ್ಕೆ ಪರಿವರ್ತನೆಯು ಮೂಲ ಶ್ರೇಣಿಯಿಂದ ಎಣಿಕೆಗಳ ಸ್ವೀಕೃತಿಯನ್ನು ಸೂಚಿಸುವುದರಿಂದ, ಎಣಿಕೆಯನ್ನು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ಸಮಾನಾಂತರವಾಗಿ, ಉಳಿದ ವಾರ್ಪ್‌ಗಳು ಎಲ್ಲಾ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಸಿಮೆಟ್ರಿಕ್ ಮೆಮೊರಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ನಕಲಿಸಲು ಸಹಕರಿಸುತ್ತವೆ, ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳು, ಸ್ಕೇಲಿಂಗ್ ಅಂಶಗಳು ಮತ್ತು ಸ್ಥಳೀಯ ಶ್ರೇಣಿಯಲ್ಲಿನ ಅವುಗಳ ಸೂಚ್ಯಂಕವನ್ನು ನಿರಂತರ ತುಂಡಾಗಿ ಪ್ಯಾಕ್ ಮಾಡುತ್ತವೆ. ಟೋಕನ್ ಬರೆಯಲ್ಪಡುವ ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸಲು ಕಂಬೈನ್ ಕಳುಹಿಸುವವರಿಗೆ ಸೂಚ್ಯಂಕ ಅಗತ್ಯವಿದೆ. ಮುಂದೆ, ವಾರ್ಪ್ ಗುಂಪುಗಳಾದ್ಯಂತ ತಡೆಗೋಡೆ ಮೂಲಕ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ನಕಲಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ, ವಾರ್ಪ್‌ಗಳು ಮತ್ತೊಮ್ಮೆ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ ಒಂದೇ ಬಫರ್ ಅನ್ನು ಸಮಾನಾಂತರವಾಗಿ ವಿಭಿನ್ನ ತಜ್ಞರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. nvshmemx_putmem_signal_nbi_warp ಬಳಸಿ ಟೋಕನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇದು ರಿಮೋಟ್ ಸಾಧನದಲ್ಲಿ ಸ್ಥಳೀಯ ಶ್ರೇಣಿಯಿಂದ ಕಳುಹಿಸಲಾದ ಟೋಕನ್‌ಗಳ ಎಣಿಕೆಯನ್ನು ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. DP ಗುಂಪಿನೊಳಗೆ, ಪ್ರತಿ ಶ್ರೇಣಿಯು ಕಳುಹಿಸಬೇಕಾದ ಟೋಕನ್‌ನ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿರುವ ಕಾರಣ, ರವಾನೆಯು ಸಮವಾಗಿ ಸಮತೋಲನಗೊಂಡಿದೆ, ಪ್ರತಿ ಸಾಧನವು ಟೋಕನ್‌ಗಳ ಉಪವಿಭಾಗವನ್ನು ಹೊರಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ಸ್ವೀಕರಿಸುವ ಕೊನೆಯಲ್ಲಿ, ಎಲ್ಲಾ ಕರ್ನಲ್‌ಗಳು ಮೊದಲು ಕಳುಹಿಸುವ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತವೆ ಒಟ್ಟು ಟೋಕನ್ ಎಣಿಕೆಗಳು ಕಳುಹಿಸಲು ಕಾಯುವ ಮೂಲಕ. ತರುವಾಯ, ಮೂಲ ಶ್ರೇಣಿಗಳ ಎಲ್ಲಾ ಪೇಲೋಡ್‌ಗಳನ್ನು ಸಹ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತಾ, ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚಿಸಿದ ಕಳುಹಿಸಲಾದ ಟೋಕನ್ ಎಣಿಕೆಗಳು ಒಟ್ಟು ಎಣಿಕೆಗಳಿಗೆ ನೆಲೆಗೊಳ್ಳಲು ಅವೆಲ್ಲವೂ ಕಾಯುತ್ತವೆ, ಇದು putmem ಕರೆಯ ಶಬ್ದಾರ್ಥಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ಕರ್ನಲ್‌ಗಳು nvshmem_uint64_wait_until ಬಳಸಿ ಎಣಿಕೆಗಳ ಮೇಲೆ ಪೋಲ್ ಮಾಡುತ್ತವೆ, ಎಲ್ಲಾ ಬ್ಲಾಕ್‌ಗಳು ಮತ್ತು ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸಮಾಂತರಗೊಳಿಸುತ್ತವೆ. ತರುವಾಯ, ಕ್ರಾಸ್-ಬ್ಲಾಕ್ ತಡೆಗೋಡೆ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸರಿಯಾಗಿ ಸ್ವೀಕರಿಸದ ಹೊರತು ಯಾವುದೇ ಬ್ಲಾಕ್ ಬಫರ್‌ಗಳನ್ನು ಓದುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಹರಡಿಕೊಂಡಿದೆ ಮತ್ತು ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚಿಸಿದ ಕೌಂಟರ್ ಮೂಲಕ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ, ಟೋಕನ್‌ಗಳನ್ನು ಸಿಮೆಟ್ರಿಕ್ ಮೆಮೊರಿಯಿಂದ ಸಾಮಾನ್ಯ ನಿರಂತರ ಬಫರ್‌ಗಳಿಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ ಅದು ತಜ್ಞರನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಕರ್ನಲ್‌ಗಳಿಗೆ ಇನ್‌ಪುಟ್‌ಗಳಾಗುತ್ತವೆ. ಮೂಲ ಶ್ರೇಣಿ, ತಜ್ಞರ ಸೂಚ್ಯಂಕ ಮತ್ತು ಟೋಕನ್ ಸೂಚ್ಯಂಕವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಕಂಬೈನ್ ಕರ್ನಲ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳನ್ನು ಎಲ್ಲಿ ಕಳುಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಸೂಚಿಸುತ್ತದೆ. DP ಗುಂಪಿನೊಳಗಿನ ಟೋಕನ್‌ಗಳನ್ನು ವಿಭಿನ್ನ ಸಾಧನಗಳಿಂದ ಕಳುಹಿಸಿದರೂ, ಅವುಗಳನ್ನು ಅನುಗುಣವಾದ ತಜ್ಞರಿಗೆ ರವಾನಿಸಲು ಎಲ್ಲವನ್ನೂ ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡಲಾಗುತ್ತದೆ.

ಸಂಯೋಜಿಸಿ

ಕಂಬೈನ್ ಕರ್ನಲ್‌ಗಳನ್ನು ಮತ್ತೊಮ್ಮೆ ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಅರ್ಧಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: ಕಳುಹಿಸುವವರು ಪ್ರಮಾಣೀಕರಿಸದ 16-ಬಿಟ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗಳನ್ನು ರಿಮೋಟ್ ಸಾಧನಗಳಿಗೆ ನಕಲಿಸುತ್ತಾರೆ, ಸ್ವೀಕರಿಸುವ ಕರ್ನಲ್‌ಗಳು ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ಕಾಯುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಎಲ್ಲಾ ತಜ್ಞರ ಕೊಡುಗೆಗಳ ತೂಕದ ಸರಾಸರಿಯನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತಾರೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅವು ತಡೆಗೋಡೆಯಾಗಿಯೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಡಿಸ್ಪ್ಯಾಚ್-ಕಂಬೈನ್ ಅನುಕ್ರಮವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು: ಕಳುಹಿಸುವ ಕರ್ನಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶಿಸಿದಾಗ ಪ್ರತಿ ಶ್ರೇಣಿಯು ಪ್ರತಿ ಪೀರ್‌ನಲ್ಲಿ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸುವುದನ್ನು ಗಮನಿಸಿದ ಹೊರತು ಸ್ವೀಕರಿಸುವ ಕರ್ನಲ್‌ಗಳು ಹಿಂತಿರುಗಲು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ. ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನ ವಿಳಂಬವು ಕಡಿಮೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ನಿಜವಾದ ಸಂವಹನ ಮತ್ತು ಲೆಕ್ಕಾಚಾರದೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

sender side‌ನಲ್ಲಿ, kernels ಎಲ್ಲಾ local experts‌ಗೆ ನಿಯೋಜಿಸಲಾದ tokens ಪಟ್ಟಿಯನ್ನು parallelವಾಗಿ traverse ಮಾಡಿ, ಅವುಗಳನ್ನು destination rank‌ನ buffer‌ಗೆ ಬರೆಯುತ್ತವೆ. target rank, expert index ಮತ್ತು token index ಅನ್ನು tokens ಸ್ವೀಕರಿಸುವಾಗ scater kernels populate ಮಾಡುವ per-token buffers‌ನಿಂದ ಓದಲಾಗುತ್ತದೆ. ಪ್ರತಿ sender ತನ್ನದೇ private memory region ಅನ್ನು ಪ್ರತಿ expert‌ಗೆ ಬರೆಯಲು ಹೊಂದಿರುತ್ತದೆ, ಮೇಲಿನ ಆಕೃತಿಯಲ್ಲಿ ಸೂಚಿಸಿರುವಂತೆ, synchronization ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. dispatch‌ನಂತೆ, combine ಕೂಡ destination rank‌ನ ಮೇಲೆ ಪ್ರತಿ token counters ಅನ್ನು atomically ಹೆಚ್ಚಿಸಿ data ಸ್ವೀಕಾರವನ್ನು ಸೂಚಿಸುತ್ತದೆ: counter ಒಂದು token dispatch ಮಾಡಲಾದ experts‌ಗಳ ಸಂಖ್ಯೆಗೆ ಹೊಂದಿದಾಗ, token contents ಅನ್ನು ಪ್ರವೇಶಿಸಬಹುದು.

receive kernel‌ನಲ್ಲಿ, tokens ಪಟ್ಟಿಯನ್ನು ಹಲವು blocks across parallelವಾಗಿ traverse ಮಾಡಲಾಗುತ್ತದೆ, signalling operation set ಮಾಡಿದ flag ಅನ್ನು poll ಮಾಡಿ ಅವುಗಳ contents ಬರಲು ಕಾಯುತ್ತಾ. arrival ಆಗುತ್ತಿದ್ದಂತೆ, payloads ಅನ್ನು private buffers‌ನಿಂದ ಓದಲಾಗುತ್ತದೆ, routing table ಯಾವ buffer‌ನಿಂದ ಓದಬೇಕು ಮತ್ತು ಪ್ರತಿ expert‌ಗೆ ಯಾವ weight ಅನ್ನು ನಿಯೋಜಿಸಬೇಕು ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ನಂತರ ಫಲಿತಾಂಶಗಳನ್ನು externally allocated tensors‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಎಲ್ಲಾ devices barrier ಅನ್ನು ದಾಟಿದ ನಂತರ kernel execution ಮುಗಿಯುತ್ತದೆ. DP group across, ಎಲ್ಲಾ ranks ಪ್ರತಿ expert activation‌ನ ಒಂದು copy ಅನ್ನು ಸ್ವೀಕರಿಸಿ ತಮ್ಮದೇ replicas ಅನ್ನು compute ಮಾಡುತ್ತವೆ.

ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು

ಇನ್ಫಿನಿಬ್ಯಾಂಡ್ ಮತ್ತು CX-7 NIC ಗಳ ಮೂಲಕ ಸಂಪರ್ಕಗೊಂಡಿರುವ 16 ನೋಡ್‌ಗಳಲ್ಲಿ ಹರಡಿರುವ 128 GPU ಗಳ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಾವು ನಮ್ಮ ಕರ್ನಲ್‌ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. ನಾವು GPUDirect Async (IBGDA) ಮತ್ತು CPU ಪ್ರಕ್ಸಿಯೊಂದಿಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಸಂಪರ್ಕ (RC) ಎರಡನ್ನೂ ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ DeepSeek ಅನುಷ್ಠಾನದೊಂದಿಗೆ, ಹಾಗೆಯೇ PyTorch (NCCL ಮೂಲಕ) ಅಥವಾ NVSHMEM ಒದಗಿಸಿದ ದಟ್ಟವಾದ ಪ್ರಿಮಿಟಿವ್‌ಗಳೊಂದಿಗೆ ನಾವು ಅವುಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ.

ವಿಸ್ತರಿಸಿ

ದಟ್ಟವಾದ NVSHMEM ಆಲ್-ಟು-ಆಲ್ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ, IBRC ಮತ್ತು IBGDA ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಒಂದೇ ರೀತಿ ಇದ್ದರೂ (6378 µs vs 6180 µs), ವಿರಳ ಕರ್ನಲ್‌ಗಳೊಂದಿಗೆ IBGDA ಗಮನಾರ್ಹವಾಗಿ ವೇಗವಾಗಿರುತ್ತದೆ. ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಅನ್ನು ಸೇರಿಸಿದರೆ, IBGDA 902 µs ಅನ್ನು ಬಳಸುತ್ತದೆ ಆದರೆ IBRC 3223 µs ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ವಿಳಂಬದಲ್ಲಿ 3.6x ಸುಧಾರಣೆ. ಆಲ್-ಟು-ಆಲ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಬೌಂಡ್ ಆಗಿರುವಾಗ, ವಿರಳ ಕರ್ನಲ್‌ಗಳು ಮ್ಯಾಗ್ನಿಟ್ಯೂಡ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಪ್ರಸಾರ ಮಾಡುತ್ತವೆ, ವಿಳಂಬದಿಂದ ಬಂಧಿಸಲ್ಪಡುತ್ತವೆ. GPU ಮತ್ತು NIC ಅನ್ನು ಸಮನ್ವಯಗೊಳಿಸಲು CPU ಪ್ರಕ್ಸಿ ಅಗತ್ಯವಿಲ್ಲದೆ, ನೇರವಾಗಿ GPU ನಿಂದ ನೆಟ್‌ವರ್ಕ್ ವರ್ಗಾವಣೆಗಳನ್ನು ಪ್ರಚೋದಿಸುವ ಮೂಲಕ, ಎಂಡ್-ಟೋ-ಎಂಡ್ ವಿಳಂಬವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ನಮ್ಮ ಪೋರ್ಟಬಲ್ ಕರ್ನಲ್‌ಗಳು ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ DeepSeek ಕರ್ನಲ್‌ಗಳಿಗಿಂತ ಸುಮಾರು 2x ನಿಧಾನವಾಗಿದ್ದರೂ, ದಟ್ಟವಾದ ಕರ್ನಲ್‌ಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಅವು ವಿಳಂಬವನ್ನು 10x ಸುಧಾರಿಸುತ್ತವೆ (902 µs vs 9944 µs).

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಳುಹಿಸುವವರಿಂದ-ಸ್ವೀಕರಿಸುವ ಘಟಕಗಳಾಗಿ ವಿಂಗಡಿಸುವುದು ಲೈಬ್ರರಿ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಕೆಲವು ವಿಳಂಬವನ್ನು ಮರೆಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಸಿಂಗಲ್-ನೋಡ್‌ನಲ್ಲಿ (EP8), NVSHMEM ಸಾರಿಗೆಗಾಗಿ NVLINK ಅನ್ನು ಬಳಸುತ್ತದೆ, ನೋಡ್-ನಡುವಿನ ನೆಟ್‌ವರ್ಕಿಂಗ್‌ಗಿಂತ ಕಡಿಮೆ ವಿಳಂಬ ಮತ್ತು ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಅನ್ನು ತಲುಪಿಸುತ್ತದೆ. ನಮ್ಮ ಪೋರ್ಟಬಲ್ ಕರ್ನಲ್‌ಗಳು ಸಿಂಗಲ್-ನೋಡ್‌ನಲ್ಲಿ DeepEP ಗಿಂತ ಸುಮಾರು 2.5x ವೇಗವಾಗಿವೆ (186µs vs 481 µs).

ಮತ್ತಷ್ಟು ಸುಧಾರಣೆಗಳು

ಇಲ್ಲಿ ವಿವರಿಸಿದ kernels ML frameworks‌ಗಳ built-in primitives‌ಗಳನ್ನು ಮೀರಿಸಿ, NVLink ಅಥವಾ InfiniBand ಮುಂತಾದ ನಿರ್ದಿಷ್ಟ inter-device transports‌ಗಾಗಿ ಅತಿಯಾಗಿ specialize ಮಾಡದೆ ಸಮಂಜಸವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡುತ್ತವೆ. ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿದ ಅವಕಾಶಗಳ ಜೊತೆಗೆ, communication primitives‌ಗಳನ್ನು ಇನ್ನಷ್ಟು specialized ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಹೆಚ್ಚಿನ performance gains ಸಾಧ್ಯವಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, NVLink across, symmetric memory ಬಳಕೆಯನ್ನು devices‌ಗಳ across shared ಆಗಿರುವ buffers‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ಕೆಲವು copying ನಿವಾರಣೆಯಾಗುತ್ತದೆ ಮತ್ತು finer-grained synchronization schemes, individual tokens ಮಟ್ಟದಲ್ಲಿ token batches ಬದಲಿಗೆ, ಸಾಧ್ಯವಾಗುತ್ತವೆ. InfiniBand across, implementation ಮೂಲ queue pairs‌ಗೆ ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು, expected ಮತ್ತು sent token counts ಎರಡನ್ನೂ transfer ಮಾಡುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸಿ, tokens queueಗಳಿಂದ output buffers‌ಗೆ ಅವು ಬಂದಂತೆ flush ಮಾಡಬಹುದು. ಆದರೆ, ಇಂಥ implementations portability‌ನ ಖರ್ಚಿನಲ್ಲಿ ಬರುತ್ತವೆ, ಆದರೆ ನಮ್ಮ implementations ನಿರ್ದಿಷ್ಟ configurations ಹೊಂದಿರುವ clusters‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟ hardware‌ಗೆ optimize ಮಾಡಲು development effort commit ಮಾಡುವ ಮೊದಲು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ತೀರ್ಮಾನ

ವೈವಿಧ್ಯಮಯ ಹಾರ್ಡ್‌ವೇರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಹೊಂದಾಣಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವಾಗ ಪ್ರಮಾಣಿತ ಆಲ್-ಟು-ಆಲ್ ಸಂವಹನಕ್ಕಿಂತ 10x ವೇಗದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುವ MoE ಸಂವಹನಕ್ಕಾಗಿ ನಾವು ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ, ಪೋರ್ಟಬಲ್ ಲೈಬ್ರರಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದ್ದೇವೆ. NVLink ನೊಂದಿಗೆ ಸಿಂಗಲ್-ನೋಡ್ ನಿಯೋಜನೆಗಳಲ್ಲಿ, ನಮ್ಮ ಪರಿಹಾರವು ಹಿಂದಿನ ಅನುಷ್ಠಾನಗಳಿಗಿಂತ 2.5x ಕಡಿಮೆ ವಿಳಂಬವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ನಮ್ಮ ವಿಧಾನವು ಪ್ರಮುಖ ನವೀನತೆಗಳ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು portability ಅನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತದೆ: GPU-initiated communication support, computation-communication overlap ಅನ್ನು ಸಾಧ್ಯಮಾಡುವ split kernel architecture, ಮತ್ತು minimal NVSHMEM primitives ಬಳಸಿ ದಕ್ಷ token dispatch. ಬಹು-node setups‌ನಲ್ಲಿ highly specialized implementations‌ಗಿಂತ ಸುಮಾರು 2x ನಿಧಾನವಾಗಿದ್ದರೂ, ನಮ್ಮ library ವಿವಿಧ network environments (NVLink, CX-7, ಮತ್ತು EFA) across ಉತ್ತಮ flexibility ಒದಗಿಸುತ್ತದೆ.

MoE ಮಾದರಿಗಳು ಅಳೆಯುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತಿದ್ದಂತೆ, ನಮ್ಮಂತಹ ಸಮರ್ಥ ಸಂವಹನ ಕಾರ್ಯತಂತ್ರಗಳು ಪ್ರಾಯೋಗಿಕ ನಿಯೋಜನೆಗೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗುತ್ತವೆ. ನಮ್ಮ ಸಂಪೂರ್ಣವಾಗಿ ಓಪನ್ ಸೋರ್ಸ್ ಅನುಷ್ಠಾನವು https://github.com/ppl-ai/pplx-kernels ನಲ್ಲಿ ಲಭ್ಯವಿದೆ.

ಉಲ್ಲೇಖಗಳು

DeepEP

DeepSeek-V3 ತಾಂತ್ರಿಕ ವರದಿ

NVIDIA NVSHMEM

ಉಲ್ಲೇಖ

@online{perplexity2025EfficientAndPortableMixtureOfExpertsCommunication,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Phi Hoang},
  title = {{Efficient and portable mixture-of-experts communication}},
  date = {2025-04-02},
  url = {https://perplexity.coolkeypoint.com/hub/blog/efficient-and-portable-mixture-of-experts-communication}
}