یک گردشکار هوش مصنوعی که بهطور کامل برنامهریزی شده است، باز هم میتواند سرور شما را از کار بیندازد. طبق پیشچاپ منتشرشده در ۲۵ اوت ۲۰۲۴، محک جدید PeakBench ثابت میکند توانایی یک عامل (Agent) در درک وابستگیهای وظایف، تقریباً هیچ ارتباطی با توانایی آن در زمانبندی این وظایف بدون اشباع منابع سیستم ندارد.
بیشتر بنچمارکهای فعلی، برنامهریزی و اجرا را در یک امتیاز واحد ادغام میکنند. این رویکرد یک نقطه کور خطرناک ایجاد میکند: یک عامل ممکن است بهدرستی تشخیص دهد که چهار فراخوانی ابزار میتوانند بهصورت موازی اجرا شوند، اما متوجه نمیشود که اجرای همزمان آنها، حد حافظه کانتینر را رد میکند. وقتی سیستم کرش میکند، توسعهدهندگان معمولاً «استدلال» عامل را مقصر میدانند، در حالی که شکست واقعی مربوط به زمانبندی فیزیکی است.
تصور کنید عاملی در حال تأیید یک استرداد وجه است. این عامل به چهار داده مستقل نیاز دارد: سوابق سفارش، امتیاز تقلب، تاریخچه مشتری و سیاستهای مربوطه. از نظر منطقی، اینها مستقل هستند و میتوانند همزمان اجرا شوند. جستوجوی سفارش و سیاستها ارزان است. اما مدل تشخیص تقلب یک چکپوینت حجیم را بارگذاری میکند و بررسی تاریخچه، رویدادهای دو سال اخیر را اسکن میکند. مجموع اینها از حد حافظه گره (Node) فراتر میرود، کانتینر ریاستارت میشود و استرداد وجه هرگز انجام نمیشود. برنامه از نظر منطقی درست بود، اما اجرا از نظر فیزیکی غیرممکن.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت و پایداری مدلهای عاملمحور اشاره کردیم، فاصله میان «دانستن» و «توانستن» در محیطهای عملیاتی، بزرگترین چالش استقرار است. این موضوع نشان میدهد که صرفاً افزایش اندازه مدلها راهکار نهایی نیست و برخی خطاهای ساختاری در برنامهریزی هوش مصنوعی حتی با مدلهای بزرگتر نیز به طور کامل رفع نمیشوند.
متدولوژی PeakBench
نویسندگان PeakBench برای جداسازی این «مشکل بار پیک»، محیط آزمایشی دقیقی طراحی کردند تا استقلال منطقی را از ظرفیت ماشین تفکیک کنند:
- کتابخانه ابزار: آنها حدود ۱۲۰۰ ابزار سازگار با پروتکل زمینه مدل (MCP) را از ۱۳۰ سرور مختلف جمعآوری کردند.
- گردشکارهای اجرایی: ۳۰۰ گردشکار اجرایی ایجاد و در کانتینرها اجرا شدند که به سه دسته آسان (۱۵۰ مورد)، متوسط (۱۰۰ مورد) و سخت (۵۰ مورد) تقسیم شدند.
- داده مرجع (Ground Truth): بهجای تکیه بر حدسهای انسانی، این محک جریان داده را ثبت کرده و ترتیب اجرا را تغییر میدهد تا گرافهای وابستگی مبتنی بر اجرا تولید کند. بازرسی دستی حدود ۱۰۰ گردشکار نشان داد ۹۴٪ این گرافها با ساختارهای بهینه مطابقت دارند.
تفکیک منطق از فیزیک
PeakBench استدلال میکند که یک گراف وابستگی به شما میگوید چه چیزی «میتواند» موازی اجرا شود، اما نمیگوید ماشین شما «بهصورت ایمن» چه چیزی را اجرا میکند. برای اثبات این موضوع، مدلها در دو محور مستقل امتیاز میگیرند:
۱. برنامهریزی منطقی: مدل توصیفات وظایف و ابزارها را دریافت میکند. مدل باید تشخیص دهد کدام فراخوانیها پیشنیاز هستند و کدامها میتوانند موازی باشند. این مورد از طریق فاصله ویرایش گراف (Graph Edit Distance) و امتیاز F1 یالها اندازهگیری میشود.
۲. زمانبندی فیزیکی: با دادن گراف وابستگی تأییدشده به مدل، ابهام برنامهریزی حذف میشود. مدل باید زمانهای شروع را تحت پروفایلهای مختلف ماشین (کوچک، متوسط و بزرگ) تعیین کند. معیارهای امتیازدهی عبارتند از:
- زمان تکمیل: مدت کل زمان برای اتمام وظیفه.
- مساحت تخطی از ظرفیت: معیاری از شدت و مدت زمان رد شدن از حد منابع (Capacity Violation Area).
- بهرهوری سختگیرانه منابع: میزان استفادهای که فقط زمانی محاسبه میشود که زمانبندی امکانپذیر باشد.
عملکرد مدلها و شکاف همبستگی
این مطالعه هشت مدل را تحت یک پروتکل واحد پرامپتنویسی و تجزیه (Parsing) ارزیابی کرد: GPT-5، o3، GPT-4.1، Claude Sonnet 4.6، GLM-5، Kimi-K2.5، DeepSeek-V4-Pro و DeepSeek-V4-Flash.
GPT-5 قویترین برنامهریز منطقی بود و فاصله ویرایش گراف ۰.۴۲ و امتیاز F1 یالها ۰.۸۳۹ را ثبت کرد. با این حال، زمانبندیِ «نابینا نسبت به منابع» آن منجر به مساحت تخطی ۳.۶۹۸ شد. در مقابل، DeepSeek-V4-Flash در بازسازی گراف ضعیفتر بود (فاصله ویرایش گراف ۰.۸۱ و F1 یالها ۰.۷۳۳)، اما پس از دریافت گراف تأییدشده، مساحت تخطی کمتری (۳.۴۵۸) داشت.
در تمام هشت مدل، همبستگی بین دقت برنامهریزی (Edge F1) و تخطی از ظرفیت تقریباً صفر بود و ضرایب گزارششده بین ۰.۰۰۰- تا ۰.۰۴۵- قرار داشت. بهطور خلاصه، دانستن اینکه «چه چیزی» میتواند موازی اجرا شود، هیچ اطلاعاتی درباره این موضوع نمیدهد که آیا ماشین «دوام» میآورد یا خیر.
نقش متادیتای منابع
پژوهشگران یک «بستر زمانبندی آگاه از منابع» (RASC) را آزمایش کردند. در این حالت، مدل برای هر فراخوانی ابزار، تخمین مدت زمان، میانگین و پیک CPU، پیک حافظه، ظرفیت ماشین و وابستگیهای تأییدشده را میبیند. نتایج توازن واضحی را در استراتژیهای اجرا نشان داد:
- موازیسازی کور (اجرای سریع همه چیز): سریعترین زمان تکمیل (۸.۶۲ ثانیه) اما بیشترین خطر (مساحت تخطی ۵.۸۶۵) و بهرهوری ایمن پایین (۰.۰۸۰).
- اجرای متوالی (یکی پس از دیگری): ایمنترین حالت (مساحت تخطی ۲.۹۲۵) اما کندترین زمان (۱۵.۱۹ ثانیه)، با بهرهوری ایمن ۰.۰۹۷.
- زمانبند مبتنی بر قانون: عملکرد متوازن (تکمیل ۹.۱۳ ثانیه، تخطی ۲.۹۲۵ و بهرهوری ایمن ۰.۱۴۱).
- بهترین نتیجه RASC: تقریباً با زمانبند مبتنی بر قانون در امتیاز تخطی (۲.۹۳۸) و زمان تکمیل (۹.۱۱ ثانیه) برابری کرد، در حالی که بالاترین بهرهوری ایمن (۰.۱۶۵) را ثبت کرد.
با این حال، RASC راهکار جهانی نبود. در حالی که به اکثر مدلها کمک کرد، DeepSeek-V4-Flash با دریافت متادیتای منابع، مساحت تخطیاش را کمی افزایش داد و Kimi-K2.5 و GPT-4.1 بهرهوری سختگیرانه خود را از دست دادند، حتی اگر سریعتر به پایان میرسیدند.
توصیههای معماری برای محیط عملیاتی
از آنجا که متادیتای منابع تنها یک ورودی است و نه یک کنترلکننده دسترسی (Admission Controller)، نویسندگان پیشنهاد میکنند از «اصلاحات پرامپت سیستمی» (مانند دستور «مراقب منابع باش») فاصله بگیرید. بهجای آن، یک معماری سهلایه پیشنهاد میشود:
- برنامهریز (The Planner): مدل باید فقط یک گراف وابستگی (DAG) صادر کند که الزامات منطقی را تعریف میکند. مثلاً مشخص کند مرحله «تصمیم» وابسته به «تقلب»، «تاریخچه» و «سیاست» است، اما نباید تصمیم بگیرد که هر فراخوانی آماده، فوراً شروع شود.
- زمانبند (The Scheduler): یک لایه زیرساختی قطعی (Deterministic) باید مالک اجرای فیزیکی باشد. هر ابزار باید یک پروفایل منابع نسخهبندی شده داشته باشد (مثلاً
[email protected]با مدت زمان p95 برابر ۴.۸ ثانیه، پیک حافظه ۶۱۴۴ مگابایت و حد همزمانی ارائهدهنده برابر ۴). سیستم باید این محدوده را با استفاده از صفها، سمافورهای هر-منبع، بودجههای نرخ-محدود (Rate-limit) و فشار معکوس (Backpressure) اجرا کند. - ردیاب (The Trace): هر تلاش باید زمان شروع درخواستی در برابر واقعی، تأخیر صف، نسخه پروفایل منابع، پیک منابع مشاهدهشده و تلاشهای مجدد یا جایگزین (Fallback) را ثبت کند. این کار تفاوت بین «قصد عامل» و «عملکرد زمان اجرا» را مشخص میکند. در این راستا، استفاده از حافظههای معنایی برای تحلیل خطاهای زمان اجرا میتواند مشابه رویکرد عاملهای HowiPrompt در ترمیم خودکار خطاهای کد باشد تا سیستم از شکستهای تکراری درس بگیرد.
تمرین عملیاتی برای محیط شما
برای تست آسیبپذیری سیستم خود در برابر مشکل بار پیک، میتوانید نسخه کوچکتری از تست PeakBench را اجرا کنید:
۱. یک گردشکار واقعی با حداقل دو فراخوانی سنگین و مستقل انتخاب کنید.
۲. مقادیر p95 مدت زمان، پیک حافظه، پیک CPU و محدودیتهای همزمانی خارجی هر ابزار را استخراج کنید.
۳. گردشکار را تحت سه حالت اجرا کنید: ظرفیت عادی تولید، ظرفیت محدود/بسیار کم (Burst-constrained) و ظرفیت تشخیصی بالا.
۴. سه سیاست «اجرای فوری هر فراخوانی آماده»، «اجرای متوالی تمام فراخوانیها» و «اجرای صف آگاه از منابع» را با هم مقایسه کنید.
در گزارش نهایی، صحت وظیفه (Correctness) و امکانپذیری منابع (Feasibility) را بهطور جداگانه ثبت کنید. پاسخی درست که محدوده ظرفیت را نقض کند، «قبول» نیست و زمانبندی ایمنی که همه چیز را متوالی کند، بهطور خودکار «خوب» نیست. هدف، دستیابی به حداکثر موازیسازی ایمن است.
نتیجهگیری و محدودیتها
PeakBench یک پیشچاپ نسخه اول است. گردشکارهای آن سنتز شده و پروفایلهای ظرفیت آن شبیهسازی شدهاند؛ به این معنی که نتایج باید به عنوان یک ابزار تشخیصی دیده شوند، نه اندازهگیری مستقیم یک کلاستر خاص. با این حال، این محک با موفقیت استدلال عملیاتی را قابل اندازهگیری کرد: اجرای یک عامل نه تنها توسط مدل و پرامپت، بلکه توسط پروفایل ماشین و زمانبند تعریف میشود. بدون این فیلدها، یک برنامه موفق باز هم میتواند منجر به قطعی سیستم شود — و مدل برای شکستی مقصر شناخته میشود که زمان اجرا (Runtime) ایجاد کرده است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell و بهینهسازی استنتاج مراجعه کنید.
گفتگو