Պատկերներով ծանր agent-ի քայլերը պահել հիշողության սահմաններում

Production-ում agent-ի մի քայլ հիշողությունը սպառեց 952 ՄԲ-ի սահմանին, երբ կտրում էր ապրանքները վեց կատալոգային սկաններից և դիտում իր կտրվածքները։ Մեկ արտահոսք չկար․ երեք էին։ Մոդելին յուրաքանչյուր կանչի ժամանակ նորից էր ուղարկվում քայլի բոլոր նկարները լրիվ չափով. մոդելը կանչող գրադարանը պահում էր յուրաքանչյուր հարցում կենդանի մինչև քայլի ավարտը. իսկ agent framework-ի tracing-ը պահում էր յուրաքանչյուր կանչի մուտքերը, ներառյալ նկարները, ամբողջ քայլի ընթացքում։ Շտկեցինք բոլոր երեքը․ նկարները փոքրացվում են նախքան ուղարկվելը, և յուրաքանչյուր կանչի նկարները ազատվում են, հենց որ կանչն ավարտվում է։

Ինչպես է agent-ը տեսնում նկարները

Մythex-ում կառուցելիս agent-ը աշխատում է ձեր նախագծի ամպային sandbox-ի ներսում։ Այն կարող է նայել նկարներին՝ ձեր կցած screenshot-ին, մակետին, նախագծի ֆայլին կամ նկարին, որ ինքն է հենց նոր ստեղծել, դրանք ուղարկելով մոդելին՝ զրույցի հետ միասին։

Քայլը այն ամենն է, ինչ agent-ն անում է ձեր մեկ հաղորդագրության պատասխանում։ Քայլի ընթացքում agent-ը բազմիցս է կանչում մոդելը. մտածում է, գործիք է գործարկում, նայում արդյունքին, նորից մտածում։ Յուրաքանչյուր այդ կանչ ուղարկում է մինչ այդ եղած զրույցը, և դա ներառում է քայլի նկարները, որոնք կոդավորված են որպես տեքստ (base64, ինչը դրանք մոտ մեկ երրորդով մեծացնում է)։

Քայլը, որ խափանվեց, ողջամիտ բան էր անում. վերցրեց վեց կատալոգային սկան, յուրաքանչյուրը մոտ 2.4 ՄԲ, կտրեց առանձին ապրանքներ և նորից կարդում էր իր կտրվածքները ստուգելու համար։ Դա բազմաթիվ մոդելային կանչեր էին, յուրաքանչյուրը մի քանի մեծ նկարով։

Պատճառ 1. յուրաքանչյուր կանչ նորից ուղարկում էր լրիվ չափի նկարները

Յուրաքանչյուր մոդելային կանչ իր հարցման մարմինը կառուցում էր նորից, քայլի նկարները լրիվ չափով. մոտ 20 ՄԲ base64 յուրաքանչյուր կանչի վրա։ Մարմինը կառուցվում էր որպես մեկ տող agent-ի հիշողության մեջ, ուստի յուրաքանչյուր կանչ հատկացնում էր ևս մոտ 20 ՄԲ։

Լրիվ չափով ուղարկելը նույնիսկ օգուտ չէր տալիս։ Մոդելը ինքը նկարները մասշտաբավորում է մոտ 1,300 պիքսել երկար կողմով, ուստի լրացուցիչ պիքսելները միայն հիշողություն և վերբեռնման ժամանակ էին արժենում։

Լուծում. փոքրացնել մեկ անգամ, ուղարկել փոքր

• 400 ԿԲ-ից մեծ նկարները, նախքան ուղարկելը, վերածվում են JPEG-ի, որը երկար կողմով ամենաշատը 1,568 պիքսել է։ Փոքր նկարները ուղարկվում են այնպես, ինչպես կան։
• Փոխակերպումն օգտագործում է ImageMagick-ը, որը հասանելի է յուրաքանչյուր Mythex sandbox-ում, և աշխատում է մեկ անգամ յուրաքանչյուր ֆայլի համար։ Քայլը, որ նույն սկանները ցույց է տալիս յուրաքանչյուր կանչում, օգտագործում է փոքրացված պատճենը։ Քեշը բանալի ունի ֆայլի ուղին, չափը և փոփոխման ժամանակը, այնպես որ փոփոխված ֆայլը նորից է փոխակերպվում, և քեշն ունի իր սեփական չափի սահմանը, որպեսզի ինքը չդառնա հիշողությունը լցնող բան։
• Մեկ մոդելային կանչում նկարների բյուջեն իջավ 16 ՄԲ-ից 6 ՄԲ։

Նույն վեց սկանները այժմ արժեն 4.4 ՄԲ յուրաքանչյուր կանչում՝ 19.7 ՄԲ-ի փոխարեն։

Պատճառ 2. մոդելի կլիենտը երբեք չէր ազատում հարցումը

Յուրաքանչյուր հարցման չափը միայն մասն էր խնդրի։ Հիշողությունը նույնպես աճում էր կանչից կանչ։ Մեր staging միջավայրում նույն տեսակի քայլը պահում էր 369 ՄԲ կենդանի հիշողություն, նույնիսկ լրիվ garbage collection-ից հետո՝ այն կետում, երբ ամեն ինչ, որին հասնել հնարավոր չէ, արդեն ազատված է։ Heap sampling-ը ամբողջ աճը տեղադրեց մոդելի կլիենտ գրադարանի այն մասում, որը կոդավորում է հարցման մարմինները։

Պատճառը abort listener-ն էր։ Երբ սեղմում եք Stop, քայլի abort signal-ը գործարկվում է, և յուրաքանչյուր հարցում, որ լսում է դա, չեղարկվում է։ Մենք այդ մեկ, քայլի ամբողջական signal-ը փոխանցում էինք յուրաքանչյուր հարցման։ Կլիենտ գրադարանը «abort» listener է ավելացնում այն signal-ին, որ ստանում է, և երբեք չի հեռացնում այն։

Այսպիսով, քայլի յուրաքանչյուր հարցում մնում էր հասանելի քայլի signal-ից, քայլի ողջ տևողության ընթացքում. listener-ը, որը պահում էր controller-ը, որը պահում էր հարցումը, որը պահում էր ամբողջ հարցման մարմինը իր նկարներով։

Լուծում. մեկ signal յուրաքանչյուր հարցման համար

Յուրաքանչյուր հարցում այժմ ստանում է իր սեփական signal-ը։ Այն կապվում է քայլի signal-ի հետ միայն այն ժամանակ, երբ այդ հարցումը աշխատում է. streamed պատասխանի դեպքում՝ մինչև վերջին chunk-ի կարդալը, և անմիջապես հետո կապը խզվում է։ Stop դեռ հասնում է ընթացիկ հարցմանը, բայց քայլի signal-ը երբեք միաժամանակ ավելի քան մեկ listener չի պահում։

Թեստերը ծածկում են այդ երեք մասերը․

• 12 կանչից հետո քայլի signal-ի վրա listener չի մնում։ Շտկումից առաջ՝ 12 էր։
• 15 հարցման վրա՝ յուրաքանչյուրը 8 ՄԲ, հիշողությունը մնում է հարթ։ Առաջ՝ աճում էր 128 ՄԲ-ով։
• Stop-ը դեռ ընդհատում է հարցումը իր stream-ի մեջտեղում։

Պատճառ 3. tracing-ը պահում էր յուրաքանչյուր կանչի մուտքերը

Heap snapshot-ը ցույց տվեց երրորդ պահողին՝ մոտ 6 ՄԲ յուրաքանչյուր մոդելային կանչի համար։ Այն գալիս էր agent framework-ի event streaming-ից։ Այն գրանցում է քայլի յուրաքանչյուր մոդելային կանչ որպես քայլի երեխա, մուտքերով հանդերձ, մինչև քայլն ավարտվի։ Յուրաքանչյուր կանչին կցված յուրաքանչյուր նկար մնում էր հիշողության մեջ իր հետ։

Լուծում. մաքրել նկարները, երբ կանչը վերադառնում է

Նկարները կցվում են միայն կոնկրետ մոդելային կանչի համար կառուցված հաղորդագրություններին։ Դրանք երբեք չեն պահվում զրույցի պահված վիճակում։ Ուստի երբ կանչը վերադառնում է, ապահով է դատարկել այդ հաղորդագրությունների նկարների տվյալները։ Tracing-ը պահում է կանչի տեքստային գրառումը, պիքսելները՝ ոչ։

Մեկ մանրամասն կարևոր էր․ նկարները պետք է մաքրվեն տեղում։ Tracer-ը կարող է հասնել նույն նկարի տվյալներին հաղորդագրության վրա մեկից ավելի հղումով, ուստի նոր, դատարկ ցուցակով փոխարինելը կթողներ բնօրինակը՝ պիքսելներով հանդերձ, դեռ հասանելի։ Պահված զրույցի վիճակը երբեք չի փոփոխվում։

Թեստը գործարկում է agent-ի graph-ը նույն event streaming-ով՝ յուրաքանչյուր կանչի վրա 4 ՄԲ նկարով։ Առանց շտկման հիշողությունը աճում էր 77 ՄԲ 16 կանչի ընթացքում։ Շտկումով՝ մնում է հարթ։

Ինչ սովորեցինք

• Հիշողության խնդիրները կարող են շերտավոր լինել։ Երեք առանձին պատճառ յուրաքանչյուրը պահում էր նկարները չափազանց երկար, և բոլոր երեքը պետք էր վերացնել, որ քայլը մնար հիշողության սահմաններում։
• Այն, ինչ տալիս եք գրադարանին, կարող է պահվել։ Signal-ը և trace-ը երկուսն էլ գերազանցում էին իրենց տրված կանչերը։ Երբ հիշողությունը աճում է յուրաքանչյուր կանչի հետ, նայեք, թե ինչ երկարակյաց օբյեկտներին է դիպչում կանչը։
• Մի ուղարկեք այն, ինչ մյուս կողմը ինքը նետում է։ Պիքսելներ, որոնք մոդելը այնպես էլ կհեռացներ, յուրաքանչյուր կանչում արժեցնում էին հիշողություն։
• Փորձարկեք հիշողությունը ուղղակիորեն։ Յուրաքանչյուր շտկում ուներ թեստ, որ չափում է heap-ի աճը կամ listener-ների քանակը, այնպես որ ռեգրեսիան երևում է որպես թիվ, ոչ թե վթար։

Այս agent-ի երկրորդ պատմությունն է հիշողության մասին վերջերս․ առաջինը առաջընթացի պիտակ էր, որ հերթագրեց 41,000 անգամ։ Եթե ուզում եք իմանալ, թե ինչ է agent-ը և ինչպես է աշխատում, տես մեր AI agent-ների ուղեցույցը և չատի փաստաթղթերը։