Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Где на самом деле живёт задержка LLM-стрима

У LLM API слово latency слишком легко превращается в один общий график. Для диагностики этого недостаточно. Минимум разделите путь на три наблюдаемых интервала: время до первого байта/токена, паузы между последующими чанками и полную длительность ответа. Первый интервал часто определяется очередью запросов, prefill, доступностью GPU, cold start модели или работой gateway. Второй уже сильнее зависит от decode cadence, buffering и сетевой доставки. Третий смешивает всё сразу.

Практический пример: TTFT вырос с обычного уровня, а после первого токена поток идёт ровно. Это плохой кандидат для BBR: congestion control не сокращает очередь на GPU. Обратная картина — первый токен появляется вовремя, но далее клиент видит нерегулярные паузы, RTT под нагрузкой растёт, на sender-сокете видны retransmissions или очередь qdisc. Вот здесь сетевой слой уже заслуживает отдельного canary-теста.

Ещё одна типичная ловушка — настроить не тот хост. Если внешний TCP завершается на reverse proxy, ingress-controller или L7 gateway, именно он является sender для клиентского соединения. Изменение TCP congestion control на backend с vLLM не обязано повлиять на WAN-сегмент до пользователя. Для архитектуры gateway полезно сначала свериться с материалом про Private AI API, а для проблем на GPU — с разбором GPU throttling через DCGM и Prometheus.

Поэтому первый gate простой: вы должны назвать конкретный TCP sender, интерфейс, клиентский сегмент и пользовательскую метрику, которую собираетесь улучшить. Если этого нет, смена алгоритма — тюнинг вслепую.

Что BBR и fq действительно меняют в Linux

BBR — congestion control для TCP, который опирается на модель пропускной способности пути и RTT и управляет тем, сколько данных и с какой скоростью отправлять. В Linux алгоритм для новых соединений выбирается через net.ipv4.tcp_congestion_control; список уже зарегистрированных вариантов виден в net.ipv4.tcp_available_congestion_control. Документация ядра подчёркивает важную деталь: изменение sysctl задаёт алгоритм именно для новых TCP-соединений, поэтому проверять результат на старом keep-alive сокете бессмысленно.

fq — classless qdisc, рассчитанный прежде всего на локально генерируемый трафик. Он разделяет потоки и умеет уважать pacing, заданный TCP stack. Это не «ускоритель BBR», а scheduler на egress, который помогает выпускать пакеты во времени более управляемо. После перехода Linux на EDT TCP-level pacing больше не делает fq формально обязательным для работы BBR; Google отдельно отмечает, что на современных ядрах BBR может работать и с другими qdisc, хотя fq остаётся полезным на нагруженных серверах.

Отсюда главный operational вывод: тестировать нужно пару механизмов, а не магическую строку из старого блога. Сначала убедитесь, какой congestion control реально назначен сокету; затем — какой root qdisc реально висит на нужном интерфейсе. net.core.default_qdisc показывает дефолт для создаваемых qdisc, но фактическое состояние интерфейса смотрите через tc qdisc show.

Не путайте и версии BBR. Ветка Google BBRv3 существует отдельно от стандартного bbr, поставляемого конкретным дистрибутивным ядром. Нельзя по одному имени sysctl заключить, что у вас именно v3: это проверяется по происхождению и сборке ядра. Для production-runbook разумнее начинать с того BBR, который поддерживается вашим kernel/vendor profile, а экспериментальную ветку выносить в отдельный change.

Baseline начинается с identity: какой сокет, интерфейс и qdisc вы меняете

До любых изменений соберите evidence bundle. Нужны версия ядра, доступные congestion control, текущий алгоритм, реальный qdisc интерфейса, состояние NIC и несколько живых TCP-сокетов. Это защищает от самой неприятной ошибки: вы включили BBR на backend, а клиентский TCP на самом деле живёт в другом network namespace, на proxy или вообще в отдельном узле.

Сначала определите интерфейс по маршруту до тестового клиента: ip route get CLIENT_IP. Если сервис в контейнере, проверьте, где заканчивается TCP — в pod, host network, ingress или внешнем балансировщике. На bare metal и обычном VPS sender чаще очевиден, но и там source policy routing или bonding могут отправлять трафик не через тот интерфейс, который вы выбрали по имени.

IFACE=ens5

uname -r
ip route get 203.0.113.10
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.core.default_qdisc

tc qdisc show dev "$IFACE"
ip -s link show dev "$IFACE"
ss -tin state established | head -n 80

Адрес 203.0.113.10 здесь — документационный пример: замените его IP своего canary-клиента. Не копируйте имя ens5 вслепую. Сохраните вывод рядом с change ticket: после rollout и rollback вы будете сравнивать не память инженера, а одно и то же состояние.

Отдельно запишите topology class: физический dedicated, KVM/VPS, bonding, VLAN, NAT, внешний LB. BBR работает на TCP sender, но гипервизор, vSwitch, NIC ring, ToR и провайдерский uplink остаются другими очередями. Если проблема живёт там, красивый ss на гостевой ОС не доказывает, что вы контролируете bottleneck.

Сначала докажите сетевую причину, а уже потом меняйте congestion control

Хороший canary начинается с гипотезы, которую можно опровергнуть. Например: «при одинаковом запросе TTFT остаётся стабильным, но p95 паузы между SSE-чанками растут вместе с RTT/retransmissions на клиентском TCP». Это гораздо сильнее, чем «пользователь говорит, что ответ идёт рывками».

На application layer зафиксируйте TTFT, интервал между чанками и полную длительность ответа. На network layer — RTT, retransmissions, delivery/pacing rate конкретного сокета и статистику qdisc. На host layer — CPU softirq, NIC drops и saturation, если они есть в вашей телеметрии. Важен один и тот же запрос или фиксированный набор canary-запросов, одинаковая модель, одинаковый лимит токенов и один и тот же клиентский регион. Иначе вы сравните разные workloads.

Если ss -tin показывает app_limited, это сильный disqualifier для идеи «нам мешает congestion control»: sender не заполняет доступный путь постоянно. Для LLM это нормально — decode выдаёт токены дискретно. В такой ситуации BBR может быть технически активен, но пользовательский ритм определяет приложение. Аналогично, если retransmissions не меняются, qdisc backlog почти пуст, а паузы коррелируют с GPU decode, сетевой эксперимент лучше остановить.

Не забывайте прокси. Если Nginx/Envoy/HAProxy завершает клиентский TCP, снимайте socket evidence там. Backend-соединение между proxy и inference node может выглядеть идеально и никак не описывать WAN-очередь. Разницу между L4 и L7 особенно важно учитывать в streaming API: семантика buffering и timeout может дать те же симптомы, что и плохая сеть.

Снимите контрольный профиль CUBIC и не меняйте workload одновременно

Перед BBR нужен контрольный профиль текущего congestion control. На большинстве систем это будет CUBIC, но не предполагайте — прочитайте sysctl и фактический сокет. Ключевая дисциплина эксперимента: не менять одновременно модель, batching, max tokens, proxy buffering, kernel, MTU и congestion control. Один change — одна причинная гипотеза.

Для LLM streaming полезнее всего воспроизводить не гигантский download, а настоящий API-путь. Генератор трафика должен проходить через тот же TLS terminator и тот же network segment, что и пользователь. Сохраняйте timestamp первого байта и времена каждого чанка. Если ваш клиент умеет только «полное время запроса», вы не увидите разницу между TTFT и последующими паузами.

Сетевые counters снимайте в том же окне. ss -tin показывает RTT, congestion window, pacing rate и другие параметры TCP; для BBR там же могут появляться bandwidth/min_rtt state и признак app_limited. tc -s qdisc show нужен, чтобы видеть фактическую egress-очередь, а не только выбранный алгоритм TCP.

IFACE=ens5

ss -tin state established | head -n 120
tc -s qdisc show dev "$IFACE"
nstat -az | grep -E 'TcpRetransSegs|IpOutDiscards'
ip -s link show dev "$IFACE"

Не задавайте заранее «нормальный процент улучшения». Такой порог без вашего traffic mix будет выдуманным benchmark. Сначала соберите распределение метрик на baseline, затем сравните canary в одинаковых условиях. Если разница меньше естественного разброса или исчезает после повторного прогона, честный вывод — причинность не доказана.

Для контекста по другим слоям полезно сопоставить этот эксперимент с NUMA-locality для GPU-инференса: там действует тот же принцип — низкоуровневый счётчик сам по себе не равен улучшению application SLO.

Включайте BBR и fq только на canary-узле

Когда baseline сохранён, переключайте один canary-host или небольшой canary-pool. Не начинайте с fleet-wide sysctl. Изменение congestion control затронет новые TCP-соединения, поэтому после переключения создайте новые клиентские сессии. Если приложение держит очень длинные keep-alive connections, старые сокеты могут продолжать жить с прежним профилем и смешивать результаты.

Сначала убедитесь, что модуль BBR доступен на вашем ядре. Затем переключите congestion control и qdisc. Команда tc qdisc replace ... root fq меняет root qdisc интерфейса прямо сейчас — это production change, а не безобидное чтение. Выполняйте его только на изолированном canary, где вы заранее знаете исходную конфигурацию и путь rollback.

IFACE=ens5

sudo modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo tc qdisc replace dev "$IFACE" root fq

sysctl net.ipv4.tcp_congestion_control
tc -s qdisc show dev "$IFACE"
ss -tin state established | head -n 120

Не записывайте настройки в /etc/sysctl.d до окончания canary. Сначала докажите эффект и rollback. Persistence — отдельный change. Так проще избежать ситуации, когда временный эксперимент пережил reboot и внезапно стал новым baseline.

На виртуальной машине отдельно проверьте, что вы действительно контролируете нужный egress. Гостевой fq не заменяет очереди vSwitch или физического uplink. На выделенном сервере граница контроля шире: вы управляете kernel, qdisc, NIC и часто topology целиком, но провайдерская сеть и клиентский last mile всё равно остаются вне хоста.

Как читать ss и qdisc без ложной победы по одной метрике

После переключения легко попасть в ловушку «в ss появился bbr — значит всё работает». Это доказывает только выбор congestion control для данного сокета. Для production-вывода нужны как минимум mechanism gate и application gate.

В mechanism gate смотрите, что новый сокет действительно использует BBR, что qdisc — fq, а pacing/delivery state выглядит правдоподобно. Сравните RTT, retransmissions и qdisc backlog с baseline. Если у BBR-сокета app_limited, не трактуйте низкий delivery rate как проблему сети: приложение само не подаёт достаточно данных. Для токенного стрима это частый режим.

В application gate проверяйте то, ради чего вообще делался change: распределение межтокенных пауз, tail latency стрима, число разрывов/повторных подключений и пользовательский SLO. TTFT держите рядом как контроль: если он внезапно изменился, вероятно, в эксперимент вмешалась очередь inference, autoscaling или другая нагрузка.

Сравнивать нужно идентичные traffic cohorts. Один быстрый клиент в соседнем дата-центре не доказывает эффект для мобильных пользователей через длинный WAN. И наоборот, один проблемный оператор связи не должен определять fleet-wide kernel policy. Разделите хотя бы внутренний/региональный и дальний внешний path.

Ещё один важный counterfactual — нагрузка. Повторите тест в спокойном окне. Если отличие BBR/fq проявляется только при заполненном egress и исчезает при низкой загрузке, это логично и полезно: вы локализовали queueing problem. Если «эффект» одинаков даже когда очередь пуста, ищите confounder.

Rollback — это часть эксперимента, а не аварийная кнопка

Если canary выглядит лучше, следующий шаг — не rollout, а возврат к baseline. Это отрицательный контроль. Сначала верните исходный congestion control и qdisc, откройте новые TCP-соединения и повторите тот же canary-набор. Если streaming metric возвращается к прежнему распределению, причинная связь становится сильнее. Если улучшение остаётся, BBR мог просто совпасть по времени с другой переменной.

Исходный qdisc нельзя угадывать. Сохраните его до эксперимента и восстанавливайте из вашего IaC/change record. Ниже показан только пример с переменными; подставлять fq_codel или cubic автоматически нельзя, если это не ваш реальный baseline.

IFACE=ens5
BASE_CC=cubic
BASE_QDISC=fq_codel

sudo sysctl -w net.ipv4.tcp_congestion_control="$BASE_CC"
sudo tc qdisc replace dev "$IFACE" root "$BASE_QDISC"

sysctl net.ipv4.tcp_congestion_control
tc -s qdisc show dev "$IFACE"

После rollback повторите mechanism gate и application gate в том же порядке. Если низкоуровневые TCP counters вернулись, а пользовательская метрика нет, значит bottleneck мигрировал или вы измеряете не тот слой. Например, сеть перестала быть ограничением, и теперь tail latency определяется gateway CPU, TLS, storage или decode cadence.

Именно поэтому rollback должен быть симметричным rollout. Не «вернули sysctl и разошлись», а заново проверили identity, сокет, qdisc и клиентский результат. Такой процесс длиннее, зато он предотвращает накопление мифических kernel tweaks, эффект которых никто не может воспроизвести.

Когда BBR/fq не поможет — и может отвлечь от настоящей причины

Первый disqualifier — HTTP/3. Клиентский HTTP/3 работает поверх QUIC, а не TCP; Linux sysctl net.ipv4.tcp_congestion_control не управляет QUIC congestion control. У Google для QUIC BBR есть отдельная реализация в quiche. Если внешний API уже на HTTP/3, тюнинг TCP BBR на этом сегменте — просто не тот механизм. Сначала разберите транспорт; для этого пригодится статья про HTTP/3 для AI API.

Второй disqualifier — app_limited и низкая интенсивность данных. LLM token streaming часто не похож на bulk transfer: приложение выдаёт небольшие чанки с паузами между decode steps. Если bottleneck bandwidth не заполняется, congestion control имеет мало пространства для улучшения пользовательского ритма.

Третий — buffering выше TCP. L7 proxy может копить данные до размера/таймера, библиотека — не flush-ить каждый chunk, а клиент — сам буферизовать UI. Тогда сеть доставляет всё корректно, но пользователь видит «пачки». Смотрите место фактической задержки, а не только wire metrics.

Четвёртый — saturation на GPU или admission control. Если очередь запросов растёт, TTFT уезжает, а inter-token gap ухудшается из-за конкуренции за compute, BBR здесь не лекарство. Иногда именно ограничение дорогих запросов через quota/rate policy стабилизирует сервис лучше сетевого тюнинга; см. разбор rate limits и quotas для дорогих API.

Пятый — bottleneck за пределами вашего host. Wi‑Fi пользователя, мобильная сеть, межоператорский peering и provider uplink могут доминировать. BBR на sender способен изменить своё поведение, но не даёт вам контроль над чужой очередью. Поэтому коммерчески ценен не сам алгоритм, а возможность воспроизводимо управлять своей частью пути и честно отделять её от внешней.

Production rollout: ценность не в sysctl, а в контроле сетевого пути

Если canary прошёл mechanism gate, application gate и rollback-контрфакт, можно обсуждать rollout. Делайте его по topology class: одинаковые kernel build, NIC/driver, qdisc baseline, MTU и роль в трафике. Не смешивайте в один wave разные типы виртуализации и физические серверы — одинаковый sysctl поверх разных egress paths не создаёт одинаковую систему.

Persistence включайте отдельным шагом. Зафиксируйте sysctl в управляемой конфигурации, qdisc — в network bootstrap/systemd unit или другом IaC-механизме, который ваша команда умеет проверять и откатывать. После reboot должен существовать тот же evidence gate: congestion control доступен, новые сокеты его используют, qdisc соответствует профилю, application canary проходит.

Для выделенной инфраструктуры это и есть естественный offer bridge. Dedicated host даёт ownership над kernel profile, qdisc, NIC, IRQ/CPU placement, reboot window и rollback. Это не обещание, что «dedicated + BBR всегда быстрее». Наоборот: ценность в том, что один и тот же baseline можно воспроизвести, а изменение — изолировать. Если команда не контролирует host networking или провайдер запрещает нужные kernel/qdisc changes, эксперимент может быть организационно невозможен.

При этом сеть не существует отдельно от inference topology. Если после устранения egress queue bottleneck переезжает в CPU/memory locality, вернитесь к системной диагностике. В multi-GPU сценариях полезно сопоставить сетевой rollout с NUMA-locality и другими host-level gates, а не пытаться одним TCP tweak закрыть всю цепочку.

Чек-лист перед rollout и главный вывод

BBR + fq имеет смысл не тогда, когда «так советуют для VPS», а когда вы доказали sender-side queueing problem на реальном LLM streaming path. Перед production change проверьте: известен фактический TCP sender; TTFT отделён от межтокенных пауз; baseline CUBIC/текущего CC сохранён; root qdisc известен; на canary открываются новые соединения; mechanism и application metrics улучшаются согласованно; rollback возвращает картину к baseline; после изменения bottleneck не переехал в GPU, gateway или другой сетевой слой.

Если хотя бы один из этих пунктов не выполняется, результат лучше назвать «интересным наблюдением», а не оптимизацией. Такой консерватизм экономит время: kernel tuning, который нельзя причинно связать с SLO, быстро превращается в технический долг.

Источники для перепроверки механики — актуальная документация Linux IP sysctl, описание tc-fq и материалы Google BBR. Они важнее старых рецептов с одной строкой sysctl.conf, потому что поведение pacing и kernel networking менялось.

Начните с одного canary-host и одного фиксированного набора streaming-запросов. Если эффект выдерживает повтор, rollback и reboot — тогда у вас есть инженерное основание для rollout. Если нет, это тоже хороший результат: вы исключили один слой и можете идти дальше по цепочке без гадания.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Сначала отделите HNSW maintenance от обычного pgvector tuning

У KingServers уже есть общий материал про pgvector в PostgreSQL для RAG: там важны выбор HNSW/IVFFlat, фильтрация, миграции и базовая эксплуатация. Здесь граница намеренно уже. Мы не выбираем индекс заново и не сравниваем PostgreSQL с отдельной vector DB. Нас интересует конкретный класс инцидентов: таблица с embeddings переживает заметный поток UPDATE/DELETE, после чего меняются maintenance time, количество dead tuples или проверяемый recall.

Это разграничение важно, потому что три независимые проблемы выглядят похоже. Первая — maintenance: PostgreSQL накопил obsolete tuple versions, а HNSW vacuum стал дорогим. Вторая — query budget: approximate scan просмотрел недостаточно кандидатов, особенно при фильтрах. Третья — semantic drift: изменилась embedding-модель или схема chunking, и старый индекс физически исправен, но вектора уже не соответствуют новому retrieval pipeline.

Не начинайте с команды REINDEX. Начните с трёх доказательств: версия pgvector, состояние таблицы/индекса и одинаковый canary-набор запросов для approximate-vs-exact сравнения. Только если эти слои указывают на maintenance path, имеет смысл расходовать I/O на rebuild.

Отдельный случай — смена embedding-модели. Для него у нас есть материал про embedding lifecycle и переиндексацию после смены модели. Обычный HNSW REINDEX не пересчитывает embeddings и не исправляет несовместимое vector space.

Version gate: проверьте pgvector до любого HNSW vacuum runbook

Версия здесь не формальность. В changelog pgvector есть несколько свежих исправлений именно вокруг HNSW vacuum: версия 0.8.3 от 17 июня 2026 года исправляла возможную corruption при vacuum, а 0.8.4 от 30 июня — ошибку hnsw graph not repaired и возможную ошибку при inserts во время HNSW vacuum. В актуальном changelog последняя версия — 0.8.6 от 29 июля 2026 года.

Это не означает, что любой production обязан немедленно прыгнуть на последнюю minor-версию без canary. Но если ваш maintenance-процесс построен на HNSW vacuum и вы всё ещё ниже ветки с этими исправлениями, сначала разберите upgrade path и release notes, а уже затем интерпретируйте странное поведение как «нормальный bloat».

PostgreSQL тоже фиксируйте в evidence bundle. На дату этой статьи current stable branch — PostgreSQL 18.6; при этом runbook ниже применим и к поддерживаемым 17/16/15/14, если соответствующие команды доступны. Не переносите значения memory/autovacuum между major-версиями вслепую.

SELECT version();

SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';

SELECT current_setting('server_version_num') AS server_version_num;

Что UPDATE и DELETE оставляют в PostgreSQL — и при чём здесь HNSW

PostgreSQL использует MVCC: удалённая строка или старая версия строки после UPDATE не исчезает физически мгновенно. Она остаётся как dead tuple, пока VACUUM не сможет её обработать. Поэтому write-heavy RAG corpus после массовой замены документов может иметь гораздо больше физической работы, чем подсказывает простое COUNT(*).

Для HNSW есть дополнительная практическая деталь: официальный pgvector README прямо предупреждает, что vacuum HNSW-индексов может занимать заметное время и рекомендует перед ним reindex. Это важнее, чем пытаться вывести универсальное правило вроде «при N% dead tuples всегда REINDEX»: такого порога документация не задаёт, а допустимый churn зависит от размера таблицы, storage I/O, окна обслуживания и запроса.

Нужно различать table dead tuples, index physical size и retrieval behavior. Большой n_dead_tup — сигнал к расследованию, но сам по себе не доказывает semantic recall regression. И наоборот, мало результатов в HNSW-запросе не обязательно означает bloat: при фильтрах pgvector применяет filter после approximate scan, поэтому search budget может закончиться раньше, чем будет найден нужный top-k.

Baseline до REINDEX: dead tuples, index size, plan и recall

Evidence bundle собирайте до первого maintenance action. В нём должны быть stable table/index identity, версия extension, пример реального retrieval query, статистика таблицы и размер HNSW. Для application layer сохраните небольшой набор canary queries: не случайные synthetic vectors, а те типы запросов, на которых команда замечает проблему.

pg_stat_user_tables даёт оценочные n_live_tup/n_dead_tup и время последнего vacuum/autovacuum. Размер индекса удобно фиксировать через pg_relation_size. План нужно смотреть на реальном WHERE и том же операторе distance, который использует приложение.

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  last_vacuum,
  last_autovacuum,
  n_mod_since_analyze
FROM pg_stat_user_tables
WHERE schemaname = 'public'
  AND relname = 'rag_documents';

SELECT
  pg_size_pretty(pg_relation_size('public.rag_documents')) AS table_size,
  pg_size_pretty(pg_relation_size('public.rag_documents_embedding_hnsw_idx')) AS hnsw_size;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

Почему pgvector рекомендует REINDEX CONCURRENTLY перед VACUUM

Для HNSW официальный pgvector README даёт необычно конкретную рекомендацию: если vacuum идёт долго, сначала выполните REINDEX INDEX CONCURRENTLY, затем VACUUM таблицы. Это не общий закон PostgreSQL для любого index type, а pgvector-specific operational hint.

REINDEX строит новую копию индекса из данных таблицы. В production вариант CONCURRENTLY позволяет продолжать обычные INSERT/UPDATE/DELETE, тогда как обычный REINDEX блокирует writes на время rebuild. Цена concurrency — больше общей работы, дополнительные scans и ожидание транзакций.

Команды не объединяйте в одну большую transaction. PostgreSQL не разрешает REINDEX CONCURRENTLY внутри transaction block; VACUUM тоже запускается отдельно. И не превращайте последовательность ниже в cron «после каждого batch»: сначала symptom и evidence, затем maintenance.

REINDEX INDEX CONCURRENTLY public.rag_documents_embedding_hnsw_idx;

VACUUM public.rag_documents;

-- Если после большого churn нужна свежая planner statistics:
ANALYZE public.rag_documents;

CONCURRENTLY не блокирует writes, но требует отдельного resource budget

Слово CONCURRENTLY иногда ошибочно читают как «дёшево и незаметно». PostgreSQL описывает обратный trade-off: concurrent rebuild делает больше работы, выполняет два scans таблицы и ждёт завершения транзакций, которые могут мешать переключению индекса. Кроме времени, вы платите CPU, memory и storage I/O; именно поэтому rebuild способен ухудшить application latency даже без lock, который блокирует writers.

Для крупной RAG-таблицы maintenance budget должен жить рядом с пользовательским SLO. До запуска определите stop condition: например, рост database queue/latency выше внутреннего canary threshold, replication lag выше вашего допустимого окна или saturation storage. Числа здесь нельзя копировать из статьи — они зависят от дисков, размера HNSW и текущего трафика.

PostgreSQL также ограничивает concurrent index work: на одной таблице одновременно может идти только один concurrent index build. Длинные транзакции способны затянуть фазы ожидания. Поэтому перед окном rebuild полезно посмотреть не только CPU, но и transaction age.

SELECT
  pid,
  datname,
  relid::regclass AS table_name,
  index_relid::regclass AS index_name,
  command,
  phase,
  lockers_total,
  lockers_done,
  blocks_total,
  blocks_done,
  tuples_total,
  tuples_done
FROM pg_stat_progress_create_index
WHERE relid = 'public.rag_documents'::regclass;

Если вы хотите оценить resource envelope заранее, делайте rebuild на свежем production-sized clone, а не на маленькой demo-базе. Это не докажет точную длительность в production, зато покажет порядок I/O и memory pressure без риска для live traffic. Ценность выделенной инфраструктуры в этом сценарии — не обещание «pgvector станет быстрее», а управляемый запас IOPS/CPU и возможность запланировать maintenance без соседнего noisy workload.

VACUUM после rebuild: что он освобождает и чего не делает

Обычный VACUUM обрабатывает dead tuples и делает освободившееся место доступным для повторного использования. В normal PostgreSQL operation это routine maintenance, который обычно может идти параллельно с чтениями и записями. При этом freed space чаще остаётся внутри relation для будущих tuples — ожидать, что файл на диске сразу резко уменьшится, неправильно.

VACUUM FULL — другая операция: она переписывает таблицу, может вернуть больше места операционной системе, но требует ACCESS EXCLUSIVE и значительно тяжелее. Не используйте FULL как автоматическое продолжение HNSW runbook только потому, что pg_relation_size выглядит большим.

В PostgreSQL 18 параметр INDEX_CLEANUP у VACUUM по умолчанию AUTO: движок может пропустить index vacuuming, если dead tuples очень мало и стоимость обхода индексов выше пользы. Это ещё одна причина не сводить политику к одному percentage threshold.

После завершения сравните тот же evidence bundle: dead tuples, длительность следующего vacuum, plan и application canary. Если изменился только storage counter, а retrieval SLO/recall остались прежними, называйте это доказательством maintenance mechanism — не «ускорением RAG».

Recall gate: approximate HNSW сравнивайте с exact search на том же snapshot

pgvector предлагает простой способ мониторить recall: сравнивать результаты approximate search с exact search, временно отключая index scan. Для production-проверки этого мало сделать один раз случайным vector. Нужен фиксированный набор запросов, одинаковые filters, одинаковый top-k и по возможности один database snapshot, чтобы concurrent writes не подменили причину различий.

Exact control отвечает на узкий вопрос: насколько approximate index path воспроизводит ближайших соседей, которые получил бы exact search. Он не измеряет качество RAG целиком: если embedding-модель плохо кодирует предметную область, exact top-k тоже может быть семантически плохим. Поэтому index recall и answer quality держите раздельно.

BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;

-- 1) approximate HNSW path
SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

-- 2) exact control, как рекомендует pgvector для recall monitoring
SET LOCAL enable_indexscan = off;

SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

ROLLBACK;

Сравнивайте IDs в тестовом harness: top-k overlap, попадание в заранее размеченный relevant set и стабильность на нескольких категориях запросов. Если exact и approximate расходятся только при фильтре, переходите к query-budget диагностике. Если расхождение коррелирует с churn и меняется после controlled maintenance, это уже гораздо сильнее как attribution.

Iterative scans лечат filter starvation, а не заменяют maintenance

У HNSW есть другой источник «пропавших» результатов. В approximate search pgvector применяет обычный WHERE-filter после index scan. Если условие пропускает небольшую долю rows, из первоначального candidate set может остаться меньше строк, чем запрошено через LIMIT. Это не обязательно повреждение индекса.

Начиная с pgvector 0.8.0 доступны iterative index scans. Режим strict_order продолжает обход, сохраняя строгий порядок distance; relaxed_order может дать лучшую recall ценой слегка relaxed ordering. Обход ограничивается, в частности, hnsw.max_scan_tuples; default в текущем source — 20 000, а hnsw.scan_mem_multiplier — 1. Эти default не надо автоматически увеличивать: больший search budget покупает recall дополнительной работой.

BEGIN;

SHOW hnsw.ef_search;
SHOW hnsw.max_scan_tuples;
SHOW hnsw.scan_mem_multiplier;

SET LOCAL hnsw.iterative_scan = strict_order;

SELECT id
FROM public.rag_documents
WHERE tenant_id = :tenant_id
ORDER BY embedding <=> :query_embedding
LIMIT 20;

ROLLBACK;

Autovacuum: настраивайте trigger под churn, но не превращайте его в магию

Routine vacuum должен оставаться автоматизированным. PostgreSQL запускает autovacuum, когда число obsolete tuples превышает threshold, который зависит от базового значения, scale factor и размера таблицы. Для очень большой RAG table даже стандартный scale factor может означать большой абсолютный объём изменений до следующего vacuum; для маленькой таблицы слишком агрессивный trigger создаст лишнюю фоновую работу.

Поэтому сначала смотрите фактический churn и table-specific settings. Не копируйте из чужого runbook autovacuum_vacuum_scale_factor=0.01 или другое красивое число без бюджета: частота vacuum должна соответствовать write rate, storage bandwidth и допустимому background load.

SHOW autovacuum;
SHOW autovacuum_vacuum_threshold;
SHOW autovacuum_vacuum_scale_factor;

SELECT
  n_live_tup,
  n_dead_tup,
  last_autovacuum,
  autovacuum_count
FROM pg_stat_user_tables
WHERE relid = 'public.rag_documents'::regclass;

SELECT reloptions
FROM pg_class
WHERE oid = 'public.rag_documents'::regclass;

Если autovacuum явно не успевает за predictable churn, меняйте одну table-level policy за раз и наблюдайте несколько циклов. Но не путайте более частый routine VACUUM с pgvector-specific рекомендацией reindex-before-vacuum для тяжёлого HNSW: это разные уровни maintenance.

Rollout: canary, stop condition и восстановление без легенды про «нулевой риск»

На production не начинайте с самого большого HNSW. Сначала проверьте процедуру на production-sized clone или на менее критичной таблице с той же схемой. На live primary используйте REINDEX CONCURRENTLY только когда нужен write availability и у вас есть запас ресурсов; если сервис можно полностью остановить в maintenance window, обычный REINDEX дешевле по общей работе.

У rollout должны быть три gate. Infrastructure gate: rebuild завершён, index valid, VACUUM не завис, storage и replication вернулись к baseline. Retrieval gate: canary approximate-vs-exact не ухудшился и production filters возвращают ожидаемый top-k. Application gate: RAG endpoint отвечает в вашем SLO и не переносит bottleneck, например, с database I/O на CPU или embedding service.

Rollback здесь не означает, что после каждого REINDEX вы обязаны восстанавливать базу из backup. REINDEX перестраивает индекс из данных таблицы; если data layer не менялся, при неудачном application canary чаще нужно остановить дальнейший rollout, вернуть query settings и расследовать planner/filter path. А PITR остаётся независимым data-protection control на случай ошибочных data changes, а не штатной кнопкой отмены index maintenance.

Decision tree: когда ничего не делать, когда tuning, а когда REINDEX + VACUUM

Главный вывод — HNSW maintenance должен начинаться не с команды, а с классификации причины. Если таблица почти append-only, autovacuum справляется, а canary recall стабилен, периодический REINDEX «для профилактики» только создаст ненужный I/O. Если меньше результатов возникает при selective filters, проверяйте ef_search, iterative scans и filter indexes. Если изменилась embedding-модель, запускайте полноценный re-embed/migration lifecycle. И только когда churn, dead tuples, HNSW maintenance symptom и canary указывают в одну сторону, применяйте pgvector-specific последовательность REINDEX INDEX CONCURRENTLY → VACUUM.

Для инфраструктуры решение тоже практическое. Dedicated database node полезен здесь не потому, что сам по себе повышает recall, а потому что даёт контролируемый storage/CPU envelope, понятный maintenance window и возможность воспроизвести один hardware profile. Если у вас embeddings занимают значимую долю PostgreSQL и вы ещё выбираете границу системы, сначала сверитесь со сравнением отдельной vector DB и PostgreSQL. А если retrieval cost начинает доминировать, отдельно проверьте semantic cache — это другой слой и он не должен маскировать больную database maintenance.

Практический следующий шаг: сохраните один baseline SQL bundle и 20–50 canary queries, прогоните их до и после следующего реального churn-window и только затем решайте, нужен ли recurring maintenance policy. Так у команды появится причинная связь между изменением базы, состоянием HNSW и пользовательским retrieval, а не набор периодических команд «потому что так принято».

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Симптом: RDMA есть, а прямой GPU↔NIC путь не доказан

Начните не с модулей, а с наблюдаемого расхождения. Например, два одинаковых GPU-узла работают на одной версии приложения и используют один fabric, но на одном растёт загрузка CPU и память хоста становится заметной частью data path, а на другом обмен остаётся ближе к ожидаемому GPU-centric профилю. Это повод проверить registration path. Сам по себе низкий throughput ничего не доказывает: причина может быть в MTU, routing, PFC/ECN, PCIe topology, NUMA, CPU pinning или вообще в TCP fallback.

Disqualifier важен сразу. Если rdma link уже показывает проблему, NIC не поднимается, ib_write_bw на обычной host memory нестабилен или два узла не видят друг друга по RDMA, сначала чините сеть. DMA-BUF не исправляет fabric. Точно так же миграция registration path не должна становиться способом «вылечить» плохой PCIe: для низкоуровневых P2P-проблем полезен отдельный runbook по PCIe ACS и P2P DMA.

Цель этой статьи уже: доказать, какой kernel path регистрирует GPU memory для RDMA, подтвердить реальную передачу из GPU memory, затем проверить NCCL и только после этого смотреть на LLM SLO. Если application metric не меняется, улучшение низкоуровневого счётчика остаётся доказательством механизма, а не бизнес-эффекта.

DMA-BUF и nvidia-peermem: что на самом деле меняется

GPUDirect RDMA позволяет peer-устройству — обычно RDMA NIC — работать с GPU memory без обязательной промежуточной копии через host memory. В Linux для этого нужен механизм регистрации и обмена memory handles. В современном стеке NVIDIA таким механизмом может быть стандартный DMA-BUF; legacy-вариант использует модуль nvidia-peermem и peer-memory API.

В документации NVIDIA GPU Operator 26.3 DMA-BUF обозначен как рекомендуемый вариант. Для него используется Open GPU Kernel Module, а поддержка RDMA может опираться на inbox-драйверы Linux. Legacy nvidia-peermem по-прежнему описан как отдельный путь и требует соответствующего OFED/DOCA-OFED стека. Это не означает, что каждый существующий peermem-кластер нужно срочно переделать: production-миграция оправдана, когда вы можете воспроизвести baseline и откатить canary без смешения гипотез.

Практическая разница для оператора в ownership. С DMA-BUF вы проверяете open kernel module, kernel/RDMA stack и GPU-memory transfer; с peermem появляется отдельный модуль и его совместимость с RDMA drivers. Поэтому после обновления kernel, NVIDIA driver или NIC stack разные узлы могут формально быть «зелёными», но фактически использовать разные пути.

До миграции зафиксируйте identity узла, GPU и RDMA NIC

Первое обязательное правило — не менять kernel path до evidence bundle. Запишите kernel release, версию и тип NVIDIA kernel module, PCI identity GPU, RDMA devices и физическую близость GPU↔NIC. Иначе после перезагрузки вы увидите «стало работать» и не сможете ответить, что именно изменилось.

Identity должна быть стабильной и машинно проверяемой. Для GPU полезен BDF из nvidia-smi и topology map; для NIC — RDMA device и связанный netdev. Если у вас несколько HCA, не используйте «mlx5_0» как вечную бизнес-идентичность: после firmware или PCI enumeration имя может поменяться. Сопоставляйте его с PCI BDF и физическим портом.

uname -r
modinfo nvidia | grep -E '^(version|license):'
nvidia-smi -L
nvidia-smi topo -m
rdma link
rdma dev show
ibdev2netdev
lsmod | grep -E 'nvidia_peermem|nvidia|ib_core|mlx5'

Сохраните этот вывод вместе с версией CUDA/NCCL и образом приложения. При canary сравнении нужен не просто «другой сервер», а узел того же topology class. Если одна машина имеет другой root complex, другой NIC firmware или другой kernel, она плохой контроль.

Для LLM-нагрузки отдельно зафиксируйте application baseline: время инициализации distributed job, steady-state throughput, p95/p99 интересующей операции и CPU utilization. Не выбирайте только одну метрику. Например, NCCL transport может стать чище, но end-to-end latency не изменится из-за другого bottleneck. Это нормальный результат, а не повод придумывать эффект.

Gate 1: докажите prerequisites DMA-BUF, а не просто наличие NVIDIA driver

По актуальной документации NVIDIA для GPUDirect RDMA через DMA-BUF требуется Open GPU Kernel Module; GPU Operator также указывает CUDA 11.7+ и Linux kernel 5.12+ как базовые требования этого пути. Проверяйте именно вашу поддерживаемую комбинацию OS/kernel/driver, а не переносите минимумы из документации на неподдерживаемый дистрибутив.

На практике gate должен отвечать на три вопроса. Во-первых, загружен ли open kernel variant, а не только «NVIDIA driver работает». Во-вторых, виден ли RDMA device и его netdev. В-третьих, соответствует ли GPU/NIC topology вашему canary-плану. На этом шаге не нужно запускать LLM: сначала докажите инфраструктурный механизм.

uname -r
modinfo nvidia | grep -E '^(version|license):'
rdma dev show
rdma link
nvidia-smi topo -m
ls -l /dev/infiniband

Не используйте отсутствие nvidia_peermem как единственный PASS. Модуль может быть не загружен, но DMA-BUF transfer всё равно не работать из-за несовместимой комбинации kernel/NIC driver. И наоборот, наличие старого модуля в filesystem ещё не доказывает, что runtime использует legacy path.

Gate 2: отдельно докажите RDMA из GPU memory

Следующий gate отделяет fabric от GPU-memory registration. Сначала полезно подтвердить обычный host-memory RDMA test на той же паре узлов и порту. Если он не проходит стабильно, не переходите к DMA-BUF — иначе две гипотезы смешаются. После PASS запускайте тот же класс perftest с GPU buffer и флагом DMA-BUF.

NVIDIA в troubleshooting для NCCL прямо предлагает сравнивать host-memory transfer и GPU-memory transfer через ib_write_bw; для DMA-BUF используется --use_cuda_dmabuf. Название HCA, GPU id и server address подставляйте из своего inventory, а не копируйте из примера как константы.

# На серверной стороне
ib_write_bw -d mlx5_0 -a

# На клиенте: сначала host-memory baseline
ib_write_bw -d mlx5_0 -a 

# Затем GPU-memory DMA-BUF test
ib_write_bw --use_cuda=0 --use_cuda_dmabuf -d mlx5_0 -a -F --report_gbits -q 1 

Смысл не в том, чтобы получить универсальное число Gbit/s. PASS — GPU-memory test стабильно работает на ожидаемой паре GPU/NIC, не разваливается при повторении и воспроизводится после controlled restart. Сравнение bandwidth полезно только между одинаковыми topology, message sizes и software versions.

Отрицательный контроль: намеренно запустите host-memory вариант отдельно. Если оба режима дают одинаково плохое поведение, не объявляйте DMA-BUF причиной. Если host memory стабилен, а GPU DMA-BUF падает, область поиска сужается к GPU registration/peer path и его совместимости.

Gate 3: проверьте, что NCCL не маскирует path своим fallback

Даже успешный perftest ещё не равен успешному distributed workload. NCCL выбирает transport с учётом topology и доступных plugins. В актуальной документации NCCL_DMABUF_ENABLE существует с NCCL 2.13, имеет значение по умолчанию 1 и автоматически отключается, если platform не поддерживает DMA-BUF. Поэтому отсутствие ручного export не доказывает, что path активен, а сам export не заставит неподдерживаемую систему чудесным образом заработать.

Для canary включите диагностический лог и запустите контролируемый nccl-tests на той же паре узлов. Смотрите не только на итоговую полосу, но и на transport selection, ошибки registration и неожиданный socket fallback. Команда ниже — шаблон локального теста; способ multi-node launch зависит от вашей MPI/Slurm/Kubernetes обвязки.

export NCCL_DEBUG=INFO
export NCCL_DMABUF_ENABLE=1

# Запускайте тем же orchestrator, который используете для canary
./build/all_reduce_perf -b 8M -e 1G -f 2 -g 1

Если тест не использует ожидаемый RDMA transport, не лечите его отключением safety checks вслепую. Вернитесь к identity и network baseline. Полезный принцип: каждый новый environment override должен отвечать на конкретное наблюдение в логе и иметь обратную команду.

Отдельно не путайте DMA-BUF с настройкой RoCE fabric. ECN/PFC, QoS и congestion control остаются самостоятельным слоем. Если NCCL видит RDMA, но сеть теряет пакеты или уходит в congestion, registration path уже не главный подозреваемый.

Gate 4: LLM canary должен подтвердить полезный эффект, а не красивый low-level test

Теперь повторите реальный workload на canary-узлах. Для training это может быть короткий репрезентативный distributed step; для multi-node inference — фиксированный replay запросов с теми же model revision, tensor/pipeline parallel settings и concurrency. Главное — не менять одновременно registration path, batch policy и модель: иначе attribution потеряна.

Держите рядом минимум три группы метрик: application SLO, NCCL/RDMA evidence и host pressure. Например, если после DMA-BUF direct path CPU utilization упал, но tokens/s и p95 остались прежними, вы доказали разгрузку host path, но не ускорение сервиса. Такой результат может быть полезен для capacity, но его нельзя продавать как рост производительности без дополнительного evidence.

Если наоборот p95 улучшается только на одном canary, сначала проверьте topology class и workload equality. Одна «быстрая» машина на другом PCIe root complex — плохое доказательство. Для смежных вопросов CPU/memory locality полезен runbook по pinned memory и memlock, а throttling GPU лучше исключать отдельным DCGM/Prometheus runbook.

Canary migration: не смешивайте DMA-BUF и legacy path в одном эксперименте

Самая опасная миграция — «обновим половину пакетов и посмотрим». Для canary заранее определите immutable software set: kernel, NVIDIA driver/kernel module type, CUDA/NCCL, RDMA stack, firmware и container image. Меняйте только registration path и связанные обязательные prerequisites.

Если вы используете GPU Operator, текущая документация показывает DMA-BUF как default path для GPUDirect RDMA и отдельный driver.rdma.enabled=true для legacy peer-memory сценария. Для bare metal применяйте ту же идею: два явных профиля конфигурации, а не ручные modprobe на десятках узлов. Infrastructure-as-code должен позволять вернуть прежний профиль целиком.

Порядок rollout: один canary pair → повторение после reboot → небольшой pool → только потом остальной cluster. На каждом этапе повторяйте четыре gates в одном порядке. Если после reboot GPU-memory perftest перестал работать, не переходите к NCCL; если NCCL упал, не объясняйте это application metrics.

Типовые failure modes: где DMA-BUF чаще всего обвиняют зря

Сеть не готова. Host-memory perftest уже нестабилен, но команда сразу запускает GPU test. В результате DMA-BUF получает чужую вину. Negative control здесь простой: сначала стабильный host buffer на том же HCA/port/path.

Смешаны kernel module types. Один узел использует open module, другой — другой driver profile, а orchestration считает их одинаковыми. Distributed job становится экспериментом сразу с несколькими переменными. Лечится inventory gate и node labels/taints, а не дополнительным environment variable.

NCCL auto-disable принимают за успех. Поскольку NCCL_DMABUF_ENABLE по умолчанию включён, можно ошибочно решить, что DMA-BUF точно используется. Документация прямо говорит об auto-disable на неподдерживаемой platform; поэтому нужен log/evidence, а не только значение переменной.

Peermem удаляют до rollback window. Если legacy path был рабочим baseline, не уничтожайте его в том же change, где впервые проверяете DMA-BUF. Сначала докажите новый path, затем сокращайте legacy dependencies отдельным change.

Механизм путают с SLO. GPU-memory RDMA может работать идеально, а LLM не ускориться, если bottleneck — compute, storage или scheduler. Для I/O storm на общем NVMe, например, полезнее отдельная изоляция I/O через cgroup v2/systemd.

Rollback и мониторинг: возвращайте профиль, а не отдельный модуль

Rollback должен быть симметричным rollout. Если baseline использовал legacy nvidia-peermem, верните прежний driver/RDMA profile целиком, перезагрузите узел при необходимости и повторите те же gates: identity → host/GPU perftest → NCCL → application. Это важнее, чем просто увидеть модуль в lsmod.

Для legacy path NVIDIA GPU Operator документирует отдельное включение RDMA driver integration. На bare metal эквивалентом должен быть versioned package/profile, а не «дежурный знает, какой modprobe сделать». После rollback сохраните оба evidence bundles — именно они позволяют понять, воспроизводится ли причинность.

# Пример проверки legacy baseline после возврата профиля
sudo modprobe nvidia-peermem
lsmod | grep nvidia_peermem
rdma dev show
nvidia-smi topo -m

# Затем повторите host-memory и GPU-memory tests,
# соответствующие вашему legacy baseline.

В постоянный мониторинг имеет смысл вынести не «DMA-BUF=1», а симптомы расхождения: node software fingerprint, RDMA link state, NCCL transport errors, неожиданный рост host CPU/memory при одинаковом workload и application SLO. Если инфраструктурный сигнал меняется без user-facing эффекта, храните его как ранний индикатор, но не эскалируйте как outage без порогов.

Когда выделенный GPU-узел даёт практическое преимущество

Здесь коммерческая граница довольно конкретна. Переход между kernel registration paths требует контроля над kernel, типом NVIDIA kernel module, NIC/RDMA stack, firmware, reboot/drain и составом canary pool. В среде, где эти слои скрыты или разделены между несколькими владельцами, вы можете увидеть symptom, но не собрать воспроизводимый evidence bundle.

Ценность dedicated GPU infrastructure в таком кейсе — не «DMA-BUF ускорит всё». Она в ownership: можно закрепить software/hardware profile, вывести узел из нагрузки, выполнить perftest на конкретной GPU↔NIC паре, вернуть baseline и заменить физический компонент, если проблема переживает software rollback. Это особенно важно для multi-node LLM, где один неоднородный узел способен испортить весь distributed job.

Если вы проектируете более широкий AI platform, полезно отделять этот низкоуровневый runbook от orchestration. Например, Kubernetes/KServe/GPU Operator решают scheduling и lifecycle задачи выше, но не отменяют необходимость доказать data path на хосте.

Источники и версия контекста

Проверено на дату подготовки статьи по официальной документации NVIDIA: GPU Operator 26.3 — GPUDirect RDMA, NCCL Environment Variables, NCCL Networking Troubleshooting и CUDA GPUDirect RDMA.

Особенно внимательно сверяйте minimum kernel/driver/CUDA requirements при обновлениях: эта часть стека меняется быстрее, чем общая логика runbook. Команды в статье — диагностические шаблоны; имена HCA, GPU id, IP, orchestrator и package profile должны соответствовать вашему inventory.

Вывод: мигрируйте не модуль, а доказанную цепочку data path

Переход с legacy nvidia-peermem на DMA-BUF имеет смысл делать как controlled infrastructure change. Сначала сохраните identity и baseline, затем докажите prerequisites open kernel, отдельно подтвердите RDMA из GPU memory, после этого — NCCL transport и только в конце — LLM application SLO. Если любой слой FAIL, не перепрыгивайте к следующему и не маскируйте проблему дополнительными overrides.

Главный operational результат — воспроизводимость. После reboot тот же canary должен проходить те же gates; rollback должен возвращать тот же baseline; улучшение low-level counters без application effect нужно называть именно так. Начните с одной пары однородных GPU-узлов и одного фиксированного workload replay — этого достаточно, чтобы миграция перестала быть догадкой и стала проверяемым change.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда подозревать PCIe, а когда не стоит

PCIe редко становится первым подозреваемым при деградации LLM inference. Обычно команда сначала смотрит utilization GPU, VRAM, clocks, throttling, CPU steal, NUMA и очередь запросов. Это правильный порядок: большинство проблем действительно находится выше. Но есть характерная комбинация признаков, при которой стоит спуститься на link layer: приложение теряет throughput или растёт latency, GPU не загружен так, как ожидалось, host-to-device transfer занимает заметно больше времени, а модель и workload не менялись.

Disqualifier здесь важнее красивой гипотезы. Если сервис целиком держит weights и KV cache на GPU, почти не гоняет данные через host после warmup, а p95 растёт одновременно на всех узлах независимо от конкретного BDF, PCIe — слабый кандидат. Точно так же не надо объяснять PCIe любой низкий GPU utilization: причиной может быть CPU preprocessing, storage, tokenizer, scheduler или network backpressure.

И наоборот, настораживает узел, который отличается от соседей того же hardware class. Например, две одинаковые машины работают на одной версии драйвера и одном образе, но одна после обслуживания показывает меньший negotiated link width или generation. Такая асимметрия — уже полезный след: сравнивать нужно не «нормально ли вообще», а «совпадает ли текущий effective state с известным baseline этого конкретного слота и GPU».

Если проблема выглядит как throttling, сначала исключите его по отдельному runbook: мониторинг GPU throttling через DCGM и Prometheus. Для multi-GPU topology полезен и материал про PCIe ACS и P2P DMA. Эта статья намеренно уже: здесь нас интересуют ошибки линии, retrain и downtraining.

Сначала зафиксируйте identity и baseline

До любых reset, retrain, перестановки карты или перезагрузки снимите evidence bundle. Главная ошибка диагностики — потерять исходное состояние, а затем пытаться доказать, что стало лучше. Для GPU используйте стабильный идентификатор: UUID и PCI Bus ID. NVIDIA прямо рекомендует для автоматизации UUID или PCI bus ID, потому что индекс GPU может меняться между перезагрузками.

Минимальный baseline должен отвечать на пять вопросов: какой это GPU; какой BDF видит ОС; какой upstream path ведёт к Root Port; каковы максимальные и текущие speed/width; были ли AER-события до инцидента. Если у вас несколько одинаковых узлов, сохраните те же данные с одной здоровой машины. Это превращает расследование из гадания в diff.

GPU=0
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,name --format=csv
nvidia-smi -i "$GPU" -q | sed -n '/PCI/,/Clocks/p'
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
echo "GPU BDF: $BDF"
lspci -s "$BDF" -vv
lspci -t
journalctl -k -b | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid' | tail -n 200

Привяжите GPU к реальному PCIe-пути

Сообщение AER часто приходит не от самого GPU, а от Root Port или другого элемента иерархии. Поэтому BDF endpoint — только начало. Нужно понять, через какой upstream bridge, riser или PCIe switch проходит карта. Это особенно важно в 2U/4U GPU-серверах: физический слот на задней панели не всегда очевидно соответствует тому Root Port, который вы увидите в журнале.

Начните с lspci -t, затем раскройте подробности endpoint и upstream-портов через lspci -vv. В Capability PCI Express ищите LnkCap и LnkSta: первое описывает возможности конкретного звена, второе — согласованное состояние. Сравнивать надо speed и width вместе. Gen5 x8 и Gen4 x16 — разные состояния, и один только номер поколения не говорит, что линия деградировала.

Не делайте ещё одну распространённую ошибку: не сравнивайте текущий link с маркетинговым максимумом GPU. Ограничение может находиться в слоте, riser, switch или платформе. Правильный baseline — то, что поддерживает минимальное звено по пути и что стабильно показывает здоровый узел той же конфигурации.

GPU_BDF=0000:65:00.0
lspci -s "$GPU_BDF" -vv | grep -E 'LnkCap:|LnkSta:'
lspci -t
# Затем повторите -vv для upstream bridge/root port из дерева:
lspci -s 0000:64:00.0 -vv | grep -E 'LnkCap:|LnkSta:|AER|DevSta:'

Как читать AER и replay без ложных выводов

Linux AER driver собирает расширенную информацию об ошибках PCIe, сообщает её пользователю и участвует в recovery. В документации ядра ошибки делятся на correctable и uncorrectable. Correctable исправляются протоколом без потери функциональности; uncorrectable уже могут затрагивать транзакцию или надёжность самой линии. Это ключевая граница: наличие correctable warning не равно «GPU сломан», но серия событий — хороший триггер для корреляции.

AER в Linux работает через Root Port service driver и зависит от того, передала ли прошивка управление AER операционной системе через ACPI _OSC. Поэтому отсутствие сообщений в dmesg не всегда означает отсутствие ошибок на физическом уровне. На одних платформах телеметрия будет полной в Linux, на других часть обработки остаётся в firmware/BMC. Зафиксируйте эту особенность платформы до того, как строить алерт «AER=0 — всё хорошо».

Отдельный сигнал — replay. PCIe использует механизм повторной передачи, и рост соответствующего счётчика может указывать, что протоколу приходится восстанавливать транзакции. Но опять же: абсолютное число без окна наблюдения и без baseline мало полезно. Снимайте delta за одинаковый интервал под одинаковой нагрузкой и сравнивайте с p95/throughput приложения.

В NVIDIA-стеке часть PCIe-показателей можно получать через NVML/DCGM; для долгоживущей автоматизации предпочтительнее NVML/DCGM, чем парсинг человекочитаемого вывода nvidia-smi, поскольку NVIDIA отдельно предупреждает, что формат NVSMI не гарантирует обратную совместимость.

START=$(date -Is)
echo "start=$START"
# запустите один и тот же canary workload
sleep 60
journalctl -k --since "$START" | grep -Ei 'AER|PCIe Bus Error|pcieport|NVRM|Xid'
# На поддерживаемых системах проверьте sysfs AER counters для endpoint/upstream port:
find /sys/bus/pci/devices/0000:65:00.0 -maxdepth 1 -type f -name 'aer_*' -print -exec cat {} \;

Докажите влияние на LLM, а не только на PCIe-счётчик

Даже если вы нашли AER и current link ниже baseline, этого недостаточно для коммерчески значимого вывода. Production-вопрос звучит не «есть ли ошибка PCIe», а «мешает ли она полезной работе». Поэтому разделите infrastructure gate и application gate.

Infrastructure gate считается пройденным, когда identity однозначна, topology известна, current link сопоставлен с capability и peer baseline, а AER/replay измеряются в фиксированном окне. Application gate — отдельный эксперимент: один и тот же prompt set, те же model revision, batch/concurrency, CPU affinity, tokenizer path и network path. Сравнивайте request throughput и latency, а не только GPU utilization.

Особенно аккуратно с prefilling и streaming. Workload, который часто передаёт большие host buffers, может сильнее проявлять деградацию PCIe, чем steady-state decode с данными уже в VRAM. Поэтому canary должен представлять реальный traffic mix. Если проблема видна только в synthetic host-to-device copy benchmark, а production SLO не меняется, вы доказали механизм, но не доказали влияние на сервис.

Для NUMA-проверок используйте отдельный runbook NUMA-locality для GPU-инференса: remote memory может имитировать часть симптомов, но это другой слой.

Triage: software, retrain или физический путь

Когда evidence собран, можно выбирать действие. Если link state соответствует baseline, AER не растёт, а application gate деградирован, оставайтесь на software path: драйвер, runtime, NUMA, CPU, storage, network или сама модель. Не надо «на всякий случай» трогать PCIe reset.

Если current speed/width ниже ожидаемого и состояние появилось после boot или maintenance, сначала ищите наименее разрушительный способ подтвердить гипотезу. Для production-узла это обычно drain workload, фиксация evidence, затем контролируемый reboot в maintenance window. Ручной reset bridge или endpoint может затронуть другие устройства в той же иерархии; Linux AER recovery для серьёзных ошибок тоже способен выполнять reset выше originator. Поэтому topology должна быть известна до любого воздействия.

Если после reboot/retrain линия возвращается к baseline и application metric восстанавливается, это сильная корреляция, но ещё не повод закрывать инцидент. Нужен контрфакт: повторите тот же canary и проверьте, не растут ли AER/replay снова. Возвращающаяся деградация указывает на физический путь, signal integrity, riser, слот, питание, board или firmware/BIOS interaction.

Если же link стабилен после холодного старта, но деградирует только под определённой нагрузкой, расследование становится интереснее: коррелируйте температуру платы, питание, BMC SEL, AER delta и workload. Не заменяйте этот анализ снижением PCIe generation «для стабильности» без фиксации причины: такой workaround может скрыть дефект и одновременно урезать capacity.

Когда переходить к riser, слоту и плате

Физическую диагностику начинайте только после software evidence, иначе очень быстро появляется «ремонт методом перестановки». На выключенном и снятом с нагрузки сервере проверьте посадку GPU и riser, крепёж, разъёмы питания, следы перегрева и соответствие riser/slot спецификации платформы. На системах с PCIe switch добавьте его firmware и health в evidence bundle.

Лучший hardware experiment — один контролируемый swap за раз. Перенесли GPU в другой заведомо исправный slot: если проблема следует за картой, подозрение смещается к endpoint. Оставили GPU, заменили riser: если проблема исчезла, у вас локализован элемент пути. Нельзя одновременно переставить карту, заменить riser, обновить BIOS и драйвер, а потом объявить RCA — вы потеряете причинность.

Для каждого swap сохраняйте stable identity новой комбинации: serial/UUID GPU, BDF, slot label из документации сервера, upstream Root Port, BIOS version. После каждого изменения повторяйте те же два gate: infrastructure и application. Симметрия важна — одни и те же проверки до и после изменения позволяют отличить реальное исправление от случайного изменения нагрузки.

Если сервер арендованный или размещён у провайдера, именно здесь ценность ownership становится практической: нужна возможность drain узла, получить BMC/firmware evidence, выполнить замену riser/slot и вернуть прежнюю конфигурацию. Это не обещание «dedicated быстрее»; это граница управляемости, без которой такой RCA часто останавливается на гипотезе.

Что вынести в постоянный мониторинг

После инцидента не стоит превращать все найденные счётчики в paging alerts. Хороший мониторинг PCIe строится слоями. Первый слой — inventory: GPU UUID/BDF, ожидаемый speed/width и upstream path. Второй — error telemetry: AER и поддерживаемые PCIe counters. Третий — application SLO. Срабатывать должна комбинация, а не любой одиночный correctable event.

Практический pattern: alert высокого приоритета, если current link отличается от expected baseline и одновременно деградирует application metric. Средний приоритет — sustained рост error/replay delta на конкретном BDF без SLO impact; это повод для плановой проверки. Единичный correctable warning можно оставить как event для расследования, а не будить команду ночью.

Для скриптов и exporter-логики лучше опираться на NVML/DCGM или стабильный structured interface, а не на свободный текст nvidia-smi -q. NVSMI удобен для ручной диагностики, но NVIDIA не гарантирует обратную совместимость его текстового вывода. Для AER Linux предоставляет статистику в sysfs на поддерживаемых системах; учитывайте, что firmware ownership через ACPI _OSC влияет на то, что именно увидит ОС.

GPU=0
STAMP=$(date -Is)
echo "timestamp=$STAMP"
nvidia-smi -i "$GPU" --query-gpu=uuid,pci.bus_id,utilization.gpu,power.draw,temperature.gpu --format=csv,noheader
BDF=$(nvidia-smi -i "$GPU" --query-gpu=pci.bus_id --format=csv,noheader | tr '[:upper:]' '[:lower:]')
lspci -s "$BDF" -vv | grep -E 'LnkCap:|LnkSta:'
for f in /sys/bus/pci/devices/${BDF}/aer_*; do [ -r "$f" ] && printf '%s=' "$f" && cat "$f"; done

Recovery и rollback: доказательство важнее перезагрузки

Recovery считается успешным не тогда, когда GPU снова появился в nvidia-smi. Нужно восстановить всю цепочку доказательств. Сначала identity: тот ли endpoint и тот ли slot. Затем effective link state: speed/width вернулись к expected baseline. Потом error window: AER/replay не демонстрируют прежний паттерн. И только после этого application canary подтверждает SLO.

Rollback должен быть заранее определён. Если изменение включало BIOS option, firmware, перестановку riser или новый driver, вы должны знать, как вернуться к предыдущей комбинации. Особенно опасны инциденты, где несколько действий дают временное улучшение: без rollback вы не поймёте, что действительно повлияло на линию.

Полезный контрфакт — вернуть прежнюю конфигурацию на canary, если это безопасно, и проверить, возвращается ли симптом. Для аппаратного дефекта такой эксперимент не всегда разумен: не нужно повторно создавать потенциально fatal состояние ради красивого RCA. В этом случае достаточно устойчивой связи «дефектный элемент → ошибка» и «замена элемента → стабильный baseline» при одинаковом workload.

Отдельно документируйте ownership. Кто имеет право drain узел, кто меняет BIOS, кто работает с железом, кто принимает SLO после возврата. Hardware runbook без owner часто зависает именно в момент, когда диагностика уже доказала проблему, но никто не хочет брать риск физического действия.

Решение по узлу: вернуть в пул, наблюдать или вывести

Не каждый PCIe incident требует немедленной замены сервера. Решение удобно формализовать. Вернуть узел в production можно, если negotiated link устойчиво соответствует baseline, error delta не возвращается в canary-окне, application SLO восстановлен и причина изменения понятна. Если причина не доказана, но симптомы исчезли после reboot, разумнее оставить узел под наблюдением или в пониженном blast radius, а не сразу считать его исправным.

Выводите узел из пула, если деградация воспроизводится, link снова downtrain после нагрузки, появляются uncorrectable/fatal события, устройство теряется или recovery затрагивает соседние endpoints. То же относится к повторяющемуся дефекту riser/slot: workaround вроде принудительного более низкого поколения может быть допустим временно только как явно зафиксированное operational решение с capacity impact и сроком устранения.

Для LLM-платформы полезно хранить topology class как часть inventory: модель сервера, BIOS, CPU, slot, riser, GPU SKU, ожидаемые link parameters. Тогда новый узел не просто «GPU A100/H100/другой», а член конкретного класса с проверяемым baseline. Это облегчает и capacity planning, и замену железа.

Если вам нужна среда, где команда может контролировать BIOS, PCIe topology, reboot window и аппаратную замену, выделенный GPU-сервер даёт такую границу ownership. Но покупать «больше PCIe» без измерения бессмысленно: сначала докажите, что именно link state влияет на ваш workload, и только потом принимайте инфраструктурное решение.

Источники и ограничения runbook

Основные внешние опоры этого runbook — официальная документация Linux Kernel по PCI Express Advanced Error Reporting и документация NVIDIA по nvidia-smi/NVML/DCGM. Linux описывает AER как механизм сбора расширенной информации об ошибках, их вывода и recovery; отдельно подчёркивает классификацию correctable/uncorrectable и зависимость OS AER от ACPI _OSC. NVIDIA документирует PCI bus ID как стабильный способ адресации GPU и рекомендует NVML для поддерживаемой автоматизации, поскольку текстовый вывод NVSMI может меняться между версиями.

Ссылки: Linux Kernel: PCIe AER Driver Guide HOWTO, NVIDIA System Management Interface documentation, NVIDIA DCGM Feature Overview.

Команды в статье — диагностический baseline, а не универсальная автоматизация для всех платформ. Названия sysfs-файлов, доступность отдельных counters и поведение firmware зависят от kernel, platform firmware и устройства. Перед изменениями на production-сервере сверяйтесь с документацией конкретной модели сервера и maintenance policy.

Вывод: ищите причинность по слоям

PCIe-проблема в GPU-инференсе опасна тем, что может выглядеть как «модель почему-то стала медленнее», а сам ускоритель при этом продолжит отвечать на health-check. Надёжный путь — не начинать с reset и не верить одному счётчику. Зафиксируйте identity, восстановите topology, сравните capability с effective link state, измерьте AER/replay в окне и только затем подтвердите влияние одинаковым application canary.

Если после recovery link вернулся к baseline, повторите те же gate в том же порядке. Если деградация возвращается, переходите к физическому пути — riser, slot, switch, board, power и firmware — меняя только один фактор за раз. Так вы получите RCA, который можно повторить, а не историю «перезагрузили — вроде прошло».

Практический следующий шаг простой: выберите один здоровый и один подозрительный GPU-узел, снимите одинаковый evidence bundle и сохраните expected topology class. Даже если текущего инцидента нет, этот baseline резко сокращает время диагностики, когда p95 однажды начнёт расти без очевидного GPU error.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Сначала threat model: что именно защищаем

Узел inference может загрузить модель без единой ошибки, а команда всё равно получит ложное чувство безопасности. Обычный NVMe/TCP переносит блочные команды через IP-сеть; доступный namespace и закрытый VLAN ещё не доказывают ни личность клиента, ни конфиденциальность трафика. Для весов LLM это особенно неприятно: один и тот же удалённый том часто читают несколько дорогих GPU-узлов, поэтому ошибка в trust boundary масштабируется вместе с кластером.

Разделите активы на четыре группы: сами shards модели, tokenizer и config, манифест с pinned revision и секреты подключения. Затем назовите противника. TLS полезен против пассивного перехвата и активной подмены на сетевом пути. DH-HMAC-CHAP проверяет host, а при двусторонней настройке — и controller. Но эти механизмы не спасают от root на inference-узле, скомпрометированного storage target, подменённого файла уже внутри смонтированной ФС или ошибочно опубликованного namespace.

Практический disqualifier простой: если риск находится только «на диске после доставки», начинайте с encryption at rest и контроля целостности, а не с TLS. Если сеть выделенная, но её администрируют несколько команд или трафик проходит через общую фабрику, secure NVMe/TCP уже имеет понятную ценность. Для общего контекста полезен наш материал о NVMe и распределённых файловых системах; здесь мы не повторяем обзор, а строим проверяемую границу доступа для AI workload.

Перед выбором механизма нарисуйте data flow: от model registry и staging host до NVMe target, IP-фабрики, initiator и локального page cache. Отметьте, где байты находятся в покое, где передаются и где исполняются. Веса Safetensors не становятся конфиденциальными только из-за формата, а read-only mount не защищает пакет на проводе. Зато TLS не проверит, что в разрешённом namespace лежит нужная ревизия. Такая карта быстро показывает, какие controls действительно нужны.

Зафиксируйте acceptance criteria до изменения: разрешённый Host NQN подключается только с TLS; неверный PSK и неизвестный host отвергаются; pinned manifest читается; model service проходит probe; после rollback те же проверки возвращаются к baseline. Не включайте в критерии «задержка стала лучше», если change посвящён защите. Производительность измеряется отдельно на одинаковом workload и не должна подменять security outcome.

Не смешивайте identity, authentication и encryption

Самая частая архитектурная ошибка — ставить знак равенства между Host NQN, DH-HMAC-CHAP и TLS. Host NQN — стабильное имя инициатора. Оно участвует в policy и привязке ключей, но само по себе не секрет и не доказательство личности. DH-HMAC-CHAP использует общий секрет, чтобы target проверил host; второй controller secret позволяет mutual authentication. TLS поверх NVMe/TCP шифрует transport и проверяет владение PSK.

Назначьте owner каждому слою. Platform team владеет Host NQN и жизненным циклом узла. Storage team разрешает этот NQN на конкретном subsystem и управляет target-side secrets. Security или secrets team задаёт процедуру выдачи, ротации и отзыва. Владелец model service отвечает за pinned model revision и application probe. Когда один человек «просто кладёт ключ на обе стороны», расследование первой же ошибки превращается в перебор догадок.

Мини-кейс: controller подключился, но vLLM не стартовал. Если evidence показывает корректный TLS identity, чтение namespace проходит, а hash manifest не совпадает, проблема находится выше transport. Если неверный Host NQN получает тот же namespace, наоборот, application logs здесь почти бесполезны: нарушена identity policy. Такое разделение похоже на паспорт, турникет и бронированный коридор — три разных функции, даже если пользователь проходит их подряд.

Preflight: kernel, nvme-cli, tlshd и статус функций

Secure connect начинайте не с ключа, а с evidence bundle. На дату подготовки статьи latest stable nvme-cli — 2.16; ветка 3.0 доступна как pre-release. В master старые команды gen-tls-key, tls-key, gen-dhchap-key уже помечены deprecated в пользу семейства nvme keys. Поэтому автоматизация обязана проверять локальную версию и её --help, а не копировать синтаксис из случайного gist.

Для kTLS handshake нужен tlshd из ktls-utils. Официальный проект указывает kernel 6.5+ и опции CONFIG_TLS, CONFIG_KEYS, CONFIG_KEYS_REQUEST_CACHE; конкретный дистрибутив может добавлять свои зависимости. Отдельно проверьте CONFIG_NVME_TCP_TLS и host authentication в поставленном kernel. Наличие модуля nvme_tcp не подтверждает TLS.

Сохраните вывод рядом с change ticket. Это не формальность: обновление kernel без подходящего tlshd или смена nvme-cli между major versions способно сломать reconnect после перезагрузки, хотя текущая сессия продолжит жить.

Документируйте support status, а не только номер пакета. Репозиторий nvme-cli releases отделяет stable 2.16 от beta 3.0; документация master может описывать интерфейс, которого ещё нет в вашем дистрибутиве. Проект ktls-utils прямо перечисляет kernel prerequisites для handshake agent. Если один из компонентов vendor backport, просите подтверждение дистрибутива и тестируйте именно его пакет, а не upstream mainline.

set -eu
uname -r
nvme version
nvme connect --help | sed -n '/tls\|keyring\|chap\|kxchap/p'
nvme keys --help 2>/dev/null || true
modprobe nvme-tcp
systemctl is-active tlshd
nvme show-hostnqn
grep -E 'CONFIG_(TLS|KEYS|KEYS_REQUEST_CACHE|NVME_TCP_TLS|NVME_HOST_AUTH)=' \
  /boot/config-$(uname -r) || true
keyctl show

Зафиксируйте Host NQN и границы выдачи ключа

Host NQN должен переживать reboot и не зависеть от имени /dev/nvme0. Проверьте /etc/nvme/hostnqn и /etc/nvme/hostid, занесите значения в inventory, а на target разрешите только нужную пару host–subsystem. Копирование образа VM вместе с Host NQN создаёт клон личности: новый inference-узел может получить доступ, предназначенный старому.

Перед изменением соберите baseline: список fabrics controllers, topology, разрешённые subsystem NQN, keyring и revision модели. Номера controller могут измениться после reconnect, поэтому связывайте наблюдения с NQN, transport address и namespace identifier. Owner должен уметь ответить на два вопроса: какой host сейчас предъявляет этот NQN и какой model service имеет право читать этот namespace?

Для dedicated GPU-сервера удобно выдавать отдельную identity на физический узел и отдельный subsystem для production-моделей. Для временного canary используйте другую identity и read-only копию или тестовый namespace. Не расширяйте ACL production namespace только ради проверки. Это тот самый negative control: соседний, неразрешённый Host NQN обязан получить отказ.

Такая дисциплина поддерживает и LLMOps: pinned model revision остаётся прикладной идентичностью, а Host NQN — инфраструктурной. Подробнее о версиях и rollback модели мы писали в руководстве по жизненному циклу LLM в production.

TLS PSK: keyring вместо секрета в командной строке

NVMe/TCP TLS использует pre-shared key, связанный с Host NQN и Subsystem NQN. В Linux key material должен жить в kernel keyring, а tlshd получает его во время handshake. Конфигурация хранит ссылку или identity, а не должна превращаться в склад PSK. Это важнее эстетики: секрет в аргументах виден через process inspection, попадает в shell history и нередко в CI logs.

Генерацию выполняйте командой именно вашей версии. Для stable 2.16 доступны legacy-команды, тогда как 3.0 pre-release переводит управление в nvme keys. Сначала откройте локальный man page, сгенерируйте PSK на доверенном owner-host, импортируйте его в выделенный keyring и только затем добавляйте connection config. Не вставляйте реальное значение в ticket или unit file.

После загрузки проверьте не содержимое ключа, а его presence, type, description/identity и permissions. Доступ к keyring должен иметь процесс handshake, но не model service. Это уменьшает blast radius: vLLM читает блоки модели, однако не получает право экспортировать transport credential.

Официальный design document linux-nvme предупреждает ещё об одной границе: TLS key умеет ссылаться на keyring, а DH-CHAP secret в новом INI-дизайне пока остаётся literal. Поэтому не переносите один и тот же storage credential между hosts и заранее определите срок жизни. Ключ без владельца и даты отзыва — уже технический долг, даже если шифрование работает.

Официальный design document libnvme разделяет authentication и encryption и описывает default keyring .nvme. Используйте этот источник для модели данных, но не считайте незавершённый INI-интерфейс обещанием вашего stable package. Надёжная автоматизация сначала валидирует capabilities, затем импортирует key и лишь после этого меняет connection profile. При сбое она должна остановиться до disconnect старой рабочей сессии.

В inventory храните не secret, а fingerprint или key identity, серийный номер, Host NQN, Subsystem NQN, владельца, дату выдачи и deadline отзыва. Для incident response этого достаточно, чтобы понять, какой credential затронут. Payload остаётся в secrets channel и kernel keyring. Ротация без такого реестра почти неизбежно оставляет старые PSK на части inference-узлов.

# Синтаксис генерации зависит от nvme-cli; сначала смотрим локальную справку.
nvme version
nvme gen-tls-key --help 2>/dev/null || true
nvme keys gen-tls --help 2>/dev/null || true

# После импорта проверяем метаданные, не печатая payload секрета.
keyctl show
keyctl list @s | sed -n '/NVMe/p'
systemctl status tlshd --no-pager

DH-HMAC-CHAP: включайте mutual auth осознанно

Односторонний DH-HMAC-CHAP доказывает target, что подключается host с нужным секретом. Это блокирует случайный или чужой initiator, даже если он знает адрес и NQN subsystem. Двусторонний режим добавляет controller secret и позволяет host проверить storage endpoint. Для фабрики, где маршруты или DNS могут меняться, mutual auth закрывает важную дыру в доверии.

Не путайте название протокола и текущий CLI. В исходниках nvme-cli master legacy gen-dhchap-key переименовывается в nvme keys gen-kxchap; прежние connection options также получают kxchap-* spelling. На stable-системе может быть только старое имя. Помечайте эту развилку в runbook и проверяйте доступные flags на каждом образе.

Production-ограничение здесь жёсткое: если ваша конфигурация требует literal DH-CHAP secret в world-readable файле, gate должен завершиться FAIL. Исправьте permissions и способ provisioning либо ограничьтесь TLS PSK, пока secrets story не станет приемлемой. «Функция поддерживается» не означает «её безопасно включать в данном дистрибутиве».

Начните с canary host и тестового subsystem. Положительный тест: правильный host secret подключается. Отрицательные: неверный secret не подключается; разрешённый host не принимает controller с неверным mutual secret; подключение без TLS отвергается policy. Каждый отказ должен быть виден в host journal и target audit, иначе on-call не отличит атаку от опечатки.

Secure connect и effective-state gate

Connection config должен описывать stable identities, transport address и security policy. Не привязывайте секрет к конкретному номеру controller. В свежем INI-дизайне linux-nvme параметры безопасности задаются на уровне Host или Subsystem, а отдельные controller = строки описывают пути. Но эта конфигурация относится к развивающейся ветке: для stable distribution используйте поддерживаемый им формат и nvme-stas/systemd integration.

После connect соберите три вида доказательств. Static state: нужный subsystem и namespace появились у ожидаемого Host NQN. Transport state: kernel и tlshd не сообщают fallback или handshake error. Data-path test: чтение контрольного immutable-файла проходит через агрегированное устройство. Само наличие /dev/nvmeXnY недостаточно.

Не запускайте destructive benchmark на production weights. Для canary достаточно заранее подготовленного файла с manifest hash и ограниченного read. Если storage team предоставляет два пути, TLS и authentication должны быть включены на каждом; один незашифрованный путь обнуляет смысл change.

Проверьте сетевую границу отдельно. Firewall должен разрешать target port только от storage interfaces, routing не должен неожиданно уводить трафик через management-сеть, а MTU и offload меняются независимо от TLS rollout. Packet capture допустим на лабораторном стенде как отрицательное доказательство: после secure connect в захвате не должно быть читаемого payload блоков. Но отсутствие читаемой строки не заменяет проверку negotiated security state и target policy.

Если используется multipath, сначала докажите безопасность одного пути, затем второго и только после этого тестируйте failover. Иначе ошибка соединяет сразу две переменные. У каждого пути должны совпадать Host NQN, Subsystem NQN и security requirement; различаться могут адрес и интерфейс. После отказа пути повторите application probe, а не ограничивайтесь восстановлением controller.

set -eu
nvme list
nvme list-subsys
journalctl -u tlshd -b --no-pager | tail -n 100
journalctl -k -b --no-pager | grep -E 'nvme|TLS|auth' | tail -n 150

# MODEL_MOUNT и MANIFEST задаются в окружении canary.
test -r "$MODEL_MOUNT/$MANIFEST"
sha256sum -c "$MODEL_MOUNT/$MANIFEST"
findmnt -no SOURCE,TARGET,OPTIONS "$MODEL_MOUNT"

От блока к модели: immutable mount и vLLM probe

Storage gate заканчивается не на sha256sum. Model service должен прочитать pinned revision, загрузить tokenizer и weights и ответить на известный probe. Актуальная документация vLLM принимает в --model имя либо локальный путь; именно локальный путь на защищённом mount делает связь со storage gate явной. Не включайте --trust-remote-code без отдельного review: transport encryption не делает чужой Python-код безопасным.

Смонтируйте model volume read-only для service account, запретите старт до secure connect и проверки manifest. Не полагайтесь только на network-online.target: он сообщает о готовности менеджера сети, а не о наличии конкретного NVMe namespace, mount или корректного ключа. В unit chain нужен отдельный oneshot gate, после которого стартует vLLM.

Application probe должен быть одинаковым до и после change: тот же model revision, tokenizer, короткий deterministic request и критерий готовности API. Мы не обещаем, что TLS ускорит inference — он может добавить CPU cost на I/O path. Задача canary состоит в том, чтобы подтвердить отсутствие неприемлемой регрессии на вашей сети и CPU, не выдумывая универсальный benchmark.

Если строите полный private AI endpoint, сопоставьте этот storage gate с gateway, auth и quotas из статьи про Private AI API на своих серверах. Защищённые weights — только один слой сервиса.

Официальная CLI-документация vLLM называет --model именем или путём и отдельно предупреждает о рисках локального media access и remote code. Pinning требуется на двух уровнях: файловый manifest фиксирует байты, а deployment config фиксирует путь и параметры loader. Если symlink current может переключиться без change record, storage transport остаётся защищённым, но воспроизводимость релиза теряется.

[Unit]
Description=vLLM with verified remote model storage
After=network-online.target nvme-model-storage.service
Requires=nvme-model-storage.service
ConditionPathIsReadWrite=!/srv/models

[Service]
User=vllm
ExecStartPre=/usr/local/sbin/verify-model-manifest /srv/models/revision
ExecStart=/opt/vllm/bin/vllm serve /srv/models/revision --load-format safetensors
Restart=on-failure
NoNewPrivileges=yes
ProtectSystem=strict
ReadOnlyPaths=/srv/models

[Install]
WantedBy=multi-user.target

Canary, negative controls и ротация без слепого окна

Правильный rollout начинается с нового key identity, а не с удаления старого. Загрузите новый TLS PSK на canary host и target, установите secure connection, пройдите static, data-path и application gates. Только после этого переносите небольшую долю inference workload. Старый ключ остаётся на короткое, заранее ограниченное окно rollback.

Отрицательные тесты обязательны и безопасны, если выполняются на тестовом subsystem: неверный PSK должен сломать handshake; неизвестный Host NQN — получить отказ; отсутствие TLS — не давать тихого plaintext fallback; неправильный pinned revision — останавливать model service до bind порта. Такой набор доказывает границы лучше, чем ещё один успешный connect.

Rollback симметричен rollout. Остановите model service, верните прежний connection profile и key identity, восстановите namespace, повторите manifest и application probe. Не делайте disconnect устройства, пока с него читают процессы: сначала drain, затем unmount, и лишь потом transport changes. Owner каждого шага и stop condition должны быть в runbook.

Ротацию планируйте отдельно для TLS PSK, host authentication secret и controller secret. Одновременная смена всех трёх усложняет attribution. Если canary не подключился, вы должны сразу понимать, сломана identity policy, authentication или TLS handshake.

Наблюдаемость: алерт не на шум, а на потерю гарантий

Собирайте события из kernel journal, tlshd, nvme-stas или выбранного orchestrator, target audit и model service. Полезные симптомы: повторяющиеся reconnect, authentication failure, TLS handshake error, исчезновение controller, рост model cold-start time, manifest mismatch и restart loop vLLM. Один счётчик не объяснит инцидент, поэтому связывайте их по Host NQN, Subsystem NQN и deployment revision.

Алерт должен отвечать на вопрос о гарантии. «Controller reconnect» может быть ожидаем во время maintenance. «После reconnect secure application probe не восстановился за принятый SLO» уже требует реакции. Отдельный критический сигнал — успешный plaintext connect там, где policy требует TLS. Его лучше ловить target-side и подтверждать регулярным negative test.

Не отправляйте secrets, key payload или полную командную строку в telemetry. Достаточны key identity, serial, owner, срок действия и результат операции. Для общей архитектуры метрик, логов и алертов пригодится руководство Observability vs Monitoring, но security events NVMe/TCP должны остаться самостоятельным runbook.

После каждого обновления kernel, nvme-cli или ktls-utils повторяйте capability gate на canary. Версионная совместимость здесь — часть availability. Зелёный health model API на старой сессии не доказывает, что следующий reboot сможет заново выполнить TLS handshake.

Итог: защищайте путь модели проверяемыми слоями

Безопасный NVMe/TCP для LLM — это не флаг --tls, а цепочка доказательств. Стабильный Host NQN задаёт identity, DH-HMAC-CHAP ограничивает initiator и при необходимости проверяет controller, TLS защищает сетевой путь, manifest фиксирует model revision, а vLLM probe подтверждает реальную готовность приложения. Каждый слой закрывает свой риск и имеет отдельного owner.

Начните с малого: инвентаризируйте версии и kernel configs, заведите тестовый subsystem, загрузите короткоживущий PSK в keyring и добейтесь предсказуемого отказа с неверным ключом. Затем подключите read-only model revision, пройдите тот же application probe до и после change и отработайте rollback. Если результат воспроизводится, переносите один production canary, а не весь GPU-парк.

Для workloads, где модель читается локально один раз и сеть полностью изолирована, сложность может не окупиться — это нормальный вывод. Но когда несколько выделенных inference-серверов получают ценные weights по общей IP-фабрике, сочетание сильной identity, transport encryption и negative controls превращает скрытое доверие в управляемую инфраструктурную гарантию. Подходящий выделенный сервер и сетевую схему стоит выбирать вместе с threat model; обзор критериев есть в материале о GPU-серверах для машинного обучения.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда NUMA становится проблемой для LLM-инференса

GPU загружен не полностью, но p99 первого токена ползёт вверх, CPU-потоки сервера мечутся между сокетами, а после рестарта картина иногда меняется сама собой. Такой набор симптомов часто списывают на batching, Python, драйвер или соседний workload. На двухсокетной машине стоит проверить ещё одну гипотезу: процесс обслуживает GPU через CPU и память, находящиеся по другую сторону межсокетной шины.

NUMA — это не отдельный «ускоритель». Память локального узла ближе к своим CPU-ядрам, а обращение к удалённой памяти проходит через межсокетный interconnect. Для GPU важна и топология PCIe: ускоритель физически висит за конкретным root complex. Если tokenizer, scheduler, network thread, pinned host buffers и GPU feeder оказались на разных узлах, каждый отдельный переход может выглядеть терпимо, но хвост latency собирает их вместе.

Disqualifier нужно назвать сразу: если сервер односокетный, приложение почти полностью GPU-bound, host-to-device трафик мал, а CPU и RAM не насыщены, ручная NUMA-привязка может ничего не изменить. Она также не лечит недостаток VRAM, Xid, ECC, плохой batching или медленную модель. Для аппаратных инцидентов используйте отдельный runbook по NVIDIA Xid, а не маскируйте ошибку affinity.

Практический критерий здесь простой: NUMA-locality интересна только тогда, когда вы можете связать наблюдаемый путь «CPU → память → PCIe → GPU» с application metric. Типичный пример — два одинаковых LLM-worker на одном сервере: один стабилен, второй даёт длинный хвост при одинаковом prompt mix. До изменения конфигурации сравните их topology, effective affinity и распределение страниц; одной строки из nvidia-smi недостаточно.

Снимите topology и baseline до первого изменения

Начинайте с evidence bundle, который можно повторить после rollout и rollback. Зафиксируйте модель GPU, PCI bus ID, версию драйвера, карту CPU/NUMA, память по узлам, текущие cpuset и mems процесса, а также неизменяемый canary-набор запросов. Если после тюнинга нельзя воспроизвести исходное состояние, вы получите красивую корреляцию без доказанной причины.

Официальная документация NVIDIA SMI описывает nvidia-smi topo -m: матрица показывает GPU, NIC, CPU affinity и классы пути PIX/PXB/PHB/NODE/SYS. Значение SYS особенно важно: путь пересекает PCIe и межсокетный interconnect. Но topology описывает физическую близость; она не резервирует ядра и не доказывает, где реально работает процесс.

Сохраните не только среднее время ответа. Для инференса полезны TTFT, inter-token latency, tokens/s, request queue time, CPU utilization по сокетам, memory bandwidth и число remote NUMA accesses, если платформа позволяет их получить. Canary должен сохранять модель, длины prompt/output, concurrency, batching policy, warmup и версию контейнера. Иначе изменение очереди легко выдать за эффект locality.

Проверяли ли вы, что «быстрый» worker не просто получил более короткие prompts? Возьмите один и тот же набор, прогрейте модель одинаково и разделите окна warmup, steady state и cooldown. Материал о том, как выбирать саму конфигурацию ускорителя, уже есть в гайде про GPU-серверы для машинного обучения; здесь мы намеренно сужаем задачу до размещения на готовом узле.

#!/usr/bin/env bash
set -euo pipefail
date --iso-8601=seconds
uname -a
nvidia-smi --query-gpu=index,pci.bus_id,name,driver_version --format=csv
nvidia-smi topo -m
lscpu --extended=CPU,NODE,SOCKET,CORE,ONLINE
numactl --hardware
PID="$(pgrep -n -f 'vllm|tritonserver|text-generation')"
taskset -pc "$PID"
grep -E 'Cpus_allowed_list|Mems_allowed_list' "/proc/$PID/status"
head -n 40 "/proc/$PID/numa_maps"

Как читать карту NUMA без ложных выводов

В nvidia-smi topo -m сначала найдите строку нужного GPU и колонку CPU Affinity. Затем сопоставьте ядра с lscpu -e и PCI bus ID с lspci -D. У двух GPU одинаковой модели affinity может различаться, потому что карты стоят за разными root complex. Название устройства и номер CUDA не заменяют stable identity: после перезагрузки ordinal способен измениться, а PCI address обычно лучше подходит для инвентаризации.

Матрица GPU↔GPU отвечает на другой вопрос. NVLink, PIX или PHB важны для tensor/pipeline parallel, но worker с одним GPU всё равно зависит от CPU и host memory. Например, модель целиком помещается в VRAM, однако tokenizer выдаёт много коротких запросов, scheduler постоянно формирует batches, а pinned buffers обновляются на каждом шаге. В этом случае удалённый CPU path может проявиться именно в p99, а не в среднем tokens/s.

Сверьте вывод с DCGM topology. DCGM сообщает CPU core affinity и NUMA optimal для группы, но документация отдельно предупреждает: topology не выполняет bind процесса. Это важная граница. Зелёный topology report означает, что удачное размещение возможно, а не то, что kubelet, systemd или shell его уже применили.

Для multi-GPU workload не пытайтесь любой ценой втиснуть все worker threads в один узел. Если GPU распределены по сокетам, правильнее разделить процессы по устройствам и дать каждому локальные CPU/память, чем создать один огромный cpuset. Иначе вы «исправите» локальность одного GPU ценой удалённого пути для другого. Сначала нарисуйте ownership: какой launcher создаёт процессы, кто выбирает GPU и кто управляет cgroup.

Baseline на bare metal: numactl, cpuset и проверка изнутри процесса

Для первого canary используйте явную привязку через numactl, а не сразу меняйте kubelet или системный unit. В актуальной man page numactl различает --cpunodebind, который ограничивает выполнение CPU узлами, и --membind, который разрешает выделение памяти только из заданных узлов. Жёсткий membind может завершить allocation ошибкой при нехватке локальной памяти — это полезный fail-closed режим для теста, но опасный универсальный default.

Начните с одного worker, одного GPU и конечного CPU budget. Не используйте «все ядра узла» просто потому, что команда короткая: там могут жить IRQ, storage, network и системные службы. Выделите конкретный диапазон, сохраните резерв для OS, затем запустите тот же canary. В отдельном окне проверьте /proc/PID/status, numactl --show из launcher context и /proc/PID/numa_maps. Конфигурация без effective-state проверки остаётся намерением.

Linux kernel documentation о NUMA memory policy подчёркивает, что cpuset restrictions имеют приоритет над policy процесса. Поэтому numactl --membind=0 внутри контейнера не расширит cpuset.mems, разрешённый родительским cgroup. Типичная ловушка: команда выглядит правильной, но контейнер видит только другой node или оба узла, а страницы уже были выделены до применения policy.

Практический пример: worker загружает weights до того, как launcher применил affinity к дочернему процессу. GPU выбран верно, CPU mask локален, но большая часть page cache и pinned buffers уже появилась удалённо. Полностью перезапустите canary после изменения и не сравнивайте живой процесс с новой маской со свежим baseline — это разные состояния памяти.

#!/usr/bin/env bash
set -euo pipefail
GPU=0
CPU_LIST=0-15
NUMA_NODE=0
export CUDA_VISIBLE_DEVICES="$GPU"
exec numactl   --physcpubind="$CPU_LIST"   --membind="$NUMA_NODE"   /opt/llm/bin/start-worker --config /etc/llm/canary.yaml

Kubernetes: когда Topology Manager действительно выравнивает ресурсы

В Kubernetes CPU Manager, Device Manager, Memory Manager и scheduler решают разные части задачи. Без координации pod может получить GPU с одного NUMA node, а CPU — с другого. Topology Manager собирает topology hints и выбирает согласованное размещение. Функция stable начиная с Kubernetes 1.27, но наличие компонента не означает, что строгая policy включена на узле.

Для latency-sensitive GPU-pod практичной исходной точкой служат CPU Manager static, Topology Manager single-numa-node или restricted и scope, соответствующий структуре pod. Официальная документация отмечает особую ценность сочетания pod scope и single-numa-node для workload с IPC и требованиями к latency. Однако admission зависит от hints, которые дают resource managers и device plugin; произвольный extended resource без topology information не станет локальным от одного названия policy.

CPU Manager выдаёт эксклюзивные CPU только Guaranteed pod с целочисленным CPU request. Burstable pod или fractional request останется в shared pool, и ожидаемая изоляция не появится. Проверьте фактический QoS, kubelet config, state file CPU Manager и cpuset контейнера. Если pod admitted, это доказывает совместимость hints на момент allocation; application readiness всё равно нужно проверять запросом к модели.

Не меняйте policy сразу на всём кластере. Выделите один canary node, drain его, сохраните kubelet config и resource inventory, примените изменение, затем верните только тестовый pod. У Kubernetes restart kubelet и удаление CPU Manager state имеют операционные последствия; следуйте процедурам вашей версии и не удаляйте state на работающем узле вслепую. Более широкий контекст платформы описан в материале Kubernetes для AI inference.

cpuManagerPolicy: static
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod
reservedSystemCPUs: "0-3"

Как доказать эффект: canary, отрицательный контроль и application gate

После привязки не ищите одну «правильную» цифру. Сравнивайте paired windows: тот же узел, модель, контейнер, prompt set, concurrency, batch settings и длительность. Сначала baseline без ручной policy, затем local bind, потом безопасный отрицательный контроль — привязка CPU или памяти к заведомо удалённому разрешённому node. Завершите rollback к baseline. Такая последовательность отделяет эффект topology от случайного изменения нагрузки.

Application gate должен отвечать на вопрос пользователя сервиса. Сохранился ли error rate? Не вышли ли TTFT и inter-token latency за SLO? Не упал ли goodput при улучшении p99? Инфраструктурный счётчик remote access — полезное доказательство механизма, но не успех сам по себе. Если remote accesses снизились, а latency не изменилась, узкое место, вероятно, уже мигрировало на GPU kernels, очередь, сеть или storage.

Пример: local bind снижает разброс queue time, но tokens/s остаётся прежним. Это нормальный результат для workload с короткими запросами: locality могла убрать jitter на host-side scheduler, не ускорив матричные операции. Другой пример — средний TTFT улучшается, а p99 ухудшается из-за нехватки локальной памяти и reclaim. Тогда жёсткий membind не готов к production, даже если один короткий benchmark выглядит лучше.

Заранее задайте stop conditions: OOM или allocation failure, рост error rate, нарушение SLO, исчезновение GPU из inventory, Xid, нестабильность canary либо невозможность восстановить исходный cpuset. Не продолжайте «ещё пять минут», когда gate уже красный. Сохраните результаты как evidence bundle: config digest, topology, effective masks и application summary с timestamp.

Типичные ошибки: affinity есть, а локальности нет

Первая ошибка — привязать только CPU. Процесс исполняется на локальных ядрах, но его страницы остались удалёнными или policy допускает fallback. Вторая — привязать память, но оставить network и storage IRQ на другом сокете; bottleneck просто переезжает. Третья — применить taskset к launcher, который затем создаёт отдельный runtime с другой cgroup policy. Каждый слой нужно читать из effective state конечного PID.

Четвёртая ошибка особенно неприятна: команда использует CUDA ordinal, а после reboot порядок GPU меняется. Привязка остаётся к node 0, но worker получает физически другой GPU. Храните PCI bus ID или UUID в evidence и сопоставляйте его с выбранным устройством при старте. Automation должна завершаться fail-closed, если inventory не совпал с ожидаемым, а не молча запускать модель на «GPU 0».

Пятая — считать automatic NUMA balancing универсальным лекарством. Kernel может мигрировать страницы CPU workload, но pinned memory, device DMA и жизненный цикл LLM-worker создают ограничения. Кроме того, cpuset ограничивает допустимые nodes. Не меняйте глобальный kernel.numa_balancing ради одного canary без отдельного плана: вы затронете другие workloads и потеряете чистоту эксперимента.

Шестая — переоценить synthetic copy test. Он подтверждает путь памяти или PCIe, но не моделирует tokenizer, batching и request scheduler. Держите три независимых gate: topology identity, effective placement и application request. Именно эта структура отличает production runbook от набора тюнинговых флагов.

Rollout и rollback: переносим canary в эксплуатацию

Production rollout начинайте не с процента трафика, а с ownership. Platform team отвечает за topology inventory и kubelet/cgroup policy; владелец модели — за одинаковый canary и application SLO; on-call — за stop condition и rollback. Если эти роли не названы, первая ночная деградация превратит affinity в загадочную настройку, которую никто не решится снять.

Расширяйте охват ступенчато: один worker, один GPU, один node; затем несколько worker на том же topology class; только после этого — другие модели или типы серверов. Не переносите маски CPU между разными SKU. Даже одинаковые процессоры не гарантируют одинаковое расположение PCIe slots, NIC и NVMe. Для каждого hardware class нужен собственный topology manifest.

Rollback должен быть симметричным. Верните прежний launcher или kubelet config, перезапустите worker так, чтобы память действительно выделилась заново, подтвердите исходные masks и повторите тот же application probe. Если baseline не возвращается, причинность не доказана: возможно, одновременно изменились cache, модель, нагрузка или thermal state. Зафиксируйте это честно вместо вывода «NUMA ускорила сервис».

На выделенном сервере такой эксперимент проще контролировать: у команды есть ownership над BIOS, PCIe placement, CPU reservations и restart window. Это естественный bridge к инфраструктуре KingServers, но не обещание универсального прироста. Выделенное железо даёт воспроизводимый baseline; эффект всё равно должен пройти canary и SLO gate. Соседние вопросы распределения workloads раскрыты в статье про GPU scheduling.

Короткий production-чеклист для NUMA-locality

Сведите процедуру к повторяемой последовательности. Сначала identity: модель GPU, UUID и PCI bus ID, CPU sockets, NUMA nodes, версия драйвера и container digest. Затем topology: nvidia-smi topo -m, lscpu, numactl --hardware, при наличии DCGM. После этого effective state конечного worker: CPU mask, memory mask, cgroup, numa_maps и момент выделения памяти.

Третий слой — ресурсный budget. Зарезервируйте CPU для OS и IRQ, задайте конечный набор worker cores, оцените доступную локальную память и оставьте запас. Жёсткий membind без capacity check превращает тюнинг latency в новый failure mode. В Kubernetes подтвердите Guaranteed QoS, integer CPU request, topology policy и hints device plugin.

Четвёртый слой — application proof. Один и тот же warmup и canary, одинаковый prompt mix, concurrency и batching. Смотрите среднее и хвосты, goodput и ошибки. Добавьте удалённый отрицательный контроль только на изолированном canary; затем выполните симметричный rollback. Не допускайте выводов по одному удачному прогону.

Наконец, запишите owner и stop condition. Кто имеет право менять affinity? Кто смотрит application SLO? Какой сигнал немедленно возвращает baseline? Практика кажется бюрократичной ровно до первого инцидента. Зато после неё NUMA перестаёт быть «магией железа» и становится обычной проверяемой policy.

Вывод: локальность полезна только как доказанная policy

NUMA-locality может убрать удалённый путь между CPU, памятью и PCIe GPU, снизить jitter и сделать LLM-инференс предсказуемее. Но строка affinity, успешный pod admission или меньше remote accesses ещё не означают, что пользователь получил более стабильный ответ. Надёжный результат строится из трёх независимых доказательств: topology identity, effective placement и application SLO.

Начните с одного canary-worker. Сохраните baseline, примените конечный CPU/memory budget, повторите тот же запросный профиль, добавьте безопасный удалённый контроль и верните исходную конфигурацию. Если эффект переживает эту симметрию, policy можно расширять на topology class. Если нет — вы всё равно выиграли: исключили одну гипотезу без риска для всего кластера.

Следующий практический шаг — снять карту вашего двухсокетного GPU-узла и проверить, совпадает ли реальный cpuset worker с ближайшим PCIe-root. Для нового выделенного сервера заложите topology inventory и rollback ещё до первого production-трафика. Тогда разговор о «правильной NUMA» заканчивается не верой в флаг, а воспроизводимым решением, которое команда умеет объяснить и отменить.

Стойка уже близка к пределу по питанию, GPU на пиках забирают весь доступный запас, а запрос «просто поставьте лимит на 50 ватт ниже» звучит подозрительно легко. Само значение power limit меняется одной командой, но эта команда ничего не доказывает о качестве LLM-сервиса. Нужны одинаковая нагрузка, стабильная identity устройства, три независимых gate и возврат к исходному состоянию. Ниже — production-runbook, который помогает проверить power cap без выдуманных процентов ускорения или экономии.

Что именно решает power cap — и когда он бесполезен

Power cap задаёт верхнюю границу потребления GPU. Когда карта достигает её, алгоритм управления питанием может снизить частоты. Это инструмент управления power envelope, а не кнопка «сделать inference эффективнее». В официальной документации nvidia-smi параметр --power-limit описан как максимальный лимит в ваттах в пределах min/max, причём изменение требует административных прав.

Хороший повод для эксперимента — физическое ограничение стойки, желание сгладить пики или проверить, можно ли улучшить energy-per-token при сохранении SLO. Плохой повод — низкая GPU utilization, длинная очередь из-за CPU tokenizer, медленная сеть или storage. В таких случаях GPU не упирается в собственную мощность, и новый cap лишь добавляет переменную.

Первый disqualifier прост: если одинаковый репрезентативный replay не выводит GPU к заметной загрузке и текущему power ceiling, power cap не является главным рычагом. Сначала ищите bottleneck. Для контекста полезно отделять управляемый cap от диагностики: материал про GPU throttling через DCGM и Prometheus объясняет причины снижения частот, а здесь мы намеренно создаём SW power cap и проверяем его влияние на приложение.

Есть и коммерческая граница. Если задача — разместить больше серверов в существующем power envelope, выделенная инфраструктура даёт прозрачное ownership над GPU, питанием и canary-узлами. Если задача — «сэкономить вообще», без счётчика токенов и SLO вывод будет слишком слабым для решения о конфигурации.

Baseline: что сохранить до первого изменения

Baseline должен позволять другому инженеру ответить на три вопроса: какое устройство меняли, какой лимит действовал и как в тот момент вёл себя LLM-сервис. Снимок одного nvidia-smi после инцидента для этого недостаточен. Запишите UUID, модель GPU, версию драйвера, power management mode, requested/default/min/max limit и фактически применяемый ceiling.

Затем зафиксируйте workload identity: версию модели и движка, параметры tensor parallelism, длины prompt/output, concurrency, режим batching, состояние prefix/KV cache и сам replay-набор. Знакомая ловушка: baseline прогоняют на холодном cache, а canary — уже на прогретом, после чего разницу приписывают ваттам.

Application evidence важнее красивой кривой мощности. Для vLLM сохраните TTFT, время на выходной токен, end-to-end latency, throughput, queue time, число running/waiting requests и ошибки. Актуальная документация vLLM Production Metrics перечисляет соответствующие Prometheus-метрики, но имена могут меняться между версиями, поэтому сверяйте endpoint именно вашего образа.

Соберите evidence bundle с timestamp и owner. Он пригодится не только для сравнения, но и для rollback: исходное значение нужно восстанавливать из сохранённого состояния конкретного UUID, а не копировать «обычный лимит» с соседней карты. Особенно если в сервере разные GPU или platform-level ограничения.

#!/usr/bin/env bash
set -euo pipefail
GPU_UUID="${1:?pass GPU UUID}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
OUT="power-baseline-${GPU_UUID}-${STAMP}.txt"

{
  nvidia-smi --query-gpu=uuid,name,driver_version,power.management,power.limit,power.default_limit,power.min_limit,power.max_limit --format=csv
  nvidia-smi -i "$GPU_UUID" -q -d POWER,CLOCK,TEMPERATURE
} | tee "$OUT"

UUID, допустимый диапазон и effective state

Не используйте индекс 0 как долговечную identity. После reboot, driver reload или изменения topology индекс может указывать на другое устройство. Для команды и автоматизации закрепляйте GPU UUID из inventory. Owner шага — инфраструктурная команда, которая контролирует host; приложение не должно само менять board power limit.

Перед write прочитайте ограничения именно целевого GPU. NVML предоставляет default limit и min/max constraints, а nvmlDeviceSetPowerManagementLimit требует root/admin, поддерживаемое устройство и значение в разрешённом диапазоне. Лимит применяется немедленно, но классический NVML-вызов не сохраняет его через reboot или driver unload. Это значит, что «команда вернула exit code 0» — только начало проверки.

После изменения снова прочитайте requested и enforced limit. На новых платформах различаются GPU ceiling, module power и GPU base power scopes; актуальная документация nvidia-smi отдельно описывает --scope. Не переносите команду с Hopper/Grace-конфигурации на другую архитектуру без проверки. Для обычного GPU ceiling не указывайте новый scope только потому, что он есть в свежей версии CLI.

Negative control нужен рядом: запрос к соседнему UUID должен показать, что его effective state не изменился. Если automation прошлась по группе целиком, canary потерян. В multi-GPU inference это особенно важно: один ограниченный rank способен изменить поведение всей tensor-parallel группы, поэтому либо тестируйте всю изолированную группу как единицу, либо не делайте вывод по одной карте внутри production replica.

Canary: меняем один управляемый контур

Выберите canary так, чтобы его можно было снять с трафика без нарушения доступности. Это может быть отдельная vLLM replica на одном GPU или целая tensor-parallel replica, если модель требует несколько карт. Baseline и canary должны получать один и тот же replay с одинаковой concurrency и распределением длин. Не смешивайте изменение cap с обновлением драйвера, модели, quantization или scheduler.

Шаг изменения намеренно скучный: подставьте UUID и предварительно согласованное значение в пределах min/max. Здесь нет универсального числа. Допустимый cap зависит от модели GPU, охлаждения, workload shape и SLO. Начинайте с малой, обратимой ступени, а не с минимально разрешённого значения.

Сразу после write подтвердите effective state чтением. Затем запустите прогрев, отбросьте прогревочное окно и только после этого соберите измеряемое окно. Проверяли ли вы, что токены и запросы на baseline и canary действительно совпали? Без этого power draw сравнивается с разной полезной работой.

Во время canary не отключайте защитные механизмы и не фиксируйте clocks «для чистоты эксперимента», если это не отдельный заранее спланированный тест. Power cap в реальной эксплуатации взаимодействует с boost, temperature и workload. Задача — увидеть поведение production-контура, а не лабораторную картинку без обычных ограничителей.

#!/usr/bin/env bash
set -euo pipefail
GPU_UUID="${1:?pass GPU UUID}"
CAP_WATTS="${2:?pass approved watts}"

nvidia-smi -i "$GPU_UUID" --power-limit="$CAP_WATTS"
nvidia-smi -i "$GPU_UUID" -q -d POWER
nvidia-smi --query-gpu=uuid,power.limit,power.default_limit --format=csv,noheader

Три gate вместо одной зелёной метрики

Gate 1 — configuration state. Целевой UUID сохранился, requested limit равен согласованному значению, enforced limit подтверждён, соседние GPU не изменились. Если этот gate не пройден, результаты нагрузки бессмысленны: вы тестируете неизвестное состояние.

Gate 2 — GPU data path. Смотрите power, total energy counter, SM/memory clocks, utilization, temperature и причины clock events. В актуальном DCGM поле DCGM_FI_DEV_CLOCKS_EVENT_REASONS заменяет deprecated throttle-reasons alias; отдельно доступны board power, total energy и время SW power cap. Справочник DCGM field IDs остаётся источником истины для единиц и поддержки.

Ожидаемо увидеть SW power cap при насыщенной нагрузке. Неожиданно — thermal slowdown или HW power brake. Они указывают на охлаждение, PSU/platform control или другой инцидент. Не записывайте hardware slowdown в «успешно достигли лимита».

Gate 3 — application readiness. TTFT, TPOT, throughput, queue time и error rate остаются внутри заранее определённого SLO. GPU может быть холоднее и потреблять меньше, но пользователю станет хуже из-за роста очереди. Именно application gate решает, можно ли продолжать rollout.

В каждом gate заранее задайте stop condition и owner. Infra owner откатывает limit и проверяет effective state; service owner останавливает подачу нагрузки и подтверждает возврат SLO. Такая граница ролей быстрее любого общего чата во время инцидента.

Как считать энергию на токен, а не радоваться низким ваттам

Средняя мощность сама по себе обманчива. GPU на 40 ватт ниже, но генерирующий на треть меньше токенов, может оказаться хуже по энергии на полезную работу. Нужны два монотонных счётчика на одном окне: delta total energy и delta generated tokens. DCGM публикует total energy consumption в миллиджоулях, а vLLM — counter с количеством generation tokens.

Формула проста: joules_per_token = delta_energy_mJ / 1000 / delta_tokens. Сравнивайте её только при одинаковом workload identity и достаточном числе завершённых запросов. Рядом храните TTFT, TPOT и throughput: хорошая энергоэффективность не даёт права нарушать latency SLO.

Для prefill-heavy и decode-heavy профилей результат может различаться. Prefill лучше насыщает матричные блоки, decode чаще ограничен памятью и batching. Поэтому один смешанный replay способен скрыть, какой класс запросов пострадал. Разделите отчёт хотя бы на два профиля и не усредняйте их в единственную «экономию».

Считать деньги лучше после технического gate. В статье о стоимости одного LLM-запроса на своём сервере показано, почему utilisation и простои влияют на экономику не меньше железа. Power cap добавляет ещё одну ось, но не заменяет расчёт полной стоимости и capacity.

#!/usr/bin/env bash
set -euo pipefail
VLLM_METRICS="${VLLM_METRICS:-http://127.0.0.1:8000/metrics}"
GPU_UUID="${1:?pass GPU UUID}"

date -u +%FT%TZ
nvidia-smi -i "$GPU_UUID" --query-gpu=uuid,power.draw,power.limit,clocks.current.sm,temperature.gpu --format=csv
curl --fail --silent --show-error "$VLLM_METRICS" |
  grep -E 'vllm:(generation_tokens|time_to_first_token_seconds|request_queue_time_seconds|request_time_per_output_token_seconds)'

Как читать результаты без самообмана

SLO сохранён, joules/token снизились. Это кандидат на следующую малую волну, но ещё не fleet policy. Выполните контрфакт: верните исходный cap на том же canary и повторите replay. Если метрики возвращаются к baseline, причинная связь стала сильнее.

Мощность снизилась, latency выросла. Инструмент работает, решение — нет. Возможно, cap пересёк точку, где частота падает быстрее, чем экономится энергия, или очередь усилила tail latency. Верните baseline и, если цель всё ещё актуальна, тестируйте менее строгую ступень отдельным запуском.

Ничего почти не изменилось. Это не бесплатная победа. GPU мог не достигать cap, окно оказалось коротким, workload был CPU-bound или счётчик токенов не совпал. Ищите отсутствие механизма прежде, чем расширять rollout.

Появились thermal/HW события. Остановитесь. Power cap не должен маскировать проблему питания или охлаждения. Сопоставьте результат с материалом о power density AI-серверов и стоек: board-level настройка не отменяет ограничений стойки, PSU, airflow и facility capacity.

Решение должно быть многомерным: application SLO, energy-per-token, стабильность, температура и capacity. Один график «ватты вниз» недостаточен для production change request.

Типичные ошибки эксперимента: где теряется причинность

Менять несколько параметров одновременно. Если вместе с power cap обновились драйвер, vLLM, quantization или batch scheduler, вывод не принадлежит ни одной переменной. Даже если сервис ускорился, нельзя утверждать, что причина в новом лимите. Разведите изменения по отдельным canary и оставьте одинаковый evidence bundle.

Сравнивать разные формы нагрузки. Средняя concurrency не описывает распределение prompt и output lengths. Один прогон может быть prefill-heavy, другой — decode-heavy; одинаковое число запросов при этом создаёт разную работу для GPU. Храните replay manifest, счётчики prompt/generation tokens и долю каждого профиля. Если production traffic нельзя повторить, хотя бы закрепите временные окна и объясните ограничение.

Игнорировать очередь. Throughput на завершённых запросах может выглядеть стабильным, пока waiting requests копятся. Через несколько минут tail latency внезапно выйдет за SLO. Поэтому queue time и waiting count проверяются на всём окне и после прекращения подачи: система должна успевать погасить хвост, а не только показывать хороший средний rate.

Принимать requested limit за enforced. Platform policy, module scope или out-of-band control способны сделать фактический ceiling ниже запрошенного. Читайте effective/enforced state и сохраняйте его рядом с desired value. Если они расходятся, owner сначала разбирается с control plane, а не подгоняет application benchmark под неизвестное состояние.

Считать idle-периоды экономией. Низкая средняя мощность во время пауз не показывает эффективность насыщенного inference. Отделяйте idle, warmup и измеряемое окно. Энергия на токен должна использовать delta counters только для окна, где запросы действительно обрабатывались; иначе паузы разных длительностей исказят результат.

Расширять cap на неоднородный fleet. Одинаковое число ватт не означает одинаковый operating point для разных GPU, BIOS, охлаждения и форм-факторов. Группируйте rollout по однородной hardware identity и проверяйте min/default/max на каждом устройстве. Policy должна выражать одобренное значение для конкретного класса, а не глобальную константу.

Забывать о multi-GPU синхронизации. В tensor parallel replica самый медленный rank способен удерживать остальные. Cap на одной карте может проявиться как рост collective wait и TPOT всей группы. Считайте такую replica неделимым canary-контуром, снимайте метрики по каждому UUID и откатывайте группу согласованно.

Объявлять успех без контрфакта. Температура в зале, соседняя нагрузка и cache state меняются со временем. Возврат к baseline на том же canary и повтор replay не делает эксперимент лабораторно идеальным, но хорошо отсеивает случайное совпадение. Если результат не воспроизводится в обратном направлении, зафиксируйте «эффект не доказан» вместо удобной истории.

Наконец, не превращайте runbook в гонку за минимальным cap. Цель задаётся ограничением стойки или экономической гипотезой, а guardrail — SLO. Как только следующий шаг не даёт полезного выигрыша или ухудшает application metric, эксперимент завершён. Production-инженерия выигрывает от ясной остановки, а не от самой низкой цифры в таблице.

Персистентность и автоматизация без скрытого drift

Классический NVML power limit не переживает reboot или driver unload. Persistence mode снижает вероятность unload между задачами, но не превращает произвольный write в вечную platform policy. Подробный runbook по жизненному циклу драйвера есть в статье про nvidia-persistenced для LLM.

Если cap нужен постоянно, автоматизация должна быть fail-closed. Перед write она сверяет ожидаемые UUID, модель GPU, допустимый диапазон и сохранённую policy. Если inventory изменился, новый GPU появился или UUID пропал, unit завершает работу ошибкой и не применяет лимит к «первой карте».

После write automation обязана прочитать effective state и экспортировать результат в наблюдаемость. Полезны отдельные алерты: desired != enforced, cap отсутствует после restart, power brake/thermal event активен, application SLO деградирует после смены policy. Последний алерт связывает инфраструктурную настройку с тем, за что отвечает сервис.

DCGM умеет поддерживать конфигурацию групп через lifecycle, но это отдельная policy surface. Не смешивайте DCGM enforcement и systemd-скрипт без единого owner: два контроллера могут спорить за значение. Выберите один источник desired state, документируйте его и оставьте audit trail.

#!/usr/bin/env bash
set -euo pipefail
EXPECTED_UUID="${EXPECTED_UUID:?}"
EXPECTED_NAME="${EXPECTED_NAME:?}"
DESIRED_WATTS="${DESIRED_WATTS:?}"

read -r UUID NAME MIN MAX < <( nvidia-smi -i "$expected_uuid" --query-gpu="uuid,name,power.min_limit,power.max_limit" --format="csv,noheader,nounits" | tr -d ',' awk '{$1="$1;print}'" ) [[ "$uuid"="=" ]] "$name"="=" "$expected_name" -v x="$DESIRED_WATTS" lo="$MIN" hi="$MAX" 'begin{exit !(x>=lo && x<=hi)}' nvidia-smi -i "$expected_uuid" --power-limit="$DESIRED_WATTS" -q -d power< code>

Rollout волнами и симметричный rollback

После успешного canary расширяйте изменение малыми волнами: одна replica, небольшая группа, затем согласованная доля fleet. Между волнами выдерживайте полное измеряемое окно для обоих workload profiles. Не переходите дальше, если canary попал в период низкой нагрузки или не набрал достаточного числа запросов для ваших SLO.

Для каждой волны фиксируйте список UUID, старое и новое значение, owner, start/end timestamp, application dashboard и stop conditions. На выделенных GPU-серверах такое ownership проще обеспечить: topology и power policy не делятся с неизвестным соседом. При выборе платформы сверяйте не только VRAM, но и power/cooling envelope; обзор конфигураций GPU-серверов для ML помогает поставить эту настройку в более широкий capacity plan.

Rollback симметричен rollout. Сначала остановите расширение и снимите/заморозьте новую нагрузку, затем восстановите сохранённый baseline limit по тем же UUID. Прочитайте enforced state, повторите GPU gate и тот же application replay. Возврат числа в nvidia-smi без возврата SLO — незавершённый rollback.

Проверьте automation: она не должна через минуту снова применить неудачный desired state. Если policy хранится в systemd, operator или CM-системе, сначала отмените источник desired state, затем меняйте устройство. Иначе получите «дребезг» конфигурации и спор двух владельцев.

Наконец, сохраните incident evidence. Даже отрицательный результат ценен: он показывает, для какого workload shape и SLO выбранный cap не подходит. Это лучше универсального числа, которое случайно пережило один спокойный вечер.

Итог: power cap — это проверяемая гипотеза, а не готовая оптимизация

Безопасный power cap начинается не с команды nvidia-smi -pl, а с evidence: стабильной GPU identity, диапазона ограничений, одинакового replay и application SLO. Затем идут один canary, три gate, расчёт энергии на полезный токен и контрфакт с возвратом baseline. Только после этого можно говорить о следующей волне.

Главная мысль практичная: меньше ватт не обязательно означает меньше затрат или лучший сервис. Решение считается удачным лишь тогда, когда power envelope стал управляемее, joules/token улучшились или остались приемлемыми, а TTFT, TPOT, очередь и error rate не вышли за границы. Если не совпало хотя бы одно из этих условий, честный rollback полезнее красивого графика.

Возьмите один изолированный GPU-контур, подготовьте evidence bundle и прогоните этот runbook на репрезентативной нагрузке. Для новой инфраструктуры заранее согласуйте power/cooling envelope и наблюдаемость с владельцем площадки: так настройка останется воспроизводимым инженерным решением, а не ручной магией после очередного пика.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Зачем 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 на следующем слое — это тоже хороший результат эксперимента.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Почему исправные GPU могут обмениваться через длинный путь

Симптом неприятно похож на ошибку приложения: все ускорители видны, CUDA инициализируется, память выделяется, а tensor-parallel LLM плавает по latency или зависает при создании communicator. Команда проверяет модель, меняет NCCL-переменные и перезапускает контейнер. Между тем проблема может находиться ниже — в том, куда PCIe fabric отправляет peer-to-peer транзакции.

Для прямого обмена запрос одного GPU должен дойти до памяти другого без обязательного возврата к CPU root complex. PCI Access Control Services, или ACS, умеет перенаправлять трафик вверх по иерархии. В виртуализированной среде это часть изоляции; на выделенном bare-metal узле такой redirect иногда превращает короткий путь между устройствами под одним switch в длинный маршрут через root.

Типичный инцидент начинается после BIOS update: hardware inventory формально тот же, но первый multi-GPU workload дольше проходит инициализацию. Health-check зелёный, потому что он проверяет наличие устройств, а не межGPU путь. Stop condition на этом этапе простой: не компенсировать симптом tuning-переменными, пока не сохранены topology, ACSCtl, IOMMU state и контрольный P2P-тест.

Эта тема отделена от адресного пространства и размещения BAR. Если платформа ещё не прошла базовую подготовку, сначала полезен runbook про Resizable BAR и Above 4G. Здесь же предполагается, что GPU перечисляются корректно; мы доказываем маршрут, корректность передачи и влияние на реальную LLM-нагрузку.

Главная идея статьи: ACS нельзя лечить одной командой. Нужна цепочка доказательств — pinned hardware identity, effective state, active transfer, application readiness и возврат к исходному состоянию теми же проверками.

P2P DMA: три доказательства вместо одного зелёного OK

Peer-to-peer DMA позволяет устройству инициировать обмен с памятью другого устройства без обязательной staging-копии через host buffer. Документация Linux отмечает границу: внутри одной PCIe hierarchy маршрутизация определена достаточно хорошо, а пересечение root ports и host bridges зависит от платформы. Поэтому одинаковые GPU в соседних слотах не гарантируют одинаковый путь.

Первое доказательство — topology identity. Нужно знать GPU UUID, BDF, родительские bridges и switches. Второе — mechanism availability: сообщает ли драйвер, что read/write P2P разрешены для конкретной направленной пары. Третье — traffic proof: проходит ли реальный перенос данных и использует ли приложение этот маршрут. Команда nvidia-smi topo -m отвечает в основном на первый вопрос, nvidia-smi topo -p2p p — на второй.

Официальная документация NCCL подчёркивает, что положительная P2P-матрица не является полной sanity-проверкой при bare-metal IOMMU и ACS. Это важная практическая оговорка: «OK» означает распознанную capability, но не обещает, что все platform settings совместимы с безопасным и производительным direct path.

Owner слоя topology — platform/SRE, а наблюдаемое доказательство — артефакт с hostname, временем, версиями и связкой UUID↔BDF. Отрицательный контроль — пара GPU, которая физически пересекает более дальний bridge или другой root port. Если положительная и отрицательная пары неразличимы во всех тестах, выбранный тест недостаточно чувствителен.

Не делайте вывод по одной средней скорости. Сначала корректность данных и отсутствие hang, затем сравнение на фиксированном binary. Любые универсальные цифры здесь были бы выдумкой: предел задают поколение PCIe, ширина link, switch, GPU, firmware и layout конкретного сервера.

Что означает ACSCtl и почему SrcValid+ — только улика

ACS — набор возможностей downstream port или PCIe switch. В полном выводе lspci -vvv есть capability и control state. Строка ACSCtl с SrcValid+ показывает включённую source validation, а redirect-флаги могут заставлять peer traffic подниматься к root complex. Но одна строка без дерева устройств не доказывает, что этот bridge лежит на пути проблемной пары.

Представьте развязку: два GPU находятся под одним switch и могли бы обмениваться на нижнем уровне. Redirect закрывает короткий съезд и отправляет обе транзакции через центр. Иногда это требование trust boundary. Иногда — BIOS default, не соответствующий роли выделенного inference-узла. Диагностика должна различить эти случаи до write-команды.

NCCL предлагает искать ACS через lspci -vvv | grep ACSCtl и для некоторых PLX/Broadcom bridges на bare metal показывает механизм изменения control word через setpci. Это не переносимый desired state. Адрес extended capability, поддержка firmware и последствия записи проверяются по документации производителя сервера; исходное значение регистра сохраняется обязательно.

Stop condition: BDF не сопоставлен с нужной GPU-парой; на хосте есть VM passthrough, SR-IOV или неизвестные DMA isolation requirements; отсутствует out-of-band доступ; после read-only сбора появились AER/Xid. Любой из этих пунктов закрывает change window до уточнения.

Нельзя оценивать ACS отдельно от IOMMU groups. Глобальный override способен изменить isolation semantics для других devices. Поэтому мы не используем «скрипт по всем BDF» как первый шаг и не советуем kernel override ради производительности.

set -euo pipefail
stamp=$(date -u +%Y%m%dT%H%M%SZ)
out="pcie-evidence-$stamp"
mkdir -p "$out"
nvidia-smi --query-gpu=index,uuid,pci.bus_id --format=csv > "$out/gpu-map.csv"
nvidia-smi topo -m > "$out/topology.txt"
nvidia-smi topo -p2p p > "$out/p2p-pcie.txt"
lspci -tv > "$out/lspci-tree.txt"
sudo lspci -vvv > "$out/lspci-vvv.txt"
grep -n "ACSCtl" "$out/lspci-vvv.txt" > "$out/acsctl.txt" || true
cat /proc/cmdline > "$out/proc-cmdline.txt"
dmesg | grep -i -E "iommu|dmar|default domain" > "$out/iommu.txt" || true

Evidence bundle до первого setpci и reboot

Хороший runbook начинается не с изменения, а с возможности доказать, что изменилось. Собирайте evidence тем же пользователем и в том же container namespace, где будет работать сервис. NCCL использует /sys для topology discovery; урезанный или виртуализированный sysfs может дать suboptimal решение ещё до collective.

В bundle входят версии BIOS, kernel, driver, CUDA и NCCL; GPU UUID/BDF; дерево PCIe; полный ACS capability/control state; IOMMU effective mode; состояние links; точная команда теста. Привяжите архив к maintenance ticket. После reboot BDF могут измениться, и без UUID вы легко сравните разные устройства как одно.

Static baseline фиксирует состав и route. Active baseline проверяет доступ и перенос. Application baseline использует ваш закреплённый model artifact, engine image, tensor-parallel size, запросы и warmup. Не называйте один прогон benchmark: задача — получить воспроизводимый до/после сигнал на одном canary.

Пример: GPU0 и GPU1 под одним switch — положительный кандидат. GPU0 и GPU2 пересекают host bridge — отрицательная граница. Если после изменения обе пары меняются одинаково, вероятнее всего, вы измерили CPU scheduling, warm cache или иной слой. Полезный контрфакт меняет только предполагаемую причину.

Добавьте owner и критерии. Platform owner отвечает за PCIe state, ML platform — за NCCL binary, service owner — за LLM probe. Смешивание ответственности приводит к ситуации, когда каждая команда видит зелёный локальный тест, но никто не подтверждает end-to-end readiness.

Bare metal и VM: почему один рецепт опасен

Самая дорогая ошибка — перенести bare-metal совет на hypervisor. В актуальной документации CUDA/NCCL translated IOMMU на Linux bare metal указан как несовместимый с поддерживаемым PCIe peer path NVIDIA; для VM, напротив, IOMMU и ACS обеспечивают isolation, а максимальная производительность зависит от корректной поддержки ATS и passthrough.

Первое поле change request — роль хоста: dedicated bare metal, hypervisor, guest или container на bare metal. Контейнер не равен VM, но может скрыть sysfs и devices. Гипервизор меняет trust boundary; отключение ACS там не является допустимым performance experiment.

Проверяйте /proc/cmdline и kernel messages о IOMMU/default domain. Формулировки зависят от платформы и версии ядра. Вы ищете effective state для GPU path, а не одну магическую строку. Intel DMAR/VT-d и AMD-Vi требуют platform-specific решения и vendor guidance.

Owner bare-metal change — владелец GPU pool вместе с firmware/platform owner. Owner VM path — virtualization и security teams. Stop condition — неизвестная зависимость от passthrough или DMA isolation. Материал про VFIO и IOMMU для GPU passthrough подробнее разбирает среду, где isolation важнее bare-metal короткого пути.

Если узел одновременно обслуживает доверенный LLM workload и недоверенные devices, правильным решением может быть физическое разделение ролей. Низкоуровневая настройка не должна превращать mixed-tenant платформу в неявный dedicated host.

Минимальное изменение: один canary и один подтверждённый bridge

Когда evidence подтверждает bare-metal роль, нужную GPU-пару под ACS-enabled switch и допустимость изменения, выберите один canary. Выведите его из scheduler, остановите GPU workloads и сохраните исходный ACS word для каждого затрагиваемого BDF. Не применяйте цикл ко всем PCI devices: удобство не оправдывает blast radius.

Для поддерживаемого PLX bridge NCCL показывает запись нулевого control word через setpci. Считайте это примером механизма. На части платформ устойчивый путь — BIOS option; runtime write исчезнет после reboot. Firmware update также способен перестроить topology.

У change gate три элемента. Owner выполняет запись. Evidence — read-back плюс неизменный inventory GPU/NIC/NVMe. Stop condition — исчез device, изменились IOMMU groups, появились AER/Xid, read-back не совпал или management access нестабилен. При stop выполняется rollback до запуска NCCL.

Отрицательная граница: bridge вне пути проверяемой пары не трогают. Если результат требует глобального отключения ACS, остановитесь и вернитесь к архитектуре сервера. Возможно, правильнее разместить GPU под одним switch или выбрать другой dedicated chassis.

Для автоматизации используйте fail-closed discovery: сначала GPU UUID, затем текущий BDF и родительский bridge, затем vendor/device ID и ожидаемая topology signature. Любое несовпадение завершает unit без write. Жёстко заданный BDF после firmware update опасен.

set -euo pipefail
bridge="03:00.0"   # заменить после сопоставления с lspci -tv
before=$(sudo setpci -s "$bridge" ECAP_ACS+0x6.w)
printf '%s %s
' "$bridge" "$before" | sudo tee /var/tmp/acs-before.txt
sudo setpci -s "$bridge" ECAP_ACS+0x6.w=0000
after=$(sudo setpci -s "$bridge" ECAP_ACS+0x6.w)
printf 'ACSCtl word: before=%s after=%s
' "$before" "$after"
test "$after" = "0000"

Infrastructure gate: topology, active P2P и NCCL

После изменения повторите те же read-only проверки. Сначала UUID↔BDF и PCIe tree: никакой device не исчез. Затем ACSCtl/read-back и IOMMU state. Только при совпавшем inventory запускайте P2P matrix; изменение порядка усложняет локализацию сбоя.

Следующий уровень — active transfer. В NCCL 2.31 появились opt-in active diagnostics, которые проверяют ожидаемые directed P2P edges передачей и валидацией данных. Это свежая возможность, отключённая по умолчанию: указывайте точную версию. Для закреплённых старых стеков используйте согласованный CUDA sample или nccl-tests из собственного artifact registry.

Положительный gate: ожидаемые P2P edges проходят data check, collective завершается без hang и неожиданного fallback. Отрицательный контроль: тот же binary с NCCL_P2P_DISABLE=1. Это не production tuning, а контрфакт. Если результат полностью одинаков, workload мог не использовать P2P или bottleneck находится в другом месте.

nvidia-smi topo и dcgmi topo описывают отношения, но не резервируют hardware и не измеряют bandwidth. Для NVSwitch отдельный control plane ведёт Fabric Manager; смежный runbook — NVIDIA Fabric Manager и NVSwitch. Не пытайтесь исправить его состояние через PCIe ACS.

Сохраняйте stdout, NCCL logs и exit codes как единый evidence set. Средняя скорость без correctness и ошибок недостаточна. Сначала отсутствие data corruption и hang, затем повторяемый performance comparison.

set -euo pipefail
nvidia-smi topo -m
nvidia-smi topo -p2p p

# Для NCCL 2.31+: active diagnostics являются opt-in
NCCL_RUN_DIAGNOSTICS=1 NCCL_DEBUG=INFO   ./all_reduce_perf -b 8M -e 256M -f 2 -g 4 | tee nccl-p2p-enabled.log

# Контрфакт: те же binary и параметры, P2P отключён
NCCL_P2P_DISABLE=1 NCCL_DEBUG=INFO   ./all_reduce_perf -b 8M -e 256M -f 2 -g 4 | tee nccl-p2p-disabled.log

Application gate: докажите результат на реальном LLM

Идеальный all-reduce не гарантирует улучшения LLM. Model-parallel layout может связывать другие GPU-пары, CPU affinity — заставлять input pipeline пересекать NUMA, batching — скрывать межGPU задержку. Application gate идёт после infrastructure gate, но оценивается отдельно.

Закрепите model revision, tokenizer, engine image, tensor-parallel size, набор запросов, concurrency и warmup. Смотрите readiness, ошибки communicator, latency distribution и useful throughput. Не меняйте batch size между «до» и «после». Если модель не загружается, это FAIL независимо от nccl-tests.

Безопасный контрфакт — временно отключить P2P только для тестового процесса, а затем вернуть обычный launcher. Если application metric меняется в ожидаемую сторону только при исправном P2P, attribution усиливается. Если нет, проверьте перенос bottleneck на CPU, storage, memory pressure или network.

Не формулируйте «отключение ACS ускоряет LLM» как общее правило. Защищаемый вывод звучит точнее: на конкретном hardware/firmware/software baseline восстановлен direct path выбранных GPU-пар, collective прошёл, а фиксированный workload вернулся к своему диапазону.

При Xid или AER stop condition срабатывает немедленно. Это уже incident response, а не performance change. Используйте отдельный runbook по ошибкам NVIDIA Xid, чтобы не смешивать аппаратный сбой с маршрутизацией.

Что чаще всего ломает честный вывод

Первая ловушка — сравнить холодный baseline с прогретым сервисом после change. Модельные weights, filesystem cache, JIT и allocator state должны проходить одинаковую процедуру. Иначе PCIe получает чужую заслугу.

Вторая — проверить только соседние индексы GPU. Индекс не равен физической близости и может измениться после reboot. Работайте через UUID/BDF и directed pairs. Третья — считать SrcValid+ достаточным обвинением. Нужны parent bridge, control bits и active test.

Четвёртая — оставить global kernel override ради одного canary. Он меняет semantics шире выбранной пары и способен ослабить isolation. Пятая — запустить production с тестовой переменной NCCL_P2P_DISABLE; контрфакт должен жить только в отдельном launcher и иметь time limit.

Шестая — следить лишь за throughput. P2P-проблема может проявляться хвостом latency, зависанием communicator или ошибкой данных. Собирайте correctness, readiness, p95/p99 внутри вашего измерительного контура, error rate и resource counters, но не обещайте чужие численные пороги.

Наконец, не смешивайте remediation и architecture. Если topology физически пересекает root complexes, ACS write не превратит её в one-switch path. Иногда честный результат диагностики — требование к другому размещению ускорителей или другой платформе.

Симметричный rollback и повторная сертификация после обновлений

Rollback — не обратная команда, а возврат доказанного состояния. Верните сохранённый ACS word или BIOS option, выполните нужный reboot, заново сопоставьте UUID/BDF, повторите topology, P2P, NCCL и тот же LLM probe. Если configuration вернулась, а application baseline нет, rollback не завершён.

Startup automation не должна доверять фиксированным BDF. После firmware update адрес может принадлежать другому bridge. Устойчивый unit вычисляет путь заново, сверяет vendor/device IDs и topology signature, а при несовпадении прекращает работу без write.

После каждого BIOS, firmware, kernel или driver update evidence считается устаревшим. Canary проходит тот же gate sequence; только затем обновляется золотой образ. Это сохраняет versioned proof и делает regression видимой, а не спрятанной в случайном workload.

Owner закрывает change ticket лишь после возврата узла в scheduler и успешного service readiness. Security/virtualization owner отдельно подтверждает, что isolation assumptions не изменились. Для арендованного dedicated GPU сервера запросите у провайдера topology и доступные firmware options до миграции модели.

Храните короткую запись: причина, затронутые BDF, before/after control word, версии, ссылки на evidence, результат положительного и отрицательного контроля. Такой журнал полезнее набора «магических» команд без контекста.

Вывод: короткий P2P-путь подтверждается цепочкой gates

PCIe ACS действительно способен мешать multi-GPU P2P, но лечить его нужно как control-plane change. Topology показывает, где искать; ACSCtl и IOMMU — effective state; active P2P/NCCL доказывает механизм; закреплённый LLM workload — прикладной результат. Пропуск звена оставляет правдоподобную, но недоказанную историю.

Для bare-metal canary действуйте узко: evidence bundle, одна GPU-пара, один подтверждённый bridge, read-back, infrastructure gate, application gate и те же проверки в rollback. Для VM не переносите bare-metal рецепт: ACS и IOMMU являются частью isolation, оптимизация идёт через поддерживаемый passthrough/ATS path.

Начните с read-only части на одном узле. По PCIe tree, ACSCtl, IOMMU state и P2P matrix станет понятно, есть ли основания открывать maintenance window. Не требуется рисковать production, чтобы получить первый полезный ответ.

Если нужна инфраструктура с предсказуемой multi-GPU topology, обсудите с King Servers конкретные GPU-пары, switches, firmware mode и модель эксплуатации до переноса LLM. Тогда аппаратная схема становится проверяемым требованием, а не сюрпризом после запуска. Следующий шаг прост: сохраните baseline сегодня, пока узел работает спокойно, и превратите его в canary gate для будущих обновлений.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Resizable BAR, BAR1 и Above 4G Decoding: три разных понятия

Above 4G Decoding разрешает firmware размещать 64-битные PCIe memory resources выше границы 4 ГБ. Это особенно важно для сервера с несколькими GPU, быстрыми NIC и NVMe: каждому устройству нужны BAR и окна мостов, а суммарный запрос быстро перестаёт помещаться в низком адресном пространстве. Настройка не делает GPU быстрее сама по себе; она создаёт пространство, в котором firmware и ОС могут корректно разложить ресурсы.

Resizable BAR — отдельная возможность PCIe: устройство сообщает набор поддерживаемых размеров BAR, а платформа выбирает один из них. В актуальной документации Linux kernel для этого есть интерфейсы проверки допустимых размеров и изменения resource; сам факт наличия capability не означает, что firmware выбрала максимальное окно или что это нужно конкретному workload. Поэтому фраза «ReBAR включён» без вывода lspci и resource map почти ничего не доказывает.

BAR1 в терминологии NVIDIA — окно, через которое часть framebuffer memory GPU может отображаться для CPU или сторонних PCIe devices. Его total/used/free показывает официальная документация nvidia-smi. BAR1 не равен всей VRAM и не является синонимом Resizable BAR. Типичная ошибка: увидеть большой объём VRAM, ожидать такой же BAR1 и объявить platform faulty, хотя конкретная модель GPU и режим платформы могут использовать другое отображение.

Практическая граница статьи такая: мы не обещаем прирост tokens/s от одной firmware-галочки. Мы проверяем, исчезают ли ошибки назначения MMIO, одинаково ли ОС видит все GPU после reboot и сохраняется ли требуемая P2P topology. Для выбора самих ускорителей полезен отдельный материал про конфигурацию GPU-сервера; здесь же речь только о готовности PCIe address space.

Сначала зафиксируйте симптом и неизменяемый baseline

Не начинайте с BIOS. Сначала запишите, что именно сломано: GPU отсутствует в PCI inventory, виден через lspci, но не в nvidia-smi, или полностью готов на уровне драйвера, а ошибку даёт только приложение. Это три разных владельца проблемы: platform/firmware, kernel/driver и runtime. Если смешать их в одну формулировку «GPU не работает», следующий reboot уничтожит половину доказательств.

Baseline должен включать точную модель платы и firmware, список BDF всех GPU и upstream bridges, версии kernel и NVIDIA driver, состояние IOMMU, вывод nvidia-smi -q, а также логи текущей загрузки. Сохраните не только успешные строки. Сообщения вида BAR no space, failed to assign или NVRM resource error важнее красивого summary: они показывают слой, на котором остановилась инициализация.

Представьте узел с четырьмя GPU и двумя высокоскоростными NIC. После включения ReBAR исчезла одна NIC. Это не «успешный GPU-тюнинг»: bottleneck и конфликт просто переехали на соседний PCIe resource. Нужен полный inventory до и после, а не проверка одного выбранного устройства. Именно поэтому в runbook об I/O-изоляции LLM-узла метрика приложения отделяется от состояния диска; здесь действует тот же принцип по отношению к PCIe.

Соберите evidence bundle до изменения firmware

Команды ниже не меняют состояние узла. Запускайте их из root shell или через sudo, сохраняя stdout и stderr в каталог с датой и именем сервера. Фильтр по NVIDIA удобен для быстрого просмотра, но полный lspci -nnvv нужен обязательно: конфликт может принадлежать bridge, NIC или контроллеру, а не самому GPU.

#!/usr/bin/env bash
set -euo pipefail
OUT="pcie-baseline-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"
uname -a > "$OUT/uname.txt"
lspci -Dnn > "$OUT/lspci-nn.txt"
lspci -Dnnvv > "$OUT/lspci-nnvv.txt"
nvidia-smi -L > "$OUT/nvidia-smi-L.txt"
nvidia-smi -q > "$OUT/nvidia-smi-q.txt"
dmesg -T | grep -Ei 'pci|bar|resource|mmio|nvrm|iommu' > "$OUT/dmesg-pcie.txt" || true
journalctl -k -b | grep -Ei 'pci|bar|resource|mmio|nvrm|iommu' > "$OUT/journal-pcie.txt" || true
tar -czf "$OUT.tar.gz" "$OUT"

Не отправляйте bundle в общий чат без проверки: в логах могут быть серийные номера, hostname и иные эксплуатационные детали. Храните его как change evidence. Если после изменения узел не загрузится, out-of-band console и этот архив позволят отличить новый конфликт от старого предупреждения.

Отдельно снимите firmware screenshots или экспорт profile, если BMC это поддерживает. Названия опций различаются: Above 4G Decoding может находиться рядом с PCIe/PCI subsystem, а Re-Size BAR — в другом меню и зависеть от CSM/UEFI mode. Не переносите названия пунктов между платформами наугад; сверяйтесь с руководством именно вашей платы и списком поддерживаемых GPU.

Прочитайте карту BAR в Linux, а не только BIOS-галочки

Linux показывает назначенные PCI resources в lspci -vv и в sysfs resource-файлах. В строках Memory at важны тип адреса, prefetchable-флаг и размер. Нулевой диапазон, disabled resource или повторяющееся предупреждение о нехватке места — повод остановиться до загрузки CUDA workload. Официальный PCI support guide Linux kernel описывает работу с BAR и Resizable BAR; это точнее форумных рецептов с универсальным pci=realloc.

Boot-параметр, перераспределяющий PCI resources, нельзя считать первым лекарством. Он меняет алгоритм назначения на уровне kernel и может затронуть соседние устройства. Сначала докажите, что firmware действительно оставила конфликт или недостаточное bridge window, затем проверьте рекомендации дистрибутива и поставщика платформы. На production-узле любое такое изменение должно иметь отдельное окно и rollback.

#!/usr/bin/env bash
set -euo pipefail
mapfile -t BDFS < <(lspci -dnn | awk 'tolower($0) ~ nvidia {print $1}') printf 'nvidia devices: %s\n' "${#bdfs[@]}" for bdf in "${bdfs[@]}"; do echo "="====" $bdf="====" lspci -s "$bdf" -vv sed -n ' region p; resizable bar ,+8p' test -r sys bus pci devices resource" && nl -ba done< code>

Сравнивайте не абсолютный «правильный размер из интернета», а симметрию ожидаемо одинаковых GPU и соответствие support matrix. Разные SKU, MIG/vGPU или display mode могут законно отличаться. Если один из четырёх одинаковых ускорителей получил иную карту и именно он не инициализируется, это сильное доказательство; если все четыре одинаковы, ищите следующий слой.

Driver gate: GPU перечислен, BAR1 доступен, новых NVRM ошибок нет

Следующий gate начинается только после чистого PCI inventory. nvidia-smi -q документирован NVIDIA как источник BAR1 Memory Usage: Total, Used и Free. Зафиксируйте вывод для каждого GPU и сопоставьте PCI Bus ID с BDF из lspci. Наличие записи BAR1 подтверждает, что драйвер способен отчитаться об окне, но не доказывает P2P и тем более не гарантирует скорость LLM.

Проверка должна быть позитивной и отрицательной. Позитивная: все ожидаемые GPU видны, driver version едина, query завершается без ошибки. Отрицательная: запрос из процесса с ограниченным CUDA_VISIBLE_DEVICES не должен неожиданно открывать соседний ускоритель. Такая граница важна после passthrough, MIG или изменений device policy: «нужное видно» ещё не означает «лишнее недоступно».

Если BAR1 total различается между одинаковыми картами, не перезапускайте сервис десятки раз. Снимите новый evidence bundle, сравните firmware profile, PCI link state и driver binding. Если же различие объясняется режимом GPU, зафиксируйте это как ожидаемое состояние. Статья про MIG и MPS в multi-tenant GPU полезна для понимания, почему shared accounting не следует трактовать как физическую неисправность.

Меняйте Above 4G и ReBAR как управляемый rollout

Сделайте один change set за окно. Если цель — устранить нехватку 32-битного MMIO на multi-GPU сервере, сначала включают поддерживаемое платформой Above 4G Decoding, сохраняют профиль, перезагружают и повторяют весь infrastructure gate. ReBAR включают отдельным шагом только при подтверждённой поддержке CPU/chipset, firmware, GPU и драйвера. Так причинность остаётся видимой.

До reboot назначьте owner: кто меняет firmware, кто наблюдает BMC console, кто принимает решение stop/continue. Stop condition — пропажа любого ожидаемого PCIe device, новая resource allocation error, невозможность загрузить драйвер или отсутствие удалённого доступа. Не продолжайте к CUDA только потому, что «основные GPU вроде видны».

NVIDIA прямо требует Above 4G Decoding в ряде сценариев vGPU/passthrough, но bare-metal inference — другой контекст. Документация по виртуализации подтверждает необходимость large BAR address space для некоторых конфигураций, однако её нельзя механически превращать в обещание ускорения любого LLM. Здесь мы используем это как пример требования к адресному пространству, а не как benchmark.

После reboot сравните архивы машинно, но решение принимайте глазами: исчезновение BDF, изменение bridge window или новая ошибка важнее общего числа строк. Соседние NIC и NVMe должны остаться на месте. Если изменилось несколько классов устройств, rollback безопаснее, чем попытка починить всё в текущем profile.

CUDA gate: контекст на каждом GPU и реальная P2P-матрица

После успешного driver gate создайте CUDA-контекст на каждом устройстве. Простое перечисление GPU через nvidia-smi не гарантирует, что runtime сможет выделить память и выполнить kernel. Минимальный тест должен пройти для каждого индекса в той же среде, из которой стартует production service: тот же container runtime, device mounts и permissions.

#!/usr/bin/env bash
set -euo pipefail
python - <<'py' import torch count="torch.cuda.device_count()" assert> 0, "CUDA devices not found"
for index in range(count):
    with torch.cuda.device(index):
        x = torch.ones(1024, device=f"cuda:{index}")
        torch.cuda.synchronize(index)
        assert float(x.sum()) == 1024.0
        print(index, torch.cuda.get_device_name(index), "PASS")
PY

Затем проверьте peer access между теми парами, которым он нужен по архитектуре. Официальный репозиторий NVIDIA CUDA Samples содержит deviceQuery, topologyQuery и p2pBandwidthLatencyTest. Начиная с CUDA Samples 12.9 старый bandwidthTest удалён как устаревший; NVIDIA рекомендует NVBandwidth для актуальных измерений. Не копируйте старую команду из многолетнего блога и не сравнивайте цифры разных topology как универсальный норматив.

git clone --depth 1 https://github.com/NVIDIA/cuda-samples.git
cmake -S cuda-samples -B cuda-samples/build -DCMAKE_BUILD_TYPE=Release
cmake --build cuda-samples/build -j"$(nproc)"
find cuda-samples/build -type f \( -name deviceQuery -o -name topologyQuery -o -name p2pBandwidthLatencyTest \) -print

Последняя команда намеренно только находит binaries: layout меняется между релизами, поэтому запускать найденный путь следует явно после проверки checkout/tag, соответствующего вашему CUDA Toolkit. Gate считается успешным не при «высокой цифре», а когда deviceQuery проходит, topology соответствует схеме сервера, требуемые пары сообщают peer access, а результаты повторяемы. Если P2P недоступен там, где приложение на него рассчитывает, не маскируйте это увеличением batch size.

Application gate: докажите readiness LLM, а не только здоровье GPU

Теперь запускайте pinned-версию модели и runtime, зафиксированную в change plan. Не обновляйте одновременно BIOS, драйвер, CUDA и vLLM: четыре переменные превращают любой результат в догадку. Для сервиса сохраните model revision, container digest, параметры tensor/pipeline parallelism и placement GPU. Это прикладная граница материала: hardware gate закончен, а успех всё ещё надо доказать на уровне inference.

Минимум нужны readiness, один детерминированный контрольный запрос, отсутствие CUDA/NCCL ошибок и сравнение с pre-change baseline по latency, error rate и времени старта. Не придумывайте порог заранее: используйте собственный SLO и одинаковую нагрузку. Если hardware чист, но TTFT вырос, проверьте NUMA affinity, PCIe topology, storage path, batching и thermal/power limits. ReBAR не должен становиться универсальным объяснением.

Контрфактическая проверка полезнее восторга от одного удачного запуска: верните исходный firmware profile на canary-узле и повторите тот же application probe. Если метрика не меняется, ReBAR, вероятно, не был причиной улучшения. Если меняется только время загрузки весов, но не steady-state throughput, bottleneck мог переехать в storage; сопоставьте результат с практиками GPU scheduling и не смешивайте разные фазы workload.

Проверяли ли вы поведение после второго рестарта? Однократный PASS может скрыть зависимость от порядка enumerating устройств или прогретого cache. Повторите cold boot, затем application probe без ручных вмешательств. Только воспроизводимый результат допускает rollout дальше одного узла.

Rollout, stop conditions и симметричный rollback

Начните с одного canary-узла той же аппаратной ревизии. После reboot повторите gates в неизменном порядке: inventory, resource map, driver/BAR1, CUDA context, P2P, LLM readiness. На каждом этапе сохраните артефакт рядом с baseline. Только после PASS владельца и stop conditions переходите к следующему серверу.

Rollback должен быть симметричным. Верните сохранённый firmware profile, перезагрузите узел, затем снова пройдите те же проверки. «Сервис поднялся» недостаточно: один GPU или NIC мог исчезнуть, а scheduler просто уменьшил параллелизм. Сравните полный inventory и контрольный запрос, а не только HTTP 200.

Для удалённого dedicated server заранее согласуйте hands-on процедуру: BMC console, recovery profile и окно, в котором допустим второй reboot. Если платформа не документирует совместимость ReBAR с установленными GPU, оставьте функцию выключенной и решайте resource conflict поддерживаемым способом. Production ценит воспроизводимость больше, чем красивую галочку в firmware.

Owner каждого gate должен быть назван в change record. Platform engineer подтверждает inventory и bridge resources; GPU/runtime owner — драйвер, CUDA и P2P; владелец сервиса — readiness и SLO. Такая граница избавляет от ситуации, когда все видят красный статус, но никто не имеет права остановить rollout.

Типичные ошибки и куда мигрирует bottleneck

Первая ошибка — считать большой BAR эквивалентом большой VRAM. Вторая — проверять только GPU 0, хотя конфликт может проявиться на последнем устройстве за bridge. Третья — менять Above 4G, ReBAR, CSM и IOMMU одновременно. Четвёртая — использовать чужие bandwidth numbers как pass/fail. У разных серверов различаются root complexes, switches, link width, NUMA и GPU interconnect.

После исправления MMIO bottleneck часто становится видимым в другом месте. Storage может ограничить cold start; CPU/NUMA — подготовку batch; сеть — distributed inference; power limit — устойчивую частоту. Проверяйте end-to-end application metric и отрицательный контроль причины. Если убрать спорную настройку на canary и результат не изменился, не приписывайте ей успех.

Наконец, не игнорируйте firmware lifecycle. Параметр может изменить поведение после обновления BIOS или добавления NIC. Добавьте проверку inventory и BAR resources в acceptance новых узлов, но не автоматизируйте изменение firmware без out-of-band recovery. Хорошая автоматизация сначала обнаруживает drift и останавливает rollout.

Ещё одна ловушка — считать отсутствие ошибок доказательством оптимальной конфигурации. Clean dmesg лишь разрешает следующий gate. Только application baseline покажет, соответствует ли система своей задаче; а если нет, исследование должно перейти к topology, storage, сети или планировщику.

Автоматизируйте acceptance, но оставьте firmware под контролем человека

После успешного canary превратите read-only часть runbook в повторяемую проверку. Храните ожидаемый inventory как данные: serial узла, firmware version, BDF каждого GPU, NIC и NVMe, driver version, допустимый CUDA device count и пары P2P. Скрипт сравнения должен показывать добавленные, исчезнувшие и изменившиеся устройства, а не только возвращать зелёный exit code. Тогда новая плата или переставленная карта не пройдут под видом обычного reboot.

Автоматизировать запись firmware settings сложнее: интерфейсы Redfish и vendor BMC различаются, а ошибка может лишить сеть сразу несколько узлов. Поэтому разделите workflow. CI или конфигурационный агент собирает evidence и формирует diff; человек подтверждает изменение на одном canary; автоматизация повторяет read-only gates после reboot. Массовое применение допустимо только для однородной аппаратной ревизии с проверенным recovery profile.

В acceptance report полезны четыре независимых результата. Platform PASS означает, что полный PCI inventory совпал с ожидаемым и BAR resources назначены без новых ошибок. Driver PASS — все GPU присутствуют в nvidia-smi, BAR1 читается, NVRM clean. Runtime PASS — CUDA-контекст создаётся на каждой карте и требуемые P2P пары доступны. Application PASS — pinned LLM revision отвечает, а измеряемые показатели укладываются в собственный baseline или SLO. Один общий статус скрывает место отказа.

Не фиксируйте абсолютный размер BAR как универсальную константу для всех серверов. При обновлении GPU generation, переходе в MIG/vGPU, добавлении PCIe switch или passthrough ожидаемая карта меняется. Версионируйте baseline вместе с hardware profile. Если узел отличается от profile, отправляйте его на review, а не автоматически исправляйте до похожего состояния.

Отрицательный тест автоматизации прост: временно подайте checker заранее подготовленный inventory без одного неважного на первый взгляд NVMe или с изменённым BDF. Pipeline обязан остановить rollout. Если он проверяет лишь число GPU, он пропустит миграцию конфликта на storage и создаст узел, который успешно инициализирует модель, но не выдержит cold start после очистки cache.

Сохраняйте provenance каждой проверки: время, hostname, boot ID, версии kernel и драйвера, commit скрипта и имя владельца change. Без этого два внешне одинаковых PASS нельзя сравнить. Для fleet используйте отчёт с полями expected/observed и ссылкой на сырой bundle, а не копируйте гигантский lspci в тикет. Через месяц такой формат ответит на главный вопрос: проблема появилась после firmware update, после установки новой NIC или уже существовала в baseline.

Наконец, закрепите срок пересмотра profile. Поддержка ReBAR и поведение драйвера меняются вместе с firmware и GPU generation; старый PASS не переносится автоматически на новую сборку. Перед обновлением повторите исследование по официальным release notes, пометьте preview или experimental функции и проведите canary заново.

Вывод: сначала адресное пространство, потом CUDA, затем LLM

Resizable BAR и Above 4G Decoding полезны только в точном контексте. Above 4G даёт firmware место для 64-битных PCIe resources, ReBAR позволяет выбирать поддерживаемый размер окна, а NVIDIA BAR1 показывает отображение framebuffer memory. Ни один из этих фактов по отдельности не доказывает ускорение inference.

Надёжный путь выглядит скучно, и это хорошо: evidence bundle, одно firmware-изменение, полный PCI inventory, driver/BAR1, CUDA context, P2P и pinned LLM probe. Те же проверки выполняются при rollback. Пройдите этот checklist сначала на canary-узле; если hardware gate чист, а SLO не улучшился, перенесите расследование на реальный bottleneck вместо ещё одной случайной BIOS-галочки.

Для нового multi-GPU dedicated server этот runbook стоит включить в приёмочные испытания до передачи узла команде ML. Один час на baseline и возвратный профиль обычно дешевле ночной диагностики после того, как сервер уже включён в production pool.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Полный passthrough: где проходит граница метода

Полный PCIe passthrough нужен не для того, чтобы просто «ускорить виртуализацию», а чтобы отдать одной виртуальной машине физический ускоритель почти без участия хостового драйвера. Для LLM-инференса это полезно, когда заказчики, окружения или контуры безопасности должны быть разнесены сильнее, чем это даёт контейнер. Цена ясна заранее: один GPU в момент времени принадлежит одному гостю, а плановая миграция превращается в операцию с остановкой и повторной привязкой устройства.

Это принципиально иной сценарий, чем MIG или MPS для multi-tenant GPU. MIG режет поддерживаемый ускоритель на аппаратные экземпляры, MPS совместно планирует CUDA-контексты, а passthrough передаёт весь PCI-функционал гостю. Если две команды должны одновременно загружать один GPU, этот runbook решает не ту задачу.

Зато у метода есть сильная эксплуатационная граница: хост не загружает модель и не обслуживает CUDA workload. Команда закрепляет версии guest OS, драйвера и inference runtime внутри VM, меняет сетевой слой отдельно от физического сервера и точно знает владельца устройства. Проверяли ли вы, кто владеет картой во время инцидента? Ответ должен подтверждаться командами, а не названием VM.

• Выбирайте passthrough, если важны отдельное ядро гостя, независимый userspace и один владелец GPU.
• Не выбирайте, если обязательны live migration, прозрачный sharing или быстрый autoscaling на одном устройстве.
• Не путайте изоляцию DMA с полной безопасностью сервиса: сеть, секреты, образы и API требуют собственных контролей.

IOMMU group — минимальная единица доверия

VFIO строит безопасную передачу устройства вокруг IOMMU: она ограничивает DMA теми областями памяти, которые назначены владельцу. Но единицей владения является не обязательно один адрес PCI. Документация ядра определяет IOMMU group как минимальный набор устройств, который можно изолировать от остальных. Многофункциональный GPU, его audio-функция или мост без ACS могут оказаться в одной группе.

Отсюда первый жёсткий stop condition: нельзя передавать только графическую функцию и оставлять соседнюю функцию группы активному драйверу хоста. Группа не станет viable, а попытка «починить» её принудительным ACS override меняет модель доверия. В production лучше переставить карту в другой слот, выбрать подходящую серверную плату или передать весь безопасный набор.

Сначала снимите evidence bundle: адреса, vendor/device ID, kernel driver, NUMA node и состав группы. Не начинайте с изменения initramfs. На сервере с двумя одинаковыми GPU ошибка в одном символе BDF способна отключить карту, которая обслуживает живой endpoint.

GPU=0000:65:00.0
lspci -nnk -s "$GPU"
readlink -f "/sys/bus/pci/devices/$GPU/iommu_group"
for dev in /sys/bus/pci/devices/$GPU/iommu_group/devices/*; do
  bdf=$(basename "$dev")
  lspci -nnk -s "$bdf"
done
cat "/sys/bus/pci/devices/$GPU/numa_node"

Gate проходит, когда группа существует, её состав ожидаем, и ни один соседний device не нужен хосту для диска, сети или управления. Отрицательная проверка не менее важна: выберите соседний GPU и убедитесь, что он находится в другой группе. Официальное описание модели и перехода к IOMMUFD находится в документации Linux VFIO.

Подготовка хоста: evidence до первого detach

До остановки любого процесса зафиксируйте baseline. Нужны версия ядра, параметры загрузки, драйвер GPU, активные клиенты и состояние IOMMU. Сам факт появления каталога /sys/kernel/iommu_groups полезен, но не заменяет проверку журнала загрузки и конкретной группы.

Для Intel обычно включают VT-d, для AMD — AMD-Vi/IOMMU в firmware и kernel command line согласно дистрибутиву. Не копируйте параметры из случайного руководства: названия и дефолты меняются, а часть серверных платформ включает remapping автоматически. Здесь намеренно нет универсальной строки для GRUB; её надо сверить с документацией вашей ОС и платы.

uname -r
cat /proc/cmdline
journalctl -k -b | grep -Ei 'DMAR|IOMMU|AMD-Vi'
lspci -Dnnk | grep -A3 -Ei 'VGA|3D|Audio'
nvidia-smi
fuser -v /dev/nvidia* 2>/dev/null || true

Если на GPU работают exporter, persistence daemon или контейнер, graceful stop принадлежит владельцу этого сервиса. Принудительный unbind при живом CUDA-контексте превращает понятную подготовку в reset-инцидент. Зафиксируйте owner, окно работ и команду возврата ещё до detach.

Практический пример: monitoring показывает нулевую загрузку, но exporter держит device node. Метрика говорит «idle», а kernel driver всё ещё имеет клиента. Поэтому инфраструктурный gate проходит только после проверки процессов, driver binding и группы вместе.

Сохраните baseline в тикет работ: BDF, UUID, driver version, список функций и состояние модели. После rollback эти же данные станут эталоном. Без симметричного снимка до и после команда легко пропустит исчезнувшую функцию или изменившийся NUMA affinity.

Bind и libvirt: передача должна быть управляемой

В стабильной конфигурации libvirt может сам отсоединить PCI device от хоста перед запуском и вернуть после остановки домена. Для этого у hostdev задают managed='yes' и полный domain/bus/slot/function. Это лучше набора ручных echo в sysfs: lifecycle становится частью декларации VM, а не памятью дежурного.

Если GPU многофункциональный, добавьте все необходимые функции отдельными hostdev и проверьте их совместное владение. Для современных карт также важны UEFI guest и достаточное пространство BAR. NVIDIA предупреждает, что большие BAR могут потребовать настроек VM, а некоторые обходные параметры QEMU имеют experimental-статус; применяйте их только для подтверждённого кейса.

После изменения XML проверьте фактическое состояние, а не только сохранённый файл. virsh dumpxml показывает effective configuration домена, lspci -nnk — текущий driver хоста. Спецификация libvirt Domain XML описывает managed hostdev: устройство detach перед стартом и reattach после выхода гостя.

Stop condition прост: если перед запуском весь набор группы не готов к vfio или после старта хотя бы одна функция осталась у хостового драйвера, трафик к VM не подаётся. Расширять привилегии или включать unsafe no-IOMMU ради зелёного старта нельзя: это убирает саму границу DMA.

Отдельно задокументируйте, кто может менять XML и запускать домен. Доступ к libvirt для passthrough фактически даёт управление физическим устройством. Это не обычная настройка приложения, поэтому privilege boundary должна быть узкой и журналируемой.

Старт VM: сначала PCI и reset, потом CUDA

Первый запуск делайте без production-трафика и без автоматического старта LLM. Сначала гостевая ОС должна увидеть правильные PCI ID, а хост — перестать владеть устройством. Так вы отделяете сбой assignment от проблем драйвера и приложения.

virsh start llm-vfio-01
virsh domstate llm-vfio-01
virsh dumpxml llm-vfio-01 | sed -n '//p'
lspci -nnk -s 0000:65:00.0
# В госте:
lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Если домен не стартует, сохраните ошибку libvirt, kernel log и состав группы до перезапуска. Типичные причины лежат в четырёх слоях: часть IOMMU group занята, BAR не помещается в адресное пространство гостя, device reset не поддержан в текущем lifecycle или адрес в XML неверен. Менять одновременно firmware, XML и driver version — плохой эксперимент: после такого вы не узнаете, что помогло.

Успешный старт тоже нужно попытаться опровергнуть. На хосте nvidia-smi не должна показывать переданную карту; в госте BDF и device ID должны соответствовать baseline. Если один accelerator одновременно «виден» обоим драйверам как рабочий, gate провален.

Зафиксируйте продолжительность старта, но не объявляйте её benchmark. Первый boot может включать инициализацию driver, а повторный — иной reset path. Важнее стабильность последовательности start → stop → start и отсутствие новых AER, IOMMU fault или Xid в журналах.

Application gate: CUDA видит карту, LLM отвечает

Рабочий PCI passthrough ещё не означает готовность inference. Внутри гостя проверьте driver, UUID, ECC-состояние там, где оно поддерживается, температуру и отсутствие Xid. Затем запускайте выбранный runtime с закреплённой моделью и конфигурацией. Не обновляйте гостевой драйвер «до последнего» во время миграции: совместимость CUDA runtime, kernel module и образа должна быть частью version lock.

nvidia-smi -L
nvidia-smi --query-gpu=uuid,name,driver_version,memory.total --format=csv
journalctl -k -b | grep -Ei 'NVRM|Xid' || true
curl --fail --silent http://127.0.0.1:8000/v1/models
curl --fail --silent -H 'Content-Type: application/json'   -d '{"model":"","prompt":"health probe","max_tokens":8}'   http://127.0.0.1:8000/v1/completions

Application gate содержит два разных доказательства. Первое: CUDA действительно использует переданный GPU, а не CPU fallback. Второе: сервис проходит реальный короткий запрос с закреплённым model ID. Latency одиночного запроса не является benchmark; она лишь подтверждает путь выполнения.

Контрфактическая проверка помогает не принять совпадение за причину. Остановите inference-процесс, убедитесь, что endpoint становится недоступен, а GPU memory освобождается; затем запустите снова и повторите тот же probe. Так проверяется связь между readiness и реальным workload.

Проверьте и отрицательную границу: хостовый runtime не должен найти переданный UUID, а соседняя VM не должна получить устройство. Для выбора аппаратной базы сверяйте объём VRAM, питание и охлаждение с руководством по конфигурации GPU-сервера; passthrough не исправляет недостаток памяти модели.

Отрицательные проверки и наблюдаемость границы

Изоляцию нельзя доказать только положительным nvidia-smi в госте. Нужен отрицательный контроль: переданный UUID отсутствует в рабочих инструментах хоста, соседняя VM не получает этот PCI device, а сетевые политики не открывают management API шире запланированного.

На хосте наблюдайте libvirt lifecycle, IOMMU faults, AER и reset-события. В госте — Xid, VRAM, температуру, throttling и application metrics: queue depth, error rate, время до первого токена и readiness. Эти слои нельзя сливать в один «GPU healthy». Например, карта может быть полностью видна CUDA, но модель не загружаться из-за storage timeout.

Разделите alerts по owner. Platform team отвечает за IOMMU group, vfio binding, VM lifecycle и физический reset. Команда inference — за модель, runtime, VRAM budget и API. Security — за образ гостя, сеть, секреты и доступ к libvirt. Во время инцидента такая таблица экономит больше времени, чем ещё один общий dashboard.

Добавьте correlation key: имя домена, BDF, GPU UUID и deploy revision. Тогда событие libvirt можно связать с Xid в госте и ошибкой endpoint. Без общей идентичности дежурные видят три независимых алерта и теряют причинный порядок.

Материал о безопасности данных и AI-моделей на GPU-серверах дополняет аппаратную границу контролями данных. Passthrough уменьшает совместное владение устройством, но не шифрует веса и не аутентифицирует API.

Troubleshooting по слоям: не лечите LLM через PCI

Диагностика идёт в том же порядке, что rollout. Если GPU остаётся у хоста, не трогайте CUDA в госте. Если PCI device виден, но nvidia-smi падает, не меняйте model path. Если CUDA здорова, а endpoint не готов, инфраструктурный gate уже пройден и поиск смещается в приложение.

Слой 1 — host ownership. Проверьте активные процессы, driver binding и все функции группы. Слой 2 — assignment. Сопоставьте effective XML и guest PCI inventory. Слой 3 — driver/reset. Ищите Xid, BAR и ошибки инициализации. Слой 4 — runtime. Проверяйте pinned model, доступ к хранилищу и VRAM budget.

Типичная ловушка — перезапустить хост и решить, что проблема исправлена. Reboot очищает состояние устройства, но скрывает дефект lifecycle. После восстановления повторите цикл start → stop → start без reboot. Если второй запуск ломается, у вас reset/rebind issue, а не случайный сбой приложения.

Другая ловушка — одновременно обновить driver в госте и изменить machine type. Получив зелёный результат, вы не сможете объяснить причину. Меняйте одну переменную, сохраняйте evidence и повторяйте тот же отрицательный контроль.

NVIDIA описывает поддерживаемые способы настройки KVM passthrough и замечания по large BAR в актуальном руководстве GPU Pass-Through. Сверяйте support matrix конкретного GPU и гипервизора перед rollout.

Rollback: вернуть GPU и доказать повторяемость

Rollback начинается не с virsh destroy, а со снятия трафика и остановки приложения. Дайте inference-сервису завершить активные запросы, зафиксируйте состояние GPU, остановите домен штатно и дождитесь libvirt lifecycle event. Только затем проверяйте возврат устройства хосту.

virsh shutdown llm-vfio-01
virsh domstate llm-vfio-01
lspci -nnk -s 0000:65:00.0
journalctl -k --since '-10 min' | grep -Ei 'vfio|IOMMU|AER|NVRM|Xid'
nvidia-smi -L

Положительный rollback gate: ожидаемый host driver снова владеет всеми нужными функциями, журнал не содержит новых IOMMU/AER/Xid ошибок, и хостовый probe проходит. Но этого мало. Запустите VM повторно и пройдите те же PCI, CUDA и LLM gates в том же порядке. Повторяемость важнее первого удачного запуска.

Если reattach не проходит, не пытайтесь вручную привязать половину группы, пока домен или QEMU ещё держит file descriptor. Сохраните virsh domstate, список процессов QEMU, driver links в sysfs и kernel log. Stop condition: GPU не возвращается без reboot после двух штатных циклов. Такой узел нельзя считать готовым к автоматическому обслуживанию.

Опишите аварийный вариант: перенести трафик на другой inference endpoint, оставить проблемный GPU вне пула и расследовать reset отдельно. Цель rollback — восстановить сервис и сохранить доказательства, а не любой ценой вернуть карту в работу.

Production-чеклист и следующий шаг

Готовый passthrough — это не XML, который однажды загрузился. Это повторяемый lifecycle с evidence до detach, отрицательной проверкой границы, application probe и симметричным rollback. Перед эксплуатацией закрепите BDF и UUID в inventory, владельцев gates, окно обслуживания и известный путь возврата на хост.

• IOMMU включена и подтверждена журналом; unsafe no-IOMMU запрещён.
• Состав группы проверен, соседние критичные устройства не затронуты.
• libvirt managed hostdev содержит все необходимые функции.
• Host ownership и guest ownership взаимно исключаются.
• CUDA gate отделён от LLM readiness и storage/network checks.
• Start → stop → start проходит без reboot.
• Alerts разделены между platform, inference и security owners.

Если вы выбираете площадку, начинайте не с тюнинга QEMU, а с совместимости платы, слотов, IOMMU topology, GPU и охлаждения. Для готового сервиса полезно сверить lifecycle с runbook по NVIDIA NIM и health-check. На выделенном GPU-сервере KingServers можно заранее обсудить топологию и требования VM до переноса модели.

Следующий безопасный шаг — прогнать runbook на тестовом домене, сохранить evidence bundle и намеренно сломать один gate: занять функцию группы, указать неверный BDF или остановить endpoint. Если команда локализует сбой по слою и возвращает GPU без reboot, инфраструктура действительно готова к production, а не просто красиво стартовала один раз.

Не переносите в production непроверенный experimental workaround для BAR или ACS. Зафиксируйте версию kernel, QEMU, libvirt и guest driver, затем повторите тест после каждого обновления. Такой version lock не отменяет обновления, но делает изменение наблюдаемым и обратимым.

Восемь GPU видны в nvidia-smi, но первая NCCL-операция зависает, а LLM-сервис отвечает cudaErrorSystemNotReady. Часто проблема находится ниже приложения: Fabric Manager не завершил инициализацию NVSwitch, версии пакетов разошлись или один link уже выпал из fabric. Ниже — production-runbook, который отделяет готовность инфраструктуры от готовности модели и не маскирует аппаратный сигнал перезапуском контейнера. В результате у дежурного появляется проверяемая цепочка gates, evidence и понятный rollback.

Где заканчивается Fabric Manager и начинается LLM

На NVSwitch-системе зелёный nvidia-smi ещё не означает, что multi-GPU LLM готов принимать трафик. Драйвер может увидеть все GPU, а fabric при этом не завершила инициализацию, отдельный link остаётся down или служба Fabric Manager запущена в несовместимой с драйвером версии. Типичный симптом — приложение стартует дольше обычного, NCCL зависает на первой коллективной операции либо CUDA возвращает cudaErrorSystemNotReady.

Эта статья разбирает single-node control plane: как проверить NVIDIA Fabric Manager, NVLSM, NVSwitch topology и DCGM до запуска модели. Это не повтор материала о multi-node RDMA/RoCE: сеть между серверами начинается после того, как каждый отдельный GPU-узел доказал локальную готовность. Для распределённого контура пригодится руководство про ML-кластер на нескольких GPU-серверах, но смешивать два слоя в одном тесте не стоит.

Рабочая граница проста. Infrastructure gate отвечает на вопрос «fabric собрана и наблюдаема?». Application gate отвечает на вопрос «реальный launcher использует ожидаемые GPU и завершает коллективную операцию?». Только два положительных ответа дают основание запускать vLLM, NIM или training job; один успешный systemctl status не заменяет второй.

Сначала определите, относится ли runbook к вашему серверу. Fabric Manager нужен NVSwitch-based платформам DGX/HGX; на сервере с прямыми NVLink-мостами или только PCIe отсутствие NVSwitch в DCGM discovery нормально. Официальное руководство NVIDIA Fabric Manager описывает службу как control plane, который конфигурирует memory fabric, координирует инициализацию GPU и наблюдает ошибки NVLink/NVSwitch.

Как устроен control plane NVSwitch

У стека несколько владельцев, и путаница между ними дорого стоит во время аварии. Kernel driver создаёт GPU и NVSwitch device state. Fabric Manager координирует инициализацию и, для ранних поколений NVSwitch, маршрутизацию. На B100/B200/B300 и более новых системах в service unit участвует NVLink Subnet Manager: NVLSM обнаруживает fabric, назначает идентификаторы портам, рассчитывает forwarding tables и программирует PKEY.

DCGM находится сбоку от control plane. Он обнаруживает GPU, switch и link entities, читает счётчики, health и диагностические результаты. Ограничение из документации DCGM по topology и links: DCGM наблюдает fabric, но не конфигурирует NVSwitch и не поднимает link. Поэтому dcgmi nvlink --link-status полезна для evidence, а лечить ею отсутствующую конфигурацию нельзя.

Приложение стоит выше. PyTorch, vLLM или NVIDIA NIM видит итог работы driver, FM/NVLSM и runtime. Процесс может перечислить восемь CUDA devices, но первая NCCL all-reduce выявит разрыв, незаметный при простом inventory. Для эксплуатации NIM отдельно пригодится материал про установку и health-check NVIDIA NIM; здесь нас интересует readiness узла до старта контейнера.

Не копируйте entity ids между хостами. DCGM предупреждает, что switch и link identifiers относятся к runtime inventory конкретного host engine. После перезагрузки, замены платы или обновления DCGM сначала выполняйте discovery заново, затем подставляйте найденные ids в мониторинг. Это маленькая деталь, которая отличает воспроизводимый runbook от команды, работающей только на машине автора.

Снимите baseline до любого изменения

Хороший baseline — не скриншот «всё зелёное», а воспроизводимый набор текстовых артефактов. Сохраните версии драйвера, Fabric Manager и DCGM, список PCI devices, topology matrix, switch inventory, состояние каждого link и свежий kernel log. Такой пакет позволяет сравнить узел до и после change, а не спорить по памяти о том, сколько портов было видно вчера.

nvidia-smi topo -m показывает связи GPU, CPU affinity и квалифицированные NIC; расшифровка SYS, NODE, PHB, PXB и PIX есть в официальной документации nvidia-smi. Для NVSwitch ориентируйтесь не только на матрицу: DCGM discovery и link-status дают отдельные сущности switch ports.

set -o errexit -o nounset -o pipefail
date -Is
uname -a
nvidia-smi
nvidia-smi topo -m
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
systemctl status nvidia-fabricmanager --no-pager
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 200
journalctl -k -b --no-pager | grep -Ei 'NVRM|Xid|SXid|NVSwitch|NVLink' || true

Не превращайте скрипт в автоматический PASS. На хосте без NVSwitch отсутствие switch entities ожидаемо; на HGX с NVSwitch — стоп-сигнал. Сопоставьте inventory с паспортом платформы и утверждённой конфигурацией. Проверяли ли вы, что число GPU совпадает не с «обычно восемь», а с конкретным SKU и partition mode?

Сохраните вывод в change ticket вместе со временем и серийными идентификаторами. Не записывайте только средний throughput: один неактивный port может потеряться в агрегации. Базовая единица расследования — конкретный GPU, switch и link entity, найденные на этом хосте сейчас. Добавьте checksum артефактов, если ticketing system позволяет прикреплять архивы: так проще доказать, что baseline не был заменён после инцидента.

Согласуйте версии driver и Fabric Manager

Самая приземлённая причина неготовой fabric — пакеты из разных веток. NVIDIA требует устанавливать Fabric Manager той же версии, что и Data Center GPU Driver. На B200/B300 добавляется NVLSM dependency и требования платформы к OFED/MOFED; для service VM руководство указывает также минимальные требования к kernel. Не переносите эти условия на A100 или H100 автоматически: сначала определите поколение baseboard.

Проверяйте установленные пакеты, а не только имя репозитория. На Debian/Ubuntu используйте dpkg-query, на RPM-системах — rpm -qa. Названия зависят от ветки и дистрибутива, поэтому команды ищут по шаблону и не прибивают номер версии гвоздями.

nvidia-smi --query-gpu=driver_version --format=csv,noheader | sort -u
dpkg-query -W 'nvidia-driver-*' 'nvidia-fabricmanager-*' 'nvlsm*' 2>/dev/null || true
rpm -qa | grep -E 'nvidia.*driver|fabricmanager|nvlsm' | sort || true
systemctl cat nvidia-fabricmanager
/usr/bin/nv-fabricmanager --version 2>/dev/null || true

Зафиксируйте пару «driver branch + FM package» как один version lock в Ansible, image manifest или change plan. Отдельное обновление драйвера оставляет службу на старой версии; отдельное обновление FM столь же опасно. После изменения нужен reboot или предусмотренная производителем последовательность reload, а затем полный baseline и gates с нуля.

Не редактируйте vendor unit в /lib/systemd/system без крайней необходимости: package update может заменить файл. Для override используйте systemctl edit и документируйте причину. Практический rollback — заранее доступные пакеты предыдущей согласованной пары и окно, в котором узел выведен из scheduler. «Понизим потом из репозитория» — не план: нужная версия может исчезнуть или потянуть неожиданные зависимости.

Infrastructure gate: докажите готовность fabric

Infrastructure gate должен быть бинарным и послойным. Сначала driver видит ожидаемые GPU. Затем service unit active, а journal не содержит незавершённой инициализации. После этого DCGM обнаруживает NVSwitch и показывает ожидаемые links up. Наконец, health или diagnostic run не возвращает действий isolate/reset. Если один слой не прошёл, верхние тесты не компенсируют провал.

На B200/B300 один unit может управлять FM и NVLSM, поэтому смотрите процессы и journal. По руководству Fabric Manager, операции выполняются через systemctl start|stop|status nvidia-fabricmanager, журнал читается через journalctl -u. После старта дождитесь завершения fabric initialization; мгновенный active не гарантирует configured.

systemctl is-enabled nvidia-fabricmanager
systemctl is-active nvidia-fabricmanager
systemctl show nvidia-fabricmanager -p ActiveEnterTimestamp -p ExecMainStatus
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 300
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
nvidia-smi topo -m

PASS означает: все предусмотренные платформой GPU и switch entities присутствуют, ожидаемые links up, topology соответствует baseline, новых Xid/SXid нет. Отрицательная граница столь же важна: если discovery не показывает NVSwitch на системе, где он обязан быть, не расширяйте привилегии приложению и не отключайте проверки. Остановитесь на infrastructure layer и разберитесь с driver/FM/device binding.

Пример: после обновления узел показывает восемь GPU, но DCGM discovery не содержит switches. Перезапуск vLLM ничего не меняет, потому что проблема ниже контейнера. Правильное действие — закрыть scheduler admission, проверить согласование пакетов, unit/journal и только затем повторить gate. Так диагностическая ошибка не превращается в серию упавших пользовательских запросов.

Сохраните результат gate машинно-читаемым: число ожидаемых сущностей, список down/disabled links и timestamp последнего события. Тогда автоматизация может отказать admission по конкретной причине, а не по расплывчатому «GPU unhealthy». Но не подменяйте hardware profile универсальным числом: разные HGX поколения имеют разную topology.

Application gate: проверьте реальный launcher

Даже идеальный infrastructure gate не доказывает, что service unit, контейнер или Kubernetes pod видит нужные devices. Application gate запускается в том же окружении, с теми же cgroup/device permissions и переменными, что production workload. Для PyTorch минимальный тест — NCCL all-reduce между всеми локальными rank: он создаёт CUDA tensor на каждом GPU и проверяет одинаковую сумму после коллективной операции.

Сохраните скрипт как immutable artifact и запускайте через фактический Python environment приложения. Ожидаемое число процессов задавайте из inventory платформы, а не вшивайте восемь во все серверы. В примере восемь — явный resource budget для конкретного восьми-GPU узла, а не универсальная настройка.

import torch
import torch.distributed as dist

dist.init_process_group("nccl")
rank = dist.get_rank()
world = dist.get_world_size()
torch.cuda.set_device(rank)
value = torch.tensor([rank + 1.0], device=f"cuda:{rank}")
dist.all_reduce(value)
expected = world * (world + 1) / 2
assert value.item() == expected, (rank, value.item(), expected)
torch.cuda.synchronize()
if rank == 0:
    print(f"PASS: {world} ranks, all_reduce={value.item():.0f}")
dist.destroy_process_group()

torchrun --standalone --nproc-per-node=8 fabric_smoke.py

CUDA_VISIBLE_DEVICES=0 python3 - <<'py' import torch assert torch.cuda.device_count()="=" 1, print('pass: launcher boundary exposes one gpu') py< code>

Отрицательный тест не ломает fabric: он проверяет, что launcher действительно ограничивает видимость. Если процесс всё равно видит больше одного GPU, проблема в изоляции, а успешный all-reduce не даёт права пускать multi-tenant workload. Для MIG/MPS правила другие; их сверяйте с руководством по MIG и MPS для multi-tenant GPU.

После smoke test запускайте readiness модели: загрузка весов, один контролируемый inference request и проверка логов. Не используйте latency одного запроса как benchmark; здесь нужен functional gate. Если infrastructure PASS, а all-reduce падает, область поиска уже узкая: launcher, NCCL/runtime, device mapping или container permissions, а не весь сервер.

Повторите тест из штатного launcher, а не только из интерактивной root shell. Разница в device cgroup, mount namespace или переменных окружения часто объясняет случай «у администратора работает». Фиксируйте world size, image digest и commit smoke script рядом с результатом.

Xid и SXid: как не потерять контекст ошибки

Xid — сообщение NVIDIA driver в kernel log. SXid — аналогичный класс сообщений от NVSwitch driver. Справочник NVIDIA Xid Errors разделяет источники: номер важен, но без модели GPU, driver version, времени, workload и соседних событий его недостаточно для решения.

При событии сначала заморозьте контекст. Закройте узел для новых заданий, но не перезагружайте автоматически: reboot стирает часть volatile evidence. Снимите journalctl -k, журнал FM/NVLSM, nvidia-smi -q, discovery и link-status. Затем определите, fatal ли событие, требуется ли reset/isolate и повторяется ли оно на том же port.

incident_dir="/var/tmp/nvswitch-incident-$(date +%Y%m%dT%H%M%S)"
install -d -m 0700 "$incident_dir"
journalctl -k -b --no-pager > "$incident_dir/kernel.log"
journalctl -u nvidia-fabricmanager -b --no-pager > "$incident_dir/fabricmanager.log"
nvidia-smi -q > "$incident_dir/nvidia-smi-q.txt"
nvidia-smi topo -m > "$incident_dir/topology.txt"
dcgmi discovery --list > "$incident_dir/dcgm-discovery.txt"
dcgmi nvlink --link-status --show-entity-ids > "$incident_dir/nvlink-status.txt"
tar -C /var/tmp -czf "$incident_dir.tar.gz" "$(basename "$incident_dir")"

DCGM публикует отдельные NVSwitch поля для fatal/non-fatal SXid, link errors, replay/recovery/CRC/ECC counters и reset-required. В актуальном каталоге DCGM field identifiers ids расширяются по поколениям, поэтому старый список без проверки dcgmi dmon --list рискован.

Не лечите каждый non-fatal counter reboot’ом. Сравните его с baseline и проверьте прирост: старое ненулевое значение без новых событий отличается от растущего счётчика под нагрузкой. Fatal SXid, link down или reset-required — другой класс: workload удерживать на узле нельзя до выполнения рекомендаций NVIDIA и повторных gates.

Знакомая ловушка — увидеть Xid приложения и сразу винить NVSwitch. Сопоставьте timestamps: если SXid и link error появились раньше NCCL timeout, fabric — сильный кандидат. Если fabric стабильна, а ошибка возникла только в одном контейнере после смены image, расследование должно подняться на application layer. В incident report разделяйте факт, гипотезу и принятое действие: это уменьшает число необоснованных reboot.

Мониторинг без ложного зелёного статуса

Для steady state собирайте три группы сигналов: состояние links, события Xid/SXid/reset-required и динамические counters температуры, throughput и ошибок. Один общий «GPU healthy» слишком груб: сервер может выдавать inference, пока один путь деградирует и retries постепенно растут. Alert должен указывать host, entity type, switch/link id и изменение значения за интервал.

Документация DCGM по NVSwitch и ConnectX рекомендует сначала обнаруживать ids через discovery и link-status, затем выбирать поля из каталога установленной версии. Switch temperature и aggregate throughput относятся к nvswitch entity, per-port errors — к switch_link. Entity/field mismatch может вернуть N/A; это не доказательство поломки.

dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
dcgmi dmon --list

# Подставьте ids, найденные на текущем хосте.
dcgmi dmon --entity-id nvswitch:0 --field-id 858,861,862 --count 5
dcgmi dmon --entity-id switch_link:0:3 --field-id 780,781,782,783 --count 5

Числа полей в примере соответствуют documented NVSwitch entities, но automation должна сверять их с release на узле. Для NVLink 5+ доступны дополнительные aggregate/per-link counters; на NVLink 4 и старше некоторые поля закономерно возвращают N/A. Маркируйте hardware generation в inventory, иначе одна panel будет показывать «нет данных» и «авария» одинаково.

Свяжите infra alert с application SLI, но не склеивайте их. Рост replay errors без изменения inference может быть ранним предупреждением; рост latency без link errors — повод проверить CPU, storage или scheduler. Если после ремонта fabric latency остаётся высокой, bottleneck мигрировал на соседний слой. Для orchestration и очередей полезен материал про GPU scheduling между inference, training и batch.

Храните raw counters достаточно долго, чтобы видеть скорость изменения, а не только последнее значение. Alert на абсолютный порог без baseline шумит после перезагрузок и замены железа. Отдельно отслеживайте отсутствие scrape: потерянная телеметрия не должна выглядеть как нулевые ошибки.

Recovery: возвращайте узел через те же gates

Recovery начинается не с systemctl restart, а с решения о blast radius. Запретите новые задания, дождитесь или корректно завершите текущие, сохраните evidence и только затем меняйте состояние FM, driver или хоста. В руководстве есть ABORT_CUDA_JOBS_ON_FM_EXIT, но поведение зависит от поколения и deployment model; на H100 и более новых системах часть опций неприменима. Не предполагайте, что stop FM безвреден для текущих CUDA jobs.

Если ошибка появилась после package change, предпочтительный rollback — последняя согласованная пара driver/FM, а не ещё одно обновление вперёд. Если журнал и DCGM указывают reset/isolate, следуйте runbook производителя платформы: software restart не заменяет power cycle или замену компонента, когда требуется hardware action.

systemctl is-active nvidia-fabricmanager
journalctl -u nvidia-fabricmanager -b --no-pager | tail -n 300
nvidia-smi
nvidia-smi topo -m
dcgmi discovery --list
dcgmi nvlink --link-status --show-entity-ids
journalctl -k -b --no-pager | grep -Ei 'NVRM|Xid|SXid|NVSwitch|NVLink' || true
torchrun --standalone --nproc-per-node=8 fabric_smoke.py

После reboot не сравнивайте только количество GPU. Повторите infrastructure gate, затем application gate и один LLM readiness request. Сравните topology и entity inventory с baseline. Если приложение заработало, но counter продолжает расти, узел не готов: локальное улучшение не отменяет деградацию.

Контрфактическая проверка помогает не спутать совпадение с причиной. Верните последнюю согласованную конфигурацию, не меняя одновременно container image и модель; если gates снова PASS, связь с package change подтверждается сильнее. Если проблема остаётся, переходите к hardware/service case с evidence, а не расширяйте список случайных изменений.

В Kubernetes вывод узла и возврат отражайте в scheduler, taints и admission. После восстановления не снимайте cordon до application gate. Общую архитектуру сопоставьте с руководством по KServe, GPU Operator, Kueue и autoscaling, но readiness NVSwitch-узла остаётся отдельным нижним gate.

Production checklist для change и дежурства

Соберите проверки в operational contract. До изменения: platform SKU, driver/FM/NVLSM versions, baseline topology, package rollback и свободное окно. После: service/journal, discovery, links, DCGM health, Xid/SXid, all-reduce и LLM readiness. Во время эксплуатации: alert на link state, fatal/non-fatal events, reset-required и рост error counters с entity labels.

Назначьте владельцев. Platform team отвечает за packages, systemd, firmware и hardware case. SRE — за admission, evidence и alerts. Команда модели — за launcher и application smoke. Когда ownership размыт, авария ходит по кругу: SRE перезапускает контейнер, ML-инженер меняет NCCL variables, platform team узнаёт о down-link последней.

Определите stop conditions заранее. Нет ожидаемого NVSwitch entity, есть link down, fatal SXid, reset-required, несовпадение driver/FM или all-reduce failure — узел не принимает workload. N/A по unsupported field требует уточнения поколения, но не обязательно изоляции. Такие правила делают дежурство предсказуемым и не зависят от уверенности инженера ночью.

Version lock и gates должны жить рядом с provisioning code. Проверка, которую нельзя воспроизвести после следующего обновления, превращается в устную традицию. Храните smoke script, список обязательных entities и ожидаемое число GPU как версионируемые artifacts для каждого server class.

Для каждого gate задайте owner, timeout, evidence path и rollback action. Тогда «проверить NVSwitch» перестаёт быть абстрактным пунктом и становится конечной процедурой. Раз в квартал прогоняйте runbook в maintenance window: аварийная инструкция, которую никто не запускал, обычно содержит устаревшие package names и ids.

Что считать действительно готовым узлом

Готовность NVSwitch-сервера — цепочка доказательств, а не один зелёный процесс. Driver и Fabric Manager согласованы по версии, FM/NVLSM завершили инициализацию, DCGM обнаруживает ожидаемые switch/link entities, topology совпадает с baseline, свежих fatal Xid/SXid нет, а реальный launcher завершает NCCL all-reduce и LLM readiness.

Полезная привычка — разделять infrastructure и application gates. Тогда ошибка локализуется по слою: package/service/fabric, наблюдаемость, launcher или модель. Отрицательная проверка границы и rollback к последней согласованной паре защищают от практики «дать больше прав и перезапустить всё».

Начните с простого шага: снимите baseline одного GPU-узла сегодня, пока он здоров, и сохраните вывод вместе с package versions. Затем превратите команды в change checklist и automation без жёстко скопированных entity ids. Если для multi-GPU LLM нужна выделенная инфраструктура с понятным hardware profile и окном обслуживания, параметры сервера согласуйте вместе с gate-планом, а не после первого инцидента.

LLM-сервис может внезапно отвечать медленнее, хотя очередь, VRAM и загрузка модели выглядят нормально. Причина нередко прячется ниже приложения: GPU упирается в лимит мощности или температуры, снижает частоту, а график utilization продолжает показывать почти идеальные 100%.

Такой инцидент легко принять за проблему batching, сети или планировщика и потратить часы на настройку не того слоя. Разберём рабочий контур DCGM Exporter, Prometheus и Alertmanager: какие метрики включить, как отличить power cap от thermal slowdown и что делать после алерта.

Почему GPU загружен на 100%, а токены идут медленнее

Высокая загрузка GPU отвечает только на вопрос, занят ли ускоритель. Она не показывает, с какой частотой выполняются ядра и почему эта частота ниже ожидаемой. В production картина знакомая: p95 time-to-first-token растёт, inter-token latency плывёт, а DCGM_FI_DEV_GPU_UTIL держится у потолка. Команда добавляет реплики, но новые узлы повторяют ту же деградацию.

Разделите три класса причин. Очередь перед inference-сервером увеличивает ожидание до начала обработки, но не обязана замедлять уже начатую генерацию. Давление на KV cache чаще проявляется вытеснением блоков, ошибками размещения или падением concurrency. Throttling меняет скорость вычисления: при сопоставимой модели, длине контекста и batch size падает SM clock, а рядом растёт время ограничения по мощности или температуре.

Не сравнивайте два произвольных окна. Возьмите одинаковый профиль нагрузки и сопоставьте четыре ряда: запросы и токены в секунду, utilization, SM clock и clock-event reasons. Один график вводит в заблуждение; четыре дают причинную картину. Если queue time стабилен, ITL ухудшается, частота падает, а violation растёт, гипотеза throttling становится проверяемой.

Рядом полезно держать разбор метрик AI Factory и руководство по GPU scheduling. Они закрывают goodput и планирование; здесь мы намеренно спускаемся к питанию, охлаждению и частотам конкретной карты.

Power cap, thermal slowdown и другие причины

Слово throttling часто используют как общий диагноз, хотя действие зависит от причины. Software power cap означает, что алгоритм управления питанием снижает частоты, удерживая GPU в заданном энергетическом конверте. Это не всегда неисправность. На плотном сервере лимит может быть осознанным компромиссом между скоростью одной карты и доступной мощностью стойки.

Thermal slowdown говорит о другой границе. Программное ограничение начинается возле максимальной рабочей температуры, аппаратное — у более жёсткого порога защиты. Повышение power limit здесь способно ухудшить ситуацию. Проверять нужно температуру входящего воздуха, обороты вентиляторов, загрязнение радиаторов, заглушки стойки, направление airflow и политику BMC.

Есть причины, которые нельзя автоматически назвать перегревом: sync boost ограничивает группу по самому медленному участнику, applications clocks фиксируют заданную частоту, а external power brake указывает на сигнал платформы или блока питания. В актуальной документации nvidia-smi события разделены, а часть старых названий помечена deprecated. Runbook должен опираться на конкретный event.

Представьте восемь GPU с одинаковой температурой, но аппаратный power brake только на одной. Это слабый аргумент в пользу общей проблемы охлаждения и сильный — в пользу проверки PSU, кабеля, riser или карты. Синхронный thermal violation на верхних серверах стойки, наоборот, часто указывает на рециркуляцию горячего воздуха.

Контур DCGM Exporter → Prometheus → Alertmanager

DCGM читает телеметрию NVIDIA GPU через драйвер и host engine. DCGM Exporter выбирает поля, добавляет метки устройства и, в Kubernetes-режиме, workload labels, затем отдаёт Prometheus-формат на /metrics. По официальному контракту dcgm-exporter стандартный listener — порт 9400, поддерживаемая платформа — Linux.

На bare metal разумно ставить один exporter на GPU-хост. В Kubernetes нормальная форма — DaemonSet или компонент NVIDIA GPU Operator. Один экземпляр на node видит локальные ускорители, а Prometheus связывает samples с node, pod и namespace. Запуск по exporter на каждый inference-pod размножает точки отказа и осложняет владение host engine.

У контура три независимых интервала: DCGM обновляет watched fields, exporter отдаёт значение, Prometheus делает scrape. Если температура собирается раз в 30 секунд, scrape каждые 5 секунд не создаёт новую физическую телеметрию. Быстрый collector при редком scrape тоже может скрыть короткое событие, если смотреть только gauges. NVIDIA рекомендует согласовать интервалы в руководстве по Prometheus.

Стартуйте с 15–30 секунд для общего мониторинга и ускоряйте только thermals, power и clock events, если этого требует SLO. Одновременно алертите up: отсутствие samples не должно выглядеть как здоровый ускоритель.

Развёртывание и первая проверка

До установки сверяйте совместимость GPU, драйвера и DCGM по актуальной матрице. Контейнеру нужен NVIDIA Container Toolkit и доступ к устройствам. В Kubernetes используйте GPU Operator, если он уже владеет драйвером и device plugin; отдельный Helm release удобен при раздельных жизненных циклах.

На standalone-хосте после установки проверьте GPU, сервис и endpoint. Фиксируйте версию пакета или образа в инфраструктурном коде. Копирование случайного latest-тега усложнит расследование, когда формат метрики или поддержка поля изменится.

nvidia-smi
systemctl status nvidia-dcgm-exporter --no-pager
curl --fail --silent http://127.0.0.1:9400/metrics \
  | grep -m1 '^DCGM_FI_DEV_GPU_UTIL'

В Kubernetes проверяйте не только Ready у DaemonSet. Убедитесь, что pod есть на каждом GPU-node, endpoint достижим из сети Prometheus, а метрики получили workload labels. Target может быть UP, но нужное поле отсутствовать из-за collector configuration, доступа к устройству или несовместимой связки driver/DCGM.

Endpoint лучше оставить в закрытой monitoring-сети. Exporter поддерживает web-config Prometheus exporter-toolkit для TLS и basic auth. Если chart-managed ServiceMonitor предполагает HTTP, а вы включили TLS, создайте собственную scrape-конфигурацию с нужными credentials.

Для общей платформы сверяйтесь со статьёй про Kubernetes для AI inference. DCGM закрывает hardware telemetry, но не заменяет метрики vLLM, KServe или gateway: без них вы увидите торможение карты, но не влияние на запрос.

Какие поля включить в collector

Набор должен покрывать состояние, причину и эффект. Для состояния нужны температура, power usage, GPU utilization и SM clock. Для причины — power/thermal violation и clock event reasons. Эффект измеряют application-level tokens/s, TTFT и ITL, которые приходят не из DCGM.

DCGM_FI_DEV_POWER_VIOLATION и DCGM_FI_DEV_THERMAL_VIOLATION относятся к shipped optional metrics и могут быть закомментированы в default collector. Согласно справочнику DCGM Exporter, их включают через custom CSV, YAML fields или Helm custom metrics.

DCGM_FI_DEV_GPU_UTIL, gauge, GPU utilization in percent.
DCGM_FI_DEV_GPU_TEMP, gauge, GPU temperature in Celsius.
DCGM_FI_DEV_POWER_USAGE, gauge, GPU power usage in watts.
DCGM_FI_DEV_SM_CLOCK, gauge, SM clock frequency in MHz.
DCGM_FI_DEV_POWER_VIOLATION, counter, Power violation time in microseconds.
DCGM_FI_DEV_THERMAL_VIOLATION, counter, Thermal violation time in microseconds.
DCGM_FI_DEV_CLOCKS_EVENT_REASONS, gauge, Active clock event reason bitmask.

CSV содержит ровно три поля в строке. Для новых конфигураций доступен YAML schema version 1 и отдельные watch groups. Изменение YAML требует restart, тогда как file-based CSV может перезагружаться. Exporter-owned cumulative counters хранятся в памяти и сбрасываются при recreation collector или restart, значит запросы обязаны переживать reset.

Не включайте все profiling fields «на будущее». На некоторых поколениях они требуют proprietary package и дополнительных привилегий, а поддержка определяется возможностями GPU. Для throttling базовых device fields достаточно. Короткий collector проще сопровождать и он меньше рискует раздуть cardinality.

Семантика счётчиков и типичные ошибки

Power и thermal violation — накопительные значения времени ограничения в микросекундах. Абсолютное число после недели работы почти бесполезно. Нужен прирост за окно: он показывает, сколько времени GPU находился под ограничением. При рестарте counter может сброситься, поэтому PromQL должен корректно обработать reset.

Clock event reasons может приходить как bitmask. Gauge удобен для ручной проверки, но неудобен для алерта. В актуальном exporter есть opt-in DCGM_EXP_CLOCK_EVENTS_TOTAL: он создаёт серию с label причины и считает переходы inactive→active. Это облегчает запросы, но состояние хранится в процессе и сбрасывается при его пересоздании.

Не путайте _COUNT и _TOTAL. Первый описывает события последнего collection window, второй предназначен для increase() и rate(). Частый scrape не гарантирует видимость микрособытия, если исходное поле собирается реже. Интервалы — часть дизайна, а не декоративный параметр.

Ещё одна ловушка — преждевременная агрегация. Средняя температура восьми карт может быть нормальной, когда одна уже замедляется. Для оперативного алерта сохраняйте UUID и node; для capacity review позже агрегируйте по модели, стойке или пулу. Проверяйте также unsupported или blank values: разные GPU поддерживают не одинаковый набор сенсоров.

PromQL для причинной диагностики

Смотрите запросы в одном диапазоне времени. Первые два показывают долю окна под power cap и thermal violation, третий — частоту, четвёртый — отсутствие exporter. Деление прироста микросекунд на длительность окна переводит delta в долю времени.

clamp_min(increase(DCGM_FI_DEV_POWER_VIOLATION[5m]), 0)
  / (300 * 1e6)

clamp_min(increase(DCGM_FI_DEV_THERMAL_VIOLATION[5m]), 0)
  / (300 * 1e6)

DCGM_FI_DEV_SM_CLOCK

up{job="dcgm-exporter"} == 0

Сравнивайте SM clock с baseline той же модели GPU и сопоставимого workload. Максимальная частота из случайного окна не годится как SLO: boost зависит от температуры, питания и типа kernel. Лучше создать recording rule baseline на здоровом прогоне и версионировать её вместе с профилем нагрузки.

Добавьте рядом rate(tokens_generated_total[5m]), p95 ITL, queue time и active sequences. Если violation растёт, clock падает и tokens/s деградирует при стабильном batch profile, связь сильнее. Если clock падает без violations, ищите applications clocks, sync group, idle transitions или ограничения самой workload.

Обязательно испытайте запросы на reset. Перезапустите exporter на canary-node и убедитесь, что increase() не создаёт гигантский spike. Затем устройте scrape gap и проверьте алерт missing target. Production PromQL должен переживать обслуживание наблюдаемости так же спокойно, как обычную смену нагрузки.

Как снять baseline и провести честный тест

Baseline строится не из «обычного рабочего дня», а из воспроизводимого сценария. Зафиксируйте модель и её ревизию, inference engine, квантизацию, длины prompt/output, concurrency, scheduler flags, batch policy и время прогрева. Запишите температуру помещения и размещение сервера. Иначе различие легко объяснить не power cap, а новым распределением запросов.

Прогоните несколько ступеней нагрузки: низкую, ожидаемую и близкую к пику. Для каждой сохраните TTFT, ITL, tokens/s, GPU utilization, SM clock, power usage, temperature и violation deltas. Не публикуйте универсальные числа: результат относится только к конкретной карте, шасси, охлаждению и версии ПО.

Полезен контролируемый power-cap experiment, но только в тестовом пуле и после сверки допустимых min/max устройства. Меняйте один параметр, возвращайте его к исходному значению и давайте системе стабилизироваться. Цель — найти форму зависимости latency, throughput и joules/token, а не «доказать», что максимальный лимит всегда быстрее.

Проверяли ли вы разницу между первым холодным прогоном и установившимся тепловым режимом? Десятиминутный тест может выглядеть здоровым, а через час карта выйдет на иной clock. Baseline должен длиться достаточно, чтобы температура шасси стабилизировалась, и включать повторяемость, а не единственную удачную выборку.

Алерты: отделяем симптом от причины

Не пейджите по одной высокой температуре. Порог зависит от модели и airflow, а близость к нему ещё не равна деградации. Причинный alert требует устойчивого прироста violation и, желательно, подтверждения влияния на clock или SLO. Warning может опираться на hardware-признак, critical — на hardware плюс пользовательский эффект.

groups:
  - name: gpu-throttling
    rules:
      - alert: GpuPowerCappingSustained
        expr: increase(DCGM_FI_DEV_POWER_VIOLATION[10m]) > 120e6
        for: 10m
        labels:
          severity: warning
      - alert: GpuThermalThrottling
        expr: increase(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 30e6
        for: 5m
        labels:
          severity: critical
      - alert: DcgmExporterMissing
        expr: up{job="dcgm-exporter"} == 0
        for: 5m
        labels:
          severity: warning

Числа — стартовая гипотеза, не стандарт. На batch-пуле power capping может быть нормальной политикой эффективности; на latency-sensitive endpoint тот же режим нарушит SLO. Порог должен отражать риск для пользователя и подтверждаться baseline.

В annotations добавьте node, UUID, модель GPU и ссылку на runbook. Не помещайте в labels текущие temperature, power или clock: постоянно меняющиеся значения создадут новые alert instances. Thermal critical направляйте on-call инфраструктуры, sustained power cap без SLO impact — в очередь capacity/performance.

Связываем GPU с TTFT, ITL и стоимостью токена

DCGM сообщает, что карта ограничена, но не знает, заметил ли это клиент. Для LLM нужны TTFT, ITL, tokens/s, queue time, batch size и active sequences. Сопоставляйте по node и времени. Протаскивать request_id в GPU metrics нельзя: cardinality взорвётся, а честной связи при continuous batching всё равно не получится.

Диагностическая матрица проста. Queue time растёт, частота и violations стабильны — смотрите admission control и capacity. ITL ухудшается вместе с падением clock и ростом power violation — проверяйте power policy и профиль kernel. Thermal violation растёт на одной позиции стойки — подключайте datacenter operations и анализируйте airflow.

Экономика тоже меняется. Сервер может потреблять меньше ватт под cap, но выдавать непропорционально меньше токенов; тогда joules/token ухудшается. Может быть обратное: умеренный cap немного снижает throughput, зато повышает эффективность и позволяет разместить больше GPU в power budget. Считайте на workload, а не по паспортному TDP. Методика связана с разбором стоимости LLM-запроса.

Не сравнивайте разные модели или квантизации без фиксации условий. Batch size, контекст и speculative decoding способны изменить power draw сильнее, чем лимит. Для каждого эксперимента фиксируйте версии, dataset, concurrency, warm-up, окружающую температуру и длительность.

Runbook после срабатывания

Первое действие — не менять power limit, а подтвердить событие независимым источником. Снимите clocks, temperature, power draw, enforced limit и clock event reasons через nvidia-smi. Сохраните время, UUID и node, затем сравните с DCGM и application SLO.

nvidia-smi --query-gpu=timestamp,uuid,name,temperature.gpu,power.draw,power.limit,clocks.sm,utilization.gpu,pstate --format=csv
nvidia-smi -q -d PERFORMANCE,POWER,TEMPERATURE,CLOCK
curl --fail --silent http://127.0.0.1:9400/metrics \
  | grep -E 'DCGM_FI_DEV_(GPU_TEMP|POWER_USAGE|SM_CLOCK|POWER_VIOLATION|THERMAL_VIOLATION)'

При thermal slowdown идите от общего к частному: холодный коридор, давление и заглушки, обороты и ошибки вентиляторов, фильтры, радиаторы, соседние карты. Не открывайте крышку как «быстрый тест»: это меняет рассчитанный airflow и иногда ухудшает охлаждение пассивных GPU.

При power cap выясните, задан ли лимит политикой. Сопоставьте requested и enforced limit, проверьте питание шасси и события BMC. nvidia-smi -pl требует root и поддерживается не везде; значение должно лежать между min/max устройства. Меняйте его только через change process после проверки power budget сервера и стойки.

Если виден external power brake или XID, не маскируйте симптом повышением порога. Выведите node из latency-sensitive пула, сохраните diagnostics, проверьте PSU, кабели, riser и firmware. DCGM diagnostics запускайте в согласованное окно: нагрузочный тест способен повлиять на рабочий сервис.

Безопасный rollout и вывод

Разверните collector на canary-node. Проверьте поддержку полей, units, labels, reset behaviour и cardinality. Затем добавьте recording rules без alert routing и соберите baseline по разным часам, профилям batch и температуре помещения. Только после этого включайте warning и проверяйте доставку контролируемым событием.

Свяжите alert с владельцем и runbook. У каждого сигнала должны быть ответы: кто реагирует, что безопасно сделать сразу и когда вывести node из пула. В Kubernetes предусмотрите cordon/drain либо scheduling label, но учитывайте disruption budget и запас остальных GPU: аварийный drain не должен превратить локальную деградацию в общий overload.

Постоянный power cap в часы пик может быть не инцидентом, а неверным балансом power density, cooling и SLA. Здесь полезен материал про power density AI-серверов: решение часто лежит в размещении и инженерной инфраструктуре, а не во флаге inference engine.

Главный вывод: utilization без частоты и причин ограничения не показывает реальную производительность. DCGM Exporter даёт аппаратные факты, Prometheus — время и корреляцию, метрики inference — пользовательский контекст. Начните с canary, снимите baseline и прогоните контролируемый тест. Тогда мониторинг станет инструментом сохранения latency, throughput и предсказуемой стоимости LLM-сервиса.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Какую проблему решает fs-verity, а какую — нет

Узел inference может быть технически здоров: GPU видны, сервис отвечает на health-check, latency не выросла. Но если файл весов на локальном NVMe заменён после загрузки, приложение способно без шума поднять не ту модель. Причиной бывает не только атака. Ошибочный sync, повреждение блока, ручная команда в неправильном каталоге или гонка при rollout дают тот же неприятный результат: имя ревизии в конфигурации одно, фактические байты — другие.

Именно здесь полезен fs-verity — механизм ядра Linux для прозрачной проверки содержимого неизменяемого отдельного файла. После включения ядро связывает файл с деревом Меркла, запрещает запись и проверяет прочитанные страницы. Если данные не сходятся с деревом, чтение завершается ошибкой EIO, а доступ через mmap() может привести к SIGBUS. Для больших shard-файлов это важное отличие от одноразового sha256sum: защита продолжает работать при последующих чтениях.

Граница материала узкая и практическая. Мы не повторяем общий процесс версионирования из статьи про LLMOps и не ускоряем загрузку, как в руководствах про FS-Cache или OCI-кэш весов на NVMe. Здесь задача одна: сделать идентичность локального model artifact проверяемым условием запуска.

При этом fs-verity не является доверенным источником сам по себе. Digest нужно сравнить с manifest, который хранится отдельно и защищён лучше каталога модели. Механизм не измеряет владельца, mode bits, timestamps и xattrs; файл можно переименовать, удалить или заменить другим inode. Если злоумышленник контролирует kernel или одновременно меняет файл и доверенный manifest, этот слой уже не спасает. Поэтому дальше будут два gate: инфраструктурный и прикладной.

Как fs-verity проверяет гигабайтные shard-файлы

При fsverity enable файловая система строит скрытое дерево Меркла. Листья соответствуют блокам данных, следующий уровень хранит их хеши, а верхний корень входит в fs-verity digest вместе с размером файла и параметрами алгоритма. В результате digest однозначно описывает содержимое и структуру файла, а получить его через fsverity measure можно без полного перечитывания многогигабайтного shard.

Проверка выполняется не «по расписанию», а на пути чтения. Когда loader или mmap() затягивает страницу весов в page cache, ядро проверяет нужную ветвь дерева до доверенного корня. Уже проверенная страница может отдаваться из page cache, а после повторного чтения с диска верификация выполняется снова. Документация ядра подчёркивает, что direct I/O для verity-файлов не поддерживается и откатывается к buffered I/O, а DAX исключён, потому что обходил бы проверку.

Есть два уровня доверия. Первый — integrity: случайная порча обнаруживается, потому что данные не соответствуют сохранённому дереву. Второй — authenticity: оператор убеждается, что сам digest разрешён. Для production-пайплайна проще всего держать подписанный manifest вне writable model volume и сравнивать измеренный digest до старта сервиса. Встроенные PKCS#7-подписи и keyring .fs-verity доступны, но документация fsverity-utils называет их специализированным механизмом, который требует осторожного проектирования trusted userspace.

Infrastructure gate: kernel, файловая система и отдельный staging

Начните с фактов, а не с установки пакета. В ядре должна быть включена опция CONFIG_FS_VERITY, а файловая система — реально поддерживать механизм. По актуальной документации ядра это ext4, f2fs и btrfs; ext4 поддерживает fs-verity с Linux 5.4, btrfs — с 5.15. Для ext4 у файловой системы должен быть feature flag verity. Его можно задать при форматировании или включить через tune2fs -O verity, но последняя операция меняет совместимость тома со старыми kernels и e2fsck, поэтому её нельзя превращать в бездумный copy-paste для production.

Практичный layout разделяет три зоны: download cache, writable staging и immutable revisions. Hub-кэш удобен для сети, но symlink-структура и shared blobs плохо подходят на роль конечного доверенного каталога. Скачивайте pinned commit в staging, проверяйте полноту, копируйте нужные файлы в новый каталог ревизии на fs-verity-capable volume и только затем включайте verity. Каталог current должен быть атомарной ссылкой на уже подготовленную ревизию, а не местом, куда downloader пишет поверх работающей модели.

Проверяли ли вы реальную файловую систему под model path? В контейнере путь может выглядеть локальным, но быть overlayfs или сетевым mount. Gate нужно выполнять на host path, где лежат байты, а затем проверять тот же inode из launch context сервиса.

set -euo pipefail
MODEL_ROOT=/srv/models
findmnt -no SOURCE,FSTYPE,OPTIONS "$MODEL_ROOT"
grep -E 'CONFIG_FS_VERITY=(y|m)' /boot/config-$(uname -r)
sudo tune2fs -l "$(findmnt -no SOURCE "$MODEL_ROOT")" | grep 'Filesystem features'
fsverity --version
touch "$MODEL_ROOT/.verity-probe"
fsverity enable "$MODEL_ROOT/.verity-probe"
fsverity measure "$MODEL_ROOT/.verity-probe"

Probe-файл доказывает больше, чем наличие бинарника: ioctl дошёл до нужной файловой системы, дерево построено, digest измеряется. После теста файл можно удалить; снять verity с inode нельзя. Если probe не проходит, не расширяйте привилегии контейнера наугад — сначала локализуйте слой: kernel config, filesystem feature, mount type или путь.

Загрузка модели: pinned revision вместо плавающего latest

fs-verity честно защищает любые байты, даже не те, которые вы собирались развернуть. Поэтому идентичность начинается до enable. В Hugging Face Hub параметр revision принимает branch, tag или commit hash, но для воспроизводимого rollout нужен commit hash. В официальной документации commit рассматривается как immutable revision, а snapshot_download() умеет фильтровать файлы через allow_patterns и сигнализировать о неполном offline snapshot.

Для Safetensors это особенно удобно: формат не использует произвольное выполнение pickle-кода при обычной загрузке и рассчитан на безопасное хранение tensor data. Но «безопасный формат» не означает «доверенная модель». Конфигурация, tokenizer, custom code и сами tensor values всё равно должны приходить из разрешённой ревизии. Не включайте trust_remote_code=True без отдельного review и pinning кода.

from huggingface_hub import snapshot_download

path = snapshot_download(
    repo_id="ORG/MODEL",
    revision="FULL_COMMIT_SHA",
    local_dir="/srv/models/staging/FULL_COMMIT_SHA",
    allow_patterns=["*.safetensors", "*.json", "tokenizer*"],
)
print(path)

После скачивания проверьте, что staging содержит ожидаемые shards, index JSON ссылается только на существующие файлы, а свободного места хватает и для новой ревизии, и для предыдущей. Это ваш storage budget: минимум две полные рабочие ревизии плюс временный staging. Не называйте конкретный коэффициент универсальным — sharding и auxiliary files у моделей различаются.

Скопируйте файлы в новый каталог через временное имя на том же filesystem, выполните sync, затем атомарно переименуйте каталог. Только после этого начинайте строить verity metadata. Если downloader пишет напрямую в каталог, где уже включён fs-verity, первая же попытка обновить shard закономерно получит EPERM; это защита, а не поломка.

Включение fs-verity и доверенный manifest

Операция fsverity enable необратима для inode. Сначала убедитесь, что файл закрыт на запись и больше не будет меняться. Для LLM-репозитория защищайте не только *.safetensors, но и конфигурацию, tokenizer и index JSON, если именно эти файлы определяют поведение loader. Символические ссылки измерять бессмысленно: включайте verity на конечных regular files.

set -euo pipefail
REV=/srv/models/revisions/FULL_COMMIT_SHA
MANIFEST=/srv/model-manifests/FULL_COMMIT_SHA.fsverity

: > "$MANIFEST.tmp"
find "$REV" -type f -print0 | sort -z | while IFS= read -r -d '' file; do
  fsverity enable "$file"
  digest=$(fsverity measure "$file" | awk '{print $1}')
  rel=$(realpath --relative-to="$REV" "$file")
  printf '%s  %s\n' "$digest" "$rel" >> "$MANIFEST.tmp"
done
chmod 0444 "$MANIFEST.tmp"
mv "$MANIFEST.tmp" "$MANIFEST"

Manifest храните вне model volume и доставляйте через отдельный доверенный канал: signed release artifact, конфигурационный репозиторий с review или secret/config mechanism с жёсткими правами. Обычный root-owned файл на том же writable диске защищает от случайностей, но не создаёт сильной границы против root-компрометации.

Не путайте fs-verity digest с обычным SHA-256 файла. Digest включает descriptor и корень дерева Меркла; сравнивать нужно вывод fsverity measure с таким же типом digest из manifest. Хорошая проверка также убеждается, что набор файлов совпадает полностью: отсутствие ожидаемого файла и появление лишнего должны завершать gate ошибкой.

Для больших моделей стоимость построения дерева платится один раз при подготовке revision. Скрытая metadata занимает дополнительное место; документация ядра оценивает дерево для больших файлов примерно как небольшую долю от исходного размера, но планировать storage лучше по фактическому du на своих shards, а не по чужой цифре.

Service gate: не запускать inference с неизвестными байтами

Теперь нужен trusted userspace, который свяжет path, revision и digest. Минимальный verifier читает manifest, убеждается, что каждый путь остаётся внутри revision directory, вызывает fsverity measure, сравнивает digest и завершается ненулевым кодом при первом расхождении. Важно проверять effective path из того же namespace, в котором стартует inference service: host-скрипт, проверяющий один каталог, не должен запускать контейнер с другим bind mount.

#!/usr/bin/env bash
set -euo pipefail
REV=${1:?revision directory}
MANIFEST=${2:?trusted manifest}

while read -r expected rel; do
  file=$(realpath -e "$REV/$rel")
  case "$file" in "$REV"/*) ;; *) echo "path escape: $rel" >&2; exit 20;; esac
  actual=$(fsverity measure "$file" | awk '{print $1}')
  test "$actual" = "$expected" || {
    echo "digest mismatch: $rel" >&2
    exit 21
  }
done < "$MANIFEST"

echo "fs-verity gate passed"

[Unit]
Description=LLM inference with fs-verity gate
After=local-fs.target network-online.target

[Service]
Type=simple
User=llm
Group=llm
ExecStartPre=/usr/local/libexec/verify-model-verity.sh /srv/models/current /srv/model-manifests/current.fsverity
ExecStart=/usr/local/bin/llm-server --model /srv/models/current
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Если ExecStartPre завершается ошибкой, основной процесс не стартует. Это failure-visible readiness: балансировщик не должен видеть endpoint, а alert должен содержать revision и имя первого конфликтного файла, но не секреты и не полный внутренний manifest. Не ставьте перед командой префикс, игнорирующий exit code, иначе gate станет декоративным.

Положительный тест: разрешённая ревизия проходит verifier, сервис стартует и сообщает ожидаемый model identifier. Отрицательный тест: соседняя, корректная, но неразрешённая ревизия должна быть отвергнута из-за другого digest. Такая проверка безопаснее эксперимента с raw block corruption на production-диске.

Application gate: доказать, что загружена именно эта модель

Infrastructure gate отвечает: «файлы имеют разрешённые digest и будут проверяться при чтении». Он не отвечает: «сервер загрузил все shards, использовал нужный tokenizer и готов обслуживать запросы». Для этого нужен отдельный application gate.

После старта зафиксируйте pinned identity в метриках: repository, полный commit, manifest digest и software image digest. Затем выполните короткий smoke test, который заставляет loader прочитать модель и выдаёт детерминированно проверяемый признак готовности. Это не benchmark качества и не обещание одинаковых токенов между разными kernels; достаточно проверить успешную загрузку, ожидаемый model ID, отсутствие read errors и базовый inference response.

Отрицательная граница обязательна. Подмените ссылку current на подготовленную, но отсутствующую в доверенном manifest ревизию на тестовом узле. Service gate должен остановить запуск до инициализации GPU. Затем верните разрешённую ссылку и убедитесь, что readiness восстановилась. Такой контрфактический тест доказывает причинность: сервис разрешает не «любой читаемый каталог», а только утверждённую identity.

Наконец, читайте весь набор shards во время canary или запускайте реальную загрузку модели. fsverity measure подтверждает закреплённый digest, но ошибки повреждённых data blocks проявляются именно при чтении. Для mmap-loader это может быть SIGBUS, поэтому supervisor и alerting должны отличать integrity incident от обычного OOM.

set -euo pipefail
sudo systemctl stop llm-inference
sudo ln -sfn /srv/models/revisions/UNAPPROVED_SHA /srv/models/current
if sudo systemctl start llm-inference; then
  echo "ERROR: unapproved revision started" >&2
  exit 1
fi
sudo ln -sfn /srv/models/revisions/APPROVED_SHA /srv/models/current
sudo systemctl start llm-inference
systemctl is-active --quiet llm-inference

Rollout без перезаписи: canary, promotion и быстрый rollback

Не обновляйте защищённую ревизию на месте. Правильная единица изменения — новый каталог с новым commit и manifest. Pipeline выглядит так: download в staging, проверка полноты, перенос на целевой filesystem, fsverity enable, сохранение digest manifest, canary load, application tests и только потом promotion ссылки current.

Canary должен читать модель с того же типа диска и тем же runtime, что production. Если он проходит, раскатывайте revision по узлам постепенно, сохраняя предыдущий каталог. Смена symlink атомарна, но уже работающий процесс может держать открытые inode старой ревизии; это хорошо для стабильности, однако нужно явно перезапустить или дренировать процесс, чтобы новая identity действительно вступила в силу.

Storage budget здесь важнее красоты pipeline. Держите рабочую, предыдущую и staging revision, пока rollout не завершён. Если места не хватает, сборщик может удалить rollback target в самый неподходящий момент. Политику garbage collection связывайте не с возрастом каталога, а с фактом, что ни один process не держит inode, revision не является current/previous и rollout закрыт.

С fs-verity rollback прост: ссылка возвращается на уже защищённый неизменяемый каталог, verifier проверяет старый manifest, после чего сервис снова проходит application gate. Не нужно переписывать гигабайты поверх текущего файла — и именно это сокращает время восстановления.

Что делать при EIO, SIGBUS или digest mismatch

Integrity incident не лечится повторным запуском в цикле. Первый шаг — убрать узел из балансировки и сохранить evidence: revision, manifest digest, kernel version, filesystem, сообщения kernel log, exit status и имя файла. Не пытайтесь «починить» verity-file через chmod или запись поверх: inode неизменяем по дизайну.

Разделите симптомы. digest mismatch до старта чаще означает замену path/inode, неверный manifest или rollout не той ревизии. EIO во время read() и SIGBUS у mmap-loader указывают, что прочитанный блок не совпал с деревом. EPERM при записи обычно означает, что downloader попал в immutable каталог. Один и тот же алерт «модель не стартует» скрывает три совершенно разных runbook.

Восстановление выполняйте новым inode. Загрузите тот же pinned commit в чистый staging, снова проверьте upstream identity, перенесите файлы, включите fs-verity и сравните digest с доверенным manifest. Если digest совпал, замените ссылку и прогоните оба gate. Если не совпал, не «обновляйте manifest под фактические байты» — это уничтожает смысл контроля. Эскалируйте проблему к источнику артефакта или pipeline.

Проверьте соседний слой. Ошибка могла возникнуть из-за NVMe media error, памяти, filesystem corruption или ошибочной автоматизации. Посмотрите SMART/NVMe health и kernel logs, но не объявляйте диск виновным только по одному EIO. И наоборот, успешный rollback не закрывает incident: он возвращает сервис, а root cause analysis отвечает, почему байты изменились.

Ограничения и соседние механизмы защиты

fs-verity не шифрует модель и не ограничивает чтение. Для конфиденциальности нужны права доступа, изоляция workload, encryption at rest и контроль выгрузки данных. Общую threat model полезно сверить со статьёй о безопасности AI-систем. Safetensors уменьшает риск небезопасной десериализации, но не заменяет контроль происхождения и digest.

Механизм также не стабилизирует производительность. Первое чтение по-прежнему зависит от NVMe, page cache и соседней нагрузки. Если integrity rollout совпал с I/O storm, разделяйте безопасность и resource control: рекомендации по cgroup v2 и systemd собраны в материале про I/O-изоляцию LLM-узла. Сначала докажите, что gate разрешил нужные байты, затем отдельно измеряйте model load time и latency.

Для read-only образа целого узла лучше подходит dm-verity. Для системной политики исполнения можно рассмотреть IMA appraisal или IPE; документация ядра IPE умеет использовать свойства fsverity_digest и fsverity_signature, но это уже kernel-enforced policy с отдельной моделью развертывания. Для обычного inference service trusted manifest и строгий pre-start verifier часто дают более понятный первый шаг.

Наконец, не включайте глобальный fs.verity.require_signatures=1 без инвентаризации. Он требует корректно подписанных verity-файлов и доверенных сертификатов в keyring. Ошибка в boot-time key provisioning способна остановить все consumers. Начните с userspace gate, протестируйте rotation ключей и только потом решайте, нужна ли встроенная signature enforcement.

Практический итог

fs-verity полезен не потому, что добавляет ещё один hash в pipeline. Он превращает весовые файлы в неизменяемые объекты, проверяемые ядром при чтении, и даёт быстрый digest для identity gate. Но настоящая защита появляется только в связке: pinned upstream revision, отдельный staging, доверенный manifest, pre-start verifier, application smoke test и rollback на заранее подготовленный inode.

Начните с одного canary-узла и одного model revision. Подтвердите поддержку filesystem probe-файлом, защитите все shards и конфигурацию, проверьте отрицательный сценарий с неразрешённой ревизией, затем измерьте полную загрузку. Когда оба gate устойчиво проходят, переносите схему на остальные GPU-серверы и добавляйте alerts для mismatch, EIO и SIGBUS.

Так вы получите не абстрактную «защиту модели», а конкретное эксплуатационное свойство: inference либо запускается с утверждёнными байтами, либо останавливается до приёма трафика. Для production это куда ценнее тихой надежды, что каталог на NVMe никто не трогал.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда лимит памяти маскируется под проблему GPU

Сервис LLM запускается без ошибок, GPU виден, модель помещается в видеопамять — но первый запрос после рестарта идёт рывками, CPU загружен копированием, а режим offload внезапно становится медленнее. Типичная реакция — искать неисправность в CUDA, PCIe или драйвере. Однако причина нередко находится выше: процесс не может закрепить нужный объём host RAM, потому что его RLIMIT_MEMLOCK остался на маленьком значении.

Pinned, или page-locked, memory — это страницы оперативной памяти, которые ядро не может выгрузить или переместить обычным способом. CUDA использует такой буфер для предсказуемых DMA-передач и асинхронного копирования между CPU и GPU. Официальная CUDA Programming Guide прямо указывает: page-locked память нужна для asynchronous copies, а cudaHostRegister() позволяет закрепить уже выделенный диапазон.

Но сама возможность pinning ещё не доказывает, что приложение стало быстрее. В проде нужны два независимых ответа. Infrastructure gate подтверждает лимит, права и реальный объём locked memory. Application gate показывает, что изменились полезные метрики: время холодного старта, TTFT, p95 или скорость offload-пути. Если второй ответ отрицательный, открывать memlock дальше бессмысленно: узкое место уже в storage, NUMA, PCIe, CPU preprocessing или очереди запросов.

Материал посвящён именно этой границе. Он не заменяет диагностику NVIDIA Xid и не обещает универсального ускорения. Задача практичнее: сделать pinned memory измеряемым ресурсом, задать конечный бюджет в Docker или systemd и получить воспроизводимый rollback.

Что меняет pinned memory — и чего она не исправляет

Обычная pageable memory удобна ядру: страницы можно перемещать и при необходимости отправлять в swap. Для передачи на дискретный GPU драйверу часто нужен промежуточный закреплённый буфер. В результате логический путь «тензор из RAM в GPU» может включать дополнительное копирование и синхронизацию. Pinned memory убирает эту неопределённость: физические страницы остаются на месте, и устройство может использовать стабильный DMA-адрес.

Это особенно важно, когда приложение хочет перекрыть копирование вычислением через cudaMemcpyAsync(). В CUDA Best Practices Guide NVIDIA связывает асинхронные transfers с page-locked host memory, но одновременно предупреждает: pinning — тяжёлая операция, а чрезмерный объём закреплённых страниц способен ухудшить работу всей системы. Поэтому «unlimited» не является тюнингом. Это отказ от бюджетирования дефицитного ресурса.

Представьте сервер с несколькими inference-worker. Один закрепляет весовые буферы, второй — CPU KV cache, третий готовит мультимодальные входы. Каждый по отдельности выглядит разумно, но вместе они отнимают у ядра свободу reclaim. При всплеске file cache или sidecar-нагрузки возникает memory pressure, хотя free ещё показывает доступную RAM. Проверяли ли вы, сколько страниц реально находится в VmLck, а не сколько памяти процесс просто зарезервировал?

Pinned memory не ускоряет GPU kernels, не исправляет медленный NVMe и не увеличивает пропускную способность PCIe. Она улучшает конкретный участок host↔device transfer. Если модель целиком живёт в VRAM после старта и запросы почти не двигают данные через CPU, прирост может оказаться незаметным. Поэтому сначала формулируйте гипотезу: какой буфер закрепляется, в какой фазе он копируется и какая прикладная метрика должна отреагировать.

Baseline: увидеть лимит, права и реально locked страницы

Начните до изменения unit-файлов и контейнерных параметров. Снимите soft и hard limit из того же окружения, где работает inference-процесс. Значение в вашей SSH-сессии не доказывает значение внутри Docker, Podman или systemd service: каждый launcher может установить собственный rlimit. Linux определяет RLIMIT_MEMLOCK как максимальное число байтов, которое непривилегированный процесс может закрепить в RAM; лимит округляется по размеру страницы. Это поведение описано в актуальной странице getrlimit(2).

Следующий набор команд не меняет систему. Он показывает лимит текущей оболочки, лимит конкретного PID и фактический объём locked pages. Запускайте его на canary-узле под тем же пользователем и через тот же launcher, что и сервис.

set -euo pipefail
ulimit -Sl
ulimit -Hl
grep -i "Max locked memory" /proc/self/limits

pid="$(pgrep -n -f 'vllm|python.*serve')"
grep -E '^(Name|VmRSS|VmLck|VmSwap):' "/proc/$pid/status"
grep -E '^(Rss|Locked|Swap):' "/proc/$pid/smaps_rollup"

systemctl show llm-inference.service   -p LimitMEMLOCK -p LimitMEMLOCKSoft -p MemoryCurrent -p MemoryMax

VmLck отвечает на узкий вопрос: сколько памяти процесс уже закрепил через механизмы семейства mlock. Он не равен RSS, CPU offload budget или размеру модели. Если приложение создаёт несколько worker-процессов, соберите показатель по каждому PID; один master с нулём не исключает десятки гигабайт в дочернем процессе.

Для infrastructure gate нужен ещё контролируемый отрицательный тест. Приложение должно успешно закреплять буфер внутри разрешённого бюджета и предсказуемо получать ошибку при попытке выйти за soft limit. Такой тест обнаруживает опасный случай, когда сервис получил CAP_IPC_LOCK и фактически обходит конечный rlimit. Проверяйте не только «можно», но и «граница действительно работает».

Не делайте вывод по одному cold start: page cache, lazy imports и JIT-компиляция смешиваются с transfer time. Сохраните baseline-конфигурацию, несколько повторов прикладного запроса, kernel/driver version и digest контейнерного образа. Эта дисциплина отличает измерение от удачного совпадения.

import ctypes
import errno
import mmap
import resource
import sys

size = int(sys.argv[1])
soft, hard = resource.getrlimit(resource.RLIMIT_MEMLOCK)
print({"requested": size, "soft": soft, "hard": hard})

buf = mmap.mmap(-1, size)
address = ctypes.addressof(ctypes.c_char.from_buffer(buf))
libc = ctypes.CDLL(None, use_errno=True)

rc = libc.mlock(ctypes.c_void_p(address), ctypes.c_size_t(size))
if rc != 0:
    code = ctypes.get_errno()
    raise OSError(code, errno.errorcode.get(code, "mlock failed"))

print("mlock: PASS")
libc.munlock(ctypes.c_void_p(address), ctypes.c_size_t(size))

Docker и Compose: конечный ulimit вместо лишней capability

В Docker параметр памяти контейнера и memlock решают разные задачи. --memory ограничивает общий объём memory cgroup, а --ulimit memlock задаёт process rlimit. Можно иметь большой --memory и всё равно падать на небольшой pinned allocation. Обратная комбинация ещё опаснее: высокий memlock при тесном cgroup-бюджете способен ускорить приближение OOM.

Официальная документация docker container run перечисляет memlock как максимальное locked-in-memory address space. Compose поддерживает soft/hard mapping через services.ulimits. Задавайте конкретное число, полученное из peak VmLck на canary, затем добавляйте небольшой эксплуатационный запас. Не копируйте 8 GiB из примера, если ваш offload буфер равен 40 GiB, и не ставьте unlimited на узле с несколькими арендаторами.

services:
  inference:
    image: registry.example/vllm@sha256:PINNED_DIGEST
    gpus: all
    ulimits:
      memlock:
        soft: 8589934592
        hard: 8589934592
    mem_limit: 48g
    security_opt:
      - no-new-privileges:true
    command:
      - vllm
      - serve
      - /models/current

После docker compose up -d выполните baseline-команды через docker exec. Если внутри по-прежнему виден старый лимит, контейнер мог не быть пересоздан, а только перезапущен. Зафиксируйте docker inspect, digest образа и effective /proc/1/limits. Configuration-as-code без effective-state проверки оставляет неприятную серую зону.

Capability IPC_LOCK даёт право, связанное с memory locking. Но mlock(2) отмечает, что привилегированный процесс с CAP_IPC_LOCK не ограничивается RLIMIT_MEMLOCK так же, как обычный. Поэтому сначала используйте конечный ulimit без capability. Добавляйте capability лишь тогда, когда конкретная библиотека и модель угроз действительно требуют её, и отдельно докажите, что вы не потеряли верхнюю границу.

systemd: закрепить политику в unit и проверить effective state

Для сервиса без контейнера rlimit лучше держать рядом с остальными production-ограничениями. Drop-in переживёт обновление package unit и будет виден в ревью. LimitMEMLOCK= задаёт soft и hard limit для процесса сервиса; если нужны разные значения, systemd допускает пару soft:hard. После изменения обязательны daemon-reload и restart: уже запущенный процесс не наследует новый лимит автоматически.

Размер считайте от фактического пика. Допустим, worker стабильно держит 5,6 GiB locked pages на целевой concurrency, а при reload кратковременно поднимается выше. Вы выбираете finite budget, который покрывает измеренный reload, но не позволяет одному процессу закрепить всю RAM. Это не универсальная формула: на другом backend или после обновления allocator профиль изменится.

[Service]
LimitMEMLOCK=8G
MemoryHigh=44G
MemoryMax=48G
NoNewPrivileges=yes

Затем проверьте сразу три слоя: systemctl show, /proc/$PID/limits и VmLck. Первый подтверждает декларацию manager, второй — наследованный process limit, третий — фактическое потребление. Зелёным infrastructure gate считается только их согласованность плюс успешный probe внутри бюджета.

MemoryHigh и MemoryMax здесь не заменяют memlock. Они задают общую политику cgroup и помогают увидеть конфликт между pinned buffer, RSS, page cache и sidecar-процессами. Именно такой конфликт часто выглядит как «GPU отваливается под нагрузкой», хотя устройство исправно. Для соседних I/O-нагрузок полезно отдельно пройти runbook по cgroup v2 и systemd на LLM-узле.

Rollback должен быть скучным: вернуть прежний drop-in, выполнить reload/restart и повторить baseline. Не оставляйте временный LimitMEMLOCK=infinity после расследования — временные параметры имеют привычку становиться архитектурой.

vLLM offload: где pinned memory становится частью data path

Для LLM inference pinned memory особенно заметна в сценариях, где данные продолжают ходить между host RAM и GPU после загрузки модели. Это weight offload и CPU KV-cache offload. В актуальной документации vLLM код offloader проверяет доступность pinning и использует отдельный override VLLM_WEIGHT_OFFLOADING_DISABLE_PIN_MEMORY; на unified-memory системах вроде GH200 pinning может расходовать общий memory budget иначе, поэтому там его можно отключить. Это хороший пример того, почему один рецепт не переносится на любую архитектуру.

CPU KV offload в текущей ветке vLLM регистрирует mmap-регион через cudaHostRegister, а при недоступном pinning предупреждает о возможном ухудшении производительности. Эти детали видны в официальном API reference для CPU offload worker. Однако offload-код быстро развивается. Закрепляйте версию vLLM и container digest, сверяйте flags через vllm serve --help именно в вашем образе и маркируйте экспериментальные пути в change record.

Application gate строится вокруг вашего рабочего сценария, а не synthetic copy alone. Для weight offload измеряйте cold start, TTFT первого запроса и steady-state p95. Для KV offload добавьте длинный контекст и concurrency, при которых CPU cache действительно используется. Параллельно снимайте VmLck, PCIe traffic, CPU utilization и memory pressure. Если pinned allocation проходит, но TTFT не улучшается, infrastructure gate уже не главный подозреваемый.

Сравнение должно включать отрицательный контроль: тот же image и model revision, но offload отключён либо pinning выключен документированным override. Возврат прикладной метрики к baseline подтверждает причинность. Если метрика не возвращается, вы, вероятно, измерили page cache, JIT или прогрев tokenizer, а не pinned data path.

Application gate: проверить PyTorch transfer и сам inference

Низкоуровневый mlock probe доказывает политику Linux, но не интеграцию CUDA allocator. Второй тест должен использовать тот же framework, что и сервис. В PyTorch можно выделить pinned tensor и выполнить non-blocking copy. Официальный PyTorch tutorial предупреждает о важной ловушке: ручной вызов pin_memory() в основном Python-потоке сам блокирует host и иногда делает путь медленнее. Значит, цель smoke test — корректность allocation и async API, а не обещание ускорения.

import os
import resource
import torch

size_mib = int(os.environ.get("PIN_TEST_MIB", "256"))
soft, hard = resource.getrlimit(resource.RLIMIT_MEMLOCK)
print({"memlock_soft": soft, "memlock_hard": hard, "test_mib": size_mib})

host = torch.empty(size_mib * 1024 * 1024, dtype=torch.uint8, pin_memory=True)
assert host.is_pinned()

device = host.to("cuda", non_blocking=True)
torch.cuda.synchronize()
print({"pinned": host.is_pinned(), "device": str(device.device), "status": "PASS"})

Запустите probe внутри production-контейнера до старта сервера или в отдельном canary с тем же runtime. Затем увеличьте PIN_TEST_MIB немного выше finite soft limit и убедитесь, что отрицательный тест действительно падает. Не запускайте заведомо огромный allocation на общем узле: границу можно проверить контролируемо, не создавая memory incident.

Третий уровень — сам inference. Сохраните одинаковые model files и tokenizer, сбросьте только те кэши, которые входят в сценарий, и повторите серию запросов. Не публикуйте универсальные проценты ускорения: результат зависит от PCIe topology, NUMA-locality, формата weights и доли transfers в критическом пути. Полезнее записать decision: при каком offload budget p95 улучшился, сколько VmLck это стоило и какой запас остался до MemoryHigh.

Если холодный старт определяется доставкой весов с registry, memlock начнёт влиять слишком поздно. Тогда сначала оптимизируйте model distribution и локальный NVMe-кэш; практический контекст есть в статье про OCI-артефакты и кэш весов LLM на NVMe. Это пример миграции bottleneck: после улучшения storage pinned transfer может стать заметен, но до него — нет.

Наблюдаемость: связать VmLck с latency и memory pressure

Один график locked memory мало что объясняет. Соберите три ряда. На process layer нужны VmLck, RSS, swap и restart count. На cgroup/host layer — memory.current, memory.events, PSI memory и доступная RAM. На application layer — cold-start duration, TTFT, p50/p95, очередь и ошибки allocation. Только совпадение временных рядов показывает, помогает ли pinning или просто забирает reclaimable memory.

Практический алерт лучше строить не на абсолютном «VmLck больше X», а на отношении к утверждённому budget и соседних симптомах. Например: locked pages приблизились к finite limit, в логах появились allocation failures, а TTFT вырос. Отдельный сигнал нужен для противоположной ситуации: VmLck стабилен, но memory PSI и memory.events растут. Тогда увеличение memlock ухудшит ситуацию.

В multi-worker архитектуре экспортируйте PID labels осторожно: они меняются после restart. Стабильнее собирать показатель по cgroup сервиса или агрегировать процессы по unit/container identity. При canary rollout сохраните конфигурационный fingerprint: image digest, CUDA driver, vLLM version, memlock soft/hard и offload flags. Без него сравнение через неделю превращается в археологию.

Не смешивайте locked host memory с GPU framebuffer metrics. DCGM и nvidia-smi покажут VRAM и состояние GPU, но не заменят /proc/$PID/status. Аналогично, высокий GPU utilization не доказывает, что data path оптимален: очередь может держать ускоритель занятым при плохом TTFT.

Rollout: два gate, canary и контрфактическая проверка

Начинайте с одного worker на одном GPU-узле. Зафиксируйте baseline при текущем memlock, затем установите finite limit, достаточный для измеренного буфера. Infrastructure gate: effective soft/hard совпадают с декларацией, positive probe проходит, negative probe выше границы падает, VmLck не превышает бюджет. Application gate: на той же модели и нагрузке улучшилась заранее выбранная метрика без роста ошибок и memory pressure.

После этого нужен counterfactual. Верните прежний memlock или отключите offload/pinning на том же canary и проверьте возврат метрики к baseline. Такой шаг кажется лишним, пока не выясняется, что одновременно прогрелся page cache или завершилась JIT-компиляция. Контрфактическая проверка защищает от ложной причинности.

Расширяйте rollout постепенно: один worker, затем один узел, затем небольшая доля пула. На каждом шаге проверяйте, не переехал ли bottleneck. Более быстрый CPU→GPU transfer может поднять нагрузку на NVMe, CPU allocator или frontend queue. Локально улучшив один счётчик, легко ухудшить end-to-end p95.

Rollback — отключение нового offload режима или возврат предыдущего finite limit и image digest. Он не должен требовать выдачи новых capabilities или ручной правки внутри контейнера. Для rootless GPU-контейнеров держите device access отдельно от memory policy; материал про NVIDIA CDI и rootless inference показывает, как не смешивать эти границы.

Типичные ошибки: unlimited, один benchmark и неверный слой

Первая ошибка — поставить memlock=-1 или LimitMEMLOCK=infinity, увидеть исчезновение ошибки и объявить проблему решённой. На dedicated single-tenant узле это может пройти незаметно, но в общем пуле один worker получает возможность закрепить слишком много RAM. Диагностический эксперимент допустим только на изолированном canary и должен закончиться конечным бюджетом.

Вторая ошибка — одновременно добавить IPC_LOCK, поднять ulimit, увеличить --memory и обновить vLLM. Если сервис ожил, вы не знаете почему. Меняйте один слой за раз, сохраняйте effective state и повторяйте отрицательный тест. Capability не является синонимом производительности; это изменение privilege boundary.

Третья ошибка — считать размер модели memlock-бюджетом. Весовые shards могут находиться в VRAM, pageable RAM, mmap, page cache или pinned region; KV cache живёт по другой схеме. Истина — peak VmLck конкретной версии приложения под целевым workload. Добавляйте запас на reload и allocator fragmentation только после наблюдения, не по магическому проценту.

Четвёртая ошибка — benchmark только на synthetic tensor. Он полезен для smoke test DMA-пути, но не включает tokenizer, scheduler, batching, storage и queueing. Финальное решение принимается по application gate. Проверяли ли вы длинный контекст, параллельные запросы и cold restart, или только один тёплый prompt?

Пятая ошибка — забыть об архитектуре памяти. На unified-memory платформе pinning может иметь другой trade-off; vLLM прямо предусматривает возможность его отключения для weight offload. На multi-socket сервере remote NUMA allocation способна съесть выгоду от pinning. Поэтому version lock, topology check и canary важнее универсальной строки конфигурации.

Итог: memlock — это бюджет, а не переключатель скорости

Pinned memory помогает там, где LLM inference действительно переносит заметные объёмы между host RAM и GPU: при weight offload, CPU KV-cache offload и асинхронных staging-пайплайнах. Но полезный эффект появляется не от большого числа в ulimit, а от совпадения четырёх условий: приложение использует page-locked buffers, процесс имеет достаточный конечный лимит, узел сохраняет запас обычной RAM, а прикладная метрика реагирует на изменение.

Надёжный runbook коротко выглядит так: снимите baseline из реального launcher, докажите границу через positive/negative probe, задайте finite memlock в Docker или systemd, проверьте VmLck вместе с cgroup pressure и выполните canary application test. Затем верните настройку назад и убедитесь, что метрика возвращается к baseline. Это превращает «кажется, стало быстрее» в проверяемое инфраструктурное решение.

Начните с одного worker и одной модели. Запишите image digest, версии CUDA/vLLM, offload flags, peak locked memory и выбранную метрику. Если выяснится, что bottleneck лежит в NVMe, NUMA или очереди, это тоже хороший результат: вы остановили бесконечное увеличение привилегий и получили следующий конкретный эксперимент.

Для production LLM важна не максимальная свобода процесса, а управляемая граница. Настройте её на canary, прогоните checklist и только после этого расширяйте rollout на GPU-пул или выделенный сервер.