SubQ AI explicado: quão bom é o LLM com janela de contexto de 12M?

Em 5 de maio de 2026, uma startup pequena de Miami chamada Subquadratic lançou um modelo chamado SubQ. A equipe é enxuta, mas já levantou US$ 29 milhões em rodada seed e afirma que o modelo consegue processar até 12 milhões de tokens em uma única passada.

Eles também fizeram outras afirmações que chamam atenção, como o modelo ser até 52 vezes mais eficiente que o FlashAttention com 1M de tokens e alcançar desempenho em codificação semelhante ao Claude Opus por cerca de 1/20 do custo.

São declarações grandes, então faz sentido destrinchar e ver o que realmente está acontecendo. Neste artigo, vou explicar o que é o SubQ, como a arquitetura funciona e o que os primeiros detalhes e comentários da comunidade de desenvolvedores sugerem sobre essas promessas.

O que é o SubQ?

SubQ é o LLM da Subquadratic, lançado em 5 de maio de 2026 e construído em torno de um único grande destaque: uma janela de contexto de 12 milhões de tokens. É o primeiro modelo entregue pela empresa e chega com uma série de afirmações ousadas sobre eficiência e custo que já geraram bastante debate. 

O modelo ainda não está disponível publicamente. O acesso à API, ao SubQ Code e ao SubQ Search está limitado a early access por lista de espera.

Ele é baseado em algo chamado SSA, sigla para Subquadratic Sparse Attention.

Em vez de comparar cada token com todos os outros, como acontece na atenção densa padrão, a SSA adota uma abordagem seletiva. Para cada token, o modelo escolhe os tokens mais relevantes e calcula as relações apenas dentro desse subconjunto.

Isso tem dois efeitos claros.

• Primeiro, reduz o número de cálculos, o que melhora diretamente a eficiência e diminui o custo. 
• Segundo, a seleção depende do conteúdo. Ou seja, o modelo não olha apenas para tokens próximos. Ele pode puxar tokens relevantes de qualquer lugar da sequência, mesmo que estejam distantes.

O que há de especial no SubQ?

Na prática, a arquitetura SSA faz o modelo focar no que realmente importa, em vez de processar tudo de forma igual. A proposta é manter acurácia parecida com a da atenção completa, mas com demandas significativamente menores de computação e memória.

Vamos olhar mais de perto a atenção densa e depois comparar as duas abordagens.

O problema do escalonamento quadrático nos transformers

Modelos atuais como GPT, Claude e Gemini dependem de atenção densa. Em linhas gerais, isso significa que cada token é comparado com todos os outros tokens da entrada. À medida que a entrada cresce, o número de comparações cresce de forma quadrática.

Pegue um documento longo e imagine que o modelo precisa gerar a última palavra. Ele olha para cada token daquele documento, constrói relações e decide o que vem depois. É por isso que a atenção densa funciona bem: ela considera tudo.

Mas essa força tem um custo. Conforme o tamanho da entrada aumenta, os requisitos de computação e memória sobem rapidamente e criam limites de janela de contexto. Em termos simples, o custo escala como O(n²), onde n é o número de tokens.

É por isso que a maioria dos modelos fica dentro de limites práticos. Em modelos padrão, 128k tokens é o comum, e os modelos mais poderosos, como o Claude Opus, chegam no máximo a 1M de janela de contexto.

Para contornar isso, a maior parte dos sistemas com IA evita enviar conjuntos de dados completos para o modelo. Em vez disso, usa técnicas como:

• RAG (Retrieval-Augmented Generation): Armazene dados externamente, busque apenas os trechos relevantes e passe-os para o modelo.
• Chunking: Quebre textos grandes em partes menores e envie apenas os pedaços relevantes para o modelo.
• Estratégias de sumarização: Condense conteúdos longos e alimente o modelo com resumos, em vez do texto completo.

Se você quer entender melhor os mecanismos de atenção, confira este tutorial sobre o mecanismo de atenção em LLMs. Para uma vivência prática nos blocos de construção dos LLMs modernos, recomendo nosso curso Transformer Models with PyTorch.

Como o SubQ se posiciona de forma diferente

A atenção densa cresce de forma quadrática com o tamanho da entrada, enquanto a SSA foi desenhada para escalar de forma subquadrática, mais próxima de O(n·k) em vez de O(n²), onde k é o número de tokens selecionados por etapa. Quando k é mantido pequeno em relação a n, isso é muito mais eficiente do que a atenção completa.

Diagrama de atenção quadrática vs. linear mostrando conexões densas de todos-para-todos versus conexões esparsas e seletivas.

A preocupação óbvia aqui é a acurácia. Se o modelo olha apenas para parte da entrada, pode perder relações importantes. Esse trade-off geralmente é o motivo de a atenção densa existir.

A alegação do SubQ é que esse trade-off não aparece na prática. Eles dizem que o modelo presta atenção a todos os tokens necessários, mesmo que estejam longe do token atual, e mantém acurácia semelhante à dos modelos de ponta.

Como funciona a Subquadratic Sparse Attention?

Até aqui, sabemos que, em vez de comparar cada token com todos os outros, a SSA seleciona apenas os tokens que importam na sequência e calcula a atenção nessas posições. Vamos ver como essa seleção é feita.

Como a SSA seleciona relações relevantes

A SSA usa roteamento dependente de conteúdo. Em termos simples, ela escolhe tokens com base na relevância para o token atual. Calcula uma pontuação de similaridade entre tokens, algo como similarity(query_i, key_j), e mantém apenas os k tokens com as maiores pontuações para a atenção.

Com o tempo, o modelo aprende a priorizar tokens significativos e ignorar ruído. Isso inclui palavras-chave, entidades importantes e tokens com sinais contextuais fortes.

Além de depender do conteúdo, a SSA também preserva relações estruturais na sequência. Por exemplo, tokens próximos sempre recebem atenção por meio de padrões de atenção local, enquanto certos tokens globais são projetados para atender toda a sequência.

A SSA também incorpora técnicas de atenção hierárquica e baseada em clusters. Por exemplo, ela agrupa tokens semelhantes e calcula a atenção com os clusters mais relevantes. Isso significa que o modelo não precisa avaliar cada token individualmente; ele pode raciocinar primeiro no nível de grupos e, se necessário, dar zoom nos tokens dentro desses clusters.

Treinamento para recuperação em longos contextos

Uma janela de contexto grande sozinha não faz milagre. Mesmo com 12M de tokens, o modelo precisa saber usar esse contexto de forma eficaz. A SSA é treinada com esse objetivo:

• Pré-treinamento: O modelo base é treinado em conjuntos massivos e diversos de dados com representações de longo contexto. 
• Ajuste fino supervisionado: Em seguida, o modelo é treinado em tarefas estruturadas, incluindo raciocínio e geração de código. 
• Reforço por aprendizado: Em vez de limitar o modelo a considerar apenas tokens próximos (atenção local), esta etapa faz com que ele use tokens relevantes do texto inteiro (atenção global).

A etapa de aprendizado por reforço é especialmente importante para casos de uso de codificação em empresas. Ela permite que o modelo considere um contexto mais amplo de uma vez, no caso, toda a base de código, enquanto gera a saída.

Benchmarks e desempenho do SubQ

Note que "SubQ 1M-Preview" se refere à versão avaliada em 1M de tokens. A janela completa de 12M está acessível via API.

Nos três benchmarks que a Subquadratic decidiu divulgar, o SubQ 1M-Preview bate de frente com Claude Opus 4.7, GPT-5.5 e Gemini 3.1 Pro. 

Mas a seleção de benchmarks é estreita: exatamente três testes, todos focados em recuperação de longo contexto e codificação, as duas coisas para as quais o SubQ foi explicitamente projetado. Avaliações mais amplas em raciocínio geral, matemática, desempenho multilíngue e segurança não foram publicadas.

O model card completo está como "em breve" no site, então podemos esperar mais benchmarks para casos de uso gerais.

Por enquanto, aqui estão os resultados em recuperação de longo contexto e casos de uso de código:

O que os números mostram

RULER 128K: SubQ marca 95% contra os 94,8% do Opus 4.7. Embora a diferença de acurácia seja mínima, o que realmente importa aqui é o custo: a Subquadratic afirma que rodar essa avaliação no SubQ custou cerca de US$ 8, contra aproximadamente US$ 2.600 no Opus no mesmo comprimento de contexto.

MRCR v2 (8-needle, 1M): Este benchmark testa se o modelo recupera e acompanha corretamente 8 fatos distintos dispersos em um contexto de 1M de tokens. O SubQ mostra um resultado de pesquisa de 83%, mas a pontuação em produção cai para 65,9%. Essa diferença de ~17 pontos entre laboratório e ambiente real chama atenção e não está totalmente explicada. Ainda assim, ele se mantém competitivo com o GPT-5.5 (74,0%) e bem à frente do Claude Opus 4.7 (32,2%) e do Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ marca 81,8%, à frente do Opus 4.6 com 80,8%, mas atrás do Opus 4.7 com 87,6%. As margens contra o Opus 4.6 são pequenas e sensíveis à configuração do harness. Em relação ao Opus 4.7 e ao GPT-5.5, o SubQ fica claramente atrás.

Com 12 milhões de tokens: Foi reportado que o SubQ supera 90% em tarefas de needle-in-a-haystack com contexto de 12M, embora esse número não tenha sido verificado em benchmarks oficiais. Nenhum outro modelo de fronteira foi testado nesse comprimento, então não há comparação direta. É o resultado mais interessante, do ponto de vista arquitetural, do lançamento — e também o que mais precisa de reprodução independente antes de conclusões.

O que o SubQ significa para RAG, agentes de código e custos de IA

Se a arquitetura do SubQ se sustentar em escala, ela muda como sistemas com LLM são construídos. Contextos mais longos se tornam práticos, reduzindo a necessidade de chunking agressivo, recuperação e otimização de tokens. Vamos detalhar essas mudanças.

Quando o RAG vira opcional

Nos últimos dois anos, o Retrieval-Augmented Generation (RAG) tem sido a resposta padrão para uma limitação fundamental dos LLMs: os modelos não conseguem ler tudo de uma vez. Se sua base de conhecimento é maior que a janela de contexto, você fatia documentos, gera embeddings, armazena em um banco vetorial, recupera os trechos mais relevantes e passa só esses fragmentos para o modelo junto com o prompt.

Todo esse ecossistema existe porque contexto é um recurso escasso.

Quando um modelo consegue processar milhões de tokens de forma confiável em uma única passada, muitas camadas de engenharia construídas em torno de recuperação se tornam menos necessárias para certos fluxos. Em vez de gastar tempo decidindo quais pedaços recuperar, o sistema pode ingerir o material bruto diretamente e raciocinar de ponta a ponta.

Ainda assim, além da janela de contexto, o RAG continua importante para capacidades como:

• Memória entre sessões: LLMs não lembram nada após o fim da sessão. Se o usuário volta depois, o modelo recomeça do zero. Sistemas de recuperação (ou bancos de dados) armazenam informações importantes, como decisões passadas, documentos ou dados do usuário, para que o modelo possa lembrar e usar em interações futuras.
• Permissões e controle de acesso: Sistemas de recuperação podem impor regras como "este usuário só pode acessar dados do seu time". Assim, o modelo só recebe documentos que o usuário tem permissão para ver, evitando vazamentos acidentais.
• Auditabilidade: Em ambientes corporativos, não basta dar a resposta; é preciso mostrar por que ela está correta. Sistemas de recuperação podem apontar os documentos ou fontes exatas usadas, para que as equipes verifiquem resultados e depurem problemas se algo der errado.
• Gestão estruturada do conhecimento: Empresas adicionam, atualizam e removem documentos constantemente. Sistemas de recuperação usam embeddings e indexação para organizar esses dados, permitindo que o modelo encontre rapidamente as informações mais recentes e relevantes, sem reprocessar tudo sempre.

Para uma abordagem nova e interessante de adicionar memória persistente a agentes de IA, leia nosso Supermemory Tutorial, no qual você aprende a construir um treinador de exercícios com memória de curto e longo prazo.

Fluxos de trabalho de código com longo contexto

Hoje, a maioria dos modelos para código não enxerga a base de código inteira. Então adicionamos camadas por cima — busca de arquivos, chunking, ranqueamento e planejamento em múltiplas etapas — só para manter o contexto certo na janela e construir relações entre arquivos.

Mas, com o contexto de 12M do SubQ, toda a base de código é carregada no modelo de uma vez. Isso simplifica o design de agentes de forma significativa.

• Planejamento fica global: O modelo pode raciocinar sobre arquitetura, dependências e interações entre arquivos sem perder contexto.
• Execução mais coesa: Mudanças em múltiplos arquivos podem ser coordenadas em uma única passada, em vez de atualizações incrementais.
• Revisão mais confiável: O modelo pode verificar suas próprias mudanças contra toda a base de código, reduzindo inconsistências.

Economia de custos

Em transformers padrão, a atenção escala de forma quadrática com o tamanho da sequência. Se você dobra o contexto, o custo não só dobra; ele pode ficar quatro vezes mais caro.

O SubQ afirma quebrar esse trade-off.

• Relata ~1/20 do custo de modelos de fronteira comparáveis (Claude Opus)
• E até ~1.000× de redução em compute com contexto de 12M tokens

Se isso se confirmar em produção, o processamento de longos contextos deixa de ser um caso caro e vira algo que você pode usar de forma mais rotineira.

No entanto, além de uma janela de contexto barata, o modelo precisa conseguir usar com eficiência as informações carregadas nesse contexto. Pelos benchmarks, o SubQ alega acurácia comparável por um custo bem menor, mas ainda é cedo para um veredito final.

Como posso acessar o SubQ?

O SubQ ainda não está disponível publicamente. Os três produtos — a API principal, o SubQ Code e o SubQ Search — estão em beta privado, e o acesso requer uma solicitação de early access pelo site do SubQ.

Do ponto de vista do desenvolvedor, a API foi pensada para ser fácil de integrar. Ela oferece suporte a:

• respostas em streaming
• chamada de ferramentas/funções
• endpoints compatíveis com OpenAI

Isso significa que, se sua stack já funciona com APIs no estilo OpenAI, normalmente você não precisa reescrever a integração.

O SubQ Code é posicionado como um agente de codificação via linha de comando, enquanto o SubQ Search foca em busca com longo contexto para fluxos de pesquisa mais profundos. Pense neles como as versões SubQ do Claude Code e do Perplexity. 

A precificação de qualquer uma dessas ferramentas também ainda não é transparente. Não há taxas públicas por token, o que dificulta validar de forma independente as alegações de custo da empresa.

Ceticismo e questões em aberto

Poucas horas após o lançamento, já havia muito ceticismo e reações mistas nas redes e fóruns como o Hacker News. A discussão se dividiu: alguns veem um avanço real, enquanto outros comparam a um "Theranos da IA" (referência à startup de exames de sangue que faliu após alegações fraudulentas de tecnologia).

A maioria das dúvidas se concentra em: 

• Eles afirmam janela de contexto de 12M, mas os benchmarks divulgados são todos em 1M.
• Deram à empresa o nome Subquadratic, mas em alguns lugares mencionam escalonamento parecido com O(1). Com O(1), você esperaria bem mais que 12M de tokens de contexto. Mesmo O(log n) permitiria limites maiores.

Uma narrativa parecida apareceu com a Magic.dev em 2024. Eles fizeram afirmações fortes sobre janelas de contexto extremamente grandes, até 100M de tokens, e grandes ganhos de eficiência, especialmente para fluxos de codificação. 

O pitch era quase idêntico: carregar bases de código inteiras, reduzir a complexidade de recuperação e simplificar o design de agentes. Mas o resultado, ao menos publicamente, foi mais contido. Mesmo após levantar cerca de US$ 500 milhões, ainda há pouca visibilidade ou adoção no mundo real no começo de 2026.

O que foi verificado

As alegações do SubQ não são puramente teóricas. A Subquadratic relata que os benchmarks no RULER, MRCR v2 e SWE-Bench Verified foram executados por um serviço de testes terceirizado, mostrando desempenho forte em recuperação de longo contexto e resultados competitivos em tarefas de código. 

No entanto, esses resultados ainda não foram reproduzidos de forma independente por pesquisadores externos, e o escopo da avaliação é estreito. Os três benchmarks enfatizam exatamente as áreas para as quais o SubQ foi construído (recuperar sinais de um contexto grande e operar sobre código).

Outro detalhe importante é a arquitetura. O CTO confirmou que o SubQ não treina modelos do zero, mas constrói sobre modelos open source (provavelmente de famílias como DeepSeek ou Kimi). Isso é prático para uma equipe pequena: acelera a iteração e reduz o custo de treino. Isso também significa que a inovação central não é o modelo base em si, mas o mecanismo de atenção e o design do sistema ao redor.

Considerações finais

O SubQ chegou, e as promessas são bem ousadas. A direção é clara: remover o limite da janela de contexto e deixar os modelos lidarem com entradas muito maiores. Eles estão posicionando o SubQ como capaz de igualar ou superar modelos de fronteira em codificação e recuperação de longo contexto, com um custo muito menor.

Dito isso, ainda é cedo. Ainda aguardamos o model card completo para ter mais visibilidade sobre capacidades e testes mais amplos. Os produtos construídos sobre ele, o SubQ Code e a API, também não estão disponíveis publicamente. Estou animado para colocar as mãos nessas ferramentas e ver como as promessas se sustentam em produção.