ప్రోగ్రెస్ లేబుల్‌లో దాగి ఉన్న Out-of-Memory క్రాష్

సెప్టెంబర్ చివరలో ఒక సాయంత్రం, ఒక వినియోగదారు వర్క్‌స్పేస్‌లోని AI ఏజెంట్ టర్న్ మధ్యలో out-of-memory ఎర్రర్‌తో క్రాష్ అయింది. స్పష్టమైన అనుమానితులు — ఒకేసారి ఎక్కువ సబ్-ఏజెంట్లు రన్ అవ్వడం, లేదా సందర్భం చాలా పెద్దది కావడం — రెండూ తప్పు. నిజమైన కారణం ఒక స్టేటస్ లేబుల్: మోడల్ ఒక పెద్ద షెల్ కమాండ్‌ను కొన్ని అక్షరాల చొప్పున స్ట్రీమ్ చేస్తున్నప్పుడు, మేము ప్రతి ముక్కకు ఇప్పటివరకు ఉన్న మొత్తం కమాండ్ను ప్రోగ్రెస్ లేబుల్‌గా మళ్లీ పంపాము. 124 KB కమాండ్ సుమారు 41,000 ఈవెంట్లుగా, దాదాపు 690 MB క్యూ చేయబడిన స్ట్రింగ్‌లుగా మారింది.

ఏజెంట్ తన పనిని ఎలా స్ట్రీమ్ చేస్తుంది

మీరు Mythex పై నిర్మించినప్పుడు, ఏజెంట్ మీ ప్రాజెక్ట్ యొక్క ప్రైవేట్ క్లౌడ్ sandbox లోపల రన్ అవుతుంది. మోడల్ రాస్తున్నప్పుడు, దాని అవుట్‌పుట్ మీ బ్రౌజర్‌కు తిరిగి స్ట్రీమ్ అవుతుంది: టెక్స్ట్ పదం పదం కనిపిస్తుంది, మరియు అది టూల్ రన్ చేసినప్పుడు — ఉదాహరణకు ఫైల్ రాసే షెల్ కమాండ్ — దాని లేబుల్ ప్రత్యక్షంగా అప్‌డేట్ అవుతుంది, అది ఏమి చేస్తోందో మీకు తెలుస్తుంది.

మోడల్ చిన్న ముక్కలుగా స్ట్రీమ్ చేస్తుంది. మేము ఉపయోగిస్తున్న మోడల్‌తో, ఆ ముక్కలు తరచుగా కేవలం మూడు అక్షరాలు మాత్రమే.

మొదటి అనుమానాలు తప్పు

క్రాష్ స్కేలింగ్ సమస్యలా కనిపించింది, కాబట్టి అక్కడ నుంచి మొదలుపెట్టాము.

• సమాంతర సబ్-ఏజెంట్లా? టర్న్ రెండు మాత్రమే ఉపయోగించింది, ప్రతిదీ సుమారు 1.5 MB స్థితి పట్టుకుంది. సరిపోదు.
• ఉంచిన ట్రేస్‌లా? మా ట్రేసింగ్ ఒక రన్ ట్రీని మెమరీలో ఉంచింది, కానీ క్రాష్ సమయంలోని హీప్‌కు అది దగ్గరగా లేదు.

రెండు కథలూ నమ్మదగినవే, రెండింటినీ నమ్మడం చౌకే. రెండూ క్రాష్‌ను పునరుత్పత్తి చేయలేదు. మేము మళ్లీ మళ్లీ నేర్చుకునే పాఠం: వైఫల్యాన్ని పునరుత్పత్తి చేయనంత వరకు ఒక ఊహ కారణం కాదు.

నిజంగా పునరుత్పత్తి చేయడం

ఉత్పత్తికి ఉన్న మెమరీ పరిమితులతో ఒక తాత్కాలిక sandbox నిర్మించాము, మరియు వాస్తవిక మూడు-అక్షరాల ముక్కలలో పెద్ద ఫైల్‌ను స్ట్రీమ్ చేసే నకిలీ మోడల్‌ను ఉపయోగించాము. సాకెట్ యొక్క మరొక చివర ఉన్న రీడర్‌ను కూడా నిజమైన నెట్‌వర్క్ లాగా నెమ్మదిగా చేశాము.

అదే పని చేసింది. హీప్ పెరిగింది, ప్రాసెస్ అదే ఎర్రర్‌తో చనిపోయింది.

విధానం చూడగలిగిన తర్వాత సరళమైనది. మోడల్ ఒక పెద్ద కమాండ్ రాస్తున్నప్పుడు — ఈ సందర్భంలో 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 చాట్‌లో ఏజెంట్ నిలిచిపోకుండా చాలా పెద్ద ఫైల్ కనిపించడం చూసినట్లయితే, ఇది అందులో ఒక భాగం.