Дешеві GPU: чому вони знову стануть важливими

Ваш рахунок за GPU вам бреше. Не тому, що рахунки неправильні, а тому, що ви платите за пік можливостей, якого рідко досягаєте, тоді як реальний вузький профіль сидить у чомусь буденному: PCIe‑лінії, ємність VRAM, стабільність драйверів або та модель, що наполягає на викиданні тензорів у пам’ять хоста.

Тим часом команди продовжують купувати флагманські акселератори для задач, які виглядають як обчислення, але поводяться як планування, пам’ять і надійність. «Низькопрофільний» GPU знову набуде популярності — не як утешний приз, а як найбільш прагматичний спосіб масштабувати inference, відео та edge‑завантаження без перетворення вашого дата‑центру на обігрівач із почуттями.

Що змінилося: чому «дешеві GPU» знову мають сенс

Термін «низькопрофільний GPU» навантажений змістом. Він натякає на слабкість. Насправді це означає пристрій із обмеженим VRAM, нижчою пропускною здатністю обчислень і зазвичай більш дружніми характеристиками щодо енергоспоживання та вартості — часто оптимізований для блоків фіксованої функції (кодування/декодування відео), режимів числення, дружніх до inference, або просто доступності.

Колись низькопрофільні GPU були соромом у серверних. Якщо у вас був такий — значить постачання провалилося або хтось випадково замовив «з графікою» у списку деталей. Потім сталося три речі:

1) Inference з’їв світ, і inference не масштабується як тренування

Тренування любить великі GPU. Inference любить достатній GPU — достатній VRAM, достатню пропускну здатність, достатню конкуренцію — і тоді це перетворюється на задачу теорії черг і контролю витрат. Багато робочих навантажень для inference насичують пропускну здатність пам’яті або досягають стелі VRAM задовго до того, як наситять обчислення.

Якщо ваша модель комфортно вміщується й розміри batch‑ів помірні, ви можете масштабуватися горизонтально з більшою кількістю менших GPU. Ваші SLA турбуються про p95 і p99 латентність; ваш фіндиректор — про $/запит. Обидві сторони зазвичай віддають перевагу «багатьом адекватним пристроям» над «кількома геройськими», особливо коли трафік стрибкоподібний.

2) Відео та задачі з обробки зору тихо прив’язані до GPU найпростіше

Транскодування, композитинг, реальний час inference на потоках камер — часто обмежені апаратними блоками кодування/декодування, копіюваннями пам’яті та обв’язкою конвеєра. Низькопрофільний GPU із сильними медійними блоками може перевершити вищий клас обчислювального GPU для конкретних пайплайнів, бо він виконує роботу в фіксованому апаратному забезпеченні, тоді як ваш дорогий акселератор стоїть як спортивний автомобіль за трактором.

3) Справжній ворог — це енергія, місце та операційний ризик

Щільність потужності та охолодження тепер — первинні обмеження. «Просто додайте більші GPU» натрапляє на ліміти стійок, автоматів захисту та факт, що ваш графік on‑call теж має почуття. Низькопрофільні GPU часто мають кращу продуктивність на ват в окремих завданнях inference/медіа й дозволяють розміщувати більше пристроїв у стійці без переробки електрики.

Є ще операційний ризик: флагманські плати привертають увагу, але вони також додають складності — екзотичні інтерконекти, спеціальна прошивка, примхливі топології та дорогі відмови. Менші GPU легше розмістити, легше замінити і легше упакувати по контейнерах у гетерогенних кластерах.

І так, доступність має значення. Коли всі хочуть одну й ту саму SKU топрівня, ваш план масштабування перетворюється на трилер закупівель. Низькопрофільні SKU можуть стати різницею між відвантаженням і очікуванням.

Історичний контекст і факти (коротко та по суті)

Ось кілька опорних пунктів, що пояснюють, чому низькопрофільний GPU постійно повертається — як розумні черевики, які ви весь час намагаєтесь замінити на модні непрактичні.

1. GPU стали «загального призначення» завдяки CUDA (епоха ~2007), що перетворило графічне залізо на обчислювальну платформу і змінило HPC та ML. Цей зсув також створив повторювану схему: топ‑рівень для проривів, низький рівень для масштабу.
2. Перша велика хвиля deep learning на GPU (початок 2010‑х) частково використовувала споживчі GPU, бо вони були доступні, дешеві й «достатні» для експериментів. У продукції згодом знову засвоїли той самий урок для inference.
3. Tensor‑ядра (Volta, близько 2017) змінили цінність: апарат, спеціалізований на матричній математиці, зробив inference швидшим, але тільки якщо ваш стек програмного забезпечення й режими точності працюють разом.
4. NVENC/NVDEC стали серйозними інфраструктурними примітивами — кодування/декодування відео перемістилося від CPU‑зв’язаної проблеми до GPU‑підтримки для стрімінгу та систем спостереження.
5. Топологія PCIe роками була мовчазним вбивцею: ваш «GPU‑сервер» може бути насправді «сервером зі спільним аплінком», де кілька пристроїв борються за один root complex CPU.
6. MIG і розбиття GPU популяризували ідею, що не кожному навантаженню потрібен весь GPU. Навіть коли MIG недоступний, бізнес‑урок лишається: менші шматки простіше планувати.
7. Квантизація (INT8, FP8, 4‑bit) зробила малий VRAM більш корисним — раптово моделі, які вимагали великих GPU, можуть вміститися на середніх або навіть низькопрофільних пристроях з прийнятною якістю для багатьох задач.
8. Edge‑inference став нормою: аналітика в ритейлі, QA для виробництва, робототехніка. Надсилати 700W монстра в запилений шафовий стенд — це шлях створити пожежну тривогу (іноді буквально).
9. Стабільність драйверів і ядра стала диференціатором: у продакшні приріст продуктивності на 5% не вартий щотижневого перезапуску. Низькопрофільні GPU іноді живуть на більш консервативних гілках драйверів, бо їх розгортають у великому масштабі.

Де низькопрофільні GPU перемагають у 2026

Низькопрофільні GPU знову важливі, бо найпоширеніші робочі навантаження в продукції — це не «тренувати кордонну модель», а «обслуговувати моделі та медіа надійно з передбачуваною вартістю». Ось де менші акселератори можуть бути правильним інструментом.

Високоволюмний, чутливий до латентності inference

Якщо ви подаєте embedding‑і, reranker‑и, невеликі‑середні LLM, OCR, ASR, класифікацію зображень, детекцію аномалій — ваші найбільші проблеми зазвичай:

• Вміщення у VRAM: чи помістяться модель + KV cache + накладні витрати рантайму без сторінкування або фрагментації?
• Конкурентність: чи вдається тримати GPU завантаженим декількома невеликими запитами без вибухового збільшення латентності?
• Планування: чи може ваш оркестратор розподілити роботу, не залишаючи ресурси марними?

Для них кілька низькопрофільних GPU можуть показувати кращу сумарну пропускну здатність під реальним трафіком, бо ви уникаєте блокування голови черги. Один великий GPU може бути надзвичайно швидким — допоки один надмірний запит (або batch, що «дружньо» збільшили) не затримує все інше позаду нього.

Медіа‑пайплайни (транскодування, live‑стримінг, відеоаналітика)

Класичний випадок, де низькопрофільний GPU перемагає, бо продуктивність домінують блоки фіксованої функції. Якщо ваш пайплайн — «decode → resize → inference → encode», менший GPU з потужними NVENC/NVDEC (або еквівалентом) і пристойною пропускною здатністю пам’яті може забезпечити високу щільність стрімів на ват.

І операційно медіа‑ферми хочуть передбачувану поведінку. Ви не хочете рідкісних kernel panic через гілку драйвера, оптимізовану під великі тренувальні кластери. Ви хочете нудність.

Edge і near‑edge розгортання

Edge‑середовища мають обмеження, що роблять «великий GPU» антипатерном:

• Бюджети потужності виглядають як «що зможе видати ця розетка».
• Охолодження — як «вентилятор і надія».
• Доступ на місці вимірюється днями, а не хвилинами.

Низькопрофільні GPU дають можливість розгортати прискорення там, де CPU‑Only не встигає по SLA, не перетворюючи сайт на пастку для обслуговування.

Багатокористувальні внутрішні платформи

Внутрішні платформи «GPU як послуга» ламаються через фрагментацію. Кілька монстр‑GPU важко ділити безпечно; малі GPU легше призначати команді, середовищу або домену ризику. Навіть при віртуалізації фізичні менші одиниці зменшують радіус ураження.

Жарт №1: 4090 у спільному кластері — як прийти з фаєрбразером на церемонію запалення свічок. Працює, але відділ кадрів має питання.

Як обирати: обмеження, які справді мають значення

Якщо ви купуєте низькопрофільні GPU, не шукайте за «максимумами» та маркетинговими назвами. Шукай виробу за обмеженнями. Ваше завдання — не купити найшвидший чіп; воно — купити залізо, яке рідше дає збій і при цьому виконує SLA з найнижчою загальною вартістю.

Обмеження 1: ємність VRAM і поведінка VRAM

VRAM — це не тільки ємність; це також те, як пам’ять виділяється, фрагментується та звільняється в рантаймі. Дві неприємні істини:

• Моделі вміщуються на папері, але падають у реальності, бо накладні витрати рантайму, CUDA graphs, поведінка аллокатора і ріст KV cache з’їдають запас.
• Фрагментація — це проблема продукції, особливо з довго працюючими серверами inference, які завантажують/розвантажують моделі або обробляють змінні розміри batch‑ів.

Купівля трохи більшого SKU з VRAM може бути дешевшою за витрачені тижні на «оптимізацію пам’яті», поки відбувається сторінкування в RAM хоста і горять латентності.

Обмеження 2: пропускна здатність пам’яті переважає обчислення для багатьох inference‑навантажень

Багато трансформерних inference‑завдань голодні до пропускної здатності. Коли ви квантуєте, ви знижуєте потребу в ширині смуги і зміщуєте баланс. Але якщо ядра все ще прив’язані до пам’яті, GPU з кращою пропускною пам’яті (або кращою поведінкою кешу) може перемогти «вищий обчислювальний» GPU.

Обмеження 3: PCIe‑лінії, NUMA і платформа хоста

Низькопрофільні GPU часто розгортають у більшій кількості на хості. Тут має значення платформа: кількість PCIe‑ліній, топологія сокетів CPU і чи ділиться ваш NIC тим самим root complex, що й GPU.

Класична відмова: чотири GPU фізично в слоті «x16», але електрично працюють як x8 або x4, або всі підключені до одного CPU‑сокета, тоді як ваше навантаження фіксує пам’ять на іншому. Ви можете втратити шокуючу кількість пропускної здатності через топологію.

Обмеження 4: енергія і охолодження — ваші реальні вхідні дані для планування ємності

Продакшн не працює на бенчмарках; він працює на бюджетах потужності. Низькопрофільні GPU дозволяють упакувати більше акселераторів у стійку при меншому ватажі на пристрій, часто покращуючи стійкість, бо ви можете втратити пристрій і все ще мати ємність.

Обмеження 5: зрілість гілки драйверів і домени відмов

У продакшні «кращий» драйвер — це той, що не розбудить вас. Якщо ви розгортаєте велику флотилію, ваша первинна характеристика GPU не FP16‑пропускна здатність, а середній час між неприємними сюрпризами.

Є принцип надійності, який варто закріпити на моніторі. John Allspaw чітко сформулював: «Ви не можете покращити те, що не вимірюєте.» Оце й є вся історія GPU‑операцій: вимірюйте, а потім приймайте рішення.

Швидкий план діагностики: знайдіть реальний вузький профіль швидко

Це план, який я хотів би, щоб більше команд використовували перед тим, як замовляти залізо, переписувати код або ескалювати до вендорів. Він призначений для «inference/відео‑пайплайн повільний або нестабільний». Виконуйте по порядку. Зупиніться, коли знайдете димлячий стовбур.

Перш за все: підтвердіть, що GPU дійсно виконує роботу

• Перевірте завантаження, частоти і споживання потужності під навантаженням.
• Підтвердіть, що ваш рантайм використовує очікуваний пристрій і режим точності.
• Перевірте, чи не є ваші запити CPU‑зв’язаними на етапах препроцесінгу/постпроцесінгу.

По‑друге: перевірте запас VRAM і поведінку аллокатора

• Шукайте VRAM, близький до ліміту, часті алокації або відновлення після OOM.
• Слідкуйте за ростом пам’яті хоста (pinned memory, page cache) як симптомом витіснення.

По‑третє: перевірте топологію PCIe і NUMA

• Перевірте ширину/швидкість лінку.
• Підтвердіть, що GPU та NIC не конкурують на спільному аплінку.
• Переконайтеся, що CPU‑афінність і розміщення пам’яті мають сенс.

По‑четверте: валідируйте налаштування batch/конкурентності щодо p95/p99

• Висока пропускна здатність може ховати жахливу хвостову латентність.
• Подивіться на черги та розподіл розмірів запитів.

По‑п’яте: перевірте теплове та енергетичне тротлінг

• Низькопрофільні GPU не імунні. Маленькі кулери + запилені стійки = різке падіння частот.
• Енергетичні ліміти можуть бути встановлені за замовчуванням вендором або політикою дата‑центру.

По‑шосте: підозрюйте проблеми драйверів/рантайму лише після перевірки основ

• Так, драйвери можуть бути ненадійні. Ні, вони не перша гіпотеза.
• Але якщо ви бачите Xid‑помилки або скидання GPU, розглядайте це як інцидент: збирайте логи, корелюйте з темпами й потужністю та пом’якшуйте.

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

Ці завдання написані для Linux‑хостів з NVIDIA GPU, бо це найпоширеніша продукційна конфігурація. Принципи переносяться на інших вендорів, але команди будуть відрізнятися. Кожне завдання включає: команду, що означає вивід і яке рішення прийняти.

Завдання 1: Підтвердити наявність GPU і визначити точні моделі

cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d|nvidia'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)
65:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)

Значення: Хост бачить два GPU на PCIe з їхніми vendor/device ID.

Рішення: Якщо GPU відсутній або показує «Unknown device», зупиніться і виправте апаратну/прошивку посадку, налаштування BIOS або конфігурацію IOMMU перед тим, як торкатися софту.

Завдання 2: Перевірити завантаження драйвера і коректність побачення пристроїв ядром

cr0x@server:~$ lsmod | grep -E '^nvidia|^nouveau'
nvidia_uvm           1208320  0
nvidia_drm             73728  2
nvidia_modeset       1200128  1 nvidia_drm
nvidia              62836736  85 nvidia_uvm,nvidia_modeset

Значення: Модулі ядра NVIDIA завантажені; Nouveau не активний.

Рішення: Якщо Nouveau завантажений на продакшн‑хості inference, внесіть його в чорний список і перезавантажте. Змішані стеки — це податок на надійність.

Завдання 3: Швидкий знімок стану (завантаження, температура, енергоспоживання)

cr0x@server:~$ nvidia-smi
Wed Jan 21 09:12:01 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    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  Tesla T4              On  | 00000000:01:00.0 Off |                    0 |
| 30%   63C    P0    68W /  70W |  1245MiB / 15360MiB  |     92%      Default |
|-------------------------------+----------------------+----------------------+
|  1  Tesla T4              On  | 00000000:65:00.0 Off |                    0 |
| 28%   61C    P0    66W /  70W |  1219MiB / 15360MiB  |     89%      Default |
+-----------------------------------------------------------------------------+

Значення: GPU завантажені, під навантаженням, майже на енергетичному ліміті, висока завантаженість, нормальні температури.

Рішення: Якщо GPU‑Util низький, а ваша служба повільна — перестаньте думати «потрібен більший GPU». Ймовірно, ви CPU‑зв’язані, IO‑зв’язані або блокуєтеся на копіюваннях.

Завдання 4: Спостерігати завантаження з часом, щоб уловити стрибкоподібність та хвості

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr gtemp mtemp   sm   mem   enc   dec  mclk  pclk
# Idx     W     C     C    %     %     %     %   MHz   MHz
    0    69    64     -   96    43     0     0  5001  1590
    1    68    62     -   12     8     0     0  5001   405
    0    70    65     -   97    44     0     0  5001  1590
    1    69    62     -   95    41     0     0  5001  1590

Значення: GPU 1 іноді простає, іноді навантажений — розподіл роботи нерівний.

Рішення: Виправте балансування навантаження або вибір пристрою (round‑robin, dispatch на основі черги). Купівля додаткових GPU не вирішить планувальник, що має уподобання.

Завдання 5: Підтвердити ширину і швидкість PCIe (продуктивність може залежати від цього)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (ok), Width x8 (downgraded), TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

Значення: Слот підтримує x16, але пристрій працює як x8. Це може бути нормальним — або прихованим обмежувачем пропускної здатності, якщо ви переміщуєте багато даних.

Рішення: Якщо ви робите важкі трансфери host↔GPU (відеокадри, великі входи), дослідіть зниження: проводка слоту, riser, настройки біфуркації або спільне використання з іншими пристроями.

Завдання 6: Простежити відповідність GPU до NUMA‑вузла і перевірити штрафи за крос‑сокет

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    NIC0    CPU Affinity    NUMA Affinity
GPU0     X      PHB     PHB     0-31            0
GPU1    PHB      X      PHB     32-63           1
NIC0    PHB     PHB      X

Значення: GPU0 локальний для NUMA‑вузла 0, GPU1 для NUMA‑вузла 1. CPU‑афінність відрізняється.

Рішення: Закріпіть процеси й пам’ять за локальним NUMA‑вузлом для кожного GPU. Ігнорування цього призведе до того, що ви звинуватите «повільність GPU» у трафіку QPI/UPI.

Завдання 7: Перевірити насичення CPU і час steal (GPU може чекати на CPU)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server)  01/21/2026  _x86_64_  (64 CPU)

09:13:10 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
09:13:11 AM  all   62.10  0.00  7.90   0.20 0.00  0.60   0.00 29.20
09:13:11 AM   0    2.00  0.00  1.00   0.00 0.00  0.00   0.00 97.00
09:13:11 AM  17   98.00  0.00  2.00   0.00 0.00  0.00   0.00  0.00

Значення: Одне ядро завантажене під зав’язку. Це може бути однониткове вузьке місце у препроцесінгу, мережі або Python.

Рішення: Виправте однонитковий «гарячий» фрагмент (векторизуйте, паралелізуйте, перенесіть препроцесинг на GPU або розділіть воркери). Не «апґрейджуйте GPU», щоб вирішити помилку CPU‑серіалізації.

Завдання 8: Перевірити дискові I/O і поведінку page cache (завантаження моделей, swap‑шторм)

cr0x@server:~$ iostat -xz 1 2
Linux 6.8.0 (server)  01/21/2026  _x86_64_  (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          61.4    0.0     7.9     0.2     0.0    30.5

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz   w/s   wkB/s w_await aqu-sz  %util
nvme0n1         15.0   12800.0     0.0    0.0    2.1    853.3    2.0   512.0   1.3   0.04    8.0

Значення: Сховище не завантажене. Якщо завантаження моделей повільні, проблема ймовірно у декомпресії, мережевих скачуваннях або конкуренції файлової системи в інших місцях.

Рішення: Якщо ви бачите високі await/%util під час деплоїв, подумайте про локальне кешування моделей, «прогрів» і уникнення повторних скачувань. Повільний холодний старт змушує низькопрофільні GPU виглядати «повільними».

Завдання 9: Перевірити тиск на RAM і свапінг (робота GPU може застопоритися, коли хост трясеться)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       198Gi        11Gi       2.1Gi        42Gi        38Gi
Swap:           16Gi       9.2Gi       6.8Gi

Значення: Swap використовується. Це може бути нормально або симптомом перевантаження (занадто багато воркерів, занадто великі кеші, забагато моделей завантажено).

Рішення: Якщо стрибки латентності корелюють зі swap‑активністю, зменшіть тиск на хост‑пам’ять: знизьте конкуренцію, зменшіть кількість моделей на хості або додайте RAM. Не «вирішуйте» swap більшим GPU.

Завдання 10: Переглянути логи ядра на предмет скидань GPU і Xid‑помилок (надійність продукції)

cr0x@server:~$ sudo dmesg -T | grep -iE 'NVRM|Xid' | tail -n 5
[Wed Jan 21 08:41:17 2026] NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
[Wed Jan 21 08:41:18 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:01:00.0
[Wed Jan 21 08:41:19 2026] NVRM: GPU 0000:01:00.0: GPU recovery action changed from 0x0 (None) to 0x1 (Reset).

Значення: GPU тимчасово зник з шини PCIe. Це не «програмна помилка, поки не доведено протилежне». Часто причина — енергопостачання, теплові події, riser або материнська плата.

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

Завдання 11: Підтвердити, що контейнери бачать GPU і ви не непомітно падаєте на CPU

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi -L
GPU 0: Tesla T4 (UUID: GPU-6ce9c2b0-1b9e-3d2f-a2c1-bf2a0b2a1d9a)
GPU 1: Tesla T4 (UUID: GPU-9a0c9a12-8b5b-42a8-8f5c-7b6b9b3b1c2d)

Значення: Рантайм контейнера коректно експонує GPU.

Рішення: Якщо це не вдається, виправте конфігурацію NVIDIA Container Toolkit/рантайму перед дебагом коду моделі. «Моя модель повільна» іноді означає «вона працює на CPU».

Завдання 12: Виміряти end‑to‑end латентність і розбити її по частинах (не гадати)

cr0x@server:~$ curl -s -w '\nlookup:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n' -o /dev/null http://127.0.0.1:8080/infer
lookup:0.000021 connect:0.000112 ttfb:0.084391 total:0.092507

Значення: Мережа незначна; сервер витрачає ~80–90ms до першого байта. Це ваш додаток + інференс‑пайплайн.

Рішення: Порівняйте з таймінгами GPU (нижче). Якщо GPU‑ядра займають лише 10ms, ваш вузький профіль — препроцесинг, черги або постпроцесинг.

Завдання 13: Перевірити список процесів на GPU і використання пам’яті (знайти галасливих сусідів)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu   pid   type    sm   mem   enc   dec   command
    0  21433     C    92    40     0     0   python3
    0  22010     G     -     -     -     -   Xorg
    1  21501     C    88    38     0     0   python3

Значення: Є compute‑процеси (і можливо випадковий display‑процес). Використання пам’яті й SM дає швидку перевірку здоров’я.

Рішення: Якщо один процес несподівано пожирає VRAM або SM, ізолюйте навантаження (окремі ноди/пули, накладайте ліміти або переведіть на одно‑GPU сервіси).

Завдання 14: Підтвердити енергетичні ліміти і чи не обмежують вас вони

cr0x@server:~$ nvidia-smi -q -d POWER | sed -n '1,30p'
==============NVSMI LOG==============

Timestamp                                 : Wed Jan 21 09:15:11 2026
Driver Version                            : 550.54.14

Attached GPUs                             : 2
GPU 00000000:01:00.0
    Power Readings
        Power Management                  : Supported
        Power Draw                        : 68.52 W
        Power Limit                       : 70.00 W
        Default Power Limit               : 70.00 W
        Enforced Power Limit              : 70.00 W
        Min Power Limit                   : 60.00 W
        Max Power Limit                   : 70.00 W

Значення: GPU працює на енергетичному ліміті. Це може бути нормально; може означати, що ви тротлите.

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

Три міні‑історії з реального досвіду

Міні‑історія 1: Інцидент через невірне припущення

Вони мігрували внутрішній пошуковий сервіс з CPU‑inference на GPU. Це була звична історія: час відповіді підіймався під час обіду, керівники помічали, команда під тиском. Вони купили партію малих GPU, бо моделі «малі». На папері це здавалося ідеальним рішенням.

Невірне припущення було підступним: вони вважали, що модель — це єдине, що потребує VRAM. Насправді сервіс використовував динамічний батчинг, підтримував кілька варіантів моделі «гарячими» і зберігав кеш embedding‑ів по запиту на GPU для швидкодії. Вони також запускали один зайвий «debug» воркер на кожному хості, який ніколи не видаляли, бо був зручний під час релізу.

Усе працювало в staging. Продукційний трафік мав важчий хвіст — довші запити, більші payload‑и, більше одночасних запитів. VRAM піднімався протягом днів через фрагментацію аллокатора і кешування. В підсумку p99 латентності стрибнули, потім почалися жорсткі OOM. Рантайм намагався відновитися, вивантажуючи й завантажуючи моделі, що шалено навантажувало PCIe і виглядало як DDoS.

Інженер on‑call зробив те, що роблять о 2‑й ранку: перезапустив поди. Допомогло на годину, потім паттерн повторився. Інцидент діагностували, корелювавши зріст VRAM із розподілом розмірів запитів і показниками кеш‑хітів. Виправлення не було «більший GPU», а: обмежити кеш на GPU, попередньо алокувати пул пам’яті і рознести варіанти моделі по окремих пристроях, щоб фрагментація не змішувала несумісні патерни алокацій.

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

Міні‑історія 2: Оптимізація, що відсікала назад

Медіа‑команда керувала фермою транскодування з малими GPU. Хтось помітив, що завантаженість GPU не максимальна, тому збільшили конкуренцію і ввімкнули більші батчі для препроцесінгу. Пропускна здатність у синтетичному бенчмарку покращилася. Всі вітали одне одного. Тікет закрили словами «вільна продуктивність».

У продакшені зміна тихо перевела систему з «обмеженої обчисленнями» в «обмежену чергою». Більші батчі покращили середню пропускну здатність, але збільшили затримку в черзі. Для інтерактивних стрімів хвостова латентність важила більше, ніж середня. P95 почав дрейфити; P99 впав за край. Гірше — нова конкуренція викликала більш часті сплески VRAM під час переходів кодеків, і аллокатор почав фрагментуватися під змішаними роздільностями.

Другорядний ефект був операційний: коли латентність стрибнула, автоскейлер побачив «більше роботи», підняв більше подів і створив гуркіт холодних стартів. Вагонетки з вагонами вагонів завантажували моделі й бібліотеки кодеків повторно, розбиваючи артефактне сховище. Ферма виглядала перевантаженою, але це було здебільшого самозаподіяне навантаження.

Ролбек виправив симптоми миттєво. Постмортем‑урок не був «не оптимізуйте». Він полягав у тому: оптимізуйте під метрику, яка платить вашу зарплату. Для стрімінгу це хвостова латентність і стабільність, а не пікова пропускна здатність у лабораторії. Вони обережно повернули конкуренцію з обмеженнями: окремі пули по класу роздільності, фіксований максимум батчу за типом стріму і прогрівані пули, щоб уникнути каскадів холодних стартів.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Команда ML‑платформи керувала гетерогенною флотилією GPU: деякі низькопрофільні карти для inference, деякі середнього класу, кілька великих залишені для експериментів. У них була репутація «надто обережних», що — як люди називають вас, коли ви запобігаєте інцидентам, яких інші ніколи не бачили.

Вони наполягали на трьох нудних практиках: (1) закріплювати версії драйверів по пулу нод, (2) запускати канарний пул для будь‑яких змін драйвера/рантайму GPU, і (3) збирати лічильники помилок GPU і метрики PCIe AER у ту саму панель, що й латентність додатка. Ніяких винятків, навіть для «термінових» оновлень.

Одного тижня новий реліз драйвера пройшов базові smoke‑тести. Але канарний пул показав низький, але постійний рівень скоригованих помилок PCIe. Ніякого впливу на клієнтів — ще. Через два дні ті самі ноди почали логувати поодинокі Xid‑події під максимальним трафіком. Оскільки метрики вже були підключені, команда корелювала спайки помилок з конкретною материнською платою і конкретним налаштуванням BIOS, пов’язаним з енергоменеджментом PCIe.

Вони заморозили розгортання, відкоригували налаштування BIOS у наступному вікні технічного обслуговування і замінили кілька сумнівних riser‑ів. Інцидент ніколи не став аварією. Єдина «подія» — тихий графік, що перестав бути дивним.

Жарт №2: Найнадійніша функція GPU — це canary‑розгортання. Воно не має tensor‑ядер, але дає сон.

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

1) Симптом: низька завантаженість GPU, але висока латентність

Корінь: CPU‑препроцесинг (токенізація, зміна розміру), Python‑GIL вузькі місця або синхронні RPC‑затримки домінують.

Виправлення: Профілюйте CPU, перенесіть препроцесинг у векторні бібліотеки, паралелізуйте або виконуйте препроцесинг на GPU. Перевірте це розбиттям енд‑ту‑енд таймінгів.

2) Симптом: відмінна пропускна здатність у тестах навантаження, жахливий p99 у продукції

Корінь: Надто великі батчі або надмірна конкуренція викликають затримання в чергах; трафік має важчий хвіст, ніж тести.

Виправлення: Налаштуйте під хвостову латентність: обмежте розмір батчу, реалізуйте admission control, розділіть класи запитів і моніторьте глибину черги.

3) Симптом: випадкові OOM після днів роботи

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

Виправлення: Попередньо алокуйте пули, обмежте кеші, уникайте частого unload/load моделей, періодично перезапускайте в контрольований спосіб, але розглядайте це як пом’якшення, а не лікування.

4) Симптом: GPU іноді «випадає зі шини»

Корінь: Проблеми цілісності PCIe (riser/кабель), нестабільність живлення, теплові події, енергоменеджмент BIOS або марґінальне апаратне забезпечення.

Виправлення: Перевірте AER логи, перепідключіть/замініть riser‑и, оновіть BIOS, налаштуйте PCIe ASPM/енергопараметри, валідуйте охолодження та ізолюйте проблемні хости.

5) Симптом: хост з кількома GPU працює гірше, ніж хост з одним GPU

Корінь: PCIe‑oversubscription, contention на спільному root complex, NUMA‑неправильне розміщення або NIC/GPU, що конкурують за пропускну здатність.

Виправлення: Валідируйте топологію, переконайтеся, що GPU розподілені по сокетах CPU адекватно, закріпіть CPU/пам’ять і розгляньте меншу кількість GPU на хост, якщо ліній бракує.

6) Симптом: висока завантаженість GPU, але низька пропускна здатність запитів

Корінь: GPU зайнятий неефективними ядрами (неправильна точність, погана стратегія батчингу) або застиг на пропускній здатності пам’яті.

Виправлення: Перевірте режим точності, увімкніть оптимізовані ядра, квантуйте там, де доречно, і перевірте, чи робота прив’язана до пам’яті. Іноді «низькопрофільний GPU» підходить; проблема в обранні ядер.

7) Симптом: сплески латентності під час деплоїв

Корінь: Холодні старти моделей, повторні скачування артефактів, дискова конкуренція або інвалідизація кешу, що викликає thundering herd.

Виправлення: Прогріті пули, локальне кешування, поетапні релізи і тримайте моделі резидентними де можливо.

Чеклісти / покроковий план

Покроково: вирішуємо, чи підходять низькопрофільні GPU

1. Охарактеризуйте навантаження. Це тренування, офлайн‑batch inference, онлайн‑inference чи обробка медіа? Низькопрофільні GPU блискучі в останніх двох.
2. Виміряйте поточний вузький профіль. Використайте швидкий план діагностики. Якщо проблема в CPU або IO — апґрейд GPU лише театральний жест.
3. Визначте вимоги до VRAM з запасом. Включіть ваги моделі, активації, KV cache, накладні рантайму та конкуренцію. Додайте запас на фрагментацію і дрейф версій.
4. Визначте форму масштабування: scale up чи scale out. Якщо трафік стрибкоподібний і латентність важлива — масштабування горизонтально з більшою кількістю пристроїв часто кращe.
5. Плануйте платформу хоста. Порахуйтесь PCIe‑лінії, врахуйте NUMA і уникайте oversubscription. Не будуйте ферму на материнці, яка ставиться до PCIe як до опціонального декору.
6. Спершу план операцій. Визначте закріплення драйверів, канарі, метрики і межі доменів відмов перед тим, як коробки приїдуть.

Покроково: керування флотом низькопрофільних GPU без ненависті до життя

1. Стандартизуйте пули нод. Така сама модель GPU + той самий драйвер + той самий kernel на пул. Гетерогенність між пулами — ок; хаос у межах пулу — ні.
2. Інструментуйте все. Завантаження GPU, пам’ять, потужність, температура, лічильники помилок, латентність додатка, глибина черги.
3. Примусьте правила розміщення. Один сервіс на GPU, якщо можете. Якщо потрібно шарити — накладайте ліміти і ізолюйте галасливих сусідів.
4. Реалізуйте плавне деградування. Якщо GPU недоступний — або fail fast, або маршрутуйте на fallback‑рівень; не сповільнюйте запити мовчки до таймаутів.
5. Планування ємності з урахуванням потужності. Відслідковуйте ватти на хост і на стійку так само серйозно, як і ядра CPU.
6. Майте карантин для апаратури. Хости з скоригованими помилками PCIe або періодичними Xid‑подіями йдуть у карантин, а не назад у пул.

FAQ

1) Чи означає «низькопрофільний GPU» споживчі GPU?

Ні. Іноді так, але в продукції зазвичай йдеться про низькопотужні datacenter/inference SKU або робочі станції. Визначальна риса — обмеження, а не бренд.

2) Коли мені категорично не слід використовувати низькопрофільні GPU?

Коли вам потрібен великий VRAM для великих моделей без сильної квантизації, коли потрібний швидкий multi‑GPU interconnect для тренування, або коли ваше навантаження домінує одним гігантським batch‑завданням.

3) Чи підходять низькопрофільні GPU лише для INT8/квантизованого inference?

Квантизація значно допомагає, але не є обов’язковою. Багато малих‑середніх моделей працюють добре в FP16/BF16, якщо VRAM і пропускна здатність достатні. Ключ — поєднати точність і ядра з вашим SLA.

4) Скільки малих GPU краще за один великий?

Залежить від хвостової латентності і форми трафіку. Якщо навантаження — багато незалежних невеликих запитів, кілька менших GPU часто перемагають, бо ви зменшуєте черги і блокування голови черги.

5) Яку першу метрику дивитися під час інциденту?

End‑to‑end латентність, розбита на черги, препроцесинг, GPU‑compute і постпроцесинг. Саме по собі GPU‑util — не діагноз; це відчуття.

6) Чи справді PCIe так важливий для inference?

Так, коли ви переміщаєте значні дані на запит (відеокадри, великі тензори) або коли ви oversubscribe кілька GPU за обмеженими аплінками. Це також сигнал надійності: помилки PCIe сильно корелюють із «дивними випадковими відмовами».

7) Чи варто запускати кілька моделей на одному низькопрофільному GPU?

Іноді. Це може бути ефективно, але підвищує ризик фрагментації і робить продуктивність менш передбачуваною. Якщо вам важливий передбачуваний p99, віддавайте перевагу одному основному моделю на GPU та тримайте решту на окремих пристроях або пулах.

8) Яка найпоширеніша причина, через яку команди думають, що їм потрібні кращі GPU, а насправді ні?

CPU‑зв’язаний препроцесинг і погане батчинг/планування. GPU стоїть простаючи, поки CPU токенізує, змінює розмір, копіює і серіалізує запити.

9) Як зробити низькопрофільні GPU «безпечними» для продукції?

Канарні релізи драйверів, сильний моніторинг, жорстка стандартизація пулів нод і явні межі доменів відмов. Також: розглядайте скориговані апаратні помилки як попереджувальні індикатори, а не дрібниці.

Висновок: що робити наступного тижня

Низькопрофільні GPU повертаються, бо продукція дозріла. Блискуча частина ML — це тренування. Дорога частина — сервінг. Більшість організацій не потребують максимальної теоретичної пропускної здатності; їм потрібна передбачувана латентність, розумне споживання потужності і флот, яким справді можна керувати.

Наступного тижня зробіть це:

1. Прогрійте швидкий план діагностики на вашому найповільнішому сервісі і запишіть вузький профіль, який ви можете довести.
2. Заміряйте запас VRAM під реальним трафіком, включно з хвостовими запитами і churn деплойментів.
3. Аудит PCIe/NUMA топології на одному репрезентативному хості. Якщо там безлад, виправте платформу перед купівлею додаткових пристроїв.
4. Вирішіть форму масштабування: один великий GPU на хост чи кілька малих GPU на хост. Обирайте на основі хвостової латентності і доменів відмов, а не відчуттів.
5. Налаштуйте канарний пул для змін драйверів/рантайму GPU, якщо у вас його ще немає. Це дешевше за героїчні дії.

Якщо ви зробите ці п’ять речей, ви потрапите в рідкісну категорію команд, які купують залізо тому, що воно вирішує виміряну проблему, а не тому, що виглядає ефектно у слайдах. І це — суть низькопрофільних GPU: вони не гламурні. Вони ефективні. Продакшн любить ефективне.