esp32-eye: O monitor de bebedouro para gatos que chama o MiniCPM-V 4.7 duas vezes

Duas placas ESP32-S3, um MacBook e duas versões de tamanhos diferentes do MiniCPM-V 4.7 agora mantêm um registro de qual gato bebeu da tigela de água e quando. Uma placa com câmera vigia a tigela, um MacBook executa o modelo pequeno localmente para responder a uma única pergunta específica, e o modelo grande só é chamado depois que um evento já aconteceu. O projeto se chama esp32-eye, fica em github.com/emwstudio/esp32-eye e foi tornado público em 25 de outubro de 2026. A OpenBMB o apresentou na primeira semana de novembro, e foi assim que a maioria das pessoas o conheceu.

O modelo por trás é a parte sobre a qual vale a pena ser preciso. A OpenBMB carregou o MiniCPM-V 4.7 no Hugging Face a 6 e 7 de outubro de 2026, publicou o cartão de modelo e a licença Apache-2.0 a 12 de outubro, e divulgou um comunicado de imprensa em inglês através da PR Newswire a 15 de outubro. Portanto, isto não é uma história de lançamento, e o monitor de gato não é um benchmark do fornecedor. É a implantação pública mais detalhada do modelo que alguém fora do laboratório documentou até agora, e acontece que é um eletrodoméstico.

O que a build realmente faz

O hardware é deliberadamente barato e ligeiramente desajeitado. Um Waveshare ESP32-S3-CAM-OV5640 fica na borda da tigela e transmite quadros JPEG de 1024×768 e áudio do microfone via Wi-Fi. Uma segunda placa, uma Waveshare ESP32-S3-Touch-AMOLED-2.16, é o display de mesa: um painel de 480×480 que mostra uma faixa de vídeo ao vivo, quatro cartões de gato, uma contagem diária em relação a uma meta de oito bebidas e uma pequena animação de destaque quando um gato é confirmado. O MacBook é o cérebro. Um servidor FastAPI recebe o stream, executa a lógica de detecção, grava no SQLite e corta um clipe MP4 para cada evento com cinco segundos de antecedência, três segundos de continuação e o áudio original.

A posição da câmera é a primeira coisa a entender, porque ela explica todo o design de detecção. A lente olha para o rosto do gato a partir da borda da tigela, o que significa que a superfície da água não está no enquadramento. O sistema não consegue ver um gato bebendo. Ele só consegue ver um gato ocupando a área da tigela e infere o resto a partir de persistência e identidade. Qualquer pessoa que já tenha feito um projeto com câmera sabe que é aqui que a honestidade costuma sair pela porta; aqui, isso está escrito no README.

O pipeline antes de qualquer modelo rodar é uma diferença de fundo em escala de cinza contra um quadro de referência de tigela vazia. Se a proporção de primeiro plano estiver abaixo de 15 por cento, o quadro é descartado sem tocar em uma rede neural. Acima de 15 por cento, o MiniCPM-V 4.7 1B local recebe uma pergunta: há um gato nesta imagem? Uma resposta positiva mais uma proporção de primeiro plano acima de 35 por cento se torna um voto afirmativo. Três votos afirmativos consecutivos abrem um evento; quatro votos negativos consecutivos o encerram.

A divisão em dois modelos é o aspecto interessante da engenharia

Executar um modelo de visão a cada 1,5 segundos para sempre é uma má ideia, e o processo de build trata isso como tal. O modelo de 1B roda localmente via llama.cpp como uma quantização Q4_K_M em um llama-server compatível com OpenAI na porta 8080. É barato o suficiente para que o projeto possa se dar ao luxo de chamá-lo repetidamente, mas ainda é condicionado pela diferença de fundo, de modo que uma sala vazia não custa nada. A tarefa do modelo de 1B é deliberadamente restrita: presença, não identidade, nem comportamento.

A identidade é a pergunta cara, e ela é feita uma vez por evento. Quando um evento é encerrado, o servidor amostra quadros do clipe e os envia ao MiniCPM-V 4.7 35B-A3B por meio da API de nuvem da ModelBest, com uma foto de referência para cada um dos quatro gatos. O modelo grande retorna um identificador de gato, um valor de confiança e um sim/não sobre se a cena é uma cena de consumo de água. Quadros que falham na verificação de consumo de água são descartados e não contabilizados. Identidades ambíguas são armazenadas como desconhecidas em vez de serem forçadas ao gato mais próximo, e, se a chamada à nuvem falhar, o evento entra em um caminho de nova tentativa em vez de ser preenchido retroativamente com o palpite do 1B.

Essa divisão de trabalho é o mesmo argumento que a literatura sobre processamento no dispositivo vem defendendo há dois anos, agora com comprovante. Um modelo pequeno é um sensor. Um modelo grande é um juiz. O modelo de custo decorre diretamente disso: o 1B é pago em milissegundos e bateria, o 35B é pago em tokens, e a conta de tokens escala com o número de eventos de consumo de água, não com o número de quadros. Em uma casa com quatro gatos, isso é um punhado de chamadas por dia.

O que os 89 eventos provam e não provam

O post da OpenBMB relata que, em uma casa com quatro gatos, ao longo de três dias, 89 eventos de ingestão de água foram verificados manualmente e a identidade de cada gato estava correta. Esse é um resultado real e também é restrito. A tarefa de identidade é uma escolha fechada de quatro opções entre gatos para os quais o sistema já possui fotos de referência. Não é reidentificação em conjunto aberto, não é uma alegação sobre cem gatos e não é uma alegação de que o sistema funciona em uma casa que nunca viu.

Oitenta e nove eventos ao longo de três dias equivalem a cerca de trinta por dia para quatro gatos, ou aproximadamente sete e meio por gato por dia, o que é plausível para um estudo de ingestão de água e pequeno demais para estimar uma taxa de erro com qualquer confiança. Um sistema que acerta 89 vezes em 89 ainda pode errar uma vez em cinquenta. O número a reter não é 100 por cento; é que ninguém precisou corrigi-lo em três dias de uso normal.

Há também uma ressalva quanto à proveniência. O autor é embaixador da comunidade OpenBMB e a demonstração foi publicada na própria conta da OpenBMB. Isso não torna o resultado falso, mas significa que a validação não foi concebida por um cético, e nenhum terceiro a repetiu.

Por que o 1B não identifica o gato

O README contém a frase mais útil de todo o projeto, e ela é um resultado negativo: com três gatos de pelagem clara que se parecem, o MiniCPM-V 4.7 1B local não era confiável para escolher um entre quatro. A equipe testou, considerou a discriminação entre quatro opções não confiável e passou a identificação para o 35B em vez de entregar um palpite.

Vale a pena refletir sobre isso, porque contraria a forma como modelos de visão pequenos costumam ser vendidos. Um modelo de 1,55 bilhão de parâmetros que se sai bem em OCR e benchmarks de gráficos não é automaticamente bom em distinguir dois animais semelhantes em uma visão fixa de câmera. A identidade refinada é exatamente o tipo de tarefa em que um orçamento comprimido de tokens visuais prejudica: as diferenças entre dois gatos tigrados são pequenas, locais e fáceis de diluir na média. A resposta da build — usar o modelo pequeno para a pergunta fácil e pagar pela difícil — é mais útil do que qualquer linha de leaderboard.

Quanto custa operar, e o que acontece quando o segmento de nuvem falha

Apenas uma parte deste pipeline gera custo. O 1B é um arquivo GGUF local em um laptop, então o custo marginal de um frame é eletricidade. O 35B é uma chamada hospedada à API da ModelBest, que é o endpoint da própria fornecedora e não um host de terceiros, e o projeto precisa de uma chave para isso. O README deixa explícito que o 35B não é implantado localmente: o MacBook não contém 35 bilhões de parâmetros, ele contém um cliente.

Essa separação cria um modo de falha que o projeto trata em vez de esconder. Se a chamada à nuvem falhar, o evento é tentado novamente; o resultado 1B nunca é promovido a uma identidade. Para um projeto de hobby, isso é incomumente disciplinado. Para qualquer coisa com formato de produção, o mesmo design coloca um único endpoint externo no caminho crítico de um sistema cujo propósito inteiro é registrar eventos sem supervisão.

É esta a lacuna que um router preenche, e vale a pena ser preciso sobre o que um router pode e não pode fazer aqui. O OrcaRouter oferece uma única API para mais de 200 modelos com o preço de tabela do fornecedor repassado a 0% de margem, além de failover automático entre upstreams, que é o formato certo para um pipeline como este. De momento não disponibiliza o MiniCPM-V 4.7, pelo que o percurso de 35B no esp32-eye continuaria a correr na API do próprio fornecedor. A versão honesta do conselho é: mantenha o caminho de retry e, se o passo de identidade se tornar crítico, coloque um segundo modelo que consiga realmente alcançar por trás da mesma chamada.

O que ainda não foi confirmado

Três coisas mudariam o peso que esta montagem merece. A primeira é uma segunda casa. Tudo o que foi relatado até agora vem de um único lar com quatro gatos conhecidos e uma câmara fixa. A segunda é um período de funcionamento mais longo: três dias não permitem distinguir um sistema que funciona de um sistema que funciona até um gato mudar de pelagem, a luz mudar ou chegar uma visita. A terceira é uma verificação independente dos 89 eventos, que atualmente se baseia na revisão manual do próprio construtor.

O que já está estabelecido é mais modesto e mais útil. O MiniCPM-V 4.7 existe em dois tamanhos que podem ser compostos: um modelo denso de 1,55B que roda em um arquivo Q4_K_M em um laptop, e um misto de especialistas esparso de 35,2B que ativa aproximadamente 3 bilhões de parâmetros por token e é bom o suficiente em uma tarefa de identidade de quatro vias para que se possa confiar nele para isso. Uma tigela de gato é um lugar estranho para provar isso, mas é um lugar real.

Se quiser reproduzi-lo, o repositório contém o firmware da câmera, o firmware AMOLED, o servidor FastAPI e os scripts de teste do modelo, e a única conta de que você precisa é uma chave ModelBest para a etapa de identidade. Se quiser ler o modelo em vez de executar o gato, os números do fornecedor são o ponto de partida, e as ressalvas estão no repositório.