Ar attēliem bagātus aģenta gājienus saglabājam atmiņas robežās

Aģenta gājiens ražošanā beidzās ar atmiņu pie 952 MB, kamēr no sešiem katalogu skenējumiem izgrieza produktus un skatījās savus izgriezumus. Nebija viena noplūdes avota — bija trīs. Katrs modeļa izsaukums atkārtoti sūtīja gājiena attēlus pilnā izmērā; bibliotēka, ko izmantojam modeļa izsaukšanai, turēja katru pieprasījumu dzīvu līdz gājiena beigām; un aģenta ietvara izsekošana glabāja katra izsaukuma ievadus, arī attēlus, visu gājienu. Visus trīs novērsām: attēli tiek samazināti, pirms tos nosūta, un katra izsaukuma attēli tiek atbrīvoti, tiklīdz izsaukums ir pabeigts.

Kā aģents redz attēlus

Veidojot uz Mythex, aģents darbojas tava projekta mākoņa sandbox. Tas var skatīties attēlus — ekrānuzņēmumu, ko pievienoji, maketu, failu projektā vai attēlu, ko pats tikko izveidoja — sūtot tos modelim kopā ar sarunu.

Gājiens ir viss, ko aģents dara atbildot uz vienu tavu ziņojumu. Gājiena laikā aģents modeli izsauc daudzas reizes: domā, palaiž rīku, skata rezultātu, domā vēlreiz. Katrs no šiem izsaukumiem nosūta sarunu līdz šim, tostarp gājiena attēlus, kodētus kā tekstu (base64, kas padara tos par aptuveni trešdaļu lielākus).

Gājiens, kas avarēja, darīja kaut ko saprātīgu. Tas paņēma sešus katalogu skenējumus, katrs ap 2,4 MB, izgrieza atsevišķus produktus un vairākkārt nolasīja izgriezumus, lai tos pārbaudītu. Tas ir daudz modeļa izsaukumu, katrs ar vairākiem lieliem attēliem.

1. cēlonis: katrs izsaukums atkārtoti sūtīja pilna izmēra attēlus

Katrs modeļa izsaukums pārbūvēja savu pieprasījuma ķermeni ar gājiena attēliem pilnā izmērā — ap 20 MB base64 katrā izsaukumā. Ķermenis tiek veidots kā viena virkne aģenta atmiņā, tāpēc katrs izsaukums piešķīra vēl ~20 MB.

Pilna izmēra sūtīšana pat nenesa nekādu labumu. Modelis pats samazina attēlus līdz aptuveni 1300 pikseļiem garākajā malā, tāpēc papildu pikseļi tikai patērē atmiņu un augšupielādes laiku.

Risinājums: samazināt vienreiz, sūtīt mazu

• Attēli virs 400 KB tiek pārvērsti JPEG formātā ar maksimums 1568 pikseļiem garākajā malā, pirms tos nosūta. Mazāki attēli tiek sūtīti kā ir.
• Pārvēršanai izmanto ImageMagick, kas ir katrā Mythex sandbox, un tā darbojas vienreiz katram failam. Gājiens, kas rāda tos pašus skenējumus katrā izsaukumā, izmanto atkārtoti samazināto kopiju. Kešatmiņa ir atslēgota pēc faila ceļa, izmēra un modifikācijas laika, tāpēc rediģēts fails tiek pārvērsts vēlreiz, un tai ir savs izmēra ierobežojums, lai tā pati nekļūtu par to, kas aizpilda atmiņu.
• Attēlu budžets vienā modeļa izsaukumā sarūk no 16 MB līdz 6 MB.

Tie paši seši skenējumi tagad maksā 4,4 MB katrā izsaukumā, nevis 19,7 MB.

2. cēlonis: modeļa klients nekad neatlaida pieprasījumu

Katra pieprasījuma izmērs bija tikai daļa no problēmas. Atmiņa arī auga izsaukumu pēc izsaukuma. Mūsu staging vidē tāds pats gājiens turēja 369 MB dzīvas atmiņas pat pēc pilnas atkritumu savākšanas — punkts, kur viss nesasniedzamais ir atbrīvots. Heap paraugu ņemšana parādīja, ka visa izaugsme ir modeļa klienta bibliotēkas daļā, kas kodē pieprasījumu ķermeņus.

Cēlonis bija abortēšanas klausītājs. Kad nospied Stop, gājiena abort signāls iedegas, un katrs pieprasījums, kas to klausās, atceļas. Mēs nodevām šo vienu, visam gājienam kopīgo signālu katram pieprasījumam. Klienta bibliotēka pievieno „abort” klausītāju jebkuram signālam, ko tai dod — un nekad to nenoņem.

Tātad katrs gājiena pieprasījums palika sasniedzams no gājiena signāla, cik ilgi gājiens ilga: klausītājs, kas turēja pieprasījuma kontrolieri, kas turēja pieprasījumu, kas turēja visu pieprasījuma ķermeni ar tā attēliem.

Risinājums: viens signāls katram pieprasījumam

Katram pieprasījumam tagad ir savs signāls. Tas tiek saistīts ar gājiena signālu tikai tik ilgi, cik pieprasījums darbojas — straumētai atbildei līdz pēdējam fragmentam, kas nolasīts — un atsaistīts tūlīt pēc tam. Stop joprojām sasniedz jebkuru pieprasījumu, kas ir procesā, bet gājiena signālam vienlaikus ir tikai viens klausītājs.

Testi aptver visas trīs daļas:

• Pēc 12 izsaukumiem uz gājiena signāla nepaliek neviena klausītāja. Pirms labojuma tādi bija 12.
• Pār 15 pieprasījumiem pa 8 MB katrs atmiņa paliek stabila. Pirms tam tā auga par 128 MB.
• Stop joprojām pārtrauc pieprasījumu tā straumes vidū.

3. cēlonis: izsekošana glabāja katra izsaukuma ievadus

Heap momentuzņēmums parādīja trešo turētāju: ap 6 MB katram modeļa izsaukumam. Tas nāca no aģenta ietvara notikumu straumēšanas. Tas ieraksta katru modeļa izsaukumu gājienā kā gājiena bērnu, ieskaitot ievadus, līdz gājiens beidzas. Katrs attēls, kas pievienots katram izsaukumam, palika atmiņā kopā ar to.

Risinājums: izdzēst attēlus, kad izsaukums ir atgriezies

Attēli tiek pievienoti tikai ziņojumiem, kas veidoti konkrētam modeļa izsaukumam. Tie nekad netiek glabāti sarunas saglabātajā stāvoklī. Tāpēc, kad izsaukums ir atgriezies, drošī ir tukšot attēlu datus šajos ziņojumos. Izsekošana saglabā teksta ierakstu par izsaukumu; pikseļi tiek izmesti.

Viena detaļa bija svarīga: attēli jātukšo vietā. Izsekotājs var sasniegt tos pašus attēla datus caur vairākām atsaucēm uz ziņojumu, tāpēc jauna, tukša saraksta ievietošana atstātu oriģinālu — pikseļus un visu — joprojām sasniedzamu. Saglabātā sarunas stāvokļa nekad nemaina.

Tests palaiž aģenta grafu zem tās pašas notikumu straumēšanas ar 4 MB attēlu katrā izsaukumā. Bez labojuma atmiņa auga par 77 MB pār 16 izsaukumiem. Ar labojumu atmiņa paliek stabila.

Ko no tā guvām

• Atmiņas problēmas var nākt slāņos. Trīs atsevišķi cēloņi katrs turēja attēlus pārāk ilgi, un visi trīs bija jānovērš, lai gājiens paliktu atmiņas robežās.
• Viss, ko nodod bibliotēkai, var tikt turēts. Signāls un izsekošana pārdzīvoja izsaukumus, kuriem tie bija domāti. Kad atmiņa aug katrā izsaukumā, paskaties, kādus ilgi dzīvojošus objektus izsaukums aizskar.
• Nesūti to, ko otra puse tik un tā izmet. Pikseļi, ko modelis tāpat atmestu, mums katrā izsaukumā maksāja atmiņu.
• Testē atmiņu tieši. Katram labojumam bija tests, kas mēra heap izaugsmi vai klausītāju skaitu, tāpēc regresija parādās kā skaitlis, nevis avārija.

Šis ir otrais atmiņas stāsts par aģenta izvadi īsā laikā; pirmais bija statusa uzraksts, kas 41 000 reizes atkārtoti nosūtīja virkni. Ja gribi uzzināt vairāk par to, kas ir aģents un kā tas darbojas, skaties mūsu ceļvedi par AI aģentiem un tērzēšanas dokumentāciju.