ಟೋಕನ್ ಅರ್ಥಶಾಸ್ತ್ರ

ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿ LLM ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಟೋಕನ್ ಅರ್ಥಶಾಸ್ತ್ರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮೂಲಭೂತವಾಗಿದೆ. ಸರಿಯಾದ ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಗಳಿಲ್ಲದೆ ಟೋಕನ್ ವೆಚ್ಚಗಳು ವೇಗವಾಗಿ ಹೆಚ್ಚಾಗಬಹುದು.

ಪರಿಚಯ

ನೀವು ಟೋಕನ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡದೆ LLM ಫೀಚರ್ ಅನ್ನು ಶಿಪ್ ಮಾಡಿದಾಗ, ಮೊದಲ ಆಶ್ಚರ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಇನ್‌ವಾಯ್ಸ್ ಆಗಿರುತ್ತದೆ — ಡೆವ್‌ನಲ್ಲಿ "ಅಗ್ಗವೆಂದು ಅನಿಸಿದ" ಚಾಟ್‌ಬಾಟ್ ನಿಜವಾದ ಟ್ರಾಫಿಕ್ ಬಂದ ನಂತರ ತಿಂಗಳಿಗೆ ಐದು ಅಂಕಿಗಳ ಹಣವನ್ನು ಸುಡಬಹುದು, ಏಕೆಂದರೆ ಪ್ರತಿ ಪ್ರಾಂಪ್ಟ್ ಪುನರಾವರ್ತನೆ, ಪ್ರತಿ ದೀರ್ಘ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಕ್ಯಾಶ್ ಆಗದ ಪ್ರತಿ ಸಿಸ್ಟಮ್ ಸೂಚನೆಗೆ ಪ್ರತಿ ಟೋಕನ್‌ಗೆ ಬಿಲ್ ಆಗುತ್ತದೆ. ಬಿಲ್ ಬಂದ ನಂತರ ಟೋಕನ್ ಗಣಿತವನ್ನು ಕಲಿಯುವ ತಂಡಗಳು ವ್ಯರ್ಥವನ್ನು ಕಡಿತಗೊಳಿಸುವ ಬದಲು ಫೀಚರ್‌ಗಳನ್ನು ಕಡಿತಗೊಳಿಸುವ ಅಥವಾ ಬಳಕೆದಾರರಿಗೆ ರೇಟ್-ಲಿಮಿಟ್ ಹಾಕುವ ಸ್ಥಿತಿಗೆ ತಲುಪುತ್ತವೆ. ಈ ಪಾಠದ ಕೊನೆಯಲ್ಲಿ ನೀವು ಯಾವುದೇ ಪ್ರೊವೈಡರ್‌ಗಾಗಿ ಟೋಕನ್‌ಗಳನ್ನು ನಿಖರವಾಗಿ ಎಣಿಸಲು, ನಿಯೋಜಿಸುವ ಮೊದಲು ಒಂದು ವರ್ಕ್‌ಲೋಡ್‌ನ ದೈನಂದಿನ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕಲು, ಮತ್ತು ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ ಆಕಾರಕ್ಕೆ ಯಾವ ಆಪ್ಟಿಮೈಸೇಶನ್ (ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್, ಔಟ್‌ಪುಟ್ ಟ್ರಂಕೇಶನ್, ಮಾಡೆಲ್ ಟೈರಿಂಗ್) ನಿಜವಾಗಿಯೂ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಪ್ರಮುಖ ಪರಿಭಾಷೆ

• ಟೋಕನ್ — ಪ್ರೊವೈಡರ್‌ಗಳು ಅಳೆಯುವ ಮತ್ತು ಪ್ರತಿ ಮಿಲಿಯನ್‌ಗೆ ಬಿಲ್ ಮಾಡುವ ಒಂದು ಸಬ್‌ವರ್ಡ್ ಘಟಕ (~4 ಇಂಗ್ಲಿಷ್ ಅಕ್ಷರಗಳು); ಇದು ಮುಖ್ಯ ಏಕೆಂದರೆ ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿನ ಪ್ರತಿ ಅಕ್ಷರವು ಬೆಲೆ ನಿಗದಿಯ ಮೊದಲು ಟೋಕನ್‌ಗಳಾಗಿ ಪರಿವರ್ತನೆಯಾಗುತ್ತದೆ.
• ಇನ್‌ಪುಟ್ vs. ಔಟ್‌ಪುಟ್ ಟೋಕನ್ ದರ — ಪ್ರೊವೈಡರ್‌ಗಳು ನೀವು ಕಳುಹಿಸುವ ಟೋಕನ್‌ಗಳಿಗೆ (ಇನ್‌ಪುಟ್) ಮತ್ತು ಮಾಡೆಲ್ ಉತ್ಪಾದಿಸುವ ಟೋಕನ್‌ಗಳಿಗೆ (ಔಟ್‌ಪುಟ್) ಪ್ರತ್ಯೇಕವಾಗಿ ಶುಲ್ಕ ವಿಧಿಸುತ್ತಾರೆ, ಔಟ್‌ಪುಟ್ ಸಾಮಾನ್ಯವಾಗಿ 3-5× ಹೆಚ್ಚು ದುಬಾರಿ; ಈ ವಿಭಜನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ವೆಚ್ಚ ಮಾಡೆಲ್‌ಗಳು ದೀರ್ಘ-ಕಂಪ್ಲೀಶನ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳ ಮೇಲಿನ ಖರ್ಚನ್ನು ಕಡಿಮೆ ಅಂದಾಜು ಮಾಡುತ್ತವೆ.
• ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ — ಪುನರಾವರ್ತಿತ ಪ್ರಾಂಪ್ಟ್‌ನ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿ, ಕ್ಯಾಶ್ ಆದ ರೀಡ್‌ಗಳಿಗೆ ಮೂಲ ಇನ್‌ಪುಟ್ ದರದ 10-50% ಬಿಲ್ ಮಾಡುವ ಪ್ರೊವೈಡರ್ ಫೀಚರ್; ಇದು ಮುಖ್ಯ ಏಕೆಂದರೆ ಸಾವಿರಾರು ವಿನಂತಿಗಳಲ್ಲಿ ಮರುಬಳಕೆಯಾಗುವ ಸ್ಥಿರ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಇನ್‌ಪುಟ್ ವೆಚ್ಚವನ್ನು ಕಡಿತಗೊಳಿಸಲು ಅತಿ ದೊಡ್ಡ ಏಕೈಕ ಸಾಧನವಾಗಿದೆ.
• ಟೋಕನೈಜರ್ — ಪಠ್ಯವನ್ನು ಪೂರ್ಣಾಂಕ ಟೋಕನ್ ID ಗಳಾಗಿ ಪರಿವರ್ತಿಸುವ ಎನ್‌ಕೋಡಿಂಗ್ (ಉದಾ. cl100k_base, o200k_base); ಅಂದಾಜು ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ ನಡುವೆ ಹೊಂದಿಕೆಯಾಗದ ಟೋಕನೈಜರ್‌ಗಳು 30% ರಷ್ಟು ತಪ್ಪಾದ ವೆಚ್ಚ ಮುನ್ಸೂಚನೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
• ಪ್ರತಿ ಸಂವಾದದ ವೆಚ್ಚ — ಟೋಕನ್‌ಗಳನ್ನು ಉತ್ಪನ್ನದ ಆದಾಯಕ್ಕೆ ಹಿಂತಿರುಗಿ ಜೋಡಿಸುವ ಯುನಿಟ್-ಎಕನಾಮಿಕ್ ಮೆಟ್ರಿಕ್: ಪ್ರತಿ ಬಳಕೆದಾರ ಸಂವಹನಕ್ಕೆ (input_tokens × in_rate) + (output_tokens × out_rate); ಇದಿಲ್ಲದೆ, "ಈ ಫೀಚರ್ ಲಾಭದಾಯಕವೇ?" ಎಂಬುದಕ್ಕೆ ನೀವು ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಪರಿಕಲ್ಪನೆಗಳು

ಪಠ್ಯವು ಬಿಲ್ ಮಾಡಬಹುದಾದ ಟೋಕನ್‌ಗಳಾಗುವುದು ಹೇಗೆ

ಬೆಲೆ ನಿಗದಿ ಪ್ರತಿ-ಟೋಕನ್ ಆಧಾರದಲ್ಲಿದೆ, ಪ್ರತಿ-ಅಕ್ಷರ ಅಥವಾ ಪ್ರತಿ-ವಿನಂತಿ ಆಧಾರದಲ್ಲಿ ಅಲ್ಲ. ಪ್ರೊವೈಡರ್ ಒದಗಿಸುವ ಟೋಕನೈಜರ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಟ್ರಿಂಗ್ ಎಷ್ಟು ಟೋಕನ್‌ಗಳ ವೆಚ್ಚವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಮ್ಯಾಪಿಂಗ್ ಪ್ರೊವೈಡರ್‌ಗಳ ನಡುವೆ 1:1 ಅಲ್ಲ — ಒಂದೇ ಪ್ಯಾರಾಗ್ರಾಫ್ ಒಂದು ಮಾಡೆಲ್‌ನಲ್ಲಿ 180 ಟೋಕನ್‌ಗಳಾಗಿ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ 220 ಆಗಿರಬಹುದು. ಕೋಡ್, JSON ಮತ್ತು ಇಂಗ್ಲಿಷ್-ಅಲ್ಲದ ಪಠ್ಯ ಎಲ್ಲವೂ ಗದ್ಯಕ್ಕಿಂತ ದಟ್ಟವಾಗಿ ಟೋಕನೈಜ್ ಆಗುತ್ತವೆ, ಹಾಗಾಗಿ "ಚಿಕ್ಕ" 2KB JSON ಪೇಲೋಡ್ 700+ ಟೋಕನ್‌ಗಳಿಗೆ ತಲುಪಬಹುದು. ಅಕ್ಷರ ಸಂಖ್ಯೆಯಿಂದ ಅಂದಾಜು ಮಾಡುವುದು ಸ್ಥೂಲ ಬಜೆಟ್‌ಗೆ ಸರಿ; ನೀವು ಹಣಕಾಸು ವಿಭಾಗಕ್ಕೆ ನೀಡುವ ಮುನ್ಸೂಚನೆಗಳಿಗೆ, ಪ್ರೊವೈಡರ್‌ನ ನಿಜವಾದ ಟೋಕನೈಜರ್ ಬಳಸಿ (ಕೋಡ್ ವಾಕ್‌ಥ್ರೂ ನೋಡಿ).

ವೆಚ್ಚ ಸಮೀಕರಣ ಮತ್ತು ಕ್ಯಾಶಿಂಗ್ ಅದನ್ನು ಎಲ್ಲಿ ಬದಲಾಯಿಸುತ್ತದೆ

ದೈನಂದಿನ ವೆಚ್ಚವು requests × (input_tokens × in_rate + output_tokens × out_rate) ಎಂದು ವಿಭಜನೆಯಾಗುತ್ತದೆ. ಬಹುತೇಕ ಯಾವಾಗಲೂ ಗೆಲ್ಲುವ ಸಾಧನ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್: ವಿನಂತಿಗಳಾದ್ಯಂತ ನೀವು ಮರುಬಳಕೆ ಮಾಡುವ ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ — ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಫ್ಯೂ-ಶಾಟ್ ಉದಾಹರಣೆಗಳು, ಹಿಂಪಡೆದ ದಾಖಲೆಗಳು — ಮೊದಲ ಹಿಟ್‌ನ ನಂತರ ಕ್ಯಾಶ್ ದರದಲ್ಲಿ ಬಿಲ್ ಆಗುತ್ತದೆ. ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ 80% ಸ್ಥಿರ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಆಗಿರುವ ವರ್ಕ್‌ಲೋಡ್‌ಗೆ, 90% ಕ್ಯಾಶ್ ರಿಯಾಯಿತಿ ಒಟ್ಟು ಇನ್‌ಪುಟ್ ವೆಚ್ಚವನ್ನು ~70% ರಷ್ಟು ಕಡಿತಗೊಳಿಸುತ್ತದೆ. ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಹಾಗಾಗಿ ಎರಡನೇ ಸಾಧನವೆಂದರೆ max_tokens, ರಚನಾತ್ಮಕ ಔಟ್‌ಪುಟ್ ಅಥವಾ ಸ್ಟಾಪ್ ಸೀಕ್ವೆನ್ಸ್‌ಗಳ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕುಗ್ಗಿಸುವುದು.

ವೆಚ್ಚ ಹಂಚಿಕೆ ಪ್ರಥಮ-ದರ್ಜೆಯ ಕಾಳಜಿಯಾಗಿ

ನೀವು ಬಳಕೆದಾರ, ಫೀಚರ್ ಅಥವಾ ಟೆನೆಂಟ್ ಪ್ರಕಾರ ಖರ್ಚನ್ನು ಟ್ಯಾಗ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಯಾವುದು ದುಬಾರಿ ಎಂಬುದನ್ನು ನೀವು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ — ಮತ್ತು "LLM ದುಬಾರಿ" ಎಂಬುದು ನಿಮ್ಮ ಅತ್ಯಂತ ಅಗ್ಗದ ಮತ್ತು ಅತ್ಯಂತ ದುಬಾರಿ ಕಾಲ್ ಸೈಟ್‌ಗಳ ನಡುವಿನ 10× ವ್ಯತ್ಯಾಸವನ್ನು ಸರಾಸರಿಗೊಳಿಸುತ್ತದೆ. ಹಂಚಿಕೆಯು ವಿನಂತಿಯ ಅದೇ ಲಾಗಿಂಗ್ ಪಾತ್‌ನಲ್ಲಿ ಇರಬೇಕು: ಪ್ರತಿ ಕಾಲ್‌ಗೆ model, input_tokens, output_tokens, cached_tokens ಮತ್ತು ಒಂದು feature_id ಅನ್ನು ಲಾಗ್ ಮಾಡಿ. ದೈನಂದಿನವಾಗಿ ಒಟ್ಟುಗೂಡಿಸಿ; ಖರ್ಚಿನ ಪ್ರಕಾರ ಟಾಪ್-3 ಫೀಚರ್‌ಗಳು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಆಪ್ಟಿಮೈಸೇಶನ್ ಫಲ ನೀಡುವ ಸ್ಥಳಗಳಾಗಿರುತ್ತವೆ.

ಕೋಡ್ ವಾಕ್‌ಥ್ರೂ

ಹಿಂದಿನ ವಿಭಾಗದ ಟೋಕನೈಜರ್ ಮಾಡೆಲ್, ವೆಚ್ಚ ಸಮೀಕರಣ ಮತ್ತು ಹಂಚಿಕೆ ಪರಿಕಲ್ಪನೆಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಿ, ಈ ವಾಕ್‌ಥ್ರೂ ಅವುಗಳನ್ನು ರನ್ ಮಾಡಬಹುದಾದ ಕೋಡ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ: ಪ್ರೊವೈಡರ್‌ನ ನಿಜವಾದ ಟೋಕನೈಜರ್‌ನೊಂದಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಎಣಿಸುವುದು, ಮತ್ತು ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಪರಿಗಣಿಸುವ ಪ್ರತಿ-ಸಂವಾದ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕುವುದು. ಸ್ಕ್ರಿಪ್ಟ್ ರನ್ ಮಾಡಿದಾಗ ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ನಿಖರವಾದ ಟೋಕನ್ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರೊವೈಡರ್‌ನ ಬಿಲ್ಲಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗೆ ಕೆಲವು ಶೇಕಡಾದೊಳಗೆ ಹೊಂದಿಕೆಯಾಗುವ ದೈನಂದಿನ-ವೆಚ್ಚದ ಅಂಕಿ ಎರಡನ್ನೂ ಮುದ್ರಿಸಿದರೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.

Code snippetpython
1import tiktoken
2
3# Provider rates as of model release; verify against current pricing page.
4RATES_PER_MILLION = {
5    "gpt-4o": {"input": 2.50, "cached_input": 1.25, "output": 10.00},
6    "claude-sonnet": {"input": 3.00, "cached_input": 0.30, "output": 15.00},
7}
8
9def count_tokens(text: str, model: str = "gpt-4o") -> int:
10    """Return exact token count using the model's tokenizer."""
11    try:
12        encoding = tiktoken.encoding_for_model(model)
13    except (KeyError, AttributeError):
14        encoding = tiktoken.get_encoding("cl100k_base")
15    return len(encoding.encode(text))
16
17def conversation_cost(
18    system_tokens: int,
19    user_tokens: int,
20    output_tokens: int,
21    requests_per_day: int,
22    model: str,
23    cache_hit_rate: float = 0.0,
24) -> dict:
25    """Project daily cost for a workload with optional prompt caching."""
26    rates = RATES_PER_MILLION[model]
27    cached = system_tokens * cache_hit_rate
28    uncached_input = system_tokens * (1 - cache_hit_rate) + user_tokens
29
30    daily_input = (
31        cached * rates["cached_input"] + uncached_input * rates["input"]
32    ) * requests_per_day / 1_000_000
33    daily_output = output_tokens * rates["output"] * requests_per_day / 1_000_000
34
35    return {
36        "input_usd": round(daily_input, 2),
37        "output_usd": round(daily_output, 2),
38        "total_usd": round(daily_input + daily_output, 2),
39    }
40
41if __name__ == "__main__":
42    # 10k conversations/day, stable 500-token system prompt, 90% cache hit.
43    projection = conversation_cost(
44        system_tokens=500,
45        user_tokens=100,
46        output_tokens=300,
47        requests_per_day=10_000,
48        model="claude-sonnet",
49        cache_hit_rate=0.9,
50    )
51    print(projection)  # {'input_usd': 4.5, 'output_usd': 45.0, 'total_usd': 49.5}

count_tokens ಫಂಕ್ಷನ್ ಪ್ರೊವೈಡರ್‌ನ ಟೋಕನೈಜರ್ ಅನ್ನು cl100k_base ಫಾಲ್‌ಬ್ಯಾಕ್‌ನೊಂದಿಗೆ ಬಳಸುತ್ತದೆ, ಹಾಗಾಗಿ ಅಪರಿಚಿತ ಮಾಡೆಲ್‌ನಲ್ಲಿ ನೀವು ಎಂದಿಗೂ ಕ್ರ್ಯಾಶ್ ಆಗುವುದಿಲ್ಲ; ಕಾಂಟೆಕ್ಸ್ಟ್-ವಿಂಡೋ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು ಮತ್ತು ಪ್ರತಿ-ವಿನಂತಿಯ ನಿಖರವಾದ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಲಾಗ್ ಮಾಡಲು ವಿನಂತಿ ಕಳುಹಿಸುವ ಮೊದಲು ಇದನ್ನು ಬಳಸಿ. conversation_cost ಫಂಕ್ಷನ್ ನಾಲ್ಕು ಇನ್‌ಪುಟ್‌ಗಳನ್ನು (ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು, ಟ್ರಾಫಿಕ್, ಮಾಡೆಲ್, ಕ್ಯಾಶ್ ಹಿಟ್ ದರ) ದೈನಂದಿನ-ವೆಚ್ಚದ ಅಂದಾಜಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ — ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುವ ಮೊದಲು ಅದರ ROI ಅನ್ನು ಅಳೆಯಲು cache_hit_rate ಅನ್ನು 0.0 ರಿಂದ 0.95 ವರೆಗೆ ಸ್ವೀಪ್ ಮಾಡಿ. ಒಂದು ದಿನದ ಅಂದಾಜು ವೆಚ್ಚವನ್ನು ಪ್ರೊವೈಡರ್‌ನ ಬಿಲ್ಲಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ ಪರಿಶೀಲಿಸಿ; ~5% ಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಅಂತರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ cache_hit_rate ಅಂದಾಜು ತಪ್ಪಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತವೆ.

ಗಾಗಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ

ಈಗಷ್ಟೇ ಕೋಡ್‌ನಲ್ಲಿ ಟೋಕನ್ ಎಣಿಕೆ ಮತ್ತು ವೆಚ್ಚದ ಅಂದಾಜನ್ನು ಜೋಡಿಸಿದ ನಂತರ, ಮುಂದಿನ ಪ್ರಶ್ನೆಯೆಂದರೆ ಆ ಸಾಧನಗಳನ್ನು ಮೊದಲು ಎಲ್ಲಿ ಗುರಿಪಡಿಸಬೇಕು. ಮೇಲಿನ ಯಾಂತ್ರಿಕ ಅಂಶಗಳು — ಟೋಕನ್ ಎಣಿಕೆ, ವೆಚ್ಚದ ಅಂದಾಜು, ಕ್ಯಾಶ್-ಹಿಟ್ ಗಣಿತ — ಸಾರ್ವತ್ರಿಕವಾಗಿವೆ, ಆದರೆ ಪ್ರಭಾವ ಎಲ್ಲಿದೆ ಎಂಬುದು ನೀವು ನಿಜವಾಗಿಯೂ ಹೊಂದಿರುವ ವರ್ಕ್‌ಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಮಾಡಬೇಕಾದವು ಮತ್ತು ಮಾಡಬಾರದವು

ಮೇಲಿನ ಶಿಸ್ತು-ನಿರ್ದಿಷ್ಟ ದೃಷ್ಟಿಕೋನದ ಮೇಲೆ ನಿರ್ಮಿಸಿ, ಕೆಳಗಿನ ನಿಯಮಗಳು ಇಲ್ಲಿಯವರೆಗೆ ಚರ್ಚಿಸಿದ ಪ್ರತಿಯೊಂದು ವರ್ಕ್‌ಲೋಡ್ ಆಕಾರದಲ್ಲೂ ವೆಚ್ಚವನ್ನು ಸತತವಾಗಿ ಕೆಳಗಿಳಿಸುವುದನ್ನು — ಮತ್ತು ಸತತವಾಗಿ ಅದನ್ನು ಹಾಳುಮಾಡುವುದನ್ನು — ಸಾರಾಂಶಗೊಳಿಸುತ್ತವೆ.

ಮಾಡಬೇಕಾದವು

1. ಪ್ರತಿ ವಿನಂತಿಗೆ ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಮಾಡೆಲ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ — ನಿಮ್ಮ ಲಾಗ್‌ಗಳಲ್ಲಿ input_tokens, output_tokens, cached_tokens ಮತ್ತು model ಇಲ್ಲದೆ, ನೀವು ವೆಚ್ಚವನ್ನು ಹಂಚಲು ಅಥವಾ ರಿಗ್ರೆಶನ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ; ಇದು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಅಗ್ಗದ ಇನ್‌ಸ್ಟ್ರುಮೆಂಟೇಶನ್.
2. ಲಾಂಚ್‌ಗೆ ಮೊದಲು ಪ್ರೊವೈಡರ್‌ನ ಟೋಕನೈಜರ್‌ನೊಂದಿಗೆ ವೆಚ್ಚಗಳನ್ನು ಅಂದಾಜು ಮಾಡಿ — ಅಕ್ಷರ-ಆಧಾರಿತ ಅಂದಾಜುಗಳು ಕೋಡ್ ಅಥವಾ ಇಂಗ್ಲಿಷ್-ಅಲ್ಲದ ಇನ್‌ಪುಟ್‌ಗಳಲ್ಲಿ ನಿಯಮಿತವಾಗಿ 20-30% ರಷ್ಟು ತಪ್ಪಾಗುತ್ತವೆ, ಇದು ತಿಂಗಳಿಗೆ $5k ಮತ್ತು $7k ಬಿಲ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.
3. ಕ್ಯಾಶ್ ಹಿಟ್ ದರವನ್ನು ಪ್ರಥಮ-ದರ್ಜೆಯ ಮೆಟ್ರಿಕ್ ಆಗಿ ಅಳೆಯಿರಿ — ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಸ್ಥಿರವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಕ್ಯಾಶಿಂಗ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ; 30% ಹಿಟ್ ದರ ಎಂದರೆ ನಿಮ್ಮ "ಕ್ಯಾಶ್ ಆದ" ಪ್ರಾಂಪ್ಟ್‌ನ ಹೆಚ್ಚಿನ ಭಾಗ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಮೌನವಾಗಿ ಮರುಬರೆಯಲಾಗುತ್ತಿದೆ.

ಮಾಡಬಾರದವು

1. ಇನ್‌ಪುಟ್ ಪ್ರಮಾಣವನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಔಟ್‌ಪುಟ್ ಉದ್ದವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಡಿ — ನಿಮ್ಮ ಟೋಕನ್‌ಗಳ 80% ಉಬ್ಬಿದ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಆಗಿದ್ದರೆ, ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕತ್ತರಿಸುವುದು ಒಂದಂಕಿಯ ಶೇಕಡಾವಾರು ಉಳಿತಾಯ ನೀಡುತ್ತದೆ, ಆದರೆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದು 60%+ ಉಳಿಸುತ್ತದೆ.
2. ಟೋಕನೈಜರ್‌ಗಳು ಪ್ರೊವೈಡರ್‌ಗಳ ನಡುವೆ ವರ್ಗಾವಣೆಯಾಗುತ್ತವೆ ಎಂದು ಭಾವಿಸಬೇಡಿ — ಒಂದು ಮಾಡೆಲ್‌ನ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋದಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ರಾಂಪ್ಟ್ ಇನ್ನೊಂದರಲ್ಲಿ ನೂರಾರು ಟೋಕನ್‌ಗಳಷ್ಟು ಮೀರಬಹುದು; ಮಾಡೆಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಮರು-ಎಣಿಕೆ ಮಾಡಿ.
3. ಪ್ರತಿ-ಸಂವಾದದ ವೆಚ್ಚದ ಅಂಕಿ ಇಲ್ಲದೆ ಫೀಚರ್ ಅನ್ನು ಶಿಪ್ ಮಾಡಬೇಡಿ — "LLM ವೆಚ್ಚಗಳು ಸರಿಯಾಗಿವೆ" ಎಂಬುದು ಹಣಕಾಸು ವಿಭಾಗ ಒಪ್ಪುವ ಉತ್ತರವಲ್ಲ; ಲಾಂಚ್‌ಗೆ ಮೊದಲು cost_per_user_action ಅನ್ನು ಲೆಕ್ಕಹಾಕಿ ಮತ್ತು ಅದನ್ನು ಉತ್ಪನ್ನ ಮೆಟ್ರಿಕ್ ಆಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.