esp32-eye: Máy theo dõi bát nước cho mèo gọi MiniCPM-V 4.7 hai lần

Hai bo mạch ESP32-S3, một chiếc MacBook và hai kích cỡ khác nhau của MiniCPM-V 4.7 giờ đây ghi lại nhật ký con mèo nào đã uống nước từ bát và vào lúc nào. Một bo mạch camera theo dõi bát nước, một chiếc MacBook chạy mô hình nhỏ cục bộ để trả lời một câu hỏi hẹp, còn mô hình lớn chỉ được gọi sau khi một sự kiện đã xảy ra. Bản dựng này có tên esp32-eye, nằm tại github.com/emwstudio/esp32-eye và được công khai vào ngày 25 tháng 10 năm 2026. OpenBMB đã giới thiệu nó trong tuần đầu tiên của tháng 11, và đó là cách hầu hết mọi người biết đến nó.

Mô hình bên dưới chính là phần đáng để nói cho thật chính xác. OpenBMB đã tải MiniCPM-V 4.7 lên Hugging Face vào ngày 6 và 7 tháng 10 năm 2026, công bố thẻ mô hình và giấy phép Apache-2.0 vào ngày 12 tháng 10, và phát hành một thông cáo báo chí tiếng Anh qua PR Newswire vào ngày 15 tháng 10. Vì vậy, đây không phải là một câu chuyện ra mắt, và chiếc máy giám sát mèo không phải là một phép đánh giá chuẩn của nhà cung cấp. Đây là lần triển khai công khai chi tiết nhất của mô hình mà bất kỳ ai bên ngoài phòng thí nghiệm đã ghi lại cho đến nay, và nó tình cờ lại là một thiết bị gia dụng.

Bản build thực sự làm những gì

Phần cứng được cố ý làm rẻ và hơi bất tiện. Một Waveshare ESP32-S3-CAM-OV5640 nằm trên vành bát và truyền trực tiếp các khung hình JPEG 1024×768 cùng âm thanh micrô qua Wi-Fi. Một bo mạch thứ hai, Waveshare ESP32-S3-Touch-AMOLED-2.16, là màn hình để bàn: một tấm nền 480×480 hiển thị dải video trực tiếp, bốn thẻ mèo, số đếm hằng ngày so với mục tiêu tám ly, và một hoạt ảnh điểm nhấn nhỏ khi một con mèo được xác nhận. MacBook là bộ não. Một máy chủ FastAPI nhận luồng, chạy logic phát hiện, ghi vào SQLite, và cắt một đoạn MP4 cho mỗi sự kiện với năm giây dẫn trước, ba giây kết thúc, và âm thanh gốc.

Vị trí đặt camera là điều đầu tiên cần hiểu, vì nó giải thích toàn bộ thiết kế phát hiện. Ống kính hướng lên nhìn mặt mèo từ mép bát, nghĩa là mặt nước không nằm trong khung hình. Hệ thống không thể thấy mèo đang uống. Nó chỉ có thể thấy một con mèo chiếm khu vực bát, và suy ra phần còn lại từ tính liên tục và danh tính. Bất kỳ ai từng làm dự án camera đều biết đây là chỗ sự trung thực thường bị gạt sang một bên; ở đây điều đó được viết rõ vào README.

Quy trình trước khi bất kỳ mô hình nào chạy là hiệu số nền thang độ xám so với khung tham chiếu bát trống. Nếu tỷ lệ tiền cảnh dưới 15%, khung sẽ bị loại bỏ mà không cần chạm đến mạng nơ-ron nào. Trên 15%, MiniCPM-V 4.7 1B cục bộ được hỏi một câu: trong ảnh này có mèo không? Câu trả lời khẳng định cộng với tỷ lệ tiền cảnh trên 35% sẽ trở thành một phiếu thuận. Ba phiếu thuận liên tiếp sẽ mở một sự kiện; bốn phiếu phủ định liên tiếp sẽ đóng sự kiện đó.

Việc tách thành hai mô hình là phần kỹ thuật thú vị.

Chạy một mô hình thị giác mỗi 1,5 giây mãi mãi là một ý tồi, và bản build cũng coi đó là một ý tồi. Mô hình 1B chạy cục bộ qua llama.cpp dưới dạng lượng tử hóa Q4_K_M trên một llama-server tương thích OpenAI ở cổng 8080. Nó đủ rẻ để dự án có thể gọi nó lặp lại, nhưng vẫn được điều kiện bởi chênh lệch nền để một căn phòng trống không tốn gì. Nhiệm vụ của mô hình 1B được cố ý thu hẹp: sự hiện diện, không phải danh tính, không phải hành vi.

Danh tính là câu hỏi tốn kém, và nó chỉ được hỏi một lần cho mỗi sự kiện. Khi một sự kiện kết thúc, máy chủ lấy mẫu các khung hình từ clip và gửi chúng đến MiniCPM-V 4.7 35B-A3B thông qua API đám mây của ModelBest, kèm theo một ảnh tham chiếu cho mỗi con trong bốn con mèo. Mô hình lớn trả về mã nhận diện mèo, giá trị độ tin cậy và câu trả lời có/không về việc khung cảnh đó có phải là cảnh uống nước hay không. Những khung hình không vượt qua kiểm tra uống nước sẽ bị loại bỏ và không được tính. Những danh tính mơ hồ được lưu là không xác định thay vì bị gán cưỡng bức cho con mèo gần nhất, và nếu lệnh gọi đám mây thất bại, sự kiện sẽ đi vào luồng thử lại thay vì được điền bù bằng phỏng đoán của mô hình 1B.

Sự phân công lao động đó chính là lập luận mà các tài liệu về xử lý trên thiết bị đã đưa ra suốt hai năm qua, và giờ đã có biên lai xác nhận. Một mô hình nhỏ là một cảm biến. Một mô hình lớn là một quan tòa. Mô hình chi phí suy ra trực tiếp: 1B được trả bằng mili giây và pin, 35B được trả bằng token, và hóa đơn token tỉ lệ với số lần uống chứ không phải với số khung hình. Trong một hộ có bốn con mèo, đó chỉ là vài lần gọi mỗi ngày.

89 sự kiện chứng minh và không chứng minh điều gì

Bài đăng của OpenBMB báo cáo rằng trong một gia đình có bốn con mèo, qua ba ngày, 89 sự kiện uống nước đã được kiểm tra thủ công và danh tính của mọi con mèo đều chính xác. Đó là một kết quả thực và cũng là một kết quả hẹp. Bài toán nhận diện danh tính là lựa chọn bốn chiều trong tập đóng giữa những con mèo mà hệ thống đã có ảnh tham chiếu. Đây không phải là tái nhận diện tập mở, không phải là tuyên bố về một trăm con mèo, và cũng không phải là tuyên bố rằng hệ thống hoạt động trong một ngôi nhà mà nó chưa từng thấy.

Tám mươi chín sự kiện trong ba ngày tức là khoảng ba mươi sự kiện mỗi ngày cho bốn con mèo, hay khoảng bảy rưỡi sự kiện mỗi con mỗi ngày, điều này hợp lý đối với một nghiên cứu lượng nước uống và quá nhỏ để ước tính tỷ lệ lỗi với bất kỳ độ tin cậy nào. Một hệ thống đúng 89 lần trong 89 lần vẫn có thể sai một lần trong năm mươi. Con số cần ghi nhớ không phải là 100 phần trăm; mà là không ai phải sửa nó trong ba ngày sử dụng thông thường.

Cũng có một lưu ý về nguồn gốc. Tác giả là đại sứ cộng đồng OpenBMB và màn trình diễn được chạy trên chính tài khoản của OpenBMB. Điều đó không làm kết quả thành sai, nhưng có nghĩa là việc xác thực không được thiết kế bởi một người hoài nghi, và chưa có bên thứ ba nào lặp lại nó.

Tại sao 1B không nhận diện được con mèo

README chứa câu hữu ích nhất trong toàn bộ dự án, và đó là một kết quả phủ định: với ba con mèo màu sáng trông giống nhau, MiniCPM-V 4.7 1B chạy cục bộ không đáng tin cậy trong việc chọn ra một trong bốn. Nhóm đã thử, nhận thấy khả năng phân biệt bốn lựa chọn không đáng tin cậy, và chuyển việc nhận diện danh tính sang mô hình 35B thay vì đưa ra một phỏng đoán.

Điều này đáng để ngẫm kỹ vì nó đi ngược lại cách các mô hình thị giác nhỏ thường được quảng bá. Một mô hình 1,55 tỷ tham số đạt điểm cao trên các bài đánh giá OCR và biểu đồ không tự động giỏi trong việc phân biệt hai con vật giống nhau trong một khung hình camera cố định. Nhận diện danh tính chi tiết chính là kiểu tác vụ mà ngân sách token thị giác bị nén gây bất lợi: khác biệt giữa hai con mèo mướp rất nhỏ, mang tính cục bộ và dễ bị trung bình hóa mất. Câu trả lời của bản dựng — dùng mô hình nhỏ cho câu hỏi dễ và trả giá cho câu hỏi khó — hữu ích hơn bất kỳ dòng nào trên bảng xếp hạng.

Chi phí vận hành là bao nhiêu, và điều gì xảy ra khi chặng cloud gặp sự cố

Chỉ một chặng của pipeline này phải trả tiền. Mô hình 1B là một tệp GGUF cục bộ trên laptop, nên chi phí biên của một khung hình chỉ là tiền điện. Mô hình 35B là một lệnh gọi được lưu trữ tới API của ModelBest, tức endpoint của chính nhà cung cấp chứ không phải một máy chủ bên thứ ba, và dự án cần một khóa cho nó. README nói rõ rằng 35B không được triển khai cục bộ: MacBook không chứa 35 tỷ tham số, mà nó chứa một client.

Sự phân tách đó tạo ra một chế độ lỗi mà dự án xử lý thay vì che giấu. Nếu lệnh gọi lên đám mây thất bại, sự kiện sẽ được thử lại; kết quả 1B không bao giờ được thăng cấp thành một danh tính. Với một dự án sở thích, như vậy là kỷ luật bất thường. Với bất cứ thứ gì mang dáng dấp môi trường production, cùng thiết kế đó lại đặt một điểm cuối bên ngoài duy nhất lên đường dẫn tới hạn của một hệ thống mà toàn bộ mục đích là ghi lại sự kiện không cần người trông coi.

Đây là khoảng trống mà một router lấp đầy, và cần nói thật chính xác về những gì một router có thể và không thể làm ở đây. OrcaRouter cung cấp một API duy nhất cho hơn 200 mô hình với giá niêm yết của nhà cung cấp được chuyển nguyên ở mức 0% phụ phí, cùng với tự động chuyển đổi dự phòng giữa các upstream, đúng là hình dạng phù hợp cho một pipeline như thế này. Hiện tại nó chưa hỗ trợ MiniCPM-V 4.7, nên nhánh 35B trong esp32-eye vẫn sẽ phải chạy trên API riêng của nhà cung cấp. Phiên bản trung thực của lời khuyên là: hãy giữ đường thử lại, và nếu bước nhận diện trở thành yếu tố then chốt, hãy đặt một mô hình thứ hai mà bạn thực sự có thể truy cập được phía sau cùng một lời gọi.

Điều gì vẫn chưa được xác nhận?

Ba điều sẽ thay đổi mức độ đáng tin cậy mà bản dựng này xứng đáng nhận được. Điều đầu tiên là một hộ gia đình thứ hai. Mọi thứ được báo cáo cho đến nay đều đến từ một ngôi nhà với bốn con mèo đã biết và một camera cố định. Điều thứ hai là một lần chạy dài hơn: ba ngày không thể phân biệt một hệ thống hoạt động tốt với một hệ thống chỉ hoạt động cho đến khi một con mèo thay bộ lông, ánh sáng thay đổi hoặc có khách đến. Điều thứ ba là một đợt kiểm tra độc lập đối với 89 sự kiện, hiện đang dựa vào việc chính người xây dựng tự rà soát thủ công.

Điều đã được xác lập thì khiêm tốn hơn và hữu ích hơn. MiniCPM-V 4.7 tồn tại ở hai kích cỡ có thể kết hợp với nhau: một mô hình dense 1,55B chạy trong một tệp Q4_K_M trên laptop, và một mixture-of-experts thưa 35,2B kích hoạt khoảng 3 tỷ tham số mỗi token và đủ giỏi trong một tác vụ định danh bốn lựa chọn để có thể tin tưởng giao phó việc đó. Một cái bát ăn của mèo là một nơi kỳ lạ để chứng minh điều đó, nhưng đó là một nơi có thật.

Nếu bạn muốn tái tạo nó, repo có firmware camera, firmware AMOLED, máy chủ FastAPI và các script kiểm thử mô hình, và tài khoản duy nhất bạn cần là khóa ModelBest cho nhánh nhận diện danh tính. Nếu bạn muốn đọc mô hình thay vì chạy con mèo, số liệu của nhà cung cấp là điểm khởi đầu và các lưu ý nằm trong repo.