Håll bildtunga agentturer inom minnesgränsen

En agenttur i produktion slog i minnestaket vid 952 MB medan den klippte ut produkter från sex katalogskanningar och granskade sina utklipp. Det fanns inte ett läckage — det fanns tre. Varje anrop till modellen skickade om turens bilder i full storlek; biblioteket vi använder för att anropa modellen höll varje förfrågan vid liv tills turen var slut; och agentramverkets spårning behöll varje anrops indata, bilder inkluderade, under hela turen. Vi åtgärdade alla tre: bilder krymps innan de skickas, och varje anrops bilder släpps så snart anropet är klart.

Så ser agenten bilder

När du bygger på Mythex arbetar agenten i projektets molnsandlåda. Den kan titta på bilder — en skärmdump du bifogar, en mockup, en fil i ditt projekt eller en bild den just producerat själv — genom att skicka dem till modellen tillsammans med konversationen.

En tur är allt agenten gör som svar på ett meddelande från dig. Inom en tur anropar agenten modellen många gånger: tänker, kör ett verktyg, tittar på resultatet, tänker igen. Varje sådant anrop skickar konversationen hittills, och det inkluderar turens bilder, kodade som text (base64, vilket gör dem ungefär en tredjedel större).

Turen som kraschade gjorde något rimligt. Den tog sex katalogskanningar på cirka 2,4 MB vardera, klippte ut enskilda produkter ur dem och läste tillbaka sina utklipp för att kontrollera dem. Det är många modellanrop, var och en med flera stora bilder.

Orsak 1: varje anrop skickade om bilder i full storlek

Varje modellanrop byggde sin begäran på nytt med turens bilder i full storlek — ungefär 20 MB base64 per anrop. Begäran byggs som en enda sträng i agentens minne, så varje anrop allokerade ytterligare cirka 20 MB.

Att skicka full storlek gav inte ens något. Modellen skalar själv ner bilder till cirka 1 300 pixlar på den långa sidan, så de extra pixlarna kostade bara minne och uppladdningstid.

Lösningen: krymp en gång, skicka små

• Bilder över 400 KB konverteras nu till en JPEG med högst 1 568 pixlar på den långa sidan innan de skickas. Mindre bilder skickas som de är.
• Konverteringen använder ImageMagick, som finns i varje Mythex-sandlåda, och körs en gång per fil. En tur som visar samma skanningar i varje anrop återanvänder den krympta kopian. Cachen nycklas på filens sökväg, storlek och ändringstid, så en redigerad fil konverteras om, och den har sin egen storleksgräns så att den inte kan bli det som fyller minnet.
• Budgeten för bilder i ett enda modellanrop sänks från 16 MB till 6 MB.

Samma sex skanningar kostar nu 4,4 MB per anrop i stället för 19,7 MB.

Orsak 2: modellklienten släppte aldrig en förfrågan

Storleken på varje förfrågan var bara en del av det. Minnet växte också anrop för anrop. På vår stagingmiljö höll samma sorts tur 369 MB levande minne även efter en fullständig skräpinsamling — punkten där allt som inte längre nås har frigjorts. Heap-sampling placerade hela tillväxten i den del av modellklientbiblioteket som kodar förfrågningskroppar.

Orsaken var en abort-lyssnare. När du trycker på Stopp avfyras turens abort-signal, och varje förfrågan som lyssnar avbryts. Vi skickade den turövergripande signalen till varje förfrågan. Klientbiblioteket lägger till en „abort”-lyssnare på signalen den får — och tar aldrig bort den.

Så varje förfrågan i en tur förblev nåbar från turens signal, så länge turen varade: lyssnaren, som höll kontrollern, som höll förfrågan, som höll hela förfrågningskroppen med sina bilder.

Lösningen: en signal per förfrågan

Varje förfrågan får nu sin egen signal. Den länkas till turens signal bara medan just den förfrågan kör — för ett strömmat svar, tills sista delen har lästs — och kopplas bort direkt efteråt. Stopp når fortfarande den förfrågan som pågår, men turens signal håller bara en lyssnare åt gången.

Testerna täcker alla tre delarna:

• Efter 12 anrop finns inga lyssnare kvar på turens signal. Före fixen fanns 12.
• Över 15 förfrågningar på 8 MB vardera är minnet stabilt. Förut växte det med 128 MB.
• Stopp avbryter fortfarande en förfrågan mitt i dess ström.

Orsak 3: spårningen behöll varje anrops indata

En heap-ögonblicksbild visade en tredje innehavare: cirka 6 MB per modellanrop. Den här kom från agentramverkets händelseströmning. Den registrerar varje modellanrop i en tur som ett barn till turen, inklusive indata, tills turen är slut. Varje bild som bifogades till varje anrop fanns kvar i minnet tillsammans med det.

Lösningen: töm bilderna när anropet returnerar

Bilder kopplas bara till de meddelanden som byggts för ett specifikt modellanrop. De sparas aldrig i konversationens sparade tillstånd. Så när ett anrop har returnerat är det säkert att tömma bilddatan i dessa meddelanden. Spårningen behåller en textuell post av anropet; pixlarna försvinner.

En detalj var viktig: bilderna måste tömmas på plats. Spårningen kan nå samma bilddata via mer än en referens i ett meddelande, så att byta ut mot en ny, tom lista skulle lämna originalet — pixlar och allt — nåbart. Det sparade konversationstillståndet ändras aldrig.

Ett test kör agentens graf under samma händelseströmning med en 4 MB-bild i varje anrop. Utan fixen växte minnet med 77 MB över 16 anrop. Med den är minnet stabilt.

Vad vi tog med oss

• Minnesproblem kan komma i lager. Tre separata orsaker höll var och en bilder för länge, och alla tre måste bort innan turen höll sig inom minnet.
• Allt du ger ett bibliotek kan behållas. En signal och en spårning överlevde båda anropen de fick. När minnet växer per anrop, titta på vilka långlivade objekt anropet rör.
• Skicka inte det som den andra sidan kastar. Pixlar som modellen ändå skulle förkasta kostade oss minne vid varje anrop.
• Testa minnet direkt. Varje fix kom med ett test som mäter heap-tillväxt eller antal lyssnare, så att en regression syns som ett tal, inte som en krasch.

Det här är den andra minneshistorien från agenten på kort tid; den första var en förloppsetikett som skickades om 41 000 gånger. Om du vill veta mer om vad agenten är och hur den fungerar, se vår guide om AI-agenter och chattdokumentationen.