На GTC Berlin 2026 участники воркшопа NVIDIA смогли ускорить генерацию Qwen3-32B с 16,4 до 24,5 токена в секунду, не меняя оборудование. Для этого использовали FP8 вместо BF16. Общая пропускная способность тоже выросла, хотя и заметно меньше: с 639 до 719 токенов в секунду.

Эксперимент проводили на Kubernetes-кластере с четырьмя NVIDIA A100 по 80 ГБ. У каждого участника был собственный кластер, на котором можно было разворачивать модели, менять конфигурацию и измерять производительность. Помимо квантизации, на занятии разбирали NVIDIA Dynamo, маршрутизацию запросов с учётом KV-кеша, автоматическое масштабирование и разделение prefill/decode между GPU.

Материал основан на статье инженера Siim Tolk, опубликованной 4 ноября 2026 года.

Как проходил воркшоп

Занятие состоялось 20 октября, за день до основного выступления NVIDIA на GTC Berlin. Его проводили архитекторы NVIDIA Amit Kushwaha и Yesika Ramirez Cardenas. С 9:00 до 16:00 участники прошли три практических блока, каждый из которых начинался с короткой лекции и продолжался работой с кластером.

Каждому предоставили GPU-сервер с четырьмя A100 80 GB и готовым окружением Kubernetes. В нём уже были установлены NIM и Dynamo Operators, Envoy Gateway, Prometheus, Grafana и DCGM Exporter. Практическая часть включала 14 Jupyter-ноутбуков, суммарно около 270 ячеек кода. Участники запускали настоящие модели, создавали нагрузку и анализировали метрики инференса.

Первый эксперимент: BF16 против FP8

Начали с gpt-oss-20b, модели с архитектурой Mixture of Experts. Её развернули через NVIDIA NIM, измерили время холодного старта, а затем проверили параметры API, влияющие на генерацию: reasoning effort, streaming, температуру, максимальное количество токенов и JSON mode. Отдельно измеряли время до первого токена.

Следующий эксперимент проводили на Qwen3-32B. Модель запустили в двух вариантах, BF16 и FP8, после чего сравнили их производительность через NVIDIA AIPerf. В тесте Siim Tolk на каждый вариант пришлось по 240 запросов.

Результаты получились следующими:

Метрика

BF16

FP8

Среднее время между токенами

61 мс

42 мс

Скорость генерации для пользователя

16,4 токена/с

24,5 токена/с

Общая пропускная способность

639 токенов/с

719 токенов/с

Скорость генерации для одного пользователя выросла на 49,4%, общая пропускная способность на 12,5%. Разница между показателями связана с тем, что скорость отдельного потока и суммарная производительность при конкурентных запросах зависят от разных факторов, включая батчинг, использование памяти и характер нагрузки.

В BF16 для представления веса используется 16 бит, в FP8 только 8. Это позволяет уменьшить объём данных, которые нужно хранить и передавать. В зависимости от реализации квантизация может снизить требования к видеопамяти и ускорить инференс.

Есть нюанс с оборудованием. A100 не поддерживает нативные FP8 Tensor Cores, появившиеся в более новых архитектурах NVIDIA. Поэтому само обозначение FP8 ещё не говорит о том, какие именно вычисления выполнялись в восьмибитном формате. Подробности реализации в исходной статье не приведены, как и результаты проверки качества ответов после квантизации.

Полученные 49,4% относятся к конкретной конфигурации Qwen3-32B и нагрузочному тесту. Для другой модели или GPU результат может существенно отличаться. После этих экспериментов участники перешли к метрикам vLLM в Prometheus и Grafana.

Один API для нескольких моделей

Во втором блоке участники настроили Envoy AI Gateway перед тремя моделями. Вместо отдельных API-адресов для каждой модели получился один endpoint с маршрутизацией по имени модели.

Похожую идею можно увидеть в мультимодельных чатах вроде AnyLLM: пользователь выбирает нейросеть в одном интерфейсе, а запрос направляется нужной модели. На воркшопе разбирали серверную сторону такого подхода, включая маршрутизацию, управление доступом и учёт токенов.

К шлюзу добавили API-ключи, ограничение расхода токенов, учёт использования, повторные попытки при ошибках, circuit breakers и постепенное обновление моделей. Всё это настраивалось через Kubernetes и Envoy.

Почему Gateway API вместо Ingress

Kubernetes больше не развивает Ingress API и рекомендует для новых сценариев Gateway API. Существующий Ingress продолжает поддерживаться, но новые возможности в его спецификацию уже не добавляют.

Ingress позволяет маршрутизировать HTTP-трафик по доменам и путям. Более сложные сценарии часто требуют специальных аннотаций, зависящих от конкретного контроллера. В Gateway API такие возможности предусмотрены непосредственно в спецификации. Например, можно отправить 5% запросов на новую версию модели или настроить маршрутизацию по HTTP-заголовкам и параметрам запроса.

Конфигурация разделена между несколькими ресурсами. GatewayClass определяет реализацию, Gateway описывает точку входа, а HTTPRoute задаёт правила маршрутизации. Envoy Gateway реализует эту спецификацию на базе Envoy Proxy, а Envoy AI Gateway добавляет функции для обслуживания LLM, включая маршрутизацию по моделям и ограничения токенов.

Почему лучше ограничивать токены, а не запросы

В обычном REST API часто ограничивают количество запросов в минуту. С LLM такой подход не всегда удобен, поскольку запрос с контекстом на 10 тысяч токенов может потреблять намного больше ресурсов, чем десять коротких запросов.

Envoy AI Gateway умеет учитывать токены, а Envoy Gateway применяет лимиты через механизм global rate limiting. В конфигурации воркшопа для этого использовали Redis.

Отдельно разбирали повторные запросы при ошибках. Если сервер вернул 5xx или соединение оборвалось, повторная попытка иногда помогает. Но если десятки клиентов одновременно начинают повторять запросы к перегруженному серверу, ситуация может стать хуже. Поэтому используют exponential backoff, то есть увеличивают задержку между попытками. Circuit breaker позволяет временно прекратить отправку запросов на проблемный экземпляр.

Ошибки авторизации и некорректные параметры запроса повторять без исправления бессмысленно. Для LLM есть и дополнительная проблема: после разрыва соединения генерация может продолжаться на сервере. Повторный запрос способен запустить вторую генерацию и повторно потратить ресурсы.

При обновлении моделей рассматривали два способа проверки новой версии. Canary rollout отправляет небольшую долю пользовательских запросов на новую модель. Request mirroring копирует запросы на тестируемую версию, но пользователю возвращается только ответ основной. Так можно проверить поведение новой модели на реальном трафике до полного переключения.

Автоматическое масштабирование через KEDA

После настройки шлюза участники освободили GPU и попробовали масштабировать NVIDIA NIM через KEDA. Стандартный Kubernetes HPA может использовать загрузку CPU и памяти, но для LLM эти показатели не всегда хорошо отражают количество запросов, которое способен обработать сервер.

В эксперименте использовали метрики vLLM. Показатель vllm:num_requests_running отражает количество выполняющихся запросов, а vllm:num_requests_waiting показывает длину очереди. KEDA получает значения из Prometheus и на их основе увеличивает или уменьшает число реплик.

Отдельно разбирали проблему GPU utilization в DCGM. На узлах с несколькими GPU показатели иногда неправильно сопоставляются с pod. В результате мониторинг может показывать 0% загрузки даже при наличии запросов.

Ещё одна особенность связана с масштабированием вниз. Контейнеру NIM может потребоваться несколько минут, чтобы загрузить модель. Если слишком часто удалять и создавать реплики, время запуска начнёт мешать обработке запросов. Поэтому в примере рекомендовалось уменьшать количество реплик постепенно, с интервалом около десяти минут.

NVIDIA Dynamo: разделяем prefill и decode

Третий блок посвятили NVIDIA Dynamo. Для экспериментов использовали Qwen2.5-32B-Instruct в формате GPTQ Int4, запущенную через vLLM.

Обработка запроса LLM состоит из двух основных этапов. Prefill обрабатывает входной промпт и формирует KV-кеш. На этом этапе модель выполняет много вычислений, особенно если контекст длинный. Decode генерирует ответ последовательно, по одному токену. Здесь производительность часто ограничивает пропускная способность памяти.

В обычной конфигурации обе стадии выполняются на одних GPU. Такой режим называется aggregated serving. Dynamo позволяет разделить обработку промпта и генерацию ответа между разными группами GPU, передавая KV-кеш от prefill-workers к decode-workers.

На воркшопе использовали две пары A100, соединённые через NVLink. Участники последовательно проверили aggregated serving, маршрутизацию с учётом KV-кеша и disaggregated serving. Каждую конфигурацию тестировали отдельно.

Разделение prefill и decode позволяет масштабировать их независимо. Например, при большом количестве длинных входных документов может потребоваться больше ресурсов на prefill. Если пользователи одновременно генерируют длинные ответы, возрастает нагрузка на decode.

Однако разделение полезно не всегда. Передача KV-кеша между GPU тоже требует ресурсов, поэтому при небольшом количестве запросов обычный aggregated serving может работать эффективнее.

Маршрутизация с учётом KV-кеша

У Dynamo есть KV-cache-aware router. Его задача заключается в повторном использовании уже обработанных фрагментов контекста.

Представим чат, в котором пользователь отправляет несколько сообщений подряд. При каждом новом запросе сервер может получать всю предыдущую переписку. Если начало промпта уже обрабатывалось и его KV-кеш сохранился на одном из workers, часть вычислений можно пропустить.

Роутер старается отправить запрос на тот worker, где уже есть подходящий кеш. При этом учитывается текущая загрузка. Такой подход особенно полезен для длинных диалогов и RAG-систем, в которых разные запросы повторно используют общие части промпта.

Dynamo также включает Planner, который следит за нагрузкой и регулирует количество prefill- и decode-workers. Ещё один механизм, ModelExpress, ускоряет запуск новых workers. Вместо повторной загрузки весов из хранилища новый экземпляр может скопировать их с уже работающего.

Дополнительный ноутбук был посвящён Grove, инструменту для согласованного планирования связанных pod. Он помогает размещать группы prefill- и decode-workers с учётом их совместной работы.

Другие инструменты

Во время занятия рассмотрели несколько возможностей, которые могут пригодиться и без Dynamo.

Logprobs позволяют получить логарифмы вероятностей сгенерированных токенов. По ним можно анализировать поведение модели и выделять ответы для дополнительной проверки. При этом вероятность токена не стоит напрямую приравнивать к достоверности ответа.

Фиксированный seed помогает получать более воспроизводимые результаты при тестировании. Полностью идентичный вывод во всех конфигурациях он не гарантирует. FlashAttention, в свою очередь, вычисляет attention блоками и уменьшает количество обращений к памяти GPU. Это позволяет ускорить вычисления и сократить потребление памяти, сохранив точный результат attention.

Отдельно упоминались инструменты NVIDIA для оценки производительности. AIPerf измеряет время до первого токена, задержки между токенами и пропускную способность. Его использовали непосредственно на воркшопе.

AIConfigurator помогает сравнивать конфигурации aggregated и disaggregated serving, а также оценивать необходимое число workers. AISimulate моделирует работу инференса и конфигураций Dynamo без реального развёртывания. Инструмент пока экспериментальный и предназначен для оценки вариантов, а не для точного планирования мощностей.

Финальное задание

В конце воркшопа участникам выдали модель Qwen3-1.7B, с которой они ещё не работали. Нужно было самостоятельно подготовить конфигурацию Dynamo, развернуть модель в aggregated и disaggregated режимах, провести тестирование через AIPerf и сравнить два варианта соотношения prefill/decode replicas.

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

Что можно применить на практике

Для домашнего компьютера с одной видеокартой большая часть инструментов из воркшопа избыточна. KEDA и разделение prefill/decode рассчитаны на инфраструктуру, где можно распределять нагрузку между несколькими GPU и экземплярами моделей. А вот эксперименты с квантизацией, FlashAttention и настройками движка инференса вполне применимы к локальным LLM.

При сравнении конфигураций полезно измерять не только токены в секунду, но и время до первого токена, потребление видеопамяти и качество ответов. Если модель обслуживает много пользователей, становятся актуальны маршрутизация, метрики очереди, повторное использование KV-кеша и автоматическое масштабирование.

В исходном эксперименте FP8 ускорил генерацию Qwen3-32B почти на 50% для одного пользователя. Но без проверки на конкретной модели и оборудовании рассчитывать на такой же прирост не стоит.

Источники