MiniCPM-V 4.7: OpenBMB subió un modelo de visión-lenguaje 35B-A3B sin tarjeta de modelo, sin licencia y sin benchmarks

MiniCPM-V 4.7 apareció en Hugging Face la noche del 6 de octubre de 2026 como el repositorio openbmb/MiniCPM-V-4.7-35B-A3B — y es una de las cosas más extrañas que la serie MiniCPM haya lanzado jamás, porque casi nada se lanzó junto con él. No hay tarjeta de modelo. No hay README. No hay una licencia declarada. No hay tablas de benchmark, ni publicación de lanzamiento, ni informe técnico, ni entrada en la propia documentación de OpenBMB, que a fecha de esta semana todavía llama a MiniCPM-V 4.6 «el modelo más reciente y eficiente de MiniCPM-V». Lo que sí existe son 16 fragmentos de pesos bfloat16, 70,4 GB de ellos, que describen un modelo de visión-lenguaje de mezcla de expertos de 35,2 mil millones de parámetros con una ventana de contexto de 256K y un diseño de atención híbrida inusualmente agresivo. Eso basta para decir lo que el modelo es. Todavía no es suficiente para decir en qué es bueno, y este artículo mantiene esas dos cosas estrictamente separadas.

¿Qué se implementó realmente, byte por byte?

El repositorio se creó a las 18:36 UTC del 6 de octubre de 2026 y tuvo su último commit doce minutos después, a las 18:48 UTC. En el intervalo, el uploader subió los archivos de pesos y la configuración que necesita un cargador de Transformers, y se detuvo. La lista completa de archivos tiene dieciocho entradas:

• Pesos — dieciséis safetensors fragmentos llamados model-00001-of-00016 hasta model-00016-of-00016, con el archivo de índice model.safetensors.index.json que reporta un tamaño total de tensor de 70,425,751,648 bytes.

• Recuento de parámetros — la API de Hugging Face lee 35,212,875,824 parámetros, todos en BF16. Ten en cuenta que este es el recuento total, que para un MoE disperso no es el número de parámetros activos en un token dado.

• Configuración — config.json (2.984 bytes), generation_config.json (186 bytes), preprocessor_config.json, processor_config.json.

• Tokenizer — tokenizer.json (20 MB), tokenizer_config.json, y chat_template.jinja (7.250 bytes).

• Ausente — README.md. Una petición directa del archivo sin procesar devuelve HTTP 404. En Hugging Face, que falte el README significa que no hay tarjeta de modelo, lo que significa que no hay campo de licencia, lo que significa que el repositorio no lleva ninguna etiqueta license: en absoluto.

El repositorio tiene tres me gusta, cero descargas y una pestaña de discusión vacía. Una subida comunitaria de un checkpoint de 70 GB normalmente atrae comentarios en cuestión de horas —preguntas sobre quants, sobre el serving, sobre cuál es la licencia. Esta no lo ha hecho, lo cual es coherente con que haya sido vista por un puñado de personas que siguen a openbmb como organización en lugar de haber sido anunciada a alguien.

La arquitectura, leída directamente de config.json

Como no hay una ficha que parafrasear, el archivo de configuración es la fuente principal, y es inusualmente informativo. La clase es MiniCPMV4_7ForConditionalGeneration, el tipo de modelo es minicpmv4_7, y fue guardado por Transformers 5.2.0; todo lo cual indica que se trata de un modelo de primera parte de OpenBMB dentro del linaje principal de MiniCPM, no de un ajuste fino de la comunidad que lleva ese nombre.

• Columna vertebral del lenguaje — model_type: qwen3_5_moe_text. Un MoE disperso derivado de Qwen3.5, la primera vez que la línea MiniCPM-V utiliza un stack de texto Qwen-MoE en lugar de las variantes Qwen pequeñas y densas que impulsaron MiniCPM-V 4.5 y 4.6.

• Esparsidad — 256 expertos, 8 seleccionados por token, con un tamaño intermedio de experto de 512 y un experto compartido del mismo tamaño. Un checkpoint total de 35B sobre un patrón de enrutamiento 8-de-256 activa una pequeña fracción de eso por pasada hacia adelante, que es el punto entero del nombre A3B: los pesos son grandes, el cómputo no.

• Profundidad y anchura — 40 capas ocultas, tamaño oculto 2048, 16 cabezas de atención con 2 cabezas de clave/valor y una dimensión de cabeza de 256.

• Hybrid attention — the layer_types array is 40 entries long and runs three linear_attention layers to every one full_attention layer on a fixed interval of 4. Ten of the forty layers do conventional attention; the other thirty use a Mamba-style linear path with a convolution kernel of 4. This is the single most consequential design choice in the file, and it is the same direction the wider field moved in through 2026.

• Codificación posicional — RoPE con un theta de 10,000,000 y partial_rotary_factor: 0.25, lo que significa que solo se rota un cuarto de las dimensiones de cada cabeza. RoPE multimodal está habilitado con mrope_interleaved: true, una división de secciones de [11, 11, 10], y mrope_mode: canvas.

• Contexto — max_position_embeddings: 262144, y el model_max_length del tokenizador coincide. 256K tokens.

• Predicción multi-token — mtp_num_hidden_layers: 1, una sola cabeza de decodificación especulativa, el mismo truco que ya traía MiniCPM-V 4.6.

• Torre de visión — minicpmv4_7_vision, tamaño oculto 1152, 27 capas, activaciones GELU-tanh, tamaño de parche 14 con un image_size de 980, y un insert_layer_id de 6, que es donde los embeddings visuales se empalman en la pila de lenguaje. La forma de la torre es cercana a la de MiniCPM-V 4.6, por lo que el lado de visión es una evolución más que una reconstrucción.

• Compresión de visión — downsample_mode: "16x" y max_slice_nums: 9 en el procesador de imágenes. MiniCPM-V 4.6 introdujo un esquema conmutable de compresión de tokens de 4x/16x; la configuración de 4.7 anuncia el ajuste de 16x como predeterminado, y el divisor permite hasta nueve subimágenes para entradas de alta resolución.

• Vocabulario — 248,144 tokens, con <|image_pad|> en el id 248,056 y <|video_pad|> en el 248,057. El vídeo es una entrada de primera clase, exactamente como lo ha sido desde MiniCPM-V 4.5.

• Un detalle curioso — la configuración del tokenizador todavía declara <|audio_start|>, <|audio_end|> y <|audio_pad|>. Esto casi con total seguridad significa que el vocabulario se comparte con la rama omni MiniCPM-o, y no que MiniCPM-V 4.7 hable audio. Interpretarlo como una función de audio sería un error que la configuración por sí sola no puede descartar.

Lo que la familia nos dice que este repositorio no

La generación 4.6 es el punto de referencia, y el contraste es lo que importa. MiniCPM-V 4.6 se lanzó el 11 de mayo de 2026 como un modelo de 1,3 mil millones de parámetros construido sobre un codificador visual SigLIP2-400M y un modelo de lenguaje Qwen3.5-0.8B, bajo Apache-2.0, con un argumento explícito: obtiene 13 en el Artificial Analysis Intelligence Index —una cifra reportada por el proveedor— mientras usa drásticamente menos tokens que modelos pequeños comparables, y se ejecuta en iOS, Android y HarmonyOS con el código de adaptación para edge publicado como código abierto. Toda su identidad era "pequeño, eficiente, en el dispositivo".

MiniCPM-V 4.7 es 1.3B multiplicado por aproximadamente 27. El nombre 35B-A3B lo sitúa en la clase que ocupan los buques insignia dispersos, no los teléfonos. Que OpenBMB lo conciba como un acompañante del lado del servidor para la línea de borde, como maestro de un futuro modelo pequeño o como una prueba del techo de capacidades no se indica en ninguna parte, y el repositorio no contiene ninguna pista en ninguno de los sentidos.

Lo que es genuinamente nuevo, y que vale la pena señalar para cualquiera que siga la serie, es la arquitectura base Qwen-MoE junto con la relación 3:1 entre atención lineal y atención completa. Ambas representan un cambio respecto a lo habitual. Todo lo que OpenBMB publica sobre la familia sigue escrito en torno a 4.6, así que este checkpoint va por delante de su propia documentación.

Lo que aún no se puede saber — y por qué esa lista importa

Vale la pena ser directo sobre el tamaño del hueco que hay aquí, porque la tentación con un checkpoint de 70 GB es llenarlo con inferencia plausible.

• Sin licencia. Esto no es una formalidad. MiniCPM-V 4.6 es Apache-2.0, y la comunidad ha llegado a esperar eso de esta línea. Un repositorio sin la etiqueta licencia: está, por defecto, con todos los derechos reservados en la mayoría de las jurisdicciones — no puedes construir sobre él de forma segura hasta que aparezca la etiqueta. Ese único archivo faltante es la ausencia más trascendental en el repositorio.

• No hay benchmarks, ni reportados por el proveedor ni de ningún otro tipo. No hay un solo número sobre el que discutir. Cualquiera que cite una puntuación de MMMU o OCRBench para MiniCPM-V 4.7 hoy está citando algo que no existe en la fuente.

• Sin evaluación independiente. Artificial Analysis y rastreadores similares indexan los modelos por su nombre; un checkpoint sin ficha ni anuncio normalmente permanece sin medir durante un tiempo.

• Sin receta de servicio. Que los pesos publicados funcionen sin modificaciones en vLLM, SGLang o llama.cpp no ha sido probado por nadie fuera de OpenBMB. Las rutas de código personalizadas (MiniCPMV4_7ForConditionalGeneration, MiniCPMV4_7Processor, MiniCPMV4_7ImageProcessor, MiniCPMV4_7VideoProcessor) requieren todas trust_remote_code, y la combinación de MoE más atención lineal no es una forma para la que todos los motores de inferencia tengan un kernel.

• Sin cuantizaciones. MiniCPM-V 4.6 se distribuyó con variantes GGUF, AWQ, GPTQ y BNB, y llegó a la biblioteca de Ollama en junio de 2026. Para 4.7 no existe ninguna. Para un modelo de 35B, esta es la diferencia entre un portátil y un clúster.

• No se declara ninguna relación con 4.6. Es posible que OpenBMB esté reemplazando la línea edge, extendiéndola o probando algo ortogonal. El repositorio no lo dice, y el README de GitHub tampoco, que todavía incluye 4.6 como la versión actual a fecha de su commit del 8 de septiembre de 2026.

Existe también una lectura verosímil pero no confirmada de la cronología: el intervalo de doce minutos entre la creación del repositorio y el último commit, la ausencia de una tarjeta y la ausencia de cualquier publicación son lo que parece un punto de control cuando se prepara para un lanzamiento en lugar de después de uno. Eso es una hipótesis sobre la intención, no un hecho sobre el artefacto, y debe tratarse como tal.

Cómo lo ejecutarías realmente, cuando hay algo que ejecutar

Nada de esto es citable aún como una ruta compatible, pero la configuración sí condiciona las opciones. Un checkpoint BF16 de 35B parámetros necesita unos 70 GB de memoria de acelerador antes de la caché KV, así que el despliegue de aficionado en una sola GPU queda descartado hasta que lleguen las cuantizaciones. El contexto de 256K y la proporción 3:1 de atención lineal hacen que la caché KV crezca mucho más despacio que en un transformer convencional de la misma profundidad, que es precisamente por lo que esa arquitectura merece la complejidad: el trabajo multimodal de contexto largo es donde el diseño se amortiza. Cuando aparezca una tarjeta, lo primero que hay que comprobar es la licencia, si se publica una receta oficial de vLLM o SGLang, y si el valor predeterminado de submuestreo 16x se puede cambiar por el ajuste 4x que expuso 4.6.

Para los equipos que quieren evaluar un modelo como este en el momento en que se vuelve utilizable, el problema práctico no son los pesos, sino la infraestructura que los rodea. Un modelo que vive en tu propia GPU sigue necesitando todo lo que lo rodea: un enrutador que pone más de 200 modelos alojados detrás de una sola clave, al precio de lista de cada proveedor sin ningún recargo nuestro por encima, y que conmuta automáticamente en caso de fallo cuando un proveedor se degrada. Para eso está OrcaRouter, y vale la pena decir con claridad que MiniCPM-V 4.7 en sí no es un modelo alojado: es un checkpoint de pesos abiertos que tú mismo sirves. El enrutador importa aquí como la otra mitad de la arquitectura: el modelo de frontera al que tu equipo con 4.7 le pasa los casos difíciles, accesible a través del mismo cliente que ya escribiste.

La situación actual, y el único archivo que hay que refrescar

MiniCPM-V 4.7 existe. Sus pesos se pueden descargar hoy mismo, su número de pesos es exacto y sus decisiones de diseño de la época de entrenamiento —MoE disperso, atención lineal 3:1, contexto de 256K, compresión visual 16x— se leen con claridad en el archivo de configuración. Lo que no existe es ninguna declaración de OpenBMB sobre qué hace el modelo, cuánto cuesta ejecutarlo en la práctica o qué se te permite hacer con él. Para un laboratorio cuyo último modelo de visión fue una versión edge de 1.3B con Apache-2.0 y una tabla comparativa completa, eso es una laguna chocante, y la postura sensata es vigilar el repositorio en lugar del discurso. El único archivo que conviene refrescar es README.md: en el momento en que aparezca, incluirá la licencia, los benchmarks y, probablemente, la explicación de qué pinta tiene un MiniCPM-V de 35B en una serie construida sobre modelos pequeños.

Hasta entonces, el resumen honesto es el aburrido. Este es un punto de control real de un laboratorio real, subido sin hacer ruido, y la pregunta interesante —si es bueno o no— no tiene respuesta publicada.

OrcaRouter llega a más de 200 modelos alojados a través de una sola clave, con el precio de lista de cada proveedor transferido directamente con un 0 % de margen y conmutación por error automática entre proveedores. precio de lista del proveedor transferido con un 0 % de margen MiniCPM-V 4.7 no es uno de ellos: es un checkpoint de pesos abiertos que sirves tú mismo, y el router es lo que queda al otro lado del traspaso.