ನೀವು Large Language Models (LLM) ಗಳ ಮೇಲೆ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ವೇತನ ಪಟ್ಟಿಯ (payroll) ನಂತರದ ಅತ್ಯಂತ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ವೆಚ್ಚವು ನಿಮ್ಮ Inference ಬಿಲ್ ಆಗಿರಬಹುದು. ಇದು ನಿಮ್ಮ ಪ್ರೊವೈಡರ್ನ ಯಾವುದೇ ಬೆಲೆ ಅಪ್ಡೇಟ್ ಅನ್ನು ಕೇವಲ ಮಾರ್ಕೆಟಿಂಗ್ ಗದ್ದಲವನ್ನಾಗಿ ಮಾಡದೆ, ಒಂದು ಪ್ರಮುಖ ಕಾರ್ಯಾಚರಣೆಯ ಘಟನೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. LLM ಹೋಸ್ಟಿಂಗ್ ಮತ್ತು APIಗಳಿಗಾಗಿ ಡೆವಲಪರ್ಗಳು ಪ್ರಸ್ತುತ ಬಳಸುತ್ತಿರುವ ಎರಡು ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಾದ Novita ಮತ್ತು StreamLake ಇತ್ತೀಚೆಗೆ ತಮ್ಮ ದರಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿವೆ. ನೀವು ಸೈಡ್-ಪ್ರಾಜೆಕ್ಟ್ ಚಾಟ್ಬಾಟ್ ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್ SaaS ಉತ್ಪನ್ನವನ್ನು ನಡೆಸುತ್ತಿದ್ದರೂ ಸಹ, ಈ ಬದಲಾವಣೆಗಳು ನಿಮ್ಮ ಯೂನಿಟ್ ಎಕನಾಮಿಕ್ಸ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ನೀವು ವಿವರಗಳನ್ನು ಗಮನಿಸಬೇಕು, ನಿಮ್ಮ ವೆಚ್ಚದ ದರವನ್ನು (burn rate) ಮರುಲೆಕ್ಕಹಾಕಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಸ್ಟ್ಯಾಕ್ (stack) ಇನ್ನೂ ಸೂಕ್ತವಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಬೇಕು.
ಇನ್ಫರೆನ್ಸ್ ಬೆಲೆಗೆ ನೀವು ಏಕೆ ಗಮನ ನೀಡಬೇಕು
ಹೆಚ್ಚಿನ ಡೆವಲಪರ್ಗಳು ಮಾಡೆಲ್ಗಳ ಕಾರಣಕ್ಕಾಗಿ AI ಇಂಜಿನಿಯರಿಂಗ್ ಕ್ಷೇತ್ರಕ್ಕೆ ಬರುತ್ತಾರೆಯೇ ಹೊರತು, ಬೆಲೆ ಪಟ್ಟಿಗಳನ್ನು ಓದಲು ಇಷ್ಟಪಡುವುದಕ್ಕಲ್ಲ. ಅದು ಒಂದು ತಪ್ಪು. Inference ಎಂಬುದು ಬಳಕೆಯ ಆಧಾರದ ಮೇಲೆ (consumption-based) ಇರುವ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ. ನೀವು ಸ್ಥಿರ ಮಾಸಿಕ ಶುಲ್ಕವನ್ನು ಪಾವತಿಸುವುದಿಲ್ಲ; ಸಿಸ್ಟಮ್ ಮೂಲಕ ಚಲಿಸುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ಗೆ ನೀವು ಪಾವತಿಸುತ್ತೀರಿ. ಪ್ರೊವೈಡರ್ ತನ್ನ ದರ ಪಟ್ಟಿಯನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಅದರ ಪರಿಣಾಮ ತಕ್ಷಣವೇ ಮತ್ತು ನೇರವಾಗಿ ಕಂಡುಬರುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ದಿನಕ್ಕೆ ಸರಾಸರಿ ಒಂದು ಲಕ್ಷ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಪ್ರತಿ ಟೋಕನ್ ವೆಚ್ಚದಲ್ಲಿನ ಸಣ್ಣ ಬದಲಾವಣೆಯೂ ಸಹ ನಿಮ್ಮ ಮಾಸಿಕ ಇನ್ವಾಯ್ಸ್ನಲ್ಲಿ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಪ್ರೊವೈಡರ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಬೆಲೆಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತಾರೆ. ಇನ್ಪುಟ್ ಟೋಕನ್ಗಳು ಪ್ರಾಂಪ್ಟ್ (prompt), ಸಿಸ್ಟಮ್ ಸೂಚನೆಗಳು ಮತ್ತು ನೀವು ವಿಂಡೋದಲ್ಲಿ ನೀಡುವ ಯಾವುದೇ ಸಂದರ್ಭವನ್ನು (context) ಒಳಗೊಂಡಿರುತ್ತವೆ. ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳು ಮಾಡೆಲ್ ನೀಡುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಕೆಲವು ಪ್ರೊವೈಡರ್ಗಳು ಎರಡಕ್ಕೂ ಒಂದೇ ದರವನ್ನು ವಿಧಿಸುತ್ತಾರೆ; ಇತರೆ ಪ್ರೊವೈಡರ್ಗಳು ಔಟ್ಪುಟ್ಗೆ ಹೆಚ್ಚಿನ ದರವನ್ನು ವಿಧಿಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಜನರೇಷನ್ (generation) ಕಂಪ್ಯೂಟೇಶನಲ್ ಆಗಿ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. Novita ಅಥವಾ StreamLake ತಮ್ಮ ಬೆಲೆಯನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದಾಗ, ಮುಖ್ಯವಾದ ಪ್ರಶ್ನೆಯು ಕೇವಲ “ಬೆಲೆ ಕಡಿಮೆಯಾಯಿತೇ ಅಥವಾ ಹೆಚ್ಚಾಯಿತೇ?” ಎಂಬುದಲ್ಲ. ಬದಲಾಗಿ “ಸಮೀಕರಣದ ಯಾವ ಭಾಗ ಬದಲಾಗಿದೆ ಮತ್ತು ಎಷ್ಟು ಬದಲಾಗಿದೆ?” ಎಂಬುದಾಗಿದೆ.
ಅಷ್ಟೇ ಅಲ್ಲದೆ, ಅಷ್ಟೇನೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದ ಇತರ ವೆಚ್ಚದ ಕಾರಣಗಳೂ ಇವೆ. ದೀರ್ಘವಾದ context windowsಗಳು ನಿರ್ದಿಷ್ಟ ಟೋಕನ್ ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ ಹೆಚ್ಚುವರಿ ಶುಲ್ಕದ (premium tiers) ವಿಭಾಗಕ್ಕೆ ತಳ್ಳುತ್ತವೆ. ಕೆಲವು ಪ್ರೊವೈಡರ್ಗಳು ಕನಿಷ್ಠ ಟೋಕನ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಪ್ರತಿ ವಿನಂತಿಗೆ (per request) ಬಿಲ್ ಮಾಡುತ್ತಾರೆ, ಅಂದರೆ ಒಂದು ಪದದ ಪ್ರಶ್ನೆಗೂ ಸಹ ನೀವು ಕನಿಷ್ಠ ಮೊತ್ತವನ್ನು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ. ರೇಟ್ ಲಿಮಿಟ್ಗಳು (Rate limits) ನಿಮ್ಮನ್ನು ಹೆಚ್ಚಿನ ಸಾರ್ಜ್ (surcharges) ಹೊಂದಿರುವ ಹೈಯರ್ ಕನ್ಕರನ್ಸಿ ಟಿಯರ್ಗಳಿಗೆ (higher concurrency tiers) ತಳ್ಳಬಹುದು. ನೀವು ಸಣ್ಣ ಅಕ್ಷರಗಳಲ್ಲಿರುವ ನಿಯಮಗಳನ್ನು (fine print) ಸರಿಯಾಗಿ ಓದದಿದ್ದರೆ, ನಿಮ್ಮ ವೆಚ್ಚಗಳು ಸ್ಥಿರವಾಗಿವೆ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು, ಆದರೆ ನಿಮ್ಮ ಬಿಲ್ ನಿಧಾನವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತಿರಬಹುದು.
Novita ಮತ್ತು StreamLake ನಲ್ಲಿ ಏನಾಯಿತು?
Novita ಒಂದು ಸರ್ವರ್ಲೆಸ್ ಇನ್ಫರೆನ್ಸ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಡೆವಲಪರ್ಗಳಿಗೆ GPU ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್ಗಳಿಗೆ API ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. StreamLake ಮಾಡೆಲ್ಗಳನ್ನು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ (at scale) ನಡೆಸಲು ಇದೇ ರೀತಿಯ ಮೂಲಸೌಕರ್ಯ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇವೆರಡೂ ಇತ್ತೀಚೆಗೆ ತಮ್ಮ LLM ಬೆಲೆಗಳನ್ನು ಪರಿಷ್ಕರಿಸಿವೆ, ಅಂದರೆ ಅವುಗಳ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳ (endpoints) ಮೂಲಕ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ತಗಲುವ ವೆಚ್ಚವು ಬದಲಾಗಿದೆ.
ಈ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ಹಲವಾರು ಮಾಡೆಲ್ ಕುಟುಂಬಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ ಮತ್ತು ಮಾಡೆಲ್ ಗಾತ್ರ ಹಾಗೂ context ಉದ್ದದ ಆಧಾರದ ಮೇಲೆ ಬೆಲೆಯಲ್ಲಿ ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡುವುದರಿಂದ, ಒಂದು “ಬೆಲೆ ಬದಲಾವಣೆ” ಘೋಷಣೆಯು ಅನೇಕ ವಿವರಗಳನ್ನು ಮರೆಮಾಚಬಹುದು. ಒಂದು ಮಾಡೆಲ್ ಅಗ್ಗವಾಗಬಹುದು ಮತ್ತು ಇನ್ನೊಂದು ಮಾಡೆಲ್ ದುಬಾರಿಯಾಗಬಹುದು. 4K ಟೋಕನ್ಗಳಿಗಿಂತ ಕಡಿಮೆ ಇರುವ context windowsಗಳ ಬೆಲೆ ಬದಲಾಗದೆ ಇರಬಹುದು, ಆದರೆ 128K contextಗಳಿಗೆ ಹೆಚ್ಚಿನ ಬೆಲೆ ಹೊಂದಾಣಿಕೆ (premium adjustment) ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಬ್ಯಾಚ್ ಪ್ರೊಸೆಸಿಂಗ್ ಅಥವಾ ಆಫ್-ಪೀಕ್ ಬಳಕೆಗೆ ನೀಡುವ ರಿಯಾಯಿತಿಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು ಅಥವಾ ಮಾಯವಾಗಬಹುದು. ಈ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳ ಕಾರಣದಿಂದಾಗಿ ನೀವು ಕೇವಲ ಹೆಡ್ಲೈನ್ ನೋಡಿ ತೃಪ್ತಿಪಡಬಾರದು. ನಿಮಗೆ ನಿಜವಾದ ದರ ಪಟ್ಟಿ (rate card) ಬೇಕಾಗುತ್ತದೆ.
ನಿಖರವಾದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಡೆವಲಪರ್ ವಿವರವು ಮೂಲ ಅಪ್ಡೇಟ್ ಪುಟದಲ್ಲಿ ಲಭ್ಯವಿದೆ. ಮುಂದಿನ ವಾರ ಮತ್ತೆ ಬದಲಾಗಬಹುದಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಊಹಿಸುವ ಬದಲು, ಮೂಲದಿಂದ ಪ್ರಸ್ತುತ ಅಂಕಿಅಂಶಗಳನ್ನು ಪಡೆದು ನಿಮ್ಮ ಕೊನೆಯ ಇನ್ವಾಯ್ಸ್ನೊಂದಿಗೆ ಸಾಲು ಸಾಲಾಗಿ ಹೋಲಿಸಿ ನೋಡಿ.
ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಮೇಲೆ ಆಗುವ ಪರಿಣಾಮವನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಬೇಕು (Audit)?
ಬೆಲೆ ಬದಲಾವಣೆಯ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಾಗ, ಗಾಬರಿಯಾಗುವ ಅಥವಾ ಸಂಭ್ರಮಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಬಳಕೆಯ ಬಗ್ಗೆ ತಕ್ಷಣದ ರೋಗನಿರ್ಣಯವನ್ನು (diagnostic) ಮಾಡಿಕೊಳ್ಳಿ.
1. ನಿಮ್ಮ ಟೋಕನ್ ಹಿಸ್ಟೋಗ್ರಾಮ್ ಅನ್ನು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿ. ಹೆಚ್ಚಿನ ಪ್ರೊವೈಡರ್ಗಳು ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಬಳಕೆಯನ್ನು ವಿಂಗಡಿಸುವ ಬಳಕೆ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು ಅಥವಾ API ಲಾಗ್ಗಳನ್ನು ನೀಡುತ್ತಾರೆ. ಅನುಪಾತವನ್ನು ಗಮನಿಸಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ಗಳು ಮತ್ತು RAG context ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ನೀವು ಇನ್ಪುಟ್-ಬಯಾಸ್ಡ್ (input-biased) ಆಗಿದ್ದೀರಿ ಎಂದರ್ಥ. ನೀವು ದೀರ್ಘ ಲೇಖನಗಳು, ಕೋಡ್ ಅಥವಾ ಮಲ್ಟಿ-ಸ್ಟೆಪ್ ರೀಸನಿಂಗ್ ಚೇನ್ಗಳನ್ನು ರಚಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಔಟ್ಪುಟ್-ಬಯಾಸ್ಡ್ (output-biased) ಆಗಿದ್ದೀರಿ ಎಂದರ್ಥ. ಬೆಲೆ ಬದಲಾವಣೆಯೊಂದಿಗೆ ನಿಮ್ಮ ಬಳಕೆಯ ವಿಧಾನವನ್ನು ಹೋಲಿಸಿ ನೋಡಿ. ಇನ್ಪುಟ್ ಬೆಲೆ ಇಳಿಕೆಯು RAG ಪೈಪ್ಲೈನ್ಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ; ಔಟ್ಪುಟ್ ಬೆಲೆ ಏರಿಕೆಯು ರೈಟಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ಗೆ ತೊಂದರೆ ನೀಡುತ್ತದೆ.
2. ಬಳಕೆಯ ಪ್ರಮಾಣದ ಆಧಾರದ ಮೇಲೆ ನಿಮ್ಮ ಟಾಪ್ ಐದು ಮಾಡೆಲ್ಗಳನ್ನು ಗುರುತಿಸಿ. ನೀವು ವರ್ಗೀಕರಣಕ್ಕಾಗಿ (classification) ವೇಗವಾದ ಅಗ್ಗದ ಮಾಡೆಲ್ ಮತ್ತು ಸಾರಾಂಶಕ್ಕಾಗಿ (summarization) ದೊಡ್ಡ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತಿರಬಹುದು. ಬೆಲೆ ಬದಲಾವಣೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ಮಾಡೆಲ್ಗಳ ಮೇಲೆ ಏಕರೂಪವಾಗಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. Novita ಅಥವಾ StreamLake ಸಣ್ಣ ಕ್ಲಾಸಿಫೈಯರ್ನ ದರವನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿ ಆದರೆ ದೊಡ್ಡ ಮಾಡೆಲ್ ಅನ್ನು ಹಾಗೆಯೇ ಬಿಟ್ಟರೆ, ಪ್ರತಿ ವಿನಂತಿಗೆ ನಿಮ್ಮ ಸರಾಸರಿ ವೆಚ್ಚದಲ್ಲಿ ಹೆಚ್ಚಿನ ಬದಲಾವಣೆ ಕಂಡುಬರುವುದಿಲ್ಲ.
3. ಬಂಡಲ್ ಮಾಡಲಾದ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಕೆಲವೊಮ್ಮೆ ಬೆಲೆ ಏರಿಕೆಯೊಂದಿಗೆ context-window ವಿಸ್ತರಣೆ, ಹೊಸ fine-tuning endpoint ಅಥವಾ ಪರಿಷ್ಕೃತ rate limits ಕೂಡ ಬರುತ್ತವೆ. ಒಂದು ವೇಳೆ ಪ್ರೊವೈಡರ್ ಲಭ್ಯವಿರುವ concurrency ಅನ್ನು ಎರಡರಷ್ಟು ಹೆಚ್ಚಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಬಳಕೆದಾರರ ಅನುಭವಕ್ಕೆ ತೊಂದರೆ ನೀಡುತ್ತಿದ್ದ queueing delays ಅನ್ನು ತೆಗೆದುಹಾಕಿದ್ದರೆ, ಹೆಚ್ಚಿನ per-token ವೆಚ್ಚವನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬಹುದು. ವೆಚ್ಚವು ಕೇವಲ ಒಂದು ಅಂಶವಷ್ಟೇ; latency ಮತ್ತು reliability ಕೂಡ ಮುಖ್ಯವಾಗಿವೆ.
4. ಮುಂದಿನ ಮೂವತ್ತು ದಿನಗಳ ಮಾದರಿಯನ್ನು ರೂಪಿಸಿ. ಕಳೆದ ವಾರದ token count ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಹೊಸ ದರಗಳನ್ನು ಅನ್ವಯಿಸಿ ಮತ್ತು ಮಾಸಿಕ run rate ಅನ್ನು ಅಂದಾಜಿಸಿ. ಒಂದು ವೇಳೆ ವ್ಯತ್ಯಾಸವು ಐದು ಪ್ರತಿಶತಕ್ಕಿಂತ ಕಡಿಮೆ ಇದ್ದರೆ ಮತ್ತು ನೀವು ಇನ್ನೂ ಉತ್ತಮ latency ಪಡೆಯುತ್ತಿದ್ದರೆ, APIಗಳನ್ನು ಬದಲಾಯಿಸುವ ವೆಚ್ಚವು ಉಳಿತಾಯಕ್ಕಿಂತ ಹೆಚ್ಚಿರಬಹುದು. ಒಂದು ವೇಳೆ ವ್ಯತ್ಯಾಸವು ಇಪ್ಪತ್ತೈದು ಪ್ರತಿಶತವಾಗಿದ್ದರೆ, ಚೌಕಾಸಿ ಮಾಡಲು, ಉತ್ತಮಗೊಳಿಸಲು (optimize) ಅಥವಾ ಬೇರೆ ಆಯ್ಕೆಗಳನ್ನು ಹುಡುಕಲು ಇದು ಸರಿಯಾದ ಸಮಯ.
Inference ವೆಚ್ಚಗಳನ್ನು ಮುನ್ಸೂಚನೆಗೆ ಒಳಪಡುವಂತೆ (Predictable) ಇರಿಸಲು ತಂತ್ರಗಳು
Novita ಮತ್ತು StreamLake ಬೆಲೆಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಇರಿಸಿದ್ದರೂ ಸಹ, ನೀವು token ಬಳಕೆಯ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಇರಬೇಕು. ಮಾದರಿಯನ್ನು (model) ಯಾರು ಹೋಸ್ಟ್ ಮಾಡುತ್ತಾರೆ ಎನ್ನುವುದನ್ನು ಲೆಕ್ಕಿಸದೆ ನಿಮ್ಮ ಲಾಭದ ಮಾರ್ಜನ್ ಅನ್ನು ರಕ್ಷಿಸುವ ಕೆಲವು ಪ್ರಾಯೋಗಿಕ ಅಭ್ಯಾಸಗಳು ಇಲ್ಲಿವೆ.
ನಿಮ್ಮ promptsಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ (Compress). ನಿಮ್ಮ system prompt ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಅನಗತ್ಯ ವಾಕ್ಯವು ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯ ಮೇಲೂ ಒಂದು ತೆರಿಗೆಯಂತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅನಗತ್ಯ ಪದಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ನಿಮ್ಮ JSON schemas ನಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತ ಲೇಬಲ್ಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಸೂಚನೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿ. ನೀವು ಒಂದು prompt ಅನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಬಳಸುವ ಮೊದಲು tokenizer ಬಳಸಿ token count ಅನ್ನು ಅಳೆಯಿರಿ. ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲಿ ಉಳಿತಾಯವಾಗುವ ನೂರು ಬೈಟ್ಗಳು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ನಿಜವಾದ ಹಣವಾಗಿ ಬದಲಾಗುತ್ತವೆ.
Deterministic queries ಗಳನ್ನು cache ಮಾಡಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ಪದೇ ಪದೇ ಒಂದೇ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಿದ್ದರೆ ಅಥವಾ ನಿಮ್ಮ backend ಡೇಟಾದ ಮೇಲೆ ಒಂದೇ ರೀತಿಯ classification ಕಾರ್ಯಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದರೆ, ಫಲಿತಾಂಶವನ್ನು ಕೆಲವು ನಿಮಿಷಗಳು ಅಥವಾ ಗಂಟೆಗಳ ಕಾಲ ಸಂಗ್ರಹಿಸಿಡಿ. ನಿಮ್ಮ LLM client ಮುಂದೆ ಒಂದು ಸಣ್ಣ caching layer ಅನ್ನು ಬಳಸುವುದರಿಂದ ಮಾದರಿಯ ಗುಣಮಟ್ಟವನ್ನು ಬದಲಿಸದೆ ವಿನಂತಿಗಳ ಪ್ರಮಾಣವನ್ನು ಅರ್ಧದಷ್ಟು ಕಡಿಮೆ ಮಾಡಬಹುದು.
ಕಾರ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಮಾದರಿಗಳನ್ನು (models) ಬದಲಾಯಿಸಿ. ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಗೂ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿರುವ ಅತ್ಯಂತ ಸಮರ್ಥ ಮತ್ತು ಅತ್ಯಂತ ದುಬಾರಿ ಮಾದರಿಯ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ. ಸರಳ ಕಾರ್ಯಗಳನ್ನು ಸಣ್ಣ ಮತ್ತು ಅಗ್ಗದ checkpoints ಗೆ ವರ್ಗಾಯಿಸಿ ಮತ್ತು ಕಠಿಣ ಸಂದರ್ಭಗಳಿಗಾಗಿ (edge cases) ದೊಡ್ಡ ಮಾದರಿಗಳನ್ನು ಮೀಸಲಿಡಿ. StreamLake ಅಥವಾ Novita ತಮ್ಮ mid-tier ಮಾದರಿಗಳನ್ನು ಹೆಚ್ಚು ಸ್ಪರ್ಧಾತ್ಮಕವಾಗಿಸಲು ಬೆಲೆಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದ್ದರೆ, ಅದು ನಿಮ್ಮ routing rules ಅನ್ನು ಮರುಸಮತೋಲನಗೊಳಿಸಲು ಒಂದು ಸೂಚನೆಯಾಗಿದೆ.
Token ceilings ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ generation calls ನಲ್ಲಿ output ಉದ್ದಕ್ಕೆ ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ ಮಿತಿಯನ್ನು (ceiling) ನಿಗದಿಪಡಿಸಿ. ಬಳಕೆದಾರರು ಸಾರಾಂಶವನ್ನು ಕೇಳಿದಾಗ, ಮಾದರಿಯು ಸಾವಿರ ಟೋಕನ್ಗಳವರೆಗೆ ವಿಸ್ತರಿಸಲು ಬಿಡುವ ಬದಲು ಅದನ್ನು ಇನ್ನೂರು ಟೋಕನ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಕ್ಷಿಪ್ತ ಉತ್ತರಗಳನ್ನೇ ಇಷ್ಟಪಡುತ್ತಾರೆ.
Reserved capacity ಅಥವಾ commitment discounts ಬಗ್ಗೆ ಗಮನವಿರಲಿ. ನಿಮ್ಮ ಬಳಕೆಯ ಪ್ರಮಾಣವು ಸ್ಥಿರವಾಗಿದ್ದರೆ, serverless per-token ಬೆಲೆಗಳು ಕಂಪ್ಯೂಟ್ ಖರೀದಿಸಲು ಅತ್ಯಂತ ದುಬಾರಿ ಮಾರ್ಗವಾಗಬಹುದು. ಕೆಲವು ಪ್ರೊವೈಡರ್ಗಳು ಕಡಿಮೆ ಏಕಮಾನ ದರಕ್ಕಾಗಿ (unit rate) ನಮ್ಯತೆಯನ್ನು (flexibility) ಬಿಟ್ಟುಕೊಡುವ reserved throughput ಅಥವಾ enterprise commits ಗಳನ್ನು ನೀಡುತ್ತಾರೆ. ಬೆಲೆ ಬದಲಾವಣೆಯು ಮಾರ್ಕೆಟಿಂಗ್ ಸೈಟ್ನಲ್ಲಿ ಪ್ರಕಟಿಸದ ಗುಪ್ತ ಹಂತಗಳ (hidden tiers) ಬಗ್ಗೆ ಅವರ ಸೇಲ್ಸ್ ತಂಡವನ್ನು ಕೇಳಲು ಒಂದು ಉತ್ತಮ ಅವಕಾಶವಾಗಿದೆ.
ವಿವರಗಳನ್ನು ಎಲ್ಲಿ ಗಮನಿಸಬೇಕು
LLM ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಮಾರುಕಟ್ಟೆಯು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿರುವುದರಿಂದ, ಸ್ಥಿರವಾದ ಲೇಖನಗಳು ಬೇಗನೆ ಹಳೆಯದಾಗುತ್ತವೆ. ಯಾವ Novita ಮತ್ತು StreamLake endpoints ಬದಲಾಗಿವೆ, ಎಷ್ಟು ಬದಲಾಗಿವೆ ಮತ್ತು ಯಾವ ಮಾದರಿಗಳು ಬಾಧಿತವಾಗಿವೆ ಎಂಬ ಸಂಪೂರ್ಣ ವಿವರಗಳನ್ನು ಲಿಂಕ್ ಮಾಡಲಾದ developer update ನಲ್ಲಿ ನೀಡಲಾಗಿದೆ.
ಪ್ರೊವೈಡರ್ ಬೆಲೆಗಳು, ಬಿಲ್ಲಿಂಗ್ ತಂತ್ರಗಳು ಮತ್ತು ಮಾದರಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಿಸುತ್ತಿರುವ ಇತರ ಬಿಲ್ಡರ್ಗಳೊಂದಿಗೆ ನಿರಂತರ ಚರ್ಚೆಯನ್ನು ನೀವು ಬಯಸಿದರೆ, GyaanSetu Telegram ಸಮುದಾಯವು ತೆರೆದಿದೆ. ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ತಮ್ಮ ದರಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಮತ್ತು ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಮರುರೂಪಿಸಬೇಕೇ (refactor) ಅಥವಾ ಹೆಚ್ಚಳವನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬೇಕೇ ಎಂಬ ಬಗ್ಗೆ ಎರಡನೇ ಅಭಿಪ್ರಾಯ ಬೇಕಾದಾಗ ಇದು ಉಪಯುಕ್ತವಾದ ಸ್ಥಳವಾಗಿದೆ.
ನಿಜವಾದ ಸಾರಾಂಶ
ಬೆಲೆ ಬದಲಾವಣೆಗಳು ಕೇವಲ ಮಾರಾಟಗಾರರ ಸುದ್ದಿಗಳಲ್ಲ; ಅವು ನಿಮ್ಮ ವೆಚ್ಚದ ಊಹೆಗಳು ವಾಸ್ತವದೊಂದಿಗೆ ಮರುಸಮನ್ವಯಗೊಳ್ಳಬೇಕಿದೆ ಎಂಬ ಸೂಚನೆಗಳಾಗಿವೆ. Novita ಮತ್ತು StreamLake ತಮ್ಮ LLM ದರಗಳನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದೆವು, ಅಂದರೆ ನೀವು ಮೂರು ತಿಂಗಳ ಹಿಂದೆ ತಯಾರಿಸಿದ spreadsheet ಬಹುಶಃ ತಪ್ಪಾಗಿರಬಹುದು. ನಿಮ್ಮ ಬಳಕೆಯ ಡೇಟಾವನ್ನು ಪಡೆದುಕೊಳ್ಳಿ, ಹೊಸ ದರ ಪಟ್ಟಿಯನ್ನು ಅನ್ವಯಿಸಿ, ನಿಮ್ಮ routing logic ಅನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಉತ್ತಮಗೊಳಿಸಬೇಕೇ, ಚೌಕಾಸಿ ಮಾಡಬೇಕೇ ಅಥವಾ ಬದಲಾಯಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ. Inference ಎಂಬುದು ಸ್ಥಿರವಾದ ವೆಚ್ಚವಲ್ಲ; ಇದು ನಿಮ್ಮ ಯಶಸ್ಸಿನೊಂದಿಗೆ ಬೆಳೆಯುವ ಬದಲಾಗುವ ವೆಚ್ಚವಾಗಿದೆ (variable cost). ಅದನ್ನು ಹಾಗೆಯೇ ಪರಿಗಣಿಸಿ.