ನೀವು ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳ (large language models) ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಉತ್ಪನ್ನವನ್ನು ಮಾರುಕಟ್ಟೆಗೆ ತರುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಲಾಭದ ಪ್ರಮಾಣವು (margin) ನಿಮ್ಮ ಸೇವಾ ಪೂರೈಕೆದಾರರ ದರ ಪಟ್ಟಿಯ (rate card) ಸ್ಥಿರತೆಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ. Novita ಮತ್ತು StreamLake ಎರಡೂ ಇತ್ತೀಚೆಗೆ ತಮ್ಮ ಮಾದರಿ ಬೆಲೆಗಳನ್ನು (model pricing) ಅಪ್ಡೇಟ್ ಮಾಡಿವೆ, ಇದರರ್ಥ ನೀವು ಗಮನಿಸಿದ್ದೀರಾ ಅಥವಾ ಇಲ್ಲವೇ, ನಿಮ್ಮ ಘಟಕ ಅರ್ಥಶಾಸ್ತ್ರವು (unit economics) ಬದಲಾಗಿದೆ ಎಂದರ್ಥ. ಇವು ಸಾಮಾನ್ಯ ನಿರ್ವಹಣಾ ಅವಧಿಗಳಲ್ಲ (routine maintenance windows). ಇನ್ಫರೆನ್ಸ್ ಪೂರೈಕೆದಾರರು (inference providers) ತಮ್ಮ ಪ್ರತಿ-ಟೋಕನ್ ದರಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ ಅನ್ನು ವರ್ಗೀಕರಿಸಲು, ದಾಖಲೆಯನ್ನು ಸಾರಾಂಶಗೊಳಿಸಲು ಅಥವಾ ಕೋಡ್ ಸಲಹೆಯನ್ನು ರಚಿಸಲು ತಗಲುವ ವೆಚ್ಚವು ರಾತ್ರೋರಾತ್ರಿ ಬದಲಾಗುತ್ತದೆ. API ಬೆಲೆಗಳನ್ನು ಸ್ಥಿರವಾದ ಹಿನ್ನೆಲೆ ಶಬ್ದವೆಂದು (static background noise) ಪರಿಗಣಿಸುವ ಡೆವಲಪರ್ಗಳು, ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಮಾಸಿಕ ಬಿಲ್ ಬಂದಾಗ ಮಾತ್ರ ಸಮಸ್ಯೆಯನ್ನು ಅರಿಯುತ್ತಾರೆ.
ಮೌನವಾಗಿ ನಡೆಯುವ ಬೆಲೆ ಬದಲಾವಣೆ ಹೇಗೆ ಬಜೆಟ್ ಅನ್ನು ಹಾಳುಮಾಡಬಹುದು
ಹೆಚ್ಚಿನ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಒಂದು ಇನ್ಫರೆನ್ಸ್ ಪೂರೈಕೆದಾರರನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ, ಕೆಲವು ಲೇಟೆನ್ಸಿ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳನ್ನು (latency benchmarks) ನಡೆಸುತ್ತವೆ ಮತ್ತು ನಂತರ ಮುಂದುವರಿಯುತ್ತವೆ. ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್ಗಳನ್ನು (prompt templates) ವರ್ಷನ್ ಕಂಟ್ರೋಲ್ಗೆ ಕಮಿಟ್ ಮಾಡಲಾಗುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಕೋಡ್ ಪ್ರೊಡಕ್ಷನ್ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಹಣಕಾಸು ತಂಡವು ಅಂದಾಜು ಮಾಸಿಕ ಅಂದಾಜನ್ನು ಪಡೆಯುತ್ತದೆ. ಆ ಕೆಲಸದ ವಿಧಾನವು (workflow) ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಯಾವಾಗಲಾದರೂ ಅದು ವಿಫಲವಾಗಬಹುದು. ಟೋಕನ್ಗಳು ಬಳಕೆಯಾಗುವ ಸಂಪನ್ಮೂಲಗಳಾಗಿವೆ (consumable resource). ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ, ಸಂದರ್ಭದ ಉದ್ದ (context length) ಮತ್ತು ಮರುಪ್ರಯತ್ನದ ನಡವಳಿಕೆಗೆ (retry behavior) ಅನುಗುಣವಾಗಿ ನಿಮ್ಮ ಬಿಲ್ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಸ್ಪ್ರೆಡ್ಶೀಟ್ನಲ್ಲಿ ಸಣ್ಣದಾಗಿ ಕಾಣುವ ದರ ಏರಿಕೆಯು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಬಳಕೆಯಾಗುವ ಫೀಚರ್ನ ಲಾಭವನ್ನು (margin) ಸಂಪೂರ್ಣವಾಗಿ ಅಳಿಸಿಹಾಕಬಹುದು.
ಇದರ ಪರಿಣಾಮವು ಸಂಪೂರ್ಣವಾಗಿ ನಿಮ್ಮ ಬಳಕೆಯ ಮಾದರಿಯನ್ನು (usage shape) ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಸಣ್ಣ ವರ್ಗೀಕರಣ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು (classification prompts) ಕಳುಹಿಸುವ ತಂಡವು ಯಾವುದೇ ಬದಲಾವಣೆ ಮಾಡದೆಯೇ ಬೆಲೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬಹುದು. ದೀರ್ಘ ಸಂದರ್ಭಗಳನ್ನಾಡುವ (long context windows) ಅಥವಾ ಸಾವಿರಾರು ಪುಟಗಳ ಮೇಲೆ ಬ್ಯಾಚ್ ಕೆಲಸಗಳನ್ನು (batch jobs) ಮಾಡುವ ತಂಡವು ತಮ್ಮ ವೆಚ್ಚದ ದರವು (burn rate) ವೇಗವಾಗಿ ಏರುವುದನ್ನು ನೋಡಬಹುದು. ನಿಮ್ಮ ಸರಾಸರಿ ಕರೆ (average call) ಇನ್ನೂರು ಟೋಕನ್ಗಳೇ ಅಥವಾ ಇಪ್ಪತ್ತು ಸಾವಿರ ಟೋಕನ್ಗಳೇ ಎಂಬುದರ ಮೇಲೆ ಅದೇ ಶೇಕಡಾವಾರು ಬದಲಾವಣೆಯು ವಿಭಿನ್ನವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ Novita ಮತ್ತು StreamLake ನೀಡುವ ಅಪ್ಡೇಟ್ಗಳನ್ನು ಕೂಲಂಕಷವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ. ಬಳಕೆದಾರರ ಸರಾಸರಿ ವೆಚ್ಚವು ನಿಮ್ಮ ಅಂದಾಜಿನಿಂದ ಹೊರಬಂದಿದೆಯೇ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ (reroute traffic) ಸಮಯ ಬಂದಿದೆಯೇ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿಯಬೇಕಾಗುತ್ತದೆ.
Novita ನ ಬೆಲೆ ಅಪ್ಡೇಟ್
Novita ಇತ್ತೀಚೆಗೆ ತನ್ನ ಮಾದರಿ ಬೆಲೆಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದೆ. ಈ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವಿವಿಧ ಭಾಷಾ ಮಾದರಿಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿನ ಯಾವುದೇ ಬದಲಾವಣೆಯು ಅದನ್ನು ಪ್ರಾಥಮಿಕ ಇನ್ಫರೆನ್ಸ್ ಲೇಯರ್ ಆಗಿ ಬಳಸುವ ತಂಡಗಳ ಕಾರ್ಯಾಚರಣಾ ವೆಚ್ಚದ ಮೇಲೆ ನೇರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. Novita ಹಲವಾರು ಮಾದರಿಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವುದರಿಂದ, ಈ ಅಪ್ಡೇಟ್ ಎಲ್ಲಾ ಮಾದರಿಗಳಿಗೂ ಒಂದೇ ರೀತಿ ಇರಲಿಕ್ಕಿಲ್ಲ. ಒಂದು ಮಾದರಿಯ ಗುಂಪು ಬೆಲೆ ಬದಲಾಯಿಸದೆ ಇರಬಹುದು, ಆದರೆ ಇನ್ನೊಂದು ಬದಲಾಗಬಹುದು. ಸಾಮಾನ್ಯ ಘೋಷಣೆಯಗಿಂತ ಈ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ.
ನೀವು ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಒಂದೇ ಮಾದರಿ ಐಡಿ (model ID) ಮೂಲಕ ಕಳುಹಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಹೊಸ ಅಂದಾಜು ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕುವುದು ಸುಲಭ. ನೀವು Novita ನ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ಬಳಸುತ್ತಿದ್ದರೆ, ಅಂದರೆ ಸಂಕೀರ್ಣ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ದೊಡ್ಡ ಮಾದರಿಗಳಿಗೆ ಮತ್ತು ಸರಳ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಸಣ್ಣ ಮಾದರಿಗಳಿಗೆ ಕಳುಹಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಮಿಶ್ರ ಸರಾಸರಿ ವೆಚ್ಚವು (blended average cost) ಯಾವುದೇ ಒಂದೇ ಅಲರ್ಟ್ ವಿವರಿಸಲಾಗದ ರೀತಿಯಲ್ಲಿ ಬದಲಾಗಿರಬಹುದು. ಇದನ್ನು ತಿಳಿಯಲು ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ನಿಮ್ಮ ಬಳಕೆಯ ಲಾಗ್ಗಳನ್ನು (usage logs) ಪಡೆದು, ಅವುಗಳನ್ನು ಮಾದರಿಯ ಆಧಾರದ ಮೇಲೆ ಗುಂಪು ಮಾಡಿ, ನೈಜ ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಹೊಸ ದರ ಪಟ್ಟಿಯೊಂದಿಗೆ ಗುಣಾಕಾರ ಮಾಡುವುದು. ಪ್ರತಿ ಮಿಲಿಯನ್ ಟೋಕನ್ಗಳ ಬೆಲೆ ಏನಾಗಿತ್ತು ಎಂಬ ನೆನಪಿನ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ. ಅದನ್ನು ಬರೆದಿಡಿ. ಐತಿಹಾಸಿಕ ದಾಖಲೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಮುಂದಿನ ಬದಲಾವಣೆಯು ನಿಮ್ಮನ್ನು ಅಚ್ಚರಿಗೊಳಿಸದಂತೆ ಇದನ್ನು ನಿಮ್ಮ ತ್ರೈಮಾಸಿಕ ವಿಮರ್ಶಾ ಚಕ್ರದ (quarterly review cycle) ಭಾಗವಾಗಿಸಿಕೊಳ್ಳಿ.
StreamLake ನ ಬೆಲೆ ಅಪ್ಡೇಟ್
StreamLake ಕೂಡ ತನ್ನ ಮಾದರಿಗಳ ಮೇಲೆ ಬೆಲೆ ಅಪ್ಡೇಟ್ ಅನ್ನು ಜಾರಿಗೆ ತಂದಿದೆ. ಇದರ ಸ್ಟ್ಯಾಕ್ನೊಂದಿಗೆ (stack) ಸಂಯೋಜಿತವಾಗಿರುವ ತಂಡಗಳಿಗೆ, ಟೋಕನ್ ದರಗಳಲ್ಲಿನ ಯಾವುದೇ ಹೊಂದಾಣಿಕೆಯು ಕಂಟೆಂಟ್ ಅನಾಲಿಸಿಸ್, ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಶನ್ ಬ್ಯಾಕ್ಎಂಡ್ಗಳು, ಜನರೇಟಿವ್ ಫೀಚರ್ಗಳು ಅಥವಾ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮೂಲಕ ಚಲಿಸುವ ಯಾವುದೇ ಇತರ ಭಾಷಾ ಕೆಲಸದ (language workload) ಲೆಕ್ಕಾಚಾರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಹೊಂದಾಣಿಕೆಯ ಸಂಪೂರ್ಣ ಗಾತ್ರಕ್ಕಿಂತ ಅದರ ಸಂಯೋಜಿತ ಪರಿಣಾಮ (compounding effect) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ. ನೀವು ಪ್ರತಿದಿನ ಹಲವಾರು ಪರಿಸರಗಳಲ್ಲಿ (environments) ಲಕ್ಷಾಂತರ ಟೋಕನ್ಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡುತ್ತಿದ್ದಾಗ, ಸಣ್ಣ ಪ್ರಮಾಣದ ಪ್ರತಿ-ಟೋಕನ್ ಏರಿಕೆಯೂ ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ನಿಜವಾದ ಪ್ರಶ್ನೆಯೆಂದರೆ ಹೊಸ ಬೆಲೆ ಎಷ್ಟು ಎಂಬುದು ಅಲ್ಲ, ಬದಲಾಗಿ ಆ ಹೊಸ ಬೆಲೆಯು ಪ್ರತಿ ಫೀಚರ್ನ ನಿಮ್ಮ ಒಟ್ಟು ಲಾಭದ ಮೇಲೆ (gross margin) ಎಂತಹ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದು. StreamLake ಗ್ರಾಹಕರಿಗೆ ಲಭ್ಯವಿರುವ ಸಾರಾಂಶ ಸಾಧನ ಅಥವಾ ಆಂತರಿಕ ಮಾಡರೇಶನ್ ಲೇಯರ್ ಅನ್ನು ಪೂರೈಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಮಾರಾಟದ ಸರಕುಗಳ ವೆಚ್ಚವು (cost of goods sold) ಈಗ ಬದಲಾಗಿದೆ ಎಂದರ್ಥ. ನಿಮ್ಮ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ಟೂಲಿಂಗ್ನಲ್ಲಿ (observability tooling) ಆ ವೆಚ್ಚವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಬೇಕು. ಆ API ಕರೆಗಳನ್ನು ಪೂರೈಕೆದಾರ ಮತ್ತು ಫೀಚರ್ ಆಧಾರದ ಮೇಲೆ ಟ್ಯಾಗ್ ಮಾಡಿ, ಇದರಿಂದ ಇನ್ವಾಯ್ಸ್ ಬಂದಾಗ ನೀವು ಅದನ್ನು ನಿಖರವಾಗಿ ವಿಂಗಡಿಸಬಹುದು. ಒಂದು ಬಳಕೆ ಪ್ರಕರಣವು (use case) ಲಾಭದಾಯಕವಾಗಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ನಿಯಂತ್ರಿಸಬೇಕೇ (throttle), ಸಣ್ಣ ಮಾದರಿಗೆ ಡೌನ್ಗ್ರೇಡ್ ಮಾಡಬೇಕೇ ಅಥವಾ ಅದನ್ನು ಕಾರ್ಯತಂತ್ರದ ವೆಚ್ಚವಾಗಿ (strategic cost) ಸ್ವೀಕರಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಲು ನಿಮ್ಮ ಬಳಿ ಡೇಟಾ ಇರಬೇಕು.
ನಿಮ್ಮ ಇನ್ಫರೆನ್ಸ್ ವೆಚ್ಚವನ್ನು ಹೇಗೆ ಆಡಿಟ್ ಮಾಡುವುದು
ಸ್ವೀಕರಿಸುವುದು