LFM3-VL-2B vs WeVisOne-VL-4B: O que 2,5× os parâmetros realmente entregam

A própria tabela de benchmark da Tencent argumenta contra a compra óbvia. WeVisOne-VL-4B, o maior dos dois modelos de percepção que a equipe WeChat Vision publicou em 22 de outubro de 2026, é pior em alpha matting com prompt de caixa do que seu próprio irmão de 2B: 7,3 de diferença absoluta média no P3M-500-NP contra 6,6 do 2B, em que menor é melhor. O modelo com o qual a maioria dos compradores realmente o comparará, porém, não é seu irmão, mas LFM3-VL-2B — o modelo de visão em dispositivo de 1,92B da Liquid AI, cujos pesos apareceram em 19 de outubro e que foi anunciado com o restante da família LFM3 em 27 de outubro.

Coloque esses dois lado a lado e a pergunta interessante não é qual deles é mais inteligente. É o que duas vezes e meia a quantidade de parâmetros compra, e quanto custa. A resposta curta, a partir das próprias tabelas dos fornecedores: eles compram detecção densa, precisão de referência e uma taxa muito melhor de recusar-se a responder quando o objeto não está lá. Eles não compram um generalista, não compram vídeo e não compram um modelo que você possa colocar em um celular. Tudo abaixo vem das duas tabelas publicadas com as costuras deixadas à vista — nenhum arcabouço independente reproduziu os números de nenhum dos modelos.

O que cada um realmente é

LFM3-VL-2B tem 1,92B de parâmetros densos: um backbone de linguagem de 1,73B, um codificador visual próprio de 164M e um projetor de 25M. O backbone é a pilha tri-híbrida da Liquid — 24 camadas divididas em 13 convoluções curtas com gate, 5 camadas de atenção com janela deslizante de 256 tokens e 6 camadas de atenção global. Ele aceita texto, imagens e vídeo em resolução nativa, amostrando vídeo a 2 quadros por segundo, mantém um contexto de 128K tokens, cobre 16 idiomas e tem um modo de raciocínio opcional que produz uma etapa de raciocínio antes da resposta. Sua saída é prosa.

WeVisOne-VL-4B é construído sobre um backbone Qwen3-VL e chamado de 4B, embora os metadados do Hugging Face arredondem para 5B e textos de terceiros situem a contagem real perto de 4,83B. Ele não responde tanto em prosa quanto emite geometria: caixas e pontos como tokens de coordenadas normalizadas de 0 a 1000, um marcador OBJ (id de token 152678) após cada caixa prevista e a string literal None quando o alvo está ausente. Máscaras e alpha mattes exigem um segundo artefato, mask_decoder.pt, um decodificador de pixels de 9,6M de parâmetros que recebe o estado oculto de cada token OBJ e a caixa prevista e retorna alpha em resolução total com stride 1. Ele é de turno único e somente imagem, e gera saída estruturada diretamente, sem cadeia de pensamento.

O contraste numa única passada:

Tamanho — LFM3-VL-2B denso de 1,92B vs. WeVisOne-VL-4B com cerca de 4,83B, além de um decodificador de 9,6M que é obrigatório para máscaras

• Entrada — texto, imagem e vídeo a 2 fps vs texto e uma única imagem

• Saída — prosa e uma passagem de raciocínio vs. tokens de coordenadas, caixas, máscaras, mattes, ou um None explícito

• Contexto — 128K tokens vs. nenhum limite de inferência publicado na ficha; o artigo descreve o treinamento com 4.096 e 8.192 tokens

• Cobertura de idiomas — 16 idiomas declarados vs nenhum declarado

Licença — LFM Open License v1.0, gratuita para uso comercial com receita anual abaixo de US$ 10 milhões, versus Apache 2.0 para código de autoria da Tencent

• Runtime — GGUF/llama.cpp, MLX 4 bits, ONNX e BF16 vs BF16 via Transformers, vLLM ou SGLang

A atualização é desigual, e o artigo mostra onde

WeVisOne-VL-2B e WeVisOne-VL-4B são a mesma arquitetura em duas escalas, treinadas nas mesmas aproximadamente 100M imagens pelo mesmo currículo de três etapas, e avaliadas na mesma tabela. Isso torna a comparação entre modelos irmãos a evidência mais clara disponível sobre o que os parâmetros extras fazem — e ela não aponta numa única direção.

Onde o 4B claramente vence, segundo os números da Tencent:

• Detecção Dense200 — F1 médio de 71,3 vs 61,4, o maior ganho individual

• LVIS — 55,3 vs 53,3, uma melhoria modesta de 2 pontos

• Detecção por referência RefCOCOg — 81,8 no teste vs 78,2

• Segmentação referencial do RefCOCO — 84,5 cIoU no testA vs 82,9

• ReasonSeg — 71,2 cIoU em val vs 60,9, um salto de 10 pontos na segmentação por raciocínio

• PointBench pointing — 71,9 vs 62,9

• Matting de referência WeRefMat — diferença absoluta média de 9,8 na partição de referência vs 15,8, uma redução de erro de 38%

Onde não:

• Revestimento da caixa do P3M-500-NP — 7,3 vs 6,6 do 2B, pior

• PPM-100 box matting — 6,1 vs 5,3, pior

• Ref-ZOM cIoU — 72,2 no teste vs 73,4, o 2B à frente de novo

O padrão é legível mesmo que a causa não seja publicada: o 4B se destaca em tarefas difíceis e condicionadas por linguagem — segmentação por referência, segmentação por raciocínio, matting por referência em cenas reais — e não acrescenta nada nos conjuntos mais fáceis de matting com prompt de caixa, nos quais ambos os modelos já estão próximos do teto e o decodificador de 9.6M pode estar fazendo a maior parte do trabalho. Dois de três benchmarks de matting com prompt de caixa seguem na direção errada. Se o alpha matting em uma caixa fornecida for sua única tarefa, o 4B não é uma melhoria; é uma forma mais cara de obter a mesma resposta, ligeiramente pior.

Objetos ausentes: melhor, ainda não resolvido

A coluna mais útil do artigo é aquela que quase nenhuma ficha de modelo de visão publica. O RefCOCOg-Rej é uma variante na qual toda expressão é modificada de modo que não exista nenhum objeto correspondente na imagem. Um modelo que não consegue dizer "não" vai inventar uma caixa, e todo recorte, contagem e máscara a jusante herda essa fabricação.

O WeVisOne-VL-4B rejeita corretamente em 67,4% dos casos, contra 50,2% do 2B. Esse é um avanço real e expressivo — um ganho de 17 pontos que muda o modo de falha de um pipeline de cara ou coroa para duas em três. Isso também significa que o 4B ainda retorna uma caixa confiante para aproximadamente uma em cada três consultas de objeto ausente. No WeRef-Bench interno da própria Tencent, a taxa de rejeição aparece como 96,4%, mas esse benchmark é composto por 2.880 consultas em inglês e chinês criadas pelo próprio laboratório, então ele mede uma distribuição mais amigável do que a pública. O resumo honesto é que o modelo tem um comportamento de abstenção utilizável e não resolveu o problema; se sua aplicação não pode tolerar uma região alucinada, isso exige um limiar ou uma segunda verificação adicional, seja qual for o modelo escolhido.

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

É tentador colocar os 90,5 RefCOCO-avg do LFM3-VL-2B ao lado dos 81,8 RefCOCOg do WeVisOne-VL-4B e anunciar uma vitória de 8,7 pontos para o modelo menor. Não faça isso. Esses são splits e métricas diferentes: a Liquid reporta uma média em toda a família RefCOCO, a Tencent reporta F1 de teste do RefCOCOg para detecção por referência. Subtraí-los produz um número sem referente.

A mesma armadilha está no OCR. O LFM3-VL-2B obtém 86,3 no OCRBench v1, um compósito de reconhecimento, localização e raciocínio sobre texto; o WeVisOne-VL-4B obtém 52,0 de F1 médio no TotalText, um benchmark de localização de texto em cena. Um é um exame amplo, o outro é uma tarefa de previsão densa. Não são a mesma habilidade medida duas vezes.

Portanto, as duas tabelas de fornecedores não coincidem em um único número comparável. O que pode ser comparado com honestidade são capacidades e custo, e é por isso que o restante desta comparação trata de adequação, e não de classificação. Qualquer pessoa que publique um vencedor a partir dessas duas tabelas está inventando um.

A memória é o preço real

Nenhum dos modelos tem um preço por token publicado em 28 de outubro de 2026. O card da Liquid vincula o acesso à API e ao Playground por meio do console dela, mas nenhuma tabela de preços foi publicada para o LFM3-VL-2B; os rastreadores de terceiros que listam as tarifas dos modelos de texto da Liquid não cobrem o modelo de visão. A Tencent não tem endpoint hospedado algum. Portanto, a comparação é uma comparação de auto-hospedagem, e a conta é expressa em memória.

• LFM3-VL-2B — cerca de 3,84 GB em BF16 por cálculo a partir da contagem de parâmetros, com builds de 4 bits MLX, GGUF e ONNX publicados junto a ele

• WeVisOne-VL-4B — aproximadamente 9,7 GB em BF16 segundo estimativas de terceiros, cerca de 19 GB em F32, além do mask_decoder.pt necessário

Essa diferença de 2,5× não é apenas uma GPU maior. É uma classe diferente de dispositivo. A ficha do LFM3-VL-2B deixa explícito que o modelo foi criado para trabalho no próprio dispositivo — perguntas sobre vídeo, documentos, gráficos e telas de aplicativos, localização de objetos, raciocínio espacial para robôs — e as builds MLX de 4 bits e GGUF são a forma de cumprir essa promessa: um laptop, um celular, um chassi de robô. Os caminhos documentados do WeVisOne-VL-4B são Transformers, vLLM e SGLang em BF16, sem build quantizada oficial e sem runtime no dispositivo. Ele quer uma GPU de servidor.

Vale a pena verificar o suporte do framework no seu próprio caminho, em vez de na tabela. Vídeo a 2 fps é uma capacidade do modelo no LFM3-VL-2B, mas saber se um determinado runtime aceita uma grade de vídeo é uma questão separada, e o card do modelo, os ports e os PRs upstream nem sempre concordaram sobre isso. Teste a combinação exata que você pretende enviar.

O OrcaRouter não hospeda nenhum dos dois modelos. Isso foi verificado no catálogo em 28 de outubro de 2026, não presumido — nem a linha LFM3 da Liquid nem o WeVisOne da Tencent aparecem na lista de modelos —, portanto nada aqui deve ser interpretado como uma rota para qualquer um deles. O que o catálogo de modelos do OrcaRouter oferece é Qwen3-VL-8B, nas variantes instruct e thinking, que é a opção pragmática se a sua necessidade real for um modelo de visão hospedado com preço publicado hoje, em vez de um checkpoint auto-hospedado. Uma única chave acessa tudo isso pelo preço de tabela do provedor, sem markup, e, se você estiver prototipando com um modelo de pesos abertos não comprovado, executá-lo por meio de um roteador com failover é melhor do que conectar um caminho de produção a um checkpoint que ainda não passou por uma avaliação independente.

Qual escolher

• Escolha o WeVisOne-VL-4B quando o entregável for geometria — máscaras, alpha mattes, caixas densas, contagens, apontamento — em imagens estáticas, quando as consultas forem condicionadas por linguagem em vez de por caixas e quando você tiver uma GPU sobrando

• Escolha o WeVisOne-VL-2B em vez do 4B quando sua tarefa for matting com prompt de caixa em cenas comuns; nos números publicados, o modelo menor é melhor nisso e consome menos da metade da memória

• Escolha o LFM3-VL-2B quando a entrada incluir vídeo, quando o documento for longo, quando a resposta precisar ser uma frase em vez de um polígono ou quando o dispositivo não for um servidor

• Não escolha nenhum dos dois se você precisar de um endpoint hospedado com preço por token publicado esta semana — nenhum dos fornecedores oferece isso, e nenhuma quantidade de benchmarking fecha essa lacuna

• Escolha ambos somente se aceitar dois esquemas de saída e dois caminhos de integração; a faixa de parâmetros compartilhada "cerca de 2B a 5B" disfarça dois produtos diferentes

O que mudaria isso

Três coisas. Uma estrutura de testes independente que execute os dois modelos nas mesmas imagens com os mesmos prompts — até lá, tudo acima é uma tabela de fornecedor lida com cuidado, o que é melhor do que uma tabela de fornecedor lida sem cuidado, mas não é evidência de qualidade. Uma build quantizada do WeVisOne, ou um runtime no dispositivo, o que moveria o argumento da memória de decisivo para negociável. E um preço por token publicado por qualquer uma das partes, o que substituiria a aritmética sobre gigabytes por um número com o qual alguém possa planejar o orçamento.

O menos provável dos três é o que mais importaria para este pareamento específico: suporte a vídeo no decodificador de pixels do WeVisOne. No momento, o generalista de 2B aceita vídeo e o instrumento de 4B não, e nenhuma contagem de parâmetros corrige uma modalidade que nunca foi treinada.