- A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) est un système d’IA auto-hébergé capable d’atteindre des performances de génération de code de niveau grand modèle avec un seul GPU grand public
- Sur LiveCodeBench v5, il a obtenu 74,6 % pass@1-v(k=3), dépassant Claude 4.5 Sonnet (71,4 %), soit une amélioration de performances presque doublée par rapport à la version précédente
- En gardant figé le modèle à 14B paramètres (Qwen3-14B-Q4_K_M), il atteint de hautes performances grâce à une génération sous contraintes, une boucle d’auto-vérification et de correction, et une sélection de candidats par Geometric Lens
- Il fonctionne de manière entièrement autonome en local, sans cloud ni appels API, avec pour seul coût l’électricité, ce qui lui confère une très forte efficacité économique face aux modèles fondés sur des API
- Dans un environnement RTX 5060 Ti 16GB GPU, il traite 599 problèmes en environ 2 heures, montrant que les capacités de génération de code des grands modèles peuvent être reproduites sur du matériel personnel
Résultats des benchmarks
- LiveCodeBench v5 : 74,6 % pass@1-v(k=3), 599 problèmes traités
- Pipeline V3 : PlanSearch + self-verified PR-CoT repair
- GPQA Diamond : 47,0 %, 198 problèmes
- SciCode : 14,7 %, 341 problèmes
- Le pass@k-v(k=3) n’est pas le résultat d’une tentative unique, mais d’une méthode qui génère 3 candidats, sélectionne via Lens, puis applique des corrections itératives en cas d’échec
-
Contribution détaillée de V3 (Ablation Study)
- A : version de base (sans V3) → 54,9 %
- B : Phase 1 (PlanSearch + BudgetForcing + DivSampling) → 67,3 % (+12,4 pp)
- C : Phase 1+2 (Lens routing) → 67,3 % (+0,0 pp)
- D : Phase 1+3 (self-verified refinement) → 74,6 % (+7,3 pp)
- La Phase 3 effectue une vérification interne avec des cas de test générés par le modèle lui-même, sans utiliser les bonnes réponses réelles
- En Phase 3, PR-CoT a permis de récupérer 36 problèmes sur 42 (85,7 %)
Comparaison coûts / performances
| Système |
LCB pass@1 |
Coût par problème |
Remarques |
| DeepSeek V3.2 Reasoning |
86,2 % |
~$0.002 |
API, tentative unique |
| GPT-5 (high) |
84,6 % |
~$0.043 |
API, tentative unique |
| ATLAS V3 |
74,6 % |
~$0.004 |
local uniquement sur électricité, best-of-3 + repair |
| Claude 4.5 Sonnet |
71,4 % |
~$0.066 |
API, tentative unique |
| Claude 4 Sonnet |
65,5 % |
~$0.066 |
API, tentative unique |
- ATLAS n’engendre que des coûts d’électricité, sans frais d’API
- Avec un GPU 165W, l’exécution des 599 problèmes prend environ 1 h 55
- La latence est plus élevée, mais l’efficacité économique est très forte
Principe de fonctionnement
-
Pipeline complet
- Phase 1: Generate
- PlanSearch : extraction de contraintes et génération de plans variés
- Budget Forcing : contrôle de l’usage des tokens
- Étape Verify
- Geometric Lens (C(x)) : energy scoring basé sur des embeddings internes en 5120 dimensions
- Sandbox : exécution et validation du code
- Phase 3: Repair
- Self-Test Generation : le modèle génère lui-même des paires entrée/sortie
- PR-CoT Repair : correction du code fondée sur un chain-of-thought multi-perspective
- Une instance unique de llama-server s’exécute sur K3s et réalise à la fois le speculative decoding et la génération d’embeddings internes
- Geometric Lens sélectionne le meilleur code parmi les candidats (87,8 % de précision sur les problèmes à résultats mixtes)
- Les problèmes en échec passent en Phase 3 pour une génération de tests autonome et des corrections itératives
Installation et exécution
- Cloner le dépôt GitHub, copier le fichier de configuration, puis lancer le script d’installation
- Exécuter le benchmark V3 avec
benchmark/v3_runner.py
- Voir docs/SETUP.md pour la procédure détaillée
Matériel et reproductibilité
| Ressource |
Minimum |
Environnement de test |
| GPU VRAM |
16 GB |
RTX 5060 Ti 16 GB |
| RAM système |
14 GB |
16 GB |
| Python |
3.10+ |
3.11 |
| OS |
RHEL 9 / Ubuntu 24 |
RHEL 9 (Proxmox VM) |
- Reproduit dans un environnement Proxmox VM + passthrough GPU VFIO
- Fonctionne aussi sur d’autres GPU NVIDIA avec au moins 16GB de VRAM, mais nécessite des ajustements des pilotes et des paramètres VRAM
- Principales variables d’ajustement :
- nombre de slots
--parallel (2 par défaut, réduire à 1 si la VRAM manque)
- quantification du cache KV (Q4_0)
- longueur de contexte par slot (20480 tokens par défaut)
- tests validés avec CUDA 12.8
- V3.1 doit améliorer la portabilité
Feuille de route
-
V3.0 (terminé, 2026-03-05)
- Basé sur Qwen3-14B-Q4_K_M, performances LCB à 74,6 %
- Pipeline PlanSearch + BudgetForcing + Geometric Lens + PR-CoT finalisé
-
Limites connues
- Optimisation centrée sur LCB : optimisation insuffisante pour d’autres benchmarks comme GPQA ou SciCode
- Phase 2 (Lens routing) : impact limité faute de données (+0,0 pp)
- G(x) metric tensor désactivé : absence de structure géométrique significative car C(x) n’est pas entraîné
- Traitement mono-thread : pas de prise en charge de la parallélisation des problèmes
- Bug stdio de SandboxAdapter : fonction de séparation des entrées désactivée (correction prévue en V3.1)
-
V3.1 (en cours)
- Changement de modèle : Qwen3-14B → Qwen3.5-9B (attention linéaire DeltaNet, vitesse multipliée par 3 à 4)
- Réentraînement du Lens : recalibrage de C(x) basé sur du feedback en temps réel
- Refonte de la Phase 2 : réimplémentation ou suppression de G(x), correction du bug SandboxAdapter
- Introduction du traitement parallèle : amélioration du débit via l’exécution parallèle des problèmes
- Suite de benchmarks étendue : inclut des évaluations de raisonnement et de connaissances en plus du code
-
Benchmarks V3.1 prévus
- Code : LiveCodeBench v5, SciCode, et jeux de données supplémentaires résistants à la contamination
- Raisonnement / connaissances : GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt, etc.
- Le Confidence Router choisit le parcours selon la difficulté du problème :
- requête simple → raisonnement rapide basé sur RAG (~30 secondes)
- problème de code complexe → pipeline complet (~20 minutes)
- Objectif : 80 à 90 % de LCB pass@1-v(k=3) avec une vitesse de traitement plus élevée
Licence
- A.T.L.A.S Source Available License v1.0
1 commentaires
Avis Hacker News
Je n’attends pas d’un agent qu’il génère de gros blocs de code
En revanche, il est bien plus utile pour parcourir des logs ou analyser plusieurs fichiers source afin d’expliquer la cause d’un échec de test
Je pense qu’il faudrait des benchmarks de débogage pour évaluer ce type de capacité. Ce serait bien d’avoir des tests qui mesurent aussi la maîtrise des systèmes de build ou de la CLI
Par exemple, j’ai refactoré toute une application pour passer de hard delete à soft delete, et il a fallu modifier à la fois la logique de suppression et les requêtes
Le faire à la main était fastidieux et propice aux erreurs, donc j’étais vraiment reconnaissant que l’agent le fasse rapidement
SWE Bench Pro n’a pas encore été trop optimisé, donc il reste fiable
En revanche, le SWE classique ou LCB ont déjà perdu en utilité à force de course au gonflage des scores
Pour référence, je suis le fondateur de Quesma
Désormais, je n’écris presque plus de code moi-même, que ce soit au travail ou sur des side projects
Je crée surtout des outils pour développeurs en Rust et TypeScript
Il déploie avec kubectl / helm et, en cas de problème, il débogue lui-même
Des tâches qui prenaient des heures se terminent en un instant, c’est assez bluffant
J’aimerais recommander aux développeurs d’essayer des modèles comme MiniMax et Kimi dans leur vrai travail
Mais leurs défauts apparaissent vite aussi — hausse de l’usage des tokens de raisonnement, sorties lentes, baisse de qualité, etc.
Cela dit, on peut fortement réduire les coûts en gérant bien le routage des modèles et le reasoning budget
Il est aussi important d’optimiser l’application et les prompts pour réduire les tokens de sortie
Mais sur les tâches difficiles, l’efficacité compte plus que le simple prix au token
L’approche du lien fonctionne aussi avec Sonnet et Opus
En revanche, MiniMax et Qwen n’en sont pas encore là
Au final, l’essentiel est de concevoir un harness capable de distinguer quel modèle est le plus rentable selon la tâche
J’ai essayé Opus 4.6 medium et je l’ai regretté immédiatement. L’écart de qualité est trop grand
résultats comparatifs aibenchy
Je ne me soucie pas de l’usage des tokens, avec l’abonnement à 10 euros par mois on peut faire 1500 requêtes toutes les 5 heures
En pratique, ce n’est pas plus lent qu’Opus ou Sonnet
Sur benchmark, les modèles d’Anthropic semblent meilleurs, mais sur du travail réel, il n’y a presque pas de différence
Si MiniMax bloque, il suffit de basculer sur Opus, puis de revenir à MiniMax
Opus épuise vite le budget, alors que MiniMax est pratiquement illimité
Il trouve les problèmes plus vite que Claude ou GPT
Mais il a de gros problèmes de cohérence contextuelle — au moment de réécrire du code, une petite imprécision peut tout casser
En ce moment, c’est une course sans fin sur les prix
DeepSeek bat tous les modèles en exécution unique, et son coût représente à peine la moitié de l’électricité locale
Le principe est de générer plusieurs réponses, de sélectionner les candidats prometteurs avec un petit modèle, puis d’itérer avec des tests et du feedback
Cela converge progressivement, un peu comme un algorithme génétique
Les petits modèles sont surajustés aux tests, et dans des conditions réelles leurs performances sont médiocres
Je reste toujours sceptique
Les benchmarks sont parfois réussis, mais dans la pratique la polyvalence manque souvent
Cela dit, la tentative de réduire la taille des modèles reste intéressante
En programmation système (C++, Rust), il reste encore un gros écart avec le niveau de Sonnet 4.5
Les modèles open source passent trop de temps à corriger des erreurs de syntaxe et perdent souvent leur cohérence logique
J’ai suffisamment de GPU en local, mais les problèmes de licence des modèles cloud m’inquiètent aussi
Elle génère plusieurs solutions, puis calcule une empreinte d’embedding (fingerprint) de chaque code pour prédire sa précision
Un petit réseau neuronal appelé Cost Field attribue ensuite un score pour choisir le code le plus prometteur
Cela permet de réduire le temps de test tout en sélectionnant la bonne réponse avec une précision de 88 %
Un grand modèle peut au contraire être structurellement plus simple
Pendant que je lisais, le prix du GPU est déjà passé à 1000 $
Ce projet écrit par IA exécute son propre benchmark d’une façon totalement différente de LiveCodeBench
Le README précise que le score d’ATLAS correspond au pipeline V3 (best-of-3 + Lens + iterative repair) sur 599 tâches LCB
En revanche, les scores des modèles concurrents reposent sur une exécution unique (pass@1), donc la comparaison est injuste
Si on testait Sonnet ou GPT5.4 de la même manière, ils obtiendraient probablement de meilleurs scores
Le README contient aussi beaucoup de structures jamais réellement utilisées, ce qui révèle la fragilité du code généré automatiquement par IA
Je me demande si ce type de benchmark n’est efficace que pour une optimisation spécifique au problème
Au final, nous allons probablement apprendre qu’il existe une limite incompressible à la généralité
L’expression « Geometric Lens routing » est vraiment bizarre
On dirait juste un terme inventé par GPT
Je reste sceptique, mais je suis vraiment ravi de voir ce genre d’expériences sur des modèles open source
Si on peut faire tourner des modèles en local sur un PC de milieu/haut de gamme, ce serait une vraie avancée