Prefix caching no vLLM reaproveita cálculos de um começo de prompt que já passou pelo servidor. Quando várias solicitações compartilham as mesmas instruções ou o mesmo documento inicial, o mecanismo pode evitar parte do processamento de entrada. A resposta continua sendo gerada para cada solicitação. O objetivo é diminuir trabalho repetido na infraestrutura que você administra.
Para aplicar, mantenha o conteúdo estável antes das informações variáveis, habilite o recurso na configuração do motor e compare cargas equivalentes com cache frio e aquecido. A economia depende do perfil de uso, da memória disponível e do reaproveitamento real. Não transforme uma queda isolada de latência em promessa de redução da conta mensal.
Resumo rápido
- O Automatic Prefix Caching reutiliza estados de atenção de prefixos compartilhados.
- Seu principal benefício está no processamento de entrada, chamado prefill.
- Documentos e instruções estáveis devem vir antes da pergunta variável.
- Cache de resposta, busca semântica e prefix caching resolvem problemas diferentes.
- Meça acertos, tempo até o primeiro token, filas e custo por tarefa concluída.
O que fica no cache e o que continua sendo calculado
Durante a inferência, um modelo mantém estados intermediários usados pelo mecanismo de atenção. Eles são conhecidos como KV cache, em referência a keys e values. O guia oficial de Automatic Prefix Caching explica que uma nova consulta pode reutilizar esses estados quando compartilha o prefixo de uma consulta anterior. O servidor deixa de recalcular o trecho reaproveitado.
Isso atua no prefill, etapa que processa os tokens de entrada. A geração dos novos tokens de saída, chamada decode, permanece necessária. Portanto, um serviço que recebe perguntas muito curtas e produz relatórios enormes pode obter pouco benefício perceptível. Um assistente que relê o mesmo manual extenso para responder perguntas curtas apresenta um cenário mais promissor.
Use essa distinção para formular a hipótese do projeto: “estamos gastando processamento para reler conteúdo idêntico”. Se a lentidão principal vier de uma consulta ao banco, da ferramenta externa ou da fila do aplicativo, mudar o cache do modelo não resolve a causa. O guia sobre latência e TTFT no vLLM ajuda a separar essas etapas antes de otimizar.
Como organizar prompts para reaproveitar prefixos
A documentação de arquitetura do cache descreve identificação por hashes e gerenciamento em blocos. O reaproveitamento depende da sequência efetivamente enviada ao modelo. Textos com o mesmo sentido, mas escritos de maneiras diferentes, não devem ser tratados como prefixos equivalentes.
Uma organização prática é começar pelas instruções gerais, seguir com o material estável autorizado para aquela operação e terminar com o pedido específico. Evite colocar data atual, identificador aleatório ou nome do atendente antes de um manual comum. Esses campos mudam entre chamadas e podem interromper a parte compartilhada logo no começo.
Não reorganize conteúdo às cegas. A posição de uma instrução pode afetar a interpretação do modelo. Primeiro crie uma versão candidata, depois compare a qualidade com um conjunto de perguntas representativas. Mantenha os mesmos documentos, limites de resposta e critérios de avaliação. A mudança precisa preservar tanto o comportamento quanto o controle de acesso.
Para documentos recuperados por busca, estabeleça uma ordenação previsível quando isso não prejudicar a relevância. Se cada chamada embaralha os mesmos trechos, a oportunidade de reaproveitamento diminui. Porém, nunca acrescente documentos desnecessários apenas para elevar a taxa de acerto. O texto extra ainda ocupa contexto, exige manutenção e pode distrair o modelo.
| Técnica | O que reaproveita | Decisão prática |
|---|---|---|
| Prefix caching | Cálculo de um prefixo já processado | Útil para instruções e documentos repetidos |
| Cache de resposta | Uma resposta pronta da aplicação | Exige chave e regra de validade próprias |
| Cache semântico | Resposta associada a uma pergunta parecida | Exige avaliação do risco de aproximação |
| Busca em documentos | Trechos recuperados de uma base | Seleciona contexto; não elimina por si só o prefill |
Configuração inicial e isolamento entre clientes
A referência de argumentos do motor vLLM apresenta a opção --enable-prefix-caching. Como a versão instalada pode diferir da documentação mais recente, confira a ajuda local e registre a versão utilizada. O exemplo abaixo mostra somente a ativação; substitua o caminho pelo modelo já validado no seu ambiente.
vllm serve /modelos/modelo-validado --enable-prefix-cachingEsse comando não dimensiona a GPU, não instala pesos e não configura um serviço público seguro. Em uma implantação real, acrescente os parâmetros de rede e autenticação definidos pela equipe, limite quem pode alcançar o endpoint e mantenha a configuração sob controle de versão. Trate o cache como parte da infraestrutura de inferência, com responsável técnico identificado.
Ambientes que atendem várias empresas merecem uma decisão explícita sobre compartilhamento. A arquitetura documenta cache_salt por requisição para separar grupos de reutilização. Solicitações com salts diferentes não compartilham os mesmos blocos por esse mecanismo. O valor deve ser atribuído pelo backend confiável segundo o contexto autenticado, sem permitir que um cliente escolha livremente o grupo de outro.
Isso complementa a autorização; não substitui a autorização de documentos nem o isolamento de rede. Faça um teste em que dois clientes pedem o mesmo conteúdo público e outro em que tentam acessar conteúdo privado. A política de leitura precisa funcionar independentemente de haver acerto de cache. Para um desenho mais amplo, consulte permissões em aplicações com agentes.
Como medir benefício sem fabricar uma economia
A referência de métricas de produção documenta observabilidade do servidor, incluindo medidas de latência e atividade do cache. Confira quais métricas sua versão realmente expõe. Monte o painel a partir do endpoint disponível e guarde a consulta utilizada, para que outra pessoa consiga reproduzir a medição.
Prepare três grupos de entradas: prefixos repetidos, prefixos parcialmente compartilhados e entradas sem repetição relevante. Use o mesmo modelo, hardware e limites de geração em todos. Execute uma rodada inicial e uma rodada posterior. O contraste ajuda a distinguir o custo de preencher o cache do benefício de reaproveitá-lo.
Registre o tempo até o primeiro token, a duração total, as tarefas concluídas, os erros e o tamanho das respostas. Inclua os percentis que importam para seu atendimento, porque a média pode ocultar solicitações lentas. Observe também a fila: um aumento no volume de tráfego durante o teste pode esconder uma melhoria no processamento de entrada.
Em seguida, estime o custo usando a infraestrutura efetivamente consumida. Uma GPU alugada continua custando dinheiro enquanto estiver provisionada. Se o cache permite atender mais tarefas na mesma máquina, o benefício inicial pode ser capacidade adicional. Para afirmar redução de gasto, demonstre que foi possível reduzir horas contratadas, máquinas necessárias ou outro item da fatura.
Evite comparar uma execução vazia com outra já carregada de tráfego sem registrar a diferença. Documente concorrência, distribuição de tamanhos e proporção de perguntas repetidas. Repita o ensaio depois de atualizar o modelo ou o template de conversa, pois uma alteração na montagem das mensagens pode mudar o comportamento observado.
Exemplo: assistência técnica em Campinas
Imagine uma assistência técnica de equipamentos comerciais em Campinas. Os atendentes usam um modelo hospedado pela empresa para consultar procedimentos de instalação e manutenção. O cenário é ilustrativo: não há resultados medidos nem percentuais de economia atribuídos a uma empresa real.
A primeira versão do aplicativo começa cada prompt com o número do chamado, a hora e o nome do cliente. Depois insere as mesmas instruções de segurança e um manual. A equipe propõe outra montagem: instruções estáveis, edição aprovada do manual e, ao final, os dados mínimos do chamado. O conteúdo de cada cliente continua restrito à solicitação correspondente.
O piloto usa perguntas preparadas pelos técnicos, incluindo dúvidas simples, casos sem resposta no manual e solicitações que exigem escalonamento. O avaliador verifica se a resposta cita o procedimento correto e se admite a falta de informação. Uma execução rápida que inventa instruções de manutenção é reprovada, mesmo que o cache apresente muitos acertos.
Ao trocar a edição do manual, o aplicativo envia o novo texto e registra a versão documental junto da tarefa. A equipe verifica se nenhuma resposta continua usando a edição antiga por causa de um cache de resposta separado. Essa distinção evita culpar o prefix caching por um problema de validade que pertence à aplicação.
O relatório do piloto reúne qualidade, latência, falhas e uso de infraestrutura. Somente depois desses dados a empresa decide expandir. Caso o ganho apareça apenas em uma pequena fração dos chamados, pode fazer mais sentido simplificar os prompts ou melhorar a busca documental antes de investir em mais capacidade.
Erros comuns
Confundir taxa de acerto com sucesso comercial. Um cache muito utilizado pode estar acelerando solicitações inúteis. Relacione a medição à tarefa concluída com qualidade, como orientar um técnico corretamente ou localizar a seção certa de um procedimento.
Esperar persistência ilimitada. Planeje o serviço para funcionar mesmo quando o cache não estiver aquecido. Reinícios, alterações de configuração e pressão sobre recursos fazem parte da operação. O usuário não deve receber uma resposta incorreta porque uma otimização deixou de estar disponível.
Aumentar o prompt para “aproveitar o cache”. O primeiro processamento ainda existe. Revise a necessidade de cada trecho, mantenha instruções concisas e compare com uma versão menor. O benefício precisa superar o custo de carregar material adicional.
Ignorar o balanceador. Se chamadas semelhantes são espalhadas entre instâncias, investigue onde o reaproveitamento realmente acontece. Registre a distribuição de tráfego antes de propor afinidade. Concentrar tudo em uma instância pode aumentar filas e prejudicar disponibilidade.
Medir só a demonstração. Um ensaio com perguntas idênticas mostra uma condição favorável. Acrescente horários de pico, documentos diferentes e conversas novas. A decisão de produção deve considerar a mistura de uso esperada no serviço.
Perguntas frequentes
Prefix caching guarda a resposta pronta?
Não. O mecanismo reutiliza processamento de entrada. Se você precisa devolver uma resposta anterior sem nova geração, isso exige uma estratégia separada na aplicação, com regras de validade, autorização e atualização dos dados.
Qualquer repetição dentro do texto produz um acerto?
Não conte com isso. O foco é o prefixo compartilhado, a parte inicial compatível da sequência. Um parágrafo igual colocado depois de conteúdos diferentes não deve ser considerado uma oportunidade garantida de reaproveitamento.
Devo mudar o modelo para usar esse recurso?
Comece pelo modelo que já atende aos critérios de qualidade. Confirme compatibilidade e comportamento na versão instalada do vLLM. Trocar simultaneamente modelo, hardware e estratégia de cache impede descobrir qual mudança causou o resultado.
Isso reduz automaticamente a conta de uma API terceirizada?
Este procedimento trata de um servidor vLLM sob sua administração. O custo de um serviço contratado depende das regras desse serviço. Não aplique um resultado de infraestrutura própria diretamente a uma tabela comercial externa.
Quando vale interromper o piloto?
Interrompa quando a qualidade cair, o isolamento falhar ou o custo operacional superar o benefício medido. Guarde a configuração anterior e os casos de teste. Uma reversão simples faz parte de uma implantação responsável.
