- LLM in a Flash mantém os parâmetros de LLM maiores que a DRAM na memória flash e traz para a DRAM apenas as partes necessárias, tornando a inferência possível mesmo em dispositivos com memória limitada
- Com base em um modelo de custo de inferência que reflete as características de acesso da memória flash, reduz o volume de dados transferidos e induz leituras de chunks maiores e mais contínuos
- windowing reutiliza neurônios ativados anteriormente, e row-column bundling aproveita a vantagem do acesso sequencial da flash para reduzir gargalos
- Ao combinar as duas técnicas, é possível executar modelos de até 2x o tamanho da DRAM disponível, com inferência 4 a 5 vezes mais rápida na CPU e 20 a 25 vezes mais rápida na GPU em comparação com carregamento simples
- À medida que se combinam reconhecimento de esparsidade, carregamento adaptativo ao contexto e design orientado a hardware, cresce a viabilidade de executar LLMs em dispositivos com restrição de memória
Inferência de LLM baseada em memória flash
- Modelos de linguagem de grande porte apresentam alto desempenho em várias tarefas de processamento de linguagem natural, mas suas exigências de computação e memória são elevadas, o que dificulta sua execução em dispositivos com capacidade de DRAM limitada
- O LLM in a Flash lida com essa limitação armazenando os parâmetros do modelo na memória flash e trazendo sob demanda para a DRAM apenas os dados necessários durante a inferência
- No centro da abordagem está um modelo de custo de inferência ajustado ao funcionamento da memória flash
- Ele é otimizado para reduzir o volume de dados transferidos da flash
- Foi projetado para ler os dados em chunks maiores e mais contínuos
Duas técnicas para reduzir transferência e padrão de leitura
- windowing reutiliza neurônios ativados anteriormente para reduzir o volume de dados que precisa ser transferido da flash para a DRAM
- row-column bundling aumenta o tamanho dos chunks de dados lidos da flash, alinhando-se à característica da memória flash de ter melhor desempenho em acesso sequencial
- Quando usadas em conjunto, as duas técnicas permitem executar modelos com tamanho de até 2x a DRAM disponível
- O ganho de velocidade de inferência em comparação com um método de carregamento simples varia conforme o hardware
- Na CPU, fica 4 a 5 vezes mais rápido
- Na GPU, fica 20 a 25 vezes mais rápido
- Esse design integra reconhecimento de esparsidade, carregamento adaptativo ao contexto e design orientado a hardware para viabilizar a inferência de LLM em ambientes com memória limitada
1 comentários
Opiniões do Hacker News
O artigo se baseia em técnicas de exploração de esparsidade do paper Deja Vu, que já é bem complexo, então levou um tempo para entender
O Deja Vu considera que mesmo modelos com baixa esparsidade nos pesos têm alta “esparsidade contextual” (contextual sparsity). Ou seja, surgem muitos zeros no vetor resultante da multiplicação de matrizes, mas quais posições viram zero depende da entrada
Usando essa esparsidade, dá para pular o carregamento de algumas linhas da matriz e, para obter ganho de desempenho, é preciso prever antecipadamente quais linhas pular; essa previsão pode ser feita com uma matriz de baixo posto
O paper da Apple sugere que essa descoberta ajuda não só no desempenho de carregamento da RAM, mas também no carregamento a partir da memória flash, sem sacrificar muito a largura de banda
A matriz de atenção é relativamente leve, e o alvo que precisa ser carregado de forma esparsa é a FFN. Além disso, prever a saída da camada ReLU, em vez da entrada da FFN, dá uma esparsidade muito melhor. Se for possível prever que “este slot do vetor será negativo depois da multiplicação de matrizes e antes da ReLU”, basta não carregar aquela coluna da matriz e emitir 0
A proposta é que a maioria das linhas da FFN nem precise ser carregada, e que se mantenha, para cada FFN, um cache das linhas usadas recentemente, atualizando-o a partir da flash quando necessário. Há também mais correlações entre o carregamento em chunks e as camadas de projeção, mas o insight central parece ser esse
FFN significa Feed Forward Network e, nos transformers, são os maiores blocos
Fico curioso para saber quanto do modelo pode deixar de ser carregado antes de começar a haver uma diferença real de desempenho
Por exemplo, para manter 90% do desempenho de quando tudo está na RAM, queria saber se basta usar metade da memória, ou se são necessários 90%, ou 95%
No fim, a questão é quão rápido se perde desempenho em relação ao máximo ao reduzir a RAM. O gráfico compara este algoritmo com o algoritmo básico em cenários de pouca RAM, o que é diferente, mas é uma boa pergunta
Se for possível obter bom desempenho sem carregar um modelo inteiro de 8 GB na memória de um celular, isso é claramente útil
Vale a pena ler o paper inteiro, é um trabalho bem interessante: https://arxiv.org/pdf/2312.11514
O ponto enfatizado no paper são duas técnicas complementares para minimizar a transferência de dados e maximizar a vazão da memória flash
Windowing é uma abordagem que reutiliza os valores de ativação dos tokens calculados recentemente e carrega apenas os parâmetros necessários para os últimos tokens, reduzindo o número de requisições de I/O para carregar pesos
Row-column bundling armazena linhas e colunas das camadas de up-projection e down-projection concatenadas, fazendo com que chunks contínuos maiores sejam lidos da flash, e aumenta a vazão ao ler chunks grandes
Em teoria, quando parte do modelo está na flash, o tempo de inferência de um único token deveria ser igual ao tempo de inferência com o modelo inteiro na RAM somado ao tempo de carregar a parte do modelo que está na flash
Estou assumindo que não é necessário escrever de volta na flash, mas não sou especialista em LLMs, então posso estar errado
Se houver muito mais de 10 camadas, parece possível manter apenas uma pequena parte da RAM disponível e carregar uma camada por vez. A maioria dos LLMs tem dezenas de camadas, então isso parece plausível
Se a RAM não for o gargalo durante a inferência, talvez também seja possível fazer transferência DMA da próxima camada da flash para a RAM enquanto a camada atual é inferida. Em um sistema de processador único, isso provavelmente não funcionaria bem por causa do gargalo da RAM
Em um sistema com dois processadores, talvez um processador pudesse carregar a próxima camada na RAM enquanto o outro inferisse a camada anterior, permitindo rodar LLMs muito grandes mesmo com pouca RAM
Estou sentado agora ao lado de uma pilha de peças para montar uma nova máquina de IA para LLMs. É uma z840 com dois processadores, então estou ansioso para mexer diretamente com esse tipo de coisa
Chama a atenção que os dispositivos da Apple têm muito pouca RAM em comparação com dispositivos semelhantes da concorrência
Em parte, isso acontece porque as equipes de software da Apple usam linguagens mais eficientes, como Objective-C; em parte, porque os apps de iOS não precisam mirar uma variedade enorme de resoluções de tela. Assim, há relativamente menos casos de carregar texturas em alta resolução e depois reduzi-las
Além disso, mesmo comprando na escala da Apple, RAM não fica muito mais barata, então aumentar a RAM atinge a margem mais do que adicionar outros recursos
Mas, como LLMs são inerentemente vorazes por RAM, todas essas escolhas acabam voltando. Independentemente da técnica de economia de memória usada, concorrentes com mais RAM poderão colocar modelos maiores, melhores e mais inteligentes
Quero comprar um Mac em breve e estou realmente em dúvida sobre quanta RAM pedir. Fica ainda mais difícil porque o orçamento é limitado. Se não houvesse limite, eu iria para pelo menos 32 GB
Ainda espero que a Apple mude sua política de preços de RAM, mas provavelmente é uma esperança vã
Também dá para ver uma implementação relacionada: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
Além disso, dispositivos da Apple têm um recurso chamado “jetsam”, que libera memória encerrando apps não usados ou em segundo plano para que apps de alta prioridade continuem rodando de forma fluida: https://developer.apple.com/documentation/xcode/identifying-...
Estou aberto a recomendações de notebooks Linux silenciosos ou quase sem ruído. A maioria faz a ventoinha girar forte, e eu abriria mão de parte do desempenho da CPU em troca de silêncio. Também seria bom poder ativar e desativar facilmente um modo silencioso
Até agora, nada que vi chega perto do silêncio do MacBook Air, e eu ficaria feliz em saber de algum produto que prove que estou errado
Naturalmente, seria bom se também fosse mais barato ou tivesse RAM substituível. Uso principalmente o MacBook Air para serviços baseados na web e como terminal remoto para acessar servidores Linux que uso para compilar projetos grandes e para hospedagem doméstica/autogerenciada
É claro que o cronograma foi antecipado, mas não acho que a hipótese deles esteja errada
Entendo este assunto apenas de forma limitada, mas fico me perguntando se esse método permitiria rodar LLMs offline em celulares
Se for possível, isso abriria muitas aplicações interessantes, como moderação de conteúdo assistida por IA sem enviar dados confidenciais para servidores
Por exemplo, ontem apareceu aqui uma GitHub Discussion sobre rodar LLMs em chips Apple A-series (iPhone): https://news.ycombinator.com/item?id=38703161
Gosto do fato de textos recentes chamarem isso de LLM, não de “IA”. Assim dá para saber que o assunto é uma tecnologia específica, não exagero de marketing
Fico curioso sobre como isso difere do FlashAttention. Usar termos parecidos e não explicar a diferença no resumo confunde
Edit: parece ser uma extensão de dois mecanismos diferentes dentro do framework de flash. O título do artigo poderia ter sido melhor, mas isso é explicado nas primeiras páginas
Na conclusão, eu esperava uma seção como “como esse recurso será exposto ao usuário”, mas talvez isso esteja fora do escopo do artigo
Fico curioso se esse recurso virá como uma chamada de API ou configuração do CoreML, por exemplo exigindo definir uma flag use_flash, ou se será uma otimização de runtime invisível ao usuário
Também queria saber se alguém conhece alguma boa apresentação ou talk da Apple explicando o roadmap de desenvolvimento de CoreML, Metal etc.
A Apple comprou uma empresa iraniana?
[0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
Sei que as abordagens são diferentes, mas como ambas aproveitam memória flash, eu esperava que este artigo ao menos mencionasse FlashAttention [1]
[1] https://arxiv.org/abs/2205.14135
Pelo que entendi, FlashAttention diz respeito a padrões de acesso que aproveitam melhor a memória local, especialmente SRAM. Por exemplo, mantendo os dados no cache L1 da CPU ou em uma camada equivalente na GPU
Em outras palavras, FlashAttention trata da parte mais rápida que a DRAM, enquanto este artigo aborda o problema de fazer offloading melhor para uma parte mais lenta que a DRAM
Em “o modelo OPT 6.7B, por exemplo, apresenta uma esparsidade de 97% notável dentro das camadas FFN”, alguém sabe exatamente o que essa métrica significa?
Fico me perguntando se quer dizer que 97% dos valores da camada são zero, ou que ela pode ser comprimida para 3% do tamanho
Mas, como os 3% que ficam ativos não são fixos, não dá para eliminar completamente os 97% restantes. O artigo parece dizer que é possível prever com bastante precisão os 3% ativos e, assim, torná-lo mais rápido sem perder precisão demais