Prompt Cache: पहले और दोहराए गए requests की लागत
Prompt Cache के लिए reproducible experiment: पहला request, cache hit, control miss, break-even formula और usage verification।
Prompt Cache की लागत को समान requests की श्रृंखला से जाँचें: पहला cacheable prefix बनाता या तैयार करता है, बाद के requests उसे पढ़ने का प्रयास करते हैं, और control request prefix बदलकर miss बनाती है। एक model की usage categories और actual charge की तुलना करें। Model ID, TTL, prefix length और current price के बिना स्थिर “प्रतिशत बचत” कोई प्रमाण नहीं है।
प्रयोग वास्तव में क्या मापता है
Prompt Cache input के अपरिवर्तित भाग को दुबारा process होने से घटाता है। यह system prompt, instructions, बड़ा document या stable history हो सकता है; बदलता प्रश्न common prefix के बाद आता है। तीन states चाहिए:
A और B एक model, समान settings और एक cache policy लेते हैं। C cacheable area में केवल एक character बदलता है या confirmed TTL expiry के बाद चलता है। Model, output length और prompt एक साथ बदलें तो परिणाम केवल cache से explain नहीं होता।
अपने usage पर formula जाँचने के लिए BetterToken account और API Key बनाएँ, pricing page से current rates लें और stable prefix के साथ first व repeat requests चलाएँ। Dashboard में input, output, applicable cache Token और charge मिलाएँ; cache rules तथा TTL को पहले API reference और provider docs से जाँचें।
OpenAI और Anthropic cache अलग तरह से गिनते हैं
एक ही “cache” शब्द समान mechanism नहीं बताता।
OpenAI prompt caching
Supported OpenAI APIs/models में suitable prefix पर caching automatic हो सकती है। Usage input details में cached tokens दिखाती है। Code को अलग cache object बनाने की जरूरत नहीं, पर shared prefix बिल्कुल stable रखना होता है। Exact threshold, retention और discount को official Prompt Caching page से जाँचें।
Anthropic prompt caching
Anthropic Messages में cache_control से cache boundary mark की जा सकती है। Usage cache creation और read अलग दिखा सकती है। Minimum size, TTL, block order और price current contract तथा model पर निर्भर हैं; उन्हें official Anthropic documentation से जाँचें।
Usage field names या coefficients को दोनों protocols के बीच न ले जाएँ। Experiment table में current endpoint से लौटने वाली categories ही लिखें।
Stable prefix तैयार करें
Input को दो भागों में रखें:
पहले experiment में tools और streaming हटाएँ। वे cache को आवश्यक रूप से नहीं रोकते, लेकिन usage और output में variables बढ़ाते हैं। Prefix चुनी हुई model के rules के अनुसार पर्याप्त लंबा होना चाहिए। Threshold से छोटा prefix हो तो cache hit न मिलना अपेक्षित है; production में उसे बेकार text से न भरें, ऐसा real repeated document लें जो task में पहले से है।
Call से पहले cacheable part का hash रखें:
यह A और B में identical prefix सिद्ध करता है, उसका content प्रकाशित किए बिना।
कौन-से fields दर्ज करें
हर request के लिए timestamp और request ID, Model ID और protocol, prefix_hash, ordinary input tokens, contract में अलग हों तो cache creation/write tokens, cache read/cached tokens, output tokens, actual charge तथा diagnostic-only status और latency लिखें।
Latency कीमत का प्रमाण नहीं: तेज response cache miss और queue में रुका cache hit हो सकता है। Cost निष्कर्ष usage और rate से आता है।
पहले request की formula
मान लें:
जब endpoint categories अलग करता है:
First request में W positive और R zero हो सकता है। Automatic caching में fields अलग हों तो actual usage के uncached/cached input लें; अस्तित्वहीन category न बनाएँ। Cache creation अलग bill हो तो पहला request non-cache request से महँगा होना error नहीं; break-even पर्याप्त reads के बाद आता है।
Repeat request और break-even point
मान लें:
एक creation और n - 1 hits वाली series:
Cache का minimum break-even वह पहला integer n है जिसके लिए:
Formula में दूसरी model की prices न रखें। Ch >= Cu हो तो current configuration बचत नहीं देती; cache hit, prefix size और pricing categories जाँचें।
Control cache miss
A और B के बाद C चलाएँ। केवल cacheable prefix बदलें, model और expected output length stable रखें। Contract के अनुसार cache-read category घटे या गायब हो और ordinary processing अथवा cache creation बदले। Unexpected miss के कारण हो सकते हैं: prefix का symbol/space बदलना, tool definitions का अलग क्रम, moved system block, model/endpoint change, TTL समाप्त होना, threshold से छोटा prefix या client serialization order बदलना। Stable prefix के बाद प्रश्न बदलना सामान्य है; prefix के भीतर बदलाव नई cache identity बनाता है।
हम “dollar result” क्यों publish नहीं करते
इस लेख के पास किसी account का API Key या usage नहीं है, इसलिए यह test के लिए fabricated numeric result नहीं देता। Prices, models और caching rules बदलते हैं; random number reproducible experiment को जल्दी outdated advertisement बना देगा।
अपना परिणाम निकालने के लिए एक model और protocol लें, current BetterToken pricing page खोलें, A/B/C चलाएँ, Dashboard से usage और charge लिखें, C0, Ch, Cu व break-even निकालें, और date तथा prefix_hash रखें।
FAQ
Cache वाला पहला request महँगा क्यों हो सकता है?
कुछ protocols cache creation/write को अलग charge करते हैं। Initial surcharge तभी compensate होता है जब cache reads पर्याप्त हों। Current model price देखें।
Repeat request को cache hit क्यों नहीं मिला?
Prefix length और immutability, block order, model, endpoint, TTL और threshold जाँचें। prefix_hash compare करें।
क्या OpenAI और Anthropic को एक usage field से compare कर सकते हैं?
नहीं। Mechanism, configuration और categories अलग हैं। Original fields रखते हुए पहले उन्हें अपने I, W, R, O में normalize करें।
क्या cache हमेशा लागत घटाता है?
नहीं। Short prefix, rare repeats, frequent changes और low hit rate creation cost नहीं चुका सकते।
BetterToken का actual charge कहाँ देखें?
Dashboard में request time, model और status से मिलाएँ। Rate pricing page से और caching rules संबंधित protocol documentation से लें।
Numeric example क्यों नहीं
Current prices बदल सकती हैं। अपनी rate और actual usage से formula चलाएँ; किसी पुरानी per-million number को present model price या charge न मानें।