پرش به محتوای اصلی
پرش به محتوای مقاله

کمیته مدل‌های بازمتن در برابر مدل‌های تک‌سازه غول‌پیکر در مهندسی

·۲۱ مرداد ۱۴۰۵۱۰ دقیقه مطالعه۱ بازدید
جلسه‌ای از مدل‌های ۲۷ میلیارد پارامتری، غول ۱.۶ تریلیونی را با هزینه‌ای کمتر شکست دادند
جلسه‌ای از مدل‌های ۲۷ میلیارد پارامتری، غول ۱.۶ تریلیونی را با هزینه‌ای کمتر شکست دادند
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

اثبات عملی این موضوع که یک تیم از مدل‌های ۲۷ میلیاردی می‌تواند با مصرف ۱/۱۸ توکن، عملکرد مدل ۱.۶ تریلیونی را در تسک‌های مهندسیe شکست دهد. نوآوری اصلی در «سازوکار توقف قطعی» و ارجاع هوشمند به مدل‌های جایگزین است.

تصور کنید ساعت ۱۱ شب است و تا ضرب‌الاجل انتشار پروژه تنها چند ساعت باقی مانده، اما یک باگ قدیمی در کدهای میرا (Legacy) سیستم شما، تمام تلاش‌ها را نقش بر آب می‌کند. شما با یک مخزن کد هشت ساله و مشکلی دست‌وپنجه نرم می‌کنید که سه ماه است باز مانده است. اگر این تسک را به گران‌ترین مدل ابری بازار بسپارید، احتمالاً شاهد یک حلقه تکراری خواهید بود: مدل کد را می‌خواند، تغییر می‌دهد، تست‌ها را اجرا می‌کند، با خطا مواجه می‌شود و دوباره ویرایش می‌کند. در دور نهم، مدل یک بلوک کد را به حالتی برمی‌گرداند که در دور سوم بود. در دور چهاردهم، دوباره همین اتفاق می‌افتد. مدل گیر کرده است، اما صورت‌حساب شما متوقف نمی‌شود. توکن‌ها می‌سوزند، پنجره متنی (Context) پر می‌شود و مشکل همچنان پابرجاست.

این بن‌بست، نقطه ضعف مدل‌های تک‌عاملی است؛ جایی که مدل به‌جای حل مسئله، در یک چرخه بی‌پایان از توکن‌سوزی و اشتباهات تکراری گیر می‌کند. طبق گزارش‌های منتشر شده، بسیاری از شکست‌های عامل‌های هوش مصنوعی در تسک‌های Agentic نه به‌دلیل ناتوانی در درک مسئله، بلکه به‌دلیل «چرخش در جایگاه»، تکرار اقدامات مشابه و در نهایت اتمام زمان (Timeout) رخ می‌دهد. از ژوئن سال جاری، صنعت به سمت پاسخ‌های چندمدلی حرکت کرده است: OpenRouter برای ادغام خروجی‌های مستقل، Fusion را عرضه کرد؛ Hermes قابلیت Mixture of Agents (MoA) را به یک ویژگی تبدیل کرد و Cursor از تیمی متشکل از هزاران عامل برای بازنویسی SQLite استفاده کرد. اجماع فعلی روشن است: مسیری که یک مدل نمی‌تواند از آن عبور کند، گروهی از مدل‌ها می‌توانند.

بسیاری از توسعه‌دهندگان تصور می‌کنند این رویکرد نیازمند خوشه‌های عظیم GPU و حجم عظیمی از توکن‌هاست. اما مفهوم «مرز دندانه‌دار» (Jagged Frontier) که توسط مدرسه کسب‌وکار هاروارد و تحقیقات BCG معرفی شده، ثابت می‌کند که توانمندی AI یک منحنی صاف نیست، بلکه مجموعه‌ای از قله‌ها و دره‌های عمیق است. یک مدل ممکن است در یک مسئله خاص نابغه باشد، اما در مسئله بعدی بدتر از یک کارآموز عمل کند. در مهندسی، این بدان معناست که برخی مدل‌ها در خواندن کدهای میرا عالی هستند، برخی در شناسایی ریشه خطاها در لاگ‌ها مهارت دارند و برخی دیگر در استدلال درباره تغییرات ساختاری (Breaking Changes) پیشرو هستند. رفع یک مشکل واقعی نیازمند هر سه توانمندی است؛ انتظار اینکه یک مدل در هر مرحله بهترین باشد، غیرمنطقی است. اصل اول Fusion-MOA ساده است: موضوع این نیست که کدام مدل قوی‌تر است، بلکه این است که چه کسی مدل‌ها را هوشمندانه‌تر سازمان‌دهی می‌کند.

معماری Fusion-MOA

این سیستم که توسط تیم NovaStack در شرکت ThunderSoft (中科创达) توسعه یافته، فلسفه «قوی‌ترین مدل واحد» را کنار گذاشته است. ThunderSoft با بهره‌گیری از تخصص خود در سیستم‌عامل‌های هوشمند، قابلیت‌های هسته تراشه و الگوریتم‌های AI خود را در یک مرکز داده AI و پلتفرم سرویس‌دهی مدل ادغام کرده است. Fusion-MOA یک مرکز هوشمند است که یادگیری تقویتی برای مدل‌ها را با مکانیسم‌های همکاری چندعاملی ترکیب می‌کند.

در اینجا «Fusion» یا ادغام، صرفاً یک رای‌گیری ساده با وزن‌های مختلف نیست، بلکه تلفیقی منطقی و عمیق از قابلیت‌ها، مسیرهای کاندید و شواهد قابل تایید است. این ساختار تضمین می‌کند که هر گام تصمیم‌گیری قابل ردیابی باشد. در مقابل، «MoA» (ترکیب عامل‌ها) هوشمندی لازم برای سازمان‌دهی پویا را فراهم می‌کند؛ به این صورت که بر اساس ساختار تسک، بهترین ترکیب از عامل‌ها را در لحظه زمان‌بندی می‌کند و از ناکارآمدی اجرای تکراری هر مدل برای هر تسک می‌پرهیزد.

به‌جای اینکه اجازه دهد چندین مدل روی خروجی یکدیگر بازنویسی کنند، سیستم مسئولیت‌های دقیقی را تخصیص می‌دهد. در مدل Pioneer R1، یک واحد مدل به صورت ریاضی تعریف شده است: $Cell_i = (model_i, role_i, endpoint_i, policy_i, version_i, trace_i)$. هر پروفایل تجاری $p$ به یک مجموعه شرکت‌کننده ثابت $C_p$، یک سیاست ارتباطی $M_p$، یک سیاست حل اختلاف $V_p$ و یک سیاست دسترسی $A_p$ متصل است، به‌طوری که $C_p \subseteq F$ (ناوگان مدل‌های مقیم در سیستم) باشد.

نقش‌ها و مرزهای تعریف شده

در این معماری، نقش‌ها با دقت تفکیک شده‌اند تا تداخلی ایجاد نشود:

  • مجری (Executor - E): تنها نویسنده نهایی تمام متون، فراخوانی ابزارها و برنامه‌های عملیاتی است. او رشته اصلی تسک را مدیریت می‌کند. در یک پروفایل عمومی، مجموعه شرکت‌کنندگان به صورت $C_g = {E, A_1, A_2, A_3}$ تعریف می‌شود.
  • تحلیل‌گران (Analysts - A1, A2, A3): سه مدل «فقط-خواندنی» که یک snapshot ثابت از شواهد را بررسی می‌کنند. آن‌ها به‌طور مستقل عمل کرده و تنها می‌توانند «بسته‌های داده» (Packets) ساختاریافته برگردانند.
  • درگاه (Gateway): یک لایه اعتبارسنجی است که قراردادهای رابط (Interface Contracts) را تایید می‌کند، شناسه‌های ردیابی فراخوانی (Call-tracing IDs) تولید می‌کند و یک گیت قطعی برای شناسایی توقف (Stall-detection) محاسبه می‌کند. این لایه خودش ابزاری را اجرا نمی‌کند.
  • کلاینت/عامل (Client/Agent): وضعیت خارجی تسک را نگه می‌دارد و مسئول ارسال پیام‌ها و اجرای ابزارهاست.
  • ماژول انتخاب و اعتبارسنجی: فرمت، مراجع، محدودیت‌های زمانی و تکرارها را بررسی کرده و حداکثر دو شناسه بسته (Packet ID) را برمی‌گرداند.
  • صفحه کنترل عملیات (Operations Control Plane): مدیریت ایزولاسیون، صلاحیت، ارتقاء و بازگشت (Rollback) واحدهای کاندید را بر عهده دارد. این بخش هرگز وارد زنجیره اجازه-اقدام در درخواست‌های آنلاین نمی‌شود.

این ساختار توسط سه مرز سختگیرانه حاکم می‌شود:

  1. مرز مشارکت: تعریف می‌کند چه کسی مجاز است وارد پروفایل فعلی شود.
  2. مرز اطلاعات: تعریف می‌کند شرکت‌کنندگان چه چیزی را می‌توانند ببینند و چه چیزی را می‌توانند برگردانند.
  3. مرز دسترسی: تعریف می‌کند چه کسی می‌تواند وضعیت را تغییر دهد، ابزارها را فراخوانی کند یا نتیجه نهایی را ارسال نماید.

این تفکیک مانع از انباشت هزینه‌های تضاد و بازیابی در سیستم می‌شود. سیستم تنها زمانی «مشورت محدود» را فعال می‌کند که یک توقف قطعی (Deterministic Stall) شناسایی شود؛ به این معناست که ۹۸٪ کارها توسط یک مدل واحد برای کاهش هزینه انجام می‌شود و تنها ۲٪ نقاط سخت توسط تیم مدیریت می‌گردند. این امر تضمین می‌کند که سیستم همیشه یک نویسنده واحد برای اقدامات داشته باشد.

تقابل «تیم» در برابر «غول»: بنچ‌مارک‌ها

در یک تست رودررو در Terminal-Bench 2.1 که وظایف واقعی مهندسی ترمینال را با محدودیت زمانی ۳ ساعته برای هر تسک می‌سنجد، نتایج تکان‌دهنده بود. تنها متغیر مورد بررسی، «مدل تک‌نفره» در مقابل «همکاری تیمی» بود:

  • Fusion-MOA (مدل پیشرو ۲۷ میلیاردی، روی ۸ GPU محلی): ۱۰ از ۲۰ تسک را پاس کرد (نرخ موفقیت ۵۰٪)
  • مدل ابری پرچم‌دار HY3 (مدل MoE با ۲۹۵ میلیارد پارامتر): ۹ از ۲۰ تسک را پاس کرد (نرخ موفقیت ۴۵٪)
  • همان مدل ۲۷ میلیاردی (به‌صورت تک‌نفره): ۸ از ۲۰ تسک را پاس کرد (نرخ موفقیت ۴۰٪)
  • مدل LongCat-2.0 (مدل MoE با ۱.۶ تریلیون پارامتر): ۷ از ۲۰ تسک را پاس کرد (نرخ موفقیت ۳۵٪)

دو بینش کلیدی از این نتایج حاصل می‌شود: اول، مدل ۲۷ میلیاردی وقتی در قالب تیم عمل می‌کند، ۲۵٪ مسائل بیشتری را حل می‌کند که ارزش «سازمان‌دهی» را ثابت می‌کند. دوم، یک ترکیب محلی با کسری از پارامترها، توانست غولی با ۱.۶ تریلیون پارامتر را با ۱۵ درصد اختلاف شکست دهد. همچنین Fusion-MOA به‌طور انحصاری توانست مسائل kv-store-grpc و password-recovery را حل کند؛ دو مسئله‌ای که هیچ‌کدام از مدل‌های ابری موفق به حل آن‌ها نشدند، زیرا وقتی مدل پیشرو گیر کرد، مدل دوم با زاویه دیدی متفاوت وارد شد.

عملکرد در ریاضیات و کدنویسی

بهره‌وری این سیستم به رقابت ریاضی HMMT با استفاده از امتیازدهی معادل رسمی sympy نیز کشیده شد. ادغامی از مدل‌های بازمتن در بازه ۲۰ تا ۳۰ میلیارد پارامتر، توانست با امتیاز ۸ از ۱۰، با مدل پرچم‌دار GLM-5.2 (۷۴۴ میلیارد پارامتر) برابری کند، در حالی که LongCat-2.0 (۱.۶ تریلیون پارامتر) امتیاز ۷ از ۱۰ و بهترین مدل تک‌نفره ۳۱ میلیاردی امتیاز ۶ از ۱۰ را کسب کردند. مدل DeepSeek-V4-Flash تنها ۱ از ۱۰ امتیاز را گرفت.

جالب‌ترین بخش، فرآیند حل مسئله بود: در یک مسئله دشوار، هر سه مدل در ابتدا شکست خوردند. اما پس از یک دور بحث متقاطع ناشناس (Anonymous Cross-discussion)، هر سه مدل خودشان را اصلاح کرده و به پاسخ درست رسیدند. این نشان می‌دهد که «شیمی همکاری» بین مدل‌ها واقعی است.

در مجموعه داده SWE-bench Verified برای رفع باگ‌های واقعی گیت‌هاب، Fusion-MOA به نرخ موفقیت ۱۱ از ۱۴ رسید. این نتیجه شامل دو اصلاحی بود که مدل ۲۹۵ میلیاردی HY3 در پیاده‌سازی آن‌ها شکست خورده بود.

اقتصاد هوش مصنوعی: توکن‌ها و سخت‌افزار

مخرب‌ترین یافته در مورد هزینه توکن‌ها بود. برای ۲۰ تسک مهندسی ترمینال، مصرف توکن‌های ورودی در رویکرد تیمی به‌طور چشمگیری کمتر بود:

  • LongCat-2.0: ۲۶۶ میلیون توکن
  • HY3: ۶۵.۲۷ میلیون توکن
  • Fusion-MOA: ۱۴.۲۷ میلیون توکن

سیستم Fusion-MOA تنها ۱/۱۸ توکن مورد نیاز غول ۱.۶ تریلیونی را مصرف کرد. از آنجایی که این سیستم روی سرورهای محلی اجرا می‌شود، صورت‌حساب‌های متغیر، محدودیت‌های نرخ فراخوانی (Rate Limits) و فاکتورهای غافلگیرکننده را حذف می‌کند. این سیستم برای واقعیتی طراحی شده که در آن بودجه هیچ‌کس نامحدود نیست و هیچ تسکی استحقاق بودجه نامحدود ندارد.

برای تبدیل این سیستم به یک ابزار آماده برای محیط‌های سازمانی، ThunderSoft چندین بهینه‌سازی مهندسی را اجرا کرد:

  • سرعت: با استفاده از رمزگشایی گمانه‌زنانه MTP، سرعت رمزگشایی مدل هسته از ۱۶ توکن بر ثانیه به ۶۲ توکن بر ثانیه (تقریباً ۴ برابر) افزایش یافت. نرخ برخورد حافظه پیشوند (Prefix Cache Hit Rate) در سطح ۹۰٪ تا ۹۸٪ ثابت مانده است که اجرای تسک‌های طولانی را روان‌تر می‌کند.
  • پنجره متنی: سیستم از پنجره متنی ۱۲۸ هزار توکنی پشتیبانی می‌کند که برای گنجاندن فایل‌های میرا حجیم، لاگ‌های طولانی و تاریخچه فراخوانی ابزارها در صدها دور گفتگو کافی است.
  • پایداری: در یک تست استرس مداوم ۳۶۰۰ ثانیه‌ای با ۹۰۶ فراخوانی، هیچ ری‌استارتی رخ نداد. اتصالات قطع شده به‌طور خودکار لغو می‌شوند، تایم‌اوت‌ها به حالت جایگزین (Fallback) می‌روند و خروجی‌های غیرمنطبق مشاوران به مسیر تک‌مدلی بازمی‌گردند. سیستم به‌گونه‌ای طراحی شده که «به‌طور محترمانه ساده‌تر شود»، نه اینکه «به شکلی پیچیده شکست بخورد».
  • سازگاری سخت‌افزاری: این سیستم در محیط عملیاتی روی GPUهای داخلی MetaX اجرا شده و روی پلتفرم AMD W7900D تایید شده است. سیستم نیازی به NVLink یا سخت‌افزارهای تحت محدودیت‌های صادراتی ندارد؛ زیرا با یک کارت برای هر مدل عمل کرده و تنها متن را بین کارت‌ها منتقل می‌کند. سخت‌افزارهای داخلی، مصرف‌کننده و دیتاسنتر همگی مسیرهای عملیاتی هستند.

تحلیل: چرخش به سمت AI سازمان‌یافته

این پیشرفت نشان‌دهنده یک چرخش در رقابت تسلیحاتی AI است. برای دو سال، صنعت بر این باور بود که «بزرگ‌تر بهتر است»، اما Fusion-MOA ثابت کرد که «سازمان‌دهی هوشمندانه‌تر» می‌تواند مقیاس خام را شکست دهد. این سیستم یک رابط سازگار با OpenAI فراهم می‌کند، به این معنی که کاربران می‌توانند تنها با تغییر یک خط (base_url) و بدون نیاز به بازنویسی کد، از آن استفاده کنند. تمام پیچیدگی‌های همکاری چندمدلی پشت این رابط پنهان می‌ماند.

با تبدیل مدل‌ها به کارکنان متخصص، شرکت‌ها می‌توانند سه نوع «تیم ضربت» (Tiger Teams) را مستقر کنند:

۱. «پزشک شیفت شب» برای سیستم‌های میرا: مدیریت کدهای قدیمی و باگ‌های انباشته شده‌ای که مدل‌های تک‌نفره معمولاً در آن‌ها دچار حلقه تکرار می‌شوند. کاربران می‌توانند دسته‌ای از مسائل را شب ارسال کنند و صبح وصله‌ها (Patches) را دریافت نمایند.
۲. «کمیته بازبینی» برای تصمیمات فنی: مدیریت بازبینی‌های معماری و برنامه‌های مهاجرت. این تسک‌ها به دیدگاه‌های متعدد درباره عملکرد، هزینه و ریسک نیاز دارند. با اجازه دادن به سه دیدگاه برای استدلال مستقل، سیستم از پاسخ‌هایی که فقط «در ظاهر درست به نظر می‌رسند» اجتناب می‌کند.
۳. «تیم ضربت» برای ریاضیات و الگوریتم‌ها: حل مسائل مسابقاتی و اثبات‌ها و رسیدن به سقف‌هایی که هیچ مدل واحدی به‌تنهایی قادر به لمس آن‌ها نیست، همان‌طور که امتیاز ۸ از ۱۰ در HMMT ثابت کرد.

رقابت‌پذیری آینده نه از این خواهد بود که مدل شما چقدر بزرگ است، بلکه از «قابلیت سازمان‌دهی» AI شما نشأت می‌گیرد. نسخه 0.9 از Fusion-MOA نشان می‌دهد که هوش جمعی می‌تواند از محدودیت‌های هر مدل واحد عبور کند و بنیادی استوار برای عملیاتی کردن برنامه‌های AI بدون هزینه‌های سرسام‌آور APIهای پرچم‌دار فراهم کند.

چرا این موضوع مهم است؟

این رویکرد با تکیه بر تخصص مدل‌های کوچک، هزینه‌های استنتاج را به‌شدت کاهش داده و استقلال سخت‌افزاری را ممکن می‌کند. اعتبار این یافته‌ها از طریق بنچمارک‌های سخت‌گیرانه مانند Terminal-Bench تأیید شده و مسیر جدیدی برای استقرار AI در محیط‌های سازمانی باز می‌کند.

تأثیر برای ایران

به‌دلیل عدم نیاز به سخت‌افزارهای خاص (مانند NVLink) و قابلیت اجرا روی GPUهای متنوع، این معماری برای تیم‌های توسعه در ایران که با محدودیت‌های سخت‌افزاری و تحریم‌های API مواجه‌اند، بسیار کاربردی است.

·نگاه ما
تحریریه دات‌هوش

پیروزی مدل‌های کوچک سازمان‌یافته بر غول‌های تریلیونی، پایان عصر «مقیاس‌بندی کورکورانه» (Brute-force Scaling) را اعلام می‌کند. این نتیجه نشان می‌دهد که در مهندسی نرم‌افزار، «تنوع دیدگاه» مدل‌ها ارزشمندتر از «عمق دانش» یک مدل واحد است. در واقع، ما از دوران مدل‌های همه‌کاره به دوران «سیستم‌های ارکستره‌شده» حرکت می‌کنیم که در آن مهندسیِ جریانِ کار (Workflow Engineering) جایگزین مهندسی پرامپت می‌شود.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.