nvidia-persistenced для LLM: production-runbook без скрытых GPU init

Зачем LLM-узлу persistence daemon

На headless GPU-сервере между двумя заданиями может не остаться ни одного клиента, который держит устройство открытым. В Linux это важная граница: когда последний клиент закрывает device file, драйвер может деинициализировать GPU, а следующий процесс снова оплачивает инициализацию и восстанавливает часть непостоянного состояния. Для интерактивного LLM-сервиса такая пауза выглядит странно: модель ещё не начала грузиться, а первый запрос после окна простоя уже медленнее обычного.

nvidia-persistenced решает именно эту узкую задачу. Демон остаётся пассивным клиентом устройства, держит нужные файлы открытыми и не выполняет вычисления. NVIDIA называет этот подход более надёжной заменой legacy persistence mode и направляет будущую разработку в сторону daemon; подробности есть в официальном руководстве по Persistence Daemon.

Важно не расширять обещание. Демон не ускоряет токены сам по себе, не исправляет нехватку VRAM, не лечит Xid и не гарантирует сохранение состояния после reset или перезагрузки драйвера. Он убирает один источник вариативности между CUDA-заданиями. Если у вас уже круглосуточно работает vLLM, Triton или другой процесс, эффект может быть почти незаметен: приложение и так держит GPU открытым.

Практический вопрос: есть ли у вас реальные интервалы без GPU-клиентов? Если нет, сначала ищите причину latency в очереди, thermal throttling или загрузке весов. Для смежной диагностики пригодится материал про GPU throttling через DCGM и Prometheus.

Baseline до первого restart

Любое изменение hardware control plane начинайте с evidence bundle. Здесь owner изменения — дежурный SRE или администратор GPU-узла, а наблюдаемое доказательство — неизменный inventory устройств и текущий режим persistence для каждого GPU. Не делайте первый systemctl restart, пока не записали driver version, UUID, PCI bus ID, состояние unit и список активных клиентов.

UUID нужен потому, что индекс GPU 0 может измениться после обслуживания или иной последовательности probe. Привязывайте действие к UUID или проверенному PCI bus ID, особенно на multi-GPU сервере. Сохраните вывод рядом с change ticket; секретов в нём обычно нет, но hostname и внутренние пути всё равно обрабатывайте по правилам вашей организации.

date -Is
cat /proc/driver/nvidia/version
systemctl is-enabled nvidia-persistenced.service || true
systemctl status nvidia-persistenced.service --no-pager
nvidia-smi --query-gpu=index,uuid,pci.bus_id,persistence_mode --format=csv
nvidia-smi --query-compute-apps=gpu_uuid,pid,process_name --format=csv,noheader
journalctl -u nvidia-persistenced.service -b --no-pager | tail -n 100

Stop condition проста: если inventory не совпадает с ожидаемым, драйвер не загружен или на целевом GPU есть неизвестный процесс, rollout откладывается. Нельзя «для чистоты» завершать чужой workload. Сначала выясните owner процесса и окно обслуживания.

Daemon и legacy mode: не путайте два слоя

В терминологии NVIDIA рядом живут два механизма. Legacy persistence mode — свойство kernel driver, которое можно включить через NVML или nvidia-smi. Persistence Daemon — user-space процесс, который имитирует долгоживущего клиента GPU. Если daemon запущен, актуальный nvidia-smi использует его RPC-интерфейс; если нет, утилита может откатиться к legacy реализации. Для оператора команда выглядит одинаково, но failure mode разный.

Команда nvidia-smi -pm 1 действует сразу, требует root и, согласно актуальной документации nvidia-smi, не сохраняется после reboot. Поэтому «один раз включили в консоли» — не configuration management. На пакетных установках NVIDIA systemd preset может автоматически включать daemon, но фактическое состояние всё равно проверяйте на конкретном дистрибутиве.

Не редактируйте vendor unit вслепую и не запускайте второй экземпляр вручную поверх systemd. Сначала определите, кто владеет lifecycle: пакет, образ узла, cloud-init или ваш automation. Иначе после обновления драйвера останется одновременно старый override и новый unit.

GPU_UUID="GPU-REPLACE-WITH-VERIFIED-UUID"

sudo systemctl restart nvidia-persistenced.service
sudo nvidia-smi -i "$GPU_UUID" -pm 1

systemctl is-active nvidia-persistenced.service
nvidia-smi -i "$GPU_UUID"   --query-gpu=uuid,pci.bus_id,persistence_mode   --format=csv,noheader

Не копируйте UUID из примера: подставьте значение из baseline и ещё раз сопоставьте PCI bus ID. На сервере с несколькими арендаторами право на изменение должно быть привязано к change scope, а не ко всему inventory.

Infrastructure gate: доказать состояние, а не команду

Успешный exit code от nvidia-smi — только начало. Infrastructure gate проходит, когда одновременно активен systemd unit, процесс daemon существует в ожидаемом security context, UUID не изменились, а persistence mode включён только на целевых устройствах. Проверяйте effective state после команды, а не строку из runbook.

Добавьте отрицательный контроль границы. Если rollout рассчитан на один canary GPU, соседний GPU должен сохранить прежний режим. Такая проверка защищает от опечатки без -i, которая меняет все ускорители. На выделенном single-tenant сервере это всё равно полезно: вы доказываете точность automation.

TARGET_UUID="GPU-REPLACE-TARGET"
CONTROL_UUID="GPU-REPLACE-CONTROL"

systemctl is-active --quiet nvidia-persistenced.service
nvidia-smi -i "$TARGET_UUID"   --query-gpu=uuid,persistence_mode --format=csv,noheader
nvidia-smi -i "$CONTROL_UUID"   --query-gpu=uuid,persistence_mode --format=csv,noheader

ps -eo user,pid,cmd | grep '[n]vidia-persistenced'
journalctl -u nvidia-persistenced.service -b --since '-10 min' --no-pager

Ожидаемое значение для control зависит от плана: оно не обязано быть Disabled, но обязано не измениться относительно baseline. Если изменилось, остановите rollout и восстановите исходное состояние. По той же логике в runbook по NVIDIA Fabric Manager и NVSwitch hardware inventory проверяется отдельно от приложения.

Application gate: проверить LLM, а не только GPU

Infrastructure gate не отвечает на главный вопрос пользователя: готов ли endpoint принимать запросы. Поэтому после daemon проверки запускайте тот же application probe, который используется в обычном rollout модели. Это может быть readiness endpoint vLLM, короткий детерминированный запрос к вашему gateway или загрузка минимального CUDA-контекста. Команда должна возвращать измеримый результат и fail closed.

Сравнивайте не единичную цифру, а распределение вашей штатной метрики на одинаковом workload: время readiness после controlled restart, ошибки загрузки модели, first-request latency после подтверждённого idle interval. Не обещайте ускорение заранее. NVIDIA пишет, что повторная инициализация может добавлять задержку, в том числе из-за ECC scrubbing, но реальный эффект зависит от GPU, драйвера и того, оставался ли другой клиент.

SERVICE_URL="http://127.0.0.1:8000"

curl --fail --silent --show-error   --max-time 10   "$SERVICE_URL/health" >/dev/null

curl --fail --silent --show-error   --max-time 10   "$SERVICE_URL/v1/models" | head -c 500

nvidia-smi --query-compute-apps=gpu_uuid,pid,process_name   --format=csv,noheader

Отрицательный контроль здесь — заведомо неверный endpoint или остановленный canary backend, который должен дать non-zero exit и не попасть в балансировщик. Если ваш скрипт считает такой ответ успехом, проблема опаснее persistence: readiness маскирует отказ.

Для model-weight integrity добавьте отдельную проверку immutable revision; это подробно разобрано в статье про fs-verity для весов LLM. Persistence не заменяет pinned model identity.

Systemd hardening без поломки vendor unit

NVIDIA рекомендует запускать daemon без постоянных root-привилегий. Root нужен для подготовки runtime data, после чего процесс можно опустить до отдельного пользователя через --user. Дистрибутивные пакеты обычно уже принимают это решение за вас, поэтому сначала изучите systemctl cat nvidia-persistenced и effective user. Не заменяйте unit целиком только ради красивого шаблона.

Для локальной политики используйте drop-in и меняйте лишь понятные параметры lifecycle. Например, Restart=on-failure уместен, если команда эксплуатации согласна автоматически поднимать daemon после аварийного выхода. Но бесконечный restart не должен скрывать несовместимый driver package или недоступный runtime directory: alert строится по restart counter и journal.

[Service]
Restart=on-failure
RestartSec=5s

sudo systemctl edit nvidia-persistenced.service
sudo systemctl daemon-reload
sudo systemctl restart nvidia-persistenced.service

systemctl show nvidia-persistenced.service   -p User -p Group -p Restart -p NRestarts
systemctl status nvidia-persistenced.service --no-pager

Не добавляйте sandboxing-директивы пакетом. Сначала тестируйте каждую в canary: daemon нужен доступ к NVIDIA device files, библиотеке libnvidia-cfg и runtime directory. Слишком жёсткий PrivateDevices выглядит безопасно, но отрежет саму функцию сервиса.

Canary rollout и честная атрибуция эффекта

Включайте изменение на одном узле, а не на всём inference pool. Canary должен обслуживать тот же класс запросов, иметь ту же модель и driver branch, но оставаться легко выводимым из балансировщика. До изменения запишите baseline по нескольким одинаковым циклам: controlled stop workload, подтверждённый idle interval, start, readiness, первый запрос.

После включения daemon повторите тот же сценарий. Не сравнивайте ночной canary с дневным production: очередь, page cache и загрузка storage исказят вывод. Цель — доказать причинность, а не получить красивую цифру. Если readiness стала стабильнее, но first-token latency не изменилась, так и запишите: вы убрали variation на driver-init слое, но bottleneck остался в загрузке weights или scheduler.

Затем выполните контрфакт: временно верните persistence целевого canary к baseline в согласованное окно и повторите probe. Если метрика не возвращается, эффект, вероятно, принадлежит другому изменению. Проверяйте и миграцию bottleneck: daemon может убрать init delay, после чего заметнее станет NVMe, CPU preprocessing или сеть.

Для multi-GPU систем не смешивайте этот rollout с ACS, IOMMU или BAR-настройками. Их отдельные gates описаны в runbook по PCIe ACS и P2P DMA.

Типовые сбои и stop conditions

Unit active, mode Disabled. Это не противоречие: daemon может работать, даже когда persistence выключен на всех устройствах. Проверьте точечную команду, права и target UUID. Не перезапускайте драйвер ради косметики.

Mode Enabled, daemon inactive. Возможно, nvidia-smi использовал legacy kernel mode. Система может работать, но lifecycle расходится с планом и после reboot состояние пропадёт. Исправьте owner конфигурации и повторите infrastructure gate.

Daemon не стартует после обновления. Сверьте loaded driver version с пакетами, права runtime directory и journal. Stop condition — restart loop или mismatch библиотек. Не ослабляйте unit до root навсегда только потому, что это убирает симптом.

LLM probe падает при зелёном daemon. Разделение gates как раз показывает, что проблема выше: модель, storage, CUDA compatibility, topology или сам сервер. При Xid собирайте evidence до reset и используйте отдельный runbook диагностики NVIDIA Xid.

Изменилась вся группа GPU. Скорее всего, команда была выполнена без точного -i. Остановите rollout, сравните каждый UUID с baseline и восстановите режим поштучно. Automation после такого инцидента должна fail closed при изменении inventory.

Rollback теми же gates в обратном порядке

Rollback — не команда -pm 0, а возврат узла к сохранённому baseline. Сначала выведите canary из трафика и дождитесь завершения известных заданий. Затем отключите persistence только на target UUID, верните systemd drop-in при необходимости и повторите проверки identity, effective state и application readiness.

Не делайте GPU reset автоматически: для возврата persistence mode он обычно не требуется, а reset затрагивает клиентов и может изменить диагностическую картину. Если reset нужен из-за отдельного инцидента, это уже другой change с собственным evidence и approval.

GPU_UUID="GPU-REPLACE-WITH-VERIFIED-UUID"

sudo nvidia-smi -i "$GPU_UUID" -pm 0

nvidia-smi -i "$GPU_UUID"   --query-gpu=uuid,pci.bus_id,persistence_mode   --format=csv,noheader
systemctl status nvidia-persistenced.service --no-pager

# После возврата service configuration:
sudo systemctl daemon-reload
sudo systemctl restart nvidia-persistenced.service

Application probe после rollback должен быть тем же, что после rollout. Если endpoint не готов, узел не возвращается в балансировщик, даже когда persistence mode совпал с baseline. Наблюдаемое доказательство важнее формального завершения команды.

Что оставить в production runbook

nvidia-persistenced полезен там, где headless GPU действительно остаётся без клиентов между LLM-заданиями. Он удерживает driver state через долгоживущий user-space процесс и делает поведение между jobs предсказуемее, но не превращает инфраструктурную настройку в гарантию низкой latency.

Хороший production runbook разделяет четыре доказательства: pinned GPU identity, effective state daemon/mode, application readiness и отрицательный контроль границы. Rollout и rollback используют те же проверки в одном порядке. Тогда команда понимает не только что выполнилась команда, но и почему узел безопасно возвращать в трафик.

Начните с одного canary на выделенном GPU-сервере, снимите честный baseline и повторите controlled idle test. Если persistence убирает именно вашу вариативность, закрепите настройку в образе или configuration management. Если эффект не подтверждается, оставьте baseline и ищите bottleneck на следующем слое — это тоже хороший результат эксперимента.