esp32-eye: монитор кошачьей миски с водой, который дважды обращается к MiniCPM-V 4.7

Две платы ESP32-S3, один MacBook и две модели MiniCPM-V 4.7 разного размера теперь ведут журнал того, какая кошка пила из миски с водой и когда. Плата с камерой следит за миской, MacBook локально запускает небольшую модель, чтобы ответить на один узкий вопрос, а крупная модель вызывается только после того, как событие уже произошло. Проект называется esp32-eye, он находится на github.com/emwstudio/esp32-eye и стал публичным 25 октября 2026 года. OpenBMB продемонстрировала его в первую неделю ноября — именно так большинство людей и познакомилось с ним.

Модель, лежащая в основе, — это то, в чём стоит быть точным. OpenBMB загрузила MiniCPM-V 4.7 на Hugging Face 6 и 7 октября 2026 года, опубликовала карточку модели и лицензию Apache-2.0 12 октября, а 15 октября выпустила англоязычный пресс-релиз через PR Newswire. Так что это не история о запуске, и кошачий монитор — не вендорный бенчмарк. Это самое подробное публичное развёртывание модели, которое на сегодняшний день задокументировал кто-либо за пределами лаборатории, и, как оказалось, речь идёт о бытовом приборе.

Что на самом деле делает сборка

Оборудование намеренно дешёвое и слегка неуклюжее. Waveshare ESP32-S3-CAM-OV5640 закреплена на краю миски и передаёт по Wi-Fi JPEG-кадры 1024×768 вместе с аудио с микрофона. Вторая плата, Waveshare ESP32-S3-Touch-AMOLED-2.16, — это настольный дисплей: панель 480×480 показывает полосу живого видео, четыре карточки кошек, ежедневный счётчик относительно цели в восемь напитков и небольшую анимацию-акцент, когда кошка подтверждена. MacBook — это мозг. Сервер FastAPI принимает поток, выполняет логику обнаружения, пишет в SQLite и вырезает MP4-клип для каждого события с пятью секундами до, тремя секундами после и оригинальным аудио.

Размещение камеры — первое, что нужно понять, потому что оно объясняет всю конструкцию детектирования. Объектив смотрит снизу вверх на морду кошки с края миски, а значит, поверхность воды не попадает в кадр. Система не может видеть, как кошка пьёт. Она видит только кошку, находящуюся в зоне миски, а остальное выводит из продолжительности присутствия и идентичности. Всякий, кто делал проект с камерой, знает: обычно именно здесь честность и заканчивается; здесь же она вписана в README.

Перед запуском любой модели выполняется разностное сравнение в градациях серого с эталонным кадром пустой миски. Если доля переднего плана ниже 15 процентов, кадр отбрасывается без обращения к нейронной сети. Если выше 15 процентов, локальной MiniCPM-V 4.7 1B задаётся один вопрос: есть ли на этом изображении кошка? Положительный ответ вместе с долей переднего плана выше 35 процентов становится одним утвердительным голосом. Три утвердительных голоса подряд открывают событие; четыре отрицательных голоса подряд закрывают его.

Разделение на две модели — вот что интересно с инженерной точки зрения.

Запускать модель компьютерного зрения каждые 1,5 секунды и так до бесконечности — плохая идея, и сборка относится к ней именно так. {{1}}1B{{/1}} работает локально через {{2}}llama.cpp{{/2}} в виде квантования {{3}}Q4_K_M{{/3}} на {{4}}совместимом с OpenAI llama-server{{/4}} на порту {{5}}8080{{/5}}. Это достаточно дёшево, чтобы проект мог позволить себе вызывать её повторно, но по-прежнему срабатывает только при различии фона, так что пустая комната ничего не стоит. Задача {{6}}1B{{/6}} намеренно узкая: присутствие, а не идентичность и не поведение.

Идентификация — дорогостоящий вопрос, и он задаётся один раз за событие. Когда событие завершается, сервер извлекает кадры из клипа и отправляет их в MiniCPM-V 4.7 35B-A3B через облачный API ModelBest вместе с эталонной фотографией для каждой из четырёх кошек. Большая модель возвращает идентификатор кошки, значение уверенности и ответ «да/нет» о том, является ли сцена сценой питья. Кадры, не прошедшие проверку на питьё, отбрасываются и не учитываются. Неоднозначные идентичности сохраняются как неизвестные, а не принудительно привязываются к ближайшей кошке, и если вызов облака завершается неудачно, событие попадает в путь повторных попыток, а не заполняется догадкой 1B.

Такое разделение труда — тот же аргумент, который литература о вычислениях на устройстве приводит уже два года, только теперь с подтверждением. Маленькая модель — это датчик. Большая модель — это судья. Модель затрат следует напрямую: за 1B платят миллисекундами и батареей, за 35B платят токенами, а счёт за токены масштабируется с числом событий питья, а не с числом кадров. В доме с четырьмя кошками это несколько вызовов в день.

Что 89 событий доказывают, а что — нет

В публикации OpenBMB сообщается, что в доме с четырьмя кошками за три дня вручную проверили 89 случаев питья, и личность каждой кошки была определена правильно. Это реальный результат, но при этом узкий. Задача идентификации — это выбор одного из четырёх вариантов в закрытом наборе среди кошек, для которых у системы уже есть эталонные фотографии. Это не переидентификация в открытом наборе, это не утверждение о сотне кошек и не утверждение о том, что система работает в доме, который она никогда не видела.

Восемьдесят девять событий за три дня — это примерно тридцать в день на четыре кошки, или около семи с половиной на кошку в день, что правдоподобно для исследования потребления воды и слишком мало, чтобы с какой-либо уверенностью оценить частоту ошибок. Система, которая права 89 раз из 89, всё ещё может ошибаться один раз из пятидесяти. Цифра, за которую стоит держаться, — не 100 процентов; а то, что за три дня обычного использования её никому не пришлось исправлять.

Есть также оговорка об источнике. Автор — посол сообщества OpenBMB, и демонстрация проводилась в собственном аккаунте OpenBMB. Это не делает результат ложным, но означает, что проверку разрабатывал не скептик, и ни одна третья сторона её не повторила.

Почему 1B не идентифицирует кошку

В README есть самое полезное предложение всего проекта, и это отрицательный результат: с тремя похожими друг на друга светлоокрашенными кошками локальная MiniCPM-V 4.7 1B не справлялась надёжно с выбором одной из четырёх. Команда попробовала, обнаружила, что различение четырёх вариантов ненадёжно, и передала задачу идентификации модели на 35B, вместо того чтобы выдавать догадку.

На этом стоит задержаться, потому что это противоречит тому, как обычно продают небольшие визуальные модели. Модель с 1,55 млрд параметров, показывающая хорошие результаты на бенчмарках OCR и графиков, не обязательно хорошо отличает двух похожих животных друг от друга при фиксированном обзоре камеры. Тонкая идентификация — именно та задача, где сжатый бюджет визуальных токенов вредит: различия между двумя кошками табби малы, локальны и легко теряются при усреднении. Ответ, предложенный в этой сборке — использовать малую модель для простого вопроса и платить за сложный, — полезнее любой строки лидерборда.

Во сколько обходится эксплуатация и что происходит, когда облачный сегмент выходит из строя

Только один сегмент этого конвейера платный. 1B — это локальный GGUF-файл на ноутбуке, поэтому предельная стоимость одного кадра — это электричество. 35B — это вызов размещённого API ModelBest, то есть собственной конечной точки вендора, а не стороннего хоста, и для него проекту нужен ключ. В README прямо указано, что 35B не развёрнута локально: MacBook не хранит 35 миллиардов параметров, он хранит клиент.

Такое разделение создаёт режим отказа, который проект обрабатывает, а не скрывает. Если облачный вызов завершается неудачей, событие повторяется; результат 1B никогда не превращается в идентичность. Для любительского проекта это необычайно дисциплинированно. Для любого решения, похожего на продакшен, та же схема помещает единственную внешнюю конечную точку на критический путь системы, вся цель которой — записывать события без участия человека.

Это тот пробел, который закрывает роутер, и стоит точно понимать, что роутер здесь может, а чего не может. OrcaRouter даёт единый API более чем к 200 моделям с прайсовой ценой провайдера, передаваемой при нулевой наценке, плюс автоматическое переключение между апстримами при сбое — как раз то, что нужно для такого пайплайна. Правда, сейчас он не поддерживает MiniCPM-V 4.7, так что 35B-ветка в esp32-eye по-прежнему работала бы через собственный API вендора. Честная версия совета такова: оставьте путь повторных попыток, и если шаг идентификации станет критически важным, поставьте за тем же вызовом вторую модель, до которой вы действительно можете достучаться.

Что ещё не подтверждено

Три обстоятельства изменили бы то, насколько весомой заслуживает считаться эта сборка. Первое — второе домохозяйство. Все данные, о которых сообщалось до сих пор, получены из одного дома с четырьмя известными кошками и одной фиксированной камерой. Второе — более длительный прогон: три дня не позволяют отличить систему, которая работает, от системы, которая работает лишь до тех пор, пока кошка не сменит шерсть, не изменится освещение или не придёт гость. Третье — независимая проверка 89 событий, которая сейчас опирается только на ручную проверку самого автора сборки.

То, что уже установлено, скромнее и полезнее. MiniCPM-V 4.7 существует в двух размерах, которые можно комбинировать: плотная модель на 1,55B, работающая из файла Q4_K_M на ноутбуке, и разреженная смесь экспертов на 35,2B, которая активирует примерно 3 млрд параметров на токен и достаточно хорошо справляется с задачей идентификации четырёх сущностей, чтобы ей можно было это доверить. Кошачья миска — странное место, чтобы это доказать, но вполне реальное.

Если вы хотите воспроизвести это, в репозитории есть прошивка камеры, прошивка AMOLED, сервер FastAPI и тестовые скрипты модели, а единственная учётная запись, которая вам понадобится, — это ключ ModelBest для этапа идентификации. Если вы хотите изучить модель, а не запускать кота, лучше начать с показателей производителя, а оговорки приведены в репозитории.