Microsoft-Decision-1 vs Intern-Decision-2B: nueve milisegundos más rápido y mediblemente peor calibrado

Hay un número en la propia tabla de InternLM que no debería existir, y es la razón por la que esta comparación vale más que la hoja de especificaciones. Intern-Decision-2B — 2.213.241.664 parámetros, ajustado mediante fine-tuning a partir de Qwen/Qwen3.5-2B, subido a Hugging Face el 26 de septiembre de 2026 a las 05:36:19 UTC sin ningún anuncio — registra una 33,28 ms de latencia media por consulta en una sola RTX 4090, ligeramente más rápida que la de su propio hermano de 852 millones de parámetros, con 33,98 ms. También registra la peor calibración de su familia: un error de calibración esperado de 0,100 frente al 0,066 del 0.8B, con una temperatura ajustada de 2,100509348278 frente al 2,747760550703 del 0.8B. Mientras tanto, Microsoft-Decision-1, con disponibilidad general en Microsoft Foundry desde el 8 de octubre de 2026, no publica ninguna cifra de latencia ni ningún error de calibración — solo un párrafo de metodología que describe cómo se midieron ambos. Así que la pregunta que realmente plantea este enfrentamiento no es cuál de los dos es mejor. Es qué estás comprando cuando compras el tamaño intermedio de cualquier cosa.

Ambos modelos son puntuadores de decisiones: entra un estado, entra un conjunto acotado de preguntas, salen probabilidades calibradas, no hay texto generado ni tokens que analizar. Ese contrato compartido es lo que hace legibles las diferencias. Microsoft-Decision-1 es una API de Foundry alojada y solo de texto sobre una base Qwen3.5-9B con una ventana de 32.768 tokens, sin pesos distribuidos y sin vía de ajuste fino. Intern-Decision-2B es un checkpoint Apache-2.0 con la licencia original de Qwen conservada como LICENSE-QWEN, aproximadamente 4,46 GB de repositorio, código de inferencia personalizado y ningún endpoint alojado en ningún lugar.

Para qué sirve realmente el tamaño mediano

InternLM publicó tres checkpoints en cuarenta segundos: el 0.8B a las 05:35:57, este a las 05:36:19, el 4B a las 05:36:37. En el promedio de siete suites del propio proveedor, la familia asciende en el orden que uno desearía —79.38, 84.68, 90.02—, que es el único punto en el que el 2B parece una compra sensata. En todo lo demás, parece el tamaño que nadie habría elegido a propósito.

El procesamiento del prompt domina una llamada de decisión, y esa es la explicación mecánica de la inversión de latencia en lugar de un misterio. Un evaluador hace exactamente un pase hacia adelante sobre un prompt cuya longitud está determinada por el estado, el esquema y las descripciones de las opciones — nunca por nada que el modelo escriba, porque no escribe nada. En ese régimen, el recuento de parámetros es un costo de segundo orden, por lo que la razón habitual para recurrir al checkpoint más pequeño no se aplica: no estás ahorrando tiempo, estás ahorrando memoria. Todo el repositorio del 0.8B es de aproximadamente 1,73 GB frente a los 4,46 GB de este modelo, y esa es la razón honesta para preferirlo. La única afirmación real del 2B es que resulta ser el más rápido de los rápidos, por un margen lo suficientemente pequeño como para ser ruido.

Comparado con Microsoft-Decision-1, esa afirmación es casi irrelevante, porque los dos modelos no operan en el mismo régimen de latencia. La velocidad de un endpoint alojado es función de la forma de tu despliegue —sin servidor frente a rendimiento aprovisionado sobre el mismo SKU estándar— antes que del modelo, y Microsoft no publica ninguna cifra por llamada con la que comparar. Lo que Microsoft sí publica es una restricción operativa estricta que apunta en la dirección opuesta: la inferencia por lotes está deshabilitada. No hay ningún canal offline por el que amortizar una ejecución de puntuación masiva, así que un pipeline de Microsoft-Decision-1 paga el coste interactivo de cada decisión, mientras que un checkpoint autoalojado paga en horas de GPU puntúe o no.

La columna de calibración, donde el medio pierde

Lee las tres tarjetas de Intern-Decision en conjunto y la familia deja de comportarse de forma predecible. La precisión es monótona con el tamaño; la calibración no. La 2B tiene un ECE de 0.100 —la más débil de las tres— y una temperatura ajustada de 2.100509348278, muy por debajo de la 2.747760550703 de la 0.8B. La tarjeta te indica que uses el módulo de inferencia que se incluye con el tamaño que descargaste, porque las calibraciones predeterminadas son por checkpoint; quien copia un wrapper de un hermano a otro aplica silenciosamente la temperatura incorrecta.

La propia transformación merece la pena entenderse antes de tratar ese 0.100 como un veredicto sobre los pesos. Es un softmax sobre los logits candidatos del campo, seguido de un segundo softmax sobre el logaritmo de esa distribución dividido por la temperatura. Como se ejecuta después del primer softmax y preserva el orden, no puede cambiar el argmax en absoluto. Mueve la confianza, la probabilidad de sí y el valor esperado de una pregunta de puntuación, y deja la etiqueta idéntica. Si tu pipeline lee etiquetas, la temperatura no tiene efecto y el ECE es una curiosidad. Si tu pipeline lee probabilidades —las umbraliza, las clasifica por ellas, las introduce en un cálculo de valor esperado—, entonces un ECE de 0.100 es la diferencia entre un umbral que significa lo que escribiste y uno que no. La respuesta correcta es ajustar tu propia temperatura con tus propios casos etiquetados, no concluir que los pesos son malos.

Microsoft-Decision-1 pide exactamente el mismo trabajo, con menos material de partida. Su pestaña Benchmarks señala que la exactitud, el error de calibración, el recall de seguridad, las tasas de falsos positivos y la consistencia de equidad se midieron en benchmarks de decisiones públicos y comunitarios, además de conjuntos de prueba internos reservados; que se varió el orden de las opciones; que se aplicaron pruebas estadísticas pareadas; y que el modelo «rinde a la par de los modelos de decisión líderes y por delante de otros modelos de decisión abiertos evaluados con la misma metodología». Sin ECE. Sin Brier. Sin temperatura. Sin tabla de exactitud. El modelo cuya propuesta de valor entera es una probabilidad fiable es el que aparece en esta comparación sin ninguna cifra de calibración publicada.

Límites del contrato: cuatro cosas que el modelo alojado no hará

Los dos modelos toman lo que parece ser la misma llamada, y las divergencias viven en los bordes de ella.

• Modalidad — Microsoft-Decision-1 es explícitamente solo texto y no acepta imágenes, audio ni video. Intern-Decision-2B acepta hasta ocho imágenes junto con el estado, lo que lo convierte en candidato para la clasificación de capturas de pantalla y verificaciones de diseño que la API alojada no puede ofrecer con precisión alguna.

• Límite de entrada y modo de fallo — Microsoft-Decision-1 ejecuta una sola invocación sobre hasta 32,768 tokens. Intern-Decision-2B declara DecisionEngine(max_length=8192) y rechaza la entrada de tamaño excesivo en lugar de truncarla, lo cual es el comportamiento correcto para un puntuador y también una barrera infranqueable, porque el estado, el esquema y el esqueleto deben estar todos presentes en una sola pasada; ninguna estrategia de fragmentación preserva el contrato.

• Forma de la pregunta — InternLM documenta de una a dieciséis preguntas por llamada, con hasta 62 opciones en cada una, repartidas en tres tipos de campo (choice, score, noul), donde noul es un sí/no binario que devuelve una probabilidad y score devuelve un valor esperado ponderado por probabilidad en una escala que tú nombres. Microsoft documenta los formatos — sí/no, opción múltiple, valoración, clasificación, rúbrica — además de una opción de abstención admitida explícitamente, como «no se puede determinar», cuando la evidencia es insuficiente, que es la línea más útil de la página para cualquiera que escriba lógica de escalado.

• Precio — la página del modelo Microsoft-Decision-1 no muestra una tarifa; los precios enlazan a la superficie de precios de Microsoft, así que el costo por decisión es algo que se lee de Azure o de una factura, y el 0 % de ello es atribuible a tokens de salida porque no hay ninguno. Intern-Decision-2B no cuesta nada por llamada y todo en tiempo de GPU, y no tiene proveedor alojado. Su almacenamiento es de aproximadamente 4,46 GB repartidos entre un fragmento de lenguaje de 3,76 GB, una torre de visión de 612,5 MB y un proyector de 50,3 MB.

¿Qué está confirmado y qué es solo lo que dice el proveedor?

Mantener separadas esas dos categorías es toda la disciplina con esta familia. Confirmado por un listado de archivos o una respuesta HTTP: el recuento de parámetros, el mapa de fragmentos, el par de licencias, el modelo base, la arquitectura subyacente —un Qwen3_5ForConditionalGeneration con 24 capas, un tamaño oculto de 2.048, 8 cabezas de consulta frente a 2 cabezas de clave-valor, una dimensión de cabeza de 256, un patrón repetitivo de tres capas de atención lineal por cada capa de atención completa, una capa retenida de predicción multitoken y un techo de embedding de 262.144 posiciones que el límite del motor de 8.192 tokens hace prácticamente irrelevante.

Reportado por el proveedor y no reproducido: cada cifra de precisión, cada dato de latencia y la temperatura. No hay artículo, ni entrada en arXiv, ni publicación de lanzamiento, ni registro de cambios, ni evaluación independiente. El Space de demostración responde 401, lo que significa que no es público, no que esté roto. El repositorio de GitHub que apareció después que el modelo —tres commits, código de entrenamiento, dos backends de inferencia, un paquete de evaluación con 10.751 filas de prueba, un benchmark de calibración de 96 casos y una guía de reproducción— es más documentación de la que reciben la mayoría de los lanzamientos discretos, y no incluye pesos, ni datos de entrenamiento, ni licencia de código. Microsoft está en una posición distinta pero adyacente: su metodología es real y su afirmación es cualitativa, y actualmente ninguna de las dos empresas está en posición de que su cifra central sea verificada por nadie más que tú.

Dónde encaja OrcaRouter en una canalización como esta

Ninguno de los dos modelos está en nuestro catálogo, y nada de lo que aquí se dice debe interpretarse como una afirmación de disponibilidad. Un modelo que devuelve probabilidades en lugar de texto no es algo a lo que se enruten las completaciones de chat, y eso es cierto en ambos casos. Lo que sí ofrecemos es la mitad generativa del bucle al que sirven esos evaluadores: los más de 200 modelos tras una única clave compatible con OpenAI que escriben la rúbrica, redactan las respuestas candidatas y emiten la llamada a herramienta que luego un evaluador califica antes de ejecutarla. El precio de lista del proveedor se traslada con 0 % de margen, por lo que una bajada de precio de un proveedor en el lado generativo se aplica al nuestro el mismo día, y si prefieres no apostar tu umbral a un solo juez, el DSL de enrutamiento compone varios modelos en una sola llamada y la fusión de modelos informa de su concordancia como un campo que puedes puntuar. La conmutación por error automática mantiene ese lado activo cuando un único proveedor se degrada, lo que importa más en un bucle que puntúa todo lo que ve que en uno que responde a un usuario de vez en cuando.

En resumen

Microsoft-Decision-1 está disponible de forma general en Microsoft Foundry desde el 8 de octubre de 2026: alojado, solo texto, 32.768 tokens, una base Qwen3.5-9B postentrenada por Microsoft, sin pesos distribuidos, y una sección de benchmark que documenta su metodología sin imprimir una cifra —sin incluir siquiera latencia—, con la inferencia por lotes desactivada. Intern-Decision-2B es un checkpoint Apache-2.0 de 2.213.241.664 parámetros del 26 de septiembre de 2026, que es el más rápido de sus tres hermanos con 33,28 ms en una 4090 y el peor calibrado con un ECE de 0,100, con una temperatura ajustada de 2,100509348278 que no puede cambiar una etiqueta, pero cambiará cada confianza sobre la que apliques un umbral. Si quieres el tamaño intermedio, el argumento honesto a su favor es escaso: paga los 2,7 GB adicionales por la precisión del 4B o acepta la huella del 0,8B, y en cualquiera de los dos casos ajusta tu propia calibración antes de que un umbral se acerque siquiera a producción.

Lo que sí ofrecemos es la mitad generativa del bucle al que esos evaluadores están destinados a servir: los más de 200 modelos detrás de una clave compatible con OpenAI que escriben la rúbrica, redactan las respuestas candidatas y emiten la llamada a herramienta que un evaluador luego califica antes de que se ejecute.