اگر برای استقرار عامل‌های هوش مصنوعی بین هزینه و سرعت مردد هستید، خبر خوب این است که دیگر مجبور نیستید برای حذف تأخیر، هزینهٔ پردازش‌های بیکار را بپرداختید. طبق اعلام آمازون وب سرویسز (AWS)، رانتایم بازطراحی‌شدهٔ AgentCore در ۱۸ سپتامبر ۲۰۲۶ عرضه شد تا مشکلاتی نظیر جهش‌های تأخیر (Latency Spikes) و مسائل مربوط به صورت‌حساب‌های «نقطه اوج» (High-water mark billing) را حل کند.
اکنون یک تصویرِ عامل (Agent Image) با حجمی بین ۲۰۰ مگابایت تا ۲ گیگابایت، در حدود ۲ ثانیه بوت می‌شود؛ عددی که در مقایسه با رکورد ۳۰ ثانیه‌ای نسخه پیشین، یک جهش خیره‌کننده است.
برای اکثر کسب‌وکارها، استقرار عامل‌های هوش مصنوعی شبیه به یک معاملهٔ سخت بود: یا باید برای جلوگیری از لگ (Lag)، هزینهٔ منابع «گرم» و فعال را می‌پرداختند یا تأخیرهای طولانیِ شروع به کار را تحمل می‌کردند که باعث نارضایتی کاربران می‌شد. این همان چالش کلاسیک رایانش بدون سرور (Serverless) است؛ یعنی مقیاس‌پذیری تا صفر برای کیف پول عالی است، اما برای تجربهٔ اولین درخواست کاربر، فاجعه‌بار است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، مدیریت بهینهٔ منابع در مقاس تولید، مرز بین سوددهی و شکست یک محصول است.
زمینه: لایه محاسباتی مدیریت‌شده
AgentCore در واقع لایهٔ محاسباتی مدیریت‌شده در Amazon Bedrock است. این سرویس به توسعه‌دهندگان محیطی کاملاً مدیریت‌شده فراهم می‌کند تا عامل‌های خود را بدون تحمل بار ساخت یا نگهداری زیرساخت‌های زیرین مستقر و اجرا کنند.
از زمان عرضه اولیه، هزاران تیم از این پلتفرم برای اجرای عامل‌های عملیاتی (Production) استفاده کرده‌اند. نسخه اول یک بنیاد بدون سرور را ایجاد کرد که ویژگی‌های اصلی آن ایزولاسیون جلسات (Session Isolation)، رفتار مقیاس‌پذیری تا صفر و قیمت‌گذاری بر اساس مصرف بود. این مدل مصرف در نسخه جدید نیز حفظ شده است: صورت‌حساب بر اساس استفاده از منابع است و هیچ هزینه‌ای برای CPUهای بیکاری که منتظر ورودی/خروجی (I/O) هستند، دریافت نمی‌شود.
حل مشکل نشت حافظه
در رانتایم اصلی V1، هر جلسه (Session) تمام بایت‌های حافظه‌ای را که یک بار لمس کرده بود، تا پایان جلسه نگه می‌داشت. چون هیچ مکانیزمی برای بازپس‌گیری حافظه در طول مسیر وجود نداشت، جلسه حافظه تخصیص‌یافته خود را از لحظه تخصیص تا لحظه پایان نگه می‌داشت.
به گزارش AWS، اگر یک عامل برای یک تسک پیچیده به طور لحظه‌ای به ۲ گیگابایت رم نیاز داشت و سپس بیکار می‌شد، کاربر باید هزینهٔ آن ۲ گیگابایت را برای کل مدت زمان جلسه می‌پرداخت. این موضوع یک شکاف هزینهٔ قابل توجه برای عامل‌هایی ایجاد می‌کرد که گهگاه دچار جهش مصرف می‌شدند اما در بیشتر ساعات روز بیکار بودند.
نسخه AgentCore V2 این رویکرد را تغییر داده است. اکنون جلسات با یک پروفایل حافظه کوچک شروع می‌شوند و تنها در صورتی که حجم کاری (Workload) تقاضا کند، حافظه اضافی را وارد (Page-in) می‌کنند. مهم‌تر از آن، پلتفرم اکنون حافظه را در زمان آزاد شدن بافرها یا انقضای کش‌ها بازپس می‌گیرد، به جای اینکه منتظر پایان جلسه بماند. AWS این رفتار بازپس‌گیری را بر اساس تحلیل الگوهای تخصیص در میلیاردها جلسه بهینه کرده است.
مکانیزم اسنپ‌شات (Snapshotting)
تأخیر در راه‌اندازی سرد (Cold Start) پیش از این با افزایش اندازه تصاویر کانتینر، بیشتر می‌شد. در سیستم قدیمی، اکثر جلسات با یک شروع سرد آغاز می‌شدند که باید محیطی تازه را بوت می‌کرد، تصویر را می‌کشید و عامل را پیش از اجرای اولین درخواست مقداردهی اولیه می‌کرد.
برای حل این مشکل، AWS اکنون از یک فرآیند اسنپ‌شات استفاده می‌کند:
- هنگامی که یک رانتایم ایجاد یا به‌روزرسانی می‌شود، AgentCore کانتینر را اجرا کرده و منتظر می‌ماند تا وضعیت سلامت آن از طریق نقطه انتهایی
/pingتأیید شود. - سیستم سپس یک اسنپ‌شات از محیط در حال اجرا، شامل آرتیفکت‌های مدل بارگذاری‌شده و تنظیمات استاتیک، می‌گیرد.
- هر جلسه جدید به‌جای مقداردهی اولیه از صفر، این اسنپ‌شات را بازیابی (Restore) می‌کند.
آمازون برای ثابت نگه داشتن زمان بازیابی، حافظه‌های موقت و کش‌ها را از این اسنپ‌شات‌ها حذف کرده است. این کار تضمین می‌کند که اندازه اسنپ‌شات حتی با رشد حجم تصویر کانتینر، تقریباً ثابت بماند.
اندازه‌گیری عملکرد
برای جداسازی سربار پلتفرم، AWS یک «عامل اکو» (Echo Agent) را تست کرد که ورودی را بدون فراخوانی مدل‌ها یا ابزارها، بازمی‌گرداند. در این تست از یک کلاینت پایتون روی یک نمونه Amazon EC2 در منطقه us-west-2 برای فراخوانی عامل‌ها در us-east-1 از طریق اینترنت عمومی و با استفاده از SDK boto3 استفاده شد. این اندازه‌گیری شامل رفت و برگشت بین دو منطقه AWS بود.
در ۵۰۰۰ فراخوانی سرد برای هر عامل و در پنج اندازه مختلف تصویر، نتایج بسیار واضح بود:
- رانتایم V2: تأخیر P75 شروع سرد حدود ۲ ثانیه برای تصاویری از ۲۰۰ مگابایت تا ۲ گیگابایت ارائه داد.
- رانتایم V1: تأخیر با افزایش اندازه تصویر بالا رفت و از حدود ۵.۴ ثانیه به نزدیکی ۳۰ ثانیه رسید.
در این تست اکو، کد خودِ عامل در حدود ۳۴ میلی‌ثانیه در P75 اجرا شد، به این معنی که تقریباً تمام زمان اندازه‌گیری شده، مربوط به زمان شروع پلتفرم بود.
استقرار و محدودیت‌ها
توسعه‌دهندگان می‌توانند با تنظیم فیلد platformVersion روی V2 هنگام ایجاد یا به‌روزرسانی رانتایم (مطابق راهنمای توسعه‌دهنده AgentCore)، این قابلیت را فعال کنند. نسخه V1 همچنان پیش‌فرض است؛ حذف این فیلد هنگام ایجاد، منجر به تولید V1 می‌شود و حذف آن هنگام به‌روزرسانی، نسخه فعلی را حفظ می‌کند.
نسخه V2 در حال حاضر در مناطق us-east-1، us-east-2، us-west-2، eu-west-1 و ap-northeast-1 در دسترس است. با این حال، چند تبادل (Trade-off) وجود دارد که باید در نظر گرفت:
- زمان آماده‌سازی (Ready Time): رانتایم‌های V2 به دلیل فرآیند اسنپ‌شات، چندین دقیقه طول می‌کشد تا به وضعیت READY برسند، در حالی که V1 در عرض چند ثانیه آماده می‌شود. اگر کانتینر ظرف ۱۲۰ ثانیه پس از استارت‌آپ وضعیت سلامت را گزارش نکند، ایجاد آن با خطای Health Check شکست می‌خورد.
- متغیرهای محیطی (Env Vars): سقف اندازه کل متغیرهای محیطی اکنون برای استقرار مستقیم کد به ۱.۵ کیلوبایت و برای عامل‌های کانتینری به ۲.۵ کیلوبایت کاهش یافته است (در V1 این مقدار ۴ کیلوبایت بود).
- ابزارها: AWS CloudFormation و AWS CDK هنوز از تنظیم نسخه پلتفرم پشتیبانی نمی‌کنند.
صورت‌حساب و چرخه حیات
صورت‌حساب اکنون بر اساس استفاده فعال است، نه کل فضای اشغال شده توسط کانتینر. رانتایم جدید برای حافظه‌ای هزینه می‌گیرد که فعالانه استفاده شده، بر اساس تقاضا بارگذاری شده و در زمان بیکاری بازپس گرفته شده است. AWS این مدل را به عنوان «نرخ بالاتر برای گیگابایت-ساعت‌های بسیار کمتر» توصیف می‌کند. برای اکثر عامل‌ها، کاهش اثر حافظه (Memory Footprint) بر افزایش نرخ غلبه می‌کند و منجر به صورت‌حساب‌های کلی کمتر می‌شود.
جلسات در microVMهای اختصاصی با منابع ایزوله CPU، حافظه و سیستم فایل اجرا می‌شوند. این رویکرد مشابه مدیریت وضعیت در میکرو-ماشین‌های مجازی است که پیش‌تر در تحلیل‌های مربوط به Claude Code بررسی کردیم تا ایزولاسیون کامل فراهم شود. این جلسات تا ۸ ساعت باقی می‌مانند و پس از ۱۵ دقیقه عدم فعالیت، به طور خودکار خاتمه می‌یابند؛ در این لحظه microVM بسته شده و حافظه پاک‌سازی (Sanitize) می‌شود.
اسنپ‌شات‌ها به طور خودکار بر اساس نقاط انتهایی (Endpoints) مدیریت می‌شوند. AgentCore زمانی که یک نقطه انتهایی به یک نسخه اشاره کند، اسنپ‌شات را آماده می‌کند و زمانی که هیچ نقطه انتهایی به آن اشاره نکند، آن را حذف می‌کند. حذف ممکن است تا ۸ ساعت طول بکشد تا جلسات موجود به پایان برسند.
این تغییر، عامل‌های هوش مصنوعی را به کارایی میکروسرویس‌های سنتی نزدیک می‌کند. با جداسازی اندازه تصویر از زمان شروع، AWS جریمه فنی ساخت عامل‌های «سنگین» با کتابخانه‌های محلی یا تنظیمات گسترده را حذف می‌کند. این بهینه‌سازی در لایه رانتایم، مکمل تلاش‌های AWS برای اتوماسیون مدیریت خوشه‌های GPU از طریق HyperPod InstantStart است تا سرعت استقرار در تمامی سطوح زیرساختی افزایش یابد.
برای کاربر نهایی، این یعنی «لگِ پیام اول» در چت‌بات‌ها تقریباً حذف می‌شود. آمازون پیشنهاد می‌کند جلسه را به محض باز شدن پنجره چت توسط کاربر فعال کنید تا محیط در حالی که کاربر در حال تایپ است، گرم شود.
نقشه راه و شروع کار
آمازون چندین قابلیت آتی را برای بهبود تجربه لیست کرده است:
- تخفیفات خط پایه متعهد شده (Committed Baseline Discounts): رزرو یک کف حافظه برای هر جلسه با قابلیت Bursting بر اساس تقاضا برای جلساتی که همیشه فعال و پایدار هستند.
- افزایش منابع: گزینه‌های بیشتر برای RAM، vCPU و فضای ذخیره‌سازی جلسه.
- پشتیبانی از معماری: پشتیبانی از microVMهای x86.
- مدیریت وضعیت (State Management): قابلیت‌های تعلیق و ازسرگیری (Suspend-and-resume) با استفاده از اسنپ‌شات حافظه و هوک‌های رانتایم برای سریال‌سازی وضعیت پیش از خاتمه.
- هویت: کلیدهای زمینه جلسه (Session context keys) برای ارائه هویت‌های محدود شده برای عامل‌های بدون نظارت.
توسعه‌دهندگان می‌توانند از طریق راهنمای توسعه‌دهنده AgentCore، مخزن نمونه‌های AgentCore در گیت‌هاب و مثال تست بار ارائه شده برای تأیید تأخیر شروع سرد در حساب‌های خود، کار را آغاز کنند.
گام بعدی شما
- اگر از Amazon Bedrock استفاده می‌کنید، مقدار
platformVersionرا به V2 تغییر دهید تا تأخیر کاربرانتان را کاهش دهید. - برای بررسی دقیق تأخیر در حساب کاربری خود، از نمونه‌های تست بار (Load Test) در مخزن گیت‌هاب AgentCore استفاده کنید.
- استراتژی «پیش‌گرم کردن» (Pre-warming) را با فعال کردن جلسه در لحظه باز شدن UI پیاده‌سازی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو