اگر امروز از مدل‌های زبانی محلی برای کدنویسی استفاده می‌کنید، احتمالاً با گلوگاه کندی تولید متن دست‌وپنجه نرم می‌کنید. یک آزمایش فنی که در ۲ اکتبر ۲۰۲۶ منتشر شد، نشان می‌دهد که فعال‌سازی قابلیت پیش‌بینی چندتوکنی (Multi-Token Prediction یا MTP) می‌تواند سرعت تولید توکن‌ها در مدل Qwen3.8-27B را تا ۵۶٪ افزایش دهد. این تست نشان می‌دهد در حالی که توکن‌ها سریع‌تر arrive می‌کنند، اما این افزایش سرعت همیشه به معنای رسیدن سریع‌تر به یک وصله (Patch) موفق برای وظایف پیچیده کدنویسی نیست.
در استقرار محلی مدل زبانی بزرگ (LLM) — که شبیه کتابخانداری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — اصلی‌ترین چالش، رمزگشایی سریال است؛ یعنی مدل هر بار فقط یک توکن تولید می‌کند. این وضعیت برای توسعه‌دهندگانی که از عامل‌های هوش مصنوعی (AI Agents) برای نوشتن کد استفاده می‌کنند، به معنای یک بازی انتظار است. MTP سعی می‌کند این روند را تغییر دهد و چندین توکن آینده را به‌طور هم‌زمان پیش‌بینی کند تا مدل هدف آن‌ها را در یک مرحله تأیید کند.
این سازوکار در واقع نوعی رمزگشایی گمانه‌زنانه (Speculative Decoding) است که در لاماسی‌پلاس‌پلاس (llama.cpp) پیاده شده است. طبق مستندات فنی، در تئوری اگر پیش‌بینی درست باشد، مدل چندین مرحله از رمزگشایی را بدون تغییر در توزیع خروجی نهایی می‌پرد. برای کاربرانی که از سخت‌افزارهای مصرفی مثل RTX 3090 استفاده می‌کنند، این تفاوت می‌تواند مرز بین یک عامل کاربردی و یک ابزار کند و خسته‌کننده باشد.
زمینه و آماده‌سازی
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی استنتاج در سخت‌افزارهای لبه اشاره کردیم، کاهش تأخیر همواره اولویت اول توسعه‌دهندگان است. این تلاش‌ها در راستای بهینه‌سازی مدل‌های باز است، مشابه آنچه در دست‌وردهٔ پیش‌آموزش Magic برای کاهش ۱۰ برابری هزینه‌های محاسباتی مشاهده کردیم که بهره‌وری مدل‌ها را در مراحل اولیه افزایش داد. این آزمایش بر اساس پیشنهاد یکی از خوانندگان برای امتحان کردن MTP یا یک کوانتش که شامل آن باشد، شکل گرفت. سخت‌افزار مورد استفاده یک کارت گرافیک RTX 3090 بود که از دوران استخراج اتریوم باقی مانده بود. مدل از قبل از طریق OpenCode در حال اجرای Qwen3.8-27B بود و هدف این بود که ببینیم آیا تولید سریع‌تر متن، منجر به ارائه سریع‌تر وصله‌های صحیح می‌شود یا خیر.
برای کنترل دقیق، پژوهشگر ۸ جفت مقایسه را در قالب ۱۶ تلاش با استفاده از یک فایل مدل یکسان بررسی کرد. هر جفت دارای وظیفه، بذر (Seed) و محیط اولیه یکسان بود و تنها متغیر، تنظیمات MTP بود. برای حفظ کنترل‌های سخت‌گیرانه، پژوهشگر از بذرهای جفت‌شده ۴۲۴۲ و ۸۶۷۵۳۰۹ استفاده کرد و برای بذر دوم ترتیب را معکوس کرد تا از هرگونه سوگیری (Bias) جلوگیری شود.
پیکربندی فنی
بر اساس گزارش منتشر شده، جزئیات سخت‌افزاری و نرم‌افزاری به شرح زیر است:
- مدل و GPU: مدل Qwen3.8-27B با کوانتش Q4_K_M GGUF روی RTX 3090 با ۲۴ گیگابایت حافظه.
- پشته نرم‌افزاری: نسخه b11146 از llama.cpp، درایور CUDA 12.8 و OpenCode 2.0.20.
- تنظیمات سرور: ظرفیت ۱۳۱,۰۷۲ توکن، یک اسلات و انتقال تمام لایه‌های مدل به GPU.
- محاسبات: حافظه KV-Cache از نوع q8_0، استفاده از توجه برق‌آسا (Flash Attention)، اندازه دسته ۵۱۲ و میکرو-بچ ۲۵۶.
- پارامترهای تولید: تفکر متوسط (Medium thinking)، دمای ۱.۰، top_p 0.95 و top_k 20.
- بودجه: ۸,۱۹۲ توکن خروجی برای هر تولید و حداکثر ۴۸۰ ثانیه برای هر وظیفه.
- گمانه‌زنی: مقایسه حالت خاموش (
--spec-type none) در برابر روشن (--spec-type draft-mtp) با حداکثر طول پیش‌نویس ۳.
بنچمارک‌های سرعت
مقایسه مدل در دو حالت فعال و غیرفعال MTP، جهشی قابل‌توجه در سرعت خام را نشان داد:
- توان عملیاتی کلی: افزایش از ۳۶.۰ توکن بر ثانیه به ۵۶.۲ توکن بر ثانیه.
- پاسخ‌های کوتاه: در پاسخ‌های کوتاه برای انتخاب ابزار، سرعت با MTP به ۷۴.۰ تا ۸۴.۲ توکن بر ثانیه رسید، در حالی که بدون آن تنها حدود ۳۸.۹ تا ۳۹.۸ توکن بر ثانیه بود.
- تکمیل وظیفه: در وظایفی که با موفقیت به پایان رسیدند، زمان کل بین ۲۰.۱٪ تا ۳۹.۹٪ کاهش یافت.
تحلیل دقیق زمان‌بندی
توان عملیاتی کلی از تقسیم توکن‌های پذیرفته‌شده هدف بر زمان کل تولید سرور به دست می‌آید. این عدد شامل استدلال و فراخوانی ابزارهاست اما پردازش پرامپت و پیش‌نویس‌های ردشده را حذف می‌کند. زمان تکمیلی وظیفه، معیار جامع‌تری است که پردازش پرامپت، اجرای ابزارها و تست‌های خودِ عامل را هم شامل می‌شود و بازتاب‌دهنده زمان واقعی انتظار کاربر برای دریافت یک وصله است.
در دو جفت وظیفه مربوط به حافظه (Cache) که در هر دو حالت موفق بودند، صرفه‌جویی در زمان کاملاً مشهود بود:
- جفت اول: از ۱۹۲.۰ ثانیه (خاموش) به ۱۵۳.۵ ثانیه (روشن) = ۲۰.۱٪ صرفه‌جویی.
- جفت دوم: از ۴۳۱.۲ ثانیه (خاموش) به ۲۵۹.۰ ثانیه (روشن) = ۳۹.۹٪ صرفه‌جویی.
کیفیت کدنویسی و پس‌روی‌ها
با وجود سرعت بالا، داده‌ها نشان می‌دهند که MTP ممکن است در سناریوهای خاص باعث ناپایداری شود. از ۸۰ بررسی مستقل در ۱۶ تلاش، حالت «MTP خاموش» در ۳۵ مورد موفق شد، اما حالت «MTP روشن» تنها در ۲۶ مورد به نتیجه رسید.
نکته جالب این است که تمام این اختلاف از یک وظیفه خاص مربوط به تعمیر انتقال (transfer-repair) در یک بذر خاص نشأت گرفت. در حالت خاموش، عامل یک وصله کد تولیدی (production-code patch) ایجاد کرد که متعاقباً تمام ۱۰ بررسی مستقل را پاس کرد و در ثانیه ۴۸۰.۱ به خط پایان رسید. اما در حالت روشن، عامل در ثانیه ۱۸۶.۱ بدون ویرایش کد تولیدی متوقف شد و تنها یک بررسی را پاس کرد که در واقع همان بررسی‌ای بود که پیاده‌سازی اولیه از پیش پاس کرده بود.
تفکیک امتیاز وظایف
در سایر وظایف، امتیازها در هر دو حالت یکسان بود:
- حافظه منقضی‌شده (Expiring Cache): ۱۰ از ۱۰ برای هر دو حالت.
- دفتر کل CSV: ۱ از ۱۰ برای هر دو حالت.
- برنامه‌ریز ساخت افزایشی (Incremental Build Planner): ۱ از ۱۰ برای هر دو حالت.
- انتقالات SQLite: در حالت خاموش ۱/۱۰ و ۱۰/۱۰، اما در حالت روشن هر دو مورد ۱/۱۰ بود.
لبه‌های فنی و خطاهای خاص
پژوهشگر همچنین یک باگ ظریف در کد تولید شده توسط MTP پیدا کرد. در یک وظیفه حافظه، کاندیدای MTP عبارت math.isfinite(ttl) را برای اعتبارسنجی TTL اضافه کرد. هنگام تست با یک عدد صحیح بسیار بزرگ (۱۰ به توان ۴۰۰) و یک ساعت صحیح تزریق شده، این کد باعث بروز خطای OverflowError در هنگام تبدیل به عدد اعشاری شد. در مقابل، کاندیدای غیر MTP این مرز API افراطی را به‌درستی مدیریت کرد.
سایر بررسی‌ها نشان‌دهنده شکست‌های مشترک بود. بررسی‌های دفتر کل برای خطاهای زمان خواندن و مقادیر دقیق بزرگ در هر دو حالت شکست خوردند. یک بررسی مربوط به سرریز عدد صحیح در مقصد کیف پول (wallet destination-integer-overflow) در جفت اول در هر دو حالت شکست خورد و در جفت دوم، تنها در حالت MTP شکست خورد.
گلوگاه بودجه پاسخ
یک یافته حیاتی این است که MTP مشکل «حلقه استدلال» را حل نمی‌کند. بسیاری از شکست‌ها در هر دو حالت به دلیل یک موضوع مشترک بود: مدل تمام بودجه ۸,۱۹۲ توکنی پاسخ را صرف استدلال‌های داخلی کرد، به دلیل محدودیت طول متوقف شد و هرگز کد تولیدی را ویرایش نکرد.
از آنجا که بودجه پاسخ یک سقف سخت (Hard Cap) بر روی آنچه یک تولید می‌تواند ایجاد کند است، MTP فقط باعث می‌شود مدل سریع‌تر به این سقف برسد. این قابلیت فضای بیشتری برای فکر کردن یا نوشتن وصله‌های طولانی‌تر فراهم نمی‌کند. افزایش ظرفیت متنی (که روی ۱۲۸ هزار توکن بود) نیز این مشکل را حل نمی‌کند چون بودجه پاسخ یک محدودیت مجزا است.
کنترل‌های آزمایشی
برای تضمین دقت، بازاستفاده از حافظه پیشوند (prefix-cache) در هر دو حالت غیرفعال شد، به این معنی که تعداد توکن‌های حافظه پیشوند گزارش شده صفر بود. هر تلاش، کد اولیه را از نو ساخت و دایرکتوری کاری، پرامپت‌ها و دسترسی‌ها را تثبیت کرد. یک پروکسی تأیید کرد که نخستین درخواست‌های ارسالی به مدل در هر دو جفت دقیقاً یکسان بود و هش‌های اولیه فایل‌ها نیز مطابقت داشتند.
تحلیل: سرعت در برابر قابلیت اطمینان
برای یک توسعه‌دهنده، این نتایج نشان می‌دهد که MTP ابزاری قدرتمند برای چت و فراخوانی‌های ساده ابزار است، اما برای عامل‌های کدنویسی خودمختار ریسک‌آور است. افزایش سرعت ۵۶ درصدی وسوسه‌انگیز است، اما پس‌روی در وظیفه انتقال نشان می‌دهد که رمزگشایی گمانه‌زنانه ممکن است گاهی مدل را به مسیر استدلالی غیربهینه سوق دهد.
توضیحات احتمالی برای واگرایی در وظیفه انتقال شامل رفتار عددی در تأییدات دسته‌ای (batched verification)، مدیریت وضعیت یا تفاوت‌های نمونه‌برداری (sampling) است. علاوه بر این، چون اقدامات مختلف یک عامل می‌تواند ورودی‌های بعدی را تغییر دهد، این واگرایی ممکن است نتیجه‌ای از انتخاب مسیر کاملاً متفاوتی توسط عامل باشد.
در دنیای عملی مدل‌های محلی، تمرکز باید از «توکن بر ثانیه» به «وصله موفق در ساعت» تغییر کند. اگر مدل سریع‌تر در وظیفه‌ای شکست بخورد که مدل کندتر آن را حل می‌کند، سرعت بالا در واقع یک ضرر خالص است. شواهد فعلی پیشنهاد می‌کنند برای کدهای حساس تولیدی، MTP خاموش بماند تا علت این واگرایی‌ها مشخص شود.
برای اعتبارسنجی واقعی MTP، تست‌های آینده نیاز دارند که بودجه توکن‌های خروجی را در هر دو حالت به‌طور یکسان افزایش دهند و از وظایفی استفاده کنند که به کارهای روزمره نزدیک‌تر باشند. این کار مشخص می‌کند که آیا شکاف کیفی نتیجه مکانیسم MTP است یا صرفاً به این دلیل است که مدل سریع‌تر از توانایی‌اش در حل منطق مسئله، به محدودیت طول می‌رسد.
گام بعدی شما
- اگر از llama.cpp استفاده می‌کنید، MTP را برای کارهای متنی ساده فعال کنید اما در پروژه‌های کدنویسی حساس، آن را خاموش نگه دارید.
- بودجه توکن‌های خروجی (Response Budget) را در تنظیمات مدل خود بررسی کنید تا مطمئن شوید مدل قبل از رسیدن به جواب، به سقف توکن‌ها برخورد نمی‌کند.
- برای تست مدل‌های استدلالی، به‌جای سرعت خام، نرخ موفقیت در حل مسئله (Pass@k) را معیار قرار دهید.
اما تأثیر این بهینه‌سازی‌ها بر مصرف حافظه VRAM حتی پیچیده‌تر است — به تحلیل ما درباره مدیریت KV-Cache مراجعه کنید.
گفتگو