ડેವಲಪರ್‌ಗಳು Claude ನ ಪ್ರಾಂಪ್ಟ್-ಕ್ಯಾಶಿಂಗ್ (prompt-caching) ಮೌನವಾಗಿ ವಿಫಲವಾಗಬಹುದು ಎಂದು ಕಂಡುಕೊಂಡಿದ್ದಾರೆ, ಇದು ಶೂನ್ಯ ಕ್ಯಾಶ್ಡ್ ಟೋಕನ್‌ಗಳನ್ನು (cached tokens) ನೀಡುವಾಗಲೂ ಪ್ರೀಮಿಯಂ ದರಗಳನ್ನು ವಿಧಿಸುತ್ತದೆ. ಒಂದು ವಾರಗಳ ಕಾಲ WhatsApp ಹ್ಯಾಂಡ್ಲರ್‌ನಲ್ಲಿ ನಡೆಸಿದ ಲಾಗ್ ವಿಶ್ಲೇಷಣೆಯು ಯಾವುದೇ ಕ್ಯಾಶ್ ರೀಡ್‌ಗಳನ್ನು ತೋರಿಸಲಿಲ್ಲ, ಆದರೂ API ಕ್ಯಾಶಿಂಗ್ ಫೀಚರ್‌ಗಾಗಿ ಬಿಲ್ ಮಾಡಿದೆ—ಇದು ಮಾಸಿಕ ವೆಚ್ಚವನ್ನು $1,890 ರಿಂದ $406 ಕ್ಕೆ ಇಳಿಸಿತು.

ಈ ಸಮಸ್ಯೆ ಏಕೆ ಮುಖ್ಯ

ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಎಂಬುದು ಪ್ರಾಂಪ್ಟ್‌ನ ಒಂದು ಸ್ಥಿರ ಭಾಗವನ್ನು ("prefix") ಮರುಬಳಕೆ ಮಾಡುವ ಮೂಲಕ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ಇದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿದಾಗ, ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಇರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ತಮ್ಮ ಮಾಸಿಕ ಬಿಲ್‌ಗಳಿಂದ ನೂರಾರು ಡಾಲರ್‌ಗಳನ್ನು ಉಳಿಸಬಹುದು. ಇದು ಕೆಲಸ ಮಾಡದಿದ್ದಾಗ, ડેವಲಪರ್‌ಗಳು ತಾವು ಎಂದಿಗೂ ಬಳಸದ ಫೀಚರ್‌ಗಾಗಿ ಹಣ ಪಾವತಿಸುತ್ತಾರೆ ಮತ್ತು ಈ ಮೌನ ವೈಫಲ್ಯವು ಸಮಸ್ಯೆಯನ್ನು ಸೂಚಿಸಲು ಯಾವುದೇ ದೋಷ (error) ಅಥವಾ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ.

ಈ ಬಗ್ ಹೇಗೆ ಕಂಡುಬರುತ್ತದೆ

API ಒಂದು cache-control ಫ್ಲಾಗ್ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್‌ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ನಂತರ ಕ್ಯಾಶ್‌ನಿಂದ ಎಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಓದಲಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಗಮನಿಸಿದ ಪ್ರಕರಣದಲ್ಲಿ, ಪ್ರತಿ ವಿನಂತಿಯು ಶೂನ್ಯ ಕ್ಯಾಶ್-ರೀಡ್ ಎಣಿಕೆಯನ್ನು ನೀಡಿತು. ಕರಲ್ ಯಶಸ್ವಿಯಾಯಿತು, ಯಾವುದೇ ಎಕ್ಸೆಪ್ಶನ್ (exception) ಉಂಟಾಗಲಿಲ್ಲ, ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ ಪ್ರೀಮಿಯಂ ಕ್ಯಾಶ್ ವೆಚ್ಚವನ್ನು ಪ್ರತಿಫಲಿಸಿತು. ನೀವು ರೀಡ್ ಕೌಂಟ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಲಾಗ್ ಮಾಡದ ಹೊರತು ಈ ವೈಫಲ್ಯವು ಅದೃಶ್ಯವಾಗಿರುತ್ತದೆ.

ಕ್ಯಾಶ್ ವಿಫಲವಾಗಲು ಸಾಮಾನ್ಯ ಕಾರಣಗಳು

  • ಪ್ರಿಫಿಕ್ಸ್ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದರೆ – ಪ್ರತಿಯೊಂದು Claude ಮಾಡೆಲ್ ಕ್ಯಾಶ್ ಮಾಡಬಹುದಾದ ಪ್ರಿಫಿಕ್ಸ್‌ನ ಕನಿಷ್ಠ ಟೋಕನ್ ಉದ್ದವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Haiku 4.5 ಗೆ ಕನಿಷ್ಠ 4,096 ಟೋಕನ್‌ಗಳು ಬೇಕು; Sonnet 4.6 ಗೆ ಕೇವಲ 1,024 ಬೇಕು. ಚಿಕ್ಕದಾದ ಪ್ರಿಫಿಕ್ಸ್‌ ಅನ್ನು ಕಳುಹಿಸುವುದು ವಿನಂತಿ ಫಾರ್ಮ್ಯಾಟ್‌ಗೆ ಸರಿಹೊಂದಬಹುದು, ಆದರೆ ಸೇವೆ ಕ್ಯಾಶ್ ಸೂಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.
  • ಬದಲಾಗುವ ಬೈಟ್ ಚಲಿಸಿದರೆ – ಕ್ಯಾಶಿಂಗ್ ಮಾಡಲು ನಿಖರವಾದ ಬೈಟ್-ಬೈಟ್ ಹೊಂದಾಣಿಕೆ ಅಗತ್ಯವಿದೆ. ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ನ ಮುಂಭಾಗಕ್ಕೆ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್, new Date(), ಅಥವಾ ಬಳಕೆದಾರರ ಇಮೇಲ್‌ನಂತಹ ಡೈನಾಮಿಕ್ ಅಂಶವನ್ನು ಸೇರಿಸುವುದು ಬೈಟ್ ಸರಣಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಇದರಿಂದ ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಹೊಸದಾದ, ಅನ್‌ಕ್ಯಾಶ್ಡ್ ಬರೆಯುವಿಕೆಯಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
  • ಟೂಲ್ ಲಿಸ್ಟ್‌ನ ಕ್ರಮ ಬದಲಾದರೆ – ಟೂಲ್‌ಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಮುಂಚಿತವಾಗಿ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಟೂಲ್ ಅರೇ (array) ಅನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಕೀಗಳಿಂದ ನಿರ್ಮಿಸಿದರೆ, ಇಟರೇಶನ್ ಕ್ರಮವು ಕರಲ್‌ಗಳ ನಡುವೆ ಬದಲಾಗಬಹುದು, ಇದು ಬೈಟ್ ಲೇಔಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿ ಕ್ಯಾಶ್ ಅನ್ನು ಮುರಿಯುತ್ತದೆ.

ನೀವು ಇಂದು ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದಾದ ಪರಿಹಾರಗಳು

  • ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವನ್ನು ಪರಿಶೀಲಿಸಿ – ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು, ಮಾಡೆಲ್‌ನ ಕನಿಷ್ಠ ಉದ್ದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಪ್ರಿಫಿಕ್ಸ್‌ನ ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಅಂದಾಜಿಸಿ. ಅದು ಕಡಿಮೆ ಇದ್ದರೆ ಪ್ರಿಫಿಕ್ಸ್‌ ಅನ್ನು ತಿರಸ್ಕರಿಸಿ ಅಥವಾ ಪ್ಯಾಡ್ (pad) ಮಾಡಿ.
  • ಪ್ರತಿ ಕರಲ್‌ನಲ್ಲಿಯೂ ಕ್ಯಾಶ್ ರೀಡ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ – “cache read tokens” ಫೀಲ್ಡ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಶೂನ್ಯಗಳ ಸರಣಿಯು ಕ್ಯಾಶ್ ಬಳಕೆಯಾಗುತ್ತಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸ್ಪಷ್ಟ ಸಂಕೇತವಾಗಿದೆ.
  • ಪ್ರಾಂಪ್ಟ್‌ನ ಆರಂಭಿಕ ಬೈಟ್‌ಗಳನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ – ಕ್ಯಾಶ್ಡ್ ಸೆಗ್ಮೆಂಟ್‌ನಿಂದ ಡೈನಾಮಿಕ್ ಡೇಟಾವನ್ನು ಹೊರಗಿಡಿ. ನೀವು ಬಳಕೆದಾರರಿಗೆ ಸಂಬಂಧಿಸಿದ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸಲೇಬೇಕೆಂದಿದ್ದರೆ, ಅದನ್ನು ಕ್ಯಾಶ್ಡ್ ಪ್ರಿಫಿಕ್ಸ್ ನಂತರ ಇರಿಸಿ.
  • ಮಾಡೆಲ್ ಐಡೆಂಟಿಫೈಯರ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿ – ರೂಟಿಂಗ್‌ನಲ್ಲಿ ಬಳಸುವ ಮಾಡೆಲ್ ID ನಿಮ್ಮ ಕ್ಯಾಶ್ ಟೇಬಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ID ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ; ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದ ID ಗಳು ಕ್ಯಾಶ್ ಲುಕಪ್ ಅನ್ನು ತಡೆಯುತ್ತವೆ.

ವೆಚ್ಚದ ದೃಷ್ಟಿಕೋನ

ದಿನಕ್ಕೆ ಸಾವಿರಾರು ಕರಲ್‌ಗಳನ್ನು ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ, ಅನ್‌ಕ್ಯಾಶ್ಡ್‌ನಿಂದ ಕ್ಯಾಶ್ಡ್‌ಗೆ ಬದಲಾಗುವುದು ಮಾಸಿಕ ವೆಚ್ಚವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು—ವರದಿ ಮಾಡಲಾದ ಪ್ರಕರಣದಲ್ಲಿ ಸುಮಾರು $1,890 ರಿಂದ $406 ಕ್ಕೆ ಇಳಿಕೆಯಾಗಿದೆ. ಸಾಧಾರಣ ಟ್ರಾಫಿಕ್ ಕೂಡ ಗಮನಾರ್ಹ ಉಳಿತಾಯವನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಸ್ಥಿರ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆ ಹೆಚ್ಚುತ್ತದೆ ಮತ್ತು ವಿಳಂಬತೆ (latency) ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ

ಆದಾಗ್ಯೂ, ವೈಫಲ್ಯದ ಮೌನ ಸ್ವಭಾವವು ನೀವು ಅತಿಯಾಗಿ ಪಾವತಿಸುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ರೀಡ್ ಕೌಂಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು—ಇದನ್ನು ಅನೇಕರು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • ಮೆಟ್ರಿಕ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು – ವಿನಂತಿ ಪ್ರಮಾಣದ ಜೊತೆಗೆ ಕ್ಯಾಶ್-ರೀಡ್ ಟೋಕನ್‌ಗಳಿಗಾಗಿ ಒಂದು ಗೇಜ್ ಅನ್ನು ಸೇರಿಸಿ.
  • ಟೂಲ್-ಆರ್ಡರಿಂಗ್ ಸ್ಥಿರತೆ – ನೀವು ಡೈನಾಮಿಕ್ ಆಗಿ ಜನರೇಟ್ ಮಾಡಲಾದ ಟೂಲ್ ಲಿಸ್ಟ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಅವುಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಸೇರಿಸುವ ಮೊದಲು ನಿರ್ಣಾಯಕವಾಗಿ (deterministically) ವಿಂಗಡಿಸಲು ಪರಿಗಣಿಸಿ.

ಸಾರಾಂಶ: Claude ನ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಮೌನವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಿದಾಗ ಯಾವುದೇ ದೋಷವನ್ನು (error) ತೋರಿಸುವುದಿಲ್ಲ. ರೀಡ್ ಟೋಕನ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡುವ ಮೂಲಕ ಕ್ಯಾಶ್ ಪರಿಣಾಮಕಾರಿಕತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಸರಿಯಾದ ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ನ ಆರಂಭಿಕ ಬೈಟ್‌ಗಳನ್ನು ಬದಲಾಗದಂತೆ (immutable) ಇರಿಸಿ. ಆಗ ಮಾತ್ರ ನೀವು ಭರವಸೆ ನೀಡಿದ ವೆಚ್ಚ ಮತ್ತು ವೇಗದ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.