Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Повільний інференс на GPU: відкат на CPU, конфлікти версій CUDA/TensorRT і помилки контейнерів (ШІ-дубляж)

Transcript

Повільний інференс на GPU: відкат на CPU, конфлікти версій CUDA/TensorRT і помилки контейнерів (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Все почалося з попередження, а потім настала тиша.
• 0:02
  Рахунок за GPU зростав так, ніби прискорювач ніколи не спав,
• 0:05
  проте вихідні дані повзли, ніби світло вимкнули.
• 0:07
  Дашборди були зеленими, а клієнти – ні.
• 0:09
  Ця аномалія не вкладалася в логіку.
• 0:12
  Майже нульове завантаження GPU при стрибках затримки.
• 0:15
  Жодних сповіщень, жодних червоних ліній просто час випаровувався.
• 0:18
  Докази вказують на єдину патологію, яка маскується під норму.
• 0:22
  Ось наша обіцянка.
• 0:23
  Ми відстежимо артефакти, назвемо «Винуватця» та виправимо патологію.
• 0:27
  Ми розглянемо три режими збоїв, відкат до CPU,
• 0:29
  невідповідність версій CUDA та ONNX Stensort,
• 0:32
  а також помилки конфігурації контейнерів,
• 0:34
  і доведемо це показниками затримки, пропускної здатності
• 0:37
  та використання GPU до і після.
• 0:38
  Підготовка кейсу, середовище та профіль жертви.
• 0:41
  Кожна конфігурація розповідає свою історію,
• 0:43
  і ця починається зі звичайного орендаря під навантаженням.
• 0:46
  Робоче навантаження – це дифузія тексту в зображення,
• 0:48
  варіанти Stable Diffusion, що працюють з роздільною здатністю 512 на 512
• 0:51
  і з масштабуванням до 1024 на 1024.
• 0:53
  Трафік має сплесковий характер.
• 0:55
  Паралельність становить від 8 до 32 запитів.
• 0:58
  Розміри пакетів варіюються від 1 до 8.
• 1:00
  Рівні обслуговування суворо ставляться до затримок у хвості.
• 1:02
  Порушення P95 прямо конвертуються у штрафи та зменшення кредитів.
• 1:06
  Моделі не екзотичні, але вибір має значення.
• 1:08
  Конвейери Stable Diffusion експортовані в ONNX,
• 1:11
  оптимізації перехресної уваги, такі як сформерс або масштабована точкова увага,
• 1:14
  та вибір плановальників, що обмінюють кроки на якість.
• 1:17
  Екосистема має прискорюватися, якщо інфраструктура працює чесно.
• 1:20
  Апарат незабезпечення на папері виглядає гідно.
• 1:23
  Карти Nvidia RTX та серії A у хмарі від 16 до 32 гігабайтів VRM.
• 1:27
  PCI-E стоїть між хостом і пристроєм як пункт оплати.
• 1:30
  Достатньо швидкий при налаштуванні, але карає,
• 1:32
  коли операції введення-виведення переходять на сторінкові передачі.
• 1:34
  У цьому середовищі нічого не є випадковим.
• 1:36
  Інструментарій складається зі знайомих рівнів.
• 1:38
  PyTouch використовується для експорту, а потім ONNX, Runtime або Tensort бере на себе висновок.
• 1:42
  Драйвери CUDA знаходяться в основі всього.
• 1:45
  Ядра уваги обіцяють швидкість, якщо версії збігаються.
• 1:48
  Розгортання суворо контейнеризоване, незмінні образи,
• 1:51
  CI-керовані релізи, блогрін за політикою.
• 1:53
  Це обмеження має створювати безпеку.
• 1:55
  Воно також може законсервувати дефекти.
• 1:58
  Бізнес-ризики не є абстрактними.
• 1:59
  Вартість одного запиту визначає маржу.
• 2:01
  Резервування GPU оплачується погодинно, незалежно від того, чи працюють ядра.
• 2:05
  Коли затримка зростає з секунд до пів хвилини, пропускна здатність колапсує.
• 2:08
  Одна помилка в конфігурації перетворює прискорювач на обігрівач,
• 2:11
  дорогий, тихий і зайнятий чим завгодно, крім допомоги черзі.
• 2:14
  При детальнішому розгляді профіль жертви звужується.
• 2:17
  Паралельність 16, пакети по 2, щоб залишатися під лімітами VRM на 512 з кроком до 1024 для якості.
• 2:24
  Орендар очікує стабільного показника P95.
• 2:27
  Натомість трасування показує хаотичні затримки, великі дельти між P50 і P95,
• 2:32
  а також коливання циклу роботи GPU від 5% до 40% без очевидної причини.
• 2:36
  Графіки CPU свідчать про інше.
• 2:38
  Ядра завантажені наповну, хоча попередньої обробки немає.
• 2:41
  Докази вказують на три можливі шляхи.
• 2:43
  По-перше, перемикання на CPU.
• 2:45
  Коли провайдер виконання CUDA або Tensor не завантажується,
• 2:48
  рушій тихо обирає графік CPU.
• 2:50
  Модель працює, але із затримкою у 10-30 разів.
• 2:53
  По-друге, невідповідність версій.
• 2:55
  ONNX Runtime скомпілювано під одну версію CUDA,
• 2:57
  вузли працюють на іншій, рушій і Tensor стають недійсними
• 3:00
  і перебудовуються з універсальними ядрами.
• 3:02
  Завантаження відображається, але швидкі шляхи втрачені.
• 3:05
  По-третє, помилки конфігурації контейнерів, перевантажені образи,
• 3:09
  відсутні підключення GPU, невірні налаштування NVIDIA Toolkit
• 3:12
  та виділення пам'яті, що збільшують затримку під навантаженням.
• 3:15
  Зрештою, це не таємниця моделей.
• 3:17
  Це справа про достовірність інфраструктури.
• 3:20
  Ми відстежимо артефакти, порядок провайдерів,
• 3:22
  логи можливостей, підключення пристроїв
• 3:24
  і зіставимо їх із трьома показниками,
• 3:26
  затримка, пропускна здатність та використання GPU.
• 3:29
  Все почалося із запиту, який мав тривати секунди, але не тривав.
• 3:38
  Показник GPU мовчав занадто тихо.
• 3:41
  Графік CPU тим часом злетів, як пожежна тривога.
• 3:43
  Після детальнішого аналізу стало зрозуміло, Рушій зробив вибір.
• 3:46
  Він виконав завдання, розраховане на GPU за допомогою CPU.
• 3:48
  Жодних сповіщень не надійшло.
• 3:50
  Результат, зрештою, повернувся.
• 3:51
  Це і є тихий саботажник, перемикання на CPU.
• 3:54
  Чому це важливо? Просто пояснити.
• 3:55
  Stable Diffusion на CPU – це марна трата часу.
• 3:58
  Модель працює, але затримка зростає, у 10-30 разів повільніше, а пропускна здатність падає.
• 4:03
  У середовищі, де цінуються мілісекунди, такий розрив фатальний.
• 4:06
  Рахунок продовжує відображати час GPU, хоча пристрій не виконує роботу.
• 4:09
  Хронологія виявила закономірність.
• 4:10
  Контейнери, що запускалися локально з CUDA, працювали миттєво.
• 4:13
  Розгорнуті на вузлі кластера з дещо іншим стеком драйверів,
• 4:16
  ті самі контейнери завантажувалися, проходили перевірку справності, а потім деградували.
• 4:19
  Ендпоінт справності перевіряв лише одне, чи працює сервер,
• 4:22
  тож він ніколи не перевіряв, чи насправді виконує роботу GPU.
• 4:25
  У цьому середовищі нічого не буває випадково.
• 4:27
  Тиша – це теж артефакт.
• 4:29
  Ключовий артефакт – це порядок провайдерів виконання в ONNX Runtime.
• 4:33
  Рушій приймає список «спробувати Тенсорт», потім CUDA, потім CPU.
• 4:37
  Якщо CUDA не ініціалізується через невірний драйвер, відсутні бібліотеки
• 4:41
  чи непідключений пристрій, ОАРТі тихо переключиться на провайдер виконання CPU.
• 4:44
  Жодних виключень, жодних збоїв, лише рядок у логах, часто десь глибоко внизу.
• 4:48
  Провайдер виконання CUDA недоступний – перемикання на CPU.
• 4:51
  Цей рядок – зізнання, яке більшість команд ніколи не читають.
• 4:54
  Ось найдивніше.
• 4:55
  Графіки використання на перший погляд виглядають оманливо нормально.
• 4:58
  Запити все одно завершуються.
• 5:00
  Карта сервісів зелена, але робочий цикл GPU ледь сягає 5%,
• 5:03
  тоді як навантаження на CPU стрімко зростає.
• 5:06
  P50 затримка зростає вчетверо, а P95 стає непередбачуваною.
• 5:09
  Сплески трафіку лише погіршують ситуацію.
• 5:11
  Черги ростуть, а автоскейлер додає нові репліки, які успадковують той самий дефект.
• 5:15
  Це схоже на естафету, де спринтер не вийшов на старт, і його етап біжить бібліотекар.
• 5:19
  Естафетна паличка рухається, але зовсім не зі швидкістю бігуна.
• 5:21
  Іншими словами, система видає правильний результат ціною всього бюджету СЛО.
• 5:25
  Під час відстеження послідовності завантаження артефакти накопичуються дуже швидко.
• 5:28
  Логи завантаження провайдерів показують спроби ініціалізації CUDA з перевіркою версії драйвера.
• 5:33
  Якщо контейнер зібрано під CUDA 12, 2, а на вузлі лише 12, ініціалізація не вдається.
• 5:39
  Якщо Nvidia-контейна Toolkit не налаштовано, точка монтування пристрою не з'являється в контейнері.
• 5:44
  Немає, де в Nvidia, немає ліпкуда.
• 5:46
  Отже, якщо специфікація пода не запитує GPU явно, планувальник ніколи не призначить пристрій.
• 5:52
  Будь-яка з цих причин призводить до прихованої деградації продуктивності.
• 5:55
  Відтворити цю проблему досить легко.
• 5:57
  На неправильно налаштованому вузлі простий інференс показує CPU-Execution Provider там,
• 6:03
  де очікується TENSO-RT або CUDA-Execution Provider.
• 6:07
  Відправте запит, GPU залишається бездіяльним.
• 6:10
  CPU потоки стрибають, зображення генерується за 20-40 секунд замість від 2 до 6.
• 6:15
  Повторіть те саме на вузлі з правильними драйверами, запит виконується миттєво,
• 6:19
  а завантаження GPU стабільно зростає.
• 6:22
  Докази свідчать, що поточні механізми захисту є лише пролюдське око.
• 6:25
  Зонди стану Health Probes повертають 200, бо сервер відповідає.
• 6:28
  Немає перевірки при запуску, чи працює GPU-шлях.
• 6:31
  Перевірок продуктивності не існує, тому оркестратор вважає репліки справними.
• 6:34
  Система не бачить різниці між прискоренням і емуляцією.
• 6:37
  Контрзахід має бути радикальним за задумом.
• 6:40
  Повна відмова, якщо GPU-Execution Provider відсутній або працює з помилками.
• 6:44
  Заборона запуску на CPU в продуктовому середовищі.
• 6:47
  При запуску процесу перерахуйте провайдери, переконайтеся, що TENSO-RT або CUDA завантажені та кількість пристроїв відповідає очікуванням.
• 6:54
  Залогуйте набір можливостей QDNN, доступні тензорні ядра, ліміти пам'яті і завершуйте роботу з помилкою, якщо чогось не вистачає.
• 7:01
  Жертвуйте доступністю заради цілісності, дозвольте оркестраторам перезапустити поднасправному вузлі.
• 7:05
  Щоб це працювало надійно, запровадьте перевірку прив'язки вводу-виводу IO-байндинг.
• 7:08
  Прив'язуйте вхідні та вихідні дані до пам'яті пристрою та перевіряйте простий інференс під час старту.
• 7:13
  Один прогрівочний прогін, що задіює ядро Fused Attention.
• 7:16
  Якщо час виконання перевищує ліміт затримки, вважайте шлях деградованим і вбивайте POD.
• 7:20
  Додайте набір тестових запитів Canary з детермінованими зернами SIDS.
• 7:23
  Порівнюйте затримку з базовим вікном продуктивності.
• 7:26
  Якщо відхилення перевищує допуск, сповіщайте команду та зупиняйте розгортання.
• 7:29
  Це може здатися жорстким, але альтернатива значно гірша.
• 7:32
  Кластер, що працює, втрачаючи час і бюджет.
• 7:35
  Зафіксуйте порядок провайдерів, відхиліть резервний CPU і змусте систему довести свою швидкість, перш ніж вважати її робочою.
• 7:41
  Тільки тоді зелений означатиме прискорення.
• 7:43
  Файл доказів B, невідповідність версій, несумісність CUDA, ONNX та Tensor.
• 7:49
  Якщо GPU не використовувався, наступне питання, чи міг він працювати на повній швидкості, навіть якщо він присутній.
• 7:54
  Дані вказують на більш тонкий збій.
• 7:56
  Версії збігаються достатньо для запуску, але недостатньо для відкриття швидкого шляху.
• 8:00
  Система виглядає прискореною, доки не подивишся на таймінги.
• 8:03
  Чому це важливо? Очевидно.
• 8:04
  Дифузіні конвоїри живуть або вмирають, залежно від продуктивності механізму Attention.
• 8:08
  Коли ONNX, Runtime і Tensor не можуть завантажити очікувані ними ядра через невідповідність версій CUDA, CAN або Tensor, вони тихо переходять на загальні реалізації.
• 8:17
  Модель працює.
• 8:18
  Використання коливається від 30 до 50%, а затримка виходить за межі бюджету.
• 8:23
  Збірка виглядає так само, робота виконується повільніше.
• 8:26
  При детальнішому огляді артефакти стають точними.
• 8:29
  Логи завантаження провайдерів повідомляють про успіх з підказкою.
• 8:32
  Перехід на ядра за замовчуванням або вимкнення з формерс.
• 8:36
  Ви побачите, що десеріалізація плану Tensor не вдається через несумісність перебудови рушія, що ініціює компіляцію на вузлі.
• 8:42
  Рушії, створені на одній мінорній версії Tensor, не десеріалізуються на іншій.
• 8:46
  Перебудова завершується, але отриманий план може не містити Fused Attention або оптимізації FP16.
• 8:51
  Гонка завершується.
• 8:52
  Без сплесків робочі цикли тензорних ядер залишаються приглушеними.
• 8:56
  Ось найменш очевидна частина.
• 8:57
  Команди трактують те, що воно працює як оптимальний стан.
• 9:00
  У цьому середовищі нічого не є випадковим.
• 9:03
  Якщо скейлд нижнє підкреслення Product Attention не активний, якщо сформерс вимкнено,
• 9:06
  якщо кан повідомляє про обмежений робочий простір, продуктивність ввічливо падає.
• 9:10
  Простими словами, невідповідні бінарні файли змушують використовувати ядра,
• 9:13
  які потребують більше переміщень пам'яті та меншої щільності обчислень.
• 9:16
  Псі стає помітним у трасуванні.
• 9:18
  Хвостові затримки зростають разом із паралелізмом.
• 9:20
  Уявіть стек як набір замків.
• 9:22
  Driver, CUDA Toolkit, CAN, пропорції збірки ONNX, Runtime та Tensor.
• 9:28
  Один зубець не на місці, і ключ повертається лише наполовину.
• 9:31
  OART рекламує граф можливостей для кожного виконавчого провайдера.
• 9:34
  Якщо скомпільований OART очікує CUDA, 12, 2, а драйвер вузла надає 12, 1.
• 9:39
  CUDA завантажується з обмеженими функціями або не завантажується зовсім.
• 9:43
  Якщо на вузлі Tensor 8, 6, а плани були згенеровані на 8, 4,
• 9:46
  десеріалізація не вдається і перезапускається з консервативною тактикою.
• 9:50
  Система тихо віддає перевагу коректності над швидкістю.
• 9:53
  Бенчмарки доводять втрати на практиці.
• 9:55
  З активними сформерс або SDPD фузійний attention помітно скорочує час виконання.
• 9:59
  Дослідження послідовно показують прискорення від 2 до 5 разів у шляху attention залежно від роздільної здатності та розміру пакету.
• 10:05
  Вимкніть їх через невідповідність версій і ви втратите ці множники.
• 10:09
  Об'єднання токенів TOME додається до цих прискорень.
• 10:12
  Без фьюзд ядер перевага обмежується пропускною здатністю пам'яті та неоптимізованими макетами.
• 10:17
  Розрив збільшується при роздільній здатності 1024 на 1024 та вищій паралельності.
• 10:21
  Щоб відстежити артефакти, почніть із переліку можливостей.
• 10:24
  Під час запуску виведіть точний список провайдерів та їхні заявлені функції.
• 10:28
  Версія Tensor, доступність FP16 та INT8, максимальний робочий простір, евристика згортки CAN, наявність NCCL для мульти-GPU.
• 10:38
  Для ONNX Runtime виведіть пріоритети IP.
• 10:41
  Tensor, CUDA, потім CPU.
• 10:43
  Перевірте, що саме прив'язується до вузлів вашого графа.
• 10:46
  Зареєструйте, чи призначаються вузли уваги Attention Tensor з об'єднаними ядрами чи загальним ядрам CUDA.
• 10:52
  Далі дослідіть середовище.
• 10:54
  Опитайте драйвер.
• 10:55
  NVIDIA SMI показує модуль ядра та сумісність CUDA.
• 10:58
  Считайте версії бібліотек у контейнері.
• 11:00
  LípCuda, LípCablas, LípCAN, Linwinfer.
• 11:03
  Якщо образ містить бібліотеки CUDA 12, 3, а драйвер госта підтримує лише 12, 2, режим сумісності може завантажитися з обмеженнями.
• 11:11
  Якщо образ очікує заголовки Tensor 8, 6, а вузол надає 8, 4, виклики ARRI погіршаться або анулюють певні оптимізації.
• 11:18
  Рішенням є матриця збірки, а не сподівання.
• 11:21
  Зафіксуйте точні версії в єдиному джерелі істини.
• 11:24
  Базовий образ із сумісністю драйверів, мінорною версією CUDA, CAN, хешем збірки OART та версією Tensor.
• 11:30
  Створюйте образи для виведення відповідно до цієї матриці та відхиляйте вузли, що не збігаються, через мітки вузлів та перевірки допуску.
• 11:36
  Попередньо створюйте та кешуйте рушії Tensor для кожного варіанта моделі та роздільної здатності на тій самій версії Tensor, яку ви розгортаєте.
• 11:41
  Ставтеся до файлів плану як до артефактів, прив'язаних до матриці.
• 11:44
  Ніколи не покладайтеся на створення рушія на вузлі у продуктивному середовищі.
• 11:47
  Це маскує відхилення та подовжує час холодного старту.
• 11:50
  Щоб закріпити результат, додайте CI-тести, що перевіряють можливості ядер.
• 11:54
  Запустіть контейнер в ізольованому середовищі з цільовим драйвером і перевірте,
• 11:57
  чи завантажує Tensor ядра FP16, чи об'єднані вузли уваги, чи активна прив'язка I.O., чи розпізнані сформерс або SDP.
• 12:05
  Запустіть детермінований набір підказок і скасуйте збірку, якщо затримка перевищує базовий рівень або логи містять повідомлення про відкат до інших методів.
• 12:13
  Зберігайте знімок можливостей разом із дайджестом образу, щоб відкати відновлювали як код, так і характеристики продуктивності.
• 12:19
  Зрештою, докази свідчать, що відхилення версій – це не баг, як бачите.
• 12:22
  Це ціна, яку ви платите швидкістю.
• 12:27
  Ерозія ефективності через неправильну конфігурацію закладена в проєкті.
• 12:33
  Навіть коли версії збігаються, контейнер може саботувати ефективність всередини.
• 12:37
  Докази вказують на повільний витік, роздутість образу, відсутність GPU-інфраструктури та поведінку алукатора, що спотворює затримку під навантаженням.
• 12:44
  Ніщо не падає, все деградує.
• 12:47
  Чому це важливо? Просто.
• 12:49
  Контейнери формують реальність середовища виконання.
• 12:51
  Якщо образ заважкий, а холодні старти довгі, репліки запізнюються на інцидент.
• 12:56
  Якщо пристрої GPU не змонтовані або середовищу, виконання бракує правильних прапорів, провайдери виконання поводяться неправильно.
• 13:01
  Якщо арени пам'яті накопичують виділення, це через активність ARM викликає підкачування та стрибки затримки.
• 13:06
  Модель виглядає нормально.
• 13:08
  Контейнер тихо обтяжує кожен запит.
• 13:10
  При детальнішому розгляді виявляється накопичення артефактів під час збірки.
• 13:14
  Образи перевищують 2 ГБ через компілятори, заголовки та тестові ресурси через відсутність багатоетапної збірки.
• 13:19
  Відсутній докерігнор залучає ноутбуки, кеші та експериментальні ваги у виробничі шари.
• 13:24
  Кожне розгортання завантажує гігабайти через мережу.
• 13:27
  Маштабуйте це на пули вузлів, і холодний старт стає правилом, а не винятком.
• 13:31
  Докази не є загадковими.
• 13:33
  Історія Дока розповідає цю історію по шарах.
• 13:35
  Середовище виконання виявляє другий рівень ерозії.
• 13:38
  Без явних прапорів GPU, без GPU в Дока або через відсутність конфігурації плагіна пристрою в Кубанітаз,
• 13:44
  Процес не бачить пристроїв NVIDIA.
• 13:47
  Помилки конфігурації NVIDIA-контейна Toolkit приховують ліпкуда.
• 13:51
  Отже, друзі, провайдер виконання завантажується з обмеженнями або не завантажується взагалі.
• 13:55
  MIG не застосовується, тому навантаження борються за фрагменти пам'яті, створюючи втрати, які планувальники не розуміють.
• 14:00
  Журнали залишаються ввічливими, продуктивність згасає.
• 14:02
  Поведінка пам'яті – це третій рівень.
• 14:04
  За замовчуванням арена пам'яті CUDA в ONNX, рантайм агресивно кешує виділення.
• 14:14
  Тому передача між хостом і пристроєм відбувається через підкачувані буфери, перетворюючи PCI і на вузьке місце.
• 14:20
  Відвивід не прив'язаний до пристрою, тому тензори стрибають між CPU та GPU, створюючи невидимі податки на затримку.
• 14:25
  Спочатку погіршується хвостова поведінка, а потім середня.
• 14:28
  Ось як виглядає цей набір симптомів у реальних умовах.
• 14:31
  Ефективна пропускна здатність відстає, попри помірне використання GPU.
• 14:34
  Затримка при легкому навантаженні прийнятна, але P95 коливається при конкурентності, а потім непередбачувано стрибає.
• 14:40
  Випадкові OOM Kill скидають репліки при піковому трафіку, створюючи ефект стада.
• 14:44
  Перезапуски стають каскадними, автоскалювання працює нестабільно, а черги накопичуються.
• 14:47
  Оператори шукають не ту причину, вважаючи модель важкою, тоді як політики контейнерів спричиняють колапс.
• 14:52
  Ставтеся до гігієни контейнерів, як до роботи з доказами.
• 14:54
  Багатоетапні збірки видаляють відбитки пальців.
• 14:56
  Компілятори та інструменти розробки ніколи не потрапляють у середовище виконання.
• 14:59
  D-Strelless або Slim базовий образ звужує поверхню атаки та скорочує час завантаження.
• 15:03
  Аудити Doka Slim або Dive підтверджують, що вижило після збірки.
• 15:06
  Doka Rignor запобігає випадковому накопиченню зайвого.
• 15:09
  Результатом є судова чистота.
• 15:10
  Працює лише те, що має працювати.
• 15:13
  Налаштування GPU потребують явних вказівок.
• 15:15
  У Doka оголошуйте всі GPU або точний фрагмент MIG.
• 15:19
  У Kubanitas запитуйте ресурси NVIDIA GPU і переконайтеся, що плагін пристрою відповідає вашій гілці драйверів.
• 15:25
  Під час запуску перевіряйте наявність пристрою та сумісність драйверів.
• 15:28
  NVIDIA SME та LDConfig – це не прикраси, а перевірки допуску.
• 15:31
  Якщо щось відсутнє або не збігається, запишіть це як порушення та завершіть роботу.
• 15:35
  Потім налаштувайте ONNX Runtime та Tensor цілеспрямовано.
• 15:38
  Заблокуйте порядок провайдерів виконання лише на шляхах GPU у виробничому середовищі.
• 15:45
  Під час запитуйте, що перевищують робочий набір.
• 15:47
  Обмежте зростання або встановіть попереднє виділення в передбачуваних межах.
• 15:50
  Увімкніть АВП-16 за замовчуванням, якщо це дозволяють обмеження точності.
• 15:54
  Захистіть INT вісьмома тестом на точність.
• 15:57
  Прив'яжіть введення-виведення до пам'яті пристрою, щоб дані потрапляли туди, де відбувається обчислення,
• 16:01
  та ретельно оберейте потоки, щоб запобігти блокуванню черги.
• 16:03
  Закріпіть це двома перевірками – працездатність та продуктивність.
• 16:06
  Працездатність – це не просто статус 200, це підтверджений знімок можливостей.
• 16:10
  Провайдери завантажені, об'єднані ядра присутні, тензорні ядра розпізнані, введення-виведення обмежене.
• 16:15
  Продуктивність – це базовий набір запитів, що виконується під час запуску з вікном затримки та мінімальним порогом використання.
• 16:20
  Якщо контейнер не відповідає обом вимогам, він не допускається до обслуговування.
• 16:24
  Встановіть бюджети розміру образу для CI, щоб збірки, які перевищують ліміти, завершувалися помилкою.
• 16:28
  Зберігайте різницю вмісту образів для кожного дайджесту, щоб відкати відновлювали код та гігієну системи.
• 16:33
  Дані свідчать, що контейнери не просто розгортають ПЕЗЕ, вони кодують поведінку під навантаженням.
• 16:38
  Коли вони шумні, важкі або невизначені щодо GPU, вони перетворюють прискорення на формальність.
• 16:43
  Коли вони легкі, чіткі та впевнені, вони зберігають швидкий шлях, за який ви заплатили.
• 16:46
  У цьому середовищі нічого не буває випадковим.
• 16:48
  Контейнер або допомагає GPU виконувати роботу, або заважає йому.
• 16:51
  Лабораторія криміналістики, метрики, що виносять вирок.
• 16:54
  Затримка, пропускна здатність, рівень використання.
• 16:57
  Докази важливіші задумки, тому ми фіксуємо набір запитів, блокуємо сіди та прогріваємо систему.
• 17:01
  Ті самі планувальники, ті самі кроки.
• 17:03
  2025 для 512 розширено до 50 для 1024 на 1024, щоб виявити навантаження.
• 17:09
  Паралельність утримується на рівні 16 і з перевіркою до 32.
• 17:12
  Розмір пакета починається з одиниці й обережно зростає, доки не впреця у межі ВІРМ.
• 17:16
  Жодної екстраполяції, жодних виправдань, лише годинники та лічильники.
• 17:20
  Затримка свідчить першою.
• 17:21
  У деградованому стані при використанні CPU або стандартного шляху Attention P50 для 512 на 512 розтягується до двозначних чисел.
• 17:28
  P95 розповідає справжню історію.
• 17:30
  Він непередбачувано коливається від 20 до 40 секунд, бо черги накопичують дрібні неефективності.
• 17:35
  При 1024 на 1024 з 50-ма кроками P95 одразу стає критичним порушенням.
• 17:41
  Після виправлення DPUP заблоковано, Fused Attention активовано, I.O. прив'язано до пристрою, P50 повертається до низьких значень, а P95 вкладається в бюджет.
• 17:50
  Діапазон звужується, система стає передбачуваною.
• 17:53
  Пропускна здатність це підтверджує.
• 17:55
  При паралельності 16 деградований шлях дає лише краплю.
• 17:58
  Кількість зображень за хвилину ледь зростає при додаванні реплік, бо кожен екземпляр гальмує сам себе.
• 18:02
  Масштабування до 32-х множить суперечки, а не продуктивність.
• 18:05
  Після виправлення залежність вирівнюється.
• 18:07
  Зображення за хвилину зростають майже лінійно, поки не насититься робочий цикл тензорних ядер або VRM не обмежить пакет.
• 18:13
  Різниця в нахилі графіка – це і є вирок.
• 18:15
  Робота справді швидше доходить до фінішу, а не просто створює більше шуму.
• 18:18
  Використання закриває справу.
• 18:20
  До цього робочий цикл DPU коливався від 0 до 50% з довгими пласкими провалами.
• 18:25
  Лічильники ПСІ показують затримки від передачі даних зі сторінкових пам'ятій.
• 18:29
  Після робочий цикл стабілізується у високому послідовному діапазоні з помітним навантаженням тензорних ядер.
• 18:35
  CPU повертається до оркестрації та легкої попередньої обробки.
• 18:39
  Піки ПСІ стискаються, оскільки закріплена пам'ять та прив'язка вводу-виводу усунули зайвий трафік.
• 18:44
  Ніщо інше, крім реального прискорення, не пояснює ці зміни.
• 18:47
  Ми додаємо стресову перевірку.
• 18:48
  При 512 на 512 кроках 2025 оптимізований шлях підтримує паралелізм 16 безхвостових піків.
• 18:54
  При підвищенні до 32 система поступово деградує.
• 18:56
  Пі-95 зростає передбачувано, а не хаотично.
• 18:59
  При 1024 на 1024 на 50 кроках різниця стає ще відчутнішою.
• 19:04
  Деградований шлях зривається у таймаути.
• 19:07
  Загартований шлях утримує прийнятні Пі-50 та Пі-95 з пакетом від 1 до 2 до межі VRM.
• 19:12
  Ось де арени та потоки мають значення.
• 19:15
  Після налаштування блокування на початку черги зменшується.
• 19:17
  З точки зору витрат це проста арифметика.
• 19:19
  Запитів на годину GPU стає у від 2 до 5 разів більше, коли перевірено Fused Attention FP16 та прив'язку вводу-виводу.
• 19:25
  Ефективна вартість тисячі зображень відповідно падає.
• 19:28
  Штрафи за холодний старт зменшуються, бо образи компактні, а двигуни попередньо зібрані.
• 19:32
  Вузли перестають платити податок на компіляцію при першому зверненні.
• 19:35
  Реєстр збігається з логами.
• 19:37
  Верифікація запобігає випадковим успіхам.
• 19:39
  Повторіть на другому пулі вузлів з іншою мінорною версією драйвера.
• 19:42
  Загартований образ за задумом відмовляється запускатися на невідповідному вузлі.
• 19:46
  Тому результати порівнянні, а не спотворені.
• 19:49
  Перехресно перевіряйте знімки можливостей.
• 19:51
  Той самий порядок провайдерів, той самий тенсорт, ті самі твердження ядра.
• 19:55
  Повторно запустіть набір запитів і знову зафіксуйте розподіли.
• 19:58
  Коли гістограми збігаються, впевненість зростає.
• 20:00
  Коли ні, різниця в можливостях пояснює причину.
• 20:03
  Зрештою, цифри не сперечаються, вони доводять.
• 20:05
  Затримка стискається, пропускна здатність зростає, використання стабілізується.
• 20:09
  Патологія не є гіпотетичною.
• 20:11
  Вона вимірювана і після виправлення залишає відбитки на кожному графіку.
• 20:14
  Протокол виправлення – це контрольний список для повторюваного гартування.
• 20:18
  Контроль доступу на першому місці.
• 20:20
  Відмовляти в запуску, якщо відсутні провайдери Тенсорт або CUDA.
• 20:24
  Перераховуйте провайдери, перевіряйте кількість пристроїв,
• 20:26
  виведьте знімки можливостей CAN, FP16, робочий простір INT8.
• 20:31
  Якщо чогось не вистачає, завершуйте роботу з кодом помилки.
• 20:33
  Доступність слідує за цілісністю.
• 20:35
  Закріплення версій – це основа.
• 20:37
  Підтримуйте єдину матрицю, гілка драйвера, CUDA, CAN, хеш збірки ONNX, Runtime, Тенсорт.
• 20:42
  Збирайте образи для виведення відповідно до цієї матриці.
• 20:45
  Позначайте вузли для відповідності.
• 20:46
  Обмежуйте доступ на основі рівності.
• 20:48
  Попередньо зібрані двигуни Тенсорт для кожної моделі та роздільної здатності.
• 20:51
  Плани – це артефакти, а не припущення під час виконання.
• 20:54
  Гігієна контейнерів зберігає істину.
• 20:56
  Використовуйте багатоетапні збірки.
• 20:58
  Тримайте рантайм бездистрибутива або максимально легким.
• 21:00
  Включайте суворий докерігнор.
• 21:01
  Перевіряйте через докахістарі та аудит оптимізації розміру.
• 21:04
  Встановлюйте бюджети розміру пулу в CI.
• 21:06
  Блокуйте роздуті образи, підписуйте образи та звіряйте вміст за дайджестом.
• 21:10
  Налаштуйте GPU першочергово, зафіксуйте порядок IP на Тенсорт CUDA,
• 21:14
  вимкніть CPU провайдер у продуктиві.
• 21:16
  Підтвердьте наявність NVIDIA DEV та версію NVIDIA Container Toolkit.
• 21:19
  Запитуйте gpugvidea.com явно або змішуйте ліцензії та перевіряйте під час запуску.
• 21:24
  Налаштуйте середовище виконання.
• 21:25
  Увімкніть HP 16 за замовчуванням.
• 21:28
  Обмежте INT вісьмома перевірками точності.
• 21:30
  Прив'яжіть I.O. безпосередньо до пам'яті пристрою, увімкніть закріплену пам'ять, обирайте потоки, щоб уникнути черг.
• 21:37
  Переналаштуйте або вимкніть ORTC UDA Arena, якщо вона зупиняється за межами робочого набору.
• 21:41
  Встановіть ASL у продуктивності як код, самотестування при запуску з детермінованими підказками, вікном затримки та мінімальним використанням.
• 21:47
  Викликайте помилку при зростанні черг.
• 21:49
  Додайте спостережуваність метрики GPU на запит, сповіщення про деградацію, канейрі запити та порівнювані базові лінії.
• 21:55
  Розгортайте за модельлю Blue Green з контрольними точками продуктивності та автоматичним відкатом при порушенні.
• 22:00
  Коли протокол дотримується, прискорення є доведеним, а не передбачуваним.
• 22:04
  Урок цілком клінічний.
• 22:06
  Прихований перехід на CPU, розбіжність версій та роздуті контейнери – це не баги.
• 22:10
  Це передбачувані патерни збоїв, які ви можете заблокувати.
• 22:12
  Виконуйте протокол, вимірюйте утилізацію GPU, відмовляйтеся від деградованих шляхів, фіксуйте версії, ставтеся до двигунів, як до артефактів.
• 22:18
  Якщо ви хочете глибше зануритися в ONNX Runtime, роботу з пам'яттю TensorT, коли вимикати арени, дивіться наступний кейс у цій серії та підписуйтесь на лабораторні нотатки.