AISubHub/Notícias de IA
Desenvolvedores

Análise aprofundada · Cerca de 4 min de leitura

Duas estratégias KV do vLLM tratam gargalos diferentes

AWS contrapõe envio push e reutilização bidirecional, sem somar ganhos de testes distintos.

Data da fonte
Publicado aqui
Fonte verificada

Duas guias de 19 de outubro discutem cache KV no vLLM desagregado. Reunimos alternativas de transferência, não duas acelerações acumuláveis ou novas versões dos modelos avaliados.

Ouça as notícias

Ouça este artigo ou continue ouvindo as notícias.

Duas estratégias KV do vLLM tratam gargalos diferentes

Preparando a leitura…

Voz do dispositivo

O navegador ou dispositivo processa a voz. O AISubHub não envia o texto a uma API de áudio. As vozes e a reprodução com a tela bloqueada variam conforme o dispositivo.

Ao continuar, uma frase curta pode se repetir.

Resumo

  • Push relata até três vezes melhor TTFT e 30% melhor TPOT para Qwen3-32B com um nó por fase em P5en/EFA.
  • Transferência bidirecional relata até 1,6 e 3,3 vezes melhor TTFT para Qwen3-32B e GLM-5-FP8 em outras condições de cache.

Mesma arquitetura não significa mesmo teste

Prefill processa o prompt e constrói KV; decode usa esse estado para gerar tokens. Separar os motores permite escala independente, mas exige transferência. Os guias usam NIXL e EFA em hardware compatível para mover memória de dispositivo sem passar pelo host. As funções nasceram em Trainium e foram contribuídas como independentes do acelerador; os números apresentados usam GPU P5en. Nem toda instância tem suporte à memória direta. As otimizações tratam esperas distintas: preparar a entrega de um pedido e recalcular contexto num turno posterior.

Push antecipa a coordenação

Pull espera o prefill, encaminha metadados pelo roteador e prepara a leitura em decode. Push reserva e registra destinos enquanto prefill calcula. O produtor combina registro e cálculo concluído em qualquer ordem, e uma thread de fundo prepara descritores e envia NIXL WRITE. Decode espera todas as notificações previstas antes de usar KV. Retirar a preparação do laço de decode reduz interferência. Ambos usam NixlPushConnector. O custo é escolher o nó decode antes; pull pode esperar o fim do prefill para considerar a carga.

Reuso entre turnos precisa de estado retido

O modo bidirecional preserva KV do prompt e resposta para prefill recuperar no turno seguinte. O roteador mantém posições por conversation_id, não tensores. A retenção padrão é 480 segundos, fixa e não renovada; após expirar, volta-se ao prefill normal. O limiar padrão é 64 tokens reutilizáveis: menos são recalculados, a partir dele pode haver transferência. AWS exige vLLM 0.21.0 ou posterior, NixlConnector, bidirectional_kv_xfer nos dois servidores e roteador adequado. Uma configuração isolada não é uma implantação completa.

Separe as duas referências experimentais

Push usou Qwen3-32B, um nó por fase, P5en/EFA, 128 tokens de saída e cache de prefixo desligado em decode. A oito pedidos por segundo e entrada 16k, TTFT foi cerca de 1.744 contra 540 ms; sob carga alta, TPOT foi 10,4 contra 7 ms. Carga leve e prompts curtos quase empataram. O teste bidirecional desligou cache em prefill para simular perda local: Qwen em 24k foi 778 contra 460 ms, GLM em 20k, 2.334 contra 702. Isso sustenta até 1,6 e 3,3 nesse experimento, não ranking universal.

Análise: escolher política e validar serviço

O guia push mantém pull para reuso bidirecional ou escolha tardia de decode; os ganhos não devem ser multiplicados. Sugerimos medir intervalos reais entre turnos, sobreposição e carga, registrando TTFT, latência por token, vazão, memória e expiração. Desligar cache serve à reprodução desse teste, não é conselho geral para produção. Repetições, metadados antigos e isolamento de conversas exigem testes operacionais. São recomendações nossas; não implantamos nem medimos contas. A utilidade é decidir entre coordenação, reuso e roteamento com condições claras, não garantir velocidade para qualquer aplicação.

Por que importa

A escolha depende de coordenação por pedido ou recálculo entre turnos, além de memória, rede e roteamento.

Limites e disponibilidade

São medições AWS, não testes nossos. Não se multiplicam fatores nem se criam cotas pessoais ou preços fixos.

Fontes e evidências

AWS Machine Learning Blog · vLLM transfer guide

Data da fonte: 19 de out. de 2026 · Fonte verificada: 20 de out. de 2026

AWS Machine Learning Blog · vLLM transfer guide

Data da fonte: 19 de out. de 2026 · Fonte verificada: 20 de out. de 2026

Conteúdo editorial com apoio de IA, verificado em fontes primárias. Alegações dos fornecedores são atribuídas; inclusão não é recomendação.