Как NVIDIA предлагает архитектурам ИИ дружить с видеокартами: четыре правила для быстрого вывода

Инженеры NVIDIA опубликовали практическое руководство по совместному проектированию механизма внимания языковых моделей и графических процессоров. Главный вывод: чем длиннее контекст, тем больше времени уходит именно на внимание — и это можно исправить на этапе архитектуры модели.

Когда контент окна чата превышает 32 тысячи токенов, механизм внимания начинает «съедать» до 85% времени отклика — и дальнейшие улучшения нужно искать не только в драйверах, но и в самой конструкции нейросети.

Зачем вообще думать о внимании

Кто хоть раз использовал чат-бот с длинной историей диалога, замечал: чем больше накоплено сообщений, тем дольше модель «думает». Это не глюк и не ограничение подписки — за ним стоит конкретный технический факт. Механизм внимания (attention), который позволяет нейросети «помнить» и связывать все токены контекста между собой, масштабируется нелинейно. И на длинных последовательностях он становится главным узким местом.

Инженеры NVIDIA только что опубликовали на своём техническом блоге детальный разбор того, как архитектурные решения при проектировании модели влияют на скорость инференса. Пост не про новый чип и не про драйвер — он про то, как проектировать саму нейросеть так, чтобы она эффективно работала на существующих GPU. В NVIDIA это называют «co-design» — совместное проектирование модели и железа.

Prefill и decode: два разных мира внутри одного ответа

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

Prefill — это первичная обработка всего введённого текста. Модель параллельно «прочитывает» все токены вашего запроса и строит внутреннее представление контекста. Здесь работает масса параллельных вычислений, и процесс ограничен производительностью вычислительных ядер GPU.

Decode — это генерация ответа, токен за токеном. Каждое новое слово требует обращения ко всему накопленному контексту (так называемому KV-кешу). Здесь GPU уже не столько считает, сколько читает данные из памяти — процесс ограничен пропускной способностью видеопамяти.

Это ключевое различие. Решения, которые ускоряют одну фазу, могут никак не влиять на другую. А иногда — даже вредить.

Рост контекста: внимание становится монстром

NVIDIA приводит наглядный пример на модели DeepSeek-R1. При контексте в 4 тысячи токенов механизм внимания занимает всего 18% времени prefill-фазы. При 32 тысячах — уже заметно больше. А при 128 тысячах токенов — 85%. То есть львиная доля ожидания — это не вычисление самого текста, а именно перебор связей между токенами.

Для пользователя это означает простую вещь: увеличение «окна памяти» модели — это не бесплатное обновление. Чем длиннее контекст, тем дороже каждый шаг внимания. И если архитектура модели не оптимизирована под длинные последовательности, даже мощная видеокарта будет простаивать.

Четыре правила от NVIDIA

Инженеры компании сформулировали четыре практических рекомендации для разработчиков моделей. Давайте разберём каждую.

Правило 1: Увеличивайте «группу» запросов

В современных архитектурах внимания не каждый «запрос» (query) имеет свой собственный «ключ-значение» (KV). Несколько запросов могут совместно использовать одну KV-голову — это называется Grouped Query Attention (GQA). Число запросов, приходящихся на одну KV-голову, называется размером группы (G).

Почему это важно? В фазе decode, где модель генерирует ответ токен за токеном, увеличение G примерно линейно ускоряет работу. Если поднять G с 1 (классическое MHA) до 8, скорость decode может вырасти в 8 раз — потому что на каждый токен нужно загружать меньше данных из памяти.

А вот на фазе prefill размер группы практически не влияет на производительность. Там всё определяется длиной входной последовательности. Поэтому при проектировании модели можно смело увеличивать G ради эффективной генерации, не опасаясь замедлить обработку запроса.

Модели вроде NVIDIA Nemotron 3 уже используют этот подход — там всего 2 KV-головы на 64 запросных, что делает decode существенно эффективнее.

Правило 2: Выбирайте размер «головы» 128 или 256

Каждая голова внимания работает с векторами фиксированной размерности — это называется размером головы (Hsz). Казалось бы, чем больше размерность, тем больше вычислений — но на практике всё сложнее.

GPU обрабатывает данные блоками (тайлами) размером 64 или 128 элементов. Если ваша размерность — 64, GPU всё равно зарезервирует тайл на 128, потратив ресурсы впустую. Если размерность — 512 и выше, можно упереться в ограничения тензорной памяти (TMEM). Оптимальное окно — 128 или 256.

Интересный нюанс: операция softmax (нормализация весов внимания) не зависит от размера головы — она работает с матрицей «запросы × ключи». Поэтому более широкие головы даже выгодны в фазе prefill: они «прячут» фиксированные затраты softmax за увеличенным объёмом матричных умножений.

Правило 3: Сокращайте эффективный KV-кеш

Здесь мы подходим к главному архитектурному решению. KV-кеш — это память, в которой модель хранит ключи и значения всех предыдущих токенов. С каждой новой порцией контекста он растёт, и в фазе decode модель должна его перечитывать целиком.

Зависимость неприятная: в фазе prefill время растёт квадратично от длины последовательности (O(n²)), в фазе decode — линейно (O(n)). Причём «квадрат» в prefill — это внимание каждого токена к каждому.

NVIDIA предлагает несколько путей сокращения:

• Сжатие KV-кеша — хранить не полные вектора, а их компактные представления.
• Разреженное или скользящее окно — не все токены «смотрят» на все остальные, а только на ближайшие.
• Гибридные архитектуры — вроде Nemotron 3, где только некоторые слои несут полный глобальный контекст, а остальные работают локально.

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

Правило 4: Параллелизм должен учитывать число KV-голов

Когда модель запускается на нескольких GPU, используется тензорный параллелизм (TP): каждый GPU получает свою долю голов внимания. Но здесь есть ловушка.

Если GPU больше, чем KV-голов (TP > KH), одна KV-голова начинает дублироваться на нескольких картах. Это не ускоряет, а только тратит память и канал связи между GPU. Поэтому правило такое: TP не должен превышать числа KV-голов.

А что делать, если KV-голов мало — как в том же Nemotron 3, где их всего 2? В этом случае NVIDIA предлагает использовать другие стратегии параллелизма:

• Attention Data Parallelism (ADP) — распределение запросов между GPU.
• KV Parallelism (KVP) — распределение самого KV-кеша по картам памяти.
• Wide EP и Helix Parallelism — комбинированные подходы, реализованные в фреймворке TensorRT-LLM.

Всё это уже доступно в open-source TensorRT-LLM, так что разработчики могут применять эти стратегии прямо сейчас.

Спекулятивное декодирование: ещё один рычаг

Отдельно стоит упомянуть технику, которая помогает «разбудить» простаивающие вычислительные блоки в фазе decode. Спекулятивное декодирование заставляет модель генерировать сразу несколько «черновых» токенов за один шаг, а затем проверяет их. Это увеличивает эффективный размер матричного умножения и может перевести decode из состояния «ограничен памятью» в состояние «ограничен вычислениями» — то есть задействовать больше ресурсов GPU.

Что это значит для обычного пользователя

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

Уже сейчас TensorRT-LLM реализует большинство описанных подходов, а модели вроде Nemotron 3 демонстрируют, что «hardware-aware» проектирование — не теоретическое упражнение, а реальный инженерный метод.

И это, пожалуй, главный тренд в индустрии: больше не достаточно просто обучить большую модель на мощном кластере. Нужно проектировать архитектуру с самого начала так, чтобы она умела работать с тем оборудованием, на котором будет запускаться. GPU-дизайн и модель-дизайн становятся двумя сторонами одной медали.