El problema fundamental que ATLAS V3 aborda es cómo maximizar la utilidad y el rendimiento de modelos de lenguaje grandes (LLM) de tamaño moderado en entornos de recursos limitados, específicamente en una única GPU de consumidor. En lugar de depender de la escalada de parámetros del modelo o de costosas APIs en la nube, ATLAS V3 propone que una infraestructura de inferencia inteligente, que envuelve un modelo congelado más pequeño, puede lograr un rendimiento competitivo. Esto se logra mediante un pipeline de generación estructurada, verificación basada en energía y auto-reparación iterativa.
La relevancia de esta aproximación radica en la creciente demanda de soluciones de IA que sean privadas, rentables y soberanas en cuanto a datos. Al mantener todo el proceso de inferencia y refinamiento local, ATLAS V3 elimina las preocupaciones sobre la fuga de datos, la dependencia de proveedores de API y los costos recurrentes asociados con los servicios en la nube. Históricamente, la mejora del rendimiento de los LLM se ha centrado en el escalado de modelos (más parámetros, más datos de entrenamiento), pero ATLAS V3 demuestra que la ingeniería de prompts y la lógica de control externa pueden desbloquear capacidades latentes en modelos más pequeños, un enfoque que recuerda a los sistemas expertos y la planificación simbólica que precedieron a la era de los LLM.
Este enfoque se alinea con la tendencia de "Edge AI" y "AI on device", donde la computación se acerca a la fuente de los datos para reducir latencia, mejorar la privacidad y disminuir los costos operativos. La capacidad de ejecutar un sistema de este calibre en hardware de consumidor democratiza el acceso a capacidades avanzadas de IA, permitiendo a individuos y pequeñas organizaciones beneficiarse de la IA generativa sin la barrera de entrada de la infraestructura de hyperscaler.
Arquitectura del Sistema
La arquitectura de ATLAS V3 se organiza en un pipeline de tres fases principales: Generación, Verificación y Reparación, orquestadas por un servidor llama.cpp parcheado que maneja la inferencia del modelo y la generación de embeddings. El modelo base es un Qwen3-14B-Q4_K_M congelado y cuantizado, ejecutándose en una GPU con 16GB de VRAM.
La Fase 1 (Generación) comienza con PlanSearch, que extrae restricciones del problema y genera planes diversos. Estos planes son alimentados a Budget Forcing, que controla la asignación de tokens de "pensamiento" para guiar la generación. Esto produce múltiples candidatos de solución (k=3 en la configuración actual).
La fase de Verificación utiliza el Geometric Lens (C(x)), un campo de energía que selecciona el mejor candidato entre los generados, basándose en embeddings auto-generados de 5120 dimensiones. Los candidatos seleccionados se ejecutan en un Sandbox aislado para verificar su funcionalidad. Si todos los candidatos fallan, el flujo pasa a la Fase 3.
La Fase 3 (Reparación) activa Self-Test Gen, donde el modelo genera sus propios pares de entrada/salida para crear casos de prueba internos. Estos tests se utilizan en PR-CoT Repair (Multi-perspective Chain-of-Thought), un mecanismo de refinamiento iterativo donde el modelo intenta reparar la solución fallida. El código reparado se vuelve a ejecutar en el Sandbox hasta que pasa o se agotan los intentos. El servidor llama.cpp modificado es crucial, ya que no solo proporciona la inferencia del LLM, sino también la capacidad de generar los self-embeddings necesarios para el Geometric Lens y soporta la decodificación especulativa para un throughput de ~100 tokens/segundo. La orquestación se gestiona mediante K3s, con manifiestos de despliegue para los diversos componentes.
Pipeline de Generación y Refinamiento de Código ATLAS V3
- 1 PlanSearch Extracción de restricciones y generación de planes diversos.
- 2 Budget Forcing Control de tokens de pensamiento para guiar la generación de candidatos.
- 3 Geometric Lens Selección del mejor candidato (k=3) mediante scoring de energía de self-embed...
- 4 Sandbox Ejecución aislada del código candidato para verificación.
- 5 Self-Test Gen Generación de casos de prueba internos por el modelo si el código falla.
- 6 PR-CoT Repair Refinamiento iterativo de la solución fallida usando Chain-of-Thought multi-p...
- 7 Sandbox Re-ejecución del código reparado para verificación.
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | Qwen3-14B-Q4_K_M (frozen) | Modelo de lenguaje grande (LLM) base, cuantizado para eficiencia en VRAM. Cuantización Q4_K_M, 14B parámetros, congelado (no fine-tuning). |
| compute | llama.cpp (patched server) | Servidor de inferencia LLM modificado para decodificación especulativa y generación de self-embeddings. Soporte para decodificación especulativa (~100 tok/s) y embeddings de 5120 dimensiones. |
| orchestration | K3s | Orquestación de contenedores ligera para desplegar los componentes del pipeline. vs Docker Compose, Kubernetes (completo) |
| security | Sandbox | Entorno de ejecución de código aislado para verificar soluciones generadas. |
Trade-offs
Ganancias
- ▲ Costo operativo
- ▲▲ Privacidad y soberanía de datos
- ▲ Rendimiento en LiveCodeBench
Costes
- ▲ Latencia por tarea
- △ Generalización a otros benchmarks
- △ Portabilidad de hardware
./scripts/verify-install.sh
# Run V3 benchmark
python3 benchmark/v3_runner.pyFundamentos Teóricos
El concepto de refinamiento iterativo y auto-verificación en la generación de código tiene raíces en la investigación de programación automática y sistemas de prueba formales. La idea de que un sistema puede generar sus propios casos de prueba para validar y corregir su salida se remonta a trabajos en verificación de software y síntesis de programas. Por ejemplo, la generación de tests a partir de especificaciones o el uso de técnicas de fuzzing para encontrar errores son principios bien establecidos.
La aplicación de un "campo de energía" como el Geometric Lens para la selección de candidatos evoca conceptos de modelos basados en energía en el aprendizaje automático, popularizados por Yann LeCun y otros en la década de 2000. Estos modelos asignan una "energía" a las configuraciones de entrada, donde configuraciones de baja energía son más deseables. En el contexto de ATLAS, esto se traduce en seleccionar la solución con la energía más baja (o más alta, dependiendo de la definición) como la más prometedora. La "Chain-of-Thought" (CoT) y sus variantes, como PR-CoT, se basan en investigaciones recientes en LLMs que demuestran que guiar al modelo a través de un proceso de razonamiento paso a paso mejora significativamente su capacidad para resolver problemas complejos, un principio que tiene paralelos con la resolución de problemas en la psicología cognitiva y la inteligencia artificial simbólica.