ပုံများများပါတဲ့ agent turn တွေကို memory အတွင်း ထိန်းထားခြင်း

Production မှာ agent turn တစ်ခုက catalogue scan ခြောက်ခုကနေ ထုတ်ကုန်တွေကို ဖြတ်ယူပြီး ၎င်းရဲ့ crop တွေကို ပြန်ကြည့်နေစဉ် 952 MB မှာ memory ကုန်သွားခဲ့ပါတယ်။ leak တစ်ခုတည်း မဟုတ်ပါဘူး၊ သုံးခု ရှိပါတယ်။ model ကို ခေါ်တိုင်း turn ရဲ့ ပုံတွေကို အရွယ်အစားအပြည့်နဲ့ ပြန်ပို့နေတယ်။ model ခေါ်ဖို့ သုံးတဲ့ library က request တိုင်းကို turn ပြီးမှ ထားခဲ့တယ်။ agent framework ရဲ့ tracing က ခေါ်ဆိုမှုတစ်ခုချင်းစီရဲ့ input တွေ၊ ပုံတွေအပါအဝင်၊ turn တစ်ခုလုံး ထိန်းထားခဲ့တယ်။ သုံးခုလုံး ပြင်ပြီးပါပြီ– ပုံတွေကို မပို့ခင် ချုံ့ပြီး၊ ခေါ်ဆိုမှုတိုင်းရဲ့ ပုံတွေကို ခေါ်ဆိုမှု ပြီးတာနဲ့ လွှတ်ပေးပါတယ်။

agent က ပုံကို ဘယ်လို မြင်လဲ

Mythex မှာ တည်ဆောက်တဲ့အခါ agent က ပရောဂျက်ရဲ့ cloud sandbox ထဲမှာ အလုပ်လုပ်ပါတယ်။ သင် ထည့်တဲ့ screenshot၊ mockup၊ ပရောဂျက်ထဲက ဖိုင်၊ ဒါမှမဟုတ် ကိုယ်တိုင် ထုတ်လိုက်တဲ့ ပုံ– ဒါတွေကို စကားဝိုင်းနဲ့အတူ model ဆီ ပို့ပြီး ကြည့်နိုင်ပါတယ်။

turn ဆိုတာ သင့်မက်ဆေ့ချ်တစ်ခုကြောင့် agent လုပ်တဲ့ အရာအားလုံးပါ။ turn တစ်ခုအတွင်း agent က model ကို အကြိမ်များစွာ ခေါ်ပါတယ်– စဉ်းစား၊ tool run၊ ရလဒ်ကြည့်၊ ထပ်စဉ်းစား။ ခေါ်တိုင်း အထိ စကားဝိုင်းကို ပို့ပြီး၊ အဲဒီ turn ရဲ့ ပုံတွေ ပါလာပါတယ်၊ base64 စာသားအဖြစ် (ဒါက ဆိုဒ် သုံးပုံတစ်ပုံ ပိုကြီးစေပါတယ်)။

ပြိုကျသွားတဲ့ turn က ဖြစ်သင့်တဲ့အတိုင်း အလုပ်လုပ်နေတာပါ။ catalogue scan ခြောက်ခုကို ဖိုင်တစ်ခုလျှင် ~2.4 MB နဲ့ ယူပြီး ထုတ်ကုန်တစ်ခုချင်းစီကို ဖြတ်ထုတ်ကာ crop တွေကို ပြန်ဖတ်ပြီး စစ်ဆေးနေခဲ့တာပါ။ model ခေါ်ဆိုမှု အများကြီး ရှိပြီး ခေါ်တိုင်း ပုံကြီးများစွာ ပါနေပါတယ်။

အကြောင်းရင်း ၁– ခေါ်တိုင်း အရွယ်အပြည့်ပုံတွေကို ပြန်ပို့နေခြင်း

ခေါ်ဆိုမှုတိုင်း request body ကို ပြန်တည်ဆောက်ပြီး turn ရဲ့ ပုံတွေကို အပြည့်အစုံ ထည့်ထားပါတယ်– ခေါ်တိုင်း base64 ~20 MB။ body ကို agent ရဲ့ memory ထဲ string တစ်ခုအဖြစ် တည်ဆောက်တာမို့ ခေါ်တိုင်း ~20 MB အသစ် ခွဲယူနေတာပါ။

အရွယ်အပြည့်ပို့တာက အကျိုးမရှိပါဘူး။ model က ပုံကို အရှည်ဘက် ~1,300 pixel ခန့် ကိုယ်တိုင် ချုံ့ပါတယ်၊ ဒါကြောင့် အပိုပစ်ဆယ်တွေက memory နဲ့ upload အချိန်သာ ကုန်စေပါတယ်။

ပြင်ဆင်ချက်– တစ်ကြိမ်ချုံ့၊ သေးသေးပို့

• 400 KB ထက်ကြီးတဲ့ ပုံတွေကို မပို့ခင် ရှည်ဘက် 1,568 pixel ထက်မကျော်အောင် JPEG အဖြစ် ပြောင်းပါတယ်။ သေးတဲ့ပုံတွေကို ဘာမှ မလုပ်ပါ။
• ပြောင်းလဲမှုကို ImageMagick နဲ့ လုပ်ပြီး၊ Mythex sandbox တိုင်းမှာ ပါပြီးသားပါ၊ ဖိုင်တစ်ခုကို တစ်ကြိမ်သာ လုပ်ပါတယ်။ ခေါ်တိုင်း တူညီတဲ့ scan တွေ ပြတဲ့ turn က ချုံ့ပြီးသား မိတ္တူကို ပြန်သုံးပါတယ်။ cache က path၊ size နဲ့ ပြင်ဆင်ချိန်အလိုက် သိမ်းထားပါတယ်၊ ဖိုင်ပြင်ထားရင် ထပ်ပြောင်းပါတယ်၊ ကိုယ်ပိုင် အရွယ်ကန့်သတ်ချက်လည်း ရှိလို့ memory ကို မဖြည့်နိုင်ပါဘူး။
• ခေါ်ဆိုမှုတစ်ခုတည်းရဲ့ ပုံ budget ကို 16 MB ကနေ 6 MB သို့ လျှော့ပါတယ်။

ဒီ scan ခြောက်ခုကို ခေါ်တိုင်း 19.7 MB အစား 4.4 MB ပဲ ကုန်အောင် ပြောင်းလိုက်ပါပြီ။

အကြောင်းရင်း ၂– model client က request ကို လွှတ်မပေးခြင်း

request တစ်ခုချင်းစီရဲ့ အရွယ်အစားက တစ်စိတ်တစ်ပိုင်းပါ။ memory က ခေါ်ဆိုမှုတိုင်း တိုးလာတာလည်း ရှိပါတယ်။ staging မှာ ဒီလို turn က garbage collection အပြည့်ပြီးနောက်တောင် live memory 369 MB ကျန်နေခဲ့ပါတယ်။ heap sampling က အကုန် တိုးလာတာကို model client library ရဲ့ request body ကို encode လုပ်တဲ့ အပိုင်းမှာ တွေ့ခဲ့ပါတယ်။

အကြောင်းရင်းက abort listener ပါ။ Stop ကို နှိပ်လိုက်ရင် turn ရဲ့ abort signal က မီးလင်းပြီး၊ နားထောင်နေတဲ့ request တိုင်း ပယ်ဖျက်ပါတယ်။ ကျွန်တော်တို့က turn-wide signal တစ်ခုတည်းကို request အားလုံးကို ပေးထားခဲ့ပါတယ်။ client library က ပေးထားတဲ့ signal ပေါ်မှာ "abort" listener ထည့်ပြီး ဘယ်တော့မှ ပြန်မဖယ်ပါဘူး။

ဒါကြောင့် turn ရဲ့ request တိုင်းက turn ကြာသမျှ turn signal ကနေ ရောက်နိုင်နေပါတယ်– listener က controller ကို ကိုင်ထားပြီး controller က request ကို ကိုင်ထားပြီး request က ပုံပါတဲ့ body အပြည့်ကို ကိုင်ထားတာပါ။

ပြင်ဆင်ချက်– request တစ်ခုအတွက် signal တစ်ခု

အခု request တိုင်းက ကိုယ်ပိုင် signal ရပါတယ်။ ၎င်းက request ပြေးနေစဉ်မှာသာ turn signal နဲ့ ချိတ်ထားပြီး၊ streamed response အတွက် နောက်ဆုံး chunk ဖတ်ပြီးမှ၊ ချက်ချင်း ဖြုတ်ပါတယ်။ Stop ကတော့ ပြေးနေတဲ့ request ကို ရောက်ပါတယ်၊ turn signal မှာ listener တစ်ခုတည်းသာ ရှိပါတယ်။

စမ်းသပ်ချက်တွေက သုံးပိုင်းလုံးကို ဖုံးလွှမ်းပါတယ်–

• ခေါ်ဆိုမှု ၁၂ ကြိမ်ပြီးနောက် turn signal ပေါ်မှာ listener မရှိ တော့ပါ။ ပြင်ခင်က ၁၂ ခု ရှိခဲ့ပါတယ်။
• request ၈ MB ၁၅ ခုအကြား memory ငြိမ် နေပါတယ်။ ပြင်ခင်က 128 MB တိုးခဲ့ပါတယ်။
• Stop ကို နှိပ်ရင် stream အလယ်မှာ ပြေးနေတဲ့ request ကို ရပ်ပါတယ်။

အကြောင်းရင်း ၃– tracing က ခေါ်ဆိုမှုတိုင်း input တွေကို ထိန်းထားခြင်း

heap snapshot က သုံးခုမြောက် ထိန်းသူကို ပြပါတယ်– model ခေါ်ဆိုမှုတစ်ခုလျှင် ~6 MB။ ဒါက agent framework ရဲ့ event streaming ကနေ လာတာပါ။ turn ရဲ့ ခေါ်ဆိုမှုတိုင်းကို turn ရဲ့ child အဖြစ် မှတ်တမ်းတင်ပြီး input တွေပါ၊ turn ပြီးတဲ့အထိ ထိန်းထားပါတယ်။ ခေါ်ဆိုမှုတိုင်းရဲ့ ပုံတိုင်း memory ထဲမှာ ကျန်နေခဲ့ပါတယ်။

ပြင်ဆင်ချက်– ခေါ်ဆိုမှု ပြန်ရောက်ပြီးနောက် ပုံတွေကို ဖျက်ခြင်း

ပုံတွေကို model ခေါ်ဆိုမှုတစ်ခုအတွက် တည်ဆောက်ထားတဲ့ message တွေထဲမှာသာ ထည့်ပါတယ်။ စကားဝိုင်းရဲ့ သိမ်းထားတဲ့ state ထဲ ဘယ်တော့မှ မထည့်ပါဘူး။ ဒါကြောင့် ခေါ်ဆိုမှု ပြန်ရောက်ပြီးနောက် အဲဒီ message တွေက ပုံ data ကို ဖျက်ရုံ ဘေးကင်းပါတယ်။ trace ကတော့ ခေါ်ဆိုမှုရဲ့ စာသား မှတ်တမ်း ကျန်ပါမယ်၊ pixel တွေ ပျောက်ပါမယ်။

တစ်ခု အရေးကြီးပါတယ်– ပုံတွေကို နေရာတူမှာပဲ ဖျက်ရပါမယ်။ tracer က message တစ်ခုရဲ့ ပုံ data ကို reference တစ်ခုထက်ပိုပြီး ရောက်နိုင်တာမို့၊ list အသစ် ဗလာ ထည့်လိုက်ရင် မူရင်း pixel တွေ ဆက်ကျန်နေမှာပါ။ သိမ်းထားတဲ့ စကားဝိုင်း state ကို ဘယ်တော့မှ မပြောင်းပါ။

စမ်းသပ်ချက်တစ်ခုက agent graph ကို event streaming အောက်မှာ ပုံ 4 MB ခေါ်ဆိုမှုတိုင်းမှာ run ပါတယ်။ ပြင်မထားရင် ခေါ်ဆိုမှု ၁၆ ကြိမ်မှာ memory 77 MB တိုးခဲ့ပါတယ်။ ပြင်ထားရင် memory ငြိမ်နေပါတယ်။

ဒီကနေ ရလာတာတွေ

• Memory ပြဿနာတွေ အလွှာလိုက် ရှိနိုင်ပါတယ်။ အကြောင်းရင်း သုံးခုစလုံး ပုံတွေကို ကြာကြာ ကိုင်ထားပြီး၊ သုံးခုစလုံး ပြင်မှ turn က memory အတွင်း ရှိနိုင်ပါတယ်။
• library တစ်ခုကို ပေးလိုက်တာ ဘာမဆို ထိန်းထားနိုင်ပါတယ်။ signal နဲ့ trace နှစ်ခုစလုံး ၎င်းတို့ကို ပေးထားတဲ့ ခေါ်ဆိုမှုထက် ကြာပါတယ်။ ခေါ်ဆိုမှုတိုင်း memory တိုးနေရင် ခေါ်ဆိုမှုက ထိတွေ့တဲ့ ကြာရှည်တဲ့ object တွေကို ကြည့်ပါ။
• တဖက်က စွန့်ပစ်မယ့်အရာကို မပို့ပါနဲ့။ model က ဘယ်လိုမှ မသုံးမယ့် pixel တွေက ခေါ်တိုင်း memory ကုန်စေပါတယ်။
• memory ကို တိုက်ရိုက် စမ်းပါ။ ပြင်ဆင်ချက်တစ်ခုစီမှာ heap တိုးနှုန်း သို့မဟုတ် listener အရေအတွက် တိုင်းတဲ့ test ပါတယ်၊ ဒါကြောင့် regression တစ်ခုက crash မဟုတ်ဘဲ ဂဏန်းအဖြစ် ပေါ်ပါတယ်။

ဒါက agent ရဲ့ output နဲ့ ပတ်သက်တဲ့ memory အကြောင်း ဒုတိယ အကြိမ်ပါ။ ပထမတစ်ခုက string 41,000 ကြိမ် ပြန်ပို့နေတဲ့ progress label ဖြစ်ပါတယ်။ agent က ဘာလဲ၊ ဘယ်လို အလုပ်လုပ်လဲ သိချင်ရင် AI agents guide နဲ့ chat docs ကို ကြည့်ပါ။