Сколько производительности отнимает Confidential AI на NVIDIA Blackwell

Что именно мы измеряем

Confidential computing — режим выполнения, в котором данные и код защищаются аппаратно, а состояние среды может проверяться аттестацией. Для GPU-инференса это не одна функция, а цепочка: доверенная CPU-среда, GPU в CC-режиме, защищенные соединения, прошивки, драйвер, виртуализация и политика выдачи ключей.

Поэтому эксперимент должен отвечать не только на вопрос «на сколько процентов стало медленнее», но и на четыре отдельных вопроса:

1. Изменилась ли установившаяся пропускная способность генерации?
2. Изменились ли TTFT и время на выходной токен при одинаковой нагрузке?
3. Увеличилось ли время от старта процесса до готовности модели?
4. Как изменились сетевой трафик и обмен между хостом и GPU?

Дизайн A/B-сравнения

Сравниваются два режима: OFF — обычный инференс и CC — полный confidential-инференс с проверенной аттестацией. Простое включение CC-флага без проверки доверенной среды не считается вариантом CC.

Лучший вариант — две одинаковые ноды из одной аппаратной партии. Если доступна одна нода, выполните серии OFF → CC → OFF и учитывайте перезагрузки, смену GPU-режима и прогрев. Такой эксперимент дольше, зато повторный OFF помогает заметить дрейф температуры, частот или фоновой нагрузки.

Не сравнивайте bare metal OFF с Kata-контейнером CC, а затем не называйте разницу «ценой шифрования GPU». Это цена всей смены среды. Полезны два среза:

• Прикладной: обычная производственная среда против полной защищенной среды.
• Диагностический: максимально одинаковые VM, контейнеры и серверные настройки; меняется только допустимый CC-режим.

Шаг 1. Снимок конфигурации

Следующие команды только читают состояние. Запускайте их внутри той среды, где работает inference-сервер, а сведения о гипервизоре и хосте собирайте отдельно. Сохранение вывода в файлы показано как пример; каталог должен уже существовать и не содержать секретов.

RUN_DIR="/var/tmp/blackwell-bench/off-run-01"

uname -a > "$RUN_DIR/uname.txt"
lscpu > "$RUN_DIR/lscpu.txt"
numactl --hardware > "$RUN_DIR/numa.txt"
nvidia-smi -L > "$RUN_DIR/gpus.txt"
nvidia-smi -q > "$RUN_DIR/nvidia-smi-q.txt"
nvidia-smi topo -m > "$RUN_DIR/topology.txt"
nvidia-smi --query-gpu=name,uuid,driver_version,vbios_version,pstate,power.limit,clocks.sm,clocks.mem,temperature.gpu,memory.total \
  --format=csv,noheader > "$RUN_DIR/gpu-state.csv"

Дополнительно сохраните digest контейнера, commit или версию inference-сервера, его полную командную строку и хеш файла с настройками. Не записывайте токены доступа, ключи расшифрования модели, содержимое аттестационных секретов и пользовательские промпты.

На Blackwell используйте только комбинации GPU, VBIOS, драйвера и CC-режима, указанные в актуальной документации NVIDIA Trusted Computing и матрице совместимости. Режим нельзя считать переменной обычного приложения: его переключение может требовать административных действий и перезапуска. В Kubernetes NVIDIA отдельно предупреждает, что смена режима не останавливает пользовательские workload автоматически.

Шаг 2. Сделайте запросы детерминированными

Подготовьте локальный JSONL-набор без чувствительных данных. Храните уже токенизированные длины или проверяйте их тем же tokenizer: одинаковое число символов не означает одинакового числа токенов.

{"id":"p0001","prompt":"<синтетический текст>","input_tokens":1024,"max_new_tokens":256}
{"id":"p0002","prompt":"<синтетический текст>","input_tokens":1024,"max_new_tokens":256}

Это формат примера, а не готовый тестовый набор. Создайте несколько корзин: короткий и длинный контекст, короткая и длинная генерация. Для каждой корзины испытайте несколько уровней concurrency, включая низкую нагрузку и насыщение GPU.

Если сервер поддерживает deterministic decoding, зафиксируйте temperature, top-p, seed и максимальное число новых токенов. При потоковом API клиент должен измерять время первого полученного фрагмента отдельно от полного времени ответа.

Шаг 3. Разделите холодный старт на этапы

Одного таймера «контейнер запущен — endpoint готов» недостаточно. Размечайте минимум пять событий:

1. T0: запуск VM, pod или процесса;
2. T1: завершение аттестации и разрешение выдачи ключа;
3. T2: начало чтения весов;
4. T3: веса размещены, сервер выполняет инициализацию;
5. T4: readiness успешна и пробный запрос завершен.

Если сервер не экспортирует эти события, используйте монотонные timestamps в его логах. Измерение только wall-clock дает полезный прикладной итог, но не объясняет причину.

START_NS="$(date +%s%N)"
until curl --silent --show-error --fail \
  --connect-timeout 2 --max-time 3 \
  "http://127.0.0.1:8000/health/ready" >/dev/null
do
  sleep 1
done
READY_NS="$(date +%s%N)"
awk -v start="$START_NS" -v ready="$READY_NS" \
  'BEGIN { printf "ready_seconds=%.3f\n", (ready-start)/1000000000 }'

Адрес health endpoint — пример: замените его на документированный endpoint своего сервера. Выполните отдельные серии с весами в page cache и после настоящего холодного старта. Не очищайте системный cache на общей машине: это влияет на другие workload. Для холодного чтения безопаснее использовать выделенную ноду, новый экземпляр VM или управляемый экспериментальный том.

Шаг 4. Измерьте steady-state

После готовности модели отправьте короткий прогрев, который не входит в результат. Затем выполните не менее пяти независимых повторов каждой комбинации длины и concurrency. Порядок комбинаций лучше перемешать, но последовательность должна быть одинаковой в OFF и CC.

Клиент должен сохранять по каждому запросу:

• монотонное время отправки, первого байта и завершения;
• число входных и реально сгенерированных токенов;
• HTTP-статус, timeout и признак отмены;
• число отправленных и полученных байтов;
• идентификатор запуска, режим, корзину и concurrency.

Для единичной проверки HTTP-трафика подходит curl:

curl --silent --show-error --output /dev/null \
  --request POST "http://127.0.0.1:8000/v1/completions" \
  --header "Content-Type: application/json" \
  --data-binary @request.json \
  --write-out \
'http_code=%{http_code}
time_starttransfer=%{time_starttransfer}
time_total=%{time_total}
size_upload=%{size_upload}
size_download=%{size_download}
'

Это диагностический пример, не генератор конкурентной нагрузки. Для основного прогона используйте один и тот же клиент в обоих режимах. Клиент размещайте на отдельной закрепленной машине либо запускайте локально в обоих вариантах. Иначе сетевой RTT и CPU клиента попадут в «цену CC».

Основные показатели рассчитываются так:

• Throughput: сумма успешно сгенерированных токенов, деленная на длительность измерительного окна.
• Throughput/GPU: throughput, деленный на число занятых GPU.
• TTFT: время от отправки до первого элемента потокового ответа.
• TPOT: время после первого токена, деленное на число последующих токенов.
• Goodput: число запросов, уложившихся в заданные SLO, за секунду.

Публикуйте медиану, p95, число успешных запросов и доверительный интервал между повторами. Относительное изменение throughput удобно считать как 100 × (CC / OFF − 1). Для latency используйте 100 × (CC / OFF − 1), но помните: здесь положительное значение означает ухудшение.

Шаг 5. Найдите место замедления

GPU и сервер

Во время каждого прогона собирайте utilization, память, мощность, частоты и температуру. Доступные поля зависят от драйвера, поэтому сначала проверьте список:

nvidia-smi --help-query-gpu
nvidia-smi dmon --help
nvidia-smi dmon -s pucmt -d 1 -o DT

Если CC теряет throughput при более низкой загрузке GPU, но без нехватки памяти и без throttling, исследуйте CPU scheduler, частоту и размер GPU-запусков, CUDA Graphs и синхронные копирования. Если GPU постоянно насыщен, а разница мала, вычислительные ядра, вероятно, не являются главным ограничением.

Передача CPU–GPU

Соберите PCIe Rx/Tx штатной телеметрией платформы, если эти счетчики поддерживаются именно вашей комбинацией GPU и драйвера. Сопоставляйте интеграл байтов за измерительное окно, а не один пик. Для профилирования отдельного короткого прогона можно применять Nsight Systems, но трассировка сама создает overhead, поэтому ее результаты не смешивают с итоговым throughput.

Признак транспортного ограничения: при увеличении размера входа растет разница OFF/CC, GPU получает интервалы простоя, а объем или длительность host-to-device операций заметно увеличиваются. Это гипотеза для проверки, а не автоматический диагноз.

Сеть

size_upload и size_download показывают прикладной объем HTTP-тела, но не Ethernet-трафик, TLS, повторные передачи и служебные пакеты. Для общего сетевого объема снимайте счетчики интерфейса до и после теста:

IFACE="eth0"
ip -s link show dev "$IFACE"

Делайте это на выделенном интерфейсе или ноде: иначе счетчики включат чужой трафик. Если payload одинаков, но wire bytes различаются, проверьте TLS, streaming, keep-alive, прокси, ретраи и service mesh. Эти байты не относятся к PCIe или NVLink.

Хранилище и загрузка модели

Собирайте throughput и latency тома штатными средствами облака или ОС. Время загрузки может измениться из-за расшифрования весов, удаленного key release, page cache, компрессии, сетевого хранилища и порядка инициализации. Отчет должен показывать отдельно T1−T0, T3−T2 и T4−T0.

Минимальная матрица эксперимента

Как проверить результат

Перед выводом о производительности пройдите контрольный список:

1. Аттестация CC подтверждена ожидаемой политикой, а не только сообщением «режим включен».
2. Во всех запусках совпадают хеш весов и tokenizer, версии ПО и параметры сервера.
3. Число входных и выходных токенов совпадает по корзинам; ошибки и отмены не потеряны.
4. Нет thermal или power throttling, а фоновые workload отсутствуют.
5. Одинаково настроены batching, CUDA Graphs, KV-cache и tensor parallel.
6. Клиент не достиг собственного предела CPU, сокетов или сетевой полосы.
7. Разница больше межсерийного разброса и повторяется в обратном OFF-прогоне.
8. Трафик разделен на HTTP, сеть хоста, CPU–GPU и GPU–GPU; эти величины не суммируются как одна метрика.

Финальная таблица должна содержать абсолютные значения OFF и CC, относительную разницу, разброс и количество наблюдений. Не публикуйте только проценты: потеря 5% при 100 запросах в секунду и при 10 000 — разные эксплуатационные ситуации.

Интерпретация характерных картин

Каждая строка — направление диагностики, не доказательство причинности. Подтверждайте гипотезу отдельным контролируемым прогоном.

Типовые ошибки

• Сравнивать разные версии сервера. Изменения autotuner, CUDA Graphs или асинхронного чтения токенов могут быть больше CC-overhead.
• Считать первый запрос steady-state. В него попадают JIT-компиляция, autotuning и заполнение cache.
• Чистить cache на общей ноде. Это небезопасно для соседних сервисов и портит измерения.
• Менять режим при активных workload. Сначала штатно остановите их и следуйте процедуре администратора платформы.
• Путать CC и PPCIe. Для актуального Blackwell NVIDIA указывает режим CC on с шифрованием NVLink; конкретная поддержка зависит от совместимого стека.
• Не учитывать ошибки. Высокий throughput при большом числе timeout — не выигрыш.
• Логировать секреты. Аттестационные токены, ключи, приватные модели и реальные промпты не должны попадать в benchmark bundle.
• Сравнивать только среднее. Среднее скрывает хвосты latency и фазовые колебания batching.

Ограничения

Этот протокол не задает универсальный процент потерь. Результат зависит от модели Blackwell, топологии, firmware, драйвера, TEE хоста, inference-фреймворка, формы запросов и режима multi-GPU. Даже два внешне одинаковых сервера могут различаться лимитами мощности и конфигурацией BIOS.

Наблюдаемая разница полного прикладного сценария включает виртуализацию, аттестацию, выдачу ключей, storage и сеть. Диагностический A/B-тест помогает локализовать overhead, но не заменяет production-тест с реальной политикой безопасности.

Телеметрия внутри доверенной VM может быть ограничена, а профилировщики способны менять тайминги. Отсутствие видимого счетчика не означает отсутствия передачи. Наконец, режим CC защищает данные только в рамках заявленной модели угроз; корректность политики аттестации и управления ключами остается отдельной задачей.

Что положить в отчет

Воспроизводимый пакет содержит обезличенный manifest окружения, digest образа, хеш настроек, описание модели без раскрытия закрытых весов, генератор синтетических запросов, сырые результаты по запросам, телеметрию, расчет метрик и журнал исключенных прогонов. Для каждого исключения укажите правило, заданное до анализа.

Краткий вывод формулируйте по компонентам: «steady-state throughput», «TTFT/TPOT», «cold start», «HTTP bytes», «сетевые bytes» и «CPU–GPU transfer». Так одна итоговая цифра превращается в инженерное решение: увеличить batch, включить поддерживаемые CUDA Graphs, убрать аттестацию с горячего пути, ускорить загрузку весов или пересмотреть сетевой слой.

Официальные материалы

• NVIDIA Trusted Computing Solutions — документация, release notes и матрица совместимости.
• NVIDIA Confidential Computing Deployment Guide — настройка Hopper и Blackwell в поддерживаемых режимах.
• NVIDIA Confidential Containers — архитектура, ограничения и эксплуатация в Kubernetes.
• Managing the Confidential Computing Mode — режимы CC и процедура переключения.
• Hardware-Rooted AI Security That Won’t Slow You Down — опубликованная NVIDIA методика и результаты для конкретной платформы и модели.

Другие практические материалы доступны в разделе гайдов, а определения терминов — в глоссарии Agent Lab Journal.