# N+1 для GPU: запас обслуживания измеряется на рабочей нагрузке

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

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

N+1 для GPU нельзя подтвердить одной запасной картой в inventory. После вывода выбранного элемента должна оставаться готовая ёмкость под нужный workload и критерии обработки. Учитывайте подготовку реплик, ограничения размещения и общий failure domain, а не только сумму устройств.

## Определите единицу удаления

Запишите, что именно выводится: GPU, весь сервер, rack segment или другой элемент. Если несколько карт находятся в одном host, обслуживание этого host убирает их вместе. Общие зависимости также могут сделать номинальные ресурсы недоступными одновременно. Для каждого сценария составьте список остающихся ready workers и совместимых моделей. Наличие устройства без загруженных артефактов и проверенного запуска не равно немедленно доступной производительности. N+1 здесь требует явного определения границы, а не обещания универсальной отказоустойчивости.


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

## Измерьте полезную ёмкость

Для каждого worker зафиксируйте workload mix, latency/error criteria и устойчивый результат. NVIDIA best practices помогают задать корректное измерение CUDA, а DCGM diagnostics — отдельные проверки состояния среды. Диагностический pass не заменяет измеренный serving capacity. Не объявляйте максимальный краткий benchmark устойчивым потолком для обслуживания. Сохраните ресурсы CPU, RAM и сеть: после вывода одного узла оставшиеся worker могут начать конкурировать за общую зависимость раньше достижения собственного GPU предела.


[Официальный источник 2](https://docs.nvidia.com/datacenter/dcgm/latest/learn/modules/dcgm-diagnostics.html).

## Посчитайте условный сценарий

Представим четыре независимых worker, каждый в тесте устойчиво выполняет 30 одинаковых операций в минуту при выбранных критериях. После удаления одного остаётся 90, а входной поток равен 80. Арифметический запас составляет 10 операций в минуту в условиях этого примера. Это синтетические числа, не показатели оборудования или SLA. Если удаляется сервер с двумя worker, расчёт другой. Если требуется cold start замены, отдельно анализируют переходный интервал и накопление работы.

| Поле сценария | Что фиксируется |
| --- | --- |
| Removed domain | Какие worker исчезают вместе |
| Remaining capacity | Измеренный готовый ресурс |
| Demand profile | Нужный тип и объём работы |
| Transition interval | Как меняется ёмкость во времени |

## Проверьте переход, а не только итог

На стенде перестаньте назначать новую работу выбранному worker предусмотренным способом и проследите готовность остальных. Плановое обслуживание и внезапный отказ имеют разные последовательности. Сохраните очередь, ошибки и время подготовки резервного процесса. Если запас существует только после длительного запуска, он не покрывает весь переход автоматически. Не обещайте нулевые потери по одной сумме capacity: поведение повторов, ownership задач и маршрутизации должно быть спроектировано и проверено отдельно.

## Сохраните capacity worksheet

Артефакт включает measured capacities, критерии, failure domains и timeline проверенного сценария. Укажите ограничения суммирования неоднородных worker и зависимость от workload mix. После изменения модели или software stack повторите измерение: прежний резерв может исчезнуть без изменения числа GPU. Такой worksheet помогает проверить конкретный maintenance plan, но не устанавливает договорное SLA. Обозначение N+1 имеет смысл только рядом с определённым элементом отказа и подтверждённой достаточностью остающейся рабочей ёмкости.

Связанные разборы: [inference capacity planning](/ru/journal/inference-capacity-planning/); [reserve gpu capacity](/ru/journal/reserve-gpu-capacity/).