ખર્ચ ઓપ્ટિમાઇઝેશન: પ્રોમ્પ્ટ કેશીંગ

નફો:

• પ્રોમ્પ્ટ કેશીંગના ઉપસર્ગ મેચિંગ તર્ક સમજાવો
• નિશ્ચિત સંદર્ભને પ્રથમ અને ચલ સંદર્ભ પછી મૂકીને કેશ હિટને વધારે છે
• કેશ રાઇટ/રીડ ઇકોનોમિક્સ અને બ્રેક-ઇવન પોઇન્ટની ગણતરી કરી શકે છે

એલએલએમ ઉત્પાદન પ્રોટોટાઇપમાં સસ્તું લાગે છે; જ્યારે તમે સ્કેલ પર જાઓ છો, ત્યારે બિલ આશ્ચર્યચકિત થાય છે. મોટાભાગના વર્કલોડ્સમાં, મોટાભાગના બિલ એ જ નિશ્ચિત સંદર્ભમાંથી આવે છે જે દરેક વિનંતી સાથે વારંવાર મોકલવામાં આવે છે: એક લાંબી સિસ્ટમ પ્રોમ્પ્ટ, એક નિયમપુસ્તક, સંદર્ભ દસ્તાવેજીકરણ. પ્રોમ્પ્ટ કેશીંગ બરાબર આ કચરાને દૂર કરે છે. આ એકમમાં, તમે શીખી શકશો કે કેશ કેવી રીતે કાર્ય કરે છે, હિટ કરવા માટે પ્રોમ્પ્ટ કેવી રીતે ગોઠવવી અને કેશ અર્થતંત્રના બ્રેક-ઇવન પોઈન્ટની ગણતરી કેવી રીતે કરવી. જ્યારે યોગ્ય રીતે ઇન્સ્ટોલ કરવામાં આવે, ત્યારે તે એકલા તમારા બિલને અડધો અથવા તેનાથી પણ ઓછું કરી શકે છે.

કેશ કેવી રીતે કામ કરે છે? એક અપરિવર્તનશીલ નિયમ

પ્રોમ્પ્ટ કેશીંગ એ ઉપસર્ગ મેચ છે. તમારા પ્રોમ્પ્ટની શરૂઆતથી પ્રદાતા અસ્થાયી રૂપે ટોકન્સને સંગ્રહિત કરે છે જે તેણે પ્રક્રિયા કરી છે. જો આગલી વિનંતી પર પ્રોમ્પ્ટ સમાન ઉપસર્ગ સાથે શરૂ થાય છે, તો આ સામાન્ય ભાગની પુનઃ ગણતરી કરવામાં આવશે નહીં; કેશ કરતાં વાંચવું ઘણું સસ્તું છે.

એક અપરિવર્તનશીલ નિયમ આનાથી અનુસરે છે: જો એક બાઈટ ઉપસર્ગમાં ગમે ત્યાં બદલાય છે, તો તે બિંદુથી સમગ્ર કેશ અમાન્ય બની જાય છે. એટલે કે, નિશ્ચિત સામગ્રી શરૂઆતમાં હોવી જોઈએ અને ચલ સામગ્રી અંતમાં હોવી જોઈએ. જો તમે સિસ્ટમ પ્રોમ્પ્ટની શરૂઆતમાં એક લીટી મુકો છો જે દરેક વિનંતી સાથે બદલાય છે, જેમ કે "આજની તારીખ: 18.07.2026", તેની પાછળની દરેક વસ્તુ કેશમાં દાખલ થઈ શકશે નહીં.

પ્રોસેસિંગ ઓર્ડર સામાન્ય રીતે છે: ટૂલ્સ → સિસ્ટમ પ્રોમ્પ્ટ → સંદેશાઓ. તમે નિશ્ચિત વિભાગના અંતે કેશ પોઈન્ટ (બ્રેકપોઈન્ટ) મુકો છો.

કેશ ઇકોનોમી

કેશમાં ત્રણ ભાવ સ્તરો છે:

• કેશ લખો: પ્રથમ વખત સ્ટોર કરી રહ્યું છે. ~1.25x સામાન્ય ઇનપુટ કિંમત (5 મિનિટ સ્ટોરેજ માટે).
• કેશ રીડ: અનુગામી વિનંતીઓ પર વાંચન. સામાન્ય ઇનપુટ કિંમત કરતાં ~0.1 ગણી — એટલે કે દસમા ભાગ.
• સામાન્ય ઇનપુટ: તે ભાગ જે કેશમાં દાખલ થતો નથી અને દરેક વખતે સંપૂર્ણ કિંમતે પ્રક્રિયા કરવામાં આવે છે.

બ્રેક-ઇવન પોઈન્ટ: પ્રથમ વિનંતી લખવાનું પ્રીમિયમ ચૂકવે છે (1.25×). બીજી વિનંતીથી, વાંચન (0.1×) અમલમાં આવે છે. આશરે, તમે બે વિનંતીઓ પર ગરદન અને ગરદન હશો; તે પછી, તે ચોખ્ખી બચત છે. નિયત સંદર્ભ જેટલો મોટો અને વધુ વિનંતીઓ તેનો પુનઃઉપયોગ થાય તેટલો મોટો ફાયદો થાય છે.

દૃશ્ય

કેશ કામ કરે છે?

મોટી નિશ્ચિત સિસ્ટમ પ્રોમ્પ્ટ, હજારો વિનંતીઓ

હા — સૌથી વધુ કમાણી

સમાન સંદર્ભ દસ્તાવેજો પર ઘણા પ્રશ્નો

હા

દરેક વિનંતી માટે સંપૂર્ણપણે અલગ ટૂંકું લખાણ

ના — લખવાનું બોનસ વ્યર્થ છે

એક વાર વિનંતી

ના - બિલકુલ વાંચન નથી

સિસ્ટમ પ્રોમ્પ્ટ પર દરેક વિનંતી સાથે તારીખ/આઈડી બદલાય છે

ના — ઉપસર્ગ તૂટી ગયો છે, હિટ શૂન્ય છે

સ્ટેપ બાય સ્ટેપ: હિટ પ્રોમ્પ્ટ કેવી રીતે સેટ કરવું?

1. સ્થિર અને ચલને અલગ કરો. કઈ સામગ્રી ક્યારેય બદલાતી નથી (સિસ્ટમ પ્રોમ્પ્ટ, રૂલબુક, દસ્તાવેજીકરણ)? દરેક વિનંતી (વપરાશકર્તા પ્રશ્ન, તારીખ, ID) સાથે કયો ફેરફાર થાય છે?
2. શરૂઆતમાં સતત મૂકો. પ્રક્રિયા દરમિયાન, જે ભાગ પ્રથમ આવે છે (ટૂલ્સ, સિસ્ટમ) સ્થિર હોવો જોઈએ.
3. અંતમાં ચલ મૂકો. વપરાશકર્તાનો વર્તમાન પ્રશ્ન, છેલ્લો.
4. સરહદના અંતમાં ચિહ્ન મૂકો. નિશ્ચિત ભાગના છેલ્લા બ્લોકમાં કેશ પોઇન્ટ મૂકો.
5. હિટ ચકાસો. પ્રતિસાદમાં ઉપયોગ ફીલ્ડમાં cache_read_input_tokens શૂન્ય કરતા વધારે છે કે કેમ તે તપાસો. જો શૂન્ય હોય, તો ઉપસર્ગમાં છુપાયેલ અવરોધક છે.

{ "સિસ્ટમ": [ { "પ્રકાર": "ટેક્સ્ટ", "ટેક્સ્ટ": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ક્ષણિક" } } ], "સંદેશા": [ { "ભૂમિકા": "વપરાશકર્તા", "સામગ્રી"{_current]}}"

ટિપ: કૅશ હિટ્સનું અનુમાન ન કરો, તેમને માપો. જો સતત વિનંતિઓ પર usage.cache_read_input_tokens હજુ પણ શૂન્ય છે, તો સિસ્ટમ પ્રોમ્પ્ટ પર સાયલન્ટ બ્રેકર (datetime.now(), અનઓર્ડર્ડ JSON, દરેક વિનંતી સાથે બદલાતા ટૂલ્સની સૂચિ) ચાલી રહી છે. બાઈટ બાય બાઈટ બે વિનંતીઓના કાચા પ્રોમ્પ્ટની તુલના કરો અને તફાવત શોધો.

સાયલન્ટ ડિસપ્ટર્સ

લાક્ષણિક પેટર્ન કે જે અજાણતા કેશને દૂષિત કરે છે:

# BREAKER: સિસ્ટમ પ્રોમ્પ્ટમાં માહિતી એમ્બેડ કરવી જે દરેક વિનંતી સાથે બદલાય છે "આજની તારીખ: {{હવે}}. તમે સહાયક છો..." ← દરેક વિનંતી સાથે ઉપસર્ગ બદલાય છે, હિટ શૂન્ય છે ..."}] ← અંતે ચલ

અન્ય બ્રેકર્સ: JSON દરેક વિનંતિ પર અલગ રીતે સૉર્ટ કરે છે (કીઓ નિશ્ચિત ક્રમમાં રાખો), વપરાશકર્તાઓ દ્વારા અલગ-અલગ સાધનોની સૂચિ (ટૂલ્સ પર પહેલા પ્રક્રિયા કરવામાં આવે છે; જો તેઓ બદલાય તો કેશમાં કંઈ જતું નથી), મૉડલને મધ્ય-વાતચીતમાં બદલવું (કેશ મોડલ વિશિષ્ટ છે).

નબળા પ્રોમ્પ્ટ / સ્ટ્રોંગ પ્રોમ્પ્ટ (કેશ મૈત્રીપૂર્ણ માળખું)

# નબળી (કેશ બસ્ટિંગ બિલ્ડ) સિસ્ટમ: "તારીખ: 18.07.2026 14:32. વપરાશકર્તા: અહમેટ (આઈડી 8842). તમે સપોર્ટ બોટ છો. નિયમો: ...(2000 ટોકન્સ)..."

# સ્ટ્રોંગ (કેશ-ફ્રેન્ડલી સ્ટ્રક્ચર) સિસ્ટમ: "તમે સપોર્ટ બોટ છો. નિયમો: ...(2000 ટોકન્સ, ક્યારેય બદલાતા નથી)..." [કેશ સાઇન] સંદેશાઓ: [ { ભૂમિકા: વપરાશકર્તા, સામગ્રી: "તારીખ: 18.07.2026 14:32. વપરાશકર્તા આઈડી: 8842. પ્રશ્ન: હું મારા રિફંડમાં કેવી રીતે રિફંડ કરું?" }]

નબળા સંસ્કરણમાં, 2000 ટોકન્સનો નિયમ બ્લોક દરેક વિનંતી પર સંપૂર્ણ કિંમતે પ્રક્રિયા કરવામાં આવે છે. મજબૂત સંસ્કરણમાં, સમાન બ્લોક એકવાર લખવામાં આવે છે અને કિંમતના દસમા ભાગ માટે અનુગામી તમામ વિનંતીઓ પર વાંચવામાં આવે છે.

ત્રણ મિની કેસ

કેસ 1 - રૂલબુક કેશીંગ. એકાઉન્ટિંગ ઓટોમેશન દરેક ઇન્વોઇસમાં 12,000 ટોકન રૂલબુક ઉમેરી રહ્યું હતું; દરરોજ 5,000 વિનંતીઓ. કેશલેસ ઇનપુટનો ખર્ચ પ્રતિ દિવસ ~$180 છે. તેઓએ રૂલબુકને સતત રાખ્યું અને તેને કેશ કર્યું: પ્રથમ વિનંતીઓએ લેખન પ્રીમિયમ ચૂકવ્યું, ત્યારબાદ 0.1× વાંચ્યું. ઇનપુટ ખર્ચ ~90% ઘટીને ~$18 પ્રતિ દિવસ થયો.

કેસ 2 - છુપાયેલ તારીખ રેખાની કિંમત. એક ટીમે એક કેશ સેટ કર્યો પરંતુ તેને કોઈ હિટ મળી ન હતી; cache_read_input_tokens હંમેશા શૂન્ય હતા. કારણ: સિસ્ટમ પ્રોમ્પ્ટની પ્રથમ લાઇનમાં datetime.now() હતું, દરેક વિનંતી સાથે ઉપસર્ગ બદલાતો હતો. જ્યારે અમે તારીખને વપરાશકર્તા સંદેશમાં ખસેડી, ત્યારે હિટ રેટ અચાનક 0% થી વધીને 94% થઈ ગયો.

કેસ 3 - ખોટો કેશ. શોધ એપ્લિકેશન દરેક વિનંતી સાથે સંપૂર્ણપણે અલગ ટૂંકી ક્વેરીઝ મોકલતી હતી; તેઓએ આતુરતાથી કેશ સાઇન ઉમેર્યું. કોઈ સામાન્ય ઉપસર્ગ વિના, દરેક વિનંતીએ માત્ર લખવાનું પ્રીમિયમ ચૂકવ્યું, કોઈ વાંચ્યું નહીં — ખર્ચમાં વધારો. તેઓએ ચિહ્ન દૂર કર્યું. પાઠ: કેશ ફક્ત ત્યારે જ ચૂકવે છે જો ત્યાં મોટો અને સતત ઉપસર્ગ હોય જેનો ફરીથી ઉપયોગ કરવામાં આવે.

સામાન્ય ભૂલો

• સતત અને ચલનું મિશ્રણ: જ્યારે ચલ સામગ્રી ઉપસર્ગમાં હોય, ત્યારે હિટ રીસેટ થાય છે.
• સિસ્ટમ પ્રોમ્પ્ટમાં તારીખ/ID એમ્બેડ કરવું: સૌથી સામાન્ય સાયલન્ટ ડિસપ્ટર.
• હિટને માપતા નથી: જો cache_read_input_tokens ચકાસાયેલ નથી, તો કચરો ધ્યાનમાં લેવામાં આવશે નહીં.
• જ્યારે કોઈ સાર્વજનિક ઉપસર્ગ ન હોય ત્યારે કેશ ઉમેરવાનું: તમે ફક્ત લખવાનું પ્રીમિયમ ચૂકવો છો, ખર્ચ વધે છે.
• વાહન સૂચિ અથવા મોડેલ બદલવું: ઉપસર્ગ શરૂઆતથી તૂટી ગયો છે; બધું ફરીથી લખવામાં આવે છે.
• ન્યૂનતમ કેશ કદ ભૂલી જવું: ખૂબ જ ટૂંકા કેશ (મોડેલ પર આધાર રાખીને ~1–4k ટોકન્સ હેઠળ) કેશમાં શાંતિપૂર્વક પ્રવેશ કરશે નહીં.

ડીપર: વર્કલોડના પ્રકાર દ્વારા કેશ ડિઝાઇન કરવી

કેશીંગનું વાસ્તવિક વળતર તમારા વર્કલોડની પ્રકૃતિને આધારે બદલાય છે; તેથી પહેલા તમારા ટ્રાફિકને જાણો. ત્રણ લાક્ષણિક પેટર્ન અને યોગ્ય ઇન્સ્ટોલેશન:

સામાન્ય સિસ્ટમ પ્રોમ્પ્ટ, વિવિધ પ્રશ્નો. સૌથી સામાન્ય એન્ટરપ્રાઇઝ પેટર્ન: સેંકડો વિવિધ વપરાશકર્તા પ્રશ્નો સાથે એક વિશાળ સિસ્ટમ પ્રોમ્પ્ટ (ભૂમિકા, નિયમો, કદાચ સંદર્ભ દસ્તાવેજ). અહીં નિશ્ચિત ભાગ (સિસ્ટમ) શરૂઆતમાં કેશ થયેલ છે; દરેક નવો પ્રશ્ન ફક્ત તેના પોતાના નાના ભાગ માટે સંપૂર્ણ કિંમત ચૂકવે છે. લાભ ઘણો ઊંચો છે કારણ કે મોટા ભાગની કિંમતના દસમા ભાગમાં વારંવાર પાઠ કરવામાં આવે છે.

મલ્ટી રાઉન્ડ મોનોલોગ. જેમ જેમ વાતચીત આગળ વધે છે તેમ, દરેક નવો રાઉન્ડ અગાઉના તમામ ઇતિહાસની ટોચ પર બને છે. જો તમે છેલ્લા રાઉન્ડના અંતે કેશ ફ્લેગ મૂકો છો, તો દરેક વિનંતી અગાઉના વાર્તાલાપ ઉપસર્ગનો ફરીથી ઉપયોગ કરે છે; વાતચીત વધે તેમ હિટ એકઠા થાય છે. આ નાટકીય રીતે લાંબા સહાયક સત્રોના ખર્ચ પર લગામ લગાવે છે.

વહેંચાયેલ ઉપસર્ગ એ બદલવા માટેનો છેલ્લો ભાગ છે. બહુવિધ વિનંતીઓ નિશ્ચિત પ્રાયોરનો મોટો સમૂહ (નમૂનો સમૂહ, સૂચનાઓ) શેર કરે છે પરંતુ અંતે એક પ્રશ્ન દ્વારા અલગ કરવામાં આવે છે. તમે વહેંચાયેલ ભાગના અંતે કેશ પોઇન્ટર મૂકો છો; નહિંતર, દરેક વિનંતી તેની પોતાની અલગ કેશ લખશે અને તેમાંથી કોઈ વાંચવામાં આવશે નહીં.

એક ચેતવણી: કેશ મોડેલ અને ચોક્કસ લઘુત્તમ કદ પર આધારિત છે. ખૂબ નાના ઉપસર્ગો (મોડેલ પર આધાર રાખીને, થોડા હજાર ટોકન્સ હેઠળ) તમે તેમને ફ્લેગ કરો તો પણ કેશમાં શાંતિપૂર્વક દાખલ થશે નહીં — cache_creation_input_tokens શૂન્ય રહે છે. ઉપરાંત, મૉડલને મધ્ય-વાતચીતમાં બદલવાથી સમગ્ર કૅશ અમાન્ય થઈ જાય છે; જો કોઈ અલગ કાર્ય માટે સસ્તા મોડેલની જરૂર હોય, તો મુખ્ય પ્રવાહને એક મોડેલમાં રાખો અને બાજુના કામને અલગ કૉલમાં મૂકો.

સારાંશમાં

પ્રોમ્પ્ટ કેશીંગ એ ઉપસર્ગ મેચ છે: નિશ્ચિત સામગ્રી શરૂઆતમાં હોવી જોઈએ, ચલ સામગ્રી અંતમાં હોવી જોઈએ. મોટા, પુનઃઉપયોગી સંદર્ભ માટે, વાંચવાની કિંમત સંપૂર્ણ કિંમતનો દસમો ભાગ છે, જે લગભગ બે વિનંતીઓમાં પણ તૂટી જાય છે. સિસ્ટમ પ્રોમ્પ્ટમાં વેરીએબલ ડેટાને એમ્બેડ કરીને ઉપસર્ગને બગાડવો એ સૌથી સામાન્ય ભૂલ છે; તમે ઉપયોગ ફીલ્ડમાં તેને માપીને હિટને ચકાસો છો.

એપ્લિકેશન કાર્ય

વર્કલોડ પસંદ કરો. (1) સામગ્રીને બે કૉલમમાં વિભાજીત કરો: "ક્યારેય બદલાતું નથી" અને "દરેક વિનંતી સાથે બદલાય છે". (2) પ્રોમ્પ્ટ સ્ટ્રક્ચરને ફરીથી દોરો, સતત ભાગને શરૂઆતમાં અને ચલ ભાગને અંતે મૂકો. (3) નિશ્ચિત ભાગના ટોકન કદનો અંદાજ કાઢો અને કેશ સાથે/વિના માસિક ખર્ચની તુલના કરો. (4) નોંધ કરો કે તમે કયા ફીલ્ડ (cache_read_input_tokens)માંથી હિટની ચકાસણી કરશો.

ચેકલિસ્ટ

• [ ] હું સમજાવી શકું છું કે કેશ ઉપસર્ગ મેચિંગ છે અને એકમાત્ર અપરિવર્તનશીલ નિયમ છે.
• [ ] હું નિશ્ચિત સામગ્રીને શરૂઆતમાં અને ચલને અંતે મૂકીને ચોકસાઈ વધારી શકું છું.
• [ ] મને અર્થશાસ્ત્ર લખવું/વાંચવું અને ટુ-રિક્વેસ્ટ બ્રેક-ઇવન પોઈન્ટ ખબર છે.
• [ ] હું સાયલન્ટ ડિસપ્ટર્સને ઓળખી શકું છું (તારીખ, બિનક્રમાંકિત JSON, વાહનની સૂચિમાં ફેરફાર).
• [ ] હું હિટને usage.cache_read_input_tokens વડે ચકાસી શકું છું.