ಬಹು-ನೋಡ್ DeepSeek ನಿಯೋಜನೆಯೊಂದಿಗೆ ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್

ಹೆಚ್ಚಿನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ವಿಳಂಬ ಮತ್ತು throughput ಸಾಮಾನ್ಯವಾಗಿ ಪರಸ್ಪರ ವಿರುದ್ಧ ಗುರಿಗಳಾಗಿದ್ದು, ವಿನ್ಯಾಸ ಮತ್ತು ನಿಯೋಜನೆಯ ವೇಳೆ ಸಮತೋಲನಗಳನ್ನು ಅಗತ್ಯಪಡಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ದಟ್ಟವಾದ ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳಲ್ಲಿ, batch size ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು throughput ಅನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ ವಿಳಂಬವನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ; single machine ಒಳಗೆ tensor parallelism ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು, ಆದರೆ replicas ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆಗೊಳಿಸಿ throughput ಅನ್ನು ಇಳಿಸುತ್ತದೆ.

DeepSeek-V3/R1 ನಂತಹ ಮಿಕ್ಶ್ಚರ್ ಆಫ್ ಎಕ್ಸ್‌ಪರ್ಟ್ಸ್ (MoE) ಮಾದರಿಗಳು ಇತ್ತೀಚೆಗೆ ಅತ್ಯುತ್ತಮ ಮಾದರಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ದಕ್ಷತೆಯನ್ನು ಪ್ರದರ್ಶಿಸಿವೆ. ಉದಾಹರಣೆಗೆ, DeepSeek-V3/R1 ಮಾದರಿಯು ಒಟ್ಟು 671B ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಪ್ರತಿ ಟೋಕನ್ ಅನುಮಾನದ (inference) ಸಮಯದಲ್ಲಿ ಕೇವಲ 37B ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ. ಈ ಮಾದರಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನುಮಾನ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸವಾಲುಗಳು ಮತ್ತು ಅವಕಾಶಗಳೆರಡನ್ನೂ ಒದಗಿಸುತ್ತದೆ.

ಈ ಲೇಖನವು ಸಾಂಪ್ರದಾಯಿಕ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ, DeepSeek-V3/R1 ನಂತಹ MoE ಮಾದರಿಗಳು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ GPU ಗಳನ್ನು ಬಳಸುವಾಗ ಏಕಕಾಲದಲ್ಲಿ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಮತ್ತು ಕಡಿಮೆ ಲೇಟೆನ್ಸಿಯನ್ನು ಸಾಧಿಸಬಹುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ನಿಯೋಜನಾ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು

ವಿಸ್ತರಿಸಿ

ವಿಸ್ತರಿಸಿ

ಮಾದರಿಯು ಹೊಂದಿರುವ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಸಣ್ಣ ತಜ್ಞರ (experts) ಕಾರಣದಿಂದಾಗಿ, ನಿಯೋಜನೆಗಳನ್ನು ಬಹು ಸಾಧನಗಳಲ್ಲಿ ಹಂಚಬೇಕು. ನಾವು 8xH200 GPU ಗಳನ್ನು ಹೊಂದಿರುವ ಏಕ-ನೋಡ್‌ನಲ್ಲಿ ಏಕ-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಮತ್ತು 8xH100 GPU ಗಳಲ್ಲಿ ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಎರಡನ್ನೂ ಪರಿಗಣಿಸಿದ್ದೇವೆ.

ಎರಡೂ ನಿಯೋಜನಾ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ, ಇದನ್ನು ನಮ್ಮ ಇನ್‌ಹೌಸ್ ವಿನಂತಿ ಶೆಡ್ಯೂಲರ್ ಮೂಲಕ ಸಂಘಟಿಸಲಾಗುತ್ತದೆ. ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್ ಅನುಷ್ಠಾನವು ಬಹು ಅನುಮಾನ ಇಂಜಿನ್ ನಿದರ್ಶನಗಳನ್ನು (instances) ಪ್ರಾರಂಭಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. GRPC ಮೂಲಕ ಇಂಜಿನ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ವಿನಂತಿ ಶೆಡ್ಯೂಲರ್, ವಿನಂತಿಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸಮವಾಗಿ ಹರಡುವುದಕ್ಕೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತದೆ, ಜೊತೆಗೆ KV ಮರುಬಳಕೆಯನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಭಾಗಶಃ ಹೊಂದಾಣಿಕೆಯ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೊಂದಿರುವ ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹವನ್ನು (cache) ಹೊಂದಿರುವ ಸರ್ವರ್‌ಗಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಇಂಜಿನ್ ನಿದರ್ಶನಗಳು ಬಹು ನೋಡ್‌ಗಳಲ್ಲಿ ವ್ಯಾಪಿಸುವುದಿಲ್ಲ. ಅವು ಐಚ್ಛಿಕವಾಗಿ ಬಹು ಸಾಧನಗಳಲ್ಲಿ ಗಮನವನ್ನು ಹಂಚಲು ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್ ಅನ್ನು ಬಳಸಬಹುದು. ಏಕ-ನೋಡ್ ಸಂದರ್ಭದಲ್ಲಿ NVLink ಮೂಲಕ ಅಥವಾ ಬಹು-ನೋಡ್ ಸಂದರ್ಭದಲ್ಲಿ InfiniBand ಮೂಲಕ ನಿದರ್ಶನಗಳು ಪರಸ್ಪರ ಸಂಪರ್ಕಗೊಂಡಿವೆ, ತಜ್ಞರನ್ನು ರವಾನಿಸುತ್ತವೆ ಮತ್ತು ಸಂಗ್ರಹಿಸುತ್ತವೆ.

ಏಕ-ನೋಡ್ ನಿಯೋಜನಾ ಕಾನ್ಫಿಗರೇಶನ್ ಸಣ್ಣ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳೊಂದಿಗೆ ಉತ್ತಮ ಲೇಟೆನ್ಸಿಯನ್ನು ನೀಡುತ್ತದೆ; ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಲೋಡ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯು ವೇಗವಾಗಿ ಕ್ಷೀಣಿಸುತ್ತದೆ.

ಸೇವೆ ಸಲ್ಲಿಸುವ ಇಂಜಿನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು, ನಾವು ಬಹು ಇಂಜಿನ್ ನಿದರ್ಶನಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಪ್ರತಿ ನೋಡ್‌ಗೆ ಒಂದು ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ವಿತರಿಸಿದ ಸಂವಹನವನ್ನು ಹೊಂದಿಸಲು ಮತ್ತು NVSHMEM ಆರಂಭಿಕತೆಯನ್ನು ಮಾತುಕತೆ ಮಾಡಲು PyTorch ಜವಾಬ್ದಾರವಾಗಿರುತ್ತದೆ. ಸಂವಹನಕ್ಕಾಗಿ, ನಾವು ಹಿಂದಿನ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ನಲ್ಲಿ ವಿವರಿಸಿದ ಕಸ್ಟಮ್ CUDA ಕರ್ನಲ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ. ಎರಡು ನಿಯೋಜನೆಗಳ ಅನುಷ್ಠಾನವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ, ತಜ್ಞರ ಪ್ಯಾರಲಲಿಸಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಫ್ಯಾಬ್ರಿಕ್ ಆಧರಿಸಿ ಬಳಸಲು ಸರಿಯಾದ ಕರ್ನಲ್‌ಗಳನ್ನು ಮಾದರಿಯು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

ಸಮಾನಾಂತರೀಕರಣ ತಂತ್ರಗಳು

ನಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೋಲಿಕೆಗಳಿಗೆ ಧುಮುಕುವ ಮೊದಲು, DeepSeek-V3/R1 ನಂತಹ ಬೃಹತ್ MoE ಮಾದರಿಗಳನ್ನು ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗಿಸುವ ಪ್ರಮುಖ ಸಮಾಂತರ ತಂತ್ರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅತ್ಯಗತ್ಯ.

ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್

LLM ಅನುಮಾನದಲ್ಲಿ, ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್ (TP) ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ GPU ಗೆ ಮೆಮೊರಿ ಬಳಕೆ ಮತ್ತು ಲೆಕ್ಕಾಚಾರವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಲೇಟೆನ್ಸಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಗಮನ ಮತ್ತು MLP ಲೇಯರ್‌ಗಳಲ್ಲಿ Linear ಪ್ರೊಜೆಕ್ಷನ್‌ಗಳನ್ನು ಸಾಲು ಅಥವಾ ಕಾಲಮ್ ಆಯಾಮಗಳ ಉದ್ದಕ್ಕೂ ಶಾರ್ಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಗಮನ ಹೆಡ್ ಆಯಾಮದ ಉದ್ದಕ್ಕೂ ಗಮನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಶಾರ್ಡ್ ಮಾಡಬಹುದು.

TP ಯೊಂದಿಗೆ, Llama-3 ಆರ್ಕಿಟೆಕ್ಚರ್ GPU ಗಳಲ್ಲಿ Linear ಪ್ರೊಜೆಕ್ಷನ್ ಮತ್ತು ಗಮನ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಯಾವುದೇ ನಕಲು ಮಾಡದ ಲೆಕ್ಕಾಚಾರವನ್ನು ಹೊಂದಿಲ್ಲ, ಇದು ಆದರ್ಶ ಶಾರ್ಡಿಂಗ್ ವಿಧಾನವಾಗಿದೆ. ಆದಾಗ್ಯೂ, DeepSeek-V3/R1 ಮಾದರಿಗಳಲ್ಲಿ, TP ಇದನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

DeepSeek-V3/R1 ಮಾದರಿಗಳು Multi-Latent Attention (MLA) ಅನ್ನು ಬಳಸುತ್ತವೆ. ಒಂದು MLA Layer ಮೊದಲು Linear Projection kv_a_proj ಅನ್ನು ಬಳಸಿ latent vector ಅನ್ನು ಗಣನೆ ಮಾಡುತ್ತದೆ, ನಂತರ ಇನ್ನೊಂದು Linear Projection kv_b_proj ಅನ್ನು ಬಳಸಿ ಅದನ್ನು ಪ್ರತಿ attention head‌ನ space‌ಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಎಲ್ಲ attention heads‌ಗಳು ಒಂದೇ latent vector ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ, TP latent vector ಅನ್ನು shard ಮಾಡಲಾಗದು, ಆದ್ದರಿಂದ ಎಲ್ಲಾ TP Ranks‌ಗಳಿಗೆ kv_a_proj ಮತ್ತು kv_b_proj ಯ parameters ಮತ್ತು computation ಅನ್ನು replicate ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಅದೇ ರೀತಿ, MLA latent vector ಅನ್ನು KV Cache‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದರಿಂದ, ಪ್ರತಿ TP Rank ಒಂದೇ ರೀತಿಯ KV Cache ನ ಪ್ರತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

MLA ನಲ್ಲಿ ಕೆಲವು ನಕಲುಗಳಿದ್ದರೂ, ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್ ಇನ್ನೂ ಲೆಕ್ಕಾಚಾರದ ಬೇಡಿಕೆಗಳಲ್ಲಿ ಭಾಗಶಃ ಕಡಿತವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚಿನ ಔಟ್‌ಪುಟ್ ವೇಗ ಅಗತ್ಯವಿರುವ ದೃಶ್ಯಗಳಿಗೆ ಇದನ್ನು ಮೌಲ್ಯಯುತವಾಗಿಸುತ್ತದೆ.

ಎಕ್ಸ್‌ಪರ್ಟ್ ಪ್ಯಾರಲಲಿಸಮ್

DeepSeek-V3/R1 ಮಾದರಿಗಳು MLP ಲೇಯರ್‌ಗಳನ್ನು MoE ಲೇಯರ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತವೆ. MoE ಲೇಯರ್ 256 ರೂಟ್ ಮಾಡಿದ ತಜ್ಞರು ಮತ್ತು ಒಬ್ಬ ಹಂಚಿದ ತಜ್ಞರನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ ಟೋಕನ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರಕ್ಕಾಗಿ 8 ವಿಭಿನ್ನ ರೂಟ್ ಮಾಡಿದ ತಜ್ಞರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ತೂಕದ ಮೊತ್ತ ಮಾಡಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಟೋಕನ್ ಹಂಚಿದ ತಜ್ಞರಲ್ಲೂ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ರೂಟ್ ಮಾಡಿದ ತಜ್ಞರ ಫಲಿತಾಂಶಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಎಕ್ಸ್‌ಪರ್ಟ್ ಪ್ಯಾರಲಲಿಸಮ್ (EP) ಎಂಬುದು MoE ಲೇಯರ್‌ಗಳಿಗೆ ವಿಶಿಷ್ಟವಾದ ಶಾರ್ಡಿಂಗ್ ವಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರತಿ GPU 256 / EP ರೂಟ್ ಮಾಡಿದ ತಜ್ಞರನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಹಂಚಿದ ತಜ್ಞರ ನಕಲನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. TP ಗೆ ಹೋಲಿಸಿದರೆ, EP ಯ ಪ್ರಯೋಜನವೆಂದರೆ ಅದು ಹೆಚ್ಚಿನ GPU ಗಳಲ್ಲಿ ಲೆಕ್ಕಾಚಾರವನ್ನು ವಿತರಿಸಬಹುದು, ಪ್ರತಿ GPU ಗೆ ಲೆಕ್ಕಾಚಾರ ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರವನ್ನು ನಿರ್ವಹಿಸುವ ಮೊದಲು, ಎಲ್ಲಾ GPU ಗಳು ಅನುಗುಣವಾದ ತಜ್ಞರು ಇರುವ GPU ಗಳಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು AllToAll ಸಂವಹನವನ್ನು ನಿರ್ವಹಿಸಬೇಕು; ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರದ ನಂತರ, ವಿವಿಧ GPU ಗಳಿಂದ ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ತೂಕದ ಮೊತ್ತವನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತೊಂದು AllToAll ಸಂವಹನದ ಅಗತ್ಯವಿದೆ. ನಾವು NVSHMEM ಬಳಸಿ ಈ ಎರಡು AllToAll ಸಂವಹನ ಕರ್ನಲ್‌ಗಳಾದ ಡಿಸ್ಪ್ಯಾಚ್ (Dispatch) ಮತ್ತು ಕಂಬೈನ್ (Combine) ನ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಆವೃತ್ತಿಯನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ನಮ್ಮ ಹಿಂದಿನ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ನಲ್ಲಿ ನಾವು ಅನುಷ್ಠಾನವನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಕರ್ನಲ್‌ಗಳು GitHub ನಲ್ಲಿ ಓಪನ್ ಸೋರ್ಸ್ ಆಗಿವೆ.

ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್

EP ಯೊಂದಿಗೆ, ನಾವು 128 ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ GPU ಗಳಲ್ಲಿ MoE ಲೆಕ್ಕಾಚಾರವನ್ನು ವಿತರಿಸಬಹುದು. ಆದಾಗ್ಯೂ, MLA ಲೆಕ್ಕಾಚಾರವನ್ನು EP ಯೊಂದಿಗೆ ವಿಭಾಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ, ನಾವು ಡೇಟಾ ಪ್ಯಾರಲಲಿಸಮ್ (DP) ಅನ್ನು ಪರಿಚಯಿಸಬಹುದು. ಪ್ರತಿ DP ಗ್ರೂಪ್ MLA ಲೇಯರ್‌ನ ಸಂಪೂರ್ಣ ನಕಲನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ DP ಗ್ರೂಪ್ ವಿಭಿನ್ನ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು MLA ಲೇಯರ್ ಲೆಕ್ಕಾಚಾರವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ.

MLA ಲೇಯರ್‌ನ DP ಮತ್ತು TP ಅನ್ನು ಸಂಯೋಜಿಸಬಹುದು, ಒಂದು DP ಗ್ರೂಪ್ ಅನ್ನು ಬಹು TP ರ‍್ಯಾಂಕ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು. MoE ಲೇಯರ್‌ನ EP ಅನ್ನು MLA ಲೇಯರ್‌ನ DP/TP ಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು. EP = DP * TP. ಉದಾಹರಣೆಗೆ, 16 ಯಂತ್ರಗಳಲ್ಲಿ, EP128 DP32 TP4 ಎಂದರೆ 128 GPU ಗಳಲ್ಲಿ ರೂಟ್ ಮಾಡಿದ ತಜ್ಞರನ್ನು ವಿತರಿಸುವುದು, ಪ್ರತಿ 4 GPU ಗಳು ಒಂದು DP ಗ್ರೂಪ್ ಅನ್ನು ರೂಪಿಸುತ್ತವೆ, ಒಟ್ಟು 32 ಸ್ವತಂತ್ರ DP ಗ್ರೂಪ್‌ಗಳು ಇರುತ್ತವೆ.

ಏಕ-ನೋಡ್ ಮತ್ತು ಬಹು-ನೋಡ್ ಹೋಲಿಕೆ

DeepSeek‌ನ 671B parameters ಒಂದೇ 8-GPU H100 machine‌ನ memory capacity ಅನ್ನು ಮೀರುತ್ತವೆ (80 GB * 8), ಆದರೆ ಒಂದೇ 8-GPU H200 machine ಸಂಪೂರ್ಣ model ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ accommodate ಮಾಡಬಹುದು (141 GB * 8). EP8 DP8 TP1 configuration ಅನ್ನು ಬಳಸುವುದರಿಂದ, model ಪ್ರತಿ GPUಗೆ ಸುಮಾರು 100 GB memory ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದರಿಂದ KV Cache ಮತ್ತು ಇತರ ಮಧ್ಯವರ್ತಿ ಫಲಿತಾಂಶಗಳಿಗೆ ಸುಮಾರು 40 GB ಉಳಿಯುತ್ತದೆ. ಒಂದು token 70,272 bytes KV Cache ಅನ್ನು occupies ಮಾಡುತ್ತದೆ. ಪ್ರತಿ requestಗೆ 5,000 tokens ಇವೆ ಎಂದು ಊಹಿಸಿದರೆ, ಪ್ರತಿ GPU ಸುಮಾರು 100 requests ಅನ್ನು accommodate ಮಾಡಬಹುದು.

ನಾವು ವಿಭಿನ್ನ configurations ಅಡಿಯಲ್ಲಿ single-node ಮತ್ತು multi-node deployments ನಡುವಿನ performance ವ್ಯತ್ಯಾಸಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಿದೆವು. single-node deploymentಗೆ ನಾವು ಒಂದು H200 machine ಅನ್ನು, ಮತ್ತು multi-node deploymentsಗೆ ಗರಿಷ್ಠ 16 H100 machines ಗಳನ್ನು ಬಳಸಿದೆವು. ಪ್ರತಿ deployment environmentಗೆ, ನಾವು TP 1, 2, 4, 8 ಸಂಯೋಜನೆಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ GPUಗೆ 1, 2, 4, 8, 16, 32, 64, 128 batch sizes ಗಳನ್ನು ಬಳಸಿದೆವು. ಪ್ರತಿ requestಗೆ KV Cache length 5,000 tokens ಇದೆ ಎಂದು ನಾವು ಊಹಿಸಿದೆವು. Multi-Token Prediction (MTP) 1 ಹೆಚ್ಚುವರಿ token ಅನ್ನು predict ಮಾಡುತ್ತದೆ (ಅಂದರೆ, ಪ್ರತಿ request‌ನ query length 2 ಆಗಿದೆ), ಮತ್ತು 60% acceptance rate ಎಂದು ಸಂಯಮವಾಗಿ ಊಹಿಸಿದೆವು. ಕೆಳಗಿನ figure ವಿಭಿನ್ನ configurations‌ಗಳಿಗೆ throughput ಮತ್ತು output speed ಅನ್ನು ತೋರಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ផ្ដಾಕ್ಷರ ಅಕ್ಷವು (horizontal axis) ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಟೋಕನ್‌ಗಳಲ್ಲಿ ಪ್ರತಿ ವಿನಂತಿಯ ಔಟ್‌ಪುಟ್ ವೇಗವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಲಂಬ ಅಕ್ಷವು (vertical axis) ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಟೋಕನ್‌ಗಳಲ್ಲಿ ಪ್ರತಿ ಯಂತ್ರದ ಥ್ರೂಪುಟ್ ಅನ್ನು ತೋರಿಸಲು ಲಾಗರಿಥಮಿಕ್ ಸ್ಕೇಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ನಾವು ಪ್ರತಿಯೊಂದು EP ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ಪ್ಯಾರೆಟೊ ಫ್ರಾಂಟಿಯರ್ ಅನ್ನು ವಿಭಿನ್ನ ಬಣ್ಣದ ರೇಖೆಗಳೊಂದಿಗೆ ಗುರುತಿಸಿದ್ದೇವೆ.

ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ಔಟ್‌ಪುಟ್ ವೇಗದ ಅವಶ್ಯಕತೆಗಳಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ, 1 ರ ಬ್ಯಾಚ್ ಗಾತ್ರದೊಂದಿಗೆ ಏಕ-ನೋಡ್ EP8 DP1 TP8 ಅನ್ನು ಬಳಸುವುದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ಟೋಕನ್‌ಗಳನ್ನು ಮೀರಿದ ಔಟ್‌ಪುಟ್ ವೇಗವನ್ನು ಸಾಧಿಸಬಹುದು, ಆದರೆ ಥ್ರೂಪುಟ್ ಅತ್ಯಂತ ಕಡಿಮೆಯಾಗಿದೆ, ಇದು ಔಟ್‌ಪುಟ್ ವೇಗಕ್ಕೆ ಸಮಾನವಾಗಿರುತ್ತದೆ. ಈ ದೃಶ್ಯದಲ್ಲಿ, ಸಂಪೂರ್ಣ ಬ್ಯಾಚ್ ಕೇವಲ 2 ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಇದನ್ನು ಗರಿಷ್ಠ 2*8=16 ತಜ್ಞರಿಗೆ ಕಳುಹಿಸಬಹುದು, ಇದು ಒಟ್ಟು ಗರಿಷ್ಠ 57B ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

80-40 tokens/s output speed range‌ನಲ್ಲಿ, throughput ಹೆಚ್ಚಾದಂತೆ output speed ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, EP128 ಅದೇ output speed‌ನಲ್ಲಿ single-node deployment‌ಗಿಂತ ಸುಮಾರು 5x ಹೆಚ್ಚಿನ throughput ಹೊಂದಿದೆ.

ಏಕ-ನೋಡ್ ನಿಯೋಜನೆಗಳು ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸುವ ಮೂಲಕ ಈ ವಿದ್ಯಮಾನವನ್ನು ವಿವರಿಸಬಹುದು: ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಸಕ್ರಿಯಗೊಂಡ ತಜ್ಞರ ಹೆಚ್ಚಳಕ್ಕೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸಿದೆ. ಬ್ಯಾಚ್ ಗಾತ್ರ 1 ಆಗಿರುವಾಗ, ಪ್ರತಿ GPU ಗೆ ಸಕ್ರಿಯಗೊಂಡ ತಜ್ಞರ ಸರಾಸರಿ ಸಂಖ್ಯೆ 2 * 8 / 8 = 2 ಆಗಿದೆ. ಬ್ಯಾಚ್ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾದಾಗ, ಎಲ್ಲಾ ತಜ್ಞರು ಸಕ್ರಿಯಗೊಳ್ಳುತ್ತಾರೆ, ಅಂದರೆ ಪ್ರತಿ GPU 256 / 8 = 32 ತಜ್ಞರನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ತಜ್ಞರನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಎಂದರೆ GPU ಮೆಮೊರಿಯಿಂದ ಹೆಚ್ಚಿನ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಓದಬೇಕು, ಇದು ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಒತ್ತಡವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳ ಡಿಕೋಡ್ ಹಂತವು ಈಗಾಗಲೇ ಕಂಪ್ಯೂಟ್ ಕಾರ್ಯಕ್ಷಮತೆಗಿಂತ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಿಂದ ಅಡೆತಡೆಗೆ ಒಳಗಾಗಿರುವುದರಿಂದ, ಏಕ-ನೋಡ್ ನಿಯೋಜನೆಯಲ್ಲಿ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಔಟ್‌ಪುಟ್ ವೇಗವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ನಾಲ್ಕು ಬಹು-ನೋಡ್ ನಿಯೋಜನಾ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ (EP16, EP32, EP64, ಮತ್ತು EP128) ಹೋಲಿಕೆಯು ಹೆಚ್ಚಿನ EP ಮೌಲ್ಯಗಳು ಥ್ರೂಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ವೇಗದ ಏಕಕಾಲಿಕ ಸುಧಾರಣೆಗಳ ಕಡೆಗೆ ಪ್ಯಾರೆಟೊ ಫ್ರಾಂಟಿಯರ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.

ಹೆಚ್ಚಿನ EP ಸಂಖ್ಯೆಯನ್ನು ಬಳಸುವುದು ಎಂದರೆ ಪ್ರತಿ GPU ಗೆ ಕಡಿಮೆ ತಜ್ಞರನ್ನು ಹಂಚಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, EP128 ಎಂದರೆ ಪ್ರತಿ GPU 256 / 128 = 2 ತಜ್ಞರಿಗೆ ಜವಾಬ್ದಾರವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಒತ್ತಡವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ದೊಡ್ಡ EP ಸಂಖ್ಯೆಯನ್ನು ಬಳಸುವ ಮೂಲಕ, ನಾವು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಪ್ರತಿ GPU ಬ್ಯಾಚ್ ಗಾತ್ರವು 64 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿರುವಾಗ, ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರದ ವೇಗವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಇನ್‌ಪುಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಒತ್ತಡವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, EP128 ಅನ್ನು ಬಳಸುವಾಗ, ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಔಟ್‌ಪುಟ್ ವೇಗವನ್ನು ಅಷ್ಟು ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ.

ಕುತೂಹಲಕಾರಿಯಾಗಿ, ದೊಡ್ಡ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಲ್ಲಿ (ಪ್ರತಿ GPU ಗೆ 64 ವಿನಂತಿಗಳು), ನಾವು ಹೊಸ ವಿದ್ಯಮಾನವನ್ನು ಗಮನಿಸಿದ್ದೇವೆ: ಏಕ-ನೋಡ್ ನಿಯೋಜನಾ ಥ್ರೂಪುಟ್ ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚಾಗಿದೆ. ಕಾರಣದ ಒಂದು ಭಾಗವೆಂದರೆ ನೋಡ್-ೊಳಗಿನ NVLink ನೋಡ್-ಅಂತರದ InfiniBand ಗಿಂತ ಹೆಚ್ಚಿನ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಹೊಂದಿದೆ. ಮತ್ತೊಂದು ಭಾಗವು ನಮ್ಮ ಅನುಷ್ಠಾನದಲ್ಲಿನ ಮಿತಿಗಳಿಂದಾಗಿ. ಈ ವಿದ್ಯಮಾನವನ್ನು ನಾವು ನಂತರ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ.

ಮೆಮೊರಿ ಸಾಮರ್ಥ್ಯದ ಮಿತಿಗಳಿಂದಾಗಿ, EP8 DP1 TP1 ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರತಿ GPU ಗೆ 128 ರ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಅನ್ನು ಅನುಸರಿಸುವ ದೃಶ್ಯಗಳಲ್ಲಿ ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಯು ಇನ್ನೂ ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ.

ಲೆಕ್ಕಾಚಾರ ಮತ್ತು ಸಂವಹನ ಅತಿ ವ್ಯಾಪ್ತಿ (Computation and Communication Overlapping)

ಎಕ್ಸ್‌ಪರ್ಟ್ ಪ್ಯಾರಲಲಿಸಮ್ ಕುರಿತು ಮೇಲೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಪರಿಚಯಿಸಿದಂತೆ, MoE ಲೇಯರ್ ಸಂವಹನದ ಸಮಯದಲ್ಲಿ GPU ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ (idle). ತ್ಯಾಜ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಈ ನಿಷ್ಕ್ರಿಯ ಸಮಯವನ್ನು ತುಂಬಲು ನಾವು ಡೇಟಾ-ಸ್ವತಂತ್ರ ಲೆಕ್ಕಾಚಾರದ ಕಾರ್ಯಗಳನ್ನು ಹುಡುಕಬೇಕು.

ವಿಸ್ತರಿಸಿ

ಮೇಲಿನ ಚಿತ್ರದ ಮೇಲಿನ ಭಾಗವು ಒಂದು ಲೇಯರ್‌ನ ಲೆಕ್ಕಾಚಾರದ ಹರಿವನ್ನು ತೋರಿಸುತ್ತದೆ. MoE ಲೆಕ್ಕಾಚಾರವು ಡಿಸ್ಪ್ಯಾಚ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಲೇಯರ್‌ನ ಲೆಕ್ಕಾಚಾರವು ಕಂಬೈನ್ ಫಲಿತಾಂಶವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ನಾವು ಪ್ರತಿ GPU ನಲ್ಲಿ ಹಂಚಿದ ತಜ್ಞರನ್ನು ಇರಿಸುತ್ತೇವೆ. ಈ ರೀತಿಯಾಗಿ, ಹಂಚಿದ ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ AllToAll ಸಂವಹನದ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಡಿಸ್ಪ್ಯಾಚ್ ಕಳುಹಿಸಿದ ತಕ್ಷಣವೇ ಹಂಚಿದ ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರವನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ನಂತರ ಡಿಸ್ಪ್ಯಾಚ್ ಸ್ವೀಕರಿಸಲು ಕಾಯಬಹುದು. ನಾವು ಈ ಅತಿ ವ್ಯಾಪ್ತಿ ಯೋಜನೆಯನ್ನು "ಡಿಸ್ಪ್ಯಾಚ್ ಅತಿ ವ್ಯಾಪ್ತಿ" (Dispatch Overlap) ಎಂದು ಕರೆಯುತ್ತೇವೆ.

ಡಿಸ್ಪ್ಯಾಚ್ ಅತಿ ವ್ಯಾಪ್ತಿಯು ನೇರವಾದ ಅನುಷ್ಠಾನ ಮತ್ತು ವ್ಯಾಪಕವಾದ ಅನ್ವಯಿಕತೆಯನ್ನು ನೀಡುತ್ತದೆ. ಈ ತಂತ್ರವು ಎಲ್ಲಾ EP ಗಾತ್ರಗಳು ಮತ್ತು ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಲ್ಲಿ ಹಂಚಿದ ತಜ್ಞರ ಲೆಕ್ಕಾಚಾರದ ಸಮಯವನ್ನು ಮರೆಮಾಚುತ್ತದೆ.

ಲೆಕ್ಕಾಚಾರ ಮತ್ತು ಸಂವಹನ ಅತಿ ವ್ಯಾಪ್ತಿಯನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸಲು, ಡೇಟಾ ಅವಲಂಬನೆಯನ್ನು ಮುರಿಯಲು DeepSeek ತಾಂತ್ರಿಕ ವರದಿಯಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ಮೈಕ್ರೋ ಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ನಾವು ಬಳಸಿದ್ದೇವೆ. ಚಿತ್ರದ ಕೆಳಗಿನ ಭಾಗದಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ, ನಾವು ಒಂದು ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಲೇಯರ್‌ನ ಲೆಕ್ಕಾಚಾರವನ್ನು 5 ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇವೆ:

ಹಂತ 1: InputNorm, QKVProj, AppendKV, BMM

ಹಂತ 2: BMM, Attn, OProj, PostNorm, Gate

ಹಂತ 3: Dispatch Send, Shared Expert

ಹಂತ 4: Dispatch Recv, MoE, Combine Send

ಹಂತ 5: Combine Recv

ಮೊದಲ 3 ದಟ್ಟವಾದ ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಲೇಯರ್‌ಗಳಲ್ಲಿ, ನಾವು ಸಂಪೂರ್ಣ ಬ್ಯಾಚ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಕೆಳಗಿನ 58 MoE ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಲೇಯರ್‌ಗಳಲ್ಲಿ, ನಾವು ಬ್ಯಾಚ್ ಅನ್ನು ಸಮವಾಗಿ ಎರಡು ಮೈಕ್ರೋ ಬ್ಯಾಚ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ. ಎರಡು ಮೈಕ್ರೋ ಬ್ಯಾಚ್‌ಗಳು ಪರ್ಯಾಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತವೆ, 3 ಹಂತಗಳಿಂದ ಆಫ್‌ಸೆಟ್ ಆಗಿರುತ್ತವೆ. ಈ ಎರಡು ಮೈಕ್ರೋ ಬ್ಯಾಚ್‌ಗಳ ನಡುವೆ ಯಾವುದೇ ಡೇಟಾ ಅವಲಂಬನೆ ಇಲ್ಲದಿರುವುದರಿಂದ, ಡಿಸ್ಪ್ಯಾಚ್ ಕಳುಹಿಸಿದ ನಂತರ ಮತ್ತು ಕಂಬೈನ್ ಕಳುಹಿಸಿದ ನಂತರ ನಾವು ಮತ್ತೊಂದು ಮೈಕ್ರೋ ಬ್ಯಾಚ್‌ನ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು.

ಲೇಟೆನ್ಸಿ ವಿಭಜನೆ (Latency Breakdown)

ಮುಂದೆ, ನಾವು ಪ್ರಯೋಗದ ಮೂಲಕ overlapping‌ನ ಪರಿಣಾಮಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ, ಹಾಗೆಯೇ single-node deployment EP8 ಮತ್ತು multi-node deployment EP128 ನಡುವಿನ performance ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ. ಹೋಲಿಕೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು, ಈ ಕೆಳಗಿನ ಪ್ರಯೋಗಕ್ಕಾಗಿ ನಾವು H100 GPUs ಗಳನ್ನು ಬಳಸಿದೆವು. ನಾವು TP1, ಪ್ರತಿ GPUಗೆ batch size 128, ಪ್ರತಿ requestಗೆ Query length 2, ಮತ್ತು KV Cache length 5000 ಅನ್ನು ಬಳಸಿದೆವು.

ವಿಸ್ತರಿಸಿ

ಮೇಲಿನ ಚಿತ್ರವು ಒಂದು MoE ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್ ಲೇಯರ್‌ನಲ್ಲಿ ಕಳೆದ ಒಟ್ಟು ಸಮಯವನ್ನು ಮತ್ತು ವಿಭಿನ್ನ ಪ್ರಕಾರದ ಕರ್ನಲ್‌ಗಳ ಲೇಟೆನ್ಸಿ ಅನುಪಾತವನ್ನು ತೋರಿಸುತ್ತದೆ. ಡಿಸ್ಪ್ಯಾಚ್, ಕಂಬೈನ್ ಮತ್ತು GroupGEMM ಹೊರತುಪಡಿಸಿ, ಬ್ಯಾಚ್ ಗಾತ್ರ ಒಂದೇ ಆಗಿರುವುದರಿಂದ EP8, EP128 NoOverlap ಮತ್ತು EP128 DispatchOverlap ಸರಣಿಗಳಲ್ಲಿ ಇತರ ಕರ್ನಲ್‌ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವು ಸಮಾನವಾಗಿರಬೇಕು.

ಅತಿ ವ್ಯಾಪ್ತಿ (Overlapping)

ಮೊದಲು ಮೂರು ಅತಿ ವ್ಯಾಪ್ತಿ ವಿಧಾನಗಳ ಪರಿಣಾಮಗಳನ್ನು ಹೋಲಿಸೋಣ. NoOverlap ಒಟ್ಟು 2667µs ತೆಗೆದುಕೊಂಡಿತು, DispatchOverlap 2651µs ತೆಗೆದುಕೊಂಡಿತು, 16µs ಅಥವಾ ಕೇವಲ 0.6% ಉಳಿಸಿತು. ಮೈಕ್ರೋಬ್ಯಾಚ್ ಬಹಳ ಗಮನಾರ್ಹ ಸುಧಾರಣೆಯನ್ನು ತೋರಿಸಿತು, 1896µs ತೆಗೆದುಕೊಂಡಿತು, 29% ವೇಗವರ್ಧನೆ. ಡಿಸ್ಪ್ಯಾಚ್ ಮತ್ತು ಕಂಬೈನ್ ಸಮಯ ಎರಡೂ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ. ಡಿಸ್ಪ್ಯಾಚ್ 593µs ನಿಂದ 367µs ಗೆ ಇಳಿದಿದೆ, ಮತ್ತು ಕಂಬೈನ್ 1012µs ನಿಂದ 237µs ಗೆ ಇಳಿದಿದೆ.

ಲೆಕ್ಕಾಚಾರದ ಕರ್ನಲ್‌ಗಳಿಗಾಗಿ, 128 ಗಾತ್ರದ ಬ್ಯಾಚ್ ಅನ್ನು 64 ಗಾತ್ರದ ಎರಡು ಬ್ಯಾಚ್‌ಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಒಟ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಆದ್ದರಿಂದ, ಸಂವಹನಕ್ಕಾಗಿ ಕಳೆದ ಸಮಯವು 1001µs ರಷ್ಟು ಕಡಿಮೆಯಾಗಿದ್ದರೂ, ಒಟ್ಟು ಸಮಯವು ಕೇವಲ 771µs ರಷ್ಟು ಮಾತ್ರ ಕಡಿಮೆಯಾಗಿದೆ. ಕೆಳಗಿನ ವಿಭಾಗದಲ್ಲಿ ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯನ್ನು ಬಳಸಿ ನಾವು ಕಾರಣವನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

ಈ ಕಾರಣಕ್ಕಾಗಿ, ಮೈಕ್ರೋಬ್ಯಾಚಿಂಗ್ ಯಾವಾಗಲೂ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವುದಿಲ್ಲ.

ವಿಸ್ತರಿಸಿ

ಮೇಲಿನ figure batch sizes 4-128 ಗಾಗಿ DispatchOverlap‌ಗೆ ಹೋಲಿಸಿದಾಗ Microbatch‌ನ performance ಸುಧಾರಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. batch size 32 ಕ್ಕಿಂತ ಕಡಿಮೆ ಇದ್ದಾಗ, Microbatch performance ಅನ್ನು 5%-40% ಕಡಿಮೆಗೊಳಿಸುತ್ತದೆ. batch size 32 ಕ್ಕಿಂತ ದೊಡ್ಡದಾಗಿದ್ದಾಗ ಅಥವಾ ಸಮನಾಗಿದ್ದಾಗ, Microbatch performance ಅನ್ನು 10%-35% ಹೆಚ್ಚಿಸಬಹುದು.

EP8 ಮತ್ತು EP128 ರ ಹೋಲಿಕೆ

ಹಿಂದಿನ figure‌ಗೆ ಮರಳಿ EP8 ಮತ್ತು EP128 Microbatch ಅನ್ನು ಹೋಲಿಸೋಣ. EP8 ಒಟ್ಟು 1802µs ತೆಗೆದುಕೊಂಡಿತು, ಅದು EP128‌ನ 1896µs‌ಗಿಂತ ಸ್ವಲ್ಪ ಕಡಿಮೆ. ಮೇಲೆ ಉಲ್ಲೇಖಿಸಿದ Microbatch ನಿಂದ ಬಂದ ಹೆಚ್ಚಿದ kernel execution time ಹೊರತಾಗಿ, ಮುಖ್ಯ ವ್ಯತ್ಯಾಸಗಳು MoE computationಗೆ ಬಳಸುವ GroupGEMM, ಮತ್ತು ಎರಡು communication kernels, Dispatch ಮತ್ತು Combine‌ನಲ್ಲಿ ಇವೆ.

EP8 ನ GroupGEMM 555µs ತೆಗೆದುಕೊಂಡಿತು, ಆದರೆ EP128 ನ GroupGEMM 270µs ತೆಗೆದುಕೊಂಡಿತು, ಅರ್ಧದಷ್ಟು ಕಡಿಮೆಯಾಗಿದೆ. ಇದು ಬಹು-ನೋಡ್ ನಿಯೋಜನೆಯ ಪ್ರಮುಖ ಪ್ರಯೋಜನವಾಗಿದೆ.

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

ಗಮನಾರ್ಹವಾಗಿ ಹಿಂದುಳಿದ ಮತ್ತೊಂದು ಕರ್ನಲ್ GEMM ಆಗಿದೆ. ಮೈಕ್ರೋಬ್ಯಾಚ್ GEMM ಅನ್ನು 95µs ರಷ್ಟು ಹೆಚ್ಚಿಸಿದೆ. ಕೆಳಗಿನ ರೂಫ್‌ಲೈನ್ ವಿಭಾಗದಲ್ಲಿ ನಾವು GEMM ಅನ್ನು ಹೆಚ್ಚು ಆಳವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ಪ್ರಸ್ತುತ GEMM ಅನುಷ್ಠಾನವು ಇನ್ನೂ ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿಲ್ಲ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.

ರೂಫ್‌ಲೈನ್ (Roofline)

ಕರ್ನಲ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯು ಉತ್ತಮ ಸಾಧನವಾಗಿದೆ. ಇದರ ಸಮತಾಲದ ಅಕ್ಷವು ಅರಿತ್ಮಟಿಕ್ ಇಂಟೆನ್ಸಿಟಿ ಆಗಿದೆ, ಇದು ಮೆಮೊರಿ I/O ಬೈಟ್‌ಗಳಿಗೆ FLOP ನ ಅನುಪಾತವಾಗಿದೆ. ಸಮತಾಲದ ಅಕ್ಷದ ಮೌಲ್ಯವನ್ನು ಕರ್ನಲ್‌ನ ಶ್ಯುಮ್ಯಾಂಟಿಕ್ಸ್‌ನಿಂದ ನೇರವಾಗಿ ಲೆಕ್ಕಹಾಕಬಹುದು. ಲಂಬ ಅಕ್ಷವು ಸಾಧಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ, ಇದನ್ನು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸುಪ್ತತೆಯಿಂದ FLOP ಅನ್ನು ಭಾಗಿಸುವ ಮೂಲಕ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.

ಕರ್ನಲ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸೈದ್ಧಾಂತಿಕ ಮೇಲಿನ ಮಿತಿಯನ್ನು GPU ನ ನಿರ್ದಿಷ್ಟತೆಗಳಿಂದ ನೇರವಾಗಿ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. H100 ನ FP8 ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯು 1979 TFLOP/s ಆಗಿದೆ, ಇದನ್ನು ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯಲ್ಲಿ ಸಮತಾಲದ ರೇಖೆಯಾಗಿ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ. H100 ನ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ 3.35 TB/s ಆಗಿದೆ, ಇದನ್ನು ಮೂಲದ ಮೂಲಕ ಹಾದುಹೋಗುವ ರೇಖೆಯ ಇಳಿಜಾರಾಗಿ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ. ಈ ಎರಡು ರೇಖೆಗಳು ಕ್ರಮವಾಗಿ ಕಂಪ್ಯೂಟ್-ಬೌಂಡ್ ಮತ್ತು ಮೆಮೊರಿ-ಬೌಂಡ್ ಕರ್ನಲ್‌ಗಳಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಿತಿಗಳನ್ನು ನೀಡುತ್ತವೆ.

ಕೆಳಗೆ, ನಾವು ಗ್ರೂಪ್‌ಜೆಎಂಎಂ (GroupGEMM) ಮತ್ತು ಜೆಎಂಎಂ (GEMM) ಕರ್ನಲ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ.

ಗ್ರೂಪ್‌ಜೆಎಂಎಂ

MoE ನಲ್ಲಿರುವ GroupGEMM ಕರ್ನಲ್ ಕೆಳಗಿನ ಗಣನೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಒಟ್ಟು g ಗುಂಪುಗಳಿವೆ, i-ನೇ ಗುಂಪು m_i ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಇದು [m_i, k] x [k, n] -> [m_i, n] ನ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಪ್ರತಿ ಗುಂಪಿನಲ್ಲಿರುವ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯು ಒಂದೇ ಆಗಿರುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಇದನ್ನು m_i = m ಎಂದು ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಆಗ GroupGEMM ಗಾಗಿ FLOP ಎಣಿಕೆಯು 2 * g * m * k * n ಆಗಿದೆ, ಮತ್ತು ಮೆಮೊರಿ I/O ಬೈಟ್‌ಗಳು g * (m * k + n * k + m * n) ಆಗಿರುತ್ತವೆ.

DeepSeek-V3/R1 ಮಾದರಿಯಲ್ಲಿ, 256 ತಜ್ಞರಿದ್ದಾರೆ, ಮತ್ತು ಪ್ರತಿ ಟೋಕನ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರಕ್ಕಾಗಿ 8 ತಜ್ಞರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. 128 ರ ಬ್ಯಾಚ್ ಗಾತ್ರ, 2 ರ ಪ್ರಶ್ನೆ ಉದ್ದ, EP128 DP128 ಕಾನ್ಫಿಗರೇಶನ್ ಬಳಸಿ, ಪ್ರತಿ ತಜ್ಞರು ಸ್ವೀಕರಿಸುವ ಟೋಕನ್‌ಗಳ ಸರಾಸರಿ ಸಂಖ್ಯೆ (ಅಂದರೆ, m) 128 * 2 * 8 * 128 / 256 = 1024 ಆಗಿದೆ. ಅದೇ ರೀತಿ, ನಾವು ಇತರ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಿಗಾಗಿ m ಅನ್ನು ಲೆಕ್ಕಹಾಕಬಹುದು.

ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಾಗಿ ನಾವು DeepGEMM ನ GroupGEMM ಅನುಷ್ಠಾನವನ್ನು ಬಳಸಿದ್ದೇವೆ. ಟೆಸ್ಟ್ ಪಾಯಿಂಟ್‌ಗಳು TP1 ಮತ್ತು ಬ್ಯಾಚ್ ಗಾತ್ರಗಳು 1-128 ರೊಂದಿಗಿನ EP8, EP16, EP32, EP64, EP128 ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಸಂಯೋಜನೆಗಳನ್ನು ಒಳಗೊಂಡಿವೆ.

ವಿಸ್ತರಿಸಿ

ಮೇಲಿನ ಚಿತ್ರವು ವಿವಿಧ EP ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಅಡಿಯಲ್ಲಿ GroupGEMM ಗಾಗಿ ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ವಿಭಿನ್ನ EP ಯು ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ ಗುಂಪುಗಳಿಗೆ ಅನುರೂಪವಾಗಿದೆ. ಈ ಚಿತ್ರವು ಬಹುತೇಕ ಅತಿಕ್ರಮಿಸುವ ಕಾರ್ಯಕ್ಷಮತೆಯ ರೇಖೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಇದು GroupGEMM ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ಒಟ್ಟು ಟೋಕನ್ ಎಣಿಕೆಯಿಂದ (g * m ಎಂದು ಪ್ರತಿನಿಧಿಸಲಾಗಿದೆ) ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.

ಪ್ರತಿ EP ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ಪ್ರತಿ GPU ಗೆ 128 ರ ಬ್ಯಾಚ್ ಗಾತ್ರಕ್ಕೆ ಅನುರೂಪವಾಗಿರುವ ಡೇಟಾ ಬಿಂದುಗಳನ್ನು ನಕ್ಷತ್ರಗಳು ಗುರುತಿಸುತ್ತವೆ. ಈ ನಕ್ಷತ್ರದ ಚಿಹ್ನೆಯ ಡೇಟಾ ಬಿಂದುಗಳನ್ನು ಹೋಲಿಸಿದರೆ, EP ಹೆಚ್ಚಾದಂತೆ (ಮತ್ತು DP ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಹೆಚ್ಚಾದಂತೆ), ಪ್ರತಿ ತಜ್ಞರ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆ m ಕೂಡ ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೋಡಬಹುದು. EP8 ನಲ್ಲಿ, m=128, ಆದರೆ EP128 ನಲ್ಲಿ, m=2048 ಆಗಿದೆ.

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

GEMM

GEMM ಕರ್ನಲ್ ಮಾದರಿಯಲ್ಲಿನ ಲೀನಿಯರ್ ಪ್ರೊಜೆಕ್ಷನ್‌ಗಳಿಗೆ ಅನುರೂಪವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ Q/K/V/O ಪ್ರೊಜೆಕ್ಷನ್. [m, k] x [k, n] -> [m, n] ನ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರಕ್ಕಾಗಿ, FLOP ಎಣಿಕೆಯು 2 * m * k * n ಆಗಿದೆ, ಮತ್ತು ಮೆಮೊರಿ I/O ಬೈಟ್‌ಗಳು m * k + n * k + m * n ಆಗಿರುತ್ತವೆ. ನಾವು 1-128 ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಿಗೆ ಸುಪ್ತತೆಯನ್ನು ಸಹ ಪರೀಕ್ಷಿಸಬಹುದು.

ವಿಸ್ತರಿಸಿ

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

ಮೈಕ್ರೋಬ್ಯಾಚ್

ಮೈಕ್ರೋಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ಬಳಸುವಾಗ, ನಾವು ಬ್ಯಾಚ್ ಅನ್ನು ಸಮವಾಗಿ ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ. ಮೇಲಿನ ಎರಡು ಚಿತ್ರಗಳಿಂದ, m ಯು m/2 ಆದಾಗ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರದ ದಕ್ಷತೆಯು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೋಡಬಹುದು. ಆದ್ದರಿಂದ, m/2 ಗಾತ್ರದ ಎರಡು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು m ಗಾತ್ರದ ಒಂದು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಮಲ್ಟಿ-ಟೋಕನ್ ಪ್ರಿಡಿಕ್ಷನ್

ಈ ಲೇಖನದಾದ್ಯಂತ, ಊಹಾತ್ಮಕ ಡಿಕೋಡಿಂಗ್‌ಗಾಗಿ ಮಲ್ಟಿ-ಟೋಕನ್ ಪ್ರೆಡಿಕ್ಷನ್ (MTP) ಅನ್ನು ಬಳಸುವುದನ್ನು ನಾವು ಊಹಿಸಿದ್ದೇವೆ. MTP ಪ್ರತಿ ವಿನಂತಿಗೆ ಪ್ರಶ್ನೆಯ ಉದ್ದವನ್ನು 1 ರಿಂದ 2 ಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರಕ್ಕಾಗಿ, ಇದು m ಅನ್ನು m * 2 ಕ್ಕೆ ಬದಲಾಯಿಸುವುದಕ್ಕೆ ಸಮಾನವಾಗಿರುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರದ ದಕ್ಷತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, ನಾವು MLA ಗಾಗಿ ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯನ್ನು ಚಿತ್ರಿಸಿದರೆ, ಪ್ರಶ್ನೆಯ ಉದ್ದವನ್ನು ಹೆಚ್ಚಿಸುವುದು MLA ಕರ್ನಲ್ ದಕ್ಷತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.

ಆದ್ದರಿಂದ, ಮಾದರಿ ದಕ್ಷತೆಯಲ್ಲಿ MTP ನ ಬಳಕೆಯು ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತದೆ.

ಅನುಷ್ಠಾನ & ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು

ಈ ವಿಭಾಗದಲ್ಲಿ, ನಮ್ಮ DeepSeek-V3/R1 ಮಾದರಿಗಾಗಿ ನಾವು ಕೆಲವು ಅನುಷ್ಠಾನ ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್ ವಿವರಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತೇವೆ.

ಕ್ವಾಂಟೈಸೇಶನ್

DeepSeek-V3/R1 ಅನ್ನು ಪ್ರತಿ-ಬ್ಲಾಕ್ ಕ್ವಾಂಟೈಸೇಶನ್ ಸ್ಕೀಮ್ ಬಳಸಿ FP8 ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ತರಬೇತಿ ನೀಡಲಾಗಿದೆ, ತೂಕಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಕ್ವಾಂಟೈಸ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಆಕ್ಟಿವೇಷನ್‌ಗಳನ್ನು ಆನ್-ದಿ-ಫ್ಲೈ ಕ್ವಾಂಟೈಸ್ ಮಾಡಲಾಗಿದೆ. ಪ್ರತಿ ಚಾನೆಲ್ ಅಥವಾ ಪ್ರತಿ ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ಗೆ ಸ್ಕೇಲಿಂಗ್ ಅಂಶವನ್ನು ಸ್ಥಿರವಾಗಿ ಲೆಕ್ಕಹಾಕುವ ಬದಲು, ಆಕ್ಟಿವೇಷನ್‌ಗಳಿಗಾಗಿ 128-ಎಲಿಮೆಂಟ್ ವೆಕ್ಟರ್‌ಗಳಾದ್ಯಂತ ಮತ್ತು ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ಗಳಿಗಾಗಿ 128x128 ಎಲಿಮೆಂಟ್ ಟೈಲ್‌ಗಳಾದ್ಯಂತ ಸ್ಕೇಲಿಂಗ್ ಅಂಶಗಳನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ, ಇದು ಕ್ವಾಂಟೈಸೇಶನ್ ಕಾರಣದಿಂದಾಗುವ ನಿಖರತೆಯ ಅವನತಿಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

Perplexity ನಲ್ಲಿ, ಅನುಮಾನವನ್ನು ಬೆಂಬಲಿಸಲು ನಾವು CUDA ಮತ್ತು Triton ಕರ್ನಲ್‌ಗಳ ಮಿಶ್ರಣವನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ, ಅತ್ಯಂತ ಕಾರ್ಯಕ್ಷಮತೆ-ಸಂವೇದನಾಶೀಲ ಮತ್ತು ವಿರಳವಾಗಿ ಮಾರ್ಪಡಿಸಿದ ಕರ್ನಲ್‌ಗಳಿಗಾಗಿ (ಗಮನ ಮತ್ತು GEMM ನಂತಹ) CUDA ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು Triton ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಆಕ್ಟಿವೇಷನ್, ಸಾಮಾನ್ಯೀಕರಣ ಮತ್ತು ಯುಟಿಲಿಟಿ ಕರ್ನಲ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಬ್ಲಾಕ್ ಕ್ವಾಂಟೈಸೇಶನ್ ಸ್ಕೀಮ್‌ಗೆ ಕರ್ನಲ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಹೊಂದಿಸಲು Triton ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿದೆ.

linear ಮತ್ತು MoE layers‌ಗಾಗಿ, ನಾವು Deep GEMM kernels‌ಗಳನ್ನು ನಮ್ಮ ಸ್ವಂತ Triton GEMM kernels‌ಗಳೊಂದಿಗೆ ಮಿಶ್ರಣ ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಕೆಲವು matrix dimensions ಮತ್ತು ಕಡಿಮೆ batch sizes‌ಗಳಲ್ಲಿ Split-K ಕಡಿಮೆ latency ನೀಡುತ್ತದೆ ಎಂದು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. unquantized layer ಒಂದು (M, K) x (K, N) multiplication ಅನ್ನು ನಿರ್ವಹಿಸಿದರೆ, block quantization‌ಗಾಗಿ ಅದಕ್ಕೆ (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) scaling factor ಅಗತ್ಯವಿರುತ್ತದೆ. block quantizationಗೆ, activations‌ಗಾಗಿ scaling factors ಅನ್ನು ಪೂರ್ವ-ಮಾಪನ ಮಾಡುವ ಬದಲು, on-the-fly ಆಗಿ ಗಣನೆ ಮಾಡಲಾಗುತ್ತದೆ. activation scaling factors ಅನ್ನು K boyunca ಮಾತ್ರ aggregate ಮಾಡಲಾಗುವುದರಿಂದ ಮತ್ತು M dimension boyunca ಅಲ್ಲದಿರುವುದರಿಂದ, ಈ scheme ಅನ್ನು ಬೆಂಬಲಿಸಲು kernels‌ಗಳಿಗೆ ಕೇವಲ ಸಣ್ಣ ಬದಲಾವಣೆಗಳಷ್ಟೇ ಅಗತ್ಯವಿರುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

DeepSeek-V3/R1 ಬಳಸುವ SiLU ಆಕ್ಟಿವೇಷನ್ ಫಂಕ್ಷನ್‌ಗೆ CUDA ಗ್ರಾಫ್‌ಗಳು, ಬ್ಲಾಕ್ ಕ್ವಾಂಟೈಸೇಶನ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಆಗಿ ರೂಟ್ ಮಾಡಲಾದ ಟೋಕನ್ ಎಣಿಕೆಗಳನ್ನು ಬೆಂಬಲಿಸಲು ಗಮನಾರ್ಹ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿತ್ತು. ಬ್ಲಾಕ್ ಕ್ವಾಂಟೈಸೇಶನ್ ಸಮಸ್ಯಾತ್ಮಕವಾಗಬಹುದು ಏಕೆಂದರೆ ಇದು ಸಮತಾಲದ ಕಡಿತಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಆದಾಗ್ಯೂ ಕರ್ನಲ್ ಈಗಾಗಲೇ ತನ್ನ ಹಿಡನ್ ಆಯಾಮದ ಉದ್ದಕ್ಕೂ ಆಕ್ಟಿವೇಷನ್‌ಗಳನ್ನು 1024 ಅಂಶಗಳ ಬ್ಲಾಕ್‌ಗಳಾಗಿ ಚಂಕ್ ಮಾಡಿದೆ. ಒಂದು ಬ್ಲಾಕ್ ಒಳಗೆ, ದೊಡ್ಡ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಹಾಕಲು ಕ್ವಾಂಟೈಸ್ ಮಾಡಬೇಕಾದ ಟೆನ್ಸರ್ ಅನ್ನು 128 ರ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಮತ್ತಷ್ಟು ಚಂಕ್ ಮಾಡಲಾಯಿತು, Triton ಸಮರ್ಥ ಕ್ರಾಸ್-ವಾರ್ಪ್ ಗರಿಷ್ಠ ಕಡಿತಗಳನ್ನು ಸೃಷ್ಟಿಸುವುದರೊಂದಿಗೆ, ಕನಿಷ್ಠ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ.

CUDA graphs ಅಡಿಯಲ್ಲಿ MoE routing ಅನ್ನು ಬೆಂಬಲಿಸಲು, kernels‌ಗಳು upper bound token counts ಅನ್ನು ಹಿಡಿದಿಡಲು allocate ಮಾಡಲಾದ buffers‌ನ size ಆಧಾರವಾಗಿ ಕೆಲಸವನ್ನು schedule ಮಾಡುವ ಬದಲು, ಪ್ರತಿ expert‌ಗೆ tokens ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುವ routing information ಬಗ್ಗೆ ತಿಳಿದಿರಬೇಕು. ನಾವು input tensor dimensions ಆಧಾರವಾಗಿ problem ಅನ್ನು split ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ populated tokens ಎಷ್ಟು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು routing information ಅನ್ನು ಓದುವ fixed number of persistent kernels ಅನ್ನು launch ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ activations ಅನ್ನು process ಮಾಡುವ ಕೆಲಸವನ್ನು dynamic ಆಗಿ split ಮಾಡುತ್ತೇವೆ.

ನಾವು ಈಗಾಗಲೇ ನಮ್ಮ ಕೆಲವು ಕರ್ನಲ್‌ಗಳನ್ನು FlashInfer ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ನಮ್ಮ ಹೆಚ್ಚಿನ ಕೋಡ್ ಅನ್ನು ಓಪನ್-ಸೋರ್ಸ್ ಮಾಡುತ್ತೇವೆ.

MLA ಲೇಯರ್

MLA ಲೆಕ್ಕಾಚಾರಕ್ಕಾಗಿ ನಾವು FlashInfer ಅನ್ನು ಬಳಸುತ್ತೇವೆ. FlashInfer ಹೊಂದಿಕೊಳ್ಳುವ ಪುಟ ಟೇಬಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮತ್ತು ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ನಾವು q_a_proj ಮತ್ತು kv_a_proj ಅನ್ನು ಒಂದೇ qkv_a_proj ಆಗಿ ಫ್ಯೂಸ್ ಮಾಡಿದ್ದೇವೆ. ಸುಪ್ತತೆಯು 15.4 µs + 14.8 µs = 30.2 µs ನಿಂದ 16.7 µs ಗೆ ಇಳಿಯಿತು.

ನಾವು kv_b_proj ಅನ್ನು ಎರಡು ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇವೆ, k_b_proj ಮತ್ತು v_b_proj. ಈ ಎರಡು ಮ್ಯಾಟ್ರಿಕ್ಸ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಲೆಕ್ಕಾಚಾರಗಳಿಗಾಗಿ ನಾವು FP8 ಬ್ಲಾಕ್ ಕ್ವಾಂಟೈಸ್ಡ್ BMM ಕರ್ನಲ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ.

Cuda ಗ್ರಾಫ್

Cuda ಗ್ರಾಫ್ ಕರ್ನಲ್ ಲಾಂಚ್ ಮಾಡುವ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ. ನಾವು ಪ್ರತಿ ಬ್ಯಾಚ್ ಗಾತ್ರಕ್ಕೆ Cuda ಗ್ರಾಫ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ.

ನಮ್ಮ AllToAll ಕರ್ನಲ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮೊದಲು, AllToAll ಸಂವಹನಕ್ಕಾಗಿ ನಾವು torch.all_to_all_single() ಅನ್ನು ಬಳಸಿದ್ದೆವು. ಈ ಕಾರ್ಯಾಚರಣೆಗೆ ಎಲ್ಲಾ GPU ಗಳು ಒಂದೇ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಬಳಸುವ ಅಗತ್ಯವಿದೆ. ಆದಾಗ್ಯೂ, ವಿಭಿನ್ನ DP ಗುಂಪುಗಳು ವಿಭಿನ್ನ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳನ್ನು ರನ್ ಮಾಡಬಹುದು.

ವಿಭಿನ್ನ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳನ್ನು ಬಳಸುವ ವಿಭಿನ್ನ DP ಗುಂಪುಗಳೊಂದಿಗೆ all_to_all_single() ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಎಲ್ಲಾ DP ಗುಂಪುಗಳಲ್ಲಿ ಗರಿಷ್ಠ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಪಡೆಯಲು ಪ್ರತಿ ಮಾದರಿ ರನ್ ಮೊದಲು ನಾವು ಮೊದಲು allreduce() ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ. ನಂತರ ನಾವು ಎಲ್ಲಾ DP ಗುಂಪುಗಳು ರನ್ ಮಾಡಲು ಈ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಬಳಸುವಂತೆ ಮಾಡಿದ್ದೇವೆ.

ಈ ವಿಧಾನವು ನಾವು Cuda ಗ್ರಾಫ್ ಅನ್ನು ಬಳಸಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆಯಾದರೂ, ಇದು ಮೂರು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಇದಕ್ಕೆ ಹೆಚ್ಚುವರಿ allreduce() ಕಾರ್ಯಾಚರಣೆಯ ಅಗತ್ಯವಿದೆ. ಎರಡನೆಯದಾಗಿ, ಸಣ್ಣ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳನ್ನು ಹೊಂದಿರುವ DP ಗುಂಪುಗಳನ್ನು ಪ್ಯಾಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. ಮೂರನೆಯದಾಗಿ, ಇದು ನಮ್ಮ ಅನುಷ್ಠಾನ ಕೋಡ್ ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ.

ನಮ್ಮ ಸ್ವಂತ AllToAll ಕರ್ನಲ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿದ ನಂತರ, ಎಲ್ಲಾ GPU ಗಳು ಒಂದೇ ಬ್ಯಾಚ್ ಗಾತ್ರವನ್ನು ಬಳಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚುವರಿ allreduce() ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಥವಾ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳನ್ನು ಪ್ಯಾಡ್ ಮಾಡುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

MoE ರೂಟರ್

MoE ರೂಟರ್ ಅನ್ನು Triton ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಪ್ರಮಾಣಿತ ಲೈಬ್ರರಿಯಿಂದ ಪಡೆದ ಮಾರ್ಪಡಿಸಿದ ವಿಂಗಡನೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ ಮತ್ತು ಇದು ವಿಂಗಡಿಸಲಾದ ಅಂಶಗಳ ಸೂಚ್ಯಂಕಗಳನ್ನು ಸಹ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. Top-K ಗುಂಪು ಎಲ್ಲಾ ತಜ್ಞರ ಗುಂಪಿಗೆ ಸಮಾನವಾಗಿರುವ DeepSeek ಮಾರ್ಗಗಳ ವಿಶೇಷ ಸಂದರ್ಭವಾಗಿ Mixtral ರೂಟಿಂಗ್ ಇರುವುದರಿಂದ, ಅನುಷ್ಠಾನವನ್ನು ಎಲ್ಲಾ MoE ಮಾದರಿಗಳಾದ್ಯಂತ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ. ಸ್ಪೇರ್ಸ್ ಕರ್ನಲ್‌ಗಳು Top-K ಸೂಚ್ಯಂಕಗಳು ಮತ್ತು ಸ್ಕೋರ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದರೆ ಆಲ್-ಟು-ಆಲ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುವ ಡೆನ್ಸ್ ಡಿಸ್ಪಾಚ್/ಕಂಬೈನ್ ಸ್ಕೀಮ್‌ಗಳಿಗೆ ಪ್ರತಿ-ಟೋಕನ್ ಆಧಾರದ ಬದಲಿಗೆ ಪ್ರತಿ-ತಜ್ಞರ ಆಧಾರದ ಮೇಲೆ ರೂಟಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಭವಿಷ್ಯದ ಕೆಲಸ

ಭವಿಷ್ಯದ ಕೆಲಸದಲ್ಲಿ, DeepSeek ಮಾದರಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮತ್ತಷ್ಟು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ.

ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಮುಂದಿನ ಆಪ್ಟಿಮೈಸೇಶನ್ ಪ್ರೆಫಿಲ್ ಡಿಸಾಗ್ರಿಗೇಷನ್ ಆಗಿದೆ. DeepSeek-V3/R1 ಮಾದರಿಯ ಪ್ರೆಫಿಲ್ ಹಂತ ಮತ್ತು ಡಿಕೋಡ್ ಹಂತವು ಬಹಳ ವಿಭಿನ್ನವಾದ ಗಣನಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ. ಎರಡೂ ವಿಭಿನ್ನ ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಗಳು ಮತ್ತು ನಿಯೋಜನಾ ಯೋಜನೆಗಳನ್ನು ಬಳಸಬಹುದು.

MLA Layerಗಾಗಿ, Decode phase‌ನಲ್ಲಿ, MLA computation‌ನ FLOP count ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು Matrix Absorption ಅನ್ನು ಬಳಸುತ್ತೇವೆ. Prefill phase‌ನಲ್ಲಿ, ಮೊದಲು latent vector ಅನ್ನು K/V space‌ಗೆ project ಮಾಡಿ ನಂತರ Multi-Head Attention (MHA) form‌ನಲ್ಲಿ ಗಣನೆ ಮಾಡುವುದು ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಪ್ರೆಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ಒಂದೇ GPU ನಲ್ಲಿ ರನ್ ಆದರೆ, ಡಿಕೋಡ್ ಔಟ್‌ಪುಟ್ ವೇಗದ ಮೇಲೆ ಪ್ರೆಫಿಲ್‌ನ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಪ್ರೆಫಿಲ್‌ಗಾಗಿ ಪ್ರಶ್ನೆಯನ್ನು ಅನೇಕ ಚಂಕ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಲು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಚಂಕ್ಡ್ ಪ್ರೆಫಿಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. KV ಕ್ಯಾಶ್ ಲ್ಯಾಲೆಂಟ್ ವೆಕ್ಟರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದರಿಂದ, MLA ಅನ್ನು MHA ರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.

MoE ಲೇಯರ್‌ಗಾಗಿ, ಡಿಕೋಡ್ ಹಂತದಲ್ಲಿ, ಪ್ರತಿ ತಜ್ಞರಿಗೆ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ದೊಡ್ಡ EP ಮತ್ತು DP ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದರಿಂದ GroupGEMM ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು. ಪ್ರೆಫಿಲ್ ಹಂತದಲ್ಲಿ, ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯು ಈಗಾಗಲೇ ದೊಡ್ಡದಾಗಿರುವುದರಿಂದ, GroupGEMM ಈಗಾಗಲೇ ಕಂಪ್ಯೂಟ್-ಬೌಂಡ್ ಆಗಿದೆ. ಆದ್ದರಿಂದ, ಪ್ರೆಫಿಲ್‌ಗಾಗಿ, ನಾವು ಸಣ್ಣ EP ಮತ್ತು DP ಅನ್ನು ಬಳಸಬಹುದು.

ಪ್ರೆಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ಒಂದೇ GPU ನಲ್ಲಿ ರನ್ ಆದರೆ, ಯಾವುದೇ DP ಗುಂಪು ಪ್ರೆಫಿಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಿರುವವರೆಗೆ, ಎಲ್ಲಾ GPU ಗಳಲ್ಲಿ MoE ಲೇಯರ್‌ಗಳ ಸುಪ್ತತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಇದು ಡಿಕೋಡ್ ಔಟ್‌ಪುಟ್ ವೇಗದ ಮೇಲೆ ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ಪ್ರೆಫಿಲ್ ಡಿಸಾಗ್ರಿಗೇಷನ್ ಹೊರತುಪಡಿಸಿ, ನಾವು ಈ ಕೆಳಗಿನ ಅಂಶಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಸಹ ಯೋಜಿಸುತ್ತೇವೆ:

AllToAll ಕಾರ್ಯಕ್ಷಮತೆ: ನಮ್ಮ AllToAll ಕರ್ನಲ್ ಪ್ರಸ್ತುತ Infiniband ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನ 1/3 ಅನ್ನು ಮಾತ್ರ ಸಾಧಿಸಬಹುದು. ನಾವು ಈ ಕರ್ನಲ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.

EAGLE-style speculative decoding: ಮೇಲಿನ data‌ನಲ್ಲಿ, speculative decoding ಬಳಸಿ 1 token ಅನ್ನು predict ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾವು ಊಹಿಸಿದೆವು. EAGLE ಒಂದು tree structure ಅನ್ನು ಬಳಸಿಕೊಂಡು multiple tokens ಅನ್ನು predict ಮಾಡಬಹುದು, acceptance length ಅನ್ನು ಸುಧಾರಿಸಿ, output speed ಅನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು.

GEMM ಕರ್ನಲ್: ಹಿಂದೆ ತೋರಿಸಿದ ರೂಫ್‌ಲೈನ್ ಮಾದರಿಯಲ್ಲಿ, GEMM ಕರ್ನಲ್‌ನ ದಕ್ಷತೆಯು ಸೈದ್ಧಾಂತಿಕ ಮಿತಿಯಿಂದ ಇನ್ನೂ ದೂರದಲ್ಲಿದೆ ಎಂದು ನಾವು ಕಾಣಬಹುದು. ನಾವು ಈ ಕರ್ನಲ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.

GB200 NVL72: NVIDIA‌ನ ಇತ್ತೀಚಿನ GB200 NVL72 solution‌ನಲ್ಲಿ, 72 Blackwell GPUs ಗಳು high-speed NVLink ಮೂಲಕ interconnect ಆಗಿವೆ. MoE architecture models‌ಗಳಿಗೆ, ಇದು ಬಹಳ ದೊಡ್ಡ ಅವಕಾಶವೂ ಮತ್ತು ಸವಾಲೂ ಆಗಿದೆ.

ತೀರ್ಮಾನ

DeepSeek MoE ಮಾದರಿಗಳ ಮಲ್ಟಿ-ನೋಡ್ ನಿಯೋಜನೆಯು ಡೆನ್ಸ್ LLM ಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಸಾಧ್ಯವಾದದ್ದನ್ನು ಸಾಧಿಸುತ್ತದೆ: ಥ್ರೂಪುಟ್ ಮತ್ತು ಸುಪ್ತತೆ ಎರಡನ್ನೂ ಏಕಕಾಲದಲ್ಲಿ ಸುಧಾರಿಸುವುದು. ಹೆಚ್ಚಿನ GPU ಗಳಲ್ಲಿ ತಜ್ಞರನ್ನು ವಿತರಿಸುವ ಮೂಲಕ, ಪ್ರತಿ ಸಾಧನಕ್ಕೆ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಒತ್ತಡವನ್ನು ನಾವು ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ, ಇದು ವೇಗವಾದ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಿಸ್ಟಮ್ ಥ್ರೂಪುಟ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಏಕ-ನೋಡ್ ನಿಯೋಜನೆಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಸಮಾನ ಔಟ್‌ಪುಟ್ ವೇಗದಲ್ಲಿ 5x ವರೆಗೆ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಅನ್ನು ಸಾಧಿಸುವ EP128 ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ನಮ್ಮ ಪ್ರಯೋಗಗಳು ತೋರಿಸುತ್ತವೆ.

ಮೈಕ್ರೋ-ಬ್ಯಾಚಿಂಗ್‌ನಂತಹ ಕಂಪ್ಯೂಟೇಶನ್-ಕಮ್ಯುನಿಕೇಷನ್ ಓವರ್‌ಲ್ಯಾಪಿಂಗ್ ತಂತ್ರಗಳು ಮಲ್ಟಿ-ನೋಡ್ ಸಂವಹನ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ನಮ್ಮ ಅನುಷ್ಠಾನವು 40% ರಷ್ಟು ವೇಗವನ್ನು ತೋರಿಸುತ್ತದೆ. ನಮ್ಮ ಕಸ್ಟಮ್ AllToAll ಸಂವಹನ ಕರ್ನಲ್‌ಗಳು ಮತ್ತು ಆಪ್ಟಿಮೈಸ್ಡ್ ಕರ್ನಲ್ ಅನುಷ್ಠಾನಗಳು 671B ಪ್ಯಾರಾಮೀಟರ್ ಮಾದರಿಯ ಸಮರ್ಥ ನಿಯೋಜನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿವೆ.

MoE ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ತಮ್ಮ ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸುತ್ತಿರುವಂತೆ, ಈ ನಿಯೋಜನಾ ತಂತ್ರಗಳು ಅಂತಹ ಮಾದರಿಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಸ್ಕೇಲಿಂಗ್ ಮಾಡಲು ಮೌಲ್ಯಯುತ ಒಳನೋಟಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ.

ಉಲ್ಲೇಖಗಳು

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

DeepSeek-V3/R1 ಅನುಮಾನ ಸಿಸ್ಟಮ್ ಅವಲೋಕನ

Megatron-LM: ಮಾದರಿ ಸಮಾನಾಂತರತೆಯನ್ನು ಬಳಸಿ ಬಹು-ಬಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್ ಭಾಷಾ ಮಾದರಿಗಳಿಗೆ ತರಬೇತಿ ನೀಡುವುದು

EAGLE: ಊಹಾತ್ಮಕ ಮಾದರಿಯು ವೈಶಿಷ್ಟ್ಯದ ಅನಿಶ್ಚಿತತೆಯನ್ನು ಮರುಚಿಂತನೆ ಮಾಡುವ ಅಗತ್ಯವಿದೆ

ಉಲ್ಲೇಖ

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}