vLLM meets Transformers: Нативная скорость без компромиссов

Долгие годы экосистема больших языковых моделей (LLM) делилась на два лагеря. С одной стороны, была библиотека Transformers от Hugging Face — эталонная, понятная и поддерживающая сотни архитектур. Она стала стандартом де-факто для исследователей и разработчиков, желающих быстро прототипировать модели, обучать их и делиться результатами. С другой стороны, существовали специализированные движки инференса, такие как vLLM, SGLang или MLX, которые предлагали экстремальную оптимизацию, непрерывное батчингование (continuous batching) и кастомные ядра внимания для максимальной пропускной способности. Обычно, чтобы получить скорость от vLLM, автору модели приходилось писать отдельную, сложную реализацию архитектуры, дублируя логику и теряя совместимость с обучающими пайплайнами.

Эта дихотомия создавала значительный барьер для входа. Каждое новое архитектурное решение требовало не только реализации в Transformers, но и ручного портирования в vLLM с учетом всех тонкостей параллелизма, слияния операций (fused kernels) и управления памятью. Это замедляло внедрение новых идей и создавало фрагментацию. Однако ситуация кардинально изменилась с выходом обновления, которое делает бэкенд Transformers в vLLM не просто альтернативой, а лидером по производительности для широкого спектра архитектур.

Теперь, благодаря интеграции, основанной на статическом анализе графов вычислений, модели, написанные в стиле Transformers, могут запускаться в vLLM с той же скоростью, что и их «ручные» нативные реализации. Это означает, что авторы моделей могут сосредоточиться на создании качественных архитектур, а не на низкоуровневой оптимизации инференса, получая при этом «ультрабыстрый» результат автоматически. Давайте разберем, как это работает, какие архитектуры поддерживаются и что это значит для разработчиков, работающих с LLM в реальных условиях.

01От теории к практике: Эволюция интеграции

Чтобы понять масштаб изменений, нужно回顾 (вернуться) к тому, как все работало раньше. Библиотека Transformers стала референсной библиотекой для машинного обучения, поддерживая более 450 архитектур через единый, последовательный API. Ее главная философия — самодостаточность и понятность кода. Разбирая код модели в Transformers, разработчик легко понимает, как работает архитектура, и может перенести ее в другие фреймворки. Однако перенос в движки инференса, такие как vLLM, всегда был «узким горлышком».

Ранее интеграция Transformers в vLLM была возможна, но она фокусировалась преимущественно на оптимизации одного компонента — механизма внимания (attention). Подключая реализацию внимания от vLLM к модели Transformers, можно было получить прирост скорости, но это не решало всех проблем. Инференс — это многомерная задача. Параллелизм между GPU, компиляция, слияние слоев (fused kernels) и управление памятью требуют комплексного подхода, который обычно обеспечивался только кастомными, написанными вручную реализациями моделей внутри vLLM.

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

02Результаты бенчмарков: Встреча с реальностью

Теория — это хорошо, но в индустрии LLM правят бал цифры. Команда Hugging Face провела масштабное сравнение нового бэкенда Transformers с нативными, «ручными» реализациями vLLM. Для тестов были выбраны три совершенно разных модели семейства Qwen3, которые покрывают широкий спектр сценариев использования: от легких моделей до гигантских MoE-архитектур.

Первый тест включал плотную модель Qwen3-4B, запущенную на одном GPU. Это типичный сценарий для edge-устройств или легких сервисов. Второй тест задействовал более тяжелую модель Qwen3-32B с использованием тензорного параллелизма (tensor parallelism) на двух GPU. Это уже уровень серьезного продакшена, где важно эффективно распределять вычисления. Третий и самый впечатляющий тест — модель Qwen3-235B-A22B-FP8 (Mixture-of-Experts) с использованием FP8 квантования. Она запускалась на ноде с 8 GPU H100, используя как параллелизм данных (data parallelism), так и параллелизм экспертов (expert parallelism). Это крайняя граница возможного для современных кластеров.

Результаты оказались однозначными: бэкенд Transformers в vLLM не просто «догнал» нативные реализации, но и в некоторых метриках превзошел их. Пропускная способность (throughput) на всех трех архитектурах была либо равна, либо выше, чем у кастомного кода. Это доказывает, что автоматизированная оптимизация через статический анализ графов может конкурировать с ручной работой экспертов, которые годами оттачивали детали конкретных архитектур.

03Как это работает: Магия Torch.fx и AST

Секрет такой высокой производительности кроется в том, как именно происходит трансформация модели. Раньше оптимизации применялись точечно, часто только к слоям внимания. Новая система использует torch.fx — инструмент для статического анализа графов вычислений PyTorch. Процесс можно описать как интеллектуальное сканирование кода модели.

Система проходит по графу вычислений модели и ищет известные паттерны, которые можно оптимизировать. Как только паттерн найден, система использует абстрактное синтаксическое дерево (AST) для манипуляции исходным кодом. Она не просто подменяет функции, а переписывает операции «на лету» (in-place), создавая оптимизированную версию графа. Это позволяет применять сложные слияния операций (fused operations), которые ранее были доступны только при ручном написании кода.

Например, для моделей типа Mixture-of-Experts (MoE) система идентифицирует паттерны, связанные с маршрутизацией экспертов, и сливает их в оптимизированные ядра, используемые для экспертного параллелизма. Для плотных моделей она находит блоки линейных преобразований и объединяет их в MergedColumnParallelLinear и QKVParallelLinear. Эти слияния критически важны, так как они уменьшают количество вызовов ядра GPU и улучшают использование памяти.

Важнейшим аспектом является то, что manipulated (модифицированные) модели остаются полностью совместимыми с torch.compile и CUDA Graphs. Это означает, что оптимизации, примененные на уровне графа, не мешают дальнейшей компиляции кода в эффективный машинный код. Вы получаете лучшее из двух миров: гибкость и читаемость Transformers с производительностью низкоуровневого C++/CUDA кода.

04Параллелизм и масштабируемость

Одной из самых сильных сторон новой интеграции является ее способность автоматически выводить планы параллелизма. В традиционных подходах разработчик должен явно указывать, как модель должна быть распределена по GPU. В новом бэкенде система анализирует структуру модели и может автоматически определить, какие слои можно распараллелить по тензорам (TP) или по конвейеру (PP).

Если список блоков декодера легко идентифицируем, система может вывести план конвейерного параллелизма. Это особенно важно для очень больших моделей, где распределение вычислений по множеству GPU является единственным способом уместить модель в память. Для MoE-моделей, таких как Qwen3-235B, это означает автоматическое применение экспертного параллелизма, что ранее требовало глубокого понимания внутренней структуры модели и ручного написания кода маршрутизации.

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

05Единый код для обучения и инференса

Еще одно фундаментальное преимущество новой архитектуры — это устранение разрыва между обучением и инференсом. Модели, написанные в стиле Transformers, изначально предназначены для обучения. Они поддерживают обратное распространение ошибки (backpropagation), градиенты и все необходимые компоненты для RLHF (Reinforcement Learning from Human Feedback) и других продвинутых техник дообучения.

Ранее, чтобы запустить модель на инференсе с высокой скоростью, приходилось писать вторую версию кода, которая часто не поддерживала обучение. Это создавало проблему «разрыва в знаниях»: оптимизации, примененные для инференса, могли быть потеряны при возврате к обучению, или наоборот. Теперь одна и та же кодовая база используется для обоих этапов. Вы можете обучить модель, провести оценку (evals), запустить rollout для RL, а затем развернуть ее для инференса, используя тот же самый код, который автоматически оптимизируется для скорости.

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

06Ограничения и будущие планы

Несмотря на впечатляющие результаты, важно отметить текущие ограничения. На данный момент модели, использующие линейное внимание (linear attention), не поддерживаются. Однако команда активно работает над добавлением этой поддержки, так как линейное внимание становится все более популярным для обработки длинных контекстов. Также стоит отметить, что кастомные модели, код которых хранится в репозиториях Hugging Face, могут не работать, если они не написаны в соответствии с требованиями совместимости. Это связано с тем, что система опирается на стандартные паттерны, которые должны быть четко выражены в коде модели.

Для разработчиков, которые хотят поэкспериментировать, доступен полный воспроизводимый скрипт бенчмарка в виде gist. Это позволяет каждому проверить производительность на своем оборудовании и убедиться в преимуществах нового подхода. Команда также анонсировала детальную техническую статью, которая глубже погрузит читателей в механизмы оптимизации и объяснит, как именно происходит манипуляция с моделью для достижения нативной скорости.

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

Для разработчиков и компаний, работающих с LLM, это обновление означает несколько ключевых изменений. Во-первых, снижается порог входа для развертывания больших моделей. Больше не нужно нанимать узких специалистов по оптимизации инференса для каждой новой архитектуры. Достаточно иметь модель, написанную в стиле Transformers, и использовать флаг --model-impl transformers.

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

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

В заключение, интеграция бэкенда Transformers в vLLM знаменует собой новый этап в развитии экосистемы LLM. Она стирает границы между обучением и инференсом, между прототипированием и продакшеном. Теперь скорость больше не требует компромиссов в удобстве использования. Это шаг к более демократичной и эффективной разработке искусственного интеллекта, где фокус смещается с борьбы за каждый миллисекунду на создание более умных и полезных моделей.

Мы рекомендуем всем, кто использует Hugging Face модели, обновить свои зависимости и протестировать новую функциональность. Возможно, именно это обновление станет тем самым толчком, который позволит вам запустить вашу любимую модель быстрее и эффективнее, чем когда-либо прежде.

Источник: Hugging Face Blog ↗