Nestor: la escasez anidada en attention supera a MoE con costes equivalentes

El mixture-of-experts se consolidó hace tiempo como la base estándar de los grandes modelos de lenguaje: en cada paso hacia adelante solo se activa una pequeña parte de los pesos. Un equipo de la Universidad de Hong Kong y Berkeley propone añadir una segunda capa de ese ahorro. Tianzhe Chu, Druv Pai y Yi Ma describieron la arquitectura Nestor, en la que el cómputo condicional está integrado en el operador de atención y se anida dentro de la escasez de MoE.

Según sus datos, con cómputo equivalente e igual nivel de escasez, Nestor muestra mejor calidad de preentrenamiento del modelo de lenguaje que el transformer MoE clásico. El artículo se publicó en arXiv el 22 de octubre de 2026 (2610.31818), y el código y los checkpoints ya están disponibles.

Dónde se esconde la segunda escasez en el transformer

En un transformer MoE convencional, la escasez vive en un solo lugar. El operador MoE generaliza el perceptrón multicapa del transformer clásico: un enrutador decide qué expertos procesan cada token, mientras el resto de los pesos permanece inactivo en ese paso. El bloque de atención, en cambio, sigue siendo denso.

Los autores de Nestor avanzan de forma simétrica. Introducen un mecanismo de cómputo condicional que generaliza el operador de atención, no el MLP. El resultado son dos ejes independientes de ahorro. Se combinan de forma jerárquica, es decir, se anidan uno dentro del otro, de ahí el nombre. Un mismo transformer obtiene escasez tanto en la parte de atención como en la parte MoE, y no solo en una de ellas.

La comparación está construida con cuidado: se contrastan modelos con cómputo equivalente e igual nivel de escasez. Esto descarta la objeción más obvia, que la ventaja se compre con FLOPs adicionales o un mayor número de parámetros activos.

Reentrenamiento en contexto largo y nuevos dominios

La parte más práctica del trabajo tiene que ver con el continual pretraining, es decir, la continuación del preentrenamiento de un modelo ya existente. Para los laboratorios y las empresas esto es rutina: el modelo base se extiende periódicamente a contextos más largos o se reentrena en un nuevo dominio.

Según los resultados de los autores, Nestor se desempeña mejor que los MoE convencionales en este escenario:

• se adapta de forma más eficiente a contextos más largos;
• cambia de forma más eficiente a nuevos dominios;
• olvida menos en los dominios antiguos.

Este último punto es relevante por sí mismo. El olvido catastrófico sigue siendo el principal coste del reentrenamiento, y una arquitectura que reduce ese coste sin trucos adicionales como los búferes de replay resulta interesante para cualquiera que lleve modelos a través de varias etapas de entrenamiento.

Los autores también comprobaron el escalado. Las ventajas se mantienen al crecer el tamaño del modelo, el volumen del conjunto de datos y la longitud del contexto. Para las ideas arquitectónicas, este es el examen principal: muchas mejoras se ven bien en modelos pequeños y desaparecen en los grandes.

Lo que se sabe del trabajo

• Nombre de la arquitectura: Nestor (nested sparsity).
• Autores: Tianzhe Chu, Druv Pai, Yi Ma; afiliación en la página del artículo: The University of Hong Kong.
• Idea: un mecanismo de cómputo condicional que generaliza el operador de atención, de forma análoga a como MoE generaliza el MLP.
• Relación con MoE: las escaseces se anidan jerárquicamente una dentro de la otra.
• Preentrenamiento: ventaja sobre el transformer MoE convencional con cómputo equivalente e igual nivel de escasez.
• Continual pretraining: mejor adaptación a contexto largo, transición más eficiente a nuevos dominios, menos olvido de los antiguos.
• Escalado: el efecto se mantiene al crecer el modelo, los datos y el contexto.
• Artefactos: código y checkpoints en el repositorio de GitHub Ma-Lab-Berkeley/Nestor, con una página de proyecto en ma-lab-berkeley.github.io/Nestor.

Qué pueden hacer con esto los profesionales

Por ahora se trata de un artículo académico sin implementación en modelos de producción, y en la página de Hugging Face Daily Papers tiene un solo voto. Pero el material es abierto, lo que significa que la idea se puede verificar sin negociar con los autores. A los equipos que entrenan sus propios modelos MoE les conviene tomar los checkpoints y el código y comparar Nestor con su arquitectura base en tareas de extensión de contexto y adaptación de dominio, que es justo donde se declara el mayor efecto.

Para los equipos de infraestructura queda una pregunta aparte: cómo se traducirá este segundo eje de escasez a los kernels reales y al entrenamiento distribuido. Una ventaja en cómputo equivalente, en teoría, no garantiza una ventaja en tiempo real en un clúster mientras no existan implementaciones optimizadas para el enrutamiento de atención. Si esas implementaciones llegan a aparecer, MoE dejará de ser sinónimo de MLP disperso, y el terreno para la experimentación arquitectónica se ampliará de forma notable.