LFM3-Omni-2B vs MiniCPM-V 4.7 1B: Cuando el modelo más pequeño lee mejor

Sobre el papel, esta no es una pelea justa. LFM3-Omni-2B tiene 2,17 mil millones de parámetros; MiniCPM-V 4.7 1B se comercializa como un modelo de 1B. El modelo más grande debería ganar los benchmarks de visión. No lo hace. MiniCPM obtiene 86,1 en OCRBench frente a 80,6, 69,5 en MMStar frente a 55,67, 56,9 en MMMU frente a 42,44 y 74,3 en MathVista frente a 62,5. Todos los benchmarks de visión que comparten ambas fichas favorecen al modelo con el nombre más pequeño, normalmente por un amplio margen, y MiniCPM además tiene ocho veces la ventana de contexto. Fusion cuesta más por llamada que enrutar a un único modelo. Se factura al precio de lista del proveedor sin ningún margen añadido.

Tres cosas explican eso, y ninguna de ellas es un defecto en ninguno de los dos modelos. MiniCPM-V 4.7 1B es un especialista que dedicó todo su presupuesto de parámetros a ver. LFM3-Omni-2B es un generalista que dedicó su presupuesto a ver, oír y hablar. Y la cifra de MiniCPM que más importa —86,1 en OCRBench— se midió con su ajuste de 4× tokens visuales, que intercambia cómputo por detalle de una forma que un límite de 2.048 tokens por imagen no puede. Entender ese intercambio es toda la decisión.

Por qué el modelo más pequeño lee mejor

MiniCPM-V 4.7 1B gira en torno a una única idea: comprimir los tokens visuales de forma temprana y permitir que el usuario elija cuánto comprimirlos. El modelo aplica una compresión de tokens de 4× o 16× dentro del codificador visual, antes de que el modelo de lenguaje vea nada. Con 16× es barato y rápido, adecuado para generar leyendas y descripciones de escenas. Con 4× conserva cuatro veces más tokens, que es lo que necesitan el OCR de documentos y la lectura de gráficos densos. Las cifras más destacadas de OpenBMB se presentan con la configuración de 4×.

LFM3-Omni-2B adopta el enfoque contrario. Procesa imágenes a resolución nativa, pero limita el presupuesto visual a 2048 tokens por imagen, y ese límite se comparte con un codificador de audio, una ruta de vídeo y un decodificador de voz dentro de una red densa de 2,17B. El techo de 2048 tokens es una opción razonable para un modelo que tiene que caber en un teléfono junto con otras tres modalidades. Es un techo rígido para la cantidad de detalle de página que puede llegar al modelo de lenguaje, y DocVQA 92,47 sugiere que el modelo le saca mucho provecho, pero OCRBench 80,6 indica que no basta para superar a un especialista que puede gastar 4× los tokens en la misma página.

Hay un segundo factor, más silencioso. La ventana de contexto de MiniCPM es de 262,144 tokens. La de LFM3-Omni-2B es de 32,768. Para una sola captura de pantalla, ninguno de los dos importa. Para un PDF de 40 páginas, un vídeo largo o una conversación de varios turnos sobre un documento, la diferencia no es una fila de un benchmark: es si la tarea es posible o no.

Especificación, sin el redondeo del marketing

Hay que corregir un dato antes de cualquier comparación. MiniCPM-V 4.7 1B se denomina modelo de 1B, y su número de parámetros densos es de aproximadamente entre 1300 y 1550 millones, según cómo se cuente la torre de visión. La barra lateral de Hugging Face lo redondea a "2B params", y así es como un modelo de 1B acaba pareciendo un modelo de 2B en un catálogo. El tamaño del archivo es la guía honesta: unos 3,1 GB en BF16, frente a 4,3 GB de LFM3-Omni-2B.

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

• Entradas — texto, imagen, vídeo con audio, audio de 16 kHz frente a texto, imagen, multiimagen y vídeo.

• Salidas — texto y voz de 24 kHz frente a solo texto.

• Contexto — 32.768 tokens frente a 262.144 tokens.

• Tokens visuales — limitados a 2.048 por imagen frente a la compresión conmutable de 4× o 16× dentro del codificador.

• Licencia — LFM Open License v1.0 frente a Apache-2.0.

• Lanzamiento — 27 de octubre de 2026 frente a 12 de octubre de 2026.

• Huella de memoria — alrededor de 4,3 GB en BF16 frente a alrededor de 3,1 GB en BF16, aproximadamente 5 GB de VRAM para servir.

Cada fila que comparten las dos tarjetas

La comparación es inusualmente limpia para una tabla entre laboratorios, porque ambos proveedores reportan los mismos cuatro conjuntos de datos de visión y ambos son modelos sin razonamiento evaluados en modo instruct. Sigue siendo dos evaluaciones de proveedores, y ninguna ha sido reproducida de forma independiente.

• OCRBench — 80,6 para LFM3-Omni-2B (806 de 1.000) frente a 86,1 para MiniCPM-V 4.7 1B. Una diferencia de 5,5 puntos en el reconocimiento de texto en documentos.

• MMStar — 55,67 frente a 69,5. Una diferencia de 13,8 puntos, la mayor del conjunto.

• Validación MMMU — 42,44 frente a 56,9. Una diferencia de 14,5 puntos en razonamiento multimodal de nivel universitario.

• MathVista mini — 62,50 frente a 74,3. Una diferencia de 11,8 puntos en matemáticas visuales.

Cuatro filas, cuatro derrotas, diferencias de entre cinco y quince puntos. No hay ninguna fila en la que gane el modelo omni, lo que es un resultado más limpio que el que produjo la comparación entre LFM3 y LFM2.5, y más difícil de justificar. La interpretación más defendible es que un especialista de 1,4B con un contexto de 256K y un presupuesto de tokens 4× es simplemente un mejor lector que un generalista de 2,17B con un contexto de 32K y un límite de imagen de 2.048 tokens. La capacidad invertida en una sola modalidad supera a la capacidad repartida entre cuatro, a esta escala.

Dos advertencias deben mencionarse en la misma frase, porque ninguna de las dos fichas las ofrece por iniciativa propia. El 86,1 de MiniCPM se mide con una compresión de 4×, y el mismo modelo con su configuración predeterminada de 16× obtendría una puntuación menor y sería más barato de ejecutar; la ficha no publica esa cifra. Y la ficha del modelo de OpenBMB no incluye ninguna tabla de benchmarks; las cifras aparecen como texto corrido e imágenes de gráficos en la página del producto, lo que constituye una forma de publicación más débil que una tabla con una nota metodológica. Ambos conjuntos de cifras son afirmaciones del fabricante. La dirección de la diferencia es lo bastante consistente como para que probablemente sobreviva a pruebas independientes; el tamaño exacto, probablemente no.

El contexto es la fila que decide las cargas de trabajo reales.

Un contexto de 32K es generoso para una sola imagen y limitado para un documento. Con aproximadamente 2.048 tokens visuales por imagen, LFM3-Omni-2B puede albergar alrededor de una docena de imágenes completas en su ventana antes de que el historial de conversación empiece a competir por espacio. Los 262.144 tokens de MiniCPM-V 4.7 1B no son una mejora modesta; son una clase de carga de trabajo diferente. Los PDF largos, los formularios de varias páginas, los resúmenes de vídeos de una hora y los bucles de agentes que mantienen capturas de pantalla en el contexto son factibles con 256K y se ven limitados con 32K.

Esta es la diferencia menos comentada y más trascendental entre los dos modelos. Las tablas de benchmarks premian la precisión con una sola imagen; los flujos de trabajo de documentos en producción fallan en la decimocuarta página. Si tu caso de uso implica más que un puñado de imágenes por conversación, la ventana de 32K es un límite más duro que cualquiera de las cuatro brechas de benchmark anteriores.

Lo que MiniCPM no puede hacer

No puede oír. No hay ninguna ruta de entrada de audio, ni salida de voz, ni gestión de la pista de sonido del vídeo. Si la aplicación consiste en una persona hablando con un dispositivo sobre lo que ve la cámara, MiniCPM-V 4.7 1B es un componente de una pipeline que necesita al menos dos modelos más —un sistema ASR y un sistema TTS— además de la conexión necesaria para mover el texto entre ellos.

LFM3-Omni-2B condensa ese pipeline en un único checkpoint de 4,3 GB. Sus resultados en audio no son destacables frente a modelos dedicados al habla —ASR en inglés con una tasa de error de palabras de 6,36, VoiceBench 64,73—, pero existen dentro de la misma pasada hacia adelante que la ruta de visión, lo que significa que el modelo puede responder una pregunta hablada sobre una imagen sin que llegue a escribirse una transcripción. Para una herramienta de campo manos libres o un kiosco, esa es la función clave. Para un pipeline de documentos, es peso muerto en el presupuesto de parámetros.

de OrcaRouterLa fusión de modelos es la otra forma de obtener ambos comportamientos: un panel donde un especialista en documentos y un modelo generalista responden al mismo prompt y la respuesta se compone a partir de ambos. Eso es una capacidad del producto más que una afirmación sobre estos dos checkpoints —ninguno está en nuestro catálogo hoy—, pero es la respuesta arquitectónica a un emparejamiento en el que cada modelo es claramente mejor en una mitad diferente del trabajo. La fusión cuesta más por llamada que enrutar a un solo modelo, y merece la pena exactamente cuando una respuesta incorrecta cuesta más que los tokens.

La decisión

Si el trabajo es leer —OCR, facturas, formularios, gráficos, capturas de pantalla, PDF largos, interfaces de usuario densas—, MiniCPM-V 4.7 1B es el mejor modelo en todas las métricas publicadas, tiene ocho veces más contexto, es Apache-2.0 en lugar de una licencia personalizada con un umbral de ingresos, y es más pequeño en disco. No es una decisión reñida, y el hecho de que se le denomine un modelo 1B no debería ocultarlo.

Si el trabajo consiste en una conversación con un dispositivo que tiene cámara y micrófono, LFM3-Omni-2B es el único de los dos que puede participar. Lee peor, retiene menos contexto y se distribuye bajo términos más estrictos, y nada de eso importa si la alternativa requiere tres modelos y un pipeline.

Hay un tercer caso que vale la pena mencionar: un producto que necesita ambos, donde la ruta de documentos y la ruta de voz son funciones separadas. Entonces, la arquitectura correcta no es un modelo, sino dos, enrutados según el tipo de solicitud: el modelo de lectura para documentos y el modelo omni para voz; y la única pregunta es si quieres ejecutar ambos o dejar que un único endpoint decida. Esa es la pregunta a la que no deja de llegar este conjunto de comparaciones, y es la correcta. Los modelos tienen una huella lo bastante parecida como para que ejecutar ambos sea una opción real; sus capacidades están lo bastante distanciadas como para que ejecutar solo uno sea un compromiso, elijas el que elijas.

Lo que cambiaría el veredicto es una evaluación independiente de cualquiera de los dos modelos, y en concreto una que pruebe MiniCPM con su compresión predeterminada de 16× en lugar del ajuste de 4× que usan sus cifras destacadas. Ese único número podría cerrar la mayor parte de la brecha —o ampliarla. Hasta que alguien lo publique, las tablas del fabricante son lo que tenemos, y apuntan en una sola dirección.