Prompt caching-ஐ ஆன் செய்ததால் எனக்கு எந்தப் பயனும் இல்லை—உண்மையில், எனது OpenAI-API விலைப்பட்டியல் (invoice) சுமார் கால் பகுதி அதிகரித்தது. ஒவ்வொரு கோரிக்கையிலும் (request) மாறும் ஒரு வரிதான் இதற்குத் தகுதியான காரணம்: சிஸ்டம் பிராம்ப்ட்டில் (system prompt) இணைக்கப்பட்டிருந்த ஒரு நேர முத்திரை (timestamp).

டோக்கன் செயலாக்கச் செலவைக் (token-processing costs) குறைக்க LLM வழங்குநர்கள் டெவலப்பர்களை பிராம்ப்ட் துண்டுகளை (prompt fragments) கேச் (cache) செய்ய அனுமதிக்கிறார்கள். ஒரு கேச் ரீட் (cache read - “hit”) வழக்கமான விலையில் பத்தில் ஒரு பங்கு மட்டுமே செலவாகும், ஆனால் ஒரு கேச் ரைட் (cache write - “miss”) வழக்கமான விலையை விட சுமார் 1.25 மடங்கு அதிகமாக இருக்கும். ஒரு ரைட் (write) நடந்தும், அந்த கேச் செய்யப்பட்ட துண்டு ஒருபோதும் ரீட் (read) செய்யப்படவில்லை என்றால், அந்த கூடுதல் 25% கட்டணம் வீணாகிறது. நேர முத்திரை (timestamp) காரணமாக, பிராம்ப்ட் ஏற்கனவே உள்ள எந்த கேச் பதிவோடு ஒத்துப்போகாதபோது சரியாக இதுதான் நடந்தது.

கேச்சிங் (caching) ஏன் எதிர்மறையாக மாறக்கூடும்

கேச்சிங் என்பது கேச் செய்யப்பட்ட பகுதியின் துல்லியமான (exact) பைட் வரிசையை (byte sequence) பொருத்துவதன் மூலம் செயல்படுகிறது. வழங்குநர் உள்ளீட்டை ஹாஷ் (hash) செய்கிறார்; அந்த ஹாஷ் சேமிக்கப்பட்ட பதிவோடு பொருந்தினால், சிஸ்டம் முந்தைய கணக்கீட்டை மீண்டும் பயன்படுத்துகிறது மற்றும் குறைந்த விலையிலான ரீட் ரேட்டை (read rate) பயன்படுத்துகிறது. ஏதேனும் ஒரு மாற்றம்—ஒரு ஒற்றை எழுத்து கூட—பொருத்தத்தை உடைத்துவிடும், இதனால் புதிய கணக்கீடு செய்யப்பட வேண்டியிருக்கும், இது அதிக விலையுள்ள ரைட் ரேட்டில் (write rate) வசூலிக்கப்படும்.

எனது விஷயத்தில், சிஸ்டம் பிராம்ப்ட் இதனுடன் தொடங்கியது:

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

ஒவ்வொரு API அழைப்பிற்கும் (call) நேர முத்திரை (timestamp) புதுப்பிக்கப்பட்டதால், கோரிக்கையின் முதல் சில பைட்ஸும் (bytes) ஒருபோதும் ஒரே மாதிரியாக இருக்கவில்லை. வழங்குநர் ஒவ்வொரு அழைப்பையும் ஒரு புதிய கேச் பதிவாகக் கருதி, ரைட் பிரீமியத்தை (write premium) வசூலித்தார், ஆனால் ஒரு ரீடையும் (read) பதிவு செய்யவில்லை. இதன் விளைவாக, cache_read_input_tokens பூஜ்ஜியமாக இருந்த நிலையில், cache_creation_input_tokens தொடர்ந்து அதிகரித்தது; இது கேச் ஒருபோதும் பயன்படுத்தப்படவில்லை என்பதற்கான தெளிவான அறிகுறியாகும்.

ஒரு பழுதான கேச்-ஐ எவ்வாறு கண்டறிவது

API வழங்கும் பயன்பாட்டுப் பதிவுகள் (usage logs) இரண்டு முக்கிய கவுண்டர்களைத் (counters) தருகின்றன:

  • cache_creation_input_tokens – ஒரு ரைட்டைத் (write) தூண்டிய டோக்கன்கள்.
  • cache_read_input_tokens – ரீட் (read) மூலம் பயனடைந்த டோக்கன்கள்.

முந்தையது அதிகரிக்கும் போது மற்றொன்று நிலையாக இருந்தால், கேச் மீண்டும் பயன்படுத்தப்படவில்லை என்று அர்த்தம். ஒரு விரைவான சரிபார்ப்பிற்கு (sanity check), அதே கோரிக்கையை இரண்டு முறை மீண்டும் செய்யவும்; கேச் சரியாகச் செயல்பட்டால், இரண்டாவது அழைப்பில் ரீட் டோக்கன்கள் (read tokens) அதிகரித்திருக்க வேண்டும்.

சிக்கலைச் சரிசெய்தல்

இதற்குத் தீர்வு எளிது: கோரிக்கைகள் முழுவதும் கேச் செய்யப்பட்ட பகுதி நிலையானதாக (static) இருப்பதை உறுதி செய்யவும். இந்த இரண்டு விதிகளையும் பின்பற்றவும்:

  1. மாற்ற முடியாத உள்ளடக்கத்தை முதலில் வைக்கவும் (Place immutable content first). சிஸ்டம் பிராம்ப்ட்கள், டூல் வரையறைகள் (tool definitions), அல்லது ஒருபோதும் மாறாத எந்தவொரு அறிவுறுத்தலும் கோரிக்கையின் ஆரம்ப பைட்ஸ்களில் (leading bytes) இருக்க வேண்டும்.
  2. மாறக்கூடிய உள்ளடக்கத்தை இறுதியில் சேர்க்கவும் (Append mutable content last). நேர முத்திரைகள் (timestamps), பயனர் உருவாக்கிய உரை, கோரிக்கை ஐடிகள் (request IDs), அல்லது ஒவ்வொரு அழைப்பிற்கும் மாறுபடும் எந்தவொரு தரவும் கேச் செய்யப்பட்ட பகுதிக்கு அடுத்து வர வேண்டும்.

ஒரு எழுத்து மாறினாலும், ஹாஷ் மாறிவிடும் மற்றும் கேச் மிஸ் (cache miss) தொடரும். நேர முத்திரை இறுதியில் இருக்குமாறு பிராம்ப்ட்டை மறுசீரமைப்பதன் மூலம், கேச் ஹிட் ரேட் (cache hit rate) மீட்டெடுக்கப்பட்டு, கட்டணம் எதிர்பார்க்கப்பட்ட குறைந்த செலவு நிலைக்குக் கொண்டு வரப்படும்.

கேச்சிங் உண்மையில் எப்போது உதவும்

ஒரே அறிவுறுத்தல் தொகுப்பு பலமுறை பயன்படுத்தப்படும் சூழல்களில் பிராம்ப்ட் கேச்சிங் சிறப்பாகச் செயல்படும்:

  • ஏஜென்ட் லூப்கள் (Agent loops), இதில் ஒரு AI ஒரு குறிப்பிட்ட டூல் தொகுப்பைத் திரும்பத் திரும்ப அழைக்கும்.
  • சாட் செஷன்கள் (Chat sessions), இதில் பயனர் கேட்கும் சமீபத்திய கேள்வி மட்டும் மாறிக்கொண்டே இருக்கும், ஆனால் ஒரு நீண்ட, நிலையான ஆவணத்தை அது குறிப்பிடும்.
  • மொத்த தரவு பிரித்தெடுத்தல் (Bulk data extraction), இதில் ஒரே பார்சிங் பிராம்ப்ட் (parsing prompt) பல பதிவுகளுக்குப் பயன்படுத்தப்படும்.

ஒவ்வொரு முறையும் புதிய சூழலை உள்ளடக்கிய ஒற்றை-முறை அழைப்புகளுக்கு (single-shot calls)—உதாரணமாக, ஒரு தனித்துவமான முன்னுரையுடன் கூடிய ஒரு கேள்விக்கு—கேச்சிங் எந்தப் பயனும் தராது, மேலும் கோரிக்கை தற்செயலாக ஒரு ரைட்டைத் (write) தூண்டினால் கூடுதல் செலவையும் ஏற்படுத்தக்கூடும்.

மறைந்திருக்கும் சிக்கல்கள்

பிராம்ப்ட் நிலையானதாக இருந்தாலும் கூட, கோரிக்கை (request) அடுத்தடுத்த நிலைகளில் மாற்றப்படலாம்:

  • வரிசையை மாற்றியமைக்கும் அல்லது இடைவெளிகளை (whitespace)ச் சேர்க்கும் புராக்சிகள் அல்லது அக்ரிகேட்டர்கள் (Proxies or aggregators) பைட்-பைட் பொருத்தத்தை உடைக்கலாம்.
  • அங்கீகார ஹெடர்களை (authentication headers) முன்னால் சேர்க்கும் அல்லது JSON வடிவமைப்பை மாற்றும் கேட்வே சேவைகள் (Gateway services) தற்செயலாக கேச் செய்யப்பட்ட துண்டை மாற்றக்கூடும்.

கேட்வே மூலம் ஒரே மாதிரியான கோரிக்கையை இரண்டு முறை அனுப்பி, ரீட் கவுண்டர்களைச் (read counters) சரிபார்ப்பதன் மூலம், கேச்சிங் பாதை அப்படியே உள்ளதா என்பதை உறுதிப்படுத்த முடியும்.

விரிவான செலவுப் பார்வை

ரைட்களுக்கான (writes) 25% கூடுதல் கட்டணம் கேச்சிங் பயன்படுத்துவதற்கான அபராதம் அல்ல; இது எதிர்கால மறுபயன்பாட்டிற்காக அந்தத் துண்டைச் சேமிக்கத் தேவைப்படும் கூடுதல் கணக்கீட்டைக் (extra compute) குறிக்கிறது. ஒரு கேச் ஹிட் (cache hit) நிகழும்போது, செலவு வியக்கத்தக்க வகையில் குறைகிறது—பெரும்பாலும் வழக்கமான விலையில் ஒரு சிறு பகுதி மட்டுமே. சிஸ்டம் உண்மையில் கேச்-ஐப் பயன்படுத்துவதை உறுதி செய்வதே முக்கியம். இல்லையெனில், எந்தச் சேமிப்பும் இன்றி நீங்கள் கூடுதல் கட்டணத்தைச் செலுத்த வேண்டியிருக்கும்.

எதிர் வாதம்: கேச்சிங் என்பது அழிந்துவிடவில்லை

சில டெவலப்பர்கள் நிலையான (static) மற்றும் மாறும் (dynamic) பிராம்ப்ட் பகுதிகளை நிர்வகிப்பதன் சிக்கல், அதனால் கிடைக்கும் சேமிப்பை விட அதிகம் என்று வாதிடுகின்றனர். ஆனால், பல உற்பத்திப் பாதைகள் (production pipelines) ஏற்கனவே உள்ளமைவை (configuration - static) பயனர் தரவிலிருந்து (user data - dynamic) பிரித்து வைத்துள்ளன என்ற உண்மையை அந்தப் பார்வை கவனிக்கத் தவறிவிடுகிறது. அதற்கேற்ப பிராம்ப்ட்களை வடிவமைப்பதன் மூலம், API-இன் ஆரம்பகால டெவலப்பர்களுக்கு உதவிய அதே கேச்சிங் (caching) முறையை கூடுதல் முயற்சி இன்றி பயன்படுத்த முடியும். இதில் உள்ள சவால் என்பது பிராம்ப்ட் வடிவமைப்பில் ஒரு சிறிய ஒழுக்கத்தைப் பின்பற்றுவது மட்டுமே தவிர, தொழில்நுட்பத்தில் உள்ள அடிப்படை குறைபாடு அல்ல.

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

  • உங்கள் பயன்பாட்டு டேஷ்போர்டில் (usage dashboard) உள்ள இரண்டு கேச் கவுண்டர்களையும் (cache counters) வாராவாரம் கண்காணிக்கவும்.
  • எந்தவொரு மாறக்கூடிய உறுப்பும் (variable element) கேச் செய்யப்பட்ட பிளாக்கிற்குப் பிறகு இருப்பதை உறுதி செய்ய, பிராம்ப்ட் கட்டமைப்பைத் தணிக்கை (Audit) செய்யவும்.
  • உண்மையான சேமிப்பைக் கணக்கிட, ஒரு பிரதிநிதித்துவப் பணிச்சுமையைக் கொண்டு (representative workload), கேச்சிங் இருந்தால் மற்றும் இல்லையென்றால் என A/B சோதனைகளைச் செய்யவும்.
  • ஏதேனும் ப்ராக்ஸிக்கு (proxy) முன்னும் பின்னும் உள்ள மூல கோரிக்கை பேலோடுகளை (raw request payloads) ஒப்பிட்டுப் பார்த்து, கேட்வேயை (gateway) சரிபார்க்கவும்.

முக்கியக் கருத்து

பிராம்ப்ட் கேச்சிங் (Prompt caching) LLM API செலவுகளைக் குறைக்க உதவும், ஆனால் கேச் செய்யப்பட்ட பகுதி அழைப்புகளுக்கு இடையே (calls) உண்மையாகவே ஒரே மாதிரியாக இருந்தால் மட்டுமே இது சாத்தியம். பிராம்ப்ட்டின் தொடக்கத்தில் ஒரு தேதியுடன் கூடிய நேர முத்திரை (timestamp) அல்லது வேறு ஏதேனும் மாறும் டோக்கன் (dynamic token) இருந்தால், அது ஒவ்வொரு முறையும் அதிக செலவுமிக்க ஒரு 'ரைட்' (write) செயல்பாட்டைத் தூண்டி, பில்லை அதிகமாக்கும். நிலையான அறிவுறுத்தல்களை முன்னால் வைப்பதன் மூலமும், மாறும் தரவை இறுதியில் வைப்பதன் மூலமும், கேச் சரியாகச் செயல்பட வழிவகை செய்து உங்கள் செலவுகளைக் கட்டுப்பாட்டில் வைத்திருக்கலாம்.