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.4 Análise da fragmentação da memória
A Tabela 8 mostra o tamanho do bloco (definido como o número mínimo de tokens em uma página) e quanta memória física pode ser (teoricamente) desperdiçada devido à alocação excessiva no pior caso. O pior caso ocorre quando uma nova página é alocada, mas permanece completamente não utilizada. Além disso, mostramos cada modelo sob duas configurações de TP-TP-1 e TP-2-para destacar o efeito da dimensão TP no tamanho do bloco.
A Vattion aloca a memória física equivalente ao tamanho da página em cada trabalhador do TP, enquanto o requisito de memória física por toque de um trabalhador diminui à medida que a dimensão do TP aumenta (porque as cabeças de KV se dividem entre os trabalhadores do TP).
Portanto, o tamanho do bloco aumenta proporcionalmente com a dimensão TP. A Tabela 8 mostra que isso resulta nos menores tamanhos de bloco de 32 (Yi-34b TP-1) a 128 (Yi-6b TP-2). Em termos da quantidade de memória física, o tamanho da página de 64kb resulta em um desperdício teórico máximo de apenas 4-15 MB por solicitação, que aumenta para 16-60 MB para o tamanho da página de 256kb. No geral, o ponto importante a ser observado é que, ao controlar a granularidade da alocação de memória física, a Vattion torna a fragmentação da memória insignificante. Lembre -se de que o serviço de transferência satura em cerca de 200 tamanho em lote para todos os nossos modelos (Figura 6). Portanto, mesmo em tamanhos de lote tão grandes, os resíduos teóricos máximos de memória são no máximo alguns GBs. Portanto, semelhante ao VLLM, a Vattion é altamente eficaz na redução da fragmentação e permite servir usando tamanhos grandes em lote. No entanto, se necessário, o tamanho da página pode ser reduzido ainda mais para 4KB, que é o tamanho mínimo da página suportado em quase todas as arquiteturas hoje, incluindo o NVIDIA GPUS [28].
Esforço de implementação
A principal vantagem da Vattion é a portabilidade: permite integrar perfeitamente novos kernels de atenção sem ter que escrever uma versão paginada ou alterar a estrutura de servir. Por exemplo, a alternância entre os grãos de preenchimento ou decodificação de flashattion e flashinfer requer apenas algumas linhas de alterações de código, como mostra a Figura 12. Em contraste, na Pagedattion, os desenvolvedores precisam primeiro escrever um kernel de atenção e depois fazer alterações significativas na estrutura de servir. Por exemplo, a integração do flashInfer decodifica os kernels no VLLM exigiu mais de 600 linhas de alterações de código espalhadas por 15 arquivos [21, 22, 24]. A implementação do suporte inicial de paginação no kernel da GPU Flashattion também exigiu cerca de 280 linhas de alterações de código [20] e esforços adicionais para permitir o suporte para tamanhos de blocos menores [16]. Dado o rápido ritmo da inovação no LLMS, acreditamos que é importante reduzir a carga de programação: os sistemas de produção devem ser capazes de aproveitar novas otimizações do operador de atenção sem reescrever o código-semelhante à implementação otimizada das GEMMs é aproveitada por estruturas de aprendizado profundo sem intervenção do programador.
