Cuando se habla de modelos de lenguaje grandes (LLMs), la mayoría de la gente imagina un asistente de propósito general: algo capaz de responder sobre clima, política, software, historia, viajes, cocina, electrónica y casi cualquier otro tema. Se espera que el modelo sepa un poco de todo, sostenga conversaciones abiertas y reaccione a un rango muy amplio de prompts. Esa es la experiencia a la que estamos acostumbrados, porque las herramientas de IA en la nube se masificaron rápido.

Los sistemas embebidos viven en un mundo mucho más acotado. Un robot no necesita discutir política, un sistema de inspección no necesita sugerir destinos de vacaciones y un asistente de mantenimiento instalado junto a una máquina no necesita explicar historia antigua. El sistema debe entender el dispositivo, la tarea, los comandos posibles, los datos locales y las acciones que es seguro sugerir o ejecutar. El objetivo es darle al equipo de borde la inteligencia lingüística suficiente para volverse más útil, más comprensible y menos dependiente de la red.

Ese es el marco en el que conviene pensar los LLMs locales sobre la UNO Q: una plataforma práctica para explorar la idea porque junta un entorno Debian Linux con el ecosistema de hardware Arduino. El lado Linux puede correr herramientas locales de IA, flujos en línea de comandos, aplicaciones Python, servicios web y runtimes de inferencia. El lado Arduino conecta esa inteligencia con sensores, actuadores, shields, nodos Arduino Modulino y señales del mundo físico. La combinación abre la puerta a experimentar con modelos de lenguaje no como chatbots aislados, sino como parte de flujos embebidos reales.

La pregunta clave no es cómo forzar la corrida de un modelo grande, sino qué tipo de inteligencia útil puede vivir cerca de los datos, del dispositivo y de la acción física.

Paso 1: elegir el modelo correcto para tu caso

El edge es donde los modelos más chicos y optimizados se vuelven interesantes. En la nube tiene sentido un modelo general grande porque se espera que responda casi cualquier cosa. En el borde, un modelo entrenado, afinado, destilado o cuantizado para un dominio específico puede ser más práctico. Carga menos peso innecesario, se concentra en el tipo de lenguaje que el dispositivo realmente necesita y se integra a un flujo de aplicación controlado.

Por ejemplo, en robótica la interacción suele reducirse a un conjunto limitado de instrucciones útiles: avanzar, detenerse, inspeccionar un objeto, volver a base, reportar nivel de batería, explicar el último error, pasar a modo manual. El modelo puede ayudar a interpretar lenguaje natural, pero el sistema debe mapear esa interpretación a un set acotado de comandos válidos. Eso vuelve el comportamiento más testeable, más validable y más confiable.

Ese alcance acotado es una de las razones por las que los LLMs locales pueden tener sentido en plataformas embebidas.

Paso 2: entender los límites de memoria y almacenamiento

Un modelo de lenguaje grande suele tener muchos parámetros, y cada parámetro representa datos que hay que almacenar, cargar y procesar durante la inferencia. Los pesos del modelo son solo parte de la historia. Durante la generación, el runtime también necesita memoria de trabajo para el prompt, la computación intermedia y la cache key-value que los transformers usan para llevar registro de tokens previos. A medida que crece el contexto, crece el consumo de memoria.

Un modelo de 1.000 millones de parámetros en cuantización de 4 bits (por ejemplo, Llama 3.2 1B Q4) ocupa cerca de 600 a 700 MB en disco y requiere alrededor de 1 GB de RAM en tiempo de ejecución, incluyendo la cache KV para una ventana de contexto corta. Un modelo de 3B con la misma precisión supera los 2 GB. Son números que importan en una placa con memoria y almacenamiento fijos, donde el modelo tiene que convivir con el sistema operativo, el runtime y el resto de la aplicación.

La cuantización es una de las técnicas que vuelve esto más realista. En vez de guardar los pesos del modelo con valores numéricos de alta precisión, un modelo cuantizado usa representaciones de menor precisión. Eso reduce el uso de memoria y puede hacer viable la inferencia en hardware que de otro modo quedaría corto. En la práctica, la cuantización lleva al modelo desde "demasiado grande para correr localmente" a "lo suficientemente chico para experimentar", aceptando un trade-off en precisión, fluidez o velocidad según el caso.

La destilación de modelos es otro concepto clave. En términos simples, la destilación es un enfoque de entrenamiento donde un modelo más chico aprende de un modelo profesor más grande. El objetivo es preservar comportamiento útil reduciendo el costo de inferencia y el footprint de memoria. Un modelo destilado no tendrá el alcance completo del profesor, pero puede ser mucho más adecuado cuando la aplicación necesita una capacidad focalizada on-device.

El proyecto Running local LLMs and VLMs on UNO Q with yzma expande la conversación más allá del chat de texto y explora flujos locales con LLMs y VLMs usando yzma y llama, apuntando a una clase más amplia de experimentos de IA en el borde donde los modelos pueden trabajar con imágenes, datos locales y contexto del dispositivo.

Paso 3: identificar dónde el LLM local agrega valor real

Los LLMs locales se vuelven aún más útiles cuando se combinan con otros flujos de borde. El OCR es un buen ejemplo. Una cámara conectada a una UNO Q puede extraer texto de una etiqueta, una pantalla, un documento o una interfaz de máquina. Un modelo de lenguaje compacto puede después resumir ese texto, clasificarlo o convertirlo en una respuesta estructurada. El modelo solo necesita procesar el contexto relevante, lo que mantiene el flujo más liviano y focalizado.

El mismo principio se aplica a una UNO Q que recolecta logs, lecturas de sensores, estados de error o eventos del sistema. Un modelo local puede transformar esa información en un resumen breve y legible directamente en el dispositivo. Para un técnico, eso convierte datos crudos en algo de utilidad inmediata: una explicación compacta del estado actual o una descripción corta de la última condición de error.

Paso 4: diseñar la arquitectura y fijar los límites

Una manera práctica de pensar los LLMs locales en UNO Q es tratar al modelo como una capa de razonamiento ocasional. Se invoca cuando la comprensión de lenguaje, el resumen o la interpretación aportan valor. Los lazos de control rápidos, el monitoreo continuo y las acciones críticas en tiempo siguen siendo mejor terreno para software determinístico corriendo en el lado adecuado del sistema.

Al trabajar con LLMs locales sobre UNO Q hay tres parámetros prácticos. El uso de memoria viene primero: el modelo debe entrar cómodamente junto con el runtime y el resto de la aplicación. La latencia de respuesta viene después: un modelo que corre puede igual sentirse lento si el caso de uso espera respuestas instantáneas. El almacenamiento también hay que planearlo con cuidado, porque los archivos del modelo y las dependencias pueden ser voluminosos.

El mejor punto de entrada es el tutorial del Arduino Project Hub Local LLM AI Chatbot on UNO Q, que recorre la instalación de un LLM chico y su ejecución offline. Funciona como punto de partida porque muestra la forma básica de una aplicación de LLM local.

Existe también un puente natural hacia los agentes locales. Los flujos agénticos pueden ir más allá de un chat simple y empezar a coordinar herramientas, archivos, scripts y acciones. Sobre UNO Q, esta dirección se vuelve especialmente interesante cuando el agente es tratado como orquestador en el lado Linux. Puede inspeccionar logs, preparar archivos, llamar scripts, interactuar con herramientas locales o ayudar a manejar flujos de desarrollo, mientras la capa orientada al hardware mantiene el control directo sobre el I/O físico.

Ese tipo de configuración exige límites claros. Darle a un agente acceso a herramientas significa darle la capacidad de cambiar cosas, así que el entorno se debe diseñar con criterio. Una placa dedicada puede funcionar como un sandbox útil para este tipo de experimentación, con credenciales acotadas, acceso a datos limitado y un set específico de herramientas permitidas. Eso permite explorar flujos agénticos manteniendo el sistema comprensible y controlado.

Para quienes prefieren un flujo de desarrollo familiar, Installing Ollama on Arduino UNO Q cubre un detalle práctico que pesa mucho en sistemas Linux embebidos: cómo gestionar de forma eficiente los recursos disponibles en la UNO Q para sacarle el máximo provecho.

Paso 5: correr, medir, iterar

Elegí un modelo, corrélo en la placa y prestá atención al uso de memoria y al tiempo de respuesta para tu prompt específico. Esos datos del mundo real dicen más que cualquier benchmark, y entregan una imagen mucho más clara de dónde encaja un LLM local en el próximo proyecto embebido.

Los LLMs locales sobre UNO Q siempre balancean potencia, costo, tamaño, latencia, privacidad, confiabilidad y conectividad. La pregunta interesante es cuánta inteligencia útil se puede colocar cerca de los datos, del hardware y del usuario. La IA en el borde no se trata de más potencia, se trata de elecciones más inteligentes. Con el modelo correcto, la arquitectura correcta y la flexibilidad de la UNO Q, se puede testear IA local donde más importa: sobre hardware real, en proyectos reales.

¿Qué hace de la UNO Q un terreno fértil para LLMs locales?

La combinación Debian Linux más microcontrolador es la diferencia con un ESP32 puro. Linux carga Ollama, llama.cpp o yzma sin pelearse con flash, mientras que el lado MCU sigue manejando GPIO, sensores y actuadores con timing determinístico. El integrador chileno que ya armaba proyectos con Raspberry Pi 5 más Arduino aparte ahora tiene una placa única que cubre los dos roles, con la UNO Q 4GB disponible vía Mouser, RS Components, Robu.in y otros distribuidores autorizados, incluyendo varios con presencia regional en LATAM.

Cifras útiles para dimensionar el proyecto

  • Llama 3.2 1B Q4: 600 a 700 MB en disco, cerca de 1 GB de RAM en runtime con contexto corto.
  • 3B con misma precisión: supera los 2 GB de RAM, exige planificación de swap o variante con más memoria.
  • Roles típicos: resumen de logs de sensores, interpretación de comandos en lenguaje natural para robots con vocabulario acotado, OCR más clasificación de etiquetas en línea de producción.
  • No es para: control en tiempo real, lazos PID, lectura de encoder de alta frecuencia. Eso sigue en el lado MCU.