تصور کنید مدل شما تمام دانش لازم برای حل یک مسئله را دارد، اما چون نمی‌داند چگونه از ابزارها استفاده کند، در نهایت هیچ کاری انجام نمی‌دهد. این تناقض دقیقاً همان جایی است که بسیاری از توسعه‌دهندگانی که مدل‌های زبانی بزرگ را روی سخت‌افزارهایی مثل RTX 3090 اجرا می‌کنند، شکست می‌خورند.
این مشکل زمانی رخ می‌دهد که مدل دارای توانمندی نهفته است، اما چارچوبی که آن را هدایت می‌کند ناکارآمد است. طبق بررسی‌های اخیر، تفاوت میان «هوش خام» یک مدل و «پایبندی به ابزار» (Tool Adherence) — یعنی توانایی اجرای واقعی یک تابع به‌جای صرفاً صحبت درباره آن — بسیار حیاتی است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌ی مدیریت مدل می‌تواند نقاط ضعف یا قوت‌های آن را در دنیای واقعی آشکار یا پنهان کند. این تغییر رویکرد در مدیریت عامل‌ها را می‌توان در بررسی ابزارهای محلی برای اجرای عامل‌های خصوصی مشاهده کرد که نشان می‌دهد چرا سخت‌افزارهای صنعتی دیگر پیش‌نیاز این فناوری نیستند.
در یک بنچمارک جدید، پنج مدل با وزن‌های باز (Open Weights) — که شبیه به انتشار «دستور پخت» مدل است تا هر کسی بتواند آن را اجرا کند — در دو محیط مختلف مقایسه شدند: مسیر استاندارد opencode و یک عامل ری‌اکت (ReAct) سفارشی در LangGraph که از فراخوانی ابزار بومی اولاما (ollama) استفاده می‌کرد.
بر اساس داده‌های این مطالعه، نتایج برای مدل GLM-4.5-Air (106B) تکان‌دهنده بود:
- در محیط opencode: نرخ موفقیت در ۱۲ تکلیف کدنویسی ۰٪ بود (هیچ فایلی ویرایش نشد).
- در محیط LangGraph: نرخ موفقیت به ۹۳٪ رسید.
این یعنی پرامپت‌های سیستمی سنگین در برخی چارچوب‌ها، مدل‌های محلی را گیج کرده و آن‌ها را به حالت «گفتگوی ساده» بازمی‌گرداند. در مقابل، رویکرد بومی و سبک اجازه می‌دهد مدل روی هدف تمرکز کند. با این حال، به نقل از گزارشگر این بنچمارک، «اقدام کردن» همیشه به معنای «حل مسئله» نیست. برای مثال در مدل Devstral Small، نرخ تلاش برای استفاده از ابزار از ۸٪ به ۵۳٪ رسید، اما نرخ موفقیت نهایی در کدنویسی همچنان ۸٪ باقی ماند. این ثابت می‌کند که چارچوب تعیین می‌کند مدل «تلاش» کند یا خیر، اما وزن‌های مدل تعیین می‌کنند که آیا آن تلاش «درست» است یا نه.
برنده مطلق این رقابت مدل Qwen3-Coder 30B-A3B بود که با استفاده از معماری ترکیب خبره‌ها (Mixture-of-Experts) — که شبیه به داشتن تیمی از متخصصان است که هر کدام بخشی از سؤال را جواب می‌دهند — به موفقیت ۱۰۰ درصدی در تکالیف کدنویسی دست یافت و توان عملیاتی (Throughput) بالایی ثبت کرد. برای کسانی که قصد عملیاتی کردن چنین مدل‌هایی را دارند، راهنمای استقرار مدل‌های Qwen روی کوبرنتیز می‌تواند مسیر بهینه‌سازی زیرساختی را هموار کند.
یک یافته کاربردی دیگر در این مطالعه، معیار «هزینه برق به‌ازای هر تکلیف درست» بود. با پایش توان مصرفی GPU، مشخص شد مدل‌های بهینه مثل Qwen، تکالیف را با کسری از هزینه انرژی مدل‌های بزرگ‌تر و شکست‌خورده حل می‌کنند. این بهره‌وری در کنار کاهش هزینه‌ها، یادآور تجربه‌های مشابهی است که در جایگزینی GPT-4o با مدل‌های ارزان‌تر منجر به کاهش چشمگیر هزینه‌های استنتاج شد. برای کاربران خانگی، پیام روشن است: مدل به‌صرفه‌ترین نیست که بزرگ‌ترین باشد، بلکه مدلی است که بالاترین پایبندی به ابزار را در کنار کارایی معماری داشته باشد تا انرژی GPU تلف نشود.
گام بعدی شما
- اگر از مدل‌های محلی استفاده می‌کنید، به‌جای تکیه بر پرامپت‌های سیستمی طولانی، قابلیت Native Tool Calling را در اولاما فعال کنید.
- در انتخاب مدل، به‌جای تعداد پارامترها، روی بنچمارک‌های Tool Adherence تمرکز کنید.
- برای کاهش هزینه برق و افزایش سرعت، مدل‌های مبتنی بر MoE را جایگزین مدل‌های Dense کنید.
اما تأثیر این بهینه‌سازی‌ها بر مصرف حافظه VRAM حتی پیچیده‌تر است — به تحلیل ما درباره‌ی کوانتش وزن‌ها مراجعه کنید.
گفتگو