MiniCPM-V 4.7 mete un modelo de visión de 35B en 3 GB: desentrañando la afirmación de 100 tok/s

Un modelo de 35 mil millones de parámetros no cabe en tres gigabytes. MiniCPM-V 4.7 35B-A3B funciona de todos modos en unos tres gigabytes, y ambas afirmaciones son ciertas: ese es justamente el truco, y la razón por la que vale la pena detenerse en las cifras que circulan sobre este lanzamiento. El modelo es la primera entrada de mezcla dispersa de expertos de la línea MiniCPM-V de OpenBMB: 35,2 mil millones de parámetros almacenados, unos 3 mil millones activos por token, Apache-2.0, pesos en Hugging Face. Lee imágenes, conjuntos de varias imágenes y vídeo, y responde en texto. Desde el 10 de octubre también se ejecuta en llama.cpp upstream, que es donde la mayoría de la gente lo conoció. Lo que sigue separa las tres cifras que todo el mundo repite —3 GB, 35B y la cifra de 100 tok/s— y muestra cuáles de ellas publicó realmente OpenBMB. Más de 200 modelos alojados, una sola clave, la lista de precios del proveedor repercutida con un 0 % de margen. Descubre a dónde enruta OrcaRouter El checkpoint de pesos abiertos se queda en tu hardware; la vía de escape alojada es un único endpoint. Los fallos de IA y los incidentes de agentes documentados que hay detrás de lanzamientos como este se recopilan en el Archivo de Incidentes de IA de OrcaRouter donde cada entrada incluye sus propias fuentes, su gravedad, su grado de confianza y su indicador de disputa.

Tres gigabytes, treinta y cinco mil millones de parámetros y ninguna contradicción

La aritmética solo parece imposible si se asume que "en memoria" significa "todo". MiniCPM-V 4.7 35B-A3B mantiene residentes unos 3000 millones de parámetros y va incorporando por streaming el resto de los expertos a medida que el enrutador los solicita —la propia formulación de la tarjeta del modelo es Lookahead Expert Scheduling, un predictor de enrutamiento entre capas que precarga los expertos que la siguiente capa probablemente necesite, solapando esa carga con el cómputo ya en curso. La tarjeta se cuida de señalar que la predicción solo impulsa la precarga y la programación; los tokens siguen el enrutamiento real del modelo, y un experto que el predictor no haya anticipado se carga y se evalúa como cualquier otro.

Esa distinción tiene una consecuencia medible. El repositorio GGUF publica el modelo completo en cada cuantización común, y ninguno de esos archivos ocupa tres gigabytes:

• Q4_K_M — 21,2 GB en disco.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Proyector de visión — 0,9 GB con compresión 4x, 1,1 GB en f16.

Así que «3 GB» es una cifra de memoria residente con streaming de expertos en un teléfono, no un tamaño de descarga ni un requisito de VRAM para un equipo de escritorio. Si estás planeando un despliegue, el número que rige tu disco y tu primera carga es 21,2 GB en Q4_K_M, y el número que rige tu huella en estado estacionario en un teléfono es el ~3 GB del proveedor. Ambas cifras están en el lanzamiento. Responden a preguntas distintas, y la mayoría de la cobertura los ha fusionado en uno.

De dónde proceden los 100 tok/s y de dónde no

Esta es la parte sobre la que conviene ser franco. OpenBMB no publica una cifra de 100 tok/s para MiniCPM-V 4.7. El número que aparece en la tarjeta del modelo es 13+ tokens/s, en un iPhone 17 Pro Max, con aproximadamente 3 GB de memoria. Esa es la única afirmación sobre la velocidad de procesamiento en el dispositivo que hace el lanzamiento, y está medida por el fabricante en un hardware que nadie fuera del laboratorio ha reproducido.

Existen números más altos, y provienen de un artefacto diferente. El fork llama.cpp-omni de OpenBMB —el repositorio que contiene las optimizaciones para dispositivos— publica su propia tabla para el objetivo 35B-A3B, organizada según qué optimizaciones están activadas:

• iPhone 18 Pro Max, 12 GB — 3.38 tok/s de línea base, 11.34 con Lookahead Expert Scheduling, 17.16 al añadir precisión mixta y 20.51 también con la cabeza de borrador DSpark.

• iPad Pro de 11 pulgadas M4, 16 GB — 2,97 tok/s de referencia, 9,81 con LES, 14,92 con precisión mixta, 17,39 con DSpark.

Esas son las cifras más altas publicadas en dispositivo para este modelo, y lo más alto de la escala es 20,51 tok/s: una quinta parte de 100. La diferencia importa porque cambia para qué sirve el modelo. A 13 tok/s, una app móvil responde a una pregunta sobre una foto en un par de segundos. A 100 tok/s, lo considerarías como un lector de primera pasada en streaming para vídeo. Lo primero es un producto real. Lo segundo no es lo que se lanzó, y cualquiera que haga presupuesto con la cifra del tuit se llevará una decepción de un factor de cinco.

La lectura honesta de la afirmación de 100 tok/s es que se trata de una compresión de tres hechos separados —3 GB, se ejecuta localmente, más rápido que la generación anterior por un amplio margen— en un único número que ninguna de las fuentes contiene. La mejora de una generación a otra es real y grande: pasar de 3,38 a 20,51 tok/s supone un avance de 6x en la misma clase de dispositivo, logrado combinando tres técnicas en lugar de mediante un chip más grande.

El lanzamiento no fue de un solo día, y las fechas importan.

MiniCPM-V 4.7 salió a la luz como suelen hacerlo ahora muchos lanzamientos de pesos abiertos: primero los archivos, después la explicación, y el soporte del framework en algún punto intermedio.

• 6 de octubre, 17:40 UTC — el modelo 1B y sus variantes AWQ, GPTQ e int4 aparecen en Hugging Face, junto con las compilaciones GGUF a las 18:05.

• 7 de octubre, 07:07 UTC — aparece el repositorio 35B-A3B. Todavía no hay ficha del modelo.

• 8 de octubre — cabezas de decodificación especulativa DSpark para ambos tamaños, y una compilación FP8 del 35B.

• 10 de octubre, 18:42 UTC — llama.cpp integra el soporte del modelo.

• 12 de octubre — OpenBMB registra la ficha del modelo, declara la licencia Apache-2.0 y anuncia el lanzamiento como un producto documentado.

• 15 de octubre — las cabezas DSpark están enlazadas desde la tarjeta principal, con borradores GGUF para ambos objetivos.

Ese orden explica gran parte de la confusión en la cobertura secundaria. Alguien que conoció el modelo a través de llama.cpp en la segunda semana de octubre estaba ejecutando una versión que oficialmente aún no existía, sin etiqueta de licencia ni gráfico de benchmarks, y sus cifras de throughput reflejan las propias decisiones de cuantización del framework en lugar de cualquier cosa que OpenBMB haya evaluado con benchmarks.

Soporte de llama.cpp: fusionado, y no del todo terminado

La pull request upstream que añadió MiniCPM-V 4.7 es inusualmente clara sobre lo que cambió, y la respuesta es: casi nada a nivel de arquitectura. El modelo es casi idéntico a MiniCPM-V 4.6; la diferencia es 3D RoPE, una posición de tres valores por token —tiempo, fila, columna— en lugar del único escalar que usan la mayoría de los modelos de visión-lenguaje. El soporte extiende la ruta existente de 4.6 para transportar esa dimensión adicional. La PR también indicó que el modelo era «próximo» cuando se abrió el 25 de septiembre, lo que es una buena pista sobre lo temprano que estaban en circulación los pesos.

Vale la pena conocer el residuo antes de construir sobre él una función de grounding. Desde ese merge, upstream llama.cpp asigna a los tokens marcadores de imagen posiciones incorrectas en los prompts de MiniCPM-V 4.7: los tokens de imagen en sí quedan bien, pero <slice>, </slice> y los marcadores de fin de fila se numeran como texto plano en lugar de recibir las coordenadas de las esquinas de sus tiles, como hace la implementación de referencia get_rope_index. El síntoma visible es que las coordenadas devueltas quedan sistemáticamente bajas cuando preguntas dónde está algo en una imagen. Existe una corrección con una prueba unitaria en una pull request abierta, fechada el 14 de octubre, y a fecha del 20 de octubre sigue abierta. Si tu carga de trabajo es «describe esto», no lo notarás. Si es «dame la caja delimitadora», lo notarás, y deberías esperar al merge o usar el fork que incluye la ruta corregida.

Una cosa más sobrevive al viaje de ida y vuelta: para el modelo 1B, el proyector de visión es la descarga más grande. Los pesos Q4_K_M son 672 MB; el proyector f16 es de 1.11 GB. Por lo tanto, el despliegue útil más pequeño de 1B ocupa unos 1.8 GB de archivos, la mayor parte ojos en lugar de lenguaje — un detalle que cualquier expectativa de «1B significa 1 GB» pasa por alto.

Qué ejecutar y en qué

Si el objetivo es probarlo esta semana, la vía de menor fricción es llama.cpp u Ollama con los repositorios GGUF, apuntando el cliente multimodal al archivo mmproj correspondiente. En una GPU de 24 GB, Q4_K_M con 21,2 GB deja muy poco margen para el contexto: una ventana de 8K tokens más los mosaicos de imagen no cabrán cómodamente, así que plantéate Q4_K_S o una cuantización menor si además quieres un prompt largo. En un Mac con 32 GB o más, Q8_0 es viable y es lo más parecido al comportamiento de referencia. En un teléfono, solo las propias apps del fabricante y el fork llama.cpp-omni incorporan el trabajo de programación de expertos; llama.cpp estándar te da corrección, no los 20 tok/s.

Donde una capa de enrutamiento se gana su lugar aquí es en el lado remoto de la llamada local. Un modelo de 3B activos en un teléfono es excelente para el trabajo rutinario —lee este recibo, ¿esta estantería parece tener existencia, qué dice este letrero— y de vez en cuando se topará con una página que no puede terminar. OrcaRouter pone más de 200 modelos alojados detrás de una sola clave, transfiere el precio de lista de cada proveedor con un 0 % de margen, de modo que un cambio de precio del proveedor se refleja el mismo día, y conmuta automáticamente cuando un servicio upstream se degrada. El patrón que funciona es local primero, con una vía de escape alojada, no solo local. El checkpoint de pesos abiertos sigue siendo tuyo para alojarlo; el enrutador se encarga de todo lo que el teléfono delega.

MiniCPM-V 4.7 no es servido por OrcaRouter, y no vamos a insinuar lo contrario. Es un checkpoint que ejecutas tú mismo.

¿Qué determinaría los tres números?

Una medición independiente del modelo de 35B en un teléfono concreto, con la app y la cuantización indicadas, resolvería la cuestión del rendimiento, incluido si 20,51 tok/s sobrevive al cronómetro de otra persona. Una definición publicada de la cifra de 3 GB —conjunto residente, asignación máxima o algo más— resolvería la cuestión de la memoria. Y una tabla por benchmark con puntuaciones reales, en lugar de los cinco gráficos enlazados que incluye actualmente la ficha, permitiría comprobar la afirmación «mejor que Qwen3.6 35B-A3B en menos tiempo» con la ponderación que eligió OpenBMB. Ninguna de esas cosas existe todavía. Hasta que existan, la frase correcta es la aburrida: un modelo disperso de 35B que se ejecuta en un teléfono a unos 13 tokens por segundo o más, según lo reportado, en unos 3 GB, con una descarga de 21 GB y una ruta de framework fusionada que todavía tiene un error de coordenadas abierto.