Claude Opus 5 ನ ಹೊಸ prompt-caching API, ಬದಲಾಗದ ಪಠ್ಯವನ್ನು ಮರುಪಠಿಸುವ ಅಗತ್ಯವಿಲ್ಲದಂತೆ ಮಾಡುವುದರ ಮೂಲಕ ಚಾಟ್-ಶೈಲಿಯ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಟೋಕನ್ ಬಿಲ್ಗಳನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಮೊದಲ ವಿನಂತಿಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ಶುಲ್ಕವಿರುತ್ತದೆ; ಪ್ರತಿ ನಂತರದ ವಿನಂತಿಯು ಮೂಲ ದರದಲ್ಲಿ ಸರಿಸುಮಾರು ಹತ್ತನೇ ಒಂದು ಭಾಗದಷ್ಟು ವೆಚ್ಚವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಇದು ಪುನರಾವರ್ತಿತ ವೆಚ್ಚವನ್ನು ಏಕಕಾಲದ ಶುಲ್ಕವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
Same ಪದಗಳಿಗಾಗಿ ಡೆವಲಪರ್ಗಳು ಏಕೆ ಎರಡು ಬಾರಿ ಪಾವತಿಸುತ್ತಾರೆ
ಹೆಚ್ಚಿನ ಸಂಭಾಷಣಾ ಇಂಟರ್ಫೇಸ್ಗಳು ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಪೂರ್ಣ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತವೆ: ಬಳಕೆದಾರರು ಅನುಬಂಧ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದ ಪ್ರತಿ ಬಾರಿಯೂ 8,000-ಟೋಕನ್ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಲಗತ್ತಿಸಲಾದ PDFಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವು ಒಟ್ಟಾಗಿ ಮಾಡೆಲ್ಗೆ ತಲುಪುತ್ತವೆ. ಪಠ್ಯದ ಬಹುಪಾಲು ಭಾಗವು ಎಂದಿಗೂ ಬದಲಾಗದಿದ್ದರೂ ಸಹ, ಮಾಡೆಲ್ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಅನ್ನು ಮರು-ಪ್ರೊಸೆಸ್ ಮಾಡುತ್ತದೆ. ಪ್ರಸ್ತುತ ಬೆಲೆಗಳ ಪ್ರಕಾರ, ಈ ಅನಗತ್ಯ ಪುನಾವರ್ತನೆಯು ಕಾರ್ಯನಿರತ ಬಾಟ್ನ ವೆಚ್ಚದ ಮೇಲೆ ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಬೀರಬಹುದು.
ಕ್ಯಾಶ್ (cache) ಹೇಗೆ ಲೆಕ್ಕಾಚಾರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ
API ಒಂದು ನಿರ್ದಿಷ್ಟ ಬ್ರೇಕ್ಪಾಯಿಂಟ್ವರೆಗೆ ಪ್ರತಿ "ಬ್ಲಾಕ್" ಟೋಕನ್ಗಳಿಗಾಗಿ ಕ್ಯಾಶ್ ಎಂಟ್ರಿಯನ್ನು ರಚಿಸುತ್ತದೆ. ಮುಂದಿನ ವಿನಂತಿಯು ಮುಂಭಾಗದಲ್ಲಿ ಅದೇ ಬ್ಲಾಕ್ ಅನ್ನು ಹೊಂದಿದ್ದಾಗ, ಸೇವೆ ಅದನ್ನು ಮತ್ತೆ ಟೋಕನೈಸ್ ಮಾಡುವ ಬದಲು ಕ್ಯಾಶ್ನಿಂದ ಓದುತ್ತದೆ. ಉಳಿತಾಯವಾದ ಕೆಲಸವನ್ನು ಈ ಬೆಲೆ ವಿಭಜನೆಯು ಪ್ರತಿಫಲಿಸುತ್ತದೆ:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಹೊಸ ಬ್ಲಾಕ್ಗೆ ಮಾಡುವ ಮೊದಲ ಕರೆಯು ಸಾಮಾನ್ಯ ವಿನಂತಿಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸುವ ನಂತರದ ಪ್ರತಿಯೊಂದು ಕರೆಯು 90% ರಷ್ಟು ಅಗ್ಗವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಭಾಷಣೆ ಮುಂದುವರಿಯುತ್ತಿದ್ದಂತೆ ಒಟ್ಟು ವೆಚ್ಚವು ತೀವ್ರವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ರಚಿಸಲು "ಸುವರ್ಣ ನಿಯಮ"
ಕ್ಯಾಶ್ನ ಪರಿಣಾಮಕಾರಿತ್ವವು ನೀವು ಸ್ಥಿರ (static) ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ (dynamic) ವಿಷಯಗಳನ್ನು ಎಲ್ಲಿ ಇರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಬದಲಾಗದ ಎಲ್ಲವನ್ನೂ ಮುಂಭಾಗದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಬದಲಾಗುವ ಭಾಗಗಳನ್ನು ಕೊನೆಯಲ್ಲಿ ಇರಿಸಿ. ವಿಶ್ವಾಸಾರ್ಹ ಕ್ರಮವು ಈ ರೀತಿ ಇರುತ್ತದೆ:
- Tools – ಮಾಡೆಲ್ ಕರೆಯಬಹುದಾದ ಯಾವುದೇ ಬಾಹ್ಯ ಫಂಕ್ಷನ್ಗಳ ವ್ಯಾಖ್ಯಾನಗಳು.
- System instructions – ಮಾಡೆಲ್ ಅನುಸರಿಸಬೇಕೆಂದು ನೀವು ಬಯಸುವ ಉನ್ನತ ಮಟ್ಟದ ನಡವಳಿಕೆ.
- Documents – PDFಗಳು, ನೌಲೆಡ್ಜ್ ಬೇಸ್ಗಳು ಅಥವಾ ಪಾಲಿಸಿ ಸಾರಾಂಶಗಳಂತಹ ದೀರ್ಘ ಸಂದರ್ಭಗಳು (context).
- User questions – ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಬದಲಾಗುವ ನೇರ ಪ್ರಶ್ನೆ.
ನೀವು ಬ್ರೇಕ್ಪಾಯಿಂಟ್ಗಿಂತ ಮೊದಲು ಯಾವುದೇ ಟೋಕನ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಕ್ಯಾಶ್ ಎಂಟ್ರಿ ಅಸಿಂಧುವಾಗುತ್ತದೆ ಮತ್ತು ಮಾಡೆಲ್ ಅದರ ನಂತರದ ಎಲ್ಲವನ್ನೂ ಮರು-ಪ್ರೊಸೆಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ನೀವು ಗೌರವಿಸಬೇಕಾದ ಗುಪ್ತ ಮಿತಿಗಳು
- Minimum block size – Opus 5 ಕನಿಷ್ಠ 512 ಟೋಕನ್ಗಳನ್ನು ಹೊಂದಿರುವ ಬ್ಲಾಕ್ಗಳನ್ನು ಮಾತ್ರ ಕ್ಯಾಶ್ ಮಾಡುತ್ತದೆ. ಅದಕ್ಕಿಂತ ಚಿಕ್ಕದಾದವುಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಕ್ಯಾಶ್ನಿಂದ ಹೊರಗುಳಿಯುತ್ತವೆ.
- Timestamp bug – ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಬ್ಲಾಕ್ನ ಒಳಗೆ ಬದಲಾಗುವ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಸೇರಿಸುವುದು ಕ್ಯಾಶ್ ಮಿಸ್ ಆಗಲು ಖಚಿತ ಕಾರಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಬ್ಲಾಕ್ನ ಪಠ್ಯವು ಎಂದಿಗೂ ನಿಖರವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
- 20-block look-back – ಸೇವೆ ಹೊಂದಾಣಿಕೆಗಾಗಿ ಕೊನೆಯ 20 ಬ್ಲಾಕ್ಗಳನ್ನು ಮಾತ್ರ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ. ವೇಗವಾಗಿ ಮುಂದುವರಿಯುವ ದೀರ್ಘ ಅವಧಿಯ ಸೆಷನ್ಗಳು ಕ್ಯಾಶ್ ವಿಂಡೋವನ್ನು ಮೀರಿ ಹೋಗಬಹುದು.
- Parallel requests – ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿದರೆ ಅವುಗಳೆಲ್ಲವೂ ಕ್ಯಾಶ್ ಮಿಸ್ ಆಗುತ್ತವೆ, ಏಕೆಂದರೆ ಮೊದಲ ವಿನಂತಿ ಮುಗಿದ ನಂತರವೇ ಕ್ಯಾಶ್ ಅನ್ನು ತುಂಬಿಸಲಾಗುತ್ತದೆ. ಮೊದಲು ಒಂದೇ ಒಂದು ಕರೆಯ ಮೂಲಕ ಕ್ಯಾಶ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿ (warm), ನಂತರ ಉಳಿದವುಗಳನ್ನು ಕಳುಹಿಸಿ.
ನಿಮ್ಮ API ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಉಳಿತಾಯವನ್ನು ನೋಡುವುದು
ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಯು ಮೂರು ಟೋಕನ್ ಕೌಂಟರ್ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ:
cache_read_input_tokens– ಕ್ಯಾಶ್ ಹಿಟ್ನಿಂದ ಬಂದ ಟೋಕನ್ಗಳು.cache_creation_input_tokens– ಈ ವಿನಂತಿಯಲ್ಲಿ ಕ್ಯಾಶ್ಗೆ ಬರೆಯಲಾದ ಟೋಕನ್ಗಳು.input_tokens– ಕ್ಯಾಶ್ ಮಾಡದ ಹೊಸ ಟೋಕನ್ಗಳು.
ಆ ಹಂತದಲ್ಲಿ ಮಾಡೆಲ್ ಪರಿಗಣಿಸಿದ ಒಟ್ಟು ಟೋಕನ್ಗಳನ್ನು ಪಡೆಯಲು ಈ ಮೂರು ಸಂಖ್ಯೆಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ. ಎರಡೂ ಕ್ಯಾಶ್ ಫೀಲ್ಡ್ಗಳು ಸೊನ್ನೆಯಾಗಿದ್ದರೆ, ವಿನಂತಿಯು ಕ್ಯಾಶ್ ಅನ್ನು ಮಿಸ್ ಮಾಡಿದೆ ಎಂದರ್ಥ; ನಿಮ್ಮ ಬ್ಲಾಕ್ ಗಾತ್ರ ಮತ್ತು ಬ್ರೇಕ್ಪಾಯಿಂಟ್ ಸ್ಥಳವನ್ನು ಪರಿಶೀಲಿಸಿ.
Takeaway: ಬದಲಾಗದ ಸಂದರ್ಭವನ್ನು (immutable context) ಮುಂಭಾಗದಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಮತ್ತು Claude Opus 5 ನ prompt-caching API ಅನ್ನು ಮುಖ್ಯ ಕೆಲಸ ಮಾಡಲು ಬಿಡುವುದರ ಮೂಲಕ, ನೀವು ಪುನರಾವರ್ತಿತ ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಏಕಕಾಲದ ಶುಲ್ಕವನ್ನಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು. ನೀವು ಟೋಕನ್ ಮಿತಿಯನ್ನು ಗೌರವಿಸಿದರೆ, ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಬ್ಲಾಕ್ಗಳ ಒಳಗೆ ಬದಲಾಗುವ ಮಾರ್ಕರ್ಗಳನ್ನು ತಪ್ಪಿಸಿದರೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ಯಾಶ್-ಅರ್ಹ ವಿಷಯವನ್ನು 20-ಬ್ಲಾಕ್ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಇರಿಸಿಕೊಂಡರೆ, ಒಂದೇ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅಥವಾ ಡಾಕ್ಯುಮೆಂಟ್ ಸೆಟ್ ಅನ್ನು ಪದೇ ಪದೇ ಉಲ್ಲೇಖಿಸುವ ಯಾವುದೇ ಚಾಟ್ಬಾಟ್ಗೆ ಇದು ಗಮನಾರ್ಹ ವೆಚ್ಚ ಕಡಿತವನ್ನು ನೀಡುತ್ತದೆ.