Cómo JBlanked conecta Flipper Zero, Cardputer y PicoCalc con IA local mediante ZimaBoard 2

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

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

Gracias a JBlanked por documentar una forma diferente de incorporar la IA local al desarrollo de dispositivos integrados. En su video completo, convierte ZimaBoard 2 en un servidor local de Ollama y conecta dispositivos portátiles, como Cardputer-ADV, PicoCalc y Flipper Zero, a ese entorno de IA compartido.

En lugar de intentar ejecutar un modelo de lenguaje grande directamente en cada dispositivo pequeño, el experimento separa la carga de trabajo: ZimaBoard 2 gestiona el servicio de IA local, mientras que los dispositivos portátiles actúan como interfaces de desarrollo ligeras. JBlanked utiliza entonces su agente Picoware de código abierto para crear aplicaciones, consultar la información de los dispositivos y gestionar el hardware mediante esa conexión de IA local.

Divulgación de la colaboración: este artículo se basa en la configuración mostrada por JBlanked y en la documentación pública de Picoware y FlipperHTTP. Las versiones del software, la disponibilidad de modelos de IA, la compatibilidad del hardware y el rendimiento de la inferencia local pueden cambiar con el tiempo.

El resultado: un único servidor doméstico compacto puede proporcionar la capa de IA para varios dispositivos maker con recursos limitados. El hardware portátil sigue ejecutando su propio firmware e interfaz, mientras que Ollama puede encargarse de las tareas de modelos de lenguaje que requieren más capacidad de cálculo en el servidor local.

La configuración de IA local de un vistazo

El proyecto combina un servidor x86 compacto con varias plataformas integradas. En lugar de imponer la misma pila de software a todos los dispositivos, JBlanked utiliza diferentes capas de conexión según las capacidades de cada dispositivo.

Componente	Función en la configuración	Consideración clave
ZimaBoard 2	Actúa como el servidor local central que ejecuta ZimaOS y aloja el entorno de IA.	El rendimiento del modelo depende de la configuración completa del hardware, no solo de la CPU de la placa.
ZimaOS	Proporciona el entorno del servidor y la App Store utilizados para implementar Ollama.	La configuración de la aplicación y el acceso a la red deben revisarse antes de usar el servidor con proyectos confidenciales.
Ollama	Ejecuta el modelo de lenguaje localmente y responde a las solicitudes de los dispositivos conectados.	Los distintos modelos tienen diferentes requisitos de memoria, almacenamiento y aceleración.
NVIDIA GeForce RTX 3060	Aparece en el entorno de ZimaOS mostrado como una GPU disponible con 12 GB de VRAM.	La GPU que se muestra en el video forma parte de la configuración demostrada y debe tenerse en cuenta al evaluar los resultados de inferencia.
Cardputer-ADV	Ejecuta Picoware y utiliza la interfaz Agent para comunicarse con el servidor de IA local.	El dispositivo portátil sigue siendo la interfaz; el modelo de lenguaje se ejecuta en el servidor.
PicoCalc	Utiliza Picoware como otro cliente para el mismo flujo de trabajo de IA local.	Las funciones disponibles dependen de la versión actual de Picoware y de la configuración del dispositivo.
Flipper Zero	Utiliza una ruta de solicitudes de red para comunicarse con el servicio de IA local.	Se requiere un puente o una placa de desarrollo compatible con Wi-Fi para la comunicación de red.

¿Por qué usar ZimaBoard 2 como servidor de IA?

Lo interesante de este proyecto no es simplemente que ZimaBoard 2 pueda ejecutar una aplicación de IA. Es la forma en que la placa cambia la arquitectura de los pequeños proyectos integrados.

Dispositivos como Cardputer, PicoCalc y Flipper Zero están diseñados para ofrecer portabilidad y hardware integrado especializado. Son útiles para interfaces, scripts, experimentos con firmware, herramientas de red y aplicaciones portátiles, pero sus recursos integrados son mucho más limitados que los de una estación de trabajo de IA convencional.

El mini servidor doméstico ZimaBoard 2 proporciona un host x86 independiente con conexión de red por cable, conectividad para almacenamiento y expansión PCIe. Esto permite mantener pequeños los dispositivos portátiles y trasladar la carga de trabajo más exigente del servidor a otro equipo.

En el flujo de trabajo de JBlanked, ZimaBoard 2 ejecuta ZimaOS y Ollama proporciona el servicio de modelos de lenguaje local. Una vez que el servicio está disponible en la red local, los dispositivos compatibles pueden comunicarse con él sin que cada dispositivo portátil necesite suficiente capacidad de procesamiento y memoria para alojar el modelo por sí mismo.

El video también muestra un detalle importante sobre la configuración del servidor: mientras Ollama está en ejecución, el panel del sistema de ZimaOS indica una NVIDIA GeForce RTX 3060 con 12 GB de VRAM. Esto significa que el rendimiento mostrado en la demostración debe entenderse en el contexto de un servidor local equipado con GPU, no como una prueba de ZimaBoard 2 usando únicamente la CPU.

Ollama ejecutándose en ZimaOS, con una NVIDIA GeForce RTX 3060 y 12 GB de VRAM visibles en el panel del sistema

Ollama ejecutándose dentro del entorno de ZimaOS. El panel del sistema visible detrás muestra una NVIDIA GeForce RTX 3060 y 12 GB de VRAM, lo que indica que el servidor de IA local mostrado cuenta con aceleración mediante GPU.

Cómo funciona la conexión con la IA local

El diseño básico puede entenderse en tres capas:

Capa del servidor: ZimaBoard 2 ejecuta ZimaOS y aloja Ollama.
Capa del agente o de red: Picoware o la pila de red del Flipper envía solicitudes entre el dispositivo integrado y el servidor local.
Capa del dispositivo: Cardputer-ADV, PicoCalc o Flipper Zero proporciona la interfaz física y ejecuta acciones específicas del dispositivo.

Esta separación es útil porque el modelo de lenguaje no necesita ejecutarse directamente en cada pieza de hardware. El firmware de cada dispositivo puede exponer las funciones compatibles, mientras que el servidor proporciona la capacidad del modelo utilizada para interpretar solicitudes o ayudar con tareas de desarrollo.

Cardputer-ADV y PicoCalc usan Picoware Agent

El proyecto de código abierto Picoware de JBlanked es un entorno de firmware compatible con Cardputer-ADV, PicoCalc, Flipper Zero y otros dispositivos basados en ESP32 o Raspberry Pi Pico.

Para este experimento, el componente importante es Picoware Agent. Agent proporciona una interfaz basada en un LLM con distintos contextos operativos, en lugar de actuar únicamente como una ventana de chat genérica.

Sus modos documentados incluyen chat general, un creador de aplicaciones diseñado para crear o editar aplicaciones de Picoware y funciones de gestión del dispositivo que pueden trabajar con información y comandos. Conectar esas capacidades a la instancia de Ollama en el servidor local proporciona al dispositivo portátil un flujo de trabajo de desarrollo asistido por IA, al tiempo que mantiene la carga de trabajo del modelo fuera del pequeño dispositivo.

Flipper Zero envía solicitudes al servidor de IA local

El Flipper Zero sigue un patrón de interacción diferente. En el video, JBlanked muestra cómo el dispositivo prepara una carga útil de solicitud estructurada para el modelo local mediante una placa de desarrollo con Wi‑Fi conectada al Flipper.

La carga útil que se muestra en la pantalla incluye un campo de modelo para qwen3.5:9b. Esto ilustra claramente la división de responsabilidades: el Flipper prepara y envía la solicitud, mientras que el modelo de lenguaje seleccionado se ejecuta en el servidor local, más potente.

Flipper Zero introduciendo una carga útil de solicitud de IA local para el modelo qwen3.5:9b, con una placa de desarrollo con Wi‑Fi conectada

Flipper Zero preparando una carga útil de solicitud para el servicio de IA local. La pantalla muestra el campo del modelo establecido en qwen3.5:9b, mientras una placa de desarrollo con Wi‑Fi está conectada en la parte superior del dispositivo.

Esta distinción es importante. El Flipper no ejecuta localmente el modelo de lenguaje completo. Su función es proporcionar la interfaz portátil y la conexión de red, mientras que Ollama y el modelo seleccionado se ejecutan en el servidor.

¿Qué puede hacer realmente el Agente de IA local?

Conectar un dispositivo portátil a un LLM resulta más interesante cuando el modelo puede hacer algo más que responder una pregunta. JBlanked muestra el servidor de IA como parte de un flujo de trabajo de desarrollo integrado.

Crear aplicaciones de Picoware

Picoware incluye un contexto de App Creator para su Agente de IA. Esto permite a un desarrollador describir una aplicación o un cambio en lenguaje natural y utilizar el modelo para ayudar a producir o editar la aplicación de Picoware correspondiente.

En la demostración, se pide a App Creator que cree una aplicación sencilla que muestre el saludo «hello from youtube» al iniciarse. El Agente devuelve una descripción estructurada del comportamiento solicitado y de cómo debería funcionar la interfaz.

PicoCalc ejecutando Picoware App Creator para una aplicación de saludo «hello from youtube» junto a Flipper Zero y Cardputer-ADV

App Creator de Picoware ejecutándose en PicoCalc. El Agente está procesando una solicitud para una aplicación que muestra «hello from youtube», mientras Flipper Zero y Cardputer-ADV se encuentran junto al dispositivo.

Eso puede acortar la distancia entre una idea y un prototipo, especialmente en un dispositivo donde escribir y editar directamente grandes cantidades de código fuente en la pantalla pequeña resultaría engorroso.

El código generado por IA aún requiere revisión. Un resultado que parece plausible puede contener API incorrectas, un manejo de errores incompleto, suposiciones inseguras o un comportamiento que no coincida con el hardware de destino.

Inspeccionar el firmware y la información de desarrollo

El flujo de trabajo del Agente también puede utilizarse como asistente de desarrollo. En lugar de tratar el dispositivo portátil como un cliente de chat convencional, el sistema puede combinar las respuestas de un modelo local con la información que exponen el dispositivo y su firmware.

Este enfoque resulta especialmente útil en pantallas pequeñas, donde navegar manualmente por registros, documentación o resultados de comandos puede ser más lento que pedirle al Agente que interprete una solicitud específica.

Administrar el dispositivo

El marco de trabajo del Agente de Picoware también incluye funciones de administración del dispositivo. El modelo puede trabajar con las herramientas que expone el firmware, en lugar de limitarse a devolver texto para que el usuario lo ejecute manualmente.

En un ejemplo del video se pregunta «cuántas redes hay cerca». El Administrador de dispositivos responde que hay seis redes Wi-Fi cercanas disponibles, lo que demuestra que el Agente puede utilizar información del dispositivo para responder a una solicitud práctica, en lugar de depender únicamente del conocimiento general del modelo.

Administrador de dispositivos PicoCalc Picoware mostrando seis redes Wi-Fi cercanas junto a Flipper Zero y Cardputer-ADV

Picoware Device Manager en PicoCalc responde a la pregunta «cuántas redes hay cerca». La interfaz muestra seis redes Wi‑Fi cercanas, lo que demuestra cómo el agente puede combinar la IA local con información obtenida del dispositivo.

Aquí es donde un agente de IA se diferencia de un chatbot normal. El modelo de lenguaje proporciona la capa de interpretación e instrucciones, mientras que el firmware determina qué operaciones del dispositivo y fuentes de información están realmente disponibles.

Por qué un servidor de IA local compartido es útil para dispositivos pequeños

La arquitectura aborda un desajuste básico de los proyectos de IA embebida: los dispositivos más portátiles suelen ser los que menos capacidad de cómputo tienen disponible para los modelos de lenguaje.

Usar un servidor compartido cambia ese equilibrio. Un desarrollador puede mantener la interfaz física en un dispositivo del tamaño de un bolsillo y darle acceso a una máquina local más potente a través de la red.

Ejecutar la IA directamente en el dispositivo portátil	Usar ZimaBoard 2 como servidor de IA
La capacidad de cómputo está limitada por el procesador embebido.	El procesamiento de IA se traslada a un servidor x86 dedicado y al hardware acelerador disponible.
El tamaño del modelo está muy limitado por la memoria del dispositivo.	El servidor puede utilizar su propia memoria del sistema, la VRAM de la GPU y el almacenamiento para los archivos del modelo.
Cada dispositivo necesita su propia implementación de IA.	Varios clientes pueden compartir un mismo servicio de inferencia local.
Actualizar el modelo puede requerir cambios en todos los dispositivos.	El modelo puede gestionarse de forma centralizada en el servidor.
El dispositivo portátil debe gestionar tanto las cargas de trabajo de la interfaz como las de inferencia.	El dispositivo portátil puede centrarse en la interfaz, el firmware, la conectividad de red y las funciones específicas del dispositivo.

Un backend de IA, varios dispositivos maker

Una de las ideas más útiles del experimento de JBlanked es que ZimaBoard 2 no está vinculado a una única interfaz. PicoCalc y Cardputer-ADV pueden participar mediante Picoware, mientras que Flipper Zero puede comunicarse con el mismo entorno de IA local a través de su propio flujo de trabajo de red.

Esto convierte al servidor en una pieza reutilizable de un laboratorio maker más amplio. En lugar de reconstruir un entorno de IA para cada nuevo microcontrolador u ordenador portátil, los desarrolladores pueden mantener el servicio de inferencia centralizado y centrarse en crear la integración del cliente que tenga sentido para cada dispositivo.

El concepto también puede simplificar la experimentación. El modelo puede cambiarse en el servidor sin sustituir el dispositivo portátil, mientras que el firmware del dispositivo puede evolucionar de forma independiente del entorno de ejecución de la IA.

Lo que este experimento demuestra —y lo que no

La creación de JBlanked es una demostración útil de cómo la IA local puede integrarse en el desarrollo de sistemas embebidos, pero es importante distinguir la arquitectura de las garantías de rendimiento o seguridad.

El experimento demuestra	No garantiza
ZimaBoard 2 puede funcionar como host local de Ollama para clientes de dispositivos embebidos.	Se obtendrá el mismo rendimiento sin la GPU mostrada en el entorno de demostración.
El entorno de demostración de ZimaOS reconoce una NVIDIA GeForce RTX 3060 con 12 GB de VRAM.	Todos los modelos cabrán en 12 GB de VRAM o se ejecutarán a la misma velocidad.
PicoCalc y Cardputer-ADV pueden usar Picoware como parte de un flujo de trabajo de IA local.	Todas las funciones o modelos de Picoware funcionarán de forma idéntica en todos los dispositivos compatibles.
Flipper Zero puede enviar solicitudes estructuradas al servidor de IA local mediante una configuración con capacidad de red.	El propio Flipper Zero está ejecutando el modelo de lenguaje.
Un agente de IA puede ayudar en la creación de aplicaciones y los flujos de trabajo de gestión de dispositivos.	El código, las interpretaciones o los comandos generados por IA son automáticamente correctos o seguros.
Un solo servidor local puede admitir varias interfaces de dispositivos pequeños.	Una red local no proporciona automáticamente autenticación, aislamiento ni privacidad completa.

Local no significa configuración cero

Ejecutar Ollama localmente elimina la necesidad de enviar cada solicitud de inferencia a un servicio de chatbot alojado, pero el sistema completo aún requiere una planificación normal del servidor y la red.

Deben instalarse el modelo inicial y los paquetes de aplicaciones; los dispositivos portátiles necesitan acceso de red al servidor, y cualquier servicio expuesto debe configurarse teniendo en cuenta los límites de red previstos. Los desarrolladores también deben verificar exactamente qué herramientas puede utilizar un agente de IA antes de habilitar funciones de gestión de dispositivos.

La configuración del acelerador también es importante. La RTX 3060 visible en el panel de ZimaOS de JBlanked tiene 12 GB de VRAM, por lo que la elección del modelo aún debe tener en cuenta la memoria de GPU disponible, la compatibilidad del entorno de ejecución y los requisitos de rendimiento de la carga de trabajo prevista.

Para casos de uso de generación de código, es especialmente importante mantener copias de seguridad o un sistema de control de versiones. Si una edición asistida por IA produce una aplicación o configuración de firmware inutilizable, el desarrollador necesita poder volver a un estado funcional conocido.

¿Quién debería considerar una configuración como esta?

Esta arquitectura resulta especialmente interesante para desarrolladores y creadores que ya trabajan con dispositivos embebidos, pero quieren experimentar con LLM locales sin convertir cada proyecto en una integración con una API en la nube.

Puede ser útil para:

Desarrolladores de Cardputer y PicoCalc que crean aplicaciones de Picoware.
Usuarios de Flipper Zero que experimentan con herramientas conectadas a la red.
Desarrolladores de sistemas embebidos que quieren asistencia de IA cerca de su hardware de prueba.
Usuarios de homelab que buscan otra carga de trabajo práctica para un servidor local.
Creadores que quieren que varios dispositivos de bajo consumo compartan un backend de IA.

Un servicio de IA en la nube puede seguir siendo más sencillo para los usuarios que solo necesitan chatear o generar código ocasionalmente y no quieren mantener un servidor. Una estación de trabajo más grande o un sistema con una GPU más potente también puede ser más adecuado cuando el tamaño del modelo y la velocidad de inferencia son las prioridades principales.

El enfoque de ZimaBoard 2 resulta aún más atractivo cuando el objetivo es mantener el servicio de IA dentro del mismo homelab y ponerlo a disposición de varios proyectos independientes.

Construye un centro de IA local para tu laboratorio maker

El proyecto de JBlanked muestra una dirección útil para la IA local: en lugar de preguntarse si cada dispositivo pequeño puede ejecutar un modelo de lenguaje, hay que preguntarse si esos dispositivos pueden utilizar un modelo compartido que se ejecute en un sistema más adecuado para la tarea.

Con ZimaOS alojando Ollama en ZimaBoard 2, Picoware proporcionando una interfaz asistida por IA para dispositivos como PicoCalc y Cardputer-ADV, y un flujo de trabajo con capacidad de red que incorpora Flipper Zero al mismo entorno, el sistema se convierte en un centro flexible de IA local para la experimentación con dispositivos integrados.

Las cuatro demostraciones también muestran por qué el servidor debe evaluarse como un sistema completo. Los dispositivos portátiles proporcionan las interfaces y las funciones específicas del hardware, Ollama proporciona la capa de servicio de modelos y la GPU visible en ZimaOS aporta recursos de cómputo adicionales para la carga de trabajo de IA local.

Para ver otro ejemplo de lo que los modelos locales pueden hacer en la misma plataforma, consulta la prueba del asistente de IA local de ZimaBoard 2, que explora la relación entre el hardware de servidor compacto, el tamaño del modelo, el almacenamiento y las cargas de trabajo de IA.

Mira el video completo de JBlanked para ver directamente la configuración y el flujo de trabajo del dispositivo, o explora el proyecto Picoware en GitHub si quieres entender cómo encajan el agente y los dispositivos compatibles.

¿Quieres ver qué están haciendo otros creadores con servidores compactos, IA local y hardware poco convencional? Únete a la comunidad de Discord de ZimaSpace para descubrir más proyectos, comparar configuraciones y compartir tus propios experimentos.