اوپنکلو سیشن ایک دن میں 21.5 ملین ٹوکن جلا دیتی ہے، بہتری کی حکمت عملیاں لاگت کم کرتی ہیں

کیوں میرے اوپنکلॉ سیشنز نے ایک دن میں 21.5 ملین ٹوکنز جلائے (اور اس کا اصلی حل کیا تھا)

ماشی III

پیگی، بلاک بیٹس

ایڈیٹورل نوٹ: ایجینٹ ایپلیکیشنز کے تیزی سے عام ہونے کے دوران، کئی ٹیمیں ایک عجیب ظاہری مسئلہ کا تجربہ کرتی ہیں: سسٹم مکمل طور پر درست طریقے سے کام کر رہا ہے، لیکن ٹوکن لاگت غیر متوقع طور پر لگاتار بڑھ رہی ہے۔ اس مضمون میں، ایک حقیقی OpenClaw ورک لوڈ کے تجزیہ سے پتہ چلتا ہے کہ لاگت میں اچانک اضافہ عام طور پر صارف کے ان پٹ یا ماڈل کے آؤٹ پٹ سے نہیں، بلکہ نظر انداز کیے جانے والے کیشڈ پریفکس ری پلے (cached prefix replay) سے ہوتا ہے۔ ماڈل ہر کال میں بڑے حجم کے تاریخی سندھ کو دوبارہ پڑھتا ہے، جس سے بہت زیادہ ٹوکن استعمال ہوتے ہیں۔

یہ مضمون مخصوص سیشن ڈیٹا کے ساتھ ملا کر دکھاتا ہے کہ ٹول کے آؤٹ پٹ، براؤزر اسناپشٹ، JSON لاگ جیسے بڑے درمیانی پیداوار کو کیسے لگاتار تاریخی سیاق و سباق میں لکھا جاتا ہے اور ایجنٹ سائکل میں دوبارہ پڑھا جاتا ہے۔

اس کیس میں، مصنف نے ایک واضح بہتری کا طریقہ کار پیش کیا ہے: متن کی ساخت، ٹول کے آؤٹ پٹ کے انتظام اور کمپیکشن میکنزم کی ترتیب تک۔ ایجینٹ سسٹم بنانے والے ڈویلپرز کے لیے، یہ صرف ایک ٹیکنیکل ٹربل شوٹنگ ریکارڈ نہیں بلکہ ایک سچی اور قیمتی بچت کا راستہ بھی ہے۔

درج ذیل اصل متن ہے:

میں نے ایک حقیقی OpenClaw ورک لوڈ کا تجزیہ کیا، جس میں میں نے ایک ایسا نمونہ دریافت کیا جسے بہت سارے ایجینٹ صارفین پہچان سکتے ہیں:

ٹوکن کا استعمال بہت "فعال" لگ رہا ہے

جواب بھی عام لگ رہا ہے

لیکن ٹوکن کی استعمال کی شرح اچانک بہت تیزی سے بڑھ گئی

اس تجزیے کی ساخت، بنیادی وجوہات، اور عملی حل کے راستے درج ذیل ہیں۔

سب سے بڑا لاگت کا عامل صرف اس لیے نہیں کہ صارف کے پیغامات لمبے ہیں، بلکہ اس لیے ہے کہ بہت زیادہ کیشڈ پریفکس (cached prefix) دوبارہ دوبارہ پلے ہو رہے ہیں۔

سیشن ڈیٹا کے مطابق:

کل ٹوکنز: 21,543,714

کیش پڑھی گئی: 17,105,970 (79.40%)

4,345,264 (20.17%)

آؤٹ پٹ: 92,480 (0.43%)

دوسرے الفاظ میں: زیادہ تر کالوں کی لاگت، نئے صارف کے ارادوں کو سمجھنے کے بجائے، بڑے تاریخی سیاق و سباق کو دہرانے میں لگ رہی ہے۔

میں نے اصل میں سوچا تھا کہ ٹوکن کے زیادہ استعمال کا سبب بہت لمبے صارف پرامپٹ، زیادہ آؤٹ پٹ جنریشن، یا مہنگے ٹول کالز ہوں گے۔

لیکن حقیقی طور پر مسلط ماڈل یہ ہے:

کئی سو سے لے کر کئی ہزار ٹوکن

cacheRead: ہر کال پر 170,000 سے 180,000 ٹوکن

یعنی، ماڈل ہر راؤنڈ میں ایک ہی بڑا مستقل پریفکس دوبارہ پڑھ رہا ہے۔

میں نے دو سطحوں کے ڈیٹا کا تجزیہ کیا:

1. رن ٹائم لاگس

2، سیشن ریکارڈز

یہ قابل ذکر ہے کہ:

运行日وز کا استعمال عام طور پر رویے کے سگنلز (جیسے ریسٹارٹ، ایرر، کانفیگریشن مسائل) کا مشاہدہ کرنے کے لیے کیا جاتا ہے۔

ٹوکن کی درست تعداد session JSONL کے usage فیلڈ سے حاصل کی جاتی ہے

استعمال کیا جانے والا اسکرپٹ:

اسکرپٹس/سیشن_ٹوکن_بریکڈاؤن.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

مسئلہ بنیادی طور پر ٹول کال چین کے سائیکل میں ہے، عام چیٹ نہیں۔

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 اسناپ

فائلوں کی فہرست

براؤزر ڈیٹا حاصل کر رہا ہے

سوب ایجنٹ کا مکالمہ ریکارڈ

سب سے بڑے سیشن میں حروف کی تعداد تقریباً ہے:

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 کریکٹرز)

میں نے ایک ہی کال کے اندر دہرائے گئے مواد کا تناسب بھی ناپا:

دوہرائی جانے والی فیصد تقریباً: 1.72%

یہ حقیقت میں موجود ہے، لیکن اس کا بنیادی مسئلہ نہیں ہے۔

اصل مسئلہ یہ ہے کہ کیش پریفکس کا مطلق حجم بہت زیادہ ہے

ساخت یہ ہے: وسیع تاریخی سیاق، ہر کال پر دوبارہ پڑھنا، اور صرف کچھ نئے ان پٹ کو اوپر جوڑنا

اس لیے بہترین بنانے کا مرکزی نقطہ دہرائی کو ختم کرنا نہیں، بلکہ سیاق و سباق کی ساخت ڈیزائن کرنا ہے۔

تین مکینزم ایک دوسرے پر叠加 ہوتے ہیں:

1، بہت سارے ٹولز کے آؤٹ پٹ کو تاریخی کنٹیکس میں لکھ دیا گیا ہے

2، ٹول سائکل سے بہت زیادہ مختصر انٹروال کے کالز پیدا ہوتے ہیں

3، پریفکس میں بہت کم تبدیلی → کیش ہر بار دوبارہ پڑھا جائے گا

اگر کنٹیکسٹ کمپیکشن مستقل طور پر فعال نہیں ہوتا، تو مسئلہ جلد بڑھ جائے گا۔

P0—بڑے ٹول آؤٹپٹ کو لمبے وقت کے کانٹیکسٹ میں نہ ڈالیں

بہت بڑے ٹول کے لیے آؤٹ پٹ:

• خلاصہ برقرار رکھیں + حوالہ راستہ / شناخت کار
• اصل پیلوز کو فائل آرٹیفیکٹ میں لکھیں
• پورا اصل متن کو چیٹ تاریخ میں نہ رکھیں

ان شرحوں کو ترجیح دیں:

• بڑا JSON
• لمبی فہرست
• براؤزر کا مکمل اسناپ
• سوب ایجنٹ مکمل ٹرانسکرپٹ

P1—یہ یقینی بنائیں کہ کمپیکشن میکنزم حقیقت میں کام کر رہا ہے

اس ڈیٹا میں، کنفیگریشن کمپیٹیبلٹی مسائل کئی بار ظاہر ہوئے: کمپیکشن کی غلط ہے

یہ تہہ کی گئی بہترین سہولت کو بند کر دے گا۔

درست طریقہ: صرف مطابقت پذیر ترتیبات استعمال کریں

پھر تصدیق کریں:

openclaw doctor --fix

اور شروع کرنے کے لاگ کو چیک کریں تاکہ یہ تصدیق کی جا سکے کہ کمپیکشن قبول کر لیا گیا ہے۔

P1— reasoning ٹیکسٹ کی مسلسل محفوظ کرنا کم کریں

طویل استدلال کے متن کو دوبارہ ری پلے نہ کریں

پروڈکشن ماحول میں: مکمل وجہ کی بجائے مختصر خلاصہ محفوظ کریں

P3 — پرامپٹ کیش ڈیزائن میں بہتری

ہدف cacheRead کو زیادہ سے زیادہ نہیں کرنا ہے۔ ہدف ہے کہ کمپیکٹ، مستحکم اور اعلیٰ قیمت والے پریفکس پر cache کا استعمال کیا جائے۔

سجھاؤ:

• سٹیبل رولز کو سسٹم پرامپٹ میں ڈال دیں
• بے ثبات ڈیٹا کو استحکام کے پیش لفظ میں مت ڈالیں
• ہر راؤنڈ میں زیادہ ڈیبگ ڈیٹا کا اضافہ نہ کریں

1. سب سے زیادہ cacheRead کا تناسب والی سیشن تلاش کریں

2. runaway session کے لیے /compact کریں

3. ٹول کے آؤٹ پٹ میں کٹ آف + آرٹیفیکٹ کو شامل کریں

4. ہر تبدیلی کے بعد ٹوکن کی گنتی دوبارہ کریں

چار KPI پر توجہ مرکوز کریں:

کیش پڑھیں / کل ٹوکنز

ٹول استعمال کریں avgTotal/call

100k ٹوکن یا اس سے زیادہ کے کالز

زیادہ سے زیادہ سیشن کا تناسب

اگر بہتری کام کرتی ہے، تو آپ کو دکھائی دینا چاہیے:

100k+ ٹوکن کالز میں واضح کمی

کیش ریڈ کا تناسب کم ہو گیا

ٹول استعمال کی وزن کم ہو گیا

ایک سیشن کی اہمیت کم ہو گئی ہے

اگر یہ اشارے تبدیل نہیں ہوئے، تو یہ ظاہر کرتا ہے کہ آپ کی سیاق و سباق کی حکمت عملی اب بھی بہت آزاد ہے۔

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 اسکرپٹس/سیشن_ڈپلیکیٹ_ویسٹ_اینالیسس.py 'سیشنز' \

--include-deleted \

--ٹاپ 20 \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

اگر آپ کا ایجینٹ سسٹم مکمل طور پر درست لگ رہا ہے لیکن لاگت لگاتار بڑھ رہی ہے، تو پہلے ایک مسئلہ کی جانچ کریں: کیا آپ نئے انفرینس کے لیے ادائیگی کر رہے ہیں یا پرانے کنٹیکسٹس کو بڑے پیمانے پر دوبارہ چلا رہے ہیں؟

میرے معاملے میں، زیادہ تر لاگت دراصل کنٹیکس ری پلے سے آتی ہے۔

جب آپ اس بات کو سمجھ لیں، تو حل واضح ہو جاتا ہے: لمبے متن میں داخل ہونے والے ڈیٹا پر سخت کنٹرول رکھیں۔

اصل لنک