Granite Switch 4.1 de IBM mete chat, decisiones y speech en un solo modelo

IBM sacó esta semana Granite Switch 4.1 en tamaños 8B y 30B, y la apuesta es densidad: un solo endpoint hosted atiende chat en lenguaje natural, tareas de decisiones generales y especializadas, y transcripción speech-to-text, y el modelo compuesto ocupa más o menos el mismo VRAM en la GPU que el base solo. Es una actualización del proyecto Granite Switch, que IBM presentó la primavera pasada con una forma modular de desarrollar modelos alrededor de adapters intercambiables.

Un checkpoint, tres trabajos

Cada modelo 4.1 sale precargado con tres componentes. Un nuevo Decision aLoRA atiende el decision making general del tipo que el ecosistema de Typesafe llama /v1/systemone. Un Guardian aLoRA especializado apunta a tareas de decisión relacionadas con seguridad, donde según IBM supera en promedio a un grupo de decision models cerrados, entre ellos Jev 1.13, Microsoft-Decision-1, GPT-Luna-Decisions y Clef-Flash. Y Granite-Speech-5.0-Turbo-CTC, que según IBM es el modelo de ASR más rápido del OpenASR leaderboard, viene embebido para transcripción. Los tres, junto con el base, se componen en un solo modelo.

Por qué cambiar de trabajo sale barato

La ingeniería está en los adapters. Los adapters de Switch se arman como Activated LoRAs eficientes en caché, así que el KV cache que genera el base se puede reusar para cualquier decisión posterior basada en adapter. Sumá las contribuciones recientes del equipo de IBM a vLLM para acelerar el inferencing de low-rank adapters, más un encoder de ASR en el mismo lugar, y el modelo pasa de un request de chat a uno de decisiones y a uno de speech sin volver a correr el base para cada tarea. La demo pública de IBM corre el 8B transcribiendo audio, generando resúmenes, filtrando contenido dañino y probando 15 flags definidos por el usuario, todo en un solo endpoint y en tiempo real.

Especialistas contra generalistas

Granite Libraries, la salida anterior de IBM con adapters de tareas especializadas, es de donde sale el argumento de precisión. La evaluación propia de IBM compara adapters de granitelib con decision models generalistas en tareas de clasificación especializadas, y los especialistas ganan en las tareas para las que se armaron. Como los adapters comparten el KV cache del base, sumar especialistas al lado de un decision adapter generalista cuesta casi nada. IBM publicó una "carrera" entre Granite-Switch-4.1-30B (base congelado más cuatro aLoRAs especializados) y Jev-27B (base Qwen congelado más un decision LoRA genérico), y según el report el 30B completó un workflow RAG real de cinco pasos bastante más rápido. En un ejemplo juguetón, un Granite Switch 3B custom juega a Doom a 60-100 decisiones por segundo, contra las 10 por segundo que Typesafe reportó para Jev, y además narra su propia partida mientras juega. Esos comparativos salen del post de IBM; las corridas independientes serían el paso antes de tratarlos como un ranking cerrado.

Cómo corre

Los tamaños 8B y 30B están pensados para caber donde ya corre tu workload. Los modelos andan en vLLM con un plugin, tienen inferencing nativo en llama.cpp y en plataformas downstream, y pueden reemplazar las llamadas existentes a la API /v1/systemone mientras atienden chat común con un prefix cache compartido. Tampoco estás atado a la configuración de IBM: cualquiera puede componer su propio modelo Granite Switch mezclando adapters de Granite Libraries, y IBM planea un Adapter SDK para entrenar adapters nuevos en Mellea, su plataforma de training. Para un equipo cuyo pipeline ya mezcla chat, decisiones tipo clasificación y transcripción sobre el mismo tráfico, el claim que interesa es el de costo: más trabajos con el mismo VRAM. La verificación es tarea tuya: los números de precisión de decisiones son de IBM, así que conviene correr tus propios datos de clasificación antes de jubilar los clasificadores separados.