Tess-4.5-27B, un modèle de code conçu pour l’exécution locale

SSacha

La première chose à comprendre, c’est que Tess-4.5-27B est un modèle ouvert de 27 milliards de paramètres, dérivé de Qwen3.8-27B et publié sous licence Apache 2.0, d’après AlphaSignal. Il est conçu pour des agents de programmation qui fonctionnent sur une machine locale, et non seulement pour répondre à une question de code dans une fenêtre de conversation. Un agent de ce type peut, selon le contexte, modifier des fichiers, appeler des outils ou lancer des commandes. L’idée est donc de fournir un modèle qui accompagne une tâche de programmation en plusieurs étapes, plutôt que de produire uniquement un fragment de texte à copier. Le chiffre mis en avant par Continuity Research est une consommation de tokens réduite de 25 % au total par rapport au modèle de base, tout en obtenant le même score global sur BenchLocal. Cette évaluation attribue à Tess 133 points sur 150, comme à Qwen3.8-27B. Il faut garder les deux éléments ensemble : le score comparable et la baisse de tokens sont des résultats annoncés par le projet, pas une preuve que Tess serait supérieur dans tous les usages. Pour un développeur, le bénéfice possible serait de faire réaliser certaines tâches avec moins de texte généré. Mais cela ne permet pas de conclure à une baisse du temps d’attente, ni à une réduction générale des besoins en calcul : ces points ne sont pas établis par les chiffres disponibles.

SSacha

Continuity Research indique avoir entraîné Tess à partir de 127 sessions d’ingénierie, représentant 39,8 millions de tokens, avec des fenêtres de contexte de 64 000 tokens. Ces chiffres décrivent le corpus et le cadre d’entraînement annoncés, mais ils ne permettent pas de dire que le modèle aurait été formé uniquement sur ces sessions, ni de comparer leur taille à l’ensemble des données d’autres modèles. Une fenêtre de contexte, pour se représenter cela, correspond à la quantité d’informations que le modèle peut prendre en compte dans un même échange ou une même tâche. Dans un travail de code, cela pourrait aider à garder ensemble plusieurs consignes ou éléments de contexte, sans garantir que le modèle les interprète toujours correctement. Le projet a aussi évalué 182 réponses portant sur les appels d’outils : Tess n’y aurait produit aucun appel halluciné, tandis qu’un checkpoint de développement non ancré en aurait produit 42. C’est un indicateur intéressant, parce qu’un agent doit choisir le bon outil et l’appeler au bon moment, mais il concerne cet échantillon précis. On ne peut donc pas en déduire que Tess n’appellera jamais un outil à tort dans une autre situation. Le lancement mentionne également des têtes de prédiction multi-tokens, associées à la génération de code. Le projet annonce 96 tokens par seconde sur une RTX 4090 et 38 sur un Apple M4 Max avec ces têtes, des mesures qui dépendent de ces configurations et ne prédisent pas automatiquement la vitesse sur un autre appareil.

SSacha

La proposition vise les personnes qui souhaitent essayer un agent de programmation local, notamment des développeurs qui veulent que le modèle s’exécute sur leur propre matériel. Des versions quantifiées au format GGUF sont proposées, avec une déclinaison Q4_K_M de 16,5 Go et une Q8_0 de 28,6 Go. La quantification réduit la taille des poids du modèle afin de rendre différentes configurations possibles, avec des compromis qui ne peuvent pas être résumés par la seule taille du fichier. Ainsi, voir une version à 16,5 Go ne suffit pas à garantir qu’elle fonctionnera sans difficulté sur une machine dotée d’une mémoire de 24 Go : les besoins réels dépendent aussi du logiciel et de l’usage. Le lancement présente des fichiers GGUF, mais les informations disponibles ne détaillent pas ici toutes les étapes d’installation, ni les performances de chaque variante sur chaque matériel. Le projet fournit aussi des indications pour le déploiement avec vLLM, et le format GGUF est associé à des outils comme llama.cpp. Ce sont des pistes d’intégration, pas une assurance que toutes les configurations se comporteront de la même façon. Les chiffres de débit donnent des repères pour deux appareils précis, mais ils ne sont pas des promesses de vitesse pour l’ensemble des ordinateurs personnels. Avant de choisir une version, il faudrait donc vérifier la mémoire disponible et tester le modèle dans le logiciel et sur les tâches que l’on utilise réellement.

SSacha

La réserve principale concerne la provenance des performances : AlphaSignal précise que les mesures viennent des documents de lancement de Continuity Research et qu’elles n’ont pas été vérifiées indépendamment dans son article. Le score de 133 sur 150 à BenchLocal et la baisse de tokens de 25 % au total sont donc à présenter comme des résultats communiqués par le projet. Celui-ci annonce aussi une réduction de 32 % des tokens pour les tâches en ligne de commande. BenchLocal rassemble 150 scénarios portant sur des activités différentes, notamment le travail au terminal, les appels d’outils, le suivi d’instructions ou la détection de bugs. C’est utile pour comparer des modèles sur un ensemble défini, mais cela ne reproduit pas nécessairement la diversité des projets de programmation réels. Les chiffres ne disent pas non plus que chaque tâche sera réussie avec moins de texte, ni que la qualité sera identique dans tous les langages et toutes les bases de code. Pour les appels d’outils, l’absence d’erreur dans 182 réponses évaluées est encourageante, mais elle reste bornée par le nombre et la nature des réponses testées. Même chose pour la vitesse : les résultats annoncés correspondent à une RTX 4090 et à un Apple M4 Max, avec les têtes de prédiction multi-tokens. Le bon réflexe est donc de distinguer ce qui a été mesuré dans les essais du projet de ce qu’un utilisateur pourrait observer dans son propre environnement.

SSacha

À retenir, Continuity Research propose Tess-4.5-27B, un modèle ouvert de 27 milliards de paramètres dérivé de Qwen3.8-27B et destiné aux agents de programmation locaux. Dans les évaluations publiées par le projet, il obtient le même score global que son modèle de base sur BenchLocal, avec 25 % de tokens en moins au total et 32 % de moins sur les tâches en ligne de commande. Le lancement rapporte aussi zéro appel d’outil halluciné sur 182 réponses évaluées, mais ce résultat ne suffit pas à garantir un comportement sans erreur sur d’autres tâches. Les versions quantifiées et les mesures de vitesse donnent des repères concrets pour envisager une exécution sur du matériel local, sans établir que chaque appareil pourra faire tourner le modèle ni à quelle vitesse. Il n’y a donc pas ici une démonstration indépendante que les agents de code locaux seraient désormais plus rapides, plus sobres en mémoire ou plus stables en général. C’est plutôt une proposition qu’on peut examiner à partir de chiffres précis, en gardant à l’esprit leur périmètre et leur origine. Pour un développeur, l’intérêt sera de vérifier si la baisse de tokens annoncée se retrouve sur ses tâches, et si le modèle s’intègre à son environnement. La comparaison avec le modèle de base est un point de départ utile, pas une conclusion universelle sur la qualité du code. C’est cette combinaison d’un modèle local, de variantes quantifiées et de résultats à confirmer hors des essais du projet qui résume le mieux Tess-4.5-27B.