Radar · 23/07/2026 · ocurrido el 21/07/2026

Dos papers convergen: la memoria del optimizador es el cuello de botella en MoE a escala de billones

Dos papers publicados en Hugging Face Daily Papers (22-23 julio 2026) abordan el mismo cuello de botella desde dos perspectivas. SLAI T-Rex documenta el post-entrenamiento completo de DeepSeek-V4, un MoE de billones de parámetros, en un cluster Ascend NPU SuperPOD: presión de memoria severa, comunicación sin superposición, kernels ineficientes. “Where Should Optimizer State Live?” cuantifica el problema de raíz: en un MoE de 6,78 mil millones de parámetros, AdamW acumula 50,6 GB de estado del optimizador para actualizar 12,6 GB de pesos. El estado del optimizador es la partida más grande en el presupuesto de memoria.

Por qué te importa: como contábamos el 22 de julio, AMD ha invertido 5 mil millones y 2 GW de GPUs en Anthropic. Este es el lado técnico de esa inversión. Entrenar modelos a escala de billones requiere más que comprar chips: la memoria que necesita el algoritmo de entrenamiento para rastrear gradientes crece más rápido que los parámetros mismos. SkewAdam, el optimizador del segundo paper, asigna precisiones diferentes a las tres componentes de un MoE (backbone denso, expertos, router) según sus estadísticas de gradiente. Reduce el 97,4% del estado del optimizador: de 50,6 GB a 1,29 GB. La memoria pico baja de 81,4 GB a 31,3 GB, permitiendo el entrenamiento de MoE de miles de millones de parámetros dentro del presupuesto de una GPU de 40 GB. Para quienes construyen modelos o evalúan restricciones de infraestructura, es el detalle que separa un cluster en funcionamiento de uno paralizado.

En detalle

El problema del estado del optimizador explica por qué entrenar modelos grandes es tan costoso. Cuando entrenas un modelo con AdamW (el optimizador estándar para LLM), el algoritmo no conserva solo los pesos: también mantiene una copia de los gradientes anteriores (primer momento) y una estimación de su varianza (segundo momento). Por cada parámetro se necesitan dos valores adicionales en memoria, más el parámetro mismo. En un modelo denso esto duplica o triplica la memoria necesaria. En un MoE el problema es más sutil.

Un MoE tiene tres poblaciones de parámetros con características muy distintas: el backbone denso (pequeño pero actualizado en cada paso), los expertos (grandes pero activados raramente) y el router (diminuto pero crítico para el enrutamiento). AdamW los trata a todos igual, asignando a cada uno la misma cantidad de estado. El paper “Where Should Optimizer State Live?” parte de una observación: las estadísticas de gradiente de estas tres poblaciones son tan diferentes que tratarlas uniformemente es un desperdicio.

SkewAdam asigna precisiones diferentes a las tres componentes. El backbone denso recibe estado a precisión completa, los expertos reciben estado a precisión reducida, el router recibe un tratamiento intermedio. El resultado, medido en un MoE de 6,78 mil millones de parámetros: el estado del optimizador pasa de 50,6 GB a 1,29 GB, una reducción del 97,4%. La memoria pico total baja de 81,4 GB a 31,3 GB, permitiendo el entrenamiento dentro del presupuesto de una GPU de 40 GB sin pérdida medible en la perplejidad de validación.

El paper de SLAI T-Rex aborda el problema desde el otro lado: no el optimizador, sino la infraestructura. El post-entrenamiento completo de DeepSeek-V4 en un cluster Ascend NPU SuperPOD requiere gestionar presión de memoria, overhead de comunicación y kernels ineficientes. El paper documenta la optimización end-to-end en hardware no-NVIDIA, un detalle importante porque el mercado de compute se está expandiendo más allá de CUDA.

Los dos papers convergen en un punto: a escala de billones de parámetros, la memoria es el cuello de botella principal, más que la potencia de cálculo bruta. El estado del optimizador es la partida más grande en el presupuesto, y distribuirlo bien (con precisión diferenciada o con arquitecturas de sistema rediseñadas) es lo que hace que un cluster funcione en lugar de pararse.

Qué queda abierto. SkewAdam se prueba en un MoE de 6,78 mil millones de parámetros, no billones. La escalabilidad de la precisión reducida a escala real es una pregunta abierta. El paper de SLAI T-Rex es una práctica de ingeniería documentada en hardware específico (Ascend), no un resultado generalizable a cualquier cluster. Ambos papers son preprints en Hugging Face, sin revisión por pares al 23 de julio de 2026.

Escribe para buscar en curso, playbooks, skills, papers…