تصور کنید می‌خواهید یک دستیار هوشمند کامل داشته باشید که هم عکس بکشد و هم تحلیل متن کند، اما تنها دارایی شما یک لپ‌تاپ قدیمی با گرافیک ضعیف است. اگر تا امروز فکر می‌کردید اجرای مدل‌های پیشرفته محلی فقط مخصوص کسانی است که کارت‌های گرافیکی گران‌قیمت دارند، باید بدانید که مدیریت هوشمند حافظه می‌تواند جایگزین سخت‌افزار گران شود.
بر اساس گزارش منتشر شده در dev.to، یک توسعه‌دهنده تا تاریخ ۱ آگیست ۲۰۲۶ ثابت کرد که یک GPU مدل NVIDIA RTX 3050 با تنها ۴ گیگابایت حافظه ویدیویی (VRAM)، می‌تواند یک پشته (Stack) کامل و خصوصی از هوش مصنوعی را پشتیبانی کند. این دستاورد از طریق «جابه‌جایی تهاجمی سخت‌افزار» به دست آمده است؛ یعنی سیستمی که به‌جای تلاش برای گنجاندن همه چیز در حافظه، آن‌ها را با سرعت بالا جابه‌جا می‌کند و از این طریق اجازه می‌دهد سخت‌افزاری که معمولاً تحت چنین بارهایی کرش می‌کند، پایدار بماند. این تلاش برای بهینه‌سازی استنتاج بر روی سخت‌افزارهای محدود، یادآور ابتکاراتی است که در پروژه متن‌باز ZML برای افزایش سرعت استنتاج در تراشه‌های متنوع دنبال شده بود تا وابستگی شدید به سخت‌افزارهای خاص کاهش یابد.
اکثر کاربران خانگی هنگام اجرای هوش مصنوعی محلی با یک دیوار سخت برخورد می‌کنند: محدودیت VRAM. اگر یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — را بارگذاری کنید، به‌ندرت جایی برای یک مدل انتشار (Diffusion Model) — که شبیه به نقاشی است که یاد گرفته چطور از میان نویز، تصاویر دقیق بسازد — باقی می‌ماند. این وضعیت کاربر را در یک انتخاب دوگانه بین متن و تصویر قرار می‌دهد. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه Claude Code چگونه از مکانیزم‌های ابزاری برای مدیریت عدم قطعیت استفاده می‌کند اشاره کردیم، این پروژه مشکل متفاوتی را حل می‌کند: بحران فیزیکی و اتمام منابع سخت‌افزاری.
جزئیات سخت‌افزاری و نرم‌افزاری
طبق مستندات این پروژه در dev.to، سخت‌افزار پایه شامل یک RTX 3050 (۴ گیگابایت VRAM) و ۱۶ گیگابایت رم سیستم است. این سیستم برای پاسخ به چندین نیاز هدفمند و مشخص در یک محیط خانگی طراحی شده است:
- استفاده همزمان: پشتیبانی از ۲ تا ۴ کاربر محلی که از طریق شبکه داخلی (LAN) به سیستم دسترسی دارند.
- تولید تصویر: ظرفیت عملیاتی برای تولید ۱۵ تا ۲۰ تصویر در هفته.
- زبان و داده: بهره‌گیری از قابلیت‌های چندزبانه و ادغام مستقیم با جست‌وجوی زنده وب.
- کاربردهای اصلی: کمک در برنامه‌ریزی دستور پخت غذا، برنامه‌ریزی سفر و انجام کارهای کدنویسی جزئی.
- بینایی: درک چندوجهی (Multimodal) — یعنی مدلی که هم متن و هم عکس را می‌فهمد، شبیه به انسان که با چندین حس دنیا را می‌خواند — و تحلیل تصاویر.
- حریم خصوصی: عملیات ۱۰۰٪ آفلاین با صفر وابستگی به ابر، بدون نیاز به اتصال اینترنتی برای پردازش و بدون پرداخت هزینه توکن.
این ساختار بر سه ستون اصلی استوار است:
۱. llama.cpp: برای مدیریت استنتاج (Inference) — یعنی لحظه‌ای که مدل واقعاً جواب تولید می‌کند. این بخش باید پیش از اجرای ارکستراتور راه‌اندازی شود.
۲. ComfyUI: مدیریت تولید تصویر در حالت --lowvram. این ابزار از طریق یک نصب ساده pip نصب شده است.
۳. SearXNG: یک کانتینر داکر خود-میزبان که جست‌وجوی خصوصی در وب را فراهم می‌کند. برای کارکرد صحیح، باید فرمت JSON در تنظیمات آن فعال باشد.
برای هماهنگی این‌ها، توسعه‌دهنده یک ارکستراتور پایتونی به نام chat-webui.py ساخت که از طریق Nginx میزبانی می‌شود. این تنظیمات اجازه می‌دهد ۲ تا ۴ کاربر به‌طور همزمان در شبکه داخلی به AI دسترسی داشته باشند، بدون اینکه داده‌های خود را با ارائه‌دهندگان ابری به اشتراک بگذارند یا هزینه‌ای بپردازند. این رویکرد در ساخت یک دستیار محلی و کاربرپسند، شباهت زیادی به استراتژی‌هایی دارد که دستیار Meetily با استفاده از زبان Rust برای دستیابی به کارایی بالا در پیش گرفت تا مورد استقبال گسترده توسعه‌دهندگان قرار گیرد.
انتخاب مدل برای محدودیت ۴ گیگابایتی
یافتن مدلی که در حافظه جای بگیرد و سرعت را فدا نکند، اولین و سخت‌ترین مانع بود. توسعه‌دهنده چندین کاندید را طی چندین روز تست کرد تا تعادل مناسب بین استدلال و عملکرد را پیدا کند:
- Qwen3.5 9B: اگرچه کیفیت بسیار بالایی داشت، اما به‌دلیل نیاز به تقسیم بار بین CPU و GPU برای جای گرفتن در حافظه، بیش از حد کند بود.
- Qwen3 VL 4B: با سرعت‌های معقولی کار می‌کرد، اما زمان زیادی را صرف «استدلال» می‌کرد و در نتیجه چرخه‌های پردازشی را هدر می‌داد.
- Gemma4 E4B: عملکرد خوبی داشت، اما برای مکالمات سیال و روزمره بیش از حد کند بود.
- Gemma4 E2B IT: برنده نهایی. این مدل سرعتی کاربردی بین ۳۵ تا ۴۵ توکن (Token) — تکه‌های کوچک متن، شبیه برش‌های کیک — در ثانیه ارائه می‌دهد، پشتیبانی بومی از چندین زبان دارد و استدلال‌های پایه را با اطمینان انجام می‌دهد.
در بخش بصری، مدل‌های انتشار مختلفی برای تعادل بین دقت و مصرف VRAM آزمایش شدند:
- Realistic: بسیار سریع بود، اما دقت لازم را نداشت.
- SD 1.5: سرعت فوق‌العاده‌ای داشت، اما تصاویر تولید شده دقیق نبودند.
- SD 3.5: تصاویری تولید می‌کرد که دارای یک «حس مصنوعی» (Synthetic feel) متمایز بودند.
- Z-Image-Turbo: این مدل در بودجه VRAM جای می‌گیرد و تصاویر مناسبی تولید می‌کند. همچنین از جریان‌های تبدیل تصویر به تصویر (Img2Img) پشتیبانی می‌کند. برای مثال، توسعه‌دهنده توانست یک نقاشی سیاه و سفید از یک گربه را بکشد و با موفقیت آن را به رنگ قهوه‌ای و سفید تغییر دهد، هرچند که این قابلیت هنوز روی عکس‌های واقعی کاملاً بی‌نقص عمل نمی‌کند.
ماشین وضعیت VRAM
از آنجایی که GPU نمی‌تواند همزمان LLM و تولیدکننده تصویر را بدون کرش کردن نگه دارد، یک «ماشین وضعیت پویا» (Dynamic State Machine) برای مدیریت محدودیت ۴ گیگابایتی طراحی شده است. این یک راهکار مهندسی حیاتی است، زیرا استفاده مداوم از GPU در طول یک جلسه چت اغلب باعث می‌شود دستگاه از طراحی حرارتی (Thermal Design) خود فراتر رود.
وقتی کاربر درخواست تصویر می‌کند، ارکستراتور فراخوانی ابزار (Tool Call) را رهگیری می‌کند. سپس یک دستور «تخلیه» (Unload) به llama-server می‌فرستد تا VRAM گرافیک به‌طور کامل آزاد شود. زمانی که VRAM خالی شد، ComfyUI در حالت --lowvram جریان تولید تصویر را اجرا می‌کند. بلافاصله پس از اتمام، VRAM دوباره پاک‌سازی شده و LLM به‌طور خودکار در حافظه GPU بارگذاری می‌شود. در نهایت، LLM هرگونه تسک معلق را بررسی کرده و پاسخ نهایی را به کاربر بازمی‌گرداند.
سلامت سیستم و حلقه‌های حرارتی
استفاده مداوم از GPU در لپ‌تاپ‌ها اغلب فراتر از طراحی حرارتی آن‌هاست و منجر به شکست‌های ناگهانی سیستم، کرش‌های OOM (کمبود حافظه) و توقف‌های ناگهانی می‌شود. برای تبدیل این «دموی» آزمایشگاهی به یک سیستم آماده تولید برای ۲۴ ساعت در روز، دو مکانیسم مراقبتی ویژه پیاده‌سازی شد:
پایش حرارتی (Thermal Monitoring): یک دیمون (Daemon) در پس‌زمینه هر ۱۰ ثانیه دستور nvidia-smi را اجرا می‌کند. اگر دمای GPU به ۸۵ درجه سانتی‌گراد برسد، سیستم به‌اجبار تمام مدل‌های فعال را تخلیه می‌کند. مدل‌ها تا زمانی که دما به زیر ۶۵ درجه سانتی‌گراد نرسد، بارگذاری نمی‌شوند تا از آسیب‌های سخت‌افزاری جلوگیری شود.
تخلیه RAM (RAM Evacuation): استفاده از LLM باعث می‌شود رم سیستم به‌مرور زمان افزایش یابد که می‌تواند منجر به ری‌بوت کامل سیستم شود. برای حل این مشکل، سیستم مجموع مصرف رم را پایش می‌کند. اگر مصرف به ۹۵٪ برسد، تسک‌های در حال اجرا به‌طور ایمن دوباره در صف قرار می‌گیرند، تمام سرویس‌ها ری‌استارت شده و حافظه پاک‌سازی (Flush) می‌شود. در این هنگام، رابط کاربری (UI) یک پیام هشدار درباره سربار حرارتی یا بیش‌بار رم به کاربر نمایش می‌دهد.
مدیریت صف
برای جلوگیری از کرش در اثر درخواست‌های همزمان، سیستم از چندرشته‌ای (Multi-threading) برای استنتاج استفاده نمی‌کند. ابزارهای استانداردی مثل Ollama اغلب برای هر پرس‌وجو رشته‌های استنتاج جدیدی ایجاد می‌کنند، اما در سخت‌افزار ۴ گیگی، اگر یک درخواست تصویر با یک درخواست متن تداخل پیدا کند، سیستم فوراً کرش می‌کند. به‌جای آن، توسعه‌دهنده دو استخر (Pool) سخت‌گیرانه تعریف کرده است:
۱. _llm_pool (۱ Worker): استنتاج تک-LLM را اجباری می‌کند تا از تلاطم حافظه (Memory Thrashing) جلوگیری شود.
۲. _tool_pool (۲ Worker): فراخوانی‌های موازی ابزارهایی را مدیریت می‌کند که VRAM را تحت فشار قرار نمی‌دهند، مانند پرس‌وجوهای SearXNG یا ژیکودینگ معکوس از طریق Nominatim.
راه‌اندازی پشته
برای کسانی که قصد تکرار این تجربه را دارند، توالی راه‌اندازی نیازمند فلگ‌های خاصی برای مدیریت منابع است. llama-server باید با فعال‌سازی CUDA و با پارامترهای زیر شروع به کار کند:--host 0.0.0.0 --port 8081 --models-dir ~/local-ai-files/my-models/ --n-gpu-layers 99 --ctx-size 32768 -ctk q8_0 -ctv q8_0 -fa on
سپس ComfyUI باید از محیط مجازی خود با فلگ --lowvram اجرا شود. در نهایت، ارکستراتور chat-webui.py اجرا می‌شود تا تمام این سرویس‌ها را به هم متصل کند.
بهبودهای آینده
توسعه‌دهنده چندین فعالیت برنامه‌ریزی شده برای تکامل این پشته شناسایی کرده است؛ از جمله افزودن پشتیبانی از اپلیکیشن بومی اندروید، گسترش LLM به یک گردش‌کار عامل‌محور (Agentic Workflow)، ایجاد یک رابط صوتی فعال و ایجاد روشی امن برای اتصال به این AI خصوصی از طریق اینترنت.
این پروژه ثابت می‌کند که مانع اصلی در برابر AI خصوصی، صرفاً هزینه سخت‌افزار نیست، بلکه ارکستراسیون است. در حالی که کاربران سازمانی ممکن است GPUهای B300 را برای آموزش اجاره کنند، یک علاقه‌مند معمولی می‌تواند از طریق مدیریت دقیق منابع و جابه‌جایی وضعیت-محور (State-based swapping)، به کارایی دست یابد. این رویکرد، تمرکز را از «VRAM بیشتر» به «مدت‌زمان هوشمندانه‌تر حافظه» تغییر می‌دهد.
گام بعدی شما
- اگر کارت گرافیک مدل‌های قدیمی یا ارزان‌قیمت دارید، به جای خرید سخت‌افزار جدید، روی پیاده‌سازی «ماشین وضعیت» برای جابه‌جایی مدل‌ها تمرکز کنید.
- مدل‌های سری Gemma4 E2B را برای کاربردهای محلی با حافظه کم تست کنید.
- برای کاهش دمای GPU در اجرای محلی، از ابزارهای پایش لحظه‌ای مثل
nvidia-smiدر اسکریپت‌های خود استفاده نمایید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو