NVIDIA Nemotron Labs Dory 1.0 4B vs MiniCPM5 2B: un runtime personalizado frente a un LlamaForCausalLM común

Lo más útil que hay que observar sobre NVIDIA Nemotron Labs Dory 1.0 4B y MiniCPM5-2B no es la tabla comparativa de ninguno de los dos modelos, sino lo que aparece en la primera línea de la sección de arquitectura de MiniCPM5-2B. Su ficha dice, sin rodeos, que la arquitectura es un LlamaForCausalLM estándar: 42 capas, atención de consultas agrupadas con 16 cabezas de consulta y 2 cabezas KV, sin kernels personalizados, sin necesidad de bifurcar el código del modelo. La ficha de Dory dice lo contrario en todos los sentidos prácticos. Su arquitectura es una red recurrente latente en bucle cuyo bloque de capas se aplica un número variable de veces, y para servirla hoy hay que instalar vLLM desde una solicitud de extracción abierta o compilar llama.cpp desde un commit fijado. Uno de estos modelos se integra directamente en la pila que ya tienes. El otro exige que primero cambies la pila. Esa diferencia decidirá más implementaciones que cualquier puntuación que haya publicado cualquiera de los dos proveedores.

Dos modelos pequeños, dos apuestas completamente diferentes

N​VIDIA N​emotron Labs Dory 1.0 4B es el modelo denso con bucles de 4B de N​VIDIA, publicado en Hugging Face en BF16, MXFP8, NVFP4 y Q5_K_M GGUF bajo la licencia OpenMDW 1.1, con su ficha marcada como «GA (10/16/2026)». Es solo texto y solo en inglés, admite hasta 256K tokens e introdujo aproximadamente 6 billones de tokens de preentrenamiento en una pila entrenada de forma nativa en NVFP4 durante los primeros ~4,5T antes de cambiar a BF16; luego se extendió a contexto largo con 300B tokens y se finalizó con SFT más aprendizaje por refuerzo GRPO en múltiples entornos. Se publicó sin ningún tipo de anuncio.

MiniCPM5-2B es el modelo denso de 2,5B de OpenBMB — 2.516.756.480 parámetros en total, de los cuales 1.981.982.720 no son de embedding — bajo la licencia Apache 2.0, con una ventana de contexto de 131.072 tokens y soporte bilingüe en inglés y chino. Es la segunda entrada de la línea MiniCPM5 tras el 1B, construida para escalar lo que la ficha denomina la misma receta de entrenamiento, y está orientada explícitamente a despliegues en el propio dispositivo, locales y con recursos limitados. El postentrenamiento incluyó ajuste fino supervisado, aprendizaje por refuerzo y destilación on-policy. La ficha declara un estado del arte de código abierto de la clase 2B con un promedio de 53,9 en su conjunto de benchmarks.

Ambos son lo bastante pequeños para ejecutarse en un solo acelerador. Ambos se pueden descargar hoy mismo. A partir de ahí, todo diverge.

El contraste, dimensión por dimensión

• Arquitectura — Dory 1.0 4B es un GPT latente recurrente en bucle, normalizado, con atención de ventana deslizante y atención completa intercaladas, un bloque de entrada de 8 capas, un bloque recurrente de 20 capas y un bloque de salida de 8 capas. MiniCPM5-2B es un transformer causal denso convencional, de 42 capas, GQA de 16 cabezas por 2 cabezas KV, LlamaForCausalLM.

• Coste de entrada de servicio — este es el titular. MiniCPM5-2B no necesita ningún kernel personalizado ni un motor bifurcado; si tu stack ejecuta modelos con forma de Llama, ejecuta este. Dory necesita vLLM compilado a partir de una pull request no fusionada o llama.cpp compilado a partir de un commit fijado, con anulaciones en tiempo de ejecución para el recuento de bucles y el modo de caché KV.

• Parámetros — 4B densos frente a 2.516B totales (1.98B sin embeddings). Dory es aproximadamente un 60 % más grande, y su bloque recurrente se aplica de forma repetida, por lo que su cómputo efectivo por token con cuatro iteraciones supera lo que sugiere el recuento de parámetros.

• Contexto — Dory alcanza 256K tokens con 262.144 posiciones validadas en vLLM. MiniCPM5-2B admite 131.072. La ventana de Dory es el doble; si estás dispuesto a pagar por ello es la cuestión de la caché KV que se trata a continuación.

• Idiomas — Dory es solo inglés, con 43 lenguajes de programación en su mezcla de preentrenamiento. MiniCPM5-2B es bilingüe en inglés y chino. Para una carga de trabajo en chino, esta dimensión zanja la comparación sin necesidad de consultar ninguna otra fila.

• Licencia — OpenMDW 1.1 para Dory, Apache 2.0 para MiniCPM5-2B. Ambas permiten el uso comercial; Apache 2.0 es la que ya ha aprobado la mayoría de las revisiones legales.

• Flexibilidad de cómputo — la profundidad de Dory es un parámetro en tiempo de ejecución: un bucle para latencia, dos como predeterminado recomendado, cuatro cuando la precisión agéntica importa más, todo desde un único checkpoint. MiniCPM5-2B tiene profundidad fija, y su palanca de rendimiento es la cuantización — la familia incluye compilaciones GGUF, MLX, GPTQ y LiteRT, además de un modelo draft DSpark para decodificación especulativa.

• Ecosistema — MiniCPM5-2B es público desde principios de septiembre de 2026 y tiene más de un millón de descargas y una variedad de compilaciones cuantizadas y derivadas. Los cuatro repositorios de Dory se poblaron de la noche a la mañana y sus contadores de descargas estaban en cero cuando se escribió esto.

Los números, y por qué no deberías restarlos.

Ambas tarjetas publican tablas de referencia, y las tablas coinciden en suficientes tareas como para que sea posible una comparación en paralelo. Vale la pena hacerlo con cuidado, porque una resta ingenua resultaría engañosa de una manera concreta y predecible.

Lee Dory en sus tres configuraciones de bucle frente a la única cifra reportada de MiniCPM5-2B:

• SciCode — 27.3 / 34.94 / 35.11 frente a 26.3. A partir de dos bucles, Dory lidera.

• SWE-bench Verified — 50,3 / 59,5 / 61,8 frente a 46,4.

• Terminal-Bench 2.1 — 12.5 / 18.1 / 22.2 frente a 8.6.

• GPQA Diamond — 69.19 / 72.41 / 72.16 frente a 70.2. Incluso con un solo bucle, Dory está nominalmente por detrás; con tres o más bucles, se adelanta ligeramente.

• HLE, solo texto — 8.25 / 10.89 / 10.43 frente a 8.9.

• IFBench — 74.29 / 77.94 / 79 frente a 66.3.

• AA-LCR — 63 / 71 / 73 frente a 59.0.

Dory se ve más fuerte en la mayoría de estas, a veces por mucho. Ahora bien, la razón para no creer en la aritmética: son dos arneses distintos que miden dos conjuntos de prompts diferentes, y ninguno de los dos proveedores ejecutó el modelo del otro. N​VIDIA midió Dory en NeMo Gym y el Nemo Evaluator SDK, con recuentos de repeticiones por benchmark que la ficha divulga: SciCode ocho veces, AA-LCR dieciséis, y varios benchmarks exactamente una vez. OpenBMB midió MiniCPM5-2B con su propia configuración y reportó un único promedio de 53,9 en su suite. Una diferencia de dos o tres puntos entre esas dos configuraciones es ruido, no un veredicto. Nada en ninguna de las dos fichas es una reproducción independiente, y ningún tercero ha publicado una comparación directa de estos dos modelos.

Hay una razón estructural para esperar que la aparente ventaja de Dory sea real en tareas agénticas y se desvanezca en otros contextos. Su ficha muestra que la iteración en bucle es la que más aporta en SWE-bench y Terminal-Bench, y la que menos en recuperación de conocimiento: AA-Omniscience apenas varía según el número de bucles. La propia fortaleza de MiniCPM5-2B se reparte de forma distinta: reporta 97,1 en τ²-Bench Telecom y 88,7 en GAIA Text-103, resultados agénticos que la ficha de NVIDIA no mide de forma comparable. Si tu tarea es el uso de herramientas en un dominio limitado, los números de la ficha de MiniCPM son los que hay que probar primero, y ninguno de ellos aparece en la hoja de Dory.

Fíjate también en lo que las dos tarjetas evitan comparar. MiniCPM5-2B se evalúa frente a Qwen3.5-4B en 51,1, frente a granite-4.2-3B en 42,7 y frente a LFM2.5-2.6B en 33,2 según su propio promedio. Dory se evalúa frente a Qwen3.5-4B, Qwen3.5-9B, Gemma 4 26B A4B y Qwen3.6-35B-A3B. El único modelo al que ambas tarjetas le ponen un número es Qwen3.5-4B, y lo puntúan de forma distinta, lo que dice más sobre los arneses de evaluación que sobre Qwen.

Cuánto te cuesta operar cada uno

La historia operativa de MiniCPM5-2B es la aburrida, y lo aburrido es un cumplido aquí. Arquitectura estándar, sin kernels personalizados, una variedad de cuantizaciones listas para usar, y una familia que ya incluye versiones MLX para Apple Silicon, GPTQ para inferencia en GPU, LiteRT para móviles y un modelo borrador para decodificación especulativa. Un modelo de 2.5B con forma de LLaMA y contexto de 128K cabe en memoria modesta y se puede servir en los motores que ya ejecutas. OpenBMB presenta toda la línea como diseñada para el dispositivo y con recursos limitados, y nada en la ficha requiere que adoptes nada nuevo.

La historia operativa de Dory es la interesante y no está terminada. El soporte de vLLM está en revisión en la pull request 60149; hasta que se fusione, la ficha te indica que instales vLLM desde esa rama con la bandera de kernel precompilado activada, y luego lo lances con anulaciones que configuren el recuento de bucles recurrentes y el modo de caché KV. El soporte de llama.cpp está en la pull request 30306, con una revisión fijada en lugar de la cabeza móvil, e instrucciones de compilación dirigidas a macOS ARM64 nativo en Apple Silicon. Las únicas cifras de velocidad de Dory publicadas por N​VIDIA son aceleraciones de cuantización en un DGX Spark — 1,69× y 1,84× para MXFP8 sobre BF16 dependiendo de la mezcla de entrada/salida, 2,17× y 2,44× para NVFP4 — no cifras de rendimiento. No hay ningún endpoint alojado para Dory en ningún lugar que podamos verificar.

La única pieza de ingeniería genuinamente novedosa del lado de Dory es el diseño de memoria, y es la afirmación que más vale la pena poner a prueba antes de comprometerse. El bucle recurrente estándar mantiene una caché KV separada por bucle, por lo que la memoria aumenta con cada pasada adicional. Dory admite un modo de caché KV de último bucle que mantiene una única caché por capa de atención recurrente y la sobrescribe en cada pasada, manteniendo la huella en aproximadamente el tamaño de un solo bucle sin importar cuántos bucles se ejecuten. NVIDIA afirma que la precisión se mantiene cercana a la del modo por bucle, con longitudes de salida casi sin cambios. Si eso se cumple, la profundidad elástica es una capacidad real; si la precisión se desvía, la función cuesta más de lo que la tarjeta implica. Nadie fuera de NVIDIA lo ha comprobado.

Donde un router se gana su lugar — y donde no

MiniCPM5-2B no está en el catálogo de OrcaRouter, y NVIDIA Nemotron Labs Dory 1.0 4B tampoco. Dory no tiene ningún endpoint alojado que podamos confirmar; MiniCPM5-2B es un modelo en dispositivo cuya ficha está escrita para despliegue local, no para una plataforma de inferencia. Decirlo sin rodeos importa más que buscarle un ángulo, porque el efecto práctico es que ambos lados de esta comparación se ejecutan en hardware que tú posees.

Ahí es cuando el baseline alojado se convierte en la parte incómoda del experimento. La mayoría de los equipos que evalúan un modelo de 2B o 4B no lo hacen en el vacío: se preguntan si puede sustituir una llamada a un servicio alojado por una fracción del coste y una fracción de la capacidad, y responder a esa pregunta implica ejecutar el modelo alojado con el mismo conjunto de tareas. Una sola clave de OrcaRouter llega a esos modelos alojados al precio de lista del proveedor con un 0% de recargo, sin un segundo contrato y sin un segundo SDK, así que la comparación no necesita su propio proceso de compras. La conmutación automática por error importa aquí por una razón distinta: una evaluación local prolongada en una sola GPU se verá interrumpida, y tener la ruta de respaldo ya conectada detrás del mismo endpoint mantiene la ejecución activa. El DSL de enrutamiento permite que un endpoint local y uno alojado compartan un único punto de llamada, de modo que las dos mitades de un despliegue híbrido no se bifurquen en dos bases de código. Nada de esto elige un ganador entre Dory y MiniCPM5-2B. Hace que descartar al perdedor salga barato.

El veredicto

Elige MiniCPM5-2B si la fricción de despliegue importa más que las puntuaciones máximas de agentes. Es Apache 2.0, la mitad de tamaño, bilingüe, de arquitectura estándar y está rodeado de cuantizaciones, incluidos entornos de ejecución móviles. Si tu equipo tiene que lanzarlo este mes y la alternativa es pelearse con una compilación del kernel, el 2.5B gana solo por logística, y sus resultados reportados en τ²-Bench y GAIA sugieren que no cede mucho en las tareas de uso de herramientas para las que realmente se despliegan los modelos pequeños.

Elige N​VIDIA N​emotron Labs Dory 1.0 4B si lo que quieres no es un modelo sino un experimento: un único checkpoint que escala su propia precisión con el cómputo de inferencia, una ventana de 256K con un diseño de caché pensado para que eso resulte asequible, y una licencia que permite el despliegue comercial. Entra sabiendo que construirás tu motor de servicio a partir de una rama, que cada cifra publicada es del propio proveedor, obtenida en su propio harness y con los recuentos de repetición divulgados en una nota al pie, y que los contadores de descargas siguen en cero. La ventaja es que estarías entre las primeras personas fuera de N​VIDIA en probar una forma genuinamente distinta de gastar cómputo en un modelo pequeño. El coste es que estarías haciendo por él el trabajo de verificación de N​VIDIA.

Lo que cambiaría más rápido esta comparación no es un benchmark. Es que vLLM y llama.cpp fusionen sus pull requests de Dory. En el momento en que Dory se cargue desde un binario publicado, el argumento de la fricción que actualmente favorece a MiniCPM5-2B desaparece en gran medida, y los dos modelos por fin compiten en los términos que implican las tablas de benchmark en lugar de en los términos que impone tu sistema de compilación.

Nada de eso es hipotético: los fallos documentados de IA y los incidentes de agentes detrás de lanzamientos como este se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, severidad, grado de confianza e indicador de disputa.