AWS aposta no cache KV, mas a fatura continua dependendo do modelo

Se você roda um LLM em produção, a promessa mais importante do anúncio da AWS não é um desconto por token. É fazer com que requisições que compartilham o mesmo começo de prompt encontrem a mesma instância e reaproveitem o cache KV. Isso pode diminuir o tempo de resposta em fluxos repetitivos, mas não reduz automaticamente a tarifa do modelo nem garante uma fatura menor.

A AWS descreve a técnica como roteamento sensível a prefixo para o Amazon SageMaker Inference. A ideia é direcionar pedidos com prefixos semelhantes para recursos que já processaram aquela parte do contexto. Com isso, a infraestrutura evita recalcular uma sequência que continua igual entre chamadas.

Segundo a publicação da AWS, a estratégia reduz a latência em cenários com prefixos compartilhados. O ponto decisivo para quem paga a conta é outro: o ganho depende do padrão real de tráfego. Se cada usuário envia um prompt completamente diferente, quase não há prefixo para reaproveitar. Se a aplicação repete instruções, documentos, histórico ou ferramentas, o benefício potencial é maior.

O que mudou — e o que não mudou

O anúncio muda a forma de encaminhar solicitações dentro da infraestrutura de inferência. Ele não apresenta um novo modelo, não altera a janela de contexto e não cria um preço universal para tokens. Também não transforma qualquer carga de trabalho em uma carga otimizada para cache.

A diferença é operacional. Sem considerar o prefixo, um balanceador pode espalhar requisições entre instâncias e reduzir a chance de reutilizar estados intermediários. Com o roteamento orientado pelo prefixo, a distribuição tenta preservar essa afinidade. O resultado esperado é menos trabalho repetido e menor tempo até o primeiro token em determinadas cargas.

Isso não deve ser confundido com cache de entrada oferecido por uma API. No catálogo do OpenRouter, por exemplo, o Gemini 3.8 Flash aparece com entrada a US$ 0,75 por milhão de tokens, saída a US$ 3,75 e cache a US$ 0,075. Esses valores são tarifas de modelo e não medem o comportamento do SageMaker.

A promessa de latência não é uma promessa de economia

O anúncio pode melhorar o custo operacional de forma indireta. Se a mesma capacidade atende mais requisições, ou se o sistema precisa de menos recursos para cumprir uma meta de latência, a conta de infraestrutura pode cair. Mas essa economia precisa ser medida na implantação, porque depende de taxa de acerto do cache, tamanho dos prefixos, concorrência e distribuição dos pedidos.

A diferença importa especialmente para equipes pequenas. É fácil transformar uma redução de latência em uma previsão de economia sem separar três componentes: cobrança do modelo, custo das instâncias e custo de engenharia. O roteamento atua principalmente no segundo componente. O preço por token continua definido pelo modelo e pelo provedor usado na operação.

O DeepSeek V4.1 Flash, lançado no dia, aparece no OpenRouter a US$ 0,15 por milhão de tokens de entrada e US$ 0,60 por milhão de tokens de saída, com contexto de 1.048.576 tokens. Esses números podem ajudar na escolha do modelo, mas não comprovam que uma implantação no SageMaker terá a mesma latência ou a mesma estrutura de custo.

Para quem o recurso faz diferença

A novidade vale mais para aplicações com prefixos longos e estáveis. Assistentes corporativos que repetem políticas, manuais, instruções de sistema ou grandes blocos de contexto são candidatos naturais. Também pode ajudar fluxos agênticos nos quais várias etapas consultam o mesmo ambiente e alteram apenas a pergunta final.

O ganho tende a ser menor para chat aberto, tradução de textos independentes, chamadas com prompts curtos ou sistemas que embaralham o conteúdo a cada requisição. Nesses casos, o roteamento pode não encontrar estados úteis para reaproveitar. Se a aplicação usa uma API gerenciada fora do SageMaker, o anúncio também não muda sua fatura.

A publicação da AWS, “Reduce LLM latency with prefix-aware routing on Amazon SageMaker Inference”, apresenta a técnica e seus resultados. Porém, os dados de preços disponíveis para comparação são do OpenRouter, enquanto as notas de inteligência, código e uso agêntico são do Artificial Analysis. Nenhuma dessas referências demonstra uma redução de custo específica para uma conta AWS.

O teste que deve vir antes da migração

Antes de trocar a arquitetura, meça a repetição dos prefixos no tráfego real. Registre o tempo até o primeiro token, a duração total, a taxa de acerto do cache e o uso das instâncias. Depois compare uma janela com roteamento convencional e outra com roteamento sensível a prefixo, mantendo modelo, carga e qualidade constantes.

Se a latência cair sem aumento proporcional de recursos, o recurso pode justificar a mudança. Se apenas o tempo de resposta melhorar, a decisão passa a ser de experiência do usuário, não de redução de custos. E se os prefixos forem raros, o ganho anunciado não deve entrar na previsão financeira.