Intern-Decision-2B se lanzó discretamente en Hugging Face. El enlace de GitHub en su tarjeta acaba de dejar de dar error 404

Hoy más temprano, la ficha del modelo de internlm/Intern-Decision-2B apuntaba a tres lugares para obtener más información, y dos de ellos estaban caídos: el Space de demostración respondía HTTP 401, y github.com/internlm/Intern-Decision devolvía 404 a cualquiera que hiciera clic en él. A las 08:58 UTC, el repositorio detrás de ese segundo enlace ya existe: es público, tiene tres commits y contiene 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 la guía de reproducción. Eso es lo único que ha cambiado en este modelo desde que apareció en Hugging Face a las 05:36 UTC del 26 de septiembre de 2026, y basta para que Intern-Decision-2B pase de «un checkpoint con un README inaccesible» a «un checkpoint que de verdad puedes inspeccionar, con el que puedes reproducir y discutir».

Los pesos en sí no han cambiado y no son ambiguos. Intern-Decision-2B es un modelo de decisión estructurado multimodal de 2.213.241.664 parámetros ajustado a partir de Qwen/Qwen3.5-2B —la base de Alibaba del 28 de febrero de 2026—, publicado bajo Apache-2.0 con la licencia Qwen original conservada junto a él como LICENSE-QWEN. Es el intermedio de los tres tamaños que InternLM publicó en cuarenta segundos: Intern-Decision-0.8B a las 05:35:57, este a las 05:36:19 e Intern-Decision-4B a las 05:36:37. Todavía no hay ningún tipo de anuncio detrás de ninguno de ellos.

Lo que hace que el tamaño intermedio merezca su propio artículo es que es donde la familia deja de comportarse de forma predecible. Según los propios números de InternLM, es el más rápido de los tres y el peor calibrado de los tres, y vale la pena entender ambos hechos antes de descargar cuatro gigabytes y medio de cualquier cosa.

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

Dos categorías, y hay que mantenerlas separadas.

Confirmado, porque se trata de un listado de archivos o de una respuesta HTTP: el recuento de parámetros (2.592 F32 más 2.213.239.072 pesos BF16); el mapa de fragmentos (un fragmento de lenguaje de 3,76 GB, una torre de visión de 612,5 MB, un proyector de 50,3 MB, unos 4,43 GB de tensores y aproximadamente 4,46 GB de repositorio); el par de licencias; el modelo base; la arquitectura subyacente (un Qwen3_5ForConditionalGeneration con 24 capas, tamaño oculto de 2.048, 8 cabezas de consulta frente a 2 cabezas de clave-valor, dimensión de cabeza de 256, un patrón repetitivo de capas de atención lineal por cada capa de atención completa, una capa retenida de predicción multi-token y un límite de embedding de 262.144 posiciones); la existencia del repositorio; y el hecho de que la colección de modelos en huggingface.co/collections/internlm/intern-decision ahora resuelve y enumera los tres checkpoints.

Reportado por el proveedor y no reproducido: cada cifra de precisión, cada dato de latencia y la temperatura de calibración. No hay artículo, ni entrada en arXiv, ni publicación de lanzamiento, ni registro de cambios, ni evaluación independiente; una búsqueda de la cadena "Intern-Decision" no devuelve nada que trate sobre este modelo. El Space de demostración sigue respondiendo 401, lo que significa que no es público, no que esté roto. El checkpoint de 2B tiene un like y cero descargas. Nadie fuera de InternLM lo ha ejecutado.

El contrato de inferencia, en el orden en que ocurre

El archivo más informativo del repositorio no es la tarjeta. Es src/inference/engine.py y el inference.py que se incluye en el Hub, porque entre ambos documentan un contrato en lugar de un prompt.

• Tú proporcionas el estado — el material que se evalúa — el esquema de preguntas, y opcionalmente hasta ocho imágenes. De una a dieciséis preguntas, hasta 62 opciones cada una.

• Las opciones de cada pregunta se asignan a símbolos de un solo token: A–Z, luego a–z, luego 0–9. El límite de 62 opciones no es una preferencia de diseño; es exactamente la cantidad de símbolos de un solo token que el contrato puede direccionar.

• El prompt del sistema, el estado, el esquema y un esqueleto JSON completo del asistente se representan con un <decision> marcador de posición por campo. La plantilla de chat del checkpoint y el bloque de pensamiento vacío se conservan tal cual.

• Se ejecuta una única pasada forward causal. Los logits se leen en la posición inmediatamente anterior a cada marcador de posición — no después, ni en un token generado.

• Se toma un softmax únicamente sobre los símbolos candidatos válidos de ese campo, se aplica la calibración del checkpoint y los símbolos se asignan de nuevo a tus valores de opción originales.

La ficha del modelo es franca sobre lo que esto es: "Esta API realiza una puntuación estructurada de candidatos. No llama a generate() ni muestrea texto de forma libre." Un DecisionEngine(max_length=8192) rechaza la entrada de tamaño excesivo en lugar de truncarla, de modo que una solicitud que no encaja falla de forma ruidosa en vez de perder en silencio su último párrafo. La lista de backends también es honesta: backend="hf" es el predeterminado y el único implementado en el repositorio de Hugging Face, lo cual conviene saber porque la versión de GitHub incluye además un backend de XTuner y ambos no son numéricamente idénticos. La propia guía de evaluación de InternLM lo dice: "Las diferencias de kernel y de BF16 pueden cambiar las probabilidades y, ocasionalmente, las etiquetas."

La anomalía en el medio

Pongan los tres checkpoints uno al lado del otro en la propia tabla de InternLM y la forma es lo suficientemente extraña como para ser la historia.

• Promedio de las siete suites — Intern-Decision-0.8B 79.38, Intern-Decision-2B 84.68, Intern-Decision-4B 90.02. Ordenados, como cabría esperar al aumentar los pesos.

• Latencia en una RTX 4090: 33.98 ms de media para el 0.8B, 33.28 ms para el 2B, 44.16 ms para el 4B. El tamaño intermedio es el más rápido de los tres, por un margen lo suficientemente pequeño como para ser ruido en una sola GPU, pero consistente en la media, la mediana (33.15 ms) y el P95 (33.55 ms).

• Puntuación de Brier, menor es mejor — 0,530, 0,437, 0,347. Monótona con el tamaño, como suele serlo una regla de puntuación propia.

• Error de calibración esperado, cuanto menor, mejor — 0.066 para el de 0.8B, 0.100 para este de 2B, 0.065 para el de 4B. El tamaño intermedio es el peor, y es peor que el modelo de la mitad de su tamaño.

Esa última línea es la interesante, y las temperaturas ajustadas la corroboran en lugar de explicarla. Cada checkpoint lleva su propia temperatura ajustada por NLL: 2,747760550703 para el 0.8B, 2,100509348278 para el 2B, 1,992418 para el 4B. Cada una se ajustó sobre 1.728 casos de calibración designados, con 1.693 reservados, minimizando la log-verosimilitud negativa mediante una búsqueda de temperatura inversa en [0,01, 100], y con las etiquetas del conjunto de pruebas deliberadamente excluidas del ajuste. La temperatura del 2B se sitúa entre las de sus dos hermanos, que es lo que cabría esperar si la anomalía fuera un artefacto del ajuste. No lo es: el valor ajustado es monótono con el tamaño, mientras que el error posterior a la calibración no. Según la propia medición de InternLM, el checkpoint de 2,2 mil millones de parámetros es el menos fiable de los tres cuando te dice cuánta confianza tiene.

Dos advertencias antes de que eso se convierta en una conclusión. El ECE con diez intervalos de igual ancho y confianza de máxima probabilidad es una estadística ruidosa en el pequeño conjunto que usa esta tabla —Jevbench-Hard, 111 ítems—, así que toda la columna de ECE se apoya en un centenar y pico de preguntas y en una elección de intervalos. Y internlm/Intern-Decision-2B es la única de las tres tarjetas que no lleva la sección de calibración adicional que tiene la tarjeta de 4B, así que aquí hay menos documentación, no más. Lee el 0.100 como una razón para ajustar tu propia temperatura en lugar de como un veredicto sobre los pesos.

Lo que el repositorio aporta y lo que aún retiene

La versión publicada en GitHub es más completa que la ficha del modelo, que de por sí ya es informativa — un laboratorio que pretendiera un artefacto para un artículo no suele distribuir un generador de calibración determinista y un paquete de evaluación con verificación por hash junto con el lanzador de entrenamiento.

Lo que ahora es público: el código de entrenamiento y el objetivo de masked-next-token (los símbolos de respuesta de referencia aparecen solo en las etiquetas, nunca en la entrada; la respuesta de cada campo se predice por el logit inmediatamente anterior a su marcador, y todos los campos comparten una única pasada hacia adelante); las siete suites de precisión con hashes verificados por SHA-256 y recuentos de filas; el código de puntuación; los scripts de ajuste de temperatura y de replay, donde se afirma que el replay cambia cero decisiones; el banco de pruebas de calibración de distribución de 96 casos con su generador y evaluador offline; y una demo de navegador servida en loopback con POST /v1/decisions (con alias /v1/jev).

¿Qué se excluye explícitamente, en palabras del propio repositorio: «Los datos de entrenamiento, los registros privados de calibración/validación, las imágenes, los pipelines de preparación y los pesos del modelo no están incluidos»? El repositorio no incluye ningún archivo de licencia en absoluto, por lo que no se declaran los términos del código, aunque los pesos son Apache-2.0. Y la composición de la división de calibración —qué 1.728 casos, de dónde— sigue sin revelarse, que es la única omisión que limita hasta qué punto se pueden verificar las cifras de ECE.

Los tamaños que realmente enrutamos, y el que no

Intern-Decision-2B no está en OrcaRouter. Nuestra página de modelo para él devuelve un 404, no hay ningún endpoint alojado para él en ninguna parte que hayamos podido encontrar, y nada de lo que aparece aquí debe interpretarse como una afirmación de disponibilidad. La única forma de invocarlo hoy es descargar el checkpoint y ejecutar inference.py junto a los pesos.

Eso importa para la decisión de la que realmente trata este artículo, porque un scorer que nadie sirve es un scorer que tienes que operar. Si la decisión de conjunto cerrado que intentas tomar se parece en su forma a lo que hace esta familia —un estado, preguntas tipadas, probabilidades calibradas—, la comparación alojada es Jev 1.13 de TypeSafe, que es el modelo contra el que InternLM hizo el benchmark a propósito y que está en OrcaRouter a $0,042 por millón de tokens de entrada con un contexto de 65K y un tiempo hasta el primer token P50 de 178 ms.

Ejecutar en local un checkpoint de 2200 millones de parámetros y llamar a un clasificador alojado no son la misma compra, pero sí son el mismo problema, y tener ambos en una sola clave con el precio de lista del proveedor repercutido con un 0 % de margen es la razón para mantener la comparación abierta en lugar de apostar la arquitectura a uno de los dos.

¿Qué cambiaría esta imagen?

Tres cosas, en orden.

Alguien ajeno a InternLM necesita reproducir el promedio de 84,68 y el ECE de 0,100, y el repositorio es ahora lo que hace posible eso, que es la verdadera noticia aquí. El examen es público y está verificado por hash; solo falta la hoja de respuestas, y la hoja de respuestas es el checkpoint que cualquiera puede descargar ahora.

El proveedor tiene que decir para qué es esto. Un modelo con un stack de entrenamiento funcional, un paquete de evaluación publicado y ningún anuncio, ninguna licencia en su código y ningún endpoint alojado se interpreta como una publicación de investigación que aún no se ha decidido a convertirse en producto. Los pesos Apache-2.0 apuntan en una dirección; la licencia de código ausente y el 401 Space apuntan en la otra.

Y el tamaño intermedio necesita una razón para existir. Si la ventaja de velocidad del 2B sobre el 0.8B es real pero marginal, y su calibración es la más débil de los tres en todas las medidas que InternLM publicó, entonces la recomendación honesta para la mayoría de los lectores es pagar el 2,6× en espacio en disco por el 4B o aceptar la precisión más débil del modelo más pequeño. El argumento a favor del 2B es que resulta ser el más rápido de los rápidos, y ese es un argumento más endeble de lo que sugiere el encuadre de la familia, moldeado por el marketing.