بازگشت به وبلاگ

Ollama از GPU استفاده نمی‌کند؟ رفعش روی Linux و Windows و WSL

۲۵ شهریور ۱۴۰۵

TL;DR

وقتی مدل بارگذاری شده ollama ps را اجرا کنید: ستون PROCESSOR حقیقت را می‌گوید. 100% GPU یعنی GPU سالم است و می‌توانید همین‌جا رها کنید. شکافی مثل 40%/60% CPU/GPU یعنی مدل در VRAM جا نشده — quant کوچک‌تر بردارید. 100% CPU یعنی Ollama هیچ GPU قابل‌استفاده‌ای پیدا نکرده: معمولاً درایور کهنه، نبود عضویت گروه (AMD روی Linux)، OLLAMA_LLM_LIBRARY پین‌شده، یا کانتینری که بدون دسترسی GPU بالا آمده. علتی را که لاگ نام می‌برد رفع کنید؛ فقط حدود پنج‌تاست.

چطور مطمئن شوم Ollama واقعاً از GPU استفاده می‌کند؟

دو دستور، بدون حدس زدن.

# In one terminal: load a model
ollama run llama3.2 "hello"

# In another: see where it runs
ollama ps
NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

ستون PROCESSOR سه حالت دارد:

  • 100% GPU — همه لایه‌ها offload شده‌اند. تمام.
  • 48%/52% CPU/GPU — offload ناقص. GPU کار می‌کند، ولی مدل به‌علاوه context در VRAM جا نشده. بخش VRAM در پایین را ببینید.
  • 100% CPU — استنتاج روی CPU است. GPU یا دیده نشده یا آگاهانه غیرفعال شده.

بعد لاگ سرور را بخوانید؛ همان‌جا می‌گوید موقع راه‌اندازی واقعاً چه سخت‌افزاری پیدا کرده:

journalctl -u ollama --no-pager | grep -i "inference compute"

روی یک جعبه سالم NVIDIA خطی شبیه این می‌خواهید:

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

نه هیچ خطی، یا خطی که به پیام fallback فقط-CPU ختم می‌شود — مشکل را پیدا کرده‌اید. بقیه این نوشته همان پنج علت است، محتمل‌ترین اول.

چرا Ollama می‌گوید «هیچ GPU سازگاری کشف نشد»؟

روی NVIDIA مقصر همیشگی درایور است، نه CUDA. Ollama کتابخانه‌های runtime خود CUDA را همراه دارد، پس لازم نیست CUDA toolkit نصب باشد — ولی runtime همراه باید درایوری به‌اندازه کافی تازه داشته باشد که با آن حرف بزند. کار کردن nvidia-smi اثبات نیست؛ فقط ثابت می‌کند درایوری وجود دارد، نه اینکه به‌اندازه کافی تازه باشد.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

اگر نسخه چند سال عقب است، آپدیتش کنید و ریبوت بزنید:

# Debian/Ubuntu family
sudo apt install nvidia-driver-570
# Arch family
sudo pacman -S nvidia

بعد از آپدیت درایور، سرویس Ollama را ری‌استارت کنید تا دوباره دستگاه‌ها را کشف کند — کشف یک بار موقع شروع اتفاق می‌افتد، نه به ازای هر درخواست:

sudo systemctl restart ollama

اگر لاگ حالا GPU تان را با library=CUDA چاپ می‌کند، تمام. اگر هنوز سر باز می‌زند، چک کنید OLLAMA_LLM_LIBRARY هیچ جا ست نشده باشد — بخش «بعد از آپدیت» را ببینید.

چرا Ollama فقط بخشی از مدل را روی GPU می‌برد؟

Offload ناقص حساب و کتاب است، نه باگ: وزن‌های مدل به‌علاوه KV cache برای پنجره context تان باید در VRAM جا شوند. یک مدل 7B در Q4 حدود 4–5 گیگابایت است؛ 8K context بدهید، cache بیشتر اضافه می‌کند. روی کارت 8 گیگابایتی چیزی باید روی CPU بماند و ollama ps همان تقسیم را نشان می‌دهد.

سه راه بستن شکاف، ارزان‌ترین اول:

  1. Quant کوچک‌تر. از Q8 به Q4 حجم وزن‌ها نصف می‌شود با هزینه کیفیت معقول. مبادله‌ها در کوانتیزاسیون GGUF: کدام سطح را به‌کار ببرید؟ چیده شده‌اند.
  2. Context کوتاه‌تر. num_ctx تعیین‌کننده اصلی حجم cache است. 32K context روی کارت 8 گیگابایتی یعنی بیشتر لایه‌ها روی CPU بمانند.
  3. لایه‌های GPU کمتر. گزینه num_gpu سقف لایه‌های offload شونده را می‌زند. ست کردنش زیر تعداد لایه‌ها تضمین می‌کند split بیفتد — اگر کسی در Modelfile یا فراخوان API ست کرده، برداریدش.

تله برعکس را هم ببینید: GPU ای که 100% GPU نشان می‌دهد ولی کندتر از انتظار اجرا می‌کند، شاید دارد روی RAM سیستم swap می‌کند. SIZE مربوط به ollama ps را با VRAM واقعی تان مقایسه کنید.

چرا Ollama از GPU ی AMD من استفاده نمی‌کند؟

AMD روی Linux سه چیز می‌خواهد، و هر سه قابل‌چک‌اند:

1. پشتیبانی ROCm در بیلد. اسکریپت نصب رسمی Linux یک بیلد ROCm همراه می‌آورد. چک کنید سرور چه دیده:

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. عضویت گروه. runtime مربوط به ROCm به /dev/kfd و /dev/dri دسترسی می‌خواهد، یعنی گروه‌های render و video:

sudo usermod -aG render,video $USER
# log out and back in, then:
sudo systemctl restart ollama

همین یک گروه غایب، پراستنادترین پستِ «Ollama در Ubuntu از GPU استفاده نمی‌کند» در همه فروم‌هاست، و از نصب دوباره درایور هم جان به در می‌برد، چون درایور هرگز مشکل نبود.

3. GPU پشتیبانی‌شده — یا یک override. کارت‌های مصرفی RDNA2 بدون پشتیبانی (gfx1031، gfx1032) حتی با ROCm سالم، کشف نمی‌شوند. workaround استاندارد، معرفی خود به‌عنوان یک هدف سازگار است:

sudo systemctl edit ollama
[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

بعد sudo systemctl restart ollama. این یک override بدون‌پشتیبانی-ولی-پرکاربرد است؛ اگر بدرفتاری کرد، برداریدش و به قلمرو پشتیبانی رسمی برمی‌گردید. اگر کنترل کامل روی backend ها را به گم شدن در autodetect ترجیح می‌دهید، آن تفاوت محوری در llama.cpp یا Ollama: در 2026 کدام را اجرا کنید؟ پوشش داده شده.

روی Windows، پشتیبانی AMD باریک‌تر است — قبل از اینکه بگویید نصب خراب است، فهرست GPU های پشتیبانی‌شده Ollama را برای کارت خودتان چک کنید.

چرا Ollama بعد از آپدیت از GPU استفاده نمی‌کند؟

آپدیت یکی از این سه را عوض می‌کند، به این ترتیب احتمال:

  1. کتابخانه backend پین‌شده. OLLAMA_LLM_LIBRARY یک runner مشخص را تحمیل می‌کند (cuda_v11، rocm، یا حتی cpu). برای دیباگ ساخته شده، بی‌سروصدا از autodetect عبور می‌کند، و در shell profile ها و فایل‌های سرویس مدت‌ها بعد از فراموشی دلیلش می‌ماند. پیدا و پاکش کنید:
systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA
  1. درایور از runtime عقب مانده. آپگریدهای Ollama یک runtime CUDA تازه‌تر همراه می‌آورند؛ درایور شما تا نبریدش جلو نمی‌رود. همان رفع بخش درایور بالاتر.
  2. سرویس کانتینر است و فلگ‌ها رفته‌اند. کانتینر بازسازی‌شده بدون فلگ‌های GPU یک کانتینر فقط-CPU است. فراخوان NVIDIA:
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

برای کانتینرهای AMD، معادلش device passthrough به‌علاوه اضافه کردن گروه‌هاست:

docker run -d --device=/dev/kfd --device=/dev/dri 
  --group-add video --group-add render 
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

نه --gpus=all، نه GPU — Docker دلیلی برای بخشندگی ندارد.

آیا Ollama در WSL2 کار می‌کند؟

بله، با درایور درست در جای درست: درایور NVIDIA مربوط به Windows را نصب کنید، هرگز درایور Linux داخل توزیع نه — درایور داخل WSL پاس‌ترو CUDA را می‌شکند نه اینکه درستش کند. بعد خود WSL را آپدیت کنید و وجود دستگاه passthrough را تأیید کنید:

wsl --update   # from PowerShell
ls /dev/dxg    # inside WSL — must exist for GPU use

با /dev/dxg حاضر و درایور Windows به‌روز، Ollama در WSL2 مثل نصب بومی به GPU offload می‌کند. اگر واسطه را کلاً نمی‌خواهید، بیلد Windows ای Ollama بومی اجرا می‌شود و بدون WSL، GPU را می‌بیند.

اصلاً Ollama GPU لازم دارد؟

نه — اجرای فقط-CPU از نظر عملکرد یکسان است، فقط کندتر، و برای مدل‌های کوچک روی CPU سریع کاملاً قابل‌استفاده. روی Apple Silicon سؤال منحل می‌شود: Metal خودکار از حافظه یکپارچه استفاده می‌کند و تنها سقف، چقدر RAM حاضرید با مدل تقسیم کنید.

چک‌لیست پنج‌دقیقه‌ای

نشانهعلت محتملرفع
100% CPU در ollama ps با کارت NVIDIA حاضردرایور برای CUDA همراه خیلی کهنه استآپدیت درایور، ریبوت، ری‌استارت سرویس
100% CPU، AMD روی Linuxگروه render/video غایبusermod -aG render,video، لاگین دوباره
100% CPU، کارت AMD بدون پشتیبانیROCm هدف gfx را رد می‌کندHSA_OVERRIDE_GFX_VERSION=10.3.0
تقسیم 40%/60% CPU/GPUمدل + context از VRAM می‌گذردquant کوچک‌تر یا num_ctx کوتاه‌تر
GPU دیروز بود، CPU امروزOLLAMA_LLM_LIBRARY پین‌شده یا درایور کهنهمتغیر env را پیدا و پاک کنید؛ درایور را آپدیت کنید
GPU در اجرای بومی، CPU در Dockerکانتینر بدون فلگ‌های GPU بالا آمدهبا --gpus=all (یا دستگاه‌های AMD) بازسازی کنید

به این ترتیب چک کنید: ollama ps برای وضعیت، لاگ‌های سرور برای فهرست کشف، بعد جدول. نُه بار از ده، خط لاگ از قبل گفته کدام ردیف‌اید.

GPU برگشت به خدمت؟ تصمیم بعدی خود runtime است — llama.cpp یا Ollama: در 2026 کدام را اجرا کنید؟ با یک هفته استفاده واقعی حکمش را می‌دهد.

FAQ

چطور بفهمم Ollama از GPU استفاده می‌کند؟

ollama ps برای هر مدل بارگذاری‌شده درصد GPU نشان می‌دهد؛ nvidia-smi باید پروسه ollama را با VRAM واقعی ببیند.

چرا Ollama به CPU برمی‌گردد؟

معمولاً VRAM: مدل به‌علاوه context جا نمی‌شود، پس لایه‌ها به RAM می‌روند. quant یا context را کم کنید — و مطمئن شوید اصلاً nvidia-smi کار می‌کند.

آیا 100 درصد GPU در ollama ps یعنی offload کامل؟

بله — سهم لایه‌هایی است که روی کارت اجرا می‌شوند. هر چیزی کمتر یعنی بقیه در RAM سیستم نشسته.

— mrsaynothing

— mrsaynothing

یادداشت‌های میدانی درباره AI، لینوکس و self-hosting.

این نوشته را در dev.to بحث کنید dev.to ↗

آموزش بعدی با ایمیل

هر نوشته یک ایمیل. درستش کن، برو سراغ بعدی.

self-hosted · بدون واسطه‌های ثالث · لغو اشتراک با یک کلیک

این چیست؟

Git revert در مقابل reset: کدام تاریخچه شما را نجات می‌دهد؟

این نوشته‌ها را می‌پسندید؟ این همان کاری است که برای زندگی از آن درمی‌آورم. استخدامم کنید