las ecuaciones de esta slide
Att(Q,K,V) = softmax(QK√d) V,   A = QK ∈ ℝT×T(atención escalada)
cada token (fila de Q) se compara con todos los tokens (columnas de K): la matriz intermedia A tiene T·T entradas. Con T = 105 son 1010 números: 40 GB en FP32 solo para UNA capa y UNA cabeza, antes de multiplicar por V.
FLOPsatención ≈ 4·L·T2·d   vs   FLOPsproyecciones+MLP ≈ 8·L·T·d2(cruce en T = 2d)
el término cuadrático en T (construir A y aplicarla a V) contra el término lineal en T (proyecciones Q,K,V,O y el MLP, que son matrices d×d por token). Igualando: 4LT²d = 8LTd² ⇔ T = 2d. Por debajo del cruce la atención es barata; por encima, domina todo el cómputo y crece sin freno.
guion paso a paso
  1. Con d = 4096, mueve T desde 100 hasta 1M mirando el panel superior. La curva dorada (atención, pendiente 2 en log–log) cruza a la curva tinta (resto, pendiente 1) exactamente en T = 2d = 8192: ahí empieza el muro.
  2. Pon T = 100 000 y lee el reparto en el panel inferior. La atención ya se come más del 80% de los FLOPs: estás pagando casi todo el cómputo en comparar tokens entre sí.
  3. Sube d a 16384 sin tocar T. El cruce se desplaza a la derecha (T = 32768): un modelo más ancho "aguanta" contextos mayores antes de que lo cuadrático domine, pero paga más por token siempre.
  4. Lleva T a 1M y mira el euro del lector. Una sola pasada completa sobre el contexto cuesta del orden de 1 € de GPU. Procesar 1000 contratos así al día son ~1000 €/día solo en prefill.
Comprueba que entiendes: ¿por qué duplicar T multiplica el coste de atención por 4 y el del MLP solo por 2?
Porque la atención compara pares de tokens: con el doble de tokens hay 2×2 = 4 veces más pares (T²). El MLP procesa cada token por separado: el doble de tokens, el doble de trabajo (T). Toda la motivación del día cabe en esa diferencia de exponente: cualquier arquitectura que procese tokens "de uno en uno" con estado compacto hereda la pendiente 1, no la 2.

Setup. El panel superior pinta, en log–log, los FLOPs de una pasada hacia delante de un Transformer de L capas y dimensión d sobre un contexto de T tokens, separados en sus dos términos: el cuadrático de la atención (dorado) y el lineal de proyecciones y MLP (tinta). La línea gris es el total. El panel inferior muestra qué fracción del cómputo se lleva la atención según T. El lector traduce a tiempo y a euros en una H100 (4·1014 FLOP/s útiles, 3 €/h).

Juega. Piensa en un caso BBVA: pasar contratos hipotecarios enteros (T ≈ 60k tokens) por un modelo de d = 4096. Mira dónde cae respecto del cruce. Luego piensa en historiales clínicos de años o en logs de transacciones: T ≈ 106. Ningún ajuste de d razonable te salva de la pendiente 2.

Lee así. En log–log las potencias son rectas y el exponente es la pendiente: la atención sube 2 décadas de coste por década de contexto; el resto, 1. Toda recta de pendiente 2 acaba cruzando a cualquier recta de pendiente 1: la única pregunta es dónde, y la respuesta es T = 2d.

Mensaje. El Transformer no "falla" en contextos largos: se vuelve económicamente inviable. Las tres rutas del día (atención lineal, SSM y MoE) atacan este coste desde ángulos distintos sin renunciar a la calidad.

Términos. T: longitud de la secuencia en tokens. d: dimensión interna del modelo. L: número de capas. FLOP: operación de coma flotante; una multiplicación+suma son 2 FLOPs. prefill: procesar el contexto completo antes de generar el primer token.

las ecuaciones de esta slide
MKV = 2 · L · T · d · bytes(memoria del KV-cache)
para generar el token T+1 sin recomputar nada, cada capa guarda los vectores K y V de todos los tokens anteriores: el 2 es "K y V", L capas, T tokens, d números por token, y bytes por número (2 en FP16, 4 en FP32). Crece linealmente con T y vive en la VRAM mientras dure la conversación.
Tmáx = MGPU − Mpesos2 · L · d · bytes(contexto máximo por GPU)
despejando T: el contexto máximo que cabe es la memoria libre dividida por el coste por token. Es la fórmula con la que un equipo de plataforma dimensiona cuántas conversaciones simultáneas soporta cada GPU.
guion paso a paso
  1. Con L = 32 y d = 4096 en FP16, sube T hasta que el badge se ponga en rojo. Alrededor de T ≈ 153 000 tokens el KV-cache solo ya desborda los 80 GB de una H100 — sin contar los pesos del modelo.
  2. Activa FP32. La recta entera sube un factor 2 (media década no: exactamente ×2) y el contexto máximo cae a la mitad: la precisión es un multiplicador directo de la factura de memoria.
  3. Configura un modelo grande: L = 80, d = 8192 (tamaño Llama-3-70B sin GQA). A 100k tokens el cache pide ~262 GB: por eso los modelos reales usan GQA, que comparte K,V entre cabezas y divide esa cifra por 8.
  4. Vuelve a FP16 y lee Tmáx en el lector para tu configuración. Esa es la cifra que decide cuántos usuarios concurrentes soporta tu despliegue: memoria, no FLOPs, es el cuello de la inferencia.
Comprueba que entiendes: ¿por qué el KV-cache crece con T si la atención lineal y los SSM no lo necesitan?
Porque la atención exacta debe poder mirar cualquier token pasado con su K y V originales: no hay forma de comprimirlos sin perder la garantía de recuperación exacta. Un SSM renuncia a esa garantía: comprime toda la historia en un estado ht de tamaño fijo N·d, que no crece con T. Es exactamente el trade-off memoria perfecta vs memoria comprimida que verás en las slides de Mamba.

Setup. El canvas pinta, en log–log, la memoria del KV-cache en GB según el contexto T, para tu configuración (L, d, precisión). La línea discontinua horizontal son los 80 GB de una NVIDIA H100; la línea fina gris es la otra precisión, para comparar. El punto dorado es tu T actual y el lector da los GB exactos, el badge de si cabe, y el Tmáx despejado.

Juega. Caso Netflix: un asistente que mantiene en contexto el historial completo de visionado y soporte de un usuario (T ≈ 200k). Caso Inditex: pasar todas las incidencias logísticas de una temporada (T ≈ 500k). Comprueba cuántas GPUs de 80 GB exige cada escenario solo en cache, por usuario activo.

Lee así. La pendiente de la recta es 1 (lineal en T): no es el muro cuadrático de la slide anterior, pero es un coste que persiste durante toda la generación y se multiplica por cada conversación abierta. El prefill paga FLOPs una vez; el KV-cache paga VRAM todo el rato.

Mensaje. En producción, el coste de servir LLMs es tanto memoria como cómputo. Mamba ataca exactamente este frente: su "KV-cache" es un estado de tamaño constante, independiente de T.

Términos. KV-cache: almacén de los vectores K y V ya calculados, para no recomputarlos al generar cada token. VRAM: memoria de la GPU. FP16/FP32: números de 2 o 4 bytes. GQA: grouped-query attention, varias cabezas de Q comparten un mismo par K,V.

las ecuaciones de esta slide
Attlin(Q,K,V) ≈ φ(Q) (φ(K)V)(atención lineal)
se sustituye el softmax por una feature map φ (aquí ELU+1, la del Linear Transformer) y se usa la asociatividad: en vez de construir la matriz T×T de φ(Q)φ(K) y aplicarla a V, se computa primero φ(K)V, que es d×d e independiente de T. La misma operación, en otro orden, con otro coste.
coste: 2·T2·d  →  2·T·d2   (ahorro ×Td)(el truco del orden)
el orden estándar paga T² (todas las parejas); el orden lineal paga d² por token. Como en contextos largos T » d, el ahorro es el cociente T/d: con T = 100k y d = 4096, ×24. El precio: φ solo aproxima el softmax.
guion paso a paso
  1. Compara los dos heatmaps con T = 16, d = 4. El patrón general de la atención (qué filas miran a qué columnas) se conserva, pero la versión lineal es más "borrosa": los picos nítidos del softmax se aplanan.
  2. Sube T a 40 dejando d = 4 y mira el lector. El cociente de multiplicaciones llega a T/d = 10: la exacta paga 10 veces más, y la brecha crece linealmente con T.
  3. Sube d a 10 con T = 16. Ahora 2Td² > 2T²d: con secuencias cortas y d grande, ¡el orden lineal es PEOR! El truco solo gana cuando T > d.
  4. Pulsa "nueva muestra" varias veces observando el error. El error de aproximación cambia con los datos pero no con T ni con d de forma sistemática: es el precio fijo de cambiar softmax por φ.
Comprueba que entiendes: si el resultado es "casi el mismo", ¿por qué no usamos siempre atención lineal?
Porque "casi" importa en las tareas de recuperación precisa: copiar un número de póliza exacto de la página 3, comparar dos cláusulas lejanas. El softmax puede concentrar casi toda la probabilidad en UN token (pico nítido); la versión φ(Q)φ(K) es de rango ≤ d y no puede formar picos tan selectivos: difumina. En generación fluida apenas se nota; en "needle in a haystack" se nota mucho. Por eso conviven ambas y por eso los híbridos tipo Jamba mezclan capas de los dos tipos.

Setup. Genero Q, K, V gaussianos para una secuencia de juguete de T tokens con dimensión d y calculo la atención de verdad de las dos maneras: arriba, la matriz softmax(QK/√d) exacta; abajo, la matriz implícita normalizada φ(Qi)·φ(Kj)/zi del orden lineal con φ = ELU+1. Ambas filas suman 1 (compruébalo en el lector). El color usa la rampa dorada: más oscuro = más atención.

Juega. El lector cuenta las multiplicaciones reales de cada orden (2T²d vs 2Td²) y mide el error entre las salidas O = AV de ambos métodos. Busca el régimen donde el ahorro es grande y el error tolerable: ese es el nicho de Performer, Linear Transformer y RetNet (streaming en edge, poca VRAM, tokens/seg en CPU como KPI).

Lee así. La asociatividad (AB)C = A(BC) no cambia el resultado cuando no hay softmax en medio; el softmax es lo único que obliga a materializar la matriz T×T. Quitarlo (aproximarlo con φ) es comprar libertad de orden a cambio de capacidad de foco.

Mensaje. La atención lineal es la primera de las tres rutas del día: misma interfaz que la atención, coste lineal en T, y un trade-off de precisión explícito y medible — lo acabas de medir tú.

Términos. φ (feature map): transformación de q y k tal que φ(q)·φ(k) ≈ exp(q·k/√d). ELU+1: x+1 si x>0, ex si x≤0; garantiza positividad. rango: la matriz lineal implícita tiene rango ≤ d, el softmax no tiene esa restricción. RetNet/Performer: variantes con decaimiento exponencial y kernels aleatorios.

las ecuaciones de esta slide
ht = &Abar; ht−1 + &Bbar; xt,    yt = C ht(SSM discreto, Ec. 1 de la nota)
el estado ht ∈ ℝN resume toda la historia: en cada paso se atenúa por &Abar; (cuánto se recuerda), se le suma la entrada escalada por &Bbar; (cuánto entra lo nuevo) y se lee con C. Aquí lo ejecutamos en el caso escalar: &Abar; = ā ∈ (0,1), &Bbar; = b̄ = 0.5, C = 1. Es estructuralmente una RNN lineal.
ht = Σk=0..t−1 āk b̄ xt−k(desenrollada: memoria exponencial)
desenrollando la recurrencia: la entrada de hace k pasos sobrevive en el estado con factor k. Memoria geométrica: con ā = 0.9, lo de hace 22 pasos pesa un 10%; con ā = 0.99, hace falta retroceder 229 pasos para caer al 10%. La semivida es t½ = ln 2 / ln(1/ā).
guion paso a paso
  1. Deja ā₁ = 0.90 y lee h₁, h₂, h₃ en el lector. Salen exactamente 1.00, 1.40 y 2.76: los tres pasos del ejemplo del deck (x = 2, 1, 3 con b̄ = 0.5), calculados aquí en vivo.
  2. Mira la respuesta al impulso (panel superior). Es una exponencial āk: el "recuerdo" de un token decae geométricamente. El canal con ā mayor tiene cola más larga.
  3. Sube ā₁ a 0.99. La semivida pasa de ~6.6 a ~69 pasos: el canal se vuelve "memoria a largo plazo". Pero fíjate en la trayectoria: también olvida más despacio el ruido.
  4. Baja ā₂ a 0.50. Ese canal solo "ve" los últimos 2–3 tokens: es un detector de presente. Un SSM real apila N canales con ā distintos: un banco de memorias a distintas escalas.
Comprueba que entiendes: ¿por qué el coste por token es O(N), independiente de T?
Porque para producir ht solo hacen falta ht−1 y xt: una multiplicación por canal y una suma, N operaciones, da igual que lleves 100 o un millón de tokens. La historia entera está comprimida en N números. La atención, en cambio, debe releer los T tokens pasados (su KV-cache) en cada paso. Esa es la diferencia estructural: memoria comprimida O(N) contra memoria literal O(T).

Setup. Ejecuto la recurrencia de verdad para dos canales escalares con ā distintos, b̄ = 0.5, C = 1. Panel superior: la respuesta al impulso kₖ = C ākb̄, es decir, cuánto pesa en el estado un token de hace k pasos. Panel inferior: la trayectoria ht sobre la secuencia del ejemplo del deck (x₁ = 2, x₂ = 1, x₃ = 3, después silencio): se ve cómo el estado absorbe cada entrada y luego se desvanece geométricamente.

Juega. Forecast de demanda Inditex: un canal con ā ≈ 0.99 captura la tendencia de temporada (memoria larga); otro con ā ≈ 0.6 captura el pico de esta semana (memoria corta). El slider te deja sentir ese dial: ā ES el dial de memoria del modelo.

Lee así. La contribución de x₁ = 2 a h₃ es b̄·x₁·ā² = 0.5·2·0.81 = 0.81 (con ā = 0.9): el lector la calcula para tu ā actual. Esa cifra es el deck hecho slider: el estado comprime toda la historia con decaimiento exponencial āk.

Mensaje. Un SSM es una RNN lineal con estado de tamaño fijo N: coste O(T·N) en tiempo y O(N) en memoria. Para T = 106 y N = 16 son 1.6·107 operaciones, contra 1012 del Transformer denso. Lo que le falta — decidir QUÉ recordar — es exactamente lo que añade Mamba en la siguiente slide.

Términos. ht: estado oculto, N números que resumen la historia. &Abar;, &Bbar;, C: transición, entrada y lectura (discretizadas). N: tamaño del estado, fijo (16–64), independiente de T. respuesta al impulso: peso de un token según su antigüedad.

las ecuaciones de esta slide
Δt = Δ(xt),   āt = e−Δt,   b̄t = 1 − e−Δt(discretización selectiva)
la novedad de Mamba (Gu & Dao, 2023): el paso de discretización Δ depende de la entrada. Δ pequeño ⇒ ā ≈ 1, b̄ ≈ 0: la puerta se cierra, el estado se conserva y la entrada se ignora. Δ grande ⇒ ā ≈ 0, b̄ ≈ 1: la puerta se abre, el estado se reescribe con la entrada. El modelo decide token a token qué guardar y qué olvidar.
ht = āt ht−1 + b̄t xt(la misma recurrencia, con puertas)
idéntica estructura que la slide anterior, pero ahora los coeficientes cambian con cada token. Ya no es LTI (invariante en el tiempo): se pierde el modo convolución, pero el scan paralelo asociativo mantiene el entrenamiento eficiente. Aquí Δ(x) = 0.02 + 3·σ(s·(|x|−1.5)), con σ la sigmoide y s la sensibilidad del slider.
guion paso a paso
  1. Con todo por defecto, compara las dos trayectorias del panel inferior. La dorada (selectiva) salta al llegar cada token importante y luego se queda plana: la puerta se cierra y lo retiene. La tinta (Δ fijo) decae y se contamina con cada token de ruido.
  2. Lee el reparto de autoría en el lector. En el SSM selectivo más del 90% del estado final procede de los tokens importantes; en el fijo, el ruido reciente pesa tanto o más que la señal antigua.
  3. Sube el ruido a 1.0. El fijo se degrada aún más; el selectivo apenas se inmuta mientras el ruido no cruce el umbral de |x| = 1.5 que abre la puerta.
  4. Baja Δ fijo a 0.05 y luego súbelo a 1.5. Con Δ pequeño el fijo recuerda mucho pero apenas escribe (también ignora lo importante); con Δ grande escribe todo y olvida todo. Sin selectividad, recordar e ignorar son el MISMO dial: no puedes tener ambos.
Comprueba que entiendes: ¿qué pierde Mamba al hacer Δ dependiente de la entrada?
La invariancia temporal (LTI). Con coeficientes constantes la recurrencia equivale a una convolución con kernel fijo (siguiente slide) y se entrena en paralelo vía FFT. Con coeficientes que dependen de xt ese kernel ya no existe: cada secuencia tiene sus propias puertas. Mamba lo resuelve con un scan asociativo en GPU: el producto de mapas afines h → āh + b̄x es asociativo, y eso basta para paralelizar con coste O(T log T). Selectividad sin renunciar al entrenamiento paralelo: esa es la contribución técnica del paper.

Setup. Secuencia de juguete de 28 tokens: ruido gaussiano de amplitud σruido con DOS tokens importantes (valor 3, barras doradas en el panel superior) en las posiciones 7 y 20. Pienso en churn telco: la "señal" son dos eventos críticos (una reclamación grave, una bajada de consumo) en medio de semanas de actividad anodina. Ejecuto en vivo dos recurrencias: el SSM de Δ fijo (tinta) y el selectivo con Δ(xt) (dorado), y descompongo el estado final en la autoría exacta de cada token (wi = b̄ixij>ij).

Juega. El experimento clave es el paso 4 del guion: con Δ fijo, memoria larga implica sordera y escritura ávida implica amnesia. La selectividad rompe ese acoplamiento porque el dial se mueve token a token.

Lee así. El panel superior también pinta Δt (puntos sobre cada token, eje derecho implícito): verás que solo se dispara en los tokens importantes. Eso ES la selectividad: B y Δ como funciones de la entrada, igual que las matrices At, Bt, Ct del deck.

Mensaje. Mamba escala a contextos de 106 tokens (genoma, libros, registros médicos) porque une el coste O(N) del SSM con la capacidad de decidir qué guardar. Pierde, en cambio, cuando hay que comparar dos posiciones lejanas con precisión quirúrgica: ahí la memoria literal del Transformer sigue mandando.

Términos. Δt: paso de discretización por token; la "apertura de puerta". selectividad: &Abar;t, &Bbar;t, Ct funciones de xt. LTI: sistema lineal invariante en el tiempo. scan asociativo: paralelización del prefijo acumulado en GPU.

las ecuaciones de esta slide
yt = Σj=0..t−1 kj xt−j,    kj = C &Abar;j &Bbar;(el SSM como convolución global)
desenrollar la recurrencia LTI da una convolución causal de la entrada con un kernel implícito de longitud T cuyo j-ésimo coeficiente es C&Abar;j&Bbar;: el mismo decaimiento geométrico de la respuesta al impulso. El kernel no se almacena como parámetros: se genera desde tres números (aquí) o tres matrices pequeñas (en general).
entrenar: convolución paralela (FFT, O(T log T))  ·  inferir: recurrencia (O(N) por token)(la dualidad)
la misma función matemática tiene dos algoritmos: en entrenamiento conviene la vista convolución (toda la secuencia disponible, paraleliza en GPU); en inferencia conviene la vista recurrencia (un token cada vez, estado constante, sin cache creciente). Esta dualidad es el corazón de S4 y de toda la familia SSM.
guion paso a paso
  1. Mueve ā de 0.5 a 0.99 mirando el kernel (panel superior). El kernel implícito se alarga: de un filtro de 2–3 taps a uno que abarca toda la secuencia. Un solo escalar controla un kernel de longitud ilimitada.
  2. Mira el panel inferior. La línea tinta (recurrencia, token a token) y los puntos dorados (convolución, todo de golpe) coinciden SIEMPRE: son el mismo objeto matemático.
  3. Lee el error máximo en el lector. Del orden de 10−15: precisión máquina. No es una aproximación, es una identidad algebraica.
  4. Pulsa "nueva secuencia" y repite. La coincidencia es exacta para cualquier entrada: la dualidad no depende de los datos, solo de que los coeficientes sean constantes (LTI).
Comprueba que entiendes: ¿por qué Mamba (selectivo) ya no puede usar la vista convolución?
Porque kj = C&Abar;j&Bbar; exige que &Abar; y &Bbar; sean los MISMOS en todos los pasos: solo así "lo que pesa un token de hace j pasos" es una función fija de j. Si āt cambia con la entrada, el peso de xi en yt es ∏j=i+1..tj, que depende de la secuencia concreta: no hay kernel universal que precomputar. Mamba sustituye la FFT por el scan asociativo paralelo, pagando algo de eficiencia a cambio de la selectividad.

Setup. Genero una entrada aleatoria de T = 60 tokens y calculo yt de las dos maneras: ejecutando la recurrencia ht = āht−1 + b̄xt paso a paso (línea tinta) y aplicando la convolución con el kernel implícito kj = ājb̄ (puntos dorados). El panel superior muestra ese kernel y su "memoria efectiva" 1/(1−ā) pasos.

Juega. El slider de ā es el mismo de la slide SSM, pero ahora lo ves como diseñador de filtros: ā cerca de 1 = filtro de tendencia (forecast de demanda mensual); ā bajo = filtro de novedad (detección de picos en transacciones). Dos lecturas del mismo escalar.

Lee así. El lector compara costes reales: la recurrencia hace 2 multiplicaciones por token (O(N) con N = 1 aquí); la convolución ingenua haría ~T/2 por token, pero en entrenamiento se hace UNA vez para toda la secuencia vía FFT en O(T log T), que en GPU es masivamente paralelo. Por eso S4 entrena como una CNN e infiere como una RNN.

Mensaje. Recurrencia y convolución son dos algoritmos para la misma función. Esa dualidad da a los SSM lo mejor de ambos mundos: entrenamiento paralelo (como el Transformer) e inferencia con estado constante (como una RNN), sin KV-cache que crezca.

Términos. kernel implícito: filtro kj = C&Abar;j&Bbar; generado por los parámetros, no almacenado. convolución causal: yt solo usa entradas pasadas. FFT: transformada rápida de Fourier, convoluciona en O(T log T). memoria efectiva: 1/(1−ā), escala temporal del filtro.

las ecuaciones de esta slide
MoE(x) = Σk=1..K gk(x) Ek(x),    g(x) = softmax(Wg x) con top-r(Ec. 2 de la nota)
K expertos Ek (MLPs independientes) y un router: una capa lineal Wg seguida de softmax que produce un peso por experto. Solo los r mayores se activan (los demás gk = 0, sus expertos ni se evalúan); los r pesos supervivientes se renormalizan para sumar 1. El router se entrena end-to-end con el modelo.
softmax(z)k = ezkΣj ezj,    z = Wg x(el triaje del hospital)
la metáfora del deck: el token es un paciente, el router es el triaje, los expertos son los especialistas. El triaje (softmax sobre K logits) decide qué r de los K especialistas ven al paciente; los otros K−r descansan y no cuestan FLOPs.
guion paso a paso
  1. Mueve x₁ y x₂ despacio por el mapa. El punto dorado cruza fronteras entre regiones: cada región es el territorio de un experto (su color = su índice). Las fronteras son rectas porque el router es lineal.
  2. Observa las barras al cruzar una frontera. Cerca de la frontera dos expertos tienen gates parecidos (reparto ~50/50); lejos, uno domina. El softmax hace el triaje GRADUAL, el top-r lo hace DISCRETO.
  3. Sube r de 2 a 4 con K = 8. Se activan más barras doradas y cada una pesa menos; la suma sigue siendo 1.000 (lo verifica el lector). Más expertos activos = más calidad potencial y más coste por token.
  4. Pulsa "otro router". Las regiones cambian por completo: el mapa de especialización no está prefijado, lo aprende Wg durante el entrenamiento.
Comprueba que entiendes: ¿por qué el coste por token no depende de K sino de r?
Porque los K−r expertos no seleccionados ni se evalúan: su gk es exactamente 0 tras el top-r, así que su MLP nunca se ejecuta. El router sí evalúa los K logits, pero eso es una matriz K×d minúscula comparada con un experto. K solo aparece en la factura de MEMORIA (hay que tener los K expertos cargados en VRAM por si acaso) — ese es el trade-off de la slide siguiente.

Setup. Un token de juguete x ∈ ℝ² (en un modelo real sería el vector de dimensión d del token) y un router real: z = Wgx con Wg ∈ ℝK×2 aleatoria, softmax encima, top-r y renormalización — todo calculado en vivo. El mapa pinta, para cada punto del plano, qué experto ganaría (rampa dorada por índice); las barras de abajo muestran el softmax completo (contorno gris) y los gates finales tras top-r (relleno dorado).

Juega. Versión negocio del mapa: en un asistente bancario, unos expertos acaban especializados en lenguaje jurídico, otros en números y tablas, otros en conversación general. El token "EURIBOR" cae en una región; el token "hola" en otra. Tú estás moviendo el token por el espacio de representaciones.

Lee así. El lector muestra los dos invariantes que el cálculo debe cumplir: el softmax completo suma 1.000 y los gates renormalizados tras top-r también. Si r = 1 (Switch Transformer), el ganador se lleva gate = 1 y la frontera entre regiones es una decisión dura.

Mensaje. MoE no elimina parámetros: los organiza para que trabajen por turnos. El router es la pieza que convierte un modelo enorme en uno barato por token — y también la pieza frágil que hay que vigilar (slide de balanceo).

Términos. Ek: experto, un MLP independiente. gk(x): peso de routing (0 si no está en el top-r). Wg: matriz del router. K: expertos totales (8–256). r: activos por token (típicamente 2). Switch: la variante r = 1.

las ecuaciones de esta slide
Ptotal ≈ K·|E|    Pactivos ≈ r·|E|(la aritmética de MoE)
con K expertos de |E| parámetros cada uno y r activos por token: la capacidad (lo que el modelo sabe) escala con los totales; el coste por token (FLOPs ≈ 2·Pactivos) escala con los activos. Mixtral 8×7B: K = 8, |E| = 7B, r = 2 ⇒ 56B totales, 14B activos. DeepSeek-V3: K = 256, r = 8 ⇒ 671B totales, 37B activos.
VRAM ≈ 2·Ptotal bytes (FP16)  ·  €/token ∝ 2·Pactivos FLOPs(memoria vs latencia)
la letra pequeña: TODOS los expertos deben estar cargados en VRAM (no sabes a cuál enrutará el siguiente token), así que la memoria paga los totales aunque la latencia pague los activos. MoE es para servidores con mucha VRAM; en un portátil no hay milagro.
guion paso a paso
  1. Configura Mixtral: K = 8, r = 2, |E| = 7. El punto dorado cae encima de la referencia Mixtral (56B totales, 14B activos): pagas inferencia de 14B con capacidad de 56B.
  2. Sube K a 256 dejando r y |E|. Los totales se disparan (×32) pero los activos NO se mueven: el coste por token es exactamente el mismo. Esa es la palanca que explota DeepSeek.
  3. Mira la VRAM en el lector con K = 256. ~3.6 TB en FP16: hacen falta decenas de GPUs solo para tener el modelo cargado. La capacidad gratis en FLOPs se paga en memoria.
  4. Compara con la diagonal del canvas. Los modelos densos (Llama-3-405B) viven en la diagonal activos = totales; todo MoE vive por debajo. La distancia vertical a la diagonal es el descuento de inferencia.
Comprueba que entiendes: ¿por qué DeepSeek-V3 pudo entrenar un modelo de 671B por ~5.5 M$ cuando GPT-4 costó ~100 M$?
Porque el coste de entrenamiento también escala con los parámetros ACTIVOS, no con los totales: cada token de entrenamiento solo atraviesa r expertos (37B efectivos), no los 671B. A eso se suman precisión FP8 y optimizaciones de comunicación, pero la palanca dominante es MoE: separar capacidad de coste por token vale tanto para entrenar como para servir. Es la razón por la que MoE es la receta de los modelos punteros cerrados (GPT-4) y abiertos (Mixtral, DeepSeek).

Setup. El canvas es un mapa log–log de parámetros totales (eje x) contra activos por token (eje y). La diagonal discontinua es el mundo denso (activos = totales); cada punto gris es un modelo real con cifras públicas: Mixtral 8×7B (56B/14B), DeepSeek-V3 (671B/37B), Llama-3-405B denso (405B/405B) y la estimación filtrada de GPT-4 (~1.8T/~280B, no confirmada). El punto dorado es TU configuración de los sliders, con la fórmula Ptotal = K|E|, Pactivos = r|E| calculada en vivo (los modelos reales añaden además parámetros compartidos de atención, por eso sus activos no son exactamente r|E|).

Juega. El lector traduce a dinero: FLOPs por token generado (≈ 2Pactivos), euros por millón de tokens en una H100 a 3 €/h, y la VRAM mínima para tener el modelo cargado. Diseña el MoE que tu presupuesto cloud soporta y mira qué capacidad total te llevas a cambio.

Lee así. Moverse en horizontal (más K) es comprar conocimiento pagando solo VRAM; moverse en vertical (más r) es comprar calidad por token pagando FLOPs. Los diseñadores de Mixtral y DeepSeek eligieron puntos muy distintos del mismo plano.

Mensaje. MoE separa el número total de parámetros del coste por token: la clave de la eficiencia moderna. Democratiza el entrenamiento de modelos gigantes — ya no hace falta presupuesto de big tech para competir.

Términos. Ptotal: parámetros cargados en memoria. Pactivos: parámetros que procesan cada token concreto. |E|: tamaño de un experto. FP8/FP16: precisiones de entrenamiento e inferencia. denso: modelo donde activos = totales.

las ecuaciones de esta slide
Laux = λ · K · Σe=1..K fe · Pe(pérdida de balanceo, Switch Transformer)
fe = fracción de tokens cuyo top-1 es el experto e (con stop-gradient); Pe = probabilidad media que el router asigna a e. Si el reparto es uniforme, fe = Pe = 1/K y Laux = λ: su mínimo. Si un experto acapara, su producto f·P crece y el gradiente empuja sus logits hacia abajo en los tokens que acapara.
∂Laux∂zi,e = λKn · pi,e(feΣe'fe'pi,e')(el gradiente que ejecuta esta slide)
el gradiente exacto a través del softmax: para cada token i, baja el logit de los expertos sobre-usados (fe mayor que la media ponderada) y sube el de los infra-usados. Es lo que el botón "entrenar" aplica de verdad, paso a paso, sobre Wg.
guion paso a paso
  1. Pulsa "entrenar 50 pasos" tres o cuatro veces con λ = 1. El histograma tinta (sin balanceo) se concentra en unos pocos expertos y aparecen barras a cero: expertos muertos. El dorado (con balanceo) se mantiene cerca de la línea uniforme 1/K.
  2. Mira el badge de expertos muertos. Sin balanceo suele haber varios; con balanceo, ninguno o casi ninguno. Un experto muerto es VRAM ocupada que no aporta nada.
  3. Reinicia, pon λ = 0 y entrena. Ahora las DOS simulaciones colapsan igual: sin el término auxiliar, el rico se hace más rico — el experto que gana un token se especializa, gana más tokens, y los demás nunca aprenden.
  4. Reinicia con λ = 2 y entrena mirando el scatter. El plano queda repartido en territorios de tamaño parecido: balanceo fuerte = reparto equitativo, aunque a veces fuerza divisiones poco naturales de un mismo cluster (el precio de λ alto).
Comprueba que entiendes: ¿por qué el routing colapsa sin ayuda, si nadie "quiere" matar expertos?
Es un bucle de retroalimentación: el experto que por azar inicial gana los tokens de un cluster se entrena con ellos y mejora en ellos; al mejorar, el router le asigna aún más tokens parecidos. Los expertos que no ganan nada no reciben gradiente y no mejoran nunca: ricos más ricos, muertos para siempre. Es el mismo fenómeno que el "winner-take-all" en k-means con mala inicialización. La pérdida auxiliar rompe el bucle penalizando la concentración mientras los expertos aún están a tiempo de especializarse en otra cosa.

Setup. 360 tokens sintéticos en 2D (tres clusters: piensa en consultas de banca, jurídico y conversación general llegando a un MoE de BBVA) y dos routers idénticos al inicio que entreno en vivo con la MISMA dinámica (especialización winner-take-all tipo k-means online sobre Wg): la simulación tinta sin pérdida de balanceo y la dorada añadiendo el gradiente exacto de Laux con tu λ. Arriba: histograma de uso fe de cada experto en ambas simulaciones, con la línea uniforme 1/K. Abajo: los tokens coloreados por el experto que se los queda en la simulación dorada, con los vectores We marcados.

Juega. El botón "entrenar" ejecuta 50 pasos reales de la dinámica (asignación top-1, actualización del ganador, gradiente de balanceo). No hay curvas precocinadas: cada reinicio con otra semilla produce otra historia de colapso.

Lee así. El lector da el uso máximo y mínimo, el recuento de expertos muertos (fe < 2%) en cada simulación y el valor actual de K·ΣfePe (que vale 1 en el reparto perfecto). Verás que el dorado se acerca a 1 y el tinta se aleja.

Mensaje. El router es la pieza frágil de MoE: sin un término de balanceo, parte de la capacidad que pagas en VRAM muere. Todo MoE serio (Switch, Mixtral, DeepSeek) entrena con una Laux de este tipo, y DeepSeek-V3 llegó a sustituirla por sesgos ajustados dinámicamente: balancear sin contaminar el gradiente principal.

Términos. fe: fracción de tokens enrutados a e. Pe: probabilidad media del router hacia e. experto muerto: fe ≈ 0 de forma persistente. λ: peso de la pérdida auxiliar frente a la de la tarea. winner-take-all: dinámica donde el ganador refuerza su ventaja.

familiaFLOPs/tokencache/estado VRAM totalGPUs 80 GB€/1M toktokens/mes
las ecuaciones de esta slide
FLOPs/token ≈ 2·Pact + 4·L·T·d  (atención)   ·   ≈ 2·P  (SSM)(coste de generación)
generar un token cuesta dos veces los parámetros activos (multiplicar-acumular por cada peso) más, si hay atención, releer el KV-cache: 4·L·T·d FLOPs que crecen con el contexto T. El SSM no tiene ese segundo término: su estado no crece. Memoria: KV = 2LTd·bytes (Transformer/MoE) contra 2LdN·bytes constante (Mamba).
guion paso a paso
  1. Con T = 10k, lee la tabla. El denso 70B y el MoE están parejos en €/1M tokens; Mamba es el más barato pero con menos capacidad. A contexto corto, el Transformer denso es perfectamente competitivo.
  2. Sube T a 1M. Las curvas del Transformer y del MoE despegan (el término 4LTd domina) mientras Mamba sigue plana: a contexto extremo el coste por token del denso se multiplica por ~20 y el de Mamba no se mueve.
  3. Mira la columna de GPUs a T = 1M. El KV-cache añade cientos de GB: el denso 70B pasa de 2 a 9 GPUs por réplica. Mamba sigue cabiendo en 1.
  4. Fija tu presupuesto (p. ej. 3000 €/mes) y compara tokens/mes. La última columna es la decisión de negocio: cuántos tokens sirves al mes con cada familia, en TU contexto típico.
Comprueba que entiendes: ¿por qué no hay una columna "calidad" calculada con fórmula?
Porque la calidad no se deduce de la aritmética: depende de la tarea. La evidencia empírica (2024–2026) dice: el denso y el MoE dominan en recuperación precisa y razonamiento; Mamba iguala en modelado fluido de secuencias largas y pierde en "needle in a haystack"; los híbridos tipo Jamba (capas Transformer intercaladas con capas Mamba) capturan lo mejor de ambos a partir de 128k de contexto. Por eso la tabla del deck termina en un KPI por familia, no en un ranking universal: eliges familia justificando TU KPI.

Setup. Tres modelos concretos con cifras realistas: un Transformer denso de 70B (L = 80, d = 8192), un MoE tipo DeepSeek (671B totales, 37B activos, L = 61, d = 7168) y un SSM tipo Mamba de 7B (L = 64, d = 4096, N = 16). El canvas pinta € por millón de tokens generados según el contexto T (log–log), con tu T marcado; la tabla recalcula con tus sliders todas las columnas usando las fórmulas del panel: FLOPs por token, memoria de cache o estado, VRAM total, GPUs de 80 GB necesarias, coste por millón de tokens (H100 a 3 €/h, 4·1014 FLOP/s útiles) y tokens servibles con tu presupuesto mensual. La celda dorada marca al ganador de cada columna.

Juega. Tres escenarios del curso: chatbot de churn telco (T ≈ 4k → gana el denso por simplicidad), asistente generalista BBVA con RAG (T ≈ 32k, mucho volumen → el MoE da máxima calidad por euro) y análisis de historiales clínicos completos (T ≈ 1M → solo Mamba o un híbrido lo sirven a coste sano).

Lee así. Ninguna fila gana todas las columnas, y esa es la lección: el coste de entrenamiento favorece al MoE, la memoria por petición a Mamba, la calidad por defecto al denso. La elección es un argumento de KPI, no de moda.

Mensaje. Las alternativas no sustituyen al Transformer: lo complementan cuando una dimensión concreta (contexto, latencia, coste) deja de admitir el modelo denso. En el proyecto AI-first, eliges familia justificando el KPI — exactamente lo que acabas de hacer con los sliders.

Términos. prefill/generación: procesar el contexto vs producir tokens nuevos. híbrido (Jamba): alterna bloques Transformer y Mamba. Griffin/StripedHyena: otras mezclas (atención local + recurrencias; convoluciones largas). KPI: la métrica de negocio que decide la arquitectura.

El muro cuadrático
Slides: Muro n² · KV-cache
"La atención compara todos los pares: FLOPs ∝ T² a partir de T = 2d, y un KV-cache que crece con T hasta desbordar la VRAM. El Transformer no falla en contextos largos: deja de ser pagable."
Atención lineal
Slide: At. lineal
"Cambiar softmax por φ y reordenar el producto: φ(Q)(φ(K)V) baja de O(T²d) a O(Td²). El precio es foco: la matriz implícita de rango ≤ d difumina la recuperación precisa. KPI: tokens/seg en edge."
SSM y Mamba
Slides: SSM · Selectividad · Convolución
"ht = &Abar;ht−1 + &Bbar;xt: memoria exponencial comprimida en N números, coste O(N) por token, estado que no crece. Mamba añade Δ(x): puertas que guardan lo importante e ignoran el ruido. Dualidad recurrencia–convolución para entrenar en paralelo. KPI: memoria por petición en contextos de 106 tokens."
Mixture of Experts
Slides: MoE router · Tot/activos · Balanceo
"softmax(Wgx) con top-r: capacidad K|E| pagando r|E| por token. La VRAM paga los totales, la latencia los activos; el router necesita Laux de balanceo o colapsa en expertos muertos. KPI: €/token a calidad alta. Es la receta de GPT-4, Mixtral y DeepSeek-V3 (671B por 5.5 M$)."
La decisión de arquitectura
Slide: Comparativa
"Denso para ≤ 32k y calidad por defecto; MoE para asistentes generalistas en cloud con VRAM grande; Mamba para genoma, historiales y libros; atención lineal para streaming en edge; híbridos (Jamba) para 128k+ balanceando calidad y coste. En el proyecto AI-first, la familia se elige justificando el KPI."

En una frase. El Bloque I termina donde empezó la ingeniería de 2026: la arquitectura ya no es un dogma sino un menú, y el criterio de elección es siempre el mismo — qué dimensión del coste (pares de tokens, memoria de contexto, parámetros por token) limita TU caso de negocio, y qué familia la convierte en lineal.

Garrido-Merchán — ecgarrido@comillas.edu — Deep Learning para Business Analytics — Día 10 · Alternativas al Transformer: Mamba, SSM y MoE