BLOG
Shiwen Dialogue 037 | Cinq agents 27B battent-ils Fable 5 ?
Petit dialogue d’ouverture
Shiwen: Aujourd’hui, j’ai appris sur le forum extérieur qu’un projet GitHub est mentionné, décrivant cinq agents Qwen3.8-27B qui ont battu Fable 5 lors des dix premières questions du LiveCodeBench Hard. La source de l’information est un exemple de flux de travail de Memdoor, et l’auteur a publié les archives complètes des 50 exécutions. Ne vous laissez pas influencer par le titre ; valait-il la peine d’en parler ?
Yongliang: Oui, mais ce n’est pas une histoire sensationnaliste sur un « petit modèle battant un grand modèle ». Ce qui est vraiment intéressant, c’est que cet exemple transforme une méthode multi-agent déjà testée en un flux de travail YAML, permettant à n’importe qui d’utiliser différents modèles, différentes températures et de mettre en place des processus de validation. Cela équivaut à décomposer la solution académique GVS5H en composants que l’équipe de développement peut intégrer directement dans le pipeline de développement. Quant à savoir si Fable 5 a vraiment été battu, cela doit être évalué avec prudence.
Q1: Comment ce « succès » s’est-il produit ?
Shiwen: Le README de Memdoor est très clair : les cinq premières passes donnent une moyenne de 9.8/10, tandis que le modèle original et les mêmes instructions donnent 9.6, et Fable 5 avec une seule exécution donne 8.0. Comment interpréter ces données ?
Yongliang: Il faut comprendre bien les termes. Le projet a utilisé Qwen3.8-27B pour effectuer un cycle multi-agent : le planner propose des solutions, deux ideators présentent des propositions, le solver écrit du code, le manager effectue des révisions, et un repair worker corrige les bugs. Chaque rôle fonctionne dans un contexte nouveau, via la communication par fichiers sur disque. Après cinq passes, la moyenne est de 9.8, légèrement supérieure à 9.6 du modèle original GVS5H, et bien plus élevée que 8.0 obtenu avec Fable 5 pour ces dix questions.
Shiwen: Cela signifie donc que ce n’est pas le modèle lui-même qui s’est amélioré, mais la manière dont il est utilisé ?
Yongliang: Oui. Les 8.0 de Fable 5 proviennent des données d’exécution unique du modèle GVS5H, et non de nouvelles exécutions par Memdoor dans le même environnement. Donc, pour être strict, c’est « une même série de questions, sous les mêmes conditions, un modèle multi-agent de 27B performant mieux qu’une seule exécution de Fable 5 », et non « un modèle de 27B surpassant complètement Fable 5 ». Mais même ainsi, cette différence suffit à montrer que bien organiser plusieurs petits modèles peut effectivement permettre de surpasser les modèles frontier dans certaines tâches spécifiques. Ce qui est encore plus important, c’est que Memdoor a transformé cette méthode en un flux de travail YAML, ce qui signifie que vous pouvez remplacer le planner, l’ideator et le manager par vos propres modèles et températures, et placer n’importe quel processus de validation à n’importe quel stade du processus. Cela est plus utile pour l’équipe de développement que les scores eux-mêmes.
Q2: Le taille des modèles n’est-il plus une caractéristique déterminante ?
Shiwen: Ces dernières années, l’industrie considère généralement que « plus le modèle est grand, mieux il se débrouille ». Ce projet semble dire que la coordination est le nouveau levier. Êtes-vous d’accord ?
Yongliang：Je suis d’accord à moitié. La taille du modèle reste un limite supérieur, mais la configuration détermine dans quelle mesure vous pouvez exploiter ce limite. Dans l’exemple de Memdoor, quatre facteurs jouent un rôle important : premièrement, la division des tâches, chaque agent ne s’occupe que d’une petite partie de la tâche, ce qui rend le contexte plus clair ; deuxièmement, l’état persistant, les plans, notes et solutions actuelles sont tous enregistrés dans des fichiers, évitant que les rôles ne transfèrent toute l’histoire dans le prompt ; troisièmement, la vérification multi-étape, le manager regarde non seulement le code, mais aussi les résultats des tests ; quatrièmement, la récupération possible, le flux de travail YAML inclut des mécanismes de validation et de redémarrage en continu, permettant de continuer à partir de l’étape échouée.
Shiwen：Memdoor mentionne également un “modèle de décision” qui permet d’économiser des tokens. Comment cela se comprend-il ?
Yongliang：C’est un point de gestion très pratique. Un modèle de chat normal doit ingérer toute l’histoire du dialogue, le contenu des fichiers et les résultats des outils à chaque fois, ce qui entraîne une augmentation linéaire des coûts des tokens. Le modèle de décision passe d’abord en revue les entrées pour déterminer quels outils, quels fichiers et quel contexte sont nécessaires, puis fournit uniquement les informations essentielles au grand modèle. Memdoor indique dans ses tests que certaines tâches peuvent économiser 74 % des tokens d’entrée. Cela est particulièrement important pour les cycles multi-agent, car chaque rôle lit et écrit à nouveau dans les fichiers. Sans filtrage, le contexte s’étend rapidement.
Shiwen：Est-ce que cela signifie que l’efficacité de l’achat des API de frontier va diminuer à l’avenir ?
Yongliang：Cela dépend du contexte. Si la tâche est courte, le contexte n’est pas profond et la latence est importante, une seule invocation de frontier reste la plus économique. Si la tâche peut être divisée en plusieurs sous-tâches, nécessite plusieurs itérations, est auditable ou exécutive localement, “modèle de décision + plusieurs travailleurs + flux de travail persistant” devient plus rentable. À l’avenir, les équipes de développement seront plus orientées vers la conception de chaînes de production, plutôt que de s’attarder sur les prompts des modèles.
Q3：Comment calculer les coûts ? Les modèles locaux peuvent-ils vraiment économiser de l’argent ?
Shiwen：Memdoor souligne BYOK et les modèles locaux, Ollama, llama.cpp, vLLM peuvent tous les gérer. Le papier original de GVS5H dit aussi que le coût est réduit à un neuvième de celui de frontier. Est-ce que cela est fiable ?
Yongliang：Memdoor a en fait exécuté ses tests sur OpenRouter, pas sur des machines locales. 50 exécutions efficaces ont coûté 35,79 dollars, plus 16 tentatives de correction ou de coupure, pour un total de 38,77 dollars. Le coût moyen par invocation est de 0,39 dollar, le temps de fonctionnement moyen est de 40 minutes, et le plus longtemps de 4 heures. Si on utilise un vLLM FP8 local, les auteurs disent qu’il peut fonctionner correctement sur une seule GPU. Donc, il est vrai que l’on peut économiser les coûts d’appel aux API, mais il faut payer pour le matériel, l’électricité et la maintenance.
Shiwen：Est-ce que cela signifie que les développeurs individuels peuvent également exécuter leurs modèles chez eux ?
Yongliang：Théoriquement, c’est possible. Memdoor prend en charge Ollama, llama.cpp, vLLM, LM Studio, ainsi que son propre gateway janis. Sur le forum, on a mentionné que après la quantification de Bonsai 2, Qwen3.8-27B peut atteindre 50 tokens/s sur une console de jeu ordinaire. Il y a des commentaires sur HN qui disent : « Le niveau de performance de codage de Fable 5 peut être atteint localement, à condition que le design du harness soit bon ». Mais il y a deux problèmes : d’une part, la quantification peut entraîner une perte de qualité de l’inférence, d’autre part, le temps d’attente du cycle multi-agents. Exécuter un agent local peut être rapide, mais lorsque cinq agents sont réutilisés ensemble, avec les opérations de lecture/écriture des fichiers et les tests, le temps total est augmenté.
Shiwen：Et comparé à la frontier API ?
Yongliang：La frontier API est facturée par token. L’avantage est sa flexibilité, sa rapidité et l’absence de gestion des machines. Les modèles locaux nécessitent un investissement matériel unique, avec un coût marginal bas. Par exemple, avec Qwen3.8-27B, après quantification avec Bonsai 2, on peut atteindre 50 tokens/s sur une console de jeu ordinaire, ce qui est très attrayant pour les développeurs individuels et les petites équipes. Mais il faut noter que dans cette reproduction de Memdoor, le cycle multi-agents a duré jusqu’à 4 heures. Si la GPU locale est lente, l’expérience sera très décevante. Le coût ne se mesure pas uniquement au bilan, mais aussi au temps, à la complexité et au taux de défaillance.
Q4 : Quel pourcentage de réduction faut-il appliquer au terme « beats » dans le titre ?
Shiwen：Vous avez insisté sur la nécessité d’appliquer une réduction. Quelles sont les précautions spécifiques ?
Yongliang：Premièrement, les exemples ne concernent que les dix premières questions. Le paper GVS5H mentionne 100 questions, mais Memdoor n’a pris que les dix premières, ce qui limite la représentativité. Deuxièmement, la contamination est difficile à évaluer. Ces dix questions proviennent des compétitions du milieu mars-milan 2025, et les données d’entraînement de Qwen3.8-27B ont très probablement déjà rencontré ces questions, et les auteurs ont clairement dit que la contamination ne peut pas être exclue. Troisièmement, Fable 5 n’est pas réexécuté dans le même environnement, et les données proviennent des documents des auteurs de GVS5H, ce qui ne permet pas d’exclure des différences dans le design du harness. Quatrièmement, le coût en temps pour les multi-agents est élevé, avec une moyenne de 40 minutes et un maximum de 4 heures, ce qui est complètement différent d’une seule invocation. Cinquièmement, l’exactitude sur différents hosts sur OpenRouter n’est pas transparente ; les auteurs utilisent localement FP8 vLLM, ce qui pourrait être différent sur le cloud.
Shiwen：Qu’en pensez-vous des commentaires sur le forum ?
Yongliang：Sur Hacker News, certains ont souligné que les dix premières questions pourraient être saturées, et LiveCodeBench Hard est également assez ancien. D’autres espèrent voir des tests de Qwen3.8-flash-next, car flash-next est plus rapide et plus performant que 27B dans de nombreuses tâches de codage. Les auteurs eux-mêmes admettent qu’en ajustant les prompts et les paramètres, on pourrait obtenir une note de 10. Cela montre que les résultats sont sensibles aux paramètres, et qu’une seule recette ne peut pas être appliquée à tous les cas. Un autre commentaire pose une bonne question : « Les cinq 27B peuvent-ils surpasser les cinq Fable 5 ? » Cette question touche juste au point crucial, car une comparaison équitable devrait se faire entre plusieurs multi-agents et non entre de petits modèles multi-agents et des grands modèles avec une seule invocation.
Shiwen: Est-ce que cela signifie que le titre « Cinq 27B battent Fable 5 » est un titre trompeur ?
Yongliang: Dans certaines circonstances, c’est vrai, mais il est loin d’être une conclusion généralement acceptée. Cela ressemble plutôt à une reproduction technique et à une vérification des méthodes, plutôt qu’une conclusion qui pourrait être incluse dans une guide de choix. En tant que lecteur, je comprendrais « beats » comme « montrant une comparabilité sous conditions spécifiques », et non « surpasser complètement ».
Q5: Pour les ingénieurs de premier plan, quelle est la plus grande leçon à en tirer ?
Shiwen: Dernier question, si c’est vrai et que cela peut être généralisé, quelles implications cela a-t-il pour le travail des ingénieurs ordinaires ?
Yongliang: Cela signifie que notre travail se déplacera de « écrire du code » vers « concevoir les flux de travail et les critères de validation ». Au cours des deux dernières années, tout le monde s’est concentré sur l’ingénierie des prompts ; maintenant, il s’agit de savoir comment diviser les tâches en étapes vérifiables, comment concevoir les protocoles de collaboration entre les agents, et comment définir des points de validation et de rollback. Memdoor propose plusieurs points intéressants à apprendre : utiliser YAML pour définir les étapes, exécuter indépendamment les étapes, permettre la répétition des étapes échouées, ajouter une validation humaine aux étapes clés, et enregistrer les résultats sur disque plutôt que de les stocker dans le contexte.
Shiwen: Quel impact cette transformation a-t-elle sur la structure de l’équipe ?
Yongliang: L’impact le plus direct est que « écrire du code avec l’AI » n’est plus une compétence rare, mais plutôt « concevoir les flux de travail des agents ». Auparavant, la valeur d’un ingénieur avancé réside dans sa capacité à écrire des algorithmes complexes, mais maintenant, il s’agit de savoir quelles problèmes conviennent à un seul agent, lesquels nécessitent plusieurs agents, et quelles étapes doivent être soumises à une validation humaine. De nouvelles responsabilités apparaîtront dans l’équipe : des concepteurs de flux de travail, des réviseurs d’agents. Pour les managers, les indicateurs de performance devront changer : on ne doit pas se concentrer uniquement sur le nombre de lignes de code, mais sur la stabilité du processus, sa reproductibilité et sa capacité à revenir sur les erreurs.
Shiwen: Est-ce que les ingénieurs n’auront plus besoin d’écrire du code à l’avenir ?
Yongliang: Non. Mais « écrire du code » deviendra une partie plus mineure, tandis que la valeur réside dans la définition des problèmes, la dissection des processus et la conception des critères de validation. Tout comme le DevOps a connecté les opérations et le développement, les flux de travail d’agents combinent l’analyse des besoins, la génération de code, la vérification des tests et la validation humaine en une chaîne de production. À l’avenir, la compétence essentielle d’un ingénieur pourrait être de traduire les problèmes métier en schémas de flux d’action que les agents peuvent exécuter, plutôt que de comparer qui peut écrire des fonctions plus belles.
Shiwen: Quels conseils donneriez-vous aux équipes qui veulent essayer ?
Yongliang: Commencez par tester vos propres tâches de code réelles, sans utiliser des chiffres de benchmarks pour guider votre choix. Prenez une tâche spécifique de correction de bogues ou de redéveloppement, exécutez-la avec les méthodes de Memdoor ou GVS5H, et notez le temps, le coût des tokens et le taux de réussite. De plus, il est essentiel de définir des critères de validation, comme la nécessité de passer les tests unitaires et la révision humaine ; sinon, plusieurs agents peuvent facilement se piéger eux-mêmes. Enfin, ne considérez pas les modèles locaux comme un repas gratuit : il faut prendre en compte l’équipement, la précision quantitative et le retard de raisonnement. Si votre équipe n’a pas d’expérience avec la gestion des GPU locaux, il est plus réaliste de commencer par des solutions BYOK comme OpenRouter.
SIGNATURE: Yongliang