WeVisOne-VL-2B vs LFM2.5-VL-3B: Um Criador de Máscaras Contra um Leitor de Tela

Dê aos dois modelos a mesma fotografia e a mesma frase — “o cachorro à esquerda” — e duas coisas diferentes retornam. O LFM2.5-VL-3B responde com uma localização e, se você perguntar, uma descrição: uma caixa, um ponto ou uma frase curta sobre o que encontrou. O WeVisOne-VL-2B também responde com uma caixa, e então um pequeno decodificador transforma essa caixa em uma máscara alfa de bordas suaves que você poderia compor sobre um novo fundo sem um halo ao redor dos pelos. Um modelo foi criado para ler uma interface e responder. O outro foi criado para entregar pixels a você.

Essa diferença é a comparação inteira, e ela resiste a todas as tabelas de benchmark publicadas por qualquer um dos fornecedores. Também explica por que os dois modelos raramente são avaliados um contra o outro: a ficha da Liquid AI não menciona o WeVisOne, o artigo da Tencent não menciona a Liquid, e nenhum terceiro os executou lado a lado. O que segue é o que cada lançamento de fato registrou, quais dos seus números podem ser colocados lado a lado e quais não podem.

Dois lançamentos, duas quantidades de evidências muito diferentes

LFM2.5-VL-3B foi publicado pela Liquid AI em 11 de agosto de 2026 — os pesos primeiro, o anúncio no dia seguinte — e veio com uma tabela numérica de benchmarks, um baseline nomeado para cada linha e uma seção de velocidade medida em hardware nomeado. É um modelo denso de 3,12 bilhões de parâmetros: um backbone de linguagem LFM2.5-2.6B combinado com um codificador visual SigLIP2 NaFlex 400M, um contexto de 32.768 tokens, um vocabulário de 128.000 tokens e dezesseis idiomas nomeados. Sua licença é a própria LFM Open License v1.0 da Liquid, que é gratuita para uso comercial abaixo de um limite de receita, em vez de gratuita incondicionalmente.

WeVisOne-VL-2B foi publicado pela equipe WeChat Vision da Tencent em 22 de outubro de 2026, e seu card de modelo não contém nenhuma tabela de benchmarks — nenhuma pontuação, nenhum comprimento de contexto, nenhum número de throughput, nenhum requisito de hardware. Os números existem, mas estão no artigo que o acompanha, que apresenta sete tabelas de tarefas distribuídas por mais de trinta benchmarks, segundo a descrição dos autores. Portanto, os dois lançamentos não são apenas modelos diferentes; são tipos diferentes de documento. A Liquid publicou uma especificação de produto. A Tencent publicou um resultado de pesquisa e deixou a ficha de especificações praticamente em branco.

Essa assimetria é importante quando se lê uma comparação como esta. Os números do Liquid foram reunidos para serem lidos em relação às suas próprias referências de base. Os da Tencent foram reunidos para ganhar uma tabela académica. Nenhum dos fornecedores escolheu os seus números a pensar no outro modelo, e é precisamente por isso que os números não coincidem.

O número que parece comparável e não é

Ambos os modelos publicam uma pontuação RefCOCO e, ao colocá-los lado a lado, surge uma manchete de aparência limpa: LFM2.5-VL-3B com 87,9 contra WeVisOne-VL-2B com 79,7. Essa comparação não tem sentido, e vale a pena percorrer o porquê, porque o mesmo erro está sendo cometido em planilhas neste momento.

• Liquid relata RefCOCO precision@1 em média entre as divisões. Essa é uma estatística de detecção: a caixa prevista de melhor classificação se sobrepôs à caixa de referência o suficiente para contar como correta.

• O 79,7 da Tencent está numa tabela de segmentação, e o artigo afirma claramente que os números da família RefCOCO ali são IoU cumulativo — interseção total sobre união total em todo o conjunto de avaliação.

• A tabela de detecção referencial da Tencent não reporta o RefCOCO de forma alguma. Ela reporta o RefCOCOg, onde o 2B obtém 77,1 de F1 médio.

Então, o 87,9 e o 79,7 medem três coisas diferentes em duas tarefas diferentes. Uma caixa que quase não se sobrepõe a um alvo pode ter boa pontuação em precision@1 e baixa pontuação em cIoU; uma máscara que cobre bem um objeto grande pode ter pontuação alta em cIoU enquanto sua caixa delimitadora é imprecisa. Não há aritmética que os concilie.

A mesma armadilha está presente no OCR. A Liquid publica o OCRBench v1 com 84,2 e o OCRBench v2 English com 47,5 — benchmarks de transcrição. A Tencent publica OCR como F1 de localização com limiar de IoU de 0,5: 62,1 no SROIE, 42,6 no ICDAR2015, 42,5 no TotalText, 30,5 no HierText. Esses números medem se o modelo encontrou e delimitou o texto, não se o leu corretamente. Citar "84,2 versus 62,1" seria comparar um teste de leitura com um teste de apontamento.

O que é, na verdade, uma comparação justa?

Retire as pontuações e os dois modelos se alinham em dimensões que não exigem um harness:

• Tamanho — cerca de 3,12 B de parâmetros densos para o LFM2.5-VL-3B vs cerca de 2 B para o WeVisOne-VL-2B, além de um decodificador de 9,5 M de parâmetros que deve ser baixado separadamente e é necessário para saídas densas.

• Base — o backbone híbrido LFM2.5-2.6B da própria Liquid vs Qwen3-VL.

• Contexto — {{1}}32.768 tokens{{/1}} publicados na ficha técnica vs {{2}}nenhum comprimento de contexto publicado{{/2}}. As etapas de treinamento do artigo do WeVisOne rodaram com {{3}}4.096 e 8.192 tokens{{/3}}, e a inferência limita cada imagem a {{4}}1.960 tokens visuais{{/4}}, mas nada disso é uma janela de implantação.

• Tipos de saída — caixas, pontos e texto vs caixas, pontos, máscaras binárias e mattes alfa contínuos.

• Raciocínio — o LFM2.5-VL-3B é deliberadamente não raciocinante, respondendo diretamente para manter a latência baixa; o WeVisOne também é não raciocinante, mas por um motivo diferente, gerando saída estruturada sem cadeia de pensamento para eficiência de inferência. Nenhum dos modelos "pensa" antes de responder, e nenhum dos fornecedores finge o contrário.

• Chamada de ferramentas — suportada e avaliada no LFM (ToolSandbox 59,5, BFCL v4 32,5) vs. não ser uma capacidade declarada no WeVisOne.

• Idiomas — dezesseis indicados no cartão da LFM vs não informados no cartão da WeVisOne.

• Licença — LFM Open License v1.0, com um limite de receita, versus Apache 2.0 para código de autoria da Tencent.

• Builds quantizados — exportações GGUF, ONNX e MLX oferecidas pela Liquid vs nenhuma anunciada pela Tencent.

• Avaliação independente — nenhum dos modelos tem uma entrada no Artificial Analysis até o momento desta publicação. Todos os números neste artigo, de ambos os fornecedores, são informados pelos próprios fornecedores.

A lacuna de implementação é maior do que a lacuna de parâmetros

O LFM2.5-VL-3B foi projetado para rodar em um celular, e o card comprova isso com números: menos de 3,3 GB de memória, 20 tokens por segundo em um Galaxy S26 Ultra, 228 tokens por segundo em um Apple M5 Max, 116 em um AMD Ryzen AI Max+ 395 e cerca de 11.000 tokens de saída por segundo em alta concorrência em uma única H100. Ele é distribuído em formatos que os runtimes de consumidor realmente conseguem carregar.

O WeVisOne-VL-2B não publica nada disso. O que ele publica implica uma conta diferente. O estágio final do decodificador produz um alpha matte de resolução total com stride 1, o que significa que a saída densa tem o tamanho da imagem de entrada, e não um vetor de tamanho fixo — um custo que escala com a resolução, não com a contagem de parâmetros. Para um modelo de 2B em uma GPU moderna, isso é administrável. Para um celular, não é nada obviamente administrável, e a Tencent não afirmou que seja.

A consequência prática é que esses dois modelos não competem pelo mesmo slot de implantação. Um é um componente que você poderia incluir dentro de um aplicativo. O outro é um componente que você executaria em um servidor, ou em uma estação de trabalho, ao lado de qualquer outra coisa que precise de mascaramento.

Escolha pelo tipo de saída, não pela pontuação

Se a tarefa é ler uma tela — analisar um fluxo de checkout, encontrar o botão rotulado "Continuar", extrair uma tabela de um documento fotografado —, o LFM2.5-VL-3B é o candidato óbvio. Ele tem ScreenSpot-v2 em 80,7, DocVQA em 91,1, ChartQA em 81,3 e uma pontuação no ToolSandbox que sugere que ele pode agir com base no que vê, em vez de apenas descrevê-lo. Ele também tem uma média de 69,4 em 28 benchmarks que a Liquid publica em comparação com modelos irmãos nomeados, o que ao menos indica como o fornecedor enxerga seu próprio entorno.

Se a tarefa é isolar um objeto — um recorte de produto, uma pessoa contra um fundo carregado, um primeiro plano com fios de cabelo soltos ou uma borda transparente —, o LFM2.5-VL-3B não produz essa saída, e nenhuma quantidade de prompting fará com que produza. O WeVisOne-VL-2B produz, e a margem nas tabelas de matting é grande: 6,6 de diferença absoluta média contra 15,4 do SAM2-Matting no P3M-500-NP, e 15,8 contra 23,0 de um pipeline Qwen3-VL-8B mais SAM2 no split WeRefMat com prompt de linguagem.

Há mais um caso em que a WeVisOne tem uma alegação que vale a pena notar: ausência. A Tencent relata uma taxa de rejeição de 50,2 no RefCOCOg para consultas cujo alvo não está na imagem, contra 0,5 e 0,6 de dois modelos especializados de grounding na mesma tabela. Se seu pipeline processa milhares de recortes e a maioria deles não contém nada que lhe interesse, um modelo que diz confiavelmente "não está lá" economiza um classificador downstream. A ficha do LFM2.5-VL-3B não relata um número de rejeição comparável, então não há nada para colocar ao lado dele — uma lacuna nas evidências, não uma perda.

Nada disso é motivo para escolher um e aposentar o outro, e vale ser honesto sobre onde um roteador se encaixa. O OrcaRouter não serve nenhum dos dois modelos; nenhum está no nosso catálogo, e nenhum está hospedado em qualquer lugar que possamos verificar especificamente para a WeVisOne. O que oferecemos é a stack ao redor: se seu pipeline usa um modelo de visão hospedado para a parte de leitura e um modelo auto-hospedado para a parte de mascaramento, as chamadas hospedadas passam por uma única chave de API pelo preço de tabela do provedor, sem markup, o failover as move para outro provedor quando um degrada, e a DSL de roteamento permite colocar as duas partes atrás de um único endpoint, para que sua aplicação nunca saiba qual delas respondeu.

O que realmente resolveria isso

Uma estrutura de avaliação independente, executada por alguém que não seja nenhum dos dois fornecedores, sobre as mesmas imagens, relatando tanto uma estatística de detecção quanto uma estatística de segmentação para ambos os modelos. Isso não existe. Até que exista, a posição defensável é a mais sem graça: esses modelos respondem a perguntas diferentes, seus números publicados são medidos com instrumentos diferentes, e a escolha entre eles é decidida pelo que o seu código a jusante espera receber — uma frase ou uma máscara.

Se você só levar uma coisa desta comparação, leve a forma da evidência. A Liquid AI lhe deu uma tabela que você pode falsear. A Tencent lhe deu um artigo que você pode ler e um cartão que diz, com franqueza, o que o modelo não fará. Nenhuma das duas lhe deu um número que possa ser comparado ao outro, e qualquer artigo que publique 87.9 ao lado de 79.7 sem essa ressalva está lhe vendendo um ranking que não existe.