Chyba nedostatku paměti skrytá v popisku průběhu

Jednoho večera na konci září se AI agent v pracovním prostoru uživatele uprostřed tahu zhroutil s chybou nedostatku paměti (out of memory). Očividní podezřelí – příliš mnoho subagentů běžících najednou, nebo příliš velký kontext – byli oba mimo. Skutečnou příčinou byl stavový popisek: zatímco model streamoval velký shellový příkaz po několika znacích, při každém kousku jsme znovu odeslali celý dosavadní příkaz jako popisek průběhu. Jeden příkaz o velikosti 124 KB se stal přibližně 41 000 událostmi a asi 690 MB ve frontě čekajících řetězců.

Jak agent streamuje svou práci

Když stavíte na Mythexu, agent běží v soukromém cloudovém sandboxu projektu. Jak model píše, jeho výstup se streamuje zpět do vašeho prohlížeče: text se objevuje slovo po slovu a když agent spustí nástroj – třeba shellový příkaz, který zapisuje soubor –, vidíte popisek, který se živě aktualizuje, takže víte, co dělá.

Model streamuje v malých kouscích. U modelu, který jsme používali, byly tyto kousky často jen tři znaky dlouhé.

První hypotézy byly špatně

Pád vypadal jako problém škálování, tak jsme začali tam.

Paralelní subagenti? Tah použil jen dva, každý držel kolem 1,5 MB stavu. Nestačí to.
Uchovávané stopy? Naše trasování drželo strom běhů v paměti, ale nebylo to ani zdaleka tolik jako halda v okamžiku pádu.

Obě byly věrohodné a obě se daly snadno uvěřit. Ani jedna pád nezreprodukovala. Ponaučení, které si pořád znovu připomínáme: hypotéza není příčina, dokud nereprodukuje selhání.

Reprodukce doopravdy

Sestavili jsme jednorázový sandbox se stejnými limity paměti jako v produkci a falešný model, který streamoval velký soubor v realistických tříznakových kouscích. Také jsme udělali čtenáře na druhém konci socketu pomalým, jako skutečnou síť.

To zabralo. Halda rostla a proces zemřel se stejnou chybou.

Mechanismus byl jednoduchý, jakmile jsme ho mohli sledovat. Zatímco model psal velký příkaz – v tomto případě heredoc, který zapisoval soubor o 124 KB –, náš streamovací kód aktualizoval popisek nástroje při každém kousku. Popisek nebyl nových tři znaky; byl to celý dosavadní příkaz. Události tak rostly: 3 znaky, pak 6, pak 9, … až na 124 KB, asi 41 000krát. Socket je nedokázal odesílat tak rychle, jak vznikaly, takže se hromadily v jeho zápisovém bufferu jako řetězce – asi 690 MB.

Oprava

Omezit popisek. Stavový popisek musí říct jen to, co se děje. Nyní je omezen na 200 znaků a přepočítávání částečného příkazu je zpomaleno.
Zrušit kvadratické spojování. Spojovat streamované kousky opakovaným zřetězením řetězců je u velkých výstupů O(n²). Přešli jsme na přístup založený na blocích, který připojuje v lineárním čase.

Pak jsme hledali cokoli dalšího, co by mohlo bez omezení růst při záplavě výstupu, a omezili to:

Živý výstup příkazů zobrazený v chatu je dávkován a drží se posledních 8 000 znaků.
Jednotlivé řádky událostí jsou omezeny na 4 MB.
Replay buffer, ze kterého se prohlížeč dohání po opětovném připojení, je omezen na 8 MB na projekt.
Staré checkpointy se během tahu prořezávají a zachovávají nejnovější stav a kotvy, které potřebují předchozí tahy.

Poctivé testování záplav

Dvě věci to ztížily víc, než mělo být:

Skutečné modely nespolupracují. Pokud požádáte model, aby vypsal obrovský soubor, obvykle odmítne, shrne ho nebo ho zapíše rozumněji. Pro testování záplav potřebujete skriptovaný model, který dělá přesně to, co mu řeknete, a běží skrze skutečný kód agenta.
Skripty se musí chovat jako modely. Náš první skriptovaný model používal na každou odpověď stejné ID odpovědi, takže rámec agenta považoval každou odpověď za náhradu té předchozí a tahy ukončoval předčasně. Vypadalo to jako chyba obnovování UI. Nebyla – lhal testovací kostra. Také jsme museli ve skriptu vynutit skutečný limit kontextu modelu, jinak byla čísla paměti nerealistická.

Co jsme si z toho odnesli

Streamovaná UI zesilují drobné chyby. Cokoli, co posíláte „na kousek“, se odešle desítky tisíc krát. Posílejte rozdíly, nebo omezte objem dat.
Omezte každý buffer, který přechází přes pomalou hranici. Sockety, replay logy i checkpointy potřebují strop.
Reprodukujte před opravou. Naše první dvě vysvětlení zněla správně a byla špatně.

Pokud jste v poslední době v chatu Mythexu viděli velmi dlouhý soubor, který se objevil, aniž by se agent zasekl, je to částečně tímto.