પ્રોમ્પ્ટ કેશિંગ (prompt caching) ચાલુ કરવાથી મને કંઈ જ ફાયદો થયો નહીં—હકીકતમાં, મારું OpenAI-APIનું ઇનવોઇસ લગભગ ચોથા ભાગે વધી ગયું. આનું કારણ એક જ લાઇન હતી જે દરેક રિક્વેસ્ટ સાથે બદલાતી હતી: સિસ્ટમ પ્રોમ્પ્ટમાં સમાવિષ્ટ એક ટાઈમસ્ટેમ્પ (timestamp).
LLM પ્રોવાઈડર્સ ટોકન-પ્રોસેસિંગ ખર્ચ ઘટાડવા માટે ડેવલપર્સને પ્રોમ્પ્ટના ટુકડાઓ કેશ (cache) કરવાની સુવિધા આપે છે. કેશ રીડ (એક “hit”) નો ખર્ચ સામાન્ય દરના દસમા ભાગ જેટલો ઓછો હોય છે, જ્યારે કેશ રાઈટ (એક “miss”) નો ખર્ચ સામાન્ય કિંમતના આશરે 1.25 × જેટલો હોય છે. જો રાઈટ થાય પરંતુ કેશ થયેલ ટુકડો ક્યારેય રીડ ન થાય, તો વધારાનો 25% ચાર્જ વેડફાય છે. જ્યારે ટાઈમસ્ટેમ્પને કારણે પ્રોમ્પ્ટ કોઈપણ અસ્તિત્વ ધરાવતા કેશ એન્ટ્રી સાથે મેચ ન થઈ શક્યો, ત્યારે બરાબર આવું જ થયું.
કેશિંગ કેમ નુકસાનકારક બની શકે છે
પ્રોમ્પ્ટ કેશિંગ કેશ કરેલા ભાગના ચોક્કસ (exact) બાઇટ સિક્વન્સને મેચ કરીને કામ કરે છે. પ્રોવાઈડર ઇનપુટને હેશ (hash) કરે છે; જો હેશ સ્ટોર કરેલી એન્ટ્રી સાથે મેચ થાય છે, તો સિસ્ટમ અગાઉની ગણતરીનો ફરીથી ઉપયોગ કરે છે અને સસ્તો રીડ રેટ લાગુ કરે છે. કોઈપણ ફેરફાર—એક જ અક્ષર પણ—મેચ તોડી નાખે છે અને નવી ગણતરી કરવા માટે મજબૂર કરે છે, જેનો બિલ ઊંચા રાઈટ રેટ પર આવે છે.
મારા કિસ્સામાં સિસ્ટમ પ્રોમ્પ્ટ આ રીતે શરૂ થતો હતો:
Current session started: 2026-07-14T09:41:07Z
કારણ કે દરેક API કોલ માટે ટાઈમસ્ટેમ્પ અપડેટ થતો હતો, રિક્વેસ્ટના પ્રથમ થોડા બાઇટ્સ ક્યારેય સમાન નહોતા. પ્રોવાઈડરે દરેક કોલને નવી કેશ એન્ટ્રી તરીકે ગણ્યો, રાઈટ પ્રીમિયમ વસૂલ્યું, અને ક્યારેય રીડ રેકોર્ડ ન કર્યો. પરિણામે cache_creation_input_tokens માં સતત વધારો થયો જ્યારે cache_read_input_tokens શૂન્ય રહ્યો, જે સ્પષ્ટ સંકેત હતો કે કેશ ક્યારેય 'hit' થઈ રહ્યો ન હતો.
બ્રોકન કેશ (broken cache) ને કેવી રીતે ઓળખવું
API દ્વારા આપવામાં આવતા યુસેજ લોગ્સ બે મુખ્ય કાઉન્ટર્સ આપે છે:
- cache_creation_input_tokens – એ ટોકન્સ જેણે રાઈટ (write) ટ્રિગર કર્યું.
- cache_read_input_tokens – એ ટોકન્સ જેમને રીડ (read) નો લાભ મળ્યો.
જ્યારે પહેલું વધે અને બીજું સ્થિર રહે, ત્યારે કેશનો ફરીથી ઉપયોગ થઈ રહ્યો નથી. એક ઝડપી ચેક કરવા માટે, બરાબર એક જ રિક્વેસ્ટ બે વાર મોકલો; જો કેશ યોગ્ય રીતે કામ કરી રહ્યું હોય, તો બીજા કોલમાં રીડ ટોકન્સમાં વધારો દેખાવો જોઈએ.
સમસ્યાનું નિરાકરણ
નિરાકરણ સરળ છે: ખાતરી કરો કે કેશ કરેલો વિસ્તાર તમામ કોલ્સમાં સ્ટેટિક (static) હોય. આ બે નિયમોનું પાલન કરો:
- અપરિવર્તનીય (immutable) સામગ્રી પહેલા મૂકો. સિસ્ટમ પ્રોમ્પ્ટ્સ, ટૂલ ડેફિનેશન અથવા કોઈપણ સૂચના જે ક્યારેય બદલાતી નથી, તે રિક્વેસ્ટના શરૂઆતના બાઇટ્સમાં હોવી જોઈએ.
- પરિવર્તનશીલ (mutable) સામગ્રી છેલ્લે ઉમેરો. ટાઈમસ્ટેમ્પ, યુઝર દ્વારા જનરેટ કરેલ ટેક્સ્ટ, રિક્વેસ્ટ ID અથવા કોઈપણ ડેટા જે દરેક કોલ મુજબ બદલાય છે, તે કેશ કરેલા સેગમેન્ટ પછી આવવો જોઈએ.
જો એક પણ અક્ષર બદલાય, તો હેશ બદલાઈ જાય છે અને કેશ મિસ (cache miss) ચાલુ રહે છે. પ્રોમ્પ્ટને એવી રીતે ફરીથી ગોઠવવાથી કે ટાઈમસ્ટેમ્પ અંતમાં આવે, કેશ હિટ રેટ (cache hit rate) પાછો આવે છે અને બિલ અપેક્ષિત ઓછા ખર્ચના સ્તરે આવી જાય છે.
કેશિંગ ખરેખર ક્યારે મદદરૂપ થાય છે
પ્રોમ્પ્ટ કેશિંગ એવા કિસ્સાઓમાં શ્રેષ્ઠ કામ કરે છે જ્યાં એક જ ઇન્સ્ટ્રક્શન સેટનો વારંવાર ઉપયોગ કરવામાં આવે છે:
- એજન્ટ લૂપ્સ (Agent loops) જ્યાં AI વારંવાર ટૂલ્સના નિશ્ચિત સેટને કોલ કરે છે.
- ચેટ સેશન્સ (Chat sessions) જે લાંબા, સ્ટેટિક ડોક્યુમેન્ટનો સંદર્ભ આપે છે જ્યારે માત્ર યુઝરનો લેટેસ્ટ ક્વેરી બદલાય છે.
- બલ્ક ડેટા એક્સટ્રેક્શન (Bulk data extraction) જ્યાં ઘણા રેકોર્ડ્સ પર એક જ પાર્સિંગ પ્રોમ્પ્ટ લાગુ કરવામાં આવે છે.
સિંગલ-શોટ કોલ્સ માટે જેમાં દરેક વખતે નવો સંદર્ભ (context) સામેલ હોય—જેમ કે યુનિક પ્રીએમ્બલ સાથેનો વન-ઓફ પ્રશ્ન—કેશિંગથી કોઈ ફાયદો થતો નથી અને જો રિક્વેસ્ટ અજાણતા રાઈટ ટ્રિગર કરે તો ખર્ચ પણ વધી શકે છે.
છુપાયેલા જોખમો
જો પ્રોમ્પ્ટ પોતે સ્ટેટિક હોય તો પણ, રિક્વેસ્ટમાં નીચે મુજબના ફેરફારો થઈ શકે છે:
- પ્રોક્સી અથવા એગ્રીગેટર્સ (Proxies or aggregators) જે ક્રમ બદલે છે અથવા વ્હાઇટસ્પેસ ઉમેરે છે, તે બાઇટ-ફોર-બાઇટ મેચ તોડી શકે છે.
- ગેટવે સર્વિસીસ (Gateway services) જે ઓથેન્ટિકેશન હેડર્સ ઉમેરે છે અથવા JSON ફોર્મેટિંગમાં ફેરફાર કરે છે, તે અજાણતા કેશ કરેલા ટુકડાને બદલી શકે છે.
સમાન રિક્વેસ્ટ બે વાર મોકલીને અને રીડ કાઉન્ટર્સ તપાસીને ગેટવે દ્વારા ટેસ્ટિંગ કરવાથી એની ખાતરી કરી શકાય છે કે કેશિંગ પાથ અકબંધ છે.
ખર્ચનું વ્યાપક ચિત્ર
રાઈટ પરનો 25% સરચાર્જ એ કેશિંગનો ઉપયોગ કરવા માટેનો દંડ નથી; તે ભવિષ્યમાં ફરીથી ઉપયોગ કરવા માટે ટુકડાને સ્ટોર કરવા માટે જરૂરી વધારાના કમ્પ્યુટિંગને દર્શાવે છે. જ્યારે કેશ હિટ થાય છે, ત્યારે ખર્ચમાં મોટો ઘટાડો થાય છે—અવારનવાર સામાન્ય દરના માત્ર એક ભાગ જેટલો. મુખ્ય વાત એ છે કે સિસ્ટમને ખરેખર કેશ હિટ કરવા દેવી જોઈએ. અન્યથા, તમે કોઈપણ બચત વગર પ્રીમિયમ ચૂકવો છો.
વિરોધી દલીલ: કેશિંગ મરી ગયું નથી
કેટલાક ડેવલપર્સ દલીલ કરે છે કે સ્ટેટિક વિરુદ્ધ ડાયનેમિક પ્રોમ્પ્ટ ભાગોનું સંચાલન કરવાની જટિલતા બચત કરતા વધુ છે. તે દૃષ્ટિકોણ એ હકીકતને અવગણે છે કે ઘણા પ્રોડક્શન પાઈપલાઈન્સ પહેલેથી જ કોન્ફિગરેશન (સ્ટેટિક) ને યુઝર ડેટા (ડાયનેમિક) થી અલગ કરે છે. પ્રોમ્પ્ટ્સને તે મુજબ સ્ટ્રક્ચર કરીને, એ જ કેશિંગ મિકેનિઝમનો ઉપયોગ વધારાના પ્રયત્નો વિના કરી શકાય છે જેણે API ના મૂળ ડેવલપર્સને બચત કરાવી હતી. આમાં ટ્રેડ-ઓફ પ્રોમ્પ્ટ ડિઝાઇનમાં થોડી શિસ્તનું પાલન કરવાનું છે, ટેકનોલોજીમાં કોઈ મૂળભૂત ખામી નથી.
આગળ શું ધ્યાન રાખવું
- તમારા વપરાશ ડેશબોર્ડમાં દર અઠવાડિયે બે કેશ કાઉન્ટર્સનું મોનિટરિંગ કરો.
- એ વાતની ખાતરી કરવા માટે પ્રોમ્પ્ટ કન્સ્ટ્રક્શનનું ઓડિટ કરો કે કોઈપણ વેરિયેબલ એલિમેન્ટ કેશ કરેલા બ્લોક પછી જ આવે છે.
- વાસ્તવિક બચતને માપવા માટે પ્રતિનિધિત્વ કરતા વર્કલોડ પર કેશિંગ સાથે અને કેશિંગ વગર A/B ટેસ્ટ ચલાવો.
- કોઈપણ પ્રોક્સી પહેલા અને પછીના રો (raw) રિક્વેસ્ટ પેલોડ્સની તુલના કરીને ગેટવેને વેલિડેટ કરો.
મુખ્ય વાત
પ્રોમ્પ્ટ કેશિંગ LLM API ખર્ચમાં મોટો ઘટાડો કરી શકે છે, પરંતુ તે ત્યારે જ શક્ય છે જો કેશ કરેલ સેગમેન્ટ દરેક કોલ દરમિયાન ખરેખર સમાન હોય. પ્રોમ્પ્ટની શરૂઆતમાં કોઈ વધારાનો ટાઈમસ્ટેમ્પ અથવા અન્ય કોઈ ડાયનેમિક ટોકન દરેક વખતે ખર્ચાળ રાઈટ (write) કરવા માટે મજબૂર કરે છે, જેનાથી બિલ વધી જાય છે. સ્ટેટિક સૂચનાઓને આગળ રાખવાથી (front-loading) અને બદલાતા ડેટાને છેલ્લે રાખવાથી, તમે કેશને તેનું કામ કરવા દો છો અને તમારા ખર્ચને નિયંત્રણમાં રાખો છો.