Tabela de links
Resumo e 1 Introdução
2 Antecedentes
2.1 Modelos de idiomas grandes
2.2 Fragmentação e Pagedattion
3 problemas com o modelo Pagedattion e 3.1 requer reescrever o kernel de atenção
3.2 adiciona redundância na estrutura de servir e 3.3 sobrecarga de desempenho
4 Insights sobre sistemas de porção de LLM
5 Vattion: design do sistema e 5.1 Visão geral do design
5.2 Aproveitando suporte de CUDA de baixo nível
5.3 Servindo LLMs com Vattion
6 Vattention: otimizações e 6.1 Mitigando a fragmentação interna
6.2 Hiding Latência de alocação de memória
7 Avaliação
7.1 Portabilidade e desempenho para preenchimento
7.2 Portabilidade e desempenho para decodificar
7.3 Eficácia da alocação de memória física
7.4 Análise da fragmentação da memória
8 Trabalho relacionado
9 Conclusão e referências
5 Vattention: design do sistema
Nosso objetivo é melhorar a eficiência e a portabilidade adicionando suporte à alocação dinâmica de memória aos kernels existentes. Para atingir esse objetivo, a Vattention alavanca o suporte ao sistema
Alocação de memória dinâmica em vez de implementar a paginação no espaço do usuário.
5.1 Visão geral do projeto
A Vattion se baseia na capacidade de alocar memória virtual e memória física separadamente. Especificamente, alocamos um grande buffer contíguo para o cache KV na memória virtual antes do tempo (semelhante aos alocadores baseados em reserva) enquanto adia a alocação da memória física para o tempo de execução, ou seja, aloce a memória física somente quando necessário (semelhante à Pagedattion). Dessa forma, a Vattention preserva a contiguidade virtual do KV-cache sem desperdiçar a memória física. Essa abordagem é viável porque a capacidade de memória e a fragmentação são fatores limitantes apenas para a memória física, enquanto a memória virtual é abundante, por exemplo, os sistemas modernos de 64 bits fornecem um espaço de endereço virtual gerenciado pelo usuário de 128 TB para cada processo[3].
5.1.1 Memória virtual de pré-realização. Como a memória virtual é abundante, pré-allocamos espaço de memória virtual suficiente que seja grande o suficiente para manter o cache KV do tamanho máximo do lote (configurável) que precisa ser suportado.
Número de buffers de memória virtual: Cada camada em um LLM mantém seus próprios tensores K e V: nos referimos a eles individualmente como K-Cache e V-Cache. Alocamos buffers de memória virtual separados para K-Cache e V-Cache. Para um único trabalho de GPU, isso requer buffers 2 𝑁 𝑁 de pré-reeritagem, onde 𝑁 é o número de camadas no modelo. Em um trabalho multi-GPU, cada trabalhador se reserva de buffers 2 × 𝑁 ‘, onde 𝑁 ′ é o número de camadas gerenciadas por esse trabalhador (𝑁 ′ = 𝑁 com paralelismo tensorial, enquanto 𝑁 ′ <𝑁 com paralelismo da tubulação).
Tamanho de um buffer de memória virtual: o tamanho máximo de um buffer é 𝐵𝑆 = 𝐵 × 𝐿 × 𝑆 onde B é o tamanho máximo do lote, L é o comprimento máximo do contexto suportado pelo modelo e 𝑆 é o tamanho de um único token por camada K (ou cache V) em um trabalhador. Além disso, 𝑆 = 𝐻 × 𝐷 × 𝑃, onde 𝐻 é o número de cabeças KV em um trabalhador, 𝐷 é a dimensão de cada cabeça de kV e 𝑃 é o número de bytes baseados na precisão do modelo (por exemplo, p = 2 para FP16/BF16). Observe que 𝑆 é constante para uma determinada configuração do modelo.
Considere Yi-34b com FP16 e paralelismo tensorial bidirecional (TP-2). Nesse caso, 𝑁 = 60, 𝐻 = 4, 𝐷 = 128, 𝑃 = 2 (as cabeças de 8 kV de Yi-34b são divididas uniformemente em duas GPUs) e o comprimento máximo do contexto suportado 𝐿 = 200𝐾. Para este modelo, o tamanho máximo do c-cache (ou v-cache) por trabalhador por camada é 𝑆 = 200𝑀𝐵 (200𝐾 ∗ 4 ∗ 128 ∗ 2). Assumindo 𝐵 = 500, o tamanho máximo de cada buffer por trabalhador é 𝐵𝑆 = 100𝐺𝐵 (500 × 200𝑀𝐵). Portanto, o requisito total de memória virtual para 60 camadas de Yi-34b é de 120 buffers de 100 GB cada (total de 12 TB). Observe que a quantidade de espaço de endereço virtual disponível cresce com o número de GPUs, por exemplo, com dois trabalhadores do TP, a quantidade de espaço de endereço virtual disponível é de 256 TB. Portanto, as alocações de memória virtual podem ser satisfeitas facilmente.
5.1.2 Alocação de memória física sob demanda. A Vattion aloca preferencialmente a memória física uma página de cada vez e somente quando uma solicitação usou todas as suas páginas de memória física alocadas anteriormente. Para mostrar como funciona, nos referimos a um exemplo simples na Figura 7. O exemplo mostra como a Vattention gerencia o c-cache (ou v-cache) em uma camada do modelo, assumindo o tamanho máximo do lote de dois. O restante dos buffers K-Cache e V-Cache são gerenciados de maneira semelhante em todas as camadas.
[3] Os sistemas de 64 bits normalmente utilizam 48 bits para endereços virtuais, fornecendo um espaço de memória virtual por processo de 256 TB, que é dividido igualmente entre o espaço do usuário e o espaço do kernel (OS).
Autores:
(1) Ramya Prabhu, Microsoft Research India;
(2) Ajay Nayak, Instituto Indiano de Ciência e contribuiu para este trabalho como estagiário da Microsoft Research India;
(3) Jayashree Mohan, Microsoft Research India;
(4) Ramachandran Ramjee, Microsoft Research India;
(5) Ashish Panwar, Microsoft Research India.
