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 के बिना स्थिर “प्रतिशत बचत” कोई प्रमाण नहीं है।

उपयोगअनुशंसित configurationपहले क्या जाँचें
Terminal में interactive developmentConfig file और environment variablesstatus और Model ID
Automated pipelines और CI/CDDirect endpoint वाला headless modetimeout handling

प्रयोग वास्तव में क्या मापता है

Prompt Cache input के अपरिवर्तित भाग को दुबारा process होने से घटाता है। यह system prompt, instructions, बड़ा document या stable history हो सकता है; बदलता प्रश्न common prefix के बाद आता है। तीन states चाहिए:

A. first request: stable prefix + question 1 B. cache hit: stable prefix + question 2 C. cache miss: changed prefix + question 3

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 को दो भागों में रखें:

STABLE_PREFIX system instructions tool definitions, यदि वास्तव में जरूरी हों unchanged reference document DYNAMIC_SUFFIX current user question

पहले experiment में tools और streaming हटाएँ। वे cache को आवश्यक रूप से नहीं रोकते, लेकिन usage और output में variables बढ़ाते हैं। Prefix चुनी हुई model के rules के अनुसार पर्याप्त लंबा होना चाहिए। Threshold से छोटा prefix हो तो cache hit न मिलना अपेक्षित है; production में उसे बेकार text से न भरें, ऐसा real repeated document लें जो task में पहले से है।

Call से पहले cacheable part का hash रखें:

import hashlib prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest() print(prefix_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

मान लें:

I — ordinary input tokens W — cache write / creation tokens R — cache read / cached tokens O — output tokens Pi — ordinary input price per 1,000,000 tokens Pw — cache write price per 1,000,000 tokens Pr — cache read price per 1,000,000 tokens Po — output price per 1,000,000 tokens

जब endpoint categories अलग करता है:

cost = I / 1_000_000 × Pi + W / 1_000_000 × Pw + R / 1_000_000 × Pr + O / 1_000_000 × Po

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

मान लें:

C0 — cache creation वाले first request की cost Ch — एक cache-hit request की cost Cu — cache बिना उसी प्रकार के request की cost n — total requests

एक creation और n - 1 hits वाली series:

C_cached(n) = C0 + (n - 1) × Ch C_uncached(n) = n × Cu

Cache का minimum break-even वह पहला integer n है जिसके लिए:

C_cached(n) < C_uncached(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 न मानें।

अपना LLM वर्कफ़्लो बेहतर बनाना चाहते हैं?

एक API से मॉडल जोड़ें, कुंजियाँ प्रबंधित करें और AI खर्च नियंत्रित करें।