Poda de expertos en MoE: parámetros activos, presupuestos de memoria y HOPE

Una razón actual para revisar la memoria de los MoE

Amazon publicó su explicación técnica de HOPE el 9 de noviembre de 2026. El artículo de investigación apareció por primera vez en septiembre. La publicación de hoy vuelve oportuna una discusión sobre la poda de expertos al desplegar modelos, sin presentar un resultado de investigación anterior como un lanzamiento nuevo.

La pregunta útil es concreta: si un modelo activa solo una fracción de sus parámetros para cada token, ¿por qué puede seguir necesitando tanta memoria?

En una capa de mezcla de expertos (MoE), un enrutador selecciona varias redes de expertos y combina sus salidas.

Los parámetros activos describen el cómputo de una ruta seleccionada. La planificación de capacidad también debe contemplar los parámetros disponibles para otras rutas, el estado de las solicitudes y las asignaciones temporales. Un experto que está inactivo para un token puede seguir ocupando memoria.

Este artículo desarrolla un ejemplo de memoria y un pequeño experimento de selección, seguidos de una propuesta de protocolo de evaluación. No presenta una reproducción local de HOPE ni una medición de rendimiento en GPU.

Separar cuatro presupuestos de memoria

Empezá con un inventario para una revisión del modelo, un formato numérico, un motor de inferencia y una carga de trabajo fijos:

Presupuesto	Qué incluye	Qué revisar
Almacenamiento del checkpoint	Pesos serializados y metadatos de cuantización	Los archivos reales, en lugar de la cantidad de parámetros indicada en el nombre del modelo
Pesos residentes	Tensores de expertos y del resto del modelo ubicados en cada dispositivo	Distribución, replicación, precisión y descarga a otra memoria
Estado de las solicitudes	Caché KV y otro estado persistente por solicitud	Longitud del contexto, solicitudes simultáneas y política de caché
Margen de memoria para la ejecución	Tensores temporales, kernels, búferes de comunicación y margen del asignador	El pico de asignación durante la carga real

Estas categorías pueden superponerse según la implementación, así que definí el límite de la contabilidad antes de sumar mediciones. No sumes la memoria reservada total de un framework a su memoria asignada: son mediciones que se superponen.

Para un ejemplo de capacidad deliberadamente inventado, supongamos 80 GiB de pesos residentes de expertos y 16 GiB para todo lo demás, con un perfil fijo de solicitudes. Eliminar la mitad de esos bytes de expertos deja:

before = 80 + 16 = 96 GiB
after  = 40 + 16 = 56 GiB
saved  = 40 / 96 = approximately 41.7%

La reducción es del 50% del almacenamiento de expertos y del 41,7% de este total hipotético. Ninguna cifra predice los tokens por segundo. Los 16 GiB restantes se mantuvieron constantes solamente para hacer explícita la aritmética; las asignaciones reales durante la ejecución pueden cambiar después de la poda.

La descarga de pesos a otra memoria y el paralelismo de expertos cambian dónde residen los pesos y cuándo se mueven. No eliminan la necesidad de almacenarlos. Del mismo modo, la capacidad recuperada puede admitir solicitudes más largas solo si el sistema de inferencia puede aprovecharla sin alcanzar otra restricción.

Los artículos sobre cuantización y caché KV y procesamiento por lotes cubren mecanismos relacionados. Un despliegue puede combinarlos, pero sus beneficios deben medirse en conjunto.

Por qué las puntuaciones independientes pueden elegir el conjunto equivocado

HOPE selecciona un conjunto de expertos para eliminar mediante un objetivo cuadrático, p^T F p, con una cantidad fija de eliminaciones. Los términos por pares influyen en la elección. Su análisis de error separa la sustitución de la renormalización; el objetivo aproximado no garantiza directamente el error total ni la calidad en las tareas. Artículo, sección 3 y apéndice A

Veamos un ejemplo aritmético independiente. Supongamos que observamos tres magnitudes de contribución sintéticas, A, B y C, en dos muestras:

Muestra	A	B	C
1	1	1	0
2	0	0	1.5

Definimos el costo de un conjunto de eliminaciones como el promedio del cuadrado de la suma de sus contribuciones. Es un objetivo ilustrativo, no un daño medido sobre un modelo.

Evaluados por separado, A y B cuestan 0,5 cada uno; C cuesta 1,125. Eliminar las dos puntuaciones individuales más bajas selecciona A y B. Sin embargo, sus contribuciones coinciden: el costo conjunto es 2. Eliminar A y C cuesta 1,625.

La diferencia surge del término cruzado de (a + b)^2. Ordenar los cuadrados individuales no permite representarlo. Esto no demuestra que A y B entiendan el mismo tema, cooperen causalmente ni deban conservarse siempre juntos.

Un ejemplo de selección que se puede ejecutar

El siguiente código usa solamente la biblioteca estándar de Python. Enumera todos los pares de este pequeño ejemplo y comprueba los resultados esperados.

from itertools import combinations

names = ("A", "B", "C")
samples = ((1.0, 1.0, 0.0), (0.0, 0.0, 1.5))


def removal_cost(indices):
    return sum(
        sum(sample[index] for index in indices) ** 2
        for sample in samples
    ) / len(samples)


individual = sorted(range(len(names)), key=lambda i: removal_cost((i,)))
independent = tuple(sorted(individual[:2]))
joint = min(combinations(range(len(names)), 2), key=removal_cost)

assert independent == (0, 1)
assert joint == (0, 2)
assert removal_cost(independent) == 2.0
assert removal_cost(joint) == 1.625

for selected in (independent, joint):
    print(tuple(names[i] for i in selected), removal_cost(selected))

Salida esperada, verificada localmente:

('A', 'B') 2.0
('A', 'C') 1.625

B y C empatan con A y C. El orden de iteración elige A y C; no hay un ganador único. La enumeración exhaustiva sirve para tres candidatos, no como propuesta de optimizador para un modelo grande. El ejemplo omite los reemplazos de enrutamiento, la renormalización y las interacciones entre capas.

El algoritmo de optimización publicado usa, en cambio, relajación continua y redondeo, sin certificar un óptimo global. También normaliza las estadísticas por pares según las cantidades de selecciones conjuntas. Nuestro ejemplo promedia sobre todas las muestras. Esas decisiones producen objetivos distintos; este ejemplo no implementa el algoritmo publicado.

Convertir la compresión en una comparación controlada

Antes de recopilar datos de calibración, dejá por escrito qué decisión debe respaldar el experimento. Por ejemplo: hacer que un modelo quepa en una configuración de dispositivos más pequeña y conserve una corrección aceptable para una carga de trabajo específica.

Separá la calibración, la selección de configuración y la evaluación final. Un conjunto de calibración dominado por tareas de programación no debería convertirse silenciosamente en la definición de comportamiento aceptable para una carga de soporte multilingüe. Conservá las tareas poco frecuentes como segmentos de evaluación identificados, en lugar de dejar que sus fallos desaparezcan dentro de un promedio.

Compararía el checkpoint original, una referencia simple de poda con puntuaciones independientes y el método por pares, con la misma cantidad de eliminaciones. Si la cuantización forma parte del despliegue, evaluaría cada candidato con esa misma precisión. Mantendría fijos el tokenizador, los prompts, la configuración de decodificación, el motor de inferencia y la secuencia temporal de solicitudes siempre que la comparación lo permita.

Medición	Pregunta propuesta para la aceptación
Corrección de las tareas por segmento	¿Qué comportamientos requeridos empeoran y en qué medida?
Llamadas fallidas a herramientas y salidas inválidas	¿La compresión rompe los contratos de ejecución?
Memoria residente y pico de memoria por dispositivo	¿El candidato cabe con un margen realista?
Tiempo hasta el primer token y tiempo por token de salida	¿Qué fase cambia bajo la misma carga?
Solicitudes completadas por unidad de tiempo	¿Se puede procesar más trabajo con el mismo objetivo de servicio?
Costo de calibración y preparación	¿Vale la pena preparar el checkpoint para el uso previsto?

Para mediciones con ruido, conservá las observaciones por solicitud y repetí las ejecuciones. Para respuestas estocásticas, compará las mismas tareas en varias muestras. Publicá la distribución y la incertidumbre en lugar de elegir la mejor ejecución.

El código de poda publicado conserva la cantidad original de expertos del enrutamiento top-k. Por lo tanto, almacenar menos expertos no implica evaluar proporcionalmente menos expertos por token. Es una razón concreta para separar el ahorro de memoria de las afirmaciones sobre velocidad.

Leer las mejoras de evaluación con su denominador

Para Qwen3.5-35B-A3B con una poda del 50%, los autores informan puntuaciones de SWE-Bench Pro de 42,3 para HOPE, 41,8 sin poda y 36,2 para REAP. Son resultados publicados por sus autores, no mediciones de este artículo. Comparación publicada

Una diferencia de 6,1 puntos frente a otro modelo comprimido responde una pregunta distinta de la mejora frente al checkpoint original. Ninguna comparación demuestra menor latencia, una mejora universal de calidad ni el resultado de usar otra distribución de calibración.

El artefacto que se publique para uso práctico debería incluir las revisiones exactas del modelo fuente y del código, la identidad del conjunto de calibración, el conjunto de eliminaciones, los hashes del checkpoint, la configuración de evaluación y los casos rechazados. Conservá el checkpoint original para poder volver atrás y probá la restauración antes de depender del artefacto comprimido.

Elegí un candidato solo después de que cumpla el objetivo de memoria y los límites de calidad de la carga de trabajo. Si ahorra memoria pero falla en un segmento esencial de tareas, la restricción del despliegue sigue sin resolverse.