प्रॉम्प्ट कैशिंग क्या है? दोहराया गया प्रॉम्प्ट कैसे दोबारा इस्तेमाल होता है

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

वह सपोर्ट बॉट जो एक ही पेज बार-बार पढ़ता है#

मान लीजिए आप एक सपोर्ट बॉट चलाते हैं जिसमें रोज़ 2,000 टिकट आते हैं। हर अनुरोध की शुरुआत में वही 3,000 टोकन होते हैं: बात करने का लहज़ा, रिफ़ंड नियम, शिपिंग पॉलिसी। उसके बाद ग्राहक का एक-लाइन संदेश आता है, जैसे "मेरा ऑर्डर कहाँ है?" (अगर टोकन अभी भी धुँधला लगता है, तो टोकन क्या है से शुरू करें।)

कैशिंग के बिना, प्रोवाइडर टिकट नंबर 1, टिकट नंबर 2, और टिकट नंबर 2,000 के लिए नियमों के सभी 3,000 टोकन फिर से पढ़ता है। वही पेज, 2,000 बार पढ़ा गया। कैशिंग के साथ, पहला अनुरोध इसे पढ़ने की पूरी कीमत चुकाता है, और बाद के अनुरोध जो उसी टेक्स्ट से शुरू होते हैं, उस काम का दोबारा इस्तेमाल कर सकते हैं।

DeepSeek की API गाइड (24 अक्टूबर 2026 को जाँची गई) बिल्कुल यही बताती है: कॉन्टेक्स्ट कैशिंग डिफ़ॉल्ट रूप से चालू है, इसमें कोई कोड बदलाव नहीं चाहिए, और ओवरलैपिंग प्रीफ़िक्स वाला बाद का अनुरोध "कैश हिट" माना जाता है। सिर्फ़ इनपुट कैश होता है। जवाब हर बार नया बनाया जाता है।

"वही" क्या माना जाता है: प्रीफ़िक्स नियम#

कैश पहले अक्षर से आगे मिलान करता है। जिस पल आपका अनुरोध कैश किए गए अनुरोध से अलग होता है, उसके बाद का सब कुछ नया होता है। इसीलिए आपके अनुरोध का क्रम उसकी लंबाई से ज़्यादा मायने रखता है।

यहाँ वह गलती है जो चुपचाप कैशिंग को खत्म कर देती है। एक डेवलपर चाहता है कि बॉट को समय पता हो, और उसे सबसे ऊपर रख देता है:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

समय हर सेकंड बदलता है, इसलिए पहली ही लाइन हर अनुरोध में अलग होती है, और उसके बाद कुछ भी मिल नहीं सकता। समाधान है जो भी बदलता है उसे अंत में ले जाना:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

अब नियमों के 3,000 टोकन पहले आते हैं और वैसे ही रहते हैं। यही तर्क बाकी दो आम मामलों पर भी लागू होता है: एक लंबी चैट हर बार अपनी पूरी हिस्ट्री दोबारा भेजती है, इसलिए पुराने संदेश एक तैयार दोहराने वाली शुरुआत होते हैं (इस पर ज़्यादा लंबी चैट ज़्यादा महँगी क्यों पड़ती है में), और एक एजेंट हर कदम पर अपनी टूल परिभाषाएँ और निर्देश दोहराता है।

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

इसे कैसे देखें: usage में कैश फ़ील्ड#

आपको अंदाज़ा लगाने की ज़रूरत नहीं कि यह काम करा या नहीं। हर प्रोवाइडर इसे रिस्पॉन्स के usage हिस्से में अपने-अपने फ़ील्ड नामों के तहत बताता है।

DeepSeek दो फ़ील्ड इस्तेमाल करता है:

• prompt_cache_hit_tokens — इनपुट टोकन जो कैश में मिले
• prompt_cache_miss_tokens — इनपुट टोकन जो नहीं मिले

मान लीजिए आपका पहला सपोर्ट टिकट prompt_cache_hit_tokens: 0 और prompt_cache_miss_tokens: 3200 के साथ आता है, और एक मिनट बाद का टिकट prompt_cache_hit_tokens: 3000 और prompt_cache_miss_tokens: 200 दिखाता है। नियमों के 3,000 टोकन दोबारा इस्तेमाल हुए; सिर्फ़ नया ग्राहक संदेश और कुछ टोकन शुरू से पढ़े गए। अगर हर कॉल पर हिट संख्या शून्य ही रहती है, तो अपने अनुरोध की शुरुआत देखें: वहाँ कुछ बदल रहा है।

Anthropic अलग तरह से काम करता है, क्योंकि आप तय करते हैं कि क्या कैश करना है। आप अनुरोध में या किसी कंटेंट ब्लॉक में cache_control जोड़ते हैं, type ephemeral के साथ:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Anthropic के प्रॉम्प्ट कैशिंग दस्तावेज़ (24 अक्टूबर 2026 को जाँचा गया) के अनुसार, जवाब तीन संख्याएँ बताता है: cache_creation_input_tokens (अभी कैश में लिखा गया), cache_read_input_tokens (उससे पढ़ा गया), और input_tokens (आखिरी कैश ब्रेकपॉइंट के बाद जो आया)। मान लीजिए पहली कॉल cache_creation_input_tokens: 10000, cache_read_input_tokens: 0 दिखाती है; दूसरी 0 और 10000 दिखाती है। यह एक कैश राइट के बाद कैश रीड है।

स्क्रीन पर एक जाल है। मॉडल के न्यूनतम (मॉडल के अनुसार 512, 1,024 या 4,096 टोकन) से छोटे प्रॉम्प्ट बिना कैशिंग और बिना किसी त्रुटि के प्रोसेस होते हैं। आपको दोनों कैश फ़ील्ड में शून्य दिखेंगे और कोई चेतावनी नहीं। डिफ़ॉल्ट जीवनकाल 5 मिनट है, हर इस्तेमाल पर मुफ़्त में रीफ़्रेश होता है; वैकल्पिक ttl जिसकी वैल्यू 1h है, इसे ज़्यादा देर तक रखता है।

यह आपके बिल पर क्या असर डालता है#

कैशिंग दोहराए गए हिस्से की कीमत बदल देती है, इसलिए एक बार हिसाब लगाना फ़ायदेमंद है। Anthropic बेस इनपुट कीमत पर गुणक बताता है: 5-मिनट जीवनकाल वाला कैश राइट 1.25× लागत लेता है, रीड 0.1× (Opus 5.5 और Sonnet 5.5 के लिए 0.05×)। 5-मिनट की विंडो में 20 अनुरोधों में दोबारा इस्तेमाल किया गया 10,000-टोकन प्रीफ़िक्स लें, मानक 0.1× रीड के साथ:

कैशिंग के बिना बेस कीमत पर 10,000 × 20 = 200,000 टोकन

कैश लिखने वाले पहले अनुरोध के लिए 10,000 × 1.25 = 12,500

इसे पढ़ने वाले 19 अनुरोधों के लिए 19 × 10,000 × 0.1 = 19,000

कैशिंग के साथ 12,500 + 19,000 = 31,500 टोकन-समतुल्य

तो दोहराए गए हिस्से की लागत बिना कैश वाली राशि के एक-पाँचवें से भी काफ़ी कम है। पेच यह है: अगर अनुरोधों के बीच 5 मिनट बीत जाएँ, तो अगला अनुरोध कैश को 1.25× पर फिर से लिखता है, और कम इस्तेमाल होने वाला प्रीफ़िक्स बिना कैशिंग से ज़्यादा महँगा पड़ सकता है।

अब शुरुआत वाला बॉट, सादे पूरी-कीमत बेसलाइन के रूप में। रोज़ 2,000 अनुरोध, हर एक में 3,000 इनपुट टोकन और लगभग 300 आउटपुट टोकन:

रोज़ 2,000 × 3,000 = 6,000,000 इनपुट टोकन

रोज़ 2,000 × 300 = 600,000 आउटपुट टोकन

तालिका उस दिन के वर्कलोड की कीमत हर उपलब्ध CheapTokens मॉडल पर OpenRouter के मुक़ाबले लगाती है:

DeepSeek-V4-Flash इनपुट और आउटपुट को मिलाकर कुल में OpenRouter से सस्ता है, और वर्कलोड आसानी से फ़िट हो जाता है: 380K कॉन्टेक्स्ट और प्रति जवाब 32,768 आउटपुट टोकन तक। यह वर्कलोड की पूरी-कीमत लागत है: इनपुट टोकन × प्रति टोकन कीमत। लंबा स्थिर प्रीफ़िक्स वह जगह है जहाँ यह इनपुट हिस्सा सबसे बड़ा होता है।

इसे खुद पाँच मिनट में आज़माएँ#

योजना: वही लंबा सिस्टम प्रॉम्प्ट अलग-अलग सवालों के साथ दो बार भेजें और usage देखें। अपना खुद का नियम टेक्स्ट support_rules.txt में डालें (एक-दो पेज का टेक्स्ट काफ़ी है)। एंडपॉइंट OpenAI-संगत CheapTokens API है, और आप अपने अकाउंट से की ले सकते हैं।

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

प्रिंटआउट में क्या जाँचें: prompt_tokens बताता है कि आपका अनुरोध कितना बड़ा है। दोनों अनुरोधों में वही SYSTEM टेक्स्ट है, इसलिए उस संख्या का ज़्यादातर हिस्सा एक अनुरोध से अगले तक दोहराया जाता है — मोटे तौर पर आपकी नियम फ़ाइल का आकार। वही दोहराई गई शुरुआत वह हिस्सा है जिसे कैशिंग वाला प्रोवाइडर, जैसे ऊपर DeepSeek API या Anthropic, दोबारा इस्तेमाल कर सकता है। अब क्रम पर एक अभ्यास: SYSTEM के सबसे ऊपर वर्तमान समय वाली एक लाइन (datetime.now()) जोड़ें और फिर चलाएँ। दोनों अनुरोध अब शुरुआत साझा नहीं करते, क्योंकि वे पहली ही लाइन से अलग हैं। वही लाइन प्रॉम्प्ट के अंत में रखें और साझा शुरुआत वापस आ जाती है।

अपने खुद के प्रॉम्प्ट के लिए एक छोटी चेकलिस्ट:

1. स्थिर टेक्स्ट पहले: निर्देश, नियम, टूल परिभाषाएँ, उदाहरण।
2. बदलता टेक्स्ट आखिर में: तारीख, उपयोगकर्ता का नाम, नवीनतम संदेश।
3. प्रीफ़िक्स को बाइट-दर-बाइट वैसा ही रखें — एक अतिरिक्त स्पेस भी मायने रखता है।
4. यह सोचने से पहले कि कुछ कैश क्यों नहीं हुआ, प्रोवाइडर का न्यूनतम आकार जाँचें।
5. बदलाव के बाद usage फ़ील्ड देखें, पहले नहीं।

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