esp32-eye：会两次调用 MiniCPM-V 4.7 的猫咪水碗监测器

两块 ESP32-S3 开发板、一台 MacBook，以及两种不同尺寸的 MiniCPM-V 4.7，如今会记录哪只猫在什么时候喝了水碗里的水。一块摄像头板负责盯着水碗，一台 MacBook 在本地运行小模型来回答一个范围很窄的问题，而大模型只在事件已经发生后才被调用。这个项目名为 esp32-eye，仓库位于 github.com/emwstudio/esp32-eye，并于 2026 年 10 月 25 日公开。OpenBMB 在 11 月第一周展示了它，大多数人就是这样认识它的。

真正值得精确说明的是底层模型。OpenBMB 于 2026 年 10 月 6 日和 7 日将 MiniCPM-V 4.7 上传至 Hugging Face，于 10 月 12 日发布了模型卡和 Apache-2.0 许可证，并于 10 月 15 日通过 PR Newswire 发布了一份英文新闻稿。因此，这不是一篇新品发布报道，猫咪监控器也不是厂商基准测试。这是迄今为止实验室之外的人所记录过的、该模型最详细的公开部署，而它恰好是一件家用电器。

构建实际做了什么

这套硬件刻意采用廉价且略显笨拙的方案。一块 Waveshare ESP32-S3-CAM-OV5640 安装在猫碗边缘，通过 Wi-Fi 传输 1024×768 的 JPEG 帧以及麦克风音频。第二块板子是 Waveshare ESP32-S3-Touch-AMOLED-2.16，用作桌面显示器：一块 480×480 面板，显示实时视频条、四张猫咪卡片、对比每日八杯目标的当日计数，以及确认某只猫时的一小段高亮动画。MacBook 则是大脑。一个 FastAPI 服务器接收视频流，运行检测逻辑，写入 SQLite，并为每个事件剪出一段 MP4 片段，包含五秒前置、三秒后置以及原始音频。

摄像头的位置是首先要理解的，因为它解释了整个检测设计。镜头从碗沿向上看猫的脸，这意味着水面不在画面中。系统看不到猫在喝水。它只能看到猫占据碗所在区域，并根据持续性和身份推断其余部分。任何做过摄像头项目的人都知道，通常正是在这里，坦诚就不见了；而在这里，它被写进了 README。

在任何模型运行之前，流水线会先针对空碗参考帧做灰度背景差分。如果前景占比低于 15%，该帧会被直接丢弃，不会触及任何神经网络。高于 15% 时，本地的 MiniCPM-V 4.7 1B 会被问一个问题：这张图里有猫吗？肯定回答，加上前景占比高于 35%，构成一张赞成票。连续三张赞成票会开启一个事件；连续四张反对票则会将其关闭。

双模型拆分才是有趣的工程设计

每 1.5 秒不停地跑一次视觉模型是个糟糕的主意，而这个构建也正是这么对待它的。这个 1B 模型通过 llama.cpp 在本地运行，以 Q4_K_M 量化的形式跑在 8080 端口上兼容 OpenAI 接口的 llama-server 中。它的开销足够低，项目负担得起反复调用，但它仍然受背景差异的门控，因此空房间不会产生任何开销。这个 1B 模型的职责被刻意限定得很窄：判断有无，而非身份，也非行为。

身份识别是一个代价高昂的问题，而且每个事件只询问一次。当事件结束时，服务器会从片段中采样帧，并通过 ModelBest 的云 API 将它们发送给 MiniCPM-V 4.7 35B-A3B，同时为四只猫中的每一只附带一张参考照片。大模型会返回猫的标识符、置信度值，以及该场景是否为饮水场景的“是/否”结果。未通过饮水检查的帧会被丢弃，并且不计入。模糊的身份会被存储为未知，而不是强行归到最接近的猫；如果云端调用失败，事件会进入重试路径，而不是用 1B 的猜测来回填。

这种分工与端侧文献两年来一直在提的论点相同，如今还附上了账单。小模型是传感器。大模型是裁判。成本模型由此直接得出：1B 的代价是毫秒和电池，35B 的代价是 token，而 token 账单随饮水事件的数量增长，而不是随帧数增长。在养四只猫的家庭里，这不过是每天几次调用。

这89起事件能证明什么、不能证明什么

OpenBMB 的帖子报告称，在一个养了四只猫的家庭中，连续三天人工核查了 89 次饮水事件，每一只猫的身份都识别正确。这是一个真实的结果，也是一个范围很窄的结果。身份识别任务是在系统已经有参考照片的猫之间进行的封闭集四选一。它不是开放集重识别，也不是关于一百只猫的说法，更不是声称系统能在它从未见过的房子里工作。

三天内八十九次事件，对四只猫来说大约是每天三十次，也就是每只猫每天约七次半，这对饮水摄入研究来说说得通，但也太小，无法有把握地估计错误率。一个89次全对的系统仍可能每五十次错一次。要记住的数字不是100%；而是在三天的日常使用中，没有人不得不纠正它。

关于来源还有一个需要提醒的地方。作者是 OpenBMB 社区大使，而且这次展示是在 OpenBMB 自己的账号上进行的。这并不意味着结果是假的，但这确实意味着验证并非由怀疑者设计，也没有第三方复现过。

为什么 1B 无法识别这只猫

README 里包含着整个项目中最有用的一句话，而它是一个负面结果：面对三只长相相似的浅色猫，本地运行的 MiniCPM-V 4.7 1B 无法可靠地从四只中挑出正确的那一只。团队试过之后，发现这种四选一的区分并不可靠，于是把身份识别交给 35B 模型，而不是硬着头皮给出一个猜测。

这值得细细琢磨，因为它与小型视觉模型通常的宣传方式相悖。一个拥有 15.5 亿参数的模型即便在 OCR 和图表基准测试中得分很高，也并不意味着它能在固定摄像头视角下自动分辨两只相似的动物。细粒度身份识别恰恰是压缩视觉 token 预算会吃亏的那类任务：两只虎斑猫之间的差异细微、局部化，而且很容易在平均化过程中被抹掉。这一构建方案的答案——用小型模型处理简单问题，为困难问题付出更高成本——比任何排行榜上的名次都更有用。

运行成本是多少，以及云链路发生故障时会发生什么

这条流水线只有一个环节需要付费。1B 是笔记本电脑上的本地 GGUF 文件，因此一帧的边际成本就是电费。35B 是对 ModelBest 的 API 发起的托管调用，而该 API 是厂商自己的端点，不是第三方主机，项目需要为其准备一个密钥。README 明确说明，35B 并未在本地部署：MacBook 并不承载 350 亿参数，它承载的是一个客户端。

这种分离制造出一种失败模式，而项目选择去处理它，而不是把它藏起来。如果云端调用失败，事件会被重试；1B 的结果永远不会被提升为身份。对于一个业余项目来说，这自律得不同寻常。而对于任何生产形态的东西，同样的设计把单一外部端点放在了系统的关键路径上——而这个系统的全部目的，恰恰是无人值守地记录事件。

这正是路由器所填补的空白，也值得准确说明路由器在这里能做什么、不能做什么。OrcaRouter 通过一个 API 覆盖 200 多个模型，将提供商列表价格按 0% 加价透传，并支持上游之间的自动故障转移，这对这样的流水线来说是合适的形态。它目前不提供 MiniCPM-V 4.7，因此 esp32-eye 中的 35B 环节仍会运行在供应商自己的 API 上。诚实的建议是：保留重试路径；如果身份识别步骤变得关键，就把一个你实际能访问到的第二模型接到同一个调用后面。

仍未确认的是什么？

有三件事会改变这个构建应得到多少重视。第一是第二户人家。到目前为止报告的所有内容都来自一个家庭，其中有四只已知的猫和一台固定摄像头。第二是更长时间的运行：三天无法区分一个真正有效的系统，和一个只在猫换毛、光线变化或访客到来之前才有效的系统。第三是对这 89 个事件的独立核查，目前这仅依赖于构建者自己的人工复核。

已经确立的东西更为 modest，也更有用。MiniCPM-V 4.7 有两个可以组合的规模：一个 1.55B 的稠密模型，能在笔记本电脑上以 Q4_K_M 文件运行；还有一个 35.2B 的稀疏混合专家模型，每个 token 大约激活 30 亿参数，在一个四分类身份任务上表现足够好，足以让人放心托付给它。猫碗是个奇怪的证明场所，但它确实是一个真实的场所。

如果你想复现它，仓库里有摄像头固件、AMOLED 固件、FastAPI 服务器和模型测试脚本，你唯一需要的账号是一个用于身份验证环节的 ModelBest 密钥。如果你想阅读模型而不是运行这只猫，厂商给出的数字是起步之处，而注意事项都在仓库里。