Držanje zahtjevnih poteza agenta sa slikama u okviru memorije

Potez agenta u produkciji ostao je bez memorije na 952 MB dok je izrezivao proizvode iz šest skeniranih kataloga i gledao izrezke. Nije postojalo jedno curenje — bila su tri. Svaki poziv modelu ponovo je slao slike poteza u punoj veličini; biblioteka kojom pozivamo model držala je svaki zahtjev živim do kraja poteza; a praćenje u okviru agentskog okvira čuvalo je ulaze svakog poziva, uključujući slike, cijeli potez. Popravili smo sva tri: slike se smanje prije slanja, a slike svakog poziva se oslobađaju čim se poziv završi.

Kako agent vidi slike

Kada gradite na Mythexu, agent radi unutar cloud sandboxa vašeg projekta. Može gledati slike — snimak ekrana koji priložite, maket, datoteku u projektu ili sliku koju je upravo sam napravio — tako što ih šalje modelu zajedno s razgovorom.

Potez je sve što agent radi kao odgovor na jednu vašu poruku. Unutar poteza agent poziva model mnogo puta: razmisli, pokrene alat, pogleda rezultat, pa opet razmisli. Svaki od tih poziva šalje razgovor do tada, a to uključuje slike poteza, kodirane kao tekst (base64, što ih čini oko trećinu većim).

Potez koji je pao radio je nešto razumno. Izrezao je pojedinačne proizvode iz šest skeniranih kataloga, od kojih je svaki bio oko 2,4 MB, i stalno čitao izreske nazad da ih provjeri. To su mnogi pozivi modelu, a svaki nosi nekoliko velikih slika.

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

Svaki poziv modelu ponovo je gradio tijelo zahtjeva sa slikama poteza u punoj veličini — oko 20 MB base64 po pozivu. Tijelo se gradi kao jedan string u memoriji agenta, pa je svaki poziv alocirao još oko 20 MB.

Slanje pune veličine nije ni donosilo nikakvu korist. Model sam smanjuje slike na oko 1.300 piksela na dužoj strani, pa dodatni pikseli samo troše memoriju i vrijeme učitavanja.

Popravka: jednom smanji, šalji malo

• Slike veće od 400 KB sada se pretvaraju u JPEG od najviše 1.568 piksela na dužoj strani prije slanja. Manje slike idu kakve jesu.
• Pretvaranje koristi ImageMagick, koji dolazi u svakom Mythex sandboxu, i izvršava se jednom po datoteci. Potez koji na svakom pozivu prikazuje isti skenirani katalog koristi već smanjenu kopiju. Taj keš je ključan po putanji, veličini i vremenu izmjene datoteke, pa se izmijenjena datoteka ponovo pretvara, a ima i vlastito ograničenje veličine kako sam ne bi postao uzrok punjenja memorije.
• Budžet za slike u jednom pozivu modelu smanjen je sa 16 MB na 6 MB.

Isto onih šest skenova sada košta 4,4 MB po pozivu umjesto 19,7 MB.

Uzrok 2: klijent modela nikada nije oslobodio zahtjev

Veličina svakog zahtjeva bila je samo dio problema. Memorija je također rasla iz poziva u poziv. Na našem staging okruženju isti tip poteza držao je 369 MB žive memorije čak i nakon potpunog garbage collectiona — tačke u kojoj se sve što je nedostižno oslobodi. Uzorkovanje heapa pokazalo je da sav rast dolazi iz dijela biblioteke klijenta modela koji kodira tijela zahtjeva.

Uzrok je bio abort listener. Kada pritisnete Stop, abort signal poteza se aktivira, i svaki zahtjev koji ga sluša se otkazuje. Mi smo taj jedan signal za cijeli potez prosljeđivali svakom zahtjevu. Klijentska biblioteka dodaje listener „abort” na bilo koji signal koji dobije — i nikada ga ne ukloni.

Tako je svaki zahtjev jednog poteza ostajao dostupan iz signala poteza, koliko god je potez trajao: listener, koji je držao kontroler, koji je držao zahtjev, koji je držao cijelo tijelo zahtjeva sa slikama.

Popravka: jedan signal po zahtjevu

Svaki zahtjev sada dobija vlastiti signal. Povezan je sa signalom poteza samo dok taj zahtjev radi — za streamovani odgovor, do čitanja posljednjeg dijela — a odmah nakon toga se odvezuje. Stop i dalje dopire do svakog zahtjeva u toku, ali signal poteza u jednom trenutku drži samo jedan listener.

Testovi pokrivaju sva tri dijela:

• Nakon 12 poziva, na signalu poteza nema listenera. Prije popravke bilo ih je 12.
• Tokom 15 zahtjeva od po 8 MB, memorija ostaje ravna. Prije je rasla za 128 MB.
• Pritisak na Stop i dalje prekida zahtjev usred njegovog streama.

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

Snimak heapa pokazao je treći nosilac: oko 6 MB po pozivu modelu. Ovo je dolazilo iz streamovanja događaja agentskog okvira. Ono bilježi svaki poziv modelu u potezu kao podređeni element poteza, uključujući ulaze, sve dok potez ne završi. Svaka slika priložena svakom pozivu ostajala je u memoriji zajedno s njim.

Popravka: obriši slike kada poziv vrati odgovor

Slike se uvijek priloži samo porukama napravljenim za konkretan poziv modelu. Nikada se ne čuvaju u sačuvanom stanju razgovora. Zato je, nakon što poziv vrati odgovor, sigurno isprazniti podatke slika u tim porukama. Praćenje zadržava tekstualni zapis poziva; pikseli nestaju.

Jedan detalj je bio bitan: slike se moraju prazniti na mjestu. Praćenje može doći do istih podataka slike kroz više referenci na poruci, pa bi zamjena novom, praznom listom ostavila original — s pikselima — i dalje dostupnim. Sačuvano stanje razgovora se nikada ne mijenja.

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

Šta smo izvukli iz ovoga

• Problemi s memorijom mogu biti u slojevima. Tri zasebna uzroka držala su slike predugo, i sva tri su morala nestati da bi potez ostao u okviru memorije.
• Sve što predate biblioteci može biti zadržano. I signal i praćenje nadživjeli su pozive kojima su bili predati. Kada memorija raste po pozivu, pogledajte koje dugovječne objekte poziv dira.
• Ne šaljite ono što druga strana odbacuje. Pikseli koje bi model svakako odbacio koštali su nas memoriju na svakom pozivu.
• Testirajte memoriju direktno. Svaka popravka došla je s testom koji mjeri rast heapa ili broj listenera, pa se regresija pokazuje kao broj, a ne kao pad.

Ovo je druga priča o memoriji od agenta u kratkom vremenu; prva je bila oznaka napretka poslana 41.000 puta. Ako želite znati više o tome šta je agent i kako radi, pogledajte naš vodič o AI agentima i dokumentaciju o chatu.