Ang Out-of-Memory Crash na Nagtatago sa Isang Progress Label

Isang gabi noong huling bahagi ng Setyembre, nag-crash ang AI agent sa workspace ng isang user dahil sa out-of-memory error sa gitna ng isang turn. Ang mga halatang suspek, sobrang daming sub-agent na sabay-sabay tumatakbo, o context na lumaki nang sobra, ay parehong mali. Ang totoong sanhi ay isang status label: habang nagsi-stream ang model ng malaking shell command ng ilang karakter sa bawat pagkakataon, ipinapadala namin muli ang buong command hanggang sa puntong iyon bilang progress label sa bawat piraso. Ang isang 124 KB na command ay naging humigit-kumulang 41,000 na event at halos 690 MB na nakapilang string.

Paano nagsi-stream ng trabaho ang agent

Kapag nagbu-build ka sa Mythex, tumatakbo ang agent sa loob ng pribadong cloud sandbox ng project mo. Habang sumusulat ang model, bumabalik ang output nito sa browser mo: lumalabas ang text salita-salita, at kapag nagpapatakbo ito ng tool, halimbawa isang shell command na sumusulat ng file, nagbabago nang live ang label nito, para alam mo kung ano ang ginagawa nito.

Nagsi-stream ang model sa maliliit na piraso. Sa model na ginagamit namin, kadalasang tatlong karakter lang ang bawat piraso.

Mali ang mga unang hinala

Mukhang problema sa scaling ang crash, kaya doon kami nagsimula.

• Parallel sub-agents? Dalawa lang ang ginamit ng turn, bawat isa ay may humigit-kumulang 1.5 MB na state. Hindi sapat iyon.
• Nakaimbak na traces? Nagtatago ang aming tracing ng run tree sa memory, pero malayo ito sa laki ng heap noong nag-crash.

Pareho silang kapani-paniwalang kuwento, at parehong madaling paniwalaan. Walang nag-reproduce ng crash sa alinman. Ang aral na paulit-ulit naming natutuklasan: hindi pa sanhi ang hinala hangga't hindi ito nagre-reproduce ng pagkabigo.

Pag-reproduce nito para sa totoo

Gumawa kami ng pansamantalang sandbox na may parehong memory limits ng production at isang pekeng model na nagsi-stream ng malaking file sa makatotohanang tatlong-karakter na piraso. Pinabagal din namin ang reader sa kabilang dulo ng socket, gaya ng totoong network.

Iyon ang nagpakita nito. Umakyat ang heap at namatay ang proseso na may parehong error.

Simple ang mekanismo kapag nakikita na namin ito. Habang sumusulat ang model ng malaking command, sa kasong ito isang heredoc na sumusulat ng 124 KB na file, ina-update ng streaming code namin ang label ng tool sa bawat piraso. Hindi ang bagong tatlong karakter ang laman ng label; ang buong command hanggang sa puntong iyon ang laman. Kaya lumalaki ang mga event: 3 karakter, pagkatapos 6, pagkatapos 9, hanggang 124 KB, humigit-kumulang 41,000 beses. Hindi ito maipadala ng socket nang kasing bilis ng pagkakagawa, kaya nagtambak ang mga ito sa write buffer nito bilang mga string, humigit-kumulang 690 MB.

Ang ayos

• Limitahan ang label. Kailangan lang sabihin ng status label kung ano ang nangyayari. Ngayon, 200 karakter lang ang pinapayagan, at pinapabagalan namin kung gaano kadalas i-scan muli ang partial command.
• Ihinto ang quadratic concatenation. Ang pagdurugtong ng mga streamed na piraso gamit ang paulit-ulit na string concatenation ay O(n²) para sa malalaking output. Lumipat kami sa chunk-based na approach na nagdadagdag sa linear na oras.

Pagkatapos, hinanap namin ang anumang iba pang maaaring lumaki nang walang hangganan sa baha ng output, at nilimitahan namin ang mga ito:

• Ang live na command output na ipinapakita sa chat ay pinagsasama-sama at pinananatili sa huling 8,000 karakter.
• Ang bawat linya ng event ay limitado sa 4 MB.
• Ang replay buffer na ginagamit ng browser para makahabol pagkatapos muling kumonekta ay limitado sa 8 MB bawat project.
• Ang mga lumang checkpoint ay binubura habang umuusad ang turn, na pinananatili ang pinakabagong state at ang mga anchor na kailangan ng mga naunang turn.

Tapat na pagsubok sa mga baha

Dalawang bagay ang nagpahirap sa pagsubok nito kaysa dapat:

1. Hindi nakikipagtulungan ang totoong model. Kapag humingi ka sa model ng pag-print ng napakalaking file, karaniwang tumatanggi ito, nagbubuod, o isinusulat ito nang mas maayos. Para masubukan ang mga baha, kailangan mo ng scripted na model na eksaktong gumagawa ng sinabi mo, na tumatakbo sa totoong agent code.
2. Kailangang kumilos na parang model ang mga script. Ang una naming scripted na model ay ginamit ang parehong response ID sa bawat sagot, kaya itinuring ng agent framework ang bawat sagot bilang kapalit ng nauna at tinapos ang mga turn nang maaga. Mukhang bug sa UI refresh. Hindi pala, sinisinungaling kami ng test harness. Kinailangan din naming ipatupad sa script ang totoong context limit ng model, o hindi makatotohanan ang mga numero ng memory.

Ang natutunan namin

• Pinaparami ng streaming UI ang maliliit na pagkakamali. Anumang ipinapadala "kada chunk" ay naipapadala nang sampu-sampung libong beses. Magpadala ng deltas, o limitahan ang payload.
• Limitahan ang bawat buffer na tumatawid sa mabagal na hangganan. Kailangan ng takip ng sockets, replay logs at checkpoints.
• Mag-reproduce bago mag-ayos. Ang unang dalawang paliwanag namin ay tunog tama at mali.

Kung nakakita ka kamakailan ng napakahabang file na lumitaw sa Mythex chat nang hindi tumitigil ang agent, bahagi ito ng dahilan.