Porque é que a cache KV cresce com o comprimento do contexto da IA doméstica?

A cache KV cresce com o comprimento do contexto porque o runtime armazena as chaves e os valores da atenção para cada token retido em várias camadas do modelo.

Um prompt curto de IA doméstica pode deixar memória suficiente para vários utilizadores, enquanto um documento longo, um histórico de conversa extenso ou um registo de agente pode consumir muito mais memória de trabalho sem alterar o próprio ficheiro do modelo. A cache começa a ser criada durante o processamento do prompt e continua a crescer à medida que o modelo gera novos tokens. O seu tamanho também depende do número de camadas, da arquitetura da atenção, da precisão numérica e do número de pedidos simultâneos. As secções abaixo acompanham esse crescimento desde um token até ao limite de memória de todo o servidor.

Cada Token Retido Adiciona Estado de Atenção

Durante a inferência do transformador, cada camada produz tensores de chaves e valores a partir dos tokens já processados. O runtime mantém esses tensores para que o token seguinte possa prestar atenção ao contexto anterior sem recalcular toda a sequência.

O trabalho do vLLM identifica o estado KV por token como um requisito importante de memória para servir modelos. Os novos tokens adicionam novas entradas à cache, enquanto as entradas anteriormente retidas continuam disponíveis para os passos de atenção seguintes.

A cache é, por isso, estado mutável do pedido e não faz parte dos pesos estáticos do modelo. Carregar o mesmo modelo com uma conversa ativa mais longa cria uma utilização de memória maior.

O Crescimento da Cache É Aproximadamente Linear em Relação ao Comprimento da Sequência Retida

Para uma arquitetura de modelo e uma precisão da cache fixas, duplicar o número de tokens retidos duplica aproximadamente as entradas KV mantidas para esse pedido. Tanto o prompt como a resposta gerada contam para a sequência ativa.

O H2O descreve como a cache KV escala com o comprimento da sequência e o tamanho do lote. A relação mantém-se aproximadamente linear porque cada token adicional contribui com chaves e valores em todas as camadas que produzem cache.

É por isso que aumentar uma definição do runtime de um contexto pequeno para um máximo muito maior pode alterar o limite prático de memória, mesmo quando o modelo utiliza exatamente os mesmos pesos.

A definição máxima e a utilização real são coisas diferentes. Alguns runtimes alocam blocos de cache a pedido, enquanto outros reservam antecipadamente uma região maior para garantir o crescimento futuro.

A Arquitetura do Modelo Altera o Número de Bytes por Token

Dois modelos com o mesmo número de parâmetros podem exigir diferentes quantidades de memória KV, porque podem utilizar diferentes números de camadas, dimensões das cabeças, números de cabeças de atenção, atenção de consultas agrupadas ou atenção de múltiplas consultas.

O KIVI estuda a precisão da cache KV e mostra que armazenar chaves e valores com menos bits pode reduzir significativamente o pico de memória. O benefício aplica-se ao estado dos pedidos, não à redução dos pesos subjacentes do modelo.

Os designs de atenção de consultas agrupadas e de múltiplas consultas partilham cabeças de chaves e valores entre mais cabeças de consulta, o que pode reduzir os bytes de cache por token em comparação com a atenção de múltiplas cabeças completa. O número de camadas e a largura das cabeças continuam a multiplicar o estado retido.

Por isso, uma estimativa útil deve utilizar a arquitetura exata do modelo e o formato da cache do runtime, e não apenas uma regra genérica de bytes por token copiada de outro modelo.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Os Tokens Gerados Continuam a Aumentar a Cache Depois do Preenchimento Inicial

O processamento do prompt cria a cache inicial para o contexto de entrada. A descodificação autorregressiva acrescenta depois o estado de cada token de saída aceite, para que os tokens seguintes possam prestar atenção à conversa completa.

O vAttention trata o crescimento dinâmico da cache como um problema de alocação, porque o comprimento final da saída é desconhecido quando um pedido começa. Reservar memória em excesso desperdiça recursos, enquanto reservar pouca memória pode obrigar à preempção ou a operações de expansão.

Um prompt que cabe confortavelmente ainda pode ultrapassar o limite de memória durante uma resposta longa. Por isso, os limites de saída protegem a memória, além do comprimento da resposta e do tempo de geração.

Os Utilizadores Simultâneos Multiplicam o Estado de Contexto Separado

Os pesos do modelo podem ser partilhados entre pedidos, mas cada conversa ativa normalmente mantém o seu próprio histórico de tokens e a sua própria cache KV. Cinco utilizadores com contextos longos não partilham uma única cache universal apenas por utilizarem o mesmo modelo.

A investigação recente sobre gestão de KV apresenta as reservas por pedido como um compromisso central entre a eficiência da memória e o risco de preempção. Os comprimentos de saída desconhecidos tornam o pico combinado mais difícil de prever do que uma simples contagem de utilizadores.

Os prefixos de prompts partilhados podem, por vezes, reutilizar o estado da cache quando o runtime suporta correspondência exata de prefixos, mas o histórico privado das conversas e as saídas divergentes continuam a criar ramificações separadas.

O guia de hardware da ZimaSpace considera o contexto e a simultaneidade como requisitos de memória para além do ficheiro do modelo. Por isso, um teste com um único utilizador pode subestimar a RAM ou VRAM necessária para um assistente doméstico.

A Paginação, a Quantização e a Evicção Alteram o Limite, Não a Causa

A alocação paginada reduz a fragmentação ao dividir o estado da cache em blocos mais pequenos, para que o runtime não tenha de reservar uma única região contígua sobredimensionada para cada sequência possível.

O PagedAttention fornece alocação baseada em blocos, enquanto a quantização da cache reduz os bytes por valor armazenado e as políticas de evicção eliminam determinadas entradas antigas. Cada método altera a quantidade de contexto que cabe, mas o estado de atenção retido continua a crescer à medida que os tokens se acumulam.

A evicção ou as janelas deslizantes podem limitar a memória ao remover tokens anteriores, mas o modelo deixa de poder prestar atenção ao estado eliminado através do percurso normal de contexto completo. A compressão e a retenção seletiva também podem introduzir compromissos específicos em termos de qualidade ou carga de trabalho.

Meça a utilização da cache com o modelo real, o contexto, a precisão da cache, o tamanho do lote e o número de utilizadores reais. O limite prático é atingido quando não é possível admitir outro token ou pedido sem evicção, transferência para outro nível de armazenamento, recalculação ou falha.

Perguntas Frequentes

O ficheiro do modelo fica maior quando o comprimento do contexto aumenta?

Não. Os pesos do modelo permanecem iguais. A memória adicional é estado do runtime criado para o prompt ativo e para os tokens gerados.

Definir um contexto máximo elevado aloca sempre toda a memória KV imediatamente?

Não. O comportamento de alocação depende do runtime. Alguns reservam capacidade antecipadamente, enquanto os sistemas paginados alocam blocos à medida que os tokens são admitidos.

A RAM do sistema pode armazenar a cache KV quando a VRAM está cheia?

Alguns runtimes podem transferir ou mover o estado da cache, mas essas transferências acrescentam latência e dependem do suporte do software, da largura de banda e do percurso de atenção ativo.