MiniCPM-V-4.7-1B-DSpark: un modelo borrador de 213M lanzado sin anuncio

MiniCPM-V-4.7-1B-DSpark es un checkpoint de 213.547.777 parámetros que no puede responder a una pregunta. No lee imágenes, no mantiene una conversación y, servido por sí solo, no produce nada que merezca la pena leer. Su única función es colocarse delante de un único modelo —MiniCPM-V-4.7-1B— y adivinar los siguientes quince tokens para que un modelo de visión-lenguaje pequeño, de clase telefónica, pueda verificar un bloque de ellos en una sola pasada hacia delante en lugar de generarlos uno a uno.

El archivo ocupa 0,85 GB y está bajo Apache-2.0, y apareció en Hugging Face a las 04:26 UTC del 8 de octubre de 2026, en el mismo lote que el borrador del hermano mayor 35B-A3B. Cuatro días después, la tarjeta principal todavía lo trata como una nota al pie: el borrador aparece una sola vez, como una fila en la tabla de pesos y detrás de un interruptor contraído "Decodificación especulativa (DSpark)". No hay ninguna publicación en el blog de OpenBMB sobre él, ni informe técnico, ni entrada en la documentación de GitHub del propio proyecto.

Ese silencio es la parte interesante, por lo que este archivo en particular hace posible. Es el primer artefacto de la familia MiniCPM-V 4.7 cuya afirmación central —que un modelo de visión de 1B se ejecute de forma aceptable en un teléfono— puede ser verificada por alguien fuera de OpenBMB. Todo lo que sigue mantiene separados dos montones: lo que es un archivo en disco que puedes abrir, y lo que es un número que el proveedor imprimió junto a él.

¿Qué hay realmente en el repositorio?

Cuatro archivos. Eso es todo: .gitattributes, README.md, config.json, y un único model.safetensors que contiene 854.204.052 bytes de pesos BF16. No hay tokenizador en el repositorio, porque no hace falta que lo haya: el borrador toma prestado el del objetivo, y el vocabulario de su configuración es exactamente el del padre, con 248.094 tokens. Un borrador cuyos tokens no se asignen uno a uno con los del objetivo no puede proponer nada que el objetivo acepte, así que compartir el vocabulario es un requisito, no una comodidad.

La API de Hub registra el repositorio como creado el 2026-10-08T04:26:19Z y modificado por última vez el 2026-10-12T14:29:57Z, etiquetado para inglés y chino, con licencia Apache-2.0, y con tres me gusta y una descarga en el momento de escribir esto. El último número es el que hay que retener. Una descarga, cuatro días después, en un archivo lo bastante pequeño como para descargarlo por una conexión de teléfono.

El campo de arquitectura dice Qwen3DSparkModel con un model_type de qwen3, lo cual es coherente y no extraño: la columna vertebral lingüística de MiniCPM-V 4.7 desciende de la línea Qwen3, así que un stub de cinco capas extraído de la misma familia es lo que cabría esperar. Lo que no es una copia más pequeña del padre es cómo el stub se comunica con él. La configuración arma un dflash_config con projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" y markov_rank: 256. Esa cabeza de confianza es la parte tomada del método DSpark: es la maquinaria para estimar cuánto de un bloque propuesto merece la pena verificar, que es la razón por la que la configuración de servicio expone un interruptor para desactivar la verificación adaptativa.

La especificación, y por qué cada número está ahí

Del lado del borrador, según la tarjeta y la configuración, las cuales coinciden:

• Parámetros del borrador — 213.547.777, todos en BF16, en un checkpoint de un solo archivo de 0,85 GB

• Profundidad del borrador — 5 capas, todas con atención completa, tamaño oculto 1.024, tamaño intermedio 3.584, activación SiLU

• Geometría de atención — 8 cabezas de consulta frente a 2 cabezas de clave/valor, dimensión de cabeza 256, atención de consulta agrupada

• Tokens por pasada hacia adelante — 15, incluidos en la configuración como block_size: 15

• Rango de posiciones — RoPE theta 10,000,000 con un embedding rotatorio de 256 dimensiones, y max_position_embeddings establecido en 262,144, coincidiendo con la ventana de 256K del padre

• Capas de tap — [3, 7, 11, 15, 19], de las 24 del padre (num_target_layers: 24)

• Vocabulario — 248.094, vinculado al tokenizador del objetivo, con un token de máscara dedicado en 248.076 para el paso de borrador semiautoregresivo

Dos de esas líneas merecen más que un vistazo. La primera se refiere a las capas de toma. El borrador no lee la capa final del modelo padre; lee estados ocultos de cinco capas dispersas por la profundidad del modelo padre y los proyecta a través de un dspark proyector. Los estados intermedios de la red son más baratos de alinear y aún portan información que la última capa ya ha colapsado en logits del siguiente token. La segunda es la dimensión de cabeza de 256 frente a un tamaño oculto de 1.024. Es una cabeza deliberadamente ancha en un modelo estrecho, y la configuración establece tie_word_embeddings: false — la matriz de embeddings se mantiene separada en lugar de compartirse con la proyección de salida, por lo que el recuento de parámetros incluye ambas.

En resumen, es un modelo borrador de aproximadamente una quinta parte del tamaño del objetivo, con una forma completamente distinta. Para comparar, el borrador del modelo hermano 35B-A3B tiene 389,223,169 parámetros que toman capas [3, 11, 19, 27, 35] de 40. Dos borradores, uno por objetivo, porque un borrador solo es válido para el vocabulario y la representación intermedia con los que fue entrenado.

La tabla de aceptación es una ficha de modelo, no una medición

Aquí está todo lo numérico que OpenBMB publicó sobre el rendimiento de este par, expresado como tokens aceptados por paso de verificación, medido con terminación natural de EOS y max_new_tokens=8192:

• Vision, MMMU — 3.452 tokens aceptados por paso

• Visión, MathVista — 4.333

• Visión, razonamiento de CharXiv (validación) — 4.452

• Visión, OCRBench — 4.752

• Texto, matemáticas — 5.891

• Texto, código — 5.347

• Texto, general — 3.370

La horquilla va desde 5,891 hasta 3,370, un factor de aproximadamente 1,75 entre la categoría más fácil y la más difícil. Que el orden sea ese no sorprende, y de algún modo dice algo sobre las cifras: las matemáticas son la superficie más regular que produce un modelo de lenguaje, el texto general la menos, y la tasa de éxito de un modelo borrador va en función de la previsibilidad de la salida del objetivo, no de su calidad.

Tres advertencias deberían figurar en esa tabla, y la tarjeta no ofrece ninguna de ellas por iniciativa propia.

Es un dato autoinformado, y hay exactamente una descarga en el repositorio. Nadie fuera de OpenBMB ha producido una cifra de aceptación para este checkpoint que alguien más pueda consultar. Las cifras son del proveedor, medidas en el entorno de pruebas del proveedor, sobre el conjunto de tareas del proveedor.

La longitud de aceptación es una propiedad del par, no del modelo. Un objetivo que se repite le regala a su borrador una victoria fácil, así que un número más alto aquí no es evidencia de que MiniCPM-V 4.7-1B sea bueno en algo. Es evidencia sobre cuán predecible es su salida, que es una pregunta diferente con una respuesta diferente.

Y no es una mejora de velocidad. Un modelo borrador que propone 15 tokens y logra que se verifiquen 3,4 de ellos sigue moviendo varios tokens por cada pasada forward del modelo objetivo, pero verificar un bloque de 15 tokens cuesta más que generar un token, y cada propuesta rechazada se paga igual y se descarta. Convertir una longitud de aceptación en una cifra de tiempo real requiere el coste de verificación, el tamaño del lote y el hardware, ninguno de los cuales proporciona la tarjeta. La única receta de servicio que sí proporciona establece --max-num-seqs 1, que es una configuración ajustada para funcionar, no para ser rápida.

Leída en comparación con su hermano, la tabla resulta más útil. El borrador 35B-A3B registra 7.387 en código y 5.098 en MMMU; este borrador 1B registra 5.347 y 3.452. Los objetivos más pequeños con drafters más pequeños aceptan notablemente menos tokens por paso, que es el tipo de detalle entre familias que una sola tarjeta no puede mostrar y dos tarjetas sí.

Entrenamiento, y el detalle que explica todo el diseño

La receta tiene cuatro líneas: dos millones de secuencias de entrenamiento, seis épocas, AdamW y un objetivo combinado de entropía cruzada, un término L1 y una pérdida de confianza. La línea que importa es la que habla de de dónde vinieron los datos de entrenamiento: las respuestas fueron generadas por el propio MiniCPM-V-4.7-1B, a partir de una mezcla de prompts de visión y texto.

Eso es autodestilación, y marca el mínimo de lo que cuesta construir un modelo borrador como este. No puedes entrenar uno sin antes ejecutar el modelo objetivo a gran escala, en ambas modalidades, lo que significa que el artefacto de 0.85 GB que puedes descargar es el residuo barato de un proceso costoso. También explica por qué el modelo borrador se empareja uno a uno en lugar de compartirse: el comportamiento que imita es el de este modelo, y las salidas de un objetivo diferente entrenarían un modelo borrador diferente.

El artículo propio del método, arXiv 2607.05147, no es de OpenBMB. Es un artículo de 33 autores enviado el 6 de julio de 2026 que describe DSpark como un marco de decodificación especulativa que combina una columna vertebral paralela con un módulo secuencial ligero y programa la longitud de verificación a partir de probabilidades estimadas de supervivencia del prefijo. Informa de un despliegue dentro de un sistema de servicio DeepSeek-V4, toma una línea base de producción llamada MTP-1 y afirma que la generación por usuario es entre un 60 y un 85 por ciento más rápida con un rendimiento equivalente. Esas afirmaciones pertenecen al artículo y a ese despliegue. Nada de lo publicado los conecta con un draft de cinco capas y 213M sobre un modelo de visión de 1B, y la tabla de aceptación anterior es el único puente que alguien ha ofrecido.

Por qué este archivo importa más de lo que su tamaño sugiere

La afirmación principal de la familia MiniCPM-V 4.7 es una orientada al dispositivo. La ficha del 1B incluye un gráfico de rendimiento frente a tiempo de inferencia, un gráfico de rendimiento global para la build instruct de 1B, una grabación de pantalla sin editar capturada en un iPhone 17 Pro Max y una frase cualitativa que dice que la variante 1B supera sustancialmente a Qwen3.5 0.8B tanto en puntuación global como en eficiencia de inferencia. También enumera una familia de cuantización —int4, AWQ, GPTQ, GGUF, además de compatibilidad con FP8— y objetivos de hardware desde el día 0 que abarcan iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD y Arm.

Todas y cada una de esas son afirmaciones de proveedor sin ninguna cifra externa que las respalde, y una de ellas es internamente inconsistente: el texto de la tarjeta lo llama modelo de 1B, mientras que la barra lateral del Hub indica un tamaño de modelo de 2B parámetros. El checkpoint DSpark es de naturaleza distinta a todo lo demás. Ocupa 0,85 GB, es Apache-2.0 y viene con un comando de servicio, lo que significa que un tercero con una GPU de consumo puede ejecutarlo esta semana y producir la primera cifra medida externamente de la familia. No una puntuación de benchmark, sino algo casi tan útil: una longitud de aceptación reproducida.

Si alguien iguala 3.45 en MMMU y 3.37 en texto general, la tarjeta es creíble y la propuesta en el dispositivo tiene su primer dato externo. Si la aceptación resulta sustancialmente inferior, la tabla se midió bajo condiciones que la receta publicada no reproduce, y el gráfico de rendimiento por tiempo de inferencia hereda esa duda. Cualquiera de los dos resultados vale más que otro gráfico de proveedor, y esta es la única parte de la familia donde conseguir uno es barato.

Ejecutarlo, y lo que cuesta probarlo

La tarjeta incluye una receta y es una vllm serve, una invocación, no una simple mención. Carga el objetivo openbmb/MiniCPM-V-4.7-1B, lo sirve bajo el nombre MiniCPM-V-4.7-1B, establece --max-model-len 40960 y --max-num-batched-tokens 40960, fija --attention-backend FLASH_ATTN y --mm-encoder-attn-backend FLASH_ATTN, pasa un kwarg de procesador multimodal de {"downsample_mode": "4x"}, confía en los kwargs multimodales por solicitud, y apunta una configuración especulativa al checkpoint DSpark con "method": "dspark", "num_speculative_tokens": 15 y la verificación adaptativa desactivada. Los kwargs predeterminados de la plantilla de chat dejan el pensamiento desactivado.

Dos detalles de esa línea merecen una segunda lectura. --max-num-seqs 1 significa que la configuración publicada atiende una secuencia a la vez, por lo que la receta describe una configuración de latencia de un solo flujo, no una configuración de rendimiento. Y el modo de submuestreo visual 4x es el más económico de los dos que anuncia la tarjeta principal — la misma tarjeta ofrece un esquema mixto 4x/16x que intercambia detalle por velocidad, y la receta selecciona el lado de ese intercambio que favorece la velocidad.

La envolvente de hardware es lo opuesto al marketing de la familia. El objetivo de 1B es de aproximadamente 2 GB en BF16 más una caché KV, y el draft añade 0,85 GB adicionales, así que esto es una tarea para una sola GPU —una tarjeta de consumo, o una estación de trabajo con suficiente memoria unificada— en lugar de una tarea para un teléfono. La ruta en el dispositivo de la documentación del modelo padre pasa por compilaciones cuantizadas y frameworks que no están en esta receta, y el checkpoint DSpark tal como se publica es un artefacto BF16 del lado del servidor.

Eso deja una brecha con la que se toparán la mayoría de los equipos: la versión interesante de MiniCPM-V 4.7-1B es la que se ejecuta en el dispositivo, y la versión que puedes ejecutar hoy sin disponer del conjunto de herramientas para el teléfono es una del lado del servidor. Si lo que realmente necesitas ahora es inferencia multimodal pequeña, el equivalente alojado más cercano es un modelo diferente — Qwen3 VL 8B Instruct está en OrcaRouter a $0.18 por millón de tokens de entrada y $0.70 por millón de salida, con una ventana de contexto de 128K y entrada de texto, imagen y video, sin pesos locales y sin receta de servido que mantener en funcionamiento. MiniCPM-V 4.7 no es un modelo alojado en OrcaRouter y este artículo no pretenderá lo contrario; el enfoque honesto es que estas son dos formas de hacer un mismo trabajo, y solo una de ellas es medible desde el catálogo esta tarde.

Donde algo como DSpark se gana su lugar es en el caso del modelo no probado, y eso es una cuestión de enrutamiento más que una cuestión de modelo. Un drafter que nadie ha reproducido es exactamente el tipo de componente que quieres detrás de un endpoint del que puedas hacer fallback. Ejecutar más de 200 modelos detrás de una sola clave, con los precios de lista del proveedor transferidos con un 0 % de recargo, con failover automático cuando una ruta se degrada, significa que un experimento de serving que sale mal te cuesta un reintento en lugar de una caída — y, como nada lleva recargo, un cambio de precio del proveedor en cualquier modelo del catálogo se aplica el mismo día en lugar de en el siguiente ciclo de facturación.

¿Qué haría que esto fuera comprobable?

Faltan tres cosas, y solo una de ellas requiere OpenBMB.

El proveedor no ha anunciado nada. El repositorio tiene una tarjeta de modelo, una licencia y una receta de entrenamiento, pero ninguna entrada de blog, ningún informe técnico y ninguna línea en la documentación de GitHub del proyecto — que, en la primera semana de la familia, seguía describiendo la generación anterior como la actual. Cuatro días después de que aterrizara el checkpoint, la tarjeta del 1B padre lo enlaza como una fila de tabla y nada más.

Nadie ha reproducido las cifras de aceptación, y el número de descargas es uno. Esa es la brecha más barata de cerrar y la que más importa, porque es el único punto en el que una medición externa movería de manera significativa la historia de la familia.

Y la cuestión de la calidad queda completamente al margen. No hay ninguna puntuación MMMU, ningún resultado de OCRBench, ninguna cifra de comprensión de documentos ni dato de grounding para MiniCPM-V 4.7-1B en ningún lugar del lanzamiento: la tabla de aceptación es una tabla sobre decodificación, y leer una longitud de aceptación alta como señal de calidad es exactamente el error al que invitan esas cifras.

Así que: un artefacto real, una licencia permisiva, un comando de servicio que funciona y una pieza de evidencia genuinamente nueva sobre un modelo que no tenía ninguna. El siguiente archivo que vale la pena actualizar sigue siendo la tarjeta del modelo padre.