В этом материале
N+1 для GPU нельзя подтвердить одной запасной картой в inventory. После вывода выбранного элемента должна оставаться готовая ёмкость под нужный workload и критерии обработки. Учитывайте подготовку реплик, ограничения размещения и общий failure domain, а не только сумму устройств.
N+1 для GPU нельзя подтвердить одной запасной картой в inventory. После вывода выбранного элемента должна оставаться готовая ёмкость под нужный workload и критерии обработки. Учитывайте подготовку реплик, ограничения размещения и общий failure domain, а не только сумму устройств.
Определите единицу удаления
Запишите, что именно выводится: GPU, весь сервер, rack segment или другой элемент. Если несколько карт находятся в одном host, обслуживание этого host убирает их вместе. Общие зависимости также могут сделать номинальные ресурсы недоступными одновременно. Для каждого сценария составьте список остающихся ready workers и совместимых моделей. Наличие устройства без загруженных артефактов и проверенного запуска не равно немедленно доступной производительности. N+1 здесь требует явного определения границы, а не обещания универсальной отказоустойчивости.
Измерьте полезную ёмкость
Для каждого worker зафиксируйте workload mix, latency/error criteria и устойчивый результат. NVIDIA best practices помогают задать корректное измерение CUDA, а DCGM diagnostics — отдельные проверки состояния среды. Диагностический pass не заменяет измеренный serving capacity. Не объявляйте максимальный краткий benchmark устойчивым потолком для обслуживания. Сохраните ресурсы CPU, RAM и сеть: после вывода одного узла оставшиеся worker могут начать конкурировать за общую зависимость раньше достижения собственного GPU предела.
Посчитайте условный сценарий
Представим четыре независимых 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; reserve gpu capacity.