Jak udržet běhy agenta s mnoha obrázky v paměti

Běh agenta v produkci došel na 952 MB paměti, když vyřezával produkty ze šesti skenů katalogu a kontroloval své výřezy. Nešlo o jeden únik, byly tři. Každé volání modelu znovu posílalo obrázky běhu v plné velikosti; knihovna, kterou voláme model, držela všechny požadavky naživu až do konce běhu; a trasování frameworku agenta uchovávalo vstupy každého volání, včetně obrázků, po celou dobu běhu. Všechny tři jsme opravili: obrázky se před odesláním zmenší a obrázky každého volání se uvolní hned, jakmile volání skončí.

Jak agent vidí obrázky

Když stavíš na Mythexu, agent pracuje uvnitř cloudového sandboxu tvého projektu. Umí se podívat na obrázky – na snímek obrazovky, který připojíš, na mockup, na soubor v projektu nebo na obrázek, který právě sám vytvořil – tak, že je pošle modelu spolu s konverzací.

Běh je vše, co agent udělá v reakci na jednu tvou zprávu. V rámci běhu agent volá model mnohokrát: přemýšlí, spustí nástroj, podívá se na výsledek a znovu přemýšlí. Každé z těchto volání posílá konverzaci dosud, a patří do ní i obrázky běhu, zakódované jako text (base64, což je zhruba o třetinu větší).

Běh, který spadl, dělal rozumnou věc. Vzal šest skenů katalogu, každý zhruba 2,4 MB, vyřezával z nich jednotlivé produkty a opakovaně kontroloval své výřezy. To jsou stovky volání modelu, každé nese několik velkých obrázků.

Příčina 1: každé volání posílalo obrázky v plné velikosti

Každé volání modelu znovu sestavilo tělo požadavku s obrázky běhu v plné velikosti – zhruba 20 MB base64 na volání. Tělo se staví jako jeden řetězec v paměti agenta, takže každé volání alokovalo dalších ~20 MB.

Odesílání v plné velikosti navíc nic nepřinášelo. Model si obrázky sám zmenší na zhruba 1 300 pixelů na delší straně, takže přebytečné pixely jen stály paměť a čas na nahrávání.

Oprava: zmenšit jednou, poslat malé

• Obrázky větší než 400 KB se před odesláním převedou na JPEG s nejvýše 1 568 pixely na delší straně. Menší obrázky se pošlou beze změny.
• Převod provádí ImageMagick, který je v každém sandboxu Mythexu, a běží jednou pro každý soubor. Běh, který ukazuje stejné skeny při každém volání, použije znovu zmenšenou kopii. Cache je klíčovaná cestou k souboru, velikostí a časem úpravy, takže upravený soubor se převede znovu, a má vlastní limit velikosti, aby sama nemohla zaplnit paměť.
• Rozpočet obrázků v jednom volání modelu klesá z 16 MB na 6 MB.

Stejných šest skenů teď stojí 4,4 MB na volání místo 19,7 MB.

Příčina 2: klient modelu nikdy nepustil požadavek

Velikost každého požadavku byla jen část problému. Paměť také rostla volání za voláním. Na naší staging instanci stejný typ běhu držel 369 MB živé paměti i po úplném úklidu paměti (garbage collection) – tedy po okamžiku, kdy se uvolní vše, na co už nic neodkazuje. Vzorkování haldy připsalo všechen růst části knihovny klienta modelu, která kóduje těla požadavků.

Příčinou byl posluchač abortu. Když stiskneš Stop, signál přerušení celého běhu se spustí a každý požadavek, který na něj naslouchá, se zruší. Předávali jsme jeden signál pro celý běh každému požadavku. Klientská knihovna přidá k signálu, který dostane, posluchač „abort“ – a nikdy ho neodebere.

Každý požadavek běhu tak zůstal dosažitelný přes signál běhu po celou dobu běhu: posluchač, který držel controller, který držel požadavek, který držel celé tělo požadavku i s obrázky.

Oprava: jeden signál na požadavek

Každý požadavek teď dostane vlastní signál. Ten se propojí se signálem běhu jen dokud požadavek běží – u streamované odpovědi až do přečtení posledního kusu – a hned potom se odpojí. Stop stále dosáhne každého požadavku, který běží, ale signál běhu drží vždy jen jednoho posluchače.

Testy pokrývají všechny tři části:

• Po 12 voláních nezůstane na signálu běhu žádný posluchač. Před opravou jich bylo 12.
• Při 15 požadavcích po 8 MB paměť zůstane konstantní. Předtím přibyla o 128 MB.
• Stop stále přeruší požadavek uprostřed jeho streamu.

Příčina 3: trasování uchovávalo vstupy každého volání

Snímek haldy ukázal třetího držitele: zhruba 6 MB na každé volání modelu. Ten pocházel ze streamování událostí frameworku agenta. Zaznamenává každé volání modelu v běhu jako potomka běhu, včetně vstupů, až do konce běhu. Každý obrázek připojený k jakémukoli volání tak zůstal v paměti spolu s ním.

Oprava: vymazat obrázky, jakmile volání vrátí odpověď

Obrázky se připojují jen ke zprávám sestaveným pro konkrétní volání modelu. Nikdy se neukládají do uloženého stavu konverzace. Jakmile tedy volání vrátí odpověď, je bezpečné vyprázdnit data obrázků v těchto zprávách. Trasování si ponechá textový záznam volání; pixely pryč.

Jeden detail měl zásadní význam: obrázky se musí vymazat na místě. Trasovač se může ke stejným datům obrázku dostat přes více odkazů na zprávě, takže kdyby se vyměnil za nový prázdný seznam, původní – pixely a všechno – by zůstal dosažitelný. Uložený stav konverzace se nikdy nemění.

Test spustí graf agenta pod stejným streamováním událostí s obrázkem o 4 MB u každého volání. Bez opravy paměť za 16 volání vzrostla o 77 MB. S opravou zůstává konstantní.

Co jsme si z toho odnesli

• Problémy s pamětí mohou mít vrstvy. Tři oddělené příčiny držely obrázky příliš dlouho a všechny tři musely pryč, aby běh zůstal v paměti.
• Cokoli předáš knihovně, si může nechat. Signál i trasování přežily volání, kterým byly předány. Když paměť roste s každým voláním, podívej se, jaké dlouhodobé objekty volání používá.
• Neposílej to, co druhá strana stejně zahodí. Pixely, které by model stejně zahodil, nás stály paměť při každém volání.
• Testuj paměť přímo. Každá oprava přišla s testem, který měří růst haldy nebo počty posluchačů, takže regrese se projeví jako číslo, ne jako pád.

Tohle je druhý příběh o paměti z agenta za krátkou dobu; první byl popisek průběhu, který se znovu posílal 41 000krát. Pokud chceš vědět víc o tom, co agent je a jak funguje, podívej se na náš průvodce AI agenty a dokumentaci k chatu.