मुख्य कंटेंट तक स्किप करें
उन्नत

जैसे-जैसे Anthropic प्लेटफॉर्म को अपडेट करता है, कैश की कार्यप्रणाली, प्राइसिंग टियर, TTL अवधि, और न्यूनतम टोकन सीमाएँ बदलती हैं। किसी भी तीसरे-पक्ष की गाइड से किसी खास संख्या पर भरोसा न करें। मौजूदा मानों के लिए हमेशा आधिकारिक प्रॉम्प्ट कैशिंग दस्तावेज और मॉडल्स और प्राइसिंग पन्ने की जाँच करें।

प्रॉम्प्ट कैशिंग इकोनॉमिक्स

हर बार जब आप Claude API को कॉल करते हैं, तो आप अपने भेजे हर इनपुट टोकन के लिए भुगतान करते हैं — आपके सिस्टम प्रॉम्प्ट, आपकी टूल परिभाषाओं, और आपके इंजेक्ट किए किसी भी कॉन्टेक्स्ट समेत। अगर आप एक ही बड़े प्रीफिक्स के साथ कई कॉल कर रहे हैं, तो आप उस प्रीफिक्स को हर एक बार शुरू से प्रोसेस करने के लिए भुगतान कर रहे हैं।

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

बचत सजावटी नहीं है। बड़े, स्थिर सिस्टम प्रॉम्प्ट या भारी कॉन्टेक्स्ट वाले एप्लिकेशनों के लिए, कैशिंग किसी फीचर की इकोनॉमिक्स को "शिप करने के लिए बहुत महँगा" से "चलाने के लिए मूलतः मुफ्त" में बदल सकती है।

मानसिक मॉडल: स्थिर प्रीफिक्स, अस्थिर सफिक्स​

हर API कॉल को दो हिस्सों के रूप में सोचें:

स्थिर प्रीफिक्स — सामग्री जो कॉल्स के बीच नहीं बदलती। यहीं कैशिंग लागू होती है। उदाहरण:

  • आपका सिस्टम प्रॉम्प्ट
  • टूल परिभाषाएँ
  • एक बड़ा संदर्भ दस्तावेज या कोडबेस जिसे आप हर कॉल पर इंजेक्ट करते हैं
  • एक लंबा फ्यू-शॉट उदाहरण ब्लॉक

अस्थिर सफिक्स — सामग्री जो हर कॉल पर बदलती है। यहाँ कैशिंग लागू नहीं होती। उदाहरण:

  • मौजूदा यूजर संदेश
  • रियल-टाइम डेटा जिसे आप हर अनुरोध पर इंजेक्ट करते हैं
  • बातचीत का इतिहास जो हर टर्न के साथ बढ़ता है

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

अगर आप स्थैतिक सामग्री से पहले गतिशील सामग्री रखते हैं, तो आप कैश तोड़ देते हैं, क्योंकि प्रीफिक्स हर अनुरोध पर बदलता है।

लागत मॉडल कैसे काम करता है​

प्रॉम्प्ट कैशिंग इनपुट टोकनों की कीमत तय करने में एक तीन-तरफा बँटवारा लाती है:

टोकन प्रकारयह कब होता हैसामान्य इनपुट के सापेक्ष लागत
कैश राइटपहला कॉल, या कैश समाप्त होने के बादसामान्य इनपुट से ज्यादा
कैश रीडआगे के कॉल जो कैश से टकराते हैंसामान्य इनपुट से बहुत कम
नियमित इनपुटआखिरी कैश ब्रेकपॉइंट के बाद के टोकनसामान्य दर

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

लेटेंसी वही पैटर्न अपनाती है। कैश रीड कैश किए हिस्से की पूरी प्रोसेसिंग छोड़ देते हैं, जो बड़े प्रीफिक्स वाले कॉल्स पर टाइम-टू-फर्स्ट-टोकन को सार्थक रूप से घटाता है।

प्रॉम्प्ट कैशिंग कब मदद करती है​

कैशिंग तब फल देती है जब दो शर्तें दोनों सच हों:

  1. आपके पास एक पर्याप्त स्थिर प्रीफिक्स है (एक न्यूनतम टोकन सीमा है जिसके नीचे कैशिंग उपलब्ध नहीं है — मॉडल के अनुसार सटीक संख्या के लिए मौजूदा दस्तावेज जाँचें)।
  2. आप उस प्रीफिक्स का इतनी बार पुन: उपयोग करते हैं कि कभी-कभार से ज्यादा बार कैश से टकराते हैं।

ऐसे परिदृश्य जहाँ कैशिंग एक स्वाभाविक मेल है:

  • डॉक्यूमेंट Q&A — वही बड़ा दस्तावेज कई उपयोगकर्ता सवालों के लिए इंजेक्ट किया जाता है।
  • कोडिंग असिस्टेंट — हर अनुरोध में एक बड़ा कोडबेस या फाइल ट्री शामिल होता है।
  • एजेंटिक लूप — वही सिस्टम प्रॉम्प्ट और टूल परिभाषाएँ बहु-चरण वर्कफ्लो के हर कदम पर भेजी जाती हैं।
  • लंबे निर्देशों वाले संवादी एजेंट — एक विस्तृत परसोना, नियम-सेट, या नॉलेज बेस जो कॉल-दर-कॉल कभी नहीं बदलता।
  • बैच प्रोसेसिंग — कई इनपुट एक ही टेम्पलेट के विरुद्ध चलते हैं।

प्रॉम्प्ट कैशिंग कब मदद नहीं करती​

कैशिंग तब उपयोगी नहीं है जब:

  • आपके प्रॉम्प्ट छोटे हैं (न्यूनतम कैश करने योग्य टोकन सीमा से नीचे)।
  • आपका प्रीफिक्स हर कॉल पर बदलता है — एक टाइमस्टैम्प, एक उपयोगकर्ता-विशिष्ट कॉन्टेक्स्ट, या कोई भी निजीकरण "स्थिर" हिस्से में इंजेक्ट करना कैश को अमान्य कर देता है।
  • आप उनके बीच लंबे अंतरालों के साथ कभी-कभार कॉल करते हैं। कैश की गई सामग्री एक TTL के बाद समाप्त हो जाती है (एक अवधि जिसे आप कॉन्फ़िगर कर सकते हैं, उन सीमाओं के भीतर जिन्हें API समर्थन करता है)। अगर आपका ट्रैफिक विरल है, तो आप ज्यादातर कम रीड के साथ राइट लागत का भुगतान कर रहे होंगे।
  • आपका प्रीफिक्स प्रति-कॉल गतिशील सामग्री के सापेक्ष छोटा है। बचत उस चीज के आकार के साथ बढ़ती है जो कैश की गई है।

प्रॉम्प्ट को कैश-अनुकूल बनाने के लिए संरचित करना​

एकमात्र संरचनात्मक जरूरत क्रम है: स्थिर सामग्री अस्थिर सामग्री से पहले आनी चाहिए।

व्यवहार में:

[System prompt — instructions, persona, rules]
[Tool definitions — if static]
[Large injected documents or context — if the same across calls]
--------- cache breakpoint here ---------
[Dynamic per-call content — user message, retrieved chunks specific to this request]

आप जिस आखिरी ब्लॉक को कैश में शामिल करना चाहते हैं उस पर एक cache_control फील्ड से ब्रेकपॉइंट चिह्नित करते हैं। उस चिह्न से पहले की हर चीज कैशिंग के लिए योग्य है; उसके बाद की हर चीज नियमित इनपुट है।

आप एक ही अनुरोध में चार तक स्पष्ट ब्रेकपॉइंट रख सकते हैं। यह तब उपयोगी है जब आपके प्रॉम्प्ट के अलग-अलग हिस्से अलग-अलग बारंबारता पर बदलते हैं — उदाहरण के लिए, टूल परिभाषाएँ कभी-कभार बदलती हैं, बातचीत का इतिहास हर टर्न बदलता है। हर सेक्शन का अपना ब्रेकपॉइंट हो सकता है।

कैश अमान्यकरण के नियम​

कैश क्रम के प्रति संवेदनशील है। किसी कैश किए ब्लॉक में कोई भी बदलाव, या किसी ऐसे ब्लॉक में जो प्रॉम्प्ट में उससे पहले आता है, उस ब्रेकपॉइंट और उसके बाद के सभी ब्रेकपॉइंट्स पर कैश को अमान्य कर देता है।

टूल परिभाषाओं में बदलाव सभी कैश को अमान्य कर देते हैं। सिस्टम प्रॉम्प्ट में बदलाव सिस्टम और मैसेज कैश को अमान्य कर देते हैं। बातचीत के बीच में किए बदलाव सिर्फ मैसेज कैश को प्रभावित करते हैं।

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

प्री-वार्मिंग और मॉनिटरिंग​

आप उपयोगकर्ता ट्रैफिक आने से पहले कैश को प्री-वार्म कर सकते हैं, max_tokens: 0 के साथ एक अनुरोध भेजकर — यह बिना आउटपुट पैदा किए कैश लिखता है। बैच जॉब के लिए या ऑफ-पीक घंटों में राइट लागत को आगे लोड करने के लिए उपयोगी।

API रिस्पॉन्स का usage फील्ड आपको बताता है कि कैश से कितने टोकन पढ़े गए (cache_read_input_tokens), कैश में कितने लिखे गए (cache_creation_input_tokens), और कितने नियमित इनपुट के रूप में बिल किए गए। यह सत्यापित करने के लिए कि आपकी कैशिंग सचमुच टकरा रही है और आपको मिल रही बचत को मापने के लिए इन पर नजर रखें।

किसी कैशिंग आर्किटेक्चर के लिए प्रतिबद्ध होने से पहले अपेक्षित बचत का मॉडल बनाने के लिए कॉस्ट कैलकुलेटर इस्तेमाल करें।

सार-संक्षेप​

प्रॉम्प्ट कैशिंग कोई सूक्ष्म-अनुकूलन नहीं है। किसी भी ऐसे एप्लिकेशन के लिए जो वही बड़ा प्रीफिक्स बार-बार भेजता है, यह एक संरचनात्मक आर्थिक फैसला है। इसके बारे में सोचने का मॉडल सीधा है: स्थिर सामग्री पहले जाती है, अस्थिर सामग्री आखिर में जाती है, ब्रेकपॉइंट को सीमा पर रखें।

अगर आप API के विरुद्ध निर्माण कर रहे हैं और अभी तक कैशिंग पर नजर नहीं डाली है, तो बड़े स्थिर सेक्शनों के लिए अपने मौजूदा प्रॉम्प्ट जाँचें। अगर वे मौजूद हैं, तो कैशिंग सक्षम करना आमतौर पर कम-मेहनत वाला होता है और बचत असली होती है।

संबंधित​