Vattion: eficácia da alocação de memória física para LLMS

Tabela de hyperlinks

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

7.3 Eficácia da alocação de memória física

O alocador de cache de pytorch aloca objetos de memória (por exemplo, tensores) sem exigir uma viagem de ida e volta ao kernel. Por outro lado, a Vattention precisa invocar o motorista do kernel de Cuda enquanto mapeia uma nova página física no cache KV de uma solicitação. Nesta seção, mostramos que, com nossas otimizações, a Vattion pode atender efetivamente aos requisitos das fases de preenchimento e decodificar em um sistema de porção LLM.

A Tabela 7 mostra que, mesmo com o menor tamanho de página de 64kb, a Vattion pode alocar até 7,6 GB por segundo por GPU. Isso é mais do que uma ordem de magnitude maior que a taxa máxima de alocação de memória de 600 MB por segundo dos decodões (Figura 6). Tamanhos de página maiores e dimensões mais altas de TP aumentam a taxa de alocação de memória proporcionalmente. Isso mostra que a Vattion é mais do que capaz de satisfazer a largura de banda de alocação de memória dos decodões.

Além disso, a Figura 10 mostra que nossa otimização da alocação de memória sobreposta com a execução do modelo também oculta o impacto da latência de invocar APIs de CUDA. Este exemplo mostra a latência das iterações de decodificação consecutiva para LLAMA3-8B em execução com TP-1 e tamanho 4. Sem alocação de memória sobreposta com computação, novas páginas para o cache KV são alocadas de forma síncrona que aumentam o

Latência de algumas iterações de 25 milissegundos a 41 milissegundos (≈ 4 milissegundos de latência devido à alocação de memória para uma única solicitação). Observe que esses picos de latência ocorrem após cada 1024 iterações porque usamos o tamanho da página de 2 MB para essas experiências e cada página de 2 MB contém 1024 tokens para esta configuração de modelo. Quando a alocação de memória se sobrepõe à execução do modelo de iteração anterior de decodificação, o efeito de latência está completamente oculto.

Finalmente, como um pré-enchimento pode exigir mais de uma página para o cache KV, também investigamos como diferentes esquemas de alocação de memória afetam a latência de um preenchimento. A Figura 11 mostra que a alocação de memória física síncrona (quando nosso encadeamento de segundo plano, recuperação diferida e otimizações de alocação ansiosa são todas desativadas) podem adicionar até 15% de sobrecarga com tamanho de página de 64kb. Os tamanhos de página maiores amortizam o custo da alocação e reduzem a sobrecarga para o tamanho de 3% (com tamanhos de página de 256kb e 2 MB). A Vattention reduz ainda mais o custo de alocação com recuperação diferida e alocação ansiosa, enquanto sobreposta à alocação de memória com computação. Na maioria dos casos, essas otimizações garantem que uma solicitação recém-chegada possa simplesmente reutilizar as páginas de memória física que foram alocadas para uma solicitação anterior. Portanto, a Vattention incorre na sobrecarga insignificante, com desempenho tão bom quanto o VLLM para preencher.