Los "3B parámetros activos" de MiniCPM-V 4.7 no están en la ficha del modelo: los medí a partir de los pesos

El número más repetido sobre MiniCPM-V 4.7 35B-A3B no aparece impreso en ninguna parte de su propia documentación. La afirmación —«solo 3B de parámetros activos (!) — se ejecuta incluso en un iPhone»— proviene de una publicación de terceros del 13 de octubre de 2026, y la ficha del modelo, el README del repositorio y las notas de lanzamiento del proveedor no indican ninguna cifra de parámetros activos en absoluto. Eso no es tanto una crítica a la afirmación como una laguna que vale la pena cerrar: el checkpoint codifica su propia respuesta. Así que, antes que nada, extraje el índice de safetensors y el encabezado de cada shard de openbmb/MiniCPM-V-4.7-35B-A3B y conté. A modo de comparación, el otro modelo de la misma publicación —Qwen3.8-27B, publicado el 13 de agosto de 2026— es un modelo denso de 27B y no tiene tal ambigüedad que resolver: todos los parámetros están activos en cada token. La pregunta interesante es si «3B activos» sobrevive al contacto con los pesos, y la respuesta es: sobrevive, pero solo si defines la palabra «activo» como lo define el proveedor, y el número honesto se acerca más a 4B una vez que cuentas las partes que no puedes evitar ejecutar.

El libro mayor, leído desde el propio punto de control

El archivo de índice enumera 40 capas de lenguaje, además de una torre de visión y un proyector, 35.212.875.824 parámetros en total en BF16 — 70,43 GB de pesos para descargar. Eso coincide con el "35B" del nombre. La cuestión de MoE es qué fracción de eso se toca por token:

• Total almacenado — 35,21 mil millones de parámetros, 70,43 GB en BF16. Todos los expertos están en disco, se usen o no.

• Presupuesto del router — 8 expertos seleccionados por token, de 256, por capa MoE. Configurado en config.json como num_experts_per_tok: 8. Cada experto es pequeño: 3,15 M de parámetros.

• Ruta MoE por capa — 8 expertos (25.17M) + un experto compartido (3.15M) + la puerta del enrutador (0.52M) ≈ 28.83M.

• Ruta de atención por capa — la arquitectura es híbrida: 30 de las 40 capas usan atención lineal (33,72 M cada una), 10 usan atención completa (27,26 M cada una). Total ≈ 2,44 B en las 40 capas para la atención más la aritmética de MoE, repetido por token.

Además, lo que no puedes omitir — embeddings de tokens 508,2 M, cabeza LM 508,2 M, torre de visión 522,3 M, proyector 30,7 M.

• Las dos respuestas defendibles — ~2.44B activos solo en la ruta de atención y MoE; ~4.01B si se cuentan los embeddings, la cabeza de salida, la torre de visión y el proyector, que una solicitud de visión sí pone en juego.

Así que "3B active" no es incorrecto. Es un redondeo al alza de 2.44B, y cae en la brecha entre los dos números anteriores. Simplemente no es una cifra que OpenBMB haya publicado, y no es lo mismo que el sufijo "A3B": ese sufijo es parte del nombre del modelo, y los materiales del propio proveedor nunca lo convierten en una medición.

Por qué el sufijo y el número no son lo mismo

Las convenciones de nomenclatura en el ecosistema de pesos abiertos implican un recuento de parámetros activos: un modelo llamado 30B-A3B, o 235B-A22B, te está diciendo que activa aproximadamente esa cantidad de parámetros por token. La implicación suele ser fiable, pero es una convención, no un contrato, y MiniCPM-V 4.7 es un caso en el que nada en la ficha, el README ni la publicación de lanzamiento convierte el "A3B" en un número con el que puedas planificar la memoria. Hasta que alguien haga el recuento, el sufijo es una etiqueta.

El recuento anterior es aritmética, no una inferencia a partir de esa etiqueta. También es la razón por la que las cifras de ~2.44B y ~4.01B difieren: contar o no la tabla de embeddings y la cabeza de salida es una decisión real, no pedantería. En un modelo denso, los embeddings son una pequeña porción de un presupuesto de 27B. En un modelo disperso donde la ruta de cómputo por token es de solo unos pocos miles de millones de parámetros, una tabla de embeddings de 508M y una cabeza LM de 508M ya no son ruido — juntas representan alrededor de una quinta parte de la ruta activa, y se almacenan a ancho completo mientras los expertos están cuantizados.

Una consecuencia que vale la pena decir sin rodeos: la proporción entre parámetros almacenados y activos aquí es de aproximadamente 8,8 a 1 en la lectura estricta. Esa es la razón de que un modelo de 35B pueda presentarse como un modelo de teléfono, y también es la razón de que no lo sea del modo en que lo es un modelo denso de 3B. El almacenamiento no se reduce cuando el enrutador ignora a un experto.

La afirmación sobre el iPhone es una afirmación aparte con una base de evidencia aparte.

Todo lo concreto sobre el rendimiento en el dispositivo en esta versión está reportado por el proveedor y no ha sido reproducido. La cifra específica es de 13+ tokens por segundo con alrededor de 3 GB de memoria en un iPhone 17 Pro Max, con el mismo checkpoint demostrado en un iPad M4. OpenBMB lo atribuye a tres técnicas que trabajan en conjunto —Lookahead Expert Scheduling, que predice el enrutamiento entre capas y precarga expertos, la cuantización de grano fino capa por capa y el muestreo especulativo DSpark— y describe el resultado como el primer modelo MoE de código abierto que se ejecuta sin problemas en el dispositivo sin perder capacidad. No existe ninguna medición independiente de ese rendimiento en el registro público, ninguna reproducción por terceros y ningún desglose publicado de qué cuantización asume la cifra de 3 GB.

Esto importa por una razón concreta: 3 GB es el número que determina si la afirmación te resulta interesante, y es el número del que sabemos menos. Un MoE de 35B cuyos pesos de expertos residen en su mayoría en almacenamiento flash no es un modelo de 3 GB, es un modelo cuyo conjunto de trabajo residente resulta caber en 3 GB una vez que las predicciones de enrutamiento, el prefetch y una caché de expertos cuantizada cumplen todos su función. Esas son exactamente las condiciones en las que el rendimiento de referencia y el rendimiento del mundo real divergen — el primer prompt calienta la caché, y el comportamiento que te da 13 tokens por segundo en una demo es una planificación, no una propiedad de los pesos.

Considera los 13 tokens por segundo como una afirmación sobre una técnica, no sobre el checkpoint. El checkpoint es lo que puedes verificar hoy: 35,21B almacenados, 8 de 256 expertos enrutados por token, ~2,44B a ~4,01B activos según lo que cuentes, Apache-2.0, cuantizaciones desde el día 0 en GGUF, AWQ, GPTQ, int4 y FP8, y una lista de proveedores de chips compatibles que incluye Rockchip, Houmo, Intel, AMD y Arm.

Lo que el recuento activo decide y lo que no decide

Un recuento de parámetros activos es un proxy de cómputo. Te dice cuánta multiplicación de matrices ocurre por token, lo que se corresponde con la velocidad a la que se ejecuta una decodificación limitada por GPU. No te dice cuánta memoria necesitas para almacenar el modelo, lo cual está determinado por el total: 70,43 GB de pesos BF16, o aproximadamente una cuarta parte de eso a 4 bits, antes de tener en cuenta una caché KV. En un modelo de contexto de 256K, esa caché tampoco es un error de redondeo.

• Velocidad de decodificación — determinada por los parámetros activos (~2,44B–4,01B aquí). De esto trata la afirmación de 13 tokens/s.

• Memoria residente — determinada por el total de parámetros (35.21B almacenados) y luego reducida por la cuantización y por el conjunto de expertos que permanezca residente.

• Almacenamiento y carga: determinados por los 70,43 GB completos en BF16. El enrutamiento disperso no reduce la descarga.

• Ancho de banda, no flops — en un teléfono, la restricción determinante es hacer pasar a los expertos por un bus de memoria, que es la razón por la que existe la técnica de planificación y por la que un recuento de activos por sí solo no predice nada sobre la latencia en móviles.

La conclusión práctica: si tienes una GPU con suficiente memoria para albergar los pesos cuantizados, el número de parámetros activos es lo que determina tu rendimiento y «3B activos» es algo bueno. Si tú eres la razón por la que la frase «funciona en un iPhone» aparece en una publicación, el número total es la cifra que decide la viabilidad, y el trabajo de planificación del proveedor es la parte que hace que el número total sea llevadero. Ambas lecturas del mismo titular son correctas y no son la misma lectura.

La comparación en esa publicación necesita dos etiquetas, no una.

El encuadre que circuló esta vez fue el de lo local frente al hardware costoso: MiniCPM-V 4.7 35B-A3B como el modelo que te da la misma capacidad sin el equipo, frente a Qwen3.8-27B como el modelo que era más inteligente pero necesitaba el equipo. La parte de capacidad de eso proviene de la propia model card de Qwen, y está reportada por el proveedor como todo lo demás en esta página. Los números publicados por Qwen para Qwen3.8-27B incluyen 90,3 en LiveCodeBench v6, 89,2 en GPQA Diamond, 84,3 en OSWorld-Verified y 79,0 en QwenSWEBench, y nuestra propia entrada de catálogo para este modelo señala esos como resultados inusualmente sólidos en tareas agénticas y de codificación para un modelo denso de 27B. Que fuera “más inteligente que Opus 4.6” es una afirmación de la publicación en redes sociales, y no tengo ninguna evaluación independiente delante de mí que lo zanje, así que no voy a repetirlo como un hecho.

La diferencia estructural es la que realmente se puede comprobar: Qwen3.8-27B es denso, así que sus 27B parámetros están todos activos y su consumo de memoria y su factura de cómputo son el mismo número. MiniCPM-V 4.7 35B-A3B separa esos dos números por un factor de aproximadamente nueve. Ese es todo el argumento arquitectónico, y es real. Simplemente no es lo mismo que una comparación de benchmarks, y la publicación que lo hizo famoso mezcló las dos cosas.

Dónde un enrutador cambia la decisión y dónde no

Dos cosas son ciertas aquí y merecen distinguirse, porque apuntan en direcciones opuestas.

Lo primero es que no ofrecemos MiniCPM-V 4.7. No está en nuestro catálogo. Si lo quieres, el camino es tu propio hardware — que es exactamente para lo que está diseñado el lanzamiento, con pesos, cuantizaciones y guías de despliegue en dispositivo publicados junto con él. Nada de una API alojada te ayuda a ejecutar un modelo en un teléfono, y sería engañoso sugerir lo contrario.

La segunda es que el modelo con el que se mide este no está en esa posición. Qwen3.8-27B está disponible a través de nuestra API, autoalojado en nuestra propia infraestructura, a $0.33 por millón de tokens de entrada y $2.40 por millón de tokens de salida. Si la pregunta que en realidad te estás haciendo es «¿sustituyo mis llamadas a mi Qwen3.8-27B alojado por un MiniCPM-V 4.7 desplegado localmente?», la versión honesta de la respuesta es que deberías hacer el experimento antes de comprometerte: la cifra de rendimiento en el dispositivo no ha sido reproducida, y la comparación de capacidades es la propia ficha de la otra parte. Esa es la situación para la que existe la conmutación por error — enruta una fracción del tráfico por una ruta nueva, mantén la ruta probada detrás de ella y deja que una mala semana te cueste una fracción de una carga de trabajo en lugar de la carga de trabajo. Un modelo con 0 % de margen también mantiene la aritmética honesta: cuando un proveedor cambia un precio, el importe que pagas cambia ese mismo día, porque no hay una capa de margen entre su precio de lista y tu factura.

Lo que un router no puede hacer es hacer desaparecer la cuestión de local frente a alojado. Esa la deciden tu hardware, tus restricciones de privacidad y si una descarga de 70 GB es aceptable — y el número de parámetros activos, sin importar cómo lo redondees, no cambia ninguna de las tres.

¿Qué lo resolvería?

Tres cosas, en orden descendente de utilidad. Una cifra de parámetros activos publicada por OpenBMB, para que el número que todo el mundo repite deje de ser la aritmética de un tercero —incluida la mía, y la mía es reproducible a partir de las cabeceras de los fragmentos si no estás de acuerdo con ella. Una medición independiente de los 13 tokens por segundo en un teléfono, con los ajustes de cuantización indicados, porque una cifra dependiente de la planificación sin sus ajustes no es una especificación. Y una evaluación real que compare MiniCPM-V 4.7 35B-A3B con Qwen3.8-27B en las mismas tareas, ya que la comparación que hizo notable a este modelo es actualmente la gráfica de un proveedor contra la ficha de otro proveedor.

Hasta entonces, el resumen prudente es más limitado que el post: los pesos son reales, la dispersión es real, la descarga es de 70,43 GB y, por token, el modelo realiza un trabajo equivalente a entre 2,4 y 4 mil millones de parámetros, según cómo cuentes las partes que no puedes esquivar mediante enrutamiento. Eso es un resultado de ingeniería auténtico. Todavía no es un benchmark medido en teléfono, y no es una victoria de benchmark frente a un modelo denso de 27B.

Procedencia: los parámetros, el número de expertos, los tipos de capas, la longitud de contexto y el tamaño de descarga se leyeron directamente de config.json y de los encabezados de los fragmentos safetensors de openbmb/MiniCPM-V-4.7-35B-A3B el 13 de octubre de 2026. La velocidad en el dispositivo, la cifra de memoria, los resultados de benchmark y las cifras de evaluación de Qwen3.8-27B son reportados por el proveedor y no se han reproducido. Las afirmaciones «3B de parámetros activos» y «más inteligente que Opus 4.6» provienen de una publicación en redes sociales de un tercero, no de ninguno de los dos proveedores.

Nada de eso es hipotético: los fallos de IA documentados y los incidentes de agentes en los que se cita una cifra como esta se recopilan en el OrcaRouter AI Incident Archive , donde cada entrada incluye sus propias fuentes, su gravedad, su calificación de confianza y su marca de disputa.