CapordiaЗібрати компактний, але відтворюваний вихідний матеріал
Зберігайте версії системи, застосунку та його залежностей, процедуру запуску й невеликий репрезентативний набір. Додайте очікувані шляхи, дозволи та спосіб перевірки вихідних даних. Цей маніфест описує відому відправну точку. Для зміни створіть кандидатну версію поряд із цією відправною точкою; секрети залишаються у вашому засобі керування доступом. Називайте відсутні елементи та їхнього відповідального, а не приховуйте їх за згадкою «середовище готове».
Призначте одну людину для приймання й іншу для рішення про перемикання, якщо цього вимагає ваша організація. Вони мають знати критерії, перш ніж нове опрацювання стане залежністю для решти команди. Уподобання Ubuntu, PyTorch, Blender чи власний варіант, вибраний під час замовлення, визначає підготовку; воно не замінює точного переліку вашого застосунку.
Перевірити ресурси, які насправді видно
Під час надання порівняйте виявлену модель, кількість карт і їхню пам'ять з очікуваним обсягом. Також зафіксуйте елементи, потрібні для проєкту, які не описані самим лише GPU: систему, робочий простір, дозволи та доступ до призначень. Розбіжність стає конкретним питанням, яке треба вирішити, без припущення про наявність потужності CPU, мережі чи диска, відсутньої у специфікації.
У середовищі NVIDIA з наявним nvidia-smi запропонована команда зчитує назву, загальний обсяг пам'яті, заявлений інструментом, і драйвер. Вона не характеризує ні продуктивність, ні всі залежності CUDA. Для AMD скористайтеся документацією, що відповідає обладнанню та обраній комбінації ROCm; уникайте перенесення перевірки NVIDIA як доказу працездатності MI300X.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csvВиконати повний прохід з окремими критеріями
Перевірте послідовно доступ, конфігурацію, завантаження даних, виконання та експорт. Для кожного етапу зафіксуйте спостереження й рішення. Програма, що завершується без помилки, не обов'язково створила всі очікувані файли. І навпаки, коректне відображення карти не доводить, що програмне забезпечення використовує обраний GPU.
Визначте прийнятний результат до випробування. Це може бути точна кількість тек, візуально перевірене зображення чи числовий критерій. PyTorch нагадує, що повна відтворюваність не гарантована між версіями та платформами. Тож оберіть допуск, доречний для роботи, разом з відповідальною особою; не розширюйте його заднім числом лише для того, щоб пройти тест.
| Етап | Очікуване спостереження | Рішення в разі невдачі |
|---|---|---|
| Доступ | Уповноважена особа потрапляє до потрібного середовища | Виправити доступ до імпорту |
| Завантаження | Усі вхідні дані тестового набору читаються | Виправити пакет або його дозволи |
| Виконання | Обробка використовує передбачені ресурси й завершується | Визначити залежність або налаштування |
| Результат | Вміст відповідає записаним критеріям | Призупинити розширення кампанії |
| Експорт | Результат можна використати з місця призначення | Виправити вихідні дані до перемикання |
Опрацьований приклад: сто отриманих тек, дев'яносто дев'ять результатів
У цьому вигаданому випадку команда замінює версію A попередньої обробки на версію B. Її маніфест указує код, залежності та формат виведення до і після; набір приймання й далі складається з тих самих 100 тек, позначених від 001 до 100. Версія A дає 100 результатів. Версія B завершується, але експортує 99 різних ідентифікаторів: теки 057 бракує. Записаний критерій вимагає 100 результатів без дублікатів. Тож на цьому етапі зміну відхилено.
Залежність, потрібна для теки 057, відсутня в кандидатному пакеті. Команда відновлює її в новій версії маніфесту, перевіряє цю теку, а тоді повторно запускає всі 100 входів на виправленому кандидаті. Вона знову отримує 100 різних ідентифікаторів і відкриває пакет із кінцевого призначення. Повне випробування перевіряє, що виправлення не лише усунуло поодинокий випадок. Цей результат розв'язує описану розбіжність; він ще не доводить роботу на більшому обсязі чи за безперервного навантаження.
Порівняти маніфест до і після, тоді вирішити щодо впровадження
Запис про зміну вміщується в кілька рядків: причина, змінений елемент, збережені елементи, критерії та відповідальна особа. Зберігайте придатну для використання копію базової конфігурації. Якщо ви змінюєте одночасно драйвер, фреймворк і формат даних, ви множите можливі причини розбіжності. Розділяйте, коли це можливо; інакше явно розглядайте цю сукупність як ширшу зміну.
Після виправлення дайте власнику результату затвердити новий базовий рівень. Наведена нижче таблиця впорядковує це рішення; вона не є переліком наданого програмного забезпечення. Обрана версія стає базовою лише після узгоджених перевірок. Датуйте впровадження та вкажіть завдання, до яких воно застосовується, щоб двоє людей не запускали мовчки два варіанти однієї кампанії.
| Елемент | До | Обраний кандидат після виправлення |
|---|---|---|
| Застосунок | Версія A | Версія B, включно з виправленням залежності |
| Вхідні дані приймання | 100 зафіксованих наборів | Ті самі 100 наборів |
| Обов’язкові результати | 100 різних ідентифікаторів | 100 різних ідентифікаторів, прийнятний формат |
| Публікація | Еталон, який використовує команда | Дата впровадження після погодження відповідального |
Зберегти можливість відкату, не змішуючи результати
Перед впровадженням перевірте, чи попередній еталон усе ще може прочитати свої вхідні дані та відновити свій стан. Відокремте вихідні дані кандидата, уникайте подвійної публікації та визначте, хто може вирішити відкат. Якщо нове програмне забезпечення незворотно змінює робочі файли, самого лише збереження старої програми недостатньо: потрібен також сумісний стан даних. Посібник із міграції розглядає перехід між середовищами; тут рішення стосується кваліфікованої зміни програмного забезпечення.
Підтвердження оплати та надання доступу залишаються окремими від цих технічних перевірок. Кнопка «Я оплатив» повідомляє про оплату; вона не підтверджує ні доступ, ні зміну програмного забезпечення. Виконуйте випробування, коли середовище справді доступне, а потім пов’яжіть їхній результат із вашим номером замовлення у внутрішній справі.
Завершити з командою, здатною експлуатувати та виводити
Очікуваний результат — коротка справа: зафіксоване середовище, набір приймання, прийняті перевірки, залишкові розбіжності та особа, яка вирішує подальші дії. Дайте комусь, хто не готував встановлення, перечитати процедуру запуску. Якщо цій особі доводиться питати шлях або важливе налаштування, доповніть справу, перш ніж передавати їй експлуатацію.
Також заплануйте фінальне отримання та його перевірку. Часті помилки — розширювати навантаження до приймання, змінювати кілька версій під час діагностики та виявляти експорт лише в момент настання строку. На 3, 7 чи 30 днів передбачте час на ці етапи в обраному періоді, не вважаючи їх обов’язково миттєвими операціями.
Запитання для ухвалення рішення
Чи достатньо виявленої карти, щоб прийняти розгортання?
Ні. Виявлення перевіряє частину апаратного периметра. Ще потрібно завантажити вхідні дані, запустити програмне забезпечення, перевірити його результати та отримати їх із місця призначення. Кожна перевірка повинна мати окремий критерій.
Чи потрібні точно ідентичні вихідні дані після зміни GPU?
Це залежить від вашого процесу. Визначте, що має залишатися строго ідентичним, а що належить до обґрунтованого допуску. Документуйте версії та параметри; не можна припускати цілковиту ідентичність для будь-якого програмного забезпечення та будь-якого середовища.
Хто вирішує, що розбіжність прийнятна?
Призначений відповідальний за відповідний критерій, разом із особою, яка ухвалює рішення про перехід, якщо розбіжність впливає на сервіс. Особа, яка запускає випробування, описує спостереження; вона не замінює автоматично відповідального за бізнес-процес чи за дані.