Decision 3.0 vs Intern-Decision-4B: Dos equipos le hicieron ajuste fino al mismo modelo y discreparon en todo lo demás

Coloca d3-mini, el miembro de 4B de Decision 3.0, junto a Intern-Decision-4B y lo primero que notas no es una diferencia. Ambos son ajustes finos del mismo checkpoint base, Qwen3.5-4B. Ambos figuran con 4,54 mil millones de parámetros. Ambos toman un estado, un esquema de preguntas con nombre y un conjunto de respuestas candidatas, y devuelven una probabilidad calibrada por candidato sin generar ningún token. Ambos son Apache-2.0. Ambos se publicaron sin anuncio — InternLM subió tres checkpoints en cuarenta segundos el 26 de septiembre de 2026, y la familia Decision 3.0 de vLLM-SR llegó a Hugging Face el 10 de octubre de 2026, con la noticia difundida únicamente por la cuenta de X del proyecto vLLM.

Todo lo que viene después de eso es una discrepancia. Discrepan sobre cómo leer una probabilidad del modelo, sobre si el video cuenta como entrada, sobre cuánto puede durar una solicitud y —de manera más marcada— sobre si el equipo está dispuesto a publicar el número que dice que su propia confianza es fiable. Este artículo trata de esas cuatro discrepancias y de lo que cada una te cuesta, no de cuál modelo es «mejor», porque los dos no se miden en la misma escala y no pueden clasificarse entre sí sin hacer un trabajo que ninguno de los proveedores ha hecho.

La coincidencia que vale la pena entender primero

Que dos laboratorios hayan elegido el mismo backbone de 4B en un plazo de dos semanas no es del todo sorprendente — Qwen3.5-4B es una base razonable para un modelo de salida estructurada, y ambos equipos claramente recurrieron a él porque es lo bastante pequeño para ejecutarse de forma barata y lo bastante potente para leer instrucciones. Lo sorprendente es que hayan llegado al mismo número de parámetros con cuatro cifras significativas. Eso indica que el ajuste fino preservó la arquitectura, y que ninguno añadió una torre de visión independiente lo bastante grande como para alterar el total. Ambos integran su capacidad multimodal en los mismos pesos.

La parte interesante es la lectura de resultados. Ambos modelos responden a las preguntas de la misma manera en principio —puntúan respuestas candidatas en lugar de generarlas— y de forma completamente distinta en cuanto a su mecanismo:

• Intern-Decision-4B — asigna cada opción a un único símbolo de token (A–Z, luego a–z, luego 0–9), renderiza un esqueleto JSON en el prompt con un marcador de posición por campo y ejecuta una única pasada forward causal, leyendo los logits en la posición inmediatamente anterior a cada marcador de posición. El mecanismo está documentado paso a paso en su tarjeta de modelo, incluido el paso exacto de softmax y temperatura.

• d3-mini — incluye una arquitectura personalizada en modeling_d3.py con una cabeza de lectura independiente en su propio readout.safetensors, un decision_config.json que declara noncausal_full_attention y pooling del último token, y una asignación de token a código definida en la configuración en lugar de descrita en prosa.

Ninguno de los dos enfoques es obviamente mejor. La ruta de InternLM tiene la ventaja de que se ejecuta sobre una clase de modelo estándar de Hugging Face con una secuencia numérica documentada — puedes comprobar su funcionamiento. La ruta de vLLM-SR tiene la ventaja de que la lectura es una cabeza entrenada en lugar de una proyección de un embedding de token existente, lo cual es un ajuste más libre, y el coste es que debes trust_remote_code=True y ejecutar su código para hacer cualquier cosa.

Los límites que cada uno publica

Aquí es donde empieza a formarse una preferencia real, porque una tarjeta es mucho más específica que la otra acerca de dónde deja de funcionar.

• Límite de entrada — Intern-Decision-4B: 8.192 tokens de forma predeterminada y las solicitudes que lo superan se rechazan de plano, nunca se truncan, y el límite lo establece un argumento del constructor. d3-mini: max_length es null en la configuración distribuida y no aparece ningún presupuesto de tokens en ninguna parte de la tarjeta.

• Preguntas por solicitud — Intern-Decision-4B: de 1 a 16, con un máximo declarado de 62 opciones en una sola pregunta. d3-mini: no se indica ningún límite; la ficha solo dice que las preguntas se responden juntas, cada una desde su propia pasada hacia adelante.

• Imágenes — Intern-Decision-4B: hasta ocho por solicitud, ordenadas por una lista que usted proporcione, con el procesador de checkpoint encargándose del redimensionamiento y la expansión de tokens. d3-mini: varias por solicitud como rutas, URLs, imágenes PIL o URLs de datos base64, cada una se lee a hasta 1,6 megapíxeles y cada pregunta ve todas las imágenes.

• Vídeo — Intern-Decision-4B: ninguno. d3-mini: varios vídeos, leídos a 2 fotogramas por segundo, con un límite de 32 fotogramas distribuidos a lo largo del clip y 0,2 megapíxeles por fotograma.

El techo de entrada es la línea que decidirá esto para la mayoría de la gente. Un presupuesto de 8192 tokens compartido entre el estado, las instrucciones de la pregunta y las descripciones de los candidatos es una restricción real para el trabajo de evaluación de documentos y de enrutamiento de contexto largo para el que se venden estos modelos, e InternLM merece reconocimiento por decirlo con claridad en lugar de dejar que se descubra por sí solo. Que vLLM-SR no lo declare es lo contrario: no un límite oculto, sino uno desconocido, y por mucho que se lea el repositorio, no se aclara.

La calibración es la verdadera división

Todo modelo de decisión hace la misma promesa: el número que devuelve es una probabilidad, y los umbrales establecidos con respecto a él significan algo. Casi ninguno lo demuestra. Aquí es donde más divergen las dos versiones, y la divergencia va en la dirección opuesta a la que uno supondría por las fechas de lanzamiento.

Intern-Decision-4B publica, en su propia tarjeta, una puntuación de Brier de 0.347 y un error de calibración esperado de 0.065 en su promedio de siete benchmarks, una temperatura ajustada de 1.99241824 derivada mediante minimización de NLL sobre 1,728 casos de calibración designados con 1,693 casos de validación separados, una declaración explícita de que las etiquetas del conjunto de pruebas no se utilizaron para seleccionar esa temperatura, y un diagnóstico de 96 casos que muestra su calibración moviéndose de 0.628 Brier / 0.213 ECE antes del escalado de temperatura a 0.550 / 0.089 después. También indica el valor predeterminado y dice que la calibración es por punto de control, por lo que usar otro tamaño con este módulo no coincidirá.

Decision 3.0 publica un índice de precisión y una afirmación de cobertura —las 140.178 solicitudes públicas respondidas, ninguna sin respaldo— y ninguna cifra de calibración en absoluto. Ni puntuación de Brier, ni ECE, ni temperatura declarada, en ninguno de los seis puntos de control. temperatura en el decision_config.json que distribuye d3 es 1.0, que es la identidad y puede o no ser el valor ajustado; el archivo no lo indica.

Lee los dos titulares de índice lado a lado y la asimetría se agrava. La tarjeta de d3-mini reporta una puntuación de 54.90 en la suite pública del Jev Decision Index 0.3, descrita como medida con el kit oficial sobre los pesos publicados, mientras que las filas de comparación en la misma ... se describen como datos en vivo. Intern-Decision-4B reporta un promedio de 90.02 en sus propios siete benchmarks. Esos dos números no están en la misma escala, no usan las mismas tareas, y ponerlos en una sola frase como comparación sería deshonesto. Lo que sí es comparable es la divulgación: una tarjeta te dice cuán equivocadas están sus confianzas, y la otra no lo sabe o no lo dirá.

Latencia, y por qué los dos conjuntos de milisegundos tampoco son comparables

Ambas tarjetas publican la latencia por solicitud, y tomarlas al pie de la letra sería un error por la misma razón por la que las cifras de precisión no son comparables.

• Intern-Decision-4B — media 44,16 ms, mediana 44,03 ms, p95 44,60 ms, medidos en una sola RTX 4090 a través de la ruta local de Hugging Face, descrito como dependiente de la carga de trabajo y del hardware.

• d3-mini — mediana de 17,5 ms para texto, 96,2 ms con una imagen, 371,5 ms con un vídeo de diez segundos, en un AMD Instinct MI325X, una solicitud a la vez.

Dos cosas hacen que estos sean incomparables. La primera es el hardware y la ruta de software: una 4090 frente a una MI325X, una pasada forward estándar de Hugging Face frente a una implementación de atención personalizada con ctypes disponible a través de flash-linear-attention. La segunda es la carga de trabajo: el número de InternLM se describe como de extremo a extremo por consulta en una mezcla no especificada, y el de vLLM-SR se desglosa por modalidad de entrada, por lo que la comparación solo de texto es la única línea comparable e incluso esa cruza dos proveedores de GPU.

La cifra que hay que tomar de ambas tarjetas no es la clasificación, es la forma. Un modelo de decisión se invoca repetidamente dentro de un flujo de trabajo — un registro de soporte podría necesitar un destino, una comprobación de reembolso, una decisión de escalado y una puntuación de prioridad, cuatro preguntas, y un lote de 128 registros convierte eso en 512 decisiones. A ese volumen, 17 ms y 44 ms desaparecen junto a lo que cueste el modelo generativo posterior. Las cifras dependientes de la modalidad son las que hay que vigilar, porque una solicitud de imagen o de vídeo cuesta entre cinco y veinte veces lo que una de texto según los propios números de d3-mini, y si tu decisión se toma a partir de una captura de pantalla, has importado un perfil de costes que la mayoría de las implementaciones de modelos de decisión no tienen.

¿Cuál elegir realmente?

Si la decisión que necesitas tomar depende de un vídeo, no hay comparación posible ni hace falta análisis: Decision 3.0 lee vídeo e Intern-Decision-4B no. Esa es toda la respuesta para cualquier cosa que implique grabaciones de pantalla, clips de cámara o secuencias de fotogramas, y es la brecha de capacidades que justifica por sí sola la existencia de la familia más reciente.

Si tus entradas son texto e imágenes ocasionales, la elección depende de dos cosas y ninguna de ellas es la tabla de clasificación.

Elige Intern-Decision-4B cuando necesites razonar sobre umbrales. Es el único de los dos que te dice si un 0,9 significa nueve de cada diez, indica su temperatura, dice en qué casos se ajustó esa temperatura, y documenta su inferencia como un procedimiento breve numerado que puedes reimplementar sobre una clase de modelo estándar. Para un scorer situado delante de una acción automatizada, esa es la propiedad que importa, y es más rara que los puntos de precisión.

Usa Decision 3.0 cuando necesites la gama o las modalidades. Seis checkpoints de 0,59B a 26,09B significan que el mismo formato de solicitud puede ser servido por un modelo edge de 6,7 ms y por uno de 27B, y la familia comparte una única interfaz, por lo que pasar de un nivel a otro es un cambio de configuración en lugar de una reescritura. El problema es que estás confiando en un presupuesto de entrada no declarado y en una afirmación de calibración no auditada, y el modelo más grande de la familia es aquel cuyo número de índice el proveedor midió en su propio entorno de pruebas.

Hoy, ninguno de los dos es una opción predeterminada segura. El checkpoint más descargado de d3 lleva alrededor de un día en Hugging Face; Intern-Decision-4B lleva dos semanas publicado y ha acumulado unas 3.200 descargas y 83 me gusta, lo cual es atención, pero no tráfico de producción. Ambos son lo bastante baratos como para probarlos y ninguno tiene una evaluación de terceros detrás. Si vas a poner un scorer delante de algo que gasta dinero, lo correcto es ejecutar ambos con tus propios casos etiquetados y comparar las curvas de calibración, no las filas del índice.

Dónde encaja un router, honestamente

OrcaRouter no ofrece ninguno de estos modelos. Los checkpoints de Decision 3.0 corresponden a una ruta de inferencia local en Python dentro de un repositorio de Hugging Face, sin ningún endpoint HTTP publicado, e Intern-Decision-4B se distribuye como una DecisionEngine clase que usted mismo instancia. Ninguno de los dos es algo que podamos enrutar hoy, y ninguna parte de este artículo debe interpretarse como una afirmación de disponibilidad.

Lo que sí ofrecemos es el extremo alojado de la misma familia. typesafe/jev-1.13 está en nuestro catálogo, servido mediante POST /v1/systemone — el mismo contrato de estado y preguntas con nombre que implementan ambos modelos abiertos de arriba — a $0.042 por millón de tokens de entrada, sin cargo por completación, ya que nunca genera ninguna. Se encuentra junto a más de 200 modelos, y ese es el punto práctico para cualquiera que compare estos dos: el evaluador es la parte barata del bucle y el modelo que actúa sobre la decisión es la parte cara. Enrutar ambos a través de una sola clave, con conmutación automática cuando un proveedor falla y el precio de lista del proveedor pasado con un 0 % de margen, significa que evaluar un modelo de decisión no requiere firmar un segundo contrato ni reescribir el punto de llamada cuando cambias de backend. Si estás en plena evaluación — que es donde están ambos modelos hoy — esa es la parte que vale la pena configurar antes de comprometerte con cualquiera de los dos.

La pregunta abierta

Las dos tarjetas discrepan sobre qué le debe un autor de modelos a un lector, y esa discrepancia es más interesante que los modelos. InternLM publicó una temperatura y los casos sobre los que se ajustó, y luego publicó el diagnóstico que muestra cuánto mejoró la calibración. vLLM-SR publicó hashes de archivos, revisiones base fijadas, un objetivo de hardware declarado, una afirmación de cobertura —verdadero trabajo de procedencia— y ningún número de calibración en absoluto.

La prueba de qué lanzamiento madura no es cuál gana una tabla de clasificación. Es si el próximo checkpoint de Decision se publica con una puntuación de Brier incluida, y si la próxima subida de InternLM llega a video. Ambas son visibles desde fuera, ambas son baratas de comprobar, y ninguna ha ocurrido todavía.