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

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

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

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

01От внимания к комплексной оптимизации

Чтобы понять масштаб достижения, нужно回顾 (вернуться) к тому, как работала предыдущая интеграция. Изначально фокус был сделан на оптимизации механизма внимания (attention). vLLM подменял стандартные операции внимания из Transformers на свои собственные, более эффективные ядра. Это давало прирост скорости, но не использовало весь потенциал аппаратного обеспечения.

Инференс — это многомерная задача. Помимо внимания, критическую роль играют:

• Параллелизм: Распределение вычислений между несколькими GPU (Tensor Parallelism, Pipeline Parallelism, Data Parallelism).
• Компиляция: Использование torch.compile и CUDA Graphs для минимизации накладных расходов Python.
• Fused Kernels: Объединение нескольких операций в один вызов ядра, чтобы сократить количество обращений к памяти GPU.

Предыдущие решения часто упускали из виду эти аспекты, полагаясь на то, что оптимизация внимания даст достаточный буст. Однако для больших моделей, особенно Mixture-of-Experts (MoE), эти факторы становятся определяющими. Новая архитектура бэкенда Transformers в vLLM решает эту проблему комплексно, применяя оптимизации на уровне всего графа вычислений модели, а не только отдельных слоев.

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

Чтобы доказать эффективность нового подхода, команда провела серию строгих тестов. Они сравнили производительность моделей Qwen3 (разных архитектур) при запуске через нативные реализации vLLM и через новый бэкенд Transformers. Тестирование проводилось на мощном кластере из 8 GPU NVIDIA H100.

Были протестированы три совершенно разных сценария:

1. Qwen3-4B (Dense): Запуск на одном GPU. Это типичный сценарий для edge-устройств или легких сервисов.
2. Qwen3-32B (Dense): Запуск с использованием Tensor Parallelism (TP) на 2 GPU. Здесь важно, как модель делит веса и вычисления между устройствами.
3. Qwen3-235B-A22B-FP8 (MoE): Самая сложная задача. Модель с 235 миллиардами параметров, использующая архитектуру Mixture-of-Experts. Запуск осуществлялся с использованием Data Parallelism и Expert Parallelism на всех 8 GPU. FP8 означает использование 8-битной плавающей точки для экономии памяти и ускорения вычислений.

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

03Как это работает: магия Torch FX и AST

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

Процесс можно описать в несколько шагов:

1. Трассировка: Когда модель загружается, vLLM проходит по графу вычислений Transformers, создавая его представление.
2. Поиск паттернов: Алгоритм ищет известные шаблоны операций, которые можно оптимизировать. Например, он находит последовательности линейных слоев, которые можно объединить.
3. Трансформация через AST: Используя абстрактное синтаксическое дерево (Abstract Syntax Tree), система модифицирует исходный код модели «на лету». Она заменяет стандартные операции на их оптимизированные аналоги, совместимые с ядрами vLLM.

Это позволяет создавать fused operations (слитые операции). Например, операции MergedColumnParallelLinear и QKVParallelLinear из vLLM теперь могут быть применены к моделям Transformers. Эти операции критически важны для Tensor Parallelism, так как они позволяют эффективно распределять матричные умножения между GPU.

Важно отметить, что модифицированные модели остаются полностью совместимыми с torch.compile и CUDA Graphs. Это значит, что вы получаете преимущества компиляции PyTorch, не теряя при этом гибкости архитектуры Transformers.

04Универсальность и простота развертывания

Главное преимущество для конечного пользователя — отсутствие необходимости менять пайплайн развертывания. Вам не нужно писать новые классы моделей или настраивать сложные скрипты. Все управление осуществляется через стандартные флаги командной строки vLLM.

Для запуска модели с использованием нового бэкенда достаточно добавить флаг --model-impl transformers. Вот как это выглядит на практике для разных сценариев:

# Qwen3-4B dense, single GPU
vllm serve Qwen/Qwen3-4B --model-impl transformers

# Qwen3-32B dense, tensor-parallel across 2 GPUs
vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2

# Qwen3-235B-A22B-FP8 MoE, data-parallel + expert-parallel across 8 GPUs
vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel

# add --max-model-len 8192 if your node is memory constrained

Этот подход сохраняет совместимость со всеми обычными опциями параллелизма. Если вы привыкли использовать --tensor-parallel-size или --data-parallel-size, они продолжают работать как раньше. Это снижает порог входа для новых пользователей vLLM и упрощает жизнь существующим.

05Преимущества для обучения и RLHF

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

• Обучения (Training): Fine-tuning модели на ваших данных.
• Оценки (Evals): Проверка качества модели на бенчмарках.
• RL Rollouts: Запуск процессов обучения с подкреплением (Reinforcement Learning from Human Feedback), где требуется быстрая генерация примеров.

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

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

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

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

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

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

Для разработчиков и компаний, работающих с LLM, это обновление означает несколько ключевых изменений:

1. Сокращение времени выхода на рынок (Time-to-Market): Новые модели теперь доступны для быстрого инференса сразу после публикации в Hugging Face. Не нужно ждать, пока сообщество или сами авторы напишут нативную реализацию для vLLM.
2. Снижение порога входа: Меньше необходимости в глубоком знании внутренней кухни vLLM для развертывания новых архитектур. Достаточно знать API Transformers.
3. Экономия ресурсов: Поскольку производительность сопоставима с нативными реализациями, компании могут использовать меньше GPU для тех же задач или обрабатывать больше запросов на том же оборудовании. В условиях, когда доступ к мощным GPU (особенно в РФ и СНГ) может быть ограничен или дорог, каждый процент прироста эффективности имеет значение.
4. Упрощение инфраструктуры: Единый код для обучения и инференса упрощает CI/CD пайплайны. Вам не нужно поддерживать сложные сборки для разных этапов жизненного цикла модели.

В контексте российского рынка, где многие компании активно внедряют LLM для внутренних задач (анализ документов, чат-боты, генерация контента), эта технология открывает новые возможности. Локальный запуск больших моделей на имеющемся оборудовании становится более доступным и предсказуемым. Вы можете взять любую модель из каталога Hugging Face, запустить её с флагом --model-impl transformers и получить производительность, близкую к идеальной, без необходимости нанимать команду специалистов по низкоуровневой оптимизации CUDA.

08Заключение

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

Рекомендуем всем, кто использует vLLM для развертывания моделей, обновить свои пакеты и протестировать новые возможности. Возможно, именно это обновление позволит вам запустить ту самую большую модель, которую вы откладывали из-за соображений производительности.

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