ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಷಿಂಗ್ (prompt caching) ಅನ್ನು ಆನ್ ಮಾಡಿದ್ದು ನನಗೆ ಯಾವುದೇ ಉಳಿತಾಯವನ್ನು ಮಾಡಿಕೊಡಲಿಲ್ಲ—ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ನನ್ನ OpenAI-API ಇನ್‌ವಾಯ್ಸ್ ಸುಮಾರು ಕಾಲು ಭಾಗ ಹೆಚ್ಚಾಯಿತು. ಇದಕ್ಕೆ ಕಾರಣ ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ (request) ಬದಲಾಗುತ್ತಿದ್ದ ಒಂದು ಸಾಲು: ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದ್ದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ (timestamp).

ಟೋಕನ್ ಪ್ರೊಸೆಸಿಂಗ್ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು LLM ಪ್ರೊವೈಡರ್‌ಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಫ್ರಾಗ್ಮೆಂಟ್‌ಗಳನ್ನು (prompt fragments) ಕ್ಯಾಶ್ ಮಾಡಲು ಅವಕಾಶ ನೀಡುತ್ತಾರೆ. ಕ್ಯಾಶ್ ರೀಡ್ (ಒಂದು “hit”) ಸಾಮಾನ್ಯ ದರಕ್ಕಿಂತ ಹತ್ತನೇ ಒಂದು ಭಾಗದಷ್ಟು ಕಡಿಮೆ ವೆಚ್ಚವನ್ನು ಹೊಂದಿದ್ದರೆ, ಕ್ಯಾಶ್ ರೈಟ್ (ಒಂದು “miss”) ಸಾಮಾನ್ಯ ಬೆಲೆಗಿಂತ ಸುಮಾರು 1.25 × ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಒಂದು ವೇಳೆ ರೈಟ್ (write) ನಡೆದರೂ, ಕ್ಯಾಶ್ ಮಾಡಿದ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಎಂದಿಗೂ ರೀಡ್ ಮಾಡದಿದ್ದರೆ, ಆ ಹೆಚ್ಚುವರಿ 25% ಶುಲ್ಕ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ನಿಂದಾಗಿ ಪ್ರಾಂಪ್ಟ್ ಯಾವುದೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಯಾಶ್ ಎಂಟ್ರಿಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ ನಿಖರವಾಗಿ ಹೀಗೆಯೇ ನಡೆಯಿತು.

ಕ್ಯಾಷಿಂಗ್ ಏಕೆ ವಿಫಲವಾಗಬಹುದು

ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಷಿಂಗ್ ಎಂಬುದು ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಭಾಗದ ನಿಖರವಾದ (exact) ಬೈಟ್ ಸೀಕ್ವೆನ್ಸ್ ಅನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಪ್ರೊವೈಡರ್ ಇನ್‌ಪುಟ್ ಅನ್ನು ಹ್ಯಾಶ್ (hash) ಮಾಡುತ್ತಾರೆ; ಒಂದು ವೇಳೆ ಹ್ಯಾಶ್ ಸಂಗ್ರಹಿಸಲಾದ ಎಂಟ್ರಿಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾದರೆ, ಸಿಸ್ಟಮ್ ಹಿಂದಿನ ಕಂಪ್ಯೂಟೇಶನ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ದರದ ರೀಡ್ ದರವನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಯಾವುದೇ ವ್ಯತ್ಯಾಸ—ಒಂದು ಅಕ್ಷರವಾದರೂ—ಹೊಂದಾಣಿಕೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ ಕಂಪ್ಯೂಟೇಶನ್ ಅನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಇದಕ್ಕೆ ಹೆಚ್ಚಿನ ರೈಟ್ ದರವನ್ನು ವಿಧಿಸಲಾಗುತ್ತದೆ.

ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಹೀಗಿನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತಿತ್ತು:

Current session started: 2026-07-14T09:41:07Z

ಪ್ರತಿ API ಕಾಲ್‌ಗೆ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅಪ್‌ಡೇಟ್ ಆಗಿದ್ದರಿಂದ, ವಿನಂತಿಯ ಮೊದಲ ಕೆಲವು ಬೈಟ್‌ಗಳು ಎಂದಿಗೂ ಒಂದೇ ರೀತಿ ಇರಲಿಲ್ಲ. ಪ್ರೊವೈಡರ್ ಪ್ರತಿ ಕಾಲ್ ಅನ್ನು ಹೊಸ ಕ್ಯಾಶ್ ಎಂಟ್ರಿ ಎಂದು ಪರಿಗಣಿಸಿ, ರೈಟ್ ಪ್ರೀಮಿಯಂ ಅನ್ನು ವಿಧಿಸಿದರು ಮತ್ತು ಎಂದಿಗೂ ರೀಡ್ ಅನ್ನು ದಾಖಲಿಸಲಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವಾಗಿ cache_read_input_tokens ಶೂನ್ಯದಲ್ಲಿಯೇ ಉಳಿಯುವಾಗ, cache_creation_input_tokens ನಿರಂತರವಾಗಿ ಏರುತ್ತಲೇ ಇತ್ತು; ಇದು ಕ್ಯಾಶ್ ಎಂದಿಗೂ ಬಳಕೆಯಾಗುತ್ತಿಲ್ಲ (hit ಆಗುತ್ತಿಲ್ಲ) ಎಂಬುದಕ್ಕೆ ಸ್ಪಷ್ಟ ಸಂಕೇತವಾಗಿತ್ತು.

ದೋಷಪೂರಿತ ಕ್ಯಾಶ್ ಅನ್ನು ಹೇಗೆ ಗುರುತಿಸುವುದು

API ನೀಡುವ ಬಳಕೆ ಲಾಗ್‌ಗಳು (usage logs) ಎರಡು ಪ್ರಮುಖ ಕೌಂಟರ್‌ಗಳನ್ನು ನೀಡುತ್ತವೆ:

  • cache_creation_input_tokens – ರೈಟ್ (write) ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಚೋದಿಸಿದ ಟೋಕನ್‌ಗಳು.
  • cache_read_input_tokens – ರೀಡ್ (read) ಮೂಲಕ ಪ್ರಯೋಜನ ಪಡೆದ ಟೋಕನ್‌ಗಳು.

ಮೊದಲನೆಯದು ಏರುತ್ತಾ ಮತ್ತು ಎರಡನೆಯದು ಸ್ಥಿರವಾಗಿದ್ದರೆ, ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತಿಲ್ಲ ಎಂದರ್ಥ. ಒಂದು ಸರಳ ಪರೀಕ್ಷೆಯೆಂದರೆ (sanity check) ಒಂದೇ ವಿನಂತಿಯನ್ನು ಎರಡು ಬಾರಿ ಮಾಡುವುದು; ಕ್ಯಾಶ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಎರಡನೇ ಕಾಲ್‌ನಲ್ಲಿ ರೀಡ್ ಟೋಕನ್‌ಗಳಲ್ಲಿ ಏರಿಕೆ ಕಾಣಿಸಿಕೊಳ್ಳಬೇಕು.

ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುವುದು

ಪರಿಹಾರ ಸರಳವಾಗಿದೆ: ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಪ್ರದೇಶವು ಎಲ್ಲಾ ಕಾಲ್‌ಗಳಲ್ಲೂ ಸ್ಥಿರವಾಗಿರಲಿ (static) ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಈ ಎರಡು ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ:

  1. ಬದಲಾಗದ (immutable) ವಿಷಯವನ್ನು ಮೊದಲು ಇರಿಸಿ. ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳು, ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳು (tool definitions), ಅಥವಾ ಎಂದಿಗೂ ಬದಲಾಗದ ಯಾವುದೇ ಸೂಚನೆಗಳು ವಿನಂತಿಯ ಆರಂಭಿಕ ಬೈಟ್‌ಗಳಲ್ಲಿ ಇರಬೇಕು.
  2. ಬದಲಾಗುವ (mutable) ವಿಷಯವನ್ನು ಕೊನೆಯಲ್ಲಿ ಸೇರಿಸಿ. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು, ಬಳಕೆದಾರರು ಸೃಷ್ಟಿಸಿದ ಪಠ್ಯ, ರಿಕ್ವೆಸ್ಟ್ ಐಡಿಗಳು ಅಥವಾ ಪ್ರತಿ ಕಾಲ್‌ಗೆ ಬದಲಾಗುವ ಯಾವುದೇ ಡೇಟಾ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಭಾಗದ ನಂತರ ಬರಬೇಕು.

ಒಂದು ಅಕ್ಷರ ಬದಲಾದರೂ, ಹ್ಯಾಶ್ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಯಾಶ್ ಮಿಸ್ (cache miss) ಮುಂದುವರಿಯುತ್ತದೆ. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಕೊನೆಯಲ್ಲಿರುವಂತೆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದರಿಂದ ಕ್ಯಾಶ್ ಹಿಟ್ ದರವು (cache hit rate) ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಬಿಲ್ ಅನ್ನು ನಿರೀಕ್ಷಿತ ಕಡಿಮೆ ವೆಚ್ಚದ ಮಟ್ಟಕ್ಕೆ ತರುತ್ತದೆ.

ಕ್ಯಾಷಿಂಗ್ ಯಾವಾಗ ನಿಜವಾಗಿಯೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ

ಒಂದೇ ಸೂಚನೆಗಳ ಸೆಟ್ ಅನ್ನು ಅನೇಕ ಬಾರಿ ಮರುಬಳಕೆ ಮಾಡುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಷಿಂಗ್ ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

  • ಏಜೆಂಟ್ ಲೂಪ್‌ಗಳು (Agent loops) ಎಲ್ಲಿ AI ಪದೇ ಪದೇ ನಿರ್ದಿಷ್ಟ ಟೂಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ.
  • ಚಾಟ್ ಸೆಷನ್‌ಗಳು (Chat sessions) ಎಲ್ಲಿ ಬಳಕೆದಾರರ ಇತ್ತೀಚಿನ ಪ್ರಶ್ನೆಯು ಮಾತ್ರ ಬದಲಾಗುತ್ತದೆಯೇ ಹೊರತು, ಒಂದು ಉದ್ದವಾದ ಸ್ಥಿರ ದಾಖಲೆಯನ್ನು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ.
  • ಬಲ್ಕ್ ಡೇಟಾ ಎಕ್ಸ್‌ಟ್ರಾಕ್ಷನ್ (Bulk data extraction) ಎಲ್ಲಿ ಒಂದೇ ಪಾರ್ಸಿಂಗ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಅನೇಕ ದಾಖಲೆಗಳಿಗೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸ ಸಂದರ್ಭವನ್ನು ಒಳಗೊಂಡಿರುವ ಸಿಂಗಲ್-ಶಾಟ್ ಕಾಲ್‌ಗಳಿಗೆ (single-shot calls)—ಉದಾಹರಣೆಗೆ ವಿಶಿಷ್ಟ ಪ್ರೇರಣೆಯೊಂದಿಗೆ (preamble) ಕೇಳುವ ಏಕೈಕ ಪ್ರಶ್ನೆ—ಕ್ಯಾಷಿಂಗ್ ಯಾವುದೇ ಪ್ರಯೋಜನವನ್ನು ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ವಿನಂತಿಯು ಅನಿರೀಕ್ಷಿತವಾಗಿ ರೈಟ್ (write) ಅನ್ನು ಪ್ರಚೋದಿಸಿದರೆ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.

ಅಡಗಿರುವ ಅಪಾಯಗಳು

ಪ್ರಾಂಪ್ಟ್ ಸ್ಥಿರವಾಗಿದ್ದರೂ ಸಹ, ವಿನಂತಿಯು ಡೌನ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಬದಲಾಗಬಹುದು:

  • ಪ್ರೊಕ್ಸಿಗಳು ಅಥವಾ ಅಗ್ಲಿಗೇಟರ್‌ಗಳು (Proxies or aggregators) ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸಿದರೆ ಅಥವಾ ವೈಟ್‌ಸ್ಪೇಸ್ (whitespace) ಅನ್ನು ಸೇರಿಸಿದರೆ, ಬೈಟ್-ಬೈಟ್ ಹೊಂದಾಣಿಕೆಯು ತಪ್ಪಬಹುದು.
  • ಗೇಟ್‌ವೇ ಸೇವೆಗಳು (Gateway services) ಅಥೆಂಟಿಕೇಶನ್ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಿದರೆ ಅಥವಾ JSON ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಿದರೆ, ಅರಿಯದೇ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಫ್ರಾಗ್ಮೆಂಟ್ ಬದಲಾಗಬಹುದು.

ಗೇಟ್‌ವೇ ಮೂಲಕ ಒಂದೇ ವಿನಂತಿಯನ್ನು ಎರಡು ಬಾರಿ ಕಳುಹಿಸಿ ಮತ್ತು ರೀಡ್ ಕೌಂಟರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಪರೀಕ್ಷಿಸುವುದು, ಕ್ಯಾಷಿಂಗ್ ಮಾರ್ಗವು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ವೆಚ್ಚದ ವಿಶಾಲ ಚಿತ್ರಣ

ರೈಟ್‌ಗಳ ಮೇಲಿನ 25% ಹೆಚ್ಚುವರಿ ಶುಲ್ಕವು ಕ್ಯಾಷಿಂಗ್ ಬಳಸಿದ್ದಕ್ಕಾಗಿ ವಿಧಿಸುವ ದಂಡವಲ್ಲ; ಇದು ಭವಿಷ್ಯದ ಮರುಬಳಕೆಗಾಗಿ ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಬೇಕಾಗುವ ಹೆಚ್ಚುವರಿ ಕಂಪ್ಯೂಟ್ ಅನ್ನು ಪ್ರತಿಫಲಿಸುತ್ತದೆ. ಕ್ಯಾಶ್ ಹಿಟ್ ಆದಾಗ, ವೆಚ್ಚವು ನಾಟಕೀಯವಾಗಿ ಕುಸಿಯುತ್ತದೆ—ಅದು ಹೆಚ್ಚಾಗಿ ಸಾಮಾನ್ಯ ದರಕ್ಕಿಂತ ಒಂದು ಭಾಗದಷ್ಟು ಇರುತ್ತದೆ. ಸಿಸ್ಟಮ್ ನಿಜವಾಗಿಯೂ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸುವಂತೆ (hit) ಮಾಡುವುದು ಇಲ್ಲಿ ಮುಖ್ಯ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಯಾವುದೇ ಉಳಿತಾಯವಿಲ್ಲದೆ ಹೆಚ್ಚಿನ ಬೆಲೆಯನ್ನು ಪಾವತಿಸುತ್ತೀರಿ.

ಪ್ರತಿವಾದ: ಕ್ಯಾಷಿಂಗ್ ಅಳಿದು ಹೋಗಿಲ್ಲ

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

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

  • ನಿಮ್ಮ ಬಳಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿರುವ ಎರಡೂ ಕ್ಯಾಶ್ ಕೌಂಟರ್‌ಗಳನ್ನು ವಾರಕ್ಕೊಮ್ಮೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
  • ಯಾವುದೇ ಬದಲಾಗುವ ಅಂಶವು (variable element) ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಬ್ಲಾಕ್ ನಂತರವಷ್ಟೇ ಇರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಾಂಪ್ಟ್ ರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ (Audit).
  • ನೈಜ ಉಳಿತಾಯವನ್ನು ಅಳೆಯಲು, ಪ್ರತಿನಿಧಿಸುವ ಕೆಲಸದ ಹೊರೆಯನ್ನು (workload) ಬಳಸಿಕೊಂಡು ಕ್ಯಾಶಿಂಗ್ ಇರುವ ಮತ್ತು ಇಲ್ಲದ ಸಂದರ್ಭಗಳಲ್ಲಿ A/B ಪರೀಕ್ಷೆಗಳನ್ನು (A/B tests) ನಡೆಸಿ.
  • ಯಾವುದೇ ಪ್ರೊಕ್ಸಿಯ ಮೊದಲು ಮತ್ತು ನಂತರದ ರೊ (raw) ರಿಕ್ವೆಸ್ಟ್ ಪೇಲೋಡ್‌ಗಳನ್ನು ಹೋಲಿಸುವ ಮೂಲಕ ಗೇಟ್‌ವೇಯನ್ನು (gateway) ದೃಢೀಕರಿಸಿ.

ಸಾರಾಂಶ

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