HOPE, el método de Amazon que poda expertos en LLMs

Qué es HOPE y por qué importa si sirves modelos MoE

El 95% de la memoria de un modelo como Qwen3.5–122B la ocupan expertos que casi nunca se activan: de sus 256 expertos por capa, solo 8 se usan por token. Ese desperdicio es el cuello de botella que ataca HOPE (Higher–Order Pruning of Experts), un método de poda de segundo orden que Amazon publicó en su blog de Hugging Face y que promete recortar hasta la mitad de los expertos sin destruir la calidad del modelo.

Para un founder que sirve modelos abiertos en su propia infraestructura, esto no es un detalle académico. La memoria de GPU es el costo dominante de la inferencia, y cada experto que se queda en disco o en VRAM es dinero que no genera valor.

El problema: expertos que ocupan memoria pero casi nunca se usan

Los modelos de arquitectura Mixture-of-Experts (MoE) lograron escalar los LLM a cientos de miles de millones de parámetros sin disparar el cómputo por token. La trampa es que todos los expertos deben residir en memoria en el momento de la inferencia, aunque la gran mayoría esté inactiva.

En Qwen3.5–122B, con 256 expertos en cada una de sus 48 capas MoE, los expertos MLP concentran el 95% de la huella de memoria de parámetros de ~250 GB. Y sin embargo, para cualquier token dado solo se activan 8 expertos por capa.

La poda de expertos es una de las correcciones más directas: borrar permanentemente los expertos menos útiles. Evita los problemas de latencia de cargar y descargar expertos de forma dinámica, no requiere entrenamiento y se combina con cuantización. La dificultad está en decidir cuáles eliminar sin romper el modelo.

Cómo funciona la poda de segundo orden

Los métodos de poda existentes (primer orden) puntúan cada experto de forma independiente: le asignan un score escalar de importancia y cortan los menos importantes capa por capa. Asumen que la contribución de cada experto es independiente de las demás.

En la práctica, los expertos forman grupos cooperativos. Se observan clusters de expertos coactivados de manera consistente, y trabajos independientes mostraron que esa cooperación es una propiedad estable de los MoE. Si eliminas el experto A, que coopera con el experto B —que sí es muy importante—, desarmas un grupo entero con una sola decisión. Los métodos de primer orden no ven esto, porque puntúan A y B por separado.

HOPE define una función de error de poda que, al expandirse, genera términos cruzados entre pares de expertos. Esos términos de interacción son justo los que los métodos de primer orden descartan. El método los resuelve como un programa cuadrático sobre un conjunto de calibración, con una relajación continua que luego se redondea a soluciones binarias.

El costo práctico es bajo: HOPE necesita el mismo pase de calibración que cualquier otro método de poda, y lo único que agrega es resolver el programa cuadrático, que según el equipo tarda 1 a 2 segundos por capa. El tiempo de calibración sigue dominando el proceso.

Qué resultados obtuvo frente a REAP y otros métodos

El equipo evaluó HOPE con 3 modelos (Qwen3.5–122B, Qwen3.5–35B y GLM-4.5–Air), 2 datasets de calibración (Evol-CodeAlpaca y trayectorias de SWE-Bench Verified) y benchmarks como Tulu3 y SWE-Bench Pro. Lo comparó contra 4 baselines de primer orden: REAP, MAN, EAN y Frequency.

• Ranking promedio: HOPE logró el mejor rank medio (2,07 sobre 5 métodos), con la mayor tasa de primeros puestos (39% de las condiciones) y de top-2 (67%).
• Poda agresiva: al 50%, su rank promedio mejora a 1,58 frente a 2,42 del siguiente mejor método, REAP. La ventaja crece justo cuando más se rompen los vínculos de cooperación.
• Código agéntico: en Qwen3.5–35B-A3B con 50% de poda, HOPE alcanzó 42,3 en SWE-Bench Pro, igualando al modelo sin podar (41,8), mientras REAP cayó a 36,2, una regresión del 13%.

La conexión con REAP es reveladora: la diagonal de la matriz de HOPE reproduce casi perfectamente los rankings de importancia de REAP (correlación de Spearman cercana a 1). Es decir, toda la mejora viene de los términos de interacción fuera de la diagonal. HOPE sacrifica algunos expertos individualmente valiosos para preservar clusters cooperativos, y los benchmarks validan que ese intercambio conviene.

Vale un matiz honesto: en tasas bajas de poda (10–20%), métodos de primer orden como REAP y MAN a veces son competitivos. Y HOPE poda cada capa de forma independiente, sin considerar interacciones entre capas.

Cómo probarlo en tus propios modelos

El equipo liberó un paquete con tres pasos: calibrar, resolver y podar. Fue probado en Qwen3, Qwen3–Next, Qwen3.5 y GLM-4.5, y el checkpoint resultante es un modelo estándar de Hugging Face, más chico en disco y en memoria, sin cambios en las definiciones de vLLM o SGLang.

El código está en github.com/awslabs/HOPE y el paper en arXiv (2609.18916).

¿Qué significa esto para tu startup?

Si sirves modelos MoE abiertos, la poda de expertos es una palanca de costos que no requiere reentrenar nada. La documentación de vLLM para compresión de MoE con REAP reporta que Qwen3–30B-A3B pasa de 56,93 GiB a 29,92 GiB al podar 50% de los expertos, con una recuperación del 99,8% en la tarea gsm8k_platinum. Ese mismo modelo, sin podar, ocupa casi el doble de VRAM. Y el proyecto llm-d reportó que sirvió el modelo abierto GLM 5.2, de aproximadamente 753.000 millones de parámetros, con costos 5 a 10 veces menores por token que APIs comerciales equivalentes.

Dos acciones concretas:

• Prueba podar 40–50% antes de comprar más GPUs. Es el rango donde HOPE muestra su mayor ventaja y donde el ahorro de memoria habilita contextos más largos, razonamiento más profundo y más llamadas a herramientas. Corre la calibración sobre datos que se parezcan a tu tráfico real, no sobre un dataset genérico.
• Cuida el dataset de calibración como si fuera parte del producto. La propia documentación de vLLM advierte que si las muestras de calibración omiten ciertos temas, expertos relevantes para esos temas se marcan como irrelevantes y se eliminan. Si tu caso de uso es código o agentes, calibra con código o trayectorias de agentes.

Y no te fíes solo del benchmark ajeno: mide con tus propias tareas antes de desplegar. Un modelo podado puede igualar o incluso superar al original en tareas específicas, pero esa ganancia depende de que la calibración esté alineada con lo que tú necesitas.