LFM3-Omni-2B vs MiniCPM-V 4.7 1B: Quando o Modelo Menor Lê Melhor

No papel, esta não é uma disputa justa. LFM3-Omni-2B tem 2,17 bilhões de parâmetros; MiniCPM-V 4.7 1B é comercializado como um modelo de 1B. O modelo maior deveria vencer os benchmarks de visão. Não vence. O MiniCPM obtém 86,1 no OCRBench contra 80,6, 69,5 no MMStar contra 55,67, 56,9 no MMMU contra 42,44 e 74,3 no MathVista contra 62,5. Todos os benchmarks de visão que as duas fichas compartilham favorecem o modelo com o nome menor, geralmente por uma margem ampla, e o MiniCPM ainda tem oito vezes mais janela de contexto. O Fusion custa mais por chamada do que o roteamento para um único modelo. Ele é cobrado pelo preço de tabela do provedor sem nenhum acréscimo de margem.

Três coisas explicam isso, e nenhuma delas é um defeito em qualquer um dos modelos. O MiniCPM-V 4.7 1B é um especialista que gastou todo o seu orçamento de parâmetros em visão. O LFM3-Omni-2B é um generalista que gastou seu orçamento em visão, audição e fala. E o número do MiniCPM que mais importa — 86,1 no OCRBench — foi medido com sua configuração de 4× tokens visuais, que troca computação por detalhe de uma forma que um limite de 2,048 tokens por imagem não consegue. Entender essa troca é a decisão inteira.

Por que o modelo menor lê melhor

O MiniCPM-V 4.7 1B é construído em torno de uma única ideia: comprimir tokens visuais desde cedo e permitir que o usuário escolha o quão forte será a compressão. O modelo aplica compressão de tokens de 4× ou 16× dentro do codificador visual, antes que o modelo de linguagem veja qualquer coisa. Com 16×, ele é barato e rápido, adequado para legendagem e descrição de cenas. Com 4×, ele mantém quatro vezes mais tokens, que é o que OCR de documentos e leitura densa de gráficos precisam. Os números de destaque da OpenBMB são reportados na configuração de 4×.

O LFM3-Omni-2B adota a abordagem oposta. Ele processa imagens em resolução nativa, mas limita o orçamento visual a 2.048 tokens por imagem, e esse limite é compartilhado com um codificador de áudio, um caminho de vídeo e um decodificador de fala dentro de uma rede densa de 2,17 bilhões. O teto de 2.048 tokens é uma escolha razoável para um modelo que precisa caber em um celular ao lado de outras três modalidades. É um teto rígido para quanto detalhe da página pode chegar ao modelo de linguagem, e o DocVQA 92,47 sugere que o modelo extrai muito proveito disso — mas o OCRBench 80,6 diz que não é suficiente para superar um especialista que pode gastar 4× os tokens na mesma página.

Há um segundo fator, mais discreto. A janela de contexto do MiniCPM é de 262.144 tokens. A do LFM3-Omni-2B é de 32.768. Para uma única captura de tela, nenhuma das duas importa. Para um PDF de 40 páginas, um vídeo longo ou uma conversa de vários turnos sobre documentos, a diferença não é uma linha de benchmark — é se a tarefa é possível ou não.

Especificação, sem o arredondamento de marketing

Um número precisa ser corrigido antes de qualquer comparação. O MiniCPM-V 4.7 1B é chamado de modelo 1B, e sua contagem de parâmetros densos é de aproximadamente 1,3 a 1,55 bilhão, dependendo de como você conta a torre de visão. A barra lateral do Hugging Face arredonda para "2B params", e é assim que um modelo 1B acaba parecendo um modelo 2B em um catálogo. O tamanho do arquivo é o guia honesto: cerca de 3,1 GB em BF16, contra 4,3 GB para o LFM3-Omni-2B.

• Parâmetros — 2,17B densos para o LFM3-Omni-2B vs aproximadamente 1,3B a 1,55B densos para o MiniCPM-V 4.7 1B.

• Entradas — texto, imagem, vídeo com áudio, áudio de 16 kHz vs texto, imagem, várias imagens e vídeo.

• Saídas — texto e fala de 24 kHz vs. apenas texto.

• Contexto — 32.768 tokens vs 262.144 tokens.

• Tokens visuais — limitados a 2.048 por imagem, em comparação com a compactação comutável de 4× ou 16× dentro do codificador.

• Licença — LFM Open License v1.0 vs Apache-2.0.

• Lançamento — 27 de outubro de 2026 vs 12 de outubro de 2026.

• Pegada — cerca de 4,3 GB em BF16 vs cerca de 3,1 GB em BF16, aproximadamente 5 GB de VRAM para servir.

Cada linha que os dois cartões compartilham

A comparação é incomumente limpa para uma tabela entre laboratórios, porque ambos os fornecedores relatam os mesmos quatro conjuntos de dados de visão e ambos são modelos não de raciocínio avaliados no modo instruct. Ainda assim, são duas avaliações de fornecedores, e nenhuma foi reproduzida de forma independente.

• OCRBench — 80,6 para LFM3-Omni-2B (806 de 1.000) vs 86,1 para MiniCPM-V 4.7 1B. Uma diferença de 5,5 pontos no reconhecimento de texto em documentos.

• MMStar — 55,67 vs 69,5. Uma diferença de 13,8 pontos, a maior do conjunto.

• validação MMMU — 42,44 vs 56,9. Uma diferença de 14,5 pontos em raciocínio multimodal de nível universitário.

• MathVista mini — 62,50 vs 74,3. Uma diferença de 11,8 pontos em matemática visual.

Quatro linhas, quatro derrotas, diferenças entre cinco e quinze pontos. Não há nenhuma linha em que o modelo omni vença, o que é um resultado mais limpo do que o produzido pela comparação entre LFM3 e LFM2.5 e mais difícil de justificar. A interpretação mais defensável é que um especialista de 1,4B com contexto de 256K e um orçamento de tokens 4× maior é simplesmente um leitor melhor do que um generalista de 2,17B com contexto de 32K e um limite de imagem de 2.048 tokens. Nesta escala, capacidade investida em uma única modalidade supera capacidade dividida entre quatro.

Duas ressalvas devem ser feitas no mesmo fôlego, porque nenhum dos dois cartões as menciona espontaneamente. O 86,1 do MiniCPM é medido com compressão de 4×, e o mesmo modelo na sua configuração padrão de 16× teria uma pontuação menor e seria mais barato de executar — o cartão não publica esse número. E o cartão de modelo da OpenBMB não traz nenhuma tabela de benchmark; os números aparecem como texto corrido e imagens de gráficos na página do produto, o que é uma forma mais fraca de publicação do que uma tabela com uma nota de metodologia. Ambos os conjuntos de números são alegações do fornecedor. A direção da diferença é consistente o suficiente para provavelmente resistir a testes independentes; o tamanho exato, provavelmente, não.

O contexto é a linha que decide cargas de trabalho reais.

Um contexto de 32K é generoso para uma única imagem e apertado para um documento. A cerca de 2.048 tokens visuais por imagem, o LFM3-Omni-2B consegue manter cerca de uma dúzia de imagens completas em sua janela antes que o histórico da conversa comece a competir por espaço. Os 262.144 tokens do MiniCPM-V 4.7 1B não são uma melhoria modesta; são uma classe diferente de carga de trabalho. PDFs longos, formulários de várias páginas, resumos de vídeos de uma hora e loops de agentes que mantêm capturas de tela no contexto são todos viáveis com 256K e todos limitados com 32K.

Esta é a diferença menos discutida e mais consequente entre os dois modelos. As tabelas de benchmark recompensam a precisão em imagem única; pipelines de documentos em produção falham na décima quarta página. Se o seu caso de uso envolve mais do que um punhado de imagens por conversa, a janela de 32K é um limite mais rígido do que qualquer uma das quatro lacunas de benchmark acima.

O que o MiniCPM não consegue fazer

Ele não consegue ouvir. Não há caminho de entrada de áudio, nem saída de fala, nem tratamento de trilha sonora de vídeo. Se o aplicativo for uma pessoa conversando com um dispositivo sobre o que a câmera vê, o MiniCPM-V 4.7 1B é um componente de um pipeline que precisa de pelo menos mais dois modelos — um sistema ASR e um sistema TTS — além da cola para mover texto entre eles.

O LFM3-Omni-2B condensa esse pipeline em um único checkpoint de 4,3 GB. Suas pontuações em áudio são pouco impressionantes em comparação com modelos de fala dedicados — taxa de erro de palavra de 6,36 no ASR em inglês, VoiceBench 64,73 —, mas elas existem dentro do mesmo forward pass que o caminho de visão, o que significa que o modelo pode responder a uma pergunta falada sobre uma imagem sem que uma transcrição chegue a ser escrita. Para uma ferramenta de campo hands-free ou um quiosque, esse é o recurso. Para um pipeline de documentos, é peso morto no orçamento de parâmetros.

A OrcaRouter tem na fusão de modelos a outra forma de obter ambos os comportamentos: um painel em que um especialista em documentos e um modelo omni respondem ao mesmo prompt e a resposta é composta a partir dos dois. Isso é uma capacidade do produto, e não uma afirmação sobre estes dois checkpoints — nenhum dos dois está no nosso catálogo hoje —, mas é a resposta arquitetural para um confronto em que cada modelo é claramente melhor em uma metade diferente da tarefa. A fusão custa mais por chamada do que o roteamento para um único modelo, e vale a pena exatamente quando uma resposta errada custa mais do que os tokens.

A decisão

Se o trabalho for leitura — OCR, faturas, formulários, gráficos, capturas de tela, PDFs longos, interfaces densas —, o MiniCPM-V 4.7 1B é o melhor modelo em todas as métricas publicadas, tem oito vezes mais contexto, é Apache-2.0 em vez de uma licença personalizada com limite de receita e é menor em disco. Não é uma decisão apertada, e o fato de ele ser chamado de modelo 1B não deve obscurecer isso.

Se o trabalho for uma conversa com um dispositivo que tem câmera e microfone, o LFM3-Omni-2B é o único dos dois que pode participar. Ele lê menos bem, retém menos contexto e é distribuído sob termos mais rígidos, e nada disso importa se a alternativa exigir três modelos e um pipeline.

Há um terceiro caso que vale a pena nomear: um produto que precisa dos dois, em que o caminho de documentos e o caminho de voz são recursos separados. Então a arquitetura correta não é um modelo, mas dois, roteados pelo tipo de solicitação — o reader para documentos, o modelo omni para voz — e a única questão é se você quer executar os dois ou deixar um único endpoint decidir. É a questão a que esta leva de comparações sempre chega, e é a certa. Os modelos são próximos o suficiente em pegada para que executar os dois seja uma opção real; são distantes o suficiente em capacidade para que executar apenas um seja um compromisso, seja qual for a sua escolha.

O que mudaria o veredito seria uma avaliação independente de qualquer um dos dois modelos, e especificamente uma que teste o MiniCPM na compressão padrão de 16× em vez da configuração de 4× usada nos seus números de destaque. Esse único número poderia fechar a maior parte da lacuna — ou ampliá-la. Até que alguém o publique, as tabelas dos fornecedores são o que temos, e elas apontam numa única direção.