MiniCPM-V 4.7-35B-A3B-DSpark: el borrador de 389M de OpenBMB llega con una tarjeta de modelo que su modelo base nunca recibió

MiniCPM-V-4.7-35B-A3B-DSpark es un modelo borrador de 389.223.169 parámetros. No responde preguntas, no ve imágenes y, por sí solo, es inútil. Todo su trabajo consiste en adivinar los siguientes quince tokens para que MiniCPM-V-4.7-35B-A3B pueda verificar un bloque entero en una sola pasada hacia delante en lugar de generar un token a la vez. Eso es la decodificación especulativa, y OpenBMB lanzó un borrador para su nuevo modelo de visión-lenguaje de 35B hace once días sin decir una palabra al respecto en público.

Lo que hace que merezca una página no es el borrador. Es el papeleo que vino con él. El checkpoint de DSpark tiene una ficha de modelo: una licencia, una tabla de especificaciones, una receta de entrenamiento y una tabla de longitudes de aceptación para siete categorías de tareas. Su modelo padre de 35 mil millones de parámetros no tenía nada de eso cuando apareció. Así que, por primera vez, hay cifras reales asociadas a un lanzamiento de MiniCPM-V 4.7 —y son cifras sobre el modelo padre, medidas indirectamente, por un archivo de 0,78 GB cuyo propósito declarado es hacerlo ir más rápido.

Todo lo que sigue separa lo que figura en la tarjeta de lo que la tarjeta no establece. Las cifras de aceptación son de OpenBMB y nadie fuera del laboratorio las ha reproducido. La tabla de benchmark del modelo base todavía no existe.

Qué es realmente el checkpoint de DSpark

El repositorio openbmb/MiniCPM-V-4.7-35B-A3B-DSpark data del 8 de octubre de 2026. Es un checkpoint de un solo archivo — model.safetensors, más un config.json y un README — bajo Apache-2.0, etiquetado para inglés y chino. Un segundo borrador, openbmb/MiniCPM-V-4.7-1B-DSpark, se creó un segundo antes, por lo que los dos se subieron al hub en el mismo lote en lugar de descubrirse uno a uno.

Cada borrador se sitúa delante de un objetivo y solo de ese objetivo. La ficha lo dice claramente: este checkpoint está "entrenado para emparejarse exactamente con MiniCPM-V-4.7-35B-A3B y su tokenizador". El vocabulario es el del padre, todos y cada uno de sus 248.144 tokens, lo cual es un requisito más que una optimización: un borrador cuyos tokens no se correspondan uno a uno con los del objetivo no puede proponer nada que el objetivo pueda aceptar. La misma restricción es la razón por la que el borrador hermano existe por separado, en lugar de que un solo borrador sirva a la familia.

La arquitectura no es una copia más pequeña del padre. Es una pila de atención de cinco capas, 2.048 de ancho oculto, 8 cabezas de consulta frente a 2 cabezas de clave/valor, un tamaño intermedio de 6.144 y RoPE con un theta de 10.000.000. El campo arquitecturas dice Qwen3DSparkModel — el mismo backbone de la familia Qwen3 del que proviene la pila de lenguaje del padre, reducido a un stub.

Lo interesante es cómo el stub se comunica con el objetivo. No lee la capa final del objetivo. Extrae estados ocultos de cinco capas intermedias — [3, 11, 19, 27, 35] de las 40 del padre — y los proyecta mediante un proyector de tipo dspark. Tomar de la mitad de la pila en lugar del final es deliberado: los estados de mitad de red son más económicos de alinear y transportan información que la capa final ya ha comprimido en logits del siguiente token. La configuración también dota a una cabeza de confianza de un componente de Markov de rango 256, que es el mecanismo del artículo de DSpark para decidir cuánto de un bloque propuesto vale la pena verificar.

La tabla de aceptación es una tarjeta, no una medida.

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

• Vision, MMMU — 5.098 tokens aceptados por paso.

• Visión, MathVista — 6.126.

• Visión, razonamiento CharXiv (validación) — 5.479.

• Visión, OCRBench — 5.407.

• Texto, Matemáticas — 6.687.

• Texto, Código — 7.387.

• Texto, General — 3.501.

Tres cosas sobre esa tabla merecen decirse en voz alta. Primero, es autoinformada. Nadie fuera de OpenBMB ha ejecutado este checkpoint y publicado una cifra, y con una descarga registrada en el repositorio, nadie fuera de OpenBMB lo ha ejecutado en absoluto. Segundo, la longitud de aceptación es una propiedad del par, no del modelo: mide cuán predecible es la salida de MiniCPM-V-4.7-35B-A3B, no cuán buena es esa salida. Un objetivo que se repite le da una victoria fácil a un borrador. Tercero, la dispersión es lo importante: 7.387 en código frente a 3.501 en texto general es un factor de dos entre la mejor y la peor categoría, y que el código sea el más fácil refleja la superficie de baja entropía y altamente repetitiva del código más que cualquier fortaleza de los modelos.

También hay una lectura de aritmética simple que la tarjeta deja implícita. Un drafter que propone 15 tokens y consigue que se acepten de 5 a 7 sigue avanzando varios tokens por cada pasada forward del objetivo, así que el techo aquí es una gran ganancia de rendimiento — pero no es la afirmación ingenua de "5× más rápido", porque verificar un bloque de 15 tokens cuesta más que generar uno, y las propuestas rechazadas se pagan y se desechan. Esa brecha es exactamente de lo que trata el artículo de DSpark, y es por eso que la configuración expone un interruptor para desactivar la verificación adaptativa.

Lo que el borrador nos dice accidentalmente sobre el modelo base

MiniCPM-V 4.7 etiquetó su lanzamiento como enviado silenciosamente — pesos, sin publicación de lanzamiento. Eso ahora ha cambiado, de una manera pequeña pero real. El repositorio principal en openbmb/MiniCPM-V-4.7-35B-A3B fue creado el 7 de octubre de 2026. Para el 12 de octubre ya contaba con una tarjeta de modelo completa con un README, una página de lanzamiento al estilo de Hugging Face, una lista de afirmaciones, una sección en dispositivo y una tabla de pesos. Desde entonces, el repositorio ha hecho crecer una familia de cuantización — compilaciones FP8, int4, AWQ, GPTQ y GGUF, cada una en su propio repositorio, todas modificadas el 12 de octubre — y 27 me gusta frente a 166 descargas.

Así que el panorama exacto es un lanzamiento en dos etapas, no uno silencioso. Los pesos llegaron el 6 y el 7 de octubre. Los checkpoints preliminares llegaron después, el 8 de octubre. La documentación, los modelos cuantizados y la historia de ejecución en dispositivo llegaron para el 12 de octubre. OpenBMB todavía no ha publicado una entrada de blog ni un informe técnico para la familia, y todavía no hay una tabla de benchmarks en la tarjeta principal — las afirmaciones de rendimiento están dentro de imágenes de gráficos enlazadas en lugar de como texto que un lector pueda citar.

La afirmación que sí aparece en el texto es la principal: con Lookahead Expert Scheduling, cuantización por capas e «integración de muestreo especulativo DSpark», el modelo 35B-A3B se describe como el primer modelo MoE de código abierto que se ejecuta sin problemas en el dispositivo, a más de 13 tokens por segundo en un iPhone 17 Pro Max. Esa cifra está reportada por el proveedor, no se ha reproducido y no tiene salvedades: ningún formato de cuantización, ningún build, ningún prompt, ningún método de medición. El checkpoint de DSpark es una de las tres técnicas en las que se basa esa afirmación, lo que lo convierte en la única de las tres que puedes descargar e inspeccionar. También es la única cuya evidencia es una sola fila de benchmark no leída por tarea.

Ejecutándolo, si quieres

La tarjeta incluye una receta y es un comando de vLLM, no una vaguedad. Sirve el objetivo con un tamaño de paralelismo tensorial de 2 con una longitud máxima de modelo de 40.960, FLASH_ATTN tanto en los backends de atención del codificador de lenguaje como en los del codificador multimodal, un modo de submuestreo visual de 4x, enable_thinking establecido en false, y la configuración especulativa apuntando al checkpoint DSpark con 15 tokens especulativos y la verificación adaptativa desactivada. Dos detalles de esa línea merecen atención por sí mismos: --max-num-seqs 1 significa que la configuración publicada sirve una secuencia a la vez, y --disable-custom-all-reduce con la pasada de fusión all-reduce desactivada significa que esta es una configuración que se ajustó para funcionar en lugar de para ser lo más rápida posible. Considera la receta como un punto de partida que OpenBMB logró ejecutar, no como una afirmación de rendimiento.

El límite del hardware es la verdadera barrera. El objetivo es de aproximadamente 70 GB de pesos BF16 antes de la caché KV, y el borrador añade unos 0.78 GB adicionales. Dos aceleradores es el mínimo declarado, lo que lo sitúa muy lejos del teléfono en el que se apoya el marketing de la familia: un despliegue en el dispositivo para un modelo 35B-A3B implica una cuantización agresiva y offloading, que es precisamente para lo que sirven el LES y el trabajo de cuantización por capas, y ninguna de esas cosas está en la receta de vLLM anterior.

Esa asimetría es la decisión práctica para la mayoría de los equipos. Servir MiniCPM-V 4.7 cuesta dos GPU que son tuyas; llamar a un MoE multimodal alojado comparable no cuesta nada por adelantado. Qwen3.6 35B A3B es la comparación directa más cercana —misma configuración de 35B totales y 3B activos, mismo contexto de 262K, entrada de imagen y video— y se sirve a través de OrcaRouter desde $0.248 por millón de tokens de entrada y $1.485 por millón de tokens de salida, según la ruta del proveedor, con conmutación por error automática si una de esas rutas se degrada. MiniCPM-V 4.7 no es un modelo alojado en OrcaRouter y este artículo no va a pretender lo contrario; el planteamiento honesto es que ambos son alternativas en un punto de decisión, y el alojado es el que puedes medir esta tarde.

¿Qué haría que esto fuera comprobable?

El checkpoint de DSpark es Apache-2.0, pesa menos de un gigabyte y viene con un comando de servicio que alguien con dos GPU podría pegar en una terminal hoy mismo. Esa combinación lo convierte en la ruta más barata hacia una cifra independiente en MiniCPM-V 4.7 —no una puntuación de benchmark, sino algo casi igual de útil: una longitud de aceptación reproducida. Si un tercero iguala 5.1 en MMMU y 3.5 en texto general, la ficha es creíble y la historia de eficiencia de la familia gana su primer dato externo. Si la aceptación resulta sustancialmente inferior, la tabla publicada se midió en condiciones que la receta no reproduce, y la afirmación de 13 tokens por segundo hereda esa duda.

Lo que todavía falta es aquello para lo que normalmente sirve una tarjeta de modelo. No hay puntuación MMMU, ni puntuación OCRBench, ni resultado de comprensión de documentos, ni número de grounding, ni cifra de latencia para el propio MiniCPM-V 4.7 — nada que responda si este modelo es bueno. La tabla del modelo borrador no puede sustituir eso, e interpretar una longitud de aceptación alta como una señal de calidad es precisamente el error al que invitan los números. Una predicción con forma de ChatGPT es fácil para un modelo borrador y no dice nada sobre si la predicción era correcta.

Entonces: un artefacto real, una licencia real, una pieza genuinamente nueva de evidencia publicada sobre un modelo que no tenía ninguna —y una brecha de evaluación exactamente tan amplia como lo era el 7 de octubre. El próximo archivo que hay que actualizar sigue siendo la tarjeta de modelo del padre.