Inicio / Artículos

minicpmsmall-language-modelsbenchmarksagentsquantization

MiniCPM5-2B vs 4B Rivals: Por qué un arnés agente cuenta una historia diferente

MiniCPM5-2B supera a sus rivales 4B en puntuaciones de un solo disparo, pero queda dos a tres veces por detrás en sistemas de agente. Confusión en las pruebas de referencia y rendimiento de Ollama.

Editor: REACTAPP.TOP10 min de lectura2397 palabras

Fuentes: The 2B Model That Beats 4B Rivals — Until You Test It as an Agent

Un modelo con 2.5 mil millones de parámetros que supuestamente supera a sus competidores de 4 mil millones en pruebas de codificación de élite suena como una buena oferta. Sin embargo, al integrar ese mismo modelo en un sistema agente de múltiples turnos real, su rendimiento disminuye hasta en tres veces. Las evaluaciones de un solo intento no dicen mucho sobre la compleja realidad de la ingeniería de software en producción. Mirar más allá de las puntuaciones globales e imprimir el rendimiento localmente proporciona un marco concreto para determinar cuándo este modelo es la herramienta adecuada.

La afirmación

OpenBMB publicó MiniCPM5-2B el 7 de septiembre de 2026. Se trata de un modelo de lenguaje causal denso con 2.516 mil millones de parámetros, una licencia Apache 2.0 y un contexto nativo de 131,072 tokens. Según el anuncio, es el mejor modelo abierto por debajo de los 4B, con un promedio de 53.9 en 34 pruebas de rendimiento, superando a varios competidores de la categoría 4B, incluido Qwen3.5-4B, cuyas puntuaciones son: MATH-500 en 94.6, AIME 2026 en 86.5, LiveCodeBench v6 en 69.1 y SWE-bench Verified en 46.4.

Nadie está mostrando aquí una captura de pantalla del ranking seleccionada a dedo. El lanzamiento fue organizado y serio: ocho artefactos aterrizaron al mismo tiempo. El conjunto incluye puntos de control para la etapa básica, el entrenamiento intermedio y el SFT por separado, además del modelo final ajustado con RL y OPD, conversiones a GGUF y MLX, una versión de GPTQ en 4 bits, y un modelo preliminar de decodificación especulativa llamado MiniCPM5-2B-DSpark. Un laboratorio que simplemente prueba un benchmark de forma discreta no lanza sus resultados de esa manera. Este parece esperar un examen detallado y llega con archivos para cada entorno de ejecución objetivo, desde llama.cpp y Ollama pasando por LM Studio, vLLM y SGLang hasta Transformers, MLX y FlagOS multi-chip.

Según las afirmaciones, cuando está en su capacidad máxima, un modelo aproximadamente un 44 por ciento más pequeño que Qwen3.5-4B supera a este último en pruebas de matemáticas, código e ingeniería de software. Si esto fuera cierto sin reservas, constituiría un dato significativo sobre la escalabilidad en modelos orientados al razonamiento tras el entrenamiento. Sin embargo, no es así sin reservas, y lo interesante es precisamente dónde falla y por qué.

Qué hay detrás

Saber qué se está ejecutando realmente ayuda, ya que la arquitectura tiene en cuenta tanto las fortalezas como los puntos ciegos. MiniCPM5-2B es un decodificador construido de manera similar a LlamaForCausalLM: 42 capas de transformador que utilizan atención de consulta agrupada, con 16 cabezas de consulta que comparten 2 cabezas de clave/valor. Una relación de 8 a 1 es notable para un modelo de este tamaño. Esto reduce considerablemente la caché KV por token, lo cual es ventajoso cuando es necesario conservar historiales largos de llamadas a herramientas o cuando muchas sesiones de agente comparten una GPU. No se utiliza atención esparsa ni lineal exótica, aunque los modelos relacionados de la familia MiniCPM, MiniCPM-SALA y MiniCPM4, experimentaron con híbridos. El equipo optó por mantener el mecanismo familiar e invertir en otros aspectos.

Lo que determina esto es la longitud del contexto y la selección cuidadosa de los datos de entrenamiento. Un número nativo de 131,072 tokens es inusual en modelos con menos de 3 mil millones de parámetros, ya que la mayoría de los modelos de ese tamaño alcanzan un máximo de entre 32K y 64K tokens antes de que disminuya su calidad. En tareas que requieren capacidad de agencia, donde el modelo debe mantener un registro cada vez más extenso de llamadas, diferencias y salidas de la shell, ese margen adicional es más importante que la simple cantidad de parámetros.

El modelo solo maneja inglés y chino, sin capacidad de visión ni audio. Se trata de una limitación intencionada, no de un descuido, ya que cada parámetro invertido en la alineación multimodal es uno que no se destina al razonamiento ni al uso de herramientas. OpenBMB también publicó los datos posteriores al entrenamiento: UltraData-SFT-Agent-2609 con 500K muestras de trayectorias de agentes y UltraData-RL-2609 con más de 80K muestras de aprendizaje por refuerzo. Eso representa una verdadera transparencia, ya que el comportamiento del agente integrado en el modelo puede ser inspeccionado en lugar de deducirse a partir de las diferencias en las pruebas de referencia.

Al comprender la arquitectura, las afirmaciones de las pruebas de referencia pasan de ser números abstractos a hipótesis verificables sobre un decodificador específico y una metodología de entrenamiento concreta.

La primera brecha: 23 contra 15

Los problemas surgieron dentro de un día del lanzamiento. El anuncio de OpenBMB indicó una puntuación de 23 en el Índice de Inteligencia de Análisis Artificial para el modelo, mientras que el rastreador independiente de Artificial Analysis mostró 15. Una revisión posterior del índice situó la puntuación cerca de 13. La reacción esperada fue preguntarse si OpenBMB había inflado sus propios números.

No fue así, y este caso merece un análisis detallado, porque la indignación refleja es la respuesta incorrecta ante una discrepancia en las métricas de referencia, pero también la más común. La nota metodológica de Artificial Analysis explica esta diferencia. En resumen, la discrepancia no se debe a que el modelo haya empeorado. La forma de evaluación cambió: los conjuntos de pruebas privados ahora representan el 40 por ciento del peso total, en comparación con versiones anteriores, y la versión 4.2 añadió dos componentes nuevos, la evaluación basada en AA-Briefcase y una prueba de contexto largo.

La cifra de 23 de OpenBMB se obtuvo con el Intelligence Index v4.1.1. Para cuando la gente comparó las cifras, el seguimiento público ya había pasado a la versión v4.2, con un sistema de ponderación diferente y dos componentes que no existían cuando se calculó la cifra inicial. Comparar 23 en una versión con 15 en otra no revela ninguna mentira; simplemente se comparan dos instrumentos de medición distintos y luego se expresa sorpresa por que den resultados diferentes.

El verdadero error corresponde a las primeras coberturas periodísticas que publicaron ambas cifras una al lado de la otra sin indicar que provenían de versiones diferentes del índice, lo que llevó a una conclusión errónea que los datos nunca respaldaron. Un artículo que cite una puntuación total del índice debe indicar la versión correspondiente. Si no lo hace, 23 y 15 no pueden compararse y en realidad son dos preguntas diferentes que comparten un mismo nombre.

Ese problema se puede resolver. Otro no se puede solucionar con tanta facilidad.

La verdadera brecha: los harnesses de agencia

La cifra que debería cambiar la forma en que se percibe este modelo proviene de Terminal-Bench v2.1. MiniCPM5-2B obtiene puntuaciones entre 8.6 y 9 allí, mientras que Qwen3.5-4B alcanza 25.8. Eso representa una brecha de aproximadamente tres veces, lo que dejó a MiniCPM5-2B en el octavo lugar en ese benchmark, a pesar de que lidera el Intelligence Index entre los modelos de su tamaño. SWE-bench Pro muestra la misma situación, con 14.4 para MiniCPM5-2B frente a 28.2 para Qwen3.5-4B, lo que equivale a una brecha de aproximadamente dos veces.

Colóquelo junto a la afirmación sobre el lanzamiento. El resultado verificado de 46.4 de OpenBMB en SWE-bench, presentado como una superación de Qwen3.5-4B, es uno de los pilares del titular sobre las ventajas de beats-4B. Sin embargo, SWE-bench Pro no es la misma prueba con un nombre más intimidante; utiliza un conjunto más amplio y adversarial de problemas reales de repositorios y funciona a través de un entorno de agente real, donde la opción Verificado se acerca más a la generación de parches de un solo intento. Terminal-Bench está aún más alejado de la evaluación de un solo intento: se trata de un entorno de terminal en tiempo real en el que el modelo debe planificar, ejecutar comandos, leer los resultados y recuperarse de sus propios errores a lo largo de varias interacciones.

Una evaluación independiente realizada por MindStudio lo expresó sin rodeos: el modelo muestra potencial en algunos benchmarks de agente, pero queda muy por detrás de Qwen en las pruebas de agente más difíciles, como SWE-bench Pro y Terminal-Bench.

Este resultado, mucho más que la discrepancia entre la versión del índice, debería ajustar las expectativas. Las recompensas verificadas corresponden a la elaboración de un parche correcto para una tarea ordenada y cuidadosamente definida, que consiste en la generación de una sola solución presentada como trabajo de ingeniería. Terminal-Bench y SWE-bench Pro premian el hecho de mantenerse en el camino correcto a lo largo de numerosas utilizaciones de la herramienta, recuperarse de un comando de shell que falló y evitar el colapso tres pasos antes de completar un plan. El modelo es evidentemente bueno en el primer tipo de tarea y claramente más débil en el segundo. Cualquiera que lo utilice como subagente autónomo para codificar, en lugar de un generador de parches de una sola etapa, se encontrará con las limitaciones del segundo tipo.

Esta brecha es real y no está resuelta, y ningún artefacto metodológico puede explicarla, por lo que merece ser verificada manualmente en lugar de confiar en las cifras totales de cualquiera de las partes.

Reproducirlo localmente

Parece que nadie ha publicado un análisis sistemático de los tokens por segundo según el nivel de cuantización en hardware real. La información disponible suele repetir la tabla de pruebas del lanzamiento o incluye solo un dato anecdótico sobre velocidad. Los números que se presentan a continuación corresponden a una sola ejecución, no a un análisis controlado con diferentes valores de inicialización y tamaños de lote; por lo tanto, sirven como punto de partida para realizar mediciones locales y no como conclusión definitiva.

Uso de memoria según el nivel de cuantización en un contexto de 8K:

  • Q4_K_M: aproximadamente 2.78 GB
  • Q8_0: aproximadamente 3.7 GB
  • BF16/FP16: aproximadamente 6.3 GB

Rendimiento reportado por fuentes independientes: aproximadamente 144.23 tokens por segundo en una RTX 3070 Ti con 8 GB de VRAM, utilizando la cuantización Q4 en LM Studio con un solo flujo, lo cual corresponde a una tarjeta de consumo modesta. En el rango más alto, una discusión en Hacker News sobre el lanzamiento mencionó 32 subagentes funcionando simultáneamente en un DGX Spark, con un promedio de 931 tokens por segundo en conjunto y un pico de 1,364. Esa segunda cifra se ajusta al uso previsto; el objetivo no es ganar una competencia de latencia en un solo flujo. La relación GQA y el tamaño reducido están diseñados para servir muchas sesiones al mismo tiempo, y 32 agentes compartiendo un nodo se adaptan perfectamente a ello.

La forma más rápida de reproducir cualquier cosa es Ollama:

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# Recommended flags for flash attention + quantized KV cache
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve &

# Run directly from Ollama's registry
ollama run openbmb/minicpm5-2b

Para una cuantización específica extraída de Hugging Face e integrada en llama.cpp:

huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
  MiniCPM5-2B-Q4_K_M.gguf \
  --local-dir ./minicpm5-2b-gguf

Y para un servicio a escala compatible con OpenAI, vLLM:

pip install vllm

vllm serve openbmb/MiniCPM5-2B \
  --max-model-len 131072 \
  --dtype bfloat16 \
  --port 8000

# Query it like any OpenAI chat completion endpoint
curl http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "openbmb/MiniCPM5-2B", "messages": [{"role": "user", "content": "Write a quicksort in Rust"}]}'

La calidad varía según la tarea de maneras que los benchmarks globales no reflejan. Las pruebas prácticas con GGUF realizadas por MindStudio mostraron que el modelo Q8_0 manejaba bien la programación autónoma y el razonamiento matemático y físico verificable, pero falló gravemente en una tarea de depuración de SQL específica de un esquema y en la traducción multilingüe, dando respuestas seguras pero factualmente incorrectas.

Ese comportamiento erróneo pero seguro tiene más importancia que cualquier porcentaje de precisión. Los fallos evidentes son fáciles de detectar durante la revisión, pero es precisamente un fallo presentado con certeza como causa de que una migración SQL defectuosa llegue a producción. La reproducibilidad también presenta otro problema: llama.cpp se comporta de manera bastante diferente según su versión de compilación y según cómo el frontend aplica el template de chat. Cuando los resultados locales difieren de los de otra persona, verifique la versión de compilación antes de concluir que el modelo ha cambiado.

En conjunto, las pruebas locales coinciden con las diferencias observadas en Terminal-Bench y SWE-bench Pro. Las tareas bien delimitadas y verificables se realizan sin problemas, pero la situación se vuelve más incierta cuando se requiere un conocimiento preciso de un esquema externo o un juicio multietapa abierto. Fuentes independientes coinciden de manera consistente en este patrón, lo que permite confiar en él y tomar la decisión final.

Cuándo este modelo es la opción adecuada

Una vez eliminada la controversia sobre los benchmarks, queda un marco de toma de decisiones útil, que no equivale a un veredicto de calidad buena o mala.

Casos de uso ideales:

  • Grupos de muchos subagentes que operan al mismo tiempo. La eficiencia de memoria de GQA y los 931 tokens por segundo generados por 32 agentes en un DGX Spark son los factores decisivos, mucho más importantes que la puntuación del índice.
  • Despliegue en el dispositivo y en el perímetro. Una versión de 2,78 GB para el cuarto trimestre funciona sin problemas en hardware de consumo, teléfonos y mini-PCs a través de GGUF o MLX.
  • Flujos de trabajo que almacenan registros o documentos largos de herramientas y utilizan realmente la ventana de 131K, sin una capa de recuperación separada.
  • Inferencia local donde la latencia es importante, utilizando MiniCPM5-2B-DSpark como modelo preliminar para la decodificación especulativa.

Casos en los que no es adecuado:

  • Generación de código de forma libre o creativa. Las pruebas externas mostraron resultados más débiles en comparación con modelos de programación especializados en tareas como crear páginas HTML o arte SVG, ya que la fortaleza del modelo radica en el razonamiento, las matemáticas, el uso de herramientas y la llamada a funciones.
  • Depuración de SQL específica de esquemas y traducción multilingüe, áreas en las que ha fallado de manera contundente y sin flexibilidad.
  • Cualquier tarea que se ejecute a través de un sistema de agente más complejo. Un agente de codificación en entornos de producción que realice sesiones terminales de múltiples turnos o tareas de nivel profesional en entornos de pruebas presentará una diferencia de dos a tres veces mayor frente a Qwen3.5-4B, y eso no se debe a un error de redondeo.

Por equidad, y ya que las opiniones apresuradas suelen pasar por alto este punto: la objeción de que las comparaciones utilizan versiones obsoletas como Qwen2.5-2B o Gemma-2B corresponde a comentarios secundarios y no a la ficha oficial del modelo. Dicha ficha compara el modelo con versiones actualizadas como Qwen3.5-2B, Gemma-4-E2B-it, granite-4.2-3B y LFM2.5-2.6B. Las críticas a esta versión deberían dirigirse a su verdadero punto débil, la brecha con los sistemas de agente más avanzados, y evitar quejas basadas en versiones obsoletas que la fuente principal ya refuta.

Las afirmaciones de las pruebas de rendimiento son específicas de cada prueba

Más allá de este modelo en particular, la lección más importante es la que merece conservarse. La afirmación sobre beats-4B es cierta pero limitada. Se basa en las matemáticas de OpenBMB y en el conjunto de pruebas de programación de un solo intento AIME, LiveCodeBench y SWE-bench Verified, así como en el agregado de Artificial Analysis una vez que se corrija la versión. Falla en Terminal-Bench y SWE-bench Pro, donde Qwen3.5-4B supera con una ventaja de dos a tres veces. Todo eso es correcto al mismo tiempo.

El procedimiento para cualquier futura afirmación relacionada con modelos menores a 4B es: someterlos al menos a una prueba adversaria similar al trabajo real, como Terminal-Bench, SWE-bench Pro o algo equivalente, antes de permitir que un conjunto de pruebas de un solo intento prediga el rendimiento del modelo. Crear un parche y llevar a cabo una tarea de varias etapas son habilidades distintas, y un modelo puede destacar en la primera mientras es promedio en la segunda. El agregado publicado en Twitter nunca indica cuál de estas habilidades se está evaluando.

En cualquier índice agregado con versión fija, ya sea de Artificial Analysis o de cualquier otra fuente, el número de versión no es un metadato opcional. Sirve para distinguir una discrepancia real de una fabricada artificialmente. El caso de 23 contra 15 pareció un escándalo durante aproximadamente un día, hasta que las notas metodológicas revelaron un simple aumento de versión rutinario. La próxima controversia relacionada con pruebas de rendimiento podría resolverse de la misma manera o no, y la única forma de saberlo es verificarlo.

Qué llevarse como conclusión

Considerando su tamaño, MiniCPM5-2B está realmente bien diseñado: cuenta con 42 capas, una relación GQA de 8 a 1, 131K de contexto nativo, datos de entrenamiento abiertos y ocho artefactos coordinados que abarcan desde un DGX Spark hasta una computadora portátil. El hecho de que funcione bien en algunas pruebas de rendimiento y no en otras no resta valor a ninguno de estos aspectos. Las pruebas de rendimiento son herramientas específicas, cada una destinada a medir algo concreto, y una puntuación total nunca refleja la historia completa.

Antes de adoptar el próximo modelo pequeño que suene demasiado bueno para ser verdad, reproduzca al menos una prueba de referencia de agente adversarial y confirme la versión detrás de cualquier puntuación de índice agregado. Un único número en un titular no debería determinar una arquitectura.

Leer más

← Todos los artículosEnviar el brief