Olá a todos!
Prefácio do costume, hoje em formato mil folhas. A primeira já a conhecem: corro modelos locais em casa, defendo que se corram mais, e tenho um preconceito assumido a favor de tudo o que baixe a barreira de entrada. A segunda: o r/LowEndLocalAI é uma comunidade recente, nascida no fim do verão, e não tenho ligação nenhuma a quem a criou nem à moderação. Passei uma tarde a ler o feed de ponta a ponta antes de escrever isto, e os exemplos que se seguem vêm de lá. São relatos de utilizadores, não testes meus. Leiam com isso em mente.
Há uma pergunta que me chega com regularidade, por email, no LinkedIn, ao café, quase sempre com a mesma forma. “Tenho um portátil de há quatro anos com 16 GB de RAM. Dá para correr alguma coisa?” Às vezes vem com uma variante envergonhada: “Sei que não é nada de especial, mas…”
A vergonha é o pormenor que me interessa.
Quem abre o r/LocalLLaMA, o YouTube ou o feed de qualquer pessoa que fale de IA local fica com a impressão de que o ponto de partida é uma torre com duas gráficas de topo e uma fatura de luz que se vê do espaço. É conteúdo divertido, e eu também o vejo. Mas para quem está a começar tem um efeito perverso: convence a pessoa de que a máquina que já tem não serve, e que o primeiro passo é ir às compras.
No r/LowEndLocalAI a mesma pergunta aparece dezenas de vezes. A diferença é que lá ninguém se envergonha de a fazer, e há quase sempre alguém com uma máquina parecida a responder com números.
De onde vem, e o que quer ser
O sub foi apresentado no r/LocalLLaMA pelo utilizador u/soadsob, que tem como máquinas principais um MacBook Air M1 com 16 GB e um portátil com Ryzen 7840U e 32 GB. Andava à procura de modelos, definições e benchmarks para esse hardware e encontrava a informação espalhada por comentários soltos, enterrada em threads sobre outras coisas. Daí a ideia de um sítio focado e pesquisável.
A lista de temas do anúncio diz muito sobre o espírito: modelos e quantizações para máquinas e tarefas concretas, inferência só em CPU ou em gráfica integrada, offloading parcial, otimização da KV cache, speculative decoding, reaproveitar hardware velho, hardware estranho ou sem suporte, relatos honestos de falhanços, e projetos do género “não acredito que isto corre”. No topo, fixado, está o Tiny League, um projeto para comparar modelos que correm em batatas, e o post de boas-vindas onde as pessoas se apresentam.
“Low end” é uma restrição, não uma etiqueta de preço
A decisão mais inteligente do sub está na definição do próprio nome. Não há corte de VRAM, de preço nem de idade. O critério é outro: se a capacidade de cálculo, a RAM, a VRAM, a largura de banda da memória, a energia, a compatibilidade ou o custo afetam de forma relevante o que consegues correr, o teu post pertence lá. Um portátil normal cabe. Uma gráfica de 24 GB também pode caber, se o interessante for espremer lá uma carga que não devia caber. O que não cabe é o sistema multi-GPU mostrado só porque é poderoso.
No feed vê-se essa fronteira a ser negociada em tempo real. Há alguém com um Mac Studio de 96 GB que pede desculpa logo na primeira linha por estar a perguntar ali. Há uma montagem com duas GeForce de marcas diferentes metidas à força na mesma caixa, que o autor apresenta como uma abominação e que só lá foi parar porque outros utilizadores sugeriram. E a resposta da comunidade, nos dois casos, foi tratar a restrição de cada um como legítima.
Li a definição e pensei logo no Kobayashi Maru. O teste da Academia da Frota Estelar estava desenhado para não ter vitória possível, e o Kirk passou-o reprogramando a simulação. O low end tem um bocadinho disso: as regras do jogo dizem que perdes, e a graça está em mudar as condições até a coisa funcionar.
Vista de Portugal, esta definição faz ainda mais sentido. Uma gráfica que nos EUA é “entrada de gama” pode representar cá uma fatia séria de um salário, e o nosso mercado de usados (o OLX, o CustoJusto, a loja do bairro que vende portáteis recondicionados de empresas) não tem nada a ver com o eBay americano. Basta ver o post de alguém que encontrou uma FirePro W7100 de 8 GB por 40 dólares e quer saber se vale a pena: é exatamente o tipo de pergunta que se faz aqui ao ver um anúncio no OLX.
Um passeio pelo feed
Vale a pena descrever o que lá se encontra, porque é isso que torna o sub útil para quem está a começar.
A pergunta de sempre, feita por gente muito diferente
A flair “Which LLM Should / Can I Use?” é a mais comum, e as máquinas são um retrato honesto do que as pessoas têm em casa. Um portátil com uma RTX 4050 de 6 GB e 16 GB de RAM. Um MacBook Air de 2020, ainda com Intel e 8 GB. Um mini PC com Ryzen 7940HS e 64 GB de DDR5, onde o dono aumentou para 56 GB a memória que a gráfica integrada pode usar. Um i7 moderno sem gráfica, onde um modelo de 9B anda a uns 2 tokens por segundo, a correr dentro de uma VM Debian em cima de Windows (e só esse pormenor já dava uma conversa).
O que mais me chamou a atenção foi um programador que usa o Claude Code no trabalho a sério e diz claramente que não quer substituí-lo. Quer perceber se um modelo local, num Dell com um i3 de 11.ª geração, serve para as tarefas pequenas do dia a dia. É a pergunta certa. O modelo local raramente substitui o melhor modelo da nuvem, mas pode tirar-lhe muito trabalho de cima, e esse trabalho deixa de sair de casa.
Os que já lá chegaram
A outra metade do feed são respostas com números, e é aqui que se aprende.
Um utilizador corre uma variante do Qwen3.6-35B-A3B numa RTX 2060 de 6 GB com 32 GB de DDR4, com 131 mil tokens de contexto e visão. Começa a uns 600 tokens por segundo no processamento do prompt e 23 na geração, e quando a conversa chega aos 90 mil tokens estabiliza em cerca de 485 e 15. O projetor de visão corre na CPU para não roubar VRAM.
Outro tem um Dell T5810 com um Xeon E5-2680 v3 e uma 1080 Ti, a correr Jellyfin, Immich e chiama.cpp num contentor LXC do Proxmox. Usa um modelo de 9B para reescrever emails e relatórios, a cerca de 35 tokens por segundo, que caem para uns 22 quando o Jellyfin está a transcodificar. Quem leu o post sobre os serviços essenciais do homelab percebe porque é que isto me fez sorrir: é o homelab clássico, com um LLM encaixado ao lado dos outros serviços, a partilhar a mesma gráfica.
E há o caso mais extremo de “low end” honesto: uma GTX 1060 de 3 GB, um processador AMD E2-2000 e 8 GB de DDR3, com componentes de dez a quinze anos. Modelos pequenos a 20 a 30 tokens por segundo.
Hardware que não devia servir para isto
A flair “Unusual Hardware” é onde o sub se diverte, e o próprio criador dá o exemplo: partilhou um projeto que pega numa PS5 desbloqueada e põe a gráfica dela a correr um modelo de 27B, quantizado a 2 bits, a uns 20 tokens por segundo, com o painel a mostrar cerca de 86 W de consumo. Noutro post, alguém meteu um modelo de linguagem com uns 370 mil parâmetros dentro de um Game Boy Color. Não serve para nada de prático, e não precisa de servir.
Do lado menos divertido, as perguntas sobre as NPUs dos portáteis novos (um Snapdragon X Elite, um Framework 12) ficam quase sem resposta. Prometem muito, mas por enquanto quase ninguém as usa para LLMs de forma útil.
A comunidade a construir ferramentas
O que distingue um sub vivo de um fórum de dúvidas é haver gente a construir coisas. No feed aparecem versões afinadas de modelos pequenos para programação, um motor de inferência chamado Strata (do projeto PolyStrata) onde os utilizadores votam no próximo modelo a suportar, um motor de memória para RAG que corre em menos de 1,2 GB ou só em CPU, um MoE ternário de 20B com apenas 1B ativo que ocupa uns 5,5 GB, e alguém que pegou no Qwen3.6-35B-A3B e lhe cortou dez das quarenta camadas para o pôr mais rápido, gastando uns 50 dólares a recuperar parte da qualidade perdida.
Um pormenor de que gostei: o autor do motor de RAG abre o post a dizer que é o criador e único programador do projeto. Num nicho onde muita gente vem divulgar o que fez, esta transparência devia ser regra.
O que os números do feed ensinam
Ler estes relatos com proveito exige perceber duas restrições que explicam quase tudo.
A primeira é a capacidade. O modelo, já quantizado, tem de caber na memória disponível, e ainda tem de sobrar espaço para a KV cache, a memória onde fica o estado da conversa. Quantizar é guardar os pesos com menos bits (quatro ou cinco em vez de 16), com uma perda de qualidade que costuma ser aceitável até por volta dos quatro bits.
A segunda é a largura de banda da memória, e é a que quase ninguém considera quando começa. Para gerar cada token, o motor de inferência tem de ler da memória os pesos ativos do modelo, por isso o teto de velocidade é, grosso modo, a largura de banda a dividir pelo volume de pesos lidos por token. Não é por acaso que um dos posts sobre portáteis com 8 GB de VRAM refere logo os 250 GB/s da RTX 4060: quem já anda nisto há algum tempo olha primeiro para esse número. E outro utilizador, a pensar comprar várias RTX 3060 baratas para uma máquina de quatro a oito gráficas, pergunta exatamente se a largura de banda delas não vai ser o gargalo antes de ele carregar no botão de comprar.
Os modelos MoE (Mixture of Experts) são a razão de tanta gente com pouca VRAM conseguir coisas que parecem impossíveis. O modelo tem muitos parâmetros no total mas, para cada token, só ativa uma fração deles. O Qwen3.6-35B tem 35 mil milhões de parâmetros e cerca de 3 mil milhões ativos. Precisas de memória para o modelo inteiro, que pode viver em grande parte na RAM do sistema, mas cada token custa mais ou menos o mesmo que num modelo de 3B. É isso que explica a RTX 2060 com 131 mil tokens de contexto, e é por isso que o mesmo modelo aparece em metade dos posts do sub. O autor da versão podada percebe isto bem: diz que cortar especialistas poupa disco mas não muda a largura de banda gasta por token, e que por isso preferiu cortar camadas inteiras.
O exemplo da 2060 mostra ainda uma terceira coisa: o contexto não é gratuito. A velocidade de geração cai de 23 para 15 tokens por segundo à medida que a conversa cresce. Outro utilizador, que corre o mesmo modelo numa 3060 de 12 GB com 32 GB de DDR4, está limitado a 42 mil tokens de contexto e pensa juntar-lhe uma 1660 Ti de 6 GB que tem na gaveta só para ganhar espaço para mais contexto.
Lento não quer dizer inútil
O post que mais me fez pensar foi o de um modelo de programação afinado, o SharpSpark. O autor pegou num modelo de 4B, melhorou a quantização, corrigiu o template de conversa e trabalhou o prompt de sistema, e chegou a um ficheiro de 3,6 GB. Depois correu-o num benchmark de engenharia de software com 17 problemas reais, três vezes cada. Resolveu em média 5,7 dos 17. O Claude Haiku 4.5, em esforço elevado, resolveu 5,0 no mesmo teste.
Antes que alguém se entusiasme: o modelo pequeno demorou em média 74 minutos por problema resolvido, contra 21 do Haiku. E 17 problemas é uma amostra pequena, medida pelo próprio autor. Mas o número interessante é outro: a versão original do mesmo modelo, sem as afinações, resolvia 3,7 e demorava 145 minutos. O trabalho em cima do modelo valeu mais do que trocar de modelo. Um post irmão, com um modelo de 2B de 2,5 GB para gráficas de 4 GB, chega a 6,3 em 17.
Outro utilizador fez um benchmark agêntico pessoal com seis modelos pequenos, entre 2B e 12B, e chegou a uma conclusão que me parece útil para quem está a começar: em seguir instruções e perceber o que lê, todos ficam mais ou menos ao mesmo nível. Um modelo de 2B com 2,5 GB fica poucos pontos atrás de um de 9B com quatro vezes o tamanho.
Tudo isto aponta na mesma direção. A maior parte das pessoas avalia um modelo local como avalia o ChatGPT: escreve uma pergunta e fica a olhar para o ecrã à espera. A cinco tokens por segundo, essa experiência é má. Mas muito do que um LLM faz bem não precisa de ser interativo. Reescrever um email, como o dono do 1080 Ti. Sugerir etiquetas para as faturas digitalizadas no Paperless-ngx. Resumir durante a noite a pasta de PDFs da semana. Resolver um problema de programação enquanto vais almoçar. Nestes casos, a métrica deixa de ser tokens por segundo e passa a ser tarefas por noite. E um portátil velho, ligado à corrente num canto, faz muitas tarefas por noite, gastando uma fração da luz de uma gráfica de topo.
Como usar o sub para começar o teu caminho
Com método, o sub poupa-te semanas. Esta é a sequência que eu seguiria se estivesse a começar hoje.
- Faz o inventário da tua máquina: RAM total e velocidade, se está em dual channel, gráfica e VRAM (dedicada ou integrada), CPU, sistema operativo. Sem isto não consegues comparar nada com ninguém.
- Usa as flairs como filtro. “Which LLM Should / Can I Use?” para ver perguntas parecidas com a tua, “Guide / Tutorial” e “Optimization” para configurações completas, “Benchmark” para números.
- Procura alguém com uma máquina parecida. A tua gráfica, o teu CPU, a tua quantidade de RAM. Se não houver, pergunta.
- Reproduz antes de inventar. Pega na configuração de alguém e tenta obter números parecidos. Se não conseguires, descobrir porquê ensina mais do que qualquer tutorial.
- Escolhe uma tarefa, não “o melhor modelo”. “Qual é o melhor modelo para 16 GB?” não tem resposta. “Qual é o melhor modelo para reescrever emails em português numa máquina com 16 GB?” já tem.
- Mede, com uma ferramenta que os outros também usem, e publica o resultado, falhanços incluídos.
- Só depois pensa em comprar. Nessa altura vais saber exatamente que limite queres levantar: capacidade, largura de banda ou compatibilidade.
Para medir, o llama-bench, que vem com o llama.cpp, dá os dois números que interessam, processamento do prompt e geração:
llama-bench -m modelo.gguf -p 512 -n 128
Para o primeiro contacto, o LM Studio continua a ser a porta de entrada mais simpática, com interface gráfica e indicação de se o modelo cabe na tua máquina. O Ollama é o passo seguinte, para quem quer um serviço sempre ligado que outras aplicações usem (como o Open WebUI que tenho no Mac mini cá de casa). E o llama.cpp é onde vive o controlo fino, e é a base de quase tudo o que se faz no sub.
O que o sub não te dá, e os cuidados a ter
Seria desonesto não deixar a lista do outro lado.
Os benchmarks de terceiros são ruidosos. Um portátil que faz um número bonito nos primeiros dois minutos pode baixar a frequência logo a seguir, quando aquece, e duas máquinas com o mesmo CPU podem ter RAM a velocidades muito diferentes. Trata os números alheios como ordem de grandeza, não como promessa.
A compatibilidade continua a ser o limite mais duro. Há no feed um pai com um portátil com Radeon RX 6600M que só queria gerar desenhos simples para os filhos. Seguiu as instruções que o ChatGPT lhe deu, tentou PyTorch com DirectML, e falhou sempre. Um amigo disse-lhe que sem NVIDIA não ia lá. Não é bem assim, mas também não é mentira nenhuma: fora do ecossistema CUDA, o caminho é mais estreito e mais mal sinalizado. O low end não é só falta de memória.
Grande parte do que se faz no sub corre em forks: do llama.cpp, de motores alternativos, de modelos podados ou reconvertidos por desconhecidos. Há até um post só a perguntar que forks a malta com 8 GB de VRAM anda a usar. É assim que o nicho avança, e é também uma superfície de ataque. Escrevi em agosto sobre o LiteLLM envenenado durante quarenta minutos, e a lição aplica-se aqui na perfeição: prefere fontes conhecidas, lê o script antes de o correr com sudo, e desconfia do repositório com dois dias de vida e estrelas a mais.
As ferramentas da comunidade também morrem. Um dos posts mais votados pergunta o que aconteceu ao GPU Poor LLM Arena, um espaço na Hugging Face que comparava modelos para hardware fraco e que deixou de ser mantido. Mais um argumento para guardares os teus próprios números.
E há uma ironia que não posso deixar passar. Um sub sobre correr IA em casa, precisamente para não mandar os teus dados para terceiros, vive no Reddit, que é a nuvem de um terceiro e que tem acordos para licenciar o que lá se publica para treino de modelos. Escrevi sobre isso há umas semanas. Não é motivo para não participar, é motivo para pensar no que publicas: nada de logs com nomes de ficheiros pessoais ou excertos dos documentos que estás a processar.
Porque é que isto me importa
Volto à pessoa do email, a do portátil de há quatro anos e da vergonha.
O que o r/LowEndLocalAI faz, quando corre bem, é tirar a vergonha da equação. Diz a essa pessoa que a pergunta dela é legítima, que há mais gente com a mesma máquina e as mesmas dúvidas, e que alguém com uma 2060, uma 1060 de 3 GB ou um Xeon reformado já fez o caminho e deixou os números.
Tenho escrito muitas vezes que a soberania sobre os nossos dados começa por sabermos correr as coisas nós mesmos. Se a única porta de entrada para a IA local for uma gráfica de dois mil euros, então a IA local é para uma minoria, e toda a gente fica com a nuvem por falta de alternativa. Quanto mais pessoas aprenderem a correr um modelo útil no portátil que já têm, mais percebem o que está em jogo quando entregam os dados a terceiros, e mais ficam com competências para, mais tarde, operar estas coisas a sério.
Há uma gaveta em quase todas as casas portuguesas com um portátil que foi substituído e que ninguém teve coragem de deitar fora. Tem 8 ou 16 GB de RAM, uma bateria cansada e um ecrã que já viu melhores dias. Tira-o da gaveta este fim de semana, liga-o à corrente, instala um Linux leve e o llama.cpp, e vê o que ele consegue fazer. Se alguém conseguiu pôr um modelo dentro de um Game Boy, o teu portátil não tem desculpa.
Depois conta no sub. Com a especificação completa, claro.
Até ao próximo post!
Nuno
Documentação:
A comunidade
- https://www.reddit.com/r/LowEndLocalAI/ (o feed, as flairs e os posts referidos neste artigo)
- https://www.reddit.com/r/LocalLLaMA/comments/1vxd6yb/please_join_rlowendlocalai_a_community_for/ (o post de apresentação, com a lista de temas e a definição de “low end”)
Projetos e recursos que aparecem no feed
- https://github.com/VecSzn/PolyStrata (o motor de inferência Strata e a votação do próximo modelo)
- https://huggingface.co/spaces/k-mktr/gpu-poor-llm-arena (o GPU Poor LLM Arena, já sem manutenção)
- https://huggingface.co/LiquidAI/LFM2.5-24B-A2B-GGUF (LFM 2.5 24B A2B, outro MoE com poucos parâmetros ativos)
- https://huggingface.co/nvidia/NVIDIA-Nemotron-Labs-Dory1.0-4B-BF16 (um dos modelos pequenos anunciados no sub)
- https://artificialanalysis.ai/hardware-inference-stack/mobile-phones (benchmark de modelos pequenos em telemóveis)
- https://selfhostedintelligence.com/en/benchmarks/rtt/v2610 (benchmark de tradução com várias quantizações)
Modelos e ferramentas
- https://qwen.ai/blog?id=qwen3.6-35b-a3b (o Qwen3.6-35B-A3B, o MoE que aparece em metade dos posts)
- https://ai.google.dev/gemma/docs/core (família Gemma 4)
- https://lmstudio.ai/
- https://github.com/ollama/ollama
- https://github.com/ggml-org/llama.cpp (inclui o llama-bench)
Posts anteriores referidos
- https://blog.nuneshiggs.com/o-teu-homelab-quais-os-servicos-self-hosted-essenciais/ (os serviços essenciais do homelab, incluindo Jellyfin, Immich e Paperless-ngx)
- https://blog.nuneshiggs.com/o-que-o-homelab-me-ensinou-sobre-escalar-infraestrutura-nao-esta-na-tabela-do-open-webui-esta-em-tudo-o-que-parti-quando-ainda-era-barato-partir/ (o homelab como escola, e o Open WebUI cá de casa)
- https://blog.nuneshiggs.com/envenenaram-o-litellm-durante-40-minutos-e-apanharam-segredos-de-2500-organizacoes-e-o-mais-me-incomoda-e-que-quase-ninguém-escolheu-instala-lo/ (dependências que ninguém escolheu)
- https://blog.nuneshiggs.com/tudo-o-que-escreveste-online-nos-ultimos-vinte-anos-pode-passar-a-ser-materia-prima-de-ia-sem-te-perguntarem-nada/ (o que publicas online como matéria-prima de treino)
