1. Визначте еталон і очікуваний результат
Почніть із того, що ви хочете відтворити: отримувати ті самі категорії, отримувати близькі значення чи відтворювати траєкторію навчання. Збережіть невеликий набір вхідних даних, який проходить важливі кроки, і приклад валідного виводу. Встановлення, що завершується без помилок, ще не відповідає на це питання.
Розгляньмо навчальний приклад: ваш застосунок створює ембедінги для визначеного зразка. У еталонному середовищі ви маєте зафіксувати форму виходів, їхній тип, відсутність необмежених (нечислових) значень і корисний бізнес-критерій. Якщо ви порівнюєте значення, виберіть допуск, обґрунтований вашим використанням. Універсального числового порогу тут не наведено.
Призначте ревізію коду, даним і вагам. Назва на кшталт «остання-модель» може змінитися без жодного відображення в програмі. Також прив’яжіть параметри та попередню обробку до еталону. Ця справа дає змогу зрозуміти, чи походить різниця від програмного забезпечення, вхідних даних або умов виконання.
Прокрутіть таблицю, щоб побачити всі стовпці.| Елемент | Що зберегти | Контроль після відтворення |
|---|---|---|
| Код і параметри | Ревізія, можливі зміни, конфігурація | Той самий вхідний пункт і ті самі опції. |
| Дані та ваги | Версія або відбиток, походження та права доступу | Той самий зразок і той самий очікуваний вміст. |
| Python і пакунки | Версії, процедура та джерела встановлення | Правильний інтерпретатор і узгоджені залежності. |
| Система та бекенд | ОС, архітектура, драйвер, CUDA або ROCm | Видимий пристрій і успішне мінімальне обчислення. |
| Результат | Формат і критерії приймання | Структура, а потім якість або передбачений допуск. |
2. Відокремити системний ланцюг від пакунків Python
Перевіряйте разом карту, систему, драйвер, Python і бібліотеки. Віртуальне середовище впорядковує пакунки Python; воно не замінює системний драйвер. Так само посилання на образ не описує фактичного доступу до GPU з його хоста. Для скомпільованого розширення зафіксуйте потрібні інструменти та бібліотеки компіляції.
Виберіть дистрибутив PyTorch, виходячи з обчислювальної платформи вашого проєкту. На ROCm PyTorch використовує ті самі виклики torch.cuda і пристрої з назвою cuda: назва інтерфейсу не дає змоги ідентифікувати NVIDIA. Фіксуйте окремо torch.version.cuda і torch.version.hip. Розширення, написане для певного ланцюга, заслуговує на власну перевірку.
Збережіть процедуру, яка фактично дозволила встановлення, разом із походженням пакунків. Уникайте змішування недавньої команди, знайденої в мережі, зі старим файлом залежностей без перевірки їхньої сумісності. Переглянута документація може змінюватися; впишіть використані версії у власну справу.
3. Написати відтворення замість копіювання встановленої справи
Створіть нове середовище з вибраним Python. Потім явно використовуйте його інтерпретатор для встановлення та запуску проєкту. У Linux це буде, наприклад, .venv-rebuild/bin/python; у Windows — .venv-rebuild\Scripts\python.exe. Вам не потрібно залежати від попередньої активації. Документація Python зазначає, що віртуальне середовище потрібно створювати заново, коли воно змінює розташування.
pip freeze дає перелік встановлених пакунків, а не обчислений файл блокування. Зберігайте його як спостереження. Файл відтворення також має явно вказувати індекси або файли, потрібні для вашого варіанта PyTorch, і сумісні версії. Перечитайте шляхи чи URL, які може містити перелік, перш ніж ним поділитися.
Наведені нижче команди ілюструють відтворення в Linux, яке треба адаптувати; вони не є виконаним випробуванням вашого проєкту. Файл requirements-rebuild.txt уже має описувати ваше середовище, зокрема правильний вибір PyTorch. Не замінюйте його списком версій, які вважаються універсальними.
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. Перевірити контракт залежностей перед обчисленням
python -m pip check, запущений із правильним інтерпретатором, шукає відсутні або несумісні встановлені залежності за їхніми метаданими. Результат без конфліктів не є підтвердженням драйвера, нативних розширень або якості застосунку. Тож робіть цей крок коротким і переходьте до контролю обчислень.
Щоб зробити відтворення суворішим, ви можете зафіксувати версії та зберегти відбитки дозволених дистрибутивів. Це рішення вимагає підтримувати повний список, що відповідає вашій платформі. Архів скомпільованих wheel-пакетів може залежати від ОС і архітектури; він не є гарантією переносності між двома різними машинами.
У нашому прикладі з ембедінгами порівняйте відтворений інвентар із референсом, перш ніж змінювати модель або її параметри. Якщо розбіжність навмисна, зафіксуйте її та розглядайте новий запуск як варіант. Інакше виправте відтворення; зміна кількох шарів одночасно зробить діагностику менш точною.
5. Перехід від мінімальної перевірки до застосунку
В інтерпретаторі проєкту зафіксуйте Python, PyTorch і бекенд, потім перевірте пристрій і невелике обчислення. Зупиніть цей крок, якщо очікуваний GPU недоступний; резервний запуск на CPU спотворить порівняння. Діагностика Kernodeck надає зрозумілий звіт і розрізняє фактично пройдені кроки.
Після успішної перевірки скористайтеся своїм невеликим прикладом застосунку. Для ембедінгів перевірте кількість виходів, їхні розмірності, відповідність ідентифікаторам і обраний критерій. Перезавантажте файли з вихідної теки. Успішне матричне обчислення не доводить, що попередня обробка чи розширення проєкту працюють.
Якщо спроба падає під час читання даних, передавання чи конкретної операції, збережіть крок і першу помилку. Загальне відтворення може бути правильним; блокування може належати завантажувачу даних або окремому оператору. Тоді спрямуйте діагностику на цей шар.
6. Розрізнення відтворення та числової ідентичності
Відтворення тих самих залежностей не гарантує однакових результатів між обладнанням, платформами чи версіями PyTorch. Фіксація сіда не охоплює всі джерела варіацій. Документуйте використані генератори, перетворення даних і відповідні налаштування точності чи детермінізму.
Визначте критерій порівняння, перш ніж дивитися на різницю: точна структура, числовий допуск або стабільність метрики. Деякі детерміністичні налаштування можуть відхиляти операції або змінювати вартість обчислень. Бажаний результат — зрозумілий висновок за оголошених умов, а не обіцянка ідентичності на будь-якій машині.
Для відновлення навчання версій недостатньо: потрібно також відновити стан обчислень і прогрес. Тека відновлення перевіряє це питання окремо. Її вправа на CPU та її допуск не стають автоматично умовами вашої моделі.
7. Завершити текою, яку може використати інший запуск
Підсумкова тека об'єднує процедуру, спостережений інвентар, конфігурацію, посилання на дані та результати перевірки. Додайте точну послідовність: відтворити, діагностувати, запустити приклад, перечитати вихід. Зберігайте доступи окремо та зазначте лише, як їх надавати.
Повторіть цю послідовність у чистій теці, перш ніж вважати середовище передаваним. Перевірка має пройти без отримання змінної зі старого notebook чи пошуку забутого файлу. Якщо потрібна зміна, виправте процедуру та надайте референсу нову ідентичність. Ви отримуєте базу, придатну для наступного періоду обчислень.