¿Es posible usar APIs públicas de IA en un ESP32? Sí, y dónde trabaja cada pieza
Un modelo de lenguaje de 28,9 millones de parámetros genera texto dentro de un ESP32-S3 a 9,5 tokens por segundo. La corrección y el trabajo de cada pieza.
Requisitos de hardware:
- Placa ESP32 ou ESP32-S3 com Wi-Fi
- Rede Wi-Fi com saída para internet
- Opcional: PC ou mini-servidor na mesma rede, para a parte do modelo local
Descarga el material de este tutorial:
- Projeto completo (ZIP)343 KBFirmware que consulta um modelo pelos dois caminhos: HTTP simples para um gateway na sua rede, ou HTTPS para a nuvem. Filtro de JSON, consulta não bloqueante, README e manual em PDF.
- Manual em PDF (7 páginas)417 KBComparativo entre nuvem e rede local, o custo de RAM do handshake TLS, filtro de JSON e checklist de dez itens.
¿Quieres recibir nuevos manuales y esquemas industriales? Únete a nuestro canal de Telegram / WhatsApp
La pregunta que todos hacen
“¿Se puede poner ChatGPT dentro de un ESP32?”
La respuesta corta es que el ESP32 puede conversar con estos modelos, y eso es muy diferente de ejecutar uno dentro del chip. Entender esa diferencia separa un proyecto que funciona en el banco de uno que funciona en campo, y ese es el tema de este texto.
Qué es realmente una de estas IA
Cuando se habla de Gemini, ChatGPT o Claude, se habla de una red neuronal. Simplificando lo que importa aquí: el modelo procesó una enorme cantidad de texto y guardó lo aprendido como miles de millones de números llamados pesos.
Responder una pregunta significa hacer cálculos con todos esos números. No es buscar una respuesta preparada en una base de datos: es cálculo, cada vez.
Guarda esta idea, porque todo lo que sigue se deriva de ella.
Por qué los modelos grandes no funcionan dentro de la placa
La pregunta natural es: si solo es un montón de números, ¿por qué no guardarlos en la flash y ejecutarlos allí?
Depende del tamaño del modelo. Para los grandes, el límite no es el espacio, sino la capacidad de cálculo y memoria. Un ESP32 tiene unos cientos de kilobytes de RAM interna. Gemini, ChatGPT y Claude necesitan decenas de gigabytes de memoria de vídeo y aceleradores dedicados solo para responder en un tiempo razonable. Están en el centro de datos y ninguna arquitectura ingeniosa cambia eso.
Lo que cambió desde la primera versión de este texto es dónde está la frontera de lo “pequeño”, y quedó mucho más lejos de lo que se suponía. Al final del artículo hay una rectificación sobre esto.
No es un defecto del ESP32. Son herramientas para trabajos diferentes: un servidor no permanece cinco meses encendido en un panel a 45 °C consumiendo menos de un vatio, y un ESP32 no hace álgebra lineal a escala de centro de datos. Cada uno en su sitio.
Cómo conversa el ESP32 con el modelo: la API
Una API es la forma en que un programa conversa con otro. Para quien viene de la automatización, la analogía más directa es esta: el ESP32 envía un valor a un servidor y recibe una respuesta, como consultar un equipo remoto. La diferencia es que ese “equipo” es un modelo en Internet, cobra por consulta y depende de que el enlace esté activo.
En la práctica, la placa se conecta al Wi-Fi, hace una petición HTTPS al proveedor con una clave de acceso y lee el texto que vuelve.
| 1 | #include <WiFi.h> |
| 2 | #include <HTTPClient.h> |
| 3 | const char* WIFI_SSID = "TU_RED"; |
| 4 | const char* WIFI_PASS = "TU_CONTRASENA"; |
| 5 | // La clave queda grabada en el firmware. Recuerda este detalle: |
| 6 | // vuelve a aparecer más adelante en el texto. |
| 7 | const char* API_URL = "https://api.ejemplo.com/v1/chat"; |
| 8 | const char* API_KEY = "tu-clave-aqui"; |
| 9 | String preguntarAlModelo(const String& pregunta) { |
| 10 | HTTPClient http; |
| 11 | http.begin(API_URL); |
| 12 | http.addHeader("Content-Type", "application/json"); |
| 13 | http.addHeader("Authorization", String("Bearer ") + API_KEY); |
| 14 | String cuerpo = "{\"prompt\":\"" + pregunta + "\"}"; |
| 15 | int codigo = http.POST(cuerpo); |
| 16 | String respuesta = (codigo == 200) ? http.getString() : String(""); |
| 17 | http.end(); |
| 18 | return respuesta; |
| 19 | } |
| 20 | void setup() { |
| 21 | Serial.begin(115200); |
| 22 | WiFi.begin(WIFI_SSID, WIFI_PASS); |
| 23 | // Sin límite de tiempo la placa queda aquí para siempre si el Wi-Fi |
| 24 | // no sube, y el artículo trata precisamente de depender del enlace. |
| 25 | unsigned long inicio = millis(); |
| 26 | while (WiFi.status() != WL_CONNECTED && millis() - inicio < 20000) { |
| 27 | delay(500); |
| 28 | Serial.print("."); |
| 29 | } |
| 30 | Serial.println(); |
| 31 | if (WiFi.status() != WL_CONNECTED) { |
| 32 | Serial.println("Sin Wi-Fi: no hay nada que hacer sin el enlace."); |
| 33 | return; |
| 34 | } |
| 35 | Serial.println(preguntarAlModelo("Explica MQTT en una frase.")); |
| 36 | } |
| 37 | void loop() { |
| 38 | // Ejemplo mínimo: una consulta al arrancar. |
| 39 | } |
Y funciona. La respuesta aparece en el monitor serie y es un buen momento: acabas de conectar un microcontrolador barato con un modelo que se ejecuta en un centro de datos.
Aquí termina la mayoría de los tutoriales. Demos un paso más.
Qué cambia cuando el proyecto sale del banco
Nada de lo que sigue es un defecto de la placa. Son características de la arquitectura elegida: pedir la decisión a un servicio lejano. Cada una es un criterio para decidir si esta arquitectura sirve para tu caso.
Dependencia del enlace. La decisión solo ocurre si Internet está activo. Está bien para un proyecto de mesa. No sirve para un equipo que debe seguir funcionando cuando cae el operador; la decisión debe ser local.
Tiempo de respuesta. Sumando ida, procesamiento y vuelta, la respuesta tarda de cientos de milisegundos a algunos segundos. Si tu proceso lo tolera, perfecto. Si el ciclo de la máquina es más corto que la respuesta, la decisión llega tarde.
Costo por consulta. En la prueba es irrelevante. El número que importa es el de régimen: multiplícalo por dispositivo, ciclo, turno y mes. Haz esa cuenta pronto, durante el diseño.
La clave en el firmware. La clave de API queda grabada en la placa y el firmware puede extraerse de un dispositivo con acceso físico. En el banco quizá no importe; en un equipo instalado sí. No hay una forma realmente segura de guardar un secreto en un microcontrolador.
Adónde va el dato. Cada consulta envía información fuera de tu red. En un proyecto personal es irrelevante; en un entorno corporativo suele ser la primera pregunta, y no siempre es una discusión técnica.
Observa el patrón: ninguno de estos puntos trata del ESP32. Todos tratan de dónde se hace el cálculo.
El camino intermedio: el modelo en tu propia red
Entre “usar el de Internet” y “no usar nada” existe un tercer camino: ejecutar un modelo más pequeño dentro de tu propia red. Herramientas como Ollama descargan el modelo a una máquina tuya y lo ejecutan localmente.
Un punto importante, porque es la confusión más común: Ollama no funciona en el ESP32. Funciona en un PC, mini-servidor o gateway. El ESP32 sigue haciendo lo que hace bien: recopilar, medir y publicar.
Volviendo a la idea inicial: no es que nada quepa fuera del centro de datos. Los modelos grandes no caben. Un modelo más pequeño, elegido para una tarea concreta, funciona en una máquina común, sin Internet, cuota mensual ni datos fuera de su lugar.
Este cambio resuelve cuatro problemas anteriores: el enlace externo deja de importar, baja el tiempo de respuesta, desaparece el costo por consulta y el dato permanece en tu red. Cuatro de los cinco puntos de la sección anterior, mediante una decisión de arquitectura. Lo que queda es el hardware del gateway, una inversión única que es tuya.
Dónde brilla el ESP32 en esta arquitectura
Su papel no cambia y es precisamente el que ningún servidor hace bien:
1. Leer un sensor continuamente con temporización confiable. 2. Reaccionar de inmediato a lo crítico que no puede esperar una respuesta de red. 3. Publicar el dato —MQTT, HTTP o Modbus— para quien lo analice. 4. Permanecer activo durante meses, con bajo consumo, en un entorno hostil.
La inteligencia pesada vive en el gateway, en la misma red, a pocos milisegundos. El ESP32 entrega el dato y recibe la conclusión sin depender del mundo exterior.
También existe un cuarto camino: ejecutar un modelo dentro de la propia placa. Durante mucho tiempo eso significó solo un clasificador con TensorFlow Lite Micro, entrenado para una tarea y sin generar texto. Sigue siendo una opción excelente y económica para decisiones inmediatas. Pero el límite subió: hoy existe un modelo de lenguaje funcionando en ESP32-S3, con el paso a paso publicado, y la siguiente rectificación trata de eso.
Cómo elegir en la práctica
Prototipo, prueba de concepto o proyecto personal: API pública. Rápida de montar, barata durante las pruebas y educativa.
Equipo en campo con requisito de disponibilidad o privacidad: modelo local en el gateway y ESP32 recopilando.
Decisión inmediata que siempre responde a la misma pregunta: modelo pequeño integrado directamente en la placa.
En los tres casos el ESP32 hace lo mismo: es el extremo que ve el mundo real. Lo que cambia es dónde se hace el cálculo, y ahora puedes decidirlo conscientemente en vez de descubrirlo después de instalar el equipo.
Rectificación: un modelo de lenguaje dentro de la placa
Cuando se publicó este artículo, la idea dominante, incluida la nuestra, era que un “modelo de lenguaje en un microcontrolador” no existía: dentro de la placa cabía un clasificador y la generación de texto era asunto de servidores. Eso fue refutado en la práctica con hardware en el banco.
Un modelo de 28,9 millones de parámetros almacenados genera texto coherente dentro de un ESP32-S3 N16R8, sin Internet, gateway ni PC. De extremo a extremo alcanza aproximadamente 9,5 tokens por segundo (102,9 ms por paso del modelo).
El truco no es la fuerza bruta, sino la jerarquía de memoria. Los parámetros se dividen según la velocidad de cada memoria de la placa:
- núcleo denso de 559 KB (la parte que se ejecuta en cada paso) dentro del presupuesto de SRAM interna;
- cabeza de salida preparada como int8 en la PSRAM;
- tabla de 25 millones de parámetros mapeada directamente en la flash, consultada por token.
La medición en el silicio es el punto central: una línea aleatoria de 512 B en la flash cuesta 20,3 µs y las seis líneas por token suman aproximadamente 0,12 ms, cerca del 0,7 % del tiempo de memoria por token. La tabla gigante en flash es, por tanto, casi gratis. El costo dominante es la cabeza de salida, unos 17,3 ms por token, que cualquier modelo tendría.
Qué significa y qué no. No es ChatGPT dentro del ESP32 y nunca se convierte en eso. Es un modelo TinyStories de dominio restringido, coherente pero limitado; “28,9M de parámetros” cuenta parámetros almacenados gracias a la división de memoria, no multiplica la capacidad. El párrafo sobre modelos de frontera sigue siendo válido.
Lo que cambia es el mapa. La frontera de lo que funciona dentro de la placa ya no es solo “un clasificador para una tarea”. Incluye generación de lenguaje offline y de dominio cerrado, con decenas de milisegundos por token: sin enlace, sin costo por consulta, sin clave de API en el firmware y sin datos fuera de la red. Los cinco problemas de la sección “qué cambia cuando el proyecto sale del banco” desaparecen en esta arquitectura.
El paso a paso completo está en Un modelo de lenguaje funcionando en ESP32-S3: la trampa de la PSRAM, la jerarquía SRAM/PSRAM/flash y el producto escalar vectorizado de ESP-DSP en los dos núcleos.
Así que la pregunta inicial envejeció. Ya no es “¿se puede poner una IA dentro del ESP32?”. Es “¿qué modelo merece la pena integrar y cuánto de la decisión puede dejar de depender de Internet?”.
Continúa la conversación
Si trabajas con ESP32 en un entorno industrial o estás construyendo algo parecido, la comunidad intercambia experiencias sobre este tipo de decisiones de arquitectura.
Si lo que quieres no es consultar un modelo mediante una API, sino usar un asistente de IA para escribir el firmware que hace esa consulta, el flujo que funciona está en Usar un asistente de IA para programar ESP32.