Как NVIDIA Co-Design извлекает максимум из каждого байта памяти в AI-фабрике

В современной индустрии искусственного интеллекта, особенно в контексте развертывания крупных языковых моделей (LLM) и агентов, память становится главным узким местом. Высокопроизводительная память (HBM) — это самый быстрый, самый дорогой и самый востребованный уровень хранения данных в дата-центре. Каждый байт, потраченный на дублирование весов модели, на хранение «мертвого» контекста (KV-кэша) для неактивных сессий или на пересчет уже обработанных префиксов, — это байт, который не используется для генерации токенов. Вопрос больше не в том, сколько памяти имеет видеокарта, а в том, какую полезную работу выполняет каждый отдельный байт этой памяти.

Новая архитектура NVIDIA Rubin демонстрирует революционный подход к этой проблеме. В то время как объем памяти на GPU остается неизменным на уровне 288 ГБ (по сравнению с предыдущим поколением GB300), пропускная способность возрастает до 19,2 ТБ/с. Это позволяет достичь кратного роста производительности. На платформе SemiAnalysis AgentX, которая имитирует реальные сессии программирования с агентами, включая паузы для вызова инструментов и рост контекста, система NVIDIA Vera Rubin NVL72 обеспечивает до 30-кратного увеличения пропускной способности на ватт по сравнению с GB300 NVL72 при скорости 160 токенов в секунду на пользователя.

Как же удалось достичь такого скачка, не увеличивая физический объем памяти? NVIDIA решает эту задачу через концепцию совместного проектирования (Co-Design), которая охватывает архитектуру GPU, межсоединения, программное обеспечение для обслуживания, процессоры и системы хранения. В этой статье мы подробно разберем пять ключевых рычагов, которые NVIDIA использует для максимизации ценности каждого байта в AI-фабрике.

011. NVFP4: Как хранить больше интеллекта в меньшем объеме

Самый прямой способ повысить ценность байта — сделать каждое хранимое значение меньше, не теряя при этом точности. Здесь на сцену выходит формат данных NVFP4. В отличие от традиционных форматов с плавающей запятой, NVFP4 использует 4-битный элемент E2M1, но применяет двухуровневую систему масштабирования. Каждые 16 значений в микро-блоке разделяют общий масштабный коэффициент FP8 (E4M3), а поверх этого находится масштабный коэффициент FP32 для всего тензора. Такой подход позволяет формату быть достаточно компактным, чтобы освободить значительный объем HBM, но при этом достаточно детализированным, чтобы сохранить точность там, где наивные 4-битные форматы обычно дают сбой.

Применение NVFP4 к весам модели сокращает ее footprint (размер на диске и в памяти) примерно в 3,5 раза по сравнению с FP16 и в 1,8 раза по сравнению с FP8. Это освобождает память для того, что наиболее критично для инференса агентов: большего объема KV-кэша, более крупных батчей и высокой конкурентности. NVFP4 стал стандартом точности для открытых бенчмарков с жесткими требованиями к точности, таких как AA-AgentPerf, SemiAnalysis AgentX и MLPerf Endpoints. На этих тестах, а также на архитектурах смешанного эксперта (MoE), NVFP4 обеспечивает до 4-кратного увеличения пропускной способности по сравнению с базовым уровнем FP8 при той же интерактивности.

Этот же принцип распространяется и на сам KV-кэш. Использование NVFP4 для KV-кэша сокращает его footprint до 50% по сравнению с FP8, что позволяет примерно в 2 раза большему объему контекста оставаться в устройстве. Меньшее количество вытеснений означает более высокий процент попаданий в кэш во время префилла, а меньший размер кэша снижает потребление пропускной способности во время декодирования.

022. Широкий экспертный параллелизм: Превращаем 72 GPU в один пул памяти

Модели с архитектурой MoE (Mixture of Experts) активируют только подмножество параметров для каждого токена, но веса всех экспертов должны где-то храниться в HBM. Когда эксперты упакованы на небольшое количество GPU, каждая видеокарта тратит большую часть памяти на хранение весов, и каждый шаг декодирования несет тяжелую нагрузку по загрузке весов для операций GroupGEMM. Байты присутствуют в памяти, но они не работают эффективно.

Широкий экспертный параллелизм (Wide-EP) в NVIDIA TensorRT-LLM меняет это соотношение, распределяя экспертов на восемь или более GPU. Например, для модели DeepSeek-R1 с параметром EP64 каждый GPU держит только четыре эксперта на слой, или 232 блока экспертов из 58 слоев MoE (из 14 848 в полной модели). Меньшее количество весов экспертов на GPU дает три ключевых преимущества:

• Емкость: Больше HBM на GPU остается для KV-кэша, больших батчей и высокой конкурентности.
• Арифметическая интенсивность: Ядра GroupGEMM переиспользуют каждый загруженный вес для большего количества токенов, повышая количество операций с плавающей запятой (FLOPs) на байт.
• Баланс: Балансировщик нагрузки экспертного параллелизма (EPLB) перераспределяет «горячие» и «холодные» эксперты между проходами, чтобы память одного GPU не была перегружена, пока другой простаивает.

Это возможно только благодаря тому, что домен масштабирования (scale-up domain) делает удаленные байты почти такими же полезными, как локальные. Каждый слой MoE вызывает трафик диспетчеризации и объединения all-to-all, и без высокоскоростной сети эти коллективные операции могли бы свести на нет все преимущества. На GB200 NVL72 совокупная пропускная способность NVLink в 130 ТБ/с поглощает этот трафик, и большой EP (EP32) дает до 1,8 раза больше выходных токенов в секунду на GPU, чем малый EP (EP8).

Архитектура Vera Rubin NVL72 расширяет этот подход. Каждый GPU Rubin имеет до 288 ГБ HBM4 и 3,0 ТБ/с пропускной способности NVLink 6, что дает около 20,7 ТБ HBM4 на стойку. Rubin также добавляет обновления дескрипторов ускорителя тензорной памяти (TMA) в реальном времени, так что один общий дескриптор может обслуживать каждый эксперт с общей компоновкой, снижая накладные расходы на метаданные, которые растут с количеством экспертов.

033. NVIDIA Dynamo: Как заставить каждый закэшированный байт работать

KV-кэш хранит промежуточные вычисления внимания от ранее обработанных токенов, чтобы модель могла переиспользовать их, а не пересчитывать заново. Это состояние инференса эфемерно и может быть вытеснено и пересчитано при необходимости, но KV-кэш ценен только если он переиспользуется. Агентные нагрузки полны возможностей для переиспользования: системные промпты, схемы инструментов, общие документы и растущая история многошаговой задачи. Но если запрос попадает на GPU, который не держит его префикс, или если этот префикс был вытеснен мгновение назад, система платит за префилл снова. Байты существовали; они просто были в неправильном месте.

NVIDIA Dynamo — это распределенный слой обслуживания, который закрывает этот разрыв. Он рассматривает KV-кэш как ресурс всего кластера, а не как побочный эффект отдельного GPU, и делает это через три совместных возможности:

1. Маршрутизация, aware к KV-кэшу (KV-aware routing): Роутер Dynamo отслеживает, где находятся блоки KV, и учитывает как перекрытие кэшированного префикса, так и нагрузку на воркер при размещении запросов. Он балансирует существующий контекст против стоимости отправки работы на загруженный GPU и превращает потенциальные пересчеты в попадания в кэш.
2. Деагрегированное обслуживание (Disaggregated serving): Префилл и декод выполняются на отдельных пулах GPU, каждый из которых настроен под свои профили вычислений и памяти. GPU декодирования могут выделять HBM для KV-кэша и размера батча, а не резервировать запас для бурстных префиллов.
3. Бегун KV-кэша (KV Cache Runner - KVCR): Он отслеживает, где находится каждый блок, в настроенных уровнях GPU, закрепленной памяти CPU и хранилища, включая локальные SSD и смонтированные сетевые файловые системы. Префикс, сохраненный вне HBM, может быть восстановлен, когда следующий запрос нуждается в нем, позволяя полезному контексту пережить вытеснение GPU и продолжать экономить работу по префиллу. KVCR использует библиотеку NVIDIA Inference Xfer Library (NIXL) для путей передачи данных, позволяя кэшированным блокам перемещаться, пока GPU обрабатывает другую работу.

Дополнительная функция KVCR-Guard сохраняет выделенный кэш памяти хоста, управляемый KVCR, во время сбоя движка, пока служба guard и хост доступны. Это гарантирует, что контекст не будет потерян при технических неполадках.

044. NVIDIA Vera CPU: Как избежать пустой траты HBM во время пауз

Агентный инференс не работает в одном непрерывном проходе. Одна сессия чередуется между шагами модели на GPU и работой на стороне CPU: вызовы инструментов, выполнение кода, поиск информации, запросы к базам данных и изолированная оценка. Во время каждой из этих пауз любой KV-кэш сессии, удерживаемый в HBM, занимает емкость, не обслуживая активную генерацию токенов, в то время как другие запросы конкурируют за те же байты.

В полностью загруженной AI-фабрике GPU не ждет. Он берет на себя новые запросы, пока выполняется вызов инструмента, и чем дольше пауза, тем вероятнее, что KV-кэш оригинальной сессии будет вытеснен, чтобы освободить место. Когда инструмент возвращает результат, GPU может быть вынужден восстановить этот контекст через полный префилл, а не продолжить с кэшированного состояния. Медленный CPU стоит HBM дважды: сначала как простое проживание, затем как пересчет.

NVIDIA Vera CPU атакует обе стороны этой проблемы:

• Сокращение пауз: 88 ядер Olympus обеспечивают однопоточную производительность в 1,8 раза выше, пиковую задержку на 40% ниже, чем у x86 CPU, и до 14 ГБ/с пропускной способности памяти на ядро. Более быстрые и предсказуемые вызовы инструментов сокращают окно, в течение которого KV-кэш подвергается давлению вытеснения.
• Быстрое место для парковки контекста: Каждый процессор Vera предоставляет до 1,5 ТБ LPDDR5X, что более чем в 5 раз превышает емкость HBM4 одного GPU Rubin. NVIDIA NVLink-C2C соединяет его когерентно с Rubin со скоростью 1,8 ТБ/с, что примерно в 7 раз быстрее, чем 256 ГБ/с ссылки PCIe Gen 6 x16.

Вместе эти возможности меняют экономику неактивной сессии. Вместо того чтобы удерживать свой KV-кэш в HBM или выбрасывать его, менеджер блоков KV от Dynamo может разместить его в памяти Vera на время вызова инструмента и вернуть его по NVLink-C2C, когда агент возобновит работу. HBM остается выделенным для сессий, которые активно генерируют токены, а приостановленная сессия избегает оплаты за префилл дважды.

055. NVIDIA CMX: Расширение памяти контекста на весь под

Сохранение каждого переиспользуемого байта KV-кэша в памяти GPU или хоста ограничивает емкость для активного инференса, но его выброс может вызвать пересчет. Многопользовательские сессии, задачи с длинным горизонтом и многоагентные рабочие процессы, которые разделяют рабочую память, генерируют KV-кэш, который понадобится снова, часто через минуты и часто на другом узле. Более длинные окна контекста и больше одновременных сессий увеличивают требования к емкости KV-кэша за пределы GPU HBM и памяти хоста. Традиционная иерархия не была создана для этих данных. Локальные SSD привязаны к одному узлу, а корпоративное сетевое хранилище создано для долговременных данных и несет накладные расходы на репликацию и метаданные, которые эфемерному KV-кэшу не нужны.

NVIDIA CMX (Context Memory eXtension) закрывает этот разрыв, добавляя новый уровень G3.5: флеш-накопители, подключенные по Ethernet, разделяемые на уровне под (pod) и оптимизированные специально для KV-кэша. Он построен на эталонном дизайне NVIDIA STX и совместим спроектирован по четырем слоям:

1. Обработка хранения: Процессор хранения NVIDIA BlueField-4 STX управляет NVMe SSD, запускает службы хранения и разгружает перемещение данных KV-кэша, целостность данных и шифрование. Его встроенный процессор NVIDIA Vera ускоряет обработку хранения на стороне CPU, расширяя ту же архитектуру CPU, используемую для выполнения агентов, в путь обработки данных хранения.
2. Сеть: NVIDIA Spectrum-X Ethernet обеспечивает доступ с низкой задержкой и высокой пропускной способностью RDMA между вычислительными узлами и узлами хранения CMX.
3. Сервисы, aware к KV: NVIDIA DOCA Memos предоставляет сервисы, aware к KV, и управление вводом-выводом на BlueField-4, рассматривая контекст как ресурс первого класса для размещения и обмена.
4. Интеграция обслуживания: Dynamo и NIXL делают CMX видимым как один бесшовный уровень контекста по всему под, предварительно размещая контекст и маршрутизируя запросы туда, где KV-кэш уже находится.

06Что это значит на практике

Для инженеров и архитекторов, работающих с AI-инфраструктурой, эти пять рычагов означают сдвиг парадигмы. Больше нельзя полагаться только на покупку видеокарт с большим объемом памяти. Эффективность AI-фабрики теперь определяется тем, насколько хорошо вы интегрируете алгоритмы сжатия (NVFP4), распределение нагрузки (Wide-EP), управление состоянием (Dynamo), использование CPU-памяти (Vera) и сетевое хранилище (CMX).

Для разработчиков, запускающих модели локально или в небольших кластерах, ключевым уроком является важность управления KV-кэшем. Использование форматов с пониженной точностью, таких как FP4 или FP8, и настройка стратегий вытеснения кэша может дать значительный прирост производительности даже на потребительских GPU. Для крупных предприятий интеграция таких решений, как Dynamo и CMX, позволяет масштабировать агентов до тысяч одновременных пользователей, сохраняя низкую задержку и высокую пропускную способность, что ранее было невозможно без экспоненциального роста затрат на оборудование.

В конечном итоге, NVIDIA Co-Design демонстрирует, что будущее AI-вычислений лежит не только в увеличении сырой мощности, но и в интеллектуальном управлении данными. Каждый байт памяти становится активом, который должен работать на максимуме, и только комплексный подход, охватывающий все уровни стека, позволяет достичь этой цели.

Источник: NVIDIA Developer ↗