Como a JBlanked liga o Flipper Zero, o Cardputer e o PicoCalc à IA local com o ZimaBoard 2

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How JBlanked Connects Flipper Zero, Cardputer, and PicoCalc to Local AI with ZimaBoard 2 - Zima Store Online

Obrigado ao JBlanked por documentar uma forma diferente de trazer a IA local para o desenvolvimento de dispositivos incorporados. No seu vídeo completo, transforma o ZimaBoard 2 num servidor Ollama local e liga dispositivos portáteis, incluindo o Cardputer-ADV, o PicoCalc e o Flipper Zero, a esse ambiente de IA partilhado.

Em vez de tentar executar um modelo de linguagem de grandes dimensões diretamente em cada dispositivo pequeno, a experiência separa a carga de trabalho: o ZimaBoard 2 gere o serviço de IA local, enquanto os dispositivos portáteis funcionam como interfaces de desenvolvimento leves. O JBlanked utiliza então o seu Picoware Agent de código aberto para criar aplicações, consultar informações dos dispositivos e gerir o hardware através dessa ligação de IA local.

Divulgação sobre a colaboração: este artigo baseia-se na configuração demonstrada pelo JBlanked e na documentação pública do Picoware e do FlipperHTTP. As versões do software, a disponibilidade dos modelos de IA, a compatibilidade do hardware e o desempenho da inferência local podem mudar ao longo do tempo.

O resultado: um único servidor doméstico compacto pode fornecer a camada de IA a vários dispositivos maker com recursos limitados. O hardware portátil continua a executar o seu próprio firmware e interface, enquanto as tarefas de modelos de linguagem computacionalmente mais exigentes podem ser tratadas pelo Ollama no servidor local.

A configuração de IA local num relance

O projeto combina um servidor x86 compacto com várias plataformas incorporadas. Em vez de impor a mesma pilha de software a todos os dispositivos, o JBlanked utiliza diferentes camadas de ligação, consoante o que cada dispositivo suporta.

Componente	Função na configuração	Consideração principal
ZimaBoard 2	Funciona como o servidor local central que executa o ZimaOS e aloja o ambiente de IA.	O desempenho do modelo depende da configuração completa do hardware, não apenas do CPU da placa.
ZimaOS	Fornece o ambiente do servidor e a App Store utilizados para implementar o Ollama.	A configuração da aplicação e o acesso à rede devem ser revistos antes de utilizar o servidor com projetos sensíveis.
Ollama	Executa o modelo de linguagem localmente e responde a pedidos de dispositivos ligados.	Modelos diferentes têm requisitos diferentes de memória, armazenamento e aceleradores.
NVIDIA GeForce RTX 3060	É apresentado no ambiente ZimaOS demonstrado como uma GPU disponível com 12 GB de VRAM.	A GPU apresentada no vídeo faz parte da configuração demonstrada e deve ser tida em consideração ao avaliar os resultados da inferência.
Cardputer-ADV	Executa o Picoware e utiliza a interface Agent para comunicar com o servidor de IA local.	O dispositivo portátil continua a ser a interface; o próprio modelo de linguagem é executado no servidor.
PicoCalc	Utiliza o Picoware como outro cliente para o mesmo fluxo de trabalho de IA local.	As funcionalidades disponíveis dependem da versão atual do Picoware e da configuração do dispositivo.
Flipper Zero	Utiliza um caminho de pedidos de rede para comunicar com o serviço de IA local.	É necessária uma ponte compatível com Wi-Fi ou uma placa de desenvolvimento para a comunicação de rede.

Porquê utilizar o ZimaBoard 2 como servidor de IA?

O aspeto interessante deste projeto não é simplesmente o facto de o ZimaBoard 2 conseguir executar uma aplicação de IA. É a forma como a placa altera a arquitetura de pequenos projetos incorporados.

Dispositivos como o Cardputer, o PicoCalc e o Flipper Zero foram concebidos para a portabilidade e para hardware incorporado especializado. São úteis para interfaces, scripts, experiências com firmware, ferramentas de rede e aplicações portáteis, mas os seus recursos integrados são muito mais limitados do que os de uma estação de trabalho de IA convencional.

O Mini servidor doméstico ZimaBoard 2 disponibiliza um anfitrião x86 separado, com ligação de rede com fios, conectividade para armazenamento e expansão PCIe. Isto permite manter os dispositivos portáteis pequenos, transferindo a carga de trabalho mais pesada do servidor para outro local.

No fluxo de trabalho da JBlanked, o ZimaBoard 2 executa o ZimaOS e o Ollama disponibiliza o serviço de modelos de linguagem local. Assim que esse serviço fica disponível na rede local, os dispositivos compatíveis podem comunicar com ele sem que cada dispositivo portátil precise de capacidade de processamento e memória suficientes para alojar o próprio modelo.

O vídeo também mostra um pormenor importante sobre a configuração do servidor apresentada: enquanto o Ollama está em execução, o painel de controlo do sistema ZimaOS indica uma NVIDIA GeForce RTX 3060 com 12 GB de VRAM. Isto significa que o desempenho mostrado na demonstração deve ser entendido no contexto de um servidor local equipado com GPU, e não como um teste do ZimaBoard 2 apenas com CPU.

Ollama a ser executado no ZimaOS, com uma NVIDIA GeForce RTX 3060 e 12 GB de VRAM visíveis no painel de controlo do sistema

Ollama a ser executado no ambiente ZimaOS. O painel de controlo do sistema, visível por trás, indica uma NVIDIA GeForce RTX 3060 e 12 GB de VRAM, mostrando que o servidor de IA local apresentado dispõe de aceleração por GPU.

Como funciona a ligação à IA local

O design básico pode ser compreendido como tendo três camadas:

Camada do servidor: O ZimaBoard 2 executa o ZimaOS e aloja o Ollama.
Camada do agente ou da rede: O Picoware ou a pilha de rede do Flipper envia pedidos entre o dispositivo integrado e o servidor local.
Camada do dispositivo: Cardputer-ADV, PicoCalc ou Flipper Zero fornece a interface física e executa ações específicas do dispositivo.

Esta separação é útil porque o modelo de linguagem não precisa de ser executado diretamente em cada componente de hardware. O firmware de cada dispositivo pode disponibilizar as funções que suporta, enquanto o servidor fornece a capacidade de modelo utilizada para interpretar pedidos ou auxiliar em tarefas de desenvolvimento.

Cardputer-ADV e PicoCalc utilizam o Picoware Agent

O projeto Picoware de JBlanked é um ambiente de firmware de código aberto compatível com Cardputer-ADV, PicoCalc, Flipper Zero e outros dispositivos baseados em ESP32 ou Raspberry Pi Pico.

Para esta experiência, o componente importante é o Picoware Agent. O Agent fornece uma interface baseada num LLM com diferentes contextos de funcionamento, em vez de funcionar apenas como uma janela de conversação genérica.

Os modos documentados incluem conversação geral, um Criador de aplicações concebido para criar ou editar aplicações Picoware e funções de gestão do dispositivo que podem trabalhar com informações e comandos. Ligar estas capacidades à instância do Ollama no servidor local proporciona ao dispositivo portátil um fluxo de trabalho de desenvolvimento assistido por IA, mantendo a carga de trabalho do modelo afastada do pequeno dispositivo.

O Flipper Zero envia pedidos para o servidor de IA local

O Flipper Zero segue um padrão de interação diferente. No vídeo, JBlanked demonstra como o dispositivo prepara um payload de pedido estruturado para o modelo local através de uma placa de desenvolvimento com Wi-Fi instalada no Flipper.

O payload apresentado no ecrã inclui um campo de modelo para qwen3.5:9b. Isto ilustra claramente a divisão de responsabilidades: o Flipper prepara e envia o pedido, enquanto o modelo de linguagem selecionado é executado no servidor local, mais potente.

O Flipper Zero introduz um payload de pedido de IA local para o modelo qwen3.5:9b, com uma placa de desenvolvimento com Wi-Fi instalada

O Flipper Zero prepara um payload de pedido para o serviço de IA local. O ecrã mostra o campo do modelo definido como qwen3.5:9b, enquanto uma placa de desenvolvimento com Wi-Fi está instalada na parte superior do dispositivo.

Esta distinção é importante. O Flipper não executa localmente o modelo de linguagem completo. O seu papel é fornecer a interface portátil e a ligação de rede, enquanto o Ollama e o modelo selecionado são executados no servidor.

O que consegue realmente fazer o Agent de IA local?

Ligar um dispositivo portátil a um LLM torna-se mais interessante quando o modelo consegue fazer mais do que responder a uma pergunta. A JBlanked demonstra o servidor de IA como parte de um fluxo de trabalho de desenvolvimento integrado.

Criar aplicações Picoware

O Picoware inclui um contexto App Creator para o seu Agent de IA. Isto permite a um programador descrever uma aplicação ou alteração em linguagem natural e utilizar o modelo para ajudar a produzir ou editar a aplicação Picoware correspondente.

Na demonstração, é pedido ao App Creator que crie uma aplicação simples que apresente a saudação «hello from youtube» quando for iniciada. O Agent devolve uma descrição estruturada do comportamento pedido e do funcionamento esperado da interface.

PicoCalc a executar o App Creator do Picoware para uma aplicação com a mensagem hello from youtube, junto do Flipper Zero e do Cardputer-ADV

App Creator do Picoware a ser executado no PicoCalc. O Agent está a processar um pedido para uma aplicação que apresenta «hello from youtube», enquanto o Flipper Zero e o Cardputer-ADV estão junto do dispositivo.

Isso pode encurtar a distância entre uma ideia e um protótipo, especialmente num dispositivo em que escrever e editar diretamente grandes quantidades de código-fonte no ecrã pequeno seria, de outro modo, pouco prático.

O código gerado por IA continua a precisar de revisão. Um resultado que parece plausível pode conter APIs incorretas, tratamento de erros incompleto, pressupostos inseguros ou um comportamento que não corresponde ao hardware-alvo.

Inspecionar o firmware e as informações de desenvolvimento

O fluxo de trabalho do Agent também pode ser utilizado como assistente de desenvolvimento. Em vez de tratar o dispositivo portátil como um cliente de conversação convencional, o sistema pode combinar respostas de um modelo local com informações disponibilizadas pelo dispositivo e pelo seu firmware.

Esta abordagem é particularmente útil em ecrãs pequenos, onde navegar manualmente por registos, documentação ou resultados de comandos pode ser mais lento do que pedir ao Agent para interpretar um pedido específico.

Gerir o dispositivo

A estrutura Agent do Picoware também inclui funções de gestão do dispositivo. O modelo pode utilizar as ferramentas disponibilizadas pelo firmware, em vez de se limitar a devolver texto para o utilizador executar manualmente.

Num exemplo do vídeo, é perguntado: «quantas redes estão próximas?». O Gestor de Dispositivos responde que estão disponíveis seis redes Wi-Fi próximas, demonstrando que o Agent pode utilizar informações ao nível do dispositivo para responder a um pedido prático, em vez de depender apenas do conhecimento geral do modelo.

Gestor de Dispositivos Picoware do PicoCalc a apresentar seis redes Wi-Fi próximas, junto do Flipper Zero e do Cardputer-ADV

O Gestor de Dispositivos Picoware no PicoCalc responde à pergunta “quantas redes estão próximas”. A interface apresenta seis redes Wi-Fi próximas, mostrando como o Agente pode combinar a IA local com informações obtidas a partir do dispositivo.

É aqui que um agente de IA se distingue de um chatbot normal. O modelo de linguagem fornece a camada de interpretação e instruções, enquanto o firmware determina quais as operações do dispositivo e as fontes de informação que estão efetivamente disponíveis.

Porque é útil um servidor de IA local partilhado para dispositivos pequenos

Esta arquitetura resolve uma incompatibilidade básica dos projetos de IA embebida: os dispositivos mais portáteis têm frequentemente menos capacidade de computação disponível para modelos de linguagem.

A utilização de um servidor partilhado altera esse compromisso. Um programador pode manter a interface física num dispositivo de bolso, dando-lhe simultaneamente acesso a uma máquina local mais potente através da rede.

Executar IA diretamente no dispositivo portátil	Utilizar o ZimaBoard 2 como servidor de IA
O poder de computação está limitado ao processador embebido.	O processamento de IA é transferido para um servidor x86 dedicado e para o hardware acelerador disponível.
O tamanho do modelo é fortemente limitado pela memória do dispositivo.	O servidor pode utilizar a sua própria memória do sistema, VRAM da GPU e armazenamento para os ficheiros do modelo.
Cada dispositivo precisa da sua própria implementação de IA.	Vários clientes podem partilhar um único serviço de inferência local.
A atualização do modelo pode exigir alterações em todos os dispositivos.	O modelo pode ser gerido centralmente no servidor.
O dispositivo portátil tem de gerir tanto as tarefas da interface como as de inferência.	O dispositivo portátil pode concentrar-se na interface, no firmware, na rede e nas funções específicas do dispositivo.

Um Backend de IA, Vários Dispositivos Maker

Uma das ideias mais úteis da experiência da JBlanked é que o ZimaBoard 2 não está associado a uma única interface. O PicoCalc e o Cardputer-ADV podem participar através do Picoware, enquanto o Flipper Zero pode comunicar com o mesmo ambiente de IA local através do seu próprio fluxo de trabalho de rede.

Isto transforma o servidor numa peça reutilizável de um laboratório maker mais amplo. Em vez de recriarem um ambiente de IA para cada novo microcontrolador ou computador portátil, os programadores podem manter o serviço de inferência centralizado e concentrar-se na criação da integração do cliente mais adequada a cada dispositivo.

O conceito também pode simplificar a experimentação. Um modelo pode ser alterado no servidor sem substituir o dispositivo portátil, enquanto o firmware do dispositivo portátil pode evoluir de forma independente do ambiente de execução da IA.

O que esta experiência prova — e o que não prova

A construção da JBlanked é uma demonstração útil de como a IA local pode ser integrada no desenvolvimento de sistemas embebidos, mas é importante distinguir a arquitetura das garantias de desempenho ou segurança.

A Experiência Demonstra	Não Garante
O ZimaBoard 2 pode funcionar como anfitrião local do Ollama para clientes de dispositivos embebidos.	O mesmo desempenho será alcançado sem a GPU apresentada no ambiente demonstrado.
O ambiente de demonstração do ZimaOS reconhece uma NVIDIA GeForce RTX 3060 com 12 GB de VRAM.	Todos os modelos caberão em 12 GB de VRAM ou serão executados à mesma velocidade.
O PicoCalc e o Cardputer-ADV podem utilizar o Picoware como parte de um fluxo de trabalho de IA local.	Todas as funcionalidades ou modelos Picoware funcionarão de forma idêntica em todos os dispositivos compatíveis.
O Flipper Zero pode enviar pedidos estruturados para o servidor de IA local através de uma configuração com capacidade de rede.	O próprio Flipper Zero está a executar o modelo de linguagem.
Um agente de IA pode ajudar na criação de aplicações e nos fluxos de trabalho de gestão de dispositivos.	O código, as interpretações ou os comandos gerados por IA estão automaticamente corretos ou são seguros.
Um único servidor local pode suportar várias interfaces para dispositivos pequenos.	Uma rede local não fornece automaticamente autenticação, isolamento ou privacidade total.

Local Não Significa Configuração Zero

Executar o Ollama localmente elimina a necessidade de enviar cada pedido de inferência para um serviço de chatbot alojado, mas o sistema completo continua a exigir um planeamento normal do servidor e da rede.

É necessário instalar inicialmente os pacotes do modelo e da aplicação, os dispositivos portáteis precisam de acesso de rede ao servidor e qualquer serviço exposto deve ser configurado tendo em conta os limites de rede pretendidos. Os programadores devem também verificar exatamente que ferramentas um agente de IA está autorizado a chamar antes de ativarem funcionalidades de gestão de dispositivos.

A configuração do acelerador também é importante. A RTX 3060 visível no painel do ZimaOS da JBlanked tem 12 GB de VRAM, pelo que a escolha do modelo continua a ter de considerar a memória GPU disponível, o suporte do runtime e os requisitos de desempenho da carga de trabalho pretendida.

Nos casos de utilização de geração de código, é especialmente importante manter cópias de segurança ou o controlo de versões. Se uma edição assistida por IA produzir uma aplicação ou configuração de firmware inutilizável, o programador precisa de conseguir regressar a um estado de funcionamento conhecido.

Quem Deve Considerar Uma Configuração Deste Tipo?

Esta arquitetura é especialmente interessante para programadores e criadores que já trabalham com dispositivos embebidos, mas querem experimentar LLMs locais sem transformar cada projeto numa integração com uma API na cloud.

Pode ser útil para:

Programadores de Cardputer e PicoCalc que criam aplicações Picoware.
Utilizadores do Flipper Zero que experimentam ferramentas ligadas à rede.
Programadores de sistemas embebidos que querem assistência de IA próxima do seu hardware de teste.
Utilizadores de laboratórios domésticos que procuram outra carga de trabalho prática para um servidor local.
Criadores que querem que vários dispositivos de baixo consumo partilhem um backend de IA.

Um serviço de IA na cloud pode continuar a ser mais simples para utilizadores que apenas precisam ocasionalmente de conversar ou gerar código e não querem manter um servidor. Uma workstation maior ou um sistema mais potente equipado com uma GPU também pode ser mais adequado quando o tamanho do modelo e a velocidade de inferência são as principais prioridades.

A abordagem do ZimaBoard 2 torna-se ainda mais interessante quando o objetivo é manter o serviço de IA dentro do mesmo homelab e disponibilizá-lo a vários projetos independentes.

Crie um hub de IA local para o seu laboratório maker

O projeto do JBlanked mostra uma direção útil para a IA local: em vez de perguntar se todos os dispositivos pequenos conseguem executar um modelo de linguagem, pergunte se esses dispositivos podem utilizar um modelo partilhado em execução noutro local mais adequado à tarefa.

Com o ZimaOS a alojar o Ollama no ZimaBoard 2, o Picoware a fornecer uma interface assistida por IA para dispositivos como o PicoCalc e o Cardputer-ADV, e um fluxo de trabalho com capacidade de rede a integrar o Flipper Zero no mesmo ambiente, o sistema torna-se um hub flexível de IA local para experimentação com dispositivos embebidos.

As quatro demonstrações também mostram por que razão o servidor deve ser avaliado como um sistema completo. Os dispositivos portáteis fornecem as interfaces e as funções específicas do hardware, o Ollama fornece a camada de disponibilização do modelo e a GPU visível no ZimaOS disponibiliza recursos computacionais adicionais para a carga de trabalho de IA local.

Para ver outra perspetiva sobre o que os modelos locais conseguem fazer na mesma plataforma, consulte o teste do assistente de IA local no ZimaBoard 2, que explora a relação entre hardware de servidor compacto, tamanho do modelo, armazenamento e cargas de trabalho de IA.

Veja o vídeo completo do JBlanked para ver diretamente a configuração e o funcionamento do dispositivo, ou explore o projeto Picoware no GitHub se quiser compreender como o Agent e os dispositivos compatíveis se integram.

Quer ver o que outros criadores estão a fazer com servidores compactos, IA local e hardware invulgar? Junte-se à comunidade ZimaSpace no Discord para descobrir mais projetos, comparar configurações e partilhar as suas próprias experiências.