Granite Switch 4.1 8B: un único checkpoint de 8B que chatea, decide y transcribe

Entran ocho mil trescientos ochenta millones de parámetros. Salen ocho mil setecientos setenta y seis millones. Ese 4,72 % es toda la diferencia entre el modelo base de IBM y Granite Switch 4.1 8B, y es el número más interesante del lanzamiento, porque en esa pequeña franja están empaquetados un clasificador de seguridad, un motor de decisión y un reconocedor de voz — todos responden desde un único endpoint, todos leen y escriben la misma caché KV que el modelo base habría construido de todos modos.

Los pesos llegaron a Hugging Face el 14 de octubre de 2026. El propio blog de lanzamiento de IBM, Granite Switch 4.1: chat, decisiones y voz desde un único endpoint, se publicó el 15 de octubre, y vale la pena decirlo claramente desde el principio: esto no es un lanzamiento silencioso que alguien encontró en un sitio espejo. Es un lanzamiento anunciado que tiene aproximadamente dos días en el momento de escribir esto, y la versión de la historia que importa no es "qué afirmó IBM" sino "qué puedes verificar realmente desde el checkpoint que está en el Hub ahora mismo". Esas dos cosas no son lo mismo, y este artículo las mantiene separadas.

Lo que realmente contiene el checkpoint

Granite Switch no es una arquitectura nueva. Es una composición: un modelo base congelado, un conjunto de adaptadores de bajo rango que se pueden activar y desactivar por token y —en esta compilación en particular— un codificador añadido para audio. El compositor vive en el granite-switch repositorio y el manifiesto de compilación de este checkpoint está registrado junto a los pesos, lo que significa que cada afirmación estructural que aparece a continuación se puede leer directamente del Hub en lugar de tomarse de un comunicado de prensa.

La base es Granite 4.1 8B — decodificador denso de solo decodificación, atención de consulta agrupada con 32 cabezas de consulta frente a 8 cabezas de clave/valor, SwiGLU, RMSNorm, una ventana de 131.072 tokens y un vocabulario de 100.352 tokens. El checkpoint compuesto hereda todo eso y añade dos adaptadores LoRA activados:

• guardian-core — rango 16, alpha 64, adjunto únicamente a las proyecciones de atención (k_proj, o_proj, q_proj, v_proj), extraído de la versión de Guardian Library y descrito como detector de daño, jailbreak, lenguaje obsceno, violencia, contenido sexual, sesgo social y comportamiento poco ético.

• decisión — rango 64, alfa 128, conectado a las siete proyecciones, incluidas las del MLP (down_proj, gate_proj, up_proj), y entrenado para hacer algo más acotado y extraño: dado un estado y una pregunta con opciones etiquetadas, devolver una distribución de probabilidad calibrada sobre esas etiquetas de opción en una sola pasada hacia adelante.

Ambos se activan mediante tokens de control — <|guardian-core|> y <|decision|> — que la plantilla de chat inserta por ti cuando pasas un adapter_name argumento. No escribes los tokens tú mismo, y ese detalle importa más de lo que parece: significa que la selección del adaptador es un parámetro de la solicitud, no un segundo modelo que desplegar.

¿Por qué el delta del parámetro es tan pequeño?

La aritmética es la historia. El modelo base tiene 8.380.551.168 parámetros. El modelo compuesto tiene 8.776.400.896. Eso es +395,8 millones, o +4,72%, para dos adaptadores. La razón por la que el número se mantiene tan bajo es una decisión de diseño llamada normalización de KV-cache: cada adaptador ve la caché de clave/valor del modelo base en lugar de mantener la suya propia. En una configuración multi-adaptador convencional, cada adaptador adicional es un segundo conjunto de estado de atención, y la factura de memoria crece con el número de adaptadores entre los que se alterna. Aquí no lo hace. La afirmación de IBM en la publicación de lanzamiento es que el modelo compuesto consume "aproximadamente la misma cantidad de VRAM en una GPU que el modelo base por sí solo", y aunque nadie fuera de IBM ha medido eso todavía, el delta de pesos del 4,72% es consistente con ello — y a diferencia de la afirmación sobre la VRAM, el delta de pesos es solo un número en un manifiesto que puedes leer.

El adaptador de decisiones es la mitad interesante

Leer una distribución de probabilidad de un modelo de lenguaje no es nuevo; hacerlo en una sola pasada hacia adelante con un vocabulario fijo de etiquetas de opciones, y obtener números calibrados lo suficiente como para actuar en consecuencia, es la parte que vale la pena entender. La receta de invocación está documentada en la tarjeta: un prompt de sistema fijo para el motor de decisiones, un Estado: turno evaluado en la base congelada, luego un ### DECISIÓN turno que presenta la pregunta y opciones etiquetadas con un solo token. Luego le pides al servidor los logprobs de exactamente esos ids de token de etiqueta — vLLM expone esto a través de logprob_token_ids — y aplicas la exponencial. El ejemplo documentado devuelve algo como A: 0.982, B: 0.0035, C: 0.014.

Hay un detalle de ingeniería real aquí que la versión de marketing de este lanzamiento omite. vLLM limita logprob_token_ids a 128 ids por solicitud. Si tu pregunta de decisión tiene más de 128 opciones, obtienes un HTTP 400, y la solución es dividir los ids de etiquetas en fragmentos de 128, emitir una solicitud por fragmento con un prompt idéntico y concatenar — porque los logprobs devueltos abarcan todo el vocabulario, el valor de cada etiqueta es independiente de qué fragmento lo haya solicitado, así que un único softmax sobre el conjunto completo de etiquetas es matemáticamente idéntico a una llamada sin límite. Eso es una solicitud extra por cada 128 opciones. Es un detalle genuinamente útil, y es exactamente el tipo de cosa que solo existe en el repositorio.

El único número publicado que acompaña a este adaptador es el Índice de Decisión (JEV), edición v0.3, subconjunto rápido público de 1.068 filas: General 42,9, Conocimiento 29,1, Lenguaje 48,9, Recuperación 49,8, Herramientas 59,8, Artes 18,0. Tómelo como reportado por el proveedor, porque lo es: IBM lo ejecutó, lo publicó y ningún tercero lo ha reproducido. También vale la pena leer la forma y no el titular: 59,8 en Herramientas junto a 18,0 en Artes es un perfil muy desigual, y la propia ficha advierte de que las probabilidades de las opciones son "un prior para informar una decisión, no una clasificación certificada" en dominios para los que no se entrenó el adaptador.

La conversión de voz a texto es real, y más limitada de lo que sugiere el titular.

La ruta de audio integra Granite Speech 5.0 TurboCTC, un codificador CTC conformer no autorregresivo de 470 millones de parámetros, y transcribe el audio entrante antes de empalmar la transcripción en el contexto del chat en lugar de la parte de contenido de audio. Invocarlo no cambia la forma de la solicitud: es una input_audio parte de contenido en una finalización de chat normal, y la transcripción se ejecuta en el mismo endpoint que el chat y las decisiones, así que no hay un segundo servidor de voz que levantar.

Las advertencias, todas ellas de la propia ficha de IBM y no de un crítico: el codificador es solo para inglés, su salida está en minúsculas y sin puntuación, no hay guiado en tiempo de decodificación, y —la que debería detenerte— el codificador de voz y el LLM no están entrenados conjuntamente. No hay una proyección entrenada que los acople. Por lo tanto, una transcripción errónea puede cambiar silenciosamente aquello a lo que responde el modelo, o un adaptador. Si estás construyendo cualquier cosa en la que un error de transcripción tenga consecuencias, esa frase es toda la revisión de seguridad.

Qué está confirmado, qué está reportado por el proveedor, qué nadie ha verificado

• Confirmado desde el repositorio — la identidad del modelo base y el número de capas, los dos rangos de adaptadores y sus módulos de destino, los ids de los tokens de control, el recuento de parámetros compuesto, la ventana de 131.072 tokens, la licencia Apache-2.0 y las versiones documentadas de vLLM y Transformers que solicita la tarjeta.

• Reportado por el proveedor, no reproducido — las puntuaciones del Decision Index, la afirmación de que Granite Speech 5.0 TurboCTC es el modelo ASR más rápido en la tabla de clasificación de OpenASR, la afirmación de “la misma VRAM que el modelo base”, y la nota al margen del anuncio de lanzamiento de que un modelo Granite Switch 3B personalizado juega a Doom a 60–100 decisiones por segundo frente a las 10 por segundo reportadas de un modelo de decisión cerrado. IBM dice que publicará más datos “en las próximas semanas”, lo cual es una admisión de que la evidencia actual es escasa.

• Nadie lo ha comprobado — todo lo demás. No hay ninguna evaluación independiente, ninguna entrada en una clasificación de terceros, ninguna API alojada de IBM, ni ninguna medición publicada de latencia o rendimiento de alguien que no sea IBM. El repositorio del Hub muestra unas pocas docenas de descargas y un puñado de "me gusta": este modelo tiene dos días de antigüedad y en gran medida no ha sido leído.

Lo que cuesta ejecutarlo y dónde encaja OrcaRouter

Granite Switch 4.1 8B es, por ahora, una historia de autoalojamiento. La ficha indica HuggingFace Transformers y vLLM como backends, fija una ventana de soporte bastante estrecha (Transformers 5.16–5.17, vLLM 0.26–0.28), y el checkpoint funciona con ambos sin cambios en el código. No hay ningún endpoint gestionado al que apuntar, lo que para la mayoría de los equipos significa una GPU y un contenedor antes de la primera solicitud.

Siendo francos con respecto al resto: Granite Switch no está hoy en el catálogo de OrcaRouter, y ningún otro modelo Granite tampoco — así que si quieres este checkpoint, la vía es el lanzamiento del propio proveedor y tu propio hardware, no nosotros. Lo que OrcaRouter sí te ofrece es la decisión que lo rodea. La plataforma enruta más de 200 modelos tras una única clave con conmutación por error automática, y traslada el precio de lista del proveedor con un 0% de margen, así que cuando un modelo que estés evaluando llegue a tener un endpoint alojado, compararlo con el incumbent sobre tu propio tráfico es un cambio de configuración y no un segundo contrato. Eso importa sobre todo en exactamente esta situación: un checkpoint de dos días de antigüedad y sin evaluación independiente es un candidato, no un incumbent, y lo barato que se puede hacer con un candidato es mantenerlo en una comparación lado a lado en lugar de recablear una ruta de producción en torno a él.

La pregunta abierta

Granite Switch 4.1 8B es una apuesta a que la composición supera a la escala para un tipo específico de trabajo: aplicaciones que necesitan responder, decidir y transcribir, donde ejecutar tres modelos significa tres implementaciones, tres latencias y tres facturas. La ingeniería necesaria para abaratar esa apuesta —caché KV compartida, conmutación de adaptadores por token, tokens de control resueltos en la plantilla de chat— es realmente inusual, y es la parte de este lanzamiento que seguirá importando dentro de un año.

Lo que aún no está resuelto es si la respuesta compuesta es buena. El perfil publicado del adaptador de decisión es desigual, la ruta de voz es solo en inglés y no está entrenada conjuntamente, y todo el asunto tiene apenas dos días y no cuenta con ninguna ejecución independiente que lo respalde. Lee el manifiesto de compilación, ejecuta tú mismo el comando compose y mide el rendimiento del adaptador de decisión con tu propio conjunto de etiquetas antes de creerte el 42.9 de nadie.