GPU у WSL: реальні вимоги (та поширені підводні камені)

February 6, 2026 • February 6, 2026 • Читання: 7 хв • Views: 0

Було корисно?

Обіцянка приваблива: залишити Windows для всього корпоративного, використовувати Linux для всього корисного і при цьому отримати доступ до GPU як на справжній робочій станції.
Але потім ви запускаєте nvidia-smi у WSL і отримуєте «command not found», або ще гірше — «No devices were found».

Ось реальність: підтримка GPU у WSL2 нині надійна, але вибаглива. Ви не «встановлюєте CUDA у WSL» так, як на фізичній машині.
Ви збираєте ланцюжок залежностей між Windows, WSL-ядром, Linux userland і іноді Docker. Один слабкий елемент — і ви отримуєте повільну, заплутану помилку.

Ментальна модель: що насправді означає «GPU у WSL»

WSL2 — це не «Linux на Windows» у милий спосіб. Це легка VM. Ваші Linux-процеси працюють у реальному Linux-ядрі (поставленому Microsoft),
і вони бачать апарат через межу віртуалізації.

Для обчислень на GPU WSL2 використовує паравіртуалізований інтерфейс GPU. У сучасних збірках Windows драйвер GPU у Windows відкриває шлях для обчислень у WSL VM.
Linux-процеси не спілкуються з фізичним PCI-пристроєм; вони працюють із віртуальним вузлом пристрою, який переадресовує завдання до хост-драйвера.
Драйвер Windows — джерело істини. На практиці це означає:

Ви не встановлюєте повний Linux-ядровий драйвер NVIDIA у WSL для GPU. Якщо спробуєте — зазвичай погіршите ситуацію.
libcuda у WSL походить зі спеціального інтеграційного шару, а не зі стандартного стеку kernel-module вашого дистрибутиву.
Більшість збоїв — це невідповідності між версією драйвера Windows, можливостями WSL-ядра та userland-бібліотеками (CUDA toolkit / ML-фреймворки).

Уявляйте підтримку GPU у WSL як «віддалений CUDA до Windows-драйвера по дуже швидкому локальному каналу», а не як «Linux володіє GPU».
Ця ментальна зміна запобігає класичній помилці: гонитві за Linux-ядровими модулями, які взагалі тут не застосовуються.

Жарт №1: діагностика GPU у WSL схожа на вгнання котів — тільки коти тут драйвери, і всі наполягають, що вони вже встановлені.

Реальні вимоги (що має бути виконано)

1) Ваша збірка Windows має підтримувати обчислення GPU у WSL2

Обчислення GPU у WSL2 залежить від стеку хоста Windows: WDDM GPU-драйвери, інфраструктура WSL та підтримка ядра.
Якщо Windows занадто стара, ви отримаєте чисту інсталяцію WSL з повністю мертвим шляхом до GPU.

Практична порада: тримайте Windows в актуальному стані. Якщо ви в корпоративному каналі, який відстає, перевірте підтримку GPU у WSL до того, як щось обіцяти команді.
Це не опція; це фундамент.

2) Ваш постачальник GPU і драйвер мають явно підтримувати WSL

У реальному житті більшість, хто використовує CUDA у WSL, працюють на NVIDIA. AMD може працювати у певних сценаріях (і існує DirectML),
але CUDA у WSL — це переважно історія NVIDIA.

Ключова вимога — версія Windows-драйвера NVIDIA, що включає підтримку WSL.
Встановлення випадкового «Studio» або «Game Ready» драйвера підходить, якщо він достатньо новий і містить компоненти під обчислення для WSL.
Старі драйвери з радістю відтворюватимуть ігри, але відмовлятимуться надавати обчислення у WSL.

3) WSL2, а не WSL1

WSL1 транслює системні виклики Linux. Це розумно, але це не платформа для обчислень на GPU. Вам потрібен WSL2 з реальним ядром.
Якщо ваш дистрибутив ще на WSL1 — зупиніться. Конвертуйте його. Не налагоджуйте нічого іншого, поки цього не зробите.

4) Підтримуване WSL-ядро і версія WSL

Є два рухомі елементи: збірка ОС Windows і сам компонент WSL (який тепер оновлюється більше як додаток).
Шлях до GPU живе у цій зоні. Якщо у вас застаріла версія WSL, ви можете бачити дивні невідповідності: драйвер Windows виглядає правильним, але у WSL бракує “клею”.

5) Userland-бібліотеки мають відповідати очікуванням фреймворку

Ось де люди стріляють собі у ногу: вони встановлюють повний CUDA toolkit у WSL так, ніби на звичайному Ubuntu,
потім перезаписують ключові бібліотеки і дивуються, чому nvidia-smi працює, а PyTorch — ні.

Визначте, що вам справді потрібно:

Якщо ви лише запускаєте PyTorch або TensorFlow: часто не потрібен повний CUDA toolkit; потрібен правильний build фреймворку і сумісні userland-бібліотеки.
Якщо ви компілюєте кастомний CUDA-код: вам потрібен toolkit у WSL, але все одно не слід встановлювати Linux-ядровий драйвер.

6) Docker додає ще один шар залежностей

Docker у WSL — звична річ і частий підсилювач відмов. Тепер у вас:
Windows driver → WSL GPU interface → WSL userland → Docker engine → NVIDIA container runtime → образ вашого контейнера.
Одна невідповідність — і ви втрачаєте GPU, або отримуєте контейнер, який бачить GPU, але не може запускати ядра.

Факти та історичний контекст (чому це дивно)

Це не просто цікаві факти. Вони пояснюють сучасний дизайн і ті режими відмов, які ви реально побачите.

WSL1 (2016) не був VM. Він транслював системні виклики. Чудово для CLI-інструментів; не природний варіант для GPU і драйверів kernel-mode.
WSL2 (2019) перейшов на реальне Linux-ядро. Це зробило контейнери та інструменти, залежні від ядра, практичними.
Обчислення GPU у WSL2 з’явилося через паравіртуалізацію, а не PCI passthrough. Ваш гість Linux не «володіє» GPU як у типовому passthrough.
Модель драйвера відображення Windows (WDDM) — критичний елемент в ланцюжку. Якщо компоненти WDDM застарілі, обчислення можуть відмовити, навіть якщо графіка працює нормально.
Підтримка NVIDIA для WSL включала спеціальний user-mode шлях CUDA. Ось чому версія драйвера Windows важить більше, ніж «latest» за менеджером пакетів Linux.
nvidia-smi у WSL — це індикатор сумісності, а не повна картина. Він може працювати, тоді як ваш ML-фреймворк падає через невідповідності cuDNN/cublas.
Рання підтримка GPU у WSL була обмежена збірками Windows Insider. Багато історій «працює на моїй машині» почалися в ту епоху.
DirectML став прагматичною альтернативою для деяких Windows-перших ML-навантажень. Але якщо вам потрібна екосистема CUDA — ви все ще в полі NVIDIA.

Практичні завдання: команди, виводи, рішення

Це перевірки виробничого рівня. Не ритуали типу «переінсталюйте все».
Кожне завдання включає команду, що означає типовий вивід і яке рішення прийняти далі.

Завдання 1: Підтвердити версію WSL і базовий стан (зі сторони Windows)

cr0x@server:~$ wsl.exe --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26052.1000-240405-2035.ge-release
Windows version: 10.0.22631.3007

Інтерпретація: Потрібна сучасна версія WSL і ядро 5.15+ у більшості середовищ. Точні числа різняться, але «давнє» видно відразу.

Рішення: Якщо wsl.exe --version не працює або показує дуже старі компоненти — оновіть WSL, перш ніж чіпати CUDA чи фреймворки.

Завдання 2: Підтвердити, що ваш дистрибутив працює як WSL2 (не WSL1)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Інтерпретація: VERSION має бути 2.

Рішення: Якщо це 1, конвертуйте: wsl.exe --set-version <distro> 2. Не налагоджуйте GPU на WSL1.

Завдання 3: Перевірити, чи Windows бачить драйвер NVIDIA (базова перевірка хоста)

cr0x@server:~$ nvidia-smi.exe
Tue Feb  6 09:14:22 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
|  0%   44C    P8             21W / 450W  |     987MiB / 24564MiB   |      2%      Default |
+-----------------------------------------+------------------------+----------------------+

Інтерпретація: Драйвер Windows встановлено і GPU видимий. Параметр CUDA Version тут — здатність драйвера, а не ваш toolkit у WSL.

Рішення: Якщо це не працює у Windows — зупиніться і виправте драйвер на Windows. WSL не врятує ситуацію.

Завдання 4: Перевірити наявність вузла пристрою GPU всередині WSL

cr0x@server:~$ ls -l /dev/dxg
crw-rw-rw- 1 root root 509, 0 Feb  6 09:10 /dev/dxg

Інтерпретація: /dev/dxg — це міст WSL до GPU. Немає /dev/dxg — немає шляху обчислень.

Рішення: Якщо він відсутній, підозрюйте застарілий WSL/ядро, неправильну збірку Windows або драйвер GPU без підтримки WSL.

Завдання 5: Підтвердити, що WSL може викликати стек керування NVIDIA

cr0x@server:~$ nvidia-smi
Tue Feb  6 09:16:05 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
|  0%   45C    P8             23W / 450W  |     992MiB / 24564MiB   |      1%      Default |
+-----------------------------------------+------------------------+----------------------+

Інтерпретація: Це необхідна, але не достатня перевірка. Вона доводить, що стек керування працює через WSL.

Рішення: Якщо це не працює, не витрачайте час на перевстановлення PyTorch. Виправте інтеграцію драйвера/WSL спочатку.

Завдання 6: Перевірити, чи ви випадково не встановили Linux-ядровий драйвер NVIDIA (зазвичай погано у WSL)

cr0x@server:~$ lsmod | grep -E '^nvidia|^nouveau' || true
nouveau              2539520  0
drm_ttm_helper         16384  1 nouveau
ttm                  106496  2 drm_ttm_helper,nouveau
drm_kms_helper        315392  1 nouveau

Інтерпретація: Наявність модулів nouveau або nvidia у WSL — тривожний знак.
У типовому налаштуванні GPU у WSL ці модулі не повинні використовуватись для паравіртуального шляху.

Рішення: Якщо вони завантажені — видаліть/заблокуйте їх і поверніться до підтримуваної інтеграції WSL. Це поширена самонанесена відмова.

Завдання 7: Перевірити резолюцію `libcuda.so` у WSL

cr0x@server:~$ ldconfig -p | grep -E 'libcuda\.so|libnvidia-ml\.so' | head
	libcuda.so.1 (libc6,x86-64) => /usr/lib/wsl/lib/libcuda.so.1
	libnvidia-ml.so.1 (libc6,x86-64) => /usr/lib/wsl/lib/libnvidia-ml.so.1

Інтерпретація: У WSL зазвичай бажано мати CUDA-стаби та інтеграційні бібліотеки під /usr/lib/wsl/lib.
Якщо libcuda.so.1 резольвується в інше місце (наприклад, /usr/lib/x86_64-linux-gnu з пакетів дистрибутиву), можуть виникати конфлікти бібліотек.

Рішення: Якщо резолюція неправильна — виправте шляхи бібліотек і видаліть конфліктні пакети перед тим, як налагоджувати фреймворки.

Завдання 8: Переконатися, що середовище не саботує шляхи завантаження бібліотек

cr0x@server:~$ env | grep -E 'LD_LIBRARY_PATH|CUDA_HOME|CUDA_PATH' || true
LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64
CUDA_HOME=/usr/local/cuda

Інтерпретація: Це може бути нормальним, якщо ви навмисно встановили сумісний toolkit.
Але це також може примусити ваші застосунки підхопити неправильні бібліотеки і ігнорувати /usr/lib/wsl/lib.

Рішення: Якщо ви просто запускаєте фреймворки у вигляді wheel/conda-пакетів, розгляньте можливість прибрати ці змінні і дозволити фреймворку керувати залежностями.

Завдання 9: Перевірити доступ до GPU з фреймворку (приклад PyTorch)

cr0x@server:~$ python3 -c "import torch; print(torch.__version__); print('cuda:', torch.version.cuda); print('is_available:', torch.cuda.is_available()); print('device:', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'none')"
2.2.1
cuda: 12.1
is_available: True
device: NVIDIA RTX 4090

Інтерпретація: Це ключовий тест. Якщо nvidia-smi працює, але torch.cuda.is_available() повертає false, ймовірні невідповідності userland-бібліотек.

Рішення: Якщо false — перевірте ldd на відповідних CUDA-бібліотеках і впевніться, що встановлено CUDA-enabled збірку фреймворку.

Завдання 10: Інспектувати динамічне лінкування для CUDA-бібліотеки (швидко впіймати «не та libcuda»)

cr0x@server:~$ python3 -c "import ctypes; import os; print(ctypes.CDLL('libcuda.so.1'))"
<CDLL 'libcuda.so.1', handle 55b7f6d8f900 at 0x7f2df0b7f2d0>

Інтерпретація: Якщо тут виникає «cannot open shared object file», шлях бібліотек порушений.

Рішення: Якщо не вдається, поверніться до Завдання 7 і Завдання 8. Не перевстановлюйте все підряд; виправте зв’язування.

Завдання 11: Перевірити конфігурацію пам’яті та swap у WSL (тихий вбивця продуктивності)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           31Gi       4.2Gi       21Gi       136Mi       5.8Gi        26Gi
Swap:          16Gi          0B       16Gi

Інтерпретація: WSL використовує динамічну пам’ять, але все одно може відчувати swap або тиск пам’яті під тренувальними навантаженнями.
Якщо ваш pipeline даних пам’яттєвий — GPU-утилізація може впасти, поки CPU крутиться на пейджингу.

Рішення: Якщо swap активний під час тренування — виправте ліміти пам’яті та буферизацію pipeline даних. Не звинувачуйте CUDA першою.

Завдання 12: Заміряти використання GPU під час виконання навантаження

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr gtemp   sm   mem   enc   dec  mclk  pclk
# Idx     W     C    %     %     %     %   MHz   MHz
    0    85    62   97    71     0     0  10501  2520
    0    92    63   98    73     0     0  10501  2520

Інтерпретація: Якщо sm низький, а ваше завдання — «тренування», ви не прив’язані до GPU. Вузьке місце — вище по ланцюжку (CPU, I/O, data loader).

Рішення: Низька утилізація означає, що слід профілювати pipeline вводу, сховище та CPU-потоки, перш ніж чіпати налаштування GPU.

Завдання 13: Перевірити диск і тип файлової системи (аудит I/O вузьких місць)

cr0x@server:~$ df -Th / /mnt/c
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sdd       ext4   250G   42G  196G  18% /
C:\           drvfs  953G  611G  342G  65% /mnt/c

Інтерпретація: Рідна ext4-файлова система WSL (/) поводиться як Linux. /mnt/c — DrvFS і має інші характеристики продуктивності.
Багато ML-навантажень руйнуються через читання датасетів з /mnt/c.

Рішення: Тримайте тренувальні датасети і важкий I/O всередині WSL ext4. Використовуйте /mnt/c для зручності, а не для продуктивності.

Завдання 14: Швидкий і грубий I/O-бенчмарк там, де живе ваш датасет

cr0x@server:~$ dd if=/dev/zero of=./io-test.bin bs=1M count=2048 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 1.92 s, 1.1 GB/s
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 1.92 s, 1.1 GB/s

Інтерпретація: Це тест послідовної швидкості запису. Якщо на /mnt/c ви отримуєте значно гірші цифри — ви знайшли вузьке місце.

Рішення: Перенесіть дані або переробіть pipeline (шардінг tar, кешування, менше дрібних файлових операцій), якщо мусите залишатися на DrvFS.

Завдання 15: Перевірити видимість GPU всередині контейнера (якщо використовуєте Docker)

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.3.2-base-ubuntu22.04 nvidia-smi
Tue Feb  6 09:22:18 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|=========================================+========================+======================|
|   0  NVIDIA RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
+---------------------------------------------------------------------------------------+

Інтерпретація: Якщо це не працює, але nvidia-smi у WSL працює — проблема на боці контейнерного рантайму (toolkit/runtime інтеграція).

Рішення: Виправте конфігурацію NVIDIA container runtime і переконайтеся, що Docker Desktop/Engine підключено до WSL правильно.

Завдання 16: Перевірити вузькі місця на боці CPU (GPU часто ні в чому не винен)

cr0x@server:~$ sudo apt-get update >/dev/null 2>&1; sudo apt-get install -y sysstat >/dev/null 2>&1; mpstat -P ALL 1 3
Linux 5.15.146.1-microsoft-standard-WSL2 (server) 	02/06/2026 	_x86_64_	(24 CPU)

09:23:10 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
09:23:11 AM  all   320.00    0.00   40.00   55.00    0.00    0.00    0.00    0.00    0.00  585.00
09:23:12 AM  all   330.00    0.00   41.00   60.00    0.00    0.00    0.00    0.00    0.00  570.00

Інтерпретація: Високий %iowait свідчить про очікування на зберігання, а не обчислення. Це класична причина «GPU на 10%».

Рішення: Виправте I/O (Завдання 13/14), паралелізм data loader і розклад файлів, перш ніж налаштовувати CUDA-прапори.

Швидкий план діагностики (як знайти вузьке місце)

Коли вам пишуть «GPU у WSL зламався», зазвичай мають на увазі одне з трьох: відсутність видимості GPU, GPU видимий але фреймворки падають, або GPU працює але продуктивність жахлива.
Цей план допоможе швидко потрапити у правильний бакет.

Перш за все: чи це помилка драйвера Windows / інтеграції WSL?

Запустіть nvidia-smi.exe у Windows. Якщо не працює — зупиніться. Виправте інсталяцію драйвера Windows.
У WSL перевірте ls -l /dev/dxg. Якщо його немає — зупиніться. Оновіть WSL і підтвердіть, що збірка Windows/драйвер підтримують WSL.
У WSL запустіть nvidia-smi. Якщо не працює, але /dev/dxg існує — підозрюйте конфлікти бібліотек (libnvidia-ml/libcuda) або зламану інтеграцію WSL.

По-друге: це userland-невідповідність (плутанина фреймворку/тулкіта)?

Перевірте ldconfig -p | grep libcuda і переконайтеся, що воно вказує на /usr/lib/wsl/lib.
Протестуйте фреймворк напряму (мінімальний GPU-пробник PyTorch/TensorFlow).
Якщо фреймворк падає, але nvidia-smi працює — виправте версії: збірка фреймворку проти userland CUDA та будь-які зафіксовані LD_LIBRARY_PATH.

По-третє: це продуктивність (pipeline даних / зберігання / обмеження CPU)?

Під час виконання задачі: nvidia-smi dmon -s pucm -d 1. Якщо sm низький — ви не прив’язані до GPU.
Перевірте, де живуть дані: df -Th. Якщо тренування читає з /mnt/c — перенесіть їх.
Слідкуйте за %iowait через mpstat. Високий iowait — вузьке місце зберігання. Низький iowait але CPU завантажений — обмеження data loader / preprocessing.

Парафраз думки Вернера Фогелса (Werner Vogels, CTO Amazon): «Все ламається; надійність приходить від проектування й експлуатації з урахуванням цієї істини».

Три корпоративні історії з практики

Інцидент: неправильне припущення («WSL — це просто Ubuntu, так?»)

Команда дата-сайєнс мала стандартний Windows-образ і використовувала WSL2 для розробки. Найняли нового ML-інженера, який роками робив CUDA на bare-metal Ubuntu.
Інженер зробив те, що логічно: встановив Linux-драйвер NVIDIA і відповідний CUDA toolkit у дистрибутиві WSL.

Симптоми були приголомшливо заплутані. nvidia-smi працював у Windows, але всередині WSL він то показував «No devices were found», то падав з сегфолтом.
Інколи працював після перезавантаження. Інколи — до запуску Docker. Команда витратила тиждень на археологію в Slack.

Корінна причина була проста: вони встановили пакети, що намагалися керувати ядровим драйвером, який у WSL не призначено використовувати.
Файли бібліотек перезаписалися, логіка завантаження модулів натрапила на межу ядра, і середовище стало недетермінованим залежно від того, що було завантажене першим.

Виправлення було нудним: видалити пакети Linux NVIDIA, очистити застарілі репозиторії CUDA і відновити стек /usr/lib/wsl/lib, що надається WSL.
Після цього вони встановили лише ті userland-компоненти, які дійсно були потрібні для збірки коду, і зафіксували версії фреймворків.

Зміни в культурі були важливіші за команди: вони перестали ставитися до WSL як до «справжнього Linux-хоста» і почали розглядати його як спеціалізоване середовище.
У звіті про інцидент була підкреслена одна фраза: «Windows driver — це драйвер».

Оптимізація, що підвела: «Тримаймо датасети на C:, щоб OneDrive їх бекапив»

Команда хотіла єдине джерело істини для датасетів між Windows-інструментами і WSL-ноутбуками.
Вони зберігали все під C:\Users\...\datasets і зверталися до цього у WSL через /mnt/c.
Здавалося зручно. Це влаштовувало людей з комплаєнсу. Але навчання стало болісно повільним.

Графіки GPU розповіли історію: утилізація коливалась, час навчання подвоївся, з’являлися випадкові затримки.
Команда підозрювала віртуалізаційні витрати GPU. Вони налаштовували batch size, вмикали mixed precision, змінювали версії CUDA і навіть міняли GPU.
Нічого не допомагало.

Справжнім злочинцем була поведінка файлових операцій під DrvFS, підсилена макетом датасету з мільйонами дрібних файлів і інтенсивними зверненнями до метаданих.
Додайте корпоративний антивірус і синхронізацію хмарних служб — і отримаєте смерть від тисяч дрібних викликів stat().

Вони виправили це, перемістивши “гарячі” датасети в ext4 WSL і експортувавши в Windows тільки фіналізовані артефакти.
Для датасетів, що мали лишатися на Windows, вони упакували їх у шардовані архіви, щоб зменшити метадані.
«Оптимізацію» відкотили, і продуктивність повернулась, ніби зняли підп’ятник з шиї data loader.

Нудна але правильна практика: фіксовані версії і smoke test врятували день

Інша організація мала належну платформену команду. Не гламурно. Більше таблиць і правил.
Вони склали стандартний WSL базовий образ: діапазон версій драйвера Windows, мінімальна версія WSL, версія Ubuntu і благословений набір ML-фреймворків.

Щопонеділка планова робота запускала smoke test на кількох машинах: перевірити /dev/dxg, запустити nvidia-smi, імпортувати PyTorch, запустити маленький CUDA-ядро та зафіксувати результати. Ніяких глибоких бенчмарків — просто «ланцюжок все ще працює».

Одного тижня вихідні оновлення Windows розгорнулися, і smoke test виявив, що на підмножині машин тихо перевстановився старіший OEM-драйвер GPU.
Користувачі ще не помітили, бо графіка була в порядку. Але обчислення першими б дали збій під дедлайном.

Виправлення — політика примусового застосування драйверів і автоматичний скрипт ремедіації. Ключовий виграш не в скрипті.
Він у наявності рутинного тесту, що трактував GPU у WSL як операційну залежність, а не як забобон розробника.

Жарт №2: найнадійніша GPU-настройка — та, над якою ніхто не «покращує» у п’ятницю ввечері.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: `nvidia-smi` у WSL показує «command not found»

Корінна причина: Інструменти NVIDIA userland не встановлені у дистрибутиві або PATH відсутній.
Виправлення: Встановіть відповідний набір userland-пакетів для вашого дистрибутиву або використайте тестування на рівні фреймворку. Не встановлюйте ядрові драйвери. Переконайтеся, що існує /usr/lib/wsl/lib.

2) Симптом: `nvidia-smi` у WSL показує «No devices were found»

Корінна причина: Відсутній міст WSL GPU (/dev/dxg), непідтримуваний драйвер Windows або застарілий WSL/ядро.
Виправлення: Оновіть Windows, оновіть WSL, встановіть Windows NVIDIA драйвер з підтримкою обчислень у WSL. Перевірте ls -l /dev/dxg.

3) Симптом: відсутній `/dev/dxg`

Корінна причина: Не WSL2, компонент WSL застарілий або збірка Windows не підтримує шлях обчислень GPU.
Виправлення: Конвертуйте дистрибутив у WSL2, оновіть WSL і переконайтеся, що хост-ОС відповідає вимогам GPU-in-WSL.

4) Симптом: `nvidia-smi` працює, але PyTorch каже, що CUDA недоступна

Корінна причина: Встановлено CPU-only збірку PyTorch, або userland CUDA-бібліотеки невідповідні / перезаписані LD_LIBRARY_PATH.
Виправлення: Встановіть CUDA-enabled збірку фреймворку; видаліть конфліктні CUDA-бібліотеки; переконайтеся, що libcuda.so.1 резольвується до /usr/lib/wsl/lib.

5) Симптом: контейнер Docker не бачить GPU, але WSL бачить

Корінна причина: NVIDIA container runtime не налаштований, Docker не використовує WSL-движок правильно, або забуто --gpus all.
Виправлення: Виправте інтеграцію Docker + NVIDIA runtime; протестуйте з відомим CUDA-базовим образом і nvidia-smi всередині контейнера.

6) Симптом: тренування повільне; утилізація GPU низька і стрибкоподібна

Корінна причина: Вузьке місце в pipeline даних (I/O, препроцесинг CPU, недостатньо воркерів), часто посилюється використанням /mnt/c.
Виправлення: Перемістіть датасети в WSL ext4; збільште кількість воркерів data loader; шардируйте файли; слідкуйте за %iowait і sm GPU під час запусків.

7) Симптом: випадкові сегфолти або «illegal instruction» після встановлення CUDA toolkit

Корінна причина: Конфлікти бібліотек між CUDA-пакетами дистрибутиву і інтеграційними бібліотеками WSL; інколи змішування репозиторіїв.
Виправлення: Проведіть аудит ldconfig -p, видаліть конфліктні пакети, уникайте перезапису критичних бібліотек через LD_LIBRARY_PATH.

8) Симптом: GPU видимий, але OOM відбувається раніше, ніж очікувалось

Корінна причина: Неправильне читання використання VRAM (кешування фреймворку), або тиск пам’яті у WSL на боці CPU, що виглядає як проблема GPU.
Виправлення: Використовуйте nvidia-smi для інспекції VRAM і free -h для огляду пам’яті/swap; налаштуйте batch size і pipeline пам’яті.

Контрольні списки / покроковий план

Чеклист A: Чистий базис для обчислень на GPU у WSL (орієнтований на NVIDIA)

Windows: Встановіть актуальний драйвер NVIDIA з підтримкою обчислень у WSL. Перевірте за допомогою nvidia-smi.exe.
Windows: Переконайтеся, що WSL актуальний: wsl.exe --version має показувати сучасні компоненти.
WSL: Переконайтеся, що ваш дистрибутив — WSL2: wsl.exe -l -v.
WSL: Підтвердіть пристрій-мост GPU: ls -l /dev/dxg.
WSL: Підтвердіть стек керування: nvidia-smi.
WSL: Підтвердіть резолюцію бібліотек: ldconfig -p | grep libcuda має вказувати на /usr/lib/wsl/lib.
WSL: Запустіть smoke test фреймворку (PyTorch/TensorFlow).

Чеклист B: Перевірка продуктивності для ML-навантажень

Тримайте датасети у WSL ext4, а не в /mnt/c. Перевірте за допомогою df -Th.
Під час тренувань спостерігайте GPU: nvidia-smi dmon -s pucm -d 1.
Під час тренувань стежте за iowait CPU: mpstat -P ALL 1.
Якщо iowait високий — бенчмаркуйте шлях диска за допомогою dd (або кращих інструментів) і виправляйте макет даних.
Якщо CPU завантажений, але iowait низький — зменшіть вартість препроцесингу, збільште воркерів і кешуйте декодовані дані.

Чеклист C: Шлях з Docker (тільки якщо потрібно)

Спочатку доведіть, що GPU працює у WSL без контейнерів (nvidia-smi і тест фреймворку).
Потім протестуйте відомий CUDA-базовий образ з docker run --gpus all ... nvidia-smi.
Якщо контейнер не працює: трактуйте це як проблему інтеграції рантайму, а не GPU.
Зафіксуйте версію базового образу CUDA під очікувану версію фреймворку. Уникайте «latest», якщо не любите археологію.

Питання та відповіді

1) Чи потрібно встановлювати Linux-драйвер NVIDIA у WSL?

Зазвичай — ні. Обчислення GPU у WSL покладається на драйвер Windows і інтеграційний шар WSL.
Встановлення Linux-ядрових драйверів у WSL часто створює конфлікти бібліотек і нестабільність.

2) Якщо у Windows `nvidia-smi.exe` працює, чому у WSL `nvidia-smi` не працює?

Тому що «драйвер встановлено» — це необхідна, але не достатня умова. WSL потребує мосту до GPU (/dev/dxg) і правильних userland-бібліотек.
Якщо /usr/lib/wsl/lib ігнорується або перезаписаний, інструменти у WSL можуть падати.

3) Яка найшвидша перевірка «GPU доступний у WSL»?

Перевірте ls -l /dev/dxg. Якщо його немає — шлях обчислень відсутній.
Потім запустіть nvidia-smi як подальшу перевірку.

4) Чому тренування на GPU в WSL іноді працює повільніше, ніж на рідному Linux?

Часто проблема не в шляху GPU — а в зберіганні та файлових операціях. Тренування з /mnt/c може бути драматично повільнішим для робіт із великою кількістю метаданих.
Перенесіть дані в WSL ext4 і спостерігайте за утилізацією GPU.

5) Чи можу я використовувати AMD GPU для обчислень у WSL?

Є варіанти (зокрема DirectML для певних стеків), але екосистема CUDA значно орієнтована на NVIDIA.
Якщо ваші залежності залежать від бібліотек CUDA — плануйте NVIDIA апаратне забезпечення і драйвери.

6) Docker не бачить мій GPU у WSL. Яка типова причина?

Відсутня або неправильно налаштована інтеграція GPU для контейнерів, або просто забули використати --gpus all.
Доведіть, що GPU працює поза Docker, а потім налагоджуйте шар контейнерів.

7) Чи потрібен повний CUDA toolkit у WSL для запуску PyTorch або TensorFlow?

Не завжди. Багато збірок фреймворків включають необхідні CUDA userland-бібліотеки (або очікують певні).
Встановлюйте toolkit тільки якщо ви компілюєте CUDA-код або маєте специфічну залежність.

8) Чому `nvidia-smi` показує версію CUDA, яка не збігається з моїм toolkit?

Версія CUDA в nvidia-smi відображає максимальну підтримку драйвера.
Ваш toolkit/фреймворк — це окремий userland-компонент. Невідповідність не завжди означає помилку; проблема виникає при сумісності.

9) Чи достатньо стабільна підтримка GPU у WSL для продакшн-тренувань?

Для багатьох команд — так, особливо для робочих станцій розробників і повторюваних CI-процесів.
Для ситуацій «це наш єдиний кластер для тренувань» варто мати оперативний контроль на рівні рідного Linux-сервера, але WSL може бути цілком придатним для багатьох робочих сценаріїв.

Практичні наступні кроки

Визначте цільовий стек. Тільки фреймворк (простіше) або компіляція кастомного CUDA (потрібен toolkit). Перестаньте змішувати цілі.
Доведіть ланцюжок по порядку. Драйвер Windows → WSL2 → /dev/dxg → nvidia-smi → GPU-проб фреймворку → (опційно) тест Docker.
Перенесіть дані з /mnt/c для тренувань. Якщо нічого більше не зробите для продуктивності — зробіть це.
Зафіксуйте версії і додайте smoke test. Одномінутна автоматична перевірка краще тижня «а вчора ж було ок» щоразу.

Якщо ви будете ставитися до GPU у WSL як до системи — з її залежностями, контрактами і процедурою верифікації — вона поводитиметься як система.
Якщо трактуватимете її як фокус-покус — рано чи пізно вона покаже класичний трюк: зникне прямо перед дедлайном.