Janas در برابر llama.cpp؛ برتری استریم مستقیم وزن‌ها در سخت‌افزار معمولی

تصور کنید لپ‌تاپی با تنها ۳۲ گیگابایت رم، مدلی با حجم ۴۸.۴ گیگابایت را با سرعت ۳۷ توکن در ثانیه اجرا کند. این جهش عملکردی مدیون Janas است؛ موتور مدل‌های زبانی که توسط مائوریتزیو کامالری با زبان C نوشته شده و با دور زدن گلوگاه‌های حافظه، «خبره‌ها» را مستقیماً از SSD استریم می‌کند.

سال‌هاست که «دیوار حافظه» بزرگ‌ترین مانع برای هوش مصنوعی محلی بوده است. وقتی حجم یک مدل از رم موجود بیشتر می‌شود، سیستم‌عامل‌ها معمولاً به مکانیزم نقشه‌برداری حافظه (mmap) متکی می‌شوند. این رویکرد اغلب منجر به ایجاد یک «طوفان خطا» (Fault Storm) می‌شود؛ وضعیتی که در آن سیستم به‌طور کورکورانه صفحات داده را جابه‌جا (Swap) می‌کند و در نتیجه سرعت استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً پاسخ تولید می‌کند — تقریباً به صفر می‌رسد. این مشکل به‌ویژه برای مدل‌های ترکیب خبره‌ها (Mixture of Experts یا MoE) دردناک است، زیرا در این مدل‌ها برای تولید هر توکن، تنها به بخش کوچکی از کل پارامترها نیاز است.

طبق گزارشی که در ۱۳ اکتبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، Janas با تبدیل SSDهای NVMe به حافظه اصلی برای ذخیره وزن‌ها (به‌جای اینکه صرفاً یک پشتیبان کند برای رم باشد)، این مشکل را حل کرده است. این موتور از یک فرمت فایل اختصاصی به نام .jns و دستورات خواندن O_DIRECT استفاده می‌کند تا حافظه موقت هسته (Page Cache) را کاملاً دور بزند. این کار مانع از لرزش و تلاطم سیستم (Thrashing) می‌شود که در سایر اجراکننده‌های محلی رایج است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی مدل‌های بازمتن اشاره کردیم، مدیریت حافظه کلید دسترسی به مدل‌های بزرگ در سخت‌افزارهای مصرفی است.

زمینه: شکست نقشه‌برداری حافظه استاندارد

اکثر اجراکننده‌های محلی، از جمله لاماس‌سی‌پلاس‌پلاس (llama.cpp)، برای مدیریت فایل‌های حجیم از mmap استفاده می‌کنند. در این حالت، سیستم‌عامل تکه‌های مدل را بر حسب نیاز وارد رم می‌کند. اما وقتی «مجموعه کاری» (Working Set) از حافظه فیزیکی بیشتر شود، سیستم‌عامل شروع به حذف صفحاتی می‌کند که مدل دقیقاً لحظه‌ای بعد به آن‌ها نیاز خواهد داشت.

پژوهشگران این وضعیت را «طوفان خطا» می‌نامند. وقتی اندازه مدل به تقریباً دو برابر رم موجود برسد، رویکرد mmap معمولاً فرو می‌پاشد. در حالی که موتور استنتاج در انتظار دیسک متوقف شده است، سیستم‌عامل به‌طور کورکورانه صفحات حافظه را جابه‌جا می‌کند.

مدل‌های MoE این وضعیت را تشدید می‌کنند. یک مدل MoE شامل بلوک‌های «خبره» (Expert) مجزایی است که از نوع Feed-forward هستند. برای هر توکن داده شده، مدل ممکن است تنها از ۸ خبره از میان ۲۵۶ خبره موجود مسیر خود را عبور دهد. در این حالت، میلیاردها پارامتر بیکار می‌مانند. بنابراین، گلوگاه اصلی، حجم کل مدل نیست، بلکه سرعت خواندن خبره خاصی است که برای توکن فعلی مورد نیاز است.

زمینه: مزیت مدل‌های MoE

از آنجا که مدل‌های MoE در هر توکن تنها بخشی از وزن‌های خود را فعال می‌کنند، به‌طور منحصر‌به‌فردی برای استریم کردن مناسب هستند. چالش اصلی در اینجا، خواندن کل مدل نیست، بلکه خواندن «بخش درست» مدل با سرعتی است که برای هر توکن تولید شده کافی باشد. این رویکرد یادآور تلاش‌های مشابه در پروژه Colibrì است که اجرای مدل‌های ۱۵۰ میلیاردی را با بهینه‌سازی گلوگاه ذخیره‌سازی روی لپ‌تاپ‌ها ممکن ساخت.

Janas دقیقاً همین سازوکار را هدف قرار داده است. با نگاه به مدل به‌عنوان مجموعه‌ای از خبره‌ها روی دیسک (به‌جای یک بلوک یکپارچه و صلب در رم)، نیاز سخت‌افزاری را از «ظرفیت رم» به «پهنای باند SSD» تغییر می‌دهد.

سازوکار فنی

Janas برای حفظ توان عملیاتی بالا از چندین استراتژی خاص استفاده می‌کند:

• استریم خبره‌ها: وزن‌ها روی دیسک باقی می‌مانند و موتور هرگز کل مدل را بارگذاری نمی‌کند. خواندن وزن‌های خبره از طریق O_DIRECT انجام می‌شود تا حافظه موقت صفحه (Page Cache) دور زده شود و سیستم‌عامل هرگز وارد چرخه جابه‌جایی‌های بیهوده نشود.
• کش گرم (Hot Caching): موتور تشخیص می‌دهد کدام خبره‌ها به‌طور مکرر استفاده می‌شوند و آن‌ها را در یک حافظه کش در رم نگه می‌دارد. این سیستم در ابتدای اجرا، سخت‌افزار را اندازه می‌گیرد تا اندازه این کش‌ها و انتخاب‌های مربوط به رشته‌ها (Threads) را به‌طور خودکار تنظیم کند.
• برون‌سپاری به GPU یکپارچه: در دستگاه‌های دارای GPU داخلی، Janas از گرافیک برای پردازش پرامپت (Prompt Processing) استفاده می‌کند، زیرا موازی‌سازی در این مرحله بیشترین اثر را دارد، و سپس برای تولید توکن‌ها، وزن‌های خبره را استریم می‌کند. کاربران می‌توانند با دستور JANAS_GPU=0 حالت «فقط CPU» را اجبار کنند.
• پیش‌نویس گمانه‌زنانه (Speculative Drafting): یک بلوک کوچک، توکن‌های آینده را حدس می‌زند و سپس مدل بزرگ‌تر آن‌ها را در یک گذر واحد تایید می‌کند. در مدل Qwen3-Next-80B، این قابلیت سرعت نوشتن را از ۲۴ به ۳۷ توکن در ثانیه رساند؛ در حالی که متن تولید شده کاملاً یکسان باقی ماند اما سریع‌تر تولید شد.

جزئیات سخت‌افزاری و محیط تست

برای درک دقیق این اعداد، محیط تست بسیار حیاتی است. نویسنده از یک ماشین با سیستم‌عامل Debian 13 با مشخصات زیر استفاده کرده است:

• پردازنده: Intel Core Ultra 9 185H
• رم: ۳۲ گیگابایت DDR5
• حافظه: ۱ ترابایت NVMe SSD
• سرعت دیسک: سرعت خواندن تقریباً ۵.۷ گیگابایت بر ثانیه

عملکرد در بنچمارک‌ها

در آزمایش‌های انجام شده بین ۹ تا ۱۱ اکتبر ۲۰۲۶ روی ماشین مذکور، Janas برتری خیره‌کننده‌ای نسبت به llama.cpp (با کوانتش Q4_K_M) نشان داد. این اعداد بر اساس اندازه‌گیری‌های شخصی نویسنده است.

مدل‌های بزرگ‌تر از رم (Oversized):

• Qwen3-Next-80B (۴۸.۴ گیگابایت): در Janas سرعت خواندن ۶۲ توکن و سرعت نوشتن ۲۴ توکن در ثانیه (بدون پیش‌نویس) ثبت شد. در مقابل، llama.cpp تنها ۱۶ توکن در ثانیه خواندن و ۲.۸ توکن در ثانیه نوشتن را ثبت کرد که نشان‌دهنده بهبود تقریباً ۸.۵ برابری در سرعت نوشتن است. این دستاورد در راستای چشم‌اندازی است که در اجرای مدل POCKET-Darwin-180B روی لپ‌تاپ‌های معمولی نیز دنبال می‌شد تا مدل‌های غول‌پیکر در دسترس کاربران خانگی قرار گیرند.
• Qwen3-Coder-Next (۴۸.۴ گیگابایت): سرعت Janas به ۶۶ توکن در ثانیه برای خواندن و ۲۲ توکن در ثانیه برای نوشتن رسید، در حالی که رقیب تنها ۱۴ و ۲.۲ توکن در ثانیه ثبت کرد.

مدل‌های میان‌رده:

• Qwen3.6-35B-A3B (۲۲.۳ گیگابایت): سرعت Janas برابر با ۱۰۴ توکن در ثانیه برای خواندن و ۱۹ توکن در ثانیه برای نوشتن بود، در مقابل ۷۹ و ۱۲ توکن در ثانیه برای رقیب.
• Qwen3-30B-A3B (۱۸.۶ گیگابایت): سرعت Janas به ۱۳۵ توکن در ثانیه برای خواندن و ۳۲ توکن در ثانیه برای نوشتن رسید، در حالی که رقیب ۱۲۲ و ۱۵ توکن در ثانیه ثبت کرد.
• Gemma-4-26B-A4B-it (۱۸.۳ گیگابایت): سرعت Janas برابر با ۹۰ توکن در ثانیه برای خواندن و ۱۸ توکن در ثانیه برای نوشتن بود، در مقابل ۷۶ و ۱۲ توکن در ثانیه.

مدل‌های متراکم کوچک:

• Qwen3-0.6B: سرعت خواندن پرامپت در Janas برابر با ۹۳۹ توکن در ثانیه بود، در حالی که در llama.cpp این عدد ۶۷۰ توکن در ثانیه بود.

یک نکته بسیار مهم: برای مدل‌های 80B، ابزار llama.cpp نه‌تنها کند شد، بلکه عملاً از کار افتاد. نسخه استاندارد آن هنگام اتصال GPU با خطای کمبود حافظه مواجه شد، زیرا بک‌اند CPU وزن‌ها را برای بازبسته‌بندی (Repack) کپی می‌کند و بک‌اند Vulkan وزن‌های CPU را در بافرهایی کپی می‌کند که سیستم نمی‌تواند آن‌ها را بازپس گیرد. عدد ۲.۸ توکن در ثانیه تنها با یک بیلد خاص (بدون Repack) و فلگ‌های ویژه برای باقی ماندن خبره‌ها در فایل به دست آمد. در حالی که Janas به هیچ‌کدام از این تنظیمات خاص نیاز نداشت.

محدودیت‌های پیاده‌سازی

باید توجه داشت که Janas در حال حاضر یک پروژه آزمایشی است و نه یک محصول صیقل‌خورده. رابط خط فرمان (CLI) آن چندین بار در هفته تغییر کرده است و تنها فرمت فایل مدل .jns به عنوان یک استاندارد پایدار وعده داده شده است.

این ابزار نیازمند لینوکس (اوبونتو ۲۲.۰۴+، دبیان ۱۲+) یا ویندوز ۱۰ (نسخه ۱۹۰۳ به بعد) و ویندوز ۱۱ است. نویسنده گزارش می‌دهد که در ویندوز ۱۱، مدل‌های متراکم پرامپت‌ها را ۱.۸ برابر سریع‌تر می‌خوانند، زیرا بلوک‌های کامل از طریق درایور اختصاصی اینتل به GPU منتقل می‌شوند.

محدودیت‌های کلیدی عبارتند از:

• تست سخت‌افزاری: تمام توسعه‌ها روی یک لپ‌تاپ اینتل با GPU Arc یکپارچه انجام شده است. پردازنده‌های AMD، GPUهای مجزا (Discrete) و دیسک‌های کندتر به‌طور صریح تست نشده‌اند.
• شدت مصرف منابع: کش‌های کامل حافظه و خواندن‌های سریع O_DIRECT می‌تواند دستگاه‌هایی که فضای خالی کمی دارند را به سمت Swap بکشاند. نویسنده پیشنهاد می‌کند از فلگ --cache <GiB> برای تعیین یک سقف سخت برای مصرف حافظه استفاده کنید.
• در دسترس بودن مدل‌ها: کاربران باید از کاتالوگ Hugging Face نویسنده برای مدل‌های Qwen و Gemma استفاده کنند یا فایل‌های GGUF را به‌صورت دستی به .jns تبدیل کنند.
• تفاوت در پیش‌نویس‌ها: نرخ بقای پیش‌نویس‌های گمانه‌زنانه برای متون انگلیسی ۷۴ تا ۸۹ درصد بود، اما برای متون ایتالیایی به حدود یک‌سوم کاهش یافت. نویسنده اشاره کرد که نسخه قبلی این بنچمارک خوش‌بینانه و اشتباه بود و اکنون آن را اصلاح کرده است.

نحوه اجرا

برای کاربران لینوکس x86-64، سریع‌ترین راه از طریق README است:
curl -LO https://github.com/prabanta-dev/janas/releases/latest/download/janas-linux-x86_64.tar.gz
tar xf janas-linux-x86_64.tar.gz && cd janas
./janas-chat

سپس کاربران می‌توانند مدلی را از کاتالوگ برای دانلود و تایید خودکار انتخاب کنند. برای دریافت نتایج دقیق، نویسنده توصیه می‌کند ابتدا مرورگرها و ویرایشگرها را ببندید. در تست‌ها، باز بودن یک مرورگر و ویرایشگر باعث شد سرعت مدل به حدود سه-چهارم کاهش یابد و زمان انتظار دیسک ۵ برابر شود.

تغییر در پارادایم هوش مصنوعی محلی

این پیشرفت، تعریف «مدل‌های بیش از حد بزرگ برای اجرای محلی» را از ظرفیت رم به پهنای باند SSD تغییر می‌دهد. اگر یک درایو NVMe بتواند ۵ تا ۷ گیگابایت بر ثانیه داده جابه‌جا کند، پتانسیل این را دارد که وزن‌ها را سریع‌تر از آنکه ژنراتور آن‌ها را مصرف کند، استریم کند. این یعنی ارتقای سقف عملیاتی برای هوش مصنوعی محلی بسیار ارزان‌تر می‌شود، زیرا SSDها به‌مراتب مقرون‌به‌صرفه‌تر از ماژول‌های رم با ظرفیت بسیار بالا هستند. این رویکرد بهینه‌سازی منابع، مشابه فلسفه‌ی پژوهش CetinLM در آموزش مدل‌ها با سخت‌افزارهای محدود است که نشان می‌دهد محدودیت‌های سخت‌افزاری لزوماً مانع پیشرفت نیستند.

برای اکثر کاربران، llama.cpp به‌دلیل بلوغ و پایداری، همچنان انتخاب امن‌تری برای مدل‌هایی است که در رم جای می‌گیرند. اما برای کسانی که قصد اجرای مدل‌های 80B+ را روی سخت‌افزار خانگی دارند، Janas این مدل‌ها را از یک کنجکاوی تئوریک به ابزاری کاربردی تبدیل می‌کند.

اگر می‌خواهید این ادعاها را تست کنید، نویسنده ابزار janas-bench را برای اندازه‌گیری سخت‌افزار شما و تولید گزارش ارائه داده است. از آنجا که پروژه تنها روی یک لپ‌تاپ تست شده، ارسال این گزارش‌ها مفیدترین کمکی است که یک کاربر می‌تواند به این پروژه بکند.

گام بعدی شما

• اگر لپ‌تاپی با SSD سریع دارید، ابزار janas-bench را اجرا کنید تا ببینید سخت‌افزار شما چه مدل‌هایی را پشتیبانی می‌کند.
• مدل‌های Qwen3-Next-80B را از کاتالوگ Hugging Face نویسنده تست کنید تا تفاوت سرعت با llama.cpp را حس کنید.
• برای بهینه‌سازی مصرف رم در سیستم‌های ضعیف، حتماً از فلگ --cache استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.