Una pagoda de vóxeles, un 10 % menos de tokens y la única frase que OpenBMB realmente respalda

La frase más citada esta semana sobre MiniCPM-V 4.7 35B-A3B no está en su ficha del modelo. Es un tuit publicado el 13 de octubre de 2026 que dice: «MiniCPM-V 4.7 35B-A3B no solo usó menos tokens, sino que además produjo una pagoda de vóxeles mejor que Qwen 3.6 35B-A3». La demostración a la que apunta es un video de dos modelos de lenguaje escribiendo cada uno el código de una pagoda japonesa de vóxeles en 3D, renderizados lado a lado. Es un artefacto genuinamente interesante: muestra a un modelo de visión-lenguaje reproduciendo en tres dimensiones una estructura construida a partir de un prompt de imagen, lo cual es una tarea más difícil que describir una. Pero vale la pena separar lo que ese tuit es de lo que no es, porque se han fusionado tres afirmaciones distintas en una sola línea, y tienen tres niveles distintos de respaldo. MiniCPM-V 4.7 35B-A3B es un checkpoint real de OpenBMB y tiene aproximadamente una semana. Qwen3.6-35B-A3B es un rival de pesos abiertos de nueve meses, también Apache-2.0, también una mezcla dispersa de expertos del mismo tamaño nominal. Todo lo que sigue trata sobre cuál de las afirmaciones de eficiencia en torno a ellos es verificable y cuál es un JPEG de una gráfica.

Tres afirmaciones vistiendo una sola oración

El tuit reúne tres cosas separables, y merecen separarse porque solo una de ellas está documentada.

• "Usó menos tokens" — esta es una afirmación medible sobre el consumo de tokens para una tarea. La cifra que circula junto con la demostración es un 10% menos de tokens que Qwen3.6 35B-A3B. Ese número proviene del creador externo que realizó la comparación, no de la evaluación de OpenBMB, y es un único par de prompts, no un benchmark.

• "Produjo una mejor pagoda de vóxeles": esto es un juicio, hecho al mirar dos pagodas renderizadas. No hay rúbrica, ni sistema de puntuación, ni una parte independiente. Es el tipo de afirmación que un humano hace en tres segundos y que un benchmark no puede hacer en absoluto, porque "mejor pagoda" no tiene una verdad de referencia.

• “La eficiencia más la calidad es el verdadero campo de batalla” — esa parte es una tesis, y resulta que es la que OpenBMB sí defiende por escrito, con números incluidos, en la ficha del modelo. Simplemente no es la frase que trascendió.

Esto importa porque las dos primeras afirmaciones son las memorables y la tercera es la defendible. Si estás decidiendo si gastar 70 GB de descarga en un checkpoint, quieres la tercera.

Lo que OpenBMB escribió realmente, y cuándo

Primero la cronología, porque el relato repetido la ha comprimido. Los pesos se subieron sin hacer ruido: openbmb/MiniCPM-V-4.7-1Bse creó el 6 de octubre de 2026 a las 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bel 7 de octubre a las 07:07 UTC. Ninguno de los dos llevaba una tarjeta de modelo, una etiqueta de licencia ni un benchmark en ese momento —esto se cubrió aquí en su momento, y era una situación extraña para una subida de 35 mil millones de parámetros. Seis días después, el 12 de octubre de 2026, OpenBMB incorporó la documentación de una sola vez: tarjeta de modelo, licencia Apache-2.0, gráficos de evaluación, un README del repositorio reescrito que ponía al frente la nueva serie y un anuncio. Los parámetros no cambiaron ese día. La explicación sí.

Así que la formulación honesta no es «MiniCPM-V 4.7 35B-A3B se lanzó esta semana». Es «MiniCPM-V 4.7 35B-A3B se volvió legible esta semana». Todo lo que ahora se puede citar sobre él o se subió los días 6 y 7 pero no está documentado, o se escribió el día 12 y es una afirmación del proveedor.

La afirmación que sí hace la tarjeta del modelo

Aquí está la frase, textual de la tarjeta, y es más limitada que el tuit: en modo Instruct, la variante 35B-A3B «logra una puntuación general más alta en menos tiempo de inferencia que Qwen3.6 35B-A3B». Eso es todo. Sin recuento de tokens, sin margen, sin desglose por benchmark en prosa. La evidencia que la respalda es un diagrama de dispersión —puntuación media de evaluación en el eje vertical, tiempo de inferencia en segundos en una escala logarítmica en el eje horizontal— en el que MiniCPM-V 4.7 35B-A3B se sitúa por encima y a la izquierda de Qwen3.6-35B-A3B. La propia nota al pie del gráfico define el promedio como la media de cinco benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK y MathVista. Los círculos indican el modo Instruct, los rombos indican el modo Thinking.

Esa es una afirmación real y específica sobre una disyuntiva bidimensional, y es lo más contundente del comunicado. También vale la pena señalar lo que el gráfico no puede decirte: no hay etiquetas numéricas en los puntos representados, así que no puedes leer directamente una puntuación ni un tiempo, solo una dirección. La dirección, tal como está dibujada, favorece a MiniCPM en ambos ejes a la vez.

Y fue medido por el proveedor. Las cifras de evaluación de la tarjeta del modelo llevan la frase «Los resultados provienen de informes públicos y de nuestra evaluación local usando checkpoints oficiales». Evaluación local significa el hardware de OpenBMB, el arnés de OpenBMB, la selección de modo de OpenBMB. Eso es algo normal para una tarjeta de modelo y algo anómalo de hacer pasar por hecho. Ninguna parte independiente ha ejecutado estos dos checkpoints con un arnés compartido. Ninguna tabla de clasificación ha indexado ninguno de los dos resultados. Al momento de escribir esto, la afirmación tiene exactamente una fuente, y la fuente vende el modelo.

De dónde se supone que viene la eficiencia de tokens

El argumento de eficiencia no se apoya en el gráfico comparativo. Se apoya en tres decisiones de ingeniería, y vale la pena entenderlas porque determinan si la ventaja se traslada a tu hardware o no.

• Lookahead Expert Scheduling (LES) — la técnica estrella. Una mezcla dispersa de expertos almacena muchos más parámetros de los que activa por token, y en un dispositivo que no puede contener todos los expertos en memoria, los pesos se paginan hacia adentro y hacia afuera y la decodificación se atasca. LES utiliza la predicción de enrutamiento entre capas para precargar expertos que probablemente necesite la siguiente capa, y prioriza la computación para los expertos que el enrutador real seleccionó realmente y que resulta que ya están cargados. OpenBMB se cuida de afirmar que la predicción impulsa únicamente la precarga y la programación; el enrutamiento a nivel de token del modelo no cambia, y los expertos que el predictor no detectó todavía se cargan y se evalúan. La tarjeta afirma una aceleración de 5× en dispositivos reales gracias a esto, sin pérdida de capacidades.

• Cuantización de grano fino por capas — reduce la huella de los pesos de los expertos y el tráfico de memoria, que es la otra mitad para lograr que un patrón de carga en el dispositivo encaje.

• Muestreo especulativo de DSpark: una ruta de modelo borrador emparejada, publicada por separado como openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, e integrada junto con el trabajo de planificación y cuantización.

Apilados, estos producen la cifra estelar del lanzamiento: más de 13 tokens por segundo usando aproximadamente 3 GB de memoria en un iPhone 17 Pro Max. Esa es una cifra del proveedor, en hardware del proveedor, con software del proveedor —una app escrita por OpenBMB. Es el tipo de afirmación que o es todo el producto o no es nada, y actualmente no hay forma de que alguien fuera de la compañía pueda comprobarla, porque reproducirla requiere la pila en el dispositivo que usa la demo del teléfono.

La eficiencia de tokens es real, pero aquí es una matriz, no un escalar.

Hay un detalle en este lanzamiento que ha quedado diluido en todos los resúmenes del mismo, y es el que realmente rige la economía del token.

• MiniCPM-V 4.7 35B-A3B admite compresión mixta de tokens visuales de 4x y 16x, seleccionable por solicitud. La configuración de 16x fusiona tokens visuales para ganar velocidad; 4x conserva cuatro veces más, para mayor detalle. El valor predeterminado de la tarjeta es 16x, y el parámetro debe pasarse tanto a la plantilla de chat como a la llamada de generación, o el recuento de marcadores de posición y el codificador de visión no coincidirán.

• La propia tabla comparativa de visión-lenguaje del proveedor registra el ajuste de compresión usado para la fila de cada modelo. En esa tabla, la fila de MiniCPM-V 4.7 35B-A3B está en 4x —el ajuste que preserva el detalle, es decir, el caro— y la fila de Qwen3.6 35B-A3B está en 16x. Una fila de Gemma 4 de 31B aparece en 9x; las dos filas de Qwen de 27B, en 4x.

• Una nota al pie indica claramente que MiniCPM-V 4.7 admite cualquiera de las dos configuraciones, mientras que los demás modelos de la tabla solo admiten una relación de compresión fija.

Si se lee eso en conjunto, el panorama cambia. Si la fila de MiniCPM obtiene sus puntuaciones de visión-lenguaje con la configuración que consume muchos tokens, mientras que la fila de Qwen obtiene sus puntuaciones con la que ahorra tokens, entonces las dos columnas están comparando distintas cantidades de detalle visual, y el relato de la eficiencia no es «misma entrada, menos tokens» — es «entrada ajustable, y esta es la columna que gana en calidad». Esa es una afirmación más interesante y más honesta que la del tuit, y OpenBMB la publicó en una nota al pie en lugar de ponerla al frente.

También significa que el número que realmente te importa —tokens por unidad de detalle visual— no se puede leer de esta tabla en absoluto. Requiere ejecutar ambos modelos con la misma configuración, algo que nadie ha publicado.

La tabla, con las salvedades adjuntas

La tarjeta incluye dos tablas del proveedor, una para visión-lenguaje y otra para lenguaje, ambas en modo Instruct, ambas frente a un conjunto que incluye dos modelos Qwen de la clase 35B-A3B, una Gemma de 31B y dos Qwen de 27B. Las cifras a continuación se leyeron del propio gráfico PNG del proveedor, y la advertencia es estructural: los números existen solo como píxeles en ese gráfico, no como una tabla, por lo que lo que sigue se extrajo mediante lectura automática y es posible que haya pequeños errores de transcripción.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 frente a Qwen3.6 35B-A3B con 90,40. Una diferencia de 0,8 puntos, según la propia ejecución del proveedor.

• OmniDocBench v1.6 — aproximadamente 98,2 para MiniCPM frente a aproximadamente 93,3 para el modelo Qwen, que es la mayor diferencia individual de la tabla y la que más importaría si se reprodujera, ya que el análisis de documentos es donde suelen gastarse los presupuestos de tokens.

• MMMU — aproximadamente 80,2 frente a 80,0, un empate técnico a la resolución de una imagen de gráfico.

• MMMU-Pro — aproximadamente 69,7 frente a 67,7, en una fila donde un Qwen de 27B se sitúa por encima de ambos.

• Tabla de idiomas: la misma forma, con las celdas más llamativas en seguimiento de instrucciones y código. IFBench figura en torno a 47,7 frente a 35,3, y LiveCodeBench-v6 en torno a 97,0 frente a 54,3. Esas dos son lo suficientemente grandes como para tratarlas como las celdas menos creíbles de la versión hasta que alguien más las ejecute: una diferencia de 43 puntos en un benchmark de código entre dos modelos MoE abiertos de tamaño similar, medida por una de las dos partes, es una afirmación que necesita un segundo instrumento.

Informado por el proveedor, ejecutado en el arnés del proveedor, no reproducido. Eso es todo. Si estas cifras se sostienen en un arnés independiente, la afirmación de la frontera de Pareto es correcta y el vídeo de la pagoda es una nota al pie. Si no se sostienen, el vídeo de la pagoda es todo lo que hay.

Lo que dicen los números de adopción, lo cual no tiene nada que ver con la calidad.

Hay un número en esta comparación que nadie discute, y no es un benchmark. El contador de descargas de Hugging Face, consultado el 13 de octubre de 2026, muestra 630 para openbmb/MiniCPM-V-4.7-35B-A3Bfrente a unos 3,6 millones deQwen/Qwen3.6-35B-A3B— un repositorio creado el 15 de abril de 2026 y que, por lo tanto, lleva unos nueve meses más recorrido en la curva de adopción. Esa brecha mide tiempo, no mérito, y es la razón por la que la cuestión de la eficiencia se plantea en esta dirección: el recién llegado tiene que argumentar por token precisamente porque no ha tenido nueve meses para ser la opción por defecto.

También hay una pequeña contradicción interna en la ficha que vale la pena señalar. El repositorio lleva la etiqueta «On-Device Model» heredada del resto de la familia, y un MoE disperso de 35,2 mil millones de parámetros en 70,4 GB de pesos BF16 no es on-device en ningún sentido que reconociera alguien que lo descarga. La historia on-device es real, pero pasa por la cuantización y el streaming de expertos sobre el checkpoint, no por el checkpoint. Presupuesta con la compilación cuantizada y la app, no con la etiqueta.

Qué hacer al respecto esta semana

La postura práctica es estrecha y clara. Si quieres que se verifique la afirmación de eficiencia, todavía no hay nada que verificar: es el gráfico de un solo proveedor, y el único número con una cifra por tarea adjunta (10 % menos tokens, una pagoda) proviene de una sola demo de un tercero. Si quieres ejecutar el modelo, los pesos son Apache-2.0, la arquitectura está documentada y la configuración de submuestreo es tuya para elegir, lo cual es una palanca genuina y poco valorada: 16x cuando importa el rendimiento, 4x cuando el gráfico te está mostrando un documento.

Una mitad de esta comparación es accesible hoy a través de una API alojada y la otra no, y merece la pena ser precisos sobre cuál es cuál. qwen/qwen3.6-35b-a3bes un modelo alojado en OrcaRouter — se encuentra en el catálogo detrás de una sola clave, al precio de lista del propio Qwen sin nada añadido, y se despacha al proveedor que esté en buen estado en lugar de a uno que hayas fijado. MiniCPM-V 4.7 no está alojado por nosotros; es un checkpoint de pesos abiertos que sirves tú mismo. Esa asimetría es lo útil aquí. Puedes poner el lado Qwen de esta comparación en una línea base esta tarde, ejecutar el arnés de OpenBMB sobre tus propios datos contra él, y dejar que el gráfico del proveedor sea la hipótesis en lugar de la respuesta.

Que, dado que todo el argumento trata sobre la eficiencia en tu hardware, es la única medición que alguna vez iba a zanjarlo.