কেন আমার ওপেনক্লস সেশনগুলি একদিনে 21.5M টোকেন পোড়াল (এবং এটি কী ঠিক করেছিল)
মোশি
পেগি, ব্লকবিটস
সম্পাদকীয় নোট: এজেন্ট অ্যাপ্লিকেশনের দ্রুত ব্যাপ্তির সময়ে, অনেক দল একটি অদ্ভুত ঘটনা লক্ষ্য করেছে: সিস্টেমটি সম্পূর্ণরূপে স্বাভাবিকভাবে চলছে, কিন্তু টোকেন খরচ অজান্তেই ধীরে ধীরে বৃদ্ধি পাচ্ছে। এই প্রবন্ধটি একটি বাস্তব OpenClaw ওয়ার্কলোডের বিশ্লেষণের মাধ্যমে দেখিয়েছে যে, খরচের বিস্ফোরণের কারণ প্রায়শই ব্যবহারকারীর ইনপুট বা মডেলের আউটপুটে নয়, বরং উপেক্ষিত কনটেক্সট ক্যাশে রিপ্লে (cached prefix replay)। মডেলটি প্রতিটি কলে বিশাল ইতিহাসগত কনটেক্সটকে পুনরায় পড়ে, যা অসংখ্য টোকেন খরচের কারণ হয়।
এই নিবন্ধটি নির্দিষ্ট সেশন ডেটা ব্যবহার করে দেখায় যে কীভাবে টুল আউটপুট, ব্রাউজার স্ন্যাপশট, JSON লগ ইত্যাদি বড় মধ্যবর্তী আউটপুটগুলি ধারাবাহিকভাবে ইতিহাসের প্রসঙ্গে লেখা হয় এবং এজেন্ট চক্রের মধ্যে পুনরাবৃত্তি হয়।
এই কেসটির মাধ্যমে লেখক একটি স্পষ্ট অপ্টিমাইজেশন পদ্ধতি প্রস্তাব করেন: কনটেক্সট স্ট্রাকচার ডিজাইন, টুল আউটপুট ম্যানেজমেন্ট এবং compaction মেকানিজম কনফিগারেশন পর্যন্ত। এজেন্ট সিস্টেম তৈরি করছেন এমন ডেভেলপারদের জন্য, এটি শুধুমাত্র একটি টেকনিক্যাল ট্রাবলশুটিং রেকর্ড নয়, বরং একটি বাস্তবিক টাকা বাঁচানোর গাইড।
নিম্নলিখিত মূল পাঠ:
আমি একটি বাস্তব ওপেনক্লস ওয়ার্কলোড বিশ্লেষণ করেছি এবং একটি প্যাটার্ন খুঁজে পেয়েছি যা আমি মনে করি অনেক এজেন্ট ব্যবহারকারী চিনতে পারবেন:
টোকেন ব্যবহার খুব সক্রিয় মনে হচ্ছে
উত্তরটিও সাধারণ দেখাচ্ছে
কিন্তু টোকেন খরচ হঠাৎ করে বিস্ফোরিত হয়ে উঠেছে
এই বিশ্লেষণের স্ট্রাকচার বিশ্লেষণ, মূল কারণ এবং বাস্তবসম্মত সমাধানের পথ নিচে দেওয়া হল।
TL;DR
সবচেয়ে বড় খরচের কারণ হল ব্যবহারকারীর বার্তা খুব লম্বা হওয়া নয়, বরং বিপুল পরিমাণে ক্যাশড প্রিফিক্স বারবার পুনরায় প্রচার করা।
সেশন ডেটা থেকে:
মোট টোকেন: 21,543,714
ক্যাশ পড়া: 17,105,970 (79.40%)
4,345,264 (20.17%)
আউটপুট: 92,480 (0.43%)
অন্যভাবে বললে: অধিকাংশ কলের খরচ আসলে নতুন ব্যবহারকারীর ইচ্ছাকে প্রক্রিয়া করার জন্য নয়, বরং বিশাল ইতিহাসের প্রসঙ্গ পুনরায় পড়ার জন্য।
"অপেক্ষা করুন, এটা কিভাবে হল?" এর মুহূর্ত
আমি মনে করেছিলাম উচ্চ টোকেন ব্যবহারের কারণ হল: খুব দীর্ঘ ব্যবহারকারীর প্রম্পট, বহুল আউটপুট জেনারেশন, বা মহং টুল কল।
কিন্তু প্রকৃতপক্ষে প্রধান প্যাটার্নটি হল:
শত শত থেকে হাজার হাজার টোকেন
ক্যাশ পড়া: প্রতিবার কলে 17 লক্ষ থেকে 18 লক্ষ টোকেন
অর্থাৎ, মডেলটি প্রতিটি রাউন্ডে একই বিশাল স্থির প্রিফিক্স বারবার পড়ছে।
ডেটা পরিসর
আমি দুটি স্তরের ডেটা বিশ্লেষণ করেছি:
1. রানটাইম লগস
২। সেশন রেকর্ড (session transcripts)
যা উল্লেখ করা প্রয়োজন:
রান লগগুলি প্রধানত আচরণের সংকেত (যেমন পুনরারম্ভ, ত্রুটি, কনফিগারেশন সমস্যা) পর্যবেক্ষণের জন্য ব্যবহৃত হয়।
টোকেনের সঠিক পরিসংখ্যান session JSONL-এর usage ফিল্ড থেকে আসে
ব্যবহৃত স্ক্রিপ্ট:
scripts/session_token_breakdown.py
স্ক্রিপ্ট/সেশন_ডুপ্লিকেট_ওয়েস্ট_অ্যানালিসিস.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
সমস্যাটি মূলত টুল কল চেইনের চক্রে রয়েছে, সাধারণ চ্যাট নয়।
৩) সময় কেন্দ্রিক
টোকেন শীর্ষ দৈবিক নয়, বরং কয়েকটি ঘন্টার সময়সীমায় কেন্দ্রীভূত হয়:
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 স্ন্যাপশট
ফাইলের তালিকা
ব্রাউজার ডেটা সংগ্রহ করছে
সাব এজেন্টের কথোপকথন রেকর্ড
সর্বাধিক সেশনে অক্ষরের পরিমাণ প্রায়:
৩৬৬,৪৬৯ অক্ষর
অসিস্ট্যান্ট: চিন্তা করছে: 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
বিশাল ফাইল লিস্ট আউটপুট (প্রায় ৪১,০০০ ক্যারেক্টার)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
সেশন/স্ট্যাটাস স্ট্যাটাস স্ন্যাপশট + বড় প্রম্পট কাঠামো (প্রায় 3 হাজার অক্ষর)
"পুনরাবৃত্তির অপচয়" বনাম "ক্যাশ পুনরাবৃত্তির বোঝা"
আমি একক কলের ভিতরে পুনরাবৃত্তির অনুপাতও পরিমাপ করেছি:
পুনরাবৃত্তি অনুপাত: প্রায় 1.72%
এটি বাস্তবিকভাবে বিদ্যমান, কিন্তু মূল সমস্যা নয়।
সত্যিকারের সমস্যা হলো: ক্যাশ প্রিফিক্সের পরম আকার খুব বড়
স্ট্রাকচারটি: বিশাল ঐতিহাসিক প্রেক্ষাপট, প্রতিটি কলে পুনরায় পড়া, উপরে কেবল কিছু নতুন ইনপুট যোগ করা
অতএব, অপ্টিমাইজেশনের প্রাথমিক লক্ষ্য হল পুনরাবৃত্তি দূরীকরণ নয়, বরং প্রেক্ষাপট গঠন।
কেন এজেন্ট লুপটি এই সমস্যাটির জন্য বিশেষভাবে সহজে প্রভাবিত হয়?
তিনটি মেকানিজম পরস্পর স্তরিত হয়:
1. বহু টুলের আউটপুট ইতিহাসের কনটেক্সটে লিখে ফেলা হয়েছে
২। টুল সাইকেল দ্বারা অসংখ্য সংক্ষিপ্ত ব্যবধানের কল তৈরি হয়
3、প্রিফিক্সে খুব কম পরিবর্তন → ক্যাশে প্রতিবার পুনরায় পড়া হয়
যদি কনটেক্সট কমপ্যাকশন স্থিতিশীলভাবে ট্রিগার না হয়, তবে সমস্যাটি দ্রুত বৃদ্ধি পাবে।
সবচেয়ে গুরুত্বপূর্ণ সংশোধন কৌশল (প্রভাব অনুযায়ী সাজানো)
P0—দীর্ঘস্থায়ী কনটেক্সটে বিশাল টুল আউটপুট ঢোকাবেন না
অতি বড় টুল আউটপুটের জন্য:
- সারাংশ সংরক্ষণ করুন + রেফারেন্স পাথ / আইডি
- মূল payload ফাইল আর্টিফ্যাক্টে লেখা হয়েছে
- চ্যাট হিস্ট্রিতে পুরো মূল লেখাটি রাখবেন না
এই শ্রেণীগুলির জন্য প্রাথমিক সীমাবদ্ধতা:
- বড় JSON
- দীর্ঘ ডিরেক্টরি তালিকা
- ব্রাউজারের পূর্ণ স্ন্যাপশট
- সাব এজেন্ট পূর্ণ ট্রান্সক্রিপ্ট
P1—কমপ্যাকশন মেকানিজমটি প্রকৃতপক্ষে কার্যকর হচ্ছে কিনা তা নিশ্চিত করুন
এই ডেটাতে, কনফিগারেশন সামঞ্জস্যতা সমস্যা বারবার দেখা গেছে: কমপ্যাকশন কী অবৈধ
এটি অপ্টিমাইজেশন মেকানিজমটি চুপচাপ বন্ধ করে দেবে।
সঠিক পদ্ধতি: কেবল সংস্করণ সামঞ্জস্যপূর্ণ কনফিগারেশন ব্যবহার করুন
তারপর যাচাই করুন:
openclaw doctor --fix
কমপ্যাকশন গ্রহণ করা হয়েছে কিনা তা স্টার্টআপ লগ চেক করুন।
P1— রিজনিং টেক্সট পারসিস্টেন্স কমানো
দীর্ঘ যুক্তির টেক্সটকে পুনরাবৃত্তি করা এড়ান
প্রোডাকশন পরিবেশে: পূর্ণাঙ্গ যুক্তির পরিবর্তে সংক্ষিপ্ত সারাংশ সংরক্ষণ করুন
P3—প্রম্পট ক্যাশিং ডিজাইন উন্নত করুন
লক্ষ্য হল ক্যাশে পড়াকে সর্বাধিক করা নয়। লক্ষ্য হল সংক্ষিপ্ত, স্থিতিশীল এবং উচ্চ মূল্যের প্রিফিক্সে ক্যাশে ব্যবহার করা।
পরামর্শ:
- স্থিতিশীল নিয়মগুলি সিস্টেম প্রম্পটে রাখুন
- অস্থিতিশীল ডেটা স্থিতিশীল প্রিফিক্সে রাখবেন না
- প্রতিটি রাউন্ডে বিপুল পরিমাণ ডিবাগ ডেটা ইনজেক্ট করা এড়িয়ে চলুন
ব্যবহারিক স্টপ-লস পরিকল্পনা (যদি আমি আগামীকাল এটি প্রক্রিয়া করি)
1. সর্বোচ্চ cacheRead অনুপাত সহ সেশনটি খুঁজুন
2. রানওয়ে সেশনের জন্য /compact ব্যবহার করুন
৩. টুল আউটপুটে ট্রাঙ্কেশন + আর্টিফ্যাক্ট যোগ করুন
4. প্রতিবার সংশোধনের পর টোকেন পরিসংখ্যান পুনরায় চালান
চারটি কেয়ে পিআই ট্র্যাক করুন:
ক্যাশ পড়ুন / মোট টোকেন
toolUse avgTotal/call
>=100k টোকেনের কল সংখ্যা
সর্বাধিক সেশন অংশীদারিত্ব
সফল সংকেত
যদি অপ্টিমাইজেশন কার্যকর হয়, তাহলে আপনি দেখতে পাবেন:
100k+ টোকেন কল উল্লেখযোগ্যভাবে কমে গেছে
ক্যাশ রিডের শতকরা হার কমেছে
টুলব্যবহার কল ওজন হ্রাস পেয়েছে
একটি সেশনের প্রভাব কমে গেছে
যদি এই সূচকগুলির কোনও পরিবর্তন না হয়, তাহলে আপনার প্রেক্ষাপট কৌশল এখনও খুব ঢিলেঢালা।
পরীক্ষার আদেশ পুনরায় বাস্তবায়ন করুন
python3 স্ক্রিপ্টস/সেশন_টোকেন_ব্রেকডাউন.py 'সেশনস' \
--include-deleted \
--শীর্ষ ২০ \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 স্ক্রিপ্টস/সেশন_ডুপ্লিকেট_ওয়েস্ট_অ্যানালিসিস.py 'সেশন' \
--include-deleted \
--শীর্ষ ২০ \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
শেষ কথা
যদি আপনার এজেন্ট সিস্টেম সবকিছু স্বাভাবিক দেখায়, কিন্তু খরচ ধারাবাহিকভাবে বাড়ছে, তাহলে প্রথমে একটি সমস্যা পরীক্ষা করুন: আপনি কি নতুন ইনফারেন্সের জন্য পেমেন্ট করছেন, নাকি পুরনো কনটেক্সট বড় পরিমাণে রিপ্লে করছেন?
আমার ক্ষেত্রে, বেশিরভাগ খরচ আসলে কনটেক্সট রিপ্লে থেকে আসে।
এটি বুঝতে পারলে সমাধানটি স্পষ্ট: দীর্ঘস্থায়ী কনটেক্সটে প্রবেশ করা ডেটাকে কঠোরভাবে নিয়ন্ত্রণ করুন।