ನೀವು ಎಂದಾದರೂ LLM ದೀರ್ಘ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವಾಗ, ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ನಂತರ ಅದು ಯಾಕೆ ನಿಧಾನವಾಗುತ್ತದೆ ಎಂದು ಯೋಚಿಸಿದ್ದರೆ, ನೀವು ಹಾರ್ಡ್‌ವೇರ್ ಬಾಟಲ್‌ನೆಕ್ (hardware bottleneck) ಅನ್ನು ನೇರವಾಗಿ ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ಹೆಚ್ಚಿನ ડેವಲಪರ್‌ಗಳು ತಮ್ಮ Python ಕೋಡ್, ಫ್ರೇಮ್‌ವರ್ಕ್ ಅಥವಾ ಮಾಡೆಲ್‌ನ ಗಾತ್ರವನ್ನು ದೂಷಿಸುತ್ತಾರೆ. ಅವರು ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡುತ್ತಾರೆ, ಆಪ್ಟಿಮೈಸರ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ ಮತ್ತು ಪ್ರಿ-ಪ್ರೊಸೆಸಿಂಗ್ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಆದರೆ ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ನಿಜವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ವೇಗದ ಮಿತಿ ನಿಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿಲ್ಲ, ಅದು ಸಿಲಿಕಾನ್‌ನಲ್ಲಿ (silicon) ಇದೆ.

ಪ್ರತಿಯೊಂದು ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ (inference) ಕೆಲಸವು ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿರುವ GPU ನ ಎರಡು ಭೌತಿಕ ಗುಣಲಕ್ಷಣಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ: ಅದು ಎಷ್ಟು ವೇಗವಾಗಿ ಸಂಖ್ಯೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕಬಲ್ಲದು (crunch numbers), ಮತ್ತು ಆ ಸಂಖ್ಯೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕಲು ಬೇಕಾದ ಸ್ಥಾನಕ್ಕೆ ಎಷ್ಟು ವೇಗವಾಗಿ ವರ್ಗಾಯಿಸಬಲ್ಲದು.

ಗಣಿತವು ಅಗ್ಗ. ಡೇಟಾ ವರ್ಗಾವಣೆ ಅಗ್ಗವಲ್ಲ

GPU ಮಾರ್ಕೆಟಿಂಗ್ ಕಂಪ್ಯೂಟ್ (compute) ಬಗ್ಗೆ ಮಾತನಾಡಲು ಇಷ್ಟಪಡುತ್ತದೆ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಟ್ರಿಲಿಯನ್ ಗಟ್ಟಲೆ ಫ್ಲೋಟಿಂಗ್-ಪಾಯಿಂಟ್ ಆಪರೇಷನ್‌ಗಳು (floating-point operations). ಈ ಅಂಕಿಅಂಶಗಳು ಬೆರಗುಗೊಳಿಸುವಂತಿವೆ. ಆದರೆ ಕಂಪ್ಯೂಟ್ ಎಂಬುದು ಕಥೆಯ ಅರ್ಧ ಭಾಗ ಮಾತ್ರ. ಇನ್ನರ್ಧವು ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ (memory bandwidth), ಅಂದರೆ ಹೈ-ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮೆಮೊರಿಯಿಂದ ಅಸಲಿ ಗಣಿತದ ಕ್ರಿಯೆಗಳು ನಡೆಯುವ ಕಂಪ್ಯೂಟ್ ಕೋರ್‌ಗಳಿಗೆ ಡೇಟಾ ಯಾವ ದರದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದು.

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

ಆಧುನಿಕ ಡೇಟಾ ಸೆಂಟರ್ GPUಗಳಲ್ಲಿ, ಅರಿಥ್ಮೆಟಿಕ್ ಯೂನಿಟ್‌ಗಳು (arithmetic units) ಎಷ್ಟು ಶಕ್ತಿಶಾಲಿ ಎಂದರೆ, ಅವು ತಮ್ಮ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮುಗಿಸಿದ ನಂತರ, ಮೆಮೊರಿಯ ಮೂಲಕ ವೇಯ್ಟ್‌ಗಳು (weights) ಮತ್ತು ಆಕ್ಟಿವೇಶನ್‌ಗಳು (activations) ಬರುವವರೆಗೆ ಕಾಯುತ್ತಾ ಸುಮ್ಮನೆ ಕುಳಿತುಬಿಡುತ್ತವೆ. ಈ ಅಸಮತೋಲನವು ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿನ ಬಗ್ (bug) ಅಲ್ಲ. ಚಿಪ್‌ಗಳನ್ನು ಹೇಗೆ ತಯಾರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಭೌತಿಕ ವಾಸ್ತವವಿದು. ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್, ಕಂಪ್ಯೂಟ್ ವೇಗಕ್ಕೆ ತಕ್ಕಂತೆ ಬೆಳೆದಿಲ್ಲ. LLMಗಳಿಗೆ ಈ ಅಸಮತೋಲನವು ಹೆಚ್ಚು ತೊಂದರೆ ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳ ಫಾರ್ವರ್ಡ್ ಪಾಸ್‌ಗಳು (forward passes) ಪ್ರತಿ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಾಗಿ ಪ್ರತಿಯೊಂದು ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಪ್ರಾಂಪ್ಟ್‌ಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಜನರೇಷನ್ ನಿಧಾನವಾಗಿ ಏಕೆ ಅನಿಸುತ್ತವೆ

LLM ಇನ್ಫರೆನ್ಸ್ ಎರಡು ವಿಭಿನ್ನ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಅವು ಹಾರ್ಡ್‌ವೇರ್ ಮೇಲೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಒತ್ತಡವನ್ನು ಹೇರುತ್ತವೆ.

Prefill ಎಂಬುದು ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಮೊದಲ ಬಾರಿಗೆ ಮಾಡೆಲ್‌ಗೆ ತಲುಪಿದಾಗ ಸಂಭವಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಟೋಕನ್‌ಗಳು ಒಟ್ಟಿಗೆ ಬರುತ್ತವೆ. GPU ದೊಡ್ಡ ಮ್ಯಾಟ್ರಿಕ್ಸ್-ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರಗಳನ್ನು (matrix-matrix multiplications) ಬಳಸಿ ಅವುಗಳನ್ನು ಸಮಾಂತರವಾಗಿ (parallel) ಪ್ರೊಸೆಸ್ ಮಾಡಬಲ್ಲದು. ಸಾವಿರಾರು ಅರಿಥ್ಮೆಟಿಕ್ ಯೂನಿಟ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಕೆಲಸದ ಒತ್ತಡವು ಸಾಂದ್ರವಾಗಿರುತ್ತದೆ. ಈ ಹಂತವು ಕಂಪ್ಯೂಟ್-ಬೌಂಡ್ (compute-bound) ಆಗಿದೆ. ಆರಂಭದಲ್ಲಿ ನೀವು ನೋಡುವ ಆ ಹಠಾತ್ ವೇಗ? ಅದು GPU ತನ್ನ ಉದ್ದೇಶದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವುದಕ್ಕೆ ಸಾಕ್ಷಿ.

Decode ಹಂತದಲ್ಲಿ ಪರಿಸ್ಥಿತಿ ಕಷ್ಟಕರವಾಗುತ್ತದೆ. ಮಾಡೆಲ್ ಮುಂದಿನ ಟೋಕನ್ ಅನ್ನು ರಚಿಸುವಾಗ, ಅದು ಒಂದೊಂದೇ ಟೋಕನ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಈ ಹಂತವು ಮ್ಯಾಟ್ರಿಕ್ಸ್-ವೆಕ್ಟರ್ ಆಪರೇಷನ್‌ಗಳ (matrix-vector operations) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಇದು GPU ನ ಸಮಾಂತರ ಸಾಮರ್ಥ್ಯದ ಅತ್ಯಲ್ಪ ಭಾಗವನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಪ್ರತಿ ಹೊಸ ಟೋಕನ್ GPU ಅನ್ನು ಇಡೀ ಮಾಡೆಲ್ ವೇಯ್ಟ್‌ಗಳನ್ನು ಮೆಮೊರಿಯಿಂದ ಮರುಲೋಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಅರಿಥ್ಮೆಟಿಕ್ ಯೂನಿಟ್‌ಗಳು ಕೆಲಸಕ್ಕಾಗಿ ಕಾಯುತ್ತವೆ. ಆದ್ದರಿಂದ, ಡಿಕೋಡ್ ಹಂತವು ಮೆಮೊರಿ-ಬೌಂಡ್ (memory-bound) ಆಗಿದೆ. ಗಣಿತದ ಇಂಜಿನ್‌ಗಳು ವಿಶ್ರಾಂತಿ ಪಡೆಯುತ್ತಿರುವಾಗ, GPU ಕೇವಲ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಮೆಮೊರಿ ಬಸ್ ಮೂಲಕ ಅತ್ತಿತ್ತ ಸಾಗಿಸುವ ದುಬಾರಿ ಟ್ರಾಫಿಕ್ ಕಂಟ್ರೋಲರ್‌ನಂತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ವಿಶ್ಲೇಷಣೆ ತಕ್ಷಣವೇ ನಡೆದಂತೆ ಕಂಡರೂ, ನೂರು ಪದಗಳ ಪ್ರತಿಕ್ರಿಯೆ ಪಡೆಯಲು ಹತ್ತು ಸೆಕೆಂಡುಗಳು ಬೇಕಾಗಲು ಇದೇ ಕಾರಣ.

KV ಕ್ಯಾಶ್ (KV cache) ಇದನ್ನು ಇನ್ನಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿಸುತ್ತದೆ. ಡಿಕೋಡ್ ಸಮಯದಲ್ಲಿ, ಮಾಡೆಲ್ ಪ್ರತಿ ಹಿಂದಿನ ಟೋಕನ್‌ಗಾಗಿ ಕೀ ಮತ್ತು ವ್ಯಾಲ್ಯೂ ಟೆನ್ಸರ್ಸ್‌ಗಳನ್ನು (key and value tensors) ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಇದರಿಂದ ಅದು ಅಟೆನ್ಶನ್ (attention) ಅನ್ನು ಮೊದಲಿನಿಂದ ಮರುಹಣಿಸುವುದಿಲ್ಲ. ಆ ಕ್ಯಾಶ್ ಸೀಕ್ವೆನ್ಸ್ ಉದ್ದದೊಂದಿಗೆ ಬೆಳೆಯುತ್ತದೆ. ಅದು ಕೂಡ ಮೆಮೊರಿಯಲ್ಲಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ಈಗ GPU ಕೇವಲ ವೇಯ್ಟ್‌ಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡುತ್ತಿಲ್ಲ; ಬದಲಾಗಿ ಪ್ರತಿ ಫಾರ್ವರ್ಡ್ ಪಾಸ್‌ನಲ್ಲಿ ಬೆಳೆಯುತ್ತಿರುವ ಕ್ಯಾಶ್ ಅನ್ನು ಓದುತ್ತಿದೆ ಮತ್ತು ಬರೆಯುತ್ತಿದೆ. ಕಂಪ್ಯೂಟ್ ಕೋರ್‌ಗಳು ಅಷ್ಟೇನೂ ಕೆಲಸ ಮಾಡದಿದ್ದರೂ, ಮೆಮೊರಿ ಬಸ್ ಎರಡಕ್ಕೂ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿ ಬರುತ್ತದೆ.

ಮೆಮೊರಿ ವಾಲ್ (Memory Wall) ವಿರುದ್ಧ ಹೋರಾಟ

ಡೇಟಾ ಚಲನೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅಥವಾ ಕನಿಷ್ಠ ಪಕ್ಷ ಅದರ ವೆಚ್ಚವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಎಂಜಿನಿಯರ್‌ಗಳು ಕೆಲವು ತಂತ್ರಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ.

Batching ಅತ್ಯಂತ ಸರಳವಾದ ವಿಧಾನವಾಗಿದೆ. ಒಬ್ಬ ಬಳಕೆದಾರರ ವಿನಂತಿಯು ಮೆಮೊರಿಯಿಂದ ಪೂರ್ಣ ವೇಯ್ಟ್ ಲೋಡ್ ಮಾಡಬೇಕಾದಲ್ಲಿ, ಎಂಟು ಅಥವಾ ಹದಿನಾರು ವಿನಂತಿಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರೊಸೆಸ್ ಮಾಡುವುದರಿಂದ GPU ಆ ಲೋಡ್ ಅನ್ನು ಎಲ್ಲಾ ವಿನಂತಿಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ವೇಯ್ಟ್‌ಗಳನ್ನು ಒಮ್ಮೆ ಓದಲಾಗುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಚ್‌ನಲ್ಲಿರುವ ಪ್ರತಿ ಸೀಕ್ವೆನ್ಸ್‌ಗಾಗಿ ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ಸಂಕೀರ್ಣ ಶೆಡ್ಯೂಲಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ಗುಂಪು ಮಾಡುತ್ತವೆ, ಇದನ್ನು ಕೆಲವೊಮ್ಮೆ ಕಂಟಿನ್ಯೂಯಸ್ ಅಥವಾ ಇನ್-ಫ್ಲೈಟ್ ಬ್ಯಾಚಿಂಗ್ (continuous or in-flight batching) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಇದರಿಂದ GPU ಅಪರೂಪವಾಗಿ ಮಾತ್ರ ನಿಲ್ಲುತ್ತದೆ. ಇದು ಒಂದೇ ಮಾರ್ಗದಲ್ಲಿ ಚಲಿಸುವ ಬಸ್ ಮತ್ತು ಹದಿನಾರು ಪ್ರತ್ಯೇಕ ಕಾರುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸದಂತಿದೆ.

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

FlashAttention ಮಧ್ಯಂತರ ಫಲಿತಾಂಶಗಳನ್ನು GPU ನ ವೇಗದ ಆನ್-ಚಿಪ್ ಮೆಮೊರಿಯೊಳಗೆ ಇರಿಸಲು ಅಟೆನ್ಶನ್ ಮೆಕ್ಯಾನಿಸಂ ಅನ್ನು ಮರುರಚಿಸುತ್ತದೆ. ಪ್ರಮಾಣಿತ ಅಟೆನ್ಶನ್ ವಿಧಾನವು ದೊಡ್ಡ ಅಟೆನ್ಶನ್ ಮ್ಯಾಟ್ರಿಸಿಸ್‌ಗಳನ್ನು ನಿಧಾನಗತಿಯ ಬಾಹ್ಯ ಮೆಮೊರಿಗೆ ಬರೆಯಬೇಕಾಗುತ್ತಿತ್ತು ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಮತ್ತೆ ಓದಬೇಕಾಗುತ್ತಿತ್ತು. FlashAttention ಲೆಕ್ಕಾಚಾರವನ್ನು SRAM ನಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುವ ಸಣ್ಣ ಟೈಲ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ, ಸಾಫ್ಟ್‌ಮ್ಯಾಕ್ಸ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಹಂತಗಳನ್ನು ಆನ್-ಚಿಪ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕೇವಲ ಅಂತಿಮ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಹೈ-ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮೆಮೊರಿಗೆ ಬರೆಯುತ್ತದೆ. ಇದು ಮುಖ್ಯ ಮೆಮೊರಿಗೆ ಮಾಡುವ ಅತಿ ಹೆಚ್ಚು ಸುತ್ತುಗಳ (round trips) ಬದಲಿಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ಕಂಪ್ಯೂಟ್ ಅನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಯಾವಾಗಲೂ ಲಾಭದಾಯಕವಾದ ನಿರ್ಧಾರವಾಗಿರುತ್ತದೆ.

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

ಪ್ರಶ್ನೆಯನ್ನು ಬದಲಿಸಿ

ವಿಳಂಬವು (latency) ಹೆಚ್ಚಾದಾಗ, ಅನೇಕ ತಂಡಗಳು ತಾವು ಸಣ್ಣ ಮಾಡೆಲ್‌ಗೆ ಬದಲಾಗಬೇಕೇ ಅಥವಾ ತಮ್ಮ ಇನ್ಫರೆನ್ಸ್ ಸರ್ವರ್ ಅನ್ನು ಮರುಬರೆಯಬೇಕೇ ಎಂದು ಕೇಳುತ್ತಾರೆ. ಆ ಪ್ರಶ್ನೆಗಳು ಮುಖ್ಯವಾಗಿವೆ, ಆದರೆ ಅವು ಎರಡನೇ ಆದ್ಯತೆಯಾಗಿವೆ. ಮೊದಲ ಪ್ರಶ್ನೆಯು ಹಾರ್ಡ್‌ವೇರ್ ಬಗ್ಗೆ ಇರಬೇಕು. ನಿಮ್ಮ GPU ನಿಜವಾಗಿಯೂ ಕಂಪ್ಯೂಟಿಂಗ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರತವಾಗಿದೆಯೇ ಅಥವಾ ಡೇಟಾ ಇಲ್ಲದೆ ಕಾಯುತ್ತಿದೆಯೇ?

ನಿಮ್ಮ ಯುಟಿಲೈಸೇಶನ್ ಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಗಮನಿಸಿ. GPU ಕಂಪ್ಯೂಟ್ ಆಕ್ಯುಪೆನ್ಸಿಯ ಜೊತೆಗೆ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಸ್ಯಾಚುರೇಶನ್ ಅನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡಿ. ಡಿಕೋಡ್ ಮಾಡುವಾಗ ನೀವು ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಸಂಘರ್ಷ (contention) ಮತ್ತು ಕಡಿಮೆ ಅರಿತ್ಮೆಟಿಕ್ ಇಂಟೆನ್ಸಿಟಿ (arithmetic intensity) ಅನ್ನು ನೋಡಿದರೆ, ಅದು ನಿಮಗೆ ಮಾಡೆಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸಮಸ್ಯೆಯಲ್ಲ. ಅದು ನಿಮಗೆ ಭೌತಿಕ ಸಮಸ್ಯೆ (physics problem). ಪರಿಹಾರವು ಸುಧಾರಿತ ಪೈಥಾನ್ ಕೋಡ್‌ನಿಂದ ಬರುವುದಿಲ್ಲ. ಅದು ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಬ್ಯಾಚಿಂಗ್ ಮಾಡುವುದು, ಪೈಪ್ ಮೂಲಕ ವೇಗವಾಗಿ ಸಾಗಲು ನಿಮ್ಮ ತೂಕಗಳನ್ನು (weights) ಕ್ವಾಂಟೈಸ್ ಮಾಡುವುದು, ಆನ್-ಚಿಪ್‌ನಲ್ಲಿ ಉಳಿಯಲು ಅಟೆನ್ಶನ್ ಅನ್ನು ಮರುರಚಿಸುವುದು ಮತ್ತು ಸ್ಥಳಾವಕಾಶದ ಕೊರತೆಯಿಲ್ಲದೆ ದೊಡ್ಡ ಬ್ಯಾಚ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು KV ಕ್ಯಾಶ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ಬರುತ್ತದೆ.

ಒಮ್ಮೆ ನೀವು ಇನ್ಫರೆನ್ಸ್ ಅನ್ನು ಈ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡಿದಾಗ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಒಂದು ಯಾಂತ್ರಿಕ ಪ್ರಕ್ರಿಯೆಯಾಗುತ್ತದೆ. ಮಾಡೆಲ್ ಬುದ್ಧಿವಂತಿಕೆಯು ವಿಷಯಗಳನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಎಂಬ ದ mythಗಳನ್ನು ಬೆನ್ನಟ್ಟುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ವಾಸ್ತವವಾಗಿ ಏನು ನೀಡಬಲ್ಲದು ಎಂಬುದರ ಮೇಲೆ ಆಧಾರಿತವಾದ ಇಂಜಿನಿಯರಿಂಗ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿ. ಸ್ಕೇಲ್ ಆಗುವ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳು (production systems) ಮತ್ತು ಕೇವಲ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇ ಇದು.