Como é que a Paged Attention gere a cache KV com pedidos de IA locais simultâneos?
A Paged Attention gere a cache KV concorrente ao mapear o estado de tokens crescente de cada pedido para blocos de tamanho fixo, que podem ser alocados e reciclados de forma independente.
Isso é importante num servidor de IA doméstico, porque os chats ativos, as tarefas com documentos e os agentes raramente têm o mesmo comprimento de contexto ou terminam ao mesmo tempo. Uma estratégia de reserva contígua desperdiça memória escassa do acelerador à volta dessas sequências variáveis. A paginação altera a disposição da memória para que o agendador possa utilizar a capacidade disponível de forma mais densa.
Os pedidos concorrentes criam caches KV que crescem a ritmos diferentes
Cada pedido autoregressivo ativo precisa do estado de chaves e valores dos tokens que já processou. Um chat pode terminar após 100 tokens, enquanto outro continua durante milhares, pelo que a sua necessidade de memória não pode ser conhecida com exatidão quando o lote começa.
O artigo sobre PagedAttention identifica a memória da cache KV, que cresce dinamicamente, como um gargalo do serviço, limitando o agrupamento de pedidos quando a alocação é ineficiente.
Num servidor doméstico com vários utilizadores ou agentes em segundo plano, esta variabilidade transforma um grande valor de memória livre em muitas alocações ativas de tamanhos diferentes.
As reservas contíguas fixas desperdiçam memória à volta de sequências variáveis
Um ambiente de execução ingénuo pode reservar uma grande região contígua para cada pedido, com base num comprimento máximo. Os pedidos curtos deixam espaço por utilizar dentro da sua reserva, enquanto os pedidos mais longos podem precisar de realocação ou de sobredimensionamento.
O vAttention resume a motivação original da paginação: as reservas KV antecipadas criam fragmentação interna. A memória desperdiçada reduz o número de pedidos que podem permanecer ativos em simultâneo.
O sintoma prático é um limite de falta de memória ou um lote máximo pequeno, mesmo quando a soma dos estados de tokens efetivamente utilizados parece inferior à VRAM disponível.
O PagedAttention divide o estado KV em blocos de tamanho fixo
O PagedAttention substitui um único buffer de pedido fisicamente contíguo por uma sequência lógica de blocos. À medida que chegam mais tokens, o ambiente de execução aloca blocos físicos adicionais a partir de um conjunto partilhado.
A vLLM explica que os blocos KV podem residir em memória física não contígua. Uma tabela de blocos mapeia a ordem lógica dos tokens do pedido para essas localizações físicas.
O modelo continua a dar atenção à sequência correta. A indireção altera a localização na memória, não a ordem semântica da conversa.
Os blocos libertados regressam a um conjunto partilhado quando os pedidos terminam
Quando um pedido termina, os seus blocos não partilhados podem ser libertados imediatamente e reutilizados por outro pedido ativo ou por um novo pedido admitido. O servidor não precisa de esperar que uma arena gigante fique totalmente vazia.
A infraestrutura de inferência da NVIDIA expõe a capacidade da cache KV como um recurso do serviço que deve ser equilibrado com os pesos e o espaço de trabalho do ambiente de execução.
Esta reciclagem ao nível dos blocos é valiosa em casa porque os comprimentos dos pedidos são irregulares: uma pessoa faz uma pergunta curta sobre a casa inteligente, enquanto outra executa um assistente de documentos longo e um agente em segundo plano resume ficheiros.
A paginação aumenta a concorrência ao reduzir a fragmentação, não ao diminuir cada token
O PagedAttention não torna, fundamentalmente, menores os tensores de chaves e valores de cada token. A sua principal vantagem de memória resulta da alocação mais próxima do crescimento efetivo da sequência e da possibilidade de partilha quando esta é válida.
As orientações de computação distribuída do PyTorch distinguem o paralelismo do modelo da gestão da memória do serviço. A paginação não é paralelismo de tensores e, por si só, não divide os pesos do modelo por várias GPUs.
Se os pesos de um modelo já ocuparem quase toda a memória do dispositivo, a paginação não consegue criar capacidade suficiente para uma concorrência elevada. Melhora a utilização da região KV restante.
A gestão de blocos tem os seus próprios custos e limites de agendamento
O ambiente de execução passa a manter tabelas de blocos, contagens de referências, decisões de alocação e kernels de atenção compatíveis com disposições paginadas. Lotes extremamente pequenos ou hardware não suportado podem reduzir a vantagem.
O artigo da ZimaSpace sobre concorrência familiar e pressão sobre a KV mostra o limite percecionado pelo utilizador: a eficiência da memória é importante porque determina quantos contextos ativos podem coexistir antes de o tempo de espera aumentar.
Teste vários comprimentos de pedidos e padrões de chegada, em vez de um único lote sintético. O guia da ZimaSpace sobre janelas de contexto deslizantes e memória KV é uma comparação útil, porque o uso de janelas altera a quantidade de estado que cada sequência retém, enquanto a paginação altera a forma como esse estado é alocado. Registe as sequências ativas, os blocos KV utilizados, o tempo em fila e as preempções.
O agendador TGI da Hugging Face também distingue o agendamento de prefill e decode durante o serviço concorrente. A memória paginada ajuda o agendador a admitir trabalho, mas a equidade e a latência continuam a depender da forma como esse trabalho é colocado em fila.
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...
