notícias

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Relatório do coração da máquina

Departamento Editorial de Coração de Máquina

Ser preguiçoso faz você trabalhar melhor.

O Llama 3.1 acaba de ser lançado, você já experimentou? Mesmo que o seu PC tenha as especificações mais recentes, você ainda poderá enfrentar um atraso significativo ao executar a menor versão de 8B. A fim de melhorar a eficiência do raciocínio do modelo, os pesquisadores criaram uma variedade de métodos, mas muitos deles farão com que o modelo sacrifique alguma precisão.

Recentemente, uma equipe de pesquisa da Apple e Meta AI propôs um novo método que pode aumentar a velocidade de inferência do estágio de pré-preenchimento do Llama 2 para mais de 2 vezes, garantindo que a precisão não caia significativamente. A aceleração de 3.1 fornece alguma inspiração. Eles chamam essa abordagem de LazyLLM, que significa Lazy Large Language Model.

Título do artigo: LazyLLM: Poda dinâmica de token para inferência eficiente de LLM de contexto longo

Endereço do artigo: https://arxiv.org/abs/2407.14057

Então, como eles fazem o LLM ser preguiçoso? Para entender seu método, primeiro precisamos saber qual é o processo de inferência LLM baseado em prompt padrão. Simplificando, o processo é dividido em duas etapas: pré-preenchimento e decodificação, conforme mostra a Figura 1.

Na fase de pré-preenchimento, o modelo calcula e salva o cache KV de cada token no prompt e prevê o primeiro token. Chamamos o tempo gasto na fase de pré-preenchimento de “tempo até o primeiro token (TTFT)”.

A fase de pré-preenchimento é seguida pela fase de descodificação. Neste estágio, o modelo usa novamente o KV armazenado em cache para decodificar iterativamente o próximo token até que o critério de parada seja atendido.

Durante a fase de pré-preenchimento, todas as camadas do Transformer usam todos os tokens no prompt. O TTFT pode ser lento quando o prompt é longo porque o melhor LLM atual baseado em Transformer é profundo e amplo, e o custo da atenção computacional cresce quadraticamente com o número de tokens no prompt. Por exemplo, Llama 2 (versão 7B) empilha 32 camadas de Transformers e a dimensão do modelo é 4096. Neste caso, o TTFT requer 21 vezes o tempo de parede de cada etapa de decodificação subsequente, o que representa aproximadamente 23% do tempo total de geração no benchmark LongBench.

Portanto, para tornar a inferência LLM eficiente, otimizar o TTFT é uma etapa muito crítica.

Embora a otimização de inferência LLM seja uma área de pesquisa ativa, muitos métodos se concentram em melhorar a velocidade de inferência do estágio de decodificação. Os pesquisadores têm prestado pouca atenção à melhoria do TTFT. Alguns resultados de pesquisas baseadas em compressão podem melhorar implicitamente o TTFT, reduzindo o tamanho do LLM.

Outra direção de pesquisa é melhorar o TTFT na arquitetura estática do Transformer. Para esta direção de pesquisa, surge naturalmente uma questão: Todos os prompt tokens são essenciais na geração do primeiro token?

A Figura 2 mostra os resultados da análise LLM no benchmark LongBench.

Pode-se observar que para o primeiro token gerado, as pontuações de atenção dos tokens de entrada são muito esparsas, o que mostra que muitos tokens no prompt de entrada são redundantes e, mesmo que sejam removidos, não afetarão a previsão do próximo. símbolo. Esta observação é a base para o LazyLLM proposto pela equipe.

As vantagens do LazyLLM incluem ampla gama de aplicações, sem necessidade de treinamento e bons resultados. A Figura 3 compara o LLM padrão e o LazyLLM.

LazyLLM

A Figura 4 mostra a estrutura geral do LazyLLM.

A partir do contexto completo, o LazyLLM irá remover gradualmente os tokens, reduzindo gradualmente o número de cálculos usados ​​para obter o modelo final. Observe que o LazyLLM permite que o modelo selecione diferentes subconjuntos de tokens em diferentes etapas de geração, mesmo que alguns deles possam ter sido removidos nas etapas anteriores. Em comparação com a remoção estática (todos os tokens são removidos de uma vez), a remoção dinâmica otimiza a previsão do próximo token em cada etapa de geração, o que ajuda a manter o desempenho do modelo.

Remoção progressiva de tokens

Alguns estudos anteriores usaram com sucesso a poda de tokens para otimizar a inferência do LLM. No entanto, esses métodos precisam acumular mapas de atenção completos dos primeiros tokens previstos, a fim de analisar a importância dos tokens imediatos antes do início da poda. Portanto, eles não são adequados para reduzir o TTFT porque ainda precisam calcular todos os caches KV durante a fase de pré-preenchimento.

Em comparação, o LazyLLM é "muito preguiçoso" e calculará apenas tokens que são importantes para prever o próximo token a partir da primeira iteração de inferência (etapa de pré-preenchimento).

Na primeira iteração, um desafio importante foi determinar a importância de cada token. Inspirada em pesquisas anteriores que mostram que os estados ocultos dos tokens evoluem à medida que passam pelas camadas do Transformer, a solução da equipe é usar a remoção de tokens camada por camada em cada etapa de geração. Especificamente, eles usam o mapa de atenção de cada camada para determinar a importância do token de entrada para o token a ser previsto.

Depois de calcular a pontuação de confiança do token, outro problema difícil é determinar o limite para a remoção do token.

Especificamente, para diferentes camadas e diferentes tarefas, este limite pode mudar à medida que a pontuação de atenção muda. A solução da equipe é usar a estratégia de seleção do percentil top-k. Especificamente, se a pontuação de confiança de um token for menor que o k-ésimo percentil no token de entrada, ele será removido. Depois que um token é removido, ele não participa mais do cálculo de todas as camadas subsequentes.

Ou seja, os tokens usados ​​pelas camadas subsequentes são um subconjunto dos tokens usados ​​pelas camadas anteriores.

Experimentos posteriores mostram que quando a posição da camada de poda e o número de tokens podados forem diferentes, o desempenho também mudará. Especificamente, para a mesma camada do Transformer, à medida que mais e mais tokens são removidos por poda, o desempenho do modelo diminuirá gradualmente.

Eles também descobriram que, em comparação com a poda nas camadas iniciais, foi alcançado um melhor desempenho quando a poda foi realizada nas camadas posteriores, indicando que as camadas posteriores são menos sensíveis à poda simbólica. Para equilibrar melhor a velocidade e a precisão, a equipe usou a poda progressiva conforme mostrado na Figura 4, retendo mais tokens nas camadas iniciais e, em seguida, reduzindo gradualmente o número de tokens à medida que fluem para as camadas posteriores.

Cache auxiliar (cache auxiliar)

Não há cache KV no estágio de pré-preenchimento e cada token é representado em um estado oculto. Portanto, a remoção progressiva de tokens pode ser alcançada removendo o estado oculto dos tokens removidos. No entanto, estender a remoção progressiva de tokens às etapas de decodificação subsequentes não é simples. A razão é que cada etapa de decodificação usa o buffer KV calculado no estágio de pré-preenchimento para calcular a atenção. Como o LazyLLM realiza a remoção progressiva do token no estágio de pré-preenchimento, o KV de um token que é removido em uma determinada camada não aparecerá no cache KV da próxima camada.

Como lembrete, a estrutura LazyLLM permite que cada etapa de geração escolha um subconjunto diferente de tokens da sequência completa de tokens de entrada em cada etapa, independentemente de terem sido removidos nas etapas anteriores. Por exemplo, na etapa de decodificação subsequente, os tokens removidos que não existem no cache KV podem ser selecionados novamente para cálculo de atenção. Nesse caso, o modelo não pode recuperar o cache KV para esses tokens.

Uma solução intuitiva para isso é passar os tokens pela origem do Transformer. No entanto, isso resulta na contagem dupla do mesmo token e, em última análise, diminui a velocidade geral de geração.

Para resolver este problema, a equipe introduziu outro cache além do cache KV original: Aux Cache (cache auxiliar).

Se os KVs que foram tokens removidos (como T4 e T7 na Figura 4) não aparecerem no cache KV das camadas subsequentes, seus estados ocultos serão salvos pelo Cache Aux para recuperação em iterações subsequentes.

Conforme mostrado na Figura 4, em cada etapa de decodificação, cada camada do Transformer primeiro recupera o cache KV dos tokens anteriores (se existir). Para os tokens que não estão no cache KV, seus estados ocultos são recuperados diretamente do Aux Cache da camada anterior, sem a necessidade de passar pela camada anterior novamente. Aux Cache garante que cada token seja calculado no máximo uma vez em cada camada do Transformer e também garante que o LazyLLM seja mais rápido que o LLM padrão no seu nível mais lento.

experimentar

A equipe testou essa nova abordagem “preguiçosa” em dois grandes modelos de linguagem: Llama 2 7B e XGen 7B. O LLM padrão para comparação é o mesmo modelo de ponto de verificação pré-treinado lançado publicamente, sem qualquer treinamento adicional.

O benchmark experimental é o LongBench, um benchmark multitarefa para compreensão longa de conteúdo. O benchmark LongBench contém 16 conjuntos de dados e envolve 6 tarefas, incluindo perguntas e respostas de documento único, perguntas e respostas de vários documentos, resumo, aprendizado rápido, tarefas de síntese e conclusão de código.

A métrica de avaliação é a eficácia e eficiência de cada método em termos de aceleração TTFT versus compensação de precisão.

resultado

A Tabela 1 fornece os resultados de aceleração e precisão do TTFT para LazyLLM, LLM padrão e outros métodos de linha de base.

Nesta tabela, a linha de base refere-se à inferência padrão do LLM. A eliminação aleatória de tokens refere-se à execução de remoção aleatória de tokens. A remoção de token estático refere-se à execução de uma remoção única no token de entrada com base no método de atenção das camadas anteriores do Transformer durante o estágio de pré-preenchimento. Compactação de prompt é o método de compactação de prompt, que usa LLM para remover redundância no contexto de entrada.

Como pode ser visto na Tabela 1, o LazyLLM é amplamente superior na aceleração TTFT, enquanto a diminuição na precisão é basicamente insignificante. Deve-se ressaltar que o uso do LLM para compactar prompts requer muitos cálculos. Portanto, embora o Prompt Compression torne a inferência mais rápida, seu TTFT real é mais longo que o LLM padrão.

Impacto na velocidade geral de construção

Para avaliar o impacto do novo método na velocidade geral de geração, a equipe analisou a porcentagem de tokens de prompt usados ​​nos cálculos e na aceleração de geração, consulte a Tabela 2.

Pode-se observar que a proporção de tokens utilizados nos cálculos do LazyLLM é sempre inferior a 100%, o que mostra que o LazyLLM não utilizou todos os tokens no prompt no final da geração, mas teoricamente o modelo pode utilizar todos os tokens. Isso pode fornecer aceleração adicional ao processo geral de geração para diferentes tarefas.

Taxas de queda em diferentes camadas

A equipe também analisou o impacto da localização da camada de remoção e o número de tokens removidos. Os resultados são mostrados na Figura 6.

Pode-se observar que quando a poda é realizada na mesma camada do Transformer, quanto menos tokens sobrarem, pior será o desempenho do modelo. Isso também é consistente com nossa compreensão intuitiva. Além disso, em comparação com a execução da poda na camada anterior do Transformer, a poda nas camadas posteriores resultará em melhor desempenho, o que mostra que as camadas posteriores são menos sensíveis à poda de token.

Com base nessas observações, pode-se dizer que a eficácia da poda progressiva de tokens está comprovada.

Crescimento progressivo de KV

Por fim, a equipe também tentou entender os aspectos internos do modelo usando lógica de poda de tokens. Especificamente, eles querem saber a proporção de uso cumulativo de tokens de prompt e a proporção correspondente não utilizada. Este "uso cumulativo de token" pode ser definido de forma equivalente como o tamanho do cache KV em cada etapa. A Figura 7 mostra o uso cumulativo desses tokens de prompt em cada estágio do LazyLLM.

Este resultado apoia a hipótese de que muitos tokens nunca serão selecionados pelo modelo (mesmo que o modelo pudesse, teoricamente, usar todos os tokens no prompt.

Considerando que o modelo ainda consegue manter a precisão na execução das tarefas, pode-se concluir que o modelo pode efetivamente descartar tokens que não afetam a qualidade da saída.