Image-heavy agent turns ને memory માં રાખવા

એક production agent turn છ catalogue scans માંથી products ને crop કરતી વખતે અને તેના crops જોતી વખતે 952 MB પર memory માંથી બહાર ગયો. એક જ leak નહોતો — ત્રણ હતા. મોડેલને દરેક call માં turn ના images પૂરા કદમાં ફરીથી મોકલાતા હતા; મોડેલ call કરવા માટે વપરાતી library દરેક request ને turn પૂરો થાય ત્યાં સુધી જીવંત રાખતી હતી; અને agent framework નું tracing દરેક call ના inputs, images સહિત, આખા turn દરમિયાન રાખતું હતું. અમે ત્રણેય ઠીક કર્યા: images મોકલતા પહેલાં નાની કરવામાં આવે છે, અને દરેક call ના images call પૂરો થતાં જ છોડી દેવામાં આવે છે.

Agent images કેવી રીતે જુએ છે

Mythex પર બનાવતી વખતે, agent તમારા પ્રોજેક્ટના cloud sandbox ની અંદર કામ કરે છે. તે images જોઈ શકે છે — તમે attach કરેલો screenshot, mockup, તમારા પ્રોજેક્ટમાંની ફાઇલ, અથવા તેણે પોતે હમણાં બનાવેલી image — તેમને વાતચીત સાથે મોડેલને મોકલીને.

Turn એ તમારા એક સંદેશના જવાબમાં agent જે કંઈ કરે તે બધું છે. એક turn ની અંદર, agent મોડેલને ઘણી વાર call કરે છે: વિચારે, tool ચલાવે, પરિણામ જુએ, ફરીથી વિચારે. દરેક call અત્યાર સુધીની વાતચીત મોકલે છે, અને તેમાં turn ના images પણ હોય છે, જે text તરીકે encode થયેલા હોય છે (base64, જે તેમને લગભગ એક તૃતીયાંશ મોટા કરે છે).

જે turn crash થયો તે વાજબી કામ કરી રહ્યો હતો. તેણે છ catalogue scans લીધા, દરેક લગભગ 2.4 MB, તેમાંથી વ્યક્તિગત products crop કર્યા, અને તપાસવા માટે તેના crops ફરી વાંચતો રહ્યો. તે ઘણી model calls હતી, દરેકમાં ઘણા મોટા images.

કારણ 1: દરેક call માં પૂરા કદના images ફરી મોકલાતા

દરેક model call તેની request body ફરીથી બનાવતી હતી, જેમાં turn ના images પૂરા કદમાં હતા — દરેક call દીઠ લગભગ 20 MB base64. body agent ની memory માં એક string તરીકે બનતી હતી, તેથી દરેક call બીજા ~20 MB ફાળવતી.

પૂરા કદમાં મોકલવાથી કંઈ ફાયદો પણ નહોતો. મોડેલ images ને પોતે લગભગ 1,300 pixels ની લાંબી બાજુ સુધી ઘટાડે છે, તેથી વધારાના pixels ફક્ત memory અને upload સમય ખર્ચતા હતા.

ઉકેલ: એક વાર નાની કરો, નાની મોકલો

• 400 KB કરતાં મોટા images હવે મોકલતા પહેલાં લાંબી બાજુએ વધુમાં વધુ 1,568 pixels સુધીના JPEG માં બદલાય છે. નાના images જેવા છે તેવા જ જાય છે.
• રૂપાંતર ImageMagick વડે થાય છે, જે દરેક Mythex sandbox માં આવે છે, અને દરેક ફાઇલ માટે એક વાર ચાલે છે. જે turn દરેક call માં એ જ scans બતાવે છે તે નાની થયેલી નકલ ફરી વાપરે છે. આ cache ફાઇલના path, size અને modification time થી ઓળખાય છે, તેથી સંપાદિત ફાઇલ ફરી રૂપાંતરિત થાય છે, અને તેની પોતાની size મર્યાદા છે જેથી તે પોતે memory ભરનારી વસ્તુ ન બને.
• એક model call માં images માટેનું બજેટ 16 MB થી 6 MB સુધી ઘટે છે.

એ જ છ scans હવે દરેક call દીઠ 19.7 MB ને બદલે 4.4 MB ખર્ચે છે.

કારણ 2: model client ક્યારેય request છોડતું ન હતું

દરેક request નું કદ એ તો માત્ર એક ભાગ હતો. Memory પણ call પછી call વધતી ગઈ. અમારા staging environment પર, એ જ પ્રકારનો turn પૂરા garbage collection પછી પણ 369 MB જીવંત memory ધરાવતો હતો — એ બિંદુ જ્યાં પહોંચી ન શકાય એવી દરેક વસ્તુ મુક્ત થઈ ગઈ હોય. Heap sampling એ બધી વૃદ્ધિ model client library ના તે ભાગમાં મૂકી, જે request bodies encode કરે છે.

કારણ abort listener હતું. જ્યારે તમે Stop દબાવો છો, ત્યારે turn નો abort signal ફાયર થાય છે, અને તેને સાંભળતી દરેક request રદ થાય છે. અમે તે એક turn-વ્યાપી signal દરેક request ને આપતા હતા. Client library દરેક signal પર "abort" listener ઉમેરે છે — અને તેને ક્યારેય દૂર કરતી નથી.

તેથી turn ની દરેક request turn ના signal થી જોડાયેલી રહેતી, turn ચાલે ત્યાં સુધી: listener, જે controller ધરાવતું, જે request ધરાવતી, જે images સહિતની આખી request body ધરાવતી.

ઉકેલ: દરેક request માટે એક signal

હવે દરેક request ને પોતાનો signal મળે છે. તે turn ના signal સાથે ફક્ત તે request ચાલે ત્યારે જ જોડાય છે — streamed response માટે, છેલ્લો chunk વાંચાય ત્યાં સુધી — અને તરત પછી છૂટું પડે છે. Stop હજી પણ ચાલતી કોઈપણ request સુધી પહોંચે છે, પરંતુ turn ના signal પર એક સમયે ફક્ત એક listener રહે છે.

Tests એ ત્રણેય ભાગ આવરી લે છે:

• 12 calls પછી turn ના signal પર કોઈ listeners બાકી નથી. fix પહેલાં, 12 હતા.
• 8 MB ની 15 requests પર memory સ્થિર રહે છે. પહેલાં, તે 128 MB વધતી હતી.
• Stop હજી પણ stream ની વચ્ચે રહેલી request ને abort કરે છે.

કારણ 3: tracing દરેક call ના inputs રાખતું હતું

Heap snapshot એ ત્રીજો ધારક બતાવ્યો: દરેક model call દીઠ લગભગ 6 MB રાખવામાં આવતું હતું. આ agent framework ના event streaming માંથી આવતું હતું. તે turn માં દરેક model call ને turn ના child તરીકે રેકોર્ડ કરે છે, inputs સહિત, turn પૂરો થાય ત્યાં સુધી. દરેક call સાથે જોડાયેલો દરેક image તેની સાથે memory માં રહેતો.

ઉકેલ: call પાછો આવે કે તરત images ખાલી કરો

Images ફક્ત એક ચોક્કસ model call માટે બનાવેલા messages સાથે જ જોડાયેલા હોય છે. તે ક્યારેય વાતચીતની સાચવેલી state માં સંગ્રહાતા નથી. તેથી એકવાર call પાછો આવે, પછી તે messages માંનો image data ખાલી કરવો સુરક્ષિત છે. trace call નો text રેકોર્ડ રાખે છે; pixels જાય છે.

એક વિગત મહત્વની હતી: images ને જગ્યાએ જ ખાલી કરવા પડે. Tracer એક message પરના એક જ image data સુધી એકથી વધુ reference દ્વારા પહોંચી શકે છે, તેથી નવી, ખાલી list સ્થાપિત કરવાથી મૂળ — pixels સહિત — હજી પહોંચી શકાય એવું રહેત. સાચવેલી વાતચીતની state ક્યારેય બદલાતી નથી.

એક test agent ના graph ને એ જ event streaming હેઠળ ચલાવે છે, જેમાં દરેક call પર 4 MB નો image છે. fix વગર, 16 calls પર memory 77 MB વધી. તેની સાથે, memory સ્થિર રહે છે.

અમે શું શીખ્યા

• Memory ની સમસ્યાઓ સ્તરોમાં આવી શકે છે. ત્રણ અલગ કારણો દરેકે images ને વધુ સમય રાખ્યા, અને turn memory માં રહેવા માટે ત્રણેય દૂર કરવા પડ્યા.
• લાઇબ્રેરીને જે કંઈ આપો તે રાખી શકાય છે. એક signal અને એક trace બંને તેમને આપેલી calls કરતાં વધુ જીવ્યા. જ્યારે memory દરેક call સાથે વધે, ત્યારે જુઓ કે call કઈ લાંબા-જીવી વસ્તુઓને સ્પર્શે છે.
• જે બાજુ ફેંકી દે છે તે મોકલશો નહીં. Model જે pixels ફેંકી દેવાનું હતું તે દરેક call પર અમારી memory ખર્ચતા હતા.
• Memory સીધી રીતે ટેસ્ટ કરો. દરેક fix સાથે એક ટેસ્ટ આવ્યો જે heap વૃદ્ધિ અથવા listener ગણતરી માપે છે, જેથી regression crash ને બદલે એક આંકડા તરીકે દેખાય.

આ agent તરફથી ટૂંકા સમયમાં આ બીજી memory વાર્તા છે; પહેલી progress label જે 41,000 વાર ફરી મોકલાતું હતું હતી. જો તમે જાણવા માંગતા હો કે agent શું છે અને તે કેવી રીતે કામ કરે છે, તો AI agents પરની અમારી guide અને chat docs જુઓ.