Desde que pulei de cabeça na toca do coelho local do LLM, tenho uma queda por reviver computadores antigos, transformando-os em estações de trabalho de IA confiáveis. Com os ajustes certos, consegui até executar LLMs poderosos que podem competir com seus equivalentes na nuvem em algo tão desatualizado quanto uma máquina de 10 anos. No entanto, a maioria dos meus rigorosos experimentos de LLM envolvem sistemas de jogos x86 completos com placas gráficas dedicadas e RAM redundante.
Isso significa que o Raspberry Pi 5 pode lidar com até 4 modelos B sem dobrar sob carga extra, o que o torna uma opção surpreendentemente adequada para hospedar modelos incorporados e chatbots simples. Mas como eu queria executar modelos que não estavam incluídos neste SBC, achei melhor tentar agrupar algumas placas sobressalentes. E bem, este é provavelmente um dos projetos mais amaldiçoados em que já trabalhei (mas ainda tem alguma utilidade).
Substituí ChatGPT e Claude por este poderoso LLM nativo e economizei mais de US$ 20 por mês enquanto obtive controle total
Qwen3.6 roda na minha GPU antiga e faz o que o ChatGPT faz de graça
Construir o cluster Lama.cpp não foi tão difícil
No entanto, tive que compilar o mecanismo de inferência em ambos os sistemas
Começando com os SBCs que eu queria usar como cobaias membros deste projeto, planejei inicialmente criar um conjunto de três dispositivos. No entanto, rapidamente percebi que a maioria das minhas placas ARM já estavam envolvidas em algum experimento ou outro, deixando o Raspberry Pi 5, o Libre Computer Alta e o Le Frite como as únicas opções viáveis. Infelizmente, o Le Frite é extremamente fraco para este projeto, e seu soquete USB 2.0 e 100M acabariam estreitando o já fraco setup. Então escolhi um cluster de 2 nós composto por um Raspberry Pi 5 (8GB) e um Libre Computer Alta (4GB), com um backend RPC em llama.cpp que divide as tarefas de inferência entre os dois sistemas.
Felizmente, o processo de configuração foi muito mais fácil do que eu esperava, embora eu tivesse que compilar o llama.cpp do zero. Depois de armar ambos os sistemas com uma distribuição CLI (uma versão mais antiga do Ubuntu Alta e uma versão Raspberry Pi OS Lite, você sabe o que) e configurar servidor opensshEu entrei neles usando PuTTY e instalei os pacotes necessários na inicialização sudo apt install -y git build-essential cmake pkg-config. Em seguida, clonei o repositório llama.cpp com clone do git https://github.com/ggml-org/llama.cpp.git e mudou para seu diretório recém-criado usando cd lama.cpp equipe. Finalmente, criei outra pasta chamada build-rpc usando mkdir -p build-rpc antes de mudar para ele e executar os seguintes comandos para compilar llama.cpp com recursos RPC:
cmake .. -DGGML_RPC=ON -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release -j$(nproc)
Como eu queria que o Alta SBC atuasse como uma máquina servidora secundária, executei ./bin/rpc-server -H 0.0.0.0 -p 50052 para ele e deixe o servidor RPC permanecer ativo por um tempo. Depois de usar o comando SCP para mover alguns LLMs do meu computador principal para o nó Raspberry Pi, eu estava pronto e funcionando ./bin/llama-server -m /home/ayush/models/Qwen3.5-2B-Q4_K_M.gguf –rpc 192.168.0.150:50053 –host 0.0.0.0 –porta 8080 comando e esperou que ele terminasse de carregar o modelo.
Acontece que o desempenho do cluster foi pior que o de um único SBC
Eu culpo as provisões de rede lentas por este ponto fraco
Como estou usando um Gemma 3 4B bastante leve, esperava que meu cluster tivesse um desempenho um pouco melhor do que apenas meu Raspberry Pi. No entanto, executar alguns prompts por meio da interface da web do servidor lhama provou o contrário. E também não estou falando de prompts complexos ou inferências relacionadas a servidores MCP. Um cluster tão simples como “Diga-me algo legal” teria dificuldade para atingir 2,20 tokens por segundo. Então, reiniciei meu Raspberry Pi e executei o comando lama-server novamente. Só que desta vez me livrei do sinalizador –rpc. Com certeza, o mecanismo de inferência conseguiu atingir 4,37 t/s, quase duas vezes mais rápido que a configuração do cluster!
Em teoria, o cluster deveria atingir taxas de geração de token mais altas ou, pelo menos, fornecer taxas comparáveis a uma configuração somente Raspberry Pi. Mas faz todo o sentido quando considero os gargalos de rede e armazenamento na equação. Veja, ambos os SBCs têm uma conexão de 1 GbE, o que é um pouco lento para inferência de IA de alta velocidade. Para piorar a situação, fiquei sem SSDs no meu laboratório doméstico, então tive que me contentar apenas com cartões microSD, o que definitivamente contribui para o fator velocidade (ou falta dele). Observe que as operações LLM são muito sensíveis à latência e é óbvio por que meu cluster está apresentando um desempenho horrível. Eu ia chamar esse projeto de fracasso e começar aqui, mas queria tentar um último experimento antes de matar o cluster…
Ollama ainda é a maneira mais fácil de iniciar LLMs locais, mas a pior maneira de mantê-los funcionando
Ollama é ótimo para começar… só não perca tempo.
Mas o cluster pode executar LLM, que de outra forma seria muito pesado para meu RPi
Só não olhe para a taxa de geração de tokens
Embora seu desempenho medíocre fosse uma chatice total, meu principal objetivo para esse projeto estranho era rodar modelos grandes que um Raspberry Pi com apenas 8 GB de RAM não seria capaz de hospedar. Então girei o servidor lhama novamente sem o sinalizador RPC e comecei a aumentar o tamanho dos parâmetros do modelo. Qwen 3.5 (9B) é onde o servidor lhama travou porque o SBC não conseguiu acomodar o modelo grande.
Mas quando o executei com o sinalizador RPC apontando para Alta, o servidor lhama conseguiu carregar o LLM com relativa facilidade. Para satisfazer minha curiosidade, abri a interface da web e comecei a solicitar o LLM. Bem, certamente funcionou, embora só pudesse gerar 1,27 tokens por segundo. Para minhas tarefas de produtividade e carga de trabalho de codificação, isso está longe de ser possível. Mas ainda é utilizável para tarefas automatizadas, como geração de marcadores ou digitalização de documentos OCR, especialmente porque posso deixar meus SBCs funcionando o dia todo sem me preocupar com o consumo de energia.
E para ser totalmente honesto, imaginei que acabaria medindo segundos por token em vez de tokens por segundo. Portanto, uma taxa de geração de token de 1,27 t/s é um pouco surpreendente, especialmente porque é um modelo que meu SBC nem conseguiu carregar para começar. Embora eu provavelmente não usaria esse cluster para tarefas de inferência SBC, o RPC certamente parece útil. Na verdade, posso tentar usá-lo em minhas atuais estações de trabalho de hospedagem LLM baseadas em LXC que possuem NICs 10G completos.
