LFM3-VL-2B vs MiniCPM-V 4.7 35B-A3B: A coluna que não é o modelo

Abra a tabela de benchmarks para LFM3-VL-2B e você encontrará uma coluna MiniCPM. Ela está rotulada como MiniCPM-V 4.7 1B. Esse é o irmão menor. O modelo que a maioria das pessoas quer dizer quando fala MiniCPM-V 4.7 — o MiniCPM-V 4.7 35B-A3B da OpenBMB, o primeiro checkpoint de mistura de especialistas da linha MiniCPM-V — não está na tabela da Liquid AI, e nos benchmarks que ambos os laboratórios publicam ele não chega perto do 1B. Portanto, a comparação que as pessoas realmente estão avaliando, LFM3-VL-2B contra MiniCPM-V 4.7 35B-A3B, precisa ser montada à mão a partir de duas tabelas de fornecedores que compartilham nomes de benchmarks, mas não harnesses de avaliação. O que segue é essa montagem, com as costuras deixadas visíveis.

A diferença de tamanho é a segunda surpresa. Um modelo tem 1,92 bilhão de parâmetros densos e cabe em alguns gigabytes. O outro armazena 35,21 bilhões de parâmetros e acessa aproximadamente 3 bilhões deles por token. Lido como uma ficha técnica, isso não é uma comparação justa. Lido como duas respostas à mesma pergunta — o que você consegue executar em um dispositivo que não controla —, é um desacordo genuinamente interessante sobre como chegar lá.

Dois modelos, um nome

A colisão de nomes está causando danos reais à forma como esta comparação é lida. O card da Liquid AI é escrupuloso quanto a isso: a coluna diz 1B, e o 1B é um par legítimo para um modelo de 1,92B. Mas resultados de busca, agregadores e referências casuais reduzem "MiniCPM-V 4.7" a uma única coisa, e o 35B-A3B é a variante que tem público — 289.535 downloads e 1.095 curtidas no Hugging Face contra 155.428 e algumas centenas para o irmão de 1B, em 28 de outubro de 2026.

As datas explicam parte dessa diferença, e não o resto. O repositório 35B-A3B da OpenBMB foi criado em 7 de outubro de 2026, com o lançamento datado de 12 de outubro nos materiais do próprio projeto. O repositório do LFM3-VL-2B da Liquid AI foi ao ar em 19 de outubro, e a família LFM3 foi anunciada em 27 de outubro. O LFM3-VL-2B tem nove dias de vida pública, então seus 255 downloads são um fato de calendário, não um veredito. A proporção de curtidas é o dado mais interessante: 45 para o LFM3-VL-2B, 1.095 para o MiniCPM. As pessoas que baixaram este último gostaram o suficiente para dizer isso.

O que cada um realmente é

• Parâmetros — o LFM3-VL-2B é denso com 1,92B: um backbone de linguagem de 1,73B, um codificador de visão interno de 164M e um projetor de 25M. O MiniCPM-V 4.7 35B-A3B armazena 35,21B em 256 experts e roteia 8 deles por token, com cerca de 3B ativos.

• Backbone — 24 camadas LFM3, divididas em 13 convoluções curtas com gate, 5 camadas de atenção com janela deslizante e 6 camadas de atenção global, em comparação com 40 camadas de transformer com tamanho oculto de 2.048.

• Caminho de visão — um codificador de 14 camadas com 8 convoluções 2D depthwise com gating e 6 camadas de atenção bidirecional em patches 16×16 com embeddings rotacionais 2D, contra uma torre de 27 camadas com tamanho oculto 1.152 inserida na camada 6 da pilha de texto, com compressão antecipada de tokens dentro do codificador e downsampling visual comutável de 4× ou 16×.

• Contexto — 128K tokens no LFM3-VL-2B, 256K no MiniCPM, ambos entrada mais saída.

• Entradas — texto, imagens e vídeo a 2 quadros por segundo para o modelo Liquid; texto, imagens e vídeo para o da OpenBMB. Nenhum dos dois ouve áudio, em nenhuma das direções.

• Pesos em disco — cerca de 3,8 GB em BF16 versus cerca de 65,6 GiB em BF16.

• Licença — LFM Open License v1.0, que a Liquid descreve como livre para uso comercial abaixo de 10 milhões de dólares em receita anual, versus Apache 2.0 sem qualquer condição de receita.

A discordância arquitetural é toda a história. A Liquid apostou que um modelo denso pequeno somado a um codificador de visão feito sob medida supera uma torre no estilo SigLIP em computação por imagem, e publicou uma tabela de categorias para provar isso. A OpenBMB apostou que é possível manter a capacidade de um modelo de 35B e ainda executá-lo em um celular fazendo a parte cara fluir em streaming em vez de residir. Ambas são apostas sobre memória, feitas em direções opostas.

A lacuna é real, e é mais estreita do que o enquadramento.

Aqui está o que as duas tabelas dos fornecedores dizem quando você coloca as linhas certas lado a lado. Tudo isso é autodeclarado pelos laboratórios, e as ressalvas do harness vêm depois.

• MMMU — LFM3-VL-2B 55,7 com o raciocínio ativado, 48,6 com ele desativado; MiniCPM-V 4.7 35B-A3B 80,22 com compressão visual de 4×, 80,00 com 16×.

• MMStar — 74,4 contra 80,67 em 4×, 80,13 em 16×.

• OCRBench v1 — 86,3 contra 91,20 em 4×, 90,40 em 16×.

• MathVista — 84,2 com raciocínio, 68,5 sem, contra 88,00 em 4× e 87,30 em 16×.

• Raciocínio CharXiv — 70,2 contra 75,60 em 4×, 69,20 em 16×.

O MMMU é onde o 35B justifica seu tamanho: uma diferença de 24,5 pontos sobre a configuração com pensamento, e de 31,6 pontos sobre a sem pensamento. Esse é o benchmark de raciocínio multimodal em nível universitário, e a margem é grande o suficiente para resistir a qualquer objeção razoável sobre diferenças de harness.

Todo o resto está mais próximo do que a narrativa sugere. O OCRBench é uma diferença de 4,9 pontos. O MathVista fica em 3,8 pontos quando o LFM3-VL-2B pensa. No raciocínio do CharXiv, o modelo Liquid perde por 5,4 pontos no modo de pensamento — e supera o número 16× do modelo de 35B em um ponto. Um modelo de 2B a menos de cinco pontos de um de 35B em OCR de documentos e gráficos é o achado que deveria receber mais atenção do que a manchete do MMMU.

Agora as ressalvas, porque elas importam. Os números da Liquid vêm de uma única execução em 62 benchmarks no vLLM 0.27.1, normalizados para 0–100, com o modo de raciocínio ativado para todos os modelos, exceto nas configurações marcadas de outra forma. Os cinco números da OpenBMB são publicados como imagens de gráficos, e não como uma tabela numérica, e foram transcritos aqui a partir da leitura desses gráficos por um agregador de terceiros, então trate as casas decimais como aproximadas. Os dois laboratórios não concordam quanto aos orçamentos de tokens visuais, às configurações de prompting ou de decodificação, e a divisão 4× versus 16× do lado da OpenBMB, por si só, altera suas pontuações em até seis pontos. Isto são dois conjuntos de alegações lado a lado, não um experimento controlado.

Onde o modelo pequeno tem números, o grande não publica.

A Liquid publicou 62 linhas. A OpenBMB publicou cinco. Essa assimetria é o fato mais subnotificado desta comparação, e ela pende numa direção que favorece o modelo menor.

• Ancoragem visual — RefCOCO-avg 90,5, RefCOCO-M 95,2, Point-Bench 73,8, RefSpatial-Bench 49,8 para o LFM3-VL-2B. Não aparece nenhuma linha equivalente na avaliação publicada do MiniCPM-V 4.7 35B-A3B.

• Compreensão de GUI — ScreenSpot-Pro 55.5, ScreenSpot-v2 com 94,6 em desktop, 92,2 em mobile, 89,9 em web. Novamente, nada publicado do lado da OpenBMB.

• Raciocínio incorporado — EmbSpatial-Bench 82,9, RoboSpatial-Home 63,4, Where2Place 44,9. Mesma ausência.

• Vídeo — Video-MME 62,8 sem legendas, MVBench 69,4, MLVU 71,3, ActivityNet-QA 71,2. O MiniCPM-V 4.7 oferece suporte a vídeo e a ficha técnica o aborda em detalhes, mas a tabela numérica não traz uma linha de vídeo que pudéssemos verificar.

Isto é ausência de evidência, não uma vitória por omissão. Se você está construindo um pipeline de robótica ou de agentes de tela, a posição honesta é que a capacidade do 35B nessas tarefas é desconhecida, e não fraca. Mas “desconhecida” é, por si só, um problema de aquisição: não dá para planejar uma implantação com base num número que ninguém publicou, e o LFM3-VL-2B é o único dos dois cujo desempenho em grounding e GUI você pode consultar antes de baixá-lo.

O argumento da memória é uma faca de dois gumes

O motivo habitual para escolher um 2B em vez de um 35B é que o 2B cabe. O LFM3-VL-2B cabe, de forma integral e previsível: cerca de 3,8 GB em BF16, residente, sem paginação, sem surpresas quando o dispositivo está sob carga. Essa é uma propriedade genuinamente forte para um produto que você distribui para hardware que não controla.

O MiniCPM-V 4.7 35B-A3B não cabe nem de longe em um celular com 65,6 GiB, e todo o design da OpenBMB existe por causa disso. O Lookahead Expert Scheduling prevê o roteamento da próxima camada e pré-busca os especialistas que espera; a quantização fina camada a camada encolhe esses especialistas para que se movam mais rápido; a amostragem especulativa do DSpark cobre as paralisações de decodificação. A afirmação do fornecedor é de mais de 13 tokens por segundo em um iPhone 17 Pro Max usando cerca de 3 GB de memória, e mais de 17 em um iPad Pro M4 com 16 GB.

Portanto, a alegação de execução no dispositivo não é “o 35B é pequeno”. É “o 35B faz streaming, e o streaming é suave o suficiente para ser utilizável”. Essas são apostas diferentes, com modos de falha diferentes. Um modelo residente de 3,8 GB degrada graciosamente — ou está carregado, ou não está. Um modelo de 65,6 GiB em streaming degrada conforme a largura de banda da memória flash, o throttling térmico e a latência de inicialização a frio, todos os quais variam de dispositivo para dispositivo de maneiras que um benchmark em um único iPhone não captura.

A divisão prática: se você não controla nem a velocidade de armazenamento nem o envelope térmico, a abordagem residente é o caminho de menor risco. Se você está distribuindo para hardware de ponta recente e quer a precisão, a abordagem da OpenBMB não é mais teórica — é um modelo lançado com um fork funcional por trás.

O ferramental do primeiro dia não é um empate.

O LFM3-VL-2B traz pesos BF16 que exigem transformers 5.21 ou mais recente, além de GGUF, incluindo um checkpoint Q4_0 destilado com reconhecimento de quantização, uma build MLX de 4 bits e uma exportação ONNX. O suporte em servidores ainda não está concluído: o vLLM é descrito como em andamento, o SGLang está em revisão no pull request 46858, e o llama.cpp está em revisão no pull request 31252 com uma nota explícita de que a entrada de vídeo ainda não é suportada. O card também recomenda o parser de raciocínio qwen3 e o parser de chamada de ferramentas qwen3_coder para vLLM e SGLang, um detalhe que mostra quão recentemente isso foi conectado.

O MiniCPM-V 4.7 35B-A3B oferece suporte a SGLang, vLLM, llama.cpp e Ollama, com SWIFT e LLaMA-Factory para ajuste fino, builds GGUF, BitsAndBytes, AWQ, GPTQ, FP8 e int4, e suporte desde o primeiro dia a plataformas de chips da Rockchip, Houmo, Intel, AMD e Arm em iOS, Android e HarmonyOS. O caminho no dispositivo passa pelo fork llama.cpp-omni da própria OpenBMB, e não pelo llama.cpp upstream.

Para uma implantação em produção este mês, isso não é uma decisão difícil. Para um spike de pesquisa, uma demonstração em laptop ou um fine-tune que você pretende manter, o LFM3-VL-2B funciona hoje por meio do transformers e você não vai gastar uma semana com flags de build.

A linha da licença em que mais equipas vão tropeçar

A licença Apache 2.0, em comparação com a LFM Open License v1.0, representa uma diferença prática maior do que a lacuna no MMMU, porque se aplica a todas as implantações, e não apenas aos casos difíceis. A Apache 2.0 não impõe condição de receita, nem restrição de campo de uso, nem ambiguidade sobre se um derivado quantizado ou destilado herda os termos. A LFM Open License v1.0 é gratuita para uso comercial abaixo de US$ 10 milhões em receita anual, segundo a própria descrição da Liquid, o que significa que uma empresa acima desse limite tem uma conversa sobre licenciamento antes de lançar o produto, e não depois.

Essa única cláusula muda a comparação para muitos compradores. Uma startup abaixo do limite recebe, de graça, um modelo menor, mais rápido e mais bem documentado em fundamentação. Uma empresa acima do limite recebe um modelo que exige uma assinatura — e, a partir daí, o Apache 2.0 do 35B se torna uma característica à qual você passa a prestar atenção.

O que nenhum dos dois fornecedores lhe contará

Não há um confronto direto independente. Nenhum laboratório terceirizado executou os dois modelos no mesmo ambiente de avaliação, e o que mais se aproxima de um placar neutro — a própria tabela da Liquid — compara o LFM3-VL-2B com o 1B, não com o 35B. Todos os números deste artigo vêm do laboratório que criou o modelo que ele descreve.

Vale a pena nomear outras duas lacunas. Nenhum dos modelos tem um preço por token que pudéssemos verificar, então uma comparação de custos aqui seria inventada. E nenhum dos dois está no catálogo OrcaRouter em 28 de outubro de 2026 — uma busca por minicpm não retorna modelos correspondentes, e LFM3-VL-2B também não está listado. Isso faz disto hoje uma decisão de auto-hospedagem ou de API de fornecedor, e não uma decisão de roteamento.

Qual escolher

• Documentos, gráficos, texto denso e raciocínio multimodal difícil, com um stack de serving sob seu controle — MiniCPM-V 4.7 35B-A3B. A vantagem no MMMU é o único resultado grande o suficiente para resistir às ressalvas do harness, e a Apache 2.0 elimina totalmente a questão da licença.

• Um dispositivo que você não controla, com um limite fixo de memória e nenhuma tolerância à latência de streaming — LFM3-VL-2B. Residente em 3,8 GB, e o único dos dois com números publicados de grounding, GUI e embodied para planejar com base neles.

• Agentes de tela, robótica e tarefas espaciais — LFM3-VL-2B por padrão, porque é o único lado com evidências publicadas. Trate o 35B como não comprovado nesses casos, em vez de fraco.

• Produção neste mês com trabalho mínimo de integração — MiniCPM-V 4.7 35B-A3B. Suporte a SGLang, vLLM, llama.cpp e Ollama contra três notas “em revisão” ou “em andamento”.

• Uma empresa com receita anual acima de US$ 10 milhões — MiniCPM-V 4.7 35B-A3B, a menos que a restrição no dispositivo seja rígida o suficiente para justificar uma conversa sobre licenciamento.

Como o OrcaRouter se encaixa, honestamente

Ainda não se encaixa, e dizer o contrário seria o tipo de coisa que faz um post de blog ser ignorado. Nenhum dos modelos está no catálogo do OrcaRouter hoje, então não há chave para lhe entregar nem preço para informar.

O que é verdade é o que acontece quando um modelo de visão realmente chega lá: um endpoint compatível com OpenAI para mais de 200 modelos, o preço de tabela do provedor repassado com 0% de margem, de modo que uma mudança de preço do fornecedor entra no ar no mesmo dia, e failover automático para que a indisponibilidade de um único provedor não derrube sua rota. Para uma comparação como esta — dois modelos que discordam sobre memória, sem nenhum benchmark independente para resolver a questão —, o padrão útil é executar os dois por trás de um único endpoint e medir nas suas próprias imagens, em vez de discutir sobre qual gráfico está certo.

O que assistir

Quatro coisas mudariam este artigo. O pull request 31252 sendo mesclado com suporte a vídeo, o que colocaria o caminho de vídeo do LFM3-VL-2B no llama.cpp padrão. O suporte do vLLM saindo de “em andamento”, o que o tornaria uma opção séria de serving em vez de uma demonstração. Uma avaliação independente executando os dois modelos em um mesmo harness — o artefato ausente mais valioso desta comparação. E a Liquid AI adicionando o 35B à sua própria tabela de comparação, o que mostraria que o laboratório o considera o par real.

Até que qualquer um desses se concretize, o resumo defensável é mais estreito do que o enquadramento de qualquer um dos fornecedores: o 35B vence o benchmark de raciocínio que importa e não perde nada em OCR, o 2B vence em evidências de fundamentação e previsibilidade, e a licença decide mais implantações do que o benchmark.