AIREITERvLLM Humming выглядит сильным кандидатом для высококонкурентного запуска квантованных MoE-моделей на ускорителях класса Hopper. Но публичные бенчмарки не позволяют считать его универсальной заменой бэкенда. Тесты на H100 с group-32 и декодирование batch-1 на Ampere хорошо показывают, почему проверять нужно именно свою связку модели, GPU, формата и размера батча.
Коротко: Humming ускоряет не всё подряд
Humming — библиотека JIT-компилируемых GEMM-ядер для квантованного инференса, выпущенная сообществом vLLM совместно с Ant Group. Она рассчитана на плотные и mixture-of-experts (MoE) нагрузки, поддерживает несколько форматов квантования и поколения GPU NVIDIA. В официальном анонсе заявлено ускорение отдельных ядер до 5 раз и прирост сквозной производительности MoE на 14%–43%. Однако эти цифры относятся к конкретным сочетаниям модели, оборудования, формата и уровня параллелизма (анонс vLLM).
Моё практическое правило внедрения выглядит так:
- Сначала тестируйте Humming на MoE-сервинге W4A8/W4A16 с большими батчами или высокой конкуренцией, если используются поддерживаемые конфигурации Hopper или более новых поколений.
- Не рассчитывайте на ускорение заранее при декодировании batch-1, на старых GPU Ampere и при необычном group-wise масштабировании.
- Оставляйте запасной вариант: в текущих issue встречаются ошибки маршрутизации по размерам и медленные пути, зависящие от бэкенда.
В одном независимом отчёте по DeepSeek-V4.1-Flash удалось получить 5 856 выходных токенов/с на настроенном базовом vLLM, 12 802 токена/с с data-parallel attention и 17 634 токена/с с модифицированными ядрами Humming W4A8 на одном узле с четырьмя GH200 (инженерный отчёт). Для этого потребовались исправление ядра и дополнительная настройка, поэтому результат говорит о перспективах конкретного класса нагрузок, а не обещает такой показатель сразу после установки.
Что Humming меняет в развёртывании vLLM
Humming переносит умножение квантованных матриц на гибкий слой JIT-ядер, который обслуживает GEMM-пути для плотных и MoE-моделей. Проект рассчитан на архитектуры NVIDIA начиная с Turing и поддерживает несколько низкобитных форматов (репозиторий Humming).
В упомянутом тесте на Hopper Marlin сначала деквантизировал веса FP4 в BF16, тогда как Humming преобразовывал веса FP4 в FP8 непосредственно внутри SM и использовал умножение на FP8 tensor core. Это преимущество проявилось только после того, как декодирование стало ограничиваться вычислениями. В других сценариях узким местом могут оказаться трафик памяти, раскладка тайлов, обработка scale-факторов, накладные расходы на запуск и давление на регистры.
Где ускорение заметно, а где исчезает
Публичные результаты лучше воспринимать не как одну рекламную цифру, а как карту границ производительности.
MoE с высокой конкуренцией: самый убедительный сценарий
В официальном примере для DeepSeek-V4.1-Flash сравниваются Marlin W4A16 и Humming W4A8 на восьми GPU H20. Сквозная производительность MoE выросла на 14%–43%, причём больший прирост наблюдался при более высокой конкуренции. Пользователь, опубликовавший этот бенчмарк, привёл конкретное сравнение: 442 против 634 выходных токенов/с при concurrency 64, отдельно отметив, что изменился и формат квантования (обсуждение пользователя).
Это хороший аргумент в пользу Humming как перспективного пути для сервинга, но не доказательство того, что одно и то же ядро автоматически даст такой же прирост при неизменном формате.
H100, W4A8 и group-32: важное предупреждение
В issue #38 для Humming тестировались веса MXFP4, активации MXFP8 и scale-факторы group-32 на H100. Все сравниваемые варианты выдавали корректный результат, но fused-путь на указанных размерах оказался значительно медленнее. Для (4096,3072,4096) fused Humming потребовал 4.969 мс против 0.580 мс у базового QDQ-пути; для (4096,14336,4096) — 22.298 мс против 1.256 мс (issue #38).
Позже в issue зафиксировали локальную настройку выше 500 TFLOPS, а экспериментальная реализация достигла примерно 580–665 TFLOPS благодаря дополнительной предобработке и изменённому хранению весов. Гранулярность scale-факторов, выбор тайлов, давление на регистры и предобработка способны полностью изменить итоговый результат.
SM80 и декодирование одного запроса: не переносите выводы на Ampere
В issue #72 сообщается о слабой загрузке INT3 на NVIDIA SM80 при декодировании с M=1. На CMP 170HX измеренное ядро Humming показало около 691 ГБ/с при примерно 1 591 ГБ/с пиковой пропускной способности HBM — то есть 43.4% утилизации. Для сравнения, на RTX 5070 Ti SM120 получили около 753 ГБ/с при пиковых 827 ГБ/с, или примерно 91% (issue #72).
В том же отчёте приведены результаты репозитория для A800: 692.4 ГБ/с при M=1, что составляет лишь 34.0% от заявленного пика в 2 039.04 ГБ/с. В аналогичном сравнении обычный BF16 достиг 1 232.3 ГБ/с.
«Может ли текущий путь Humming для INT3 на SM80 быть неоптимальным для этой нагрузки?» —
yangfangyunyun, issue #72 в vLLM Humming
Установка и безопасный первый тест
В официальных материалах указано, что начиная с vLLM 0.29.0 установки для CUDA включают Humming как зависимость. Для MoE-пути используйте --moe-backend humming, для поддерживаемых линейных слоёв — --linear-backend humming, либо документированную конфигурацию квантования Humming для конкретной модели (документация vLLM по квантованию). Прежде чем переносить флаг между архитектурами, проверьте документацию к релизу и модели.
Начните с контролируемого теста:
- Зафиксируйте версии vLLM, CUDA и PyTorch, архитектуру GPU, квантование чекпойнта и размеры модели.
- Сделайте одинаковыми длину промпта, длину вывода, уровень конкуренции и число повторов.
- Сравните текущий бэкенд с Humming, используя одну и ту же команду запуска и добавляя соответствующий флаг бэкенда.
- Измерьте токены/с на выходе, TTFT, задержку между токенами, объём памяти GPU и время запуска/JIT-прогрева.
- Повторите тест после прогрева кэша ядер, а затем отдельно проверьте batch 1 и производственную конкуренцию.
- Предусмотрите автоматический или ручной откат для неподдерживаемых размеров и случаев, когда бэкенд не выбирается.
Одного прироста пропускной способности недостаточно, если ухудшились TTFT, хвостовая задержка, стоимость прогрева или потребление памяти. Проект perf-eval для vLLM рекомендует YAML-рецепты, повторные запуски, агрегацию по медиане и фиксированные длины входа и выхода, чтобы результаты можно было корректно сравнивать (репозиторий perf-eval).
Маршрутизация бэкендов может заблокировать рабочую конфигурацию Humming
Отдельная issue в vLLM хорошо показывает, зачем нужны тесты с откатом. В issue #60700 у MoE-чекпойнта compressed-tensors W4A8 промежуточный размер равнялся 640. CUTLASS требовал размеров, кратных 256, тогда как Humming мог обработать проверяемую форму. Но безусловная проверка запускалась ещё до загрузки выбранного бэкенда, поэтому явный флаг --moe-backend humming тоже приводил к ошибке.
В патче автора issue проверка была ограничена CUTLASS. После этого все 62 шарда загрузились на двух GPU H100 NVL, а тест показал на 12%–50% меньший TTFT и на 2%–13% более высокую системную пропускную способность по сравнению с исходной конфигурацией CUTLASS (issue #60700). На момент проверки issue оставалась открытой, а PR #60711 предлагал исправление маршрутизации.
Поэтому неудачный запуск Humming может быть связан не с проблемой ядра, а с проверкой возможностей внутри vLLM. Перед тем как отбрасывать конфигурацию, проверьте выбранный бэкенд, ограничения по размерам и статус исправления.
Таблица решений для операторов
| Ваша нагрузка | Решение по Humming | Почему |
|---|---|---|
| MoE с высокой конкуренцией на Hopper/GH200 | Тестируйте в числе первых | В независимом отчёте после исправлений и настройки получили 17 634 токена/с. |
| Декодирование в стиле DeepSeek с большими батчами | Сильный кандидат | Выполнение на FP8 tensor core может помочь, когда MoE GEMM упирается в вычисления. |
| Декодирование batch-1 или небольших батчей на SM80 | Не рассчитывайте на ускорение заранее | В issue #72 для проверенных INT3-путей сообщается об эффективной пропускной способности 34%–43%. |
| Масштабирование активаций group-32 на H100 | Проведите узкий бенчмарк по набору размеров | Issue #38 показывает серьёзные просадки на одном из fused-путей. |
| MoE W4A8 с размерами, не кратными 256 | Проверьте версию vLLM и исправления маршрутизации | Общие проверки могут заблокировать Humming ещё до загрузки весов. |
| Продакшен без возможности менять исходный код | Используйте только после показательного сравнительного теста | Для некоторых независимых результатов потребовались изменения ядер или эвристик. |
FAQ
Какие GPU поддерживает Humming?
Проект рассчитан на GPU NVIDIA начиная с Turing и документирует несколько путей квантования. Но сама поддержка не означает, что каждый формат и сценарий нагрузки одинаково хорошо оптимизированы: для SM80 и необычных вариантов масштабирования нужны отдельные бенчмарки.
Нужен ли Humming заранее квантованный чекпойнт?
Humming — библиотека инференс-ядер, а не универсальный инструмент квантования. В рассмотренных сценариях используются чекпойнты с совместимыми квантованными весами и схемами активаций, поэтому перед запуском проверьте формат модели в документации и репозитории vLLM.
Humming быстрее любого другого бэкенда vLLM?
Нет. Он быстрее на отдельных квантованных нагрузках, особенно в описанных сценариях MoE с высокой конкуренцией. Результат зависит от архитектуры, формата, размеров, группировки scale-факторов и размера батча.
Практический вывод простой: Humming способен заметно ускорить хорошо подобранный квантованный сервис на vLLM, но короткий воспроизводимый сравнительный тест — обязательная часть внедрения. Публичные результаты слишком сильно зависят от конкретной конфигурации.