AWS ತನ್ನ Amazon SageMaker Inference ಗೆ “prefix-aware routing” ಎಂಬ ಆಯ್ಕೆಯನ್ನು ಸೇರಿಸಿದೆ. ಇದು ತಮ್ಮದೇ ಆದ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ Large Language Models (LLMs) ಅನ್ನು ನಡೆಸುವ ಗ್ರಾಹಕರಿಗೆ ಹೆಚ್ಚಿನ cache-hit നിരಕು ಮತ್ತು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ latency ಅನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯು ಮುಖ್ಯವಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ latency ಮತ್ತು ಕಡಿಮೆ GPU compute ವೆಚ್ಚಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

LLM latency ಏಕೆ ಮುಖ್ಯ

ಒಂದು LLM ವಿನಂತಿಯನ್ನು (request) ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಇಡೀ ಪ್ರಾಂಪ್ಟ್‌ನ ಮೇಲೆ ಅಟೆನ್ಶನ್ ಅನ್ನು ಮರು-ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ—ಇದು ಪ್ರತಿ ಬಾರಿ ಹೊಸ ಟೋಕನ್ ಸೇರ್ಪಡೆಯಾದಂತೆ ಹೆಚ್ಚಾಗುವ ವೆಚ್ಚದಾಯಕ ಹಂತವಾಗಿದೆ. ಮಾದರಿಯು (model) ಹಿಂದಿನ ವಿನಂತಿಯ ಅಟೆನ್ಶನ್ ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಲ್ಲದಾದರೆ, ಅದು ಪಠ್ಯದ ಹೊಸ ಭಾಗವನ್ನು ಮಾತ್ರ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ. ಒಂದೇ ರೀತಿಯ system prompt ಅನ್ನು ಪದೇ ಪದೇ ಕಳುಹಿಸುವ ಅಥವಾ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವನ್ನು (conversation history) ಕಾಯ್ದುಕೊಳ್ಳುವ ವರ್ಕ್‌ಲೋಡ್‌ಗಳು ಕ್ಯಾಶ್ ಮರುಬಳಕೆಗೆ ಉತ್ತಮ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ.

ಡಿಫಾಲ್ಟ್ SageMaker ಸೆಟಪ್‌ನಲ್ಲಿ, ಬರುವ ವಿನಂತಿಗಳನ್ನು ಇನ್ಫರೆನ್ಸ್ ಇನ್‌ಸ್ಟೆನ್ಸ್ಗಳ (inference instances) ಗುಂಪಿನಾದ್ಯಂತ ಯಾದೃಚ್ಛಿಕವಾಗಿ (randomly) ವಿತರಿಸಲಾಗುತ್ತದೆ. ಯಾದೃಚ್ಛಿಕ ವಿತರಣೆಯೆಂದರೆ, warm cache ಅನ್ನು ಬಳಸಬಹುದಾಗಿದ್ದ ವಿನಂತಿಯು ಹೆಚ್ಚಾಗಿ ಒಂದು cold instance ಗೆ ತಲುಪುತ್ತದೆ, ಇದು ಪೂರ್ಣ ಮರು-ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಒತ್ತಾಯಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಹೆಚ್ಚಿನ latency ಮತ್ತು ಹೆಚ್ಚುವರಿ GPU cycles ಉಂಟಾಗುತ್ತವೆ, ಇದು ನೇರವಾಗಿ ಹೆಚ್ಚಿನ ವೆಚ್ಚಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

prefix-aware routing ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಹೊಸ ರೂಟಿಂಗ್ ಮೋಡ್ ಇತ್ತೀಚಿನ ವಿನಂತಿಗಳ prefixesಗಳ ಲಘು ನಕ್ಷೆಯನ್ನು (lightweight map) ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ—ಇದು ಪ್ರಾಂಪ್ಟ್‌ನ ಮೊದಲ ಭಾಗವಾಗಿದ್ದು, ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ಕರೆಗಳಲ್ಲಿ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಹೊಸ ವಿನಂತಿ ಬಂದಾಗ, SageMaker ಆ ನಕ್ಷೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಈಗಾಗಲೇ ಅದೇ prefix ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಇನ್ನೂ ಸಂಬಂಧಿತ attention cache ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಮಾದರಿಯು ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಬಿಟ್ಟು ವೇಗವಾಗಿ ಉತ್ತರವನ್ನು ನೀಡಬಹುದು.

ಪ್ರಮುಖ ಅಂಶಗಳು:

  • ಯಾವುದೇ ಕೋಡ್ ಬದಲಾವಣೆ ಅಗತ್ಯವಿಲ್ಲ – ಈ ವೈಶಿಷ್ಟ್ಯವು ಸಂಪೂರ್ಣವಾಗಿ ಇನ್ಫರೆನ್ಸ್ ಸರ್ವಿಸ್ ಲೇಯರ್‌ನಲ್ಲಿರುತ್ತದೆ.
  • ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಮಾದರಿಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ – OpenAI ನ API ಅಥವಾ Anthropic ನ ಸೇವೆಗಳಂತಹ ಮ್ಯಾನೇಜ್ಡ್ ಆಫರ್‌ಗಳು ಇದರಿಂದ ಬಾಧಿತವಾಗುವುದಿಲ್ಲ.
  • ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಪಾರದರ್ಶಕವಾಗಿದೆ – ಅದೇ SageMaker endpoint URL ಮತ್ತು API contract ಹಾಗೆಯೇ ಇರುತ್ತದೆ.

ಯಾರು ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು

SageMaker ನಲ್ಲಿ LLM ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಉದ್ಯಮಗಳು ಡೇಟಾ ಗೌಪ್ಯತೆಯಿಂದ ಹಿಡಿದು ವೆಚ್ಚ ನಿಯಂತ್ರಣದವರೆಗೆ ವಿವಿಧ ಕಾರಣಗಳಿಗಾಗಿ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ. ಸಪೋರ್ಟ್ ಚಾಟ್‌ಬಾಟ್‌ಗಳು, ಸೇಲ್ಸ್ ಅಸಿಸ್ಟೆಂಟ್‌ಗಳು ಅಥವಾ ಸ್ಥಿರವಾದ system prompt ಅನ್ನು ಪದೇ ಪದೇ ಬಳಸುವ ಯಾವುದೇ ಇಂಟರಾಕ್ಟಿವ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಡೆಸುವವರಿಗೆ, ಈ ರೂಟಿಂಗ್ ತಿದ್ದುಪಡಿ ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು. ವೆಚ್ಚದ ದೃಷ್ಟಿಯಿಂದ, ಪ್ರತಿ ಕ್ಯಾಶ್ ಹಿಟ್ (cache hit) ಪ್ರಾಂಪ್ಟ್‌ನ ಹಂಚಿಕೆಯ ಭಾಗವನ್ನು ಮರು-ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದರಿಂದ GPU ಅನ್ನು ಉಳಿಸುತ್ತದೆ.

ಮಿತಿಗಳು ಮತ್ತು ವಿರೋಧಾಭಿಪ್ರಾಯಗಳು

ಈ ಪ್ರಯೋಜನವು ಪುನರಾವರ್ತಿತ prefixesಗಳ ಇರುವಿಕೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಹೆಚ್ಚು ಬದಲಾಗುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳು—ಉದಾಹರಣೆಗೆ ಏಕದಿನದ ಪ್ರಶ್ನೆಗಳು (one-off queries) ಅಥವಾ ಡೈನಾಮಿಕ್ ಆಗಿ ಜನರೇಟ್ ಮಾಡಲಾದ system messages—ಅದೇ ರೀತಿಯ cache-hit ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.

ಈ ವೈಶಿಷ್ಟ್ಯವು ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ನಿಯೋಜನೆಗಳಿಗೆ (self-hosted deployments) ಸೀಮಿತವಾಗಿರುವುದರಿಂದ, ಮ್ಯಾನೇಜ್ಡ್ LLM ಸೇವೆಗಳನ್ನು ಬಳಸುವ ಗ್ರಾಹಕರು ಇದನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಸಾರಾಂಶ: Prefix-aware routing SageMaker ಬಳಕೆದಾರರಿಗೆ ಪುನರಾವರ್ತಿತ LLM ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಂದ latency ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು GPU ವೆಚ್ಚಗಳನ್ನು ಉಳಿಸಲು ಯಾವುದೇ ಕೋಡ್ ಬದಲಾವಣೆ ಇಲ್ಲದ ಸರಳ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಈಗಾಗಲೇ ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಮಾದರಿಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತಿರುವ ಸಂಸ್ಥೆಗಳಿಗೆ, ಈ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು ಕಡಿಮೆ ಅಪಾಯದ ಬದಲಾವಣೆಯಾಗಿದ್ದು, ಇದು ವೇಗವಾದ ಬಳಕೆದಾರರ ಸಂವಹನ ಮತ್ತು ಕಡಿಮೆ ಬಿಲ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.