इमेज-भरलेल्या एजंट टर्न्स मेमरीमध्ये राखणे

Production मध्ये एका एजंट टर्नची मेमरी 952 MB वर संपली. तो सहा कॅटलॉग स्कॅनमधून उत्पादने कापून त्यांचे crops पाहत होता. एकच leak नव्हता, तीन होते. मॉडेलला प्रत्येक call मध्ये टर्नच्या इमेजेस पूर्ण आकारात पुन्हा पाठवल्या जात होत्या; मॉडेल call करण्यासाठी वापरत असलेली library प्रत्येक request टर्न संपेपर्यंत जिवंत ठेवत होती; आणि एजंट framework चे tracing प्रत्येक call चे inputs, इमेजेससह, संपूर्ण टर्नभर ठेवत होते. आम्ही तिन्ही दुरुस्त केले: पाठवण्यापूर्वी इमेजेस लहान केल्या जातात, आणि प्रत्येक call च्या इमेजेस call संपताच सोडल्या जातात.

एजंट इमेजेस कशा पाहतो

Mythex वर बनवताना एजंट तुमच्या प्रोजेक्टच्या cloud sandbox मध्ये काम करतो. तो इमेजेस पाहू शकतो: तुम्ही जोडलेला screenshot, mockup, प्रोजेक्टमधील फाईल, किंवा त्याने स्वतः नुकतीच तयार केलेली इमेज. संभाषणासोबत त्या मॉडेलला पाठवून.

टर्न म्हणजे तुमच्या एका संदेशाला उत्तर म्हणून एजंट जे काही करतो ते सर्व. एका टर्नमध्ये एजंट मॉडेलला अनेक वेळा call करतो: विचार करणे, tool चालवणे, परिणाम पाहणे, पुन्हा विचार करणे. प्रत्येक call आतापर्यंतचे संभाषण पाठवतो, आणि त्यात टर्नच्या इमेजेस असतात, text म्हणून encode केलेल्या (base64, ज्यामुळे त्या सुमारे एक-तृतीयांश मोठ्या होतात).

जो टर्न क्रॅश झाला तो वाजवी गोष्ट करत होता. त्याने सहा कॅटलॉग स्कॅन घेतले, प्रत्येकी सुमारे 2.4 MB, त्यातून वैयक्तिक उत्पादने कापली, आणि त्याचे crops तपासण्यासाठी ते परत वाचत राहिला. म्हणजे अनेक मॉडेल calls, प्रत्येकात अनेक मोठ्या इमेजेस.

कारण 1: प्रत्येक call मध्ये पूर्ण आकाराच्या इमेजेस पुन्हा पाठवल्या जात होत्या

प्रत्येक मॉडेल call टर्नच्या इमेजेस पूर्ण आकारात ठेवून आपली request body पुन्हा तयार करत होता. म्हणजे सुमारे 20 MB base64 प्रति call. body एकाच string म्हणून एजंटच्या मेमरीत बांधली जाते, त्यामुळे प्रत्येक call आणखी सुमारे 20 MB वाटप करत होता.

पूर्ण आकार पाठवण्याचा काहीच फायदा नव्हता. मॉडेल इमेजेस स्वतः सुमारे 1,300 pixels च्या लांब बाजूपर्यंत कमी करते, त्यामुळे जास्तीचे pixels फक्त मेमरी आणि upload वेळ खर्च करत होते.

उपाय: एकदा लहान करा, लहान पाठवा

• 400 KB पेक्षा मोठ्या इमेजेस पाठवण्यापूर्वी JPEG मध्ये रूपांतरित केल्या जातात, ज्याची लांब बाजू जास्तीत जास्त 1,568 pixels. लहान इमेजेस जशाच्या तशा जातात.
• रूपांतरण ImageMagick वापरते, जे प्रत्येक Mythex sandbox मध्ये असते, आणि प्रत्येक फाईलसाठी एकदाच चालते. जो टर्न प्रत्येक call वर तीच स्कॅन दाखवतो तो लहान केलेली प्रत पुन्हा वापरतो. ती cache फाईलचा path, आकार आणि modification time यावरून ठरते, त्यामुळे बदललेली फाईल पुन्हा रूपांतरित होते. आणि तिला स्वतःची आकार मर्यादा आहे, जेणेकरून ती स्वतः मेमरी भरणारी गोष्ट होऊ नये.
• एका मॉडेल call मधील इमेजेसचे बजेट 16 MB वरून 6 MB झाले.

तेच सहा स्कॅन आता प्रति call 19.7 MB ऐवजी 4.4 MB खर्च करतात.

कारण 2: मॉडेल client ने request कधीच सोडली नाही

प्रत्येक request किती मोठी आहे हा भाग फक्त अर्धा होता. मेमरी call नंतर call वाढत होती. आमच्या staging वातावरणात, त्याच प्रकारचा टर्न पूर्ण garbage collection नंतरही 369 MB जिवंत मेमरी धरून होता, म्हणजे जे काही पोहोचता येत नाही ते मोकळे झाल्यानंतर. Heap sampling ने सर्व वाढ मॉडेल client library च्या त्या भागात दाखवली जो request bodies encode करतो.

कारण एक abort listener होता. तुम्ही Stop दाबता तेव्हा टर्नचा abort signal उडतो, आणि त्याचे ऐकणारी प्रत्येक request रद्द होते. आम्ही तो एकच टर्न-व्यापी signal प्रत्येक request ला देत होतो. Client library कोणत्याही signal ला एक “abort” listener जोडते आणि तो कधीच काढत नाही.

त्यामुळे टर्नची प्रत्येक request टर्न चालू असेपर्यंत टर्नच्या signal पासून पोहोचण्याजोगी राहिली: listener, जो controller धरतो, जो request धरतो, जो images सह संपूर्ण request body धरतो.

उपाय: प्रत्येक request ला स्वतःचा signal

आता प्रत्येक request ला स्वतःचा signal मिळतो. तो फक्त ती request चालू असतानाच टर्नच्या signal शी जोडलेला असतो, streamed response साठी शेवटचा chunk वाचला जाईपर्यंत, आणि नंतर लगेच वेगळा केला जातो. Stop तरीही सुरू असलेल्या कोणत्याही request पर्यंत पोहोचतो, पण टर्नच्या signal वर एका वेळी फक्त एक listener असतो.

चाचण्या या तिन्ही भागांना कव्हर करतात:

• 12 calls नंतर टर्नच्या signal वर कोणताही listener उरत नाही. दुरुस्तीआधी 12 होते.
• 8 MB च्या 15 requests वर मेमरी स्थिर राहते. आधी ती 128 MB ने वाढली.
• Stop तरीही एखाद्या request ला तिच्या stream च्या मध्यावर abort करतो.

कारण 3: tracing ने प्रत्येक call चे inputs ठेवले

Heap snapshot मध्ये तिसरा धरणारा दिसला: प्रति मॉडेल call सुमारे 6 MB. हे एजंट framework च्या event streaming मधून आले. ते टर्नमधील प्रत्येक मॉडेल call टर्नचे child म्हणून नोंदवते, inputs सह, टर्न संपेपर्यंत. प्रत्येक call ला जोडलेली प्रत्येक इमेज त्यासोबत मेमरीत राहत होती.

उपाय: call परत आल्यावर इमेजेस रिकाम्या करा

इमेजेस फक्त एका विशिष्ट मॉडेल call साठी बांधलेल्या messages ला जोडलेल्या असतात. त्या कधीच conversation च्या saved state मध्ये साठवल्या जात नाहीत. त्यामुळे call परत आल्यावर त्या messages मधील इमेज data रिकामी करणे सुरक्षित आहे. Trace मध्ये call ची मजकूर नोंद राहते; pixels जातात.

एक तपशील महत्त्वाचा होता: इमेजेस जागेवरच रिकाम्या कराव्या लागतात. Tracer एकाच message वरील एकाच इमेज data पर्यंत एकापेक्षा जास्त references मधून पोहोचू शकतो, त्यामुळे नवीन रिकामी list ठेवली तर मूळ — pixels सह — तरीही पोहोचण्याजोगी राहील. Saved conversation state कधीच बदलला जात नाही.

एक चाचणी एजंटचा graph त्याच event streaming खाली चालवते, प्रत्येक call वर 4 MB इमेजसह. दुरुस्तीशिवाय 16 calls मध्ये मेमरी 77 MB ने वाढली. दुरुस्तीसह ती स्थिर राहते.

आम्ही काय शिकलो

• मेमरी समस्या थरांमध्ये येऊ शकतात. तीन वेगळी कारणे प्रत्येकाने इमेजेस खूप वेळ धरली, आणि टर्न मेमरीत राहण्यासाठी तिन्ही गेली पाहिजेत.
• लायब्रीला दिलेले काहीही ठेवले जाऊ शकते. Signal आणि trace दोघेही ज्या calls साठी दिले होते त्यांच्यापेक्षा जास्त जगले. मेमरी प्रति call वाढत असेल तर call कोणत्या दीर्घकाळ जगणाऱ्या objects ला स्पर्श करते ते पहा.
• समोरच्याने फेकून देणारे पाठवू नका. मॉडेल तरीही टाकून देणारे pixels आम्हाला प्रत्येक call वर मेमरी खर्च करत होते.
• मेमरी थेट चाचणी करा. प्रत्येक दुरुस्तीसोबत heap वाढ किंवा listener संख्या मोजणारी चाचणी आली, त्यामुळे regression एका क्रॅशऐवजी एका आकड्याच्या रूपात दिसते.

एजंटकडून आलेली ही अलीकडची दुसरी मेमरी कथा आहे; पहिली प्रगती label ने दर 41,000 वेळा पाठवलेली होती. एजंट म्हणजे काय आणि तो कसा काम करतो हे जाणायचे असेल तर AI agents वरील guide आणि chat docs पहा.