اگر از تداخل درایورهای CUDA و به‌روزرسانی‌های هسته لینوکس خسته شده‌اید، جداسازی محیط استنتاج تنها راه نجات است. با اجرای اولاما (Ollama) در یک کانتینر داکر، دیگر نیازی نیست نگران خراب شدن کتابخانه‌های سیستمی هنگام نصب مدل‌های مختلف باشید. این روش «جهنم وابستگی‌ها» (Dependency Hell) را که هنگام تداخل درایورهای CUDA و آپدیت‌های کرنل در سیستم میزبان رخ می‌دهد، کاملاً حذف می‌کند. با ایزوله کردن پشته استنتاج، توسعه‌دهندگان می‌توانند مدل‌هایی مانند Llama 3.2، Qwen، Mistral یا DeepSeek را بدون ریسک شکستن کتابخانه‌های سراسری سیستم مستقر کنند.
استفاده از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در محیط‌های محلی به‌دلیل نیاز به حاکمیت داده‌ها (Data Sovereignty)، حریم خصوصی سخت‌گیرانه و حذف هزینه‌های توکن افزایش یافته است. اما طبق گزارش‌های فنی، نصب مستقیم فایل‌های باینری یا درایورهای CUDA روی سرور اغلب پس از یک دستور ساده‌ی apt upgrade یا به‌روزرسانی هسته منجر به ناپایداری سیستم می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی میزبانی شخصی (Self-hosting) اشاره کردیم، استفاده از یک رویکرد کانتینری تضمین می‌کند که محیط عملیاتی تغییرناپذیر (Immutable) باقی بماند و به‌راحتی روی سخت‌افزارهای مختلف قابل تکثیر باشد.
برای اتصال سخت‌افزار میزبان به کانتینر، سیستم‌عامل (معمولاً دبیان یا اوبونتو) به ران‌تایم رسمی NVIDIA نیاز دارد. این ابزار به دیمون داکر اجازه می‌دهد تا قابلیت‌های محاسباتی GPU را به محیط ایزوله منتقل کند. بر اساس مستندات رسمی، این فرآیند شامل سه گام اصلی است:
- افزودن کلید GPG و مخزن رسمی NVIDIA به سیستم.
- نصب بسته‌ی
nvidia-container-toolkitاز طریقapt-get. - پیکربندی دیمون داکر با دستور
sudo nvidia-ctk runtime configure --runtime=dockerو بازراه‌اندازی سرویس.
برای فعال‌سازی شتاب‌دهنده گرافیکی، فایل compose.yaml باید رزرو منابع دقیقی داشته باشد. طبق بررسی‌های فنی، بخش deploy.resources.reservations.devices باید شامل دستورات حیاتی زیر باشد:
- Driver: nvidia
- Count: all
- Capabilities: [gpu, compute, utility]
همچنین برای جلوگیری از پاک شدن مدل‌ها پس از حذف کانتینر، باید یک Volume نام‌گذاری شده (مانند ollama_models_volume) به مسیر /root/.ollama متصل شود تا مدل‌های دانلود شده پایدار بمانند و با حذف کانتینر از بین نروند. کاربران می‌توانند با اجرای دستور docker exec -it ollama-gpu-server nvidia-smi صحت اتصال و انتقال سخت‌افزار (Passthrough) را بررسی کنند. اگر سخت‌افزارهایی مثل RTX 3060، RTX 4060 Ti یا A100 در خروجی ظاهر شوند، پیکربندی موفق بوده است. سپس می‌توان مدل‌ها را از طریق CLI مدیریت کرد؛ مثلاً اجرای ollama run llama3.2:3b برای کارهای سبک یا qwen2.5-coder:7b برای برنامه‌نویسی و استدلال.
یک ریسک امنیتی حیاتی این است که REST API اولاما (که در مسیر http://localhost:11434/api/... در دسترس است) فاقد احراز هویت داخلی است. اگر پورت روی 0.0.0.0:11434 باز باشد، هر کاربر در شبکه می‌تواند:
- پرامپت ارسال کرده و ۱۰۰٪ از VRAM و CPU را مصرف کند.
- مدل‌های دانلود شده را از طریق فراخوان‌های DELETE حذف کند.
- مدل‌های دلخواه و متفرقه را روی دیسک میزبان دانلود کند.
برای رفع این مشکل، توصیه می‌شود پورت فقط روی 127.0.0.1:11434 بسته شود. برای محیط‌های عملیاتی (Production)، کاربران باید یک Reverse Proxy مثل Caddy یا Nginx را همراه با احراز هویت توکن Bearer (Authorization: Bearer <token>) و پایان‌دهنده SSL/TLS پیاده‌سازی کنند.
این تغییر رویکرد، استقرار هوش مصنوعی را از نصب‌های شکننده روی سخت‌افزار (Bare-metal) به معماری میکروسرویس تبدیل می‌کند که در آن LLM تنها یک سرویس ایزوله دیگر است. برای دسترسی از راه دور نیز به‌جای باز کردن پورت‌ها در اینترنت عمومی، استفاده از تونل‌های VPN مدرن مثل Tailscale یا WireGuard پیشنهاد می‌شود.
گام بعدی شما
- نصب NVIDIA Container Toolkit و تست اتصال GPU با دستور
nvidia-smiدر داکر. - محدود کردن دسترسی API به Localhost برای جلوگیری از حملات مصرف منابع.
- بررسی بنچمارک‌های VRAM برای کارت‌های ۸، ۱۲ و ۱۶ گیگابایتی جهت تعیین اینکه سخت‌افزار شما واقعاً چه اندازه مدل‌هایی را پشتیبانی می‌کند.
اما بهینه‌سازی مصرف حافظه برای مدل‌های بزرگ‌تر، نیازمند درک عمیق‌تری از کوانتش است — به تحلیل ما درباره‌ی Weight Quantization مراجعه کنید.
گفتگو