SubQ AI explicado: ¿qué tal es el LLM con ventana de contexto de 12M?

El 5 de mayo de 2026, una pequeña startup de Miami llamada Subquadratic presentó un modelo llamado SubQ. El equipo es reducido, pero han levantado 29 millones de dólares en financiación semilla y afirman que el modelo puede procesar hasta 12 millones de tokens en una sola pasada.

También han hecho otras afirmaciones que suenan a ciencia ficción, como que su modelo es hasta 52 veces más eficiente que FlashAttention a 1M de tokens y que logra un rendimiento en programación similar a Claude Opus por aproximadamente 1/20 del coste.

Son declaraciones contundentes, así que conviene desgranarlas para entender qué hay realmente detrás. En este artículo, te cuento qué es SubQ, cómo funciona su arquitectura y qué sugieren los primeros detalles y la comunidad de desarrolladores sobre estas promesas.

¿Qué es SubQ?

SubQ es el LLM de Subquadratic, lanzado el 5 de mayo de 2026 y construido en torno a una característica estrella: una ventana de contexto de 12 millones de tokens. Es el primer modelo que la compañía envía al mercado y llega con promesas ambiciosas sobre eficiencia y coste que ya han generado un intenso debate. 

De momento no está disponible públicamente: el acceso a la API, SubQ Code y SubQ Search está limitado a una lista de espera de acceso anticipado.

Se basa en algo llamado SSA, siglas de Subquadratic Sparse Attention.

En lugar de comparar cada token con todos los demás, como hace la atención densa estándar, SSA adopta un enfoque selectivo. Para cada token, el modelo elige los tokens más relevantes y calcula las relaciones solo dentro de ese subconjunto.

Esto tiene dos efectos claros.

• Primero, reduce el número de cómputos, lo que mejora directamente la eficiencia y baja el coste. 
• Segundo, la selección depende del contenido. Es decir, el modelo no se limita a mirar tokens cercanos: puede traer tokens relevantes desde cualquier punto de la secuencia, aunque estén muy alejados.

¿Qué tiene de especial SubQ?

En la práctica, la arquitectura SSA hace que el modelo se centre en lo que de verdad importa, en lugar de procesarlo todo por igual. El objetivo es lograr una precisión similar a la de la atención completa, pero con requisitos de cómputo y memoria mucho menores.

Primero veamos la atención densa con más detalle y luego comparamos ambos enfoques.

El problema del escalado cuadrático en los transformers

Modelos actuales como GPT, Claude y Gemini se basan en atención densa. A grandes rasgos, esto significa que cada token se compara con todos los demás del input. A medida que crece la entrada, el número de comparaciones crece de forma cuadrática.

Imagina un documento largo en el que el modelo debe generar la última palabra. Retrocede y mira cada token, construye relaciones y decide qué viene después. Por eso la atención densa funciona bien: lo tiene todo en cuenta.

Pero esa fortaleza tiene un coste. Al aumentar el tamaño de la entrada, los requisitos de cómputo y memoria se disparan y crean límites en la ventana de contexto. En términos simples, escala como O(n²), donde n es el número de tokens.

Por eso la mayoría de modelos se quedan en límites prácticos. En modelos estándar, 128k tokens es lo habitual, y los más potentes como Claude Opus alcanzan como máximo 1M de ventana de contexto.

Para sortear esto, muchos sistemas con IA evitan pasar datasets completos al modelo. En su lugar, recurren a técnicas como:

• RAG (Retrieval-Augmented Generation): Almacenar datos externamente, recuperar solo los fragmentos relevantes y pasarlos al modelo.
• Segmentación en chunks: Dividir el texto grande en piezas más pequeñas y enviar solo las relevantes al modelo.
• Estrategias de resumen: Comprimir contenido largo y alimentar al modelo con resúmenes en lugar del texto completo.

Si quieres profundizar en los mecanismos de atención, puedes ver este tutorial sobre el mecanismo de atención en LLMs. Para practicar con los bloques básicos de los LLM modernos, te recomendamos el curso Transformer Models with PyTorch.

Cómo se posiciona SubQ de forma diferente

La atención densa crece de forma cuadrática con el tamaño de entrada, mientras que SSA está diseñada para escalar de forma subcuadrática, más cerca de O(n·k) en lugar de O(n²), donde k es el número de tokens seleccionados por paso. Si k se mantiene pequeño respecto a n, esto es mucho más eficiente que la atención completa.

Diagrama de atención cuadrática frente a lineal con conexiones densas de todo a todo frente a conexiones selectivas dispersas.

La preocupación evidente aquí es la precisión. Si el modelo solo mira una parte de la entrada, puede perder relaciones importantes. Ese compromiso suele ser la razón de ser de la atención densa.

SubQ afirma que ese compromiso no se produce en la práctica. Dicen que el modelo atiende a todos los tokens necesarios, aunque estén lejos del token actual, y mantiene una precisión similar a la de los mejores modelos.

¿Cómo funciona Subquadratic Sparse Attention?

A estas alturas sabemos que, en lugar de comparar cada token con todos los demás, SSA selecciona solo los tokens que importan en la secuencia y calcula la atención sobre esas posiciones. Veamos cómo hace esa selección.

Cómo selecciona SSA las relaciones relevantes

SSA utiliza enrutamiento dependiente del contenido. En términos simples, elige tokens en función de lo relevantes que sean para el token actual. Calcula una puntuación de similitud entre tokens, algo como similarity(query_i, key_j), y mantiene solo los k tokens con mayor puntuación para la atención.

Con el tiempo, el modelo aprende a priorizar tokens significativos e ignorar el ruido. Esto incluye palabras clave, entidades importantes y tokens con señales contextuales fuertes.

Además de depender del contenido, SSA también preserva relaciones estructurales en la secuencia. Por ejemplo, a los tokens cercanos siempre se les presta atención mediante patrones locales, mientras que ciertos tokens globales están diseñados para atender a toda la secuencia.

SSA también incorpora técnicas de atención jerárquica y basada en clustering. Por ejemplo, agrupa tokens similares y calcula la atención con los clusters más relevantes. Así, el modelo no necesita evaluar cada token por separado: puede razonar primero a nivel de grupos y, si hace falta, acercarse a los tokens dentro de esos clusters.

Entrenamiento para recuperación en contextos largos

Una ventana de contexto grande por sí sola no hace magia. Aunque le des 12M tokens, el modelo tiene que saber usar ese contexto con eficacia. SSA se entrena con ese propósito:

• Preentrenamiento: El modelo base se entrena con datasets masivos y diversos con representaciones de largo contexto. 
• Ajuste fino supervisado: Después se entrena en tareas estructuradas, como razonamiento y generación de código. 
• Aprendizaje por refuerzo: En lugar de limitar al modelo a tokens cercanos (atención local), este paso busca que use tokens relevantes de todo el texto (atención global).

La fase de aprendizaje por refuerzo es especialmente importante para casos de uso de programación en empresas. Permite que el modelo tenga en cuenta un contexto más amplio a la vez, en este caso, toda la base de código mientras genera la salida.

Benchmarks y rendimiento de SubQ

Ten en cuenta que "SubQ 1M-Preview" se refiere a la versión evaluada a 1M de tokens. La ventana completa de 12M es accesible vía API.

En los tres benchmarks que Subquadratic decidió publicar, SubQ 1M-Preview compite de tú a tú con Claude Opus 4.7, GPT-5.5 y Gemini 3.1 Pro. 

Pero la selección de benchmarks es limitada: exactamente tres pruebas, todas centradas en recuperación de contexto largo y programación, justo las dos cosas para las que SubQ está diseñado. Aún no se han publicado evaluaciones más amplias sobre razonamiento general, matemáticas, multilingüe y seguridad.

La ficha completa del modelo aparece como "próximamente" en la web, así que podemos esperar más benchmarks en casos de uso generales.

Por ahora, estos son los resultados en recuperación de contexto largo y casos de uso de programación:

Qué muestran los números

RULER 128K: SubQ obtiene un 95% frente al 94,8% de Opus 4.7. Aunque la diferencia de precisión es mínima, aquí lo relevante es el coste: Subquadratic afirma que ejecutar esta evaluación en SubQ costó unos 8 dólares, frente a aproximadamente 2.600 en Opus al mismo tamaño de contexto.

MRCR v2 (8-needle, 1M): Este benchmark prueba si el modelo recupera y sigue correctamente 8 hechos distintos incrustados en un contexto de 1M de tokens. SubQ muestra un resultado de investigación del 83%, pero la puntuación en producción cae al 65,9%. Esta brecha de ~17 puntos entre laboratorio y despliegue es notable y no está completamente explicada. Aun así, se mantiene competitivo con GPT-5.5 (74,0%) y muy por delante de Claude Opus 4.7 (32,2%) y de Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ logra un 81,8%, por delante de Opus 4.6 con 80,8% pero por detrás de Opus 4.7 con 87,6%. Los márgenes frente a Opus 4.6 son pequeños y sensibles a la configuración del framework de pruebas. Frente a Opus 4.7 y GPT-5.5, SubQ queda claramente por detrás.

A 12 millones de tokens: Se ha informado de que SubQ supera el 90% en tareas de "needle-in-a-haystack" a 12M de contexto, aunque esta cifra no se ha verificado en benchmarks oficiales. Ningún otro modelo de vanguardia se ha probado a esta longitud, así que no hay comparación directa. Es el resultado más interesante desde el punto de vista arquitectónico del lanzamiento y también el que necesita reproducción independiente antes de sacar conclusiones.

Qué implica SubQ para RAG, agentes de código y costes de IA

Si la arquitectura de SubQ se mantiene a escala, cambia cómo se construyen los sistemas con LLM. Los contextos largos se vuelven prácticos, reduciendo la necesidad de segmentar agresivamente, recuperar y optimizar tokens. Veamos estos cambios en detalle.

Cuando RAG pasa a ser opcional

Durante los últimos dos años, Retrieval-Augmented Generation (RAG) ha sido la respuesta por defecto a una limitación fundamental de los LLM: los modelos no pueden leerlo todo de una vez. Si tu base de conocimiento es mayor que la ventana de contexto, fragmentas documentos, los conviertes en embeddings, los guardas en una base vectorial, recuperas las piezas más relevantes y pasas solo esos fragmentos al modelo junto con el prompt.

Todo ese ecosistema existe porque el contexto es un recurso escaso.

Cuando un modelo puede procesar de forma fiable millones de tokens en una sola pasada, muchas de las capas de ingeniería alrededor de la recuperación dejan de ser necesarias para ciertos flujos. En lugar de decidir qué fragmentos recuperar, el sistema puede ingerir el material en bruto y razonar de extremo a extremo.

Aun así, más allá de la ventana de contexto, RAG sigue siendo clave para estas capacidades:

• Memoria entre sesiones: Los LLM no recuerdan nada cuando termina una sesión. Si el usuario vuelve más tarde, el modelo empieza de cero. Los sistemas de recuperación (o bases de datos) almacenan información importante como decisiones pasadas, documentos o datos de usuario para que el modelo pueda recordarla y usarla en futuras interacciones.
• Permisos y control de acceso: Los sistemas de recuperación pueden imponer reglas como "esta persona solo accede a datos de su equipo". Así, el modelo solo recibe documentos que el usuario puede ver, evitando fugas accidentales.
• Auditabilidad: En entornos empresariales no basta con dar una respuesta: hay que justificarla. Los sistemas de recuperación pueden señalar los documentos o fuentes exactos usados, para que los equipos verifiquen resultados y depuren problemas si algo falla.
• Gestión estructurada del conocimiento: Las empresas añaden, actualizan y eliminan documentos constantemente. Los sistemas de recuperación usan embeddings e indexación para organizar estos datos y que el modelo encuentre rápido la información más reciente y relevante, sin reprocesarlo todo cada vez.

Para un enfoque interesante de cómo dar memoria persistente a los agentes de IA, lee nuestro tutorial de Supermemory, en el que aprenderás a crear un entrenador personal con memoria a corto y largo plazo.

Flujos de trabajo de programación con contexto largo

Ahora mismo, la mayoría de modelos de código no ven toda la base de código. Por eso añadimos capas encima: búsqueda de archivos, segmentación, ranking y planificación multietapa, solo para mantener el contexto adecuado en la ventana y construir relaciones entre archivos.

Con el contexto de 12M de SubQ, se carga toda la base de código en el modelo a la vez. Esto simplifica de verdad el diseño de agentes.

• La planificación pasa a ser global: El modelo puede razonar sobre arquitectura, dependencias e interacciones entre archivos sin perder contexto.
• La ejecución es más coherente: Los cambios en múltiples archivos se coordinan en una sola pasada, en lugar de mediante actualizaciones incrementales.
• La revisión es más fiable: El modelo puede verificar sus propios cambios frente a toda la base de código, reduciendo inconsistencias.

Economía de costes

En los transformers estándar, la atención escala de forma cuadrática con la longitud de la secuencia. Si duplicas el contexto, el coste no solo se duplica; puede cuadruplicarse.

SubQ afirma romper ese trade-off.

• Informa de ~1/20 del coste frente a modelos de vanguardia comparables (Claude Opus)
• Y hasta ~1.000× de reducción de cómputo con 12M de tokens de contexto

Si esto se confirma en producción, el procesamiento de contextos largos deja de ser un caso caro y marginal para convertirse en algo que puedes usar con más frecuencia.

Eso sí, además de una ventana de contexto barata, el modelo debe ser capaz de usar con eficiencia la información que cargamos en su contexto. Según los benchmarks, SubQ promete precisión comparable a un coste mucho menor, pero aún es pronto para sentenciar.

¿Cómo puedo acceder a SubQ?

SubQ aún no está disponible públicamente. Los tres productos —la API principal, SubQ Code y SubQ Search— están en beta privada, y el acceso requiere solicitarlo en la web de SubQ.

Desde la perspectiva de desarrollo, la API está diseñada para integrarse con facilidad. Admite:

• respuestas en streaming
• tool/function calling
• endpoints compatibles con OpenAI

Esto significa que, si tu stack ya funciona con APIs al estilo OpenAI, normalmente no tendrás que reescribir tu integración.

SubQ Code se presenta como un agente de programación en la línea de comandos, mientras que SubQ Search se centra en búsqueda con contexto largo para flujos de investigación más profundos. Piensa en ellos como las versiones SubQ de Claude Code y Perplexity. 

La fijación de precios de estas herramientas tampoco es transparente por ahora. No hay tarifas públicas por token, lo que complica validar de forma independiente las afirmaciones de costes de la compañía.

Escepticismo y preguntas abiertas

A las pocas horas del lanzamiento, ya había bastante escepticismo y reacciones mixtas en redes sociales y foros como Hacker News. La discusión está dividida: algunos lo ven como un avance real y otros lo comparan con un "Theranos de la IA" (en referencia a la fallida startup de análisis de sangre que hizo afirmaciones tecnológicas fraudulentas).

Las principales dudas se centran en: 

• Afirman una ventana de contexto de 12M, pero los benchmarks compartidos son todos a 1M.
• Llamaron a la empresa Subquadratic, pero en algunos sitios mencionan un escalado tipo O(1). Con O(1), cabría esperar mucho más que 12M de tokens de contexto. Incluso con O(log n) permitiría límites mayores.

Un relato similar apareció con Magic.dev en 2024. Hicieron afirmaciones contundentes sobre ventanas de contexto enormes, hasta 100M de tokens, y grandes ganancias de eficiencia, especialmente para flujos de programación. 

El planteamiento era casi idéntico: cargar bases de código completas, reducir la complejidad de recuperación y simplificar el diseño de agentes. Pero el resultado, al menos públicamente, ha sido más discreto. Pese a recaudar unos 500M de dólares, a principios de 2026 sigue habiendo poca visibilidad o adopción real.

Qué se ha verificado

Las afirmaciones de SubQ no son puramente teóricas. Subquadratic indica que los benchmarks en RULER, MRCR v2 y SWE-Bench Verified se ejecutaron con un servicio de pruebas externo, mostrando un rendimiento sólido en recuperación de contexto largo y resultados competitivos en tareas de código. 

Sin embargo, estos resultados aún no han sido reproducidos de forma independiente por investigadores externos, y el alcance de la evaluación es estrecho. Los tres benchmarks enfatizan justo las áreas para las que SubQ está construido (recuperar señales desde contextos muy largos y operar sobre código).

Otro detalle importante es la arquitectura. El CTO ha confirmado que SubQ no entrena modelos desde cero, sino que se apoya en modelos base open source (probablemente de familias como DeepSeek o Kimi). Es una elección práctica para un equipo pequeño: acelera la iteración y reduce el coste de entrenamiento. Eso también significa que la innovación principal no es el modelo base en sí, sino el mecanismo de atención y el diseño del sistema que lo rodea.

Reflexiones finales

SubQ ya está aquí y las promesas son bastante audaces. La dirección es clara: eliminar la barrera de la ventana de contexto y permitir que los modelos manejen entradas mucho más grandes. Lo posicionan como un rival que iguala o supera a los modelos de vanguardia en programación y recuperación de contexto largo, a un coste mucho menor.

Dicho esto, aún es pronto. Falta ver la ficha completa del modelo para entender mejor sus capacidades y pruebas más amplias. Los productos construidos encima, SubQ Code y la API, tampoco están disponibles públicamente. Tengo ganas de probar estas herramientas y ver cómo aguantan las promesas en producción.