Kako agentske radnje sa puno slika ostaju u okviru memorije

Radnja agenta u produkciji ostala je bez memorije na 952 MB dok je sečila proizvode iz šest skeniranih kataloga i gledala svoje isečke. Nije bilo jednog curenja, bila su tri. Svaki poziv modelu ponovo je slao slike radnje u punoj veličini. Biblioteka koju koristimo za pozivanje modela držala je svaki zahtev živ do kraja radnje. Praćenje agentskog okvira čuvalo je ulaze svakog poziva, uključujući slike, tokom cele radnje. Popravili smo sve tri stvari: slike se smanjuju pre slanja, a slike svakog poziva se oslobađaju čim se poziv završi.

Kako agent vidi slike

Kada pravite na Mythexu, agent radi unutar cloud sandboxa vašeg projekta. Može da gleda slike, kao što su snimak ekrana koji priložite, makete, fajl u vašem projektu ili slika koju je sam upravo napravio, tako što ih šalje modelu zajedno sa razgovorom.

Radnja je sve što agent uradi kao odgovor na jednu vašu poruku. Unutar radnje agent poziva model mnogo puta: razmišlja, pokreće alat, gleda rezultat i ponovo razmišlja. Svaki od tih poziva šalje razgovor do tog trenutka, a to uključuje slike radnje, kodirane kao tekst (base64, što ih čini oko trećinu većim).

Radnja koja je pala radila je nešto razumno. Uzela je šest kataloških skeniranja, otprilike po 2,4 MB, isekla pojedinačne proizvode iz njih i ponovo čitala svoje isečke da bi ih proverila. To je mnogo poziva modelu, a svaki nosi više velikih slika.

Uzrok 1: svaki poziv je ponovo slao slike pune veličine

Svaki poziv modelu gradio je telo zahteva sa slikama radnje u punoj veličini, oko 20 MB base64 po pozivu. Telo se pravi kao jedan string u memoriji agenta, pa je svaki poziv alocirao još oko 20 MB.

Slanje pune veličine čak ništa nije donosilo. Model sam smanjuje slike na oko 1.300 piksela na dužoj strani, pa dodatni pikseli samo troše memoriju i vreme slanja.

Ispravka: smanjiti jednom, slati malo

• Slike veće od 400 KB se pre slanja pretvaraju u JPEG sa najviše 1.568 piksela na dužoj strani. Manje slike se šalju onakve kakve jesu.
• Pretvaranje koristi ImageMagick, koji ima svaki Mythex sandbox, i izvršava se jednom po fajlu. Radnja koja prikazuje iste skenove pri svakom pozivu koristi već smanjenu kopiju. Keš je vezan za putanju fajla, veličinu i vreme izmene, pa se izmenjen fajl ponovo pretvara. Ima i sopstveno ograničenje veličine, da sam keš ne bi napunio memoriju.
• Budžet za slike u jednom pozivu modelu smanjen je sa 16 MB na 6 MB.

Ista šest skeniranja sada koštaju 4,4 MB po pozivu umesto 19,7 MB.

Uzrok 2: klijent modela nikada nije otpuštao zahtev

Veličina svakog zahteva bila je samo deo problema. Memorija je rasla i iz poziva u poziv. Na našem staging okruženju, ista vrsta radnje držala je 369 MB žive memorije čak i posle potpunog sakupljanja smeća, tj. tačke u kojoj se sve što nije dostupno oslobodi. Uzorkovanje heap-a pokazalo je da sav rast potiče iz dela biblioteke klijenta modela koji kodira tela zahteva.

Uzrok je bio abort listener. Kada pritisnete Stop, abort signal radnje se aktivira i svi zahtevi koji ga slušaju se otkazuju. Mi smo taj jedan signal za celu radnju prosleđivali svakom zahtevu. Klijentska biblioteka dodaje listener „abort” na svaki signal koji dobije i nikada ga ne uklanja.

Tako je svaki zahtev jedne radnje ostajao dostupan preko signala radnje, dokle god je radnja trajala: listener je držao kontroler, kontroler je držao zahtev, a zahtev je držao celo telo sa slikama.

Ispravka: jedan signal po zahtevu

Svaki zahtev sada dobija sopstveni signal. On se povezuje sa signalom radnje samo dok zahtev traje (za streamovani odgovor, do pročitanog poslednjeg dela) i odmah se odvezuje. Stop i dalje dopire do zahteva koji je u toku, ali signal radnje u svakom trenutku drži samo jedan listener.

Testovi pokrivaju sva tri dela:

• Posle 12 poziva, na signalu radnje nema listenera. Pre ispravke ih je bilo 12.
• Kroz 15 zahteva od po 8 MB, memorija ostaje ravna. Pre je rasla za 128 MB.
• Pritisak na Stop i dalje prekida zahtev u sred streama.

Uzrok 3: praćenje je čuvalo ulaze svakog poziva

Heap snapshot je pokazao treći držač: oko 6 MB po pozivu modelu. Ovo je dolazilo iz strimovanja događaja agentskog okvira. Ono beleži svaki poziv modelu u radnji kao dete radnje, uključujući ulaze, sve do kraja radnje. Svaka slika priložena svakom pozivu ostajala je u memoriji zajedno sa njim.

Ispravka: isprazniti slike čim se poziv vrati

Slike su priložene samo porukama napravljenim za određeni poziv modelu. Nikada se ne čuvaju u sačuvanom stanju razgovora. Zato je, kada se poziv vrati, bezbedno isprazniti podatke o slikama u tim porukama. Praćenje zadržava tekstualni zapis poziva, a pikseli nestaju.

Jedan detalj je bio presudan: slike se moraju prazniti na licu mesta. Praćenje može da dođe do istih podataka slike preko više referenci na poruci, pa bi zamena novom, praznom listom ostavila original, sa pikselima, još dostupnim. Sačuvano stanje razgovora se nikada ne menja.

Test pokreće graf agenta pod istim strimovanjem događaja sa slikom od 4 MB u svakom pozivu. Bez ispravke, memorija je rasla za 77 MB kroz 16 poziva. Sa ispravkom, memorija ostaje ravna.

Šta smo izvukli iz ovoga

• Problemi sa memorijom mogu biti u slojevima. Tri odvojena uzroka su zadržavala slike predugo, i sva tri su morala da se uklone da bi radnja ostala u memoriji.
• Sve što predate biblioteci može biti zadržano. Signal i praćenje su nadživeli pozive kojima su bili prosleđeni. Kada memorija raste po pozivu, pogledajte koje dugovečne objekte poziv dira.
• Ne šaljite ono što druga strana ionako odbacuje. Pikseli koje model svakako odbacuje koštali su nas memoriju pri svakom pozivu.
• Testirajte memoriju direktno. Svaka ispravka je došla sa testom koji meri rast heap-a ili broj listenera, pa se regresija vidi kao broj, a ne kao pad.

Ovo je druga priča o memoriji od agenta u kratkom periodu. Prva je bila oznaka napretka poslata 41.000 puta. Ako želite da saznate više o tome šta je agent i kako radi, pogledajte naš vodič o AI agentima i dokumentaciju o čatu.