تصور کنید یک سیستم را در نظر بگیرید که یک عامل هوش مصنوعی را مجبور می‌کند پیش از ارائه حکم نهایی، ۱۱ مسیر متمایز راهکار — از اجاره GPU گرفته تا استفاده از خبره‌های MoE در رم سیستم — را به‌طور مجزا طی کند. این همان هستهٔ مرکزی مشاور سخت‌افزاری جدیدی است که توسط HelgardorLM ساخته شده تا ثابت کند ترکیب بازیابی ساختاریافته و اعتبارسنجی مبتنی بر کد، می‌تواند مانع از توهمات مدل‌های زبانی بزرگ (LLM) در مورد مشخصات حیاتی و حساس سخت‌افزاری شود.
انتخاب سخت‌افزار مناسب برای هوش مصنوعی به‌دلیل تغییر مداوم نیازهای حافظه ویدیویی (VRAM) با هر انتشار مدل جدید، به‌شدت دشوار و بدنام است. در حالی که ما پیش‌تر پوشش دادیم که چگونه تقاضای انرژی برای هوش مصنوعی در محیط‌های شهری تا سال ۲۰۳۶ به ۱۸ گیگاوات خواهد رسید، چالش فوری برای توسعه‌دهندگان انفرادی «شکاف محاسباتی» است؛ یعنی تمایل مدل‌های زبانی به اشتباه محاسبه کردن حافظه KV cache یا حافظه مورد نیاز برای وزن‌های مدل. اکثر عامل‌های فعلی به تولید بازیابی‌افزا (RAG) متنی ساده متکی هستند، که اغلب زمانی شکست می‌خورد که مدل نیاز داشته باشد محاسبه کند که آیا یک مدل ۳۲۱ میلیارد پارامتری از نوع MoE بر روی سخت‌افزاری خاص می‌گنجد یا خیر.
معماری حقیقت
این سامانه بر پایه یک مجموعه داده Sanity (شناسه پروژه: onwa0wvs، نسخه عمومی v2) بنا شده است که شامل ۲۰۰ سند در ۱۵ دسته‌بندی مختلف است. این دسته‌بندی‌ها شامل مواردی چون law (قانون)، rule (قاعده)، solutionPath (مسیر راهکار)، aiModel (مدل هوش مصنوعی)، gpu (پردازنده گرافیکی)، cpu (پردازنده مرکزی)، runReport (گزارش اجرا)، offer (پیشنهاد) و cloudOffer (پیشنهاد ابری) می‌شود. این سیستم به‌جای یک چت‌بات ساده، به عنوان یک نقطه اتصال عمومی پروتکل زمینهٔ مدل (MCP) عمل می‌کند که کاربران می‌توانند آن را به عامل‌هایی مانند Claude، ChatGPT، Claude Code، Codex، Cursor یا VS Code متصل کنند.
به نقل از مستندات پروژه، توسعه‌دهنده برای تضمین دقت، یک پروکسی stdlib در حدود ۲۳۰ خط کد پیاده کرده است که ابزار حیاتی check_answer را اضافه می‌کند. این ابزار مانند یک بازرس یا اعتبارسنج عمل می‌کند: محاسبات عامل را استخراج کرده و آن‌ها را با استفاده از فرمول‌های law.formula که در Sanity ذخیره شده‌اند، مجدداً اجرا می‌کند. این رویکرد در واقع پاسخی به این پرسش است که آیا بازرسی خروجی‌ها موثرتر از مهندسی پیچیدهٔ پرامپت است یا خیر. اگر اعداد هم‌خوانی نداشته باشند، سیستم پیش‌نویس را رد کرده و آن را برای اصلاح به عامل بازمی‌گرداند. در یک تست اولیه با Codex، این بازرس اولین پیش‌نویس را به‌دلیل وجود ۴ خطا رد کرد؛ پیش‌نویس دوم تنها پس از آنکه ۵ محاسبه مجدداً انجام شد و تمام ۱۱ مسیر راهکار پیموده شدند، تأیید گردید.
زمینه و پیاده‌سازی
این عامل از چهار ابزار اصلی Sanity Context MCP استفاده می‌کند: initial_context (زمینه اولیه)، groq_query (پرس‌وجوی گروک)، schema_explorer (کاوشگر طرحواره) و array_field_reader (خواننده فیلد آرایه). این ساختار به عامل اجازه می‌دهد تا مسیرهای راهکار را به‌جای متن ساده، به‌عنوان «داده» پردازش کند. برای هر پرسش، عامل موظف است برای تک‌تک اسناد solutionPath یک حکم «بله/خیر/شاید» به‌همراه یک عدد پشتیبان ارائه دهد.
این ۱۱ استراتژی سخت‌افزاری که عامل باید ارزیابی کند عبارت‌اند از:
- حفظ سخت‌افزار فعلی
- ارتقای قطعات موجود
- خرید سخت‌افزار دست‌دوم
- پیکربندی تک GPU
- پیکربندی‌های چند GPU
- سیستم‌های حافظه یکپارچه (Unified Memory)
- میزبانی خبره‌های ترکیب خبره‌ها (MoE) در رم سیستم
- اجرای مدل‌های کوچک فقط روی CPU
- مهاجرت به یک مدل کوچک‌تر
- استفاده از APIهای ابری
- اجاره GPU
پایان لغزش‌های ریاضی
در یک ردیابی واقعی (Trace) مربوط به مدل GLM-5.3-Flash (که در مجموعه داده پایه وجود نداشت)، سخت‌گیری این سیستم کاملاً مشهود بود. چون مدل در دیتابیس نبود، عامل بر اساس چک‌لیست داخلی خود ۸ جست‌وجوی وب انجام داد تا کارت مدل و فایل config.json (به‌ویژه برای یافتن تعداد لایه‌ها، سرهای KV و ابعاد سر یا head dim) را پیدا کند.
عامل در ابتدا سقف سرعت را ۱۹.۹۱ توکن بر ثانیه گزارش کرد. اما ابزار اعتبارسنجی فرمول را بازمحاسبه کرد و دریافت که پاسخ واقعی ۱۹۹.۱ است؛ یعنی یک خطای ۱۰ برابری. همچنین سیستم محاسبه کرد که وزن‌ها در حالت NVFP4 برابر با ۱۶۰ گیگابایت و حافظه KV برای کانتکست 8k برابر با ۲۲.۵ گیگابایت است.
سایر موارد خاصی که توسط بازرس شناسایی و اصلاح شدند عبارت بودند از:
- خطاهای KV Cache: اصلاح یک محاسبه از ۰.۹۴۹ گیگابایت به ۶.۷۵ گیگابایت برای GPU مدل A4.
- هزینه‌های برق: اصلاح تخمین‌های ماهانه از ۰.۶۷۵ به ۲.۰۲۵ برای مدل A5.
- فیلدهای مفقود: هشدار در زمانی که عامل در حین جست‌وجوی وب، فیلدهای ضروری مانند
variants.fileGbیاslotsرا نادیده می‌گرفت. - منطق فرمول: شناسایی مدلی که در فرمول «خرید در برابر اجاره»، هزینه‌های برق را به‌جای تفریق، جمع کرده بود؛ خطایی که نقطه سربه (breakeven) را از ۱۲.۳ ماه به ۱۱۰ ماه تغییر می‌داد.
بنچمارک: ساختار در برابر متن
برای سنجش کارایی این رویکرد، توسعه‌دهنده از یک داور کور (یک مدل مجزا) در ۹ سناریو و ۲۷ اجرا استفاده کرد و ۷۸ مورد از چک‌لیست را مورد آزمایش قرار داد. نتایج نشان‌دهنده یک پیشرفت واضح در دقت بود:
- نسخه ۲ (پایه + دستورالعمل‌ها): امتیاز ۴۷ از ۷۸ با میانگین زمان ۶۲ ثانیه.
- نسخه ۳ (افزودن مسیرهای راهکار): افزایش امتیاز به ۵۳ از ۷۸ با میانگین زمان ۱۰۴ ثانیه.
- نسخه ۳.۱ (Sanity Context MCP + اعتبارسنج): رسیدن به امتیاز ۵۹ از ۷۸ با میانگین زمان ۱۸۱ ثانیه.
نکته جالب این است که توسعه‌دهنده دریافت صرفاً چسباندن ۲۰۰ سند به‌صورت یادداشت‌های متنی ساده، تنها امتیاز ۵۳ از ۷۸ را به دست می‌آورد. این موضوع نشان می‌دهد که اگرچه مدل‌های زبانی می‌توانند داده‌ها را بخوانند، اما بدون اجبار ساختاری ابزارهای MCP و اعتبارسنج خارجی، نمی‌توانند منطق را به‌طور قابل‌اعتمادی اعمال کنند. این تمرکز بر دقت خروجی یادآور مکانیزم فیلترهای سخت‌گیرانه برای افزایش دقت Gemma 4 است که برای کاهش خطاها در مدل‌های لبه به کار می‌رود. پیشرفت‌های نسخه ۳.۱ به‌ویژه در سناریوهای خاص مشهود بود: احکام «نخرید» از ۴/۶ به ۶/۶ و محاسبات KV cache برای ۸ کاربر از ۷/۹ به ۹/۹ بهبود یافت.
موازنه: سرعت در برابر قطعیت
این سطح از دقت هزینه‌ای در عملکرد دارد. تولید پاسخ‌ها در نسخه ۳.۱ تقریباً سه برابر کندتر از نسخه‌های قبلی است. این تأخیر به‌این دلیل رخ می‌دهد که اعتبارسنج ممکن است پاسخ را تا دو بار پیش از تأیید نهایی ریاضی، به عامل بازگرداند.
با این حال، هنوز محدودیت‌هایی وجود دارد. اعتبارسنج اعداد، منابع و کامل بودن پاسخ را چک می‌کند، اما هنوز نمی‌تواند قضاوت کند که آیا یک حکم از نظر منطقی «معنا می‌سازد» یا خیر. برای مثال، در یک تست، عامل پیشنهاد داد که خبره‌های MoE برای یک مدل Dense (متراکم) در رم قرار گیرند؛ چون محاسبات ریاضی از نظر فنی درست بود، اعتبارسنج آن را تأیید کرد، هرچند این پیشنهاد از نظر منطقی اشتباه بود. علاوه بر این، برخی اجراها در ابتدا به‌دلیل تنظیمات حساب کاربری، پاسخ‌هایی به زبان روسی تولید می‌کردند که نیازمند پیاده‌سازی یک بررسی زبانی مبتنی بر کد بود.
این چرخش به سمت عامل‌های «تأییدشده با کد» نشان می‌دهد که آینده هوش مصنوعی قابل‌اعتماد، نه در افزایش تعداد پارامترها، بلکه در ایجاد حلقه‌های بسته و تنگ‌تر میان استدلال LLM و اجرای قطعی کد (Deterministic Code Execution) است. برای کاربر، این به معنای گذار از اعتماد به «حدس» یک چت‌بات به سمت سیستمی است که می‌تواند محاسبات خود را اثبات کند.
گام بعدی شما
- اگر از عامل‌های AI برای تخمین هزینه یا سخت‌افزار استفاده می‌کنید، هرگز اعداد را بدون یک اسکریپت ساده پایتون بازبینی نکنید.
- پروتکل MCP را برای متصل کردن پایگاه‌داده‌های ساختاریافته به Claude بررسی کنید تا از توهمات متنی فاصله بگیرید.
- در طراحی عامل‌های خود، لایه «بازرس» (Validator) را جدا از لایه «تولیدکننده» (Generator) پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو