[Tradução] Um estudo abrangente sobre Small Language Models (SLM)

(discuss.pytorch.kr)

10 pontos por ninebow 2024-10-29 | Ainda não há comentários. | Compartilhar no WhatsApp

Um estudo abrangente sobre Small Language Models (SLM) (Small Language Models: Survey, Measurements, and Insights)

Introdução ao artigo

Os avanços recentes em modelos de linguagem têm se dividido em duas tendências. A primeira é a dos grandes modelos de linguagem (LLM, Large Language Model), operados em grandes data centers com o uso de milhões de GPUs. Esses modelos lidam com tarefas linguísticas avançadas e têm como objetivo resolver problemas complexos, como os da ciência, com o uso de inteligência artificial. No entanto, esses LLMs exigem custos elevados e enormes recursos computacionais, o que torna sua implantação em dispositivos pessoais pouco realista.

Por outro lado, os pequenos modelos de linguagem (SLM, Small Language Model) foram projetados para serem implantados em dispositivos com restrições de recursos, como smartphones, tablets e wearables. O objetivo dos pequenos modelos de linguagem é tornar a IA facilmente acessível a todos, oferecendo uma inteligência artificial prática e com boa relação custo-benefício. Este artigo é o primeiro levantamento abrangente sobre SLMs e analisa os pequenos modelos de linguagem publicados nos últimos anos sob as perspectivas de inovação técnica, desempenho e custo de execução no dispositivo.

Estrutura, conjuntos de dados e treinamento dos Small Language Models (SLM)

Visão geral dos Small Language Models (SLM, Small Language Model)

Os SLMs são menores do que os modelos de linguagem com grande número de parâmetros, mas ainda assim demonstraram desempenho em várias tarefas, como raciocínio de senso comum, resolução de problemas matemáticos e aprendizado em contexto. Isso mostra o potencial de uma inteligência artificial que pode ser executada diretamente no dispositivo.

Neste estudo, foram examinados os SLMs que vêm aumentando rapidamente desde o fim de 2023, e 59 SLMs foram selecionados de acordo com os critérios abaixo para análise de desempenho, custo e outros aspectos:

O tamanho dos modelos SLM foi definido como estando entre 100M e 5B, e apenas modelos com pesos abertos e passíveis de avaliação foram considerados.
Para garantir bom desempenho e viabilidade de implantação real, foram considerados apenas modelos com arquitetura Transformer decoder-only. Ou seja, arquiteturas como RWKV e Mamba não foram incluídas.
Como esta análise se concentra no conhecimento básico obtido no processo de pré-treinamento, foram considerados apenas modelos-base (Base Model), excluindo modelos disponíveis apenas em versões ajustadas por instrução (Instruct Fine-tuned), como Microsoft Phi e StabilityAI StableLM.
Além disso, também foram excluídos modelos derivados obtidos por fine-tuning de modelos pré-treinados.

A lista de modelos selecionados com base nos critérios acima é a seguinte:

Arquitetura dos modelos SLM (Model Architecture)

A arquitetura dos modelos SLM é baseada em Transformer, com várias variações. O núcleo da arquitetura Transformer é a atenção multi-head (Multi-Head Attention, MHA) e a rede neural feed-forward (Feed-Forward Neural Network, FFN). A MHA permite focar em diferentes partes dos dados de entrada, aumentando a eficiência do processamento paralelo. Nos modelos mais recentes, vêm sendo exploradas várias abordagens no mecanismo de atenção, na FFN e nas funções de ativação, como as seguintes:

Mecanismos de atenção (Attention Mechanisms):
- Atenção multi-head (Multi-Head Attention, MHA): mecanismo central do Transformer que permite atender simultaneamente a várias partes dos dados de entrada.
- Atenção por consulta em grupo (Group-Query Attention, GQA): abordagem que agrupa vários valores de consulta para reduzir a complexidade computacional da atenção.
- Atenção por múltiplas consultas (Multi-Query Attention, MQA): abordagem que reduz a complexidade computacional ao permitir diferentes projeções de chave e valor para cada consulta.
Rede neural feed-forward (Feed-Forward Network, FFN):
- FFN padrão (Standard FFN): estrutura de rede simples composta por duas camadas.
- FFN com gate (Gated FFN): estrutura que inclui uma camada adicional de gate para melhorar o desempenho.
Taxa de expansão dimensional da rede feed-forward (The intermediate ratio of the FFN): é o valor que expressa, em forma de proporção, o tamanho da camada oculta (hidden layer) em relação ao tamanho da dimensão de entrada, sendo comumente usado para representar a taxa de expansão dimensional. Quanto maior essa proporção, mais padrões complexos a FFN pode aprender, mas maior também é o custo computacional. Em FFNs padrão, o valor costuma ser em torno de 4; em FFNs com gate, a proporção varia entre 2 e 8.
Funções de ativação (Activation Functions): nos SLMs, são usados principalmente ReLU (Rectified Linear Unit), GELU (Gaussian Error Linear Unit), $GELU_{tanh}$ e SiLU (Sigmoid Linear Unit). Em 2022, o ReLU era o mais usado; em 2023, o GELU e suas variantes; e, em 2024, o SiLU passou a ser a função de ativação mais amplamente utilizada.
Normalização de camada (Layer Normalization): na normalização de camada, são usados LayerNorm e RMSNorm. O RMSNorm vem sendo adotado cada vez mais, o que contribui para aumentar a estabilidade do treinamento do modelo.
Tamanho do vocabulário (Vocabulary Size): o tamanho do vocabulário se refere ao número de tokens únicos que o SLM consegue reconhecer. Foi observado que os SLMs recentes geralmente têm vocabulários com mais de 50 mil itens, e que vocabulários maiores melhoram o desempenho.

Para os 59 modelos selecionados anteriormente, a evolução ao longo do tempo da distribuição dessas seis variações pode ser resumida da seguinte forma:

Ao analisar essas estruturas de modelo, foi possível observar as inovações em arquitetura de modelo (Model Architecture Innovations):

Compartilhamento de parâmetros (Parameter Sharing)
- O compartilhamento de parâmetros é uma técnica usada em grandes modelos de linguagem (LLMs) para reutilizar o mesmo conjunto de pesos em várias camadas ou componentes da rede. Essa abordagem pode reduzir significativamente o número de parâmetros do modelo, levando a treinamento e inferência mais eficientes sem perda de desempenho.
- Compartilhamento entre embedding e lm_head (Embedding-lm_head sharing): compartilhar os pesos do embedding com a camada final lm_head é a técnica de compartilhamento de pesos mais comum. Trata-se do compartilhamento da camada de embedding de palavras e não tem qualquer relação com RoPE (Rotary Position Encoding). Modelos como Gemma e Qwen usam essa técnica.
- Compartilhamento de attention/FFN por camada (Layer-wise Attention/FFN sharing): esse método reutiliza o mesmo conjunto de pesos em várias camadas do modelo. É algo comum em SLMs/LLMs nos quais todas as camadas Transformer compartilham os mesmos parâmetros. Por exemplo, o MobiLLaMA compartilha os pesos da FFN em todos os blocos Transformer, e o MobileLLM compartilha os pesos de Attention e FFN entre dois blocos Transformer adjacentes.
Escalonamento de parâmetros por camada (Layer-wise Parameter Scaling)
- Essa técnica foi proposta e usada no OpenELM. Os SLMs tradicionais usam a mesma configuração para cada camada Transformer do modelo, de modo que os parâmetros são alocados uniformemente entre as camadas. Diferentemente desses modelos, cada camada Transformer do OpenELM tem uma configuração diferente (por exemplo, número de heads e dimensão da FFN), permitindo usar quantidades variadas de parâmetros em cada camada. Com isso, o OpenELM consegue aproveitar melhor o orçamento de parâmetros disponível (available parameter budget) para atingir maior precisão.
Compensação de não linearidade (Nonlinearity Compensation)
- O PanGu-$\pi$ analisa modelos de linguagem recentes com o objetivo de resolver o problema de colapso de características (feature collapse problem). Esse problema ocorre no aprendizado de representações de alta dimensão, como em LLMs, quando o modelo aprende características (features) idênticas ou muito semelhantes para entradas diferentes. Para resolver isso, o PanGu-$\pi$ compensa a não linearidade de funções de ativação como GELU e ReLU, além de escalar a magnitude dos valores de saída das camadas para manter constante a amplitude de variação desses valores.

> #### Principais insights: há duas observações centrais sobre a arquitetura dos SLMs:
> 1. Em agosto de 2024, a arquitetura típica de SLM adota GQA (Group-Query Attention), FFN com gate (Gated FFN) usando a função de ativação SiLU, taxa de expansão do FFN (Intermediate Ratio of FFN) entre 2 e 8, RMSNorm e tamanho de vocabulário (Vocabulary Size) acima de 50 mil. No entanto, essas configurações são em grande parte empíricas e não passaram por validação rigorosa e pública.
> 2. A inovação na arquitetura Transformer para SLMs é limitada. Não foram observadas evidências fortes de que outras técnicas, além do compartilhamento entre Embedding e lm_head, sejam superiores à estrutura Transformer tradicional (Vanilla Transformer). Além disso, elas também não são amplamente adotadas nem pesquisadas por vários grupos de pesquisa ou empresas, o que exige validação futura.

Conjunto de dados de treinamento (Training Dataset)

O desempenho dos SLMs depende fortemente do conjunto de dados usado no treinamento. Este estudo analisou 12 conjuntos de dados públicos usados por modelos SLM:

Nome	Número de tokens	Domínios principais	Descrição e uso
The Pile	825B	ciência, artigos acadêmicos, texto da web, documentos jurídicos	Conjunto de dados que combina vários datasets menores, incluindo textos de múltiplos domínios, usado para melhorar a capacidade geral de compreensão do modelo.
FineWeb-Edu	1.3T/5.4T	texto educacional, livros didáticos, materiais de ensino	Grande conjunto de dados composto por textos educacionais filtrados do FineWeb, usado para melhorar o desempenho do modelo em tarefas ligadas a aprendizado e ao domínio educacional.
StarCoder	35B	código Python	Conjunto de dados que inclui código escrito na linguagem de programação Python, usado para treinar modelos em geração de código e tarefas relacionadas à programação.
Cosmopedia	25B	texto sintético, materiais educacionais	Conjunto de dados composto por texto sintético, incluindo livros didáticos, posts de blog, histórias e artigos do WikiHow, ajudando o modelo a aprender diversos estilos de escrita e contextos.
RefinedWeb	5T	documentos da web, artigos de notícias, blogs, documentação técnica	Conjunto de dados de alta qualidade com dados da web extraídos do CommonCrawl e filtrados de forma rigorosa, usado para aprender conhecimento amplo de domínio em tarefas de processamento de linguagem natural.
RedPajama	1.2T	dados da web, notícias, redes sociais	Inclui um enorme volume de dados textuais extraídos de snapshots do CommonCrawl e é usado no treinamento de modelos baseados em texto da web.
Dolma	-	texto em inglês com remoção de duplicatas	Corpus em inglês com duplicatas removidas usando o algoritmo MinHash, utilizado para otimizar o desempenho do modelo com dados mais limpos ao eliminar textos repetidos.
WuDaoCorpora	4T	texto em chinês	Grande corpus baseado em dados em chinês, com 3T tokens de dados de treinamento e 1.08T caracteres chineses, usado no treinamento de modelos de linguagem em chinês.
RoBERTa CCNewsV2	-	artigos de notícias	Versão atualizada do dataset de notícias do CommonCrawl, usada em tarefas de processamento de linguagem natural baseadas em dados de notícias recentes.
PushShift Reddit	-	dados de redes sociais (posts do Reddit)	Dados coletados de uma plataforma que reúne, analisa e armazena dados do Reddit, usados para treinamento de modelos de linguagem conversacionais e de interação em redes sociais.
DCLM-baseline	1.35T	texto da web	Corpus padronizado extraído do Common Crawl, usado como dataset para modelos de linguagem pré-treinados e adequado para várias tarefas de avaliação.
CulturaX	6.3T	texto multilíngue	Enorme conjunto de dados multilíngue composto por 167 idiomas, usado como material textual em larga escala para treinamento de modelos multilíngues.

Ao observar as tendências de uso de datasets de pré-treinamento pelos SLMs analisados entre 2022 e 2024, temos o seguinte:

Em 2022 e 2023, o dataset de pré-treinamento mais amplamente usado foi o The Pile, mas recentemente mais datasets vêm sendo propostos, ampliando as opções disponíveis. Em 2024, o The Pile já não está mais sendo usado no pré-treinamento de SLMs, enquanto datasets como RefinedWeb e RedPajama estão se tornando cada vez mais populares. Isso mostra que esforços de pesquisa e engenharia para construir datasets de pré-treinamento de melhor qualidade estão em pleno andamento.

Em seguida, foi analisado o desempenho dos SLMs de acordo com o dataset de pré-treinamento utilizado. Os SLMs lançados nos últimos três anos foram classificados em quatro grupos por número de parâmetros (<1B / 1B-1.4B / 1.5-2B / 2.5B-3B) e, dentro de cada grupo, ordenados pela acurácia média (média da acurácia em dois tipos de tarefas: raciocínio/compreensão de senso comum e resolução de problemas), como mostrado abaixo:

Esses resultados mostram que dois datasets lançados recentemente, DCLM(DataComp-LM) e FineWeb-Edu, apresentam desempenho superior em comparação com outros datasets. Uma característica em comum entre esses dois datasets é a adoção de filtragem de dados baseada em modelos.

Além disso, embora capacidade de programação não seja a principal tarefa de SLMs implantados em dispositivos, dados de código costumam estar incluídos em datasets de pré-treinamento como o StarCoder. Isso pode estar relacionado à crença geral de que dados de código ajudam a melhorar a capacidade de raciocínio do modelo.

Na sequência, foram analisados o número de tokens usados no pré-treinamento e o tamanho do modelo e o número de tokens usados no pré-treinamento e a acurácia média.

Primeiro, segundo a Lei de Chinchilla (Chinchilla Law), que estudou a relação entre o tamanho do modelo e a quantidade de dados usada no treinamento (número de tokens), a proporção ideal entre número de parâmetros do modelo e número de tokens de treinamento deveria ser de cerca de 20. Por exemplo, para um modelo de 1B, seria necessário um dataset de treinamento com escala de 20B tokens.

Como resultado da análise estatística do tamanho e do número de tokens de treinamento dos SLMs lançados entre 2022 e 2024 (figura abaixo, à esquerda, (a)), em geral quanto maior o modelo, maior é o número de tokens usados no treinamento, e os modelos mais recentes tendem a usar mais tokens de treinamento. Um ponto digno de nota é que, independentemente do tamanho do modelo, os SLMs estão sendo treinados com um número de tokens muito superior ao proposto pela Lei de Chinchilla (em geral, mais de 1.5T).

Ao analisar o número de tokens usados no pré-treinamento dos SLMs e a acurácia média (figura abaixo, à direita, (b)), observa-se que, em geral, esses dois indicadores têm correlação positiva (positive correlation), algo especialmente evidente quando o número de tokens de treinamento é inferior a 700B. No entanto, quando os tokens de treinamento ultrapassam 1T, a correlação se torna fraca, porque a qualidade dos dados de treinamento passa a ser mais importante do que a quantidade de tokens usados no treinamento.

> #### Principais insights: há duas observações principais sobre os conjuntos de dados de treinamento de SLM:
> - A qualidade dos dados de treinamento é extremamente importante para o desempenho dos SLMs e vem recebendo cada vez mais atenção nas pesquisas recentes sobre SLM. Em geral, o impacto da qualidade dos dados em SLMs costuma ser maior do que o da quantidade de dados e da arquitetura do modelo. Uma tendência notável nas pesquisas sobre datasets é o uso de filtragem baseada em modelos, com FineWeb-Edu (1.3T/5.4T) e DCLM-baseline (4T) como exemplos principais. Os SLMs treinados com esses dois datasets mostraram desempenho competitivo em comparação com SLMs treinados em datasets fechados.
> - Recentemente, os SLMs vêm sendo treinados com grandes volumes de tokens de treinamento (geralmente 1.5T ou mais), independentemente do tamanho do modelo. Em alguns casos, usa-se até uma quantidade menor de dados. (Ex.: o Qwen2-0.5B usou 12T de tokens, enquanto o Qwen2-1.5B usou apenas 7T.) Isso significa que eles foram treinados de forma bastante “excessiva” (over-training) em relação à lei de Chinchilla, e esse treinamento excessivo é usado para implantar SLMs mais poderosos investindo mais tempo de treinamento para obter melhor desempenho.

Algoritmo de treinamento (Training Algorithm)

Existem vários algoritmos para o treinamento de SLMs. Entre os principais estão Maximal Update Parameterization (μP), Knowledge Distillation e a estratégia de Two Stage Pre-training.

Maximal Update Parameterization (μP): garante treinamento estável independentemente da largura das camadas do modelo ao controlar a inicialização do modelo, a taxa de aprendizado por camada e a magnitude das ativações. Esse método não só melhora a estabilidade do treinamento, como também aumenta a transferibilidade dos hiperparâmetros de treinamento de modelos pequenos para modelos grandes, permitindo usar a mesma taxa de aprendizado, entre outros. O Cerebras-GPT treina seus modelos com essa técnica.
Knowledge Distillation: conceito amplamente usado em grandes modelos de linguagem (LLMs), que consiste em extrair conhecimento valioso de um modelo professor grande e complexo e ensiná-lo a um modelo aluno menor e mais eficiente. Essas técnicas de KD funcionam minimizando a diferença entre as saídas dos dois modelos, de modo que o modelo aluno aprenda aproximadamente o comportamento e as previsões do modelo professor. LaMini-GPT e Gemma-2 usam essa técnica.
Two Stage Pre-training: como o nome indica, é uma estratégia de treinamento em duas etapas distintas. Primeiro, na fase de pré-treinamento (Pretraining Phase), o modelo é treinado com grandes volumes de dados de baixa qualidade. Esse processo exige mais recursos computacionais. Depois, na fase de refinamento (Annealing Phase), dados de SFT (Supervised Fine-Tuning) de alta qualidade e focados em tarefas específicas são misturados aos dados de pré-treinamento. O MiniCPM usa essa técnica.

Capacidades dos SLMs (Capabilities)

Datasets e métricas de avaliação de SLMs (Evaluation Datasets and Metrics)

Este estudo organizou 12 datasets para avaliar as capacidades dos SLMs em três categorias: raciocínio de senso comum (Commonsense Reasoning), resolução de problemas (Problem-Solving) e matemática (Mathematics):

Nome	Tipo	Descrição e uso
HellaSwag	Raciocínio de senso comum	Testa a compreensão narrativa e avalia possíveis conclusões de frases.
TruthfulQA	Raciocínio de senso comum	Dataset que avalia se o modelo evita fornecer informações falsas.
Winogrande	Raciocínio de senso comum	Dataset que avalia a capacidade de raciocínio de senso comum por meio da resolução de ambiguidades pronominais.
CommonsenseQA	Raciocínio de senso comum	Apresenta problemas de raciocínio de senso comum em formato de múltipla escolha que exigem conhecimento do cotidiano.
PIQA	Raciocínio de senso comum	Dataset que avalia raciocínio físico de senso comum e interação entre objetos.
OpenBookQA	Raciocínio de senso comum	Inclui problemas científicos abertos que exigem combinar conhecimento científico e senso comum.
BoolQ	Raciocínio de senso comum	Avalia capacidades de raciocínio factual e de senso comum por meio de perguntas de sim/não.
ARC Easy	Resolução de problemas	Dataset com problemas científicos simples que testam conhecimento geral e raciocínio.
ARC Challenge	Resolução de problemas	Apresenta questões científicas complexas que exigem integração de conhecimento.
MMLU	Resolução de problemas	Dataset que avalia a capacidade de resolução de problemas em várias áreas acadêmicas.
GSM8K	Raciocínio matemático	Dataset que avalia a capacidade de raciocínio matemático em nível de ensino fundamental.
Minerva Math	Raciocínio matemático	Avalia capacidades avançadas de raciocínio matemático em diversos temas.

Na avaliação, a principal métrica usada é a acurácia (Accuracy), calculada como a proporção de previsões corretas em relação ao total de exemplos do dataset de avaliação. Nas áreas de raciocínio de senso comum, resolução de problemas e tarefas matemáticas, avalia-se se a resposta correta foi escolhida e quão precisa é a solução fornecida.

Desempenho geral dos SLMs (Overall Capabilities)

Foram realizados experimentos com SLMs selecionados em três tarefas — raciocínio de senso comum, resolução de problemas e matemática — e o progresso foi analisado como mostrado na figura abaixo. No geral, foi confirmada uma melhora considerável de desempenho, com ganhos de 10.4%, 13.5% e 13.5% em cada tarefa, respectivamente. Em comparação, o modelo de linguagem open source de grande porte LLaMA apresentou melhoria média de apenas 7.5% no mesmo período:

Em especial, a família Phi, da Microsoft, treinada com datasets fechados, apresentou desempenho superior a todos os outros modelos ao atingir nível semelhante ao do mais recente LLaMA 3.1 de 7B (67.6% em raciocínio de senso comum e 72.4% em resolução de problemas). Embora ainda exista alguma diferença na área de matemática, a lacuna entre SLMs e LLMs em raciocínio geral está diminuindo rapidamente. Apesar de haver exceções como o Qwen2, de modo geral há uma tendência de melhora de desempenho conforme o tamanho do modelo aumenta.

Embora alguns SLMs pioneiros ainda sejam treinados com datasets fechados, a diferença entre modelos open source e fechados em tarefas de raciocínio de senso comum está diminuindo gradualmente. Por exemplo, o SmolLM e o DCLM-1B apresentam desempenho excelente nessa área graças a datasets de alta qualidade como DCLM e FineWeb-Edu (atingindo 64.2% e 63.8%, respectivamente). No entanto, em tarefas que exigem raciocínio ou lógica complexos, especialmente matemática, ainda há uma diferença significativa devido à falta de datasets de alta qualidade.

> #### Principais insights: há 4 observações principais no avanço dos SLMs:
> - De 2022 a 2024, os SLMs apresentaram melhorias significativas de desempenho em várias tarefas de linguagem. No geral, mostram ganhos substanciais e superam as melhorias do LLaMA-7B (nas versões 1/2/3/3.1). Esses resultados aumentam a expectativa de que será possível resolver diversas tarefas downstream em dispositivos on-device.
> - A família de modelos Phi vem apresentando desempenho de ponta de forma consistente na maioria das tarefas. Em setembro de 2024, o Phi-3-mini alcançou uma precisão comparável à do Llama-3.1-8B. Supõe-se que esse desempenho se deva à cuidadosa engenharia de dados da Microsoft, mas ele também pode ser resultado de ajuste por instruções (instruction tuning) em conjuntos de dados específicos e de potencial sobreajuste (overfitting).
> - Em geral, quanto maior o modelo, melhor também tende a ser o desempenho, embora existam casos excepcionais como o Qwen2-1.5B. Essas exceções mostram que modelos menores podem ter desempenho excelente em tarefas específicas.
> - Na área de raciocínio de senso comum, o desempenho de SLMs treinados com conjuntos de dados open source está reduzindo a diferença em relação aos SLMs proprietários. No entanto, ainda existe uma lacuna considerável em tarefas que exigem raciocínio ou lógica complexos, o que indica a necessidade de conjuntos de dados voltados para raciocínio matemático.

Capacidades de aprendizado em contexto (In-Context Learning Capabilities)

O aprendizado em contexto (In-Context Learning, ICL) é uma capacidade importante dos SLMs: a habilidade de executar novas tarefas com base no contexto de entrada fornecido. Foram realizados experimentos sobre a capacidade de ICL usando vários modelos e variantes de 2B de cada modelo em 8 tarefas, incluindo raciocínio de senso comum e resolução de problemas. Em geral, os SLMs puderam obter vantagens significativas em todas as tarefas. No entanto, em conjuntos de dados simples como HellaSwag e PIQA, excepcionalmente, o desempenho foi semelhante independentemente do número de exemplos de ICL (ICL shots). Fora isso, em média, o aprendizado em contexto com 5 exemplos (5-shot) melhora o desempenho zero-shot em 2,1% em todas as tarefas.

Como exemplo representativo, o modelo Gemma2 mostrou a maior melhoria, com aumento de 4,8% na precisão. Excepcionalmente, o modelo LaMini apresentou queda de desempenho superior a 2%. A hipótese levantada é que o LaMini sofreu sobreajuste (overfitting) ao conjunto de dados de treinamento, de modo que exemplos adicionais podem introduzir ruído.

De modo geral, foi possível confirmar que, à medida que o tamanho do modelo SLM aumenta, também melhora o desempenho de aprendizado em contexto (ICL capability).

> #### Principais insights: há 2 observações principais sobre as capacidades de aprendizado em contexto dos SLMs:
> - Em geral, a maioria dos SLMs possui certo nível de capacidade de aprendizado em contexto. No entanto, essa capacidade aparece de forma diferente dependendo do tipo de tarefa: a maioria dos SLMs melhora bastante na tarefa Arc Challenge, mas o ganho é pequeno em casos como HellaSwag e PIQA.
> - Quanto maior o tamanho do modelo SLM, mais forte tende a ser sua capacidade de aprendizado em contexto em comparação com modelos menores. Alguns SLMs de menor escala, como o LaMini, chegam a apresentar queda de desempenho ao usar aprendizado em contexto.

Custo de execução (Runtime Cost) dos SLMs

O custo de execução (Runtime Cost) dos SLMs inclui a latência e o uso de memória (memory footprint) gerados quando o modelo é executado em um dispositivo real. Este estudo avalia o desempenho em tempo de execução dos SLMs e analisa os resultados de experimentos em diferentes hardwares. Também explica o impacto da arquitetura do modelo (architecture) e da quantização (quantization) no desempenho, abordando assim como os SLMs podem ser otimizados para ambientes em tempo real.

Para medir o custo de execução, foram usados os dois tipos de dispositivos de borda (edge devices) a seguir. Um é o Jetson Orin, usado principalmente em dispositivos de borda como drones e pequenos robôs, e o outro é o smartphone, amplamente usado no dia a dia pelas pessoas. Eles são os seguintes:

Nome do dispositivo	Tipo de hardware	Especificações
Jetson Orin NX 16GB	GPU	1024-core NVIDIA Ampere architecture GPU with 32 tensor cores, 16G DRAM
MEIZU 18Pro	CPU	Snapdragon 888, 8G RAM

Além disso, como o método de medição do número oficial de parâmetros varia entre os modelos, os autores usaram os valores de parâmetros obtidos no llama.cpp. A medição foi separada entre a etapa de prefill e a etapa de decode durante a inferência e, salvo indicação em contrário, o comprimento do prompt foi definido como 50 e o comprimento de geração de tokens também como 50. Além disso, para evitar queda de desempenho causada por aquecimento (thermal throttling), os testes foram realizados com intervalos de 10 segundos e, para medir modelos maiores, foi aplicada quantização de 4 bits.

Medição de latência: dependendo do tamanho do modelo, mede-se o tempo de geração do primeiro token (prefill) e o tempo de geração de cada token subsequente (decode).
Medição de uso de memória: mede-se o uso do cache KV e dos buffers de memória para analisar quanta memória o modelo ocupa.

Visão geral do custo de execução (Overview)

A visão geral da latência de inferência (Inference Latency) e do uso de memória (Memory Footprint) dos SLMs abordados neste estudo é a seguinte:

Inference Latency (latência de inferência): a latência de inferência dos SLMs é dividida em três faixas de acordo com o tamanho do modelo: 0.1-1B, 1-2B e 2-3B. Dentro dessas faixas, cada modelo apresenta latência semelhante. Mais especificamente, o impacto da arquitetura do modelo na latência também é significativo. Por exemplo, o Qwen2-0.5B mostra um tempo até o primeiro token 1,46 vez maior do que outros modelos do mesmo porte, enquanto o Qwen1.5-0.5B apresenta desempenho semelhante ao do OpenELM-1.1B, que é um modelo ainda maior.
- Etapa de prefill: etapa em que o prompt de entrada é processado e o cache KV é gerado, com vários tokens processados em paralelo.
- Etapa de decode: etapa em que o próximo token é previsto com base em cada token gerado, exigindo mais recursos de memória.
Memory Footprint (uso de memória): o uso de memória dos SLMs varia de acordo com o tamanho do modelo e o comprimento de contexto (context length). Em particular, modelos como Bloom-560M e Gemma-2B usam mais memória por terem um vocabulário muito grande (256.000 itens). Em contrapartida, a série OpenELM economiza uso de memória ao reduzir o tamanho do cache KV com o uso de GQA (Group-Query Attention).

> #### Principais insights: há 3 observações principais sobre o custo de execução dos SLMs:
> - Além do tamanho do modelo, a arquitetura do modelo também afeta a latência. Por exemplo, o Qwen1.5-0.5B tem 25,4% mais parâmetros que o Qwen2-0.5B, mas roda 31,9% mais rápido no Jetson Orin. Isso significa que, ao desenvolver um SLM, ele deve ser ajustado ao hardware em que será implantado.
> - O impacto da arquitetura do modelo na velocidade de inferência é maior na etapa de prefill do que na etapa de decode. Isso ocorre porque a densidade computacional da etapa de prefill é mais alta, enquanto a etapa de decoding depende principalmente de memória (memory-bound). Diferenças na arquitetura do modelo tendem a afetar mais facilmente cenários limitados por computação (compute-bound). Por exemplo, modelos mais largos e rasos têm maior paralelismo computacional.
> - O uso de memória em execução geralmente tem correlação linear com o tamanho do modelo. No entanto, alguns modelos com vocabulário (vocabulary size) maior usam mais memória do que outros modelos de tamanho semelhante. Por exemplo, a família de modelos Bloom tem tamanho de vocabulário de 250.880, cerca de 5 a 8 vezes maior que o da maioria dos modelos.

Impacto da quantização e do hardware (Impact of Quantization and Hardware)

Primeiro, medimos a latência do modelo Phi-1.5 em cinco métodos de quantização (Q8_0, Q6_K, Q5_K, Q4_K_M, Q3_K) e antes da quantização (FP16) para entender o impacto da quantização (Quantization) no custo de execução dos SLMs:

Em dispositivos móveis, pode haver suporte limitado a operações int8, mas ainda assim é possível reduzir de forma eficaz o overhead de acesso à memória. Isso acontece porque a menor precisão comprime os dados, melhorando consequentemente o uso de cache. Cada método realiza quantização em n bits; Qn_K e Qn_K_M usam o método k-quant para quantizar em n bits modelos com quantidade intermediária de parâmetros, enquanto Qn_0 significa quantização simétrica.

Efeito da quantização na etapa de Prefill: quando o comprimento do prompt é curto, a quantização reduz a latência em pelo menos 25%. No entanto, à medida que o comprimento do prompt aumenta, esse efeito diminui, e quando o comprimento do prompt se aproxima de 50, os métodos de quantização Q6_K e Q3_K chegam a apresentar latência semelhante ou até maior que a do modelo FP16 sem quantização. Os métodos Q8_0, Q4_K_M e Q5_K oferecem melhorias de desempenho estáveis, com destaque para o Q4_K_M, que apresenta o melhor desempenho e reduz a latência em média em 50%.

Efeito da quantização na etapa de Decode: há uma melhora de desempenho mais consistente, com redução de latência de até 75% e no mínimo 17%. Além disso, assim como na etapa de Prefill, o método Q4_K_M é o mais eficaz, enquanto o Q6_K é o menos eficiente.

> #### Principais insights: há 2 observações principais sobre o impacto da quantização dos SLMs no custo de execução:
> - Os benefícios da quantização aparecem mais na etapa de decode do que na etapa de prefill. Em dispositivos móveis, a quantização reduz principalmente o overhead de acesso à memória. Como a etapa de decode é mais afetada pela largura de banda de memória, ela obtém mais benefícios da quantização do que a etapa de prefill, que é mais afetada por computação.
> - Quanto mais regular for a precisão da quantização (Quantization Precision), melhor é o desempenho. A quantização em 3 bits oferece taxa de compressão maior do que a quantização em 4 bits, mas a quantização em 4 bits entrega melhor desempenho tanto na etapa de prefill quanto na de decode. O pior desempenho da quantização em 3 bits ocorre porque a largura de bits irregular (irregular bit-width) tem menos suporte a otimizações de hardware e gera overhead adicional por alinhamento e padding de dados (data alignment & padding). Portanto, embora tenha menor taxa de compressão, a quantização em 4 bits é mais eficiente; da mesma forma, as quantizações em 5 e 6 bits, apesar de maior compressão, apresentam latência de inferência semelhante ou até maior que a da quantização em 8 bits.

Em seguida, testamos o modelo Bloom-1B1 no Jetson Orin NX 16GB (usando GPU) e no Meizu 18 Pro (usando CPU) para medir o impacto do hardware (Hardware) no custo de execução dos SLMs:

Na etapa de Prefill, quando o comprimento do prompt é curto, o Jetson Orin apresenta desempenho de 10 a 20 vezes superior ao do Meizu 18 Pro. Além disso, à medida que o comprimento do prompt aumenta, a vantagem de desempenho do Jetson fica ainda mais evidente. Conforme o prompt fica mais longo, o tempo para gerar o primeiro token aumenta linearmente em ambos os dispositivos, mas o Jetson mantém desempenho estável mesmo com prompts mais longos.

Na etapa de Decode, à medida que o número de tokens gerados aumenta, a latência por token do Meizu 18 Pro cresce rapidamente. Em especial, a latência sobe abruptamente entre o primeiro e o décimo token, e depois se estabiliza. Esse aumento acentuado de latência no Meizu 18 Pro é causado pelo aumento de temperatura, já que o DVFS (Dynamic Voltage and Frequency Scaling) ou o thermal throttling ajustam o consumo de energia e a frequência, reduzindo a eficiência computacional. Em contraste, o Jetson, graças a um sistema de resfriamento mais eficiente, apresenta pouca variação de latência até a geração de 30 tokens, e só depois disso se observa aumento de latência.

> #### Principais insights: há 2 observações principais sobre o impacto do hardware no custo de execução dos SLMs:
> - A etapa de decode gera cada token de forma sequencial, enquanto na etapa de prefill é possível processar em paralelo os tokens do prompt, por isso o desempenho em GPU é muito mais rápido.
> - Em tarefas de inferência longas, o Jetson mostra melhor estabilidade de desempenho que o smartphone. Isso ocorre porque o Jetson, por ter uma estrutura de hardware relativamente mais simples, dissipa calor com mais facilidade.

Análise de latência e memória (Latency and Memory Breakdown)

Ao detalhar mais a latência, analisamos para os modelos Qwen1.5-0.5B e Qwen2-0.5B a proporção que cada camada (layer) e operação (operation) ocupa na latência total:

Os modelos Qwen1.5-0.5B e Qwen2-0.5B têm tamanhos semelhantes, mas apresentam diferenças de latência (latency). Por meio de uma análise detalhada da latência de cada modelo, medimos a distribuição de tempo ocupada por cada camada (Embedding, Attention, FFN, LM_Head).

Na etapa de Prefill, no modelo Qwen1.5, a camada de attention ocupa uma proporção maior do que a camada FFN. Isso ocorre porque o aumento no tamanho do cache KV exige mais computação na camada de attention. Em contrapartida, no modelo Qwen2, a camada FFN ocupa proporção maior do que a camada de attention. Isso acontece porque o modelo Qwen2 tem uma camada FFN mais larga.

Na etapa de Decode, a proporção das operações de attention no modelo Qwen1.5 aumenta ainda mais. Isso ocorre porque os tokens gerados interagem com os tokens gerados anteriormente, exigindo mais computação, e essa tendência fica ainda mais evidente à medida que o tamanho do cache KV cresce. No modelo Qwen2, a camada FFN continua sendo a que mais consome tempo, pois a maior largura computacional da FFN faz com que ela demore mais.

Ao analisar os operadores (operator), em ambos os modelos, a operação de multiplicação matriz-vetor (matrix-vector multiplication, mul_mat_vec_q) responde por mais de 80% do tempo total de execução. Em particular, no modelo Qwen2-0.5B, como a camada FFN é mais larga, a operação mul_mat_vec_q acaba tendo peso ainda maior.

Além disso, ao analisar o uso de memória (Memory), temos o seguinte:

Os resultados da análise destacam que, além do tamanho do modelo, o tamanho do vocabulário (vocabulary size) também tem grande impacto no uso de memória. Quanto maior o vocabulário usado pelo modelo, maior fica o Compute Buffer usado na camada de saída. Por exemplo, o tamanho do vocabulário do modelo Bloom-560M é 250.880, o que faz com que seu Compute Buffer chegue a 492 MB, consumindo 3,5 vezes mais memória do que o OpenELM-1.1B, cujo vocabulário tem tamanho 32.000.

Além disso, modelos que usam GQA (Group-Query Attention) têm KV Cache menor do que modelos que usam MHA (Multi-Head Attention). Por exemplo, o tamanho do KV cache do modelo OpenELM-3B é 164 MB, cerca de 3,9 vezes menor que o do modelo StableLM-zephyr-3B.

Quando o context length aumenta, o Compute Buffer e o KV Cache se tornam os principais fatores que determinam o uso de memória do modelo. Na série de modelos Qwen2, quando o context length chega a 131.072, o Compute Buffer e o KV Cache passam a representar de 83% a 87% do uso total de memória. Em contraste, no caso do Qwen1.5, com context length máximo de 32.768, esses dois elementos representam de 85% a 90% da memória total.

Essa análise mostra com clareza o impacto do tamanho do vocabulário (Vocabulary Size) e do comprimento de contexto (Context Length) no uso de memória dos SLMs, e que, quanto maiores forem o vocabulário e o contexto, mais o consumo de memória aumenta rapidamente.

Conclusão e direções para pesquisas futuras

Até aqui, foi realizado um estudo abrangente e uma medição de desempenho de small language models (SLMs) com tamanhos de 100M a 5B, além de uma avaliação de desempenho do modelo, custo de execução e outros aspectos. Com isso, busca-se analisar os resultados atuais e as limitações dos SLMs, bem como apresentar vários temas de pesquisa que exigem investigação futura:

Projeto cooperativo e otimização conjunta da arquitetura de SLM e dos processadores do dispositivo (Co-design and co-optimizations of SLM architecture and device processors.): O desempenho dos SLMs pode variar bastante dependendo da configuração da arquitetura, mesmo dentro de um mesmo tamanho de modelo. Por exemplo, a proporção entre profundidade e largura do Transformer, o tipo de attention e a função de ativação têm enorme impacto na velocidade de execução. Em especial, é importante estudar como quantizar SLMs para que possam ser executados com eficiência em processadores otimizados para operações inteiras, como NPUs (Neural Processing Units). Para alcançar os melhores trade-offs entre acurácia e velocidade, é essencial projetar e otimizar a arquitetura de acordo com o hardware específico, e uma possível direção é encontrar arquiteturas otimizadas para velocidade antes do pré-treinamento.
Construção de datasets sintéticos de alta qualidade (Constructing high-quality synthetic dataset): Datasets de pré-treinamento lançados recentemente, como DCLM e FineWeb-Edu, melhoraram bastante o desempenho dos SLMs. A principal inovação desses datasets é o uso de modelos pré-treinados para filtrar dados de alta qualidade em corpora de larga escala. A pesquisa sobre dados sintéticos ainda está em estágio inicial e tem muito potencial. É urgente estabelecer processos padronizados de gestão de dados sintéticos, incluindo deduplicação, filtragem, mistura e avaliação.
Extensão da lei de Chinchilla com foco em implantação em dispositivos (A deployment-aware Chinchilla law for model scaling): Segundo a lei de Chinchilla, para otimizar o desempenho do modelo é necessário equilibrar o tamanho do modelo e o tamanho dos dados de treinamento (número de tokens) em aproximadamente 1:20. No entanto, como os SLMs precisam se adequar à memória limitada e à capacidade computacional dos dispositivos, eles tendem a usar volumes muito maiores de dados de treinamento. Essa abordagem é eficaz até certo ponto, mas como não é possível expandir indefinidamente a quantidade de dados de treinamento, ainda é necessário descobrir a melhor forma de escalar os dados. Além disso, é preciso considerar não apenas a escala dos dados e os custos de treinamento e inferência, mas também o ciclo de vida dos SLMs e seu retorno econômico, e o problema fica ainda mais complexo com a aplicação de sparsity, como em MoE (Mixture-of-Experts).
Aprendizado contínuo on-device para personalização (Continual on-device learning for personalization): Quando um SLM é implantado em um dispositivo, pode usar dados locais (On-Device Data) para obter melhor desempenho ou personalização sem preocupações com vazamento de dados. A primeira abordagem para isso é usar a técnica RAG (Retrieval-Augmented Generation) para injetar dados pessoais no prompt. Esse método aumenta o tempo de geração de embeddings de texto e o tempo de processamento do prompt, além de exigir que os dados para personalização permaneçam armazenados no dispositivo por longos períodos. A segunda abordagem é fazer fine-tuning do SLM, incorporando o conhecimento necessário para personalização aos pesos do modelo e permitindo apagar os dados após o ajuste fino. No entanto, o fine-tuning on-device consome muita memória e energia, o que pode causar sérios problemas de recursos. Também há espaço para pesquisas sobre métodos que apliquem zeroth-order optimization, sem armazenar ativações na memória, e que possam aproveitar aceleradores de hardware na etapa de inferência.
Colaboração entre SLMs e LLMs em dispositivos e nuvem (Device-cloud SLM-LLM collaboration): Embora as capacidades dos SLMs estejam evoluindo rapidamente, ainda existe uma diferença em relação aos large language models (LLMs) executados na nuvem. Para resolver isso, a colaboração entre dispositivo e nuvem será um tema importante de pesquisa. Intuitivamente, os SLMs podem processar tarefas que o dispositivo consegue resolver facilmente, enquanto os LLMs em nuvem podem atuar como um filtro para tarefas complexas. No entanto, é necessário um módulo de decisão para distinguir quais tarefas o SLM pode ou não processar, e mais pesquisas são necessárias para encontrar formas adequadas de colaboração entre dispositivo e nuvem.
Questões de justiça na avaliação de desempenho de SLMs (Benchmarking SLMs fairly): Os SLMs sofrem com problemas de overfitting, especialmente em benchmarks amplamente usados como o GSM8k. Além disso, como muitos SLMs são treinados com datasets fechados, é difícil comparar seu desempenho de forma justa. Como os SLMs são executados principalmente on-device, eles acabam realizando tarefas diferentes das do ambiente de nuvem. SLMs implantados em smartphones tendem a lidar com tarefas sensíveis aos dados do usuário, e como essas tarefas especializadas (ad-hoc tasks) não estão incluídas nos benchmarks existentes, pode haver o problema de exclusão de itens importantes da avaliação.
SLMs com aplicação de sparsity (Sparse SLMs): Atualmente, quase não existem pesquisas sobre aplicação de sparsity em SLMs. Isso ocorre porque, em comparação com os LLMs, espera-se que os SLMs tenham níveis relativamente menores de sparsity, o que pode limitar os ganhos de velocidade e economia de memória. Além disso, arquiteturas baseadas em sparsity, como MoE (Mixture-of-Experts), podem aumentar a complexidade computacional em vez de reduzir o uso de memória, o que pode torná-las inadequadas para dispositivos com restrições de memória. É possível expandir ainda mais os SLMs usando armazenamento externo do smartphone, como memória flash, para guardar pesos fixos (Cold Weights) e carregá-los quando necessário, mas esse tipo de abordagem ainda exige mais pesquisa sobre questões como latência de I/O e manutenção de compatibilidade com aceleradores de hardware heterogêneos.

Artigo de pesquisa abrangente sobre small language models: Small Language Models: Survey, Measurements, and Insights

https://arxiv.org/abs/2409.15790

Página inicial do projeto

https://ubiquitouslearning.github.io/TinyLLMLeaderBoard/#/slm

Repositório GitHub

https://github.com/UbiquitousLearning/SLM_Survey

Este texto foi baseado em um resumo feito com um modelo GPT, portanto pode haver partes organizadas de forma diferente do conteúdo ou da intenção do texto original. Se o tema for do seu interesse, consulte também o texto original! Se, durante a leitura, você encontrar algo estranho ou incorreto, pedimos que nos avise nos comentários. 🤗

⚠️Publicidade⚠️: Este texto, organizado pelo 🔥Grupo de Usuários PyTorch da Coreia🇰🇷, foi útil para você? Se cadastre-se como membro, enviaremos os principais textos por e-mail💌! (O padrão é Weekly, mas também é possível mudar para Daily.)