Как исправить «RuntimeError: Ошибка CUDA: сработало подтверждение на стороне устройства»

Опубликовано: 2025-10-14

Если вы работаете с моделями глубокого обучения в PyTorch, скорее всего, вы наткнулись на загадочное сообщение об ошибке, например:

 RuntimeError: CUDA error: device-side assert triggered

Эта ошибка может быть невероятно неприятной, особенно если вы не совсем уверены, что ее вызывает. В отличие от многих ошибок программирования, которые дают вам полезную трассировку стека, указывающую на проблему, эта может больше ощущаться так, будто ваш графический процессор поднимает брови и тихо уходит. Но не волнуйтесь — к концу этого руководства вы не только поймете, почему это происходит, но и как методично это исправить.

Что на самом деле означает эта ошибка?

Эта ошибка возникает, когда ядро ​​CUDA, работающее на вашем графическом процессоре, сталкивается с ошибкой утверждения. Обычно это происходит из-за недопустимого ввода или неожиданного поведения, которое вы можете не заметить в режиме ЦП. Поскольку это проблема на уровне графического процессора, она имеет тенденцию аварийно завершать работу без подробных сообщений отладки, которые мы привыкли видеть в исключениях Python.

Общие причины включают в себя:

  • Ошибки индексации (например, попытка использовать несуществующий индекс класса)
  • Недопустимые формы тензоров
  • Неправильное использование функции потерь
  • Данные, которые не оправдывают ожиданий (например, пустые тензоры)

К счастью, при правильном подходе вы можете отследить и устранить эту проблему — давайте рассмотрим, как это сделать.

Пошаговый процесс диагностики и исправления

1.Запустите свою модель на процессоре.

Первый шаг диагностики — отключить CUDA и запустить все на ЦП. Часто при работе на ЦП PyTorch выдает более четкие сообщения об ошибках, поскольку утверждения на стороне устройства теперь выдаются как исключения Python с полным контекстом.

Чтобы переключиться в режим ЦП, измените свой код следующим образом:

 device = torch.device("cpu") model.to(device)

Если утверждение не удалось, теперь вы должны получить гораздо более информативную трассировку стека.

2.Проверьте целевые метки

Одной из наиболее частых причин этой ошибки являются неправильные метки классов, особенно при использовании nn.CrossEntropyLoss . Эта функция потерь ожидает, что ваш целевой тензор будет включать индексы классов от 0 до num_classes - 1 . Итак, если ваша модель выводит 10 классов, целевые значения должны быть целыми числами от 0 до 9.

Распространенная ошибка:

 # Target contains 10 instead of 0–9 range target = torch.tensor([10])

Если эти индексы выходят за пределы, вы столкнетесь с утверждением на графическом процессоре. Чтобы подтвердить это, используйте:

 assert target.max().item() < num_classes

Если вы занимаетесь классификацией изображений, также убедитесь, что форма вашей цели подходит. Для CrossEntropyLoss он должен иметь форму [batch_size] , а не горячее кодирование!

 # Incorrect (for CrossEntropyLoss) target = torch.tensor([[0, 0, 1], [1, 0, 0]]) # Correct target = torch.tensor([2, 0])

3. Проверьте DataLoader на наличие ошибок.

Иногда ошибка возникает из-за вашего набора данных или DataLoader, особенно при использовании в пакетном обучении. Если некоторые метки повреждены или противоречивы, это может привести к поломке вашей модели на графическом процессоре.

Дважды проверьте свой набор данных следующим образом:

 for i, (x, y) in enumerate(loader): assert y.dtype == torch.long assert y.max().item() < num_classes assert x.shape[0] == y.shape[0]

Это особенно полезно, если ваш набор данных создан на основе CSV-файла или пользовательской логики обработки, которая может автоматически вводить недопустимые метки.

интроспективный разработчик, проверка кода, ноутбук, отладка

Другие распространенные ошибки

4. Несовпадающие размеры партий.

Иногда модель или функция потерь ожидают, что входные данные будут иметь определенную форму. Несоответствия могут привести к тонким проблемам. Убедитесь, что размер вашей партии во входных и целевых значениях совпадает:

 # torchvision models usually expect [N, 3, 224, 224] assert inputs.shape[1:] == (3, 224, 224)

Это особенно важно при использовании DataLoader с drop_last=False — последний пакет может быть меньше в зависимости от размера вашего набора данных. Ваша модель или операции, такие как BatchNorm, должны обрабатывать их правильно или явно проверять наличие небольших партий.

5. Случайные тензоры на разных устройствах

Убедитесь, что ваши входные функции и модель находятся на одном устройстве. Если вы отправите свою модель в CUDA, но оставите входные данные в ЦП, произойдет неожиданный сбой, часто без полезных ошибок.

Всегда дважды проверяйте:

 assert inputs.device == model.device

Совет для опытных пользователей: включите полный отчет об ошибках

Если работа на ЦП не помогает или вы работаете в смешанной конфигурации ЦП/ГП и по-прежнему не получаете полезных ошибок — попробуйте установить:

 CUDA_LAUNCH_BLOCKING=1 python my_script.py

Это говорит PyTorch синхронно запускать код графического процессора, поэтому он выйдет из строя точно в момент сбоя. Это может немного замедлить выполнение, но обеспечивает гораздо более четкую обратную трассировку.

Только в Python, без изменения оболочки:

 import os os.environ["CUDA_LAUNCH_BLOCKING"] = "1"

Теперь среда выполнения должна предлагать более конкретную информацию о том, где произошло утверждение CUDA.

Исправить на примере

Давайте рассмотрим практический пример. Предположим, вы строите модель классификации цифр в MNIST и определяете окончательный уровень модели следующим образом:

 self.fc = nn.Linear(128, 10)

В цикле обучения у вас есть:

 criterion = nn.CrossEntropyLoss() output = model(images) # Output shape: [batch_size, 10] loss = criterion(output, labels)

Но ваши ярлыки такие:

 labels = torch.tensor([[0], [1], [2]])

Эта форма неправильная. CrossEntropyLoss ожидает, что метки будут представлять собой одномерный вектор индексов классов:

 labels = torch.tensor([0, 1, 2])

Исправление этой формы само по себе может решить проблему.

модель Pytorch, функция потерь, ошибка графического процессора, исправление

Резюме: контрольный список для исправления ошибки

Прежде чем начать выдергивать волосы, следуйте этому контрольному списку:

  1. Переключитесь в режим ЦПи повторите попытку — сообщение об ошибке может быть более информативным.
  2. Проверьте метки классов:убедитесь, что они находятся в допустимом диапазоне и имеют правильный формат.
  3. Проверяйте данные, поступающие из DataLoader, — перебирайте пакеты и проверяйте на наличие аномалий.
  4. Обеспечьте правильные формы и размеры тензоров, особенно для выходных данных и целей.
  5. Используйте CUDA_LAUNCH_BLOCKING=1чтобы получить подробную синхронную обратную трассировку от CUDA.

Заключение

Хотя ошибка , вызванная утверждением на стороне устройства,поначалу может показаться расплывчатой ​​и непрозрачной, в конечном итоге это способ вашей модели или данных подать вам красный флаг. Систематически проверяя метки, формы данных, а также используя режим ЦП и блокировку запуска, вы почти всегда можете изолировать проблему.

В следующий раз вместо того, чтобы реагировать с растерянностью, вы будете вооружены знаниями и набором диагностических инструментов. Удачной отладки!