Claude Opus 5 ની નવી prompt-caching API ચેટ-શૈલીની એપ્સ માટે ટોકન બિલમાં મોટો ઘટાડો કરે છે, કારણ કે તે મોડેલને બદલાયા વગરના ટેક્સ્ટને ફરીથી વાંચવાનું ટાળવા દે છે. પ્રથમ રિક્વેસ્ટ માટે થોડો વધારાનો ખર્ચ ચૂકવવો પડે છે; પરંતુ ત્યારપછીની દરેક રિક્વેસ્ટ મૂળ દરના અંદાજે દસમા ભાગ જેટલી જ ખર્ચાળ હોય છે, જે વારંવાર થતા ખર્ચને એક વખતની ફીમાં ફેરવી દે છે.
ડેવલપર્સ શા માટે સમાન શબ્દો માટે બે વાર ચૂકવણી કરે છે
મોટાભાગના વાતચીત કરવા માટેના ઇન્ટરફેસ (conversational interfaces) દરેક વખતે આખો પ્રોમ્પ્ટ ફરીથી બનાવે છે: જ્યારે વપરાશકર્તા કોઈ ફોલો-અપ પ્રશ્ન પૂછે છે, ત્યારે 8,000-ટોકનનો સિસ્ટમ પ્રોમ્પ્ટ, જોડાયેલ PDF અને સંપૂર્ણ સંવાદનો ઇતિહાસ દર વખતે મોડેલ પાસે જાય છે. ટેક્સ્ટનો મોટો ભાગ ક્યારેય બદલાતો નથી હોવા છતાં, મોડેલ દરેક ટોકનને ફરીથી પ્રોસેસ કરે છે. વર્તમાન કિંમતો મુજબ, આ વધારાની પ્રક્રિયા એક વ્યસ્ત બોટના ખર્ચમાં મોટો હિસ્સો લઈ શકે છે.
કેશ (cache) કેવી રીતે ગણતરી બદલે છે
API દરેક ટોકન "બ્લોક" માટે, જે એક નિર્ધારિત બ્રેકપોઈન્ટ સુધી હોય, તેની માટે કેશ એન્ટ્રી બનાવે છે. જ્યારે આગામી રિક્વેસ્ટમાં આગળના ભાગમાં એ જ બ્લોક હોય છે, ત્યારે સર્વિસ તેને ફરીથી ટોકનાઇઝ કરવાને બદલે કેશમાંથી વાંચે છે. કિંમતમાં થયેલો વિભાજન બચાવેલ કામને પ્રતિબિંબિત કરે છે:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
વ્યવહારમાં, નવા બ્લોક માટેનું પ્રથમ કોલ સામાન્ય રિક્વેસ્ટ કરતા થોડું વધુ ખર્ચાળ હોય છે. કેશનો ઉપયોગ કરતી પછીની દરેક કોલ 90% સસ્તી હોય છે, તેથી જેમ જેમ વાતચીત આગળ વધે તેમ તેમ ચોખ્ખો ખર્ચ ઝડપથી ઘટે છે.
પ્રોમ્પ્ટ સ્ટ્રક્ચર કરવા માટેનો "ગોલ્ડન રૂલ"
કેશની અસરકારકતા તમે સ્ટેટિક (સ્થિર) વિરુદ્ધ ડાયનેમિક (ગતિશીલ) કન્ટેન્ટ ક્યાં મૂકો છો તેના પર નિર્ભર છે. જે વસ્તુઓ સમાન રહે છે તેને આગળ રાખો, અને જે સતત બદલાતી રહે છે તેને અંતમાં ધકેલી દો. એક વિશ્વસનીય ક્રમ આ મુજબ દેખાય છે:
- Tools – મોડેલ કૉલ કરી શકે તેવા કોઈપણ બાહ્ય ફંક્શન્સની વ્યાખ્યાઓ.
- System instructions – તમે મોડેલ પાસેથી અપેક્ષિત ઉચ્ચ-સ્તરીય વર્તન.
- Documents – લાંબા સંદર્ભો જેમ કે PDFs, નોલેજ બેઝ અથવા પોલિસીના અંશો.
- User questions – દરેક વખતે બદલાતી લાઈવ ક્વેરી.
જો તમે બ્રેકપોઈન્ટ પહેલા કોઈપણ ટોકનમાં ફેરફાર કરો છો, તો કેશ એન્ટ્રી અમાન્ય થઈ જાય છે અને મોડેલે ત્યારપછીની તમામ વિગતો ફરીથી પ્રોસેસ કરવી પડે છે.
છુપાયેલી મર્યાદાઓ જેનું તમારે પાલન કરવું જરૂરી છે
- લઘુત્તમ બ્લોક સાઈઝ – Opus 5 ફક્ત એવા જ બ્લોક્સ કેશ કરે છે જેમાં ઓછામાં ઓછા 512 ટોકન્સ હોય. તેનાથી નાની કોઈપણ વસ્તુ કેશમાંથી સંપૂર્ણપણે બહાર રહી જાય છે.
- Timestamp bug – કેશ કરેલા બ્લોકની અંદર બદલાતો ટાઈમસ્ટેમ્પ ઉમેરવાથી કેશ મિસ (miss) થવાની ખાતરી છે, કારણ કે બ્લોકનું ટેક્સ્ટ ક્યારેય બરાબર મેચ થતું નથી.
- 20-બ્લોક લુક-બેક – સર્વિસ મેચ માટે ફક્ત છેલ્લા 20 બ્લોક્સ જ સ્કેન કરે છે. લાંબા સમય સુધી ચાલતા સેશન્સ જે ઝડપથી આગળ વધે છે, તે કેશ વિન્ડોની બહાર નીકળી શકે છે.
- પેરેલલ રિક્વેસ્ટ્સ – એક જ સમયે સમાન રિક્વેસ્ટ્સ મોકલવાથી તે બધી જ કેશ મિસ થશે, કારણ કે પ્રથમ રિક્વેસ્ટ પૂર્ણ થયા પછી જ કેશ ભરાય છે. પહેલા એક સિંગલ કોલ દ્વારા કેશને 'વોર્મ' (warm) કરો, અને પછી બાકીની રિક્વેસ્ટ મોકલો.
તમારા API રિસ્પોન્સમાં બચત જુઓ
દરેક રિસ્પોન્સ ત્રણ ટોકન કાઉન્ટર્સ રિપોર્ટ કરે છે:
cache_read_input_tokens– કેશ હિટમાંથી આવેલા ટોકન્સ.cache_creation_input_tokens– આ રિક્વેસ્ટમાં કેશમાં લખાયેલા ટોકન્સ.input_tokens– નવા ટોકન્સ જે કેશ કરવામાં આવ્યા ન હતા.
તે તે ટર્ન માટે મોડેલે ધ્યાનમાં લીધેલા કુલ ટોકન્સ મેળવવા માટે ત્રણેય સંખ્યાઓનો સરવાળો કરો. જો બંને કેશ ફિલ્ડ્સ શૂન્ય હોય, તો રિક્વેસ્ટ કેશ ચૂકી ગઈ છે; તમારા બ્લોક સાઈઝ અને બ્રેકપોઈન્ટ પ્લેસમેન્ટ તપાસો.
મુખ્ય વાત (Takeaway): અપરિવર્તનીય સંદર્ભને આગળ રાખીને અને Claude Opus 5 ના prompt-caching API ને મુખ્ય કામ કરવા દેવાથી, તમે વારંવાર થતા ટોકન ખર્ચને એક વખતની ફીમાં ફેરવી શકો છો. પરિણામ એ છે કે કોઈપણ ચેટબોટ માટે ખર્ચમાં મોટો ઘટાડો થાય છે જે વારંવાર સમાન સિસ્ટમ પ્રોમ્પ્ટ અથવા ડોક્યુમેન્ટ સેટનો સંદર્ભ લે છે—જો તમે ટોકન ફ્લોરનું પાલન કરો, કેશ કરેલા બ્લોક્સની અંદર બદલાતા માર્કર્સ ટાળો, અને તમારા કેશ-લાયક કન્ટેન્ટને 20-બ્લોક હોરાઇઝનની અંદર રાખો.