Відео-движки GPU: H.264/H.265/AV1 і чому це важливо

Що таке відео-движок GPU насправді (і чим він не є)

Коли більшість людей говорять «транскодування на GPU», вони уявляють собі ядра CUDA, що пережовують кадри. Це неправильна модель мислення для більшості
виробничих відеосистем. Сучасні GPU (та багато iGPU) містять виділені блоки фіксованої функції для кодування/декодування відео. Ці блоки відокремлені від
3D/обчислювальних ядер і призначені для одного завдання: перетворювати необроблені кадри у стиснений бітпотік (encode) або навпаки (decode),
при передбачуваному споживанні енергії та затримці.

NVIDIA називає блок кодування NVENC, а блок декодування NVDEC. Intel називає це Quick Sync Video (QSV). AMD надає доступ через AMF і VCN.
Ці рушії мають власні межі пропускної здатності й власні обмеження по «сесіях». Вони часто доступні навіть коли обчислювальні ядра GPU зайняті,
тому ви можете кодувати відео під час навчання моделі — поки не настане момент, коли щось інше не насититься.

Ключова операційна відмінність: фіксована функція vs програмне кодування

Програмні енкодери (x264/x265, SVT-AV1) працюють на CPU і масштабуються за кількістю ядер, кешем і пропускною здатністю пам’яті. Вони можуть забезпечувати відмінну якість,
особливо на повільніших пресетах. Вони також охоче споживають увесь сервер, якщо дозволити.

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

Дві поширені хибні уяви, що викликають відмови

• Хибна уява: «Якщо завантаження GPU низьке, у мене є запас потужності.»
  Реальність: NVENC/NVDEC можуть бути насичені, хоча «завантаження GPU» виглядає низьким. Відео-двигун — окреме вузьке місце.
• Хибна уява: «Кодування — це складно, декодування дешеве.»
  Реальність: Декодування може домінувати, особливо при багатьох малих потоках, високих роздільностях, 10-бітному контенті або коли масштабування/конверсія відбуваються на CPU.

H.264, H.265, AV1: що змінюється в операційній роботі

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

H.264 (AVC): дефолт, від якого досі залежать усі

H.264 залишається кодеком «грає скрізь». Апаратна підтримка кодування/декодування універсальна й доросла. Якщо вашому бізнесу потрібна максимальна сумісність
(браузери, телевізори, старі телефони, корпоративні заблоковані десктопи), H.264 — це безпечна база.

Операційно, зрілість H.264 — це подарунок: стабільні драйвери, передбачувана поведінка, менше сюрпризів з B-фреймами, менше інцидентів «чому стрім зелений?».
Водночас він стискає гірше, ніж нові кодеки, і це має значення в масштабі.

H.265 (HEVC): краща компресія, складніша екосистема

HEVC зазвичай дає кращу якість на бітрейт порівняно з H.264, особливо на вищих роздільностях. Але «зазвичай» робить багато роботи.
Апаратна підтримка поширена, але не універсальна в старих клієнтах, і деякі середовища розгортання все ще мають гострі кути.

В продакшені HEVC часто змінює ваші режими відмов: ви можете зменшити витрати на egress, але збільшити навантаження служби підтримки. Також, якщо ви транскодуєте
між 8-бітовими та 10-бітовими варіантами, можна випадково змусити програмні шляхи. Саме тоді ваш «GPU транскод» перетворюється на обігрівач CPU.

AV1: гравець ефективності з реальними операційними наслідками

AV1 привабливий, бо може дати порівнянну якість при нижчому бітрейті за H.264 і часто кращу за HEVC, залежно від контенту та кодера.
Але ловушка в тому, що кодування AV1 важке в програмі, а апаратна підтримка кодування новіша.

Якщо ви можете використовувати апаратне AV1-кодування — чудово: ви отримуєте щільність і економію. Якщо ні — AV1 стає ретельно нормованою функцією, а не дефолтом.
Багато команд дізнаються про це важким шляхом: вмикають AV1 на сервері, навантаження CPU зростає, затримки черги вибухають, і канал інцидентів наповнюється «чому саме зараз?»

Цитата, що має бути в кожному runbook відео-SRE: Сподівання — не стратегія. — Gene Kranz.

Жарт №1: Кодування відео схоже на дієту — всі хочуть «краще стиснення», ніхто не хоче платити рахунок за обчислення.

Чому це важливо: витрати, затримка, щільність і режими відмови

Витрати: egress зазвичай справжній ворог

У масштабі ширина каналу домінує. Якщо більш ефективний кодек дозволяє скоротити бітрейт на 20–40% при тій же сприйманій якості, це не дрібниця.
Це може змінити вашу юніт-економіку, позицію у переговорах з CDN і наскільки агресивними ви можете бути з багаторівневими стрімами.

Апаратні енкодери роблять можливим генерувати більше варіантів на вузол без купівлі величезних CPU-машин. Але остерігайтесь: якість/бітрейт апаратних енкодерів
іноді відстає від програмних, отже ви можете втратити частину очікуваної економії стискання. «Найдешевший» варіант може бути «більше потоків на GPU»,
тоді як найдорожчий рядок у бюджеті лишається egress.

Затримка: блоки фіксованої функції передбачувані, поки пайплайн не ламається

Апаратне кодування зазвичай дає низьку затримку, особливо при налаштуваннях, що уникають довгих буферів lookahead і важкого використання B-фреймів. Але кінцева затримка
— це властивість пайплайну: захват → декодинг → масштабування → фільтр → кодування → пакування → мережа. Якщо один етап переходить на програмний шлях або починає чергуватися,
загальна затримка може підскочити, хоча сам енкодер у нормі.

Щільність: приховане обмеження «сесій» — продакшн-пастка

Відео-движки часто мають обмеження на одночасні сесії, іноді впроваджені драйверами, іноді в апаратурі. Навіть якщо здається, що сирої пропускної здатності вистачає,
ви можете вдаритися в ліміт сесій і побачити помилки при створенні нових енкодів з неясними повідомленнями. Саме тут runbook-и помирають, якщо ви не тестували на конкуренцію.

Надійність: GPU — не єдина рухома частина

Драйвери, прошивка, версії ядра, рантайми контейнерів і збірки FFmpeg мають значення. Одна дрібна зміна драйвера може змінити стабільність під навантаженням.
Апаратні енкодери — детерміновані машини, але навколишній софт-стек — ні. Ставтеся до GPU-нoдів як до приладів: фіксуйте версії,
оновлюйте усвідомлено і тестуйте під реальною конкуренцією.

Факти й історія, що пояснюють сьогоднішні дивні обмеження

Це ті факти, що здаються тривіальними, поки не пояснять тикет з інцидентом.

1. H.264 був стандартизований у 2003 році, і його довгий «хвіст» підтримки пристроїв — чому він досі базова сумісність.
2. HEVC (H.265) з’явився у 2013 році, орієнтований на вищі роздільності й кращу ефективність, але прийняття розпорошилося по пристроях і середовищах.
3. AV1 було фіналізовано у 2018 році альянсом Alliance for Open Media, з метою сучасної ефективності стиснення й широкої підтримки індустрії.
4. NVIDIA давно ввела виділені NVENC блоки, щоб відео-навантаження не крало ресурси від графіки/обчислень безпосередньо.
5. Quick Sync від Intel дебютував на платформах близько 2011 року і лишається економним транспортним засобом транскодування в багатьох парках, бо «йде в комплекті» з CPU.
6. 10-бітні та HDR пайплайни — не косметичне оновлення; вони змінюють формати пікселів і можуть викликати програмні шляхи, якщо пайплайн не сумісний наскрізь.
7. Метрики «завантаження GPU» історично акцентували 3D/обчислення, тому команди вводять в оману: відео-движок може бути в максимумі, хоча дашборди зелені.
8. B-фрейми та lookahead підвищують ефективність стиснення, але можуть збільшувати затримку і буферизацію — добре для VOD, небезпечно для інтерактиву.
9. Апаратні декодери мають власні ліміти (роздільність, профілі, референсні кадри), і деякі «підтримувані кодеки» підтримуються лише в конкретних профілях/рівнях.

Планування ємності: потоки, сесії та «це залежить» у конкретних цифрах

Думайте про пайплайни, а не лише кодеки

Завдання транскоду рідко лише «кодування». Зазвичай це декодинг → перетворення кольорового простору → масштабування → оверлей → кодування → mux. Кожен етап може виконуватися на CPU або GPU.
Ваша справжня пропускна здатність — мінімум по всіх етапах, плюс накладні синхронізації при переміщенні кадрів між пам’яттю CPU і GPU.

Три обмеження, що найбільше важать

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

Практичні поради: що стандартизувати

В корпоративній реальності ви не можете підтримувати нескінченну комбінацію налаштувань. Виберіть невелику кількість «золотих» лідерів і пресетів на клас навантаження:
low-latency live, live стандартний, VOD високої якості. Зробіть ці комбінації явними в коді, а не в плодових знаннях команди.

Якщо ви тільки починаєте, за замовчуванням:

• H.264 апаратне кодування для широкої сумісності.
• HEVC або AV1 як опціональні виходи там, де клієнти їх підтримують і ви можете виміряти вигоди.
• Чітку політику «програмного fallback» (і алерти) замість тихого переходу на програмне кодування.

Жарт №2: Єдина річ більш оптимістична, ніж «все вміститься на одному GPU», — це «ми виправимо це в постпродакшні».

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

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

Перш за все: підтвердіть, що апаратне прискорення справді задіяне

• Перевірте логи FFmpeg на предмет використаних енкодера/декодера (nvenc/qsv/amf) vs програмних (libx264/libx265/libaom-av1).
• Перевірте завантаження відео-движка GPU (не лише compute).
• Переконайтеся, що ви випадково не використовуєте невірні формати пікселів (наприклад, yuv444p, 10-бітні), що змушують програмні етапи.

По-друге: визначте, чи вузьке місце в кодуванні, декодуванні чи «усіх інших» етапах

• Виміряйте швидкість на задачу (fps), час очікування в черзі та пропуски кадрів.
• Подивіться на використання CPU: якщо CPU зашкалює, поки ви «використовуєте GPU», ймовірно масштабування/фільтри працюють на CPU або відбувся fallback.
• Перевірте RX/TX PCIe і використання копіювання пам’яті GPU, якщо маєте ці метрики; надмірні копії можуть домінувати.

По-третє: перевірте обмеження по конкуренції та стан драйвера

• Порахуйте одночасні сесії; порівняйте з відомими безпечними числами для вашого стека.
• Перевірте скидання драйвера, помилки Xid або повідомлення ядра, що вказують на збої GPU.
• Підтвердіть, що рантайм контейнера має доступ до потрібних пристроїв (/dev/nvidia*, /dev/dri).

По-четверте: вирішіть шлях пом’якшення

• Якщо ви перейшли на програмний шлях: вимкніть проблемний кодек/профіль, поки не виправите, або спрямовуйте завдання на вузли, оптимізовані для CPU, свідомо.
• Якщо обмеженість по сесіях: розподіліть завдання на більше GPU, зменшіть кількість рендішенів на вхід або переведіть частину виходів на програмне кодування, якщо є запас CPU.
• Якщо обмеженість по пропускній здатності: зменшіть роздільність/FPS, відрегулюйте пресети або перенесіть важкі фільтри на GPU (або видаліть їх).

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

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

Завдання 1: Визначте вашу GPU та версію драйвера

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:21:33 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07    Driver Version: 550.90.07    CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
|  0  NVIDIA L4               On| 00000000:01:00.0 Off |                    0 |
+-------------------------------+----------------------+----------------------+

Що це означає: Підтверджує модель GPU і драйвер. Модель GPU визначає підтримку кодеків (особливо AV1 encode) і клас пропускної здатності.

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

Завдання 2: Перевірте завантаження відео-двигуна GPU під навантаженням

cr0x@server:~$ nvidia-smi dmon -s u -d 1 -c 5
# gpu   sm   mem   enc   dec   mclk   pclk
# Idx     %     %     %     %   MHz    MHz
    0     5    12    87    10  6250   1590
    0     4    11    92     9  6250   1590
    0     6    12    95    12  6250   1590

Що це означає: enc майже насичений, тоді як sm низький. Ви обмежені відео-движком, а не обчисленням.

Рішення: Масштабуйте горизонтально (більше GPU/нодів) або зменшіть навантаження на кодування (менше рендішенів, нижчий fps, швидший пресет).

Завдання 3: Перевірте наявність NVENC енкодерів у FFmpeg

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E "nvenc|qsv|amf" | head
 V....D h264_nvenc           NVIDIA NVENC H.264 encoder (codec h264)
 V....D hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
 V....D av1_nvenc            NVIDIA NVENC av1 encoder (codec av1)

Що це означає: Ваша збірка FFmpeg бачить NVENC енкодери. Якщо цих рядків немає, ви не виконуєте апаратне кодування цим бінарником.

Рішення: Якщо відсутні — виправте пакування/збірку; не компенсуйте «додати більше CPU» і називати це GPU-транскодуванням.

Завдання 4: Перевірте підтримку NVDEC для апаратного декодування у FFmpeg

cr0x@server:~$ ffmpeg -hide_banner -hwaccels
Hardware acceleration methods:
cuda
vaapi
qsv
drm

Що це означає: Доступні бекенди апаратного прискорення. Для NVIDIA cuda включає NVDEC/NVENC потоки.

Рішення: Якщо cuda відсутній на NVIDIA-нодах, виправте драйвер/передачу пристрою в контейнері перед тим, як налаштовувати щось інше.

Завдання 5: Підтвердіть вхідний кодек/профіль/глибину бітності

cr0x@server:~$ ffprobe -hide_banner -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate -of default=nw=1 input.mp4
codec_name=h264
profile=High
pix_fmt=yuv420p
width=1920
height=1080
r_frame_rate=30000/1001

Що це означає: Пайплайн 8-бітний 4:2:0, що широко підтримується апаратно. Якщо бачите yuv420p10le або yuv444p, очікуйте більше обмежень.

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

Завдання 6: Запустіть контрольований H.264 NVENC транскод і спостерігайте швидкість

cr0x@server:~$ ffmpeg -hide_banner -y -hwaccel cuda -i input.mp4 -c:v h264_nvenc -preset p4 -b:v 4500k -maxrate 4500k -bufsize 9000k -c:a copy out_h264.mp4
frame= 6000 fps=420 q=28.0 size=   110000kB time=00:03:20.00 bitrate=4506.1kbits/s speed=14.0x

Що це означає: speed=14.0x вказує на пропускну здатність значно вище реального часу. Якщо бачите speed=0.8x, ваш вузол не встигає.

Рішення: Використайте це як базовий показник ємності на вузол і для виявлення регресій після змін драйвера/FFmpeg.

Завдання 7: Перевірте, чи випадково не перейшли на програмне кодування

cr0x@server:~$ ffmpeg -hide_banner -y -i input.mp4 -c:v libx264 -preset veryfast -t 10 -f null -
frame=  300 fps=120 q=-1.0 Lsize=N/A time=00:00:10.00 bitrate=N/A speed=4.00x

Що це означає: Це чисте CPU-кодування. Корисно як точка порівняння для якості та пропускної здатності, і як план відмови.

Рішення: Якщо ваші «GPU-ноді» в логах виглядають так у production, зупиніться і виправте залучення апаратного прискорення до його вирішення.

Завдання 8: Перевірте доступність Intel Quick Sync (на iGPU-нодах Intel)

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root        80 Jan 13 10:10 by-path
crw-rw---- 1 root video 226,   0 Jan 13 10:10 card0
crw-rw---- 1 root video 226, 128 Jan 13 10:10 renderD128

Що це означає: Вузол render існує; контейнери/сервіси потребують доступу до /dev/dri/renderD128 для QSV/VAAPI робочих процесів.

Рішення: Якщо відсутній, iGPU може бути відключений у BIOS, бракує драйвера, або ви у VM без passthrough.

Завдання 9: Підтвердіть наявність QSV енкодерів у FFmpeg

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E "h264_qsv|hevc_qsv|av1_qsv"
 V..... h264_qsv             H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
 V..... hevc_qsv             HEVC (Intel Quick Sync Video acceleration) (codec hevc)
 V..... av1_qsv              AV1 (Intel Quick Sync Video acceleration) (codec av1)

Що це означає: QSV шлях доступний у цій збірці FFmpeg.

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

Завдання 10: Виявіть CPU-вузькі місця і поверніть запас ресурсів

cr0x@server:~$ pidstat -u -p ALL 1 3 | head -n 12
Linux 6.5.0 (server)  01/13/2026  _x86_64_  (32 CPU)

10:22:01      UID       PID    %usr %system  %CPU  Command
10:22:02        0     21140   220.0     8.0 228.0  ffmpeg
10:22:02        0     21141   210.0     6.0 216.0  ffmpeg

Що це означає: Кілька процесів FFmpeg споживають по кілька ядер. Якщо ви очікували GPU-offload, щось виконується на CPU (фільтри, масштабування або програмне кодування).

Рішення: Перенесіть масштабування на GPU (наприклад, CUDA-фільтри) або зменште складність фільтрів; інакше планування ємності — фантазія.

Завдання 11: Виявлення вузьких місць PCIe/пристрою та тротлінгу GPU

cr0x@server:~$ lspci -s 01:00.0 -vv | grep -E "LnkSta|LnkCap"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s, Width x8

Що це означає: GPU працює з пониженими швидкістю/шириною ланки. Це може зашкодити передачі кадрів, особливо при фільтрах на CPU.

Рішення: Перевірте налаштування BIOS, райзери, розміщення у слотах; якщо не можна виправити, тримайте пайплайн на GPU, щоб мінімізувати переноси.

Завдання 12: Перевірте логи ядра на проблеми GPU/драйвера

cr0x@server:~$ dmesg -T | tail -n 20
[Tue Jan 13 10:18:22 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=21140, name=ffmpeg, Ch 00000028
[Tue Jan 13 10:18:22 2026] nvidia-modeset: ERROR: GPU:0: Error while waiting for GPU progress

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

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

Завдання 13: Перевірте доступ контейнера до NVIDIA-пристроїв

cr0x@server:~$ ls -l /dev/nvidia*
crw-rw-rw- 1 root root 195,   0 Jan 13 10:10 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jan 13 10:10 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jan 13 10:10 /dev/nvidia-modeset
crw-rw-rw- 1 root root 511,   0 Jan 13 10:10 /dev/nvidia-uvm
crw-rw-rw- 1 root root 511,   1 Jan 13 10:10 /dev/nvidia-uvm-tools

Що це означає: Пристрої існують. Контейнери все ще потребують конфігурації рантайма для доступу до них, але відсутність пристроїв — це критична зупинка.

Рішення: Якщо після завантаження вузла пристрої відсутні, драйвер не завантажився; не бігайте за FFmpeg-флагами.

Завдання 14: Підтвердіть, що шлях кодування дійсно на GPU, спостерігаючи завантаження енкодера

cr0x@server:~$ nvidia-smi dmon -s u -d 1
# gpu   sm   mem   enc   dec   mclk   pclk
    0     3     9     0     0  6250   210
    0     4    11    65     8  6250  1590
    0     5    11    88     9  6250  1590

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

Рішення: Використайте це як перевірку здоров’я під час інциденту. Це ловить неправильно спрямовані завдання і зламане призначення пристроїв.

Завдання 15: Підтвердіть, що вихідний кодек — це те, що ви очікуєте

cr0x@server:~$ ffprobe -hide_banner -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt -of default=nw=1 out_h264.mp4
codec_name=h264
profile=High
pix_fmt=yuv420p

Що це означає: Підтверджує вихід. Це важливо, бо «ми виводимо HEVC» часто — це віра, а не факт.

Рішення: Якщо пайплайн тихо виробляє H.264 через переговори/фолбек, ви не отримуєте очікуваної економії пропускної здатності.

Завдання 16: Виміряйте одночасність потоків і момент початку помилок

cr0x@server:~$ pgrep -af ffmpeg | wc -l
48

Що це означає: Грубо, але корисно: порахуйте одночасні воркери FFmpeg на вузлі. Корелюйте зі значенням часу, коли починають з’являтися помилки.

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

Три міні-історії з корпоративного світу (з болем включно)

1) Інцидент через неправильне припущення: «завантаження GPU низьке, отже ми в порядку»

Медійна платформа розгорнула нову функцію «моментальні хайлайти»: виявляти цікаві фрагменти і транскодувати їх у короткі кліпи. Навантаження було сплесковим,
що нормально, коли ви прив’язуєте обчислення до дій користувача. Вони розгорнули на GPU-нодах, бо план казав «NVENC дешевий».

Дашборди виглядали спокійно. Завантаження GPU коливалося біля 10–15%. CPU помірний. Пам’ять в нормі. Потім черги почали зростати і кліпи стали готуватися хвилинами,
а не секундами. Перший респондер подивився графіки GPU і вирішив: «Не GPU-проблема».

Це була саме GPU-проблема — просто не той метрик, який вони дивились. Енкодер був насичений, і ноди досягали меж одночасних сесій.
Обчислювальні ядра GPU були вільні, бо NVENC — фіксована функція; графік «завантаження GPU» був фактично непридатним для цього навантаження.

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

2) Оптимізація, що повернулась бумерангом: «Включити B-фрейми і lookahead для кращої компресії»

Команда корпоративних комунікацій вела внутрішні трансляції для великих зборів. Їхні SRE отримали завдання скоротити трафік.
Хтось виявив, що в лабораторії увімкнення більш просунутих функцій енкодера покращує якість при тому ж бітрейті.
Вони включили lookahead і збільшили B-фрейми для live-лестниці.

Наступний захід став повільним катастрофічним досвідом. Не повним крахом — гірше. Люди скаржилися, що «відчувається затримка», інтерактивні Q&A були незручними,
і доповідачі почали говорити над власним відео на моніторах. Затримка зросла з «прийнятної» до «всі помічають».

Енкодер виконав свою роботу: lookahead і B-фрейми потребують буферизації, що додає затримку. Апаратні енкодери можуть це робити, але фізика залишається.
Система не мала запасу, щоб поглинути додаткову затримку, а їхній моніторинг був сфокусований на пропускній здатності, а не на glass-to-glass затримці.

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

3) Нудна, але правильна практика, що врятувала ситуацію: фіксація версій і канарки

Інша організація мала звичку, що виглядала неамбітно: вони фіксували версії драйверів GPU, фіксували збірки FFmpeg і робили релізи через канарки з реальним
продакшн-трафіком. Без героїзму. Багато «ні» у тікетах.

Нове оновлення драйвера обіцяло кращу продуктивність AV1. Платформна команда хотіла його вжити негайно. SRE на чергуванні зробив звичне: канаркувати 5% нод,
запускати синтетичні тести на конкуренцію та порівнювати помилки, затримку і швидкість кодування. На канарці при зростанні конкуренції з’явилися спорадичні збої енкодера.
Не постійні. Не очевидні. Саме такого типу ситуації, що псують вихідні.

Вони призупинили rollout. Бізнес усе ще отримав AV1 — просто не на тому драйвері. Пізніше вони знайшли конкретну взаємодію між драйвером і конфігурацією рантайма контейнера,
що проявлялася тільки під великою паралельністю.

Сенс не в тому, що «драйвери погані». Сенс у тому, що нудні контролі — фіксація, канарки, тести регресії під конкуренцією — перетворюють загальнофлотний інцидент
на низькоризикове інженерне завдання. Найкращий інцидент — це той, який ви тихо попередили і ніхто не постить у Twitter.

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

1) Симптом: GPU-ноди «простаивают», але транскоди повільні

Корінна причина: Ви дивитесь на compute-завантаження, а не на завантаження енкодера/декодера; або пайплайн прив’язаний до CPU через масштабування/фільтри.

Виправлення: Слідкуйте за завантаженням енкодера/декодера; перенесіть масштабування на GPU де можливо; валідуйте через логи FFmpeg і nvidia-smi dmon.

2) Симптом: Нові задачі падають при вищій конкуренції з неясними помилками

Корінна причина: Обмеження сесій/конкуренції в драйвері/апаратурі або вичерпання ресурсів у рантаймі (дескриптори файлів, спільна пам’ять).

Виправлення: Обмежте одночасне кодування на GPU; розподіліть навантаження по нодах; додайте зворотний тиск і явні відповіді «немає ємності» замість ретраїв, що підсилюють навантаження.

3) Симптом: Навантаження CPU зростає після ввімкнення HEVC або AV1

Корінна причина: Відсутня апаратна підтримка для того кодека/профілю; пайплайн змушений працювати в програмі; або конвертація формату пікселів на CPU.

Виправлення: Перевірте наявність апаратних енкодерів; перевірте формати пікселів; явним чином виберіть апаратні кодеки; додайте алерти на програмний fallback.

4) Симптом: Вихід відтворюється на деяких клієнтах, але не на інших

Корінна причина: Використовуєте профілі/рівні, що не підтримуються цільовими пристроями; невідповідність підтримки HEVC/AV1 у клієнтів; 10-бітний вихід там, де клієнт очікує 8-біт.

Виправлення: Ведіть матрицю сумісності; обмежте налаштування енкодера; використовуйте переговори кодека і мульти-кодекні лідери там, де потрібно.

5) Симптом: Випадкові зелені кадри, корупція або періодичні аварії під навантаженням

Корінна причина: Проблеми драйвера, термічні/енергетичні нестабільності або баги, що виявляються специфічними бітстрімами/профілями.

Виправлення: Перевірте логи ядра; взяті ноди на карантин; зафіксуйте відому- добру версію драйвера; додайте стрес-тести і відхиляйте проблемні входи за потреби.

6) Симптом: Затримка підскакує після змін «покращення якості»

Корінна причина: Lookahead, B-фрейми або буферизація контролю швидкості збільшили затримку пайплайну; або знизилась пропускна здатність і зросла черга.

Виправлення: Розділяйте пресети для live і VOD; встановіть явні бюджети затримки; вимірюйте glass-to-glass, а не лише fps енкодера.

7) Симптом: «Апаратне декодування ввімкнено», але декодування залишається CPU-важким

Корінна причина: Непідтримуваний вхід (профіль/рівень, 10-біт) або фільтри вимагають кадри на CPU, що змушує завантаження і конверсії.

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

8) Симптом: Продуктивність сильно варіюється між ідентичними нодами

Корінна причина: Різні версії драйверів/прошивок, різні ширини PCIe, різні налаштування BIOS або термічний тротлінг.

Виправлення: Забезпечте імунність нодів; перевірте PCIe-лінк; стандартизовуйте прошивки; моніторьте температуру і поведінку частот.

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

Побудуйте промислову GPU-відеоплатформу (практичний план)

1. Визначте класи навантажень: live низької затримки, live стандарт, VOD пакетне, ескізи/прев’ю.
2. Виберіть «золоті» кодек-лідери для кожного класу: які виходи існують, які кодеки опціональні і які клієнти мають бути підтримані.
3. Стандартизуйте формати пікселів: вирішіть 8-біт чи 10-біт; будьте явними щодо обробки HDR і конверсій.
4. Оберіть апаратне забезпечення за можливостями: чи підтримує GPU/iGPU потрібний кодек і профіль в апараті (включно з AV1 encode)?
5. Зафіксуйте драйвер + збірки FFmpeg і ставтесь до змін як до релізів з канарками.
6. Реалізуйте явну політику fallback: дозволено програмне fallback? коли? яка макс. конкуренція при fallback?
7. Додайте спостережуваність, що відповідає вузьким місцям: завантаження енкодера/декодера, латентність по етапам, глибина черги, відсоток пропусків, коди помилок.
8. Тестуйте навантаження при конкуренції: не один транскод; десятки/сотні з реалістичним розмаїттям входів.
9. Встановіть обмеження одночасності на вузол у планувальнику і дотримуйтеся їх.
10. Проводьте інцидентні тренування: симулюйте втрату GPU, падіння драйвера і примусовий програмний fallback. Перевірте поведінку SLO.
11. Документуйте матрицю сумісності клієнтів і оновлюйте її по мірі еволюції додатків.
12. Зробіть якість вимірюваною: оберіть об’єктивні метрики (наприклад, VMAF) для VOD-змін і метрики затримки для live.

Операційний чекліст для rollout кодека (HEVC або AV1)

• Підтвердіть апаратну підтримку кодека у вашому флоті (не лише «на одній тестовій машині»).
• Розгорніть на невеликій когорті з продакшн-трафіком і реальною конкуренцією.
• Виміряйте: fps кодування, відмови, кінцеву затримку і збереження бітрейту на реальному контенті.
• Перевірте відтворення на клієнтах і поведінку fallback.
• Встановіть алерти на рівні програмного fallback і глибину черги.
• Тільки потім збільшуйте відсоток rollout.

Поширені запитання

1) Чи апаратне кодування завжди гірше за програмне з точки зору якості?

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

2) Чому мій дашборд показує низьке завантаження GPU, а транскоди падають?

Бо ви дивитесь не на той двигун. Кодування/декодування відео часто виконуються фіксованою функцією. Відстежуйте завантаження енкодера/декодера та ліміти сесій/конкуренції.

3) Чи треба використовувати AV1 скрізь, щоб зменшити трафік?

Ні. Використовуйте AV1 там, де клієнти його підтримують і де ваш флот має апаратне кодування (або ви можете дозволити програмне кодування). Залишайте H.264 як базову сумісність.
Розгортайте з вимірюваннями; не робіть «великого вибуху» при зміні кодека.

4) Яка найбільша прихована вартість у «GPU-транскодингу»?

Переміщення даних і «все інше»: масштабування, оверлеї, перетворення кольорового простору, muxing і обробка аудіо. Якщо це залишається на CPU, ваш GPU купує менше, ніж ви думаєте.

5) Як дізнатися, чи FFmpeg справді використовує NVENC/QSV/AMF?

Перевірте логи FFmpeg на обраний кодек (h264_nvenc, hevc_qsv тощо), валідуйте завантаження enc/dec під час запуску,
і підтвердіть вихід за допомогою ffprobe.

6) Чому у нас регресії затримки, коли ми налаштовуємо «покращення якості»?

Lookahead і B-фрейми додають буферизацію, що збільшує затримку. Також «кращий пресет» може зменшити пропускну здатність і збільшити черги.
Live і VOD не повинні ділити одні й ті ж налаштування за замовчуванням.

7) Мені потрібен великий дискретний GPU, чи Intel iGPU впорається?

Для багатьох H.264/H.265 навантажень Intel Quick Sync може бути дуже економним варіантом, особливо для помірних роздільностей і великої кількості паралельних потоків.
Дискретні GPU краще, коли потрібна вища пропускна здатність, більше функцій або масштабне AV1 encode.

8) Який найпростіший спосіб уникнути тихого програмного fallback?

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

9) Чому HEVC працює в одних середовищах і падає в інших?

Екосистема фрагментована: підтримка декодування у клієнтів, ліцензійні/пакувальні обмеження в деяких платформах і різниці в профілях/рівнях.
На практиці потрібна матриця сумісності і план fallback.

Наступні кроки, які можна відправити цього тижня

Якщо ви працюєте з продакшн-відео і хочете менше сюрпризів, зробіть це в порядку:

1. Додайте правильні метрики: завантаження енкодера/декодера, fps по задачі, глибина черги і частка програмного fallback.
2. Обмежте конкуренцію на GPU на основі виміряних точок насичення, а не бажань.
3. Зафіксуйте драйвер і збірки FFmpeg, а потім робіть релізи через канарки під реальною конкуренцією.
4. Стандартизуйте пресети за навантаженням: низька затримка для live проти високоефективного VOD, і припиніть змішувати цілі.
5. Впровадьте AV1 обережно: пропонуйте його там, де заощаджує гроші і де є апаратна підтримка; залишайте H.264 як страховку.

Вам не потрібна ідеальна стратегія кодеків. Потрібна стратегія, що переживе продакшн-трафік, недосконалі входи і квартальний «просто випустити».
Відео-движки GPU — не магія. Це спеціалізована техніка. Ставтесь до неї як до техніки: вимірюйте, обслуговуйте і ніколи не припускайте.