ಬೇರ್ಪಡಿಸಿದ ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್

ಇನ್‌ಪುಟ್ ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು, LLM ಇನ್ಫೆರೆನ್ಸ್ ಅನ್ನು ಎರಡು ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್. ಡಿಕೋಡ್ ಹಂತವನ್ನು ಪ್ರವೇಶಿಸುವ ಮೊದಲು ಪ್ರಿಫಿಲ್ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಮೇಲೆ ರನ್ ಆಗುತ್ತದೆ, ಕೆವಿ (KV) ಕ್ಯಾಶ್‌ಗಳನ್ನು ಜನರೇಟ್ ಮಾಡುತ್ತದೆ, ತದನಂತರ ಟೋಕನ್‌ಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಉತ್ಪಾದಿಸುವ ಡಿಕೋಡ್ ಹಂತವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಒಂದೇ ಡಿಕೋಡ್ ಹಂತವು ಸಾಮಾನ್ಯವಾಗಿ ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳವರೆಗೆ ರನ್ ಆದರೆ, ಪ್ರಿಫಿಲ್ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಂದೇ ಸಾಧನಗಳಲ್ಲಿ ರನ್ ಮಾಡಿದರೆ, ಪ್ರಿಫಿಲ್ ಅನ್ನು ಡಿಕೋಡ್‌ನೊಂದಿಗೆ ಬೆರೆಸುವುದು ಡಿಕೋಡ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಂದಿಸುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಪ್ರಿಫಿಲ್ ಥ್ರೂಪುಟ್ ಮತ್ತು ಡಿಕೋಡ್ ಲೇಟೆನ್ಸಿ ಎರಡನ್ನೂ ಗರಿಷ್ಠಗೊಳಿಸಲು ಪ್ರತ್ಯೇಕ ಸಾಧನಗಳಲ್ಲಿ ರನ್ ಮಾಡುವ, ಬೇರ್ಪಡಿಸಿದ ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ರೂಪದಲ್ಲಿ ಸ್ಥಾಪಿತವಾದ ಪರಿಹಾರವನ್ನು ಅನ್ವೇಷಿಸುತ್ತೇವೆ.

ಪ್ರಿಫಿಲ್ ವರ್ಸಸ್ ಡಿಕೋಡ್ ಕಾರ್ಯಕ್ಷಮತೆ

ವಿಶಿಷ್ಟವಾದ LLM ಸರ್ವಿಂಗ್ ಎಂಜಿನ್‌ನಲ್ಲಿ, ಬ್ಯಾಚ್ ಶೆಡ್ಯೂಲರ್ ಮಾದರಿಯ ಪ್ರತಿಯೊಂದು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಹಂತದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ವಿನಂತಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಒಂದೇ ಸಾಧನ ಅಥವಾ ನೋಡ್‌ನಲ್ಲಿ ರನ್ ಮಾಡುವಾಗ, ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ವಿನಂತಿ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಬ್ಯಾಚ್ ಮಾಡಲಾಗುತ್ತದೆ. ಅನುಕ್ರಮ ಉದ್ದದ ಉದ್ದಕ್ಕೂ ಒಟ್ಟುಗೂಡಿಸುವ ಅಟೆನ್ಷನ್ ವೆಚ್ಚವು, KV ಕ್ಯಾಶ್‌ನಲ್ಲಿರುವ ನಮೂದುಗಳ ಉದ್ದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ಎರಡಕ್ಕೂ ಹೆಚ್ಚಾಗುತ್ತದೆ (kv_len). ಡಿಕೋಡ್ ವಿನಂತಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಟೋಕನ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ (qo_len=1), ಅನುಕ್ರಮದ ಟೋಕನ್‌ಗಳ ಮೇಲೆ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಇತರ ಲೇಯರ್‌ಗಳ ಮೂಲಕ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ. ಪ್ರಿಫಿಲ್ ವಿನಂತಿಗಳು ದಟ್ಟವಾದ ಲೇಯರ್‌ಗಳ ಮೂಲಕ ಗಮನಾರ್ಹ ವೆಚ್ಚದಲ್ಲಿ ಸಾವಿರಾರು ಅಥವಾ ಹತ್ತಾರು ಸಾವಿರ ಟೋಕನ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ (ದೊಡ್ಡ qo_len).

ಒಂದು forward pass ನ latency ಮೇಲೆ attention ಸಮಯದಲ್ಲಿ KV cache ನಿಂದ ಹಿಂಪಡೆಯುವ tokens ಸಂಖ್ಯೆ (kv_len) ಗಿಂತ dense layers ಮೂಲಕ ಸಾಗುವ ಸ್ವತಂತ್ರ tokens ಸಂಖ್ಯೆ (qo_len) ಹೆಚ್ಚು ಪ್ರಬಲವಾಗಿ ಪ್ರಭಾವ ಬೀರುತ್ತದೆ. Attention requests ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿಯೂ ಮತ್ತು sequence lengths ಗೆ ಅನುಪಾತವಾದ kv_len ಯಲ್ಲಿಯೂ ಎರಡನ್ನೂ parallelize ಮಾಡಬಹುದು, ಇದರಿಂದ ಉತ್ತಮ utilization ದೊರೆಯುತ್ತದೆ. Prefill compute bound ಆಗಿದೆ: qo_len ಹೆಚ್ಚು ಇದ್ದಾಗ, GEMM kernels ಗಳು modern GPUs ನ compute capabilities ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು M dimension sepanjang ಸಾಕಷ್ಟು blocks allocate ಮಾಡಬಹುದು. Decode memory bound ಆಗಿದೆ: ಸಾಮಾನ್ಯವಾಗಿ batch sizes ಕಡಿಮೆ ಇರುವುದರಿಂದ, M along inputs ಗಳ ಸಂಖ್ಯೆ ಸಾಮಾನ್ಯವಾಗಿ ಚಿಕ್ಕದು, ಒಂದೇ block ಗೆ ಸಾಕಾಗುತ್ತದೆ. ಕಡಿಮೆ token batch sizes ಗಾಗಿ Split-K GEMM kernels SM utilization ಅನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ caches ಮತ್ತು matrix multiplication units ಸಾಮಾನ್ಯವಾಗಿ under-utilized ಆಗಿಯೇ ಇರುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

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

ವಿಸ್ತರಿಸಿ

ವಿಸ್ತರಿಸಿ

ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ನಿರ್ವಹಿಸಲು ಪ್ರತ್ಯೇಕ ನೋಡ್‌ಗಳ ಸೆಟ್ ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು. ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್ ಅನ್ನು ಬಹು ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ಥ್ರೂಪುಟ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ಪ್ರಿಫಿಲ್‌ಗಾಗಿ ಸಾಕಷ್ಟು ವಿನಂತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಬಹುದು ಮತ್ತು ಡಿಕೋಡ್ ಥ್ರೂಪುಟ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು. ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್‌ಗಳು ಕೆವಿ (KV) ಕ್ಯಾಶ್‌ಗಳನ್ನು ಜನರೇಟ್ ಮಾಡುತ್ತವೆ, ನಂತರ ಅವುಗಳನ್ನು ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಡಿಕೋಡರ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಪ್ರಿಫಿಲ್‌ಗಾಗಿ ನಿಲ್ಲಬೇಕಾಗಿಲ್ಲದ ಕಾರಣ, ಲೇಟೆನ್ಸಿಯು ಹೆಚ್ಚು ನಿರ್ಣಾಯಕವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಸಕ್ರಿಯ ವಿನಂತಿಗಳ ಬೆಳೆಯುತ್ತಿರುವ kv_len ನ ಒಟ್ಟಾರೆ ಪ್ರಭಾವವು ತುಂಬಾ ಕಡಿಮೆ ಇರುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕೆವಿ (KV) ಕ್ಯಾಶ್‌ಗಳ ವರ್ಗಾವಣೆಯು ಹತ್ತಾರು ಅಥವಾ ನೂರಾರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ ಮೊದಲ ಟೋಕನ್‌ಗೆ ಆಗುವ ಸಮಯದ (TTFT) ಹೆಚ್ಚಳದಲ್ಲಿ ಇದರ ವೆಚ್ಚವನ್ನು ಭರಿಸಲಾಗುತ್ತದೆ.

ಕೆವಿ ಮೆಸ್ಸೆಂಜರ್ (KV Messenger)

Perplexity ನಲ್ಲಿ, ಬೇರ್ಪಡಿಸಿದ ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್‌ಗಾಗಿ ನಮ್ಮ ಅನುಷ್ಠಾನವು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್‌ಗಳಿಂದ ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳಿಗೆ ಕೆವಿ (KV) ಕ್ಯಾಶ್ ವರ್ಗಾವಣೆಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು LLM ಎಂಜಿನ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ KV ಮೆಸ್ಸೆಂಜರ್ ಸುತ್ತಲೂ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಪ್ರಿಫಿಲ್ಲರ್ ಬದಿಯಲ್ಲಿ, ಮೆಸ್ಸೆಂಜರ್ ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಬ್ಯಾಚ್ ಶೆಡ್ಯೂಲರ್‌ಗೆ ಹಸ್ತಾಂತರಿಸುತ್ತದೆ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಲೇಟೆನ್ಸಿಯೊಂದಿಗೆ KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಫಾರ್ವರ್ಡ್ ಪಾಸ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. ಡಿಕೋಡರ್ ಬದಿಯಲ್ಲಿ, ತೆಗೆದುಹಾಕಲಾಗದ ಪುಟಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡಿದ ನಂತರ, KV ಕ್ಯಾಶ್ ಮತ್ತು ಡಿಕೋಡರ್ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವರ್ಗಾವಣೆಗಳ ಮುಕ್ತಾಯದ ಬಗ್ಗೆ ಸೂಚನೆ ನೀಡುವವರೆಗೆ ಮೆಸ್ಸೆಂಜರ್ ವಿನಂತಿಯನ್ನು ಡಿಕೋಡ್ ಮಾಡಲು ನಿಗದಿಪಡಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಪ್ರಿಫಿಲ್ ಅನ್ನು ಬೇರ್ಪಡಿಸಲು ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್, ಕಡಿಮೆ-ಲೇಟೆನ್ಸಿ ಸಂಪರ್ಕಗಳ ಅಗತ್ಯವಿದೆ, ಆದ್ದರಿಂದ ನಮ್ಮ ಅನುಷ್ಠಾನವು RDMA ಗಾಗಿ ಸಿದ್ಧಪಡಿಸಲಾಗಿದೆ, ಇದು EFA ಮತ್ತು ConnectX ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಕಂಟ್ರೋಲರ್‌ಗಳು (NICs) ಎರಡನ್ನೂ ಬೆಂಬಲಿಸುತ್ತದೆ. KV ಮೆಸ್ಸೆಂಜರ್ ಅನ್ನು libfabric ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇದು ರಿಮೋಟ್ ಡೈರೆಕ್ಟ್ ಮೆಮೊರಿ ಆಕ್ಸೆಸ್ (RDMA) ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಮೇಲೆ ಉನ್ನತ ಮಟ್ಟದ ಕಡಿಮೆ-ಲೇಟೆನ್ಸಿ ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್‌ಗಳನ್ನು ಒದಗಿಸಲು ನಮ್ಮ fabric-lib ರಾಪರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಕಡಿಮೆ-ಲೇಟೆನ್ಸಿ ಸಿಗ್ನಲಿಂಗ್ ಜೊತೆಗೆ ಸಮರ್ಥ ಪುಟ ಮತ್ತು ಮೆಟಾಡೇಟಾ ವರ್ಗಾವಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಹಿನ್ನೆಲೆಯಲ್ಲಿ, ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್‌ನಿಂದ ಡಿಕೋಡರ್ ನೋಡ್‌ಗೆ ಡೇಟಾವನ್ನು ನಕಲಿಸಲು fabric-lib GPU ಮತ್ತು ಅದಕ್ಕೆ ನೇರವಾಗಿ ಸಂಪರ್ಕಗೊಂಡಿರುವ NIC ಗಳನ್ನು ಸಂಘಟಿಸುತ್ತದೆ.

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

ವಿಸ್ತರಿಸಿ

ಕೊನೆಯ ಚಂಕ್‌ನ ವರ್ಗಾವಣೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಮೆಟಾಡೇಟಾವನ್ನು ಸಹ ನಕಲಿಸಲಾಗುತ್ತದೆ: ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಡಿಕೋಡಿಂಗ್ ಅಥವಾ MTP ಗೆ ಲಾಗ್ಟ್‌ಗಳು ಮತ್ತು ಹಿಡನ್ ಸ್ಟೇಟ್‌ಗಳನ್ನು ಡಿಕೋಡರ್‌ಗೆ ಸರಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ. ಈ ನಕಲುಗಳನ್ನು ಪೂರ್ವ-ಹಂಚಿಕೆ ಮಾಡಿದ ಬಫರ್‌ಗಳಿಗೆ ಮತ್ತು ಬಫರ್‌ಗಳಿಂದ RDMA ಮೂಲಕಯೂ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.

ಕೊನೆಯ ಚಂಕ್‌ನ ಬಾಕಿ ಉಳಿದಿರುವ ಎಲ್ಲಾ ವರ್ಗಾವಣೆಗಳು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್ KV ಪುಟಗಳನ್ನು ಡೀ-ಅಲೋಕೆಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. ಡಿಕೋಡರ್ ನೋಡ್‌ಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚನೆ ನೀಡಲಾಗುವುದಿಲ್ಲ: ಬದಲಿಗೆ, ಪೂರ್ಣಗೊಂಡ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಇದು ತಕ್ಷಣದ ಕೌಂಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಪ್ರಿಫಿಲ್ಲರ್ ಬದಿಯಲ್ಲಿರುವ RDMA ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಖ್ಯೆಯು ವರ್ಗಾಯಿಸಲಾದ ಪುಟಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ. ತಿಳಿದಿರುವ ಸಂಖ್ಯೆಯ ಪುಟ ಮತ್ತು ಕಾನ್ಟೆಕ್ಸ್ಟ್ ನಕಲುಗಳು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ವಿನಂತಿಯು ಡಿಕೋಡಿಂಗ್‌ಗೆ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಸೂಚಿಸಲು fabric-lib KV ಮೆಸ್ಸೆಂಜರ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಮೆಸ್ಸೆಂಜರ್ ಯಾವುದೇ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಡೀ-ಅಲೋಕೆಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು LLM ಎಂಜಿನ್‌ಗೆ ಹಸ್ತಾಂತರಿಸುತ್ತದೆ.

ಶಾರ್ಡ್ ಮಾಡಿದ ಕೆವಿ (KV) ಕ್ಯಾಶ್ ವರ್ಗಾವಣೆಗಳು

ಪ್ರಿಫಿಲ್ಲರ್ ಮತ್ತು ಡಿಕೋಡರ್ ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್ (TP) ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ ಮತ್ತು KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಶಾರ್ಡ್ ಅಥವಾ ರೆಪ್ಲಿಕೇಟ್ ಮಾಡಿದರೆ, ಏಕೈಕ ವರ್ಗಾವಣೆ ಎಂಜಿನ್ ಎಲ್ಲಾ ರೆಪ್ಲಿಕಾಗಳ ಪುಟಗಳನ್ನು ಕಳುಹಿಸಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ಬಹು ಸಾಧನಗಳನ್ನು ಸಂಘಟಿಸುತ್ತದೆ. ಮಾದರಿಯ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಅನ್ನು ಬಹು ಸಾಧನಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ರೆಪ್ಲಿಕೇಟ್ ಮಾಡಲಾಗಿದ್ದರೂ ಸಹ ಏಕೈಕ ಮೆಸ್ಸೆಂಜರ್ ಮತ್ತು ವರ್ಗಾವಣೆ ಎಂಜಿನ್ ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ, KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಸಾಧನ ಮೆಮೊರಿಯನ್ನು ಹಂಚಿಕೆ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಗೆ ಮ್ಯಾಪ್ ಮಾಡಲು cuMem ಮತ್ತು cuMemImportFromShareableHandle ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು KV ಕ್ಯಾಶ್ ಸ್ಲೈಸ್ ವರ್ಗಾವಣೆಗಾಗಿ ಬಳಸಲು ಹತ್ತಿರದ NUMA ನೋಡ್‌ನಲ್ಲಿರುವ NIC ಗಳು ಮತ್ತು CPU ಗಳನ್ನು ಹುಡುಕಲು ವರ್ಗಾವಣೆ ಎಂಜಿನ್ ನೋಡ್‌ನ ಟೋಪೋಲಜಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

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

ವಿಸ್ತರಿಸಿ

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

ವಿಸ್ತರಿಸಿ

ಶಾರ್ಡ್ ಮಾಡಿದ ವರ್ಗಾವಣೆಗಳಿಗೆ KV ಕ್ಯಾಶ್‌ಗಳಿಗೆ ಸ್ವಲ್ಪ ಬದಲಾವಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, FlashInfer NHD ಲೇಔಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ, ಇದು ಹೆಡ್‌ಗಳ ಒಳಗೆ ಪುಟದೊಳಗಿನ ಟೋಕನ್‌ಗಳನ್ನು ಕ್ರಮಗೊಳಿಸುತ್ತದೆ. ಕ್ಯಾಶ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಅಟೆನ್ಷನ್ ಹೆಡ್‌ಗಳ ಉದ್ದಕ್ಕೂ ಶಾರ್ಡ್ ಆಗುವ ಸಾಧ್ಯತೆಯಿರುವುದರಿಂದ, ಇದು ಹೆಡ್‌ನೊಳಗೆ ಅಸಂಬದ್ಧತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. RDMA ವರ್ಗಾವಣೆಗಳು ಸ್ಟ್ರೈಡ್ ರೈಟ್ಸ್‌ಗಳನ್ನು ಸೂಚ್ಯವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ವರ್ಗಾವಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರತಿ ಹೆಡ್‌ಗೆ ಒಂದು ಕಾರ್ಯಾಚರಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಬದಲಿಗೆ, libfabric ನೊಂದಿಗೆ ಸಂವಹನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನಾವು ಹೆಡ್ ಆಯಾಮವನ್ನು ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯ ಮೊದಲು ಇರಿಸುವ HND ಲೇಔಟ್ ಅನ್ನು ಬಳಸಿ KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಸಂಘಟಿಸುತ್ತೇವೆ. ಇದು ನಿರಂತರತೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಒಂದೇ ರೈಟ್‌ನೊಂದಿಗೆ ಪುಟವನ್ನು ನಕಲಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಡಿಕೋಡಿಂಗ್

ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಡಿಕೋಡಿಂಗ್‌ಗೆ ಬೇರ್ಪಡಿಸಿದ ಪ್ರಿಫಿಲ್-ಡಿಕೋಡ್‌ಗೆ ಸಣ್ಣಪುಟ್ಟ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ನಮ್ಮ ಅನುಷ್ಠಾನದಲ್ಲಿ, ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್‌ಗಳಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸ್ಯಾಂಪಲ್ ಮಾಡಲು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ. Perplexity ನ Sonar ಮಾದರಿಗಳು ರಚನಾತ್ಮಕ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಬೆಂಬಲಿಸುವುದರಿಂದ, ಪ್ರಿಫಿಲ್ಲರ್‌ಗಳು ಮತ್ತು ಡಿಕೋಡರ್‌ಗಳಲ್ಲಿ ಸ್ಕೀಮಾ ಪ್ರೊಸೆಸರ್ ಅನುಷ್ಠಾನಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಸಂಕೀರ್ಣತೆಯನ್ನು ನಾವು ಎದುರಿಸಲು ಬಯಸುವುದಿಲ್ಲ. MTP ಮತ್ತು ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಡಿಕೋಡಿಂಗ್ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ, ಕೊನೆಯ ಟೋಕನ್ ವರೆಗಿನ ಡ್ರಾಫ್ಟ್ ಮಾದರಿಯನ್ನು ಪ್ರಿಫಿಲ್ ಮಾಡುವುದು ಟಾರ್ಗೆಟ್ ಮಾದರಿಯಿಂದ ಟೋಕನ್‌ಗಳನ್ನು ಸ್ಯಾಂಪಲ್ ಮಾಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

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

ಬೇರ್ಪಡಿಸಿದ ನಿಯೋಜನೆಗಳು

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

ಡೀಪ್‌ಸೀಕ್-ಆರ್೧ (DeepSeek-R1)

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

DeepSeek ಮಲ್ಟಿ-ಹೆಡ್ ಲ್ಯಾಟೆಂಟ್ ಅಟೆನ್ಷನ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ, KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಕಂಪ್ರೆಸ್ ಮಾಡುತ್ತದೆ. ಎಲ್ಲಾ KV ಹೆಡ್‌ಗಳನ್ನು ಒಂದೇ ಲ್ಯಾಟೆಂಟ್ ವೆಕ್ಟರ್ ಆಗಿ ಕಂಪ್ರೆಸ್ ಮಾಡಲಾಗಿರುವುದರಿಂದ, TP ಯು KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಶಾರ್ಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಎಲ್ಲಾ ಶ್ರೇಣಿಗಳಲ್ಲಿ ಲ್ಯಾಟೆಂಟ್ ವೆಕ್ಟರ್‌ಗಳನ್ನು ರೆಪ್ಲಿಕೇಟ್ ಮಾಡಬೇಕು. ಡಿಕಂಪ್ರೆಷನ್ ನಂತರ ಶಾರ್ಡಿಂಗ್ ಸಂಭವಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಶ್ರೇಣಿಯು ಒಂದೇ ಲ್ಯಾಟೆಂಟ್ ರೆಪ್ರೆಸೆಂಟೇಶನ್‌ನಿಂದ ವಿವಿಧ ಹೆಡ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಬಹುದು. ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲಾ KV ಕ್ಯಾಶ್ ಶಾರ್ಡ್‌ಗಳು ಪ್ರಿಫಿಲ್ಲರ್ ಮತ್ತು ಡಿಕೋಡರ್ ಶಾರ್ಡ್‌ಗಳಾದ್ಯಂತ ಒಂದೇ ರೀತಿಯಲ್ಲಿರುತ್ತವೆ.

ಇಂಟ್ರಾನೋಡ್ TP ಸೆಟಪ್‌ನೊಂದಿಗೆ, ಪ್ರಿಫಿಲ್ಲರ್‌ಗಳು ಮತ್ತು ಡಿಕೋಡರ್‌ಗಳು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಶಾರ್ಡ್ ಆಗಿರುತ್ತವೆ. ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ NIC ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಎಲ್ಲಾ ಶ್ರೇಣಿಗಳ ಮೂಲಕ ವರ್ಗಾವಣೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, DP ನಿಯೋಜನೆಯೊಂದಿಗೆ, TP ಶ್ರೇಣಿಯ ಗಾತ್ರವು ಚಿಕ್ಕದಾಗಿದ್ದಾಗ ಅಥವಾ ಪ್ರತಿ DP ಶ್ರೇಣಿಯನ್ನು ಒಂದೇ GPU ಗೆ ನಿಯೋಜಿಸಿದಾಗ, KV ಕ್ಯಾಶ್‌ನ ರೆಪ್ಲಿಕೇಟ್ ಮಾಡಿದ ನಕಲನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ಪ್ರಿಫಿಲ್ಲರ್ ಸಾಧನವು ಅದನ್ನು ಕಳುಹಿಸಬಹುದು. ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ NIC ಗಳಾದ್ಯಂತ ವಿನಂತಿಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು, ಪ್ರಿಫಿಲ್ಲರ್‌ನಿಂದ ಡಿಕೋಡರ್‌ಗೆ KV ಕ್ಯಾಶ್ ಅನ್ನು ಕಳುಹಿಸಲು ನಾವು ಯಾದೃಚ್ಛಿಕವಾಗಿ GPU ಮತ್ತು NIC ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ.

Mixed prefill-decode ನಲ್ಲಿ, frequent prefill interruptions ನಿಂದಾಗಿ ನಮ್ಮ R1 deployment ನಿರಂತರವಾಗಿ 50 TPS ಅನ್ನು ಮೀರಿಸಲು ಹೋರಾಟ ಮಾಡುತ್ತಿತ್ತು; ಈ interruptions ಗಳ ಅವಧಿ ನೂರಾರು milliseconds ಆಗಿತ್ತು. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, prefill ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ, ನಾವು ಪ್ರತಿ request ಗೆ ಸುಮಾರು 100ms TTFT penalty ಅನ್ನು ಅನುಭವಿಸಿದ್ದೇವೆ, ಆದರೆ ಒಂದು prefiller node 3 decoder nodes ಗಳ ಮೇಲೆ consistent batch sizes ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು, ಪ್ರತಿ decoder node ಗೆ ಸುಮಾರು 1 QPS load ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಾ 90 TPS ಕ್ಕೂ ಹೆಚ್ಚು throughput ಅನ್ನು ಒದಗಿಸಿತು. Data-parallel deployments ಗಳಲ್ಲಿ, TPS ಸ್ವಲ್ಪ ಕಡಿಮೆ, ಸುಮಾರು 50 ಆಗಿತ್ತು; ಆದರೂ instances ಗಳು ಪ್ರತಿ rank ಗೆ 1 QPS load ಅನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲವು, ಮತ್ತು ಒಂದು node ಗೆ 8 ranks ಇದ್ದವು.

ಕ್ಯುವೆನ್೩-ಕೋಡರ್ (Qwen3-Coder)

ಈ 480B ಮಾದರಿಯು ಗ್ರೂಪ್ಡ್-ಕ್ವೆರಿ ಅಟೆನ್ಷನ್ (GQA) ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಟೆನ್ಷನ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಶಾರ್ಡ್ ಮಾಡಬಹುದು ಮತ್ತು KV ಕ್ಯಾಶ್‌ಗಳಿಗೆ ಮೆಮೊರಿಯನ್ನು ಬಿಟ್ಟುಕೊಡದೆ ಟೆನ್ಸರ್ ಪ್ಯಾರಲಲಿಸಮ್‌ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು. ಫಲಿತಾಂಶವಾಗಿ, ಪ್ರಿಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ಎರಡಕ್ಕೂ ನಾವು 8 GPU ಗಳಲ್ಲಿ ಮಾದರಿಯನ್ನು ಶಾರ್ಡ್ ಮಾಡಬಹುದು, ಸುಮಾರು 3 ಡಿಕೋಡರ್ ನೋಡ್‌ಗಳನ್ನು ಒಂದೇ ಪ್ರಿಫಿಲ್ಲರ್ ನೋಡ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಬಹುದು. ಅಟೆನ್ಷನ್ ಅನ್ನು ಶಾರ್ಡ್ ಮಾಡಲಾಗಿರುವುದರಿಂದ, ಪ್ರಿಫಿಲ್ಲರ್ ಮತ್ತು ಡಿಕೋಡರ್ KV ಕ್ಯಾಶ್‌ಗಳನ್ನು ಶಾರ್ಡ್ ಮಾಡಲು ನಾವು HND KV ಕ್ಯಾಶ್ ಲೇಔಟ್ ಅನ್ನು ಅವಲಂಬಿಸುತ್ತೇವೆ, ಪ್ರಿಫಿಲ್ಲರ್ ಶ್ರೇಣಿಗಳನ್ನು ಡಿಕೋಡರ್ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಜೋಡಿಸುತ್ತೇವೆ ಮತ್ತು ಸ್ಲೈಸ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ವರ್ಗಾಯಿಸಲು ಎಲ್ಲಾ NIC ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳುತ್ತೇವೆ.

ಉಲ್ಲೇಖ

@online{perplexity2025DisaggregatedPrefillAndDecode,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Kevin Hu and Erin McKnight and Phi Hoang},
  title = {{Disaggregated prefill and decode}},
  date = {2025-08-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/disaggregated-prefill-and-decode}
}