Moondream 3 vs MiniCPM-V 4.7: La factura de almacenamiento de MoE que nadie menciona

Ambos Moondream 3 Preview y MiniCPM-V 4.7 son modelos de visión-lenguaje de mezcla de expertos, y ambos se anuncian con un pequeño número de parámetros activos que hace que parezca que caben en hardware modesto. Moondream 3 Preview activa 2B de sus 9B parámetros por token. La variante principal de MiniCPM-V 4.7, MiniCPM-V 4.7 35B-A3B, activa aproximadamente 3B de 35B. Lee esas dos frases y esperarías que el checkpoint de Moondream fuera el más fácil de desplegar. Si lo es depende por completo de una pregunta que ninguna publicación de lanzamiento plantea: ¿dónde viven los expertos dormidos?

Esa pregunta es donde estos dos modelos divergen de verdad, y la respuesta es la razón misma de que MiniCPM-V 4.7 exista en la forma en que lo hace. Su lanzamiento —MiniCPM-V 4.7 35B-A3B y MiniCPM-V 4.7 1B, de OpenBMB, publicado el 6 de octubre de 2026— está construido en torno a ejecutar un MoE de 35B con fluidez en un teléfono sin degradarlo. Moondream 3 Preview, que Moondream lanzó el 18 de septiembre de 2025 y que ahora forma parte de Prime Intellect tras la adquisición de octubre de 2026, tomó la ruta opuesta: mantener el MoE pequeño y ejecutarlo en GPUs con Photon, el propio motor de inferencia de Moondream. Ninguna de las dos elecciones es errónea. Son respuestas a restricciones distintas, y la restricción a la que tú te enfrentas decide la comparación por ti.

Los parámetros activos son un número de cómputo, no un número de almacenamiento

Esta es la aritmética que hace que el MoE en dispositivo sea difícil, y OpenBMB lo explica con claridad en su propia tarjeta de modelo: un modelo MoE puede tener muchos más parámetros totales que los que activa para un solo token, pero sus requisitos de almacenamiento en dispositivo no se limitan a esos parámetros activos. Distintos tokens seleccionan distintos expertos en distintas capas, y la memoria del dispositivo a menudo no puede contenerlos todos.

• Moondream 3 Preview — 9B en total, 2B activos. 24 capas, las primeras cuatro densas, el resto son bloques feed-forward MoE con 64 expertos y 8 activados por token. Dimensión oculta 2048, dimensión interna/de compuerta GeGLU 1024.

• MiniCPM-V 4.7 35B-A3B — 35B en total, aproximadamente 3B activos. El primer MoE de la serie MiniCPM-V. La variante de 1B del mismo lanzamiento es densa, no MoE, lo cual importa más abajo.

• La discrepancia: divide los activos entre el total y Moondream 3 Preview parece el modelo más ligero por un amplio margen. Divide bytes entre bytes y MiniCPM-V 4.7 35B-A3B es el que carga cuatro veces los pesos.

• Por qué no zanja nada — el conjunto residente es lo que limita al dispositivo, y el conjunto residente está más cerca del total que el recuento activo. Un MoE de 9B no cabe en la memoria en la que cabe un modelo denso de 2B, sin importar lo que dispare el router.

Así que «2B active» es una afirmación sobre el cómputo por token. No es una afirmación sobre la memoria que necesitas, y tratarla como si lo fuera es, con diferencia, la manera más común en que los equipos dimensionan mal un despliegue de MoE.

OpenBMB abordó directamente el problema de almacenamiento

El diseño de MiniCPM-V 4.7 se interpreta mejor como tres técnicas orientadas exactamente a esa brecha. Lookahead Expert Scheduling utiliza la predicción de enrutamiento entre capas para precargar los expertos que probablemente necesitará la siguiente capa, y prioriza los precargados con éxito entre aquellos que seleccionó el enrutador real; la predicción solo guía la precarga y la planificación, mientras que el cómputo sigue el enrutamiento original a nivel de token del modelo y cualquier experto requerido que la predicción haya pasado por alto se carga y evalúa como de costumbre. La cuantización fina por capas reduce la huella de almacenamiento y el tráfico de memoria de los pesos de los expertos. El muestreo especulativo DSpark se integra en la ruta en el dispositivo para mejorar la eficiencia de decodificación además de las dos anteriores.

El resultado declarado es de más de 13 tokens por segundo con unos 3 GB de memoria en un iPhone 17 Pro Max, que OpenBMB describe como el primer modelo MoE de código abierto que funciona sin problemas en el dispositivo sin comprometer el rendimiento. Su comparación es explícita y vale la pena señalarla por lo que es: en modo Instruct, MiniCPM-V 4.7 35B-A3B alcanza una puntuación general más alta en menos tiempo de inferencia que Qwen3.6 35B-A3B. Se trata de una afirmación de misma clase de tamaño reportada por el proveedor, y es del tipo más útil porque ambos modelos se miden en el mismo banco de pruebas.

El resto de la historia de despliegue es inusualmente amplio. Se admiten iOS, Android y HarmonyOS, con soporte desde el día 0 para plataformas de chips de Rockchip, Houmo, Intel, AMD y Arm. La inferencia se ejecuta en SGLang, vLLM, llama.cpp y Ollama; el ajuste fino, en SWIFT y LLaMA-Factory. Se incluyen las cuantizaciones GGUF, BNB, AWQ y GPTQ, además de FP8. La variante de 1B es de nuevo una propuesta aparte: densa, no MoE, y OpenBMB la posiciona como una mejora continua de MiniCPM-V 4.6, a la vez que supera sustancialmente a Qwen3.5 0.8B tanto en la puntuación general como en la eficiencia de inferencia, que es la comparación honesta para un modelo de menos de 1B.

La respuesta de Moondream fue mover el hardware, no los pesos

Moondream no intentó hacer que un MoE de 9B cupiera en un teléfono. Mantuvo la arquitectura y cambió dónde se ejecuta: Photon, su motor de inferencia, compila cada modelo en un único programa de GPU con kernels personalizados, y se ejecuta localmente en GPU NVIDIA desde Ampere en adelante y en Macs con Apple Silicon, con la misma API que Moondream Cloud.

Esta es una estrategia defendible y el anuncio de adquisición de Prime Intellect explica por qué resultaba atractiva: el equipo de Moondream construyó Photon y el compilador de megakernel que lo sustenta, y el argumento de Prime para comprar la empresa es que el serving, no la arquitectura, es donde se decide la utilidad de un modelo. Las cifras de rendimiento de esa publicación —más de 60 inferencias de Moondream por segundo en una sola H100, respuestas en decenas de milisegundos, Moondream 3.1 a 34 solicitudes por segundo— son de Prime y ahora son material de ventas, así que etiquétalas como tales. Pero la dirección es inequívoca: la apuesta de Moondream era que preferirías tener un modelo rápido respaldado por GPU que uno del tamaño de un teléfono.

Hay una segunda diferencia, y no está en la tarjeta del modelo en absoluto. El endpoint alojado de Moondream 3 Preview, Moondream Cloud, se cerrará el 13 de noviembre de 2026 tras la adquisición, con reembolso de los créditos comprados no utilizados. MiniCPM-V 4.7 no tiene esa dependencia, porque nunca fue principalmente un producto alojado: es un conjunto de pesos con una amplia historia de despliegue en dispositivo asociada. Si tu evaluación incluía la comodidad de llamar a un endpoint, esa comodidad está a punto de expirar en uno de los lados de esta comparación.

Capacidad de la tarea: las dos tarjetas son honestas acerca de cosas diferentes

Las cuatro habilidades nativas de Moondream 3 Preview son query, caption, point y detect, y todas devuelven salida estructurada, y la publicación de lanzamiento hace hincapié en la detección y el señalamiento. La habilidad query se ejecuta en modo de razonamiento de forma predeterminada, con un flag reasoning=False documentado para preguntas simples, y las trazas de razonamiento están fundamentadas: hacen referencia a partes concretas de la imagen, por lo que Moondream lo llama razonamiento visual con fundamentación en lugar de razonamiento en general. El contexto es de 32K tokens, frente a aproximadamente 2K de la generación anterior, usando un tokenizador SuperBPE personalizado; la publicación de lanzamiento reconoce con franqueza que el postentrenamiento no aprovecha plenamente la ventana larga y que los 32K completos están ahí sobre todo para el ajuste fino.

La tarjeta de MiniCPM-V 4.7 destaca en cambio por su eficiencia y amplitud: comprensión de imágenes individuales, múltiples imágenes y vídeo, con compresión mixta de tokens visuales 4x/16x que te permite intercambiar detalle visual por coste de inferencia según la tarea, y compresión temprana intra-ViT de LLaVA-UHD v4 que reduce el cálculo en las capas posteriores del codificador. También incluye un método de ajuste fino — Self-Replay Fine-Tuning, destinado a ampliar las capacidades de un modelo de forma económica mientras reduce el olvido de lo que ya sabía.

• Detección y señalamiento fundamentados — Moondream 3 Preview: habilidades nativas en la arquitectura, coordenadas estructuradas, rastros de razonamiento fundamentados. MiniCPM-V 4.7: la comprensión de múltiples imágenes y de video son las fortalezas declaradas; la ficha no lidera en detección de vocabulario abierto.

• Vídeo — MiniCPM-V 4.7 admite entrada de vídeo, con un ejemplo documentado que utiliza 128 fotogramas. La ficha de Moondream 3 Preview documenta habilidades de imagen con caché de codificación de imágenes para consultas repetidas sobre la misma imagen.

• Detalle controlable — MiniCPM-V 4.7: un parámetro downsample_mode, 16x por defecto y 4x para un detalle más fino, que se elige en cada llamada. Moondream 3 Preview: concatenación de canales multi-crop en el codificador de visión, con la publicación de lanzamiento señalando que el codificador puede verse afectado por fuentes muy pequeñas.

• Licencia — MiniCPM-V 4.7: Apache 2.0, ambas variantes. Moondream 3 Preview: Business Source License 1.1 con una Concesión de Uso Adicional, que permite el uso comercial y en producción y prohíbe ofrecer Moondream alojado de propósito general. Moondream 3.1 pasó a la Moondream Model License 1.0 con la misma restricción central expresada de forma más clara.

La línea de licencia no es una nota al pie para esta comparación. Si tienes la intención de alojar el modelo para otras personas, los términos de Apache 2.0 y de código disponible de Moondream no son ni de lejos la misma posición de partida, y eso es cierto independientemente de cuál obtenga mejores resultados en las pruebas comparativas de tu tarea.

El ajuste fino es hacia donde apuntan ambas tarjetas, por razones opuestas

Ambos proveedores te dicen que el modelo base no es el producto, lo cual resulta refrescante y también es una pista sobre dónde reside el valor.

La publicación de lanzamiento de Moondream enumera la entrenabilidad como uno de sus cuatro objetivos, con el argumento de que las tareas de visión reales necesitan especialización —interpretar una radiografía, detectar a personas en apuros entre una multitud— y que incluso los humanos necesitan entrenamiento para esas tareas. La empresa lanzó Lens para ello, y el lanzamiento de Moondream 3.1 fue más allá: las puntuaciones de benchmark de 3.1 publicadas se generaron afinando LoRAs por tarea sobre la propia partición de entrenamiento de cada benchmark mediante Lens, y luego reincorporando lo que aprendieron de vuelta a los pesos base mediante destilación on-policy, de modo que el checkpoint descargable obtiene buenas puntuaciones sin ajuste. Eso merece leerse dos veces. Es un flujo de trabajo legítimo y una divulgación inusualmente transparente, y también significa que esos números no son cifras frías de un modelo recién salido de la caja: se alimentó al modelo con las particiones de entrenamiento de las tareas en cuestión.

El equivalente de OpenBMB es Self-Replay Fine-Tuning, orientado a un problema diferente: añadir capacidad sin olvidar la capacidad existente, a bajo coste. Su afirmación principal es sobre la retención en lugar de la puntuación máxima.

Si vas a ajustar cualquiera de los dos modelos, la diferencia práctica es la misma que atraviesa toda esta comparación. El camino de Moondream asume una GPU y un servicio alojado. El de MiniCPM-V 4.7 asume que puedes ajustar sobre los frameworks que ya ejecutas y luego desplegar en los dispositivos que ya tienes como objetivo, con una propuesta publicada de cuantización en el dispositivo que te lleve hasta allí.

Dónde una capa de enrutamiento se gana su lugar

Ninguno de los dos modelos que hay aquí se sirve a través de OrcaRouter: ambos son checkpoints de pesos abiertos que alojas tú mismo, y uno de ellos perderá su endpoint alojado el mes que viene. Eso hace que la pregunta interesante sea la que ambas fichas esquivan: ¿qué pasa con las solicitudes que tu modelo elegido gestiona mal?

La respuesta estándar es un segundo modelo, y el coste estándar de un segundo modelo es la integración: otro SDK, otro esquema de autenticación, otra política de reintentos. Es el tipo de trabajo que consume silenciosamente un sprint y luego se convierte en mantenimiento permanente. La fusión de modelos de OrcaRouter existe para la versión más concreta de ese problema —un panel de modelos que responden juntos en las llamadas donde la respuesta de un solo modelo no es lo suficientemente fiable por sí sola— y el DSL de enrutamiento para la versión más amplia, que te permite componer varios modelos en una sola llamada para que un modelo local barato se encargue de la mayoría fácil y algo más grande se ocupe del residuo.

Detrás de una sola clave hay más de 200 modelos al precio de lista del proveedor y sin margen añadido, lo que significa que una bajada de precio del proveedor te llega el mismo día en lugar de en el siguiente ciclo de facturación, y la conmutación por error entre proveedores es automática cuando un servicio upstream se degrada. Para un VLM autoalojado, la capa de enrutamiento se sitúa por encima del modelo en lugar de reemplazarlo. Esa es la descripción honesta de dónde encaja en esta comparación y, para un sistema en el que MiniCPM-V 4.7 35B-A3B está en el dispositivo y un modelo alojado cubre lo que se le escapa, es la parte que evita que los dos se conviertan en dos sistemas.

Cuál, decidido por la restricción que realmente tienes.

Si el modelo tiene que ejecutarse en el dispositivo, MiniCPM-V 4.7 35B-A3B es la respuesta y no hay comparación. OpenBMB construyó todo el lanzamiento en torno al problema de almacenamiento que impide que un MoE de 35B se ejecute en un teléfono —planificación de expertos, cuantización por capas, decodificación especulativa— y publicó la cifra que se deriva de ello: más de 13 tokens por segundo en unos 3 GB. Nada en Moondream 3 Preview aborda ese problema, porque Moondream eligió no tenerlo.

Si hay una GPU de por medio y la detección fundamentada es la tarea, Moondream 3 Preview es el instrumento más especializado. La detección y el señalamiento nativos con coordenadas estructuradas y trazas de razonamiento fundamentado inspeccionables son un producto distinto de un modelo multimodal general que también lee texto en imágenes, y si una persona revisa la salida, la traza es la característica.

Si dudas entre los dos, no lo decidas a partir de las tablas de benchmark. Ejecuta tus propias imágenes con ambos usando tus propios prompts y puntúa los resultados, porque la única cifra de esta comparación que sobrevivirá al contacto con tu carga de trabajo es la que generes tú mismo. Y revisa la licencia antes que el modelo, porque Apache 2.0 y una licencia source-available con restricción de servicio alojado son una decisión completamente distinta — una de ellas puede poner fin a la evaluación antes de que importen las cifras de precisión.

Comparaciones como esta son también donde se manifiestan los modos de fallo: los incidentes de IA documentados y los fallos de agentes que hay detrás de los modelos de esta clase se recopilan en the OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, su gravedad, su grado de confianza y su indicador de disputa.