Le fournisseur d'inférence Baseten a publié le 2 octobre un billet technique : en utilisant Claude Code pour piloter Fable 5, l'équipe a laissé un agent écrire de zéro un moteur d'inférence dédié à un seul modèle, qui a surpassé vLLM sur tous les profils de trafic testés.
Ce moteur s'appelle VibeQwen et a été conçu spécifiquement pour le Qwen-3.6-35B-A3B d'Alibaba. L'auteur, Shawn Rushefsky, écrit dans le billet :
"the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases"
(Le moteur généré, appelé VibeQwen, a surpassé vLLM sur tous les profils de trafic testés, avec des écarts très importants dans certains cas.)
D'où viennent ces chiffres
Le matériel de test était un Nvidia B200, le groupe de comparaison était vLLM 0.25.1, et l'outil de charge utilisé était AIPerf. Quelques résultats :
- Décodage en flux unique à 1792 TPS contre 943 TPS pour vLLM, soit environ 90 % plus rapide ;
- Latence jusqu'au premier token réduite de 28 à 12 millisecondes, soit environ 2,3 fois moins ;
- Avec 32 requêtes simultanées, le débit est supérieur de 71 %.
Côté coût, VibeQwen a nécessité environ une semaine, consommé environ 1,7 milliard de tokens (en grande partie via le cache), environ 200 heures de B200, pour un coût total de l'ordre de quelques milliers de dollars.
Baseten a aussi testé la même méthode sur la segmentation d'image. Le second résultat s'appelle Sammie, il sert le SAM 3.1 de Meta, tourne sur H100, a été bouclé en quelques jours, pour quelques centaines de dollars et environ 200 millions de tokens. Avec 32 requêtes simultanées, le débit est 50 % supérieur à celui du serveur de référence officiel de Meta, atteignant 91 images par seconde.
Ce que l'agent a réellement fait
Baseten a étendu son propre framework, nommé MetaInfer, en une pile de service complète, et a laissé l'agent la compléter. L'agent pouvait consulter des solutions open source existantes comme référence, mesurait avec AIPerf après chaque série de modifications, et décidait de l'étape suivante en fonction des chiffres.
Une contrainte est formulée de façon très précise : toute modification susceptible d'affecter la précision des sorties obligeait l'agent à s'arrêter pour demander une approbation humaine. Les dérives numériques subtiles sont ce qu'il y a de plus difficile à détecter dans un moteur d'inférence ; si un gain de vitesse se fait au prix de la précision, cela ne se voit pas dans un tableau de benchmarks — c'est exactement ce que cette barrière vise à bloquer.
Le billet lui-même pose des limites claires. VibeQwen et Sammie restent des expérimentations et n'ont pas encore servi de trafic de production. La comparaison pour Sammie est encore plus grossière, et l'auteur reconnaît que ces chiffres ne valent que comme "preuve indicative" : architectures différentes, accélérateurs différents, sans test contrôlé.
Ce que cela signifie pour les équipes en Chine
VibeQwen cible le modèle open source Qwen, et de nombreux services en production en Chine tournent justement aussi sur la combinaison Qwen avec vLLM ou SGLang — ces chiffres concernent donc directement le quotidien de pas mal d'équipes.
On peut comparer l'économie des deux approches. Un moteur généraliste doit prendre en charge des centaines d'architectures de modèles, ce qui empêche d'y intégrer de nombreuses optimisations agressives propres à une seule architecture ; un moteur dédié ne vise qu'un seul modèle et peut ajuster entièrement les kernels d'attention, le routage MoE et la stratégie de scheduling à la forme exacte du 35B-A3B. Auparavant, écrire un moteur dédié demandait à une équipe plusieurs mois ; cette fois, Baseten a ramené cela à une semaine et quelques milliers de dollars — à la louche, moins cher qu'un mois de travail d'un ingénieur d'inférence.
Les limites sont tout aussi nettes :
- Le moteur reste lié au modèle. Si Qwen évolue avec des changements structurels, le moteur devra probablement être régénéré.
- Les tests ne portent que sur le B200. Les modèles de GPU disponibles en Chine varient beaucoup, et le billet ne fournit aucune donnée sur la reproductibilité du même processus sur d'autres accélérateurs.
- La stabilité en longue traîne, la fragmentation mémoire et le traitement des requêtes anormales qu'exige la production ne sont pas forcément couverts par les benchmarks.
Malgré cela, l'approche consistant à doter "chaque modèle phare d'un moteur dédié généré automatiquement" dispose désormais d'un échantillon vérifiable. Que le rôle de vLLM bascule de "pilier de production" à "ligne de base et solution de repli" dépendra de la capacité des équipes à réellement déployer ce type de moteur en production et à publier des données sur plusieurs mois.
Sources : blog d'ingénierie de Baseten, CocoLoop ; TPS, latence jusqu'au premier token, débit en concurrence, consommation de tokens et heures de GPU vérifiés via le blog de Baseten.