O mais recente blog técnico da NVIDIA mostra como acelerar a inferência de mixture-of-experts (MoE) em um DGX Spark. O modelo de teste é o Ling-3.0-flash da Ant Group inclusionAI, um MoE de 124 bilhões de parâmetros com 5,1 bilhões de parâmetros ativos. A NVIDIA combinou três otimizações: um novo backend de kernel MoE, uma camada de saída FP8 e decodificação especulativa integrada. Em todas as 1.319 questões do GSM8K, o throughput de decodificação aumentou 42,5% sem alteração de precisão estatisticamente detectável. Então, por que isso é relevante para os Desenvolvedores? O DGX Spark é um sistema de desktop, não um nó de data center. Os resultados da NVIDIA mostram um MoE de 124B atendendo a solicitações de usuário único mais rapidamente nessa caixa de mesa. A publicação técnica também mostra onde o tempo de decodificação do MoE é gasto e como reduzi-lo. TL;DR Tamanho: Ling-3.0-flash-fp4: 124B total, 5.1B ativo por token; 256K de contexto nativo. Executa em: Um NVIDIA DGX Spark (GB10, 128 GB de memória unificada, 273 GB/s), tamanho de lote um. Desempenho: Três otimizações combinadas elevam o throughput de decodificação do GSM8K de 37,81 para 53,89 tokens/s. Melhor: +42,5% de throughput e -24,5% de latência média, com precisão estável (96,89% vs 96,82%). Defasagem: Ganhos sintéticos (+185,1%) diminuem no GSM8K à medida que a aceitação MTP cai de 3,90 para 2,68. Por que a decodificação MoE no DGX Spark é limitada pela memória? O DGX Spark é o sistema de desktop da NVIDIA construído no Superchip GB10 Grace Blackwell. Ele oferece 128 GB de memória unificada e 273 GB/s de largura de banda de memória. O pico de computação é de até 1 petaFLOP de FP4 esparso. A NVIDIA o classifica para inferência em modelos de até 200 bilhões de parâmetros. Na publicação técnica da NVIDIA, a equipe da NVIDIA perfilou o Ling-3.0-flash-fp4 com tamanho de lote 1. A decodificação foi limitada pela memória: a leitura dos pesos do modelo impulsionou o tempo de execução. Duas operações se destacaram: o cálculo do MoE e o cabeçalho LM que pontua o vocabulário. Isso aponta para duas alavancas: mover menos bytes por etapa de decodificação e gerar mais tokens por rodada de verificação. A linha de base seguiu a receita oficial W4A8. Ele usou kernels MoE FlashInfer MXFP4, GEMM denso CUTLASS e um caminho de cabeçalho LM FP32. Em um teste sintético de 32K de entrada e 2K de saída,
Fonte: MarkTechPost
Publicado em 2026-11-03