esp32-eye: Monitor miski z wodą dla kota, który dwukrotnie wywołuje MiniCPM-V 4.7

{{1}}Dwie płytki ESP32-S3{{/1}}, {{2}}jeden MacBook{{/2}} i {{3}}dwa różne rozmiary MiniCPM-V 4.7{{/3}} prowadzą teraz dziennik, który kot pił z miski z wodą i kiedy. Płytka z kamerą obserwuje miskę, MacBook uruchamia mały model lokalnie, aby odpowiedzieć na jedno wąskie pytanie, a duży model jest wywoływany dopiero po tym, jak zdarzenie już nastąpiło. Projekt nosi nazwę esp32-eye, znajduje się pod adresem github.com/emwstudio/esp32-eye i został udostępniony publicznie 25 października 2026 r. OpenBMB zaprezentowało go w pierwszym tygodniu listopada, i tak większość ludzi się z nim zetknęła.

Model, który się pod tym kryje, to część, co do której warto zachować precyzję. OpenBMB przesłało MiniCPM-V 4.7 do Hugging Face 6 i 7 października 2026 r., opublikowało kartę modelu i licencję Apache-2.0 12 października, a 15 października wydało angielski komunikat prasowy za pośrednictwem PR Newswire. To nie jest więc historia premiery, a koci monitor nie jest benchmarkiem dostawcy. To najbardziej szczegółowe publiczne wdrożenie tego modelu, jakie ktokolwiek spoza laboratorium dotychczas udokumentował, i przypadkiem jest to urządzenie gospodarstwa domowego.

Co tak naprawdę robi kompilacja

Sprzęt jest celowo tani i nieco nieporęczny. Waveshare ESP32-S3-CAM-OV5640 stoi na krawędzi miski i przesyła przez Wi-Fi klatki JPEG 1024×768 oraz dźwięk z mikrofonu. Druga płytka, Waveshare ESP32-S3-Touch-AMOLED-2.16, to wyświetlacz biurkowy: panel 480×480 pokazujący pasek wideo na żywo, cztery karty kotów, dzienny licznik względem celu ośmiu napojów oraz krótką animację podświetlenia po potwierdzeniu kota. MacBook jest mózgiem. Serwer FastAPI odbiera strumień, uruchamia logikę wykrywania, zapisuje do SQLite i wycina klip MP4 dla każdego zdarzenia z pięciosekundowym wyprzedzeniem, trzysekundowym dograniem i oryginalnym dźwiękiem.

Umiejscowienie kamery to pierwsza rzecz, którą trzeba zrozumieć, ponieważ wyjaśnia całą konstrukcję detekcji. Obiektyw patrzy w górę na pysk kota znad krawędzi miski, co oznacza, że tafla wody nie znajduje się w kadrze. System nie widzi kota pijącego. Widzi jedynie kota zajmującego obszar miski, a resztę wnioskuje na podstawie trwałości i tożsamości. Każdy, kto budował projekt z kamerą, wie, że to zwykle w tym miejscu uczciwość ulatnia się z pokoju; tutaj jest ona zapisana w README.

Przed uruchomieniem jakiegokolwiek modelu stosowany jest pipeline oparty na różnicy w skali szarości względem pustej miski jako klatki referencyjnej. Jeśli udział pierwszego planu wynosi poniżej 15 procent, klatka jest odrzucana bez angażowania sieci neuronowej. Powyżej 15 procent lokalny model MiniCPM-V 4.7 1B otrzymuje jedno pytanie: czy na tym obrazie jest kot? Odpowiedź twierdząca wraz z udziałem pierwszego planu powyżej 35 procent daje jeden głos na tak. Trzy kolejne głosy na tak otwierają zdarzenie; cztery kolejne głosy na nie zamykają je.

Podział na dwa modele to interesujący aspekt inżynierii

Uruchamianie modelu wizyjnego co 1,5 sekundy bez końca to zły pomysł i projekt traktuje to właśnie tak. Model 1B działa lokalnie przez llama.cpp jako kwantyzacja Q4_K_M na zgodnym z OpenAI serwerze llama-server na porcie 8080. Jest wystarczająco tani, by projekt mógł pozwolić sobie na wielokrotne wywoływanie go, ale nadal jest ograniczany przez różnicę tła, tak aby puste pomieszczenie nic nie kosztowało. Zadanie modelu 1B jest celowo wąskie: obecność, nie tożsamość, nie zachowanie.

Tożsamość to kosztowne pytanie i jest zadawane raz na zdarzenie. Gdy zdarzenie się zakończy, serwer pobiera próbki klatek z nagrania i wysyła je do MiniCPM-V 4.7 35B-A3B przez chmurowy interfejs API ModelBest, wraz z referencyjnym zdjęciem każdego z czterech kotów. Duży model zwraca identyfikator kota, wartość pewności oraz odpowiedź tak/nie, czy scena przedstawia picie. Klatki, które nie przejdą weryfikacji picia, są odrzucane i nie są liczone. Niejednoznaczne tożsamości są zapisywane jako nieznane, zamiast przypisywane na siłę do najbliższego kota, a jeśli wywołanie chmury się nie powiedzie, zdarzenie trafia do ścieżki ponawiania, zamiast być uzupełniane domysłem modelu 1B.

Ten podział pracy to ten sam argument, który literatura dotycząca przetwarzania na urządzeniu przedstawia od dwóch lat, tyle że teraz z pokwitowaniem. Mały model jest czujnikiem. Duży model jest sędzią. Model kosztów wynika bezpośrednio: za 1B płaci się milisekundami i baterią, za 35B płaci się tokenami, a rachunek za tokeny skaluje się z liczbą zdarzeń picia, a nie z liczbą klatek. W gospodarstwie domowym z czterema kotami to garść wywołań dziennie.

Co 89 wydarzeń dowodzi, a czego nie dowodzi

Post OpenBMB donosi, że w gospodarstwie domowym z czterema kotami przez trzy dni ręcznie sprawdzono 89 zdarzeń picia i każda tożsamość kota była poprawna. To prawdziwy wynik, ale także wąski. Zadanie identyfikacji to zamknięty wybór spośród czterech możliwości wśród kotów, dla których system ma już zdjęcia referencyjne. Nie jest to reidentyfikacja w otwartym zbiorze, nie jest to twierdzenie o stu kotach ani twierdzenie, że system działa w domu, którego nigdy nie widział.

Osiemdziesiąt dziewięć zdarzeń w ciągu trzech dni to około trzydziestu dziennie dla czterech kotów, czyli około siedmiu i pół na kota dziennie, co jest wiarygodne w badaniu poboru wody i zdecydowanie zbyt małe, by z jakąkolwiek pewnością oszacować wskaźnik błędów. System, który ma rację 89 razy na 89, nadal może się mylić raz na pięćdziesiąt. Liczba, której należy się trzymać, to nie 100 procent; chodzi o to, że nikt nie musiał go poprawiać przez trzy dni zwykłego użytkowania.

Istnieje również zastrzeżenie dotyczące pochodzenia. Autor jest ambasadorem społeczności OpenBMB, a pokaz odbył się na własnym koncie OpenBMB. Nie czyni to wyniku fałszywym, ale oznacza, że walidacja nie została zaprojektowana przez sceptyka i żadna strona trzecia jej nie powtórzyła.

Dlaczego 1B nie identyfikuje kota

README zawiera najważniejsze zdanie w całym projekcie i jest to wynik negatywny: w przypadku trzech jasno umaszczonych, podobnie wyglądających kotów lokalny MiniCPM-V 4.7 1B nie był niezawodny w wybieraniu jednego z czterech. Zespół wypróbował go, stwierdził, że rozróżnianie czterech opcji jest zawodne, i przeniósł identyfikację do modelu 35B, zamiast wdrażać zgadywanie.

Warto się nad tym zatrzymać, bo przeczy to sposobowi, w jaki zwykle sprzedaje się małe modele wizyjne. Model z 1,55 mld parametrów, który dobrze wypada w testach OCR i wykresów, niekoniecznie dobrze odróżnia dwa podobne zwierzęta w stałym kadrze kamery. Drobnoziarnista identyfikacja to dokładnie ten rodzaj zadania, w którym skompresowany budżet tokenów wizualnych szkodzi: różnice między dwoma pręgowanymi kotami są niewielkie, lokalne i łatwo znikają przy uśrednianiu. Rozwiązanie zastosowane w tym wydaniu — użyć małego modelu do łatwego pytania i ponieść koszt przy trudnym — jest bardziej użyteczne niż jakikolwiek wiersz tabeli wyników.

Ile kosztuje eksploatacja i co się dzieje, gdy chmurowa odnoga ulegnie awarii

Tylko za jedną część tego potoku trzeba płacić. Model 1B to lokalny plik GGUF na laptopie, więc koszt krańcowy jednej klatki to prąd. Model 35B to wywołanie hostowane przez API ModelBest, które jest własnym punktem końcowym dostawcy, a nie hostem zewnętrznym, i projekt wymaga do niego klucza. README wyraźnie stwierdza, że model 35B nie jest wdrażany lokalnie: MacBook nie przechowuje 35 miliardów parametrów, tylko klienta.

Ten podział tworzy tryb awarii, który projekt obsługuje, zamiast go ukrywać. Jeśli wywołanie chmury się nie powiedzie, zdarzenie jest ponawiane; wynik 1B nigdy nie jest podnoszony do rangi tożsamości. Jak na projekt hobbystyczny to niezwykle zdyscyplinowane. W przypadku czegokolwiek o produkcyjnym kształcie ten sam projekt umieszcza pojedynczy zewnętrzny punkt końcowy na ścieżce krytycznej systemu, którego całym celem jest rejestrowanie zdarzeń bez nadzoru.

To jest luka, którą wypełnia router, i warto dokładnie określić, co router może, a czego nie może tu zrobić. OrcaRouter udostępnia jedno API dla ponad 200 modeli z ceną katalogową dostawcy przekazywaną przy 0% marży, a dodatkowo automatyczne przełączanie awaryjne między upstreamami, co jest właściwym rozwiązaniem dla takiego potoku. Obecnie nie obsługuje MiniCPM-V 4.7, więc część 35B w esp32-eye nadal działałaby na własnym API dostawcy. Uczciwa wersja porady brzmi: zachowaj ścieżkę ponawiania, a jeśli krok identyfikacji stanie się krytyczny, umieść za tym samym wywołaniem drugi model, do którego faktycznie masz dostęp.

Co nadal pozostaje niepotwierdzone

Trzy rzeczy zmieniłyby to, jak poważnie należy traktować ten projekt. Pierwszą jest drugie gospodarstwo domowe. Wszystko, co dotychczas zgłoszono, pochodzi z jednego domu z czterema znanymi kotami i stałą kamerą. Drugą jest dłuższy okres działania: trzy dni nie pozwalają odróżnić systemu, który działa, od systemu, który działa do momentu, gdy kot zmieni sierść, zmieni się oświetlenie albo pojawi się gość. Trzecią jest niezależna weryfikacja 89 zdarzeń, która obecnie opiera się wyłącznie na ręcznym przeglądzie wykonanym przez samego twórcę.

To, co już ustalono, jest skromniejsze i bardziej użyteczne. MiniCPM-V 4.7 występuje w dwóch rozmiarach, które można łączyć: gęsty model 1,55B, który działa z pliku Q4_K_M na laptopie, oraz rzadki mixture-of-experts 35,2B, który aktywuje około 3 miliardów parametrów na token i jest wystarczająco dobry w czterokierunkowym zadaniu identyfikacji, by można było mu w nim zaufać. Miska dla kota to dziwne miejsce, by to udowodnić, ale jest to prawdziwe miejsce.

Jeśli chcesz to odtworzyć, repozytorium zawiera firmware kamery, firmware AMOLED, serwer FastAPI i skrypty testowe modelu, a jedyne konto, którego potrzebujesz, to klucz ModelBest dla odnogi tożsamości. Jeśli chcesz czytać model, a nie uruchamiać kota, od liczb dostawcy warto zacząć, a zastrzeżenia są w repozytorium.