Հիշողության սպառման վթարը, որը թաքնված է առաջընթացի պիտակում

Սեպտեմբերի վերջին մի երեկո օգտվողի աշխատանքային տարածքում AI agent-ը վթարվեց out-of-memory սխալով մի շրջանի մեջտեղում։ Ակնհայտ կասկածյալները՝ միաժամանակ աշխատող չափազանց շատ ենթա-agent-ներ կամ չափից մեծացած կոնտեքստ, երկուսն էլ սխալ էին։ Իրական պատճառը կարգավիճակի պիտակ էր․ մոդելը մեծ shell հրամանը հոսքով էր ուղարկում մի քանի նիշով, և մենք յուրաքանչյուր կտորի հետ ուղարկում էինք ամբողջ հրամանը մինչ այդ որպես առաջընթացի պիտակ։ 124 ԿԲ հրաման դարձավ մոտ 41,000 իրադարձություն և մոտ 690 ՄԲ հերթագրված տողեր։

Ինչպես է agent-ը հոսքով աշխատում

Երբ կառուցում եք Mythex-ում, agent-ը աշխատում է ձեր նախագծի մասնավոր cloud sandbox-ի ներսում։ Երբ մոդելը գրում է, նրա ելքը հոսքով հասնում է ձեր բրաուզեր․ տեքստը երևում է բառ առ բառ, և երբ գործիք է աշխատեցնում՝ ասենք՝ shell հրաման, որը ֆայլ է գրում, տեսնում եք նրա պիտակը, որը կենդանի թարմանում է, որպեսզի իմանաք, թե ինչ է անում։

Մոդելը հոսքում գրում է փոքր կտորներով։ Մեր օգտագործած մոդելի դեպքում դրանք հաճախ ընդամենը երեք նիշ էին։

Առաջին վարկածները սխալ էին

Վթարը նման էր մասշտաբի խնդրի, ուստի սկսեցինք այնտեղից։

• Զուգահեռ ենթա-agent-ներ՞։ Շրջանը օգտագործել էր միայն երկուսը, յուրաքանչյուրը մոտ 1.5 ՄԲ վիճակով։ Բավարար չէ։
• Պահպանված հետքեր՞։ Մեր թրեյսինգը պահում էր գործարկման ծառը հիշողության մեջ, բայց այն ոչ մոտ էր վթարի պահի heap-ի չափին։

Ամբողջ երկու պատմությունը հավանական էր և երկուսն էլ էժան էին հավատալու։ Ոչ մեկը չվերարտադրեց վթարը։ Դասը, որ մենք կրկնում ենք․ վարկածը պատճառ չէ, մինչև չի վերարտադրում ձախողումը։

Վերարտադրելով իրականում

Մենք ստեղծեցինք ժամանակավոր sandbox՝ արտադրության նույն հիշողության սահմաններով և կեղծ մոդել, որը հոսքով գրում էր մեծ ֆայլ իրական երեք նիշանոց կտորներով։ Նաև դանդաղեցրինք կողմը, որը կարդում էր socket-ի միջով, ինչպես իրական ցանցը։

Դա աշխատեց։ Heap-ը աճեց, և պրոցեսը մահացավ նույն սխալով։

Մեխանիզմը պարզ էր, երբ կարողացանք դիտել այն։ Երբ մոդելը մեծ հրաման էր գրում՝ այս դեպքում heredoc, որը գրում էր 124 ԿԲ ֆայլ, մեր հոսքի կոդը թարմացնում էր գործիքի պիտակը յուրաքանչյուր կտորի հետ։ Պիտակը նոր երեք նիշը չէր․ այն մինչ այդ եղած ամբողջ հրամանն էր։ Այսպիսով իրադարձությունները մեծանում էին՝ 3 նիշ, հետո 6, հետո 9, … մինչև 124 ԿԲ, մոտ 41,000 անգամ։ Socket-ը չէր կարողանում ուղարկել այնքան արագ, որքան դրանք արտադրվում էին, ուստի դրանք կուտակվում էին նրա գրման բուֆերում որպես տողեր՝ մոտ 690 ՄԲ։

Շտկումը

• Սահմանափակեք պիտակը։ Կարգավիճակի պիտակը պետք է միայն ասի, թե ինչ է կատարվում։ Այն այժմ սահմանափակված է 200 նիշով, և մենք նվազեցնում ենք, թե որքան հաճախ ենք նորից սկանավորում մասնակի հրամանը։
• Վերացրեք քառակուսային միացումը։ Հոսքային կտորները կրկնվող տողային միացմամբ միացնելը մեծ ելքերի համար O(n²) է։ Անցանք chunk-ով մոտեցման, որը ավելացնում է գծային ժամանակում։

Այնուհետև փնտրեցինք ցանկացած այլ բան, որ կարող էր անսահմանափակ աճել հոսող ելքի ծանրաբեռնվածության դեպքում, և սահմանափակեցինք այն․

• Չաթում ցուցադրվող կենդանի հրամանի ելքը խմբավորվում է և պահվում միայն վերջին 8,000 նիշը։
• Առանձին իրադարձության տողերը սահմանափակված են 4 ՄԲ-ով։
• Վերականգնման բուֆերը, որը բրաուզերը օգտագործում է վերամիանալուց հետո, սահմանափակված է 8 ՄԲ նախագծի համար։
• Հին ստուգման կետերը մաքրվում են շրջանի ընթացքում՝ պահելով նորագույն վիճակը և նախորդ շրջանների համար անհրաժեշտ խարսխները։

Ազնվորեն թեստավորել հեղեղները

Երկու բան այս թեստը դարձրեց ավելի դժվար, քան պետք էր․

1. Իրական մոդելները չեն համագործակցում։ Խնդրեք մոդելին տպել հսկայական ֆայլ, և այն սովորաբար կհրաժարվի, կամփոփի կամ ավելի խելամտորեն կգրի։ Հեղեղները թեստավորելու համար պետք է սկրիպտավորված մոդել, որը անում է հենց այն, ինչ ասում եք, և աշխատում է իրական agent կոդի միջով։
2. Սկրիպտները պետք է վարվեն մոդելի պես։ Մեր առաջին սկրիպտավորված մոդելը նույն պատասխանի ID-ն էր օգտագործում յուրաքանչյուր պատասխանի համար, ուստի agent framework-ը յուրաքանչյուր պատասխանը դիտում էր որպես նախորդի փոխարինում և շրջանները վաղ էր ավարտում։ Թվում էր, թե UI թարմացման սխալ է։ Դա չէր․ դա թեստային հարմարանքն էր սուտ ասում։ Մենք նաև ստիպված էինք սկրիպտում պարտադրել մոդելի իրական կոնտեքստի սահմանը, հակառակ դեպքում հիշողության թվերը անիրական էին։

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

• Հոսքային UI-ները բազմապատկում են փոքր սխալները։ Ցանկացած բան, որ ուղարկում եք «յուրաքանչյուր կտորի համար», ուղարկվում է տասնյակ հազարավոր անգամ։ Ուղարկեք դելտաներ կամ սահմանափակեք բեռը։
• Սահմանափակեք յուրաքանչյուր բուֆեր, որ անցնում է դանդաղ սահմանը։ Socket-ները, վերարտադրման մատյանները և ստուգման կետերը բոլորին պետք է առաստաղ։
• Վերարտադրեք նախքան շտկելը։ Մեր առաջին երկու բացատրությունները ճիշտ էին հնչում և սխալ էին։

Եթե վերջերս Mythex չաթում տեսել եք շատ երկար ֆայլ, որ հայտնվում է առանց agent-ի կանգ առնելու, սա մասամբ այդ պատճառով է։