પ્રોગ્રેસ લેબલમાં છુપાયેલો આઉટ-ઑફ-મેમરી ક્રેશ

સપ્ટેમ્બરના અંતે એક સાંજે, એક વપરાશકર્તાના વર્કસ્પેસમાં AI એજન્ટ ટર્નની વચ્ચે આઉટ-ઑફ-મેમરી એરર સાથે ક્રેશ થયું. દેખીતા શંકાસ્પદ — ઘણા બધા સબ-એજન્ટ્સ એકસાથે ચાલતા હોવા, અથવા સંદર્ભ ખૂબ મોટો થઈ ગયો હોવો — બંને ખોટા હતા. વાસ્તવિક કારણ એક સ્ટેટસ લેબલ હતું: મોડેલ મોટો શેલ કમાન્ડ થોડા-થોડા અક્ષરોમાં સ્ટ્રીમ કરતું, ત્યારે અમે દરેક ટુકડા પર અત્યાર સુધીનો સંપૂર્ણ કમાન્ડ પ્રોગ્રેસ લેબલ તરીકે ફરી મોકલતા હતા. એક 124 KB કમાન્ડ લગભગ 41,000 ઇવેન્ટ્સ અને આશરે 690 MB કતારબદ્ધ સ્ટ્રિંગ્સ બની ગયો.

એજન્ટ તેનું કામ કેવી રીતે સ્ટ્રીમ કરે છે

જ્યારે તમે Mythex પર બનાવો છો, ત્યારે એજન્ટ તમારા પ્રોજેક્ટના ખાનગી ક્લાઉડ સેન્ડબોક્સમાં ચાલે છે. મોડેલ લખે છે ત્યારે તેનું આઉટપુટ તમારા બ્રાઉઝર સુધી સ્ટ્રીમ થાય છે: ટેક્સ્ટ શબ્દ-શબ્દ દેખાય છે, અને જ્યારે તે ટૂલ ચલાવે — જેમ કે ફાઇલ લખતો શેલ કમાન્ડ — ત્યારે તમે તેનું લેબલ લાઇવ અપડેટ થતું જુઓ, જેથી ખબર પડે કે તે શું કરી રહ્યું છે.

મોડેલ નાના ટુકડામાં સ્ટ્રીમ કરે છે. અમે જે મોડેલ ચલાવતા હતા તેમાં તે ટુકડા ઘણીવાર માત્ર ત્રણ અક્ષર લાંબા હતા.

પહેલી ધારણાઓ ખોટી હતી

ક્રેશ સ્કેલિંગની સમસ્યા જેવું લાગ્યું, તેથી અમે ત્યાંથી શરૂઆત કરી.

• સમાંતર સબ-એજન્ટ્સ? ટર્નમાં ફક્ત બે વપરાયા હતા, દરેક લગભગ 1.5 MB સ્ટેટ સાથે. પૂરતું નહોતું.
• જાળવી રાખેલા ટ્રેસ? અમારું ટ્રેસિંગ રન ટ્રી મેમરીમાં રાખતું, પરંતુ ક્રેશ વખતના હીપના કદની નજીક પણ નહોતું.

બંને સંભવિત વાર્તાઓ હતી, અને બંનેમાં માનવું સસ્તું હતું. કોઈ પણ ક્રેશને પુનઃ ઉત્પન્ન કરતું નહોતું. જે પાઠ અમે વારંવાર ફરી શીખીએ છીએ: જ્યાં સુધી તે નિષ્ફળતાને પુનઃ ઉત્પન્ન ન કરે, ત્યાં સુધી ધારણા કારણ નથી.

ખરેખર પુનઃ ઉત્પન્ન કરવું

અમે ઉત્પાદન જેવી જ મેમરી મર્યાદાઓ સાથે એક નિકાલજોગ સેન્ડબોક્સ બનાવ્યું, અને એક નકલી મોડેલ જે મોટી ફાઇલને વાસ્તવિક ત્રણ-અક્ષરના ટુકડામાં સ્ટ્રીમ કરતું. અમે બીજા છેડાના રીડરને પણ ધીમો બનાવ્યો, વાસ્તવિક નેટવર્કની જેમ.

તેનાથી કામ થયું. હીપ વધ્યું અને પ્રક્રિયા એ જ એરર સાથે મરી ગઈ.

જોયા પછી મિકેનિઝમ સરળ હતું. જ્યારે મોડેલ મોટો કમાન્ડ લખી રહ્યું હતું — આ કિસ્સામાં 124 KB ફાઇલ લખતું heredoc — ત્યારે અમારો સ્ટ્રીમિંગ કોડ દરેક ટુકડા પર ટૂલનું લેબલ અપડેટ કરતો. લેબલ નવા ત્રણ અક્ષર નહોતા; તે અત્યાર સુધીનો સંપૂર્ણ કમાન્ડ હતો. તેથી ઇવેન્ટ્સ વધતી: 3 અક્ષર, પછી 6, પછી 9, … 124 KB સુધી, લગભગ 41,000 વખત. સોકેટ જેટલી ઝડપથી મોકલી શકતું તેના કરતાં ઝડપથી તે બની રહી હતી, તેથી તે સ્ટ્રિંગ્સ તરીકે તેના રાઇટ બફરમાં જમા થતી — લગભગ 690 MB.

ફિક્સ

• લેબલ મર્યાદિત કર્યું. સ્ટેટસ લેબલે માત્ર એટલું કહેવાનું છે કે શું થઈ રહ્યું છે. હવે તે 200 અક્ષર સુધી મર્યાદિત છે, અને આંશિક કમાન્ડને ફરી સ્કેન કરવાની આવૃત્તિ અમે થ્રોટલ કરી છે.
• ચતુર્ભુજ કોન્કેટેનેશન બંધ કર્યું. સ્ટ્રીમ થયેલા ટુકડાઓને વારંવાર સ્ટ્રિંગ કોન્કેટેનેશન વડે જોડવું મોટા આઉટપુટ માટે O(n²) છે. અમે ચંક-આધારિત અભિગમ તરફ ગયા, જે રેખીય સમયમાં ઉમેરે છે.

પછી અમે તપાસ્યું કે આઉટપુટના પૂરથી બીજું શું અમર્યાદિત વધી શકે છે, અને દરેકને મર્યાદિત કર્યું:

• ચેટમાં બતાવાતું લાઇવ કમાન્ડ આઉટપુટ બેચ થાય છે અને છેલ્લા 8,000 અક્ષર સુધી રખાય છે.
• વ્યક્તિગત ઇવેન્ટ લાઇન્સ 4 MB સુધી મર્યાદિત છે.
• જ્યારે બ્રાઉઝર ફરી જોડાયા પછી પકડવા માટે રિપ્લે બફર વાપરે, તે પ્રોજેક્ટ દીઠ 8 MB સુધી મર્યાદિત છે.
• જૂના ચેકપોઇન્ટ ટર્ન ચાલતાં જ કાપી નાખવામાં આવે છે, નવીનતમ સ્ટેટ અને અગાઉના ટર્ન્સને જરૂરી એન્કર જાળવીને.

પૂરને પ્રામાણિકપણે પરીક્ષણ કરવું

આ પરીક્ષણ કરવું જરૂર કરતાં મુશ્કેલ બનાવતી બે બાબતો:

1. વાસ્તવિક મોડેલો સહકાર આપતા નથી. વિશાળ ફાઇલ છાપવાનું કહો તો તે મોટેભાગે ઇનકાર કરશે, સારાંશ આપશે, અથવા વધુ સમજદારીથી લખશે. પૂરનું પરીક્ષણ કરવા માટે તમારે એવું સ્ક્રિપ્ટેડ મોડેલ જોઈએ જે તમે કહો તે બરાબર કરે, વાસ્તવિક એજન્ટ કોડ મારફતે ચાલતું.
2. સ્ક્રિપ્ટ્સે મોડેલ જેવું વર્તવું જોઈએ. અમારા પહેલા સ્ક્રિપ્ટેડ મોડેલે દરેક જવાબ પર એક જ રિસ્પોન્સ ID ફરી વાપર્યો, તેથી એજન્ટ ફ્રેમવર્ક દરેક જવાબને પાછલાનો બદલો માનતું અને ટર્ન વહેલા સમાપ્ત કરતું. તે UI રિફ્રેશ બગ જેવું લાગ્યું. તે હતું નહીં — તે ટેસ્ટ હાર્નેસ અમને ખોટું કહી રહ્યું હતું. અમારે સ્ક્રિપ્ટમાં મોડેલની વાસ્તવિક સંદર્ભ મર્યાદા પણ લાગુ કરવી પડી, નહીંતર મેમરીના આંકડા અવાસ્તવિક હતા.

અમે જે શીખ્યા

• સ્ટ્રીમિંગ UI નાની ભૂલોને ગુણે છે. “દરેક ચંક દીઠ” મોકલાતી કોઈ પણ વસ્તુ દસ હજારો વખત મોકલાય છે. ડેલ્ટા મોકલો, અથવા પેલોડ મર્યાદિત કરો.
• ધીમી સીમા પાર કરતા દરેક બફરને મર્યાદા આપો. સોકેટ્સ, રિપ્લે લોગ્સ અને ચેકપોઇન્ટ્સ બધાને ઉપરની મર્યાદા જોઈએ.
• ફિક્સ પહેલાં પુનઃ ઉત્પન્ન કરો. અમારી પહેલી બે સમજૂતીઓ સાચી લાગતી હતી અને ખોટી હતી.

જો તમે તાજેતરમાં Mythex ચેટમાં કોઈ ખૂબ લાંબી ફાઇલ એજન્ટને અટક્યા વિના દેખાતી જોઈ હોય, તો આ તેનું એક કારણ છે.