मेरे ओपनक्लॉ सेशन्स ने एक दिन में 21.5M टोकन्स क्यों जला दिए (और वास्तव में इसे क्या ठीक किया)
मूल लेखक: MOSHIII
मूल संकलन: पेगी, ब्लॉकबीट्स
संपादकीय टिप्पणी: एजेंट एप्लिकेशन के तेजी से व्यापक होने के समय, कई टीमें एक ऐसी विरोधाभासी घटना का अनुभव कर रही हैं: सिस्टम सामान्य रूप से काम कर रहा है, लेकिन टोकन लागत अनजाने में लगातार बढ़ रही है। एक वास्तविक OpenClaw वर्कलोड के विश्लेषण से पता चला है कि लागत में विस्फोट का कारण अक्सर उपयोगकर्ता इनपुट या मॉडल आउटपुट में नहीं, बल्कि उपेक्षित संदर्भ कैशिंग पुनः चलाने (cached prefix replay) में होता है। मॉडल प्रत्येक कॉल में विशाल ऐतिहासिक संदर्भ को बार-बार पढ़ता है, जिससे भारी मात्रा में टोकन खपत होती है।
लेख विशिष्ट सेशन डेटा के साथ मिलाकर दर्शाता है कि टूल आउटपुट, ब्राउज़र स्नैपशॉट, JSON लॉग आदि बड़े मध्यवर्ती उत्पाद कैसे लगातार इतिहास के संदर्भ में लिखे जाते हैं और एजेंट चक्र में दोहराकर पढ़े जाते हैं।
इस मामले के माध्यम से, लेखक एक स्पष्ट अनुकूलन दृष्टिकोण प्रस्तुत करता है: संदर्भ संरचना डिज़ाइन, उपकरण आउटपुट प्रबंधन और compaction मैकेनिज़म कॉन्फ़िगरेशन तक। एजेंट सिस्टम बना रहे डेवलपर्स के लिए, यह केवल एक तकनीकी निदान रिकॉर्ड ही नहीं है, बल्कि एक वास्तविक बचत की रणनीति भी है।
निम्नलिखित मूल पाठ है:
मैंने एक वास्तविक OpenClaw वर्कलोड का विश्लेषण किया, और एक पैटर्न खोजा जिसे मुझे लगता है कि बहुत से Agent उपयोगकर्ता पहचानेंगे:
टोकन का उपयोग बहुत 「सक्रिय」 लग रहा है
प्रतिक्रिया भी सामान्य लग रही है
लेकिन टोकन की खपत अचानक विस्फोटक रूप से बढ़ गई
इस विश्लेषण के लिए नीचे संरचना का विघटन, मूल कारण और व्यावहारिक रूप से लागू करने योग्य ठीक करने का रास्ता दिया गया है।
TL;DR
सबसे बड़ा लागत ड्राइवर यह नहीं है कि उपयोगकर्ता संदेश बहुत लंबे हैं। बल्कि यह है कि अत्यधिक मात्रा में कैश्ड प्रीफिक्स (cached prefix) को बार-बार पुनः चलाया जा रहा है।
सेशन डेटा के अनुसार:
कुल टोकन: 21,543,714
cacheRead: 17,105,970 (79.40%)
4,345,264 (20.17%)
आउटपुट: 92,480 (0.43%)
दूसरे शब्दों में: अधिकांश कॉल की लागत वास्तव में नए उपयोगकर्ता इरादों को संभालने में नहीं, बल्कि विशाल ऐतिहासिक संदर्भ को बार-बार पढ़ने में होती है।
"रुकिए, ऐसा कैसे हो सकता है?" का क्षण
मुझे लगा था कि उच्च टोकन उपयोग बहुत लंबे उपयोगकर्ता प्रॉम्प्ट, बहुत सारे आउटपुट जेनरेट करने, या महंगे टूल कॉल से आता है।
लेकिन वास्तविक रूप से प्रमुख पैटर्न है:
कई सौ से लेकर हजारों टोकन
cacheRead: प्रत्येक कॉल पर 17 लाख से 18 लाख टोकन
इसका मतलब है कि मॉडल प्रत्येक चक्र में एक ही विशाल स्थिर पूर्वरूप को बार-बार पढ़ रहा है।
डेटा रेंज
मैंने दो स्तरों के डेटा का विश्लेषण किया:
1. रनटाइम लॉग्स
2. सेशन रिकॉर्ड (session transcripts)
ध्यान दें:
रन लॉग का उपयोग मुख्य रूप से व्यवहार संकेतों (जैसे पुनः शुरू करना, त्रुटि, कॉन्फ़िगरेशन समस्याएँ) को देखने के लिए किया जाता है।
टोकन का सटीक आँकड़ा session JSONL के usage क्षेत्र से आता है
उपयोग किया गया स्क्रिप्ट:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
उत्पन्न विश्लेषण फ़ाइल:
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
टोकन कहाँ वास्तविक रूप से खर्च होता है?
1) सेशन केंद्रीकृत
एक सेशन का उपयोग अन्य सभी से काफी अधिक है:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 टोकन
फिर स्पष्ट तीव्र गिरावट:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584
2) व्यवहार केंद्रित
टोकन मुख्य रूप से आते हैं:
टूलउपयोग: 16,372,294
रोकें: 5,171,420
समस्या मुख्य रूप से टूल कॉल चेन साइकिल में है, सामान्य चैट में नहीं।
3) समय संकेंद्रित
टोकन के शीर्ष यादृच्छिक नहीं होते, बल्कि कुछ घंटे के समय अंतराल में केंद्रित होते हैं:
2026-03-08 16:00: 4,105,105
2026-03-08 09:00: 4,036,070
2026-03-08 07:00: 2,793,648
बड़े कैश प्रीफिक्स में क्या है?
यह वार्तालाप की सामग्री नहीं है, बल्कि मुख्य रूप से बड़े मध्यवर्ती उत्पाद हैं:
विशाल toolResult डेटा ब्लॉक
लंबी तर्क / सोच की ट्रेसेस
बड़ा JSON स्नैपशॉट
File List
ब्राउज़र द्वारा डेटा एकत्र किया जा रहा है
सब एजेंट की बातचीत का रिकॉर्ड
सबसे बड़े सेशन में अक्षरों की संख्या लगभग है:
366,469 अक्षर
331,494 अक्षर
53,039 अक्षर
जब ये कंटेंट इतिहास के संदर्भ में संग्रहित हो जाते हैं, तो बाद की प्रत्येक कॉल उन्हें cache प्रीफिक्स के माध्यम से पुनः पढ़ सकती है।
विशिष्ट उदाहरण (सेशन फ़ाइल से)
निम्नलिखित स्थानों पर बड़े पैमाने पर संदर्भ ब्लॉक दोहराए गए हैं:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
बड़ा गेटवे JSON लॉग (लगभग 37,000 वर्ण)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
ब्राउज़र स्नैपशॉट + सुरक्षित एन्कैप्सुलेशन (लगभग 29,000 वर्ण)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
बहुत बड़ी फाइल सूची आउटपुट (लगभग 41,000 वर्ण)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
सेशन/स्टेटस स्टेटस स्नैपशॉट + बड़ा प्रॉम्प्ट स्ट्रक्चर (लगभग 30,000 वर्ण)
"Repeated content waste" vs "cache replay burden"
मैंने एकल कॉल के भीतर दोहराए गए कंटेंट का अनुपात भी मापा:
दोहराने का अनुपात लगभग: 1.72%
यह वास्तव में मौजूद है, लेकिन यह मुख्य समस्या नहीं है।
वास्तविक समस्या यह है: कैश प्रीफिक्स का निरपेक्ष आयतन बहुत बड़ा है
संरचना है: विशाल ऐतिहासिक संदर्भ, प्रत्येक कॉल पर पुनः पढ़ना, ऊपर केवल कुछ नए इनपुट जोड़ना
इसलिए अनुकूलन का केंद्र डुप्लिकेट हटाना नहीं, बल्कि संदर्भ संरचना डिजाइन है।
क्यों एजेंट चक्र इस समस्या के लिए विशेष रूप से संवेदनशील है?
तीन तंत्र एक साथ जुड़ते हैं:
1. बड़ी मात्रा में उपकरणों के आउटपुट को इतिहास के संदर्भ में लिखा गया है
2. टूल साइकिल से बहुत सारे छोटे अंतराल के कॉल उत्पन्न होते हैं
3. प्रीफिक्स में बहुत कम बदलाव → कैश हर बार पुनः पढ़ा जाता है
यदि कॉन्टेक्स्ट कॉम्पैक्शन स्थिर रूप से ट्रिगर नहीं होता है, तो समस्या तेजी से बढ़ जाएगी।
सबसे महत्वपूर्ण निवारण रणनीतियाँ (प्रभाव के अनुसार क्रमबद्ध)
P0—बड़े टूल आउटपुट को लंबे समय तक के कॉन्टेक्स्ट में न डालें
बहुत बड़े टूल आउटपुट के लिए:
- सारांश बनाए रखें + संदर्भ पथ / आईडी
- Original payload written to file artifact
- पूर्ण मूल पाठ को चैट इतिहास में न रखें
इन श्रेणियों के लिए प्राथमिकता दें:
- बड़ा JSON
- लंबी सूची
- ब्राउज़र का पूर्ण स्नैपशॉट
- सब एजेंट पूर्ण ट्रांसक्रिप्ट
P1—सुनिश्चित करें कि compaction मैकेनिज़म वास्तव में कार्य कर रहा है
इस डेटा में, कॉन्फिगरेशन संगति समस्याएँ बार-बार आईं: compaction key अमान्य है
यह ऑप्टिमाइजेशन मैकेनिज्म को चुपचाप बंद कर देगा।
सही तरीका: केवल संगत संस्करण कॉन्फ़िगरेशन का उपयोग करें
फिर पुष्टि करें:
openclaw doctor --fix
और compaction को स्वीकार किए जाने की पुष्टि के लिए स्टार्टअप लॉग जांचें।
P1— reasoning टेक्स्ट के स्थायीकरण को कम करें
लंबे निष्कर्ष पाठ को बार-बार पुनर्चालित न करें
उत्पादन वातावरण में: पूर्ण तर्क के बजाय संक्षिप्त सारांश सहेजें
P3—प्रॉम्प्ट कैशिंग डिज़ाइन में सुधार
लक्ष्य cacheRead को अधिकतम नहीं करना है। लक्ष्य है कि संकुचित, स्थिर और उच्च मूल्य वाले प्रीफिक्स पर cache का उपयोग करना।
सुझाव:
- स्थिर नियमों को सिस्टम प्रॉम्प्ट में डालें
- अस्थिर डेटा को स्थिर प्रीफिक्स में मत डालें
- हर राउंड में बहुत सारा डीबग डेटा इनजेक्ट न करें
व्यावहारिक स्टॉप लॉस योजना (अगर मैं कल इसे संभालने वाला हूँ)
1. सबसे अधिक cacheRead अनुपात वाला सेशन ढूंढें
2. runaway session के लिए /compact निष्पादित करें
3. टूल आउटपुट में कटौती + आर्टिफैक्टिकेशन जोड़ें
4. प्रत्येक संशोधन के बाद टोकन सांख्यिकी पुनः चलाएं
चार KPI का ध्यानपूर्वक अनुसरण करें:
कैश पढ़ें / कुल टोकन
toolUse avgTotal/call
>=100k टोकन के कॉल्स
अधिकतम सेशन अनुपात
सफल संकेत
यदि अनुकूलन प्रभावी होता है, तो आपको देखना चाहिए:
100k+ टोकन कॉल में स्पष्ट कमी
कैश रीड का अनुपात घट गया
toolUse कॉल वेट घट गया
एकल सेशन की प्रभुता कम हो गई है
अगर ये सूचक नहीं बदले, तो आपकी संदर्भ रणनीति अभी भी बहुत ढीली है।
प्रयोग निर्देश पुनः लागू करें
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--शीर्ष 20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--शीर्ष 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
अंतिम शब्द
अगर आपका Agent सिस्टम सामान्य दिख रहा है, लेकिन लागत लगातार बढ़ रही है, तो पहले एक समस्या की जांच करें: क्या आप नए निष्कर्षण के लिए भुगतान कर रहे हैं, या पुराने संदर्भों को बड़े पैमाने पर पुनः चला रहे हैं?
मेरे मामले में, अधिकांश लागत वास्तव में संदर्भ पुनर्चालन से आती है।
इस बात को समझने के बाद, समाधान स्पष्ट है: लंबे समय तक के संदर्भ में प्रवेश करने वाले डेटा पर कठोर नियंत्रण रखें।