Progress Label ထဲတွင် ဝှက်ထားသော Out-of-Memory ပြဿနာ

၂၀၂၆ စက်တင်ဘာ နှောင်းပိုင်းညတစ်ညတွင် အသုံးပြုသူ၏ workspace ရှိ AI agent သည် turn တစ်ခု အလယ်တွင် out-of-memory error ဖြင့် ပျက်သွားခဲ့သည်။ လူတိုင်း ထင်မှတ်သော အကြောင်းရင်းနှစ်ခုမှာ sub-agent များ တပြိုင်နက် များလွန်းခြင်း၊ သို့မဟုတ် context ကြီးလွန်းခြင်း ဖြစ်သည်။ နှစ်ခုလုံး မှားခဲ့သည်။ အမှန်တကယ် အကြောင်းရင်းမှာ status label တစ်ခု ဖြစ်သည်။ Model က shell command ကြီးတစ်ခုကို စာလုံးအနည်းငယ်စီ stream လုပ်နေစဉ် ကျွန်ုပ်တို့က label ကို အပိုင်းတိုင်း၌ ယခုအထိ command အပြည့်အစုံ ဖြင့် ပြန်ပို့ခဲ့သည်။ KB ၁၂၄ command တစ်ခုသည် event ပေါင်း ၄၁,၀၀၀ ခန့်နှင့် string ဖြင့် queue တွင် ~၆၉၀ MB ဖြစ်သွားသည်။

Agent က အလုပ်ကို ဘယ်လို stream လုပ်သလဲ

Mythex တွင် တည်ဆောက်သောအခါ agent သည် project ၏ private cloud sandbox အတွင်း run သည်။ Model ရေးနေစဉ် output သည် browser သို့ stream ပြန်ရောက်သည်။ စာသားများ စကားလုံးအလိုက် ပေါ်လာပြီး tool တစ်ခု run လျှင် (ဥပမာ ဖိုင်ရေးသော shell command) label တစ်ခု live ပြောင်းသွားသဖြင့် ဘာလုပ်နေသည်ကို သိနိုင်သည်။

Model သည် အစိတ်အပိုင်းငယ်များဖြင့် stream လုပ်သည်။ ကျွန်ုပ်တို့ သုံးနေသော model ဖြင့် အတုံးတစ်ခုသည် မကြာခဏ စာလုံး သုံးလုံး သာ ရှိသည်။

ပထမ အယူအဆများ မှားခဲ့သည်

Crash သည် scaling ပြဿနာကဲ့သို့ ပေါ်နေသဖြင့် ထိုနေရာမှ စတင်ကြည့်ခဲ့သည်။

• Sub-agent တပြိုင်နက်များလား? Turn တွင် sub-agent နှစ်ခုသာ သုံးခဲ့ပြီး တစ်ခုစီ ~၁.၅ MB state ကိုင်ထားသည်။ မလုံလောက်ပါ။
• Trace များ ဆက်ထိန်းထားခြင်းလား? Tracing က run tree ကို memory တွင် ထားသော်လည်း crash ချိန် heap အရွယ်အစားနှင့် နီးစပ်မှု မရှိပါ။

နှစ်ခုစလုံး ယုံလောက်ဖွယ် ရှိသော်လည်း ဘယ်တစ်ခုမှ crash ကို ပြန်မပြနိုင်ခဲ့ပါ။ ကျွန်ုပ်တို့ ထပ်ခါထပ်ခါ သင်ယူရသော သင်ခန်းစာ: ပျက်ကွက်မှုကို ပြန်ဖြစ်အောင် မလုပ်နိုင်သေးလျှင် အယူအဆသည် အကြောင်းရင်း မဟုတ်သေးပါ။

အမှန်တကယ် ပြန်ဖြစ်အောင် လုပ်ခြင်း

Production နှင့် တူညီသော memory limit ရှိသော ယာယီ sandbox တစ်ခုကို တည်ဆောက်ပြီး ဖိုင်ကြီးကို စာလုံး သုံးလုံးစီ ရေးသော အတု model တစ်ခု ထည့်ခဲ့သည်။ ဆုံးဖြတ်ချက်ဖြစ်စေရန် အခြား ဘက်ရှိ reader ကို ကွန်ရက်ကဲ့သို့ နှေးစေခဲ့သည်။

ထိုအချိန် crash ပြန်ဖြစ်ခဲ့သည်။ Heap တက်လာပြီး process သည် တူညီသော error ဖြင့် သေသွားသည်။

ယန္တရားမှာ မြင်ရပြီးနောက် ရိုးရှင်းသည်။ Model က ကြီးမားသော command တစ်ခု (ဤအခြေအနေတွင် KB ၁၂၄ ဖိုင်ကို ရေးသော heredoc) ရေးနေစဉ် stream code က tool ၏ label ကို အပိုင်းတိုင်းတွင် update လုပ်သည်။ Label သည် အသစ် စာလုံး သုံးလုံး မဟုတ်ဘဲ ယခုအထိ command အပြည့် ဖြစ်သည်။ ထို့ကြောင့် event များ ကြီးလာသည်: စာလုံး ၃၊ ထို့နောက် ၆၊ ၉ … KB ၁၂၄ အထိ ~၄၁,၀၀၀ ကြိမ်။ Socket က ထုတ်ပေးသည်ထက် မြန်မြန် မပို့နိုင်သဖြင့် write buffer တွင် string အဖြစ် စုပုံသွားပြီး ~၆၉၀ MB ဖြစ်သည်။

ပြင်ဆင်ချက်

• Label ကို ကန့်သတ်ပါ။ Status label သည် ဘာဖြစ်နေသည်ကိုသာ ပြောရန် လိုသည်။ ယခု စာလုံး ၂၀၀ ဖြင့် ကန့်သတ်ထားပြီး partial command ကို ပြန်စကင်ပြုလုပ်မှု ကြိမ်နှုန်းကို throttle လုပ်သည်။
• Quadratic concatenation ကို ရပ်ပါ။ Stream လုပ်သော အပိုင်းများကို string ထပ်ပေါင်းခြင်းသည် output ကြီးအတွက် O(n²) ဖြစ်သည်။ Chunk အခြေခံ နည်းလမ်းသို့ ပြောင်းပြီး linear အချိန်ဖြင့် ထည့်သည်။

ထို့နောက် flood output အပေါ် အကန့်အသတ်မရှိ ကြီးလာနိုင်သော အခြားအရာများကို ရှာပြီး ကန့်သတ်ခဲ့သည်:

• Chat တွင် ပြသသော command output တိုက်ရိုက် ကို batch လုပ်ပြီး နောက်ဆုံး ၈,၀၀၀ စာလုံးသာ ထိန်းသည်။
• Event လိုင်းတစ်ခုချင်းစီကို ၄ MB ဖြင့် ကန့်သတ်သည်။
• Browser ပြန်ချိတ်ဆက်ပြီး နောက်မှ ဖမ်းယူရန် replay buffer ကို project တစ်ခုလျှင် ၈ MB ဖြင့် ကန့်သတ်သည်။
• Turn ဖြစ်စဉ် အဟောင်း checkpoint များကို prune လုပ်ပြီး နောက်ဆုံးအခြေအနေနှင့် အရင် turn များလိုအပ်သော anchor များကို ထိန်းထားသည်။

Flood များကို ရိုးရိုးသားသား စမ်းသပ်ခြင်း

ဤအရာကို စမ်းရန် ခက်ခဲစေသော အချက်နှစ်ခု ရှိသည်:

1. အမှန်တကယ် model များသည် ပါလာမည် မဟုတ်ပါ။ ကြီးမားသော ဖိုင်ကို print ထုတ်ရန် တောင်းလျှင် model အများစုက ငြင်းသည်၊ အနှစ်ချုပ်ပြသည် သို့မဟုတ် ပိုသင့်လျော်စွာ ရေးသည်။ Flood ကို စမ်းရန် အတွက် တိုင်းထားသည့်အတိုင်းသာ လုပ်သော scripted model လိုသည်၊ agent ၏ အစစ်ကုဒ်ကို run သည်။
2. Script များသည် model ကဲ့သို့ နေရမည်။ ကျွန်ုပ်တို့၏ ပထမ scripted model က တုံ့ပြန်မှု တိုင်းတွင် တူညီသော response ID ကို ပြန်သုံးသဖြင့် agent framework က တုံ့ပြန်မှု တိုင်းကို နောက်ဆုံး တစ်ခု၏ အစားထိုးမှုဟု ယူဆပြီး turn များကို စောစောပိတ်လိုက်သည်။ UI refresh bug ကဲ့သို့ ပေါ်သော်လည်း မဟုတ်ပါ၊ test harness က လိမ်နေခြင်း ဖြစ်သည်။ Model ၏ အစစ် context limit ကိုလည်း script တွင် ပြဌာန်းရမည်၊ မဟုတ်ပါက memory နံပါတ်များ မဖြစ်နိုင်ပါ။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• Streaming UI များသည် သေးငယ်သော အမှားများကို မြှောက်ပေးသည်။ "အပိုင်းတိုင်း" ပို့သော အရာမှန်သမျှ သောင်းချီ ပို့ခံရသည်။ Delta ပို့ပါ၊ သို့မဟုတ် payload ကို ကန့်သတ်ပါ။
• နှေးသော နယ်နိမိတ်ကို ဖြတ်သော buffer တိုင်းကို ကန့်သတ်ပါ။ Socket၊ replay log နှင့် checkpoint များအားလုံးတွင် အမြင့်ဆုံး တန်ဖိုးလိုသည်။
• ပြင်ခြင်းမတိုင်မီ ပြန်ဖြစ်အောင် လုပ်ပါ။ ကျွန်ုပ်တို့၏ ပထမ အဖြေ နှစ်ခုသည် မှန်ဟန်ရှိပြီး မှားခဲ့သည်။

ယမန်ကာလ Mythex chat တွင် agent ရပ်တန့်ခြင်းမရှိဘဲ ဖိုင်ရှည်ကြီးတစ်ခု ပေါ်လာသည်ကို မြင်ခဲ့လျှင် ဤအကြောင်းရင်းသည် အစိတ်အပိုင်း တစ်ခု ဖြစ်သည်။