कॉस्ट ऑप्टिमायझेशन: प्रॉम्प्ट कॅशिंग

नफा:

• प्रॉम्प्ट कॅशिंगचे उपसर्ग जुळणारे तर्क स्पष्ट करा
• फिक्स्ड कॉन्टेक्स्ट आधी आणि व्हेरिएबल कॉन्टेक्स्ट नंतर टाकून कॅशे हिट वाढवते
• कॅशे लेखन / वाचन अर्थशास्त्र आणि ब्रेक-इव्हन पॉइंटची गणना करू शकते

एलएलएम उत्पादन प्रोटोटाइपमध्ये स्वस्त दिसते; जेव्हा तुम्ही स्केलवर चढता तेव्हा बिल आश्चर्यचकित होते. बऱ्याच वर्कलोड्समध्ये, बहुतेक बिल समान निश्चित संदर्भातून येते जे प्रत्येक विनंतीसह पुन्हा पुन्हा पाठवले जाते: एक दीर्घ प्रणाली प्रॉम्प्ट, एक नियम पुस्तिका, संदर्भ दस्तऐवजीकरण. प्रॉम्प्ट कॅशिंग हा कचरा पूर्णपणे काढून टाकते. या युनिटमध्ये, तुम्ही कॅशे कसे कार्य करते, हिट करण्यासाठी प्रॉम्प्टची व्यवस्था कशी करावी आणि कॅशे इकॉनॉमीच्या ब्रेक-इव्हन पॉइंटची गणना कशी करावी हे शिकाल. योग्यरित्या स्थापित केल्यावर, ते एकटेच तुमचे बिल अर्धे किंवा त्याहून कमी करू शकते.

कॅशे कसे कार्य करते? एक अपरिवर्तनीय नियम

प्रॉम्प्ट कॅशिंग एक उपसर्ग जुळणी आहे. तुमच्या प्रॉम्प्टच्या सुरूवातीपासून प्रदात्ताने प्रक्रिया केलेले टोकन तात्पुरते साठवून ठेवतात. पुढील विनंतीवर प्रॉम्प्ट समान उपसर्गाने सुरू झाल्यास, या सामान्य भागाची पुनर्गणना केली जात नाही; कॅशेपेक्षा वाचणे खूप स्वस्त आहे.

यावरून एक अपरिवर्तनीय नियम येतो: जर एक बाइट उपसर्गामध्ये कुठेही बदलला, तर त्या बिंदूपासून संपूर्ण कॅशे अवैध होईल. म्हणजेच, निश्चित सामग्री सुरुवातीला असावी आणि परिवर्तनीय सामग्री शेवटी असावी. तुम्ही सिस्टम प्रॉम्प्टच्या सुरुवातीला एक ओळ टाकल्यास जी प्रत्येक विनंतीनुसार बदलते, जसे की "आजची तारीख: 18.07.2026", त्यामागील सर्व काही कॅशेमध्ये प्रवेश करू शकणार नाही.

प्रक्रिया क्रम सामान्यतः आहे: साधने → सिस्टम प्रॉम्प्ट → संदेश. तुम्ही निश्चित विभागाच्या शेवटी कॅशे पॉइंट (ब्रेकपॉइंट) ठेवता.

कॅशे इकॉनॉमी

कॅशेमध्ये तीन किंमतीचे स्तर आहेत:

• कॅशे लिहा: प्रथमच संचयित करत आहे. ~1.25x सामान्य इनपुट किंमत (5 मिनिटांच्या स्टोरेजसाठी).
• कॅशे वाचन: त्यानंतरच्या विनंत्यांवर वाचन. सामान्य इनपुट किंमतीच्या ~0.1 पट — म्हणजे, एक दशांश.
• सामान्य इनपुट: तो भाग जो कॅशेमध्ये प्रवेश करत नाही आणि प्रत्येक वेळी पूर्ण खर्चाने प्रक्रिया केली जाते.

ब्रेक-इव्हन पॉइंट: पहिली विनंती राइट प्रीमियम (1.25×) देते. दुसऱ्या विनंतीवरून, वाचन (0.1×) प्लेमध्ये येते. साधारणपणे, आपण दोन विनंत्यांवर मान आणि मान व्हाल; त्यानंतर, ती निव्वळ बचत आहे. निश्चित संदर्भ जितका मोठा असेल आणि जितक्या जास्त विनंत्या त्याचा पुन्हा वापर केला जाईल तितका मोठा फायदा होईल.

परिस्थिती

कॅशे कार्य करते का?

मोठा स्थिर प्रणाली प्रॉम्प्ट, हजारो विनंत्या

होय — सर्वोच्च कमाई

एकाच संदर्भ दस्तऐवजावर अनेक प्रश्न

होय

प्रत्येक विनंतीसाठी पूर्णपणे भिन्न लहान मजकूर

नाही — लिहिण्याचा बोनस वाया गेला

एक वेळ विनंती

नाही - अजिबात वाचन नाही

सिस्टम प्रॉम्प्टवर प्रत्येक विनंतीसह तारीख/आयडी बदलत आहे

नाही — उपसर्ग तुटलेला आहे, हिट शून्य आहे

स्टेप बाय स्टेप: हिट प्रॉम्प्ट कसा सेट करायचा?

1. स्थिर आणि चल वेगळे करा. कोणती सामग्री कधीही बदलत नाही (सिस्टम प्रॉम्प्ट, नियम पुस्तिका, दस्तऐवजीकरण)? प्रत्येक विनंतीसह कोणते बदल (वापरकर्ता प्रश्न, तारीख, आयडी)?
2. सुरवातीला स्थिरांक ठेवा. प्रक्रियेदरम्यान, प्रथम येणारा भाग (साधने, प्रणाली) स्थिर असणे आवश्यक आहे.
3. व्हेरिएबल शेवटी ठेवा. वापरकर्त्याचा वर्तमान प्रश्न, शेवटचा.
4. सीमेच्या शेवटी चिन्ह ठेवा. निश्चित भागाच्या शेवटच्या ब्लॉकमध्ये कॅशे पॉइंट ठेवा.
5. हिट सत्यापित करा. प्रतिसादातील वापर फील्डमध्ये कॅशे_रीड_इनपुट_टोकन्स शून्यापेक्षा जास्त आहेत का ते तपासा. शून्य असल्यास, उपसर्गामध्ये एक लपलेला व्यत्यय आहे.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "संदेश": [ { "भूमिका": "वापरकर्ता", "सामग्री" {current}}}

टीप: कॅशे हिट्सचा अंदाज लावू नका, त्यांचे मोजमाप करा. सलग विनंत्यांवर usage.cache_read_input_tokens अजूनही शून्य असल्यास, एक सायलेंट ब्रेकर (datetime.now(), सिस्टम प्रॉम्प्टवर, unordered JSON, प्रत्येक विनंतीनुसार बदलणाऱ्या टूल्सची सूची) चालू आहे. दोन रिक्वेस्टच्या रॉ प्रॉम्प्टची बाइट बाय बाइटची तुलना करा आणि फरक शोधा.

मूक व्यत्यय

नकळतपणे कॅशे दूषित करणारे ठराविक नमुने:

# ब्रेकर: सिस्टम प्रॉम्प्टमध्ये एम्बेडिंग माहिती जी प्रत्येक विनंतीनुसार बदलते "आजची तारीख: {{आता}}. तुम्ही सहाय्यक आहात..." ← प्रत्येक विनंतीसह उपसर्ग बदलतो, हिट शून्य आहे ..."}] ← शेवटी व्हेरिएबल

इतर ब्रेकर्स: 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 - चुकीचा कॅशे. शोध अनुप्रयोग प्रत्येक विनंतीसह पूर्णपणे भिन्न लहान क्वेरी पाठवत होता; त्यांनी उत्सुकतेने कॅशे चिन्ह जोडले. कोणतेही सामान्य उपसर्ग नसताना, प्रत्येक विनंतीने फक्त लेखन प्रीमियम दिलेला आहे, कोणतेही वाचन नाही — किंमत वाढते. त्यांनी चिन्ह काढले. धडा: पुन्हा वापरला जाणारा मोठा आणि स्थिर उपसर्ग असेल तरच कॅशे पैसे देते.

सामान्य चुका

• स्थिर आणि व्हेरिएबलचे मिश्रण: जेव्हा व्हेरिएबल सामग्री उपसर्गामध्ये असते, तेव्हा हिट रीसेट केला जातो.
• सिस्टम प्रॉम्प्टमध्ये एम्बेडिंग तारीख/आयडी: सर्वात सामान्य सायलेंट डिसप्टर.
• हिट मोजत नाही: कॅशे_रीड_इनपुट_टोकन्स तपासले नसल्यास, कचरा लक्षात येणार नाही.
• सार्वजनिक उपसर्ग नसताना कॅशे जोडणे: तुम्ही फक्त लेखन प्रीमियम भरता, खर्च वाढतो.
• वाहन यादी किंवा मॉडेल बदलणे: उपसर्ग सुरुवातीपासून तुटलेला आहे; सर्व काही पुन्हा लिहिले आहे.
• किमान कॅशे आकार विसरणे: खूप लहान कॅशे (मॉडेलवर अवलंबून ~1–4k टोकन अंतर्गत) कॅशेमध्ये शांतपणे प्रवेश करणार नाहीत.

सखोल: वर्कलोड प्रकारानुसार कॅशे डिझाइन करणे

कॅशिंगचा वास्तविक मोबदला तुमच्या वर्कलोडच्या स्वरूपावर अवलंबून असतो; त्यामुळे आधी तुमची रहदारी जाणून घ्या. तीन ठराविक नमुने आणि योग्य स्थापना:

सामान्य प्रणाली प्रॉम्प्ट, भिन्न प्रश्न. सर्वात सामान्य एंटरप्राइझ पॅटर्न: शेकडो भिन्न वापरकर्ता प्रश्नांसह एक मोठा सिस्टम प्रॉम्प्ट (भूमिका, नियम, कदाचित संदर्भ दस्तऐवज). येथे निश्चित भाग (सिस्टम) सुरुवातीला कॅश केला जातो; प्रत्येक नवीन प्रश्न फक्त त्याच्या स्वतःच्या छोट्या भागासाठी पूर्ण किंमत देतो. नफा खूप जास्त आहे कारण मोठा भाग किंमतीच्या दशांश दराने वारंवार पाठ केला जातो.

बहु-गोलाकार मोनोलॉग. संभाषण जसजसे पुढे जाईल तसतसे, प्रत्येक नवीन फेरी मागील सर्व इतिहासाच्या शीर्षस्थानी तयार होते. तुम्ही शेवटच्या फेरीच्या शेवटी कॅशे ध्वज लावल्यास, प्रत्येक विनंती मागील संभाषण उपसर्ग पुन्हा वापरते; संभाषण वाढत असताना हिट्स जमा होतात. दीर्घ सहाय्यक सत्रांच्या खर्चावर हे नाटकीयपणे लगाम घालते.

सामायिक उपसर्ग बदलण्यासाठी शेवटचा भाग आहे. एकाहून अधिक विनंत्या निश्चित अगोदरचा मोठा संच (नमुना संच, सूचना) सामायिक करतात परंतु शेवटी एका प्रश्नाने विभक्त केल्या जातात. तुम्ही शेअर केलेल्या भागाच्या शेवटी कॅशे पॉइंटर ठेवता; अन्यथा, प्रत्येक विनंतीची स्वतःची स्वतंत्र कॅशे लिहिली जाईल आणि त्यातील काहीही वाचले जाणार नाही.

एक चेतावणी: कॅशे मॉडेल आणि विशिष्ट किमान आकारावर अवलंबून असते. अगदी लहान उपसर्ग (मॉडेलवर अवलंबून काही हजार टोकन्स अंतर्गत) तुम्ही ध्वजांकित केले तरीही ते कॅशेमध्ये शांतपणे प्रवेश करणार नाहीत — cache_creation_input_tokens शून्य राहतील. तसेच, संभाषणाच्या मध्यभागी मॉडेल बदलल्याने संपूर्ण कॅशे अवैध होते; वेगळ्या कामासाठी स्वस्त मॉडेलची आवश्यकता असल्यास, मुख्य प्रवाह एका मॉडेलमध्ये ठेवा आणि बाजूला काम वेगळ्या कॉलमध्ये ठेवा.

सारांशात

प्रॉम्प्ट कॅशिंग एक उपसर्ग जुळणी आहे: निश्चित सामग्री सुरुवातीला असावी, चल सामग्री शेवटी असावी. मोठ्या, पुन्हा वापरल्या गेलेल्या संदर्भासाठी, वाचण्याची किंमत पूर्ण किमतीच्या दशांश आहे, साधारणपणे दोन विनंत्यांमध्येही खंडित होते. सिस्टम प्रॉम्प्टमध्ये व्हेरिएबल डेटा एम्बेड करून उपसर्ग दूषित करणे ही सर्वात सामान्य चूक आहे; तुम्ही वापर फील्डमध्ये मापन करून हिट सत्यापित करता.

अर्ज कार्य

वर्कलोड निवडा. (1) सामग्री दोन स्तंभांमध्ये विभाजित करा: "कधीही बदलत नाही" आणि "प्रत्येक विनंतीनुसार बदल". (२) प्रॉम्प्ट रचना पुन्हा काढा, स्थिर भाग सुरवातीला आणि चल भाग शेवटी ठेवा. (३) निश्चित भागाच्या टोकन आकाराचा अंदाज लावा आणि मासिक खर्चाची कॅशेसह/शिवाय तुलना करा. (4) कोणत्या फील्ड (cache_read_input_tokens) पासून तुम्ही हिटची पडताळणी कराल ते लक्षात घ्या.

चेकलिस्ट

• [ ] मी स्पष्ट करू शकतो की कॅशे हा उपसर्ग जुळणारा आणि एकमेव अपरिवर्तनीय नियम आहे.
• [ ] मी सुरवातीला निश्चित सामग्री आणि शेवटी व्हेरिएबल टाकून अचूकता वाढवू शकतो.
• [ ] मला अर्थशास्त्र लिहा/वाचणे आणि दोन-विनंती ब्रेक-इव्हन पॉइंट माहित आहेत.
• [ ] मी सायलेंट डिसप्टर्स ओळखू शकतो (तारीख, अक्रमित JSON, वाहनांची यादी बदलणे).
• [ ] मी usage.cache_read_input_tokens सह हिट सत्यापित करू शकतो.