പ്രോംപ്റ്റ് കാഷിംഗ് (prompt caching) ഓൺ ചെയ്തതുകൊണ്ട് എനിക്ക് ഒരു ലാഭവും ഉണ്ടായില്ല—സത്യത്തിൽ, എന്റെ OpenAI-API ഇൻവോയ്സ് ഏകദേശം കാൽഭാഗം കൂടി വർദ്ധിച്ചു. ഓരോ റിക്വസ്റ്റിനൊപ്പവും മാറിക്കൊണ്ടിരുന്ന ഒരു വരിയായിരുന്നു ഇതിന് കാരണം: സിസ്റ്റം പ്രോംപ്റ്റിൽ ഉൾപ്പെടുത്തിയ ഒരു ടൈംസ്റ്റാമ്പ് (timestamp).
ടോക്കൺ പ്രോസസ്സിംഗ് ചിലവ് കുറയ്ക്കുന്നതിനായി LLM പ്രൊവൈഡർമാർ ഡെവലപ്പർമാരെ പ്രോംപ്റ്റ് ഭാഗങ്ങൾ (prompt fragments) കാഷ് ചെയ്യാൻ അനുവദിക്കുന്നു. ഒരു കാഷ് റീഡ് (ഒരു “hit”) സാധാരണ നിരക്കിന്റെ പത്തിലൊന്ന് മാത്രമാണ് ചിലവാകുന്നത്, എന്നാൽ ഒരു കാഷ് റൈറ്റ് (ഒരു “miss”) സാധാരണ വിലയുടെ ഏകദേശം 1.25 മടങ്ങ് ചിലവ് വരുത്തുന്നു. ഒരു റൈറ്റ് നടക്കുകയും എന്നാൽ കാഷ് ചെയ്ത ഭാഗം ഒരിക്കലും റീഡ് ചെയ്യപ്പെടാതിരിക്കുകയും ചെയ്താൽ, ആ അധികമായ 25% ചാർജ് വെറുതെയാകും. ടൈംസ്റ്റാമ്പ് കാരണം പ്രോംപ്റ്റ് നിലവിലുള്ള ഒരു കാഷ് എൻട്രിയുമായും പൊരുത്തപ്പെടാതിരുന്നപ്പോൾ സംഭവിച്ചത് ഇതാണ്.
എന്തുകൊണ്ടാണ് കാഷിംഗ് തിരിച്ചടിയാകുന്നത്
കാഷ് ചെയ്ത ഭാഗത്തിന്റെ കൃത്യമായ ബൈറ്റ് ക്രമം (byte sequence) പൊരുത്തപ്പെടുന്നതിലൂടെയാണ് പ്രോംപ്റ്റ് കാഷിംഗ് പ്രവർത്തിക്കുന്നത്. പ്രൊവൈഡർ ഇൻപുട്ടിനെ ഹാഷ് (hash) ചെയ്യുന്നു; ഹാഷ് ഒരു സ്റ്റോർ ചെയ്ത എൻട്രിയുമായി പൊരുത്തപ്പെട്ടാൽ, സിസ്റ്റം മുൻപത്തെ കമ്പ്യൂട്ടേഷൻ വീണ്ടും ഉപയോഗിക്കുകയും കുറഞ്ഞ റീഡ് നിരക്ക് പ്രയോഗിക്കുകയും ചെയ്യുന്നു. ഏതെങ്കിലും തരത്തിലുള്ള മാറ്റം—ഒരു അക്ഷരം പോലും—പൊരുത്തക്കേടിന് കാരണമാവുകയും ഉയർന്ന റൈറ്റ് നിരക്കിൽ പുതിയൊരു കമ്പ്യൂട്ടേഷൻ നടത്താൻ നിർബന്ധമാക്കുകയും ചെയ്യുന്നു.
എന്റെ കാര്യത്തിൽ സിസ്റ്റം പ്രോംപ്റ്റ് തുടങ്ങുന്നത് ഇപ്രകാരമായിരുന്നു:
Current session started: 2026-07-14T09:41:07Z
ഓരോ API കോളിലും ടൈംസ്റ്റാമ്പ് മാറിക്കൊണ്ടിരുന്നതിനാൽ, റിക്വസ്റ്റിന്റെ ആദ്യത്തെ ഏതാനും ബൈറ്റുകൾ ഒരിക്കലും ഒരേപോലെയായിരുന്നില്ല. പ്രൊവൈഡർ ഓരോ കോളും ഒരു പുതിയ കാഷ് എൻട്രിയായി കണക്കാക്കുകയും, റൈറ്റ് പ്രീമിയം ഈടാക്കുകയും, ഒരിക്കലും ഒരു റീഡും രേഖപ്പെടുത്താതിരിക്കുകയും ചെയ്തു. ഇതിന്റെ ഫലമായി cache_read_input_tokens പൂജ്യമായി തുടർന്നപ്പോൾ cache_creation_input_tokens-ൽ നിരന്തരമായ വർദ്ധനവ് ഉണ്ടായി, ഇത് കാഷ് ഒരിക്കലും ഉപയോഗിക്കപ്പെടുന്നില്ല എന്നതിന്റെ വ്യക്തമായ സൂചനയാണ്.
തകരാറിലായ ഒരു കാഷ് എങ്ങനെ തിരിച്ചറിയാം
API നൽകുന്ന യൂസേജ് ലോഗുകൾ രണ്ട് പ്രധാന കൗണ്ടറുകൾ നൽകുന്നു:
- cache_creation_input_tokens – ഒരു റൈറ്റിന് കാരണമായ ടോക്കണുകൾ.
- cache_read_input_tokens – ഒരു റീഡിലൂടെ ലാഭമുണ്ടാക്കിയ ടോക്കണുകൾ.
ആദ്യത്തേത് വർദ്ധിക്കുകയും രണ്ടാമത്തേത് മാറ്റമില്ലാതെ തുടരുകയും ചെയ്യുമ്പോൾ, കാഷ് വീണ്ടും ഉപയോഗിക്കപ്പെടുന്നില്ല എന്ന് മനസ്സിലാക്കാം. ഇത് പരിശോധിക്കാൻ ഒരേ റിക്വസ്റ്റ് തന്നെ രണ്ടുതവണ ആവർത്തിച്ചു നോക്കുക; കാഷ് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ രണ്ടാമത്തെ കോളിൽ റീഡ് ടോക്കണുകളിൽ വർദ്ധനവ് കാണിക്കണം.
പ്രശ്നം പരിഹരിക്കാൻ
പരിഹാരം ലളിതമാണ്: കാഷ് ചെയ്യുന്ന ഭാഗം കോളുകൾക്കിടയിൽ സ്ഥിരമാണെന്ന് (static) ഉറപ്പാക്കുക. ഈ രണ്ട് നിയമങ്ങൾ പാലിക്കുക:
- മാറ്റമില്ലാത്ത ഉള്ളടക്കം ആദ്യം നൽകുക. സിസ്റ്റം പ്രോംപ്റ്റുകൾ, ടൂൾ ഡെഫനിഷനുകൾ, അല്ലെങ്കിൽ ഒരിക്കലും മാറാത്ത ഏതെങ്കിലും നിർദ്ദേശങ്ങൾ എന്നിവ റിക്വസ്റ്റിന്റെ തുടക്കത്തിലുള്ള ബൈറ്റുകളിൽ വരണം.
- മാറിക്കൊണ്ടിരിക്കുന്ന ഉള്ളടക്കം അവസാനം ചേർക്കുക. ടൈംസ്റ്റാമ്പുകൾ, ഉപയോക്താവ് നൽകുന്ന ടെക്സ്റ്റ്, റിക്വസ്റ്റ് ഐഡികൾ, അല്ലെങ്കിൽ ഓരോ കോളിലും മാറുന്ന ഏതെങ്കിലും ഡാറ്റ എന്നിവ കാഷ് ചെയ്ത ഭാഗത്തിന് ശേഷം വരണം.
ഒരു അക്ഷരം മാറിയാൽ പോലും ഹാഷ് മാറുകയും കാഷ് മിസ്സ് (cache miss) തുടരുകയും ചെയ്യും. ടൈംസ്റ്റാമ്പ് അവസാനം വരുന്ന രീതിയിൽ പ്രോംപ്റ്റ് പുനഃക്രമീകരിക്കുന്നത് കാഷ് ഹിറ്റ് നിരക്ക് വീണ്ടെടുക്കാനും ബില്ല് പ്രതീക്ഷിച്ച കുറഞ്ഞ നിരക്കിലേക്ക് എത്തിക്കാനും സഹായിക്കും.
കാഷിംഗ് എപ്പോഴാണ് യഥാർത്ഥത്തിൽ സഹായിക്കുന്നത്
ഒരേ ഇൻസ്ട്രക്ഷൻ സെറ്റ് പലതവണ ഉപയോഗിക്കുന്ന സാഹചര്യങ്ങളിൽ പ്രോംപ്റ്റ് കാഷിംഗ് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു:
- ഒരു AI സ്ഥിരമായ ടൂളുകളുടെ ഒരു കൂട്ടത്തിലേക്ക് ആവർത്തിച്ച് വിളിക്കുന്ന Agent loops.
- ഉപയോക്താവിന്റെ ഏറ്റവും പുതിയ ചോദ്യം മാത്രം മാറുകയും, ബാക്കി ഒരു നീളമുള്ള, സ്ഥിരമായ ഡോക്യുമെന്റിനെ റഫർ ചെയ്യുകയും ചെയ്യുന്ന Chat sessions.
- ഒരേ പാഴ്സിംഗ് പ്രോംപ്റ്റ് നിരവധി റെക്കോർഡുകൾക്കായി ഉപയോഗിക്കുന്ന Bulk data extraction.
ഓരോ തവണയും പുതിയൊരു കോൺടെക്സ്റ്റ് ഉൾപ്പെടുന്ന സിംഗിൾ-ഷോട്ട് കോളുകൾക്ക് (ഉദാഹരണത്തിന്, ഒരു പ്രത്യേക പ്രീയാംബിളോട് കൂടിയ ഒറ്റപ്പെട്ട ചോദ്യം) കാഷിംഗ് കൊണ്ട് ഗുണമില്ല, മറിച്ച് റിക്വസ്റ്റ് അവിചാരിതമായി ഒരു റൈറ്റിന് കാരണമായാൽ ചിലവ് കൂടാൻ പോലും സാധ്യതയുണ്ട്.
ഒളിഞ്ഞിരിക്കുന്ന അപകടങ്ങൾ
പ്രോംപ്റ്റ് തന്നെ സ്ഥിരമാണെങ്കിൽ പോലും, റിക്വസ്റ്റിൽ താഴെ പറയുന്ന മാറ്റങ്ങൾ സംഭവിക്കാം:
- ക്രമം മാറ്റുകയോ വൈറ്റ് സ്പേസ് (whitespace) ചേർക്കുകയോ ചെയ്യുന്ന Proxies അല്ലെങ്കിൽ aggregators ബൈറ്റ്-ടു-ബൈറ്റ് പൊരുത്തക്കേടിന് കാരണമായേക്കാം.
- ഓതന്റിക്കേഷൻ ഹെഡറുകൾ ചേർക്കുകയോ JSON ഫോർമാറ്റിംഗ് മാറ്റുകയോ ചെയ്യുന്ന Gateway services അവിചാരിതമായി കാഷ് ചെയ്ത ഭാഗം മാറ്റിയേക്കാം.
ഒരേ റിക്വസ്റ്റ് തന്നെ രണ്ടുതവണ അയച്ചുകൊണ്ട് ഗേറ്റ്വേയിലൂടെ ടെസ്റ്റ് ചെയ്യുകയും റീഡ് കൗണ്ടറുകൾ പരിശോധിക്കുകയും ചെയ്യുന്നത് കാഷിംഗ് പാത്ത് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ സഹായിക്കും.
ചിലവിന്റെ വിപുലമായ ചിത്രം
റൈറ്റുകൾക്ക് മേലുള്ള 25% സർചാർജ് കാഷിംഗ് ഉപയോഗിക്കുന്നതിനുള്ള പിഴയല്ല; ഭാവിയിലെ ഉപയോഗത്തിനായി ആ ഭാഗം സംഭരിച്ചു വെക്കാൻ ആവശ്യമായ അധിക കമ്പ്യൂട്ടിംഗിനെയാണ് അത് സൂചിപ്പിക്കുന്നത്. ഒരു കാഷ് ഹിറ്റ് സംഭവിക്കുമ്പോൾ, ചിലവ് ഗണ്യമായി കുറയുന്നു—പലപ്പോഴും സാധാരണ നിരക്കിന്റെ ഒരു ചെറിയ ഭാഗം മാത്രം. സിസ്റ്റം കാഷ് ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക എന്നതാണ് പ്രധാനം. അല്ലെങ്കിൽ, യാതൊരു ലാഭവുമില്ലാതെ നിങ്ങൾ പ്രീമിയം തുക നൽകേണ്ടി വരും.
എതിർവാദം: കാഷിംഗ് മരിച്ചിട്ടില്ല
സ്റ്റാറ്റിക് വേഴ്സസ് ഡൈനാമിക് പ്രോംപ്റ്റ് ഭാഗങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിലെ സങ്കീർണ്ണത ലാഭത്തേക്കാൾ കൂടുതലാണെന്ന് ചില ഡെവലപ്പർമാർ വാദിക്കുന്നു. എന്നാൽ പല പ്രൊഡക്ഷൻ പൈപ്പ്ലൈനുകളും കോൺഫിഗറേഷനെ (static) യൂസർ ഡാറ്റയിൽ (dynamic) നിന്ന് ഇതിനകം തന്നെ വേർതിരിച്ചിട്ടുണ്ട് എന്ന വസ്തുത ആ കാഴ്ചപ്പാട് അവഗണിക്കുന്നു. പ്രോംപ്റ്റുകൾ അതിനനുസരിച്ച് ക്രമീകരിക്കുന്നതിലൂടെ, API-യുടെ യഥാർത്ഥ ഡെവലപ്പർമാർക്ക് പ്രയോജനപ്പെട്ട അതേ കാഷിംഗ് മെക്കാനിസം (caching mechanism) അധിക പരിശ്രമമില്ലാതെ തന്നെ ഉപയോഗപ്പെടുത്താൻ കഴിയും. ഇതിനുള്ള പകരമായി വേണ്ടത് പ്രോംപ്റ്റ് ഡിസൈനിൽ ചെറിയൊരു അച്ചടക്കം പാലിക്കുക എന്നത് മാത്രമാണ്, സാങ്കേതികവിദ്യയിലെ അടിസ്ഥാനപരമായ ഒരു പോരായ്മയല്ല ഇത്.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ടവ
- നിങ്ങളുടെ ഉപയോഗ ഡാഷ്ബോർഡിലെ രണ്ട് കാഷ് കൗണ്ടറുകളും (cache counters) ആഴ്ചതോറും നിരീക്ഷിക്കുക.
- വേരിയബിൾ ഘടകങ്ങൾ കാഷ് ചെയ്ത ബ്ലോക്കിന് ശേഷം ആണെന്ന് ഉറപ്പാക്കാൻ പ്രോംപ്റ്റ് നിർമ്മാണം ഓഡിറ്റ് ചെയ്യുക.
- യഥാർത്ഥ ലാഭം എത്രയാണെന്ന് കണക്കാക്കാൻ, കാഷിംഗോട് കൂടിയും കാഷിംഗ് ഇല്ലാത്തതുമായ രീതിയിൽ ഒരു റെപ്രസെന്റേറ്റീവ് വർക്ക്ലോഡിൽ A/B ടെസ്റ്റുകൾ നടത്തുക.
- ഏതെങ്കിലും പ്രോക്സിക്ക് മുമ്പും ശേഷവുമുള്ള റോ റിക്വസ്റ്റ് പേലോഡുകൾ താരതമ്യം ചെയ്തുകൊണ്ട് ഗേറ്റ്വേ പരിശോധിക്കുക.
ചുരുക്കം
പ്രോംപ്റ്റ് കാഷിംഗിലൂടെ LLM API ചിലവുകൾ ഗണ്യമായി കുറയ്ക്കാൻ കഴിയും, എന്നാൽ കാഷ് ചെയ്ത ഭാഗം എല്ലാ കോളുകളിലും (calls) ഒന്നുതന്നെയാണെങ്കിൽ മാത്രമേ ഇത് സാധ്യമാകൂ. പ്രോംപ്റ്റിന്റെ തുടക്കത്തിൽ വരുന്ന ഒരു ടൈംസ്റ്റാമ്പോ മറ്റ് ഡൈനാമിക് ടോക്കണുകളോ ഉണ്ടെങ്കിൽ, ഓരോ തവണയും പുതിയ ഡാറ്റ എഴുതേണ്ടി വരുന്നതിനാൽ ബില്ല് വർദ്ധിക്കും. സ്റ്റാറ്റിക് നിർദ്ദേശങ്ങൾ മുൻപിലും മാറിക്കൊണ്ടിരിക്കുന്ന ഡാറ്റ അവസാനം നൽകുന്നതിലൂടെ, കാഷിംഗിന് അതിന്റെ ജോലി കൃത്യമായി ചെയ്യാൻ സാധിക്കുകയും നിങ്ങളുടെ ചിലവുകൾ നിയന്ത്രിക്കാൻ കഴിയുകയും ചെയ്യും.