Agentove poteze s številnimi slikami znotraj pomnilnika

Agentova poteza v produkciji je pri 952 MB zmanjkala pomnilnika med obrezovanjem izdelkov iz šestih skeniranih katalogov in med gledanjem izrezov. Ni šlo za eno samo puščanje — bilo jih je tri. Vsak klic modelu je ponovno poslal slike poteze v polni velikosti; knjižnica, ki jo uporabljamo za klicanje modela, je vsak zahtevek ohranjala živ do konca poteze; sledenje agentskega ogrodja pa je hranilo vhode vsakega klica, vključno s slikami, za celotno potezo. Vse tri smo odpravili: slike se pred pošiljanjem zmanjšajo, slikovni podatki vsakega klica pa se sprostijo takoj, ko je klic končan.

Kako agent vidi slike

Ko gradite v Mythexu, agent deluje v oblačnem peskovniku vašega projekta. Lahko pogleda slike — posnetek zaslona, ki ga priložite, maket, datoteko v vašem projektu ali sliko, ki jo je pravkar sam ustvaril — tako da jih pošlje modelu skupaj s pogovorom.

Poteza je vse, kar agent naredi kot odgovor na eno vaše sporočilo. Znotraj poteze agent modelu kliče večkrat: razmisli, zažene orodje, pogleda rezultat, znova razmisli. Vsak od teh klicev pošlje pogovor do tistega trenutka, vključno s slikami poteze, zakodiranimi kot besedilo (base64, kar jih naredi za približno tretjino večje).

Poteza, ki se je zrušila, je počela nekaj razumnega. Vzela je šest skeniranih katalogov, približno 2,4 MB vsak, iz njih izrezala posamezne izdelke in znova prebirala izreze, da jih je preverila. To je veliko klicev modelu, pri vsakem pa več velikih slik.

Vzrok 1: vsak klic je ponovno poslal slike v polni velikosti

Vsak klic modelu je svoje telo zahtevka sestavil znova, s slikami poteze v polni velikosti — približno 20 MB base64 na klic. Telo se gradi kot en niz v agentovem pomnilniku, zato je vsak klic dodelil še približno 20 MB.

Pošiljanje v polni velikosti sploh ni nič prineslo. Model sam slike zmanjša na približno 1.300 slikovnih točk na daljši stranici, zato dodatne točke stanejo le pomnilnik in čas nalaganja.

Rešitev: enkrat zmanjšaj, pošlji majhno

• Slike nad 400 KB se zdaj pred pošiljanjem pretvorijo v JPEG z največ 1.568 slikovnimi točkami na daljši stranici. Manjše slike gredo nespremenjene.
• Pretvorbo opravi ImageMagick, ki je na voljo v vsakem peskovniku Mythexa, in se izvede enkrat na datoteko. Poteza, ki pri vsakem klicu prikaže iste skene, ponovno uporabi zmanjšano kopijo. Predpomnilnik je ključ določen s potjo datoteke, velikostjo in časom spremembe, zato se urejena datoteka pretvori znova; ima pa tudi lastno omejitev velikosti, da ne more sam napolniti pomnilnika.
• Proračun za slike v enem klicu modelu se zniža z 16 MB na 6 MB.

Isti šest skenov zdaj stane 4,4 MB na klic namesto 19,7 MB.

Vzrok 2: model klient nikoli ni izpustil zahtevka

Velikost vsakega zahtevka ni bila vse. Pomnilnik je rasel tudi iz klica v klic. Na našem testnem okolju je enaka vrsta poteze po polnem čiščenju pomnilnika (garbage collection) — trenutku, ko se lahko sprosti vse, do česar ni več dostopa — še vedno držala 369 MB žive pomnilnine. Vzorčenje kopice je ves ta prirast pripisalo delu knjižnice za klienta modela, ki kodira telesa zahtevkov.

Vzrok je bil poslušalec prekinitve (abort). Ko pritisnete Stop, se sproži signal za prekinitev poteze, vsak zahtevek, ki ga posluša, pa se prekliče. Vsakemu zahtevku smo posredovali ta signal za celotno potezo. Knjižnica klienta na signal doda poslušalca »abort« — in ga nikoli ne odstrani.

Torej je vsak zahtevek poteze ostal dosegljiv prek signala poteze, za celotno trajanje poteze: poslušalec, ki drži krmilnik zahtevka, ki drži zahtevek, ki drži celotno telo zahtevka s slikami.

Rešitev: en signal na zahtevek

Vsak zahtevek zdaj dobi svoj signal. Povezan je s signalom poteze samo med tekom tega zahtevka — pri pretočnem odgovoru do prebranega zadnjega dela — in takoj zatem razvezan. Stop še vedno doseže vsak zahtevek v teku, signal poteze pa hrani le enega poslušalca naenkrat.

Testi pokrivajo vse tri dele:

• Po 12 klicih na signalu poteze ni poslušalcev. Pred popravkom jih je bilo 12.
• Pri 15 zahtevkih po 8 MB pomnilnik ostane raven. Prej je rasel za 128 MB.
• Pritisk na Stop še vedno prekine zahtevek sredi pretoka.

Vzrok 3: sledenje je hranilo vhode vsakega klica

Snapshot kopice je pokazal tretjega nosilca: približno 6 MB na klic modelu. To je prihajalo iz pretakanja dogodkov agentskega ogrodja. Vsak klic modelu v potezi je zabeležilo kot otroka poteze, vključno z vhodi, do konca poteze. Vsaka slika, pripeta vsakemu klicu, je ostala v pomnilniku skupaj z njim.

Rešitev: izprazni slike, ko se klic vrne

Slike so pripete samo sporočilom, zgrajenim za določen klic modelu. Nikoli se ne shranijo v shranjeno stanje pogovora. Zato je, ko se klic vrne, varno izprazniti podatke slik v teh sporočilih. Sled ohrani besedilni zapis klica; slikovne točke izginejo.

Pomembna podrobnost: slike je treba prazniti na mestu. Sledilnik lahko pride do istih podatkov slike prek več referenc na sporočilu, zato bi zamenjava z novim, praznim seznamom pustila izvirnik — s slikovnimi točkami vred — dosegljiv. Shranjen pogovor se nikoli ne spremeni.

Test zažene agentov graf pod enakim pretakanjem dogodkov s sliko 4 MB pri vsakem klicu. Brez popravka je pomnilnik zrasel za 77 MB v 16 klicih. S popravkom ostane raven.

Kaj smo iz tega vzeli

• Težave s pomnilnikom so lahko v plasteh. Trije ločeni vzroki so vsak držali slike predolgo, vsi trije pa so morali izginiti, da je poteza ostala v okviru pomnilnika.
• Vse, kar predate knjižnici, se lahko ohrani. Signal in sled sta preživela klice, za katere sta bila ustvarjena. Ko pomnilnik raste na klic, poglejte, katere dolgo živeče objekte se klic dotakne.
• Ne pošiljajte tistega, kar druga stran zavrže. Slikovne točke, ki jih model tako ali tako zavrže, so nas pri vsakem klicu stale pomnilnik.
• Preizkusite pomnilnik neposredno. Vsak popravek je prišel s testom, ki meri prirast kopice ali število poslušalcev, zato se regresija pokaže kot število, ne kot zrušitev.

To je druga zgodba o pomnilniku pri agentu v kratkem času; prva je bila oznaka napredka, ki je bila poslana 41.000-krat. Če želite izvedeti več o tem, kaj agent je in kako deluje, glejte naš vodnik o AI agentih in dokumentacijo o klepetu.