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
7.2 Portabilidade e desempenho para decodificar
Para avaliar o desempenho da decodificação, nos concentramos em cenários de longa data (16K) porque a latência do kernel de atenção se torna significativa apenas para contextos longos[4]. Avaliamos as seguintes configurações:
vllm: Usamos o VLLM v0.2.7 como a linha de base primária. A VLLM foi pioneira na Pagedattion e usa um kernel de pegada personalizada para decodificações, derivadas de Fastertransformer [4].
Fa_paged: Para a segunda linha de base, integramos o kernel do Flashattion à pilha de porções da VLLM. Isso representa um kernel de ponta da Pagedattion de última geração que inclui otimizações como o paralelismo da sequência e a cópia no local de novos vetores de chave e valor no cache KV. Avaliamos os núcleos paginos de VLLM e Flashattion com dois tamanhos de bloco diferentes – 16 e 128 – para capturar o efeito do tamanho do bloco no desempenho.
FA_Vattion: Para a Vattion, integramos o kernel de baunilha da Flashattion na pilha de porções da VLLM. O kernel trabalha com um cache KV praticamente contíguo ao qual alocamos dinamicamente a memória física usando páginas de 2 MB.
A Figura 9A mostra a taxa de transferência de decodificação de Yi-6b, LLAMA3-8B e YI-34B com tamanhos de lote variados em que o comprimento inicial do contexto de cada solicitação é de 16k tokens e geramos 256 tokens para cada solicitação. Calculamos a taxa de transferência de decodificação com base na latência média de 256 iterações de decodificação. Resumimos os principais taises abaixo.
Primeiro, o Vattention supera o VLLM (tamanhos de bloco) e fa_paged (tamanho do bloco 16), enquanto corresponde aproximadamente à melhor configuração do FA_PAGED (tamanho do bloco 128). A melhoria máxima em relação à VLLM é de 1,97 × para Yi-6b, 1,3 × para LLAMA3-8B e 1,6 × para YI-34b. Os ganhos relativos sobre o VLLM também aumentam à medida que o tamanho do lote cresce. Por exemplo, o ganho aumenta de cerca de 1,1 × para 1,97 × à medida que o tamanho do lote aumenta de 1 para 8 para Yi-6b. Isso ocorre porque a latência do cálculo da atenção cresce proporcional ao número total de tokens no lote (veja a Figura 9b), enquanto o custo dos operadores lineares permanece aproximadamente o mesmo [25, 26, 41]. Portanto, a contribuição do kernel de atenção na latência geral – e subsequentemente ganha com um kernel mais eficiente – aumenta com o tamanho do lote. Enquanto o FA_PAGAGED (tamanho do bloco 128) fornece ganhos semelhantes aos da Vattion, observe que o FA_PAGED requer uma nova implementação do kernel da GPU, enquanto a Vattion simplesmente aproveita o núcleo de baunilha da Flashattion.
Segundo, a Figura 9B confirma que a diferença de desempenho entre VLLM e FA_PAGED/Vattention se deve realmente aos núcleos de atenção. Na pior das hipóteses, a latência do melhor kernel da Pagedattion da VLLM (tamanho do bloco 16) é de 2,85 × mais alto para Yi-6b, até 1,45 × para LLAMA-3-8B e até 2,62 × para Yi-34b que o kernel da matéria flash.
Finalmente, a taxa de transferência pode ser sensível ao tamanho do bloqueio, mesmo quando a capacidade de memória não é uma restrição. Por exemplo, conforme discutido no §3.3, o kernel de atenção da VLLM tem uma latência significativamente maior com o tamanho do bloco 128 do que com o tamanho do bloco 16 (veja também a Figura 9B). Na pior das hipóteses, o tamanho do bloco 128 degrada a taxa de transferência da VLLM em 36%. Enquanto o tamanho do bloco tem um menor
Impacto no Flashattion, o uso de um pequeno tamanho de bloco ainda pode prejudicar a taxa de transferência devido a despesas gerais da CPU, principalmente devido à sobrecarga da criação de mesa de blocos para cada iteração (§3.3). Por exemplo, a Flashattion com tamanho de bloco 128 fornece uma taxa de transferência 7% maior que o tamanho 16 do bloco para LLAMA-3-8B (531 vs 494 tokens por segundo com tamanho de lote 32).
[4] Para contextos curtos, o tempo de computação da rede de feed-forward domina a latência de inferência [25]
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.
