Como é que a colocação em cache de prefixos reduz o trabalho repetido dos prompts num servidor de IA doméstico?
A colocação em cache de prefixos reduz o trabalho repetido dos prompts ao reutilizar o estado chave-valor já calculado para uma sequência inicial idêntica de tokens.
Num servidor de IA doméstico, esse prefixo partilhado pode ser uma política do sistema, um esquema de ferramentas, um documento extenso, um conjunto de instruções domésticas ou um histórico de conversas repetido. O primeiro pedido continua a suportar o custo total do prefill, mas os pedidos seguintes que correspondam podem ignorar grande parte desse trabalho. O principal benefício é um percurso de prefill mais curto e um primeiro token mais rápido, não uma geração gratuita.
Sem uma cache, os prompts repetidos recalculam o mesmo prefill
Antes de gerar uma resposta, um modelo autorregressivo processa os tokens de entrada e cria o estado chave-valor utilizado durante a descodificação posterior. Um prompt de sistema extenso, um esquema de ferramentas, o cabeçalho de um documento ou um bloco de instruções partilhado podem, por isso, consumir o mesmo trabalho de prefill em cada pedido.
A Prompt Cache formaliza esta oportunidade ao reutilizar estados de atenção de segmentos sobrepostos dos prompts. Num servidor de IA doméstico, a parte repetida pode ter milhares de tokens, apesar de o utilizador contribuir apenas com uma frase nova.
Sem reutilização, a GPU ou a CPU executa novamente essas operações matriciais e lê os mesmos pesos do modelo para o mesmo prefixo. O resultado pode ser idêntico, mas o servidor continua a suportar o custo computacional de preparação.
Uma cache de prefixos armazena o estado KV de um prefixo já processado
Depois do primeiro pedido compatível, o ambiente de execução pode manter o estado KV associado ao prefixo partilhado. Um pedido posterior começa por verificar se a sua sequência inicial de tokens corresponde a blocos colocados em cache.
A cache automática de prefixos do vLLM identifica os blocos através de tokens do bloco e do prefixo precedente. Os pedidos correspondentes podem apontar para os mesmos blocos físicos da cache, em vez de alocar e calcular estados duplicados.
O objeto reutilizável não é a resposta final nem um resumo semântico genérico. É um estado de atenção específico do modelo para um prefixo exato e compatível.
Um acerto na cache ignora o prefill partilhado, mas continua a calcular o novo sufixo
Quando o prefixo corresponde, o ambiente de execução pode começar pelo estado de atenção armazenado e avaliar apenas os novos tokens depois do limite colocado em cache. Um assistente doméstico com um prompt de sistema estável pode, assim, evitar trabalho repetido antes de cada comando curto.
A LMCache descreve a reutilização da cache KV entre pedidos de LLM como uma otimização da camada de disponibilização, e não como uma alteração aos pesos do modelo.
A nova mensagem do utilizador continua a precisar de prefill, e cada token de saída gerado continua a exigir computação de descodificação. A colocação em cache de prefixos reduz sobretudo o trabalho redundante antes do início da geração.
Prefixos longos e estáveis proporcionam o maior ganho no tempo até ao primeiro token
Uma cache poupa trabalho proporcionalmente à parte que, de outro modo, seria recalculada. Reutilizar um prefixo de 2 000 tokens com instruções e um documento é mais importante do que reutilizar uma saudação de dez tokens.
O modelo de disponibilização do SGLang utiliza a reutilização estruturada de KV para acelerar cargas de trabalho com prefixos partilhados. O equivalente num servidor doméstico é uma política de agente repetida, um catálogo de ferramentas, um conjunto de conhecimentos do agregado familiar ou um modelo de documento.
É por isso que a colocação em cache de prefixos deve ser avaliada pelo tempo até ao primeiro token e pelo débito de prefill, e não apenas pelos tokens por segundo durante a geração. A fase de descodificação pode permanecer praticamente inalterada, enquanto a resposta começa mais cedo.
Pequenas alterações no prompt podem interromper a reutilização no limite do bloco
Uma cache é normalmente exata relativamente aos tokens e ao estado do modelo. Reordenar definições de ferramentas, inserir uma marca temporal variável perto do início, mudar adaptadores ou modificar o prompt de sistema pode tornar os blocos seguintes inelegíveis para reutilização.
As orientações de disponibilização da Hugging Face distinguem o prefill da calendarização da descodificação. Manter o conteúdo estável no início do prompt faz com que uma parte maior desse prefill possa ser reutilizada.
Por isso, as aplicações devem evitar inserir dados voláteis no início de um prefixo que, de outro modo, seria estável, quando a mesma informação puder ser colocada mais tarde.
A capacidade e a expulsão da cache definem os limites num servidor doméstico
Os blocos KV ocupam memória, pelo que o servidor não pode manter todos os prefixos indefinidamente. Conversas simultâneas, contextos extensos e vários modelos competem pelo mesmo conjunto de memória e podem expulsar estados reutilizáveis antigos.
A explicação da ZimaSpace sobre colocação de modelos em cache e latência de respostas com o modelo já preparado apresenta a hierarquia mais ampla de caches. A colocação de prefixos em cache é apenas uma camada e não deve ser confundida com manter os pesos do modelo residentes.
Meça a taxa de acertos da cache, o número de tokens reutilizados, o tempo até ao primeiro token, o débito de prefill, a utilização de memória KV e a taxa de expulsão ao nível de simultaneidade real do agregado familiar.
A documentação do TensorRT-LLM da NVIDIA descreve a reutilização da cache KV como uma otimização de disponibilização, com a mesma limitação fundamental: o estado reutilizável só é útil enquanto os blocos correspondentes permanecerem disponíveis.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
