esp32-eye : le moniteur de bol d'eau pour chat qui appelle MiniCPM-V 4.7 deux fois

Deux cartes ESP32-S3, un MacBook et deux tailles différentes de MiniCPM-V 4.7 tiennent désormais un journal indiquant quel chat a bu au bol d’eau et à quel moment. Une carte caméra surveille le bol, un MacBook exécute le petit modèle localement pour répondre à une question précise, et le grand modèle n’est appelé qu’une fois qu’un événement s’est déjà produit. Le projet s’appelle esp32-eye, il se trouve à l’adresse github.com/emwstudio/esp32-eye et il est devenu public le 25 octobre 2026. OpenBMB l’a présenté lors de la première semaine de novembre, ce qui a permis à la plupart des gens de le découvrir.

Le modèle sous-jacent est l’élément sur lequel il vaut la peine d’être précis. OpenBMB a téléversé MiniCPM-V 4.7 sur Hugging Face les 6 et 7 octobre 2026, publié la fiche du modèle et la licence Apache-2.0 le 12 octobre, et diffusé un communiqué de presse en anglais via PR Newswire le 15 octobre. Il ne s’agit donc pas d’un article sur un lancement, et le moniteur pour chat n’est pas un benchmark de fournisseur. C’est le déploiement public le plus détaillé du modèle que quiconque hors du laboratoire ait documenté à ce jour, et il se trouve que c’est un appareil électroménager.

Ce que le build fait réellement

Le matériel est délibérément bon marché et un peu bancal. Un Waveshare ESP32-S3-CAM-OV5640 est posé sur le rebord du bol et diffuse via Wi-Fi des images JPEG en 1024×768 ainsi que l’audio du microphone. Une deuxième carte, une Waveshare ESP32-S3-Touch-AMOLED-2.16, sert d’écran de bureau : un panneau 480×480 affichant un bandeau vidéo en direct, quatre fiches de chats, un décompte quotidien par rapport à un objectif de huit boissons, et une petite animation de mise en surbrillance lorsqu’un chat est confirmé. Le MacBook est le cerveau. Un serveur FastAPI reçoit le flux, exécute la logique de détection, écrit dans SQLite et découpe un clip MP4 pour chaque événement avec cinq secondes de pré-roll, trois secondes de post-roll et l’audio d’origine.

L'emplacement de la caméra est la première chose à comprendre, car il explique toute la conception de la détection. L'objectif regarde vers le haut, vers le visage du chat, depuis le bord du bol, ce qui signifie que la surface de l'eau n'est pas dans le champ. Le système ne peut pas voir un chat en train de boire. Il peut seulement voir un chat occuper la zone du bol et déduit le reste de la persistance et de l'identité. Quiconque a déjà réalisé un projet de caméra sait que c'est là que l'honnêteté quitte généralement la pièce ; ici, elle est écrite dans le README.

Le pipeline, avant l’exécution de tout modèle, consiste en une différence de fond en niveaux de gris par rapport à une image de référence de bol vide. Si la proportion de premier plan est inférieure à 15 pour cent, l’image est écartée sans solliciter de réseau neuronal. Au-dessus de 15 pour cent, on pose une question au MiniCPM-V 4.7 1B local : y a-t-il un chat dans cette image ? Une réponse positive accompagnée d’une proportion de premier plan supérieure à 35 pour cent constitue un vote affirmatif. Trois votes affirmatifs consécutifs ouvrent un événement ; quatre votes négatifs consécutifs le ferment.

La séparation en deux modèles constitue l’aspect technique intéressant.

Faire tourner un modèle de vision toutes les 1,5 secondes indéfiniment est une mauvaise idée, et le build le traite comme telle. Le 1B tourne localement via llama.cpp sous forme de quantification Q4_K_M sur un llama-server compatible OpenAI sur le port 8080. Il est suffisamment peu coûteux pour que le projet puisse se permettre de l’appeler à répétition, mais il est toujours conditionné par la différence d’arrière-plan, de sorte qu’une pièce vide ne coûte rien. La tâche du 1B est délibérément étroite : la présence, pas l’identité, pas le comportement.

L’identité est la question coûteuse, et elle n’est posée qu’une fois par événement. Lorsqu’un événement se termine, le serveur échantillonne des images de la séquence et les envoie à MiniCPM-V 4.7 35B-A3B via l’API cloud de ModelBest, avec une photo de référence pour chacun des quatre chats. Le grand modèle renvoie un identifiant de chat, une valeur de confiance et une réponse oui/non indiquant si la scène montre un chat en train de boire. Les images qui ne passent pas le contrôle de boisson sont jetées et ne sont pas comptées. Les identités ambiguës sont stockées comme inconnues plutôt que forcées sur le chat le plus proche, et si l’appel au cloud échoue, l’événement passe par un chemin de nouvelle tentative au lieu d’être complété par la supposition du 1B.

Cette division du travail est le même argument que la littérature sur l’embarqué défend depuis deux ans, désormais avec une preuve à l’appui. Un petit modèle est un capteur. Un grand modèle est un juge. Le modèle de coût en découle directement : le 1B se paie en millisecondes et en batterie, le 35B se paie en tokens, et la facture en tokens évolue avec le nombre d’épisodes de boisson plutôt qu’avec le nombre d’images. Dans un foyer avec quatre chats, cela représente une poignée d’appels par jour.

Ce que les 89 événements prouvent et ne prouvent pas

Le post d'OpenBMB rapporte que, dans un foyer de quatre chats sur trois jours, 89 épisodes de boisson ont été vérifiés manuellement et que l'identité de chaque chat était correcte. C'est un résultat réel, et il est aussi limité. La tâche d'identification est un choix à quatre options en ensemble fermé parmi des chats pour lesquels le système dispose déjà de photos de référence. Il ne s'agit pas d'une réidentification en ensemble ouvert, ni d'une affirmation concernant une centaine de chats, ni d'une affirmation que le système fonctionne dans une maison qu'il n'a jamais vue.

Quatre-vingt-neuf événements sur trois jours représentent environ trente par jour pour quatre chats, soit environ sept et demi par chat et par jour, ce qui est plausible pour une étude sur la consommation d’eau et bien trop peu pour estimer un taux d’erreur avec un quelconque degré de confiance. Un système qui a raison 89 fois sur 89 pourrait encore se tromper une fois sur cinquante. Le chiffre à retenir n’est pas 100 pour cent ; c’est que personne n’a eu à le corriger en trois jours d’utilisation ordinaire.

Il y a aussi une réserve sur la provenance. L’auteur est un ambassadeur de la communauté OpenBMB et la démonstration a été diffusée sur le compte d’OpenBMB lui-même. Cela ne rend pas le résultat faux, mais cela signifie que la validation n’a pas été conçue par un sceptique, et qu’aucun tiers ne l’a reproduite.

Pourquoi le 1B n’identifie pas le chat

Le README contient la phrase la plus utile de tout le projet, et c’est un résultat négatif : avec trois chats de couleur claire qui se ressemblent, le MiniCPM-V 4.7 1B local n’était pas fiable pour désigner l’un des quatre. L’équipe l’a essayé, a jugé la discrimination à quatre voies peu fiable et a confié l’identification au 35B plutôt que de livrer une supposition.

Cela vaut la peine de s’y attarder, car cela va à l’encontre de la manière dont les petits modèles de vision sont habituellement vendus. Un modèle de 1,55 milliard de paramètres qui obtient de bons résultats sur l’OCR et les benchmarks de graphiques n’est pas automatiquement capable de distinguer deux animaux similaires dans une vue de caméra fixe. L’identité fine est exactement le type de tâche où un budget compressé de tokens visuels nuit : les différences entre deux chats tigrés sont petites, locales et faciles à moyenner jusqu’à les effacer. La réponse de cette réalisation — utiliser le petit modèle pour la question facile et payer pour la difficile — est plus utile que n’importe quelle ligne de classement.

Ce que coûte son exploitation, et ce qui se passe lorsque la liaison cloud tombe en panne

Une seule branche de ce pipeline génère une facture. Le 1B est un fichier GGUF local sur un ordinateur portable, si bien que le coût marginal d'une image est l'électricité. Le 35B est un appel hébergé vers l'API de ModelBest, qui est le point de terminaison propre du fournisseur plutôt qu'un hôte tiers, et le projet a besoin d'une clé pour cela. Le README indique explicitement que le 35B n'est pas déployé localement : le MacBook ne contient pas 35 milliards de paramètres, il contient un client.

Cette séparation crée un mode de défaillance que le projet gère plutôt qu’il ne le cache. Si l’appel au cloud échoue, l’événement est réessayé ; le résultat 1B n’est jamais promu au rang d’identité. Pour un projet de loisir, c’est d’une discipline inhabituelle. Pour tout ce qui a la forme d’un système de production, la même conception place un point de terminaison externe unique sur le chemin critique d’un système dont toute la raison d’être est d’enregistrer des événements sans surveillance.

C'est là le vide que comble un routeur, et il vaut la peine d'être précis sur ce qu'un routeur peut et ne peut pas faire ici. OrcaRouter offre une API unique pour plus de 200 modèles, avec le prix catalogue du fournisseur répercuté à 0 % de marge, ainsi qu'un basculement automatique entre les fournisseurs en amont, ce qui correspond exactement à ce qu'il faut pour un pipeline comme celui-ci. Il ne prend pas encore en charge MiniCPM-V 4.7, donc le segment 35B dans esp32-eye continuerait de tourner sur l'API du fournisseur lui-même. La version honnête du conseil est la suivante : conservez le chemin de nouvelle tentative, et si l'étape d'identification devient critique, placez derrière le même appel un second modèle que vous pouvez réellement joindre.

Qu'est-ce qui reste non confirmé ?

Trois éléments changeraient le crédit à accorder à cette réalisation. Le premier est un second foyer. Tout ce qui a été rapporté jusqu’ici provient d’un seul domicile, avec quatre chats connus et une caméra fixe. Le deuxième est une durée d’essai plus longue : trois jours ne permettent pas de distinguer un système qui fonctionne d’un système qui fonctionne jusqu’à ce qu’un chat change de pelage, que la lumière change ou qu’un visiteur arrive. Le troisième est une vérification indépendante des 89 événements, qui repose actuellement sur l’examen manuel réalisé par le concepteur.

Ce qui est déjà établi est plus modeste et plus utile. MiniCPM-V 4.7 existe en deux tailles combinables : un modèle dense de 1,55 milliard de paramètres qui s’exécute à partir d’un fichier Q4_K_M sur un ordinateur portable, et un mélange d’experts creux de 35,2 milliards de paramètres qui active environ 3 milliards de paramètres par token et est suffisamment performant sur une tâche d’identification à quatre possibilités pour qu’on lui fasse confiance pour cela. Un bol pour chat est un endroit étrange pour le prouver, mais c’est un endroit bien réel.

Si vous souhaitez le reproduire, le dépôt contient le firmware de la caméra, le firmware AMOLED, le serveur FastAPI et les scripts de test du modèle, et le seul compte dont vous avez besoin est une clé ModelBest pour le volet identité. Si vous souhaitez lire le modèle plutôt que de faire tourner le chat, les chiffres du fournisseur sont le point de départ et les mises en garde figurent dans le dépôt.