Le benchmark VibeQwen de Baseten bat vLLM jusqu’à 90 %, avec une réserve

Baseten affirme que son moteur VibeQwen a surpassé vLLM jusqu’à 90 % après qu’Claude Code a passé une semaine à optimiser un déploiement étroitement défini. Le benchmark VibeQwen de Baseten associait Qwen-3.6-35B-A3B à des poids NVFP4 et à un seul GPU NVIDIA B200.

Ce résultat peut sembler constituer une défaite directe pour les moteurs d’inférence open source les plus établis. Il est plus juste de l’interpréter comme une remise en cause de leurs priorités de conception. VibeQwen ciblait un modèle, un accélérateur, un format de précision et une charge de travail uniques, tandis que vLLM prend en charge un environnement de déploiement vaste et évolutif.

L’expérience redéfinit aussi le rôle des agents de programmation. Claude Code ne s’est pas limité à proposer des kernels CUDA isolés. Selon Baseten, il a assemblé un moteur d’inférence fonctionnel, déployé des candidats, mesuré des endpoints de production, vérifié la précision et itéré pendant environ une semaine.

Les chiffres phares restent les propres résultats de benchmark de Baseten. VibeQwen n’a pas fait l’objet de tests indépendants étendus, et l’avantage annoncé de 90 % est apparu sur du texte répétitif et structuré, favorable au décodage spéculatif. La question la plus importante est de savoir si ce processus spécialisé, piloté par agent, peut devenir une pratique d’ingénierie reproductible plutôt qu’un impressionnant résultat de laboratoire.

Ce que le benchmark VibeQwen de Baseten a réellement mesuré

Le résultat le plus marquant de Baseten provient d’une configuration étroite et explicitement optimisée, et non d’un remplacement universel de vLLM.

L’ingénieur de Baseten Shawn Rushefsky a publié l’expérience le 2 octobre 2026. Son benchmark d’inférence décrit un moteur généré pour Qwen-3.6-35B-A3B, utilisant la précision NVFP4 sur un accélérateur B200.

NVFP4 est un format à virgule flottante sur quatre bits conçu pour réduire le trafic mémoire et accélérer les calculs sur du matériel NVIDIA compatible. Ce choix de précision est déterminant, car la vitesse d’inférence dépend fortement du modèle, du format de quantification, de l’architecture GPU et des kernels disponibles.

Baseten a baptisé VibeQwen le moteur généré. L’entreprise l’a comparé à un déploiement vLLM 0.25.1 optimisé, sur le même matériel à un seul B200.

Sur du texte en flux unique favorable au spéculateur, VibeQwen aurait généré 1 792 tokens de sortie par seconde. Le déploiement vLLM a produit 943 tokens par seconde dans les mêmes conditions de test rapportées.

Cet écart a produit l’amélioration phare de 90 %. L’expression « favorable au spéculateur » décrit une sortie répétitive ou structurée où un décodeur spéculatif peut proposer plusieurs tokens probables en vue d’une vérification parallèle.

Le délai avant le premier token, ou TTFT, est passé de 28 millisecondes avec vLLM à 12 millisecondes avec VibeQwen. Le TTFT mesure le délai entre l’envoi d’une requête et la réception du premier token généré.

Baseten a qualifié ce changement d’amélioration d’un facteur 2,33. Ce délai réduit est important pour les assistants interactifs, la complétion de code et les interfaces vocales, où les utilisateurs perçoivent immédiatement la pause initiale.

VibeQwen aurait également pris l’avantage sous un trafic plus important. Avec une concurrence de 32, une réplique a généré 10 307 tokens de sortie par seconde, contre 6 030 pour vLLM.

Cela représentait un débit global de sortie supérieur de 71 %. Le résultat suggère que l’avantage du moteur ne se limitait pas à un test isolé avec un seul utilisateur, même s’il ne couvrait qu’un niveau de concurrence rapporté.

La comparaison utilisait vLLM 0.25.1, que Baseten présentait comme la version actuelle au début de l’expérience. L’historique des versions du projet montre qu’il s’agissait d’une version corrective contenant deux correctifs de bugs ciblés.

Baseten n’a pas affirmé que chaque modèle, distribution de prompts ou GPU produirait la même marge. Les résultats publiés concernent cette combinaison particulière de modèle, matériel et charge de travail.

Cette distinction doit guider l’interprétation des chiffres par les acheteurs. Une avance de 90 % sur un texte sélectionné constitue une preuve significative de marge d’optimisation, mais ne représente pas une amélioration de 90 % pour le service d’IA généraliste.

Le benchmark modifie donc la question concurrentielle. Les équipes doivent désormais se demander si un runtime largement compatible reste le meilleur endpoint pour une charge de travail stable et à fort volume.

Pourquoi un agent de programmation a pu trouver autant de marge d’optimisation

L’optimisation de l’inférence convient aux agents de programmation, car la vitesse, la qualité des sorties et le comportement matériel peuvent tous être testés à partir de retours mesurables.

Baseten a adapté des idées de MetaInfer, un système expérimental qui traite un LLM comme un compilateur de logiciels d’inférence. Au lieu de maintenir un moteur unique pour chaque environnement, le système génère un logiciel compact autour de contraintes d’exécution explicites.

Le projet MetaInfer associe des agents de programmation à une base de connaissances contractuelle. Cette base enregistre des contraintes, des tests, des schémas fonctionnels et les leçons tirées de tentatives infructueuses.

Un agent peut proposer une implémentation, la compiler, exécuter une suite de tests de correction, mesurer les performances et réviser le code. Chaque boucle renvoie un signal plus clair que ne le permettent de nombreuses tâches logicielles ordinaires.

Une refonte visuelle, par exemple, dépend en partie du jugement humain. Un moteur d’inférence offre des mesures objectives telles que la latence, le débit, l’utilisation du GPU, la consommation mémoire et la précision des sorties.

Cette clarté rend l’optimisation de longue durée praticable. Un agent n’a pas besoin de convaincre un examinateur qu’un candidat semble plus rapide. Il doit dépasser une référence chiffrée tout en respectant des seuils de correction prédéfinis.

Baseten a donné à Claude Code accès aux ressources de MetaInfer, aux poids du modèle et à une station de travail B200 via SSH. L’entreprise a également fourni le modèle en précision totale comme oracle de précision, c’est-à-dire une référence fiable pour vérifier la qualité des sorties.

L’objectif initial était exigeant. Baseten a demandé à l’agent de dépasser vLLM de 20 % sur l’ensemble des métriques de performance, sans perdre en précision par rapport à la référence NVFP4.

Claude Code pouvait déployer des candidats sur Baseten et exécuter AIPerf sur chaque endpoint. AIPerf est un générateur de charge de travail qui mesure le comportement d’un service de modèles déployé, plutôt que de chronométrer uniquement un kernel isolé.

Rushefsky indique que le processus s’est déroulé pendant environ une semaine. Il a consommé près de 1,7 milliard de tokens, principalement sous forme d’entrées mises en cache, ainsi qu’environ 200 heures de B200.

Le moteur aurait atteint la parité avec vLLM au cours des premiers jours. Baseten a autorisé le système à poursuivre ses recherches, ce qui a produit les marges finales plus importantes.

La supervision humaine n’a pas disparu. Rushefsky a parfois réorienté le système lorsqu’il se concentrait trop fortement sur une seule forme de trafic.

Claude Code s’est également interrompu lorsque les changements proposés modifiaient les sorties numériques. Baseten a finalement accepté de subtiles différences par rapport à sa référence NVFP4 lorsque la précision globale face au modèle BF16 restait au moins aussi bonne.

BF16, ou bfloat16, conserve une plage numérique et une précision supérieures à celles d’un format sur quatre bits. La comparaison avec une implémentation BF16 peut révéler si la quantification ou les modifications de kernels dégradent la qualité du modèle.

Ces contrôles expliquent pourquoi il s’agissait de plus qu’un prompt de génération de code prolongé. Baseten a construit un environnement où l’agent pouvait agir, observer les résultats, conserver des connaissances utiles et rencontrer des garde-fous avant d’accepter des changements risqués.

L’expérience s’est également appuyée sur des implémentations open source. Baseten a autorisé l’agent à examiner vLLM et TensorRT-LLM, y compris des kernels préoptimisés lorsque cela était approprié.

Ce choix rend le projet plus pertinent pour l’ingénierie de production, mais moins probant comme démonstration d’une invention algorithmique autonome. VibeQwen représente une intégration et une spécialisation dirigées par agent, à partir de composants existants et nouvellement écrits.

Le résultat reste notable. Les ingénieurs utilisent depuis longtemps des profileurs, des benchmarks et des systèmes d’autotuning. Ici, un LLM aurait coordonné des décisions couvrant les kernels, la logique du moteur, le comportement de service, le déploiement et la validation.

Les moteurs spécialisés mettent les runtimes généralistes sous pression

La concurrence principale n’oppose pas VibeQwen et vLLM en tant que produits. Elle oppose la spécialisation à la généralité comme stratégie d’ingénierie.

vLLM, SGLang et TensorRT-LLM résolvent un vaste problème de compatibilité. Ils doivent prendre en charge de nombreuses architectures, formats de quantification, accélérateurs, schémas de batching, API et exigences opérationnelles.

Cette étendue apporte une immense valeur pratique. Une équipe peut déployer un nouveau modèle sans avoir à construire d’abord un runtime adapté à chaque couche, kernel ou schéma de service inhabituel.

Elle crée aussi des abstractions. Les ordonnanceurs, exécuteurs de modèles, couches de compatibilité, chemins de repli et kernels configurables ajoutent des branches qu’un moteur à usage unique pourrait éliminer.

La thèse de MetaInfer est que ces abstractions laissent des performances inutilisées. Lorsqu’un déploiement devient stable, un agent peut spécialiser le moteur autour de ses contraintes exactes.

VibeQwen ciblait Qwen-3.6-35B-A3B en NVFP4 sur un B200. Il n’avait pas besoin de préserver une voie élégante pour des modèles sans rapport ou des accélérateurs plus anciens.

Un moteur spécialisé peut fusionner des opérations qui se produisent systématiquement ensemble. Il peut supprimer des conversions, transferts mémoire, vérifications à l’exécution et interfaces génériques qui ne servent pas la charge de travail choisie.

Les travaux antérieurs de Baseten sur l’optimisation de kernels illustrent l’espace de recherche disponible. Ses agents auraient associé du profiling au niveau du modèle à des expérimentations par kernel sur des modèles de diffusion et de langage.

Dans ces projets, les modifications utiles comprenaient le préconditionnement des échelles constantes, la fusion de la normalisation avec la quantification et la suppression d’opérations mémoire intermédiaires. Ces techniques réduisent le travail sans modifier le calcul prévu par le modèle.

L’expérience VibeQwen a étendu ce raisonnement à l’ensemble de la pile de service. Un endpoint de production implique plus qu’une multiplication matricielle rapide.

Les requêtes doivent entrer par une API, passer par l’ordonnancement et le batching, exécuter les kernels du modèle, diffuser les tokens et partager une mémoire GPU limitée. Optimiser un seul kernel peut laisser intact le principal goulot d’étranglement.

Un agent de programmation peut examiner les interactions entre ces couches. Il peut aussi mener plusieurs expériences sans se fatiguer ni s’attacher à une implémentation conçue manuellement.

Cette pression ne rend pas les moteurs généralistes obsolètes. Elle pourrait plutôt modifier leur place dans le cycle de vie d’un déploiement.

Une équipe pourrait commencer avec vLLM, car il offre compatibilité, maintenance active et une interface de service familière. Une fois le trafic prévisible, un agent pourrait générer une branche spécialisée pour ce profil de production.

Le moteur généraliste resterait la référence et la solution de repli. Le moteur personnalisé prendrait en charge les charges de travail pour lesquelles la latence économisée ou le débit supplémentaire justifie sa charge de maintenance.

Cette approche rappelle la compilation guidée par profil, mais la cible d’optimisation inclut le comportement applicatif et l’infrastructure de service. L’agent explore le code source, les kernels, la configuration du runtime et les décisions de déploiement.

Cette approche peut aussi accroître la pression sur les moteurs établis afin qu’ils exposent davantage de points d’extension pour la spécialisation. Un runtime modulaire pourrait permettre aux agents d’optimiser certains chemins sans remplacer l’ensemble du système de service.

vLLM ne reste pas immobile. Ses versions modifient régulièrement les exécuteurs de modèles, le décodage spéculatif, la prise en charge de la quantification et les chemins matériels.

Le benchmark VibeQwen de Baseten doit donc être lu comme un instantané dans une compétition en mouvement. La référence peut s’améliorer, tandis que les découvertes réutilisables de VibeQwen pourraient finir par intégrer des runtimes plus larges.

Le changement durable est stratégique. La performance généraliste n’est plus nécessairement l’étape finale d’optimisation pour les charges de travail de valeur.

L’affirmation de 90 % comporte des limites importantes

Le benchmark est suffisamment crédible pour mériter une enquête, mais trop limité et auto-déclaré pour étayer une conclusion universelle sur les performances.

La principale inquiétude concerne la sélection des charges de travail. Baseten affirme que le résultat de 90 % provenait de textes structurés et répétitifs, particulièrement favorables à son spéculateur.

Le décodage spéculatif accélère la génération en proposant plusieurs futurs tokens et en les vérifiant ensemble. Son efficacité dépend de la fréquence à laquelle ces propositions correspondent à ce que le modèle cible aurait généré.

Le code structuré, les modèles et les données répétitives peuvent produire des taux d’acceptation élevés. La prose ouverte, les langues peu courantes, l’écriture créative ou un contexte évoluant rapidement peuvent se comporter différemment.

Baseten a indiqué que VibeQwen dominait tous les profils de trafic qu’il a testés. Toutefois, le résumé public ne fournit pas suffisamment de données granulaires pour reconstituer chaque distribution de prompts et chaque taux d’acceptation.

Le benchmark provient également de l’entreprise qui a développé et héberge le moteur. Aucune partie indépendante n’a reproduit les résultats de VibeQwen sur du matériel identique et avec les mêmes poids de modèle.

Cela n’invalide pas les mesures. Cela limite l’affirmation à « Baseten affirme » tant que du code, des jeux de tests ou des résultats tiers ne permettent pas une réplication directe.

Le critère de précision mérite une prudence similaire. Baseten a commencé en exigeant l’absence de perte de précision par rapport à une référence NVFP4.

Lors de l’optimisation, l’équipe a accepté de faibles écarts numériques tant que la précision agrégée par rapport à la référence BF16 restait au moins aussi bonne. C’est un compromis d’ingénierie raisonnable, mais il exige une évaluation détaillée au niveau des tâches.

Un score moyen peut masquer des régressions dans certains domaines. Les entreprises auraient besoin de tests couvrant leurs propres prompts, appels d’outils, sorties structurées, comportements de sécurité et charges de travail à long contexte.

La fiabilité opérationnelle est une autre question ouverte. Une exécution de benchmark ne mesure pas des mois de mises à niveau en production, de requêtes malformées, de changements de tokenizer, de mises à jour de pilotes ou de longueurs de séquence inhabituelles.

Les moteurs généralistes gagnent en confiance notamment grâce à leur adoption étendue. Leurs cas limites sont rencontrés et corrigés par une base plus large de contributeurs et de clients.

Un moteur sur mesure concentre la responsabilité. La même spécialisation qui élimine des surcoûts peut créer des hypothèses fragiles sur les formes, les lots, la précision ou le comportement matériel.

Le coût de développement compte également, même sans prix public. VibeQwen aurait consommé environ 200 heures de B200 et 1,7 milliard de tokens de modèle.

Ces ressources peuvent se justifier pour une charge de travail importante et durable. Elles sont moins attrayantes lorsqu’un modèle évolue chaque semaine ou que le trafic reste trop faible pour amortir l’effort d’ingénierie.

Le budget d’itération de l’expérience complique aussi la comparaison directe. vLLM doit répartir son travail de développement entre de nombreux utilisateurs, modèles et appareils.

Claude Code a passé une semaine à optimiser une seule cible. L’avance de VibeQwen démontre donc autant la valeur d’un effort concentré que la supériorité de logiciels écrits par des agents.

La seconde expérience de Baseten fournit des éléments encourageants, mais incomplets, sur la réutilisation. L’entreprise a appliqué sa base de connaissances enrichie à un serveur de segmentation d’images SAM 3.1.

Ce système, appelé Sammie, aurait traité 91 images par seconde sur un H100. Baseten affirme que cela représentait 50 % de plus que le serveur de référence de Meta après plusieurs jours et environ 200 millions de tokens.

Le modèle, le GPU, l’architecture et la référence différaient tous de VibeQwen. Baseten a également signalé l’absence d’expérience de contrôle.

Sammie suggère donc que les connaissances accumulées ont aidé, mais il n’isole pas la contribution de la base de connaissances. Une réalisation plus rapide pourrait résulter d’une charge de travail plus simple ou d’autres différences procédurales.

L’interprétation la plus sûre n’est ni le rejet ni la célébration. VibeQwen fournit un signal sérieux montrant que des agents de codage peuvent coordonner une optimisation profonde des systèmes.

Il ne démontre pas encore que les entreprises peuvent générer à la demande des moteurs sur mesure fiables, les préserver lors des mises à jour de modèles et surpasser systématiquement des runtimes maintenus par des experts.

Pourquoi ce résultat compte au-delà d’un seul déploiement de Qwen

L’opportunité plus vaste est un processus de déploiement dans lequel l’optimisation commence une fois connus le modèle, le matériel et le profil de trafic.

Les frameworks d’inférence traditionnels doivent prendre des décisions de conception avant de connaître la charge de travail exacte de chaque utilisateur. Les moteurs construits par des agents inversent cette séquence.

Ils commencent par les faits du déploiement. Ceux-ci peuvent inclure le modèle sélectionné, les longueurs de prompts attendues, la distribution des sorties, les objectifs de concurrence, les exigences de précision et le type d’accélérateur.

Un assistant de code pour entreprise fournit un exemple utile. Ses sorties contiennent souvent de la syntaxe, de l’indentation, des appels de bibliothèques courants et des conventions de projet répétées.

Cette régularité peut favoriser le décodage spéculatif. Un faible TTFT améliore également la sensation d’interactivité des complétions de code en ligne.

Un système vocal a une priorité différente. Il peut accepter un débit total inférieur si le premier token arrive rapidement et si la génération reste suffisamment régulière pour une parole naturelle.

Un service de résumé par lots peut au contraire privilégier le débit agrégé. Il peut tolérer un premier token plus lent lorsque des milliers de documents partagent des plages d’entrée et de sortie prévisibles.

Les runtimes généralistes doivent prendre en charge les trois. Un moteur spécialisé peut n’optimiser que l’un d’entre eux.

Cette approche pourrait rendre le choix de modèle plus flexible. Un modèle qui ne satisfaisait auparavant pas un objectif de latence pourrait devenir viable après une optimisation spécifique à la charge de travail.

Cette possibilité touche les acheteurs d’infrastructure et les équipes applicatives. Les comparaisons de qualité des modèles supposent souvent que le logiciel de service a déjà capté l’essentiel des performances disponibles.

VibeQwen remet cette hypothèse en question. Les choix de runtime peuvent modifier sensiblement le modèle qui offre la meilleure qualité, la meilleure réactivité et la meilleure capacité sur du matériel fixe.

Cela est particulièrement pertinent pour les modèles mixture-of-experts. Qwen-3.6-35B-A3B n’active qu’une partie de son ensemble total de paramètres pour chaque token, ce qui crée un comportement distinctif en matière de routage et de mémoire.

Un runtime qui connaît la disposition exacte des experts et le schéma de quantification peut cibler ces profils. Un moteur générique doit conserver des chemins pour d’autres architectures.

Baseten a déjà exploré une autre voie avec le décodage spéculatif. Son implémentation DFlash aurait amélioré les performances de Qwen3-8B en prédisant plusieurs tokens en parallèle.

Ce travail antérieur nécessitait un entraînement et une implémentation spécifiques au modèle. VibeQwen met plutôt l’accent sur un agent qui coordonne l’optimisation autour d’un modèle existant et de poids quantifiés.

Les deux approches peuvent converger. Un agent d’optimisation pourrait choisir parmi des modèles de brouillon, la fusion de kernels, la mise en cache, le batching et des changements de disposition mémoire.

Cette recherche étendue est précieuse, car les goulots d’étranglement évoluent avec la charge de travail. Améliorer la vitesse de décodage peut révéler que la surcharge de l’ordonnanceur, la latence réseau ou le prétraitement constituent la contrainte suivante.

La base de connaissances réutilisable pourrait devenir l’actif le plus important. Les kernels réussis comptent, mais les échecs documentés peuvent empêcher les futurs agents de répéter des expériences coûteuses.

Une bibliothèque croissante de contrats matériels et de règles de validation pourrait réduire le travail nécessaire pour chaque nouveau moteur. Le test Sammie de Baseten constituait une première tentative d’observer cet effet.

Si la réutilisation s’améliore, l’optimisation devient moins semblable à un projet de conseil sur mesure. Elle commence à ressembler à une étape de compilation automatisée pour des services d’IA en production.

Cette transformation exige des enregistrements rigoureux. Les équipes doivent préserver les entrées de benchmark, les versions de compilateurs, les pilotes, les kernels, les hachages de modèles, les suites de précision et la configuration de déploiement.

Sinon, un résultat rapide devient un artefact impossible à reproduire. L’agent peut savoir comment il a atteint le score, mais l’organisation ne peut pas le reproduire ou l’auditer en toute sécurité.

C’est là que l’ingénierie humaine reste centrale. Les développeurs définissent des objectifs utiles, empêchent le contournement des benchmarks, choisissent les données de validation et décident quels compromis entre performance et qualité sont acceptables.

VibeQwen ne supprime pas cette responsabilité. Il permet à un agent de codage d’explorer un espace d’implémentation plus vaste après que les ingénieurs ont défini les limites.

Trois signaux détermineront si les moteurs construits par des agents perdurent

Le prochain test porte sur la répétabilité entre charges de travail, changements de cycle de vie et environnements indépendants, et non sur un nouveau record isolé.

Le premier signal est un package VibeQwen reproductible. Les équipes indépendantes ont besoin de suffisamment de code, de configuration, de données de prompts et de logique d’évaluation pour relancer la comparaison.

La réplication devrait couvrir la prose ordinaire, le code, les sorties structurées, plusieurs langues, les longs contextes et différents niveaux de concurrence. Elle devrait également rapporter les taux d’acceptation spéculative.

Un résultat étendu renforcerait l’argument de Baseten selon lequel la spécialisation a capturé une marge de performance durable. Un avantage fortement réduit limiterait le titre à un trafic favorable.

Le deuxième signal est la résistance au changement. Les fournisseurs de modèles révisent les poids, les tokenizers, les recettes de quantification et les exigences de service.

NVIDIA met également à jour les compilateurs, les pilotes, les bibliothèques et les générations de GPU. Un moteur sur mesure utile doit absorber ces changements sans nécessiter une nouvelle semaine de reconstruction fragile.

Observez la rapidité avec laquelle un agent peut porter VibeQwen vers une autre version de Qwen ou un accélérateur différent. La comparaison devrait inclure le temps de revue humaine, le budget de calcul et les régressions détectées après le déploiement.

Une migration rapide et fiable conforterait l’idée que la base de connaissances produit des effets cumulatifs. Des sauvetages manuels répétés suggéreraient que les moteurs sur mesure restent des projets coûteux réservés à des spécialistes.

Le troisième signal est une réponse des runtimes généralistes. vLLM, SGLang et TensorRT-LLM peuvent adopter de nouveaux kernels, des interfaces de spécialisation ou des techniques de réglage automatisé.

Certains gains de VibeQwen pourraient intégrer des moteurs partagés une fois que les mainteneurs auront compris les chemins concernés. Cela réduirait l’écart direct du benchmark tout en validant le travail d’optimisation sous-jacent.

Une réponse plus profonde permettrait aux utilisateurs de générer des plans d’exécution spécialisés au sein d’un runtime maintenu. Ce modèle hybride pourrait préserver la compatibilité tout en supprimant les surcoûts pour des déploiements fixes.

Le gagnant ne sera peut-être ni un moteur entièrement généré ni un moteur entièrement générique. Il pourrait s’agir d’un framework général doté de limites de spécialisation contrôlées par des agents et de solides chemins de repli.

Pour les développeurs, la leçon immédiate est pratique. Considérez le logiciel d’inférence comme un composant mesurable, et non comme une enveloppe interchangeable autour des poids du modèle.

Enregistrez les distributions de prompts et de sorties avant de choisir des cibles d’optimisation. Testez le TTFT, la latence des tokens de sortie, le débit, la mémoire, la précision et le comportement en queue avec des requêtes proches de la production.

Pour les acheteurs en entreprise, demandez aux fournisseurs ce que leur benchmark a optimisé et ce qu’il a exclu. Un unique chiffre de débit maximal dit peu de choses sur la latence interactive, la qualité, la portabilité ou l’effort opérationnel.

Demandez également si les gains annoncés résistent à des données variées. Le benchmark Baseten VibeQwen est le plus utile lorsqu’il lance une évaluation rigoureuse, et non lorsqu’il y met fin.

L’expérience offre un aperçu convaincant de l’ingénierie autonome des systèmes. Elle montre aussi pourquoi les agents ont besoin de tests soigneusement conçus et de limites définies par des humains.

Les un à trois prochains mois devraient montrer si VibeQwen devient reproductible, portable et maintenable. Quel résultat modifierait le plus votre plan de déploiement : une réplication indépendante, une migration rapide des modèles ou une spécialisation similaire au sein de vLLM ?