اگر تصور می‌کنید برای اجرای محلی هوش مصنوعی به ۲۴ گیگابایت حافظه ویدیویی (VRAM) نیاز دارید، احتمالاً بودجه‌ی سخت‌افزاری خود را هدر می‌دهید. واقعیت این است که یک کارت گرافیک ۸ گیگابایتی برای بازبینی (Review) باکیفیت کد کاملاً کفایت می‌کند. طبق یک تحلیل عملی که در تاریخ ۳۰ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این تفاوت در سخت‌افزاری مورد نیاز، ریشه در یک تفاوت بنیادی دارد: تفاوت میان «تولید کد» و «بازبینی کد».
تولید کد نیازمند این است که مدل بتواند کل ساختار یک اپلیکیشن را از صفر طراحی و پیاده‌سازی کند. اما بازبینی، در واقع خواندن کد موجود و استدلال درباره‌ی خطاهای احتمالی است. این تغییر در ماهیت تسک به این معناست که کاربران می‌توانند به‌جای سرعت خام تولید خروجی، اولویت خود را بر «پنجره‌ی زمینه» (Context Window) قرار دهند. همان‌طور که در منبع ذکر شده است، بازبینی‌ای که ۹۰ ثانیه زمان می‌برد، همچنان به‌طور قابل‌توجهی سریع‌تر از این است که منتظر بمانید تا یک بازبین انسانی در روز بعد به Pull Request شما رسیدگی کند.
تفاوت این دو کار را شبیه تفاوت بین نوشتن یک رمان و ویرایش آن بدانید. یک ویراستار نیازی ندارد به سرعت یک ماشین‌تایپ باشد، اما باید بتواند نکته‌ای از فصل اول را هنگام خواندن فصل دهم به‌خوبی به یاد داشته باشد. در اصطلاحات هوش مصنوعی، این دقیقاً همان جدال میان «وزن‌های مدل» و «حافظه موقت کلید-مقدار» (KV cache) برای تصاحب VRAM است. مدلی که توابع زیبایی می‌نویسد اما در هر لحظه فقط می‌تواند ۲۰۰ خط از یک فایل را ببیند، هرگز خطایی را که از یک import در ابتدای فایل شروع و با یک فراخوانی در انتهای فایل تمام می‌شود، پیدا نخواهد کرد.
لایه‌های سخت‌افزاری
برای کسانی که هیچ بودجه‌ای ندارند، «لایه صفر» شامل اجرای یک مدل ۱.۵ میلیارد پارامتری مثل qwen2.5-coder:1.5b روی CPU است. اگرچه این مدل‌ها کند هستند — به گونه‌ای که به‌جای استریم لحظه‌ای، با مکث‌هایی شبیه به «زمانی برای یک جرعه قهوه» توصیف می‌شوند — اما همچنان کاربردی هستند. مدل‌های ۱.۵ میلیاردی در بازبینی کد برای موارد زیر واقعاً مفیدند:
- شناسایی «بوی کد» (Code Smells) واضح، مانند بلوک‌های catch خالی، مقادیر بازگشتی بررسی نشده یا استفاده از رشته‌ها برای ساخت SQL.
- خلاصه‌سازی آنچه یک تغییر (diff) انجام می‌دهد، پیش از آنکه خودتان آن را بخوانید.
- پیش‌فیلتر کردن فایل‌ها (مثلاً پرسش اینکه: «آیا این فایل با بخش احراز هویت یا پرداخت‌ها درگیر است؟») تا مدل‌های بزرگتر فقط بخش‌های حیاتی را پردازش کنند.
با این حال، این مدل‌ها در استدلال‌های چندمرحله‌ای به‌شدت مشکل دارند. اگر از آن‌ها بپرسید آیا یک حفاظ در برابر بازگشت (reentrancy guard) واقعاً از تابعی که وجوه را منتقل می‌کند محافظت می‌کند یا خیر، یک مدل ۱.۵ میلیاردی احتمالاً با اطمینان زیاد به تقریباً هر چیزی پاسخ مثبت می‌دهد. این مدل‌ها در واقع «تطبیق‌دهنده‌ی الگو» هستند، نه «استدلالی».
«لایه یک» همان نقطهٔ طلایی ۸ گیگابایت VRAM است. این سخت‌افزار به‌راحتی یک مدل ۷ میلیاردی کدنویس را که با دقت ۴ بیت (q4) کوانتایز شده است، اجرا می‌کند و فضای خالی نیز باقی می‌گذارد. جهش از ۱.۵ به ۷ میلیارد پارامتر تحول‌آفرین است؛ مدل از تطبیق ساده الگوها به استدلال واقعی حرکت می‌کند. چنین مدلی می‌تواند دستورالعمل‌های خروجی ساختاریافته را دنبال کند و یک استدلال منطقی را در طول یک تابع حفظ کند. برای مثال، وقتی یک قرارداد Solidity به آن داده می‌شود، به‌جای اینکه فقط به دنبال کلمات کلیدی بگردد، می‌تواند درباره‌ی کنترل دسترسی (Access Control) استدلال کند.
این لایه سخت‌افزاری، پایه و اساس ابزار متن‌باز spectr-ai (حسابر قراردادهای هوشمند) بود. توسعه‌دهنده این ابزار به‌طور خاص مدل‌های ۷ میلیاردی را روی این سخت‌افزار تست کرد، زیرا ابزاری که به یک GPU ۲۰۰۰ دلاری نیاز داشته باشد، ابزاری است که اکثر مردم هرگز اجرا نخواهند کرد. در این سطح، بازبینی‌های تک‌فایلی در زمانی مناسب تکمیل می‌شوند و اسکن‌های سراسری دایرکتوری می‌توانند در پس‌زمینه اجرا شوند.
«لایه دو» شامل کارت‌های ۱۶ تا ۲۴ گیگابایتی است. این کارت‌ها مدل‌های ۱۴ میلیارد پارامتری را به‌راحتی و یا مدل‌های ۳۲ میلیارد پارامتری کوانتایز شده را پشتیبانی می‌کنند. این مدل‌ها توهمات (Hallucinatios) به‌مراتب کمتر و استدلال‌های بین-تابعی (cross-function reasoning) و توضیحات دقیق‌تری درباره‌ی شدت آسیب‌ها (Severity) ارائه می‌دهند.
با وجود این بهبودها، بازدهی در این لایه کاهش می‌یابد. جهش از ۱.۵ به ۷ میلیارد، «نوع» تسک‌های ممکن را تغییر می‌دهد، در حالی که جهش از ۷ به ۳۲ میلیارد، عمدتاً «کیفیت» تسک‌هایی را بهبود می‌بخشد که مدل ۷ میلیاردی قبلاً می‌توانست آن‌ها را امتحان کند. اگر مجبور باشید بین یک کارت ۲۴ گیگابایتی و یک کارت ۸ گیگابایتی به‌علاوه ۱۰۰۰ دلار پول نقد انتخاب کنید، توصیه می‌شود کارت ۸ گیگابایتی را بردارید و بخشی از پول باقی‌مانده را صرف فراخوانی APIهای ابری برای سخت‌ترین و پیچیده‌ترین موارد کنید.
توازن در کوانتاسیون
کوانتاسیون (Quantization) وزن‌های مدل را فشرده می‌کند تا در حافظه محدود جای بگیرند. راهنمای مذکور یک قاعده خاص را پیشنهاد می‌کند: بزرگ‌ترین تعداد پارامتری را انتخاب کنید که با دقت q4 در حافظه جا شود، پیش از آنکه VRAM خود را صرف دقت‌های بالاتر (مانند q8) کنید.
- q8: تقریباً کیفیت کامل مدل را حفظ می‌کند.
- q4: مصرف حافظه را دوباره نصف می‌کند، اما با مقدار کمی افت کیفیت.
هرچند مدل‌های q4 ممکن است گاهی در زنجیره‌های منطقی طولانی رشته‌ی افکار را گم کنند (در حالی که q8 آن را حفظ می‌کند)، اما یک مدل ۷ میلیاردی با دقت q4، در هر سناریوی ممکن، به‌طور مداوم بهتر از یک مدل ۱.۵ میلیاردی با دقت q8 عمل می‌کند. تنها یک نکته درباره‌ی خروجی‌های ساختاریافته (مانند یافته‌های JSON) وجود دارد؛ جایی که کوانتاسیون شدیدتر ممکن است باعث افزایش خطاهای فرمت شود. با این حال، این مشکل را بهتر است با یک «حلقه تکرار نرم‌افزاری» (Software Retry Loop) حل کرد، نه با خرید سخت‌افزار بیشتر.
مدیریت گلوگاه زمینه
محدودیت واقعی در سال ۲۰۲۶، حافظه مربوط به پنجره‌ی زمینه است. حافظه موقت کلید-مقدار (KV cache) — یعنی حافظه‌ای که مدل برای به خاطر سپردن ورودی‌های شما استفاده می‌کند — با افزایش طول زمینه رشد می‌کند و برای تصاحب VRAM با وزن‌های مدل رقابت می‌کند. یک قرارداد ۹۰۰ خطی به‌علاوه پرامپت و فضای پاسخ، به‌سرعت VRAM را پر می‌کند.
اگر زمینه درخواستی از حافظه‌ی موجود بیشتر شود، Ollama ممکن است به‌طور بی‌صدا لایه‌ها را به CPU منتقل کند (که سرعت بازبینی را به‌شدت کاهش می‌دهد) یا بدتر از آن، به‌طور بی‌صدا فایل را قطع (truncate) نماید و تنها نیمی از آن را بدون اطلاع کاربر بازبینی کند.
برای جلوگیری از این اتفاق، کاربران باید طول زمینه را به‌طور صریح تنظیم کنند. برای مثال، هنگام اجرای ollama run qwen2.5-coder:7b و استفاده از دستور /set parameter num_ctx 16384، تضمین می‌شود که مدل کد لازم را می‌بیند. برای فایل‌های بسیار بزرگ، تکه‌بندی دستی (Manual Chunking) بر اساس قرارداد، کلاس یا گروه‌های تابعی، بسیار موثرتر از تکیه بر یک پنجره‌ی متنی عظیم است. مدلی که ۳۰۰ خط را به‌طور کامل بخواند، بهتر از مدلی است که ۹۰۰ خط را به‌صورت نصفه و نیمه بخواند.
استقرار در WSL2
برای کسانی که از زیرسیستم لینوکس در ویندوز (WSL2) استفاده می‌کنند، ترتیب زیر برای جلوگیری از هرگونه اصطکاک در نصب ضروری است:
- نصب درایور: درایور NVIDIA را فقط روی محیط ویندوز نصب کنید. هرگز درایور لینوکس را داخل WSL نصب نکنید؛ زیرا مکانیزم passthrough خودش این کار را مدیریت می‌کند.
- تأیید: پیش از هرگونه عیب‌یابی در اولاما، دستور
nvidia-smiرا در محیط WSL اجرا کنید تا از قابلیت رؤیت GPU توسط سیستم مطمئن شوید. - اجرا: اگر بقیه ابزارهای توسعه شما در WSL هستند، Ollama را نیز درون محیط WSL اجرا کنید تا از اصطکاک ناشی از عبور از مرز localhost جلوگیری شود.
- مدیریت منابع: اگر از مدل‌های مبتنی بر CPU یا قابلیت CPU offloading استفاده می‌کنید، محدودیت‌های RAM را در فایل
.wslconfigافزایش دهید، زیرا WSL به‌طور پیش‌فرض سقف RAM را محدود می‌کند.
این رویکرد به توسعه‌دهندگان اجازه می‌دهد تا ابزارهای قدرتمند را روی سخت‌افزارهای در دسترس بسازند. «مسابقه تسلح VRAM» عمدتاً توسط بنچمارکهای مربوط به «تولید کد» پیش می‌رود، نه کاربردی‌های عملی. برای اکثر توسعه‌دهندگان، بهینه‌ترین هزینه، خرید یک کارت ۸ گیگابایتی در ترکیب با چند فراخوانی API ابری برای موارد لبه‌ای (Edge Cases) بسیار نادر و پیچیده است.
پیشنهاد می‌شود ابتدا با تست مدل ۱.۵ میلیاردی روی CPU فعلی خود به مدت یک هفته شروع کنید تا یک جریان کاری (Workflow) برای بازبینی ایجاد کنید. تنها زمانی به فکر ارتقا به یک کارت گرافیک کارکرده ۸ یا ۱۲ گیگابایتی باشید که بتوانید تسک خاصی را شناسایی کنید که مدل ۷ میلیاردی به‌طور مداوم در حل آن شکست می‌خورد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه تراشه‌های جدید استنتاج را ارزان‌تر می‌کنند، به تحلیل ما درباره‌ی معماری Blackwell مراجعه کنید.
گفتگو