SSM vs Transformers: Guía práctica de arquitecturas

Los transformers no van a ser la única opción durante mucho más tiempo. Sé que suena a afirmación atrevida: llevamos años viendo cómo la arquitectura transformer domina todo, desde los modelos de lenguaje hasta el plegamiento de proteínas. Pero después de pasar los últimos meses comparando modelos de espacio de estados (SSM) con baselines transformer en cargas de trabajo de producción, estoy convencido de que el cambio es real. No porque los SSM sean siempre mejores. No lo son. Sino porque resuelven problemas concretos que los transformers no pueden resolver de base, y la última generación ha cerrado la brecha de calidad lo suficiente como para que ignorarlos sea hoy una decisión de deuda técnica.

Esto no es un artículo de humo. Voy a repasar qué son realmente los modelos de espacio de estados, en qué mejora de verdad Mamba-3, dónde los SSM todavía se quedan cortos y cómo debería pensar tu equipo la adopción. De practicante a practicante.

Por qué los transformers chocan contra un muro a escala

Ya conoces la historia del escalado cuadrático. La auto-atención calcula una matriz N×N para una secuencia de longitud N, así que duplicar el contexto cuadruplica el cómputo y la memoria. Durante mucho tiempo esto no importó demasiado. Los modelos funcionaban con unos pocos miles de tokens, y el hardware iba al ritmo.

Esa era ya pasó. Las cargas de trabajo que construimos ahora exigen rutinariamente contextos de más de 100K tokens. Los asistentes de código necesitan ver repositorios enteros. Los pipelines multimodales procesan horas de vídeo. Los agentes mantienen historiales de conversación que abarcan días. A estas escalas, la atención cuadrática no solo es cara: es un muro.

El problema de la KV cache empeora las cosas. Durante la generación autorregresiva, cada capa del transformer almacena pares clave-valor para cada token que ha visto. Esa caché crece linealmente por capa y devora la memoria de la GPU muy rápido. He visto un transformer de 7B consumir 40 GB de VRAM solo en KV cache con un contexto de 128K. Es memoria que no puedes usar para agrupar más peticiones.

La escalabilidad cuadrática de la memoria hace casi imposibles los contextos de un millón de tokens con atención estándar
El crecimiento de la KV cache limita los usuarios concurrentes por GPU, lo que multiplica directamente el coste en producción
El consumo energético de la inferencia con contextos largos en transformers cada vez cuesta más justificarlo
Las aplicaciones en tiempo real (robótica, IA en el edge) necesitan generar tokens en menos de un milisegundo, algo que la atención no puede ofrecer
El fenómeno del «attention sink» degrada la calidad en secuencias muy largas aunque tengas memoria de sobra

Estas no son preocupaciones teóricas. Son la razón por la que tres equipos distintos con los que he trabajado empezaron a evaluar alternativas en serio el año pasado.

Cómo funcionan realmente los modelos de espacio de estados

Los modelos de espacio de estados vienen de la teoría de control, donde llevan décadas usándose para modelar sistemas dinámicos. La idea central es sencilla: en lugar de mirar cada token anterior para calcular cada salida (como hace la atención), mantienes un estado oculto comprimido que evoluciona con el tiempo. Los tokens nuevos actualizan el estado. El estado produce las salidas. Y eso es todo.

Matemáticamente, un SSM se define con cuatro matrices (A, B, C y D) que gobiernan cómo evoluciona un estado oculto h en respuesta a la entrada x. Discretizas las ecuaciones continuas para datos secuenciales y obtienes una recurrencia muy simple de calcular en inferencia.

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)

La belleza está ahí mismo, en el código. La inferencia usa memoria O(1) y cómputo O(1) por token, sea cual sea la longitud de la secuencia. Sin KV cache. Sin explosión cuadrática. Todo el historial queda comprimido en el vector de estado oculto.

¿El truco? Durante el entrenamiento, ejecutar esta recurrencia de forma secuencial sería dolorosamente lento. La clave es que el mismo cálculo se puede reformular como una convolución o como un parallel scan, que las GPUs manejan de forma eficiente. Así obtienes entrenamiento paralelo e inferencia recurrente: lo mejor de los dos mundos.

De Mamba a Mamba-3: qué arregló cada generación

Los primeros SSM, como S4, demostraron el concepto, pero tenían una debilidad crítica: no razonaban bien basándose en el contenido. Las matrices de transición de estado eran fijas para todas las entradas, así que el modelo no podía decidir qué recordar y qué olvidar según lo que estaba leyendo. Es como tomar apuntes con la regla de «escribe una de cada tres palabras»: capturas algo útil, pero no puedes adaptarte a lo que importa.

Mamba, presentado por Albert Gu y Tri Dao a finales de 2023, resolvió esto con una idea elegante: hacer que los parámetros del SSM dependan de la entrada. En lugar de matrices A, B, C fijas, Mamba las calcula en función del token actual. El modelo aprende a guardar selectivamente la información relevante y a descartar el ruido. Este mecanismo «selectivo» dio a los SSM la conciencia del contenido que les faltaba.

Mamba-2 aportó la intuición teórica de que los SSM estructurados y la atención lineal son matemáticamente duales: el marco de State Space Duality (SSD). Esto no fue solo académico. Permitió implementaciones conscientes del hardware que aprovechan mejor los tensor cores de la GPU, y subieron notablemente el throughput de entrenamiento.

Mamba-3 es donde las cosas se ponen interesantes desde el punto de vista del despliegue. Tres innovaciones son las más importantes:

Seguimiento de estado multiescala: el modelo mantiene el estado en varias resoluciones temporales a la vez, capturando tanto patrones locales como dependencias de largo alcance sin sacrificar ninguno de los dos
Compresión adaptativa del estado: el estado oculto se expande en pasajes con razonamiento complejo y se contrae en texto predecible, lo que ahorra cómputo sin perder calidad
Mejor inicialización y gating: la estabilidad del entrenamiento a gran escala mejoró mucho, lo que importa muchísimo cuando te gastas millones en una ejecución de entrenamiento

Mamba-3 no supera a los transformers en todos los benchmarks. Tampoco necesita hacerlo. Iguala la calidad en la mayoría de las evaluaciones estándar y usa una fracción del cómputo de inferencia. Para la mayoría de las cargas de producción, ese es el compromiso que importa.

Atención lineal y la convergencia con los SSM

Hay una línea paralela que vale la pena entender. La atención lineal ataca el mismo problema de eficiencia, pero desde dentro del marco transformer. La atención estándar calcula la matriz N×N completa. La atención lineal sustituye el softmax por una función kernel descomponible y reordena las operaciones para no materializar nunca esa matriz cuadrá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

Fíjate bien en ese código. La atención lineal, ejecutada de forma incremental, mantiene un estado acumulado y lo actualiza con cada token nuevo. ¿Te suena? Debería: hace esencialmente lo mismo que un SSM. El marco SSD formalizó esta conexión, y es una de las intuiciones teóricas más importantes de la investigación reciente en modelado de secuencias.

Arquitecturas como GLA (Gated Linear Attention) y las variantes de RetNet han llevado esto más lejos, añadiendo gating dependiente de los datos que difumina casi por completo la frontera entre la atención lineal y los SSM selectivos. La conclusión práctica: no los veas como enfoques competidores. Están convergiendo.

Arquitecturas híbridas: lo que realmente gana en producción

Esto es lo que les digo a los equipos que me preguntan si deberían pasarse a SSM: no apuesten por lo puro. Las arquitecturas que ofrecen mejores resultados ahora mismo son híbridos que mezclan capas SSM con un pequeño número de capas de atención. Distintas primitivas computacionales sirven para cosas distintas, y fingir lo contrario deja rendimiento sobre la mesa.

Las capas SSM destacan comprimiendo y propagando información secuencial de forma eficiente. Las capas de atención siguen sin rival para la recuperación precisa basada en el contenido: «encuentra la línea exacta de la página 47 que responde a esta pregunta». Un híbrido bien diseñado usa SSM en el 80-90 % de sus capas y espolvorea atención donde más importa.

Modelos estilo Jamba: alternan capas Mamba y de atención con bloques feed-forward MoE, enrutando dinámicamente entre el procesamiento SSM eficiente y la atención precisa
Diseños de la familia Griffin: unidades lineales recurrentes con gating combinadas con atención local de ventana deslizante, buenos resultados con muy poca atención completa
Híbridos Mamba-Attention: bloques Mamba-3 en la mayoría de las capas, con capas de atención completa insertadas en profundidades estratégicas para enrutar información global
Sucesores de StripedHyena: intercalan convoluciones con gating, capas SSM y atención dispersa en patrones optimizados mediante NAS

Los números lo respaldan. Varios grupos independientes han demostrado que una división 85/15 entre SSM y atención iguala la calidad de un transformer puro con el mismo número de parámetros, a la vez que reduce los FLOPs de inferencia un 40-60 %. El ahorro de memoria es aún mayor en cargas de contexto largo. Esto no es una mejora marginal. Es recortar a la mitad tu factura de GPU.

Benchmarks de producción: dónde los SSM aportan y dónde no

Vamos a ser concretos con los números, porque las afirmaciones vagas sobre eficiencia no sirven de nada a quien toma decisiones de despliegue.

Throughput de inferencia: un modelo basado en Mamba-3 de 8B de parámetros genera tokens a la misma velocidad tanto si el contexto es de 1K como de 500K tokens. Un transformer comparable se va ralentizando a medida que crece la KV cache. Con 500K de contexto, el modelo SSM ofrece entre 5 y 8 veces más throughput por GPU. Esto no es teórico: lo he medido yo.

Usuarios concurrentes: sin KV cache, los modelos SSM pueden atender muchas más peticiones simultáneas. En una sola A100, donde un transformer maneja unos 8 streams concurrentes con 32K de contexto, un modelo SSM equivalente puede manejar más de 30. Para cualquiera que haga inferencia a escala, este es el número que cambia la economía.

Velocidad de entrenamiento: aquí las ganancias son más modestas. Mamba-3 entrena a unas 1,4 veces el throughput de un transformer equivalente en clústeres de H100. La diferencia crece con secuencias más largas: por encima de 32K tokens, el entrenamiento de SSM va 2-3 veces más rápido porque evita por completo la atención cuadrática.

Pero aquí tengo que ser honesto con las limitaciones. En tareas que requieren recuperar literalmente información precisa de contextos largos («¿cuál era el mensaje de error exacto de la línea 4.382?»), los SSM puros siguen rindiendo peor. El estado comprimido de tamaño fijo es una representación con pérdida. La atención puede volver a mirar los tokens originales. Esta es exactamente la razón por la que funcionan las arquitecturas híbridas: las capas de atención se encargan de la recuperación que los SSM no pueden hacer.

Dónde los SSM todavía se quedan cortos

Quiero ser muy claro con las brechas que quedan, porque adoptar una arquitectura nueva con información incompleta es una excelente manera de perder seis meses.

Aprendizaje en contexto: los transformers siguen siendo mejores adaptando su comportamiento a partir de ejemplos few-shot en el prompt. Los SSM también pueden hacerlo, pero de forma menos fiable. Si tu aplicación depende mucho de la ingeniería de prompts con ejemplos, los SSM puros te van a decepcionar.
Madurez del ecosistema: las herramientas para transformers llevan años de optimización. Los kernels específicos de SSM, la infraestructura de serving y las librerías de fine-tuning están mejorando rápido, pero todavía no están al mismo nivel. Reserva tiempo extra para la integración.
Incertidumbre del escalado por encima de 70B: los modelos Mamba-3 de hasta 70B de parámetros muestran buenas curvas de escalado, pero no tenemos datos sólidos en la frontera de 200B+. Si las leyes de escalado de los SSM se mantienen en tamaños extremos es, sinceramente, desconocido.
Técnicas de fine-tuning: LoRA y QLoRA para transformers están bien entendidos. Aplicarlos a arquitecturas SSM requiere enfoques distintos, y las mejores prácticas todavía se están definiendo.
Desajuste de hardware: las GPUs actuales están optimizadas para las multiplicaciones de matrices que a la atención tanto le gustan. Los SSM dependen mucho de los parallel scans, que funcionan razonablemente bien en el hardware moderno, pero no son la operación para la que se diseñaron las GPUs.

Ninguno de estos es un impedimento definitivo. Son problemas de ingeniería con caminos de solución conocidos. Pero son reales y deberían entrar en tu planificación.

Recomendaciones prácticas: cuándo adoptar y cómo empezar

Después de evaluar SSM en varias cargas de producción, este es el marco que uso para asesorar a los equipos.

Adopta con decisión si tu carga implica inferencia con contextos largos (32K+ tokens con regularidad), requisitos altos de concurrencia o despliegues en el edge sensibles a la latencia. El ROI es sustancial e inmediato. Empieza con una arquitectura híbrida como Jamba o un modelo de la familia Griffin en lugar de ir a SSM puro: consigues la mayoría de las ganancias de eficiencia con menos riesgo.

Espera y observa si tu carga es principalmente de contexto corto, depende mucho del aprendizaje en contexto y no tienes presión por el coste de inferencia. Aquí los transformers todavía tienen ventaja, y el ecosistema está más maduro.

Perfila tu carga de inferencia real antes de decidir: la longitud mediana del contexto y el número de usuarios concurrentes son las variables clave
Empieza con arquitecturas híbridas, no con SSM puros: tienen menos riesgo y aun así ofrecen una reducción del coste de inferencia del 40-60 %
Haz benchmarks con tus tareas concretas: los SSM destacan en resúmenes y razonamiento de largo alcance, pero se quedan atrás en recuperación exacta
Construye ya infraestructura para comparar arquitecturas: necesitas medir latencia, throughput, memoria y coste por consulta, no solo precisión
Sigue el ecosistema de herramientas SSM cada trimestre: el ritmo de mejora es tan rápido que algo poco práctico hoy puede estar listo para producción en tres meses

El panorama de arquitecturas se está fragmentando, y eso es algo bueno

Se acabó la era de una sola arquitectura para gobernarlas a todas. Vamos hacia un mundo donde los equipos eligen primitivas computacionales (atención completa, atención lineal, SSM selectivos, convoluciones con gating) y las combinan según sus restricciones concretas. Así funcionan las disciplinas de ingeniería maduras: no construyes cada estructura con acero. Eliges los materiales según la carga que tengan que soportar.

El transformer no está muerto. Sigue siendo la arquitectura más probada para muchas cargas, y va a alimentar sistemas de IA críticos durante años. Pero su monopolio en el modelado de secuencias de última generación ha terminado. Los SSM y los híbridos se han ganado su lugar como herramientas de producción de primera categoría, no como curiosidades de investigación.

Para quienes construimos sistemas reales, más opciones arquitectónicas significan mejores herramientas para problemas concretos. No es una disrupción a temer. Es una palanca de ingeniería que hay que aprovechar.