A equipe da LMSYS divulgou um conjunto de dados de otimização do lado do servidor para o DeepSeek-V4-Pro, testado na plataforma H20 e comparado com a B300 da Nvidia. Os autores são Tianyu Zhang, Yusong Gao e Yun Zhang, e todo o trabalho roda sobre o framework de código aberto SGLang.
Primeiro, dois números centrais. Na fase de prefill, a configuração PP2-CP8-TP8 com contexto de 4K atinge 16900 tokens por segundo; já com PP4-CP8-TP8 em contexto longo de 512K, o throughput sobe para 25860 tokens por segundo, e processar 1 milhão de tokens leva 43,7 segundos. Na fase de decodificação, em cenário de baixa latência, um único lote na H20 entrega 271 tokens por segundo, contra 383,7 na B300 — uma razão de 1,42 vez.
Para cenários de alto throughput há outro conjunto de configurações. DP32-EP32, com contexto de 4K e 32 requisições simultâneas, atinge 703,15 tokens por segundo por GPU; DP16-EP16 é ainda mais alto, com 759,73. Com contexto estendido a 1 milhão de tokens, cada GPU ainda entrega de 66 a 67 tokens por segundo.
O que significa esse 1,42 vez
A H20 é a versão que a Nvidia criou para atender às regras de exportação do mercado chinês, e a distância de poder de processamento em relação à B300, no papel, é bem mais que um degrau. Reduzir a diferença de decodificação em lote único a 1,42 vez mostra que o gargalo não está no pico de computação, mas na largura de banda de memória, no overhead de comunicação e no tempo ocioso do escalonamento.
Isso também explica a composição da lista de otimizações. Os maiores ganhos não vêm da precisão dos operadores: a fusão do caminho crítico de quantização, que combina a ativação SwiGLU com a quantização e elimina buffers intermediários, eleva o throughput em 44,0% sozinha; substituir o produto escalar dos pesos de vocabulário por uma operação GEMM transposta reduz leituras repetidas sob alta concorrência e acrescenta mais 22,8%; reorganizar o balanceamento de carga conforme a preferência real dos especialistas, medida empiricamente, soma outros 13,5%.
Do lado do prefill, a lógica é a mesma. Fundir 7 operadores em 3 grupos de execução reduz a latência do primeiro token em 3,5%; extrair formatos de alta frequência de histogramas reais de roteamento em produção e otimizar especificamente os dois grupos de pesos de especialistas reduz mais 11,35% na latência do primeiro token. Esse último ponto é particularmente pragmático porque não assume distribuição uniforme das requisições, mas segue o padrão real e assimétrico do tráfego ao vivo.
Há ainda uma substituição estrutural: na fase de prefill, usa-se paralelismo de tensor em vez de paralelismo de especialistas para dividir o MoE. A razão é que a carga desigual entre especialistas gera longas caudas de latência, e vale pagar um pouco mais de comunicação para cortar essa cauda.
Memória é o que se troca por capacidade
Mais rígida que a velocidade é a restrição de capacidade. Duas medidas visam diretamente a memória: o Humming MXFP4AFP8 armazena os pesos dos especialistas em MXFP4 combinado com ativação FP8 online, ganhando de 1,71 a 4,47 vezes de capacidade em relação à linha de base; a compressão de KV C128 online mantém um estado agregado compacto em vez de um estado indexado item a item, contribuindo com 2,268 vezes. Somadas, as duas chegam a uma faixa de 3,88 a 10,14 vezes.
Para quem opera a infraestrutura, essa é a conta mais fácil de fazer. Na mesma máquina com 8 GPUs, o número de requisições simultâneas ou o comprimento de contexto suportado se multiplica, e o custo por token cai na mesma proporção. Quando não é possível aumentar o número de GPUs, o multiplicador de capacidade é a única variável que ainda está sob controle da equipe.
A contribuição do DSpark é contabilizada à parte: ao coordenar a execução-alvo e as etapas de verificação entre estágios do pipeline, o tempo de saída por token melhora de 74,8% a 78,0%.
Traduzindo isso em custo fica mais claro. Supondo que o custo mensal de posse de uma máquina com 8 GPUs H20 se mantenha fixo, um multiplicador de capacidade de 4 vezes permite atender à mesma fatura o quádruplo de concorrência, e o custo de máquina por token cai para cerca de um quarto (é uma conta aproximada, que ignora o processamento extra gerado por contextos longos e as oscilações de roteamento). Para provedores que cobram por token e cuja margem já está espremida pela guerra de preços, essa margem de manobra costuma valer mais do que trocar de geração de GPU — ainda mais quando nem sempre é possível conseguir GPUs novas.
O que se entrega, no fim, é uma tabela de configurações
O resultado final deste trabalho não é uma única solução ótima, mas uma tabela de configurações organizada por cenário: no prefill, usa-se PP2 até 32K de contexto e PP4 a partir de 128K; na decodificação, busca-se baixa latência com PP2-TP8, alto throughput com DP32-EP32, e o DP16-EP16 fica como referência de eficiência.
Essa forma de apresentar os dados já é, em si, um sinal. Rankings de benchmark querem um único número; ambientes de produção precisam saber como é o próprio tráfego e em qual faixa ele se encaixa. Para equipes que só têm H20 disponível e ainda assim precisam colocar em produção um modelo de 1,6 trilhão de parâmetros, essa tabela é mais útil do que qualquer recorde isolado de pico.
Fontes: blog técnico da LMSYS, CocoLoop, documentação do projeto SGLang; os números de throughput, latência e multiplicador de capacidade vêm da tabela de configurações medida publicada nesse blog, e os dados comparativos da B300 têm a mesma origem.