بنچمارک پنج عامل LLM که به صورت محلی روی یک RTX 5090 اجرا شده‌اند نشان می‌دهد که یک مدل مخلوط متخصصان (MoE) با ۳۵ میلیارد پارامتر، در یک وظیفه برنامه‌نویسی دنیای واقعی از همتایان خود پیشی گرفته است. این آزمایش که شامل افزودن یک Tag Manager به یک پنل مدیریت موجود بدون استفاده از هیچ‌گونه API ابری بود، Qwen 3.6 35B-A3B را به عنوان برنده بی‌چون و چرا معرفی کرد.

چرا این آزمایش اهمیت دارد

اجرای مدل‌های زبانی بزرگ روی سخت‌افزار شخصی به توسعه‌دهندگان اجازه می‌دهد از هزینه‌های API و نگرانی‌های مربوط به حریم خصوصی داده‌ها دوری کنند. با این حال، «عامل‌های محلی» (local agents) همچنان یک اصطلاح پرزرق‌وبرق هستند: آیا آن‌ها واقعاً می‌توانند فایل‌ها را ویرایش کنند، ابزارهای خط فرمان را فراخوانی کنند و کدی آماده برای محیط عملیاتی (production-ready) ارائه دهند، بدون اینکه انسانی آن‌ها را راهنمایی کند؟ این مقایسه عملی، که از خدمات ابری تهی شده است، درک ملموسی از جایگاه فعلی این فناوری به توسعه‌دهندگان می‌دهد.

سخت‌افزار و وظیفه

هر پنج مدل روی یک ایستگاه کاری یکسان اجرا شدند: یک پردازنده گرافیکی RTX 5090، یک کارت مصرف‌کننده سطح بالای معمولی، و بدون هیچ سرویس خارجی. وظیفه به عمد ساده اما معرف بود – افزودن یک مؤلفه Tag Manager به یک بخش مدیریت که از قبل ساخته شده بود. موفقیت مستلزم آن بود که مدل فایل‌های منبع صحیح را پیدا کند، آن‌ها را ویرایش کند و تأیید کند که ویژگی جدید بدون از کار افتادن قابلیت‌های موجود، با سیستم ادغام شده است.

عملکرد مدل‌ها

  • Qwen 3.6 35B-A3B (MoE) – کار را به صورت خودکار تمام کرد، بهبودهای منطقی که درخواست نشده بودند را اضافه کرد و به هیچ اصلاحیه (patch) پس از اجرا نیاز نداشت.
  • Qwen 3.6 27B (dense) – وظیفه را انجام داد اما تقریباً دو برابر مراحل تعامل بیشتری نیاز داشت و گاهی دستورالعمل‌ها را اشتباه تفسیر می‌کرد.
  • GLM-4.7-Flash (dense) – یک پیاده‌سازی کارآمد ارائه داد اما از الگوهای مطابقت فایل نادرست استفاده کرد و بررسی‌های امنیتی را نادیده گرفت که باعث آسیب‌پذیر شدن کد شد.
  • Qwythos-9B – هیچ ابزار واقعی را اجرا نکرد؛ این شکست می‌تواند ناشی از خود مدل یا تنظیمات محلی باشد، اما آزمایش نتوانست علت دقیق را مشخص کند.
  • Nemotron-3-Nano (hybrid) – در یک حلقه گیر کرد، ۴۰ مرحله را صرف جستجوی پوشه‌ای کرد که قبلاً پیدا کرده بود و هرگز از آن نقطه فراتر نرفت.

نتایج چه چیزی را آشکار می‌کنند

معماری یک پیش‌بینی‌کننده قابل اعتماد نیست

مدل MoE، که پارامترهای خود را بین چندین زیرشبکه متخصص تقسیم می‌کند، به طور کامل پیروز شد، در حالی که نسخه‌های dense و hybrid بین موفقیت و شکست کامل تقسیم شدند. این نشان می‌دهد که انتخاب‌های معماری خام، مهارت در استفاده از ابزار را تضمین نمی‌کنند.

استفاده از ابزار همچنان یک مانع بزرگ است

هیچ‌یک از پنج عامل از ابزار اختصاصی اسکرین‌شات که برای آزمایش ارائه شده بود استفاده نکردند. همه سعی کردند با حدس زدن نام فایل‌ها یا تلاش برای راه‌حل‌های غیرمستقیم، خودشان را با شرایط وفق دهند. شکاف بین «توانایی تولید کد» و «توانایی مدیریت ابزارهای خارجی» هنوز بسیار زیاد است.

اجرای محلی به معنای عیب‌یابی کل پشته (stack) است، نه فقط مدل

دو مدل پیش از شروع آزمایش، نیاز به اصلاح فوری قالب‌های پرامپت خود داشتند. تلاشی که صرف رفع باگ‌های خاصِ مدل شد، از زمانی که صرف نوشتن کد واقعی Tag Manager شد فراتر رفت که نشان می‌دهد استقرار‌های محلی فعلی چقدر شکننده هستند.

نکته‌ای برای احتیاط

این بنچمارک منعکس‌کننده یک پیکربندی سخت‌افزاری واحد، یک سناریوی برنامه‌نویسی واحد و مجموعه کوچکی از مدل‌ها است. مدل Qwen 3.6 35B-A3B پیش از این در دور قبلی شکست خورده بود؛ شکست قبلی آن یک اتفاق تصادفی بود. بنابراین، نتایج نشان‌دهنده روند هستند، نه قطعی.

آنچه باید در آینده زیر نظر داشت

دورهای آینده باید مجموعه وظایف را گسترش دهند، زنجیره‌های ابزار متنوع‌تری را شامل شوند و روی طیف وسیع‌تری از سخت‌افزارها آزمایش شوند. ناظران باید دنبال کنند که آیا مدل‌های MoE به طور مداوم از طراحی‌های dense و hybrid بهتر عمل می‌کنند یا خیر، و آیا توسعه‌دهندگان می‌توانند پوش‌های (wrappers) قابل اعتمادی بسازند که نیاز به اصلاح دستی باگ‌ها را از بین ببرد.

نتیجه‌گیری: یک مدل MoE با ۳۵ میلیارد پارامتر می‌تواند از همین حالا به عنوان یک دستیار برنامه‌نویسی محلی توانمند عمل کند، اما اکوسیستم گسترده‌تر – یعنی ادغام ابزار، مهندسی پرامپت و زمان‌های اجرای پایدار – هنوز عقب مانده است. تا زمانی که این قطعات کنار هم قرار نگیرند، توسعه‌دهندگان باید انتظارات خود را در مورد عامل‌های محلی «آماده استفاده» (plug-and-play) تعدیل کنند.