- A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) es un sistema de IA autoalojado que logra un rendimiento de generación de código a nivel de modelos grandes con una sola GPU de consumo
- Según LiveCodeBench v5, registró 74.6% pass@1-v(k=3), superando a Claude 4.5 Sonnet (71.4%), y logró una mejora de rendimiento de casi el doble frente a la versión anterior
- Manteniendo congelado un modelo de 14B parámetros (Qwen3-14B-Q4_K_M), obtiene alto rendimiento con generación basada en restricciones, bucle de autoverificación y corrección, y selección de candidatos con Geometric Lens
- Funciona de forma completamente autónoma en un entorno local sin nube ni llamadas a API, y el único costo es el de electricidad, por lo que su eficiencia de costos es muy alta frente a modelos basados en API
- En un entorno con GPU RTX 5060 Ti 16GB, procesa 599 tareas en unas 2 horas, lo que muestra que es posible reproducir la capacidad de generación de código de modelos grandes en hardware personal
Resultados del benchmark
- LiveCodeBench v5: 74.6% pass@1-v(k=3), 599 tareas ejecutadas
- Pipeline V3: PlanSearch + reparación PR-CoT autoverificada
- GPQA Diamond: 47.0%, 198 tareas
- SciCode: 14.7%, 341 tareas
- pass@k-v(k=3) no es el resultado de un solo intento, sino un método que incluye generar 3 candidatos, seleccionar con Lens y repetir correcciones en caso de fallo
-
Contribución por etapa en V3 (Ablation Study)
- A: base (sin V3) → 54.9%
- B: Fase 1 (PlanSearch + BudgetForcing + DivSampling) → 67.3% (+12.4pp)
- C: Fase 1+2 (Lens routing) → 67.3% (+0.0pp)
- D: Fase 1+3 (refinamiento autoverificado) → 74.6% (+7.3pp)
- La Fase 3 realiza verificación interna con casos de prueba generados por el propio modelo; no usa respuestas correctas reales
- PR-CoT recuperó 36 de 42 problemas (85.7%) en la Fase 3
Comparación de costo y rendimiento
| Sistema |
LCB pass@1 |
Costo por tarea |
Nota |
| DeepSeek V3.2 Reasoning |
86.2% |
~$0.002 |
API, intento único |
| GPT-5 (high) |
84.6% |
~$0.043 |
API, intento único |
| ATLAS V3 |
74.6% |
~$0.004 |
Solo usa energía local, best-of-3 + repair |
| Claude 4.5 Sonnet |
71.4% |
~$0.066 |
API, intento único |
| Claude 4 Sonnet |
65.5% |
~$0.066 |
API, intento único |
- ATLAS solo incurre en costo eléctrico, sin costo de API
- Con una GPU de 165W, completar 599 tareas tomó alrededor de 1 hora 55 minutos
- La latencia es alta, pero la eficiencia de costos es muy elevada
Cómo funciona
-
Pipeline completo
- Fase 1: Generate
- PlanSearch: extracción de restricciones y generación de planes diversos
- Budget Forcing: control del uso de tokens
- Etapa Verify
- Geometric Lens (C(x)): energy scoring basado en embeddings propios de 5120 dimensiones
- Sandbox: ejecución y verificación del código
- Fase 3: Repair
- Self-Test Generation: el modelo genera sus propios pares de entrada/salida
- PR-CoT Repair: corrección de código basada en chain-of-thought de múltiples perspectivas
- Una única instancia de llama-server se ejecuta sobre K3s y realiza al mismo tiempo speculative decoding y generación de embeddings propios
- Geometric Lens selecciona el mejor código entre los candidatos (87.8% de precisión en tareas con resultados mixtos)
- Las tareas fallidas pasan a la Fase 3 para generar pruebas propias y hacer correcciones iterativas
Instalación y ejecución
- Clonar el repositorio de GitHub, copiar el archivo de configuración y ejecutar el script de instalación
- Ejecutar el benchmark V3 con
benchmark/v3_runner.py
- Para el procedimiento detallado de instalación, consultar docs/SETUP.md
Hardware y reproducibilidad
| Recurso |
Mínimo |
Entorno de prueba |
| GPU VRAM |
16 GB |
RTX 5060 Ti 16 GB |
| RAM del sistema |
14 GB |
16 GB |
| Python |
3.10+ |
3.11 |
| OS |
RHEL 9 / Ubuntu 24 |
RHEL 9 (VM de Proxmox) |
- Se reprodujo en un entorno con VM de Proxmox + passthrough de GPU por VFIO
- También puede ejecutarse en otras GPU NVIDIA con 16GB o más de VRAM, aunque requiere ajustes de drivers y configuración de VRAM
- Variables principales de ajuste:
- cantidad de slots
--parallel (2 por defecto, reducir a 1 si falta VRAM)
- cuantización de caché KV (Q4_0)
- longitud de contexto por slot (20480 tokens por defecto)
- versión CUDA 12.8 probada
- Se planea mejorar la portabilidad en V3.1
Hoja de ruta
-
V3.0 (completado, 2026-03-05)
- Basado en Qwen3-14B-Q4_K_M, rendimiento LCB de 74.6%
- Pipeline completado con PlanSearch + BudgetForcing + Geometric Lens + PR-CoT
-
Limitaciones conocidas
- Optimización enfocada en LCB: la optimización para otros benchmarks como GPQA o SciCode es limitada
- Fase 2 (Lens routing): impacto mínimo por falta de dataset (+0.0pp)
- G(x) metric tensor desactivado: al no estar entrenado C(x), no hay una estructura geométrica significativa
- Procesamiento de un solo hilo: no hay soporte para paralelización de tareas
- Bug de stdio en SandboxAdapter: la función de separación de entrada está desactivada (se corregirá en V3.1)
-
V3.1 (en curso)
- Cambio de modelo: Qwen3-14B → Qwen3.5-9B (atención lineal DeltaNet, mejora de velocidad de 3 a 4 veces)
- Reentrenamiento de Lens: recalibración de C(x) basada en retroalimentación en tiempo real
- Rediseño de la Fase 2: reimplementación o eliminación de G(x), corrección del bug de SandboxAdapter
- Incorporación de procesamiento paralelo: mejora de velocidad mediante ejecución paralela de tareas
- Suite de benchmarks ampliada: incluye evaluación de razonamiento y conocimiento además de programación
-
Benchmarks previstos para V3.1
- Programación: LiveCodeBench v5, SciCode y datasets adicionales resistentes a contaminación
- Razonamiento/conocimiento: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt, etc.
- Confidence Router selecciona la ruta según la dificultad de la tarea:
- consulta simple → inferencia rápida basada en RAG (~30 segundos)
- problema complejo de programación → pipeline completo (~20 minutos)
- Objetivo: 80~90% LCB pass@1-v(k=3) y mayor velocidad de procesamiento
Licencia
- Se aplica la A.T.L.A.S Source Available License v1.0
1 comentarios
Opiniones en Hacker News
No espero que los agentes generen grandes bloques de código
En cambio, me resultan mucho más útiles para revisar logs o analizar varios archivos fuente y explicar la causa de un fallo en los tests
Creo que hacen falta benchmarks de depuración que evalúen esta capacidad. Estaría bueno tener pruebas que midan la habilidad con sistemas de build o con la CLI
Por ejemplo, refactoricé toda una app de hard delete a soft delete, y hubo que modificar tanto la lógica de borrado como las consultas
Hacerlo a mano era tedioso y fácil de arruinar, así que agradecí muchísimo que el agente lo resolviera rápido
SWE Bench Pro todavía no está demasiado optimizado, así que sigue siendo confiable
En cambio, SWE normal o LCB ya perdieron utilidad por la competencia de inflar métricas
Aclaro que soy fundador de Quesma
Ya casi no escribo código directamente, ni en la empresa ni en proyectos personales
Principalmente trabajo creando herramientas para desarrolladores en Rust y TypeScript
Despliego con kubectl / helm y, si hay problemas, el agente los depura por su cuenta
Es sorprendente lo rápido que termina algo que antes tomaba horas
Me gustaría recomendarles a los desarrolladores que prueben modelos como MiniMax y Kimi en trabajo real
Pero sus desventajas también aparecen rápido: mayor uso de tokens de razonamiento, salida lenta, menor calidad, etc.
Aun así, si manejas bien el routing de modelos y el reasoning budget, puedes ahorrar bastante
También es importante optimizar la app y los prompts para reducir los tokens de salida
Pero en tareas difíciles, la eficiencia importa más que el simple costo por token
El enfoque del enlace también funciona con Sonnet y Opus
Eso sí, MiniMax y Qwen todavía no llegan a ese nivel
Al final, la clave está en el diseño del harness para distinguir qué modelo es rentable para cada tarea
Probé Opus 4.6 medium y me arrepentí enseguida. La diferencia de calidad es enorme
resultado comparativo de aibenchy
No me preocupo por el consumo de tokens; en el plan de 10 euros al mes se pueden hacer 1500 solicitudes cada 5 horas
En la práctica, no es más lento que Opus o Sonnet
En benchmarks los modelos de Anthropic parecen mejores, pero en trabajo real casi no hay diferencia
Si MiniMax se atasca, cambio a Opus, y luego vuelvo a MiniMax
Opus consume el presupuesto rápido, pero MiniMax es prácticamente ilimitado
Encuentra problemas más rápido que Claude o GPT
Pero tiene un grave problema de consistencia de contexto: cuando reescribe código, pequeños errores pueden arruinarlo todo
En este momento es una carrera interminable de precios
DeepSeek vence a todos los modelos en una sola ejecución, y el costo también queda en la mitad de la electricidad local
La idea es generar varias respuestas, elegir candidatos prometedores con un modelo pequeño y repetir el ciclo de pruebas con retroalimentación
Va convergiendo gradualmente, como una especie de algoritmo genético
Los modelos pequeños están demasiado ajustados a los tests y en entornos reales rinden fatal
Yo siempre soy escéptico
Pasan benchmarks, pero en la práctica muchas veces les falta generalidad
Aun así, me parece interesante el intento de hacer más slim los modelos
En programación de sistemas (C++, Rust), todavía hay una gran brecha frente al nivel de Sonnet 4.5
Los modelos abiertos pierden demasiado tiempo resolviendo errores de sintaxis y a menudo también pierden la consistencia lógica
Tengo suficientes GPU locales, pero también me preocupan los problemas de licencia de los modelos en la nube
Genera varias soluciones y calcula una huella de embeddings (fingerprint) para cada código a fin de predecir su exactitud
Una red neuronal pequeña llamada Cost Field les asigna puntaje y elige el código con más probabilidades de ser correcto
Gracias a eso reduce el tiempo de testeo y aun así selecciona la respuesta correcta con 88% de precisión
De hecho, un modelo grande podría ser estructuralmente más simple
Mientras leía esto, el precio de la GPU ya había subido a $1000
Este proyecto escrito por IA ejecuta su propio benchmark de una forma completamente distinta de LiveCodeBench
El README aclara que la puntuación de ATLAS proviene de resultados del pipeline V3 (best-of-3 + Lens + reparación iterativa) sobre 599 tareas de LCB
En cambio, las puntuaciones de los modelos rivales están medidas en ejecución única (pass@1), así que la comparación no es justa
Si Sonnet o GPT5.4 se evaluaran del mismo modo, podrían sacar puntajes más altos
En el README hay muchas estructuras que ni siquiera se usan, lo que deja ver la fragilidad del código generado automáticamente por IA
Me pregunto si este tipo de benchmark solo funciona para optimización específica del problema
Al final, probablemente terminaremos aprendiendo los límites de lo que no se puede comprimir de la generalidad
La expresión “Geometric Lens routing” suena rarísima
Parece simplemente un término inventado por GPT
Aunque soy escéptico, de verdad me alegra ver este tipo de experimentos con modelos abiertos
Sería un gran avance si se pudieran correr modelos en local incluso en una PC de gama media-alta