What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
Através de um rigoroso estudo de medição de posicionamento de modelos de linguagem e velocidade de decodificação no Apple Neural Engine, o autor demonstra que a expressão computacional e a codificação de pesos, em vez da arquitetura do modelo isoladamente, ditam a residência e o desempenho do acelerador, levando a um procedimento de design que prioriza a eficiência de codificação para alcançar modelos ternários significativamente menores e mais rápidos.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine um smartphone tentando entender uma conversa. Para fazer isso, ele deve executar um enorme cérebro digital, um modelo de linguagem, diretamente no dispositivo. Para que isso funcione suavemente, o telefone precisa usar um processador especial e ultraveloz, construído justamente para esse tipo de pensamento, em vez de seu cérebro principal de uso geral. O desafio é que esse processador especial é exigente; ele só executará certos tipos de cálculos e se recusará a executar outros, mesmo que sejam matematicamente idênticos. Durante anos, desenvolvedores tentaram adivinhar quais cálculos funcionariam e como torná-los rápidos, muitas vezes baseando-se em regras práticas que acabavam sendo erradas. Eles assumiram que, se um modelo fosse pequeno o suficiente, ele rodaria no processador rápido, ou que diminuir o tamanho dos números sempre ajudaria. Mas ninguém tinha realmente observado o processador para ver o que ele estava realmente fazendo, ou para medir exatamente como o tamanho do modelo e a forma como seus números eram armazenados alteravam sua velocidade.
Um pesquisador chamado Shahir M A decidiu parar de adivinhar e começar a observar. Usando um computador Apple com um chip M1, ele construiu uma série de experimentos para ver exatamente o que acontece quando um modelo de linguagem tenta rodar no processador especial do telefone, conhecido como Neural Engine. Ele não apenas olhou para o que o software dizia que faria; ele mediu a eletricidade e os dados reais movendo-se através do chip para ver o que realmente estava acontecendo. Ele testou dezenas de maneiras diferentes de construir a mesma operação matemática, treinou modelos reais de diferentes tamanhos e alterou a forma como os números dentro desses modelos eram armazenados, variando da precisão padrão até formatos altamente comprimidos de baixa precisão. Seu objetivo era simples: descobrir o que realmente coloca um modelo no processador rápido e quão rápido ele pode falar uma vez que chega lá.
A primeira coisa que ele descobriu foi que o processador não se importa com o que um cálculo significa, apenas com como ele é escrito. Ele descobriu que, se você escrever um tipo específico de normalização — um passo que ajuda o modelo a manter seus números estáveis — de uma certa maneira, o processador o aceita imediatamente e o executa em velocidade máxima. Mas se você escrever o exato mesmo passo matemático usando um conjunto de instruções ligeiramente mais complexo, o processador se recusa a tocá-lo e força o telefone a usar seu cérebro de uso geral mais lento. É como se o processador falasse um dialeto específico de matemática; se você usar o dialeto certo, ele escuta, mas se usar um dialeto diferente, mesmo que o significado seja o mesmo, ele vai embora. Isso significa que a maneira como o desenvolvedor escreve o código é tão importante quanto a própria matemática.
A segunda descoberta, e talvez a mais surpreendente, foi que o tamanho do modelo não é a única coisa que decide se ele pode rodar no processador rápido. Os pesquisadores descobriram que um modelo com cerca de vinte e seis milhões de parâmetros, escrito em precisão padrão, era pequeno demais para rodar no processador especial. Ele era forçado a rodar no cérebro lento, levando mais de um segundo para gerar cada palavra. No entanto, quando pegaram esse exato mesmo modelo e comprimiram os números dentro dele para usar menos bits, o processador subitamente o aceitou. A versão comprimida rodou no processador rápido e gerou palavras em menos de um segundo. Na verdade, para modelos menores, comprimir os números era a única maneira de colocá-los no processador rápido. O processador tinha uma regra oculta: ele não rodaria modelos pequenos a menos que fossem comprimidos. Isso inverteu a suposição comum de que modelos maiores são sempre os que precisam do processador rápido; aqui, os pequenos precisavam da compressão para entrar pela porta.
Uma vez que o modelo estava dentro do processador rápido, a velocidade era determinada quase inteiramente por quanta quantidade de dados precisava ser movida, não pela complexidade da matemática. Os pesquisadores mediram o fluxo de dados e descobriram que, para cada palavra que o modelo gerava, ele tinha que transmitir todo o conjunto de seus pesos — os números que compõem seu conhecimento — através do processador. Isso acontecia para cada única palavra, não importava o quão longa fosse a conversa. Por causa disso, a velocidade estava diretamente ligada a quantos bits havia naqueles pesos. Um modelo com números comprimidos de baixa precisão movia muito menos dados e, portanto, era muito mais rápido. Eles descobriram que um modelo usando números de dois bits era quase três vezes mais rápido do que um modelo usando números padrão, simplesmente porque tinha que mover menos dados. O tipo de matemática que o modelo usava, como se focava mais em atenção ou em convolução, importava muito pouco para a velocidade uma vez que o modelo já estava rodando no processador. A única coisa que importava era o tamanho dos dados sendo movidos.
Os pesquisadores concluíram que a melhor maneira de construir um modelo de linguagem para um telefone é começar pela compressão, não pelo tamanho. Em vez de construir um modelo grande e depois tentar encolhê-lo, deve-se escolher o formato mais comprimido possível primeiro, e então gastar o orçamento de memória adicionando mais parâmetros. Eles descobriram que um modelo com vinte e cinco milhões de parâmetros, usando um tipo específico de matemática comprimida, poderia caber em apenas dez megabytes de espaço e gerar palavras em cerca de seis décimos de milissegundo. Isso era quase dez vezes menor e três vezes mais rápido do que os modelos padrão não comprimidos que os desenvolvedores costumam usar. O estudo mostrou que o caminho para um modelo de linguagem rápido em dispositivos não é sobre tornar o modelo maior ou mais complexo, mas sobre escolher a maneira certa de escrever a matemática e a maneira certa de armazenar os números. Ao medir o fluxo real de dados, eles provaram que a chave para a velocidade não é apenas ter um processador rápido, mas saber exatamente como alimentá-lo.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.