ಮೌನವಾಗಿ ನಡೆಯುವ ಮೂಲಸೌಕರ್ಯ ಬದಲಾವಣೆಗಳು (infrastructure changes) ಹೊಸ ಫೀಚರ್‌ಗಳ ಬಿಡುಗಡೆಯಿಗಿಂತ ವೇಗವಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಬಜೆಟ್‌ಗಳನ್ನು ಮರುರೂಪಿಸುತ್ತವೆ. StreamLake ನಂತಹ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತನ್ನ LLM ಬೆಲೆಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದಾಗ, ಅದರ ಪರಿಣಾಮವು ಪ್ರತಿಯೊಂದು API ಕಾಲ್, ಪ್ರತಿಯೊಂದು ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ಜಾಬ್ ಮತ್ತು ಆ ಮಾದರಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಪ್ರತಿಯೊಂದು ಬಳಕೆದಾರರ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಮೇಲೆ ಬೀರುತ್ತದೆ. ನೀವು StreamLake ಮೇಲೆ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈಗ ನಿಮ್ಮ ಬಳಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು (usage dashboards) ಪರಿಶೀಲಿಸಲು ಮತ್ತು ನಿಮ್ಮ ಟೋಕನ್‌ಗಳು ಎಲ್ಲಿ ಬಳಕೆಯಾಗುತ್ತಿವೆ ಎಂಬುದನ್ನು ಸೂಕ್ಷ್ಮವಾಗಿ ಗಮನಿಸಲು ಸರಿಯಾದ ಸಮಯವಾಗಿದೆ. StreamLake ನಲ್ಲಿನ ಇತ್ತೀಚಿನ ಬೆಲೆ ಅಪ್‌ಡೇಟ್ ವಿವಿಧ ಮಾದರಿಗಳಿಗೆ (models) ಹೇಗೆ ಬಿಲ್ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಅಂದರೆ ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಸ್ಟ್ಯಾಕ್ ಕಳೆದ ತಿಂಗಳಿಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಅಥವಾ ಕೆಲವು ದರಗಳು ನಿಮಗೆ ಅನುಕೂಲಕರವಾಗಿ ಬದಲಾಗಿದ್ದರೆ, ನೀವು ವಿಸ್ತರಿಸಲು (scale) ಅವಕಾಶ ಸಿಗಬಹುದು.

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬೆಲೆ ಬದಲಾವಣೆಗಳು ಏಕೆ ನಿಜವಾದ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿವೆ

StreamLake ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಬೆಳೆಯುತ್ತಿರುವ ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್‌ಗಳ (large language models) ನಡುವೆ ಒಂದು ಪದರವಾಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನೀವು ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ (endpoint) ಮೂಲಕ GPT-4, Claude, Llama ಅಥವಾ ಓಪನ್-ವೇಟ್ ಮತ್ತು ಪ್ರೊಪ್ರೈಟರಿ ಮಾದರಿಗಳ ಮಿಶ್ರಣವನ್ನು ಬಳಸುತ್ತಿರಬಹುದು. ಆ ಅನುಕೂಲವು ಶಕ್ತಿಯುತವಾಗಿದೆ, ಆದರೆ ನೀವು ನೇರವಾಗಿ ಮೂಲ ಪೂರೈಕೆದಾರರಿಗೆ (raw provider) ಪಾವತಿಸುತ್ತಿಲ್ಲ ಎಂದೂ ಅರ್ಥವಾಗುತ್ತದೆ. ನಿಮ್ಮ ಯೂನಿಟ್ ಎಕನಾಮಿಕ್ಸ್ ಅನ್ನು ನಿರ್ಧರಿಸುವ ದರಗಳನ್ನು StreamLake ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಆ ದರಗಳು ಬದಲಾದಾಗ, ಕಸ್ಟಮರ್ ಸಪೋರ್ಟ್ ಬಾಟ್, ಕಂಟೆಂಟ್ ಜನರೇಷನ್ ಪೈಪ್‌ಲೈನ್ ಅಥವಾ ಕೋಡ್ ರಿವ್ಯೂ ಅಸಿಸ್ಟೆಂಟ್‌ನ ವೆಚ್ಚವು ರಾತ್ರೋರಾತ್ರಿ ಬದಲಾಗುತ್ತದೆ.

ಅನೇಕ ತಂಡಗಳು ಬೆಲೆ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಕೇವಲ ಗೊಂದಲವೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ. ಮಾಸಿಕ ಬಿಲ್ ಬಂದಾಗ ಮಾತ್ರ ಅವರು ಇದನ್ನು ಗಮನಿಸುತ್ತಾರೆ. ಹೊಸ ಪೂರೈಕೆದಾರರ ಒಪ್ಪಂದಗಳು, ಇನ್ಫರೆನ್ಸ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ಅಥವಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕೆಲವು ಮಾದರಿಗಳನ್ನು ಹೇಗೆ ಪೋಸಿಷನ್ ಮಾಡಬೇಕೆಂದು ಬಯಸುತ್ತದೆ ಎಂಬ ಬದಲಾವಣೆಗಳ ಆಧಾರದ ಮೇಲೆ ಮಾದರಿ ವೆಚ್ಚಗಳು ಏರಿಳಿತಗೊಳ್ಳುವ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಇದು ಅಪಾಯಕಾರಿ ಅಭ್ಯಾಸವಾಗಿದೆ. StreamLake ನಲ್ಲಿನ ಬೆಲೆ ಬದಲಾವಣೆಯು ಕೇವಲ ವ್ಯವಹಾರಿಕ ಹೊಂದಾಣಿಕೆಯಲ್ಲ. ಇದು ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧಾರಗಳನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ಸಿಕ್ಕಿರುವ ಸಂಕೇತವಾಗಿದೆ.

StreamLake ಅಪ್‌ಡೇಟ್‌ಗಳ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿದಿರುವುದು ಏನೆಂದರೆ

StreamLake ತನ್ನ ಲಭ್ಯವಿರುವ ಮಾದರಿಗಳ ಬೆಲೆ ನಿಗದಿಪಡಿಸುವ ವಿಧಾನದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ತ引入 ಮಾಡಿದೆ. ನಿಖರವಾದ ಹೊಸ ದರಗಳು, ಜಾರಿಗೆ ಬರುವ ದಿನಾಂಕಗಳು ಮತ್ತು ಯಾವುದೇ ಗ್ರ್ಯಾಂಡ್‌ಫಾಧರಿಂಗ್ ಪಾಲಿಸಿಗಳನ್ನು (grandfathering policies) StreamLake ತಂಡವು ದಾಖಲಿಸಿದೆ. ಶೀಘ್ರದಲ್ಲೇ ಹಳೆಯದಾಗಬಹುದಾದ ಕೋಷ್ಟಕವನ್ನು (table) ಇಲ್ಲಿ ನೀಡುವ ಬದಲು, ಮುಖ್ಯವಾದ ಅಂಶವೆಂದರೆ: ಮಾದರಿಯ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ವೆಚ್ಚದ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಮರುರೂಪಿಸಲಾಗಿದೆ. ಈ ಮೊದಲು ದೈನಂದಿನ ಕೆಲಸಗಳಿಗೆ ಡಿಫಾಲ್ಟ್ ಆಯ್ಕೆಯಾಗಿದ್ದ ಕೆಲವು ಮಾದರಿಗಳು ಈಗ ಬೇರೆ ಬೆಲೆ ವಿಭಾಗದಲ್ಲಿರಬಹುದು. ಪ್ರಯೋಗಗಳಿಗೆ ತುಂಬಾ ದುಬಾರಿ ಎಂದು ಅನಿಸುತ್ತಿದ್ದ ಇತರ ಮಾದರಿಗಳು ಈಗ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಪರ್ಯಾಯಗಳಾಗಿರಬಹುದು.

StreamLake ಒಂದೇ ಸೂರಿನಡಿ ಹಲವಾರು ಮಾದರಿಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವುದರಿಂದ, ಒಂದೇ ಬೆಲೆ ಪರಿಷ್ಕರಣೆಯು ಸಣ್ಣ ಓಪನ್-ಸೋರ್ಸ್ ಮಾದರಿ ಮತ್ತು ಪ್ರಮುಖ ಫ್ರಾಂಟಿಯರ್ ಮಾದರಿಯ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಅಥವಾ ಹೆಚ್ಚಿಸಬಹುದು. ಅಧಿಕೃತ ಪ್ರಕಟಣೆಯನ್ನು ನೀವು ಕಡ್ಡಾಯವಾಗಿ ಓದಬೇಕು. ಮುಂದಿನ ತ್ರೈಮಾಸಿಕದ ಬರ್ನ್ ರೇಟ್ (burn rate) ಅನ್ನು ಅಂದಾಜಿಸುವಾಗ ನೆನಪು ಅಥವಾ ಹಳೆಯ ದಾಖಲೆಗಳನ್ನು ಅವಲಂಬಿಸಬೇಡಿ.

ಹೊಸ ಬೆಲೆಗಳು ನಿಮ್ಮ ಕೆಲಸದ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ

ವೆಚ್ಚದ ಬದಲಾವಣೆಗಳು ಎಲ್ಲಾ ಫೀಚರ್‌ಗಳ ಮೇಲೆ ಸಮಾನವಾಗಿ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ದಿನಕ್ಕೆ ಹತ್ತು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಪ್ರೊಟೊಟೈಪ್ (prototype) ಯಾವುದೇ ಬೆಲೆ ಏರಿಕೆಯನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲದು. ಪ್ರತಿ ಗಂಟೆಗೆ ಸಾವಿರಾರು ಸಾರಾಂಶದ ಕೆಲಸಗಳನ್ನು (summarization jobs) ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ ಅದನ್ನು ತಕ್ಷಣವೇ ಅನುಭವಿಸುತ್ತದೆ.

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

ಈ ಬದಲಾವಣೆಗಳು ನೀವು ರಿಟ್ರೈಗಳು (retries) ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳ (fallbacks) ಬಗ್ಗೆ ಯೋಚಿಸುವ ವಿಧಾನವನ್ನೂ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಒಂದು ಮಾದರಿಯು ಅಗ್ಗವಾಗಿದ್ದಾಗ, ನೀವು ಅದನ್ನು ಎರಡು ಬಾರಿ ಕರೆದು ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಹೋಲಿಸಲು ಸಾಧ್ಯವಿತ್ತು. ಬೆಲೆ ಬದಲಾದಾಗ, ಅಂತಹ ಅನಗತ್ಯ ಪುನರಾವರ್ತನೆ (redundancy) ಒಂದು ಐಷಾರಾಮಿ trởುತ್ತದೆ. ನೀವು ಹಲವಾರು ಜನರೇಶನ್‌ಗಳ ಮೂಲಕ ನಿಖರತೆಯನ್ನು ಪಡೆಯುವ ಬದಲು, ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಇಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿಸಿಕೊಳ್ಳಬೇಕಾಗಬಹುದು.

ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಮಾದರಿ ಬಳಕೆಯನ್ನು ಆಡಿಟ್ ಮಾಡುವುದು

ನೀವು ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಮೊದಲು, ನಿಮಗೆ ಡೇಟಾ ಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ StreamLake ಖಾತೆಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಿ ಮತ್ತು ಕಳೆದ ಮೂವತ್ತು ಅಥವಾ ಅರವತ್ತು ದಿನಗಳ ಬಳಕೆಯನ್ನು ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಮಾಡಿ. ಸಾಧ್ಯವಾದರೆ ಮಾದರಿ (model), ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಮೂಲದ ಆಧಾರದ ಮೇಲೆ ಅದನ್ನು ವಿಂಗಡಿಸಿ. ನೀವು '೯೦-೧೦' (ninety-ten) ಅನುಪಾತವನ್ನು ಹುಡುಕುತ್ತಿದ್ದೀರಿ. ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ, ಕೆಲವೇ ಕೆಲವು ಮಾದರಿ ಕರೆಗಳು ಹೆಚ್ಚಿನ ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

ಈ ಕೆಳಗಿನ ಮಾದರಿಗಳಿಗಾಗಿ ಗಮನಿಸಿ:

  • ಹೆಚ್ಚಿನ ಆವರ್ತನದ, ಕಡಿಮೆ ಸಂಕೀರ್ಣತೆಯ ಕಾರ್ಯಗಳು. ನೀವು ಸಣ್ಣ ಟ್ವೀಟ್‌ಗಳ ಭಾವನೆಯನ್ನು (sentiment) ವರ್ಗೀಕರಿಸಲು ದೊಡ್ಡ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಅತಿಯಾಗಿ ಪಾವತಿಸುತ್ತಿರಬಹುದು.
  • ಅತಿಯಾದ ಪ್ರಾಂಪ್ಟ್‌ಗಳು (Bloated prompts). ಉದ್ದವಾದ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಫ್ಯೂ-ಶಾಟ್ (few-shot) ಉದಾಹರಣೆಗಳು ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ವಿನಂತಿಗೆ (request) ಅನಗತ್ಯ ಸಂದರ್ಭಗಳನ್ನು (context) ನೀಡುವಾಗ ಬೆಲೆ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚು ಹೊಡೆತ ನೀಡುತ್ತವೆ.
  • ಕಡಿಮೆ ಬಳಸಲಾಗುವ ದುಬಾರಿ ಮಾಡೆಲ್‌ಗಳು. ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್‌ಗಳು ಅಭ್ಯಾಸದಂತೆ ಸಣ್ಣ ಮಾಡೆಲ್ ಸಾಕಾಗುವ ಸಂದರ್ಭದಲ್ಲೂ ದೊಡ್ಡ ಫ್ರಾಂಟಿಯರ್ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ.
  • ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ಬ್ಯಾಚ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು. ರಿಯಲ್-ಟೈಮ್ ಸ್ಟ್ರೀಮಿಂಗ್ ವೆಚ್ಚಗಳು ಅಸಿಂಕ್ರೋನಸ್ ಬ್ಯಾಚ್ ಕೆಲಸಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ನಿಮ್ಮ ಬೆಲೆಯ ಅಂದಾಜುಗಳು ನಿಮ್ಮ ವಿತರಣಾ ವಿಧಾನಕ್ಕೆ (delivery mode) ಹೊಂದಿಕೆಯಾಗುತ್ತಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ನಿಮಗೆ ಈ ಬಗ್ಗೆ ಇನ್ನೂ ಸ್ಪಷ್ಟತೆ ಇಲ್ಲದಿದ್ದರೆ, ಏನನ್ನೂ ಬದಲಾಯಿಸುವ ಮೊದಲು ಅದನ್ನು ರೂಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಅತಿದೊಡ್ಡ ವೆಚ್ಚದ ಕೇಂದ್ರಗಳನ್ನು ಕೇವಲ ಊಹಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಹಂತವನ್ನು (layer) ಸುಧಾರಿಸಲು ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ.

ಬೆಲೆ ಬದಲಾವಣೆಯ ನಂತರ ವೆಚ್ಚವನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗಗಳು

ಹಣ ಎಲ್ಲಿ ವ್ಯಯವಾಗುತ್ತಿದೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದ一旦, ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಕುಗ್ಗಿಸದೆ ನೀವು ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು. ಅಪ್‌ಡೇಟ್ ನಂತರದ ವಿಮರ್ಶೆಗೆ ಸೂಕ್ತವಾದ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯತಂತ್ರಗಳು ಇಲ್ಲಿವೆ.

ಕಾರ್ಯದ ಹಂತಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿ. ಪ್ರತಿಯೊಂದು ಫೀಚರ್‌ಗೂ ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿರುವ ಅತ್ಯಂತ ಬುದ್ಧಿವಂತ ಮಾಡೆಲ್ ಅಗತ್ಯವಿಲ್ಲ. ಸರಳ ವರ್ಗೀಕರಣ ಅಥವಾ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಕಾರ್ಯಗಳನ್ನು ಸಣ್ಣ ಮತ್ತು ವೇಗವಾದ ಮಾಡೆಲ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಿ. ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ದುಬಾರಿಯಾದ ತರ್ಕ (reasoning), ಸೃಜನಾತ್ಮಕ ಬರವಣಿಗೆ ಅಥವಾ ಸಂಕೀರ್ಣ ಎಕ್ಸ್‌ಟ್ರಾಕ್ಷನ್ (extraction) ಕಾರ್ಯಗಳಿಗಾಗಿ ದೊಡ್ಡ ಮಾಡೆಲ್‌ಗಳನ್ನು ಮೀಸಲಿಡಿ.

ಪ್ರಾಂಪ್ಟ್ ಕಂಪ್ರೆಶನ್ (Prompt compression) ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಸಿಸ್ಟಮ್ ಸಂದೇಶಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಿ ಮತ್ತು ಅನಗತ್ಯ ಫ್ಯೂ-ಶಾಟ್ ಉದಾಹರಣೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿ. ಒಂದು ಕಾರ್ಯಕ್ಕೆ ನಿಜವಾಗಿಯೂ ಉದಾಹರಣೆಗಳ ಅಗತ್ಯವಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು API ಕಾಲ್‌ಗೆ ಪೂರ್ಣ ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಬದಲು, ಅವುಗಳನ್ನು ಬಾಹ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಲಘುವಾಗಿ ಉಲ್ಲೇಖಿಸಿ.

ತೀವ್ರವಾದ ಕ್ಯಾಷಿಂಗ್ (Caching) ಬಳಸಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪದೇ ಪದೇ ಒಂದೇ ರೀತಿಯ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿ. ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಉತ್ತರವು ಶೂನ್ಯ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಶೂನ್ಯ ವಿಳಂಬವನ್ನು (latency) ಹೊಂದಿರುತ್ತದೆ.

ಮಾಡೆಲ್ ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ (Model cascading) ಬಳಸಿ. ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ಕೆಲಸವನ್ನು ನಿಭಾಯಿಸಬಲ್ಲ ಅತ್ಯಂತ ಅಗ್ಗದ ಮಾಡೆಲ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ಲಘುವಾದ ವ್ಯಾಲಿಡೇಟರ್ ಮೂಲಕ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. ಮೊದಲ ಪ್ರಯತ್ನವು ಗುಣಮಟ್ಟದ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾದರೆ ಮಾತ್ರ ಪ್ರೀಮಿಯಂ ಮಾಡೆಲ್‌ಗೆ ಹೋಗಿ. ಈ ವಿಧಾನವು ವಿನಂತಿಯ ಸರಾಸರಿ ವೆಚ್ಚವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಬ್ಯಾಚ್ ಮತ್ತು ರಿಯಲ್-ಟೈಮ್ ಅಗತ್ಯತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಬಳಕೆದಾರರಿಗೆ ತಕ್ಷಣದ ಫಲಿತಾಂಶಗಳ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, StreamLake ಬೆಂಬಲಿಸುವಲ್ಲಿ ಬ್ಯಾಚ್ ಪ್ರೊಸೆಸಿಂಗ್‌ಗೆ ಬದಲಾಯಿಸಿ. ಬ್ಯಾಚಿಂಗ್ ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ಬೆಲೆ ಮತ್ತು ದಕ್ಷತೆಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಅಲರ್ಟ್‌ಗಳ ಮೂಲಕ ಏರಿಕೆಗಳನ್ನು ಗಮನಿಸಿ. ನಿಮ್ಮ StreamLake ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ಟೆಲಿಮೆಟ್ರಿ ಮೂಲಕ ಬಜೆಟ್ ಅಲರ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ. ಬೆಲೆ ಬದಲಾವಣೆಯ ನಂತರ ವೆಚ್ಚದಲ್ಲಿ ಉಂಟಾಗುವ sudden jump ಅನ್ನು ಮೂವತ್ತು ದಿನಗಳ ನಂತರ ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ಮೂರು ದಿನಗಳಲ್ಲಿ ಸರಿಪಡಿಸುವುದು ಸುಲಭ.

ಔಟ್‌ಪುಟ್ ಗುಣಮಟ್ಟದ ವಿರುದ್ಧ ವೆಚ್ಚವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು

ಬೆಲೆ ಎಂಬುದು ಅರ್ಧದಷ್ಟೇ ವಿಷಯ. ಭ್ರಮೆಗೊಳಿಸುವ (hallucinates) ಅಥವಾ ಅನಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ನೀಡುವ ಅಗ್ಗದ ಮಾಡೆಲ್ ಮುಂದಿನ ಹಂತಗಳಲ್ಲಿ ಗುಪ್ತ ವೆಚ್ಚಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ನೀವು ಔಟ್‌ಪುಟ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಇಂಜಿನಿಯರಿಂಗ್ ಸಮಯವನ್ನು ವ್ಯಯಿಸುತ್ತೀರಿ ಅಥವಾ ಅದಕ್ಕಿಂತ最 ಕೆಟ್ಟದಾಗಿ, ಬಳಕೆದಾರರಿಗೆ ತಪ್ಪು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತೀರಿ.

ಒಂದು速 ಆಡಿಟ್ ನಡೆಸಿ. ನಿಮ್ಮ ಪ್ರೊಡಕ್ಷನ್ ಲಾಗ್‌ಗಳಿಂದ ಐವತ್ತು ಪ್ರತಿನಿಧಿಸುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಆರಿಸಿ. ಹೊಸ ಬೆಲೆ ರಚನೆಯ ಅಡಿಯಲ್ಲಿ ನೀವು ಪರಿಗಣಿಸುತ್ತಿರುವ ಮಾಡೆಲ್‌ಗಳ ಮೂಲಕ ಅವುಗಳನ್ನು ಕಳುಹಿಸಿ. ನಿಖರತೆ, ವಿಳಂಬ (latency) ಮತ್ತು ಟೋಕನ್ ಉದ್ದಕ್ಕಾಗಿ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಸ್ಕೋರ್ ಮಾಡಿ. ಕೆಲವೊಮ್ಮೆ ಸ್ವಲ್ಪ ದುಬಾರಿ ಮಾಡೆಲ್ ಕಡಿಮೆ ಟೋಕನ್‌ಗಳಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತ ಮತ್ತು ಸರಿಯಾದ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತದೆ, ಇದು ಅತಿಯಾಗಿ ಮಾತನಾಡುವ ಅಗ್ಗದ ಮಾಡೆಲ್‌ನಿಗಿಂತ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅಗ್ಗವಾಗುತ್ತದೆ.

ವಿಫಲತೆಯ ದರಗಳನ್ನು (failure rates) ಕೂಡ ಅಳೆಯಿರಿ. ಪದೇ ಪದೇ ಪ್ರಯತ್ನಿಸಬೇಕಾಗುವ (retries) ಮಾಡೆಲ್ ನಿಜವಾಗಿಯೂ ಅಗ್ಗವಾಗಿರುವುದಿಲ್ಲ. ಫಾಲ್‌ಬ್ಯಾಕ್ ಲಾಜಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಇಂಜಿನಿಯರಿಂಗ್ ವೆಚ್ಚ ಮತ್ತು ನಿಧಾನಗತಿಯ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಂದ ಬಳಕೆದಾರರ ಅನುಭವಕ್ಕೆ ಆಗುವ ವೆಚ್ಚವನ್ನು ಪರಿಗಣಿಸಿ.

ಮುಂದಿನ ಬದಲಾವಣೆಗಾಗಿ ಯೋಜನೆ

StreamLake ಅಥವಾ ಯಾವುದೇ ಇತರ LLM ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಇದು ಕೊನೆಯ ಬೆಲೆ ಅಪ್‌ಡೇಟ್ ಆಗಿರುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಮಾರುಕಟ್ಟೆಯು ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುತ್ತದೆ. ಹೊಸ ಕ್ವಾಂಟೈಸೇಶನ್ (quantization) ತಂತ್ರಗಳು ಇನ್ಫರೆನ್ಸ್ (inference) ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ. ಪ್ರೊವೈಡರ್ ಪಾಲುದಾರಿಕೆಗಳು ಬದಲಾಗುತ್ತವೆ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಸ್ಪರ್ಧಿಸಲು ಹಂತಗಳನ್ನು (tiers) ಮರುರಚಿಸುತ್ತವೆ. ಬೆಲೆಗಳು ಸ್ಥಿರವಾಗಿವೆ ಎಂದು ಭಾವಿಸಿ ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದರೆ, ಅದು ಅಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

ನಿಮ್ಮ ಮಾಡೆಲ್ ಆಯ್ಕೆಯ ತರ್ಕವನ್ನು ದಾಖಲಿಸಿ. ಫೀಚರ್ X ಗಾಗಿ ಮಾಡೆಲ್ A ಅನ್ನು ಮತ್ತು ಫೀಚರ್ Y ಗಾಗಿ ಮಾಡೆಲ್ B ಅನ್ನು ನೀವು ಏಕೆ ಆರಿಸಿದ್ದೀರಿ ಎಂದು ಬರೆದಿಡಿ. ಮುಂದಿನ ಬಾರಿ ದರಗಳು ಬದಲಾದಾಗ, ನಿಮ್ಮ ಸ್ವಂತ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನೀವು ಮರು-ವಿಶ್ಲೇಷಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಅಪ್‌ಡೇಟ್ ಮಾಡಲು ನಿಮ್ಮ ಬಳಿ ನಿರ್ಧಾರಗಳ ದಾಖಲೆ ಇರುತ್ತದೆ.

StreamLake ಡೆವಲಪರ್ ಚಾನೆಲ್‌ಗಳು ಮತ್ತು ವಿಶಾಲವಾದ ಸಮುದಾಯ ಚರ್ಚೆಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಿ. ಬೆಲೆಯ ಬಗ್ಗೆ ಚರ್ಚೆಗಳು ಹೆಚ್ಚಾಗಿ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು ಮತ್ತು ಹೊಸ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಗಳ ಜೊತೆಗೆ ನಡೆಯುತ್ತವೆ. ಸಂದರ್ಭವು ಮುಖ್ಯವಾಗಿದೆ. ವಿಳಂಬದಲ್ಲಿ (latency) ಸುಧಾರಣೆಯೊಂದಿಗೆ ಬೆಲೆ ಏರಿಕೆಯಾದರೆ ಅದು ಉತ್ತಮ ವ್ಯವಹಾರವಾಗಬಹುದು. ಬಳಕೆಯಲ್ಲಿಲ್ಲದ (deprecated) ಮಾಡೆಲ್‌ನ ಬೆಲೆ ಇಳಿಕೆಯು ಸಂಭ್ರಮಿಸಲು ಯೋಗ್ಯವಲ್ಲ.

ನಿಜವಾದ ಸಾರಾಂಶ

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