Hugging Face ускорила бэкенд transformers для vLLM до нативной скорости вывода

Библиотека transformers от Hugging Face, эталонная библиотека для описания архитектур моделей машинного обучения: она поддерживает более 450 архитектур через единый API, и её код специально написан так, чтобы реализация каждой модели была самодостаточной и понятной для чтения. Именно поэтому другие движки вывода, vLLM, SGLang, MLX, llama.cpp и другие, используют код из transformers как референс, когда переносят архитектуру под себя. В прошлом году Hugging Face встроила transformers как бэкенд прямо в vLLM: это позволило авторам моделей запускать свои LLM и VLM (модели, которые работают и с изображениями) внутри vLLM без отдельного портирования, код модели брался из transformers, а vLLM отвечал за оптимизированные техники вывода (инференса): непрерывный батчинг запросов и кастомные ядра внимания.

До сих пор этот бэкенд в основном ускорял только механизм внимания, подставляя вместо стандартной реализации оптимизированную версию из vLLM. Но многое другое, что определяет максимальную скорость на конкретном железе, способ распараллеливания между GPU, компиляция графа вычислений, слияние операций в отдельные ядра, по-прежнему требовало отдельной, написанной вручную «нативной» реализации именно под vLLM. Если авторам модели была нужна максимальная скорость, они всё равно писали кастомный код под vLLM. Новая версия бэкенда transformers меняет это: теперь на лету, во время запуска, она сама применяет к поддерживаемым архитектурам те же слияния операций уровня вывода, которые раньше давал только ручной порт, приближая скорость к «нативной» реализации vLLM.

Технически бэкенд использует torch.fx для статического анализа вычислительного графа модели и поиска в нём известных шаблонов операций, которые можно оптимизировать. Когда шаблоны найдены, модуль ast (работа с абстрактным синтаксическим деревом Python) переписывает соответствующие операции прямо в коде. Это даёт: слияние операций «много в одну» в оптимизированные ядра vLLM, например, ядра для экспертного параллелизма (Expert Parallelization) в моделях со смесью экспертов (Mixture-of-Experts, MoE); распознавание блоков vLLM MergedColumnParallelLinear и QKVParallelLinear, по которым автоматически выводится план тензорного параллелизма (Tensor Parallelism), а если список декодер-блоков модели легко определить, то и план конвейерного параллелизма (Pipeline Parallelism). При этом изменённые модели остаются полностью совместимы с torch.compile и CUDA Graphs, как и специализированные реализации vLLM. А в отличие от «нативных» реализаций vLLM, реализации на transformers по-прежнему годятся для обучения: один и тот же код модели можно использовать и для обучения, оценки и обучения с подкреплением, и для быстрого вывода.

Hugging Face сравнила новый бэкенд напрямую с вручную написанными нативными реализациями vLLM на трёх разных конфигурациях моделей Qwen3: плотная (dense) модель на 4 млрд параметров на одном GPU, плотная модель на 32 млрд параметров с тензорным параллелизмом и модель со смесью экспертов на 235 млрд параметров в формате FP8 с сочетанием параллелизма по данным и экспертного параллелизма на одном узле с 8×H100. Каждую модель тестировали в трёх условиях, одинаковых во всём, кроме используемого кода: «native», эталонная нативная реализация vLLM (флаг --model-impl vllm), «after», бэкенд transformers с новым патчем, «before», тот же бэкенд без патча. Полный воспроизводимый скрипт для бенчмарка Hugging Face выложила в открытом доступе на GitHub (файл benchmark.sh). По словам авторов поста, результат таков: версия «after» достигает нативной скорости вывода vLLM для совместимых архитектур, без единой строчки кода, написанной вручную специально для оптимизации вывода.

Включается новый режим одним флагом, --model-impl transformers в команде vllm serve, и он совместим с обычными флагами параллелизма (--tensor-parallel-size, --data-parallel-size, --enable-expert-parallel и другими), так что остальную конфигурацию запуска менять не нужно. Перед использованием предлагается обновить пакет: uv pip install --upgrade vllm --torch-backend auto. Есть ограничения: модели с linear attention (линейным механизмом внимания) пока не поддерживаются, но поддержку обещают добавить в ближайшее время; кастомные модели, код которых лежит только в отдельном репозитории на Hugging Face Hub, а не в самой библиотеке transformers, с высокой вероятностью не заработают, поскольку такой код не обязательно написан по нужным соглашениям. Hugging Face анонсировала отдельный, более подробный технический разбор того, как устроены эти методы оптимизации вывода.

Ключевые факты

Hugging Face обновила бэкенд, который запускает модели transformers внутри vLLM (флаг --model-impl transformers): теперь он сам на лету сливает операции в оптимизированные ядра и приближается по скорости к нативным реализациям vLLM
Тестировали на трёх конфигурациях Qwen3: плотная модель на 4 млрд параметров на одном GPU, плотная модель на 32 млрд параметров с тензорным параллелизмом и MoE-модель на 235 млрд параметров (FP8) с параллелизмом по данным и экспертами на узле с 8×H100
Технически используются torch.fx (анализ графа модели) и ast (переписывание кода операций), так распознаются шаблоны для слияния в ядра: экспертный параллелизм для MoE, тензорный и конвейерный параллелизм через блоки MergedColumnParallelLinear и QKVParallelLinear
Изменённые модели остаются совместимы с torch.compile и CUDA Graphs, а один и тот же код теперь годится и для обучения/оценки, и для быстрого вывода, в отличие от отдельных «нативных» реализаций vLLM
Ограничения: модели с linear attention пока не поддерживаются (обещают добавить), а кастомный код моделей из репозиториев на Hugging Face Hub, скорее всего, не заработает

Почему это важно

transformers, эталонная библиотека Hugging Face для описания архитектур моделей (450+ архитектур на едином API), на код которой опираются и другие движки вывода, vLLM, SGLang, MLX, llama.cpp. Год назад её встроили как бэкенд в vLLM, что позволило запускать модели без отдельного портирования, но раньше это ускоряло в основном механизм внимания, за максимальной скоростью авторы моделей всё равно шли писать отдельную, вручную оптимизированную реализацию под vLLM для каждой архитектуры. Новый бэкенд закрывает именно этот разрыв: он сам на лету находит и применяет те слияния операций, которые раньше давал только ручной порт, и выходит на нативную скорость vLLM для поддерживаемых моделей. Дополнительный эффект, один и тот же код модели теперь можно использовать и для обучения, и для быстрого вывода, вместо того чтобы поддерживать две отдельные кодовые базы.

Кому это важно

Инженерам и командам, которые обслуживают LLM и VLM через vLLM и раньше были вынуждены вручную писать и поддерживать отдельный «нативный» порт модели под vLLM ради максимальной скорости, особенно для только что вышедших архитектур, у которых такого порта ещё нет. Авторам моделей, которые публикуют новые архитектуры на Hugging Face и хотят, чтобы они сразу обслуживались в vLLM на полной скорости, не дожидаясь, пока кто-то вручную портирует их. Исследователям, которым нужен один и тот же код модели и для обучения/RL, и для быстрого вывода.

Как это применить

Обновить vLLM командой uv pip install --upgrade vllm --torch-backend auto и добавить флаг --model-impl transformers в команду vllm serve, он совместим с обычными флагами параллелизма, например: vllm serve Qwen/Qwen3-4B --model-impl transformers (одна GPU); vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2 (тензорный параллелизм на 2 GPU); vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel (MoE-модель, параллелизм по данным и экспертам на 8 GPU); при нехватке памяти на узле можно добавить --max-model-len 8192. Учитывать ограничения: модели с linear attention пока не поддерживаются, а кастомный код моделей из отдельных репозиториев на Hugging Face Hub, скорее всего, не заработает.

Можно ли доверять

Это первоисточник, инженерный пост самой команды Hugging Face о собственном изменении в vLLM, а не независимая проверка со стороны. В плюс: методология сравнения описана явно (три условия, native/before/after, отличающиеся только используемым кодом) и подкреплена воспроизводимым скриптом бенчмарка, который Hugging Face выложила в открытом доступе (benchmark.sh), так что результаты можно перепроверить самостоятельно. Публикация свежая (материалу чуть больше суток на момент разбора), внешних обсуждений и независимых замеров скорости пока не появилось.

Риски и подводные камни

Ускорение работает не для всех моделей: явно указано, что архитектуры с linear attention пока не поддерживаются, а кастомные модели, чей код существует только в репозитории на Hugging Face Hub (а не слит в саму библиотеку transformers), с высокой вероятностью не заработают, потому что такой код не обязательно написан по нужным соглашениям. Приведённое сравнение скорости, собственные измерения авторов фичи, без независимой стороны, которая бы их перепроверила. Сама фича только что выпущена, и Hugging Face прямо говорит, что готовит отдельный, более подробный технический разбор, то есть часть деталей о том, как именно работает оптимизация, ещё не опубликована.

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

— , блог Hugging Face, «Native-speed vLLM transformers modeling backend»