میزبانی عامل‌های هوش مصنوعی در گوگل کلاد با هزینه ۵.۷۰ دلار در ماه

اگر قصد دارید یک عامل هوش مصنوعی بسازید که شب‌ها بیدار بماند و کارهای شما را مدیریت کند، دیگر نیازی به مدیریت سرورهای پیچیده ندارید. حالا می‌توانید یک عامل دائمی را تنها با هزینه ۵.۷۰ دلار در ماه روی زیرساخت گوگل استقرار دهید.

این امکان از طریق Cloud Run instances، نوع جدیدی از منابع در گوگل کلاد (Google Cloud)، فراهم شده است. طبق مستندات گوگل، این قابلیت به عامل‌ها اجازه می‌دهد در پس‌زمینه فعال بمانند؛ مثلاً هشدارها را مرتب کنند، برنامه‌های زمانی را مدیریت کنند یا مخازن کد را در Dependabot مورد بررسی قرار دهند، بدون اینکه توسعه‌دهنده درگیر مدیریت یک سرور کامل شود.

برای سال‌ها، برنامه‌نویسان بین دو گزینه سخت گیر بودند: سادگی سرویس‌های بدون سرور (Serverless) یا پایداری ماشین‌های مجازی (VM). همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت گردش‌کارهای مبتنی بر جمینای در کلاد ران اشاره کردیم، صنعت مدت‌ها به دنبال راه حلی بود که در آن «وضعیت» (State) برنامه بدون نیاز به نگهداری دستی سرور، حفظ شود.

زمینه و نیازهای عامل‌های دائمی

عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیاران اداری که هر لحظه آماده‌اند تا دستورات شما را اجرا کنند — دیگر فقط به یک سؤال پاسخ نمی‌دهند. آن‌ها در پس‌زمینه کار می‌کنند تا مثلاً خلاصه اخبار صبحگاهی را آماده کنند، یک برنامه روزانه را در قالب پادکست تحویل دهند یا هشدارها را در طول شب دسته‌بندی کنند. پس از اتمام این وظایف، آن‌ها منتظر محرک (Trigger) بعدی می‌مانند.

بر اساس گزارش فنی منتشر شده در ۲ اکتبر ۲۰۲۶، چالش اصلی برای عامل‌های خودکار، برآوردن یک نیاز سه‌گانه است:

• عملکرد مداوم: عامل باید بتواند کارهای خود را زمان‌بندی کند و بدون نیاز به یک برنامه‌ریز خارجی، خودش را بیدار کند.
• حافظه پایدار: تاریخچه، حافظه و برنامه‌ریزی‌ها باید پس از به‌روزرسانی‌ها یا ری‌استارت‌های سیستم، از بین نروند.
• سادگی: راه‌اندازی باید با یک آدرس وب ثابت و بدون نیاز به مدیریت سرور باشد.

توابع بدون سرور استاندارد در اینجا شکست می‌خورند؛ چون وقتی درخواستی دریافت نمی‌کنند، خاموش می‌شوند و تمام حافظه و حلقه‌های فعال عامل پاک می‌شود.

مقایسه معماری‌های میزبانی

برای حل این مشکل، در یک بررسی فنی سه معماری مختلف با هم مقایسه شدند تا بهترین گزینه برای میزبانی عامل‌ها مشخص شود:

• Cloud Run Services: برای اپلیکیشن‌های وب عالی هستند چون امنیت، لاگ‌ها و آدرس URL را بدون مدیریت سرور فراهم می‌کنند. اما در زمان بیکاری «می‌روند» (Sleep)، که برای عاملی که حلقه کاری‌اش با خاموش شدن سرویس ناپدید می‌شود، یک نقص مرگبار است.
• ماشین‌های مجازی (VMs): این‌ها همیشه بیدارند و همه چیز را به خاطر می‌سپارند و نیاز به تداوم و حافظه را پوشش می‌دهند. اما بار سنگین مدیریت، از جمله تنظیم فایروال، به‌روزرسانی سیستم‌عامل، نظارت (Supervision) و مدیریت گواهینامه‌ها را به دوش برنامه‌نویس می‌اندازند. این حجم از مدیریت برای برنامه‌ای که بیشتر وقتش را در حالت انتظار می‌گذراند، بیش از حد است.
• Cloud Run Instances: یک منبع جدید شامل یک کانتینر تک‌واحدی است که همیشه روشن است. این مدل آدرس ثابت و حافظه‌ای فراهم می‌کند که در برابر هر اتفاقی باقی می‌ماند. همچنین می‌توان آن را با کمترین تلاش شروع کرد، متوقف کرد یا به‌روزرسانی نمود.

جزئیات فنی، عملکرد و هزینه

تست‌های انجام شده با Hermes Agent — یک عامل متن‌باز که توسط Gemma 4 قدرت گرفته — نشان داد که این مدل Instance بسیار مقرون‌به‌صرفه است. این عامل از طریق یک سرویس مجزای Cloud Run که مجهز به واحد پردازش گرافیکی (GPU) است با مدل ارتباط برقرار می‌کند، زیرا خودِ این Instanceها فعلاً از GPU پشتیبانی نمی‌کنند.

یک هفته تست نشان داد که عامل در برابر ری‌استارت‌های اجباری گوگل برای نگهداری، تنها در ۲۰ ثانیه زنده مانده و ظرف ۹۰ ثانیه کارش را از سر گرفته است. هزینه پایین (شروع از ۵.۷۰ دلار در ماه برای کوچک‌ترین اندازه) به دلیل تخصیص منعطف CPU است. سیستم در حالت عادی توان کمی مصرف می‌کند، اما وقتی عامل در حال «تفکر» یا فراخوانی ابزارهاست، می‌تواند تا سه و نیم دقیقه به حداکثر توان برسد. معمولاً دو دقیقه آرامش کافی است تا سیستم به حالت پایه خود بازگردد.

محدودیت‌های حیاتی

با این حال، چون این ویژگی در حالت پیش‌نمایش (Preview) است و از اواخر اوت ۲۰۲۶ عرضه شده، چندین محدودیت باقی مانده است:

• محدودیت منطقه‌ای: همه مناطق این قابلیت را ندارند. در اروپا، تنها یک منطقه است که هم Instance و هم سرویس GPU مورد نیاز برای مدل هوش مصنوعی را هم‌زمان ارائه می‌دهد.
• ماهیت ذخیره‌سازی: حافظه آن یک دیسک واقعی نیست. این فضای ذخیره‌سازی برای فایل‌هایی که توسط یک برنامه به‌صورت یک‌باره نوشته می‌شوند مناسب است، اما برای پایگاه‌های داده پیچیده کاربرد ندارد.
• چرخه‌های نگهداری: تقریباً هر هفته یک بار ری‌استارت رخ می‌دهد؛ بنابراین عامل‌ها باید طوری طراحی شوند که برنامه‌ریزی خود را از حافظه ذخیره بازخوانی کنند، نه حافظه موقت (Volatile Memory).
• زمان توقف به‌روزرسانی: به‌روزرسانی کانتینر باعث قطع سرویس برای حدود دو دقیقه می‌شود.

توصیه می‌شود تنظیماتی که زیاد تغییر می‌کنند در یک Secret Manager یا فایل ذخیره‌سازی خارجی نگه داشته شوند تا نیاز به به‌روزرسانی‌های مکرر کانتینر و قطعی‌های احتمالی نباشد.

مزیت سندباکس‌ها

یکی از نقاط قوت برجسته این سیستم، توانایی اجرای سندباکس‌های کد (Code Sandboxes) در چند میلی‌ثانیه است. وقتی عامل کدی تولید می‌کند، می‌تواند آن را در محیطی ایزوله اجرا کند بدون اینکه به سیستم میزبان آسیب بزند. این محیط‌ها به‌طور پیش‌فرض به اینترنت، اعتبارنامه‌های عامل یا حافظه اصلی دسترسی ندارند تا کدهای «توهم‌زده» (Hallucinated) باعث تخریب سیستم نشوند.

جدول مقایسه‌ای نهایی

در نهایت، این تغییر یعنی دنیای بدون سرور بالاخره یاد گرفت چگونه وضعیت خود را حفظ کند. اگرچه پردازش‌های موازی عظیم هنوز به سرویس‌های استاندارد Cloud Run نیاز دارند، اما «عامل‌های پس‌زمینه» حالا خانه‌ای اختصاصی و ارزان دارند.

اگر در حال ساخت گردش‌کارهای خودکار هستید، منتظر گسترش آتی سرویس‌های Cloud Run باشید که نویسنده به آن اشاره کرده است؛ این به‌روزرسانی‌ها احتمالاً نحوه تعامل عامل‌ها با ابزارهای خارجی را بیش از پیش بهینه خواهد کرد.

گام بعدی شما

• اگر از مدل‌های Gemma 4 استفاده می‌کنید، معماری Instance را برای جایگزینی با VMهای گران‌قیمت تست کنید.
• برای جلوگیری از توقف سرویس، تنظیمات متغیر خود را به خارج از کانتینر منتقل کنید.
• استراتژی بازخوانی حافظه (State Recovery) را در کد عامل خود پیاده کنید تا ری‌استارت‌های هفتگی گوگل باعث توقف کار نشود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.