Zadržavanje agentskih koraka bogatih slikama unutar memorije

Jedan agentski korak u produkciji ostao je bez memorije na 952 MB dok je izrezivao proizvode iz šest skenova kataloga i pregledavao svoje izreske. Nije bilo jednog curenja, nego tri. Svaki poziv modelu ponovno je slao slike koraka u punoj veličini; biblioteka koju koristimo za pozive modelu držala je svaki zahtjev živim do kraja koraka; a praćenje agentskog okvira zadržavalo je ulaze svakog poziva, uključujući slike, za cijeli korak. Popravili smo sva tri: slike se smanje prije slanja, a slike svakog poziva puštaju se čim je poziv gotov.

Kako agent vidi slike

Kad gradite na Mythexu, agent radi unutar cloud sandboxa vašeg projekta. Može pogledati slike, npr. snimku zaslona koju priložite, mockup, datoteku u projektu ili sliku koju je sam upravo proizveo, tako da ih šalje modelu zajedno s razgovorom.

Korak je sve što agent radi kao odgovor na jednu vašu poruku. Unutar koraka agent poziva model mnogo puta: razmišlja, pokreće alat, gleda rezultat, opet razmišlja. Svaki od tih poziva šalje razgovor do tada, a to uključuje slike koraka, kodirane kao tekst (base64, što ih čini oko trećinu većima).

Korak koji se srušio radio je nešto razumno. Uzeo je šest skenova kataloga, oko 2,4 MB svaki, izrezao pojedinačne proizvode i stalno čitao izreske natrag da ih provjeri. To su mnogi pozivi modelu, a svaki nosi nekoliko velikih slika.

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

Svaki poziv modelu ponovno je gradio tijelo zahtjeva sa slikama koraka u punoj veličini, otprilike 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 zapravo ničemu nije služilo. Model sam smanjuje slike na oko 1.300 piksela na dužoj strani, pa dodatni pikseli samo troše memoriju i vrijeme učitavanja.

Popravak: smanji jednom, šalji malo

• Slike veće od 400 KB sada se pretvaraju u JPEG s najviše 1.568 piksela na dužoj strani prije slanja. Manje slike se šalju kakve jesu.
• Pretvorba koristi ImageMagick, koji dolazi u svakom Mythex sandboxu, i izvodi se jednom po datoteci. Korak koji stalno prikazuje iste skenove ponovno koristi smanjenu kopiju. Predmemorija je ključ po putanji datoteke, veličini i vremenu izmjene, pa se izmijenjena datoteka ponovno pretvara, a ima i vlastitu granicu veličine kako ne bi sama postala uzrok punjenja memorije.
• Budžet za slike u jednom pozivu modelu smanjen je sa 16 MB na 6 MB.

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

Uzrok 2: klijent modela nikad nije pustio zahtjev

Veličina svakog zahtjeva bila je samo dio problema. Memorija je također rasla iz poziva u poziv. Na našem stagingu isti tip koraka držao je 369 MB žive memorije čak i nakon potpunog garbage collectiona, točke u kojoj se sve što je nedostupno oslobađa. Heap sampling je sav rast stavio u dio biblioteke klijenta modela koji kodira tijela zahtjeva.

Uzrok je bio abort listener. Kad pritisnete Stop, abort signal koraka se aktivira i svaki zahtjev koji ga sluša se otkazuje. Mi smo taj jedan signal za cijeli korak predavali svakom zahtjevu. Klijentska biblioteka dodaje listener „abort” bilo kojem signalu koji dobije, i nikad ga ne ukloni.

Tako je svaki zahtjev koraka ostao dostupan iz signala koraka za cijelo trajanje koraka: listener, koji drži kontroler, koji drži zahtjev, koji drži cijelo tijelo zahtjeva sa slikama.

Popravak: jedan signal po zahtjevu

Svaki zahtjev sada dobiva vlastiti signal. Povezan je sa signalom koraka samo dok taj zahtjev traje, za streamirani odgovor do zadnjeg pročitanog dijela, i odmah se odvaja. Stop i dalje dopire do zahtjeva u tijeku, ali signal koraka u svakom trenutku drži samo jedan listener.

Testovi pokrivaju sva tri dijela:

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

Uzrok 3: praćenje je zadržavalo ulaze svakog poziva

Snimka heapa pokazala je treći držač: otprilike 6 MB po pozivu modelu. Dolazilo je iz streaminga događaja agentskog okvira. On svaki poziv modelu u koraku bilježi kao dijete koraka, uključujući ulaze, sve do kraja koraka. Svaka slika priložena svakom pozivu ostala je u memoriji uz njega.

Popravak: isprazni slike čim se poziv vrati

Slike su vezane samo uz poruke sastavljene za određeni poziv modelu. Nikad se ne spremaju u spremljeno stanje razgovora. Zato je nakon povratka poziva sigurno isprazniti podatke slika u tim porukama. Praćenje zadržava tekstualni zapis poziva, a pikseli nestaju.

Jedan detalj je bio važan: slike se moraju prazniti na mjestu. Tracer može doći do istih podataka slike kroz više referenci na poruci, pa bi zamjena novom, praznom listom ostavila original, s pikselima, još dostupnim. Spremljeno stanje razgovora se nikad ne mijenja.

Jedan test pokreće graf agenta pod istim streamingom događaja s 4 MB slikom na svakom pozivu. Bez popravka memorija je rasla za 77 MB kroz 16 poziva. S popravkom ostaje ravna.

Što smo iz toga izvukli

• Problemi s memorijom mogu biti u slojevima. Tri zasebna uzroka svaki je držao slike predugo, i sva tri su trebala nestati da bi korak ostao unutar memorije.
• Sve što predate biblioteci može se zadržati. Signal i trag preživjeli su pozive kojima su bili predani. Kad memorija raste po pozivu, pogledajte koje dugoživuće objekte poziv dodiruje.
• Ne šaljite ono što druga strana odbacuje. Pikseli koje bi model svejedno odbacio koštali su nas memoriju pri svakom pozivu.
• Testirajte memoriju izravno. Svaki popravak došao je s testom koji mjeri rast heapa ili broj listenera, pa se regresija vidi kao broj, a ne kao rušenje.

Ovo je druga priča o memoriji vezana uz izlaz agenta u kratkom razdoblju; prva je bila oznaka napretka koja je u red stavila 41.000 ponavljanja. Ako želite znati što agent je i kako radi, pogledajte naš vodič o AI agentima i dokumentaciju za chat.