Hugging Face : le backend transformers de vLLM tourne désormais à vitesse native

Le 8 juillet 2026, Hugging Face a annoncé la parité de performances du backend transformers dans vLLM : un seul flag, `--model-impl transformers`, et l'inférence égale les implémentations natives. Le test portait sur trois modèles Qwen3 : 4B (1 GPU), 32B (2 GPU) et 235B MoE sur 8×H100, avec des résultats équivalents ou meilleurs partout. Le backend prend en charge plus de 450 architectures et conserve la possibilité de faire du fine-tuning. Des limites subsistent : les modèles à attention linéaire ne sont pas encore pris en charge, et les modèles personnalisés issus des dépôts du Hub peuvent poser des problèmes de compatibilité.

Traité par IA depuis Hugging Face Blog ; édité par Hamidun News
Hugging Face : le backend transformers de vLLM tourne désormais à vitesse native
Source : Hugging Face Blog. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primaireHugging Face Blog ↗
Rédacteur en chef
Date8 juillet 2026, blog officiel de Hugging Face
Flag de lancement`--model-impl transformers` dans la commande `vllm serve`
Modèles testésQwen3-4B (1 GPU), Qwen3-32B (2 GPU, tensor parallelism), Qwen3-235B MoE FP8 (8×H100)

Le 8 juillet 2026, Hugging Face a publié sur son blog les résultats d'un benchmark : le backend de la bibliothèque transformers dans vLLM égale désormais pleinement les performances des implémentations natives de vLLM pour les architectures compatibles. Il suffit aux développeurs d'ajouter un seul flag, `--model-impl transformers`, au lancement du serveur, sans modifier l'infrastructure.

Ce qui change pour les développeurs

Jusqu'ici, l'inférence haute performance dans vLLM exigeait des implémentations « manuelles » distinctes pour chaque architecture. La version de recherche d'un modèle dans transformers et sa version de production dans vLLM divergeaient, et chaque mise à jour d'architecture obligeait à synchroniser deux bases de code.

Désormais, la bibliothèque transformers est compilée automatiquement en kernels vLLM optimisés via `torch.fx` (analyse statique du graphe de calcul) et des manipulations d'AST pour réécrire les opérations. Sous le capot, le système construit un graphe de calcul, cherche des motifs remplaçables par un seul kernel optimisé et, pour les modèles en tensor parallelism, fusionne en plus les couches column-parallel et QKV-parallel.

Les faits clés :

  • Date : 8 juillet 2026, blog officiel de Hugging Face
  • Flag de lancement : `--model-impl transformers` dans la commande `vllm serve`
  • Modèles testés : Qwen3-4B (1 GPU), Qwen3-32B (2 GPU, tensor parallelism), Qwen3-235B MoE FP8 (8×H100)
  • Résultat : le backend égale ou dépasse le débit de vLLM natif
  • Compatibilité : `torch.compile`, CUDA Graphs, prise en charge de l'entraînement (absente des implémentations natives de vLLM)
  • Couverture : plus de 450 architectures dans la bibliothèque transformers

Comment le test a été mené

Hugging Face a lancé son benchmark sur trois configurations de Qwen3 de complexité croissante : Qwen3-4B sur un GPU, Qwen3-32B avec tensor parallelism sur deux GPU, et Qwen3-235B en FP8 avec une architecture Mixture-of-Experts sur huit H100, en data parallelism et expert parallelism simultanément. Sur les trois configurations, le backend transformers a affiché un débit égal ou supérieur à celui de vLLM natif.

«

Les développeurs de modèles peuvent désormais obtenir gratuitement une inférence vLLM ultrarapide », — extrait du blog officiel de Hugging Face.

Il présente un avantage important sur les implémentations natives de vLLM : le backend transformers conserve la prise en charge de l'entraînement. Les implémentations natives de vLLM ont été conçues exclusivement pour l'inférence ; les équipes ayant besoin à la fois de fine-tuning et de serving haute performance devaient jusque-là maintenir deux chemins de code distincts.

Pourquoi c'est important pour l'écosystème

La bibliothèque transformers sert d'implémentation de référence pour plus de 450 architectures et s'intègre à SGLang, MLX et llama.cpp. La parité avec vLLM natif écarte l'un des principaux arguments contre son usage en production : la nécessité de réécrire les modèles pour un moteur de serving donné. Cela compte particulièrement dans un contexte de fragmentation, où chaque moteur exigeait auparavant sa propre implémentation.

Le chemin entre la publication d'un nouveau modèle sur le Hugging Face Hub et un déploiement haute performance se raccourcit nettement. Le développeur n'a plus à attendre que l'équipe vLLM ajoute une prise en charge native de l'architecture : un flag et une implémentation compatible dans transformers suffisent. C'est particulièrement précieux pour les chercheurs indépendants et les petites équipes, qui n'ont pas les moyens d'écrire et de maintenir des implémentations vLLM dédiées.

Limites actuelles : les modèles à attention linéaire (linear attention) ne sont pas encore pris en charge ; les modèles personnalisés issus des dépôts du Hub peuvent poser des problèmes de compatibilité.

Ce que cela signifie

La barrière entre le code de recherche dans transformers et l'inférence haute performance dans vLLM a pratiquement disparu. Ce qui exigeait autrefois une optimisation manuelle pour chaque moteur s'obtient désormais avec un seul flag en ligne de commande : une baisse directe des coûts d'ingénierie pour les équipes qui développent et déploient de grands modèles de langage.

Questions fréquentes

Quels modèles le nouveau backend prend-il en charge ?

Le backend prend en charge plus de 450 architectures de la bibliothèque transformers. Il a été testé sur Qwen3-4B, Qwen3-32B et Qwen3-235B MoE FP8. Les modèles à attention linéaire (linear attention) ne sont pas pris en charge dans la version actuelle ; les modèles personnalisés du Hub peuvent nécessiter une vérification de compatibilité.

Comment lancer vLLM avec le backend transformers ?

Pour un seul GPU : `vllm serve Qwen/Qwen3-4B --model-impl transformers`. Pour plusieurs GPU : `vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2`. Aucune autre modification de l'infrastructure n'est nécessaire.

Dossier

Questions clés sur cet article

Quels modèles le nouveau backend prend-il en charge ?

Le backend prend en charge plus de 450 architectures de la bibliothèque transformers. Il a été testé sur Qwen3-4B, Qwen3-32B et Qwen3-235B MoE FP8. Les modèles à attention linéaire (linear attention) ne sont pas pris en charge dans la version actuelle ; les modèles personnalisés du Hub peuvent nécessiter une vérification de compatibilité.

Comment lancer vLLM avec le backend transformers ?

Pour un seul GPU : `vllm serve Qwen/Qwen3-4B --model-impl transformers`. Pour plusieurs GPU : `vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2`. Aucune autre modification de l'infrastructure n'est nécessaire.

Que sait-on sur Ce qui change pour les développeurs ?

Jusqu'ici, l'inférence haute performance dans vLLM exigeait des implémentations « manuelles » distinctes pour chaque architecture. La version de recherche d'un modèle dans transformers et sa version de production dans vLLM divergeaient, et chaque mise à jour d'architecture obligeait à synchroniser deux bases de code. Désormais, la bibliothèque transformers est compilée automatiquement en kernels vLLM optimisés via `torch.fx` (analyse statique du graphe de calcul) et des manipulations d'AST pour réécrire les opérations. Sous le capot, le système construit un graphe de calcul

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…