esp32-eye: El monitor del cuenco de agua para gatos que llama a MiniCPM-V 4.7 dos veces

Dos placas ESP32-S3, un MacBook y dos tamaños diferentes de MiniCPM-V 4.7 ahora llevan un registro de qué gato bebió del cuenco de agua y cuándo. Una placa con cámara vigila el cuenco, un MacBook ejecuta el modelo pequeño localmente para responder a una única pregunta concreta, y al modelo grande solo se recurre después de que ya ha ocurrido un evento. El montaje se llama esp32-eye, está en github.com/emwstudio/esp32-eye y se hizo público el 25 de octubre de 2026. OpenBMB lo presentó en la primera semana de noviembre, que es como la mayoría de la gente lo conoció.

El modelo subyacente es la parte que merece precisión. OpenBMB subió MiniCPM-V 4.7 a Hugging Face el 6 y 7 de octubre de 2026, publicó la tarjeta del modelo y la licencia Apache-2.0 el 12 de octubre, y emitió un comunicado de prensa en inglés a través de PR Newswire el 15 de octubre. Así que no se trata de una historia de lanzamiento, y el monitor para gatos no es un benchmark del proveedor. Es el despliegue público más detallado del modelo que alguien fuera del laboratorio haya documentado hasta ahora, y resulta que es un electrodoméstico.

Lo que realmente hace la compilación

El hardware es deliberadamente barato y ligeramente incómodo. Un Waveshare ESP32-S3-CAM-OV5640 se sitúa en el borde del cuenco y transmite por Wi-Fi fotogramas JPEG de 1024×768 junto con audio del micrófono. Una segunda placa, una Waveshare ESP32-S3-Touch-AMOLED-2.16, es la pantalla de escritorio: un panel de 480×480 que muestra una tira de vídeo en directo, cuatro tarjetas de gatos, un recuento diario frente a un objetivo de ocho bebidas y una pequeña animación de resaltado cuando se confirma un gato. El MacBook es el cerebro. Un servidor FastAPI recibe la transmisión, ejecuta la lógica de detección, escribe en SQLite y corta un clip MP4 por cada evento con cinco segundos de entrada, tres segundos de salida y el audio original.

La ubicación de la cámara es lo primero que hay que entender, porque explica todo el diseño de detección. La lente mira hacia la cara del gato desde el borde del cuenco, lo que significa que la superficie del agua no está en el encuadre. El sistema no puede ver a un gato bebiendo. Solo puede ver a un gato ocupando la zona del cuenco, e infiere el resto a partir de la persistencia y la identidad. Cualquiera que haya creado un proyecto de cámara sabe que aquí es donde la honestidad suele abandonar la sala; en este caso, está escrita en el README.

El proceso previo a la ejecución de cualquier modelo es una diferencia de fondo en escala de grises respecto a un fotograma de referencia de cuenco vacío. Si la proporción de primer plano es inferior al 15 por ciento, el fotograma se descarta sin llegar a usar una red neuronal. Por encima del 15 por ciento, se le hace una pregunta al MiniCPM-V 4.7 1B local: ¿hay un gato en esta imagen? Una respuesta positiva junto con una proporción de primer plano superior al 35 por ciento se convierte en un voto afirmativo. Tres votos afirmativos consecutivos abren un evento; cuatro votos negativos consecutivos lo cierran.

La separación en dos modelos es lo interesante de la ingeniería.

Ejecutar un modelo de visión cada 1,5 segundos para siempre es una mala idea, y la compilación lo trata como tal. El 1B se ejecuta localmente a través de llama.cpp como una cuantización Q4_K_M en un llama-server compatible con OpenAI en el puerto 8080. Es lo suficientemente barato como para que el proyecto pueda permitirse llamarlo repetidamente, pero sigue estando condicionado por la diferencia de fondo para que una sala vacía no cueste nada. La tarea del 1B es deliberadamente limitada: presencia, no identidad, no comportamiento.

La identidad es la pregunta costosa, y se plantea una vez por evento. Cuando se cierra un evento, el servidor muestrea fotogramas del clip y los envía a {{1}}MiniCPM-V 4.7 35B-A3B{{/1}} a través de {{2}}la API en la nube de ModelBest{{/2}}, con una foto de referencia para cada uno de los cuatro gatos. El modelo grande devuelve un {{3}}identificador de gato{{/3}}, un {{4}}valor de confianza{{/4}} y un {{5}}sí/no sobre si la escena es una escena de bebida{{/5}}. Los fotogramas que no superan la comprobación de bebida se descartan y no se cuentan. Las identidades ambiguas se almacenan como {{6}}desconocidas{{/6}} en lugar de forzarlas al gato más cercano, y si la llamada a la nube falla, el evento pasa a una {{7}}ruta de reintento{{/7}} en lugar de rellenarse con la suposición del 1B.

Esa división del trabajo es el mismo argumento que la literatura sobre el procesamiento en el dispositivo lleva dos años defendiendo, ahora con una prueba concreta. Un modelo pequeño es un sensor. Un modelo grande es un juez. El modelo de costes se deduce directamente: el 1B se paga en milisegundos y batería; el 35B se paga en tokens, y la factura de tokens escala con el número de eventos de ingesta de agua, no con el número de fotogramas. En una casa con cuatro gatos, eso son un puñado de llamadas al día.

Qué prueban y qué no prueban los 89 eventos

La publicación de OpenBMB informa que, en un hogar con cuatro gatos durante tres días, se verificaron manualmente 89 eventos de bebida y la identidad de cada gato fue correcta. Es un resultado real y también limitado. La tarea de identificación es una elección de cuatro opciones con conjunto cerrado entre gatos para los que el sistema ya tiene fotos de referencia. No es una reidentificación de conjunto abierto, no es una afirmación sobre cien gatos y no es una afirmación de que el sistema funcione en una casa que nunca ha visto.

Ochenta y nueve eventos en tres días son aproximadamente treinta al día para cuatro gatos, o alrededor de siete y medio por gato por día, lo cual es plausible para un estudio de ingesta de agua y demasiado pequeño para estimar una tasa de error con confianza. Un sistema que acierta 89 veces de 89 aún podría equivocarse una vez de cada cincuenta. La cifra que hay que retener no es el 100 por ciento; es que nadie tuvo que corregirlo en tres días de uso normal.

También hay una salvedad sobre la procedencia. El autor es embajador de la comunidad de OpenBMB y la demostración se ejecutó en la propia cuenta de OpenBMB. Eso no hace que el resultado sea falso, pero sí significa que la validación no fue diseñada por un escéptico, y ningún tercero la ha repetido.

¿Por qué el 1B no identifica al gato?

El README contiene la frase más útil de todo el proyecto, y es un resultado negativo: con tres gatos de colores claros que se parecen entre sí, el MiniCPM-V 4.7 1B local no era fiable a la hora de elegir uno de cada cuatro. El equipo lo probó, comprobó que la discriminación entre cuatro opciones no era fiable y trasladó la identidad al 35B en lugar de publicar una conjetura.

Vale la pena detenerse en esto porque va en contra de cómo se suelen vender los modelos de visión pequeños. Un modelo de 1550 millones de parámetros que obtiene buenos resultados en OCR y en pruebas de referencia de gráficos no es automáticamente bueno para distinguir dos animales similares en una vista fija de cámara. La identidad de grano fino es justo el tipo de tarea en la que un presupuesto comprimido de tokens visuales perjudica: las diferencias entre dos gatos atigrados son pequeñas, locales y fáciles de diluir al promediar. La respuesta de esta versión —usar el modelo pequeño para la pregunta fácil y pagar por la difícil— es más útil que cualquier fila de una tabla de clasificación.

Cuánto cuesta ejecutarlo y qué ocurre cuando falla el tramo en la nube

Solo una de las partes de este flujo tiene un coste. El 1B es un archivo GGUF local en un portátil, así que el coste marginal de un fotograma es la electricidad. El 35B es una llamada alojada contra la API de ModelBest, que es el endpoint propio del proveedor en lugar de un host de terceros, y el proyecto necesita una clave para ello. El README deja claro que el 35B no se despliega localmente: el MacBook no contiene 35 mil millones de parámetros, contiene un cliente.

Esa separación crea un modo de fallo que el proyecto gestiona en lugar de ocultar. Si falla la llamada a la nube, el evento se reintenta; el resultado de 1B nunca se promociona a una identidad. Para un proyecto de hobby, eso es inusualmente disciplinado. Para cualquier cosa con forma de producción, el mismo diseño pone un único endpoint externo en la ruta crítica de un sistema cuyo único propósito es registrar eventos sin supervisión.

Esta es la brecha que cubre un router, y merece la pena ser precisos sobre lo que un router puede y no puede hacer aquí. OrcaRouter ofrece una única API para más de 200 modelos con el precio de lista del proveedor repercutido con un 0 % de margen, además de failover automático entre proveedores upstream, que es la forma adecuada para un pipeline como este. Actualmente no incluye MiniCPM-V 4.7, así que el tramo de 35B en esp32-eye seguiría ejecutándose en la API propia del proveedor. La versión honesta del consejo es: mantén la ruta de reintento y, si el paso de identidad se vuelve crítico, pon un segundo modelo al que realmente puedas acceder detrás de la misma llamada.

¿Qué sigue sin confirmarse?

Tres cosas cambiarían el peso que merece esta versión. La primera es un segundo hogar. Todo lo reportado hasta ahora proviene de una sola casa con cuatro gatos conocidos y una cámara fija. La segunda es una ejecución más prolongada: tres días no pueden distinguir un sistema que funciona de un sistema que funciona hasta que un gato cambia de pelaje, cambia la iluminación o llega una visita. La tercera es una verificación independiente de los 89 eventos, que actualmente se basa en la revisión manual del propio creador.

Lo que ya está establecido es más modesto y más útil. MiniCPM-V 4.7 existe en dos tamaños que se pueden componer: un modelo denso de 1,55B que se ejecuta en un archivo Q4_K_M en una laptop, y un mixto de expertos disperso de 35,2B que activa aproximadamente 3 mil millones de parámetros por token y es lo suficientemente bueno en una tarea de identidad de cuatro vías como para confiarle esa tarea. Un cuenco de gato es un lugar extraño para demostrarlo, pero es un lugar real.

Si quieres reproducirlo, el repositorio contiene el firmware de la cámara, el firmware del AMOLED, el servidor FastAPI y los scripts de prueba del modelo, y la única cuenta que necesitas es una clave de ModelBest para la parte de identidad. Si prefieres leer el modelo en lugar de ejecutar al gato, los números del proveedor son el punto de partida y las advertencias están en el repositorio.