Come JBlanked connette Flipper Zero, Cardputer e PicoCalc all’IA locale con ZimaBoard 2

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

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

Grazie a JBlanked per aver documentato un modo diverso di portare l'IA locale nello sviluppo di dispositivi embedded. Nel suo video completo, trasforma ZimaBoard 2 in un server Ollama locale e collega dispositivi portatili, tra cui Cardputer-ADV, PicoCalc e Flipper Zero, a quell'ambiente di IA condiviso.

Invece di cercare di eseguire direttamente un modello linguistico di grandi dimensioni su ogni dispositivo compatto, l'esperimento separa il carico di lavoro: ZimaBoard 2 gestisce il servizio di IA locale, mentre i dispositivi portatili fungono da interfacce di sviluppo leggere. JBlanked utilizza quindi il suo Agent open source Picoware per creare applicazioni, esaminare le informazioni sui dispositivi e gestire l'hardware tramite questa connessione di IA locale.

Informativa sulla collaborazione: questo articolo si basa sulla configurazione mostrata da JBlanked e sulla documentazione pubblica di Picoware e FlipperHTTP. Le versioni del software, la disponibilità dei modelli di IA, la compatibilità hardware e le prestazioni dell'inferenza locale possono cambiare nel tempo.

Il risultato: un solo server domestico compatto può fornire il livello di IA a diversi dispositivi maker con risorse limitate. L'hardware portatile continua a eseguire il proprio firmware e la propria interfaccia, mentre le attività più impegnative legate ai modelli linguistici possono essere gestite da Ollama sul server locale.

La configurazione di IA locale in sintesi

Il progetto combina un server x86 compatto con diverse piattaforme embedded. Invece di imporre lo stesso stack software a ogni dispositivo, JBlanked utilizza diversi livelli di connessione in base a ciò che ciascun dispositivo supporta.

Componente	Ruolo nella configurazione	Considerazione chiave
ZimaBoard 2	Funziona come server locale centrale, esegue ZimaOS e ospita l'ambiente di IA.	Le prestazioni del modello dipendono dalla configurazione hardware completa, non solo dalla CPU della scheda.
ZimaOS	Fornisce l'ambiente server e l'App Store utilizzati per distribuire Ollama.	Prima di utilizzare il server con progetti sensibili, è necessario verificare la configurazione dell'applicazione e l'accesso alla rete.
Ollama	Esegue il modello linguistico localmente e risponde alle richieste dei dispositivi connessi.	Modelli diversi hanno requisiti diversi in termini di memoria, archiviazione e acceleratori.
NVIDIA GeForce RTX 3060	Compare nell'ambiente ZimaOS mostrato, come GPU disponibile con 12 GB di VRAM.	La GPU mostrata nel video fa parte della configurazione dimostrata e deve essere considerata nella valutazione dei risultati dell’inferenza.
Cardputer-ADV	Esegue Picoware e utilizza l’interfaccia Agent per comunicare con il server IA locale.	Il dispositivo portatile rimane l’interfaccia; il modello linguistico viene eseguito sul server.
PicoCalc	Utilizza Picoware come ulteriore client per lo stesso flusso di lavoro IA locale.	Le funzionalità disponibili dipendono dalla build Picoware attuale e dalla configurazione del dispositivo.
Flipper Zero	Utilizza un percorso di richieste di rete per comunicare con il servizio IA locale.	È necessario un bridge o una scheda di sviluppo compatibile con Wi-Fi per la comunicazione di rete.

Perché usare ZimaBoard 2 come server IA?

L’aspetto interessante di questo progetto non è semplicemente che ZimaBoard 2 possa eseguire un’applicazione IA. È il modo in cui la scheda modifica l’architettura dei piccoli progetti embedded.

Dispositivi come Cardputer, PicoCalc e Flipper Zero sono progettati per la portabilità e per l’uso di hardware embedded specializzato. Sono utili per interfacce, script, esperimenti con il firmware, strumenti di rete e applicazioni portatili, ma le risorse integrate sono molto più limitate rispetto a quelle di una workstation IA tradizionale.

ZimaBoard 2 Mini Home Server offre un host x86 separato con rete cablata, connettività per l’archiviazione ed espansione PCIe. In questo modo è possibile mantenere piccoli i dispositivi portatili, spostando altrove il carico di lavoro più impegnativo del server.

Nel flusso di lavoro di JBlanked, ZimaBoard 2 esegue ZimaOS e Ollama fornisce il servizio locale di modelli linguistici. Una volta che il servizio è disponibile sulla rete locale, i dispositivi compatibili possono comunicare con esso senza che ciascun dispositivo portatile disponga di potenza di calcolo e memoria sufficienti per ospitare autonomamente il modello.

Il video mostra anche un dettaglio importante sulla configurazione del server dimostrata: mentre Ollama è in esecuzione, la dashboard di sistema di ZimaOS indica una NVIDIA GeForce RTX 3060 con 12 GB di VRAM. Ciò significa che le prestazioni mostrate nella demo devono essere valutate nel contesto di un server locale dotato di GPU, non come un test di ZimaBoard 2 basato esclusivamente sulla CPU.

Ollama in esecuzione in ZimaOS, con NVIDIA GeForce RTX 3060 e 12 GB di VRAM visibili nella dashboard di sistema

Ollama in esecuzione nell’ambiente ZimaOS. La dashboard di sistema visibile sullo sfondo indica una NVIDIA GeForce RTX 3060 e 12 GB di VRAM, mostrando che il server IA locale dimostrato dispone dell’accelerazione GPU.

Come funziona la connessione all’IA locale

Il design di base può essere compreso come una struttura a tre livelli:

Livello del server: ZimaBoard 2 esegue ZimaOS e ospita Ollama.
Livello dell’agente o di rete: Picoware o lo stack di rete di Flipper invia richieste tra il dispositivo integrato e il server locale.
Livello del dispositivo: Cardputer-ADV, PicoCalc o Flipper Zero fornisce l’interfaccia fisica ed esegue azioni specifiche del dispositivo.

Questa separazione è utile perché il modello linguistico non deve essere eseguito direttamente su ogni componente hardware. Il firmware di ciascun dispositivo può esporre le funzioni supportate, mentre il server fornisce la capacità del modello utilizzata per interpretare le richieste o assistere nelle attività di sviluppo.

Cardputer-ADV e PicoCalc utilizzano Picoware Agent

Il progetto open source Picoware di JBlanked è un ambiente firmware che supporta Cardputer-ADV, PicoCalc, Flipper Zero e altri dispositivi basati su ESP32 o Raspberry Pi Pico.

Per questo esperimento, il componente importante è Picoware Agent. Agent fornisce un’interfaccia basata su un LLM con diversi contesti operativi, invece di fungere soltanto da finestra di chat generica.

Le modalità documentate includono la chat generica, un Creatore di app progettato per creare o modificare applicazioni Picoware e funzioni di gestione del dispositivo in grado di utilizzare informazioni e comandi. Collegare queste funzionalità all’istanza di Ollama sul server locale offre al dispositivo portatile un flusso di sviluppo assistito dall’IA, mantenendo il carico di lavoro del modello lontano dal piccolo dispositivo.

Flipper Zero invia richieste al server di IA locale

Flipper Zero segue un modello di interazione diverso. Nel video, JBlanked mostra il dispositivo mentre prepara un payload di richiesta strutturato per il modello locale tramite una scheda di sviluppo dotata di Wi-Fi collegata a Flipper.

Il payload mostrato sullo schermo include un campo per il modello qwen3.5:9b. Questo illustra chiaramente la suddivisione delle responsabilità: Flipper prepara e invia la richiesta, mentre il modello linguistico selezionato viene eseguito sul server locale più potente.

Flipper Zero inserisce il payload di una richiesta di IA locale per il modello qwen3.5:9b, con una scheda di sviluppo Wi-Fi collegata

Flipper Zero prepara il payload di una richiesta per il servizio di IA locale. Sullo schermo, il campo del modello è impostato su qwen3.5:9b, mentre una scheda di sviluppo dotata di Wi-Fi è collegata sopra il dispositivo.

Questa distinzione è importante. Flipper non esegue localmente il modello linguistico completo. Il suo ruolo è fornire l’interfaccia portatile e il percorso di rete, mentre Ollama e il modello selezionato vengono eseguiti sul server.

Cosa può fare concretamente l’Agente IA locale?

Collegare un dispositivo portatile a un LLM diventa più interessante quando il modello può fare più che rispondere a una domanda. JBlanked dimostra l’uso del server IA all’interno di un flusso di lavoro per lo sviluppo embedded.

Crea app Picoware

Picoware include un contesto App Creator per il suo AI Agent. Questo consente a uno sviluppatore di descrivere un’applicazione o una modifica in linguaggio naturale e di utilizzare il modello per contribuire a creare o modificare la corrispondente applicazione Picoware.

Nella dimostrazione, ad App Creator viene chiesto di creare una semplice applicazione che mostri il saluto «hello from youtube» all’avvio. L’Agente restituisce una descrizione strutturata del comportamento richiesto e del funzionamento dell’interfaccia.

PicoCalc con Picoware App Creator per un’applicazione «hello from youtube» accanto a Flipper Zero e Cardputer-ADV

App Creator di Picoware in esecuzione su PicoCalc. L’Agente sta elaborando una richiesta per un’applicazione che visualizzi «hello from youtube», mentre Flipper Zero e Cardputer-ADV sono accanto al dispositivo.

Questo può accorciare la distanza tra un’idea e un prototipo, soprattutto su un dispositivo in cui digitare e modificare direttamente grandi quantità di codice sorgente sul piccolo schermo sarebbe altrimenti macchinoso.

Il codice generato dall’IA deve comunque essere verificato. Un output dall’aspetto plausibile può contenere API errate, una gestione incompleta degli errori, ipotesi non sicure o comportamenti che non corrispondono all’hardware di destinazione.

Ispeziona il firmware e le informazioni sullo sviluppo

Il flusso di lavoro dell’Agente può essere utilizzato anche come assistente allo sviluppo. Invece di trattare il dispositivo portatile come un normale client di chat, il sistema può combinare le risposte del modello locale con le informazioni rese disponibili dal dispositivo e dal suo firmware.

Questo approccio è particolarmente utile sugli schermi piccoli, dove consultare manualmente log, documentazione o output dei comandi può essere più lento che chiedere all’Agente di interpretare una richiesta specifica.

Gestisci il dispositivo

Il framework Agent di Picoware include anche funzioni di gestione del dispositivo. Il modello può utilizzare gli strumenti messi a disposizione dal firmware, invece di limitarsi a restituire testo che l’utente dovrebbe eseguire manualmente.

In un esempio del video viene chiesto: «quante reti ci sono nelle vicinanze?». Il Gestore dispositivi risponde che sono disponibili sei reti Wi-Fi vicine, dimostrando che l’Agente può utilizzare informazioni a livello del dispositivo per rispondere a una richiesta pratica, invece di basarsi solo sulle conoscenze generali del modello.

Gestore dispositivi PicoCalc Picoware che segnala sei reti Wi-Fi vicine accanto a Flipper Zero e Cardputer-ADV

Picoware Device Manager su PicoCalc risponde alla domanda «quante reti ci sono nelle vicinanze?». L'interfaccia rileva sei reti Wi-Fi vicine, mostrando come l'agente possa combinare l'IA locale con le informazioni ottenute dal dispositivo.

È qui che un agente di IA si differenzia da un normale chatbot. Il modello linguistico fornisce il livello di interpretazione e istruzioni, mentre il firmware determina quali operazioni sul dispositivo e quali fonti di informazioni siano effettivamente disponibili.

Perché un server di IA locale condiviso è utile per i dispositivi di piccole dimensioni

L'architettura affronta un'incompatibilità di base nei progetti di IA embedded: i dispositivi più portatili spesso dispongono della minore potenza di calcolo per i modelli linguistici.

L'utilizzo di un server condiviso modifica questo compromesso. Uno sviluppatore può mantenere l'interfaccia fisica in un dispositivo tascabile, fornendogli al contempo accesso a una macchina locale più potente tramite la rete.

Eseguire l'IA direttamente sul dispositivo portatile	Utilizzare ZimaBoard 2 come server di IA
La potenza di calcolo è limitata al processore embedded.	L'elaborazione dell'IA viene spostata su un server x86 dedicato e sull'hardware acceleratore disponibile.
Le dimensioni del modello sono fortemente limitate dalla memoria del dispositivo.	Il server può utilizzare la propria memoria di sistema, la VRAM della GPU e lo spazio di archiviazione per i file del modello.
Ogni dispositivo necessita di una propria implementazione dell'IA.	Più client possono condividere un unico servizio di inferenza locale.
L'aggiornamento del modello può richiedere modifiche su ogni dispositivo.	Il modello può essere gestito centralmente sul server.
Il dispositivo portatile deve gestire sia i carichi di lavoro dell'interfaccia sia quelli dell'inferenza.	Il dispositivo portatile può concentrarsi su interfaccia, firmware, rete e funzioni specifiche del dispositivo.

Un backend di IA, più dispositivi maker

Una delle idee più utili dell'esperimento di JBlanked è che ZimaBoard 2 non è legato a un'unica interfaccia front-end. PicoCalc e Cardputer-ADV possono partecipare tramite Picoware, mentre Flipper Zero può comunicare con lo stesso ambiente di IA locale attraverso il proprio flusso di lavoro di rete.

Questo rende il server un componente riutilizzabile di un maker lab più ampio. Invece di ricreare un ambiente di IA per ogni nuovo microcontrollore o computer portatile, gli sviluppatori possono mantenere centralizzato il servizio di inferenza e concentrarsi sulla realizzazione dell'integrazione client più adatta a ciascun dispositivo.

Il concetto può anche semplificare la sperimentazione. Un modello può essere modificato sul server senza sostituire il dispositivo portatile, mentre il firmware del dispositivo portatile può evolversi indipendentemente dal runtime dell'IA.

Cosa dimostra questo esperimento e cosa non dimostra

Il progetto di JBlanked è un'utile dimostrazione di come l'IA locale possa integrarsi nello sviluppo embedded, ma è importante distinguere l'architettura dalle garanzie in termini di prestazioni o sicurezza.

L'esperimento dimostra	Non garantisce
ZimaBoard 2 può fungere da host Ollama locale per client basati su dispositivi embedded.	Le stesse prestazioni saranno ottenute senza la GPU mostrata nell’ambiente dimostrato.
L’ambiente demo di ZimaOS riconosce una NVIDIA GeForce RTX 3060 con 12 GB di VRAM.	Ogni modello entrerà in 12 GB di VRAM o funzionerà alla stessa velocità.
PicoCalc e Cardputer-ADV possono utilizzare Picoware come parte di un flusso di lavoro IA locale.	Ogni funzionalità o modello Picoware funzionerà allo stesso modo su tutti i dispositivi supportati.
Flipper Zero può inviare richieste strutturate al server IA locale tramite una configurazione dotata di connettività di rete.	È lo stesso Flipper Zero a eseguire il modello linguistico.
Un agente IA può assistere nella creazione di app e nei flussi di lavoro per la gestione dei dispositivi.	Il codice, le interpretazioni o i comandi generati dall’IA sono automaticamente corretti o sicuri.
Un singolo server locale può supportare più interfacce per dispositivi di piccole dimensioni.	Una rete locale non fornisce automaticamente autenticazione, isolamento o privacy completa.

Locale non significa configurazione zero

Eseguire Ollama localmente elimina la necessità di inviare ogni richiesta di inferenza a un servizio di chatbot ospitato, ma l’intero sistema richiede comunque la normale pianificazione del server e della rete.

È necessario installare il modello iniziale e i pacchetti dell’applicazione; i dispositivi portatili devono poter accedere al server tramite rete e ogni servizio esposto deve essere configurato tenendo conto dei confini di rete previsti. Prima di abilitare le funzionalità di gestione dei dispositivi, gli sviluppatori dovrebbero inoltre verificare esattamente quali strumenti l’agente IA è autorizzato a utilizzare.

Anche la configurazione dell’acceleratore è importante. La RTX 3060 visibile nella dashboard ZimaOS di JBlanked dispone di 12 GB di VRAM, quindi la scelta del modello deve comunque tenere conto della memoria GPU disponibile, del supporto del runtime e dei requisiti prestazionali del carico di lavoro previsto.

Per i casi d’uso di generazione del codice, è particolarmente importante mantenere backup o il controllo versione. Se una modifica assistita dall’IA produce un’applicazione o una configurazione firmware inutilizzabile, lo sviluppatore deve poter tornare a uno stato funzionante noto.

Chi dovrebbe prendere in considerazione una configurazione di questo tipo?

Questa architettura è particolarmente interessante per gli sviluppatori e i maker che lavorano già con dispositivi embedded, ma vogliono sperimentare con LLM locali senza trasformare ogni progetto in un’integrazione con un’API cloud.

Può essere utile per:

Sviluppatori di Cardputer e PicoCalc che creano applicazioni Picoware.
Utenti di Flipper Zero che sperimentano strumenti connessi alla rete.
Sviluppatori embedded che desiderano l’assistenza dell’IA vicino al loro hardware di test.
Utenti di homelab alla ricerca di un altro carico di lavoro pratico per un server locale.
Maker che vogliono condividere un unico backend di IA tra più dispositivi a basso consumo.

Un servizio di IA cloud può essere comunque più semplice per gli utenti che hanno bisogno solo occasionalmente di chat o generazione di codice e non vogliono gestire un server. Una workstation più grande o un sistema più potente dotato di GPU può inoltre essere più appropriato quando le dimensioni del modello e la velocità di inferenza sono le priorità principali.

L'approccio di ZimaBoard 2 diventa ancora più interessante quando l'obiettivo è mantenere il servizio di IA nello stesso homelab e renderlo disponibile a diversi progetti indipendenti.

Crea un hub di IA locale per il tuo laboratorio maker

Il progetto di JBlanked mostra una direzione utile per l'IA locale: invece di chiedersi se ogni piccolo dispositivo sia in grado di eseguire un modello linguistico, bisogna chiedersi se tali dispositivi possano utilizzare un modello condiviso eseguito in un ambiente più adatto a questo compito.

Con ZimaOS che ospita Ollama su ZimaBoard 2, Picoware che fornisce un'interfaccia assistita dall'IA per dispositivi come PicoCalc e Cardputer-ADV e un flusso di lavoro con funzionalità di rete che integra Flipper Zero nello stesso ambiente, il sistema diventa un hub flessibile di IA locale per la sperimentazione con dispositivi embedded.

Le quattro dimostrazioni mostrano anche perché il server dovrebbe essere valutato come un sistema completo. I dispositivi portatili forniscono le interfacce e le funzioni specifiche dell'hardware, Ollama fornisce il livello di gestione dei modelli e la GPU visibile in ZimaOS mette a disposizione risorse di calcolo aggiuntive per il carico di lavoro di IA locale.

Per vedere un altro esempio di ciò che i modelli locali possono fare sulla stessa piattaforma, consulta il test dell'assistente IA locale su ZimaBoard 2, che analizza il rapporto tra hardware server compatto, dimensioni del modello, spazio di archiviazione e carichi di lavoro IA.

Guarda il video completo di JBlanked per vedere direttamente la configurazione e il flusso di lavoro del dispositivo, oppure esplora il progetto Picoware su GitHub se vuoi capire come si integrano l'agente e i dispositivi supportati.

Vuoi vedere cosa stanno facendo altri maker con server compatti, IA locale e hardware insolito? Unisciti alla community Discord di ZimaSpace per scoprire altri progetti, confrontare le configurazioni e condividere i tuoi esperimenti.