Roteamento de Cache KV: Reduza o Trabalho Redundante de Pré-preenchimento de LLM

O roteamento de cache KV é importante quando prefixos de prompt repetidos continuam aparecendo no tráfego do seu LLM. Se a solicitação certa chegar à réplica certa, o mecanismo de serviço pode reutilizar o estado de atenção em cache em vez de recalcular os mesmos tokens de preenchimento repetidamente.

Isso parece um detalhe de infraestrutura, mas rapidamente se torna um problema de produto. Prompts longos do sistema, contexto RAG, exemplos few-shot e histórico de chat com várias interações podem tornar o trabalho de preenchimento caro. Quando cada réplica recalcula o mesmo prefixo, as equipes pagam em latência, tempo de GPU e planejamento de capacidade.

O ShareAI oferece aos desenvolvedores uma API para mais de 150 modelos, visibilidade de marketplace, roteamento e failover. O roteamento de cache KV está uma camada abaixo, dentro da infraestrutura de serviço de modelos. A conclusão útil para os leitores do ShareAI é simples: as decisões de roteamento importam em todas as camadas da pilha de IA, desde a escolha do modelo até qual réplica de GPU lida com um prompt repetido.

Por que o Roteamento de Cache KV é Importante

Durante a inferência de LLM, um modelo primeiro processa o prompt de entrada na fase de preenchimento. Ele constrói um cache de chave-valor, geralmente chamado de cache KV, para que os tokens gerados posteriormente possam se referir ao contexto já processado.

O cache de prefixo permite que os mecanismos de serviço reutilizem esse cache quando uma solicitação posterior compartilha o mesmo início do prompt. A documentação de cache de prefixo automático do vLLM descreve isso como reutilizar o cache KV para prefixos compartilhados, para que a nova solicitação possa pular a computação da parte compartilhada. O cache de prefixo do SGLang usa uma ideia relacionada para compartilhar o cache KV para sequências comuns de tokens.

Isso é especialmente importante para cargas de trabalho onde muitas solicitações começam da mesma forma: agentes de suporte com um grande prompt do sistema, aplicações RAG usando trechos de documentação repetidos, agentes de codificação com instruções de repositório ou produtos de chat que carregam o histórico da conversa entre interações.

Onde o Round-Robin Falha

O cache de prefixo é mais fácil em uma única réplica. O mesmo processo vê o prefixo repetido e pode reutilizar seu cache se houver memória disponível. O problema aparece quando o serviço escala horizontalmente.

Com um balanceador de carga round-robin padrão, a primeira solicitação pode aquecer o cache na réplica A, enquanto a segunda solicitação com o mesmo prefixo chega à réplica B. A réplica B não tem esse estado em cache, então recalcula o mesmo trabalho de preenchimento. A terceira solicitação pode ir para a réplica C e falhar novamente.

À medida que o número de réplicas cresce, o balanceamento de carga ingênuo pode espalhar solicitações relacionadas por mais máquinas. A frota de serviço de modelos pode parecer equilibrada, mas a taxa de acerto do cache de prefixo cai. Essa é a lacuna que o roteamento de cache KV tenta fechar.

Três Níveis Práticos de Roteamento

1. Afinidade de Sessão

A afinidade de sessão direciona o tráfego do mesmo usuário, espaço de trabalho, locatário ou conversa para a mesma réplica. É o lugar mais simples para começar em chats de múltiplas interações, pois os prompts de acompanhamento frequentemente compartilham o contexto anterior.

A desvantagem é que a identidade do usuário nem sempre é a mesma que a similaridade do prompt. Dois usuários podem compartilhar o mesmo prompt longo do sistema e ainda serem direcionados para réplicas diferentes. A afinidade de sessão também pode ser perturbada quando réplicas são adicionadas ou removidas.

2. Roteamento por Hash de Prefixo

O roteamento por hash de prefixo usa o próprio prompt como chave de roteamento. O roteador faz o hash do início estável do prompt e envia prefixos correspondentes para a mesma réplica.

Isso funciona melhor quando prompts repetidos do sistema, exemplos de poucos disparos ou contextos recuperados compartilhados são mais importantes do que a identidade do usuário. A parte difícil é escolher o limite do prefixo. Se o hash incluir um timestamp, ID de solicitação ou campo específico do usuário, a chave de roteamento se fragmenta e o reaproveitamento do cache se desfaz.

3. Roteamento Sensível a Eventos de Cache

A abordagem mais avançada rastreia quais blocos de cache estão residentes em qual réplica e, em seguida, direciona cada solicitação para a réplica com a melhor sobreposição de cache, ainda considerando a carga. O projeto llm-d router descreve um seletor de endpoint que considera a localidade do KV-cache, a carga atual e a prioridade ao escolher para onde uma solicitação deve ir.

Isso é mais complexo, mas é a direção certa para frotas de alta capacidade onde falhas de cache são medidas, caras e frequentes.

Quando Ignorar

O roteamento de cache KV não vale automaticamente a complexidade. É uma escolha fraca quando os prompts são curtos, principalmente únicos ou processados em lotes com pouca estrutura repetida.

Resumo de documentos, geração criativa, extração única e muitos trabalhos assíncronos em lote podem não ter sobreposição suficiente de prefixos compartilhados para justificar o roteamento sensível ao cache. Nesses casos, o balanceamento de carga simples pode ser mais eficiente.

O teste prático é a medição: taxa de acerto do cache, tempo para o primeiro token, throughput, profundidade da fila, pressão na memória da GPU e custo por tarefa concluída. Se o roteamento consciente de cache não alterar esses números, corrija primeiro a estrutura do prompt.

Como Isso Se Encaixa Com ShareAI

ShareAI é um marketplace de IA e API, não o balanceador de carga de modelos dentro do seu cluster de GPU. Os desenvolvedores usam o ShareAI para acessar vários modelos através de uma API, comparar sinais do marketplace, roteirizar solicitações, gerenciar uso e realizar failover quando uma rota se degrada.

Isso ainda torna o roteamento de cache KV relevante. Se você opera sua própria pilha de inferência, isso ajuda a fazer melhores perguntas sobre infraestrutura. Se você consome modelos hospedados, isso ajuda a avaliar por que duas rotas com nomes de modelos semelhantes podem se comportar de maneira diferente sob cargas de trabalho reais.

Para Construtores, isso também se conecta ao preço. Um aplicativo com prompts longos, contexto RAG repetido ou loops de agentes pode criar um uso de IA muito irregular. O ShareAI Builder permite que os proprietários de aplicativos roteiem o tráfego de inferência de IA através do ShareAI, definam uma margem ou sobretaxa, façam com que os clientes paguem ao ShareAI pelo uso roteado e recebam pagamentos mensais com base no uso gerado. O próprio aplicativo permanece construído fora do ShareAI.

Para seleção de modelos e avaliação de rotas, comece com o marketplace de modelos do ShareAI. Para fundamentos de implementação, use o Referência da API do ShareAI.

Checklist de Roteamento de Cache KV

• Coloque o conteúdo estável do prompt primeiro: prompt do sistema, regras de ferramentas, exemplos e contexto repetido.
• Mova os campos dinâmicos para depois: timestamps, IDs de solicitações, fatos específicos do usuário e instruções únicas.
• Meça a taxa de acerto do cache antes e depois das mudanças de roteamento.
• Observe o tempo para o primeiro token, throughput, profundidade da fila e pressão de VRAM juntos.
• Comece com roteamento de prefixo-hash antes de construir roteamento consciente de eventos de cache.
• Divida as regras de roteamento por carga de trabalho em vez de forçar uma política global.
• Mantenha o custo e a latência visíveis no nível do aplicativo, não apenas dentro do cluster de inferência.

Perguntas Frequentes

O que é roteamento de cache KV?

O roteamento de cache KV é uma estratégia de roteamento que envia solicitações com prefixos de prompt repetidos para réplicas que provavelmente já possuem o cache KV correspondente. O objetivo é reduzir cálculos redundantes de preenchimento.

Como o roteamento de cache KV é diferente do cache de prefixo?

O cache de prefixo é a capacidade do mecanismo de serviço de modelo de reutilizar o estado em cache para prefixos de prompt compartilhados. O roteamento de cache KV é a estratégia de alocação de tráfego que ajuda solicitações correspondentes a chegarem onde esse estado em cache já existe.

Por que o roteamento round-robin prejudica o cache de prefixo?

O roteamento round-robin distribui solicitações entre réplicas sem saber qual réplica possui qual prefixo em cache. Um prompt repetido pode perder o cache simplesmente porque chega a uma réplica diferente.

Quais cargas de trabalho se beneficiam mais do roteamento de cache KV?

Chat de múltiplas interações, RAG, agentes de codificação, agentes de suporte, prompts few-shot e aplicativos com prompts de sistema compartilhados longos são os candidatos mais fortes porque reutilizam prefixos de prompt substanciais.

Quando uma equipe deve ignorar o roteamento de cache KV?

Ignore-o quando os prompts forem curtos, principalmente únicos ou orientados por lotes com pouca estrutura repetida. Nesses casos, a complexidade do roteamento pode agregar pouco valor.

vLLM e SGLang suportam cache de prefixo?

Sim. vLLM documenta o cache de prefixo automático, e SGLang documenta o cache de prefixo para cache KV compartilhado em sequências comuns de tokens. O mecanismo de serviço ainda precisa de ajuda de roteamento quando várias réplicas estão envolvidas.

O roteamento de cache KV é o mesmo que cache semântico?

Não. O roteamento de cache KV funciona com reutilização exata ou quase estrutural de prefixos dentro do serviço de inferência. O cache semântico armazena e reutiliza respostas ou resultados intermediários com base no significado, geralmente com embeddings ou limites de similaridade.

O ShareAI substitui um balanceador de carga consciente de cache KV?

Não. ShareAI é o marketplace de IA e camada de API para acesso a modelos, roteamento, failover, uso e faturamento. O roteamento ciente de KV-cache é uma infraestrutura de serviço de modelos de nível inferior para equipes que operam réplicas de inferência.

Como os Builders devem pensar sobre o roteamento de cache KV?

Os Builders devem tratar o comportamento do cache como um fator de custo dentro de aplicativos pesados em IA. Se o aplicativo deles tiver uso desigual, o ShareAI pode ajudar a rotear e monetizar esse tráfego de IA enquanto o aplicativo permanece construído e de propriedade fora do ShareAI.

O que as equipes devem medir antes de alterar o roteamento?

Meça a taxa de acerto do cache, o tempo para o primeiro token, a taxa de transferência, a profundidade da fila, a pressão de VRAM, o custo por tarefa e a qualidade da saída. As alterações de roteamento devem melhorar a carga de trabalho, não apenas o painel.

O roteamento de cache KV pode reduzir os custos de API de IA?

Ele pode reduzir o custo de infraestrutura para equipes que servem modelos por conta própria, porque menos trabalho redundante de preenchimento pode melhorar a eficiência da GPU. Para APIs hospedadas, o efeito depende de o provedor expor essas economias no preço ou no desempenho.