Mbajtja e turneve të agjentit me shumë imazhe brenda memories

Një turn agjenti në prodhim mbaroi memorien në 952 MB, ndërsa priste produktet nga gjashtë skanime katalogu dhe shikonte prerjet e tij. Nuk kishte një rrjedhje të vetme; kishte tre. Çdo thirrje modelit ridërgonte imazhet e turnit në madhësi të plotë; biblioteka që përdorim për të thirrur modelin mbante çdo kërkesë gjallë deri në fund të turnit; dhe gjurmimi i kornizës së agjentit mbante hyrjet e çdo thirrjeje, përfshirë imazhet, për gjithë turnin. I rregulluam të tre: imazhet zvogëlohen përpara se të dërgohen, dhe imazhet e çdo thirrjeje lirohen sapo mbaron ajo thirrje.

Si e shikon agjenti imazhet

Kur ndërton në Mythex, agjenti punon brenda sandbox-it cloud të projektit tënd. Mund të shikojë imazhe, një screenshot që bashkangjit, një maketë, një skedar në projekt, ose një imazh që vetë sapo prodhoi, duke ua dërguar modelit bashkë me bisedën.

Një turn është gjithçka që bën agjenti si përgjigje ndaj një mesazhi nga ti. Brenda një turni, agjenti i thërret modelit shumë herë: mendon, ekzekuton një mjet, shikon rezultatin, mendon përsëri. Çdo thirrje dërgon bisedën deri atëherë, dhe kjo përfshin imazhet e turnit, të koduara si tekst (base64, që i bën rreth një të tretën më të mëdha).

Turni që u rrëzua po bënte diçka arsyetuese. Mori gjashtë skanime katalogu, rreth 2.4 MB secili, preu produkte individuale nga to, dhe vazhdoi t’i lexonte prerjet për ta kontrolluar. Janë shumë thirrje modeli, secila me disa imazhe të mëdha.

Shkaku 1: çdo thirrje ridërgonte imazhe në madhësi të plotë

Çdo thirrje modeli rindërtonte trupin e kërkesës me imazhet e turnit në madhësi të plotë, rreth 20 MB base64 për thirrje. Trupi ndërtohet si një varg i vetëm në memorien e agjentit, kështu që çdo thirrje alokonte edhe ~20 MB të tjera.

Dërgimi në madhësi të plotë as që sillte ndonjë përfitim. Modeli vetë i zvogëlon imazhet rreth 1,300 piksel në anën e gjatë, kështu që pikselët shtesë kushtonin vetëm memorie dhe kohë ngarkimi.

Rregullimi: zvogëlo një herë, dërgo të vogla

• Imazhet mbi 400 KB konvertohen tani në JPEG me së shumti 1,568 piksel në anën e gjatë, përpara se të dërgohen. Imazhet më të vogla shkojnë ashtu siç janë.
• Konvertimi bëhet me ImageMagick, që gjendet në çdo sandbox Mythex, dhe ekzekutohet një herë për skedar. Një turn që shfaq të njëjtat skanime në çdo thirrje ripërdor kopjen e zvogëluar. Cache-i çelësohet sipas shtegut të skedarit, madhësisë dhe datës së modifikimit, kështu që një skedar i ndryshuar konvertohet përsëri, dhe ka kufirin e vet të madhësisë që të mos bëhet vetë ajo që mbush memorien.
• Buxheti për imazhet në një thirrje të vetme modeli zbret nga 16 MB në 6 MB.

Të njëjtat gjashtë skanime kushtojnë tani 4.4 MB për thirrje, në vend të 19.7 MB.

Shkaku 2: klienti i modelit nuk e lëshonte kurrë kërkesën

Madhësia e çdo kërkese ishte vetëm një pjesë e problemit. Memoria gjithashtu rritej nga thirrja në thirrje. Në mjedisin tonë staging, i njëjti lloj turni mbante 369 MB memorie aktive edhe pas një garbage collection të plotë, pikën ku çdo gjë e paarritshme liridohet. Mostrat e heap-it e vunë gjithë rritjen te pjesa e bibliotekës së klientit të modelit që kodon trupat e kërkesave.

Shkaku ishte një listener abort. Kur shtyp Stop, sinjali i abort-it të turnit lëshohet dhe çdo kërkesë që dëgjon anulohet. Ne i kalonim atë sinjal të vetëm për të gjitha kërkesat. Klienti i bibliotekës shton një listener “abort” në çdo sinjal që i jepet, dhe nuk e heq kurrë.

Kështu çdo kërkesë e një turni mbetej e arritshme nga sinjali i turnit, për gjithë kohëzgjatjen e turnit: listener-i, që mbante kontrollin e kërkesës, që mbante vetë kërkesën, që mbante trupin e plotë të kërkesës me imazhet.

Rregullimi: një sinjal për çdo kërkesë

Tani çdo kërkesë merr sinjalin e vet. Lidhet me sinjalin e turnit vetëm ndërsa kjo kërkesë po ekzekutohet, për një përgjigje të transmetuar deri te copa e fundit e lexuar, dhe shkëputet menjëherë pas kësaj. Stop ende arrin çdo kërkesë që është në udhë, por sinjali i turnit mban gjithmonë vetëm një listener në një kohë.

Testet mbulojnë të tre pjesët:

• Pas 12 thirrjesh, nuk mbeten listener-ë në sinjalin e turnit. Para rregullimit, ishin 12.
• Mbi 15 kërkesa prej 8 MB secila, memoria mbetet e qëndrueshme. Më parë rritej me 128 MB.
• Shtypja e Stop ndërpret ende një kërkesë në mes të transmetimit të saj.

Shkaku 3: gjurmimi mbante hyrjet e çdo thirrjeje

Një snapshot i heap-it tregoi një mbajtës të tretë: rreth 6 MB për çdo thirrje modeli. Ky vinte nga transmetimi i ngjarjeve i kornizës së agjentit. Ai regjistron çdo thirrje modeli brenda turnit si fëmijë të turnit, përfshirë hyrjet, deri në fund të turnit. Çdo imazh i bashkangjitur në çdo thirrje mbetej në memorie me të.

Rregullimi: zbraz imazhet sapo kthehet thirrja

Imazhet bashkangjiten vetëm te mesazhet e ndërtuara për një thirrje specifike modeli. Nuk ruhen kurrë në gjendjen e ruajtur të bisedës. Kështu që, sapo kthehet një thirrje, është e sigurt të zbrazen të dhënat e imazhit në ato mesazhe. Gjurmimi mban një regjistrim tekst të thirrjes; pikselët largohen.

Një detaj ishte me rëndësi: imazhet duhet të zbrazen në vend. Gjurmuesi mund të arrijë të dhënat e të njëjtit imazh përmes më shumë se një reference në një mesazh, kështu që zëvendësimi me një listë të re të zbrazët do të linte origjinalin, me pikselët dhe gjithçka, ende të arritshëm. Gjendja e ruajtur e bisedës nuk ndryshohet kurrë.

Një test e ekzekuton grafin e agjentit nën të njëjtin transmetim ngjarjesh me një imazh 4 MB në çdo thirrje. Pa rregullimin, memoria u rrit me 77 MB gjatë 16 thirrjeve. Me rregullimin, memoria mbetet e qëndrueshme.

Çfarë morëm nga kjo

• Problemet e memories mund të vijnë në shtresa. Tre shkaqe të ndara mbanin imazhet më gjatë se duhet, dhe të tre duhej të largoheshin para se turni të mbetej brenda memories.
• Çdo gjë që i jep një biblioteke mund të mbahet. Një sinjal dhe një gjurmim mbijetuan thirrjet që u ishin dhënë. Kur memoria rritet për çdo thirrje, shiko çfarë objektesh afatgjata prek thirrja.
• Mos dërgo atë që pala tjetër e hedh tej. Pikselët që modeli do t’i hidhte gjithsesi na kushtonin memorie në çdo thirrje.
• Testo memorien drejtpërdrejt. Çdo rregullim erdhi me një test që mat rritjen e heap-it ose numrin e listener-ëve, kështu që një regres duket si një numër, jo si një rrëzim.

Kjo është historia e dytë e memories nga agjenti brenda pak kohe; e para ishte një etiketë progresi që u rifreskua 41,000 herë. Nëse dëshiron të dish më shumë për atë që është agjenti dhe si funksionon, shih udhëzuesin tonë për agjentët AI dhe dokumentacionin e chat-it.