একটি প্রগ্রেস লেবেলে লুকানো মেমোরি-ক্র্যাশ

সেপ্টেম্বরের শেষের এক সন্ধ্যায় একজন ব্যবহারকারীর ওয়ার্কস্পেসে AI এজেন্ট একটি টার্নের মাঝখানে out-of-memory ত্রুটিতে ক্র্যাশ করল। স্পষ্ট সন্দেহভাজনরা — একসঙ্গে অনেক সাব-এজেন্ট চলা, অথবা অনেক বড় হয়ে যাওয়া প্রসঙ্গ — দুটিই ভুল ছিল। আসল কারণ একটি স্ট্যাটাস লেবেল: মডেল একটি বড় শেল কমান্ড কয়েক অক্ষর করে স্ট্রিম করার সময় আমরা প্রতিটি অংশে এখন পর্যন্তের পুরো কমান্ড একটি প্রগ্রেস লেবেল হিসেবে আবার পাঠাচ্ছিলাম। একটি ১২৪ KB কমান্ড প্রায় ৪১,০০০ ইভেন্ট এবং প্রায় ৬৯০ MB কিউড স্ট্রিং হয়ে গিয়েছিল।

এজেন্ট কীভাবে কাজ স্ট্রিম করে

Mythex-এ বানানোর সময় এজেন্ট আপনার প্রজেক্টের ব্যক্তিগত ক্লাউড স্যান্ডবক্সের ভেতরে চলে। মডেল লেখার সময় তার আউটপুট আপনার ব্রাউজারে স্ট্রিম হয়: টেক্সট শব্দ ধরে ধরে আসে, আর যখন কোনো টুল চলে — যেমন একটি ফাইল লেখে এমন শেল কমান্ড — আপনি তার লেবেল লাইভ আপডেট হতে দেখেন, যাতে জানেন সে কী করছে।

মডেল ছোট ছোট অংশে স্ট্রিম করে। আমরা যে মডেল চালাচ্ছিলাম, তার অংশগুলো প্রায়ই মাত্র তিন অক্ষর লম্বা হতো।

প্রথম অনুমানগুলো ভুল ছিল

ক্র্যাশটি স্কেলিংয়ের সমস্যার মতো দেখাচ্ছিল, তাই আমরা সেখান থেকেই শুরু করেছিলাম।

• সমান্তরাল সাব-এজেন্ট? টার্নটি মাত্র দুটি ব্যবহার করেছিল, প্রত্যেকে প্রায় ১.৫ MB অবস্থা ধরে রেখেছিল। যথেষ্ট নয়।
• ধরে রাখা ট্রেস? আমাদের ট্রেসিং মেমোরিতে একটি রান ট্রি রাখত, কিন্তু ক্র্যাশের সময়কার হিপের আকারের কাছাকাছিও ছিল না।

দুটিই বিশ্বাসযোগ্য গল্প ছিল, আর দুটিই বিশ্বাস করা সহজ ছিল। কোনোটিই ক্র্যাশ পুনরুৎপাদন করেনি। আমরা বারবার নতুন করে শিখি: যতক্ষণ ব্যর্থতা পুনরুৎপাদন না হয়, ততক্ষণ সেটি কারণ নয়, শুধু একটি অনুমান।

সত্যিই পুনরুৎপাদন করা

আমরা উৎপাদনের সমান মেমোরি সীমাসহ একটি ডিসপোজেবল স্যান্ডবক্স বানালাম, এবং একটি নকল মডেল যা বাস্তবসম্মত তিন-অক্ষরের অংশে একটি বড় ফাইল স্ট্রিম করত। সকেটের অন্য প্রান্তের রিডারও একটি বাস্তব নেটওয়ার্কের মতো ধীর করেছিলাম।

এতেই কাজ হলো। হিপ বাড়ল, আর প্রক্রিয়াটি একই ত্রুটিতে মারা গেল।

দেখা যাওয়ার পর কৌশলটি সহজ ছিল। মডেল একটি বড় কমান্ড লিখছিল — এই ক্ষেত্রে একটি heredoc যা ১২৪ KB ফাইল লিখছিল — আর আমাদের স্ট্রিমিং কোড প্রতিটি অংশে টুলের লেবেল আপডেট করছিল। লেবেলটি নতুন তিন অক্ষর ছিল না; এটি ছিল এখন পর্যন্তের পুরো কমান্ড। ফলে ইভেন্টগুলো বাড়ছিল: ৩ অক্ষর, তারপর ৬, তারপর ৯, … ১২৪ KB পর্যন্ত, প্রায় ৪১,০০০ বার। সকেট যত দ্রুত উৎপাদিত হচ্ছিল তত দ্রুত পাঠাতে পারছিল না, তাই সেগুলো স্ট্রিং হিসেবে তার রাইট বাফারে জমছিল — প্রায় ৬৯০ MB।

সমাধান

• লেবেল সীমিত করুন। একটি স্ট্যাটাস লেবেলের শুধু বলা দরকার কী ঘটছে। এখন এটি ২০০ অক্ষরে সীমিত, আর আংশিক কমান্ড পুনরায় স্ক্যান করার হার আমরা থ্রটল করি।
• দ্বিঘাত সংযুক্তি বন্ধ করুন। স্ট্রিম করা অংশগুলো বারবার স্ট্রিং কনক্যাটেনেশনে জুড়লে বড় আউটপুটে O(n²) হয়। আমরা চাঙ্ক-ভিত্তিক পদ্ধতিতে সরেছি, যা রৈখিক সময়ে যুক্ত করে।

এরপর আমরা খুঁজলাম অজস্র আউটপুটের ঢেউয়ে আর কী সীমাহীনভাবে বাড়তে পারে, এবং সেগুলোও সীমিত করলাম:

• চ্যাটে দেখানো লাইভ কমান্ড আউটপুট ব্যাচ করা হয় এবং শেষ ৮,০০০ অক্ষরে রাখা হয়।
• প্রতিটি ইভেন্ট লাইন ৪ MB-তে সীমিত।
• রিকানেক্টের পর ব্রাউজার যে রিপ্লে বাফার দিয়ে ধরে ফেলে, তা প্রতি প্রজেক্টে ৮ MB-তে সীমিত।
• একটি টার্ন চলার সঙ্গে পুরনো চেকপয়েন্ট ছাঁটা হয়, সর্বশেষ অবস্থা ও আগের টার্নের প্রয়োজনীয় অ্যাঙ্কর রেখে।

আউটপুটের ঢেউ সততার সঙ্গে পরীক্ষা করা

এই দুটি বিষয় এটিকে প্রয়োজনের চেয়ে কঠিন পরীক্ষার কাজ করেছিল:

1. বাস্তব মডেল সহযোগিতা করে না। একটি বিশাল ফাইল প্রিন্ট করতে বললে মডেল সাধারণত প্রত্যাখ্যান করে, সংক্ষেপ করে, অথবা আরও বিবেচনা করে লেখে। ঢেউ পরীক্ষা করতে একটি স্ক্রিপ্টেড মডেল দরকার যা আপনি যা বলেন ঠিক তাই করে, এবং প্রকৃত এজেন্ট কোডের ভেতর দিয়ে চলে।
2. স্ক্রিপ্টকে মডেলের মতো আচরণ করতে হয়। আমাদের প্রথম স্ক্রিপ্টেড মডেল প্রতিটি উত্তরে একই রেসপন্স আইডি ব্যবহার করত, ফলে এজেন্ট ফ্রেমওয়ার্ক প্রতিটি উত্তরকে আগেরটির প্রতিস্থাপন ধরে টার্ন আগেভাগে শেষ করছিল। দেখে মনে হয়েছিল এটি UI রিফ্রেশের বাগ। আসলে এটি ছিল পরীক্ষার হার্নেসের মিথ্যা। মেমোরির সংখ্যা বাস্তবসম্মত রাখতে স্ক্রিপ্টে মডেলের প্রকৃত প্রসঙ্গসীমাও বলবৎ করতে হয়েছিল।

আমরা যা শিখেছি

• স্ট্রিমিং UI ছোট ভুল বাড়িয়ে দেয়। "প্রতি অংশে" যা পাঠানো হয় তা দশ হাজারবার পাঠানো হয়। ডেল্টা পাঠান, অথবা পেলোড সীমিত করুন।
• প্রতিটি বাফার সীমিত করুন যা ধীর সীমানা পার হয়। সকেট, রিপ্লে লগ ও চেকপয়েন্ট সবগুলোর একটি সীমা দরকার।
• ঠিক করার আগে পুনরুৎপাদন করুন। আমাদের প্রথম দুটি ব্যাখ্যা শুনতে ঠিক লাগছিল, কিন্তু ভুল ছিল।

Mythex চ্যাটে সম্প্রতি খুব লম্বা ফাইল স্টল ছাড়াই উপস্থিত হতে দেখে থাকলে, এটি তার একটি কারণ।