WEBVTT

00:00:00.000 --> 00:00:02.520
Все почалося з попередження, а потім настала тиша.

00:00:02.640 --> 00:00:05.380
Рахунок за GPU зростав так, ніби прискорювач ніколи не спав,

00:00:05.440 --> 00:00:07.520
проте вихідні дані повзли, ніби світло вимкнули.

00:00:07.680 --> 00:00:09.800
Дашборди були зеленими, а клієнти – ні.

00:00:09.960 --> 00:00:11.860
Ця аномалія не вкладалася в логіку.

00:00:12.060 --> 00:00:14.940
Майже нульове завантаження GPU при стрибках затримки.

00:00:15.160 --> 00:00:18.560
Жодних сповіщень, жодних червоних ліній просто час випаровувався.

00:00:18.760 --> 00:00:21.980
Докази вказують на єдину патологію, яка маскується під норму.

00:00:22.120 --> 00:00:23.280
Ось наша обіцянка.

00:00:23.280 --> 00:00:27.020
Ми відстежимо артефакти, назвемо «Винуватця» та виправимо патологію.

00:00:27.180 --> 00:00:29.440
Ми розглянемо три режими збоїв, відкат до CPU,

00:00:29.620 --> 00:00:32.280
невідповідність версій CUDA та ONNX Stensort,

00:00:32.380 --> 00:00:34.260
а також помилки конфігурації контейнерів,

00:00:34.360 --> 00:00:37.020
і доведемо це показниками затримки, пропускної здатності

00:00:37.020 --> 00:00:38.640
та використання GPU до і після.

00:00:38.840 --> 00:00:41.460
Підготовка кейсу, середовище та профіль жертви.

00:00:41.620 --> 00:00:43.760
Кожна конфігурація розповідає свою історію,

00:00:43.820 --> 00:00:46.480
і ця починається зі звичайного орендаря під навантаженням.

00:00:46.480 --> 00:00:48.300
Робоче навантаження – це дифузія тексту в зображення,

00:00:48.400 --> 00:00:51.480
варіанти Stable Diffusion, що працюють з роздільною здатністю 512 на 512

00:00:51.480 --> 00:00:53.540
і з масштабуванням до 1024 на 1024.

00:00:53.820 --> 00:00:55.320
Трафік має сплесковий характер.

00:00:55.500 --> 00:00:58.000
Паралельність становить від 8 до 32 запитів.

00:00:58.140 --> 00:01:00.060
Розміри пакетів варіюються від 1 до 8.

00:01:00.320 --> 00:01:02.700
Рівні обслуговування суворо ставляться до затримок у хвості.

00:01:02.820 --> 00:01:06.040
Порушення P95 прямо конвертуються у штрафи та зменшення кредитів.

00:01:06.180 --> 00:01:08.500
Моделі не екзотичні, але вибір має значення.

00:01:08.500 --> 00:01:11.060
Конвейери Stable Diffusion експортовані в ONNX,

00:01:11.180 --> 00:01:14.820
оптимізації перехресної уваги, такі як сформерс або масштабована точкова увага,

00:01:14.860 --> 00:01:17.160
та вибір плановальників, що обмінюють кроки на якість.

00:01:17.280 --> 00:01:20.680
Екосистема має прискорюватися, якщо інфраструктура працює чесно.

00:01:20.820 --> 00:01:23.100
Апарат незабезпечення на папері виглядає гідно.

00:01:23.220 --> 00:01:27.500
Карти Nvidia RTX та серії A у хмарі від 16 до 32 гігабайтів VRM.

00:01:27.660 --> 00:01:30.400
PCI-E стоїть між хостом і пристроєм як пункт оплати.

00:01:30.560 --> 00:01:32.120
Достатньо швидкий при налаштуванні, але карає,

00:01:32.120 --> 00:01:34.460
коли операції введення-виведення переходять на сторінкові передачі.

00:01:34.560 --> 00:01:36.500
У цьому середовищі нічого не є випадковим.

00:01:36.740 --> 00:01:38.620
Інструментарій складається зі знайомих рівнів.

00:01:38.740 --> 00:01:42.700
PyTouch використовується для експорту, а потім ONNX, Runtime або Tensort бере на себе висновок.

00:01:42.800 --> 00:01:44.860
Драйвери CUDA знаходяться в основі всього.

00:01:45.060 --> 00:01:48.060
Ядра уваги обіцяють швидкість, якщо версії збігаються.

00:01:48.300 --> 00:01:51.000
Розгортання суворо контейнеризоване, незмінні образи,

00:01:51.120 --> 00:01:53.480
CI-керовані релізи, блогрін за політикою.

00:01:53.480 --> 00:01:55.620
Це обмеження має створювати безпеку.

00:01:55.780 --> 00:01:57.860
Воно також може законсервувати дефекти.

00:01:58.020 --> 00:01:59.760
Бізнес-ризики не є абстрактними.

00:01:59.920 --> 00:02:01.780
Вартість одного запиту визначає маржу.

00:02:01.920 --> 00:02:05.200
Резервування GPU оплачується погодинно, незалежно від того, чи працюють ядра.

00:02:05.340 --> 00:02:08.700
Коли затримка зростає з секунд до пів хвилини, пропускна здатність колапсує.

00:02:08.860 --> 00:02:11.760
Одна помилка в конфігурації перетворює прискорювач на обігрівач,

00:02:11.880 --> 00:02:14.600
дорогий, тихий і зайнятий чим завгодно, крім допомоги черзі.

00:02:14.600 --> 00:02:17.360
При детальнішому розгляді профіль жертви звужується.

00:02:17.360 --> 00:02:24.360
Паралельність 16, пакети по 2, щоб залишатися під лімітами VRM на 512 з кроком до 1024 для якості.

00:02:24.520 --> 00:02:27.160
Орендар очікує стабільного показника P95.

00:02:27.480 --> 00:02:31.840
Натомість трасування показує хаотичні затримки, великі дельти між P50 і P95,

00:02:32.080 --> 00:02:36.560
а також коливання циклу роботи GPU від 5% до 40% без очевидної причини.

00:02:36.720 --> 00:02:38.620
Графіки CPU свідчать про інше.

00:02:38.620 --> 00:02:41.540
Ядра завантажені наповну, хоча попередньої обробки немає.

00:02:41.700 --> 00:02:43.600
Докази вказують на три можливі шляхи.

00:02:43.700 --> 00:02:45.260
По-перше, перемикання на CPU.

00:02:45.260 --> 00:02:48.500
Коли провайдер виконання CUDA або Tensor не завантажується,

00:02:48.640 --> 00:02:50.220
рушій тихо обирає графік CPU.

00:02:50.420 --> 00:02:53.120
Модель працює, але із затримкою у 10-30 разів.

00:02:53.220 --> 00:02:54.880
По-друге, невідповідність версій.

00:02:55.040 --> 00:02:57.700
ONNX Runtime скомпілювано під одну версію CUDA,

00:02:57.880 --> 00:03:00.500
вузли працюють на іншій, рушій і Tensor стають недійсними

00:03:00.500 --> 00:03:02.320
і перебудовуються з універсальними ядрами.

00:03:02.580 --> 00:03:05.540
Завантаження відображається, але швидкі шляхи втрачені.

00:03:05.540 --> 00:03:09.020
По-третє, помилки конфігурації контейнерів, перевантажені образи,

00:03:09.020 --> 00:03:12.560
відсутні підключення GPU, невірні налаштування NVIDIA Toolkit

00:03:12.560 --> 00:03:15.740
та виділення пам'яті, що збільшують затримку під навантаженням.

00:03:15.860 --> 00:03:17.780
Зрештою, це не таємниця моделей.

00:03:17.960 --> 00:03:20.200
Це справа про достовірність інфраструктури.

00:03:20.380 --> 00:03:22.740
Ми відстежимо артефакти, порядок провайдерів,

00:03:22.860 --> 00:03:24.860
логи можливостей, підключення пристроїв

00:03:24.860 --> 00:03:26.760
і зіставимо їх із трьома показниками,

00:03:26.900 --> 00:03:29.640
затримка, пропускна здатність та використання GPU.

00:03:29.640 --> 00:03:38.700
Все почалося із запиту, який мав тривати секунди, але не тривав.

00:03:38.820 --> 00:03:41.080
Показник GPU мовчав занадто тихо.

00:03:41.220 --> 00:03:43.680
Графік CPU тим часом злетів, як пожежна тривога.

00:03:43.800 --> 00:03:46.200
Після детальнішого аналізу стало зрозуміло, Рушій зробив вибір.

00:03:46.200 --> 00:03:48.520
Він виконав завдання, розраховане на GPU за допомогою CPU.

00:03:48.700 --> 00:03:49.960
Жодних сповіщень не надійшло.

00:03:50.140 --> 00:03:51.520
Результат, зрештою, повернувся.

00:03:51.660 --> 00:03:53.820
Це і є тихий саботажник, перемикання на CPU.

00:03:54.020 --> 00:03:55.680
Чому це важливо? Просто пояснити.

00:03:55.880 --> 00:03:58.280
Stable Diffusion на CPU – це марна трата часу.

00:03:58.280 --> 00:04:02.860
Модель працює, але затримка зростає, у 10-30 разів повільніше, а пропускна здатність падає.

00:04:03.020 --> 00:04:05.860
У середовищі, де цінуються мілісекунди, такий розрив фатальний.

00:04:06.000 --> 00:04:09.000
Рахунок продовжує відображати час GPU, хоча пристрій не виконує роботу.

00:04:09.220 --> 00:04:10.800
Хронологія виявила закономірність.

00:04:10.900 --> 00:04:13.640
Контейнери, що запускалися локально з CUDA, працювали миттєво.

00:04:13.760 --> 00:04:16.060
Розгорнуті на вузлі кластера з дещо іншим стеком драйверів,

00:04:16.140 --> 00:04:19.580
ті самі контейнери завантажувалися, проходили перевірку справності, а потім деградували.

00:04:19.580 --> 00:04:22.400
Ендпоінт справності перевіряв лише одне, чи працює сервер,

00:04:22.520 --> 00:04:25.260
тож він ніколи не перевіряв, чи насправді виконує роботу GPU.

00:04:25.460 --> 00:04:27.800
У цьому середовищі нічого не буває випадково.

00:04:27.920 --> 00:04:29.300
Тиша – це теж артефакт.

00:04:29.440 --> 00:04:33.280
Ключовий артефакт – це порядок провайдерів виконання в ONNX Runtime.

00:04:33.460 --> 00:04:37.460
Рушій приймає список «спробувати Тенсорт», потім CUDA, потім CPU.

00:04:37.680 --> 00:04:41.300
Якщо CUDA не ініціалізується через невірний драйвер, відсутні бібліотеки

00:04:41.300 --> 00:04:44.760
чи непідключений пристрій, ОАРТі тихо переключиться на провайдер виконання CPU.

00:04:44.760 --> 00:04:48.520
Жодних виключень, жодних збоїв, лише рядок у логах, часто десь глибоко внизу.

00:04:48.620 --> 00:04:51.500
Провайдер виконання CUDA недоступний – перемикання на CPU.

00:04:51.720 --> 00:04:54.280
Цей рядок – зізнання, яке більшість команд ніколи не читають.

00:04:54.420 --> 00:04:55.280
Ось найдивніше.

00:04:55.440 --> 00:04:58.320
Графіки використання на перший погляд виглядають оманливо нормально.

00:04:58.560 --> 00:05:00.080
Запити все одно завершуються.

00:05:00.240 --> 00:05:03.660
Карта сервісів зелена, але робочий цикл GPU ледь сягає 5%,

00:05:03.660 --> 00:05:05.960
тоді як навантаження на CPU стрімко зростає.

00:05:06.100 --> 00:05:09.420
P50 затримка зростає вчетверо, а P95 стає непередбачуваною.

00:05:09.420 --> 00:05:11.520
Сплески трафіку лише погіршують ситуацію.

00:05:11.640 --> 00:05:15.080
Черги ростуть, а автоскейлер додає нові репліки, які успадковують той самий дефект.

00:05:15.240 --> 00:05:19.000
Це схоже на естафету, де спринтер не вийшов на старт, і його етап біжить бібліотекар.

00:05:19.120 --> 00:05:21.760
Естафетна паличка рухається, але зовсім не зі швидкістю бігуна.

00:05:21.900 --> 00:05:25.500
Іншими словами, система видає правильний результат ціною всього бюджету СЛО.

00:05:25.660 --> 00:05:28.960
Під час відстеження послідовності завантаження артефакти накопичуються дуже швидко.

00:05:28.960 --> 00:05:33.400
Логи завантаження провайдерів показують спроби ініціалізації CUDA з перевіркою версії драйвера.

00:05:33.500 --> 00:05:39.380
Якщо контейнер зібрано під CUDA 12, 2, а на вузлі лише 12, ініціалізація не вдається.

00:05:39.580 --> 00:05:44.480
Якщо Nvidia-контейна Toolkit не налаштовано, точка монтування пристрою не з'являється в контейнері.

00:05:44.640 --> 00:05:46.720
Немає, де в Nvidia, немає ліпкуда.

00:05:46.920 --> 00:05:51.960
Отже, якщо специфікація пода не запитує GPU явно, планувальник ніколи не призначить пристрій.

00:05:52.140 --> 00:05:55.380
Будь-яка з цих причин призводить до прихованої деградації продуктивності.

00:05:55.380 --> 00:05:57.400
Відтворити цю проблему досить легко.

00:05:57.580 --> 00:06:02.960
На неправильно налаштованому вузлі простий інференс показує CPU-Execution Provider там,

00:06:03.120 --> 00:06:07.080
де очікується TENSO-RT або CUDA-Execution Provider.

00:06:07.560 --> 00:06:10.500
Відправте запит, GPU залишається бездіяльним.

00:06:10.680 --> 00:06:15.320
CPU потоки стрибають, зображення генерується за 20-40 секунд замість від 2 до 6.

00:06:15.540 --> 00:06:19.640
Повторіть те саме на вузлі з правильними драйверами, запит виконується миттєво,

00:06:19.740 --> 00:06:22.100
а завантаження GPU стабільно зростає.

00:06:22.100 --> 00:06:25.540
Докази свідчать, що поточні механізми захисту є лише пролюдське око.

00:06:25.680 --> 00:06:28.680
Зонди стану Health Probes повертають 200, бо сервер відповідає.

00:06:28.820 --> 00:06:31.220
Немає перевірки при запуску, чи працює GPU-шлях.

00:06:31.340 --> 00:06:34.780
Перевірок продуктивності не існує, тому оркестратор вважає репліки справними.

00:06:34.960 --> 00:06:37.820
Система не бачить різниці між прискоренням і емуляцією.

00:06:37.980 --> 00:06:40.100
Контрзахід має бути радикальним за задумом.

00:06:40.220 --> 00:06:44.140
Повна відмова, якщо GPU-Execution Provider відсутній або працює з помилками.

00:06:44.340 --> 00:06:47.000
Заборона запуску на CPU в продуктовому середовищі.

00:06:47.000 --> 00:06:54.160
При запуску процесу перерахуйте провайдери, переконайтеся, що TENSO-RT або CUDA завантажені та кількість пристроїв відповідає очікуванням.

00:06:54.280 --> 00:07:00.920
Залогуйте набір можливостей QDNN, доступні тензорні ядра, ліміти пам'яті і завершуйте роботу з помилкою, якщо чогось не вистачає.

00:07:01.080 --> 00:07:05.320
Жертвуйте доступністю заради цілісності, дозвольте оркестраторам перезапустити поднасправному вузлі.

00:07:05.500 --> 00:07:08.720
Щоб це працювало надійно, запровадьте перевірку прив'язки вводу-виводу IO-байндинг.

00:07:08.720 --> 00:07:12.920
Прив'язуйте вхідні та вихідні дані до пам'яті пристрою та перевіряйте простий інференс під час старту.

00:07:13.040 --> 00:07:15.980
Один прогрівочний прогін, що задіює ядро Fused Attention.

00:07:16.240 --> 00:07:20.200
Якщо час виконання перевищує ліміт затримки, вважайте шлях деградованим і вбивайте POD.

00:07:20.320 --> 00:07:23.340
Додайте набір тестових запитів Canary з детермінованими зернами SIDS.

00:07:23.500 --> 00:07:25.860
Порівнюйте затримку з базовим вікном продуктивності.

00:07:26.000 --> 00:07:29.420
Якщо відхилення перевищує допуск, сповіщайте команду та зупиняйте розгортання.

00:07:29.580 --> 00:07:32.380
Це може здатися жорстким, але альтернатива значно гірша.

00:07:32.380 --> 00:07:35.340
Кластер, що працює, втрачаючи час і бюджет.

00:07:35.460 --> 00:07:41.000
Зафіксуйте порядок провайдерів, відхиліть резервний CPU і змусте систему довести свою швидкість, перш ніж вважати її робочою.

00:07:41.200 --> 00:07:43.540
Тільки тоді зелений означатиме прискорення.

00:07:43.780 --> 00:07:48.780
Файл доказів B, невідповідність версій, несумісність CUDA, ONNX та Tensor.

00:07:49.000 --> 00:07:54.160
Якщо GPU не використовувався, наступне питання, чи міг він працювати на повній швидкості, навіть якщо він присутній.

00:07:54.320 --> 00:07:56.080
Дані вказують на більш тонкий збій.

00:07:56.080 --> 00:08:00.040
Версії збігаються достатньо для запуску, але недостатньо для відкриття швидкого шляху.

00:08:00.160 --> 00:08:02.980
Система виглядає прискореною, доки не подивишся на таймінги.

00:08:03.140 --> 00:08:04.620
Чому це важливо? Очевидно.

00:08:04.800 --> 00:08:08.020
Дифузіні конвоїри живуть або вмирають, залежно від продуктивності механізму Attention.

00:08:08.260 --> 00:08:17.360
Коли ONNX, Runtime і Tensor не можуть завантажити очікувані ними ядра через невідповідність версій CUDA, CAN або Tensor, вони тихо переходять на загальні реалізації.

00:08:17.720 --> 00:08:18.660
Модель працює.

00:08:18.880 --> 00:08:23.860
Використання коливається від 30 до 50%, а затримка виходить за межі бюджету.

00:08:23.860 --> 00:08:26.800
Збірка виглядає так само, робота виконується повільніше.

00:08:26.920 --> 00:08:29.420
При детальнішому огляді артефакти стають точними.

00:08:29.580 --> 00:08:32.680
Логи завантаження провайдерів повідомляють про успіх з підказкою.

00:08:32.800 --> 00:08:35.900
Перехід на ядра за замовчуванням або вимкнення з формерс.

00:08:36.000 --> 00:08:42.320
Ви побачите, що десеріалізація плану Tensor не вдається через несумісність перебудови рушія, що ініціює компіляцію на вузлі.

00:08:42.480 --> 00:08:46.240
Рушії, створені на одній мінорній версії Tensor, не десеріалізуються на іншій.

00:08:46.240 --> 00:08:51.340
Перебудова завершується, але отриманий план може не містити Fused Attention або оптимізації FP16.

00:08:51.580 --> 00:08:52.720
Гонка завершується.

00:08:52.900 --> 00:08:55.860
Без сплесків робочі цикли тензорних ядер залишаються приглушеними.

00:08:56.020 --> 00:08:57.620
Ось найменш очевидна частина.

00:08:57.740 --> 00:09:00.600
Команди трактують те, що воно працює як оптимальний стан.

00:09:00.740 --> 00:09:02.940
У цьому середовищі нічого не є випадковим.

00:09:03.100 --> 00:09:06.820
Якщо скейлд нижнє підкреслення Product Attention не активний, якщо сформерс вимкнено,

00:09:06.960 --> 00:09:10.340
якщо кан повідомляє про обмежений робочий простір, продуктивність ввічливо падає.

00:09:10.340 --> 00:09:13.400
Простими словами, невідповідні бінарні файли змушують використовувати ядра,

00:09:13.480 --> 00:09:16.180
які потребують більше переміщень пам'яті та меншої щільності обчислень.

00:09:16.300 --> 00:09:17.960
Псі стає помітним у трасуванні.

00:09:18.140 --> 00:09:20.800
Хвостові затримки зростають разом із паралелізмом.

00:09:20.920 --> 00:09:22.720
Уявіть стек як набір замків.

00:09:22.860 --> 00:09:27.920
Driver, CUDA Toolkit, CAN, пропорції збірки ONNX, Runtime та Tensor.

00:09:28.100 --> 00:09:30.980
Один зубець не на місці, і ключ повертається лише наполовину.

00:09:31.140 --> 00:09:34.280
OART рекламує граф можливостей для кожного виконавчого провайдера.

00:09:34.280 --> 00:09:39.460
Якщо скомпільований OART очікує CUDA, 12, 2, а драйвер вузла надає 12, 1.

00:09:39.640 --> 00:09:43.020
CUDA завантажується з обмеженими функціями або не завантажується зовсім.

00:09:43.180 --> 00:09:46.660
Якщо на вузлі Tensor 8, 6, а плани були згенеровані на 8, 4,

00:09:46.820 --> 00:09:50.040
десеріалізація не вдається і перезапускається з консервативною тактикою.

00:09:50.240 --> 00:09:53.180
Система тихо віддає перевагу коректності над швидкістю.

00:09:53.380 --> 00:09:55.380
Бенчмарки доводять втрати на практиці.

00:09:55.580 --> 00:09:59.840
З активними сформерс або SDPD фузійний attention помітно скорочує час виконання.

00:09:59.840 --> 00:10:05.680
Дослідження послідовно показують прискорення від 2 до 5 разів у шляху attention залежно від роздільної здатності та розміру пакету.

00:10:05.880 --> 00:10:09.080
Вимкніть їх через невідповідність версій і ви втратите ці множники.

00:10:09.280 --> 00:10:11.840
Об'єднання токенів TOME додається до цих прискорень.

00:10:12.540 --> 00:10:17.100
Без фьюзд ядер перевага обмежується пропускною здатністю пам'яті та неоптимізованими макетами.

00:10:17.320 --> 00:10:21.800
Розрив збільшується при роздільній здатності 1024 на 1024 та вищій паралельності.

00:10:21.960 --> 00:10:24.800
Щоб відстежити артефакти, почніть із переліку можливостей.

00:10:24.800 --> 00:10:28.760
Під час запуску виведіть точний список провайдерів та їхні заявлені функції.

00:10:28.940 --> 00:10:38.000
Версія Tensor, доступність FP16 та INT8, максимальний робочий простір, евристика згортки CAN, наявність NCCL для мульти-GPU.

00:10:38.380 --> 00:10:41.180
Для ONNX Runtime виведіть пріоритети IP.

00:10:41.380 --> 00:10:43.620
Tensor, CUDA, потім CPU.

00:10:43.820 --> 00:10:46.740
Перевірте, що саме прив'язується до вузлів вашого графа.

00:10:46.920 --> 00:10:52.380
Зареєструйте, чи призначаються вузли уваги Attention Tensor з об'єднаними ядрами чи загальним ядрам CUDA.

00:10:52.380 --> 00:10:54.100
Далі дослідіть середовище.

00:10:54.220 --> 00:10:55.180
Опитайте драйвер.

00:10:55.320 --> 00:10:58.360
NVIDIA SMI показує модуль ядра та сумісність CUDA.

00:10:58.580 --> 00:11:00.760
Считайте версії бібліотек у контейнері.

00:11:00.940 --> 00:11:03.500
LípCuda, LípCablas, LípCAN, Linwinfer.

00:11:03.660 --> 00:11:11.420
Якщо образ містить бібліотеки CUDA 12, 3, а драйвер госта підтримує лише 12, 2, режим сумісності може завантажитися з обмеженнями.

00:11:11.560 --> 00:11:18.600
Якщо образ очікує заголовки Tensor 8, 6, а вузол надає 8, 4, виклики ARRI погіршаться або анулюють певні оптимізації.

00:11:18.780 --> 00:11:21.020
Рішенням є матриця збірки, а не сподівання.

00:11:21.020 --> 00:11:23.920
Зафіксуйте точні версії в єдиному джерелі істини.

00:11:24.060 --> 00:11:30.260
Базовий образ із сумісністю драйверів, мінорною версією CUDA, CAN, хешем збірки OART та версією Tensor.

00:11:30.540 --> 00:11:35.980
Створюйте образи для виведення відповідно до цієї матриці та відхиляйте вузли, що не збігаються, через мітки вузлів та перевірки допуску.

00:11:36.080 --> 00:11:41.440
Попередньо створюйте та кешуйте рушії Tensor для кожного варіанта моделі та роздільної здатності на тій самій версії Tensor, яку ви розгортаєте.

00:11:41.440 --> 00:11:44.320
Ставтеся до файлів плану як до артефактів, прив'язаних до матриці.

00:11:44.460 --> 00:11:47.400
Ніколи не покладайтеся на створення рушія на вузлі у продуктивному середовищі.

00:11:47.520 --> 00:11:50.100
Це маскує відхилення та подовжує час холодного старту.

00:11:50.260 --> 00:11:54.180
Щоб закріпити результат, додайте CI-тести, що перевіряють можливості ядер.

00:11:54.280 --> 00:11:57.980
Запустіть контейнер в ізольованому середовищі з цільовим драйвером і перевірте,

00:11:57.980 --> 00:12:05.200
чи завантажує Tensor ядра FP16, чи об'єднані вузли уваги, чи активна прив'язка I.O., чи розпізнані сформерс або SDP.

00:12:05.440 --> 00:12:13.000
Запустіть детермінований набір підказок і скасуйте збірку, якщо затримка перевищує базовий рівень або логи містять повідомлення про відкат до інших методів.

00:12:13.140 --> 00:12:19.200
Зберігайте знімок можливостей разом із дайджестом образу, щоб відкати відновлювали як код, так і характеристики продуктивності.

00:12:19.360 --> 00:12:22.400
Зрештою, докази свідчать, що відхилення версій – це не баг, як бачите.

00:12:22.400 --> 00:12:24.300
Це ціна, яку ви платите швидкістю.

00:12:27.980 --> 00:12:33.000
Ерозія ефективності через неправильну конфігурацію закладена в проєкті.

00:12:33.140 --> 00:12:37.360
Навіть коли версії збігаються, контейнер може саботувати ефективність всередини.

00:12:37.520 --> 00:12:44.280
Докази вказують на повільний витік, роздутість образу, відсутність GPU-інфраструктури та поведінку алукатора, що спотворює затримку під навантаженням.

00:12:44.420 --> 00:12:46.540
Ніщо не падає, все деградує.

00:12:47.420 --> 00:12:48.860
Чому це важливо? Просто.

00:12:49.080 --> 00:12:51.760
Контейнери формують реальність середовища виконання.

00:12:51.760 --> 00:12:56.120
Якщо образ заважкий, а холодні старти довгі, репліки запізнюються на інцидент.

00:12:56.120 --> 00:13:01.800
Якщо пристрої GPU не змонтовані або середовищу, виконання бракує правильних прапорів, провайдери виконання поводяться неправильно.

00:13:01.980 --> 00:13:06.500
Якщо арени пам'яті накопичують виділення, це через активність ARM викликає підкачування та стрибки затримки.

00:13:06.660 --> 00:13:07.940
Модель виглядає нормально.

00:13:08.160 --> 00:13:10.320
Контейнер тихо обтяжує кожен запит.

00:13:10.460 --> 00:13:13.940
При детальнішому розгляді виявляється накопичення артефактів під час збірки.

00:13:14.100 --> 00:13:19.580
Образи перевищують 2 ГБ через компілятори, заголовки та тестові ресурси через відсутність багатоетапної збірки.

00:13:19.580 --> 00:13:24.240
Відсутній докерігнор залучає ноутбуки, кеші та експериментальні ваги у виробничі шари.

00:13:24.400 --> 00:13:27.380
Кожне розгортання завантажує гігабайти через мережу.

00:13:27.520 --> 00:13:31.480
Маштабуйте це на пули вузлів, і холодний старт стає правилом, а не винятком.

00:13:31.700 --> 00:13:33.060
Докази не є загадковими.

00:13:33.260 --> 00:13:35.460
Історія Дока розповідає цю історію по шарах.

00:13:35.640 --> 00:13:38.180
Середовище виконання виявляє другий рівень ерозії.

00:13:38.400 --> 00:13:44.720
Без явних прапорів GPU, без GPU в Дока або через відсутність конфігурації плагіна пристрою в Кубанітаз,

00:13:44.720 --> 00:13:46.920
Процес не бачить пристроїв NVIDIA.

00:13:47.240 --> 00:13:50.960
Помилки конфігурації NVIDIA-контейна Toolkit приховують ліпкуда.

00:13:51.140 --> 00:13:55.280
Отже, друзі, провайдер виконання завантажується з обмеженнями або не завантажується взагалі.

00:13:55.420 --> 00:14:00.200
MIG не застосовується, тому навантаження борються за фрагменти пам'яті, створюючи втрати, які планувальники не розуміють.

00:14:00.360 --> 00:14:02.680
Журнали залишаються ввічливими, продуктивність згасає.

00:14:02.800 --> 00:14:04.540
Поведінка пам'яті – це третій рівень.

00:14:04.680 --> 00:14:08.640
За замовчуванням арена пам'яті CUDA в ONNX, рантайм агресивно кешує виділення.

00:14:14.720 --> 00:14:20.180
Тому передача між хостом і пристроєм відбувається через підкачувані буфери, перетворюючи PCI і на вузьке місце.

00:14:20.340 --> 00:14:25.700
Відвивід не прив'язаний до пристрою, тому тензори стрибають між CPU та GPU, створюючи невидимі податки на затримку.

00:14:25.860 --> 00:14:28.600
Спочатку погіршується хвостова поведінка, а потім середня.

00:14:28.740 --> 00:14:31.200
Ось як виглядає цей набір симптомів у реальних умовах.

00:14:31.320 --> 00:14:34.400
Ефективна пропускна здатність відстає, попри помірне використання GPU.

00:14:34.400 --> 00:14:39.840
Затримка при легкому навантаженні прийнятна, але P95 коливається при конкурентності, а потім непередбачувано стрибає.

00:14:40.020 --> 00:14:43.940
Випадкові OOM Kill скидають репліки при піковому трафіку, створюючи ефект стада.

00:14:44.080 --> 00:14:47.540
Перезапуски стають каскадними, автоскалювання працює нестабільно, а черги накопичуються.

00:14:47.700 --> 00:14:51.860
Оператори шукають не ту причину, вважаючи модель важкою, тоді як політики контейнерів спричиняють колапс.

00:14:52.000 --> 00:14:54.160
Ставтеся до гігієни контейнерів, як до роботи з доказами.

00:14:54.160 --> 00:14:56.260
Багатоетапні збірки видаляють відбитки пальців.

00:14:56.380 --> 00:14:59.240
Компілятори та інструменти розробки ніколи не потрапляють у середовище виконання.

00:14:59.400 --> 00:15:02.960
D-Strelless або Slim базовий образ звужує поверхню атаки та скорочує час завантаження.

00:15:03.120 --> 00:15:06.120
Аудити Doka Slim або Dive підтверджують, що вижило після збірки.

00:15:06.320 --> 00:15:08.920
Doka Rignor запобігає випадковому накопиченню зайвого.

00:15:09.140 --> 00:15:10.800
Результатом є судова чистота.

00:15:10.940 --> 00:15:12.960
Працює лише те, що має працювати.

00:15:13.160 --> 00:15:15.640
Налаштування GPU потребують явних вказівок.

00:15:15.640 --> 00:15:18.960
У Doka оголошуйте всі GPU або точний фрагмент MIG.

00:15:19.180 --> 00:15:25.120
У Kubanitas запитуйте ресурси NVIDIA GPU і переконайтеся, що плагін пристрою відповідає вашій гілці драйверів.

00:15:25.280 --> 00:15:28.440
Під час запуску перевіряйте наявність пристрою та сумісність драйверів.

00:15:28.560 --> 00:15:31.780
NVIDIA SME та LDConfig – це не прикраси, а перевірки допуску.

00:15:31.920 --> 00:15:35.200
Якщо щось відсутнє або не збігається, запишіть це як порушення та завершіть роботу.

00:15:35.360 --> 00:15:38.100
Потім налаштувайте ONNX Runtime та Tensor цілеспрямовано.

00:15:38.260 --> 00:15:41.840
Заблокуйте порядок провайдерів виконання лише на шляхах GPU у виробничому середовищі.

00:15:45.640 --> 00:15:46.960
Під час запитуйте, що перевищують робочий набір.

00:15:47.060 --> 00:15:50.540
Обмежте зростання або встановіть попереднє виділення в передбачуваних межах.

00:15:50.660 --> 00:15:54.400
Увімкніть АВП-16 за замовчуванням, якщо це дозволяють обмеження точності.

00:15:54.560 --> 00:15:56.920
Захистіть INT вісьмома тестом на точність.

00:15:57.040 --> 00:16:01.200
Прив'яжіть введення-виведення до пам'яті пристрою, щоб дані потрапляли туди, де відбувається обчислення,

00:16:01.280 --> 00:16:03.780
та ретельно оберейте потоки, щоб запобігти блокуванню черги.

00:16:03.940 --> 00:16:06.740
Закріпіть це двома перевірками – працездатність та продуктивність.

00:16:06.980 --> 00:16:10.280
Працездатність – це не просто статус 200, це підтверджений знімок можливостей.

00:16:10.400 --> 00:16:15.320
Провайдери завантажені, об'єднані ядра присутні, тензорні ядра розпізнані, введення-виведення обмежене.

00:16:15.520 --> 00:16:20.720
Продуктивність – це базовий набір запитів, що виконується під час запуску з вікном затримки та мінімальним порогом використання.

00:16:20.880 --> 00:16:24.220
Якщо контейнер не відповідає обом вимогам, він не допускається до обслуговування.

00:16:24.440 --> 00:16:28.660
Встановіть бюджети розміру образу для CI, щоб збірки, які перевищують ліміти, завершувалися помилкою.

00:16:28.660 --> 00:16:33.420
Зберігайте різницю вмісту образів для кожного дайджесту, щоб відкати відновлювали код та гігієну системи.

00:16:33.560 --> 00:16:38.220
Дані свідчать, що контейнери не просто розгортають ПЕЗЕ, вони кодують поведінку під навантаженням.

00:16:38.340 --> 00:16:42.820
Коли вони шумні, важкі або невизначені щодо GPU, вони перетворюють прискорення на формальність.

00:16:43.000 --> 00:16:46.560
Коли вони легкі, чіткі та впевнені, вони зберігають швидкий шлях, за який ви заплатили.

00:16:46.560 --> 00:16:48.820
У цьому середовищі нічого не буває випадковим.

00:16:48.920 --> 00:16:51.920
Контейнер або допомагає GPU виконувати роботу, або заважає йому.

00:16:51.920 --> 00:16:54.500
Лабораторія криміналістики, метрики, що виносять вирок.

00:16:54.640 --> 00:16:56.960
Затримка, пропускна здатність, рівень використання.

00:16:57.140 --> 00:17:01.280
Докази важливіші задумки, тому ми фіксуємо набір запитів, блокуємо сіди та прогріваємо систему.

00:17:01.440 --> 00:17:03.060
Ті самі планувальники, ті самі кроки.

00:17:03.240 --> 00:17:09.520
2025 для 512 розширено до 50 для 1024 на 1024, щоб виявити навантаження.

00:17:09.520 --> 00:17:12.720
Паралельність утримується на рівні 16 і з перевіркою до 32.

00:17:12.980 --> 00:17:16.580
Розмір пакета починається з одиниці й обережно зростає, доки не впреця у межі ВІРМ.

00:17:16.580 --> 00:17:19.900
Жодної екстраполяції, жодних виправдань, лише годинники та лічильники.

00:17:20.100 --> 00:17:21.440
Затримка свідчить першою.

00:17:21.620 --> 00:17:28.240
У деградованому стані при використанні CPU або стандартного шляху Attention P50 для 512 на 512 розтягується до двозначних чисел.

00:17:28.360 --> 00:17:30.680
P95 розповідає справжню історію.

00:17:30.680 --> 00:17:35.800
Він непередбачувано коливається від 20 до 40 секунд, бо черги накопичують дрібні неефективності.

00:17:35.900 --> 00:17:41.220
При 1024 на 1024 з 50-ма кроками P95 одразу стає критичним порушенням.

00:17:41.220 --> 00:17:50.280
Після виправлення DPUP заблоковано, Fused Attention активовано, I.O. прив'язано до пристрою, P50 повертається до низьких значень, а P95 вкладається в бюджет.

00:17:50.460 --> 00:17:53.140
Діапазон звужується, система стає передбачуваною.

00:17:53.280 --> 00:17:55.060
Пропускна здатність це підтверджує.

00:17:55.060 --> 00:17:58.200
При паралельності 16 деградований шлях дає лише краплю.

00:17:58.360 --> 00:18:02.440
Кількість зображень за хвилину ледь зростає при додаванні реплік, бо кожен екземпляр гальмує сам себе.

00:18:02.620 --> 00:18:05.460
Масштабування до 32-х множить суперечки, а не продуктивність.

00:18:05.460 --> 00:18:07.500
Після виправлення залежність вирівнюється.

00:18:07.660 --> 00:18:12.920
Зображення за хвилину зростають майже лінійно, поки не насититься робочий цикл тензорних ядер або VRM не обмежить пакет.

00:18:13.060 --> 00:18:15.020
Різниця в нахилі графіка – це і є вирок.

00:18:15.180 --> 00:18:18.180
Робота справді швидше доходить до фінішу, а не просто створює більше шуму.

00:18:18.380 --> 00:18:19.920
Використання закриває справу.

00:18:20.060 --> 00:18:24.880
До цього робочий цикл DPU коливався від 0 до 50% з довгими пласкими провалами.

00:18:25.040 --> 00:18:29.380
Лічильники ПСІ показують затримки від передачі даних зі сторінкових пам'ятій.

00:18:29.380 --> 00:18:35.740
Після робочий цикл стабілізується у високому послідовному діапазоні з помітним навантаженням тензорних ядер.

00:18:35.860 --> 00:18:39.180
CPU повертається до оркестрації та легкої попередньої обробки.

00:18:39.360 --> 00:18:44.060
Піки ПСІ стискаються, оскільки закріплена пам'ять та прив'язка вводу-виводу усунули зайвий трафік.

00:18:44.200 --> 00:18:46.900
Ніщо інше, крім реального прискорення, не пояснює ці зміни.

00:18:47.040 --> 00:18:48.540
Ми додаємо стресову перевірку.

00:18:48.680 --> 00:18:54.000
При 512 на 512 кроках 2025 оптимізований шлях підтримує паралелізм 16 безхвостових піків.

00:18:54.000 --> 00:18:56.780
При підвищенні до 32 система поступово деградує.

00:18:56.940 --> 00:18:59.760
Пі-95 зростає передбачувано, а не хаотично.

00:18:59.940 --> 00:19:04.500
При 1024 на 1024 на 50 кроках різниця стає ще відчутнішою.

00:19:04.740 --> 00:19:06.920
Деградований шлях зривається у таймаути.

00:19:07.160 --> 00:19:12.740
Загартований шлях утримує прийнятні Пі-50 та Пі-95 з пакетом від 1 до 2 до межі VRM.

00:19:12.900 --> 00:19:14.820
Ось де арени та потоки мають значення.

00:19:15.000 --> 00:19:17.760
Після налаштування блокування на початку черги зменшується.

00:19:17.760 --> 00:19:19.640
З точки зору витрат це проста арифметика.

00:19:19.780 --> 00:19:25.720
Запитів на годину GPU стає у від 2 до 5 разів більше, коли перевірено Fused Attention FP16 та прив'язку вводу-виводу.

00:19:25.880 --> 00:19:28.560
Ефективна вартість тисячі зображень відповідно падає.

00:19:28.760 --> 00:19:32.720
Штрафи за холодний старт зменшуються, бо образи компактні, а двигуни попередньо зібрані.

00:19:32.860 --> 00:19:35.580
Вузли перестають платити податок на компіляцію при першому зверненні.

00:19:35.720 --> 00:19:37.160
Реєстр збігається з логами.

00:19:37.340 --> 00:19:39.360
Верифікація запобігає випадковим успіхам.

00:19:39.360 --> 00:19:42.560
Повторіть на другому пулі вузлів з іншою мінорною версією драйвера.

00:19:42.700 --> 00:19:46.580
Загартований образ за задумом відмовляється запускатися на невідповідному вузлі.

00:19:46.700 --> 00:19:48.360
Тому результати порівнянні, а не спотворені.

00:19:49.080 --> 00:19:51.220
Перехресно перевіряйте знімки можливостей.

00:19:51.360 --> 00:19:54.860
Той самий порядок провайдерів, той самий тенсорт, ті самі твердження ядра.

00:19:55.020 --> 00:19:57.860
Повторно запустіть набір запитів і знову зафіксуйте розподіли.

00:19:58.000 --> 00:20:00.400
Коли гістограми збігаються, впевненість зростає.

00:20:00.560 --> 00:20:03.020
Коли ні, різниця в можливостях пояснює причину.

00:20:03.020 --> 00:20:05.560
Зрештою, цифри не сперечаються, вони доводять.

00:20:05.700 --> 00:20:09.100
Затримка стискається, пропускна здатність зростає, використання стабілізується.

00:20:09.240 --> 00:20:10.960
Патологія не є гіпотетичною.

00:20:11.180 --> 00:20:14.800
Вона вимірювана і після виправлення залишає відбитки на кожному графіку.

00:20:14.980 --> 00:20:18.480
Протокол виправлення – це контрольний список для повторюваного гартування.

00:20:18.660 --> 00:20:20.480
Контроль доступу на першому місці.

00:20:20.720 --> 00:20:24.320
Відмовляти в запуску, якщо відсутні провайдери Тенсорт або CUDA.

00:20:24.520 --> 00:20:26.960
Перераховуйте провайдери, перевіряйте кількість пристроїв,

00:20:26.960 --> 00:20:30.840
виведьте знімки можливостей CAN, FP16, робочий простір INT8.

00:20:31.000 --> 00:20:33.560
Якщо чогось не вистачає, завершуйте роботу з кодом помилки.

00:20:33.760 --> 00:20:34.960
Доступність слідує за цілісністю.

00:20:35.680 --> 00:20:37.300
Закріплення версій – це основа.

00:20:37.420 --> 00:20:42.280
Підтримуйте єдину матрицю, гілка драйвера, CUDA, CAN, хеш збірки ONNX, Runtime, Тенсорт.

00:20:42.460 --> 00:20:45.000
Збирайте образи для виведення відповідно до цієї матриці.

00:20:45.160 --> 00:20:46.820
Позначайте вузли для відповідності.

00:20:46.980 --> 00:20:48.700
Обмежуйте доступ на основі рівності.

00:20:48.700 --> 00:20:51.760
Попередньо зібрані двигуни Тенсорт для кожної моделі та роздільної здатності.

00:20:51.840 --> 00:20:54.180
Плани – це артефакти, а не припущення під час виконання.

00:20:54.320 --> 00:20:56.080
Гігієна контейнерів зберігає істину.

00:20:56.300 --> 00:20:57.880
Використовуйте багатоетапні збірки.

00:20:58.000 --> 00:21:00.200
Тримайте рантайм бездистрибутива або максимально легким.

00:21:00.360 --> 00:21:01.800
Включайте суворий докерігнор.

00:21:01.860 --> 00:21:04.420
Перевіряйте через докахістарі та аудит оптимізації розміру.

00:21:04.580 --> 00:21:06.400
Встановлюйте бюджети розміру пулу в CI.

00:21:06.400 --> 00:21:10.340
Блокуйте роздуті образи, підписуйте образи та звіряйте вміст за дайджестом.

00:21:10.460 --> 00:21:14.160
Налаштуйте GPU першочергово, зафіксуйте порядок IP на Тенсорт CUDA,

00:21:14.360 --> 00:21:16.080
вимкніть CPU провайдер у продуктиві.

00:21:16.200 --> 00:21:19.800
Підтвердьте наявність NVIDIA DEV та версію NVIDIA Container Toolkit.

00:21:19.960 --> 00:21:23.980
Запитуйте gpugvidea.com явно або змішуйте ліцензії та перевіряйте під час запуску.

00:21:24.100 --> 00:21:25.700
Налаштуйте середовище виконання.

00:21:25.880 --> 00:21:27.400
Увімкніть HP 16 за замовчуванням.

00:21:28.080 --> 00:21:30.580
Обмежте INT вісьмома перевірками точності.

00:21:30.580 --> 00:21:37.100
Прив'яжіть I.O. безпосередньо до пам'яті пристрою, увімкніть закріплену пам'ять, обирайте потоки, щоб уникнути черг.

00:21:37.180 --> 00:21:41.780
Переналаштуйте або вимкніть ORTC UDA Arena, якщо вона зупиняється за межами робочого набору.

00:21:41.920 --> 00:21:47.380
Встановіть ASL у продуктивності як код, самотестування при запуску з детермінованими підказками, вікном затримки та мінімальним використанням.

00:21:47.500 --> 00:21:49.460
Викликайте помилку при зростанні черг.

00:21:49.460 --> 00:21:55.820
Додайте спостережуваність метрики GPU на запит, сповіщення про деградацію, канейрі запити та порівнювані базові лінії.

00:21:55.980 --> 00:22:00.720
Розгортайте за модельлю Blue Green з контрольними точками продуктивності та автоматичним відкатом при порушенні.

00:22:00.840 --> 00:22:04.600
Коли протокол дотримується, прискорення є доведеним, а не передбачуваним.

00:22:04.800 --> 00:22:06.180
Урок цілком клінічний.

00:22:06.300 --> 00:22:10.160
Прихований перехід на CPU, розбіжність версій та роздуті контейнери – це не баги.

00:22:10.280 --> 00:22:12.840
Це передбачувані патерни збоїв, які ви можете заблокувати.

00:22:12.840 --> 00:22:18.620
Виконуйте протокол, вимірюйте утилізацію GPU, відмовляйтеся від деградованих шляхів, фіксуйте версії, ставтеся до двигунів, як до артефактів.

00:22:18.740 --> 00:22:27.060
Якщо ви хочете глибше зануритися в ONNX Runtime, роботу з пам'яттю TensorT, коли вимикати арени, дивіться наступний кейс у цій серії та підписуйтесь на лабораторні нотатки.