Modelos de Espaço de Estados vs Transformers: Guia Prático

Os transformers não vão ser a única opção no mercado por muito mais tempo. Sei que parece uma afirmação ousada, já que vemos a arquitetura transformer dominar tudo, de modelos de linguagem ao dobramento de proteínas, há anos. Mas depois de passar os últimos meses comparando modelos de espaço de estados com baselines de transformers em cargas de produção, estou convencido de que a mudança é real. Não porque SSMs sejam universalmente melhores. Não são. Mas porque resolvem problemas específicos que transformers simplesmente não conseguem resolver, e a geração mais recente fechou a lacuna de qualidade o suficiente para que ignorá-los hoje seja uma decisão de dívida técnica.

Isto não é um texto de hype. Vou explicar o que são modelos de espaço de estados, onde o Mamba-3 realmente melhora as coisas, onde os SSMs ainda deixam a desejar e como sua equipe deve pensar na adoção. De praticante para praticante.

Por que os Transformers batem em um muro em escala

Você já conhece a história da escalabilidade quadrática. A auto-atenção calcula uma matriz N×N para uma sequência de tamanho N, então dobrar o tamanho do contexto quadruplica o custo de computação e de memória. Por muito tempo, isso não importou muito. Os modelos rodavam com alguns milhares de tokens, e o hardware acompanhava.

Essa era acabou. As cargas de trabalho que estamos construindo hoje exigem rotineiramente contextos de 100 mil+ tokens. Assistentes de código precisam enxergar repositórios inteiros. Pipelines multimodais processam horas de vídeo. Agentes mantêm históricos de conversa que se estendem por dias. Nessas escalas, a atenção quadrática não é apenas cara: é um muro.

O problema do KV cache piora tudo. Durante a geração autorregressiva, cada camada do transformer armazena pares chave-valor para cada token que já viu. Esse cache cresce linearmente por camada e consome memória da GPU rapidamente. Já vi um transformer de 7B consumir 40 GB de VRAM só com KV cache em um contexto de 128K. É memória que você não pode usar para processar mais requisições em lote.

A escalabilidade quadrática de memória torna contextos de um milhão de tokens quase impossíveis com atenção padrão
O crescimento do KV cache limita o número de usuários simultâneos por GPU, um multiplicador direto de custo em produção
O consumo de energia da inferência com contexto longo em transformers está ficando difícil de justificar
Aplicações em tempo real (robótica, IA na borda) precisam de geração de tokens em sub-milissegundos, algo que a atenção não consegue entregar
O fenômeno do 'attention sink' degrada a qualidade em sequências muito longas, mesmo quando há memória sobrando

Essas não são preocupações teóricas. Foi por isso que três equipes diferentes com as quais trabalhei começaram a avaliar alternativas seriamente no ano passado.

Como os modelos de espaço de estados realmente funcionam

Modelos de espaço de estados vêm da teoria de controle, onde são usados há décadas para modelar sistemas dinâmicos. A ideia central é simples: em vez de olhar para todos os tokens anteriores para calcular cada saída (como a atenção faz), você mantém um estado oculto compactado que evolui com o tempo. Novos tokens atualizam o estado. O estado produz as saídas. É isso.

Matematicamente, um SSM é definido por quatro matrizes (A, B, C e D) que governam como um estado oculto h evolui em resposta à entrada x. Você discretiza as equações contínuas para dados sequenciais e obtém uma recorrência extremamente simples de calcular na inferência.

import torch
def ssm_step(A_bar, B_bar, C, D, h, x_t):
"""Single SSM step: O(1) memory, O(1) compute.
Compare this to attention, which needs to look at
every previous token. The SSM just updates its state.
"""
h_new = A_bar @ h + B_bar @ x_t  # Update hidden state
y_t = C @ h_new + D * x_t         # Compute output
return h_new, y_t
def ssm_generate(A_bar, B_bar, C, D, tokens, embed):
"""Autoregressive generation with constant memory.
Whether you've processed 100 tokens or 500,000,
this uses the same amount of memory.
"""
h = torch.zeros(A_bar.shape[0])
outputs = []
for t in tokens:
x_t = embed(t)
h, y_t = ssm_step(A_bar, B_bar, C, D, h, x_t)
outputs.append(y_t)
return torch.stack(outputs)

A beleza está justamente no código. A inferência usa memória O(1) e computação O(1) por token, independentemente do tamanho da sequência. Sem KV cache. Sem explosão quadrática. Todo o histórico fica comprimido no vetor de estado oculto.

O porém? Durante o treinamento, executar essa recorrência sequencialmente seria dolorosamente lento. O truque é que a mesma computação pode ser reformulada como uma convolução ou um parallel scan, que GPUs processam com eficiência. Assim você tem treinamento paralelo e inferência recorrente, o melhor dos dois mundos.

Do Mamba ao Mamba-3: o que cada geração corrigiu

SSMs iniciais como o S4 provaram o conceito, mas tinham uma fraqueza crítica: não conseguiam fazer raciocínio baseado em conteúdo direito. As matrizes de transição de estado eram fixas para todas as entradas, então o modelo não podia decidir o que lembrar e o que esquecer com base no que estava de fato lendo. É como tentar tomar notas seguindo a regra 'anote toda terceira palavra': você captura algumas informações úteis, mas não consegue se adaptar ao que importa.

O Mamba, apresentado por Albert Gu e Tri Dao no fim de 2023, resolveu isso com uma ideia elegante: tornar os parâmetros do SSM dependentes da entrada. Em vez de matrizes A, B, C fixas, o Mamba as calcula em função do token atual. O modelo aprende a armazenar seletivamente a informação relevante e descartar o ruído. Esse mecanismo 'seletivo' deu aos SSMs a consciência de conteúdo que lhes faltava.

O Mamba-2 trouxe a percepção teórica de que SSMs estruturados e linear attention são matematicamente duais, o framework State Space Duality (SSD). Isso não ficou só na academia. Permitiu implementações conscientes do hardware que aproveitam melhor os tensor cores das GPUs, aumentando significativamente a vazão de treinamento.

O Mamba-3 é onde as coisas ficam interessantes do ponto de vista de deployment. Três inovações importam mais:

Rastreamento de estado multiescala: o modelo mantém estado em várias resoluções temporais simultaneamente, capturando padrões locais e dependências de longo alcance sem sacrificar nenhum dos dois
Compressão adaptativa de estado: o estado oculto se expande para trechos de raciocínio complexo e se contrai para textos previsíveis, economizando computação sem perder qualidade
Inicialização e gating aprimorados: a estabilidade do treinamento em grande escala melhorou muito, o que importa enormemente quando você está gastando milhões em uma rodada de treinamento

O Mamba-3 não supera transformers em todos os benchmarks. E não precisa. Ele iguala a qualidade na maioria das avaliações padrão usando uma fração do custo computacional de inferência. Para a maioria das cargas de produção, essa é a troca que importa.

Linear attention e a convergência com SSMs

Há uma trilha paralela que vale entender. A linear attention ataca o mesmo problema de eficiência, mas por dentro do framework de transformers. A atenção padrão calcula a matriz N×N completa. A linear attention substitui o softmax por uma função kernel decomponível e reorganiza a matemática para que você nunca precise materializar aquela matriz quadrática.

# Standard attention: O(N^2 * d)
# score = softmax(Q @ K.T / sqrt(d)) @ V
# Linear attention: O(N * d^2)
# Replace softmax with kernel feature map phi()
# Rearrange: compute K^T @ V first (d×d), then multiply by Q
def linear_attention_step(q_t, running_kv, running_k, k_t, v_t, phi):
"""Incremental linear attention — runs like a recurrence.
This is why SSMs and linear attention are duals:
both compress history into a fixed-size state.
"""
k_feat = phi(k_t)
q_feat = phi(q_t)
running_kv = running_kv + k_feat.unsqueeze(-1) * v_t.unsqueeze(-2)
running_k = running_k + k_feat
y_t = (q_feat @ running_kv) / (q_feat @ running_k + 1e-6)
return y_t, running_kv, running_k

Olhe essa formulação com atenção. A linear attention, quando executada incrementalmente, mantém um estado corrente e o atualiza a cada novo token. Familiar? Deveria ser: ela faz essencialmente a mesma coisa que um SSM. O framework SSD formalizou essa conexão, e é uma das percepções teóricas mais importantes da pesquisa recente em modelagem de sequências.

Arquiteturas como GLA (Gated Linear Attention) e variantes do RetNet levaram isso adiante, adicionando gating dependente dos dados que quase apaga a linha entre linear attention e SSMs seletivos. A conclusão prática: não pense nessas abordagens como concorrentes. Elas estão convergindo.

Arquiteturas híbridas: o que está realmente vencendo em produção

Aqui está o que eu digo às equipes que me perguntam se devem migrar para SSMs: não vá de puro nada. As arquiteturas que entregam os melhores resultados hoje são híbridos que misturam camadas SSM com um pequeno número de camadas de atenção. Primitivas computacionais diferentes são boas em coisas diferentes, e fingir o contrário deixa desempenho na mesa.

Camadas SSM são excelentes para comprimir e propagar informação sequencial de forma eficiente. Camadas de atenção ainda são insuperáveis para recuperação precisa baseada em conteúdo: 'encontre a linha exata da página 47 que responde a esta pergunta'. Um híbrido bem projetado usa SSMs em 80-90% das camadas e espalha atenção onde ela mais importa.

Modelos no estilo Jamba: alternam camadas Mamba e de atenção com blocos feed-forward MoE, roteando dinamicamente entre o processamento SSM eficiente e a atenção precisa
Designs da família Griffin: unidades recorrentes com gating combinadas com atenção local de janela deslizante, com ótimos resultados e pouca atenção completa
Híbridos Mamba-Attention: blocos Mamba-3 na maioria das camadas, com camadas de atenção completa inseridas em profundidades estratégicas para roteamento de informação global
Sucessores do StripedHyena: intercalam convoluções com gating, camadas SSM e atenção esparsa em padrões otimizados por NAS

Os números confirmam isso. Vários grupos independentes mostraram que uma divisão de 85/15 entre SSM e atenção iguala a qualidade de um transformer puro com a mesma quantidade de parâmetros, cortando os FLOPs de inferência em 40-60%. A economia de memória é ainda maior em cargas de contexto longo. Não é uma melhoria marginal. É cortar pela metade a sua conta de GPU.

Benchmarks de produção: onde os SSMs entregam e onde não entregam

Vou ser específico com os números, porque afirmações vagas de eficiência não ajudam ninguém que está tomando decisões de deployment.

Vazão de inferência: um modelo baseado em Mamba-3 com 8B de parâmetros gera tokens na mesma velocidade, seja o contexto de 1K ou de 500K tokens. Um transformer equivalente fica progressivamente mais lento conforme o KV cache cresce. Com contexto de 500K, o modelo SSM entrega de 5 a 8 vezes mais vazão por GPU. Isso não é teórico: eu medi.

Usuários simultâneos: sem KV cache, modelos SSM conseguem atender muito mais requisições simultâneas. Em uma única A100, onde um transformer atende talvez 8 streams simultâneos com contexto de 32K, um modelo SSM equivalente consegue atender mais de 30. Para quem roda inferência em escala, esse é o número que muda a economia.

Velocidade de treinamento: os ganhos aqui são mais modestos. O Mamba-3 treina a cerca de 1,4x a vazão de um transformer equivalente em clusters de H100. A diferença aumenta com sequências mais longas: acima de 32K tokens, o treinamento de SSMs roda 2-3x mais rápido, porque evita a atenção quadrática por completo.

Mas preciso ser honesto sobre as limitações. Em tarefas que exigem recuperação literal precisa de contextos longos, como 'qual era a mensagem de erro exata na linha 4.382?', SSMs puros ainda ficam abaixo. O estado comprimido de tamanho fixo é uma representação com perdas. A atenção pode simplesmente voltar aos tokens originais. É exatamente por isso que as arquiteturas híbridas funcionam: as camadas de atenção cuidam da recuperação que os SSMs não conseguem fazer.

Onde os SSMs ainda ficam devendo

Quero ser bem realista sobre as lacunas que restam, porque adotar uma nova arquitetura com informação incompleta é um ótimo jeito de desperdiçar seis meses.

Aprendizado em contexto: transformers ainda são melhores em adaptar seu comportamento com base em exemplos few-shot no prompt. SSMs conseguem fazer isso, mas com menos confiabilidade. Se a sua aplicação depende fortemente de engenharia de prompt com exemplos, SSMs puros vão decepcionar.
Maturidade do ecossistema: o tooling de transformers teve anos de otimização. Kernels específicos para SSM, infraestrutura de serving e bibliotecas de fine-tuning estão melhorando rápido, mas ainda não chegaram ao mesmo nível. Reserve tempo extra para integração.
Incerteza de escala acima de 70B: modelos Mamba-3 de até 70B de parâmetros mostram boas curvas de escala, mas não temos dados sólidos na fronteira de 200B+. Se as leis de escala dos SSMs se sustentam em tamanhos extremos é genuinamente desconhecido.
Técnicas de fine-tuning: LoRA e QLoRA para transformers são bem compreendidas. Aplicá-las a arquiteturas SSM exige abordagens diferentes, e as melhores práticas ainda estão se definindo.
Incompatibilidade de hardware: as GPUs atuais são otimizadas para as multiplicações de matrizes que a atenção adora. SSMs dependem fortemente de parallel scans, que rodam bem o suficiente em hardware moderno, mas não são a operação para a qual as GPUs foram projetadas.

Nenhum desses é um impedimento definitivo. São problemas de engenharia com caminhos de solução conhecidos. Mas são reais e devem entrar no seu cronograma.

Recomendações práticas: quando adotar e como começar

Depois de avaliar SSMs em várias cargas de produção, este é o framework que uso para orientar equipes.

Adote com agressividade se a sua carga envolve inferência com contexto longo (32K+ tokens com frequência), alta exigência de concorrência ou implantação na borda sensível à latência. O ROI é substancial e imediato. Comece com uma arquitetura híbrida como Jamba ou um modelo da família Griffin, em vez de ir para SSM puro: você obtém a maior parte dos ganhos de eficiência com menos risco.

Espere e observe se a sua carga é predominantemente de contexto curto, com forte dependência de aprendizado em contexto, e você não tem pressão de custo de inferência. Os transformers ainda levam vantagem aqui, e o ecossistema é mais maduro.

Faça o profiling da sua carga real de inferência antes de decidir: o tamanho mediano do contexto e o número de usuários simultâneos são as variáveis-chave
Comece com arquiteturas híbridas, não com SSMs puros: elas têm menor risco e ainda entregam redução de custo de inferência de 40-60%
Faça benchmarks nas suas tarefas específicas: SSMs se destacam em sumarização e raciocínio de longo alcance, mas ficam para trás em recuperação exata
Monte agora uma infraestrutura de comparação entre arquiteturas: você precisa medir latência, vazão, memória e custo por consulta, não apenas acurácia
Acompanhe o ecossistema de ferramentas de SSM trimestralmente: o ritmo de melhoria é rápido o suficiente para que algo impraticável hoje esteja pronto para produção em três meses

O cenário de arquiteturas está se dividindo, e isso é bom

A era de uma arquitetura para governar todas acabou. Estamos caminhando para um mundo em que as equipes escolhem primitivas computacionais (atenção completa, linear attention, SSMs seletivos, convoluções com gating) e as combinam de acordo com suas restrições específicas. É assim que disciplinas maduras de engenharia funcionam. Ninguém constrói toda estrutura de aço. Você escolhe os materiais de acordo com a carga que eles precisam suportar.

O transformer não está morto. Continua sendo a arquitetura mais comprovada para muitas cargas e vai alimentar sistemas de IA críticos por muitos anos. Mas seu monopólio sobre a modelagem de sequências de última geração acabou. SSMs e híbridos conquistaram seu lugar como ferramentas de produção de primeira classe, não como curiosidades de pesquisa.

Para quem constrói sistemas reais, mais opções arquiteturais significam ferramentas melhores para problemas específicos. Isso não é uma disrupção a temer. É alavancagem de engenharia a ser explorada.