NVIDIA Lança Nemotron-Labs-3-Puzzle-75B-A9B: MoE Comprimido Com Até 2x Mais Throughput

A NVIDIA acaba de lançar o Nemotron-Labs-3-Puzzle-75B-A9B, uma versão comprimida do Nemotron-3-Super que entrega até 2,03x mais throughput de servidor mantendo o mesmo throughput por usuário. O modelo reduz os parâmetros totais de 120,7 bilhões para 75,3 bilhões e os parâmetros ativos de 12,8 bilhões para 9,3 bilhões — uma compressão de aproximadamente 38% no tamanho total.

Os checkpoints estão disponíveis no Hugging Face em três formatos: BF16, FP8 e NVFP4. O modelo preserva a arquitetura híbrida Mamba-Transformer MoE com 88 blocos (40 Mamba, 40 MoE, 8 de atenção).

Por que comprimir um modelo MoE?

Modelos híbridos MoE como o Nemotron-3-Super são precisos, mas caros para servir. Os parâmetros ativos, o cache KV e o estado Mamba limitam quantos usuários um nó consegue atender simultaneamente a uma dada taxa de tokens por usuário. A compressão ataca diretamente esse gargalo: reduz o peso do modelo de ~70 GB para ~44,5 GB em NVFP4, liberando memória HBM para mais requisições simultâneas.

Resultados de throughput

Em um nó com 8 GPUs B200 (NVFP4), o throughput total aumenta entre 1,60x e 2,14x em relação ao Super. O ganho é maior em cargas decode-heavy (8K/64K) e menor em cargas prefill-heavy (50K/2K), onde o processamento de prompt domina a computação.

Em 8 GPUs H100 (FP8), os ganhos são de 1,91x (50K/2K) e 1,82x (8K/64K).

O resultado mais impressionante está no contexto longo: em uma única H100 com contexto de 1 milhão de tokens, a concorrência sobe de 1 para 8 requisições simultâneas. O throughput agregado de decodificação nessa configuração é aproximadamente 4x maior que o do Super com uma única requisição.

Como funciona o Iterative Puzzle

A compressão usa o framework Puzzletron, uma busca de arquitetura neural decomposta que aplica três técnicas de poda:

• Poda de canais intermediários: dentro de cada expert roteado, os canais são ranqueados por contribuição e podados uniformemente por camada MoE.
• Redução de top-k: o número de experts para os quais cada token é roteado varia por camada, partindo do k=22 do modelo original.
• Poda de estado SSM Mamba: o tamanho do estado SSM cai de 128 para 96 canais, acelerando o kernel SSM em 1,2x a 1,3x durante a decodificação.

O diferencial está no processo iterativo: em vez de aplicar toda a compressão de uma vez, o Puzzle executa três estágios alternando compressão e recuperação por destilação de conhecimento (KD). Cada estágio recalcula os scores de qualidade contra o modelo atual, não contra o original. O resultado é um ganho médio de 0,57 pontos em 10 benchmarks comparado à compressão em passo único.

Onde a compressão dói

Nem tudo sobrevive intacto. Os benchmarks de instruction-following e tarefas agentivas são os mais afetados:

• Arena-Hard-V2: -4,2 pontos (a maior queda)
• SWE-Bench: -2,6 pontos
• RULER (256K, 512K, 1M): dentro de 1 a 2 pontos de diferença
• AA-LCR, Scale AI Multi-Challenge, TauBench Telecom: sem regressão ou ganho marginal

O paper é transparente: a recuperação por reinforcement learning (RL) teve impacto pequeno nas métricas. A maior parte da recuperação veio da destilação de conhecimento em contexto curto (recupera ~97% do Super) e da destilação em contexto longo (recupera benchmarks específicos de entrada e geração longas).

Detalhes técnicos importantes

A verbosidade — número de tokens gerados — merece atenção. Após a última iteração do Puzzle, o modelo gerava 132% dos tokens do Super. Após o pipeline completo de recuperação, caiu para 99%. Isso significa que os ganhos de throughput sobrevivem no nível de requisição: você não está recebendo mais tokens, está recebendo as mesmas respostas mais rápido.

O modelo herda o Multi-Token Prediction (MTP) do Super. Após treinamento continuado no head MTP, o comprimento médio de aceitação no SPEED-Bench (draft length 7) subiu de 3,45 para 4,34 — um ganho de 25-30%, concentrado nas posições mais profundas de draft.

A poda Mamba é uniforme por limitação dos frameworks de inferência atuais, que não suportam tamanhos de estado SSM diferentes por camada. Já a poda de dimensão latente foi abandonada porque os kernels NVFP4 MoE exigem que a dimensão latente seja múltipla de 512.

Casos de uso

• RAG com contexto ultra-longo em uma GPU: serviços de análise de documentos com 1M de contexto passam de 1 para 8 requisições simultâneas em uma única H100.
• Assistentes de código interativos: no regime 8K/64K com 100+ tok/s por usuário, um nó entrega 2,03x mais tokens (ou 2,16x mais requisições completas por minuto após ajuste de verbosidade).
• Pipelines de documentos prefill-heavy: o ganho é menor (1,60x), já que o processamento de prompt domina a computação e a compressão ajuda menos.
• Loops agentivos de engenharia de software: é preciso avaliar os -2,6 pontos no SWE-Bench contra o mix de tarefas. A recuperação por RL mirou essa capacidade e só a recuperou parcialmente.

Disponibilidade

Três checkpoints estão publicados no Hugging Face (BF16, FP8 e NVFP4). O NVFP4 não tem suporte nativo em Hopper (H100), mas é relevante para o alvo de 1M de contexto, onde a capacidade HBM é o fator limitante. A quantização NVFP4 usou calibração max (não AutoQuantize), resultando em um checkpoint marginalmente mais agressivo mas com performance similar.