Исследование · AMD ROCm Blog
UltraQuant ускоряет длинные сессии под нагрузкой — MTP помогает до определённого предела
В эксперименте AMD на восьми MI355X UltraQuant дал на 29% большую скорость генерации при воспроизведении длинных агентных сессий Qwen3.8 с 32 одновременными запросами, чем сильнейший проверенный восьмибитный вариант кеша. Дополнительный механизм MTP, полезный при меньшей нагрузке, на этом пике уже ухудшал результат.
Что это меняет для покупателя
Исследование предлагает конкретный выбор настройки для больших локальных агентных систем на MI355X. Сжатие кеша и MTP решают разные задачи; режим с самой низкой задержкой при небольшом потоке может оказаться неудачным, когда одновременно работают многие длинные сессии.
Сжать веса и сжать разговор — разные действия
В публикации AMD от 25 сентября 2026 года исследуется UltraQuant для Qwen3.8-2.4T-A95B с весами MXFP4. MXFP4 уменьшает представление весов модели, а UltraQuant отдельно переводит KV-кеш в четырёхбитный формат. Кеш хранит промежуточные данные уже обработанного текста. Для длинной агентной работы это самостоятельная статья потребления памяти: переписка, результаты инструментов и продолжение сессии добавляют контекст, даже если очередной ответ получается коротким.
Исследованная Qwen3.8 имеет 2.4 триллиона параметров, примерно 95 миллиардов активных на токен и окно 262K. Активная часть MoE, модели с выбираемыми экспертами, не равна всем весам, которые нужно разместить. Есть ещё одна важная особенность: традиционный KV-кеш держат только 23 из 92 слоёв, остальные используют лёгкое рекуррентное состояние. Поэтому результат нельзя механически переносить на любую модель: доля архитектуры, к которой применимо такое сжатие, здесь вполне определённая.
Почему четыре бита действительно уменьшают работу
UltraQuant сохраняет группу из 32 значений кеша в 17 байтах, тогда как восьмибитный вариант занимает 32 байта. Смысл для генерации прост: меньше данных приходится читать из памяти. Но экономию можно потерять, если перед вычислением каждое значение нужно сложно восстанавливать. В описанном пути MI355X принимает FP4 непосредственно в матричные операции, а масштабирование встроено в соответствующую инструкцию. Поэтому компактное представление сохраняется до вычислительного ядра.
Перед сжатием применяется преобразование Уолша — Адамара, распределяющее резко выделяющиеся значения между каналами. Это помогает разместить данные на четырёхбитной числовой сетке. Для покупателя важна вся цепочка: подготовка распределения, формат хранения и поддержка формата оборудованием. Одного заявления о четырёхбитном кеше недостаточно, чтобы ожидать такой же эффект на другой карте. Специфика UltraQuant в этом исследовании связана с нативным вычислительным путём MI355X, а не только с уменьшенным размером.
Что именно сравнивала AMD
Авторы воспроизводили агентную трассу SemiAnalysis InferenceX: длинные общие начала запросов, входы от десятков до сотен тысяч токенов, короткие ответы и много ходов. Использовались восемь MI355X, vLLM v0.19.2rc0 с исследуемыми ядрами UltraQuant, AITER 0.1.16.post3 и FlyDSL 0.2.0. Окно составляло 262K, повторное использование общего префикса было включено. Доля попаданий в префиксный кеш держалась на уровне 91–95% у сравниваемых вариантов; выгрузка KV-кеша не использовалась.
При 32 одновременных запросах UltraQuant показал суммарно 434 токена в секунду и 58 мс между токенами. Сравниваемый восьмибитный ROCm-FA дал 338 токенов в секунду и 77 мс: преимущество составило 29% по скорости и 24% по задержке. AMD выбирала более сильный из двух проверенных восьмибитных путей для соответствующей нагрузки. При лёгкой нагрузке различие исчезало. Это результат для насыщенного длинными сессиями потока с высоким повторным использованием префиксов, а не прогноз скорости одиночного короткого чата.
Почему MTP нельзя просто включить навсегда
MTP, предсказание нескольких токенов, предлагает несколько кандидатов и проверяет их совместно. В эксперименте его добавление к UltraQuant уменьшало задержку между токенами ещё на 12–22% при одновременности до 16 включительно. При 32 оба варианта с MTP ухудшались. Авторы объясняют это дополнительной работой проверки: на небольшой нагрузке сокращение последовательных шагов выгодно, а на пике цена проверки становится существенной. Получается конкретный выбор режима по ожидаемой одновременности, а не универсально полезный переключатель.
Текущий исследованный путь UltraQuant также ещё не использовал объединённое многотокенное ядро: кандидаты обрабатывались как отдельные запросы к общему кешу, без повторного использования одного чтения между их позициями. Восьмибитный путь MTP использовал объединённое ядро AITER. Авторы относят такое объединение для UltraQuant и включение исследованной реализации в основную ветку vLLM к будущим работам. Следовательно, измеренный экспериментальный путь нельзя выдавать за уже доступную стандартную возможность любого стабильного пакета.
Какой выбор следует из результатов
Качество AMD проверяла на GPQA-Diamond из 198 вопросов и фиксированном подмножестве SWE-bench Lite из 100 задач по исправлению кода. Для оценок использовалась температура 1.0. Числа у конфигураций различались; авторы считали различия совместимыми с вариативностью выборки. В SWE-bench каждая конфигурация прошла набор один раз. Это полезное свидетельство для исследованного пути, но оно не устанавливает одинаковую точность на произвольных репозиториях или типах многошаговых задач.
Вывод касается настройки большого локального агентного сервера на MI355X: UltraQuant стоит рассматривать для длинных перекрывающихся сессий, а MTP выбирать по режиму нагрузки. Если расчётный пик похож на 32 одновременных запроса в исследовании, оснований постоянно держать MTP включённым этот результат не даёт. Для меньшей одновременности он показал дополнительную пользу. Здесь интересен именно выбор вычислительного режима: меньше последовательных шагов и меньше чтений памяти помогают в разных условиях, поэтому настройки должны соответствовать реальному потоку работы.
Что проверить до выбора системы
- Какую долю запросов составляют новые сессии без общего сохранённого начала?
- Какие ошибки исправления кода должны считаться неприемлемыми независимо от скорости?
- Как переключение MTP влияет на уже открытые сессии в выбранной реализации?
- Сохраняется ли нужное время ответа, когда рядом запускается другая серверная задача?
Выводы для покупателя — наша редакционная интерпретация. Публикация не подтверждает скорость или совместимость конкретной сборки из каталога.