Шлях діагностики у чотири рішення
Мета — знайти перший шар, який зазнає невдачі, а не пробувати кілька встановлень підряд. Зберігайте запущену команду, перше повідомлення про помилку та результат кожної перевірки. Якщо ви зміните одночасно Python, пакунок PyTorch і розмір batch, то вже не знатимете, яка саме зміна розв'язала проблему.
Завантажуваний скрипт застосовує цю послідовність і створює обмежений технічний звіт. Він не запускає вашу модель і не змінює ваше встановлення. Використовуйте його в тому самому середовищі, що й ваш проєкт, інакше ви перевірятимете інший інтерпретатор, ніж той, у якому стався збій програми.
Прокрутіть таблицю, щоб побачити всі стовпці.| Перевірка | Якщо перевірка не пройшла | Що дає змогу зробити її успіх |
|---|---|---|
| 1. Інтерпретатор та імпорт | Виправте використовуваний Python або його встановлення PyTorch. | Прочитайте версію та бекенд фактично імпортованого пакунка. |
| 2. Бекенд і пристрій | Перевірте пакунок, драйвер, надання GPU та права. | Запросіть виділення ресурсів на цільовому GPU. |
| 3. Невелике обчислення на GPU | Збережіть помилку виділення, обчислення чи синхронізації. | Перейдіть до зменшеного вхідного набору застосунку. |
| 4. Репрезентативний застосунок | Ізолюйте ваги, розширення, формат, пам'ять чи неправильний вивід. | Поступово збільшуйте реальне навантаження. |
1. Визначте Python, який фактично виконується
Термінал, notebook і служба можуть використовувати різні інтерпретатори. Виведіть sys.executable у контексті, який запускає проєкт, а тоді перевірте версію. Шлях дає змогу виявити забуте віртуальне середовище або notebook, що залишився на іншому ядрі. Перегляньте його на своїй машині; публікувати своє особисте дерево каталогів у звіті не потрібно.
Далі використайте той самий інтерпретатор, щоб опитати пакунки. Команда python -m pip show torch дає інформацію про PyTorch, пов'язаний із цим Python. Якщо import torch зазнає невдачі, наступний крок — виправити це встановлення: зменшення batch чи зміна вагів моделі не розв'яже проблему відсутнього модуля.
python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip show torch2. Розрізняйте CUDA, ROCm і пакунок без прискорення GPU
Зафіксуйте окремо torch.__version__, torch.version.cuda і torch.version.hip. Не робіть висновку «пакунок для CPU» лише на підставі значення None у torch.version.cuda: PyTorch для ROCm використовує HIP, повторно застосовує torch.cuda і так само очікує пристрій із назвою cuda. Заміна цієї назви на rocm чи hip — не те виправлення, яке слід застосовувати.
Потім перевірте torch.cuda.is_available() і torch.cuda.device_count(). Ці результати описують те, що це середовище Python може використати на цей момент. Вони не замінюють мінімального обчислення. Системний засіб може бачити карту, тоді як пакет, драйвер, доступний процесу, або його середовище заважають PyTorch використати її.
python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.device_count())"3. Створення звіту за допомогою скрипту Kernodeck
Після завантаження файлу помістіть його в робочу теку та запустіть за допомогою Python проєкту. За замовчуванням він вимагає GPU. Режим CPU потрібно запитати явно: його успіх перевіряє гілку CPU діагностики й ніколи не перетворює недоступний GPU на підтверджений GPU. Звіт виводиться в термінал, а з --output — у новий файл JSON. Наявний файл ніколи не перезаписується: виберіть іншу назву для наступної спроби.
Скрипт виділяє дві матриці 2 × 2 у float32, перевіряє їхній добуток, потім градієнт і синхронізує пристрій GPU. Очікуване значення втрат становить 196 для цього фіксованого обчислення. Ця дуже коротка перевірка не завантажує жодних ваг моделі й не вимірює жодної пропускної здатності. Вона вимагає невеликого реального обчислення від бекенду, поза межами простого виявлення пристрою.
Необов’язкова системна перевірка використовує nvidia-smi, коли він наявний. Вона повідомляє лише версію драйвера NVIDIA та загальний обсяг пам’яті, видимий цим засобом; вона не є еквівалентною системною перевіркою для ROCm. Час очікування обчислення становить 30 секунд за замовчуванням і може бути від 5 до 120 секунд. Системна перевірка має власний максимальний час очікування 3 секунди.
python kernodeck-diagnostic-v1.py --device-index 0 --timeout 30 --output diagnostic-gpu.jsonpython kernodeck-diagnostic-v1.py --device cpu --output diagnostic-cpu.jsonpython kernodeck-diagnostic-v1.py --host-check --output diagnostic-gpu-systeme.json4. Читання звіту та вибір наступної дії
Почніть зі status, code, exit_code та stage. Блок runtime визначає версію Python і родину системи. Блок pytorch розрізняє імпортований пакет, його версії компіляції CUDA/HIP, заявлений бекенд і видимі пристрої. Блок execution вказує, де насправді відбулося обчислення і чи було перевірено добуток та градієнт.
У режимі CPU gpu_available і visible_device_count залишаються null: скрипт не запитує стан драйвера GPU. Це не нуль і не збій. Також зверніть увагу на execution.device: пакет, скомпільований для CUDA, цілком може виконати цю перевірку на CPU, коли це запитано явно.
Звіт містить вибірку технічних даних. Він не включає змінні середовища, шляхи на машині, ідентифікатори сесії, повний список пакетів або необроблений стек винятку. Скрипт не надсилає жодного звіту до Kernodeck. Для докладної помилки вашої програми збережіть її стек у своєму робочому просторі й видаліть секрети перед тим, як ділитися нею.
Прокрутіть таблицю, щоб побачити всі стовпці.| Результат | Значення | Наступна дія |
|---|---|---|
| GPU_CHECK_PASSED · 0 | Добуток і градієнт перевірено на вибраному GPU. | Перейти до невеликого вводу вашої програми. |
| CPU_CHECK_PASSED · 0 | Добуток і градієнт перевірено лише на CPU. | Не робити висновків щодо CUDA або ROCm. |
| TORCH_MISSING · 3 / TORCH_IMPORT_FAILED · 4 | PyTorch відсутній у цьому Python або імпорт не вдається. | Перевірити інтерпретатор, пакет та його залежності. |
| GPU_BACKEND_ABSENT · 5 | Пакет не заявляє ні CUDA, ні HIP. | Встановити пакет, що відповідає вашому середовищу. |
| GPU_UNAVAILABLE · 6 / DEVICE_INDEX_INVALID · 7 | GPU не використовується в цьому процесі або індекс поза межами видимих пристроїв. | Перевірити доступність карт, драйвер і запитаний індекс. |
| CHECK_FAILED · 8 / OUT_OF_MEMORY або RUNTIME_ERROR · 9 | Збій фіксованого обчислення, виділення пам’яті або операції бекенду. | Прочитати зазначений етап перед запуском повної моделі. |
| TIMEOUT · 10 / WORKER_FAILED · 11 | Перевірку зупинено через час очікування або без придатного звіту. | Розглядати перевірку як невдачу; дослідити середовище. |
| OUTPUT_WRITE_FAILED · 12 | Звіт не було збережено за вказаним призначенням. | Використайте нову доступну назву файлу. |
5. Перехід від невеликого обчислення до вашого застосунку
Перед запуском підготуйте відтворювану команду, ідентифіковану модель, невеликий набір даних і доступний каталог виводу. Виберіть вхідні дані, які зберігають важливі характеристики фінальної роботи: довжину тексту, розміри зображення, формат аудіо або обов’язкові поля. Штучно короткі вхідні дані можуть приховати проблему, яку ви хочете спостерігати.
Опишіть конкретний критерій успіху. Для обчислення embeddings кожен ідентифікатор входу має дати вектор очікуваної розмірності зі скінченними значеннями. Для навчання один крок має дати придатне для використання значення втрат, оновити передбачені параметри та дозволити збереження. Код виходу процесу доповнює ці перевірки; він їх не замінює.
Додайте маркери до і після читання параметрів, імпорту бібліотек, завантаження ваг, підготовки даних, їх перенесення, обчислення та запису. Надайте кожній спробі ідентифікатор і зберігайте пов’язані з нею параметри. Повідомлення «модель завантажено» має відповідати завершеній події, а не просто наміру завантажити.
Журналюйте форми, типи та пристрої потрібних тензорів, не копіюючи весь набір даних. Підсумок на кшталт «вхід: 8 послідовностей, максимальна довжина 512, пристрій cuda:0» допомагає порівнювати дві спроби. Ці числа описують тут приклад журналу, а не універсальну конфігурацію. Уникайте розміщення токенів доступу або чутливого вмісту вхідних даних у цих повідомленнях.
6. Виправлення помилки на правильному рівні
Якщо невелике обчислення проходить, але ваги не знайдено, перевірте їхній шлях, формат і права доступу. Якщо розширення не вдається імпортувати, перевірте його сумісність із пакетом PyTorch і бекендом проєкту. Успішна діагностика не засвідчує всі розширення застосунку. Поверніться до першого кроку, який зазнає невдачі, замість змінювати кілька залежностей одночасно.
Помилка пристрою може походити від вхідних даних, що залишилися на CPU, тоді як модель на GPU. Помилка типу може походити від часткового перетворення або оператора, несумісного з вибраною точністю. Збережіть перше повне повідомлення та його трасування. Змінюйте лише одну гіпотезу за раз, потім перезапускайте мінімальні вхідні дані, перш ніж повертати фінальний обсяг.
7. Якщо модель запускається, а потім перевищує пам’ять
Визначте, чи перевищення виникає під час завантаження ваг, першого обчислення чи після кількох ітерацій. Ці моменти вказують на різні причини: завелика модель, значні активації або кеш генерації, накопичення збережених тензорів. Зафіксуйте torch.cuda.memory_allocated() і torch.cuda.memory_reserved() на тих самих етапах. Перший відстежує виділення тензорів; другий охоплює пам’ять, якою керує алокатор.
torch.cuda.empty_cache() може повернути невикористаний кеш, але не видаляє тензори, на які ще є посилання. Тому перевірте списки виводів, історії втрат і об’єкти, що зберігають граф обчислень. Потім зменште batch або довжину входу, щоб ізолювати визначальний чинник. Зміна карти стає обґрунтованим рішенням, коли ви знаєте фазу, на якій виникає перевищення, і реально необхідний запас.
8. Вимірювання обчислення з урахуванням асинхронності
Операції GPU можуть бути асинхронними щодо програми Python. Тому секундомір, розміщений навколо виклику, може вимірювати переважно надсилання роботи. Для діагностичного вимірювання синхронізуйте GPU на межах спостережуваного сегмента або використовуйте відповідні події. Ця синхронізація змінює перебіг: тримайте цю інструментацію окремо від звичайної роботи вашого застосунку.
Побудуйте простий приклад із трьома сегментами: підготовка входу, обчислення, запис виходу. Для сегмента GPU викличте torch.cuda.synchronize(), зафіксуйте time.perf_counter(), виконайте обчислення, синхронізуйте знову, а потім обчисліть різницю. Зберігайте окремо перший прохід і наступні. Завантаження чи ініціалізація не повинні зникати в середньому, яке подають як повний час відгуку.
9. Контролювати виходи та зберігати придатну для повторного використання діагностику
Для класичного виведення model.eval() встановлює поведінку відповідних модулів, тоді як torch.inference_mode() вимикає відстеження, потрібне для градієнтів. Ці два налаштування мають різні функції. Використовуйте друге, коли створені тензори не повинні згодом брати участь в обчисленні з градієнтами. Оцінювання моделі під час навчання вимагає явно повернути правильний режим перед продовженням.
Тепер порівняйте виходи з підготовленим контрактом: кількість результатів, відповідність ідентифікаторів, розмірності, скінченні значення та відповідна бізнес-метрика. Якщо ви збільшуєте batch, перевірте цю відповідність ще раз. Якщо ви додаєте GPU, проконтролюйте розподіл входів і збирання виходів. Партії оренди позначають замовлені карти; batch позначає приклади, які ваша програма обробляє разом.
Результат цього методу — невелика тека: команда, версії, параметри, мінімальний вхід, останній успішний крок, перша помилка, спостереження щодо пам’яті та отриманий вихід. Якщо запуск працює, збережіть цю теку як точку порівняння перед збільшенням навантаження. Якщо запуск не вдається, вона дає змогу відтворити проблему, не починаючи все розслідування заново.
Перед тривалою обробкою також виконайте чисте завершення та відновлення на цьому малому наборі входів. Перевірте, що вже записані виходи не втрачено й не пораховано двічі. Коли ці перевірки пройдено, поступово збільшуйте лише одну вісь — batch, довжину, паралельність або кількість процесів — і фіксуйте спостережувану межу. Ви отримуєте виміряний діапазон роботи для вашого застосунку, а не припущення, пов’язане з назвою GPU.
Наданий доказ та його межі
Приклади для завантаження походять із реальних перевірок, виконаних 24 вересня 2026 року. Обидва запуски з PyTorch використовують Windows, Python 3.14.6 і PyTorch 2.11.0+cu128. Перевірка GPU використовує CUDA на NVIDIA GeForce RTX 5070; перевірка CPU явно вимагає CPU. Це обладнання для перевірки не подано як пропозицію Kernodeck. Жодних обчислень ROCm для цього доказу не виконувалося.
Успішне мале обчислення показує, що шлях виділення пам’яті та обчислення працює на вибраному пристрої. Воно не вимірює ні швидкість вашої моделі, ні пам’ять, потрібну для її найбільших входів, ні її сумісність із конкретним розширенням. Звіт також не засвідчує багатокарткову топологію. Переходьте до репрезентативного випробування, перш ніж вирішувати збільшувати навантаження чи оренду.
Для застосунку CUDA порівняйте картку NVIDIA зі своїми потребами в пам’яті та бібліотеках; для ланцюжка ROCm розгляньте умови MI300X. Пов’язані картки — це варіанти для кваліфікації вашого проєкту, а не перелік обладнання, використаного в доказі. Враховуйте час початкової перевірки та експорту у свій період 3, 7 або 30 днів.
Прокрутіть таблицю, щоб побачити всі стовпці.| Реальна перевірка | Спостережуваний результат | Обсяг |
|---|---|---|
| Явний CPU · Python 3.14.6 / PyTorch 2.11.0+cu128 | CPU_CHECK_PASSED; добуток і градієнт точні; втрата 196. | Фіксоване обчислення працює на CPU. |
| CUDA · RTX 5070 / пакет CUDA 12.8 | GPU_CHECK_PASSED; добуток і градієнт точні; втрата 196. | Фіксоване обчислення працює на цій карті в цьому середовищі. |
| PyTorch відсутній · Python 3.12.14 | TORCH_MISSING; код виходу 3. | Відсутність модуля спричиняє явну помилку. |
| GPU зроблено невидимим для процесу перевірки | GPU_UNAVAILABLE; код виходу 6. | Скрипт не підмінює GPU на CPU мовчки. |