लागत अनुकूलन: शीघ्र कैशिंग — एपीआई, लागत और एकीकरण

लाभ:

शीघ्र कैशिंग के उपसर्ग मिलान तर्क की व्याख्या करें
निश्चित संदर्भ को पहले और परिवर्तनीय संदर्भ को बाद में रखकर कैश हिट को बढ़ाता है
कैश लिखने/पढ़ने के अर्थशास्त्र और ब्रेक-ईवन पॉइंट की गणना कर सकते हैं

एलएलएम उत्पाद प्रोटोटाइप में सस्ता दिखता है; जब आप पैमाने पर कदम बढ़ाते हैं, तो बिल आश्चर्यचकित कर देता है। अधिकांश कार्यभार में, अधिकांश बिल एक ही निश्चित संदर्भ से आते हैं जो प्रत्येक अनुरोध के साथ बार-बार भेजे जाते हैं: एक लंबा सिस्टम प्रॉम्प्ट, एक नियम पुस्तिका, संदर्भ दस्तावेज़। त्वरित कैशिंग वास्तव में इस बर्बादी को समाप्त कर देती है। इस इकाई में, आप सीखेंगे कि कैश कैसे काम करता है, हिट करने के लिए संकेत की व्यवस्था कैसे करें, और कैश अर्थव्यवस्था के ब्रेक-ईवन बिंदु की गणना कैसे करें। सही ढंग से स्थापित होने पर, यह अकेले ही आपके बिल को आधा या उससे भी कम कर सकता है।

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

प्रॉम्प्ट कैशिंग एक उपसर्ग मिलान है. प्रदाता आपके प्रॉम्प्ट की शुरुआत से संसाधित किए गए टोकन को अस्थायी रूप से संग्रहीत करता है। यदि अगले अनुरोध पर संकेत उसी उपसर्ग के साथ शुरू होता है, तो यह सामान्य भाग पुनर्गणना नहीं किया जाता है; कैश की तुलना में इसे पढ़ना बहुत सस्ता है।

इससे एक अपरिवर्तनीय नियम का पालन होता है: यदि उपसर्ग में कहीं भी एक बाइट बदलता है, तो उस बिंदु से पूरा कैश अमान्य हो जाता है। अर्थात स्थिर सामग्री प्रारंभ में और परिवर्तनशील सामग्री अंत में होनी चाहिए। यदि आप सिस्टम प्रॉम्प्ट की शुरुआत में एक लाइन डालते हैं जो प्रत्येक अनुरोध के साथ बदलती है, जैसे "आज की तारीख: 18.07.2026", तो इसके पीछे की सभी चीजें कैश में प्रवेश नहीं कर पाएंगी।

प्रसंस्करण क्रम आमतौर पर है: उपकरण → सिस्टम प्रॉम्प्ट → संदेश। आप कैश पॉइंट (ब्रेकपॉइंट) को निश्चित सेक्शन के अंत में रखें।

कैश अर्थव्यवस्था

कैश के तीन मूल्य स्तर हैं:

कैश लिखना: पहली बार भंडारण करना। ~1.25x सामान्य इनपुट मूल्य (5 मिनट के भंडारण के लिए)।
कैश रीड: बाद के अनुरोधों पर पढ़ना। सामान्य इनपुट मूल्य का ~0.1 गुना - यानी दसवां हिस्सा।
सामान्य इनपुट: वह भाग जो कैश में प्रवेश नहीं करता है और हर बार पूरी लागत पर संसाधित होता है।

ब्रेक-ईवन पॉइंट: पहला अनुरोध राइट प्रीमियम (1.25×) का भुगतान करता है। दूसरे अनुरोध से, रीडिंग (0.1×) चलन में आती है। मोटे तौर पर, आप दो अनुरोधों पर आमने-सामने होंगे; उसके बाद, यह शुद्ध बचत है। निश्चित संदर्भ जितना बड़ा होगा और जितने अधिक अनुरोधों का पुन: उपयोग किया जाएगा, लाभ उतना ही बड़ा होगा।

परिदृश्य

क्या कैश काम करता है?

बड़ा निश्चित सिस्टम प्रॉम्प्ट, हजारों अनुरोध

हाँ - सबसे ज्यादा कमाई

एक ही संदर्भ दस्तावेज़ पर कई प्रश्न

हाँ

प्रत्येक अनुरोध के लिए पूरी तरह से अलग संक्षिप्त पाठ

नहीं - राइट बोनस बर्बाद हो गया है

एक बार अनुरोध

नहीं - बिल्कुल नहीं पढ़ना

सिस्टम प्रॉम्प्ट पर प्रत्येक अनुरोध के साथ दिनांक/आईडी बदल रही है

नहीं - उपसर्ग टूट गया है, हिट शून्य है

चरण दर चरण: हिट प्रॉम्प्ट कैसे सेट करें?

स्थिरांक और परिवर्तनशील को अलग करें. कौन सी सामग्री कभी नहीं बदलती (सिस्टम प्रॉम्प्ट, नियम पुस्तिका, दस्तावेज़ीकरण)? प्रत्येक अनुरोध (उपयोगकर्ता प्रश्न, दिनांक, आईडी) के साथ कौन सा परिवर्तन होता है?
प्रारंभ में स्थिरांक रखें. प्रसंस्करण के दौरान, जो भाग पहले आता है (उपकरण, सिस्टम) स्थिर होना चाहिए।
वेरिएबल को अंत में रखें। उपयोगकर्ता का वर्तमान प्रश्न, अंतिम।
चिन्ह को सीमा के अंत में रखें। कैश पॉइंट को निश्चित भाग के अंतिम ब्लॉक में रखें।
हिट सत्यापित करें. जांचें कि प्रतिक्रिया में उपयोग फ़ील्ड में कैश_रीड_इनपुट_टोकेंस शून्य से अधिक है या नहीं। यदि शून्य है, तो उपसर्ग में एक छिपा हुआ विघ्नकर्ता है।

{ "सिस्टम": [ { "प्रकार": "पाठ", "पाठ": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "प्रकार": "क्षणिक" } } ], "संदेश": [ { "भूमिका": "उपयोगकर्ता", "सामग्री": "{{user_current_question}}" } ]}

युक्ति: कैश हिट का अनुमान न लगाएं, उन्हें मापें। यदि लगातार अनुरोधों पर उपयोग.कैश_रीड_इनपुट_टोकेंस अभी भी शून्य है, तो एक साइलेंट ब्रेकर (सिस्टम प्रॉम्प्ट पर datetime.now(), अव्यवस्थित 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 - छिपी हुई तिथि रेखा की लागत। एक टीम ने कैश स्थापित किया लेकिन कोई हिट नहीं मिल रही थी; कैश_रीड_इनपुट_टोकन्स हमेशा शून्य था। कारण: सिस्टम प्रॉम्प्ट की पहली पंक्ति में datetime.now() था, प्रत्येक अनुरोध के साथ उपसर्ग बदल रहा था। जब हमने उपयोगकर्ता संदेश में तारीख स्थानांतरित की, तो हिट दर अचानक 0% से बढ़कर 94% हो गई।

केस 3 - ग़लत कैश। एक खोज एप्लिकेशन प्रत्येक अनुरोध के साथ पूरी तरह से अलग-अलग लघु प्रश्न भेज रहा था; उन्होंने उत्सुकता से एक कैश चिह्न जोड़ा। बिना किसी सामान्य उपसर्ग के, प्रत्येक अनुरोध के लिए केवल लिखित प्रीमियम का भुगतान किया जाता है, कोई रीड नहीं - जिससे लागत बढ़ जाती है। उन्होंने साइन हटा दिया. पाठ: कैश तभी भुगतान करता है जब कोई बड़ा और स्थिर उपसर्ग हो जिसका पुन: उपयोग किया जाता है।

सामान्य गलतियाँ

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

गहनता: कार्यभार प्रकार के अनुसार कैश डिजाइन करना

कैशिंग का वास्तविक भुगतान आपके कार्यभार की प्रकृति के आधार पर भिन्न होता है; इसलिए पहले अपना ट्रैफ़िक जान लें। तीन विशिष्ट पैटर्न और सही स्थापना:

सामान्य सिस्टम प्रॉम्प्ट, अलग-अलग प्रश्न। सबसे सामान्य एंटरप्राइज़ पैटर्न: सैकड़ों विभिन्न उपयोगकर्ता प्रश्नों के साथ एक बड़ा सिस्टम प्रॉम्प्ट (भूमिका, नियम, शायद संदर्भ दस्तावेज़)। यहां प्रारंभ में निश्चित भाग (सिस्टम) को कैश किया जाता है; प्रत्येक नया प्रश्न केवल अपने छोटे से हिस्से के लिए पूरी कीमत चुकाता है। लाभ बहुत अधिक है क्योंकि बड़े हिस्से को कीमत के दसवें हिस्से पर बार-बार सुनाया जाता है।

बहु-गोल एकालाप. जैसे-जैसे बातचीत आगे बढ़ती है, प्रत्येक नया दौर पिछले सभी इतिहास पर आधारित होता है। यदि आप अंतिम राउंड के अंत में कैश फ़्लैग लगाते हैं, तो प्रत्येक अनुरोध पिछले वार्तालाप उपसर्ग का पुन: उपयोग करता है; जैसे-जैसे बातचीत बढ़ती है, हिट्स बढ़ती जाती हैं। यह लंबे सहायक सत्रों की लागत पर नाटकीय रूप से लगाम लगाता है।

साझा उपसर्ग परिवर्तन के लिए अंतिम बिट है। एकाधिक अनुरोध निश्चित प्राथमिकताओं (नमूना सेट, निर्देश) का एक बड़ा सेट साझा करते हैं लेकिन अंत में एक ही प्रश्न से अलग हो जाते हैं। आप कैश पॉइंटर को साझा भाग के अंत में रखते हैं; अन्यथा, प्रत्येक अनुरोध अपना अलग कैश लिखेगा और इसमें से कुछ भी पढ़ा नहीं जाएगा।

एक चेतावनी: कैश मॉडल और एक निश्चित न्यूनतम आकार पर निर्भर करता है। बहुत छोटे उपसर्ग (मॉडल के आधार पर कुछ हजार टोकन के तहत) चुपचाप कैश में प्रवेश नहीं करेंगे, भले ही आप उन्हें चिह्नित करें - कैश_क्रिएशन_इनपुट_टोकन शून्य रहता है। साथ ही, बातचीत के बीच में मॉडल बदलने से संपूर्ण कैश अमान्य हो जाता है; यदि किसी भिन्न कार्य के लिए सस्ते मॉडल की आवश्यकता होती है, तो मुख्य प्रवाह को एक मॉडल में रखें और अतिरिक्त कार्य को एक अलग कॉल में रखें।

संक्षेप में

प्रॉम्प्ट कैशिंग एक उपसर्ग मिलान है: निश्चित सामग्री शुरुआत में होनी चाहिए, परिवर्तनीय सामग्री अंत में होनी चाहिए। एक बड़े, पुन: उपयोग किए गए संदर्भ के लिए, पढ़ने की लागत पूरी कीमत का दसवां हिस्सा है, जो मोटे तौर पर दो अनुरोधों में भी बराबर हो जाती है। सबसे आम गलती सिस्टम प्रॉम्प्ट में वेरिएबल डेटा एम्बेड करके उपसर्ग को दूषित करना है; आप हिट को उपयोग क्षेत्र में मापकर सत्यापित करते हैं।

आवेदन कार्य

कार्यभार चुनें. (1) सामग्री को दो स्तंभों में विभाजित करें: "कभी नहीं बदलता" और "प्रत्येक अनुरोध के साथ परिवर्तन"। (2) आरंभ में स्थिर भाग और अंत में परिवर्तनशील भाग रखते हुए, शीघ्र संरचना को फिर से बनाएं। (3) निश्चित भाग के टोकन आकार का अनुमान लगाएं और कैश के साथ/बिना मासिक लागत की तुलना करें। (4) ध्यान दें कि आप किस फ़ील्ड (cache_read_input_tokens) से हिट को सत्यापित करेंगे।

चेकलिस्ट

[ ] मैं समझा सकता हूं कि कैश उपसर्ग मिलान है और एकमात्र अपरिवर्तनीय नियम है।
[ ] मैं शुरुआत में निश्चित सामग्री और अंत में वेरिएबल डालकर सटीकता बढ़ा सकता हूं।
[ ] मैं अर्थशास्त्र और दो-अनुरोध ब्रेक-ईवन बिंदु लिखना/पढ़ना जानता हूं।
[ ] मैं मूक व्यवधानों (तिथि, अव्यवस्थित JSON, बदलती वाहन सूची) को पहचान सकता हूं।
[ ] मैं उपयोग.cache_read_input_tokens के साथ हिट को सत्यापित कर सकता हूं।