تصور کنید یک خط لوله (Pipeline) پردازش اسناد ۴۸ ساعته را روی سرور اجرا کردهاید و ساعت ۳:۱۲ صبح، یک ریاستارت ناگهانی تمام نتایج ۶ ساعت گذشته را پاک میکند. اگر هنوز تمام پیشرفتهای خود را فقط در حافظه موقت (RAM) نگه میدارید، در واقع دارید روی یخ خانه میسازید. این شکست به این دلیل رخ داد که اسکریپت با یک سرور رایگان و موقت (Ephemeral) به عنوان یک محیط دائمی برخورد کرده بود و تمام پیشرفتها را در حافظه ذخیره میکرد.
این اتفاق دقیقاً برای توسعهدهندهای رخ داد که از سرویس MonkeyCode استفاده میکرد. او برای خلاصهسازی ۲۰۰۰ سند، از یک سرور رایگان و دسترسی به مدلها بهره میبرد که طبق اعلام نویسنده، ۱۰ میلیون توکن رایگان در اختیار کاربران قرار میدهد. این محیط، فضایی ایدهآل بود تا بتوان بدون هزینه زیاد، سیستم را به چالش کشید و نقاط ضعف آن را پیدا کرد. لازم به ذکر است که این مقاله به عنوان بخشی از فعالیتهای ترویجی محصول MonkeyCode تهیه شده است.
حلقه سادهلوحانه (The Naive Loop)
اسکریپت اولیه یک پیادهسازی معمولی از نوع «ساعت ۱۱ شب» بود؛ یعنی کدی که سریع نوشته شده تا فقط کار کند. منطق برنامه به این صورت بود: ابتدا لیستی از ۲۰۰۰ سند بارگذاری میشد، سپس مدل API در یک حلقه فراخوانی میشد، نتایج در یک لیست جمعآوری میگشت و در نهایت، تنها پس از اتمام تمام موارد، تلاش میشد تا همه چیز یکباره روی دیسک ذخیره شود. مسیر منطقی کد به این شکل بود: load_all_documents() $\rightarrow$ requests.post() $\rightarrow$ results.append() $\rightarrow$ save_all().
از آنجایی که تابع save_all() آخرین مرحله بود، هرگونه وقفه پیش از پایان حلقه به این معنا بود که هیچ دادهای باقی نمیماند. یک سرور رایگان در واقع یک ماشین امانتی است و هر لحظه ممکن است ناپدید شود. در این مورد خاص، ریاستارت سرور حوالی ساعت ۳ صبح رخ داد، در حالی که تقریباً ۹۰۰ سند از ۲۰۰۰ سند پردازش شده بود. بدون داشتن یک نقطه بازرسی (Checkpoint)، اجرای مجدد برنامه مستلزم ارسال دوباره تمام ۹۰۰ پرامپت بود؛ یعنی در عمل، هزینه همان کار یک بار دیگر پرداخت میشد.
درسهایی در مورد پایداری (Durability)
این شکست سه درس مشخص در مورد مدیریت منابع به ما میدهد:
- ماهیت موقت: یک سرور رایگان، تضمینی برای پایداری نیست. وقتی ماشین میتواند هر لحظه بازیافت (Recycle) شود، عبارت «دیروز درست کار میکرد» یک معیار بیارزش است.
- بودجهبندی توکن: توکنها یک بودجه هستند، نه یک منبع نامحدود. هر سند پردازششدهی مجدد، دو برابر هزینه دارد: یک بار برای کار اولیه و یک بار برای تکرار.
- هزینه فراخوانیهای API: ارزانترین فراخوانی API، فراخوانیای است که هرگز انجام نشود. نادیده گرفتن یک آیتم تکمیلشده تنها چند میلیثانیه زمان میبرد و صفر توکن هزینه دارد.
برای حل این مشکل، توسعهدهنده یک الگوی نقطه بازرسی (Checkpointing) را با استفاده از فایل JSONL پیادهسازی کرد. این رویکرد هر سند تکمیلشده را بلافاصله پس از دریافت پاسخ API ثبت میکند. این کار تضمین میکند که یک ریاستارت تنها چند ثانیه برای اسکن فایل زمان میبرد، نه چندین ساعت برای پردازش مجدد.
پیادهسازی فنی
این سیستم بازرسی مستحکم برای تضمین یکپارچگی دادهها بر سه مکانیزم خاص تکیه دارد:
- هشینگ ورودی (Input Hashing): به جای استفاده از ایندکسهای لیست، سیستم از یک هش SHA-256 از متن ورودی (که به ۱۶ کاراکتر کوتاه شده است) استفاده میکند. این کار تضمین میکند که اگر لیست اسناد بین دو اجرای برنامه تغییر ترتیب دهد یا اصلاح شود، اسکریپت همچنان بر اساس خودِ محتوا تشخیص دهد که کدام کار قبلاً انجام شده است.
- ذخیره پاسخ خام (Raw Payload Storage): اسکریپت کل پاسخ JSON خام مدل، از جمله فیلد
usageرا ذخیره میکند. این قابلیت به توسعهدهنده اجازه میدهد تا اگر تجزیه (Parsing) اولیه دادهها شکست خورد (که در طول اجرا دو بار اتفاق افتاد)، بدون صرف توکن برای یک فراخوانی جدید API، دادهها را دوباره تجزیه کند. - نوشتن اتمیک (Atomic Flushing): برای جلوگیری از خراب شدن فایل در هنگام کرش، سیستم از نوشتن دستهجمعی مستقیم در فایل اصلی اجتناب میکند. در عوض، بهروزرسانیها را در یک فایل موقت (
CHECKPOINT + '.tmp') مینویسد و سپس ازos.replaceبرای جایگزینی اتمیک فایل بازرسی اصلی در سیستمهای POSIX استفاده میکند.
بر اساس گزارش، این معماری اجازه داد تا در اجرای مجدد، ۹۰۰ سند تکمیلشده در حدود چهار ثانیه نادیده گرفته شوند. سپس ۱۱۰۰ سند باقیمانده در طول شب بدون هیچ تلفات دادهای پردازش شدند.
محدودیتها و تنگناها
با وجود این بهبود، نویسنده به یک محدودیت حیاتی اشاره میکند: فایل بازرسی روی همان دیسک موقت سرور قرار دارد. اگر سرور به جای ریاستارت ساده، به طور کامل بازیافت شود، فایل بازرسی نیز از بین میرود. برای کاهش این ریسک در بازه ۴۸ ساعته، نویسنده هر ۱۰۰ مورد، فایل را در یک مکان راه دور (Remote) کپی میکرد. برای کارهای با ریسک بالا، توصیه میشود که وضعیت (State) را از همان خط اول کد در یک Object Storage یا پایگاهداده راه دور ذخیره کنید.
محدودیتهای دیگری نیز در این فرآیند ظاهر شدند:
- محدودیت نرخ (Rate Limits): موازیسازی حلقه باعث فعال شدن محدودیتهای نرخ شد. این موضوع نیاز به پیادهسازی یک سمافور (Semaphore) ساده و منطقی برای رعایت هدرهای
Retry-Afterداشت. - منابع مشترک: این تجربه یادآور این بود که سطح رایگان (Free Tier) یک منبع مشترک است، نه یک کلاستر خصوصی.
این تغییر در طراحی، بازتابدهنده یک ضرورت گستردهتر در توسعه مدرن هوش مصنوعی است. چه از Spot Instanceها استفاده کنید، چه از توابع Serverless یا CI Runnerها، محاسبات به طور فزایندهای ارزان و موقت شدهاند. هدف دیگر ساخت فرآیندی نیست که هرگز کرش نکند، بلکه ساخت فرآیندی است که «قابلیت بقا» داشته باشد. نقطه بازرسی، سرور رایگان را قابل اعتماد نمیکند، بلکه کار شما را نجاتپذیر میکند.
چه زمانی از این الگو استفاده کنیم؟
این الگو همیشه ضروری نیست و در سناریوهای زیر بیشتر یک هزینه اضافی (Overhead) است تا یک بیمه:
- اگر کار در عرض پنج دقیقه تمام میشود.
- اگر حجم کاری دارای یک قرارداد SLA است (که در این صورت سرور رایگان اساس درستی برای کار نیست).
- اگر وضعیت (State) بسیار کوچک و زمان اجرا کوتاه است.
نقطه بازرسی تنها زمانی ارزش خود را ثابت میکند که هزینه انجام مجدد کار واقعی باشد. برای اکثر توسعهدهندگانی که خط لولههای طولانی LLM را اجرا میکنند، بازرسی مدیریت وضعیت ضروری است. استواری اسکریپت خود را با شبیهسازی یک کرش در میانه پردازش تست کنید تا ببینید آیا منطق فعلی شما میتواند بدون صرف حتی یک توکن اضافی بازیابی شود یا خیر. اگر میخواهید خط لوله خود را تست کنید، MonkeyCode متنباز است؛ آن را به بدترین اسکریپت خود متصل کنید و تا ساعت ۳ صبح منتظر بمانید. فقط اول نقطه بازرسی را بنویسید.
گام بعدی شما
- اسکریپتهای طولانی خود را بررسی کنید و هر جا که خروجی در حافظه موقت ذخیره میشود، آن را به مدل JSONL تغییر دهید.
- برای تست استواری کد، در میانه پردازش را به صورت دستی متوقف کنید و ببینید آیا سیستم بدون مصرف توکن اضافی، از همان نقطه ادامه میدهد یا خیر.
- اگر از سرورهای Spot یا Serverless استفاده میکنید، حتماً وضعیت را در یک دیتابیس خارجی ذخیره کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو