NVIDIA показала способ вернуть потерянную capacity LLM-инференса за секунды вместо нескольких минут: заранее прогретый теневой движок подхватывает нагрузку без повторной загрузки весов. Для инфраструктурных команд это шанс сократить горячий резерв, но только в узком классе аварий, где процесс умер, а GPU, драйверы и узел остались здоровы.
Что произошло
В техническом блоге NVIDIA описала Shadow Engine Recovery, preview-функцию NVIDIA Dynamo. На тех же GPU, где работает активный inference engine, заранее запускается полностью инициализированный теневой процесс. Он остаётся без нагрузки до отказа основного.
Ключевой компонент схемы, GPU Memory Service, или GMS, отделяет время жизни весов от процесса движка. Обычно GPU-память привязана к CUDA-контексту: процесс завершился, контекст исчез, веса пришлось снова читать из хранилища в HBM. Затем движок заново компилирует ядра, создаёт коммуникаторы и захватывает CUDA graphs. Для большой модели эта церемония занимает минуты, а оставшиеся воркеры всё это время обслуживают чужой трафик.
GMS работает как отдельный sidecar для каждого GPU и владеет физическими страницами памяти с весами. Активный и теневой движки отображают одни и те же данные в свои CUDA-контексты, поэтому вторая копия весов в HBM не нужна. При чтении весов дополнительной стоимости доступа нет, утверждает NVIDIA. Непередаваемое состояние, включая коммуникаторы и CUDA graphs, теневой движок готовит заранее.
В тесте на GLM-5.2 и узлах NVIDIA B200 компания намеренно завершила один воркер в конфигурации из двух. Холодный перезапуск занял 283 секунды. С Shadow Engine Recovery второй воркер вернулся в работу за 7,3 секунды, почти в 39 раз быстрее. Без тени оставшийся воркер принимал весь поток запросов, из-за чего рос TTFT и снижалась скорость декодирования на пользователя.
Быстрый recovery не равен бесплатному резерву
До сих пор проблема холодного старта обычно обсуждалась рядом с autoscaling: спрос вырос, Kubernetes поднял реплику, модель долго загружается. NVIDIA уже публиковала Dynamo Snapshot как способ ускорить запуск inference workloads на Kubernetes. Shadow Engine Recovery решает соседнюю, но другую задачу. Он не ждёт события, чтобы начать подготовку. Запасной процесс уже существует и лишь переключается из ожидания в обслуживание.
Отсюда и главный архитектурный сдвиг. Горячий резерв больше не обязательно означает отдельную реплику с ещё одной копией огромных весов. GMS позволяет двум движкам использовать одни физические данные в HBM, а значит, теневой процесс не несёт дополнительной стоимости самих весов.
Но слово «нулевой» здесь относится именно к marginal weight cost, а не ко всему резерву. Тень остаётся полностью инициализированным процессом на тех же GPU, GMS добавляет отдельный компонент, а общее потребление памяти и операционная цена такой схемы в опубликованном тесте не разложены. Поэтому вычитать горячие GPU из бюджета по одному красивому числу 7,3 секунды рано. Сначала придётся измерить накладные расходы на собственной модели, движке и профиле нагрузки.
Есть и более жёсткое ограничение: Shadow Engine Recovery лечит сбой процесса, а не исчезновение инфраструктуры. NVIDIA относит к целевым сценариям падения процесса, восстанавливаемые CUDA-ошибки и временные сбои коллективных операций, когда железо и узел продолжают работать. Если отказал GPU или весь node, тень, живущая рядом с основным движком, пропадёт вместе с ним. Для такого риска по-прежнему нужна capacity в другом месте.
Иными словами, обычный autoscaling отвечает на рост спроса, межузловой failover страхует железо, а shadow recovery быстро чинит программный процесс на живом GPU. Смешивать эти три задачи в один коэффициент запаса удобно только в таблице. В продакшене за это платят либо лишними ускорителями, либо сорванным SLA.
Что пересчитать сейчас
Командам стоит отдельно зафиксировать RTO для падения процесса и для отказа узла. Затем провести контролируемое завершение воркера под реальной нагрузкой и сравнить холодный restart с тенью по времени возврата capacity, TTFT, decode rate и расходу HBM. Поддержка GMS уже заявлена для vLLM, SGLang и NVIDIA TensorRT-LLM через специальный allocator, но сама функция пока имеет статус preview. KV cache через GMS текущая версия также не сохраняет, эта возможность находится в разработке.
Маркер успеха простой: если в вашем контуре воркер стабильно возвращается за секунды, а накладные расходы тени заметно ниже стоимости отдельной горячей реплики, запас GPU можно сокращать. Если же основные инциденты связаны с GPU и узлами, а не с процессами, Shadow Engine Recovery улучшит красивый тест, но не ваш RTO.