Não há como negar que as placas gráficas de última geração são ideais para hospedar grandes modelos de linguagem, especialmente para tarefas de produtividade onde você deseja alta fidelidade sem comprometer o desempenho. Isso significa que a inferência simples não requer um servidor poderoso, algo que só percebi depois de construir uma estação de trabalho de hospedagem LLM com Raspberry Pi.
Executei modelos simples de conversão de texto em fala e de fala em texto em máquinas virtuais simples, sem nenhuma regra de taxa de transferência de GPU, e obtive alguns resultados muito interessantes. Então, um pensamento levou a outro e decidi criar um fluxo de trabalho de assistente de voz totalmente local, alimentado por ninguém menos que meu Raspberry Pi 5.
Decidi usar llama.cpp para o LLM central que alimenta meu assistente de voz
Tive que me contentar com Qwen3.5-2B para obter o melhor desempenho
Dadas as especificações ruins do Raspberry Pi SBC baseado em ARM, eu queria manter o desempenho o mais baixo possível. Então optei pela versão Lite do Raspberry Pi OS, que remove os elementos GUI e pacotes não essenciais pelos quais esta distro é conhecida, sem causar possíveis problemas de compatibilidade, como algumas versões leves do Linux (tosse alpina). Ollama teria sido minha primeira escolha, mas como introduz uma penalidade adicional de desempenho, decidi compilar manualmente o llama.cpp para SBC.
Para ser honesto, fiquei tentado a confiar na funcionalidade RPC do servidor lhama para adicionar outro SBC ao meu Raspberry Pi para criar um cluster para minhas tarefas de hospedagem LLM. Tendo trabalhado anteriormente nesta maldita configuração, desisti quando percebi que a conexão lenta da LAN nesses SBCs acabaria reduzindo a velocidade de inferência. Mas isso significava que eu não seria capaz de carregar nada maior que o modelo 5B (ou no máximo 6B) no meu Raspberry Pi 5 (8GB).
Minha primeira escolha foi o Gemma 4 E4B, o mesmo modelo que salvou meu Pi no projeto Raspberry Pi. Infelizmente, mesmo que eu pudesse usar esse LLM de borda incrivelmente capaz em um Raspberry Pi, sua taxa de geração de token está na faixa de 2-3t/s, o que é muito lento para um assistente de voz. Optei pelo Qwen3.5-2B porque é muito mais rápido que o Gemma 4 E4B, mas não alucina tanto quanto os modelos 2B normais. Mas um pouco mais sobre isso…
Speeches fornece os modelos STT e TTS para este projeto
Também foi muito fácil de implantar
Se eu quisesse adicionar controle de voz à minha instância Qwen3.5-2B executando um servidor lhama, precisaria de mais dois modelos de IA. O primeiro é o modelo de fala para texto, que traduz tudo o que digo em texto Qwen3.5 porque o clanker não consegue interpretar comandos de voz diretamente. Eu precisaria então de um modelo de conversão de texto em fala no final do segundo pipeline do assistente de voz, pois isso converteria todo o texto gerado pelo LLM em respostas baseadas em áudio.
Como pretendo usar o Open WebUI como centro de controle para este assistente de voz, precisava que meus modelos STT e TTS fossem compatíveis com a API OpenAI. Então pensei que poderia usar o Speaches como servidor para esses modelos de processamento de áudio, já que é o mesmo aplicativo que adicionei à minha instância do Open Notebook para gerar podcasts a partir de notas. De qualquer forma, quando implantei o Speaches, peguei o fast-distil-whisper-small.en como modelo de conversão de fala, e o bom Kokoro-82M-v1.0-ONNX serviu como contraparte do TTS. Mas ainda tive que configurar a última peça que faltava para meu assistente de IA.
Open WebUI fornece uma interface para meu pipeline de assistente de voz
Está conectado a todos os modelos que implantei até agora
O Lama-server e o Speaches não conseguem se comunicar, então eu precisava de outro utilitário que os conectasse. Open WebUI, o canivete suíço dos aplicativos LLM nativos, é usado aqui, pois não apenas possui uma entrada de microfone, mas também oferece suporte à reprodução automática de áudio assim que o LLM terminar de inferir.
Emparelhar o Open WebUI com o llama-server foi tão simples quanto adicionar o último endereço IP (e número da porta) como o modelo OpenAPI local na guia Conexões das configurações de administrador. Falando em discursos, tive que acrescentar /v1 após o URL para os modelos TTS e STT na seção Áudio. Mas mesmo assim, ainda não consegui usar meu pipeline Open WebUI sem HTTPS porque meu navegador bloqueia o acesso de páginas HTTP ao microfone. Como não queria perder tempo gerando certificados autoassinados, ativei temporariamente permitir-localhost inseguro flag e reiniciou o Brave.
É claro que consegui conceder ao microfone acesso à interface Open WebUI. Depois que todos os modelos foram conectados ao Open WebUI, comecei a preencher meus servidores de IA com Raspberry Pi com coisas aleatórias. Em meus testes, fast-distil-whisper-small.en geralmente leva de 10 a 15 segundos para converter meus comandos de voz em texto, enquanto Qwen3.5-2B leva de 15 a 45 segundos para gerar uma resposta. Combine isso com os 10 segundos extras exigidos pelo Kokoro-82M-v1.0-ONNX e solicitações simples serão respondidas em um minuto.
Embora eu não vá tão longe a ponto de dizer que esta configuração pode substituir o pipeline GPT-OSS-20B em execução no meu RTX 3080 Ti (usando descarregamento MoE), é bastante impressionante que o Raspberry Pi possa produzir respostas perfeitas aos comandos de voz sem me fazer esperar 2-3 minutos. Tecnicamente, posso reduzir o tempo total de processamento pela metade se mudar para os modelos 0,7B e 1,5B, mas não tive sorte com nada além de Qwen3.5 1,5B e LFM2 1,2B. E mesmo assim, esses clankers não seriam capazes de lidar com solicitações exigentes com a mesma precisão da minha configuração atual.
