Atlas, el motor de inferencia LLM open source desarrollado por Avarok Cybersecurity, alcanza 103 tokens por segundo en Qwen3.5-35B-A3B usando speculative decoding con MTP, 2,8 veces más rápido que vLLM en las mismas condiciones. El proyecto liberó su código en GitHub el 6 de mayo de 2026 y está optimizado para hardware NVIDIA Blackwell, específicamente las unidades GB10 del DGX Spark y la SM121.
En 30 segundos
- Atlas es un motor de inferencia escrito en Rust puro, sin Python ni PyTorch, con más de 20 kernels compilados a medida para Blackwell.
- Logra 103 tok/s en Qwen3.5-35B-A3B con MTP speculative decoding y 43,8 tok/s en el modelo de 122B.
- El código fuente ya está en GitHub bajo licencia abierta; el equipo lo describe como “built for the community”.
- Qwen3.6 ofrece ventana de contexto de 1 millón de tokens, mejora SWE-bench de ~70% a 78,8%, y es 3x más rápido que la versión anterior.
- Por ahora, el soporte oficial es para GPUs Blackwell (SM120/SM121); otros chips están en el roadmap.
Qué es Atlas: el motor de inferencia built for speed
Atlas es un motor de inferencia para LLMs desarrollado por Avarok Cybersecurity, escrito en Rust desde cero, sin dependencias de Python ni PyTorch. La apuesta es simple: si eliminás la capa de abstracción que introduce PyTorch y escribís directamente contra el hardware, ganás velocidad. Y según el anuncio en el foro de NVIDIA, esa apuesta funcionó.
El engine compila más de 20 kernels personalizados optimizados específicamente para las unidades de cómputo del GB10, el chip que equipa el DGX Spark y la SM121 de NVIDIA. No es un motor genérico que después se ajusta al hardware; está construido al revés: el hardware primero, el software encima.
Esto importa porque la mayoría de los frameworks de inferencia apuntan a la portabilidad. Atlas apunta a la velocidad. Son objetivos distintos y a veces incompatibles.
Rendimiento: 103 tokens por segundo en un modelo de 35B
Los números que Avarok publica son concretos: 103 tokens por segundo en Qwen3.5-35B-A3B con MTP speculative decoding activado. En el modelo de 122B, el throughput cae a 43,8 tok/s, lo cual sigue siendo sólido para un modelo de ese tamaño corriendo en hardware local.
La comparación directa contra vLLM vanilla arroja 2,8x de diferencia a favor de Atlas. ¿Alguien verificó ese número de forma independiente? Todavía no hay benchmarks de terceros publicados, así que tomalo con pinzas hasta que aparezcan réplicas externas. El benchmark es del propio fabricante.
Dicho esto, la arquitectura explica por qué estos números son plausibles. MTP speculative decoding permite que el modelo genere tokens candidatos en paralelo y los verifique en lote, reduciendo la latencia por token. Combinado con kernels escritos directamente para Blackwell, la brecha con frameworks más genéricos tiene sentido. Cubrimos ese tema en detalle en nuestro artículo sobre evitar costos excesivos en herramientas.
A quiénes les importa esto en producción: si tenés un caso de uso donde la latencia de respuesta afecta la experiencia de usuario (assistants en tiempo real, análisis interactivo de documentos, pipelines de código), pasar de 37 tok/s a 103 tok/s es la diferencia entre una respuesta que se siente fluida y una que parece que el modelo está pensando demasiado.
Qwen3.6: el modelo detrás de estos benchmarks
Qwen3.6-35B-A3B, disponible en HuggingFace en formato FP8, es la versión que Atlas empuja al límite. La diferencia respecto a Qwen3.5 no es trivial.
La ventana de contexto salta a 1 millón de tokens (el 3.5 llegaba a 128K). La arquitectura combina atención lineal con Mixture of Experts dispersa, lo que le permite escalar sin crecer proporcionalmente en cómputo. Y en SWE-bench —el benchmark para tareas reales de ingeniería de software— pasa de ~70% a 78,8%.
Otro dato que vale notar: el output ratio en razonamiento mejora de 9% a 17%. Esto significa que el modelo produce más razonamiento útil por token de input, lo que se traduce en respuestas más densas en contenido relevante.
¿Y es 3x más rápido que su predecesor, como afirma Alibaba? Según la comparativa publicada por AIMadeTools, la mejora real depende del caso de uso, pero en inferencia local con hardware moderno los números son consistentes con esa afirmación.
Por qué auto-hospedar tu inferencia tiene sentido (y cuándo no)
Ponele que trabajás en una empresa de salud y necesitás procesar historias clínicas con un LLM. Mandar ese texto a una API externa implica que los datos salen de tu infraestructura, pasan por servidores de terceros, y dependés de sus políticas de retención. No siempre es viable legalmente, y menos en sectores regulados.
Con Atlas corriendo on-premise, los datos no salen de tu máquina. Controlás la latencia porque no dependés de la congestión de una API compartida. Y en escenarios de alto volumen, el costo operativo de mantener tu propia GPU se vuelve más conveniente que pagar por millones de tokens mensuales.
Eso sí: la infraestructura tiene un costo de entrada. Una GB10 o una RTX Pro 6000 no son hardware de consumo. Si tu volumen es bajo o tu caso de uso no requiere control de datos, una API cloud sigue siendo la opción más práctica. El punto es que ahora tenés una alternativa real con rendimiento comparable. Profundizamos sobre esto en nuestro análisis de cambios recientes en asistentes de código.
Alternativas: vLLM, Ollama y LM Studio frente a Atlas
No es la primera vez que alguien quiere correr un LLM grande de forma local. El ecosistema tiene opciones maduras. La pregunta es cuál encaja con qué caso de uso.
| Herramienta | Fortaleza principal | Hardware | Setup | Velocidad relativa |
|---|---|---|---|---|
| Atlas | Throughput máximo en Blackwell | NVIDIA GB10, RTX Pro 6000 | Docker + configuración manual | 103 tok/s (35B) |
| vLLM | PagedAttention, batching continuo, multi-usuario | NVIDIA A100/H100/RTX | Moderado | ~37 tok/s (35B, estimado) |
| Ollama | Simplicidad, CLI instantáneo | CPU + GPU consumo | 5 minutos | Varía; menor que vLLM en GPU |
| LM Studio | GUI, multi-modelo concurrente | CPU + GPU consumo/pro | Plug and play | Similar a Ollama |
vLLM sigue siendo la opción más madura para producción multi-usuario: tiene PagedAttention, batching continuo, y una comunidad grande. Si tu equipo ya lo conoce y no tenés hardware Blackwell, Atlas no te da ventaja.
Ollama y LM Studio apuntan a otro segmento: devs que quieren probar modelos rápido sin configurar nada. Para exploración y prototipado, son difíciles de superar. Para producción con requisitos de throughput, quedan cortos.
Atlas ocupa un nicho específico: hardware de última generación, requisito de velocidad máxima, y equipo técnico que puede mantener la configuración. No es para todos, y tampoco pretende serlo (según su propia documentación, es “made for the community” de desarrolladores con acceso a Blackwell).
Cómo implementarlo: lo que necesitás saber antes de empezar
El repositorio en GitHub tiene instrucciones para levantar Atlas vía Docker. El proceso básico:
- Hardware requerido: GPU NVIDIA Blackwell, preferentemente GB10 (DGX Spark) o SM121. Las tarjetas de consumo de generaciones anteriores no están soportadas en esta versión.
- Levantar el contenedor Docker con la imagen oficial de Atlas.
- Configurar MTP speculative decoding en el archivo de configuración para aprovechar el throughput máximo.
- Servir el modelo Qwen3.6-35B-FP8 (o 3.5 si querés el benchmark replicado) y medir latencia con un cliente de prueba.
- Monitorear en producción: Atlas expone métricas compatibles con el ecosistema estándar de observabilidad.
El peso del modelo en FP8 es lo que permite que quepa en la VRAM disponible sin sacrificar demasiada precisión. Para el modelo de 35B activo con 3B de parámetros en cada paso, el footprint del engine completo ronda los 2,5 GB adicionales.
Si tu equipo está evaluando infraestructura para modelos grandes y querés hostear en un servidor propio, donweb.com tiene opciones de servidores dedicados donde podés montar esta stack con control total del hardware.
Limitaciones reales que el anuncio no destaca
El soporte actual es exclusivo para Blackwell. La SM120 y SM121 están soportadas; el resto del catálogo de NVIDIA queda afuera por ahora. El equipo menciona soporte para otras GPUs en el roadmap, pero sin fecha concreta. Complementá con nuestro análisis de cuándo otras herramientas tienen limitaciones.
A esto se suma que la documentación todavía está en construcción. Es un proyecto de open source reciente, y eso significa que encontrás huecos: configuraciones no documentadas, comportamientos no especificados, y dependencia de la comunidad para resolver problemas en producción.
El rendimiento con contextos largos tampoco está benchmarkeado públicamente. Con ventanas de 1M tokens como las que soporta Qwen3.6, el throughput puede variar significativamente. Los 103 tok/s son para contextos normales; con 500K tokens en el prompt, los números serán distintos.
Qué está confirmado / Qué no
| Item | Estado |
|---|---|
| 103 tok/s en Qwen3.5-35B con MTP | Confirmado por Avarok (benchmark interno) |
| 2,8x más rápido que vLLM vanilla | Confirmado por Avarok (benchmark interno, sin réplica externa) |
| Código abierto en GitHub | Confirmado — repositorio disponible ahora |
| Soporte para GPUs pre-Blackwell | Pendiente — en roadmap sin fecha |
| Benchmarks de contexto largo (500K+) | No publicados |
| Validación independiente de velocidad | Pendiente — mayo 2026, no hay réplicas externas conocidas |
Casos de uso reales: quién debería prestarle atención
Un equipo que desarrolla un assistant de análisis de código para uso interno puede necesitar procesar miles de archivos en batch. Con 43,8 tok/s en el modelo de 122B, podés correr análisis profundos sin esperar minutos por archivo. La diferencia frente a una API cloud no es solo de velocidad: es de costo previsible y datos que no salen de tu red.
Para agentes autónomos que necesitan hacer múltiples llamadas al modelo en ciclos cortos, el throughput también importa. Un agente que tarda 3 segundos por turno se siente natural; uno que tarda 12 parece roto.
Startups en etapa temprana con hardware limitado probablemente estén mejor con Ollama o vLLM en una A10. El acceso a Blackwell tiene un costo de entrada que no siempre tiene sentido antes de validar el producto.
Errores comunes al implementar inferencia local
Elegir el modelo por benchmark sin revisar la ventana de contexto. Si tu caso de uso requiere contextos de más de 128K tokens, un modelo con ventana corta va a truncar la entrada silenciosamente o arrojar un error. Qwen3.6 con 1M de contexto cambia lo que es posible, pero solo si el engine puede manejarlo. Verificá antes de asumir. Sobre eso hablamos en técnicas para mejorar tus generaciones.
No activar speculative decoding y después quejarse de que es lento. En Atlas, MTP speculative decoding es lo que lleva los números de 60 tok/s a 103 tok/s. Viene desactivado por defecto en varias configuraciones. Si no lo configuraste explícitamente, no estás midiendo el rendimiento real del sistema.
Ignorar el footprint de memoria del engine. El modelo de 35B en FP8 ocupa menos de lo esperado en VRAM, pero el engine, el batch buffer y las capas de atención se suman. Planear con los números del papel y no con mediciones reales en tu hardware específico es la forma más rápida de tener un sistema inestable en producción.
Preguntas Frecuentes
¿Cuál es el motor de inferencia LLM open source más rápido disponible hoy?
En hardware Blackwell (GB10/SM121), Atlas alcanza 103 tok/s en modelos de 35B, 2,8x por encima de vLLM en las mismas condiciones según los benchmarks de Avarok. Para hardware de generaciones anteriores, vLLM con PagedAttention sigue siendo la referencia más validada independientemente. La respuesta depende del hardware que tenés.
¿Cómo puedo conseguir 100+ tokens por segundo en un modelo de 35B?
Necesitás una GPU NVIDIA Blackwell (GB10 o similar), instalar Atlas vía Docker, usar el modelo Qwen3.5-35B-A3B en formato FP8, y activar MTP speculative decoding en la configuración. Sin los tres elementos juntos —hardware correcto, engine optimizado y speculative decoding activo— no llegás a ese número.
¿Atlas es mejor que vLLM para producción?
Depende del caso. Atlas gana en throughput puro en Blackwell. vLLM tiene más tiempo en producción, mejor documentación, soporte para más GPUs, y batching continuo maduro para escenarios multi-usuario. Si tu prioridad es velocidad bruta en hardware moderno, Atlas. Si necesitás estabilidad probada con soporte amplio de GPU, vLLM.
¿Qué diferencia a Qwen3.6 de versiones anteriores?
Qwen3.6 tiene ventana de contexto de 1 millón de tokens (vs 128K en el 3.5), arquitectura híbrida de atención lineal con MoE dispersa, y mejora en SWE-bench de ~70% a 78,8%. El output ratio de razonamiento sube de 9% a 17%, lo que se traduce en respuestas más densas por token. La mejora de velocidad reportada es de 3x respecto al 3.5.
¿Cómo implemento Atlas en mi servidor?
El proceso básico parte del repositorio en GitHub de Avarok Cybersecurity: levantás el contenedor Docker con la imagen oficial, configurás el modelo (Qwen3.6-35B-FP8 o el que uses), activás MTP speculative decoding y exponés el endpoint. Requiere GPU NVIDIA Blackwell; otras arquitecturas no están soportadas todavía.
Conclusión
Atlas abre una posibilidad concreta: ejecutar un modelo de 35B a velocidad de producción, con datos que no salen de tu infraestructura, en hardware que ya existe. El hecho de que sea open source significa que el ecosistema puede construir encima, reportar problemas y contribuir mejoras sin depender del roadmap de una empresa.
El límite real es el hardware: Blackwell no es accesible para todos, y el soporte para GPUs anteriores todavía no llegó. Pero si tenés el hardware o estás planeando infraestructura nueva, Atlas con Qwen3.6 es una combinación que vale evaluar antes de comprometerte con una API cloud para siempre.