Microsoft ತನ್ನ Azure API Management (APIM) ಗೆ ಪ್ರತ್ಯೇಕವಾದ AI Gateway tier ಅನ್ನು ಸೇರಿಸಿದೆ. ಈ ಕ್ರಮವು LLM ಕರೆಗಳನ್ನು ಕೇವಲ ಮತ್ತೊಂದು API ಎಂಡ್ಪಾಯಿಂಟ್ ಆಗಿ ನೋಡದೆ, ಈಗ ಒಂದು ಪ್ರತ್ಯೇಕ ವರ್ಕ್ಲೋಡ್ (workload) ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಯಾಕೆ LLM ಟ್ರಾಫಿಕ್ ಸಾಂಪ್ರದಾಯಿಕ ಗೇಟ್ವೇಗಳನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ
ಒಂದು ಪ್ರಾಂಪ್ಟ್ (prompt) ಮತ್ತೊಂದಿಗಿಂತ ನೂರು ಪಟ್ಟು ಹೆಚ್ಚು ವೆಚ್ಚವಾಗಬಹುದು, ಆದರೂ ಸಾಮಾನ್ಯ API ಗೇಟ್ವೇ ಎರಡನ್ನೂ ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಯೆಂದು (request) ಪರಿಗಣಿಸುತ್ತದೆ. ಗೇಟ್ವೇಯು ಕೇವಲ ಕರೆಗಳನ್ನು (calls) ಎಣಿಸುತ್ತದೆಯೇ ಹೊರತು, ಮಾಡೆಲ್ ಪ್ರೊಸೆಸ್ ಮಾಡುವ ಟೋಕನ್ಗಳ (tokens) ಸಂಖ್ಯೆಯನ್ನು ಅಲ್ಲ. ಕೆಲವು ನೂರಾರು ಟೋಕನ್ಗಳನ್ನು ಕಳುಹಿಸುವ ವಿನಂತಿ ಮತ್ತು ಸಾವಿರಾರು ಟೋಕನ್ಗಳನ್ನು ಕಳುಹಿಸುವ ವಿನಂತಿ ಎರಡೂ ಒಂದೇ ರೀತಿಯ 'request-count' ಮೆಟ್ರಿಕ್ಗಳನ್ನು ತೋರಿಸುತ್ತವೆ, ಆದರೆ ಎರಡನೆಯದಕ್ಕೆ ವೆಚ್ಚವು ಅತಿ ಹೆಚ್ಚು ಇರಬಹುದು.
ಈ ನಾಲ್ಕು ಅಂಶಗಳು AI ಗಾಗಿ ವಿನಂತಿ ಆಧಾರಿತ (request-based) ಮಿತಿಗಳನ್ನು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿಸುತ್ತವೆ:
- ವೆಚ್ಚ ≠ ವಿನಂತಿ ಸಂಖ್ಯೆ (request count). ಬಿಲ್ಲಿಂಗ್ ಟೋಕನ್ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ, ನೀವು ಎಷ್ಟು HTTP ಕರೆಗಳನ್ನು ಮಾಡುತ್ತೀರಿ ಎಂಬುದಕ್ಕೆ ಅಲ್ಲ.
- ಟೋಕನ್ ಪ್ರಮಾಣವು ವಿಪರೀತವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಒಂದು ಪ್ರಶ್ನೆಯು ಚಿಕ್ಕದಾಗಿರಬಹುದು; ಮತ್ತೊಂದು ದೀರ್ಘವಾದ ದಾಖಲೆಯನ್ನು ಒಳಗೊಂಡಿರಬಹುದು.
- ಮಾಡೆಲ್ ಆಯ್ಕೆಯು ಬೆಲೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ವಿವಿಧ LLMಗಳು ಪ್ರತಿ ಟೋಕನ್ಗೆ ವಿಭಿನ್ನ ದರಗಳನ್ನು ವಿಧಿಸುತ್ತವೆ.
- ಸ್ಟ್ರೀಮಿಂಗ್ (Streaming) ಅಂತಿಮ ಬಿಲ್ ಅನ್ನು ಮರೆಮಾಚುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆಗಳು ಸ್ಟ್ರೀಮ್ ಆಗುತ್ತಿರುವಾಗ, ಸ್ಟ್ರೀಮ್ ಮುಗಿಯುವವರೆಗೆ ಒಟ್ಟು ಟೋಕನ್ ಸಂಖ್ಯೆಯು ತಿಳಿಯುವುದಿಲ್ಲ.
ನೀವು ಕೇವಲ ವಿನಂತಿಗಳನ್ನು (requests) ಮಾತ್ರ ಅಳೆಯುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ನಿಜವಾದ ವೆಚ್ಚದ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ನೀಡದ ಮಾನಿಟರಿಂಗ್ ಡೇಟಾವನ್ನು ನೀವು ಪಡೆಯುತ್ತೀರಿ.
AI Gateway tier ಏನನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ
ಟೋಕನ್ ಬಳಕೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಅಗತ್ಯವಿರುವ ಹೆಚ್ಚಿನ ಪಾಲಿಸಿಗಳು (policies) ಈಗಾಗಲೇ ಸ್ಟ್ಯಾಂಡರ್ಡ್ APIM ಟಿಯರ್ಗಳಲ್ಲಿ ಲಭ್ಯವಿವೆ—ಅವುಗಳನ್ನು XML ನಿಯಮಗಳಾಗಿ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಕಸ್ಟಮ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. AI ಟಿಯರ್ ಆ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಉದ್ದೇಶಕ್ಕಾಗಿ ರೂಪಿಸಲಾದ ಅನುಭವದಲ್ಲಿ (purpose-built experience) ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ:
- AI ಟ್ರಾಫಿಕ್ಗಾಗಿ ಸ್ಕೇಲಿಂಗ್ನ ಪ್ರತ್ಯೇಕತೆ (Isolation of scaling).
- ಕೈಯಿಂದ ತಯಾರಿಸಿದ XML ಪಾಲಿಸಿಗಳ ಅಗತ್ಯವಿಲ್ಲದಂತೆ ಸರಳೀಕೃತ ಕಾನ್ಫಿಗರೇಶನ್ (Simplified configuration).
ಇದರ ಮುಖ್ಯ ಬದಲಾವಣೆಯು ಕಾರ್ಯಾಚರಣೆಯದ್ದಾಗಿದೆ (operational): ಟೋಕನ್ ಬಜೆಟ್ಗಳನ್ನು ಜಾರಿಗೆ ತರಲು ನೀವು ಇನ್ನು ಮುಂದೆ ಸಂಕೀರ್ಣವಾದ ಕೋಡ್ ಬರೆಯುವ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಈ ಟಿಯರ್ ಆ ನಿಯಂತ್ರಣಗಳಿಗಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಯಾವಾಗ ಬದಲಾಯಿಸಬೇಕು – ಟ್ರಾಫಿಕ್ ಆಧಾರಿತ ಮಾರ್ಗದರ್ಶಿ
- AI ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ನ ಒಂದು ಸಣ್ಣ ಭಾಗವಾಗಿದ್ದರೆ. ನಿಮ್ಮ ಈಗಿನ APIM ಟಿಯರ್ ಅನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಿ ಮತ್ತು ನಿಖರವಾದ ನಿಯಂತ್ರಣ ಬೇಕಾದಲ್ಲಿ ಟೋಕನ್ ಪಾಲಿಸಿಗಳನ್ನು ಸೇರಿಸಿ.
- AI ನಿಮ್ಮ ಕರೆಗಳಲ್ಲಿ ಪ್ರಾಬಲ್ಯ ಹೊಂದಿದ್ದರೆ. ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಮತ್ತು ವೆಚ್ಚದ ಆಡಳಿತವನ್ನು (cost governance) ಸುಗಮವಾಗಿಡಲು AI ಟಿಯರ್ಗೆ ಬದಲಾಗಿ.
- ನೀವು ಇಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸದ ಹೊರೆ ತಪ್ಪಿಸಲು ಬಯಸಿದರೆ. ಈ ಟಿಯರ್ನ ಅಂತರ್ಗತ (built-in) ಪರಿಕರಗಳು ಕಸ್ಟಮ್ ಪಾಲಿಸಿಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ವ್ಯಯಿಸುವ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತವೆ.
ಅತಿ ದೊಡ್ಡ ವೆಚ್ಚವು ಸಬ್ಸ್ಕ್ರಿಪ್ಷನ್ ಬೆಲೆಯಲ್ಲ; ಬದಲಾಗಿ, ಸಾಮಾನ್ಯ ಗೇಟ್ವೇಯು ಟೋಕನ್ ಅರ್ಥಶಾಸ್ತ್ರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಂತೆ ಮಾಡಲು ಅದರಲ್ಲಿನ ನ್ಯೂನತೆಗಳನ್ನು ಸರಿಪಡಿಸಲು ವ್ಯಯಿಸುವ ಇಂಜಿನಿಯರಿಂಗ್ ಸಮಯವೇ ಅತಿ ದೊಡ್ಡ ವೆಚ್ಚವಾಗಿದೆ.
ಪ್ರಿವ್ಯೂ-ಫೇಸ್ (Preview-phase) ಪ್ಲೇಬುಕ್
Microsoft ಇನ್ನೂ AI ಟಿಯರ್ ಅನ್ನು ಪ್ರಿವ್ಯೂ ಹಂತದಲ್ಲಿ ನೀಡುತ್ತಿದೆ. ಇದನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಲಾಂಚ್ ಆಗಿ ನೋಡದೆ, ಒಂದು ಪರೀಕ್ಷಾ ವೇದಿಕೆಯಾಗಿ (testbed) ಪರಿಗಣಿಸಿ.
- ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಆಂತರಿಕ AI ವರ್ಕ್ಲೋಡ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಅತಿ ಹೆಚ್ಚು ಟೋಕನ್ ಟ್ರಾಫಿಕ್ ಸೃಷ್ಟಿಸುವ ಸೇವೆಯನ್ನು ಆರಿಸಿ.
- ಆ ವರ್ಕ್ಲೋಡ್ ಅನ್ನು AI ಟಿಯರ್ ಮೂಲಕ ರೌಟ್ ಮಾಡಿ. ಪ್ರತಿ ಬಳಕೆದಾರರ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಬಳಸಿ.
- ಕೆಲವು ವಾರಗಳ ಕಾಲ ಟೋಕನ್ ವೆಚ್ಚದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ. ನಿಮ್ಮ ಈಗಿನ ಮಾನಿಟರಿಂಗ್ ಜೊತೆಗೆ ಟೋಕನ್ ಸಂಖ್ಯೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವೆಚ್ಚಗಳನ್ನು ಹೋಲಿಸಿ ನೋಡಿ.
- ಬಜೆಟ್ ನಿರ್ಧರಿಸಲು ಬೇಸ್ಲೈನ್ ಬಳಸಿ. ಈ ಟಿಯರ್ನ ವೆಚ್ಚ-ನಿಯಂತ್ರಣ ಪ್ರಯೋಜನಗಳು ಅದರ ಪ್ರಿವ್ಯೂ-ಫೇಸ್ ಮಿತಿಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿವೆ ಎಂದು ನಿರ್ಧರಿಸಿ.
ಇದು ಜನರಲ್ ಅವೈಲಬಿಲಿಟಿ (general availability) ಹಂತಕ್ಕೆ ಬರುವವರೆಗೆ, ಅತ್ಯಂತ ನಿರ್ಣಾಯಕವಾದ ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಪ್ರಿವ್ಯೂ ಸೇವೆಗೆ ವರ್ಗಾಯಿಸಬೇಡಿ.
ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಪ್ರತ್ಯೇಕ ಟಿಯರ್ ಅಗತ್ಯವಿಲ್ಲ
ನಿಮ್ಮ ಸಂಸ್ಥೆಯು ಕೇವಲ ಅಲ್ಪ ಪ್ರಮಾಣದಲ್ಲಿ LLM ಕರೆಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದರೆ, AI ಟಿಯರ್ನ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚವು ಸಮರ್ಥನೀಯವಾಗಿಲ್ಲದಿರಬಹುದು. ಹೆಚ್ಚಿನ ಮ್ಯಾನುಯಲ್ ಪ್ರಯತ್ನದೊಂದಿಗೆ, ನೀವು ಈಗಿರುವ ಪಾಲಿಸಿ ಫ್ರೇಮ್ವರ್ಕ್ ಮೂಲಕ ಟೋಕನ್-ಮಟ್ಟದ ಆಡಳಿತವನ್ನು ಸಾಧಿಸಬಹುದು. ಆದರೆ AI ಟ್ರಾಫಿಕ್ ನಿಮ್ಮ API ಬಳಕೆಯ ಒಂದು ದೊಡ್ಡ ಮತ್ತು ಬೆಳೆಯುತ್ತಿರುವ ಭಾಗವಾಗಿದ್ದಾಗ ಈ ಟಿಯರ್ ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಸಾರಾಂಶ
LLM ಟ್ರಾಫಿಕ್ ಸಾಂಪ್ರದಾಯಿಕ API ಕರೆಗಳಿಗಿಂತ ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು AI Gateway tier ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ. ವಿನಂತಿ ಎಣಿಕೆಯಿಂದ (request counting) ಟೋಕನ್ ಆಧಾರಿತ ಆಡಳಿತಕ್ಕೆ (token-based governance) ಬದಲಾಗುವ ಮೂಲಕ, ಇದು ಸಂಕೀರ್ಣವಾದ ಕೋಡ್ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ AI ವೆಚ್ಚವನ್ನು ನಿಯಂತ್ರಿಸಲು ಡೆವಲಪರ್ಗಳಿಗೆ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಈಗಾಗಲೇ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ AI ಬಳಕೆಯನ್ನು ಹೊಂದಿರುವ ಅಥವಾ ಬೆಳೆಯುವ ನಿರೀಕ್ಷೆಯಿರುವ ತಂಡಗಳಿಗೆ, ಈಗಲೇ ಪ್ರಿವ್ಯೂ ಅನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಟೋಕನ್ ವೆಚ್ಚದ ಬೇಸ್ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.