# Драйвер GPU: контролируемое сравнение двух версий

Диагностика: Драйвер GPU: контролируемое сравнение двух версий. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-driver-controlled-ab/
Language: ru

Сравнение драйверов требует удержать остальные факторы и сохранить совместимость среды. Если вместе с драйвером изменились CUDA libraries, engine и image, результат относится ко всему обновлению. Планируйте контрольный A/B-опыт с понятными условиями возврата и проверкой корректности работы.

## Сохраните baseline до изменения

Запишите GPU UUID, модель устройства, driver version, firmware identity, OS/kernel, image digest и runtime. Сохраните workload, входы, параметры и метод измерения времени. Nvidia-smi показывает версию драйвера и состояние устройства, но его CUDA version display не следует автоматически принимать за версию toolkit внутри контейнера. Для приложения отдельно определите фактические библиотеки. Если исходное окружение невозможно восстановить, сравнение двух серий уже имеет существенное ограничение, которое нужно обозначить заранее.


[Официальный источник 1](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html).

## Проверьте совместимость обеих версий

Изучите требования выбранного приложения и контейнерного стека до установки. Если версия B требует смены dependency, отметьте это как связанное изменение, а не скрывайте под названием «тест драйвера». Сохраните рабочий способ recovery узла и согласованное окно. Эта статья не задаёт универсальную команду замены kernel module: порядок зависит от OS, пакетов и активных клиентов GPU. Работы с общим узлом должны учитывать приложения, которые вообще не участвуют в benchmark.


[Официальный источник 2](https://docs.nvidia.com/deploy/nvidia-smi/index.html).

## Постройте matched series

В учебном дизайне сначала выполняется серия A на фиксированных входах, затем B, затем при возможности повтор A. Возвратная серия помогает увидеть временной дрейф, но не отменяет влияние всех неучтённых факторов. Сохраняйте прогрев и cache policy одинаковыми. CUDA execution часто асинхронно, поэтому границы CPU timer требуют корректной синхронизации для выбранного измерения. End-to-end latency и чистое время compute сохраняйте как разные показатели, не объединяя их под одной цифрой скорости.

| Поле сравнения | Зачем фиксировать |
| --- | --- |
| Driver и image | Определить изменённый фактор |
| Inputs и warmup | Сохранить одинаковую работу |
| Errors и result checks | Не потерять корректность |
| Run order | Увидеть возможный временной дрейф |

## Сравните не только среднее

Покажите отдельные прогоны, медиану, разброс и ошибки. Новая версия может менять стабильность, использование памяти или наблюдаемость без большого изменения средней скорости. Успешная генерация одного ответа не является полной проверкой приложения. Отдельно сравните startup, steady work и graceful exit на тестовой среде. Не приписывайте различие драйверу, если вместе с ним обнаружились новые clocks, power policy или конкурирующая нагрузка: сначала локализуйте эти изменения и повторите нужную часть опыта.

## Сформулируйте ограниченный вывод

Артефакт должен позволять восстановить A и B и пересчитать сводку из run-level данных. Напишите, какие изменения действительно изолированы, а какие остались confounded. Не публикуйте вымышленный процент ускорения без измерений. Решение об обновлении опирается на проверенную совместимость и нужный workload, а не на универсальную новизну версии. После выбора версии сохраните baseline для следующего обслуживания, чтобы будущая проверка сравнивала фактические состояния, а не воспоминание об удачном прогоне.

Связанные разборы: [software stack reproducibility](/ru/journal/software-stack-reproducibility/); [gpu maintenance change register](/ru/journal/gpu-maintenance-change-register/).