‏اجرای مدل Dory1.0-4B انویدیا روی سیستم خودتون

انویدیا مدل Dory1.0-4B رو منتشر کرده؛ یه مدل open-weight با ۴ میلیارد پارامتر که ساختارش با transformerهای معمولی فرق داره. این مدل یه بلوک ورودی ۸ لایه، یه بلوک recurrent (یعنی دسته‌ای از لایه‌ها که چند بار پشت هم اجرا می‌شه) ۲۰ لایه و یه بلوک خروجی ۸ لایه داره. تعداد دفعاتی که بلوک وسط اجرا می‌شه اسمش loop count هست و می‌تونه ۱ تا ۴ باشه. تو مقاله اومده که این عدد رو موقع اجرا عوض می‌کنید، بدون retrain و بدون دانلود یه checkpoint دیگه.

طبق بنچمارک‌های خود انویدیا، روی SWE-bench Verified امتیاز با یه loop برابر ۵۰.۳ هست، با دو loop می‌رسه به ۵۹.۵ و با چهار loop به ۶۱.۸. روی Terminal-Bench 2.1 هم از ۱۲.۵ به ۱۸.۱ و بعد ۲۲.۲ می‌ره. بیشترین جهش بین یک و دو loop اتفاق می‌افته و بعدش سود کمتر می‌شه. برای همین انویدیا دو loop رو پیش‌فرض پیشنهاد می‌کنه، یه loop رو برای جاهایی که سرعت مهمه و چهار loop رو برای کارهای agentic و کدنویسی. نویسنده می‌گه چون loop بیشتر گاهی تعداد توکن‌های خروجی رو کم می‌کنه، بهتره هزینه و latency رو روی کار واقعی خودتون اندازه بگیرید.

یه مشکل مدل‌های loopدار، KV cache هست (یعنی حافظه‌ای که کلیدها و مقدارهای توکن‌های قبلی رو نگه می‌داره تا دوباره حساب نشن). تو حالت per_loop برای هر loop یه کش جدا ساخته می‌شه و حافظه با تعداد loop بالا می‌ره. تو حالت last_loop هر loop کش قبلی رو بازنویسی می‌کنه و حجم کش همیشه اندازه یه loop می‌مونه. به گفته انویدیا دقت این حالت به per_loop نزدیکه، یعنی اگه VRAM کمی دارید یا context طولانی‌تر و درخواست همزمان بیشتر می‌خواید، last_loop گزینه بهتریه.

پشتیبانی vLLM هنوز تو نسخه رسمی نیومده و باید از pull request شماره 60149 نصبش کنید. این دو تنظیم اصلی داخل --hf-overrides قرار می‌گیرن:

vllm serve --model nvidia/NVIDIA-Nemotron-Labs-Dory1.0-4B-BF16 \
    --hf-overrides '{"n_recurrent_loops": 2, "recurrent_kv_cache_mode": "per_loop"}' \
    --max-model-len 262144

برای llama.cpp هم یه pull request (شماره 30306) هست و راهنمای رسمی یه commit مشخص رو pin می‌کنه تا نتیجه قابل تکرار باشه. اینجا باید فایل GGUF با کوانتیزه‌سازی Q5_K_M رو دانلود کنید که حدود ۳.۶۷ گیگابایته، و تنظیمات loop و کش رو با --override-kv و کلیدهای dory.num_loops و dory.recurrent_kv_cache_mode بدید. نویسنده یادآوری می‌کنه که بنچمارک‌ها روی نسخه BF16 گرفته شدن و نسخه کوانتیزه یه کم افت دقت داره. سرور llama.cpp هم به‌صورت پیش‌فرض بدون احراز هویته، پس پورتش رو روی اینترنت باز نذارید.

تو مقایسه با Qwen3.5-4B، این مدل روی SWE-bench Verified (۶۱.۸ در برابر ۵۴.۷)، Terminal-Bench 2.1، IFBench و AA-LCR جلوتره، ولی روی دانش عمومی و بعضی بنچمارک‌های استدلال مثل GPQA Diamond و HLE عقب‌تره. نویسنده معتقده نقطه قوتش قوی‌ترین بودن نیست؛ اینه که با یه checkpoint می‌شه میزان محاسبه رو برای هر کار کم و زیاد کرد، بدون اینکه حافظه بیشتری خرج بشه.

نکات کلیدی:

• ساختار مدل: ۸ لایه ورودی، ۲۰ لایه recurrent تکرارشونده و ۸ لایه خروجی
• loop count بین ۱ تا ۴ قابل تنظیمه و دو loop پیش‌فرض پیشنهادی انویدیاست
• SWE-bench Verified: ۵۰.۳ با یه loop، ۵۹.۵ با دو loop، ۶۱.۸ با چهار loop
• حالت کش last_loop مصرف حافظه رو در اندازه یه loop ثابت نگه می‌داره
• پشتیبانی vLLM و llama.cpp فعلاً فقط از طریق pull requestهای 60149 و 30306 هست
• فرمت‌های موجود: BF16، MXFP8، NVFP4 و Q5_K_M (GGUF)، با context تا ۲۵۶ هزار توکن