Caching, Batching और Trimming

कम काम करें, या सस्ते में करें

Prompt caching provider को दोहराए prefix (लंबे निर्देश, tool परिभाषाएँ, दस्तावेज़) को घटी क़ीमत और कम latency पर दोबारा उपयोग करने देती है, यदि prompt की शुरुआत एक-सी रहे। Response caching एक-जैसे या लगभग एक-जैसे सवालों के उत्तर सहेजती है ताकि आप model call पूरी छोड़ दें (सिर्फ़ ऐसे सवालों के लिए जिनके उत्तर user या समय पर निर्भर नहीं)। Batch APIs जल्दबाज़ी न वाले jobs रियायत पर asynchronous चलाती हैं। Trimming अनावश्यक context हटाती है: छोटे निर्देश, सारांशित इतिहास, कम retrieved chunks और सीमित output लंबाई।

Prompt caching का गणित, चलाकर

मैंने यह उदाहरण मान्यता से चलाया कि cached tokens सामान्य input क़ीमत के 10% पर बिल होते हैं। प्रति दस लाख 3 की दर से 1,000 input tokens की लागत caching के बिना 0.003 और 80% prompt के cache hit होने पर 0.00084 है। असली cache क़ीमत और नियम अपने provider से जाँचें।

def cached_cost(in_tok, cached_frac, p_in, read_mult=0.1):
    return round(in_tok / 1e6 * p_in * ((1 - cached_frac) + cached_frac * read_mult), 6)

print(cached_cost(1000, 0.0, 3.0), cached_cost(1000, 0.8, 3.0))

Output:

0.003 0.00084

स्थिर text पहले रखें

Caching सिर्फ़ न बदले prefix पर काम करती है। लंबे स्थिर निर्देश और दस्तावेज़ शुरू में और बदलता user सवाल अंत में रखें; ऊपर timestamp जोड़ने से cache टूट जाती है।

त्वरित जाँच: Prompt caching ठीक चलने के लिए बदलता user सवाल कहाँ रखें?

• कहीं नहीं
• बिल्कुल शुरू में
• API key के भीतर
• अंत में, स्थिर prefix के बाद