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.1 Portabilidade e desempenho para preenchimento
Para avaliar a fase de pré -preenchimento, focamos nos kernels de atenção fornecidos pela Flashattion v2.5.6 [9, 33] e FlashInfer v0.0.3 [11, 46]. Não incluímos o VLLM nesses experimentos, porque ele não possui um núcleo de preenchimento próprio, mas usa o kernel do Flashattion. Também não podíamos avaliar o YI-34B porque os kernels flashinfer não suportam o tamanho do grupo KV do YI-34B de 7 [23].
FlashInfer é uma biblioteca que recentemente introduziu um conjunto de kernels de atenção otimizados para diferentes cenários, por exemplo, para
Preencheros em grama-uma otimização proposta em Sarathi [26] e posteriormente adotado em vários sistemas [25, 36, 38]. Sarathi divide os tokens de entrada de um prompt em vários pedaços menores e agenda um pedaço de cada vez, permitindo que um sistema de servir adicione novas solicitações em um lote sem fazer uma pausa decodificada em andamento. Isso ajuda a melhorar a taxa de transferência sem aumentar a latência [25]. A Flashattion e o FlashInfer fornecem kernels para calcular as pontuações de atenção de chunkedprefills com e sem a Pagedattion. Nós os integramos à VLLM e usando o tamanho dos 2048 tokens 2048, medimos o tempo-de-primeiro-token (TTFT) para as seguintes configurações:
Fa_paged: Usa flash_attn_with_kv_cache kernel API da flashattion.
Fi_paged: Usa o kernel da Pagedattion do Flashinfer, representando o kernel baseado em Pagedattion de última geração para a fase de pré-preenchimento.
FA_Vattion: Usa o kernel de preenchimento de baunilha da Flashattion através da API flash_Attn_Func.
Fi_vattion: Usa o kernel de pré -enchimento de baunilha do FlashInfer através da API SINDE_PREFILL_WITH_KV_CACHE.
Ambas as configurações de vattention, portanto, usam kernels que suportam os preenchimentos em um kvcache praticamente contíguo. Adicionamos suporte dinâmico de alocação de memória a eles sem precisar modificar seu código.
A Figura 8 mostra a taxa de transferência de pré-enchimento das quatro configurações para Yi-6b e LLAMA-3-8B. Em todos os casos, a Vattionation oferece uma taxa de transferência consistentemente maior, superando
FA_PAGADO por 1,60 – 3,92 × e Fi_Paged por 1,03 – 1,45 ×. Para o mesmo experimento, a Tabela 6 mostra o TTFT com diferentes comprimentos de contexto. Como o TTFT depende diretamente da taxa de transferência de preenchimento, em comparação com o uso de kernels de baunilha com Vattention, FA_PAGED e FI_PAGED aumentam o TTFT em até 3,92 × (Yi-6b, comprimento de contexto 192k) e 1,45 × (LLAMA-3-8B, contexto 192k), respectivamente.
A fonte do ganho de desempenho de Vattion é dupla nesses cenários. Primeiro, o kernel de baunilha é mais rápido que o núcleo de paginação em flashattion e flashinfer. Embora o kernel paginado da Flashattion não seja otimizado para preenchimento (ele é otimizado para decodificações), o kernel de flashInfer é projetado especificamente para suportar preenchimentos em chunked. No entanto, o núcleo paginado é mais lento que o núcleo de baunilha, conforme discutido no §3.3. Este exemplo ilustra as complexidades da transferência de otimizações críticas de desempenho entre diferentes implementações-mesmo quando as implementações são escritas pela mesma equipe. A segunda fonte de melhoria é a menor sobrecarga da Vattion. Por exemplo, anexar um novo tensor K ou V ao KV-Cache requer uma única operação de cópia tensorada em Vattion, enquanto que em uma implementação paginada requer anexar um bloco por vez. Além disso, o FlashInfer envolve a criação e a exclusão de alguns objetos para suas mesas de blocos compactadas em todas as iterações. A Vattion evita essas despesas gerais porque mantém a contiguidade virtual da KVCache e, portanto, não requer uma tabela de blocos.
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.
