Nestor: esparsidade aninhada na atenção supera MoE em custos iguais

O mixture-of-experts já se tornou há tempos a base padrão dos grandes modelos de linguagem: em cada passagem direta, apenas uma pequena parte dos pesos é ativada. A equipe da Universidade de Hong Kong e da Berkeley propõe adicionar uma segunda camada dessa economia. Tianzhe Chu, Druv Pai e Yi Ma descreveram a arquitetura Nestor, na qual a computação condicional está embutida no operador de atenção e se aninha dentro da esparsidade do MoE.

Segundo os dados dos autores, com o mesmo custo computacional e o mesmo nível de esparsidade, o Nestor apresenta qualidade superior no pré-treinamento de modelos de linguagem em comparação ao transformer MoE clássico. O artigo foi publicado no arXiv em 22 de outubro de 2026 (2610.31818), com código e checkpoints disponibilizados.

Onde se esconde a segunda esparsidade no transformer

No transformer MoE convencional, a esparsidade existe em apenas um lugar. O operador MoE generaliza o perceptron multicamadas do transformer clássico: o roteador escolhe quais especialistas vão processar o token, enquanto os demais pesos ficam ociosos nessa passagem. O bloco de atenção, por sua vez, permanece denso.

Os autores do Nestor seguem uma lógica simétrica. Eles introduzem um mecanismo de computação condicional que generaliza o operador de atenção, e não o MLP. O resultado são dois eixos independentes de economia. Eles se combinam de forma hierárquica, ou seja, se aninham um dentro do outro — daí o nome. Um único transformer passa a ter esparsidade tanto na parte de atenção quanto na parte de MoE, e não apenas em uma delas.

A comparação foi construída com cuidado: os modelos são colocados em pé de igualdade quanto ao custo computacional e ao nível de esparsidade. Isso elimina a objeção mais óbvia, de que o ganho seria obtido à custa de FLOPs adicionais ou de um número maior de parâmetros ativos.

Fine-tuning em contexto longo e novos domínios

A parte mais prática do trabalho envolve o continual pretraining, isto é, a continuação do pré-treinamento de um modelo já pronto. Para laboratórios e empresas, essa é uma rotina comum: o modelo base costuma ser estendido para contextos mais longos ou ajustado a um novo domínio específico.

De acordo com os resultados dos autores, o Nestor supera os MoE convencionais nesse quesito:

• adapta-se de forma mais eficiente a contextos mais longos;
• migra de forma mais eficiente para novos domínios;
• esquece menos os domínios antigos.

Esse último ponto merece atenção especial. O esquecimento catastrófico continua sendo o principal preço pago pelo fine-tuning, e uma arquitetura que reduz esse custo sem recorrer a truques adicionais, como buffers de replay, interessa a todos que conduzem modelos por várias etapas de treinamento.

Os autores também verificaram o comportamento em escala. As vantagens se mantêm com o aumento do tamanho do modelo, do volume do dataset e do comprimento do contexto. Para ideias arquiteturais, esse é o principal teste: muitas melhorias parecem promissoras em modelos pequenos e desaparecem em modelos grandes.

O que se sabe sobre o trabalho

• Nome da arquitetura: Nestor (nested sparsity).
• Autores: Tianzhe Chu, Druv Pai, Yi Ma; afiliação informada na página do artigo — The University of Hong Kong.
• Ideia: um mecanismo de computação condicional que generaliza o operador de atenção, de forma análoga ao que o MoE faz com o MLP.
• Relação com o MoE: as esparsidades se aninham hierarquicamente uma dentro da outra.
• Pré-treinamento: ganho em relação ao transformer MoE convencional, com o mesmo custo computacional e o mesmo nível de esparsidade.
• Continual pretraining: melhor adaptação a contextos longos, transição mais eficiente para novos domínios, menos esquecimento dos antigos.
• Escalabilidade: o efeito se mantém com o crescimento do modelo, dos dados e do contexto.
• Materiais: código e checkpoints no repositório GitHub Ma-Lab-Berkeley/Nestor, com página do projeto em ma-lab-berkeley.github.io/Nestor.

O que fazer com isso na prática

Por enquanto, trata-se de um artigo acadêmico sem adoção em modelos de produção, e na página do Hugging Face Daily Papers ele tem apenas um voto. Mas o material é aberto, o que significa que a ideia pode ser verificada sem necessidade de contato com os autores. Equipes que treinam seus próprios modelos MoE podem pegar os checkpoints e o código para comparar o Nestor com sua arquitetura base em tarefas de extensão de contexto e adaptação de domínio — justamente onde o maior efeito é relatado.

Para equipes de infraestrutura, existe uma questão separada: como esse segundo eixo de esparsidade vai se comportar em kernels reais e em treinamento distribuído. O ganho em igualdade de custo computacional, na teoria, não garante ganho de tempo em um cluster, enquanto não existirem implementações otimizadas para o roteamento de atenção. Se tais implementações surgirem, o MoE deixará de ser sinônimo de MLP esparso, e o espaço para experimentação arquitetural se ampliará consideravelmente.