Otimizando o serving do DeepSeek-V4-Pro no limite

Contexto e tese central

O LMSYS Org publicou um estudo detalhado sobre como servir o DeepSeek-V4-Pro, modelo de 1,6 trilhão de parâmetros com arquitetura Mixture-of-Experts (MoE), em GPUs NVIDIA H20 - hardware amplamente disponível, mas sem Tensor Cores nativos FP4 e com capacidade de HBM inferior à da família Blackwell. A tese central é que um modelo dessa escala não deve ser servido com uma configuração única de compromisso, mas sim com múltiplos perfis de serving, cada um otimizado para uma combinação específica de comprimento de contexto, latência, vazão e capacidade de cache KV.

Estrutura de perfis por cenário

Os autores dividem o problema em três eixos: prefill (processamento do prompt), decode de baixa latência e decode de alta vazão. Para prefill, o pipeline PP2 é preferido em contextos curtos por ter menor overhead de preenchimento e drenagem, enquanto PP4 se torna vantajoso a partir de 128K tokens, onde há trabalho suficiente para amortizar o custo do pipeline mais profundo. Para decode de baixa latência, PP2-TP8 é o perfil recomendado para produção, distribuindo pesos entre dois nós e liberando HBM para o cache KV. Para alta vazão, DP32-EP32 expande capacidade de requisições concorrentes, enquanto DP16-EP16 serve como referência de eficiência por GPU.

Otimizações de capacidade

Duas técnicas compostas ampliam a capacidade de tokens atendidos. Humming MXFP4AFP8 usa pesos de experts em MXFP4 com ativações FP8 online para reduzir a pegada de memória dos pesos. Online C128 substitui o estado auxiliar por página do cache comprimido por um estado agregado compacto, liberando HBM para o pool de KV. Combinadas, as duas técnicas elevam a capacidade para 3,88× o baseline em DP32-EP32 e 10,14× em PP2-TP8.

Otimizações de prefill

No prefill, os autores substituem MoE-EP por MoE-TP. Embora EP troque apenas tokens roteados (menos tráfego), o desbalanceamento de experts em tráfego real cria stragglers que dominam o TTFT. MoE-TP introduz comunicação mais previsível via NVLink, evitando caudas longas por rank. Coletivos de memória simétrica são fusionados e o caminho crítico do prefill é reduzido em aproximadamente 3,5% de TTFT. Ajustes específicos do Humming para as formas de roteamento reais de produção reduzem a latência dos kernels MoE em ~21% e o TTFT ponta a ponta em ~11,35%.

Otimizações de decode

Para baixa latência, o DSpark (decodificação especulativa) é estendido entre estágios de pipeline com um protocolo de execução coordenado. O DSpark otimizado reduz o TPOT de pico entre 74,8% e 78,0% em batch size 1. Para alta vazão em DP32-EP32, a etapa de refinamento é reorganizada em um GEMM transposto (+22,8% de vazão por GPU), e o balanceamento de carga de experts baseado em afinidade de roteamento medida adiciona +13,5%. A fusão SwiGLU+quantização no caminho quente do Humming melhora a vazão por GPU em 44,0%.

Resultados principais

No batch size 1, a referência H20-141GB atinge 271 tokens/s de saída, contra 383,7 tokens/s no B300 - razão de 1,42×, muito inferior à razão de ~45,6× em compute de pico. O prefill otimizado processa 1M tokens em 43,7 segundos. Em alta vazão, o DP16-EP16 atinge 4.670 tokens/s de saída por nó, com TPOT médio de 27,4 ms. A validação de precisão do Humming MXFP4AFP8 atinge 95,5% de exact-match no GSM8K1000, acima do limiar de aceitação de 95,0%.

Conclusão

Os autores enfatizam que a contribuição é metodológica: perfis de serving devem ser derivados do workload, dos SLOs e do hardware disponível, não de benchmarks isolados. O resultado transferível é uma abordagem orientada por cenário para servir modelos de fronteira sob restrições de compute, memória ou interconexão.