CODA es una técnica de optimización para transformers que reescribe bloques completos como programas GEMM-epilogue, fusionando operaciones de normalización, activación y residuales directamente en los kernels de multiplicación de matrices. Según el paper publicado en mayo de 2026, el resultado es una mejora promedio del 24% en velocidad para sequence lengths de 128 a 1024.
En 30 segundos
- CODA optimización transformers logra un 24% de mejora promedio de rendimiento al fusionar operaciones memory-bound dentro de los epilogues de GEMM.
- El truco es mantener los tiles de salida GEMM en registros on-chip y ejecutar normalización, activación y operaciones residuales mientras los datos están ahí, sin volver a memoria global.
- Cubre prácticamente toda la computación no-atención de un transformer: scaling, reducciones, transformaciones pairwise, acumulación.
- Los kernels generados funcionan tanto escritos por humanos como generados por LLMs, lo que abre una puerta interesante para síntesis automática.
- El mecanismo de atención queda fuera del scope de CODA y se sigue manejando por separado (FlashAttention y derivados).
Qué es CODA y por qué resuelve un problema real
CODA (Compiler Optimizations for Deep learning Abstractions, según el paper) es una abstracción que permite reescribir bloques enteros de transformers como programas GEMM-epilogue. En términos concretos: en vez de ejecutar una multiplicación de matrices, guardar el resultado en VRAM, traerlo de vuelta para aplicar LayerNorm, guardarlo otra vez, traerlo para la activación y así sucesivamente, CODA hace todo eso en un solo pase mientras los datos siguen en los registros del chip.
Si alguna vez perfilaste el entrenamiento de un modelo mediano y te preguntaste por qué el 40% del tiempo se va en operaciones que no son las multiplicaciones de matrices, acá está la respuesta.
El problema de fondo es que los transformers tienen dos tipos de operaciones con perfiles de rendimiento opuestos: las GEMM (multiplicaciones de matrices) que son compute-bound y aprovechan bien el hardware de las GPUs modernas, y las operaciones de normalización, activación y residuales que son memory-bound y pasan la mayor parte del tiempo moviendo datos entre registros, caché y VRAM. La optimización CODA para transformers aborda exactamente ese segundo grupo.
El cuello de botella de memoria en transformers modernos
Ponele que tenés un bloque transformer estándar: attention → LayerNorm → FFN → residual. La atención ya tiene FlashAttention para manejarla eficientemente. Pero el resto —LayerNorm, GeLU o SiLU, la suma residual— son operaciones que en la implementación naive requieren múltiples roundtrips a VRAM.
Cada roundtrip a VRAM en una H100 cuesta microsegundos que se acumulan. Con sequence lengths largas y batch sizes grandes, eso se convierte en un porcentaje significativo del tiempo de forward y backward pass. Investigaciones anteriores sobre fusión de kernels ya habían documentado que las operaciones memory-bound pueden consumir entre el 30% y el 50% del tiempo de entrenamiento en arquitecturas transformer típicas, dependiendo de la implementación.
El contraste es brutal: una GEMM en una GPU moderna puede estar utilizando el 80-90% de los FLOPS disponibles. Una LayerNorm standalone rara vez supera el 20% de uso de ancho de banda de memoria. La diferencia no es que la GPU sea lenta para la normalización, es que la normalización no le da suficiente trabajo para justificar el tiempo que tarda en mover los datos.
Cómo funciona el enfoque GEMM-Epilogue de CODA
La idea central es elegante: cuando una GEMM termina de calcular un tile de salida, ese tile está en los registros del chip. En ese momento, ejecutar una operación epilogue sobre esos datos es casi gratuito comparado con escribirlos a VRAM y volver a leerlos. Esto se conecta con lo que analizamos en la arquitectura de modelos de lenguaje.
Lo que CODA agrega es una capa de reparametrización algebraica que permite expresar operaciones como LayerNorm, activaciones (GeLU, SiLU, ReLU), sumas residuales y scalings en términos de estas operaciones epilogue. No todas las operaciones admiten esta transformación directa, así que el paper detalla las equivalencias algebraicas que permiten reformular las operaciones más comunes de los transformers en este formato.
El resultado práctico: un bloque que antes ejecutaba una GEMM + escritura a VRAM + lectura + LayerNorm + escritura + lectura + activación ahora ejecuta una GEMM con epilogue que hace todo lo anterior sin salir de los registros. Los datos tocan VRAM una sola vez al final.
¿Y en el backward pass? Acá viene la parte interesante. CODA también cubre los gradientes, lo que no es trivial porque las operaciones epilogue necesitan ser diferenciables y sus gradientes también tienen que poder expresarse como GEMM-epilogue. El paper muestra que para el conjunto de operaciones que cubre, esto es posible con las reparametrizaciones algebraicas correctas.
Qué operaciones cubre CODA en forward y backward
Según el paper, CODA puede optimizar cuatro categorías de operaciones:
- Scaling y bias: multiplicación por escalar, suma de bias, operaciones de normalización de escala.
- Reducciones: LayerNorm, RMSNorm, softmax (aunque la atención se maneja por separado), batch normalization.
- Transformaciones pairwise: activaciones elemento a elemento como GeLU, SiLU, ReLU, y sus variantes.
- Acumulación: sumas residuales, dropout aplicado durante entrenamiento, operaciones de mezcla de expertos en MoE.
En conjunto, el paper afirma cubrir “nearly all non-attention computation” de un transformer estándar. Lo que queda fuera es principalmente el mecanismo de atención (que tiene su propio ecosistema de optimización: FlashAttention, PagedAttention, y derivados) y algunas operaciones más exóticas de arquitecturas no estándar.
Eso sí: la cobertura depende de que las operaciones puedan expresarse en la gramática de GEMM-epilogue que CODA define. Arquitecturas muy customizadas o con operaciones poco comunes van a necesitar trabajo adicional para integrarse.
Resultados de rendimiento: 24% de mejora promedio
Los números que presenta el paper son concretos: mejora promedio del 24% para sequence lengths de 128 a 1024, medidos en tiempo de entrenamiento end-to-end (no solo en los kernels optimizados). El benchmark incluye tanto kernels escritos manualmente como kernels generados por LLMs usando la descripción CODA como especificación. Relacionado: en sistemas como ChatGPT.
¿Qué significa un 24% en la práctica? Si estás entrenando un modelo durante 30 días, eso es potencialmente una semana menos de GPU. A precios de H100 en 2026 (rondando los USD 2.50 a 3.50 por hora en cloud), el ahorro se vuelve muy concreto muy rápido.
El rango de mejora no es uniforme: a sequence lengths cortas (128) la ganancia es mayor porque la proporción de tiempo en operaciones memory-bound es más alta. A sequence lengths largas (1024+) la GEMM dominates más y el beneficio relativo baja (aunque en términos absolutos sigue siendo significativo).
| Sequence Length | Mejora de rendimiento | Operaciones más beneficiadas |
|---|---|---|
| 128 | ~30% (estimado) | LayerNorm, activaciones |
| 256-512 | ~24% (promedio) | Residuales + norm |
| 1024 | ~18% (estimado) | Activaciones FFN |
| 2048+ | No reportado | Requiere evaluación adicional |
Los datos exactos por sequence length no están todos disponibles en el abstract. Los valores intermedios son los reportados directamente; el resto son estimaciones basadas en la tendencia descrita. Tomá los números de los extremos con la pinza correspondiente hasta que el paper completo esté disponible para revisión.
Implicaciones para el entrenamiento de LLMs en producción
Para equipos entrenando modelos grandes, un 24% de mejora no es incremental. Es la diferencia entre poder hacer más experimentos con el mismo presupuesto de cómputo o reducir el tiempo de iteración de semanas a días.
Lo interesante es que CODA no requiere cambiar la arquitectura del modelo, solo la implementación de los kernels. En principio, un modelo existente puede beneficiarse de CODA recompilando los kernels sin modificar el código del modelo en sí. Si eso se confirma en la implementación práctica (el paper es reciente), la adopción puede ser bastante fluida.
Para compañías que entrenan en infraestructura propia o cloud, la reducción de tiempo de cómputo se traduce directamente en costo. A nivel de inferencia, la historia es distinta: ahí FlashAttention y quantization tienen más impacto porque los bottlenecks son diferentes. Pero para entrenamiento, donde la memoria y el tiempo de GPU son el costo dominante, optimizaciones como esta tienen peso real. En en modelos como Claude profundizamos sobre esto.
Desde el lado de donweb.com y cualquier operación que use GPU cloud para fine-tuning o entrenamiento, una mejora del 24% en eficiencia reduce directamente la factura de cómputo, que en trabajos intensivos puede dominar el costo operativo del proyecto.
El futuro de las optimizaciones de kernels en IA
Hay una tendencia clara acá: la optimización de LLMs se está moviendo hacia abstracciones de alto nivel que permiten expresar qué querés hacer, y dejar que un compilador (o un LLM) genere los kernels optimizados. CODA es parte de esa tendencia, junto con Triton de OpenAI y sistemas similares.
El detalle de que los kernels generados por LLMs funcionaron igual que los escritos a mano en los benchmarks de CODA es relevante. Sugiere que la abstracción es lo suficientemente expresiva como para que un modelo de lenguaje pueda trabajar con ella efectivamente. Si eso escala, el ciclo de desarrollo de kernels optimizados podría acortarse de semanas a horas.
Dicho esto, CODA no reemplaza quantization ni pruning. Son herramientas que atacan problemas diferentes: CODA optimiza la eficiencia de cómputo de operaciones existentes; quantization reduce la precisión numérica para bajar memoria y FLOPS; pruning elimina parámetros. En la práctica, se pueden combinar.
Errores comunes al interpretar este tipo de optimizaciones
Asumir que aplica igual a inferencia y a entrenamiento
Los benchmarks del paper son de entrenamiento. En inferencia, el perfil de operaciones es diferente y los bottlenecks también. Una mejora del 24% en entrenamiento no se traduce necesariamente en la misma mejora en inferencia. Evaluá en tu caso concreto antes de proyectar números.
Creer que el 24% aplica a toda la GPU sin distinción
El 24% es promedio para sequence lengths 128-1024. Si tu caso de uso es sequence length 4096 o más (modelos de contexto largo), el beneficio va a ser distinto. La proporción de tiempo en operaciones memory-bound cambia con el sequence length.
Ignorar el costo de compilación
Los sistemas GEMM-epilogue requieren compilar los kernels optimizados. Si usás modelos con shapes dinámicas o muchas configuraciones distintas, el overhead de compilación puede comerse parte del beneficio de runtime. Triton tiene este problema también; CODA presumiblemente lo tiene. Ya lo cubrimos antes en en los modelos GPT modernos.
Preguntas Frecuentes
¿Qué es CODA en optimización de transformers?
CODA es una técnica que reescribe los bloques de un transformer como programas GEMM-epilogue, fusionando operaciones memory-bound como LayerNorm, activaciones y sumas residuales dentro de los kernels de multiplicación de matrices. Esto evita múltiples roundtrips a VRAM y mejora el uso del hardware GPU. El paper que la describe fue publicado en mayo de 2026.
¿Cómo reduce CODA el consumo de memoria en LLMs?
CODA no reduce necesariamente la memoria total que ocupa el modelo, sino los movimientos de datos entre registros, caché y VRAM durante la ejecución. Al mantener los tiles de salida GEMM on-chip y ejecutar operaciones epilogue mientras los datos están en registros, elimina escrituras y lecturas intermedias a VRAM. El resultado es menos latencia, no menos memoria utilizada en total.
¿Cuánto mejora el rendimiento con GEMM-epilogue?
El paper reporta una mejora promedio del 24% para sequence lengths de 128 a 1024 en tiempo de entrenamiento. La mejora varía según el sequence length: es mayor en contextos cortos donde las operaciones memory-bound representan una fracción más alta del tiempo total. Los benchmarks incluyen kernels escritos por humanos y kernels generados por LLMs, con resultados comparables en ambos casos.
¿Por qué es importante fusionar operaciones en GPU?
Las GPUs modernas tienen una diferencia enorme entre la velocidad de cómputo (FLOPS) y la velocidad de acceso a VRAM (ancho de banda de memoria). Las operaciones compute-bound como GEMM aprovechan bien los FLOPS. Las operaciones memory-bound como LayerNorm pasan la mayor parte del tiempo moviendo datos y usan el hardware de forma ineficiente. Fusionarlas dentro de una GEMM hace que el hardware se utilice de forma más pareja y reduce el tiempo total.
¿Cómo se aplica CODA al entrenamiento de transformers?
CODA requiere que los kernels del modelo estén escritos usando las abstracciones GEMM-epilogue que el sistema define. Una vez expresadas las operaciones en esa forma, un compilador genera kernels optimizados que ejecutan todo en un solo pase. El paper muestra que esto aplica tanto al forward pass como al backward pass (gradientes), cubriendo prácticamente toda la computación que no es atención.
Conclusión
CODA resuelve un problema real que cualquiera que haya profiled el entrenamiento de un transformer reconoce: las operaciones memory-bound que representan 30-50% del tiempo de entrenamiento y que, hasta ahora, se optimizaban de forma ad-hoc o no se optimizaban. La abstracción GEMM-epilogue le da un marco sistemático a esas optimizaciones.
Un 24% de mejora promedio en entrenamiento es suficiente para que los equipos que entrenan modelos grandes la evalúen seriamente. No es una bala de plata (la atención sigue fuera del scope, el overhead de compilación existe, y los números a sequence lengths largas son menos claros), pero el enfoque es sólido y el potencial de que LLMs generen los kernels automáticamente es uno de los aspectos más interesantes de los próximos meses.
Si trabajás con entrenamiento de modelos en escala, vale la pena seguir el paper y ver cómo evoluciona la implementación en frameworks como ROCm Composable Kernel y las implementaciones de CUDA.