Granite Switch 4.1 da IBM junta chat, decisões e fala em um único endpoint

O que muda com o Granite Switch 4.1

A IBM publicou, em 15 de outubro de 2026, o Granite Switch 4.1 no blog da Hugging Face, assinado por Kate Soule, Subhajit Chaudhury, Hendrik Strobelt e Luis A. Lastras, da equipe Granite. O pacote reúne dois tamanhos, Granite-Switch-4.1-8B e Granite-Switch-4.1-30B, que fazem três coisas ao mesmo tempo: responder em linguagem natural, tomar decisões (classificação, moderação, roteamento) e transcrever áudio. Tudo isso a partir do mesmo endpoint, sem trocar de modelo nem de infraestrutura.

Isso resolve um problema real de quem constrói produtos com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →: hoje é comum ter um modelo de chat, uma API de moderação/classificação (muitas vezes fechada, como a família Jev citada no próprio post da IBM) e um serviço de transcrição separados, cada um com seu próprio custo de GPU e sua própria latência de rede. O Granite Switch tenta substituir essa pilha por um único processo.

aLoRAs: o truque por trás do endpoint único

A peça central da arquitetura são as Activated LoRAs (aLoRAs), adaptadores leves acoplados ao modelo base do Granite. Batizados pela IBM de "cache-efficient" por serem Activated LoRAs, esses adaptadores permitem que o KV cache gerado pela geração do modelo base seja reaproveitado em qualquer decisão subsequente feita por um adaptador.

Na prática, isso significa que rodar o modelo de chat, aplicar o adaptador de decisão e aplicar o adaptador de segurança consome, juntos, cerca da mesma VRAM que rodar o modelo base sozinho consumiria. A IBM lista contribuições recentes da equipe ao vLLM para acelerar a inferência desses adaptadores de baixo posto (low-rank), somadas a um encoder de fala co-localizado no mesmo processo.

Os modelos Granite Switch 4.1 conseguem alternar entre uma requisição de chat, uma de decisão e uma de fala, com velocidade impressionante.

Granite Switch 4.1 models can switch between a chat request and a decision request and a spoken request, with blazing fast speeds.Kate Soule e equipe IBM Granite, no blog do Hugging Face

O que vem dentro do pacote 4.1

Os dois tamanhos do Granite Switch 4.1 chegam com três peças pré-instaladas:

• Decision aLoRA, um adaptador genérico de decisão, pensado para substituir chamadas do tipo /v1/systemone (o padrão de API usado por modelos de decisão "rápida", como o Jev);
• Guardian aLoRA, especializado em decisões de segurança, que a IBM diz superar, em média, os concorrentes Jev 1.13, Microsoft-Decision-1, GPT-Luna-Decisions e Clef-Flash em tarefas de segurança;
• Granite-Speech-5.0-Turbo-CTC, o modelo de reconhecimento de fala que lidera o OpenASR Leaderboard em velocidade, embutido para tarefas de transcrição.

Esses três componentes, mais o modelo base, formam um único modelo combinado - não três processos separados.

Um endpoint, três tarefas: a demo que prova o conceito

A IBM publicou um espaço no Hugging Face chamado Speech-to-Decisions, em que o granite-switch-4.1-8b recebe áudio, gera um resumo, verifica se o conteúdo é prejudicial e testa outras 15 flags definidas pelo usuário, tudo em tempo real, no mesmo endpoint. É o caso de uso mais concreto do anúncio: moderação de chamadas de suporte, transcrição de reuniões com triagem automática de risco, ou pipelines de atendimento que hoje precisam encadear três serviços diferentes.

Para quem constrói pipeline de RAG ou agentes que precisam decidir "o que fazer a seguir" sem esperar uma chamada de API externa, isso é relevante: a decisão sai do mesmo processo que já gerou a resposta, sem round-trip de rede extra.

Granite Libraries: montando seu próprio Switch

O Granite Switch não nasceu com o 4.1. O projeto foi apresentado pela IBM na primavera boreal de 2026, junto com os Granite Libraries, um repositório de adaptadores especializados ("decision model" e outras tarefas) que podem ser compostos em modelos Granite Switch sob medida. A ideia é que ninguém precisa usar a versão "com baterias inclusas" da IBM: dá para montar a própria combinação de adaptadores a partir dessa biblioteca.

O ponto interessante, segundo o post, é que adaptadores especializados do granitelib tendem a superar modelos de decisão generalistas (como o Jev) em tarefas de classificação específicas. Como os adaptadores compartilham o KV cache do modelo base, empilhar um especialista ao lado de um generalista custa quase nada em termos de recursos: dá cobertura ampla com o adaptador genérico e precisão alta nos pontos que importam com o especialista.

A IBM também anunciou planos de lançar um SDK de adaptadores para treinar esses módulos usando o framework Mellea, junto com tutoriais e suporte ampliado ao Granite Switch, mas sem data definida além de "nas próximas semanas".

Contra o Jev: benchmark de velocidade

O post traz duas comparações diretas com o Jev, citado como referência de modelo de decisão fechado. Na primeira, o Granite-Switch-4.1-30B (modelo Granite base congelado mais 4 aLoRAs especializados) completou um workflow real de RAG em 5 etapas mais rápido que o Jev-27B (modelo Qwen base congelado mais 1 LoRA de decisão genérico), sem um número de latência divulgado no post.

Na segunda, mais lúdica, a IBM treinou uma versão de 3 bilhões de parâmetros do Granite Switch para jogar Doom, tomando decisões a 60-100 por segundo, contra as 10 decisões por segundo reportadas pelo Jev em um teste equivalente, segundo o blog da typesafe.ai citado como nota de rodapé pela própria IBM. A diferença, segundo o post, é que o mesmo modelo consegue narrar a partida e responder perguntas enquanto joga, porque chat e decisão rodam na mesma sessão.

Como rodar isso na prática

Os dois tamanhos do Granite Switch 4.1 rodam em vLLM via um plug-in específico, disponível no repositório do projeto no GitHub, e têm suporte nativo de inferência em llama.cpp e em outras plataformas downstream. Isso permite que o modelo substitua chamadas feitas para /v1/systemone em qualquer lugar onde esse padrão já é usado, ao mesmo tempo em que atende chamadas de chat convencionais, tudo com o mesmo prefix cache compartilhado.

Para quem já tem uma stack rodando modelos de decisão fechados e quer avaliar a troca, os recursos publicados pela IBM incluem os model cards do Granite Switch 4.1, o espaço de demonstração Speech-to-Decisions, o repositório no GitHub, o post original do Granite Switch e dos Granite Libraries, e um notebook no Colab para montar a própria "corrida" entre aLoRA e LoRA tradicional.

Onde isso ainda não resolve

Nem tudo no anúncio vem com números fechados. A comparação do workflow de RAG não traz latência em milissegundos, só "mais rápido"; os benchmarks contra Microsoft-Decision-1, GPT-Luna-Decisions e Clef-Flash são médias sem desagregação por tarefa, o que dificulta saber se o Guardian aLoRA ganha em todos os cenários ou só nos mais fáceis. O SDK de adaptadores, que é o que destravaria compor módulos de terceiros de verdade, ainda não tem data de lançamento.

Para times pequenos, a vantagem de VRAM só se traduz em economia real se o workload já combinar chat, decisão e fala. Rodar um Granite Switch só para decisões simples, sem usar a parte de chat ou de fala, provavelmente não compensa a complexidade extra de aprender o formato de adaptadores aLoRA e a configuração do plug-in do vLLM.

Fonte: Hugging Face Blog