تصویروں سے بھرے ایجنٹ turns کو memory کے اندر رکھنا

پیداوار (production) میں ایک ایجنٹ turn 952 MB پر memory ختم ہو گیا، جب وہ چھ catalogue scans میں سے پروڈکٹس کاٹ رہا تھا اور اپنے کراپس دیکھ رہا تھا۔ وجہ ایک leak نہیں تھی، تین تھیں۔ model کو ہر call پر turn کی تصاویر پورے سائز میں دوبارہ بھیجی جا رہی تھیں؛ وہ library جو ہم model کو call کرنے کے لیے استعمال کرتے ہیں، ہر request کو turn کے ختم ہونے تک زندہ رکھتی تھی؛ اور ایجنٹ فریم ورک کی tracing ہر call کے inputs، بشمول تصاویر، پورے turn کے لیے رکھے ہوئے تھی۔ ہم نے تینوں ٹھیک کر دیے: تصاویر بھیجنے سے پہلے چھوٹی کی جاتی ہیں، اور ہر call کی تصاویر اس call کے ختم ہوتے ہی چھوڑ دی جاتی ہیں۔

ایجنٹ تصاویر کیسے دیکھتا ہے

Mythex پر آپ کسی چیز کو بناتے ہیں تو ایجنٹ آپ کے پروجیکٹ کے cloud sandbox کے اندر کام کرتا ہے۔ وہ تصاویر دیکھ سکتا ہے: آپ کا منسلک screenshot، کوئی mockup، آپ کے پروجیکٹ کی کوئی فائل، یا وہ تصویر جو اس نے خود ابھی بنائی ہو۔ یہ تصاویر conversation کے ساتھ model کو بھیجی جاتی ہیں۔

ایک turn وہ سب کچھ ہے جو ایجنٹ آپ کے ایک پیغام کے جواب میں کرتا ہے۔ ایک turn کے اندر ایجنٹ model کو کئی بار call کرتا ہے: سوچتا ہے، ایک tool چلاتا ہے، نتیجہ دیکھتا ہے، پھر دوبارہ سوچتا ہے۔ ہر call اب تک کی conversation بھیجتی ہے، اور اس میں turn کی تصاویر بھی شامل ہیں، جو text کے طور پر encode ہوتی ہیں (base64، جس سے وہ تقریباً ایک تہائی بڑی ہو جاتی ہیں)۔

جو turn crash ہوا وہ ایک معقول کام کر رہا تھا۔ اس نے چھ catalogue scans لیے، جن میں سے ہر ایک تقریباً 2.4 MB کا تھا، ان میں سے انفرادی پروڈکٹس کاٹے، اور اپنے کراپس واپس پڑھ کر چیک کرتا رہا۔ یہ بہت سی model calls تھیں، اور ہر ایک میں کئی بڑی تصاویر تھیں۔

وجہ 1: ہر call پورے سائز کی تصاویر دوبارہ بھیجتی تھی

ہر model call اپنی request کا body دوبارہ بناتی تھی، جس میں turn کی تصاویر پورے سائز میں تھیں: تقریباً 20 MB base64 فی call۔ body ایجنٹ کی memory میں ایک string کے طور پر بنتی ہے، اس لیے ہر call ایک اور تقریباً 20 MB allocate کرتی تھی۔

پورے سائز میں بھیجنے سے کچھ حاصل بھی نہیں ہوتا تھا۔ model خود تصاویر کو لمبی طرف تقریباً 1,300 pixels تک گھٹا دیتا ہے، اس لیے اضافی pixels صرف memory اور upload کا وقت لیتے تھے۔

حل: ایک بار چھوٹا کریں، چھوٹا بھیجیں

• 400 KB سے بڑی تصاویر کو بھیجنے سے پہلے JPEG میں بدلا جاتا ہے، جس کی لمبی طرف زیادہ سے زیادہ 1,568 pixels ہوتے ہیں۔ چھوٹی تصاویر جیسی ہیں ویسی ہی جاتی ہیں۔
• تبدیلی ImageMagick سے ہوتی ہے، جو ہر Mythex sandbox میں موجود ہے، اور ہر فائل کے لیے ایک بار چلتی ہے۔ ایسا turn جو ہر call پر وہی scans دکھاتا ہے، چھوٹی کی گئی کاپی دوبارہ استعمال کرتا ہے۔ یہ cache فائل کے path، سائز اور آخری تبدیلی کے وقت سے شناخت ہوتا ہے، اس لیے بدلی ہوئی فائل دوبارہ تبدیل ہوتی ہے، اور اس کی اپنی سائز کی حد ہے تاکہ خود memory نہ بھرے۔
• ایک model call میں تصاویر کا بجٹ 16 MB سے گھٹ کر 6 MB ہو گیا ہے۔

وہی چھ scans اب فی call 4.4 MB بنتے ہیں، پہلے 19.7 MB کے بجائے۔

وجہ 2: model client کبھی request کو چھوڑتا نہیں تھا

ہر request کا سائز صرف ایک حصہ تھا۔ memory بھی call در call بڑھتی جا رہی تھی۔ ہمارے staging environment پر ایسا ہی turn، مکمل garbage collection کے بعد بھی 369 MB live memory رکھے ہوئے تھا، یعنی وہ مقام جہاں ہر ناقابلِ رسائی چیز آزاد ہو چکی ہوتی ہے۔ heap sampling نے سارا اضافہ model client library کے اس حصے میں دکھایا جو request bodies کو encode کرتا ہے۔

وجہ ایک abort listener تھا۔ جب آپ Stop دباتے ہیں تو turn کا abort signal فائر ہوتا ہے، اور ہر چلتی request منسوخ ہو جاتی ہے۔ ہم ہر request کو turn کا ایک ہی signal دے رہے تھے۔ client library کسی بھی signal میں “abort” listener شامل کرتی ہے، اور اسے کبھی ہٹاتی نہیں۔

اس لیے turn کی ہر request turn کے signal سے جڑی رہتی تھی، turn کے پورے دورانیے کے لیے: listener، جو controller کو تھامے ہوئے تھا، جو request کو، جو پورے request body کو، تصاویر سمیت، تھامے ہوئے تھا۔

حل: ہر request کا اپنا signal

اب ہر request کا اپنا signal ہے۔ وہ turn کے signal سے صرف اس وقت جڑا ہوتا ہے جب وہ request چل رہی ہو، streamed response کے لیے آخری chunk پڑھے جانے تک، اور اس کے فوراً بعد الگ کر دیا جاتا ہے۔ Stop اب بھی چلتی ہوئی request تک پہنچتا ہے، مگر turn کے signal پر ایک وقت میں صرف ایک listener رہتا ہے۔

ٹیسٹ اس کے تینوں حصے کو کور کرتے ہیں:

• 12 calls کے بعد turn کے signal پر کوئی listener باقی نہیں۔ fix سے پہلے 12 تھے۔
• 8 MB کی 15 requests پر memory ہموار رہتی ہے۔ پہلے وہ 128 MB بڑھ گئی تھی۔
• Stop اب بھی stream کے بیچ میں چلتی request کو abort کرتا ہے۔

وجہ 3: tracing ہر call کے inputs رکھتی تھی

ایک heap snapshot نے تیسرا holder دکھایا: ہر model call کے لیے تقریباً 6 MB۔ یہ ایجنٹ فریم ورک کی event streaming سے آ رہا تھا۔ یہ turn میں ہر model call کو turn کے بچے کے طور پر ریکارڈ کرتی ہے، inputs سمیت، turn کے ختم ہونے تک۔ ہر call کی ہر تصویر اس کے ساتھ memory میں رہتی تھی۔

حل: call واپس آنے پر تصاویر خالی کریں

تصاویر صرف اس model call کے لیے بنائے گئے messages کے ساتھ منسلک ہوتی ہیں۔ وہ کبھی conversation کی محفوظ state میں نہیں رکھی جاتیں۔ اس لیے call واپس آنے کے بعد ان messages میں تصویر کا ڈیٹا خالی کرنا محفوظ ہے۔ trace میں call کا text ریکارڈ رہتا ہے؛ pixels چلے جاتے ہیں۔

ایک بات اہم تھی: تصاویر کو اسی جگہ پر خالی کرنا ہوتا ہے۔ tracer ایک message پر موجود ایک ہی تصویر کے ڈیٹا تک ایک سے زیادہ references کے ذریعے پہنچ سکتا ہے، اس لیے نئی خالی list رکھنے سے اصل (pixels سمیت) اب بھی قابلِ رسائی رہتی۔ محفوظ conversation کی state کبھی نہیں بدلتی۔

ایک ٹیسٹ ایجنٹ کے graph کو اسی event streaming کے ساتھ چلاتا ہے، جس میں ہر call پر 4 MB کی تصویر ہے۔ fix کے بغیر 16 calls پر memory 77 MB بڑھی۔ fix کے ساتھ وہ ہموار رہتی ہے۔

ہم نے کیا سیکھا

• Memory کے مسائل تہوں میں آ سکتے ہیں۔ تین الگ وجوہات میں سے ہر ایک تصاویر کو زیادہ دیر تک رکھتی تھی، اور تینوں کو ہٹانا پڑا تاکہ turn memory کی حد میں رہے۔
• جو کچھ آپ کسی library کو دیں وہ رکھا جا سکتا ہے۔ ایک signal اور ایک trace دونوں اپنی call سے زیادہ دیر تک زندہ رہے۔ جب memory فی call بڑھے تو دیکھیں کہ call کون سی طویل مدتی چیزوں کو چھوتی ہے۔
• وہ نہ بھیجیں جو دوسری طرف پھینک دی جائے گی۔ وہ pixels جو model بہرحال رد کر دیتا، ہر call پر ہماری memory کھا رہے تھے۔
• Memory کو براہِ راست جانچیں۔ ہر fix کے ساتھ ایک ٹیسٹ آیا جو heap کی بڑھوتری یا listeners کی گنتی ناپتا ہے، تاکہ regression ایک crash کے بجائے ایک عدد کے طور پر ظاہر ہو۔

یہ ایجنٹ کی دوسری memory کہانی ہے، ایک مختصر عرصے میں۔ پہلی وہ تھی جس میں ایک progress label 41,000 بار دوبارہ بھیجا گیا۔ اگر آپ جاننا چاہتے ہیں کہ ایجنٹ کیا ہے اور کیسے کام کرتا ہے، تو ہماری AI ایجنٹس گائیڈ اور chat docs دیکھیں۔