چگونه مدل ThinkingCap حجم توکن‌های استدلال را ۳۷ درصد کاهش داد؟

مدل‌های استدلالی فعلی اغلب روی توکن‌هایی هزینه می‌کنند که هیچ تأثیری بر پاسخ نهایی ندارند. ThinkingCap-Qwen3.8-27B ثابت می‌کند که می‌توان با هرس کردن این ردپاهای زائد، سرعت استنتاج را بدون تخریب هوش مدل افزایش داد. طبق گزارش فنی منتشر شده در marktechpost.com، BottleCap AI توانسته است میانگین توکن‌های مورد نیاز برای تفکر را در ۱۲ محک کلیدی تا ۳۷.۲٪ کاهش دهد.

این دستاورد در حالی رخ می‌دهد که صنعت با تأخیر بالا و هزینه‌های سنگین مدل‌های استدلالی (Reasoning Models) یا مدل‌های «سیستم ۲» دست‌وپنجه نرم می‌کند. در حالی که مدل‌های سری Qwen قابلیت‌های عمیقی در زنجیره تفکر (Chain-of-Thought) دارند، اما اغلب برای پرسش‌های ساده بیش از حد فکر می‌کنند. رویکرد BottleCap AI، کارایی استدلال را به جای یک محصول جانبی یا نتیجه‌ی اندازه مدل، به هدف اصلی بهینه‌سازی تبدیل کرده است. این تلاش برای کاهش هزینه‌های عملیاتی در راستای روندهایی است که در مدل‌های دیگر نیز دیده می‌شود؛ برای مثال، مدل BDH-CQ توانست هزینه استنتاج در محک ARC-AGI را به شدت کاهش دهد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی مدل‌های بازمتن اشاره کردیم، کاهش هزینه استنتاج اکنون به اندازه افزایش دقت اهمیت یافته است.

اهداف و سازوکار فنی

مدل ThinkingCap-Qwen3.8-27B دومین عضو این خانواده است و پس از نسخه قبلی که بر پایه Qwen3.6-27B بود، عرضه شده است. هدف تیم توسعه در این نسخه به‌طور آگاهانه محافظه‌کارانه بود؛ آن‌ها تلاشی برای افزودن دانش جدید یا تغییر سبک پاسخ‌دهی نکردند.

به نقل از مستندات فنی، تمرکز اصلی بر این بود که توانایی استدلال، پیروی از دستورات و رفتارهای ایمنی در فرآیند تنظیم دقیق (Fine-tuning) دست‌نخورده باقی بمانند. برای تضمین پایداری، تیم تحقیق تأکید بیشتری بر محک‌های ریاضی، استدلال، زمینه‌های متنی طولانی و قابلیت‌های عامل‌محور (Agentic) صورت داد.

این مدل یک تنظیم دقیق مستقیم از مدل پایه Qwen3.8-27B است. داده‌ها نشان می‌دهند که صحت کلی (Macro-average accuracy) مدل از ۸۶.۶۵٪ به ۸۵.۷۹٪ رسیده است؛ یعنی یک هزینه ناچیز (۰.۸۶ درصد) در برابر افزایش چشمگیر سرعت. میانگین توکن‌های تفکر (Pooled mean thinking tokens) از ۱۵,۷۳۵ به ۱۲,۱۴۴ عدد کاهش یافته است.

تحلیل عملکرد در محک‌های مختلف

میزان کاهش توکن‌ها بسته به نوع وظیفه، بین ۱۰.۷٪ تا ۶۵.۵٪ متغیر است:

• دانش و چندزبانی: بیشترین کاهش در این بخش رخ داده است؛ توکن‌های تفکر در MMMLU حدود ۶۵.۵٪ (از ۱,۶۵۶ به ۵۷۱) و در MMLU-Pro حدود ۵۷.۳٪ کم شده‌اند.
• استدلال پیچیده: در محک GPQA-Diamond کاهش ۴۳.۱ درصدی مشاهده شد (از ۱۲,۷۷۲ به ۷,۲۶۷ توکن). در IFBench نیز توکن‌های تفکر ۴۶.۴٪ کاهش یافتند در حالی که صحت مدل تقریباً ثابت ماند (۷۹.۷۵٪ به ۷۹.۷۱٪).
• زمینه متنی طولانی: در یک نتیجه غیرمنتظره، صحت مدل در AA-LCR حدود ۲.۲۵ درصد افزایش یافت (۸۱.۷۵٪ به ۸۴.۰۰٪) در حالی که ۳۸.۶٪ توکن کمتری مصرف کرد.
• ریاضیات: بیشترین افت کیفیت در AIME 2026 رخ داد؛ جایی که صحت مدل برای دستیابی به ۳۰.۲٪ کاهش توکن، ۳.۸۵ درصد افت کرد (۹۸.۱۳٪ به ۹۴.۲۷٪).
• وظایف عامل‌محور: نتایج نزدیک به مدل پایه بود. در $\tau^2$-bench کاهش ۳۰.۹ درصدی توکن‌ها با افت ۱.۰۱ درصدی صحت همراه بود. در Terminal-Bench 2.1، مدل ۰.۵۶ درصد صحت از دست داد (که در بازه خطای $\pm 4.26$ قرار دارد) تا به کاهش ۱۰.۷ درصدی توکن‌ها برسد. همچنین در LiveCodeBench v6، صحت مدل ۰.۰۷ درصد افزایش یافت در حالی که ۲۰.۳٪ کمتر فکر می‌کرد.

بودجه محاسباتی و دینامیک تلاش

گزارش‌های BottleCap یک منحنی بودجه را نشان می‌دهد که ثابت می‌کند در صورت اعمال سقف ۱۶ هزار توکن برای هر پاسخ، مدل ThinkingCap در واقع امتیاز بیشتری نسبت به مدل پایه کسب می‌کند. در این حالت، ردپاهای قطع شده (Truncated traces) از ۰.۵۱٪ به ۰.۳۴٪ و نرخ تکرار (Looping) از ۰.۰۶٪ به ۰.۰۵٪ کاهش یافته است.

این مدل همچنین با تنظیمات «میزان تلاش استدلال» (Reasoning-effort dial) در Qwen3.8-27B تعامل دارد. در تنظیمات 'medium'، مدل ThinkingCap حدود ۶۰.۲٪ از توکن‌های تفکر را حذف می‌کند که منجر به افت ۹.۹۰ درصدی صحت می‌شود (در مقایسه با مدل پایه که ۵۲.۱٪ کاهش توکن و ۹.۱۶٪ افت صحت داشت). در حالت 'low'، کاهش توکن‌ها به ۶۲.۳٪ می‌رسد و افت صحت ۱۰.۷۹٪ است. در صورتی که تفکر به‌طور کامل خاموش شود، ThinkingCap حدود ۵.۷ درصد از مدل پایه عقب می‌ماند.

استقرار و مشخصات فنی

هر دو مدل روی یک پردازنده NVIDIA H200 با استفاده از vLLM 0.29.0 ارزیابی شدند. تنظیمات نمونه‌برداری یکسان بود: دما ۱.۰، top_p ۰.۹۵، top_k ۲۰ و min_p ۰.۰. همچنین استفاده از رمزگشایی گمانه‌زن MTP (با ۳ توکن پیش‌نویس) در AIME 2026 تأثیری بر دقت نداشت و ۵۳٪ از توکن‌های پیش‌نویس پذیرفته شدند.

مدل ThinkingCap یک جایگزین مستقیم (Drop-in replacement) برای Qwen3.8-27B در vLLM یا SGLang است. نسخه bf16 دارای ۲۸ میلیارد پارامتر است و ورودی‌های متنی و تصویری را می‌پذیرد. برای استقرار، فرمت‌های مختلف کوانتیزاسیون (Quantization) ارائه شده است:

• FP8 (۳۱ گیگابایت): بهینه برای GPUهای Hopper و Blackwell.
• NVFP4 Weight-only (۲۱ گیگابایت): مخصوص Hopper (هسته Marlin) و Blackwell.
• NVFP4 W4A4 AWQ (۲۳ گیگابایت): فقط برای Blackwell.
• GGUF (۱۶ تا ۵۵ گیگابایت): سازگار با llama.cpp، LM Studio و Ollama.
• MLX 4-bit DWQ (۲۱ گیگابایت): مخصوص مک‌های اپل با ۳۲ گیگابایت رم.

برای کسانی که از تنظیمات میزان تلاش استدلال استفاده می‌کنند، BottleCap حالت 'xhigh' را برای بهترین تعادل بین دقت و تعداد توکن توصیه می‌کند. برای سرویس‌دهی، از دستور --reasoning-parser qwen3 به همراه ابزار qwen3_xml در vLLM استفاده شود تا توکن‌های تفکر در یک فیلد جداگانه بازگردانده شوند.

این تحول نشان می‌دهد که مرز بعدی مدل‌های استدلالی، «بیشتر فکر کردن» نیست، بلکه «هوشمندتر فکر کردن» است. وقتی نزدیک به ۴۰٪ از توکن‌های استدلال عملاً نویز هستند، فرض قدیمی که «ردپاهای طولانی‌تر برابر با منطق بهتر است» به چالش کشیده می‌شود. برای توسعه‌دهندگان، این به معنای هزینه‌های استنتاج کمتر و کاهش زمان رسیدن به اولین توکن (TTFT) بدون قربانی کردن هوش هسته معماری Qwen است. این رویکرد بهینه‌سازی در سایر مدل‌های چندوجهی خانواده Qwen نیز دیده شده است، جایی که مدل Qwen3.8-Omni-Flash توانست مصرف توکن‌های ویدیو را ۴۵.۷٪ کاهش دهد.

این مدل تحت مجوز PolyForm Small Business 1.0.0 به همراه گرنت استفاده شخصی BottleCap در دسترس است، در حالی که متریال‌های بالادستی Qwen تحت Apache-2.0 باقی می‌مانند. استفاده تجاری فراتر از مجوز کسب‌وکارهای کوچک، نیازمند توافق‌نامه با BottleCap است.

گام بعدی شما

• اگر از مدل‌های Qwen برای وظایف استدلالی استفاده می‌کنید، نسخه ThinkingCap را برای کاهش هزینه استنتاج (Inference) تست کنید.
• برای دستیابی به بهترین تعادل بین دقت و تعداد توکن، تنظیمات reasoning-effort را روی حالت 'xhigh' قرار دهید.
• در محیط vLLM از پارامتر --reasoning-parser qwen3 برای جداسازی توکن‌های تفکر از پاسخ نهایی استفاده کنید.

اما تأثیر این بهینه‌سازی بر سخت‌افزارهای لبه حتی حیاتی‌تر است — به تحلیل ما درباره‌ی تراشه‌های NPU مراجعه کنید.