Comment JBlanked connecte Flipper Zero, Cardputer et PicoCalc à l’IA locale avec ZimaBoard 2

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

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

Merci à JBlanked d’avoir documenté une autre manière d’intégrer l’IA locale au développement d’appareils embarqués. Dans sa vidéo complète, il transforme le ZimaBoard 2 en serveur Ollama local et connecte des appareils portables, notamment Cardputer-ADV, PicoCalc et Flipper Zero, à cet environnement d’IA partagé.

Plutôt que d’essayer d’exécuter un grand modèle de langage directement sur chaque petit appareil, l’expérience sépare la charge de travail : le ZimaBoard 2 gère le service d’IA local, tandis que les appareils portables servent d’interfaces de développement légères. JBlanked utilise ensuite son agent Picoware open source pour créer des applications, consulter les informations des appareils et gérer le matériel via cette connexion d’IA locale.

Divulgation de la collaboration : cet article s’appuie sur la configuration présentée par JBlanked ainsi que sur la documentation publique de Picoware et FlipperHTTP. Les versions logicielles, la disponibilité des modèles d’IA, la compatibilité matérielle et les performances de l’inférence locale peuvent évoluer au fil du temps.

Le résultat : un seul serveur domestique compact peut fournir la couche d’IA à plusieurs appareils de création aux ressources limitées. Le matériel portable continue d’exécuter son propre firmware et sa propre interface, tandis que les tâches liées aux modèles de langage, plus exigeantes en calcul, peuvent être prises en charge par Ollama sur le serveur local.

La configuration d’IA locale en un coup d’œil

Le projet associe un serveur x86 compact à plusieurs plateformes embarquées. Plutôt que d’imposer la même pile logicielle à chaque appareil, JBlanked utilise différentes couches de connexion selon les capacités de chaque appareil.

Composant	Rôle dans la configuration	Élément clé à prendre en compte
ZimaBoard 2	Fait office de serveur local central exécutant ZimaOS et hébergeant l’environnement d’IA.	Les performances du modèle dépendent de la configuration matérielle complète, et pas uniquement du processeur de la carte.
ZimaOS	Fournit l’environnement serveur et l’App Store utilisés pour déployer Ollama.	La configuration de l’application et l’accès au réseau doivent être vérifiés avant d’utiliser le serveur pour des projets sensibles.
Ollama	Exécute le modèle de langage localement et répond aux requêtes des appareils connectés.	Les différents modèles ont des exigences différentes en matière de mémoire, de stockage et d’accélérateur.
NVIDIA GeForce RTX 3060	Apparaît dans l’environnement ZimaOS présenté comme un GPU disponible avec 12 Go de VRAM.	Le GPU montré dans la vidéo fait partie de la configuration présentée et doit être pris en compte lors de l’évaluation des résultats d’inférence.
Cardputer-ADV	Exécute Picoware et utilise l’interface Agent pour communiquer avec le serveur d’IA local.	L’appareil portable reste l’interface ; le modèle de langage s’exécute lui-même sur le serveur.
PicoCalc	Utilise Picoware comme autre client du même workflow d’IA locale.	Les fonctionnalités disponibles dépendent de la version actuelle de Picoware et de la configuration de l’appareil.
Flipper Zero	Utilise un chemin de requête réseau pour communiquer avec le service d’IA local.	Un pont ou une carte de développement compatible avec le Wi-Fi est requis pour les communications réseau.

Pourquoi utiliser le ZimaBoard 2 comme serveur d’IA ?

L’intérêt de ce projet ne réside pas simplement dans le fait que le ZimaBoard 2 peut exécuter une application d’IA. Il réside dans la manière dont la carte modifie l’architecture des petits projets embarqués.

Des appareils tels que Cardputer, PicoCalc et Flipper Zero sont conçus pour être portables et reposer sur du matériel embarqué spécialisé. Ils sont utiles pour les interfaces, les scripts, les expérimentations de firmware, les outils réseau et les applications portables, mais leurs ressources intégrées sont bien plus limitées que celles d’une station de travail d’IA classique.

Le mini-serveur domestique ZimaBoard 2 fournit un hôte x86 distinct avec une connexion réseau filaire, une connectivité de stockage et une extension PCIe. Il est ainsi possible de conserver des appareils portables compacts tout en déplaçant les charges de travail plus lourdes vers un autre système.

Dans le workflow de JBlanked, le ZimaBoard 2 exécute ZimaOS, tandis qu’Ollama fournit le service de modèle de langage local. Une fois ce service disponible sur le réseau local, les appareils compatibles peuvent communiquer avec lui sans que chaque appareil portable dispose de suffisamment de puissance de calcul et de mémoire pour héberger lui-même le modèle.

La vidéo montre également un détail important concernant la configuration du serveur présenté : pendant l’exécution d’Ollama, le tableau de bord système de ZimaOS indique une NVIDIA GeForce RTX 3060 avec 12 Go de VRAM. Les performances montrées dans la démonstration doivent donc être considérées dans le contexte d’un serveur local équipé d’un GPU, et non comme celles d’un test du ZimaBoard 2 fonctionnant uniquement sur CPU.

Ollama s’exécutant dans ZimaOS, avec une NVIDIA GeForce RTX 3060 et 12 Go de VRAM visibles dans le tableau de bord système

Ollama s’exécute dans l’environnement ZimaOS. Le tableau de bord système visible à l’arrière indique la présence d’une NVIDIA GeForce RTX 3060 et de 12 Go de VRAM, ce qui montre que le serveur d’IA locale présenté bénéficie d’une accélération GPU.

Fonctionnement de la connexion à l’IA locale

La conception de base peut être comprise comme trois couches :

Couche serveur : ZimaBoard 2 exécute ZimaOS et héberge Ollama.
Couche agent ou réseau : Picoware ou la pile réseau du Flipper envoie les requêtes entre l’appareil intégré et le serveur local.
Couche appareil : Cardputer-ADV, PicoCalc ou Flipper Zero fournit l’interface physique et exécute les actions propres à l’appareil.

Cette séparation est utile, car le modèle de langage n’a pas besoin de s’exécuter directement sur chaque élément matériel. Le micrologiciel de chaque appareil peut exposer les fonctions qu’il prend en charge, tandis que le serveur fournit les capacités du modèle utilisées pour interpréter les requêtes ou assister les tâches de développement.

Cardputer-ADV et PicoCalc utilisent Picoware Agent

Le projet Picoware de JBlanked est un environnement de micrologiciel open source prenant en charge Cardputer-ADV, PicoCalc, Flipper Zero et d’autres appareils basés sur ESP32 ou Raspberry Pi Pico.

Pour cette expérience, le composant important est Picoware Agent. L’Agent fournit une interface optimisée par un LLM, avec différents contextes d’utilisation, au lieu de se limiter à une simple fenêtre de chat générique.

Ses modes documentés comprennent un chat général, un App Creator conçu pour créer ou modifier des applications Picoware, ainsi que des fonctions de gestion de l’appareil capables de traiter des informations et des commandes. La connexion de ces fonctionnalités à l’instance Ollama exécutée sur le serveur local offre à l’appareil portable un flux de développement assisté par l’IA, tout en évitant de faire fonctionner le modèle sur le petit appareil.

Le Flipper Zero envoie des requêtes au serveur d’IA local

Le Flipper Zero suit un schéma d’interaction différent. Dans la vidéo, JBlanked montre l’appareil préparer une charge utile de requête structurée destinée au modèle local, via une carte de développement compatible Wi-Fi fixée au Flipper.

La charge utile affichée à l’écran comprend un champ de modèle pour qwen3.5:9b. Cela illustre clairement la répartition des responsabilités : le Flipper prépare et envoie la requête, tandis que le modèle de langage sélectionné s’exécute sur le serveur local, plus puissant.

Flipper Zero saisit une charge utile de requête d’IA locale pour le modèle qwen3.5:9b, avec une carte de développement Wi-Fi fixée à l’appareil.

Flipper Zero prépare une charge utile de requête pour le service d’IA local. L’écran affiche le champ du modèle défini sur qwen3.5:9b, tandis qu’une carte de développement compatible Wi-Fi est fixée au-dessus de l’appareil.

Cette distinction est importante. Le Flipper n’exécute pas localement le modèle de langage complet. Son rôle est de fournir l’interface portable et la connexion réseau, tandis qu’Ollama et le modèle sélectionné s’exécutent sur le serveur.

Que peut réellement faire l’Agent IA local ?

Connecter un appareil portable à un LLM devient plus intéressant lorsque le modèle peut faire davantage que répondre à une question. JBlanked présente le serveur IA dans le cadre d’un flux de travail de développement embarqué.

Créer des applications Picoware

Picoware inclut un contexte App Creator pour son Agent IA. Cela permet à un développeur de décrire une application ou une modification en langage naturel et d’utiliser le modèle pour aider à produire ou à modifier l’application Picoware correspondante.

Dans la démonstration, il est demandé à App Creator de créer une application simple affichant le message « hello from youtube » au lancement. L’Agent renvoie une description structurée du comportement demandé et du fonctionnement de l’interface.

PicoCalc exécutant App Creator de Picoware pour une application affichant hello from youtube, à côté de Flipper Zero et Cardputer-ADV

App Creator de Picoware exécuté sur PicoCalc. L’Agent traite une demande de création d’une application affichant « hello from youtube », tandis que Flipper Zero et Cardputer-ADV sont posés à côté de l’appareil.

Cela peut réduire la distance entre une idée et un prototype, en particulier sur un appareil où saisir et modifier directement de grandes quantités de code source sur le petit écran serait autrement fastidieux.

Le code généré par l’IA doit toujours être vérifié. Un résultat qui semble plausible peut contenir des API incorrectes, une gestion des erreurs incomplète, des hypothèses dangereuses ou un comportement qui ne correspond pas au matériel cible.

Inspecter le firmware et les informations de développement

Le flux de travail de l’Agent peut également servir d’assistant au développement. Plutôt que de considérer l’appareil portable comme un simple client de conversation, le système peut combiner les réponses d’un modèle local avec les informations exposées par le périphérique et son firmware.

Cette approche est particulièrement utile sur les petits écrans, où parcourir manuellement les journaux, la documentation ou la sortie des commandes peut être plus lent que de demander à l’Agent d’interpréter une requête précise.

Gérer le périphérique

Le framework Agent de Picoware inclut également des fonctions de gestion du périphérique. Le modèle peut utiliser les outils exposés par le firmware, au lieu de simplement renvoyer du texte que l’utilisateur devrait exécuter manuellement.

Dans un exemple de la vidéo, l’utilisateur demande « combien de réseaux sont à proximité ». Le Gestionnaire de périphériques répond que six réseaux Wi-Fi sont disponibles à proximité, démontrant que l’Agent peut utiliser des informations au niveau du périphérique pour répondre à une demande pratique, plutôt que de s’appuyer uniquement sur les connaissances générales du modèle.

Gestionnaire de périphériques PicoCalc Picoware signalant six réseaux Wi-Fi à proximité, à côté de Flipper Zero et Cardputer-ADV

Le gestionnaire d’appareils Picoware sur PicoCalc répond à la question « combien de réseaux se trouvent à proximité ? ». L’interface signale six réseaux Wi-Fi à proximité, montrant comment l’agent peut associer l’IA locale aux informations obtenues depuis l’appareil.

C’est là qu’un agent d’IA se distingue d’un chatbot classique. Le modèle de langage fournit la couche d’interprétation et d’instructions, tandis que le micrologiciel détermine quelles opérations sur l’appareil et quelles sources d’information sont réellement disponibles.

Pourquoi un serveur d’IA local partagé est utile aux petits appareils

Cette architecture répond à un décalage fondamental des projets d’IA embarquée : les appareils les plus portables disposent souvent de la puissance de calcul la plus limitée pour les modèles de langage.

L’utilisation d’un serveur partagé modifie cet équilibre. Un développeur peut conserver l’interface physique dans un appareil de poche tout en lui donnant accès, via le réseau, à une machine locale plus puissante.

Exécuter l’IA directement sur l’appareil portable	Utiliser ZimaBoard 2 comme serveur d’IA
La puissance de calcul est limitée au processeur embarqué.	Le traitement de l’IA est transféré vers un serveur x86 dédié et le matériel d’accélération dont il dispose.
La taille du modèle est fortement limitée par la mémoire de l’appareil.	Le serveur peut utiliser sa propre mémoire système, la VRAM du GPU et son espace de stockage pour les fichiers de modèles.
Chaque appareil doit disposer de sa propre implémentation de l’IA.	Plusieurs clients peuvent partager un même service d’inférence local.
La mise à jour du modèle peut nécessiter des modifications sur chaque appareil.	Le modèle peut être géré de manière centralisée côté serveur.
L’appareil portable doit gérer à la fois l’interface et les tâches d’inférence.	L’appareil portable peut se concentrer sur l’interface, le micrologiciel, la mise en réseau et les fonctions propres à l’appareil.

Un seul backend d’IA, plusieurs appareils de makers

L’une des idées les plus utiles de l’expérience de JBlanked est que ZimaBoard 2 n’est pas lié à une seule interface. PicoCalc et Cardputer-ADV peuvent participer via Picoware, tandis que Flipper Zero peut communiquer avec le même environnement d’IA locale grâce à son propre processus de mise en réseau.

Le serveur devient ainsi un élément réutilisable d’un laboratoire de makers plus vaste. Au lieu de recréer un environnement d’IA pour chaque nouveau microcontrôleur ou ordinateur portable, les développeurs peuvent centraliser le service d’inférence et se concentrer sur l’intégration cliente adaptée à chaque appareil.

Le concept peut également simplifier l’expérimentation. Un modèle peut être modifié sur le serveur sans remplacer l’appareil portable, tandis que le micrologiciel de l’appareil peut évoluer indépendamment de l’environnement d’exécution de l’IA.

Ce que cette expérience prouve — et ce qu’elle ne prouve pas

La réalisation de JBlanked montre utilement comment l’IA locale peut s’intégrer au développement embarqué, mais il est important de distinguer l’architecture des garanties de performance ou de sécurité.

L’expérience démontre	Cela ne garantit pas
ZimaBoard 2 peut servir d’hôte Ollama local pour des clients équipés d’appareils embarqués.	Les mêmes performances seront obtenues sans le GPU présenté dans l’environnement de démonstration.
L’environnement de démonstration ZimaOS reconnaît une NVIDIA GeForce RTX 3060 avec 12 Go de VRAM.	Tous les modèles tiendront dans 12 Go de VRAM ou fonctionneront à la même vitesse.
PicoCalc et Cardputer-ADV peuvent utiliser Picoware dans le cadre d’un workflow d’IA local.	Chaque fonctionnalité ou modèle Picoware fonctionnera de manière identique sur tous les appareils pris en charge.
Le Flipper Zero peut envoyer des requêtes structurées au serveur d’IA local via une configuration compatible avec le réseau.	Le Flipper Zero lui-même exécute le modèle de langage.
Un agent IA peut aider à créer des applications et à gérer les appareils.	Le code, les interprétations ou les commandes générés par l’IA sont automatiquement corrects ou sûrs.
Un seul serveur local peut prendre en charge plusieurs interfaces pour petits appareils.	Un réseau local fournit automatiquement une authentification, une isolation ou une confidentialité complète.

Local ne signifie pas sans configuration

Exécuter Ollama localement évite d’avoir à envoyer chaque demande d’inférence à un service de chatbot hébergé, mais le système complet nécessite toujours une planification normale du serveur et du réseau.

Le modèle initial et les packages d’application doivent être installés, les appareils portables doivent pouvoir accéder au serveur via le réseau, et tout service exposé doit être configuré en tenant compte des limites réseau prévues. Les développeurs doivent également vérifier précisément quels outils un agent IA est autorisé à appeler avant d’activer les fonctionnalités de gestion des appareils.

La configuration de l’accélérateur est également importante. La RTX 3060 visible dans le tableau de bord ZimaOS de JBlanked dispose de 12 Go de VRAM ; le choix du modèle doit donc tenir compte de la mémoire GPU disponible, de la compatibilité avec l’environnement d’exécution et des exigences de performances de la charge de travail prévue.

Pour les cas d’utilisation liés à la génération de code, il est particulièrement important de conserver des sauvegardes ou d’utiliser un contrôle de version. Si une modification assistée par IA produit une application ou une configuration de firmware inutilisable, le développeur doit pouvoir revenir à un état connu et fonctionnel.

À qui s’adresse une configuration de ce type ?

Cette architecture est particulièrement intéressante pour les développeurs et les makers qui travaillent déjà avec des appareils embarqués, mais souhaitent expérimenter avec des LLM locaux sans transformer chaque projet en intégration d’une API cloud.

Cela peut être utile pour :

Les développeurs de Cardputer et de PicoCalc qui créent des applications Picoware.
Les utilisateurs de Flipper Zero qui expérimentent avec des outils connectés au réseau.
Les développeurs de systèmes embarqués qui souhaitent disposer d’une assistance IA à proximité de leur matériel de test.
Les utilisateurs de homelabs à la recherche d’une autre charge de travail pratique pour un serveur local.
Les makers qui souhaitent que plusieurs appareils basse consommation partagent un même backend d’IA.

Un service d’IA cloud peut rester plus simple pour les utilisateurs qui ont seulement besoin de discuter ou de générer du code occasionnellement et qui ne souhaitent pas gérer un serveur. Une station de travail plus grande ou un système plus puissant équipé d’un GPU peut également être plus adapté lorsque la taille des modèles et la vitesse d’inférence sont les priorités principales.

L’approche ZimaBoard 2 devient encore plus intéressante lorsque l’objectif est de conserver le service d’IA dans le même homelab et de le rendre accessible à plusieurs projets indépendants.

Créez un hub d’IA locale pour votre laboratoire de création

Le projet de JBlanked montre une piste intéressante pour l’IA locale : au lieu de se demander si chaque petit appareil peut exécuter un modèle de langage, il faut se demander si ces appareils peuvent utiliser un modèle partagé exécuté quelque part où il est mieux adapté à cette tâche.

Avec ZimaOS qui héberge Ollama sur ZimaBoard 2, Picoware qui fournit une interface assistée par IA pour des appareils tels que PicoCalc et Cardputer-ADV, et un flux de travail compatible réseau intégrant Flipper Zero au même environnement, le système devient un hub d’IA locale flexible pour l’expérimentation embarquée.

Les quatre démonstrations montrent également pourquoi le serveur doit être évalué comme un système complet. Les appareils portables fournissent les interfaces et les fonctions propres au matériel, Ollama fournit la couche de mise à disposition des modèles, et le GPU visible dans ZimaOS apporte des ressources de calcul supplémentaires à la charge de travail d’IA locale.

Pour découvrir une autre utilisation des modèles locaux sur la même plateforme, consultez le test de l’assistant d’IA locale sur ZimaBoard 2, qui explore la relation entre le matériel de serveur compact, la taille des modèles, le stockage et les charges de travail d’IA.

Regardez la vidéo complète de JBlanked pour voir directement la configuration et le fonctionnement de l’appareil, ou explorez le projet Picoware sur GitHub si vous souhaitez comprendre comment l’Agent et les appareils pris en charge s’intègrent.

Vous voulez voir ce que d’autres créateurs font avec des serveurs compacts, l’IA locale et du matériel original ? Rejoignez la communauté Discord ZimaSpace pour découvrir d’autres configurations, comparer les installations et partager vos propres expériences.