MobileLLM: otimizando modelos de linguagem com menos de um bilhão de parâmetros para casos de uso no dispositivo

 (github.com/facebookresearch)
3 pontos por GN⁺ 2024-07-11 | 1 comentários | Compartilhar no WhatsApp
  • O repositório MobileLLM fornece o código de treinamento do artigo do ICML 2024 “MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases” e aborda projetos para elevar a qualidade de modelos de linguagem com menos de 1 bilhão de parâmetros
  • O design do modelo integra SwiGLU, uma estrutura profunda e estreita, compartilhamento de embeddings e grouped-query attention para compor o MobileLLM
  • MobileLLM-125M/350M alcançaram, respectivamente, 2,7%/4,3% de melhoria de acurácia em relação aos modelos SoTA existentes de 125M/350M em tarefas zero-shot de raciocínio de senso comum, e as versões atualizadas também mostram resultados SoTA em 600M/1B/1.5B
  • O código de treinamento exige Python 3.9 e PyTorch 2.0 ou superior; pretrain.sh inicia com torchrun em um nó 1x8 GPU, e, ao aumentar o número de nós ou o tamanho do batch, a taxa de aprendizado deve ser aumentada linearmente
  • O custo de treinamento para 1T tokens em 32 GPUs NVIDIA A100 80G é de cerca de 3 dias para 125M, 6 dias para 350M, 8 dias para 600M, 12 dias para 1B e 18 dias para 1.5B

Objetivo e escopo de lançamento do MobileLLM

Elementos de design do modelo

  • O MobileLLM integra os seguintes elementos de design
    • Função de ativação SwiGLU
    • Arquitetura profunda e estreita

    • Compartilhamento de embeddings

      • grouped-query attention
      • Na versão atualizada, essa filosofia de design é apresentada como extensível também a modelos maiores, mostrando resultados SoTA em MobileLLM-600M/1B/1.5B

Lançamento público e notícias sobre modelos subsequentes

  • Em 30 de outubro de 2024, o modelo MobileLLM foi disponibilizado no HuggingFace
  • Em setembro de 2025, foi divulgado o trabalho subsequente MobileLLM-R1
    • Com cerca de 2T tokens de pré-treinamento e menos de 5T tokens no total, iguala ou supera os resultados do Qwen3-0.6B com 36T tokens em MATH, GSM8K, MMLU e LiveCodeBench
    • Código, modelo, dados e receita de treinamento foram disponibilizados
    • A coleção do HuggingFace está disponível
  • Em novembro de 2025, MobileLLM-R1.5 foi disponibilizado
    • O MobileLLM-R1.5-950M supera o DeepSeek-R1-Distill-Qwen-1.5B em todos os benchmarks avaliados de matemática e programação
    • Tem menos parâmetros: 0.95B contra 1.5B
  • Em janeiro de 2026, MobileLLM-R1 foi aceito no ICLR 2026

Execução e configuração de treinamento

  • Os requisitos são Python 3.9, PyTorch 2.0 ou superior e pip install -r requirement.txt
  • O pré-processamento dos dados consiste em dividir um dataset tokenizado ou tokenizar um dataset próprio e então distribuí-lo conforme o número total de nós de treinamento
    • Cada nó é composto por 1x8 GPU
    • A estrutura dos dados coloca arquivos xxx.jsonl em basepath/1, basepath/2, ..., basepath/#nodes
    • Cada linha jsonl é um par chave-valor de dados tokenizados no formato {"token_ids": [1,2,3,4,...]}
    • O código de treinamento é compatível com o método de pré-processamento de dados de LLM360/amber-data-prep
  • pretrain.sh é um script que inicia o treinamento com torchrun em uma configuração de nó 1x8
    • É possível ajustar --nnodes e outras configurações para ambientes multinó, como Slurm ou TorchX
    • A taxa de aprendizado no script tem como referência 1 nó 1x8 e batch size 32
    • Ao aumentar o número de nós ou o tamanho do batch, a taxa de aprendizado deve ser aumentada linearmente
  • O procedimento de execução consiste em definir --train_data_local_path em pretrain.sh para os dados pré-processados, definir --input_model_filename como ./configs/{model_size}/ e então executar bash pretrain.sh
  • A avaliação Wiki é executada baixando o modelo, atualizando o caminho do checkpoint em eval.sh e então rodando bash eval.sh

Custo de treinamento

  • Ao treinar o MobileLLM com 1T tokens, o tempo necessário em 32 GPUs NVIDIA A100 80G é o seguinte
    • 125M: cerca de 3 dias
    • 350M: cerca de 6 dias
    • 600M: cerca de 8 dias
    • 1B: cerca de 12 dias
    • 1.5B: cerca de 18 dias

Resultados de raciocínio de senso comum zero-shot

  • O MobileLLM-125M registra 46,3 na média de arc_easy, arc_challenge, boolq, piqa, siqa, hellaswag, obqa e winogrande
    • OPT-125M registra 42,6; GPT-neo-125M, 42,9; Pythia-160M, 42,5
    • MobileLLM-LS-125M tem média 47,0
  • O MobileLLM-350M registra média 51,3
    • OPT-350M registra 43,9; Pythia-410M, 46,6
    • MobileLLM-LS-350M tem média 52,1
  • O MobileLLM-600M registra média 54,3
    • Qwen1.5-500M registra 48,8; BLOOM-560M, 44,2; MobiLlama-800M, 50,7
  • O MobileLLM-1B registra média 57,3
    • Pythia-1B registra 48,7; MobiLlama-1B, 55,2; Falcon-1B, 56,3; BLOOM-1.1B, 46,9; TinyLlama-1.1B, 54,2
  • O MobileLLM-1.5B registra média 59,4
    • GPT-neo-1.3B registra 50,6; OPT-1.3B, 52,3; BLOOM-1.7B, 49,6; Qwen1.5-1.8B, 56,5
    • GPT-neo-2.7B registra 52,8; OPT-2.7B, 55,1; Pythia-2.8B, 55,8; BLOOM-3B, 52,3

Projetos relacionados e licença

  • O código se baseia parcialmente no repositório Transformers da HuggingFace, que usa a Apache License
  • Os seguintes projetos relacionados são apresentados
    • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
    • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
  • Como próximos passos, são apresentados MobileLLM-R1 e o modelo MobileLLM-R1.5
  • O MobileLLM atualmente usa a licença FAIR NC

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-11
Opiniões no Hacker News

  • Modelos pequenos melhoraram um pouco, mas ainda parecem insuficientes para serem usados nas mesmas finalidades dos modelos online. Ainda assim, o avanço incremental em si é positivo
    O modelo de 1,5 bilhão de parâmetros parece um salto considerável, e também vence modelos maiores por uma boa margem. Não sei por que não fizeram um ainda maior. Um modelo mais eficiente que caiba em hardware do nível de um Raspberry Pi poderia mudar o jogo. Pelo que lembro, até o TinyLlama 7B mal roda

    • Modelos de linguagem menores também parecem úteis como parte de sistemas de reconhecimento de fala. Em situações ambíguas ou com ruído, um modelo de linguagem pode ajudar a restringir qual palavra foi dita
    • Dá para imaginar esse tipo de modelo embutido no app do Instagram e sendo usado para segmentação de anúncios com computação no dispositivo do usuário. Assim, o Facebook poderia ver muito mais dados a um custo menor e com risco de processos muito mais baixo
      Para esse uso, não é justo comparar modelos pequenos com modelos na nuvem. Mesmo um pequeno aumento na precisão de um modelo pequeno é significativo e pode se converter diretamente em receita
    • Não tenho certeza se o Raspberry Pi é o alvo certo para a próxima etapa de LLMs locais, e também vale considerar a distribuição pela web por meio de motores como o WebLLM https://github.com/mlc-ai/web-llm
      Mesmo que um modelo 7B “rode bem” em um Raspberry Pi, pessoalmente acho um modelo 7B um pouco grande para baixar e executar em uma interface baseada na web. Por outro lado, um bom modelo de 125M pode rodar em uma página web, e o tempo de download para o navegador local e o custo de banda não são excessivos
    • Llama-3-8b roda bem em Raspberry Pi

  • Precisa mesmo estar só em dispositivos móveis? Embora seja um caso de uso de nicho, se não consumir muitos recursos, acho que poderia ser usado em jogos para tornar os diálogos de NPCs mais interessantes
    Melhor ainda seria se pudesse ser ajustado de alguma forma para que a conversa influenciasse o comportamento ou as ações do NPC

    • Será que esse diálogo seria realmente interessante? Dá para aumentar a quantidade de falas, mas fico em dúvida se haveria uma base que interessasse ao jogador. Por exemplo, moradores de uma vila poderiam falar sobre a paisagem local ou sobre suas relações com outros NPCs, mas as coisas que eles descrevem talvez nem existam de fato dentro do jogo. Pessoalmente, acho que começaria a parecer estranho se NPCs passassem a inventar coisas que não existem
      Consigo imaginar treinar um LLM com dados do jogo para que os NPCs descrevam o mundo real do jogo. Mas não sei qual escala seria necessária para isso ficar mais barato do que simplesmente ter uma pessoa escrevendo as falas. Talvez em uma escala como a da Ubisoft seja possível. Pelo que sei, a Ubisoft também vem investigando escrita com IA, mas principalmente para usos muito repetitivos e praticamente próximos de ruído, como gritos durante combates
    • Acho que seria interessante se NPCs tivessem mais histórias de fundo e comportamentos mais complexos. Mas, como qualquer coisa poderia influenciar o comportamento, os testes provavelmente seriam quase impossíveis

  • Quais apps hoje conseguem rodar modelos assim no iPhone? Só conheço o MLC, mas lá há apenas três modelos antigos

  • Fico curioso até onde dá para levar a abordagem de torná-los mais profundos e mais estreitos. Em algum momento, se a FFN inteira couber no cache L2, acho que pode surgir uma faixa em que o desempenho melhora bastante

    • Outro estudo da Meta FAIR sugere que, para aumentar o desempenho mantendo a precisão, na verdade é preciso podar camadas profundas https://arxiv.org/html/2403.17887v1
      Então deve haver um limite de redes pequenas em que essa abordagem funciona. Caso contrário, os resultados entram em contradição. Ou talvez isso signifique que esses novos modelos ainda possam ser muito mais aprimorados
    • Isso me lembra os resultados do artigo EfficientT5 do Google https://arxiv.org/abs/2109.10686. Lá eles chamam isso de “DeepNarrow”

  • Não sei se estou deixando passar algo, mas algo como destilação de conhecimento não ajudaria aqui?

    • O artigo diz que eles tentaram isso: https://arxiv.org/abs/2402.14905
      Deeplink em HTML para a parte relevante: https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
      “Até agora, treinamos modelos pequenos do zero usando o próximo token como rótulo rígido. Também exploramos a destilação de conhecimento (KD)... Infelizmente, a KD aumenta o tempo de treinamento (fica 2,6~3,2 vezes mais lenta) e apresentou precisão semelhante ou menor que o treinamento baseado em rótulos (detalhes no apêndice).”

  • No momento, realmente preciso de reconhecimento de fala no dispositivo semelhante a wake word. Qual é o modelo com o menor WER que roda em um Raspberry Pi 4B? Estou olhando o openWakeWord para um sistema de estoque DIY

  • Modelos pequenos parecem reduzir mais o tamanho com compartilhamento de embeddings/amarramento de pesos entre a cabeça linear e os embeddings de tokens. Fico curioso se há pesquisas em andamento para reduzir ainda mais a partir daí

    • Se a LM-head for simplesmente a matriz de embeddings invertida, isso já era feito no GPT-2
      Infelizmente, o que encontrei sobre isso foi apenas que modelos grandes se beneficiam de uma camada separada. Mas vi isso em algum lugar no Discord, então não tenho um artigo para indicar; por intuição pessoal, acho que deveria funcionar também em modelos grandes. No fim, o GPT-3 também era uma ampliação do GPT-2
      Em experimentos pessoais, quando eu dava tarefas mais difíceis ao modelo, ele aprendia melhor. Pesos amarrados podem ser uma dessas coisas; previsão de múltiplos tokens também pode ser; e o bitnet também pode ser visto assim. Dropout também

  • E se, no desktop, não fosse IA generativa, mas simplesmente IA de desktop? Seria bom se ela organizasse todos os meus arquivos, e-mails e notas, e me permitisse buscar informações nos meus dados

  • Legal. Dá para usar isso também para treinar um modelo para PCs Windows? Não tenho muita RAM

    • O treinamento de modelos não depende do sistema operacional. A RAM depende do tamanho, e acho que, nessa escala, seria muito mais fácil fazer fine-tuning com menos RAM de GPU
      Ainda assim, é bem provável que o objetivo final seja baixar um modelo desses, ou pagar pelo fine-tuning e recebê-lo, para então usá-lo por meio de um chip neural otimizado
      Agora é mais uma questão de quando isso vai acontecer. A certificação mais recente do Windows já exige algum tipo de chip neural, e meu Google Pixel 8 Pro também consegue hospedar um modelo pequeno. O Pixel não é um telefone barato, mas o coprocessador deve ser muito mais barato que uma GPU grande

  • É interessante, mas fico me perguntando quais seriam os usos além de um autocompletar melhor

    • Acho que poderia ser feito fine-tuning para tarefas de domínio restrito, como no tiny-agent https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
      Gosto da abordagem que a Apple parece estar seguindo. Tarefas do dia a dia ficam com modelos pequenos ajustados por fine-tuning, e aquilo que eles não conseguem resolver com confiança é repassado para um modelo grande fora do dispositivo. Acho que dá para criar um conjunto de treinamento com exemplos em que ele deve dar uma resposta de baixa confiança e adicionar uma saída que, na prática, equivale a “pedir ajuda”, treinando-o para escolher essa opção. Com modelos pequenos, também seria possível rodar vários em paralelo e fazer outro modelo rotear a solicitação para o especialista adequado
    • Coisas como ler e-mails, responder e-mails, agendar compromissos e usar APIs de serviços
      Basicamente, qualquer tarefa que exija ação, não conhecimento. Você diz “avise minha esposa que vou me atrasar” e ele conversa com algum serviço, de uma forma mágica configurada, para resolver isso
      A Siri funciona muito bem para automação residencial mesmo sem internet, mas o antigo Google Assistente e a Alexa não eram nada assim, e acho que nunca conseguiram fazer isso offline. Isso viabiliza um assistente local-first que funcione bem
    • Um agente local como a Siri poderia lidar com tarefas simples e rotear solicitações mais complexas
    • Pode ser ajustado por fine-tuning para tarefas relacionadas ao dispositivo. Em outras palavras, praticamente todos os recursos que os aplicativos ou serviços do dispositivo têm também poderiam ser usados por um modelo pequeno
      Ele poderia repassar solicitações do usuário, em linguagem natural, ao aplicativo correspondente e coordenar aplicativos entre si. Solicitações que vão além das capacidades do dispositivo poderiam ser enviadas a um modelo na nuvem. Isso é poderoso porque pode mudar a forma como interagimos com o dispositivo
    • Testei o Google AI no celular e, com o navegador aberto, pedi para ele ler a página; ele respondeu que não tinha acesso à internet
      O assistente de IA que eu quero deve 1) entender inglês e minha língua materna; 2) saber que está rodando no Android ou no KDE/Linux e entender comandos como “abra a seção de aplicativos nas configurações do Android”, “leia a página aberta no navegador”, “leia o texto do pop-up aberto agora”, além de ser integrado ao sistema operacional por APIs públicas. As grandes empresas de IA podem competir vendendo assistentes melhores, especialmente para usuários multilíngues
      3) O modelo deve ser pequeno e não precisa saber coisas como geografia, história ou bandas de música. Basta ter a opção de encaminhar ao mecanismo de busca ou a um LLM online as tarefas sobre as quais o usuário fizer perguntas