Como o LLaMA.cpp é possível?

• Graças ao LLaMA.cpp, que reescreveu o código de inferência do LLaMA em C++ puro, ele pode rodar em diversos tipos de hardware, como Pixel 5, MacBook Pro com M2 e Raspberry Pi
• Modelos grandes normalmente exigem GPUs caras, então como isso é possível?
• GPUs são vantajosas para deep learning por causa de sua grande largura de banda de memória e capacidade de computação, mas a largura de banda de memória frequentemente se torna o gargalo da inferência
  • Isso acontece porque, para o cálculo real, os dados precisam ser movidos da memória HBM (RAM) para a memória on-chip
• A quantization (quantização) é importante no uso de RAM para os pesos do LLaMA
  • Ao reduzir a precisão, é possível diminuir drasticamente a quantidade de memória necessária para armazenar o modelo
  • Com a quantização, reduz-se a quantidade de memória necessária para armazenar o modelo, permitindo que ele caiba na memória de GPUs padrão de datacenter e GPUs de consumo de ponta
• A largura de banda de memória é o fator limitante em quase todas as tarefas relacionadas ao sampling de transformers
• Ao reduzir os requisitos de memória com métodos como a quantização, torna-se muito mais fácil fazer o serving
• Este também é mais um motivo para usar distillation ou "treinar modelos menores por mais tempo"

[breezymind]

Na minha máquina local, carreguei o llama2 com o LlamaCpp e fiz um teste de embeddings.

https://breezymind.com/llamacpp-embedding

[xguru]

O primeiro comentário no HN é útil

"Para quem estiver curioso, há um custo ao quantizar um modelo.
https://oobabooga.github.io/blog/posts/perplexities/

Basicamente, a precisão cai um pouco e podem surgir respostas estranhas, com maior chance de sair do esperado ou alucinar. Mas, quanto maior o número de parâmetros, menor é a perda de qualidade. Então, quando o modelo é muito grande, essa diferença se torna praticamente desprezível. Além disso, esse é apenas o custo da inferência. Treinamento é um problema totalmente diferente e exige muito mais poder computacional.

Mesmo assim, estamos vendo desempenho no nível do GPT-3 em um único rack de servidor. É um feito impressionante, considerando que, até apenas 1 ano atrás, esse tipo de IA era literalmente algo quase mágico e só podia rodar em grandes datacenters. Largura de banda e capacidade de memória provavelmente são mais fáceis de ampliar do que computação bruta, pelo menos no meu entendimento limitado, então talvez em breve realmente tenhamos dispositivos "inteligentes"."

[GN⁺]

Comentários do Hacker News

• Artigo sobre o custo de quantizar o modelo, a perda de precisão causada por isso e a possibilidade de respostas anormais. No entanto, quanto mais parâmetros o modelo tiver, menos importante essa perda se torna.
• Artigo destacando o excelente desempenho do GPT3, que agora pode rodar em um único rack de servidor, um grande avanço em comparação com a IA que no ano passado exigia um grande data center.
• Texto apontando que a geração de tokens é serial e limitada por largura de banda, mas a inserção de prompts não é, podendo ser executada em lotes de 512+.
• O Llama.cpp agora tem quantização de ~4 bits que não afeta muito a complexidade. O Q6_K tem complexidade quase igual à do FP16, mas é muito menor.
• A verdadeira mágica do Llama.cpp está na divisão do modelo, permitindo que pequenas GPUs discretas façam offload completo da inserção de prompts e de parte da inferência do modelo. Isso é algo único no campo da IA generativa.
• Os backends de GPU (OpenCL, Metal, CUDA, em breve ROCm e Vulkan) são a forma preferida de executar o Llama.cpp. Sem eles, é impossível rodar 70B em um desktop ou 33B em um notebook com 16GB de RAM.
• O projeto é elogiado pela facilidade de extensão com Go, Python e outros runtimes. Com isso, foram criadas ferramentas para carregar e executar vários modelos em Go e servi-los via API REST.
• Executar inferência em CPUs modernas com AVX2 é mais lento do que em GPU, mas oferece a vantagem de poder ter uma única região longa e contínua de RAM. No entanto, quantizar para 4 bits e não haver opção de executar inferência com algo diferente de fp32 em CPUs x86_64 é uma grande desvantagem.
• O artigo menciona a replicação bem-sucedida de um dataset 13B em um único Pi4 8gig e de um dataset 65B em três nós pi4, mostrando a acessibilidade da técnica.
• O artigo é criticado por tratar as unidades de forma descuidada ao discutir números de latência.
• O artigo levanta a questão de por que fabricantes de chips incluem tantas unidades funcionais nos chips quando a maior parte das cargas de trabalho é limitada por memória.
• O artigo é elogiado por trazer conteúdo único, difícil de encontrar com frequência fora do Hacker News.
• O texto discute as limitações da geração de tokens limitada por memória em decodificadores transformer e demonstra expectativa por modelos futuros mais amigáveis ao hardware.
• O artigo questiona por que o hardware especializado foi projetado dessa forma, considerando o importante gargalo de largura de banda de memória, e se mudanças de paradigma em software poderiam alterar esse equilíbrio.