tokens , संदर्भ विंडो, और कैशिंगः क्या आप गलत हो रही है

मेटा विवरण: Production Claude एजेंट अक्सर टोकन मूल्य निर्धारण, संदर्भ वृद्धि और शीघ्र कैशिंग आकार विलंबता के कारण महंगे हो जाते हैं। यहां बताया गया है कि उन्हें कैसे मापा जाए और ठीक किया जाए।

टैगः क्लाउड-ऑपस-5, शीघ्र कैशिंग, AI एजेंट्स, टोकन लागत, विलंबता

विशेष रुप से प्रदर्शित छवि: टोकन टुकड़ों का अमूर्त चित्रण, एक बढ़ती वार्तालाप विंडो और कैश शेल्फ; दोस्ताना फ्लैट शैली, कोई लोग नहीं, कोई लोगो, कोई पाठ नहीं।

एंथ्रोपिक के क्लाउड-ओपस -5 के साथ निर्मित Production AI एजेंट अक्सर लागत और गति पर दुर्घटनाग्रस्त होने के बिना विफल हो जाते हैं। एक परीक्षण किए गए एजेंट की कीमत बजट से तीन गुना हो सकती है, बातचीत जारी रहने के रूप में प्रतिक्रिया समय बढ़ सकता है, और उपयोगकर्ता द्वारा लगातार चार प्रश्न पूछने के बाद एक छोटा डेमो टूट सकता है। लॉग कुछ भी उपयोगी नहीं दिखा सकते क्योंकि वास्तव में कुछ भी क्रैश नहीं हुआ था। यह उन डेवलपर्स और तकनीकी उत्पाद मालिकों के लिए है जिन्हें वास्तविक बिलों की भविष्यवाणी करने की आवश्यकता होती है; यह दर्शाता है कि टोकन मूल्य निर्धारण, संदर्भ वृद्धि और शीघ्र कैशिंग कैसे काम करती है। ये डिफ़ॉल्ट असफलताएं हैं जब टीम नीचे मशीन को समझने के बिना निर्माण करते हैं।

टोकन की कीमत टुकड़ों से तय होती है, शब्दों से नहीं

टोकन एक छोटा पाठ टुकड़ा है जो टोकनेज़र प्रशिक्षण के दौरान सांख्यिकीय रूप से चुना जाता है, व्याकरणिक शब्द नहीं। "the" और "running" जैसे सामान्य शब्द प्रत्येक में एक टोकन हो सकते हैं। दुर्लभ स्ट्रिंग्स विभाजित हो सकती हैंः "idempotency" "idem", "pot", और "ency". API कुंजी और अन्य यूयूआईडी-जैसे मूल्य विशेष रूप से महंगे होते हैं। क्योंकि हर UUID अलग दिखता है, इसके चरित्र समूहों को व्यक्तिगत रूप से एन्कोड किया जाना चाहिए। एक एकल UUID की लागत 12 से 14 टोकन तक हो सकती है, और दस UUIDs की सूची एक छोटे अंग्रेजी पैराग्राफ से अधिक हो सकता है।

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

claude-opus-5 के लिए एंथ्रोपिक की count_tokens विधि वास्तविक संकेत को माप सकती है। इसे सिस्टम प्रॉम्प्ट, टूल परिभाषाओं और वार्तालाप इतिहास के साथ कॉल करें। लौटाई गई इनपुट_टोकन संख्या आमतौर पर अपेक्षित से बड़ी होती है।

टूल-परिभाषा समस्या लगभग सभी को पकड़ती है। प्रत्येक कॉल करने योग्य उपकरण का वर्णन करने वाली जेएसओएन योजनाएं हर अनुरोध पर भेजी जाती हैं, एक बार नहीं। एक दर्जन अच्छी तरह से प्रलेखित उपकरण 4,000 या 5,000 टोकन तक चल सकते हैं। उन्हें प्रत्येक वार्तालाप के पूरे जीवनकाल के लिए बारी 1, बारी 2, बारी 15, और 40 में बिल दिया जाता है। यदि कोई एजेंट महीने में 10,000 बातचीत संभालता है और प्रत्येक बातचीत औसतन 8 मोड़ होती है, तो उन योजनाओं के लिए 80,000 बार भुगतान किया जाता है. विस्तृत पैरामीटर विवरणों के साथ आठवें उपकरण को जोड़ने से पहले, खाली संदेश के साथ count_tokens चलाएँ ताकि केवल उपकरण सूची परिभाषा देखें। वह संख्या गायब नहीं होती; यह गुणा करती है।

आउटपुट मूल्य निर्धारण अधिक है क्योंकि हार्डवेयर का व्यवहार अलग होता है। इनपुट टोकन को प्रीफिल के दौरान समानांतर में संसाधित किया जाता है। एक 40,000-टोकन प्रॉम्प्ट को एक पास में संभाला जा सकता है क्योंकि समानता वह है जिसके लिए जीपीयू बनाए गए हैं। डिकोडिंग के दौरान आउटपुट टोकनों को एक-एक करके बनाया जाता है, और प्रत्येक आउटपुट टोकेन को दूसरे फॉरवर्ड पास की आवश्यकता होती है। प्रत्येक पास इससे पहले वाले टोकन पर निर्भर करता है, इसलिए कुछ भी समांतर नहीं हो सकता है। यह अनुक्रमिक कार्य मेमोरी-बैंडविड्थ-बाउंड है, सबसे महंगी बाधा आधुनिक हार्डवेयर चेहरे. यही कारण है कि आउटपुट टॉकन्स लागत लगभग 5 गुना क्या इनपुट टॉकन लागत।

दो परिणामों का पालन करें। विलंबता मुख्य रूप से इनपुट लंबाई के बजाय आउटपुट लंबाई द्वारा नियंत्रित की जाती है। सिस्टम प्रॉम्प्ट को दोगुना करने से लगभग 100 मिलीसेकंड जोड़ा जा सकता है, जबकि प्रतिक्रिया की लंबाई दोगुनी होने पर प्रतीक्षा लगभग दुगुनी हो सकती है। यदि कोई एजेंट धीमा महसूस करता है, तो फिक्स आमतौर पर एक छोटा जवाब होता है, न कि एक छोटा संकेत। एक वर्बोज़ उत्तर भी दो बार बिल किया जाता हैः पहले आउटपुट के रूप में, फिर प्रत्येक बाद के मोड़ पर इतिहास के हिस्से के रूप میں। एक लंबी बातचीत समाप्त होने से पहले शुरुआती चैटी रिप्लाई को दर्जन भर बार इनपुट के तौर पर चार्ज किया जा सकता हैं।

संदर्भ लागत वक्र है, स्मृति नहीं

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

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

वृद्धि तेज हो सकती है। पहला मोड़ 6,000 टोकन भेज सकता है। पांचवां मोड़ा 22,000 भेजेगा। बीसवीं बारी 80,000 भेजी जाएगी। चालीसवें मोड़ पर 160,000, खिड़की की सीमाओं के करीब, कुल खर्च रैखिक से अधिक चतुर्भुज तक बढ़ता है। यह वक्र उत्पादन में एजेंट अर्थशास्त्र को तोड़ देता है।

एक मध्य वार्तालाप उदाहरण में, उपयोगकर्ता ने 40 टोकन टाइप किए जबकि अनुरोध के लिए लगभग 46,000 टोकन का भुगतान किया गया। वास्तविक प्रश्न बिल के दसवें प्रतिशत से कम था। बाकी सब कुछ वास्तुकला चुना जाता है, इसलिए इसे मापा जा सकता है, बदला और कटौती की जा सकती है।

तीन संदर्भ विफलताएं बाहर से समान दिखती हैं लेकिन उनके अलग-अलग कारण और सुधार होते हैं।

ओवरफ्लो तब होता है जब विंडो भर जाती है. अनुरोध विफल हो जाता है या प्रदाता चुपचाप इतिहास को कॉम्पैक्ट करता है, और एजेंट कुछ खो देता है जिसकी उसे आवश्यकता होती है. यह वह विफलता है जिसके लिए हर कोई तैयार रहता है और सबसे कम खतरनाक क्योंकि यह खुद की घोषणा करता है. आपको एक त्रुटि मिलती है या स्पष्ट रूप से भ्रमित प्रतिक्रिया। इसे ठीक किया जा सकता है.

विघटन तब होता है जब ध्यान लंबे संदर्भों में असमान रूप से कम हो जाता है। शुरुआत और अंत के पास की जानकारी को बीच की जानकारी की तुलना में अधिक विश्वसनीयता से याद किया जाता है. प्रभाव संदर्भ लंबाई के साथ बढ़ता है। 8,000 टोकन पर सही ढंग से उद्धृत तथ्य को बिना किसी त्रुटि, कोई चेतावनी और एक आत्मविश्वासपूर्ण उत्तर जो केवल गलत है 80,000 टोकन में अनदेखा किया जा सकता है। "मॉडल एक मिलियन टोकन का समर्थन करता है" इसका मतलब यह नहीं है कि आप इसमें दस लाख टोकन डाल सकते हैं और सुसंगत व्यवहार की उम्मीद कर सकते हैं। क्षमता ध्यान नहीं है।

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

अतिप्रवाह खुद की घोषणा करता है। पतलापन चुपचाप होता है. विषाक्तता एक प्रतिक्रिया लूप है जो लंबे समय तक चलने पर बदतर हो जाती है।

व्यावहारिक बचाव माप और ट्रिमिंग हैं। लंबी बातचीत के लिए, रोलिंग सारांश का उपयोग करें जब इतिहास 20,000 टोकन जैसी सीमा से अधिक हो जाए। पिछले तीन मोड़ों की तुलना में पुराने सब कुछ को एक पैराग्राफ में संक्षेप में प्रस्तुत करें और कच्चे मोड़ों को इसके साथ प्रतिस्थापित करें। यह विकास वक्र को नाटकीय रूप से समतल करता है। क्लाउड-ऑप्स -5 कॉल में, max_tokens=512 और सिस्टम लाइन जैसे "आप वार्तालाप इतिहास को सटीक और संक्षिप्त रूप से सारांशित करते हैं" 3-5 वाक्यों के लिए पूछें जो तथ्यों, निर्णयों और मूल्यों को संरक्षित करते हैं। यदि प्रत्येक मोड़ पर उपयोगकर्ता और सहायक संदेश होते हैं, तो अंतिम तीन टर्न रखने का मतलब है कि अंतिम छह संदेश रखना।

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

त्वरित कैशिंग केवल एक सटीक बाइट उपसर्ग पर काम करता है

प्रत्येक प्रदाता जो शीघ्र कैशिंग प्रदान करता है, वही अंतर्निहित तंत्र का उपयोग करता हैः यदि एक नया संकेत हाल ही में भेजे गए प्रॉम्प्ट की शुरुआत से मेल खाता है, तो प्रदाता मिलान वाले हिस्से को संसाधित करने के लिए छोड़ देता है और सामान्य दर का एक अंश लेता है। बचत वास्तविक हैं। एंथ्रोपिक के साथ, कैश रीड लागत लगभग 10 प्रतिशत होती है सामान्य इनपुट टोकन दरें. कैश लिखता है कि सामान्य दरों का लगभग 125 प्रतिशत खर्च होता है। दो अनुरोधों के बाद अल्पकालिक कैश प्रविष्टि ब्रेक-ईवन तक पहुंचती है।

तंत्र सटीक बाइट्स पर एक उपसर्ग मिलान है. यह शब्दार्थ समानता नहीं है और "पर्याप्त करीब" नहीं है। वह एक तथ्य बताता है कि क्यों अधिकांश कैशिंग सेटअप चुपचाप विफल हो जाते हैं।

जब कोई अनुरोध एंथ्रोपिक को भेजा जाता है, तो API कॉल की संरचना के बावजूद सामग्री एक निश्चित क्रम में प्रस्तुत की जाती हैः उपकरण परिभाषाएं, फिर सिस्टम प्रॉम्प्ट, फिर वार्तालाप इतिहास। टूल परिभाषाएँ हमेशा पहले आती हैं और टोकन अनुक्रम में शून्य स्थिति पर बैठती हैं। यदि टूल सूची अनुरोधों के बीच बदलती है, तब कैश पूरे अनुरोध के लिए अमान्य हो जाता हैः सिस्टम प्रोम्प्ट , सभी इतिहास, सब कुछ।

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

अदृश्य अवैधकर्ता अक्सर छोटे होते हैं। एजेंट को वर्तमान समय बताने के लिए datetime.now का उपयोग करके सिस्टम प्रॉम्प्ट में एक टाइमस्टैंप कैश प्रविष्टि हर मिनट बदलता है। आपको कभी भी कैश हिट नहीं मिलता है। सामने की ओर यूयूआईडी या अनुरोध आईडी समान समस्या पैदा करता हैः प्रत्येक अनुरोध अद्वितीय होता है।

उत्पादन एजेंटों के लिए, व्यावहारिक प्रभाव यह है कि लागत, विलंबता और विश्वसनीयता वास्तुकला विकल्प हैं. count_tokens के साथ प्रॉम्प्ट आकार को मापें, ट्रिम उपकरण आउटपुट, कैश उपसर्ग स्थिर रखें, और उपयोगकर्ताओं को स्केल करने से पहले संदर्भ वृद्धि देखें।