8 modelos locais de IA em um Raspberry Pi 5: só 3 são utilizáveis

Autoria: Zero to MVP · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: 8 Local AI Models on a Raspberry Pi 5: Only 3 Are Usable · Canal: Zero to MVP · 09:52 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

O vídeo testa oito modelos locais em um Raspberry Pi 5 com 8 GB de RAM, avaliando velocidade, tempo até a primeira resposta e desempenho em quatro tarefas práticas. Pelos critérios definidos, cinco modelos são rápidos o bastante para chat, mas apenas três passam em todas as tarefas: Granite, Gemma 3n E2B e Gemma 3n E4B. Gemma 3n E2B e Granite são as escolhas recomendadas para chat; Gemma 3n E4B se destaca em tarefas em segundo plano, mas é lenta para conversar. O apresentador também conclui que modelos nessa velocidade não são adequados para programação e recomenda usar dois threads na maioria dos casos.

Pontos-chave

O teste foi feito em um Raspberry Pi 5 com 8 GB de RAM, usando llama.cpp e modelos quantizados em 4 bits, com exceção do Bonsai.
Para ser considerado adequado para chat, o modelo deveria gerar cerca de cinco tokens por segundo e começar a responder em até 10 segundos.
Qwen 3.5 com 0,8 bilhão de parâmetros foi o mais rápido, com quase 15 tokens por segundo; LFM 2.5 passou de 10, mas levou cerca de 17 segundos para começar a responder.
Cinco modelos passaram o critério de velocidade para chat: Qwen 3.5 0.8B, MiniCPM-5, Gemma 3n E2B, Bonsai e Granite.
Granite, Gemma 3n E2B e Gemma 3n E4B passaram nas quatro tarefas testadas.
Bonsai e Qwen 3.5 4B falharam apenas na tarefa de resumo; o apresentador sugere considerá-los se resumir textos não for essencial.
Na maioria dos casos, usar dois threads resultou em geração de texto 18% a 38% mais rápida do que usar quatro.
O vídeo não inclui testes de programação: o apresentador considera a geração lenta demais para esse uso.

Capítulos

Início	Capítulo	Resumo
00:00	Objetivos e critérios de usabilidade	O apresentador explica as perguntas do teste e define limites de velocidade e estabilidade para chat e tarefas em segundo plano.
02:04	Configuração e modelos testados	São apresentados o método de medição, a quantização e os oito modelos avaliados no Raspberry Pi 5.
04:11	Velocidade e adequação para chat	Os resultados de geração e tempo até a primeira resposta mostram quais modelos atendem ao critério de velocidade para chat.
06:15	Resultados nas quatro tarefas	Os modelos são avaliados em resumo, organização de arquivos, geração de JSON e uso de ferramentas.
08:52	Recomendações finais	O apresentador recomenda modelos diferentes para chat e tarefas em segundo plano e aponta Gemma 3n E2B como sua escolha única.

Citações

Só porque um modelo roda não significa que ele seja realmente utilizável. — 00:00

Vou considerar um modelo utilizável para chat se ele gerar pelo menos cerca de cinco tokens por segundo. — 00:32

No geral, cinco dos oito modelos passaram o limite para chat. — 05:44

Nessas velocidades, até uma função simples demora demais para ser gerada. — 08:20

Se eu pudesse manter apenas um modelo neste Raspberry Pi, escolheria Gemma 3n E2B. — 09:22

Conceitos e entidades

Raspberry Pi 5 (ferramenta): Computador de placa única usado para executar e testar os modelos locais.
llama.cpp (ferramenta): Mecanismo usado para executar os modelos e medir seu desempenho no Raspberry Pi.
llama.bench (ferramenta): Ferramenta de benchmark incluída no llama.cpp, usada para medir o processamento do prompt e a geração de respostas.
Q4_K_M (conceito): Formato de quantização de 4 bits usado pela maioria dos modelos testados.
Qwen3.5 (modelo): Família de modelos testada nas variantes de 0,8 bilhão e 4 bilhões de parâmetros.
Bonsai (modelo): Modelo de 8 bilhões de parâmetros quantizado em 1 bit, que passou nos testes exceto na tarefa de resumo.
MiniCPM-5 (modelo): Modelo testado que teve bom desempenho de velocidade, mas falhou em algumas tarefas, inclusive no uso de ferramentas.
Granite (modelo): Modelo de 3 bilhões de parâmetros que passou nas quatro tarefas e foi recomendado para chat.
Gemma 3n E2B (modelo): Modelo que passou nas quatro tarefas e foi recomendado para chat no Raspberry Pi 5.
Gemma 3n E4B (modelo): Modelo que passou nas quatro tarefas, mas foi considerado lento demais para chat e indicado para tarefas em segundo plano.
LFM 2.5 (modelo): Modelo com arquitetura de mistura de especialistas que ativa cerca de 1,5 bilhão de parâmetros por token, mas demora para começar a responder.

Tradução completa (pt-BR)

00:00 Já existem muitos modelos locais pequenos que conseguem rodar fisicamente em um Raspberry Pi 5, mas o fato de um modelo rodar não significa que ele seja realmente utilizável. Então, hoje vou tentar responder a duas perguntas. Primeiro: há algum valor real em rodar um LLM em um Raspberry Pi? E, segundo: qual modelo você deve usar? Testei oito modelos locais no meu Raspberry Pi 5 para responder a essas perguntas. Medi a velocidade de cada um em tokens por segundo e dei a eles o tipo de tarefa que um modelo pequeno

00:32 deveria realisticamente conseguir realizar. Ao final deste vídeo, você saberá quais são realmente utilizáveis, quais servem apenas para tarefas em segundo plano e quais provavelmente pode descartar. Primeiro, deixe-me explicar o que quero dizer com “utilizável”, para que minhas conclusões no final não se baseiem no que eu por acaso sinto, mas em critérios objetivos. Vou considerar um modelo utilizável para chat se conseguir gerar pelo menos cerca de cinco tokens por segundo. Essa é mais ou menos a velocidade mínima em que uma pessoa consegue ler

01:03 uma resposta com certo conforto. Outro critério importante será a rapidez com que ele começa a responder a uma pergunta curta. Isso não deve levar mais de 10 segundos. Certo, agora vamos falar sobre o uso de modelos em segundo plano. Nesse caso, a velocidade não é tão importante. No entanto, o modelo precisa passar por todas as tarefas de teste e rodar por meia hora sem fazer o Raspberry Pi superaquecer ou reduzir o desempenho. Se um modelo não atender a esses critérios e não puder funcionar nem no modo de chat nem em segundo plano, então eu

01:33 o considero inutilizável em um Raspberry Pi. Certo, algumas palavras sobre a configuração de hoje. Vou usar um Raspberry Pi 5 com 8 GB de RAM, um cooler ativo e dois SSDs conectados a ele. O sistema operacional está instalado no primeiro SSD, e o Pi inicia por ele, enquanto os modelos ficam armazenados no segundo. Todos os modelos rodam pelo llama.cpp, o mesmo agent usado nos bastidores pelo LM Studio e pelo Ollama. Ele inclui uma ferramenta de benchmark chamada

02:04 llama.bench, que nos dá dois números que serão importantes hoje: a rapidez com que o modelo processa seu prompt e a rapidez com que gera a resposta. Todos os modelos, com uma exceção, usam a mesma quantização de 4 bits, Q4_KM, e o mesmo tamanho de context window. A exceção é o Bonsai. Ele foi lançado desde o início como um modelo de 1 bit, mas falarei mais sobre ele depois. Desativei o modo de raciocínio sempre que era possível. Para tarefas curtas, ele não é necessário; apenas desperdiça tempo. Mas um modelo, o LFM 2.5, sempre raciocina. Então, incluí esse tempo de raciocínio nos resultados dele.

02:36 Certo, aqui está a lista de participantes, ordenados do menor arquivo de modelo para o maior. São eles: Qwen 3.5 com 0,8 bilhão de parâmetros, Bonsai com 8 bilhões de parâmetros, MiniCPM-5 com 2 bilhões de parâmetros, Granite 4.2 com 3 bilhões de parâmetros, Qwen 3.5 com 4 bilhões de parâmetros, Gemma 4 E2B,

03:07 Gemma 4 E4B e LFM 2.5 com 8 bilhões de parâmetros. Como você pode ver, há uma faixa bem ampla de quantidades de parâmetros: desde um modelo minúsculo com menos de 1 bilhão de parâmetros até um com 8 bilhões. Quase todos foram lançados este ano, e estes estão entre os modelos pequenos mais populares que cabem em 8 GB de memória. Dois dos modelos desta lista são incomuns. O primeiro é o Bonsai, com 8 bilhões de parâmetros, mas apenas um bit por peso. Por isso, o arquivo inteiro do modelo tem

03:39 pouco mais de 1 GB. O outro é o LFM 2.5. Ele tem o maior arquivo da lista, mas, graças à sua arquitetura especial de mistura de especialistas, não usa todos os parâmetros ao gerar cada token, apenas cerca de 1,5 bilhão. Isso permite que ele continue razoavelmente rápido e rode bem em um Raspberry Pi. Certo, agora vamos passar aos testes propriamente ditos. Vamos começar pela velocidade de geração das respostas. Medi cada número várias vezes porque, em um Raspberry Pi,

04:11 uma execução pode diferir bastante de outra. O modelo mais rápido é o menor, o Qwen 3.5 com 0,8 bilhão de parâmetros: quase 15 tokens por segundo. Em segundo lugar está o maior modelo, o LFM 2.5. Ele roda a mais de 10 tokens por segundo, mas lembre-se de que apenas 1,5 bilhão de parâmetros ficam ativos nesse modelo. Em seguida vêm o MiniCPM-5 e o Gemma 4 E2B, com cerca de sete. O Bonsai e o

04:42 Granite ficam um pouco acima do limite. Já o Gemma 4 E4B e o Qwen 3.5 com 4 bilhões de parâmetros ficam em torno de 3,5. Isso é mais lento que o limite que defini no início. Lembre-se: precisa ser pelo menos cinco. Na prática, é assim: a 15 tokens por segundo, o texto aparece mais rápido do que você consegue ler. A sete, o ritmo é confortável. E, a 3,5, você fica esperando cada palavra. E uma coisa que eu não esperava: quase todos esses números foram medidos usando dois

05:14 núcleos de CPU, não quatro. Com duas threads, os modelos geram texto de 18 a 38 por cento mais rápido. A exceção é o Bonsai: ele precisa dos quatro. Acho que, nesse caso, a geração no Raspberry é limitada pela largura de banda da memória, e não pelo desempenho da CPU. Então, minha conclusão prática é simples: use duas threads. O segundo critério que defini foi a rapidez com que a resposta começa. Todos os modelos, com uma exceção, começam a responder em 2,5 segundos ou

05:44 menos. A exceção é o LFM 2.5. Ele sempre raciocina primeiro, e as primeiras palavras só aparecem após 17 segundos. Então, no total, cinco dos oito modelos passaram no limite para chat: Qwen 3.5 com 0,8 bilhão de parâmetros, MiniCPM-5, Gemma 4 E2B, Bonsai e Granite. O Gemma 4 E4B e o Qwen 3.5 com 4 bilhões de parâmetros são lentos demais para chat, enquanto o LFM 2.5 demora demais raciocinando. Mas a velocidade

06:15 por si só não torna um modelo utilizável. Um modelo rápido que dá a resposta errada é pior do que um modelo lento que dá a resposta certa, especialmente para tarefas em segundo plano. Então, agora vamos avaliar que tipo de tarefas esses modelos realmente conseguem realizar. Cada modelo recebeu as mesmas quatro tarefas. Elas não foram escolhidas ao acaso. São tarefas úteis que um Raspberry Pi consegue realisticamente executar. Não há pontuação parcial. A resposta funciona ou não funciona. Tarefa um: resumo.

06:48 Um artigo de 800 palavras resumido em três tópicos. Todos os fatos do artigo são reais, não inventados. E, aqui, quatro dos oito modelos falharam. O Qwen 3.5 com 4 bilhões de parâmetros escreveu algo que não estava no artigo. O LFM 2.5 alterou um dos fatos. O Bonsai acrescentou algo que não estava lá. E o MiniCPM-5 não captou a ideia principal do artigo. Tarefa dois: organizar 25 arquivos da pasta de downloads em seis pastas.

07:19 Essa é uma tarefa típica para um servidor doméstico. Aqui, quase todos deram conta. No geral, tudo correu bem. Mas dois modelos falharam. O Qwen 3.5 com 0,8 bilhão de parâmetros perdeu oito arquivos, enquanto o LFM 2.5 passou 5 minutos pensando e depois simplesmente se esqueceu de dois arquivos. Tarefa três: transformar um e-mail de pedido em JSON. O critério aqui é simples. A saída precisa ser um JSON válido, porque, caso contrário, não dá para fazer nada com segurança com essa

07:50 resposta depois. E aqui vem a surpresa: todos os modelos produziram JSON válido. No entanto, alguns modelos cometeram erros no conteúdo. Foram eles o menor modelo do teste de hoje, o Qwen 3.5 com 0,8 bilhão de parâmetros, e também o MiniCPM-5. Tarefa quatro: chamar uma ferramenta. É uma única função: mover um arquivo para uma pasta, com três arquivos processados um após o outro. Se um modelo não consegue chamar ferramentas, não dá para criar um agent em torno dele. O MiniCPM-5

08:20 falhou nesta tarefa. Respondeu que estava movendo o arquivo naquele momento e não fez nada. E o LFM 2.5 tentou colocar uma foto em uma pasta de arquivo que não existe. E um ponto importante: deliberadamente não incluí um teste de programação. Nessas velocidades, até uma função simples demora demais para ser gerada. Então, não faz muito sentido usar modelos como estes para programação. E, no fim, três modelos passaram nas quatro tarefas: Granite, Gemma 4 E2B e Gemma 4 E4B.

08:52 O Bonsai e o Qwen 3.5 com 4 bilhões de parâmetros falharam apenas na tarefa de resumo. Você pode tentar usá-los para organizar arquivos, mas não para escrever resumos. Então, acho que chegou a hora de concluir e decidir quais modelos são realmente utilizáveis em um Raspberry Pi 5. Para chat, eu escolheria o Gemma 4 E2B e o Granite com 3 bilhões de parâmetros. Eles são rápidos o suficiente e passaram nas quatro tarefas. Para tarefas em segundo plano, sem dúvida, o Gemma 4 E4B. Ele deu conta de tudo, mas

09:22 Infelizmente, é lento demais para conversar. Bonsai e Qwen 3.5 com 4 bilhões de parâmetros quase entraram na lista final. Eles dão conta de tudo, exceto de resumir textos. Se isso não for essencial para você, pode experimentá-los com uso de ferramentas, mas eu não usaria outros modelos no Raspberry Pi 5, porque eles não passaram nos meus testes. E, se eu pudesse manter apenas um modelo neste Raspberry Pi, manteria o Gemma 4 82B. Ele passou em tudo e é o mais rápido dos finalistas. E

09:52 É só isso por hoje. Não se esqueça de se inscrever no canal e na minha newsletter semanal sobre TI e IA. Você encontrará o link na descrição. Até breve. Cuide-se.

Transcrição original

[00:00] There are already plenty of small local models that can physically run on Raspberry Pi 5, but just because a model runs doesn’t mean it’s actually usable. So, today I’m going to try to answer two questions. First, is there any real value in running an LLM on a Raspberry Pi? And second, which model should you use? So, I tested eight local models on my Raspberry Pi 5 in order to answer these questions. I measured the speed of each one in tokens per second and gave them the kind of work that a small model

[00:32] should realistically be able to handle. So, by the end of this video, you’ll know which ones are actually usable, which are only suitable for background tasks, and which ones you can probably skip. First, let me explain what I mean by usable so that my conclusions at the end aren’t based on how I happen to feel, but on objective criteria. So, I’ll consider a model usable for chat if it can generate at least around five tokens per second. That’s roughly the minimum speed at which a person can read

[01:03] a response reasonably comfortably. Another important criterion will be how quickly it starts answering a short question. That should take no more than 10 seconds. Okay, now let’s talk about using models in the background. Here, speed isn’t that important. However, the model has to pass all of the test tasks and run for half an hour without causing the Raspberry Pi to overheat or throttle. If a model doesn’t meet these criteria and can’t work either in chat mode or in the background, then I

[01:33] consider it unusable for use on a Raspberry Pi. Okay, a few words about today’s setup. I’ll be using a Raspberry Pi 5 with 8 GB of RAM with an active cooler and two SSDs connected to it. The operating system is installed on the first SSD and the Pi boots from it, while the models are stored on the second one. All of the models run through llama.cpp, the same agent used under the hood by LM Studio and Ollama. It includes a benchmarking tool called

[02:04] llama.bench, which give us two number that we’ll care about today. How quickly the model processes your prompt and how quickly it generate the response. All of the models except one use the same 4-bit quantization, Q4_KM, and they all use the same context size. The exception is Bonsai. It was released as a 1-bit model from the start, but I’ll talk more about that one later. I disabled reasoning mode everywhere it could be disabled. For short tasks, it isn’t necessary, it

[02:36] only wastes time. But one model, LFM 2.5, always reasons. So, I include that reasoning time in its results. Okay, here’s the list of participants ordered from the smallest model file to the largest. They are Qwen 3.5 with 0.8 billion parameters, Bonsai with 8 billion parameters, MiniCPM-5 with 2 billion parameters, Granite 4.2 with 3 billion parameters, Qwen 3.5 with 4 billion parameters, Gemma 4e2b,

[03:07] Gemma 4e4b, and LFM 2.5 with 8 billion parameters. As you can see, there’s a pretty wide range in parameters counts. From a tiny model with less than 1 billion parameters all the way up to 8 billion. Almost all of them were released this year, and these are some of the most popular small models that can fit with 8 GB of memory. Two of the model here are unusual. The first is Bonsai with 8 billion parameters, but only one bit per weight. So, the entire model file is

[03:39] just a little over 1 GB. The other is LFM 2.5. It has the largest file in the list, but thanks to its special mixture of expert architecture, it doesn’t use all of its parameters when generating each token, only around 1 and 1/2 billion. That allows it to stay fairly fast and run reasonably well on a Raspberry Pi. Okay, now let’s move on to the actual testing. We’ll start with response generation speed. I measured each number several times because on a Raspberry Pi,

[04:11] one run can differ quite noticeably from another. The fastest model is the smallest one, Qwen 3.5 with 0.8 billion parameters, almost 15 tokens per second. In second place in the largest model, LFM 2.5. It runs at more than 10 tokens per second, but keep in mind that only 1 and 1/2 billion parameters are active in this model. Next come Mini CPM 5 and Gemma 4 82B, around seven. Bonsai and

[04:42] Granite are slightly above the threshold. And Gemma 4 84B and Qwen 3.5 with 4 billion parameters are at around 3 and 1/2. That’s slower than the limit I defined at the beginning. Remember, it needs to be at least five. In practice, it looks like this. At 15 tokens per second, the text appears faster than you can read it. At seven, it’s a comfortable pace. And at 3 and 1/2, you are waiting for every word. And one thing I didn’t expect, almost all of these numbers were measured using two

[05:14] CPU cores, not four. With two threads, the models generate text 18 to 38 percent faster. The exception is Bonsai, it needs all four. I think that in this case, generation on the Raspberry is limited by memory bandwidth rather than CPU performance. So, the practical takeaway for me is simple, use two threads. The second criterion I defined was how quickly the response starts. All of the models except one begin responding within 2 and 1/2 seconds or

[05:44] less. The exception is LFM 2.5. It always reasons first, and the first words only appear after 17 seconds. So, overall, five out of eight models passed the threshold for chat. Qwen 3.5 with 0.8 billion parameters, MiniCPM-5, Gemma 4 e2b, Bonsai, and Granite. Gemma 4 e4b and Qwen 3.5 with 4 billion parameters are too slow for chat, while LFM 2.5 spends too long reasoning. But, speed

[06:15] alone doesn’t make a model usable. A fast model that gives the wrong answer is worse than a slow model that gives the right one, especially for background tasks. So, now let’s move on to evaluating what kind of tasks these models are actually capable of handling. So, each model got the same four tasks. They weren’t chosen randomly. These are useful tasks that a Raspberry Pi can realistically handle. There are no partial points. The answer either works or it doesn’t. Task one, summarization.

[06:48] An 800-word article summarized into three bullet points. All the facts in the article are real, not made up. And here, four out of eight models failed. Qwen 3.5 with 4 billion parameters wrote something that wasn’t in the article. LFM 2.5 changed one of the facts. Bonsai added something that wasn’t there. And MiniCPM-5 missed the main point of the article. Task two, sort 25 files from the download folder into six folders.

[07:19] This is a typical job for a home server. Here, almost all of them handled it. So, overall, everything was fine. But, two models failed. Qwen 3.5 with 0.8 billion parameters lost eight files, while LFM 2.5 spent 5 minutes thinking and then simply forgot about two files. Task three, turn an order email into JSON. The criterion here is simple. The output has to be valid JSON because otherwise you can’t reliably do anything with that

[07:50] response afterward. And here’s the surprise. Every model produced valid JSON. However, some models made mistakes in the content. Those were the smallest model in today’s test, Qwen 3.5 with 0.8 billion parameters, as well as MiniCPM 5. Task four, call a tool. It’s a single function, move a file into a folder with three files processed one after another. If a model can’t call tools, you can’t build an agent around it. MiniCPM 5

[08:20] failed here. It replied that it was moving the file now and did nothing. And LFM 2.5 tried to put a photo into archive folder that doesn’t exist. And one important moment, I deliberately didn’t include a coding test. At these speeds, even a simple function takes too long to generate. So, using models like these for coding doesn’t really make sense. And in the [clears throat] end, three models passed all four tasks. Granite, Gemma 4 E2B, and Gemma 4 E4B.

[08:52] Bonsai and Qwen 3.5 with 4 billion parameters failed only the summarization task. You can try them to organize files, but not to write summaries. So, I think it’s time to wrap things up and decide which model are actually usable on a Raspberry Pi 5. For chat, I would choose Gemma 4 E2B and Granite with 3 billion parameters. They are fast enough and passed all four tasks. For background tasks, definitely Gemma 4 E4B. It handled everything, but

[09:22] unfortunately it’s too slow for chat. Bonsai and Qwen 3.5 with 4 billion parameter almost made it to the final list. They handle everything except text summarization. If that isn’t critical for you, you can try them with tool use, but I wouldn’t use other models on Raspberry Pi 5 because they didn’t pass my tests. And if I could keep only one model on this Raspberry Pi, I would keep Gemma 4 82B. It passed everything and it’s the fastest of the finalists. And

[09:52] that’s it for today. Don’t forget to subscribe to the channel and to my weekly newsletter about IT and AI. You’ll find the link in the description. See you soon. Take care.