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 次飲水事件，每隻貓的身分都正確。這是一個真實的結果，但也是一個範圍狹窄的結果。身分判定任務是在系統已有參考照片的貓咪之間，進行封閉集合的四選一。它不是開放集重識別，不是關於一百隻貓的主張，也不是主張該系統能在它從未見過的房子裡運作。

三天內八十九次事件，對四隻貓來說大約是每天三十次，也就是每隻貓每天約七點五次；這對飲水量研究而言是合理的，但要用來有把握地估計錯誤率則遠遠太小。一個在八十九次中正確八十九次的系統，仍可能每五十次錯一次。要記住的數字不是百分之百；而是在三天的日常使用中，沒有人需要去糾正它。

另外還有一點關於來源的提醒。作者是 OpenBMB 社群大使，而這次展示是在 OpenBMB 自家的帳號上進行的。這並不代表結果是假的，但確實意味著這項驗證並非由抱持懷疑態度的人所設計，而且也沒有任何第三方重複驗證過。

為什麼 1B 無法辨識這隻貓

README 裡有整個專案中最有用的一句話，而那是一個負面結果：面對三隻長相相似的淺色貓，本地的 MiniCPM-V 4.7 1B 在四選一中並不可靠。團隊試過之後，發現四選一的區辨並不可靠，於是改由 35B 負責辨識身分，而不是把一個猜測直接上線。

值得深入思考，因為這與小型視覺模型通常的推銷方式相悖。一個在 OCR 與圖表基準測試中表現良好的 15.5 億參數模型，並不代表它自然擅長在固定攝影機視野中分辨兩隻相似的動物。細粒度身分辨識正是壓縮視覺 token 預算會造成傷害的那類任務：兩隻虎斑貓之間的差異細微、局部，且很容易在平均化過程中被抹平。這個 build 的解法——用小型模型處理簡單問題，並為困難問題付出更高成本——比任何排行榜上的名次都更有用。

運行成本是多少，以及雲端環節故障時會發生什麼事

這條管線只有其中一段需要付費。1B 是筆電上的本機 GGUF 檔案，因此每幀的邊際成本就是電費。35B 是對 ModelBest API 的託管式呼叫，這是廠商自家的端點，而非第三方主機，而且專案需要為此取得金鑰。README 明確指出 35B 並未在本機部署：MacBook 並不持有 350 億個參數，它持有的是用戶端。

這種拆分會產生一種失敗模式，而專案會處理它，而不是把它藏起來。若雲端呼叫失敗，事件會重試；1B 結果永遠不會被提升為身分。對一個興趣專案來說，這異常自律。對任何具備生產形態的系統而言，同樣的設計卻把單一外部端點放上系統的關鍵路徑，而這個系統的全部目的正是無人值守地記錄事件。

這正是路由器所填補的缺口，而值得精確說明路由器在這裡能做什麼、不能做什麼。OrcaRouter 以單一 API 涵蓋超過 200 個模型，並以供應商定價原價傳遞、加價 0%，再加上上游之間的自動容錯切換，這正是這類管線該有的架構。它目前並未支援 MiniCPM-V 4.7，因此 esp32-eye 中 35B 的那一段仍會跑在廠商自家的 API 上。誠實的建議是：保留重試路徑，而若身分驗證這一步變得舉足輕重，就在同一個呼叫後面放一個你實際能觸及的第二個模型。

還有什麼仍未確認

有三件事會改變這套建置值得多少重視。第一是第二個家戶。目前為止所報告的一切，都來自一個有四隻已知貓和固定式攝影機的家庭。第二是更長時間的運行：三天無法區分一套有效的系統，和一套只在貓換了毛色、光線變化或訪客到來之前才有效的系統。第三是對這 89 個事件的獨立檢查，而這目前依賴建置者自己的手動審查。

已經確立的事更為樸實，也更有用。MiniCPM-V 4.7 以兩種可組合的規模存在：一種是 1.55B 的稠密模型，可在筆電上以 Q4_K_M 檔案執行；另一種是 35.2B 的稀疏混合專家模型，每個 token 約啟用 30 億個參數，而且在四選一身分識別任務上夠可靠，足以放心交給它處理。用貓碗來證明這件事很奇特，但這是真實的案例。

如果你想重現它，儲存庫裡有相機韌體、AMOLED 韌體、FastAPI 伺服器和模型測試腳本，而你唯一需要的帳號，是供身分驗證環節使用的 ModelBest 金鑰。如果你想閱讀模型而不是實際跑那隻貓，廠商提供的數字是很好的起點，注意事項則在儲存庫裡。