تصور کنید ماهانه ۱۲۵ دلار بابت منابعی در AWS پرداخت میکنید که حتی نامشان را هم به یاد نمیآورید. یک سامانه چندعاملی (Multi-agent system) — شبیه تیمی از متخصصان که هر کدام وظیفه مشخصی دارند و با هم هماهنگ هستند — توانست ۴۱.۷٪ از صورتحساب ماهانه یک کاربر را در کمتر از ۶۰ ثانیه حذف کند. این پیادهسازی ثابت میکند که عبور از مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — در حالت تکپرامپت و حرکت به سمت خط لولههای عاملمحور، توهماتی که معمولاً حسابرسیهای خودکار زیرساخت را دچار خطا میکند، از بین میبرد.
اتلاف منابع ابری برای توسعهدهندگانی که سریع مقیاس میگیرند، یک مشکل سیستماتیک است. حجمهای EBS فراموششده، IPهای الاستیک بلااستفاده و اسنپشاتهای قدیمی اغلب در دیدرس هستند اما نادیده گرفته میشوند و باعث افزایش تدریجی هزینهها میشوند. برای مثال، ممکن است کاربر متوجه شود که صورتحسابش به دلیل اسنپشاتهای ۶ ماه پیش که هیچکس یادش نیست چه کسی ساخته، به ۳۰۰ دلار رسیده است. اگرچه AWS ابزارهای بومی مثل Trusted Advisor و Cost Explorer را ارائه میدهد، اما این ابزارها اغلب دقت کافی برای اینکه دقیقاً به کاربر بگویند کدام منبع را برای صرفهجویی در یک مبلغ مشخص حذف کند، ندارند.
همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی هزینههای استنتاج اشاره کردیم، مدیریت منابع در مقیاس بالا نیازماد دقت میلیمتری است. به نقل از راهنمای فنی منتشر شده در dev.to در ۹ سپتامبر ۲۰۲۶، راهکار این مشکل در یک خط لوله متوالی از سه عامل مجزا نهفته است. این معماری، فرآیند جمعآوری داده را از استدلال جدا میکند تا هوش مصنوعی شناسههای منابع را «اختراع» نکند یا بر اساس حدس و گمان، میزان صرفهجویی را تخمین نزند.
معماری سه-عاملی
این سیستم به صورت یک خط لوله خطی عمل میکند که در آن هر عامل، زمینه (Context) خود را به عامل بعدی منتقل میکند: اسکنر $ \rightarrow $ بهینهساز $ \rightarrow $ نویسنده گزارش.
- تحلیلگر هوشمند هزینه (Cost Intelligence Analyst): این عامل با استفاده از یک ابزار سفارشی که کتابخانه boto3 را در بر میگیرد، حساب کاربری را اسکن میکند. او واقعیتهای خام را درباره نمونههای EC2، حجمهای EBS، IPهای الاستیک، اسنپشاتها، باکتهای S3 و دادههای Cost Explorer جمعآوری میکند. وظیفه او تصمیمگیری نیست؛ او صرفاً واقعیتها را گزارش میکند، مثلاً: «حجم vol-0abc123، ۲۰ گیگابایت gp2، متصل نشده، ۲ دلار در ماه».
- استراتژیست بهینهسازی (Optimization Strategist): این عامل منطق FinOps را روی دادههای خام اعمال میکند. او حجمهای یتیم (Orphaned) که قابل حذف هستند، IPهای متصلنشده (که هر کدام ۳.۶۰ دلار در ماه هزینه دارند)، حجمهای gp2 که باید به gp3 مهاجرت کنند و کاندیداهای Reserved Instance که ۲۴ ساعته روی حالت On-Demand اجرا میشوند را شناسایی میکند.
- نویسنده گزارش اجرایی (Executive Report Writer): عامل نهایی یافتهها را در قالب یک گزارش Markdown اولویتبندی شده تدوین میکند. او برای هر اقدام، سطح ریسک و مبلغ دقیق صرفهجویی را مشخص میکند تا خروجی حرفهای و مناسب برای یک مدیر ارشد فناوری (CTO) تولید شود.
چرا ابزارهای بومی AWS کافی نیستند؟
طبق گزارش توسعهدهنده این پروژه، ابزارهای مدیریت هزینه AWS محدودیتهایی دارند که رویکرد عاملمحور را موثرتر میکند:
- Trusted Advisor (لایه رایگان): این ابزار تنها به ۷ بررسی محدود است. به همین دلیل مکرراً حجمهای یتیم، اسنپشاتهای قدیمی و فرصتهای ارتقای gp2 به gp3 را نادیده میگیرد.
- Compute Optimizer: تمرکز این ابزار منحصراً روی EC2 و Lambda است و از EBS، EIPها و شکافهای چرخه عمر S3 چشمپوشی میکند.
- Cost Explorer: برای نمایش اینکه «چه مقدار» هزینه کردهاید عالی است، اما به شما نمیگوید که برای اصلاح آن «چه کاری» باید انجام دهید.
- Infracost: برای زیرساختهای مدیریت شده با Terraform بسیار مفید است، اما اگر منابع به صورت دستی از طریق کنسول AWS ساخته شده باشند، عملاً بیفایده است.
رویکرد چندعاملی تمام این شکافها را در یک مرحله میپوشاند و به جای داشبوردی که نیاز به تفسیر دستی دارد، دستورالعملهای اجرایی صادر میکند؛ مثلاً: «حجم vol-0abc123 را حذف کنید تا ماهانه ۲۰ دلار صرفهجویی شود».
پیادهسازی فنی و نتایج
در این پروژه از مدل Amazon Bedrock Nova Pro به عنوان موتور استدلال استفاده شده است. دمای (Temperature) — که مثل پیچ تنظیم خلاقیت مدل است و هرچه کمتر باشد، مدل دقیقتر و خشکتر جواب میدهد — روی ۰.۲ تنظیم شد تا مدل به واقعیتها پایبند بماند. دمای بالاتر (مثلاً ۰.۷) باعث میشد بهینهساز بر اساس «حس» و نه واقعیت، منابع را پیشنهاد دهد. برای حذف ریسک امنیتی مدیریت کلیدهای API استاتیک، سیستم روی یک نمونه EC2 با یک نقش IAM اجرا شد تا کلاینت boto3 به طور خودکار نقش نمونه را شناسایی کند.
توسعهدهنده یک ابزار سفارشی به نام AWSCostScannerTool ساخت که متدهای boto3 را در بر میگیرد. برای مثال، متد _scan_ebs() دستور ec2.describe_volumes() را اجرا کرده و هر حجمی که لیست Attachments آن خالی باشد را علامتگذاری میکند. این ابزار شامل متدهای اسکن تخصصی زیر است:
_scan_ec2()برای تحلیل نمونهها._scan_ebs()برای بررسی حجمها._scan_eips()برای حسابرسی IPهای الاستیک._scan_snapshots()برای شناسایی بکآپهای قدیمی._scan_s3()برای تحلیل باکتها._scan_costs()برای یکپارچگی با Cost Explorer.
در یک تست واقعی، این عاملها موارد زیر را شناسایی کردند:
- سه حجم EBS یتیم: ۳۳ دلار صرفهجویی در ماه.
- دو IP الاستیک متصلنشده: ۷.۲۰ دلار صرفهجویی در ماه.
- یک نمونه t3.medium که باید رزرو میشد: ۸۲ دلار صرفهجویی احتمالی.
- دو اسنپشات منسوخ شده از ژانویه.
غلبه بر چالشهای رایج
این پروژه چند نکته حیاتی و «تله» برای توسعهدهندگانی که قصد ساخت سیستمهای مشابه را دارند، برجسته میکند:
- نسخه پایتون: CrewAI به پایتون ۳.۱۱ به بالا نیاز دارد. استفاده از نسخه پیشفرض ۳.۹ در Amazon Linux 2023 منجر به خطای
ModuleNotFoundErrorمیشود. توسعهدهندگان باید صراحتاً ازpython3.11وpip3.11استفاده کنند. - دسترسی به مدل: کاربران باید به صورت دستی در کنسول Bedrock و در بخش "Model access" درخواست دسترسی به Nova Pro را بدهند، در غیر این صورت با خطای
AccessDeniedExceptionمواجه میشوند. - متغیرهای محیطی: سیستم به متغیر محیطی
AWS_DEFAULT_REGIONوابسته است. از آنجایی که CrewAI فایلهای~/.aws/configرا نمیخواند، منطقه (Region) باید صراحتاً Export شود تا از خطایNoRegionErrorجلوگیری شود. - تاخیر Cost Explorer: اگر Cost Explorer هرگز استفاده نشده باشد، AWS حدود ۲۴ ساعت زمان نیاز دارد تا دادهها را جمعآوری کند. در اجراهای اولیه ممکن است تفکیک هزینهها خالی باشد، هرچند منابع یتیم همچنان شناسایی میشوند.
علاوه بر این، مشخص شد که رویکرد تکپرامپت — یعنی درخواست از یک LLM برای اسکن، تحلیل و گزارش همزمان — منجر به عملکرد متوسط و تولید شناسههای جعلی (توهم) میشود. تفکیک نقشها در سامانه چندعاملی این مشکل را حل میکند: اسکنر بهینهسازی نمیکند و بهینهساز گزارش نمینویسد. در این راستا، بهینهسازی مصرف توکنها در سیستمهای عاملمحور اهمیت ویژهای دارد، چرا که بخش بزرگی از هزینههای این عاملها صرف بازخوانی تاریخچه و تکرار دادهها میشود.
استقرار و اجرا
راهاندازی سیستم به گونهای طراحی شده که سریع باشد. پس از کلون کردن مخزن از گیتهاب، فرآیند شامل نصب ساده نیازمندیها و Export کردن منطقه است. کل فرآیند اجرا — از اولین فراخوانی API تا گزارش نهایی Markdown — برای یک حساب معمولی کمتر از ۶۰ ثانیه زمان میبرد.
برای کسانی که رابط گرافیکی را ترجیح میدهند، یک داشبورد Streamlit طراحی شده است. این رابط کاربری همان عاملها را در بر میگیرد و دکمههای اصلاحی (Remediation) را اضافه میکند تا کاربران بتوانند منابع یتیم را مستقیماً از مرورگر حذف کنند. با این حال، هسته اصلی سیستم همچنان CLI است، زیرا میتواند از طریق SSH روی هر نمونه EC2 بدون نیاز به وبسرور اجرا شود.
چرخش به سمت FinOps
این رویکرد مدیریت ابر را از نظارت واکنشی در داشبوردها به حسابرسی پیشدستانه و عاملمحور تغییر میدهد. با زمانبندی اجرای این خط لوله در هر دوشنبه صبح (Cron-scheduling)، تیمها میتوانند پاکسازی زیرساخت را به یک روتین تبدیل کنند، نه یک بحران فصلی.
برای خواننده، این بدان معناست که مانع رسیدن به «بهداشت کامل» ابری دیگر زمان یا تخصص نیست، بلکه تنها راهاندازی یک خط لوله عاملمحور ساده است. هزینه اجرای هر بار این حسابرسی حدود ۰.۰۱ دلار است که بازگشت سرمایه (ROI) آن برای هر حسابی با بیش از ۱۰ منبع، تقریباً آنی است. البته برای حسابهای بسیار کوچک (کمتر از ۵ منبع) یا کاربرانی که هنوز در لایه رایگان هستند، سربار راهاندازی ممکن است در مقایسه با بررسی دستی ارزشمند نباشد. برای مدیریت دقیقتر این هزینههای خرد، میتوان از راهکارهای کنترل سقف توکن برای ردیابی مصرف در APIهای رایگان استفاده کرد.
اگر یک زیرساخت در حال رشد در AWS مدیریت میکنید، گام بعدی بازبینی نقشهای IAM است تا مطمئن شوید عامل هوش مصنوعی میتواند با ایمنی منابع را اسکن کند اما اجازه حذف پیشرس را ندارد. برای تجربه بصری، داشبورد Streamlit میتواند این عاملها را در بر بگیرد تا دکمههای حذف تککلیکی برای منابع یتیم فراهم کند.
پاکسازی نهایی و ایمنی
هنگام تست این عاملها، مدیریت منابع دمو بسیار حیاتی است. اسکریپت دموی ارائه شده (scripts/create-demo-resources.sh) حدود ۴۰ دلار در ماه منابع مجازی ایجاد میکند تا عملکرد عاملها تایید شود. برای جلوگیری از هزینههای واقعی، کاربران باید اسکریپت پاکسازی (bash scripts/cleanup-demo-resources.sh) را اجرا کنند یا به صورت دستی از طریق AWS CLI منابع را آزاد کنند:
- حذف حجمها:
aws ec2 delete-volume --volume-id vol-xxx --region us-east-1 - آزاد کردن IPها:
aws ec2 release-address --allocation-id eipalloc-xxx --region us-east-1
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو