Библиотека transformers достигла скорости vLLM без переписывания кода

Библиотека transformers достигла скорости работы, сопоставимой с кастомными реализациями в фреймворке vLLM, благодаря обновлению бэкенда моделирования. Теперь авторы моделей могут запускать свои решения с максимальной производительностью, используя стандартный код без необходимости ручной оптимизации под конкретный движок. Тесты на архитектурах Qwen3 (от 4 млрд до 235 млрд параметров) показали, что новый подход не уступает, а в ряде случаев превосходит нативные решения vLLM.

Важный нюанс: Разработчикам больше не нужно дублировать усилия, создавая отдельные версии кода для обучения и для продакшена. Единая реализация теперь обеспечивает максимальную скорость инференса.

Техническая реализация и результаты тестов

Разработчики перешли от простой интеграции внимания к глубокой оптимизации вычислительного графа. Раньше для достижения пиковой скорости требовалась ручная переписывание модели под vLLM. Сейчас система автоматически анализирует код модели с помощью torch.fx, находит шаблоны, которые можно ускорить, и переписывает операции на лету. Это позволяет использовать слияние операций (fused kernels), характерное для кастомных решений, включая поддержку параллелизма экспертов в моделях типа MoE (Mixture-of-Experts).

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

Тестирование проводилось на кластере из 8 видеокарт H100 на трех конфигурациях модели Qwen3:

• 4 млрд параметров (плотная модель) на одной GPU.
• 32 млрд параметров с тензорным параллелизмом на двух GPU.
• 235 млрд параметров (FP8, MoE) с комбинацией параллелизма данных и экспертов на восьми GPU.

Во всех трех сценариях обновленный бэкенд transformers достиг или превысил пропускную способность нативной реализации vLLM.

Стоит учесть: Технология пока не поддерживает модели с линейным вниманием, хотя поддержка обещана в ближайшем будущем. Также могут возникнуть сложности с кастомными моделями из репозиториев, код которых не соответствует стандартам библиотеки.

Практические последствия для разработки

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

• Снижение порогов входа: Интеграция новой архитектуры в систему инференса занимает минуты, а не недели ручной оптимизации.
• Упрощение поддержки: Поддержка одной кодовой базы вместо двух (для обучения и для инференса) снижает риск ошибок при обновлении моделей.
• Гибкость масштабирования: Модели автоматически адаптируются под доступное железо, используя компиляцию через torch.compile и CUDA Graphs.

На фоне этого: Скорость внедрения новых архитектур на рынок возрастает, так как технический барьер оптимизации под конкретный движок инференса фактически исчезает.

Операционные последствия, тренды и практические аспекты

• Снижение затрат на разработку: Отказ от необходимости писать кастомные реализации для vLLM высвобождает ресурсы инженеров, которые теперь могут фокусироваться на улучшении архитектуры моделей, а не на оптимизации кода под движок.
• Зависимость от стандартов: Успешная работа оптимизации напрямую зависит от того, насколько код модели соответствует внутренним стандартам библиотеки transformers. Нестандартные реализации могут не получить прироста производительности.
• Технические ограничения: Для моделей с линейным вниманием (linear attention) текущая версия бэкенда не обеспечивает ускорения, что требует временного использования старых методов или ожидания обновления.
• Инфраструктурная готовность: Для достижения заявленных результатов требуется наличие современного оборудования (например, H100) и корректная настройка параллелизма, так как автоматическая оптимизация работает в связке с аппаратными возможностями.