A equipe do framework de inferência de código aberto vLLM, em parceria com a Inferact, publicou em 7 de outubro um blog técnico apresentando um conjunto de otimizações de inferência desenvolvidas para o DeepSeek-V4.1-Flash. Em testes que simulam cargas de trabalho de agentes, a velocidade aumentou 1,9 vez em cenários de baixa concorrência; ao limitar a velocidade de saída por usuário a 150 tokens por segundo, a taxa de transferência total subiu 5,3 vezes.
A carga de teste utilizada foi o benchmark AgentX da SemiAnalysis, que a equipe considera representativo de cenários de serviço baseados em agentes: diálogos de múltiplas rodadas, contexto longo e afinidade de sessão que mantém a taxa de acerto do cache de prefixo. A configuração de baixa latência usa paralelismo de tensores em 4 placas com FlashInfer; a de alta taxa de transferência usa paralelismo de dados duplo com paralelismo de especialistas.
Características do próprio modelo
Segundo o blog, o V4.1 Flash adota uma arquitetura causal de codificador-decodificador com 40 camadas no total, sendo que a camada 20 é responsável por calcular o KV global usado pelo decodificador. Na fase de geração, cada token ativa cerca de 16 bilhões de parâmetros; na fase de pré-preenchimento (prefill), cerca de 8 bilhões. O cache KV global é comprimido e compartilhado entre as camadas, ocupando apenas cerca de 890 bytes por token em precisão FP4; há ainda uma janela deslizante de KV que cobre as últimas 128 posições, armazenada em FP8 sem compressão.
Um cache tão pequeno traz uma consequência direta: ao longo de toda a execução do benchmark, não foi necessário descarregar o cache KV para memória ou disco. Em tarefas de agentes com contexto longo, esse descarregamento costuma ser uma das principais causas de lentidão na latência.
Os destaques entre as oito otimizações
A equipe listou oito mudanças, das quais algumas trazem os ganhos mais expressivos:
- Replay limitado por janela deslizante: quando há acerto no cache de prefixo, os últimos 128 tokens são recalculados diretamente, combinados com CUDA Graph, reduzindo a latência do primeiro token em cerca de 30%. Em um contexto de cerca de 100 mil tokens, essa latência cai quase 70%. Esse recurso vem ativado por padrão no V4.1 e pode ser desligado com a flag
--no-swa-bounded-replay. - Kernel de pontuação MQA esparso: até 14 a 23 vezes mais rápido que a implementação original em contexto de 512K, apenas 1,2 vez mais rápido em 8K, refletindo em cerca de 3% a 6% na decodificação de ponta a ponta.
- Atenção NVFP4: o cache KV fica 45% menor que a solução FP8 anterior, com ganho de velocidade de cerca de 1,45 vez na etapa correspondente.
- Busca em tabela Engram: com pré-busca assíncrona e páginas enormes transparentes (transparent huge pages), a busca mais rápida chega a ganhar cerca de 10 vezes em velocidade.
Outras mudanças envolvem a fusão de operadores: várias etapas do roteamento de mistura de especialistas (MoE) foram unidas em um único kernel, ficando 1,18 a 1,31 vez mais rápido em lotes médios; os kernels relacionados ao mHC no GB200 são 1,14 a 1,51 vez mais rápidos que a versão em TileLang.
Em termos de precisão, a equipe fez comparações no GSM8K e no GPQA, afirmando que a perda de qualidade é "negligível", com diferença dentro de cerca de 1,5 erro padrão. O blog não apresenta avaliações em outras tarefas.
Quanto disso é aproveitável em implantações na China
Todos esses números vêm da plataforma Blackwell da Nvidia. Devido aos controles de exportação dos EUA, é muito difícil para instituições chinesas obter placas como a GB200 e a GB300; o NVFP4 também é um formato de dados exclusivo do Blackwell, de modo que os ganhos correspondentes não podem ser reproduzidos diretamente em H20 ou em aceleradores nacionais.
A parte que pode ser transferida está principalmente nas camadas de agendamento e cache. O replay por janela deslizante, a afinidade de sessão e a ausência de descarregamento de KV são itens menos dependentes do hardware; o código já foi incorporado à linha principal do vLLM, de modo que equipes que usam o mesmo modelo conseguem esses ganhos apenas atualizando a versão. O progresso da integração de cada kernel é acompanhado pela vLLM na issue número 57448 no GitHub. Ainda não há testes de terceiros sobre o ganho real de velocidade em chips nacionais.
Fontes: blog técnico oficial do vLLM, CocoLoop, descrição do benchmark AgentX da SemiAnalysis; os dados do blog foram verificados quanto aos fatores de ganho de cada otimização, hardware de teste e configuração de paralelismo.