MoRI UMBP расширяет возможности графических процессоров AMD Instinct

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

В июле совместно с Moonshot AI мы представили SGLang + MoRI UMBP (Unified Memory & Bandwidth Pool) в статье «Переосмысление агентного ИИ с фундаментальных принципов для GPU AMD». MoRI UMBP — это инфраструктура KV-кэша, созданная командой AMD MoRI с нуля, исходя из специфики агентных рабочих нагрузок и специально разработанная для платформы AMD. За последний месяц мы внесли этот вклад в сообщество SGLang, где он стал частью экосистемы с открытым исходным кодом благодаря новому компоненту KVCache Store Linker, что принесло пользу всему сообществу. Согласно публичному бенчмарку SemiAnalysis AgentX с использованием модели DeepSeek-V4-Pro-0813 1.6T, графический процессор AMD Instinct™ MI355X — при использовании дезагрегации MoRI с MoRI UMBP в качестве унифицированного пула KV-кэша, в дополнение к текущим работам по оптимизации, проводимым AMD в сообществе SGLang, — теперь обеспечивает на пике 69 млн общих токенов на 1 доллар совокупной стоимости владения (TCO) по сравнению с 46 млн у NVIDIA B200, работающего на Dynamo SGLang: это преимущество в 1,5 раза по количеству токенов на доллар, что также превосходит показатели NVIDIA GB200, B300 и GB300 на некоторых уровнях интерактивности (SemiAnalysis, обновлено 25.09.2026).

Рисунок 1: Общее количество агентных токенов DeepSeek-V4-Pro-0813 1.6T на 1 доллар TCO в зависимости от интерактивности P90, согласно данным публичной панели мониторинга SemiAnalysis InferenceX (уровень аренды / 3-летнее обязательство, обновлено 25.09.2026). Красным цветом отмечен MI355X FP4 с UMBP + MoRI + SGLang; зеленые кривые представляют решения NVIDIA — B200, B300, H200, GB200 и GB300 NVL72, а также предварительную версию Vera Rubin NVL72. Чем выше и правее, тем лучше; метки показывают схему параллелизма для каждой точки.

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

Краткий обзор публичного бенчмарка AgentX

AgentX — это публичный бенчмарк, созданный SemiAnalysis на основе реальных трасс агентного программирования, обслуживаемый через публичную систему тестирования и панель мониторинга InferenceX. Он быстро становится отраслевым стандартом для оценки агентного вывода, принятым во всем мире ведущими командами, включая OpenAI, Meta, Inferact, RadixArk, MiniMax, Alibaba Qwen, Moonshot AI, Zhipu GLM и Oracle. Его методология, результаты и CI являются публичными, поэтому каждое число в этой публикации может быть проверено независимо, в том числе компанией NVIDIA.

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

• Длительные многоходовые сессии — примерно 43 хода за сессию, около 1 млн токенов контекстного трафика за время жизни сессии.
• Длинные контексты, короткие выводы — медианное значение 142 тыс. входных токенов против 444 выходных токенов за ход.
• Широкое повторное использование префиксов — более 96% токенов промпта являются повторами префикса, который сервер уже видел.
• Субагенты и вызовы инструментов, которые распределяют одну пользовательскую задачу на несколько параллельных сессий, использующих общий префикс.

Он сообщает TTFT (время до первого токена), интерактивность P90 (ток/с на пользователя), TPGS (общее количество токенов на GPU-секунду, включая кэшированные токены) и TCO (стоимость инфраструктуры на токен) — последнее из которых и отображено на Рисунке 1.

При 96% повторного использования префиксов управление кэшем определяет стоимость предварительного заполнения (prefill). А поскольку агент блокируется до получения полного ответа, важной является сквозная задержка, в которой доминирует декодирование. Таким образом, AgentX представляет три проблемы, которые нам пришлось решить:

• KV-кэш не помещается в HBM: при большом количестве активных длинных сессий и разветвлении субагентов большая часть повторно используемого KV-кэша уже вытесняется из памяти GPU при умеренной конкуренции.
• KV-кэш не шардируется по рангам TP: при разреженном внимании DeepSeek-V4 латентные состояния MLA и индексы DSA KV реплицируются полностью на каждом ранге.
• Прогрев кэша не бесплатен: кэш хоста, который находится внутри процесса движка, теряется при каждой перезагрузке и при каждом обновлении системы.

MoRI UMBP + SGLang KVCache Store Linker

Мы решили эти три проблемы, объединив MoRI UMBP с SGLang KVCache Store Linker. В этом разделе описывается то, что мы наблюдали в AgentX, как в ответ на это был спроектирован линкер и какие результаты он принес.

Наблюдения по AgentX

MoRI UMBP был первоначально интегрирован в SGLang как бэкенд хранилища HiCache L3. Оценивая эту конфигурацию в AgentX, мы сделали шесть наблюдений:

• Растрата совместно используемой DRAM: L2-кэш хоста на каждом ранге занимает DRAM, которая могла бы обслуживать совместно используемый бэкенд L3, что сокращает эффективную емкость общего доступа.
• Непрямой путь данных: KV перемещается между L1 HBM и бэкендом L3 через уровень хоста L2, что добавляет накладные расходы на загрузку/выгрузку и исключает прямой путь данных L1 ⇔ L3.
• Локальное управление на каждом ранге: каждый ранг управляет своим кэшем хоста и принимает все решения по KV только на основе локальной информации, что глобально неоптимально.
• Избыточная репликация: при MLA + TP каждый ранг TP реплицирует KV-кэш и выполняет загрузку/выгрузку независимо, тратя память и пропускную способность PCIe.
• Отсутствие послойного конвейера: загрузка L2→L1 перекрывается с вычислениями слой за слоем, но выборка из внешнего бэкенда L3 в L2 не конвейеризируется — она должна завершиться до начала вычислений.
• Кэш умирает вместе с движком: кэш хоста живет в процессе движка, поэтому любая перезагрузка приводит к его потере.

KVCache Store Linker

Мы предложили сопровождающим SGLang вариант полного обхода уровня хоста L2 с помощью прямого пути данных между L1 HBM и внешними хранилищами KV-кэша — направление, которое, как оказалось, тесно совпадает с собственными планами сообщества. Затем команда MoRI совместно с сообществом SGLang разработала KVCache Store Linker, интегрировав MoRI UMBP как бэкенд первого класса. Линкер соединяет унифицированное дерево radix SGLang напрямую с распределенным пулом DRAM. При совпадении префикса prefill извлекает страницы KV из DRAM вместо их пересчета.

Linker + MoRI UMBP решает все шесть проблем, указанных выше:

• Полностью совместно используемая DRAM между рангами DP и экземплярами моделей — что позволяет развертывание DP + round-robin через совместное использование KV-кэша между рангами DP.
• Прямой путь L1 ⇔ L3 без промежуточных накладных расходов; сам по себе это улучшает TTFT до 13% по сравнению с работой без MoRI UMBP.
• Глобальное управление KV — MoRI UMBP размещает и вытесняет KV на основе глобальной информации, что эффективнее, чем локальные политики на каждом ранге.
• Дедупликация + разделение загрузки/выгрузки по рангам, что снижает нагрузку на память и пропускную способность PCIe. Теперь prefill TP-N хранит и извлекает одну копию реплицированного MLA/DSA KV вместо N; при TP8 восемь ключей превращаются в один. Это умножает эффективную емкость DRAM и сокращает трафик хоста в той же пропорции.
• Послойная конвейерная загрузка, при которой MoRI UMBP скрывает дополнительные накладные расходы на запросы для каждого слоя за счет пакетной обработки, группировки слоев, API с поддержкой диапазонов и оптимизированного ядра GPU gather для загрузки KV с хоста на устройство.
• Кэш сохраняется при перезагрузках движка — в автономном режиме MoRI UMBP пул KV живет в отдельном процессе на узел, поэтому перезагрузки и обновления используют его повторно без прогрева.

Результаты

Эти исправления приносят пользу, даже когда уровень DRAM почти не используется. В тестовом прогоне с той же конфигурацией (1P1D TP8 + TP8, 16 графических процессоров MI355X, бюджет DRAM KV 600 ГБ и маршрутизатор consistent_hashing для аффинити кэша KV) HBM уже обслуживает около 95,6% токенов промпта при параллелизме 128–256, а уровень DRAM — менее 1%. Включение MoRI UMBP все равно дает прирост пропускной способности на GPU на +8,3% и снижение P90 TTFT на 35% при параллелизме 256, а также +2,7% и –34% при 128 (Рисунок 2). Этот прирост является архитектурным, а не следствием выгрузки данных, и он напрямую связан с двумя наблюдениями, приведенными выше:

• Неэффективное использование общей DRAM: при выключенном MoRI UMBP пул KV на хосте все равно заполняется (72% при параллелизме 128, 100% при 256), обслуживая при этом не более 0,1% токенов промпта. Включение MoRI UMBP превращает эту DRAM в единый общий пул.
• Косвенный путь передачи данных: поскольку уровень DRAM практически простаивает в обоих прогонах, прирост достигается за счет прямого пути линкера HBM ⇔ DRAM, который устраняет промежуточный уровень подготовки данных и связанные с ним накладные расходы на загрузку/выгрузку.

Рисунок 2: Пропускная способность на GPU в сравнении с интерактивностью P90 при выключенном и включенном MoRI UMBP, та же конфигурация, параллелизм 128 и 256. Чем выше и правее, тем лучше.

Достаточно большой кэш меняет топологию. Как только дедуплицированный уровень DRAM задействован, для префилла больше не требуется TP8 просто для хранения KV. При параллелизме 16–48 мы запускаем префилл TP4 с декодированием TP8 (12 GPU) вместо TP8 + TP8 (16 GPU). MoRI UMBP обслуживает 30%, 52% и 75% токенов промпта при параллелизме 16, 32 и 48, при этом менее 3% токенов пересчитываются. Пропускная способность на GPU возрастает на 24–34% при использовании на 25% меньшего количества GPU.

Рисунок 3: Слева: где префилл TP4 находит KV для каждого токена промпта под управлением линкера MoRI UMBP — кэш префикса GPU HBM, уровень DRAM MoRI UMBP или пересчет. По мере роста параллелизма и увеличения вытеснений из HBM, уровень DRAM поглощает разницу. Справа: пропускная способность на GPU для конфигурации от 15 сентября (префилл TP8 + декодирование TP8, 16 GPU) в сравнении с конфигурацией от 25 сентября (префилл TP4 + MoRI UMBP + декодирование TP8, 12 GPU).

Дальнейшая оптимизация

Наряду с этим команда AMD SGLang продолжает внедрять оптимизации для DeepSeek-V4-Pro-0813, охватывающие следующие области.

• Индексатор разреженного внимания FP4: индексатор DSA в DeepSeek-V4 оценивает весь контекст для каждого токена запроса на каждом слое и несет собственный KV для каждого токена. Запуск его на ядрах AITER FP4 на архитектуре gfx950 сокращает объем KV со 132 байт до 68 байт на токен — это позволяет увеличить количество параллельных последовательностей в HBM, снизить пропускную способность индексатора на шаг декодирования и уменьшить объем данных, передаваемых по каналу MoRI.
• Оптимистичный префилл с использованием спекулятивного KV, принадлежащего запросу: при дезагрегации PD запрос обычно ожидает декодирования для своей инициализации, прежде чем начнется префилл; при высоком параллелизме это «рукопожатие» превращается в чистое время ожидания в очереди. Запуск префилла в оптимистичном режиме, когда спекулятивный KV принадлежит запросу, а не предварительно зарезервированному слоту декодирования, сократил P90 TTFT на 27,7% при параллелизме 256. Устранение синхронизации с хостом при расширении слота префилла DSpark сократило P90 TTFT еще на 13–16% при параллелизме 128–256.
• Разделение K (split-K) для декодирования MLA для каждого потока: выбирает коэффициент split-K для каждого потока индексов вместо применения одной настройки к слоям, длины KV которых различаются на порядки.

Рисунок 4: Пропускная способность на GPU в сравнении с интерактивностью P90 на протяжении всей кампании по оптимизации. Базовая конфигурация от 21 августа использует 16 GPU (1P1D, TP8 + TP8) во всех точках; оптимизированные конфигурации выбирают 8, 12 или 16 GPU в зависимости от параллелизма и показывают пропускную способность, нормализованную на один GPU.

Итоги

Эта работа привела к двум результатам.

• Во-первых, в сравнении с системами NVIDIA Blackwell: в публичном рейтинге AgentX модель MI355X превосходит GB200 NVL72, B300 и GB300 NVL72 в выбранных рабочих точках, достигая превосходства до 5,6 раз по количеству токенов на доллар (см. таблицу после Рисунка 1).
• Во-вторых, в сравнении с нашими собственными результатами месячной давности: тот же бенчмарк, тот же параллелизм 192:

Рисунок 5: MI355X при параллелизме 192, сравнение базовой конфигурации от 21 августа и прогона от 25 сентября. Слева направо: пропускная способность на GPU, P90 TTFT (чем ниже, тем лучше) и P90 интерактивность.

Пиковая пропускная способность на GPU также выросла с 22,9 тыс. до 55,8 тыс. (в 2,4 раза) при параллелизме 256.

В агентных рабочих нагрузках 96% токенов промпта уже вычислены, поэтому стоимость одного токена определяется системой, которая управляет тем, где эти токены хранятся. MoRI UMBP — это и есть такая система: она превращает DRAM в дедуплицированный пул KV, который является общим для разных экземпляров и сохраняется после перезапуска движка, будучи напрямую подключенным к дереву radix в SGLang через KVCache Store Linker.

Первым пунктом в дорожной карте на июль было завершение интеграции MoRI UMBP; теперь это выполнено. Следующий шаг — внедрение MoRI UMBP в более широкую экосистему, например, ATOM, vLLM, llm-d.

Благодарности

Мы благодарим сообщество SGLang за проверку дизайна и быстрое внесение изменений в основной код, SemiAnalysis за бенчмарк AgentX и инфраструктуру CI InferenceX, а также команды AMD MoRI, SGLang и AITER.

Ссылки

• SemiAnalysis - Бенчмарк AgentX и панель мониторинга InferenceX
• vLLM - AgentX
• AMD - Переосмысление агентного ИИ с нуля для GPU AMD совместно с Moonshot AI ("Что такое UMBP")