Claude-ன் prompt-caching அமைப்பானது அமைதியாகத் தோல்வியடையக்கூடும் என்பதையும், இதனால் பூஜ்ஜிய cached tokens மட்டுமே கிடைத்தும், அதிக கட்டணம் வசூலிக்கப்படுவதையும் டெவலப்பர்கள் கண்டறிந்துள்ளனர். ஒரு WhatsApp handler-ல் ஒரு வார கால அளவில் மேற்கொள்ளப்பட்ட log ஆய்வில், cache reads எதுவும் இல்லை என்பது தெரியவந்தது, இருப்பினும் API caching வசதிக்காகக் கட்டணம் வசூலித்தது—இது மாதச் செலவை $1,890-லிருந்து $406-ஆகக் குறைத்தது.

இந்தச் சிக்கல் ஏன் முக்கியமானது

Prompt caching என்பது ஒரு prompt-ன் நிலையான பகுதியை (the “prefix”) மீண்டும் பயன்படுத்துவதன் மூலம் செலவைக் குறைக்கவும் மற்றும் பதில்களின் வேகத்தை அதிகரிக்கவும் வடிவமைக்கப்பட்டுள்ளது. இது சரியாகச் செயல்படும்போது, அதிகப் பயன்பாடு கொண்ட (high-traffic) செயலிகள் தங்கள் மாதக் கட்டணத்தில் நூற்றுக்கணக்கான டாலர்களைச் சேமிக்க முடியும். ஆனால் இது செயல்படாதபோது, டெவலப்பர்கள் தாங்கள் உண்மையில் பயன்படுத்தாத ஒரு வசதிக்காகப் பணம் செலுத்த வேண்டியுள்ளது; மேலும் இந்த அமைதியான தோல்வி (silent failure), சிக்கலைப் பற்றிய எந்தத் தவறுச் செய்தியையோ (error) அல்லது எச்சரிக்கையையோ வழங்காது.

இந்தத் தவறு எவ்வாறு வெளிப்படுகிறது

API ஒரு cache-control flag மற்றும் ஒரு prefix-ஐ ஏற்றுக்கொண்டு, பின்னர் cache-லிருந்து எத்தனை tokens படிக்கப்பட்டன என்பதைத் தெரிவிக்கும். ஆய்வில் கண்டறியப்பட்ட நிகழ்வில், ஒவ்வொரு கோரிக்கையும் (request) பூஜ்ஜிய cache-read எண்ணிக்கையையே வழங்கியது. அந்த அழைப்பு (call) வெற்றிகரமாக முடிந்தது, எந்தத் தவறும் (exception) ஏற்படவில்லை, ஆனால் கட்டணத்தில் premium cache கட்டணம் வசூலிக்கப்பட்டது. நீங்கள் read count-ஐத் தனிப்பயனாக்க (explicitly log) செய்யாதவரை, இந்தத் தோல்வி கண்ணுக்குத் தெரியாது.

Cache செயலிழப்பதற்கான பொதுவான வழிகள்

  • Prefix மிகச் சிறியதாக இருப்பது – ஒவ்வொரு Claude மாடலும் cache செய்யக்கூடிய prefix-கிற்கு ஒரு குறைந்தபட்ச token நீளத்தைத் தீர்மானிக்கிறது. Haiku 4.5-க்கு குறைந்தது 4,096 tokens தேவை; Sonnet 4.6-க்கு 1,024 tokens மட்டுமே தேவை. மிகச் சிறிய prefix-ஐ அனுப்புவது கோரிக்கை வடிவமைப்பிற்கு (request format) சரியாக இருந்தாலும், சேவை cache அறிவுறுத்தலைத் தவிர்க்கிறது.
  • மாறக்கூடிய byte நகர்தல் – Caching செய்வதற்கு byte-for-byte துல்லியமான பொருத்தம் தேவை. system prompt-ன் தொடக்கத்தில் ஒரு timestamp, new Date(), அல்லது பயனர் மின்னஞ்சல் போன்ற ஒரு மாறும் (dynamic) கூறுகளைச் சேர்ப்பது byte வரிசையை மாற்றுகிறது, இதனால் ஒவ்வொரு கோரிக்கையும் ஒரு புதிய, cache செய்யப்படாத பதிவாகக் (uncached write) கருதப்படுகிறது.
  • Tool பட்டியலின் வரிசை மாறுதல் – Tools என்பவை prompt-ன் முன்னால் சேர்க்கப்படுகின்றன. ஒருவேளை tool array என்பது object keys-லிருந்து உருவாக்கப்பட்டால், அழைப்புகளுக்கு இடையே அதன் வரிசை மாறக்கூடும், இது byte அமைப்பை மாற்றி cache-ஐச் செயலிழக்கச் செய்கிறது.

நீங்கள் இன்று செயல்படுத்தக்கூடிய தீர்வுகள்

  • Prefix நீளத்தைச் சரிபார்க்கவும் – ஒரு கோரிக்கையை அனுப்புவதற்கு முன், மாடலின் குறைந்தபட்சத் தேவையைச் Stirling prefix-ன் token எண்ணிக்கையுடன் ஒப்பிட்டுப் பார்க்கவும். அது குறைவாக இருந்தால், அந்த prefix-ஐ நிராகரிக்கவும் அல்லது கூடுதல் tokens சேர்த்து நிரப்பவும் (pad).
  • ஒவ்வொரு அழைப்பிலும் cache reads-ஐப் பதிவு செய்யவும் – “cache read tokens” புலத்தைப் (field) பதிவு செய்யவும். தொடர்ச்சியாக பூஜ்ஜியங்கள் வருவது, cache சரியாகப் பயன்படுத்தப்படவில்லை என்பதற்கான தெளிவான அறிகுறியாகும்.
  • Prompt-ன் தொடக்க byte-களை நிலையானதாக மாற்றவும் – மாறும் தரவுகளை (dynamic data) cache செய்யப்படும் பகுதியிலிருந்து விலக்கி வைக்கவும். பயனர் சார்ந்த தகவல்களைச் சேர்க்க வேண்டியிருந்தால், அவற்றை cache செய்யப்பட்ட prefix-க்குப் பிறகு வைக்கவும்.
  • Model identifiers-களை ஒருங்கிணைக்கவும் – routing-ல் பயன்படுத்தப்படும் model ID, உங்கள் cache table-ல் சேமிக்கப்பட்டுள்ள ID-யுடன் ஒத்துப்போவதை உறுதி செய்யவும்; ID-கள் பொருந்தவில்லை என்றால் cache தேடல் (lookup) தடுக்கப்படும்.

செலவு குறித்த பார்வை

தினமும் ஆயிரக்கணக்கான அழைப்புகளைச் செய்யும் ஒரு செயலிக்கு, uncached நிலையில் இருந்து cached நிலைக்கு மாறுவது மாதச் செலவை வியத்தகு முறையில் குறைக்கலாம்—அறிவிக்கப்பட்ட நிகழ்வில் இது தோராயமாக $1,890-லிருந்து $406-ஆகக் குறைந்தது. மிதமானப் பயன்பாடு (modest traffic) கொண்ட செயலிகள்கூட குறிப்பிடத்தக்கச் சேமிப்பைக் காண முடியும், மேலும் ஒரு பெரிய நிலையான prompt-ஐ மீண்டும் பயன்படுத்துவதால் கிடைக்கும் செயல்திறன் அதிகரிப்பு தாமதத்தைக் (latency) குறைக்க உதவும்.

மறுப்புப் புள்ளி

இருப்பினும், இந்தத் தோல்வி அமைதியாக நடப்பதால், நீங்கள் அதிகப்படியான கட்டணம் செலுத்தவில்லை என்பதை உறுதிப்படுத்த ஒரே வழி read count-ஐச் சரிபார்ப்பதுதான்—இதை பலர் கவனிக்கத் தவறிவிடுகிறார்கள்.

அடுத்து கவனிக்க வேண்டியவை

  • Metric dashboards – கோரிக்கை அளவோடு (request volume) சேர்த்து, cache-read tokens-களுக்கான ஒரு அளவீட்டையும் (gauge) சேர்க்கவும்.
  • Tool-ordering நிலைத்தன்மை – நீங்கள் மாறும் முறையில் உருவாக்கப்படும் (dynamically generated) tool பட்டியல்களைப் பயன்படுத்துகிறீர்கள் என்றால், அவற்றை prompt-ல் இணைப்பதற்கு முன் ஒரு குறிப்பிட்ட வரிசையில் (deterministically) வரிசைப்படுத்துவதைக் கருத்தில் கொள்ளவும்.

சுருக்கமாக: Claude-ன் prompt caching உங்கள் கோரிக்கையை அமைதியாகத் தவிர்க்கும்போது எந்தத் தவறுச் செய்தியையும் (error) காட்டுவதில்லை. Read tokens-களைப் பதிவு செய்வதன் மூலம் cache-ன் செயல்திறனைச் சரிபார்க்கவும், சரியான prefix நீளத்தை உறுதி செய்யவும், மற்றும் prompt-ன் தொடக்க byte-களை மாற்ற முடியாதபடி (immutable) வைத்திருக்கவும். அப்போதுதான் நீங்கள் எதிர்பார்க்கும் செலவு மற்றும் வேகப் பலன்களைப் பெற முடியும்.