Teste de aceitação de visão local do LFM2.5-VL-3B: como qualificar VLMs no dispositivo para telas, documentos e fluxos de trabalho privados

O teste de aceitação de visão local do LFM2.5-VL-3B da Liquid AI deve ser julgado como um exercício de qualificação de rota, não como um destaque de model card. A pergunta prática é mais estrita: um pequeno modelo de linguagem visual local consegue lidar com uma tarefa privada de tela, documento ou ancoragem com qualidade suficiente para que o produto aceite o resultado sem enviar a imagem para uma VLM na nuvem?

Essa pergunta é fácil de formular e difícil de provar. Uma captura de tela de demonstração polida mostra apenas que o modelo consegue ler algum conteúdo visual. Uma rota de produção precisa resistir a um dispositivo mais quente, memória apertada, deriva do estado da tela entre captura e ação, digitalizações inclinadas, tabelas densas e regras de privacidade que proíbem upload.

Este artigo usa como material de origem o post de lançamento da Liquid AI, o model card do Hugging Face, a documentação da Liquid, notas de capacidade de visão, orientação de avaliação de hardware, documentação de implantação ONNX, artefatos ONNX e artefatos GGUF. Trate números de benchmark, velocidade e capacidade dessas páginas como medidos pelo fornecedor ou específicos da fonte até que sua equipe os reproduza em seus próprios dispositivos. O objetivo não é provar que visão local vence visão na nuvem em todos os lugares. O objetivo é decidir onde o local é aceito, onde a nuvem ainda é necessária e onde o fallback híbrido é o modelo operacional mais honesto.

Para padrões de aceitação relacionados, veja o trabalho da Optijara sobre reprodutibilidade da visibilidade do feed, teste de rota de captura selecionada por IA, teste de limites de memória de contexto de trabalho e teste de aceitação de rota de inferência.

Por que o LFM2.5-VL-3B precisa de um teste de aceitação, não de uma recapitulação de lançamento

Uma VLM local não deve ser adotada porque é nova, compacta ou promissora em benchmarks. Ela ganha lugar apenas quando uma rota definida passa na aceitação. Uma rota pode extrair campos de cabeçalho de fatura de uma foto de telefone enquanto offline. Outra pode identificar o botão ativo em uma tela de aplicativo controlada. Outra pode resumir uma captura de tela com dados mascarados sem mover a imagem para fora do dispositivo. Cada rota precisa de seu próprio limite para precisão, latência, privacidade e fallback.

As fontes da Liquid AI estabelecem o que o fornecedor disponibiliza: a página do modelo LFM2.5-VL-3B, artefatos públicos do modelo, documentação de runtime e orientação de implantação. Elas não provam que seu fluxo de câmera, escolha de quantização, runtime móvel, orçamento de memória ou design de interface vai se comportar sob uso sustentado. Essa prova ausente é o teste de aceitação.

Fluxos de tela e documento são menos tolerantes do que chat aberto. Uma coordenada errada pode clicar no controle errado. Um campo perdido pode corromper um formulário. Uma linha de tabela alucinada pode entrar em um registro de negócio. Um fallback para a nuvem que dispara silenciosamente pode enfraquecer a expectativa de privacidade que os usuários acreditavam estar recebendo. A visão local só ganha confiança quando essas falhas são medidas diretamente.

O que verificar antes de testar: artefatos, licença, runtime e adequação ao dispositivo

Comece fixando os pesos do modelo, a configuração do processador, o tokenizer, exemplos de runtime e qualquer variante quantizada. Use revisões imutáveis quando possível. Registre o nome do artefato, URL de origem, commit ou revisão, hashes de arquivo, script de conversão e código de pré-processamento. Um resultado de teste ligado apenas à expressão LFM2.5-VL-3B é frouxo demais para aceitação de produção.

Disponibilidade de pesos não é permissão para todo uso de produto. Revise o model card e o texto da licença antes de redistribuição, incorporação comercial, envio em dispositivo, fine-tuning ou serviço de API. Mantenha a revisão de licença no mesmo pacote de aceitação que os resultados de precisão e runtime. Revisão jurídica separada da revisão técnica é como as equipes perdem o fio.

A escolha de runtime também importa. Um caminho Hugging Face em precisão total pode não se comportar como um caminho ONNX móvel. Uma build GGUF quantizada pode mudar pressão de memória, latência, estabilidade de saída ou tratamento de imagem. Teste cada rota separadamente. Não deixe um bom resultado em um runtime validar outro runtime por associação.

Monte uma matriz de dispositivos antes de relatar a primeira pontuação. Inclua versão do sistema operacional, CPU, disponibilidade de GPU ou NPU, RAM, armazenamento, perfil térmico, estado da bateria, estado da rede e runtime. Adicione pelo menos um dispositivo de menor capacidade que se pareça com a base real de usuários. Se uma rota passa apenas em um dispositivo de laboratório ligado à tomada que começou frio, ela não passou na rota de produto.

A estrutura LVAT da Optijara: Teste de Aceitação de Visão Local

LVAT é uma estrutura de aceitação em quatro partes para decidir quando o LFM2.5-VL-3B consegue lidar com uma tarefa visual localmente. A estrutura é específica por tarefa por design. Uma rota pode passar para triagem de documentos e falhar para automação precisa de UI, e isso não é uma contradição. É o objetivo do teste.

Prova de limite local e privacidade. Desative a rede e execute a rota. Inspecione logs, relatórios de falha, analytics, buffers de telemetria, payloads de fallback e verificações de atualização. Confirme que prompts, imagens, saídas de OCR e coordenadas permanecem dentro do limite pretendido, a menos que uma política explícita de fallback seja acionada e divulgada.

Fidelidade visual em telas e documentos. Inclua fontes pequenas, posições de rolagem, popups, modais, baixo contraste, desfoque, compressão, capturas rotacionadas, tabelas densas, formulários, digitalizações e páginas multilíngues. Pontue campos exatos, estrutura normalizada de tabela, preservação de layout e omissões de texto. Registre o que degrada quando imagens são redimensionadas, divididas em blocos ou cortadas.

Acionabilidade por ancoragem e esquemas de ferramenta. Teste saídas de coordenadas contra janelas de tolerância, sobreposição de região e segurança do alvo de clique. Para chamadas de ferramentas, valide cada saída contra esquemas JSON estritos. Conte esquema inválido, tentativas de ação insegura, referências ao alvo errado e casos em que o modelo deveria se abster.

Tolerância sob estresse do dispositivo, entradas malformadas e fallback. Execute a rota sob pressão de memória, loops sustentados, dispositivos quentes e bateria baixa. Adicione imagens quebradas, capturas de tela parciais, capturas interrompidas e estados de tela em mudança. O fallback deve ser visível, fundamentado e auditável. Se o usuário não consegue saber quando a nuvem foi usada, o produto está ocultando uma decisão arquitetural.

Matriz de decisão de rota LVAT: local, nuvem ou híbrida

Local deve ser o padrão quando a tarefa é sensível à privacidade, o tamanho da imagem é gerenciável, o dispositivo passa nos testes sustentados de latência e memória, a precisão de ancoragem fica dentro da tolerância e a rota funciona offline. Exemplos incluem triagem estreita de documentos, resumo local de capturas de tela ou detecção de região de UI controlada depois de passar em um conjunto de testes de referência.

A nuvem continua mais segura quando a tarefa precisa de raciocínio mais amplo, contexto maior, compreensão multilíngue mais complexa, limites de precisão que o local não atinge, lotes pesados de documentos ou políticas de auditoria que exigem controles centralizados de modelo. Privacidade local tem valor real. Ela não compensa capacidade ausente quando capacidade é a restrição vinculante.

Roteamento híbrido costuma ser o melhor caminho para a primeira versão. Execute local primeiro para classes de entrada aceitas. Escale quando a confiança for baixa, a entrada estiver malformada, o dispositivo estiver quente, a pressão de memória for alta, o idioma ou tipo de documento estiver fora do conjunto aceito, ou o usuário tiver optado pelo fallback na nuvem.

Meça custo por tarefa aceita, não preço bruto de token nem velocidade de demonstração. Inclua uso de recursos do dispositivo, tratamento de falhas, volume de fallback, monitoramento, manutenção, testes de regressão e risco de atualização. A rota mais barata em um slide pode ficar cara quando lógica de repetição e tickets de suporte entram no cálculo.

Checklist de implementação para telas, documentos e ancoragem de objetos

Defina temporização de captura de tela, orientação, regras de corte, limites de redimensionamento, estratégia de tiling e mascaramento antes de medir o modelo. Inclua testes de deriva do estado da tela em que o alvo se move após a captura. Teste sobreposições, estados de teclado, popups e posições de rolagem. Eles parecem detalhes de produto, mas frequentemente explicam mais falhas do que o próprio modelo.

Monte um conjunto representativo de formulários, faturas, tabelas, digitalizações, imagens de baixo contraste e páginas multilíngues. Use amostras sensíveis mascaradas quando possível. Pontue exatidão de campo, comportamento de campo ausente, alinhamento de linhas e colunas, normalização de tabela e recusa quando a imagem é ilegível.

Avalie coordenadas com janelas de tolerância e sobreposição de região, não com correção narrativa. Um modelo que diz botão superior direito não é equivalente a um modelo que retorna uma região clicável segura. Adicione testes negativos em que o objeto está ausente ou apenas parcialmente visível.

Toda saída de ferramenta deve ser validada por esquema antes de uso. Exija campos tipados, valores de coordenada limitados, campos de confiança ou abstenção, motivo da rota e flags de ação segura. Rejeite JSON malformado em vez de repará-lo silenciosamente em produção. Reparar estrutura ruim pode transformar um erro do modelo em erro da aplicação.

Versione prompts, limites, código de pré-processamento, artefatos do modelo e conjuntos de testes de referência. Execute testes de regressão antes de mudar quantização, runtime, revisão do modelo ou pré-processamento da câmera. Defina critérios de rollback antes do rollout, enquanto ninguém está discutindo sob pressão de incidente.

{
  "framework": "Optijara LVAT",
  "accepted_route": "local only after task-level pass",
  "rejected_route": "local when grounding, schema, privacy or sustained-device tests fail",
  "fallback_triggers": ["low confidence", "malformed image", "thermal pressure", "unsupported language", "schema failure"],
  "required_evidence": ["pinned artifacts", "device matrix", "golden tests", "privacy audit", "rollback plan"]
}

Plano de medição: da velocidade de demonstração à confiabilidade sustentada do dispositivo

Meça inicialização fria, latência quente e latência sustentada por categoria de tarefa. Não copie um limite universal de uma página de modelo. Uma ação rápida de assistente pessoal, um lote de documentos e um leitor de tela de acessibilidade têm tolerâncias diferentes. Relate p50 e p95 para cada rota e dispositivo.

Execute loops longos o bastante para expor throttling, falhas, crescimento de memória e impacto na bateria. Acompanhe se a rota se abstém ou escala quando o dispositivo cruza um limite de recursos. Confiabilidade sustentada importa mais do que uma demonstração atraente.

Use correspondência exata de campo, precisão de tabela normalizada, consistência de região de layout, taxa de acerto de ancoragem, prevenção de clique inseguro, taxa de esquema válido, precisão de abstenção e qualidade de fallback. A métrica certa é aquela ligada ao valor aceito pelo usuário. Para uma rota de fatura, isso pode ser precisão de campo e qualidade de recusa. Para ação de UI, prevenção de clique inseguro pode importar mais do que uma descrição fluente.

Teste operação offline com a rede desativada. Inspecione logs de runtime, analytics da aplicação, relatórios de falha e filas de fallback. Inferência local não significa automaticamente privada se imagens sensíveis aparecem em telemetria ou payloads de escalonamento para a nuvem.

Erros comuns que equipes cometem ao qualificar VLMs locais

Benchmarks são sinais úteis, não prova de implantação. Um modelo pode pontuar bem em um benchmark e ainda falhar em uma ação estreita de tela porque o corte, a resolução, o idioma da interface ou o esquema de coordenadas difere da tarefa do benchmark.

Imagens limpas escondem risco de produção. Adicione desfoque, compressão, reflexo, capturas parciais, modais, rolagem, texto minúsculo e documentos malformados. A aceitação deve refletir as entradas confusas que os usuários realmente criam.

Não presuma que caminhos ONNX, GGUF, quantizados e de precisão total sejam intercambiáveis. Trate cada combinação de modelo mais runtime mais dispositivo como uma rota candidata separada. Essa regra parece tediosa até que uma atualização mude a estabilidade de saída em uma classe de dispositivo e ninguém consiga reproduzir o resultado antigo.

Fallback é útil quando é visível e controlado. É perigoso quando esconde o fato de que a rota local falha com frequência demais. Acompanhe motivo de fallback, classe de entrada, estado de recursos e resultado final. Uma taxa alta de fallback não é uma história de sucesso de visão local.

Inferência no dispositivo ainda pode vazar por logs, dumps de falha, analytics, monitoramento, sistemas de atualização ou fallback na nuvem. Aceitação de privacidade exige inspeção, não pressupostos.

Ressalvas, limitações e recomendações operacionais

LVAT não pode provar comportamento futuro do modelo, toda variante de dispositivo, todo tipo de documento, todo idioma ou todo estado de interface. É um processo de aceitação para rotas conhecidas. Execute-o novamente quando artefatos, runtimes, prompts, pré-processamento, dispositivos ou políticas de fallback mudarem.

Rotas locais trazem tamanho de pacote, gerenciamento de atualização, impacto na bateria, comportamento térmico, variação de acelerador e complexidade de suporte. Rotas na nuvem trazem dependência de rede, revisão de privacidade, variação de fornecedor e custos recorrentes de inferência. Rotas híbridas trazem requisitos de política de roteamento, divulgação e observabilidade. Nenhuma é universalmente melhor.

Um sprint LVAT prático começa com revisão de artefatos e licença, depois monta uma matriz de dispositivo/runtime, conjunto de testes de referência, pipeline de pré-processamento, executor de pontuação, auditoria de privacidade e política de fallback. A saída é uma decisão de rota: local aceito, nuvem necessária ou híbrida com gatilhos explícitos. Se uma equipe está avaliando o LFM2.5-VL-3B para fluxos de trabalho visuais privados, este é o nível de qualificação que mantém a decisão fundamentada.

A regra é simples: aceite visão local apenas onde a evidência a sustenta. Fixe os artefatos, teste a rota, meça o comportamento sustentado do dispositivo, audite o limite de privacidade e mantenha o fallback honesto.