Colibrì: اجرای مدل ۱۵۰ میلیاردی روی لپ‌تاپ با ۶٪ گلوگاه ذخیره‌سازی

۱.۱۱ توکن در ثانیه؛ این سرعتِ اجرای مدل ۱۵۰ میلیاردی DeepSeek V4 Flash روی یک لپ‌تاپ مهندسی معمولی است. طبق گزارشی که در ۱۶ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این دستاورد ثابت می‌کند که مدل‌های با وزن‌های باز (Open Weights) در مقیاس پیشرو، دیگر برای ارزیابی اولیه به سخت‌افزارهای گران‌قیمت اجاره‌ای وابسته نیستند.

سال‌هاست که در دنیای مهندسی هوش مصنوعی، این باور وجود داشت که سرعت حافظه ذخیره‌سازی یا همان «دیوار دیسک»، اجرای مدل‌های عظیم روی لپ‌تاپ را غیرممکن می‌کند. فرض بر این بود که چون یک مدل ۱۵۰ میلیاردی در رم سیستم جا نمی‌شود، زمان استریم کردن وزن‌ها از SSD باعث کندی شدید سیستم می‌شود. تصور می‌شد بخش‌هایی از مدل که در لحظه استفاده نمی‌شوند باید از دیسک خوانده شوند و همین دیسک تبدیل به یک سد عبورناپذیر شود.

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی مدل‌های محلی اشاره کردیم، مدیریت حافظه کلید اصلی است. تصور کنید مدل مانند کتابخانه‌ای عظیم است که شما برای پاسخ به یک سوال، فقط به سه یا چهار کتاب خاص نیاز دارید. به‌جای اینکه سعی کنید کل کتابخانه را روی میز کارتان (RAM) جای دهید، فقط فهرست را روی میز می‌گذارید و کتاب‌های مورد نیاز را از قفسه‌ها (SSD) می‌گیرید. این منطق اصلی Colibrì است؛ موتور استنتاجی با مجوز Apache-2.0 که توسط Vincenzo Fornaro ساخته شده است. این رویکرد در واقع پاسخی به چالش‌های محاسبه دقیق حافظه مورد نیاز برای مدل‌های محلی است که در سخت‌افزارهای سال ۲۰۲۶ اهمیت دوچندانی یافته است.

سازوکار Colibrì

Colibrì حافظه VRAM، رم و فضای ذخیره‌سازی را به عنوان یک سلسله‌مراتب واحد می‌بیند. این موتور، اجرای مدل‌های بزرگ را به یک مسئله «جای‌گذاری» تبدیل می‌کند (Fornaro, 2026a). بخش‌های متراکم شبکه را در حافظه نگه می‌دارد و خبره‌های مسیریابی‌شده را روی دیسک ذخیره می‌کند. وقتی مسیریاب مدل، خبره‌های خاصی را برای یک توکن انتخاب می‌کند، موتور فقط بایت‌های مورد نیاز را از درایو می‌خواند.

برای بهینه‌سازی این فرآیند، استراتژی‌های زیر به کار گرفته شده است:

• مرحله‌بندی سلسله‌مراتبی: شبکه متراکم در رم می‌ماند و خبره‌ها روی دیسک.
• کشینگ هوشمند: یک حافظه موقت (Cache) برای هر لایه ایجاد می‌کند، ثبت می‌کند که بار کاری به کدام خبره‌ها مسیریابی می‌شود و خبره‌های «داغ» یا پرکاربرد را در رم تثبیت (Pin) می‌کند.
• پیاده‌سازی سبک: موتور از یک فایل C برای هر خانواده مدل تشکیل شده و در زمان اجرا از هیچ کتابخانه BLAS یا زبان پایتون استفاده نمی‌کند. این کد با gcc 13.3.0 و فلگ‌های -O3 -march=native -fopenmp -flto کامپایل شده است. فلگ -march=native روی پردازنده‌های Zen 5 حیاتی است، زیرا تفاوت بین اندازه‌گیری واقعی بار کاری و اندازه‌گیری عملکرد کامپایلر است.
• دامنه گسترده: این پروژه پژوهش‌محور است و موضوعاتی چون فرمت‌های مدل، سلسله‌مراتب حافظه، ورودی/خروجی ذخیره‌سازی، جای‌گذاری، زمان‌بندی، کرنل‌ها، گمانه‌زنی (Speculation) و هم‌پوشانی CPU/GPU را پوشش می‌دهد. این موتور حتی یک پیکربندی کاملاً مقیم (Fully-resident) را ارائه می‌دهد که در آن دیسک به‌طور کامل از مسیر رمزگشایی حذف می‌شود.

مشخصات سخت‌افزاری و مدل

تست‌ها روی یک لپ‌تاپ مهندسی مدل ۲۰۲۶ با پردازنده AMD Ryzen AI 9 365 (۲۰ هسته منطقی)، ۶۱ گیگابایت رم و درایو WD Blue SN5100 1 TB NVMe تحت اوبونتو ۲۴.۰۴ انجام شد. برای حذف متغیرهای شتاب‌دهنده، از GPU داخلی Radeon 880M استفاده نشد.

دو جزئیات سخت‌افزاری قابل توجه وجود دارد: اول اینکه CPU ترکیبی از هسته‌های Performance و Compact را با کلاک‌های پایدار متفاوت اجرا می‌کند. دوم اینکه شاسی لپ‌تاپ محدودیت توان پایدار کمتری نسبت به یک دسکتاپ دارد. هر دو مورد می‌توانند زمان CPU را به ازای هر واحد کار افزایش دهند، هرچند هیچ‌کدام به‌طور مستقیم اندازه‌گیری نشدند.

مدل مورد استفاده، نسخه‌ای از DeepSeek V4 Flash بود که با روش REAP هرس شده و توسط puwaer منتشر شده است و ۸۴.۷ گیگابایت فضای دیسک اشغال می‌کند.

جزئیات مدل:

• تعداد پارامترها: ۱۵۰,۱۲۸,۵۴۹,۱۱۱ پارامتر.
• معماری: ۴۳ لایه با ۱۳۲ خبره؛ برای هر توکن ۶ خبره انتخاب می‌شوند.
• دقت: خبره‌های مسیریابی‌شده در حالت بومی fp4 هستند که اجازه می‌دهد Colibrì بدون نیاز به مرحله تبدیل، مستقیماً نقطه بازرسی (Checkpoint) را بخواند.
• فشرده‌سازی: روش REAP یک متد هرس خبره‌ها است (Lasby et al., 2025) که گزارش می‌دهد حتی با حذف ۵۰٪ خبره‌ها در مدل‌هایی از ۲۰ میلیارد تا ۱ تریلیون پارامتر، فشرده‌سازی در تولید کد تقریباً بدون افت کیفیت (Near-lossless) است.

اندازه‌گیری «دیوار دیسک»

برای اینکه مشخص شود آیا حافظه واقعاً عامل محدودکننده است، پژوهشگر ابتدا درایو را تست کرد. موتور Colibrì بدون اندازه‌گیری ذخیره‌سازی از برنامه‌ریزی امتناع می‌کند. با ابزار سفارشی iobench و حالت O_DIRECT سرعت NVMe در یک رشته ۵.۶۷ گیگابایت بر ثانیه، در چهار رشته ۶.۱۷ گیگابایت بر ثانیه و در ۱۶ رشته ۵.۷۲ گیگابایت بر ثانیه بود. خواندن‌های با بافر (Buffered reads) در چهار رشته به ۷.۴۳ گیگابایت بر ثانیه رسید، هرچند این عدد به دلیل Page Cache روی فایلی که دقایق قبل نوشته شده بود، بیش از حد واقعی بود.

برای هر پیکربندی تنها یک اجرا انجام شد و واریانسی گزارش نشد. پراکندگی ۸ درصدی در تعداد رشته‌ها یک نتیجه محسوب نمی‌شود، زیرا یک خواندن ۱۳ مگابایتی اپلیکیشن پیش از رسیدن به درایو، به درخواست‌های متعدد در سطح دستگاه تقسیم می‌شود.

برای مقایسه، در مستندات GLM-5.3-Flash موتور Colibrì، سرعت درایو مرجع در عمق صف ۱ تنها ۷۲ مگابایت بر ثانیه بود و در نزدیکی ۲۰۰ مگابایت بر ثانیه اشباع می‌شد، که باعث می‌شد کفِ زمان هر توکن ۲۴ ثانیه باشد (Fornaro, 2026b). یک NVMe مصرفی در سال ۲۰۲۶ حدود ۸۰ برابر سریع‌تر است و ثابت می‌کند «دیوار دیسک» ویژگیِ سخت‌افزار است، نه تکنیک استنتاج.

در یک اجرای سه دقیقه‌ای برای تولید ۲۰۰ توکن، درایو کمتر از ۱۱ ثانیه در حال خواندن داده بود. طبق داده‌ها، I/O فیزیکی مربوط به خطاهای کش ۶۰.۶ گیگابایت بود (محاسبه شده از ۶,۵۹۷ خطا با میانگین ۹.۱۹ مگابایت برای هر خواندن). عدد بزرگتر ۸۸.۲ گیگابایت که در v4_tokens گزارش شده، به هیچ اندازه معقولی برای هر خواندن تقسیم نمی‌شود و به عنوان یک حسابداری مجزا در نظر گرفته شده است.

در درایوی با سرعت ۵.۶۷ گیگابایت بر ثانیه، این یعنی از ۱۸۰ ثانیه کل زمان اجرا، تنها ۱۰.۷ ثانیه صرف دسترسی به سخت‌افزار شده است. اگر حافظه ذخیره‌سازی بی‌نهایت سریع بود، سرعت از ۱.۱۱ به ۱.۱۸ توکن در ثانیه می‌رسید؛ یعنی تنها ۶٪ بهبود جزئی.

هزینه پنهان خطاهای حافظه موقت

اگرچه دیسک سد راه نیست، اما رم همچنان حیاتی است. برنامه‌ریز موتور برای این اجرا از بودجه ۳۹.۶ گیگابایت رم استفاده کرد (۸.۸ گیگابایت برای بخش متراکم، ۵.۹ گیگابایت برای زمان اجرا و ۲۴.۹ گیگابایت برای خبره‌های گرم). برنامه‌ریز پیش‌بینی کرد که ۳۳٪ از خبره‌ها مقیم رم باشند و خطاهای دیسک را به عنوان محدودیت مورد انتظار شناسایی کرد. رمزگشایی گمانه‌زن (Speculative decoding) غیرفعال شد زیرا پیش‌نویس زدن، مجموعه خبره‌های مورد نیاز یک توکن را گسترش می‌دهد، اما هم‌پوشانی خواندن و محاسبه فعال شد.

یک مرحله خود-تنظیم (Self-tuning) روی یازده کاندید — شامل اندازه تیم OMP، تعداد رشته‌های لودر و کش‌های رم — آزمایش شد، اما هیچ‌کدام از سد بهبود ۳ درصدی عبور نکردند و تنظیمات پیش‌فرض حفظ شدند.

وقتی پژوهشگر صراحتاً بودجه کش رم را به ۲۰ گیگابایت کاهش داد و کش صفحه را پاک کرد (sync; sysctl -w vm.drop_caches=3)، توان عملیاتی ۱۵٪ افت کرد (از ۱.۰۴۵ به ۰.۸۸۵ توکن در ثانیه).

نکته جالب این است که هزینه یک «خطای کش» (Cache Miss) فقط زمان خواندن از دیسک نیست، بلکه به اندازه همان زمان، سیکل‌های CPU را هم می‌بلعد. تحلیل‌ها نشان می‌دهد یک خطای کش تقریباً به اندازه I/O دیسک، هزینه سیکل CPU دارد:

• افزایش زمان رمزگشایی: ۳۴.۷ ثانیه کندتر.
• افزایش زمان دستگاه: ۱۶.۹ ثانیه (به دلیل خواندن ۹۶ گیگابایت بیشتر).
• افزایش CPU کاربر: ۳۲۹ ثانیه (تقریباً ۱۹ ثانیه زمان واقعی در ۱۷ رشته).

CPU باید خبره fp4 را از حالت کوانتیده خارج کند، آن را در جای درست کپی کند، داده‌های قدیمی را حذف کند و دفترچه حسابداری را به‌روز کند. بنابراین، افزایش رم فقط خواندن از دیسک را کم نمی‌کند، بلکه «مالیات پردازشی» مدیریت این خواندن‌ها را هم کاهش می‌دهد. حدود نیمی از مزیت حافظه بیشتر، به صورت سیکل‌های CPU است که دیگر مجبور به صرف آن‌ها نیستید.

واقعیت‌های عملکردی

با وجود این پیشرفت در دسترسی، سرعت برای استفاده تعاملی همچنان پایین است. تولید یک پاسخ ۶۰۰ کلمه‌ای حدود ۱۰ دقیقه زمان می‌برد. اما برای کارهای مهندسی خاص، این سرعت کافی است:

• بررسی رعایت استایل نوشتاری در اسناد طولانی.
• تست حلقه‌های فراخوانی ابزار بدون ارسال داده به APIهای خارجی.
• ارزیابی کیفیت خروجی روی داده‌های محرمانه و محلی.

یک مشاهده مهم این بود که مرحله پیش‌پُرکردن (Prefill) — یعنی پردازش پرامپت اولیه — کندتر از رمزگشایی بود. ۱۷.۲ ثانیه برای ۱۷ توکن پرامپت برابر با ۱.۰۱ ثانیه در توکن است، در حالی که در رمزگشایی این عدد ۰.۹۰ است. این احتمالاً به دلیل «جاروب سرد» است؛ جایی که موتور برای اولین بار باید بخش بزرگی از خبره‌ها را لمس کند و در این لحظه، زمان تا نخستین توکن بیشتر به سرعت دیسک وابسته است.

سایر مشاهدات فنی عبارتند از:

• استفاده از خبره‌ها: یک پرامپت کوتاه در ۲۰۰ توکن، ۴,۲۱۶ خبره متمایز از مجموع ۵,۶۷۶ خبره را لمس کرد. این نشان می‌دهد بار کاری از گوشه کوچکی از شبکه استفاده نمی‌کند.
• نرخ命中 (Hit Rate): این اجرا نرخ命中 ۸۷.۶٪ را ثبت کرد (۴۶,۶۶۵命中 در مقابل ۶,۵۹۷ خطا)، که به طور قابل توجهی بالاتر از پیش‌بینی ۳۳ درصدی برنامه‌ریز بود. این شکاف ممکن است به دلیل یک مسیریاب منحرف (Skewed router) باشد تا تثبیت یادگرفته شده.
• رفتار CPU: تست با OMP_WAIT_POLICY=passive تغییر قابل توجهی در زمان رمزگشایی ایجاد نکرد (۱۹۱.۷ ثانیه در مقابل ۱۹۱.۲ ثانیه)، که باعث شد احتمال spin-waiting در GNU OpenMP به عنوان علت مصرف بالای CPU رد شود. با این حال، رشته‌های لودر موتور از همگام‌سازی مجزایی استفاده می‌کنند که این سیاست روی آن‌ها اثر نمی‌گذارد.

تغییر روایت سخت‌افزاری

این آزمایش استدلال اجاره GPUهای گران‌قیمت برای ارزیابی اولیه مدل‌ها را تغییر می‌دهد. اگر یک مدل ۱۵۰ میلیاردی روی لپ‌تاپ اجرا می‌شود، مانع ورود برای تست محلی عملاً از بین رفته است. موازنه دیگر روی «امکان اجرا» نیست، بلکه روی «میزان صبر کاربر» است. این تغییر رویکرد، هزینه‌های بلندمدت استنتاج مدل‌های زبانی را در مقایسه با استقرار ابری به شدت کاهش می‌دهد و استقلال مهندسان را افزایش می‌دهد.

برای کسانی که به دنبال بازتولید این نتایج هستند، پژوهشگر اشاره می‌کند که هر درایو NVMe فعلی کافی است. متغیر واقعی، رم است. نردبان منتشر شده برای GLM-5.2 (۷۴۴ میلیاردی) این را نشان می‌دهد: این مدل روی شش RTX 5090 با سرعت ۶.۸ توکن در ثانیه (مقیم کامل)، روی یک دسکتاپ فقط-CPU با ۱۲۸ گیگابایت رم با سرعت ۱.۸، و روی یک ماشین ۲۵ گیگابایتی در حالت خواندن سرد به ۰.۰۵-۰.۱ توکن در ثانیه می‌رسد. دسکتاپ ۱۲۸ گیگابایتی ۶۲٪ سریع‌تر از لپ‌تاپ است و حافظه تفاوت آشکار است.

وقتی ماشین حافظه کافی برای نگه داشتن کل مدل (۸۴.۷ گیگابایت برای این نسخه) داشته باشد، تمام مکانیسم‌های استریم و هزینه‌های CPU مرتبط با آن کاملاً حذف می‌شوند. زیر این خط، شما در حال مبارزه با کش هستید و بالای این خط، مکانیسم استریم بی‌اهمیت می‌شود.

اگر بین خرید SSD سریع‌تر یا رم بیشتر برای ایستگاه کاری هوش مصنوعی مردد هستید، داده‌ها نشان می‌دهند که رم تنها گزینه‌ای است که سوزن سرعت را به طور معناداری جابه‌جا می‌کند. تحلیل‌های ما درباره ظرفیت رم و کوانتش نیز تایید می‌کند که در مدل‌های محلی، مقدار رم تعیین‌کننده نهایی نوع مدل‌های قابل اجراست. حساب‌وکتاب قابلیت اجرا ساده است: مجموعه متراکم باید مقیم باشد، کش خبره‌ها حافظه باقی‌مانده را می‌گیرد و دیسک باید کل نقطه بازرسی را نگه دارد. این مدل به ۶.۲ گیگابایت حافظه مقیم و ۸۵ گیگابایت فضای دیسک نیاز داشت. روی یک ماشین ۳۲ گیگابایتی، فضای بسیار کمی برای کش باقی می‌ماند که اجرا را احتمالاً دردناک اما غیرممکن نمی‌کند.

ملاحظات نهایی

باید توجه داشت که این نتایج از یک ماشین، یک مدل و یک پرامپت به دست آمده است. در حالی که واریانس بین اجراها کم بود (۰.۲٪)، این یک مجموعه محک (Benchmark) جامع نیست. زمان CPU مشاهده شده کار واقعی است، اما ممکن است ویژگیِ کرنل‌های دست‌نویس Colibrì باشد تا خودِ بار کاری. بدون شمارش دستورالعمل‌ها یا ردهای I/O در سطح دستگاه، مقصد دقیق زمان CPU بر اساس تفاوت بین اجراها تخمین زده شده است.

با این حال، نتیجه برای مهندسان روشن است: ارزیابی محلی اکنون رایگان است. هرچند لپ‌تاپ نمی‌تواند ایزولاسیون، ردپاهای حسابرسی (Audit trails) یا هم‌روندی محیط‌های مدیریت‌شده مانند Sakura Sky را فراهم کند، اما بهانه نبود تست پیش از استقرار را از بین می‌برد. برای بازتولید این نتیجه، موتور Colibrì از گیت‌هاب و نقطه بازرسی puwaer/DeepSeek-V4-Flash-0731-reap-150b از Hugging Face مورد نیاز است. فرآیند ساخت، دانلود و اجرا را می‌توان در یک بعدازظهر به پایان رساند.

گام بعدی شما

• اگر توسعه‌دهنده هستید، موتور Colibrì را روی ماشین خود نصب کنید تا مدل‌های عظیم را بدون هزینه API تست کنید.
• در خرید سخت‌افزار آینده، اولویت را به افزایش ظرفیت RAM بدهید تا هزینه پردازشی مدیریت کش کاهش یابد.
• مدل‌های هرس‌شده (Pruned) را برای کاربردهای محلی دنبال کنید تا تعادل بهتری بین دقت و سرعت به دست آورید.

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