Granite Switch 4.1 8B: Um único checkpoint de 8B que conversa, decide e transcreve

Oito bilhões, trezentos e oitenta milhões de parâmetros entram. Oito bilhões, setecentos e setenta e seis milhões saem. Esses 4,72% são toda a diferença entre o modelo base da IBM e o Granite Switch 4.1 8B, e é o número mais interessante do lançamento, porque comprimidos nessa fresta estão um classificador de segurança, um mecanismo de decisão e um reconhecedor de fala — todos respondendo a partir de um único endpoint, todos lendo e escrevendo o mesmo cache KV que o modelo base teria construído de qualquer forma.

Os pesos chegaram ao Hugging Face em 14 de outubro de 2026. O próprio blog de lançamento da IBM, Granite Switch 4.1: Chat, Decisões e Fala a partir de um Único Endpoint, foi publicado em 15 de outubro, o que vale dizer claramente desde o início: este não é um lançamento discreto que alguém encontrou em um espelho. É um lançamento anunciado que tem aproximadamente dois dias no momento em que escrevo, e a versão da história que importa não é "o que a IBM alegou", mas "o que você consegue de fato verificar a partir do checkpoint que está no Hub agora mesmo". Essas duas coisas não são a mesma coisa, e este artigo as mantém separadas.

O que o checkpoint realmente contém

O Granite Switch não é uma nova arquitetura. É uma composição: um modelo base congelado, um conjunto de adaptadores de baixo posto que podem ser ativados e desativados por token e — nesta compilação em particular — um codificador acoplado para áudio. O compositor vive no granite-switch repositório e o manifesto de compilação deste checkpoint está registado junto aos pesos, o que significa que todas as afirmações estruturais abaixo podem ser lidas diretamente no Hub, em vez de retiradas de um comunicado de imprensa.

A base é o Granite 4.1 8B — decoder-only denso, atenção de consulta agrupada com 32 cabeças de consulta contra 8 cabeças de chave/valor, SwiGLU, RMSNorm, uma janela de 131.072 tokens e um vocabulário de 100.352 tokens. O checkpoint composto herda tudo isso e adiciona dois adaptadores LoRA ativados:

• guardian-core — rank 16, alpha 64, anexado apenas às projeções de atenção (k_proj, o_proj, q_proj, v_proj), extraído da versão da Guardian Library e descrito como capaz de detectar danos, jailbreaking, profanidade, violência, conteúdo sexual, viés social e comportamento antiético.

• decisão — rank 64, alpha 128, anexado a todas as sete projeções, incluindo o MLP (down_proj, gate_proj, up_proj), e treinado para fazer algo mais restrito e mais estranho: dado um estado e uma pergunta com opções rotuladas, retornar uma distribuição de probabilidade calibrada sobre esses rótulos de opção em uma única passagem direta.

Ambos são ativados por tokens de controle — <|guardian-core|> e <|decision|> — que o template de chat insere para você quando você passa um argumento adapter_name. Você não escreve os tokens você mesmo, e esse detalhe importa mais do que parece: significa que a seleção de adaptador é um parâmetro de requisição, não um segundo modelo a implantar.

Por que o delta do parâmetro é tão pequeno

A aritmética é a história. O modelo base tem 8.380.551.168 parâmetros. O modelo composto tem 8.776.400.896. Isso é +395,8 milhões, ou +4,72%, para dois adaptadores. A razão pela qual o número permanece tão baixo é uma decisão de design chamada normalização do KV-cache: cada adaptador vê o cache de chave/valor do modelo base em vez de manter o seu próprio. Em uma configuração convencional com múltiplos adaptadores, cada adaptador adicional é um segundo conjunto de estado de atenção, e a conta de memória cresce com o número de adaptadores entre os quais você alterna. Aqui, isso não acontece. A afirmação da IBM no post de lançamento é que o modelo composto ocupa "aproximadamente a mesma quantidade de VRAM em uma GPU que o modelo base ocuparia sozinho", e, embora ninguém fora da IBM tenha medido isso ainda, o delta de peso de 4,72% é consistente com isso — e, ao contrário da afirmação sobre a VRAM, o delta de peso é apenas um número em um manifesto que você pode ler.

O adaptador de decisão é a metade interessante

Extrair uma distribuição de probabilidade de um modelo de linguagem não é novidade; fazê-lo em um único forward pass, com um vocabulário fixo de rótulos de opção, e obter números calibrados o suficiente para agir sobre eles é a parte que vale a pena entender. A receita de invocação está documentada no card: um system prompt fixo do mecanismo de decisão, State: um turno avaliado sobre a base congelada e, em seguida, um ### DECISION turno apresentando a pergunta e as opções rotuladas com um único token. Você então pede ao servidor os logprobs exatamente daqueles ids de token de rótulo — o vLLM expõe isso por meio de logprob_token_ids — e aplica a exponencial. O exemplo documentado retorna algo como A: 0.982, B: 0.0035, C: 0.014.

Há uma complicação real de engenharia aqui que a versão de marketing deste lançamento omite. O vLLM limita logprob_token_ids a 128 IDs por requisição. Se a sua pergunta de decisão tiver mais de 128 opções, você recebe um HTTP 400, e a correção é dividir os IDs dos rótulos em blocos de 128, enviar uma requisição por bloco com um prompt idêntico e concatenar — porque os logprobs retornados abrangem o vocabulário completo, o valor de cada rótulo é independente de qual bloco o solicitou, então um único softmax sobre o conjunto completo de rótulos é matematicamente idêntico a uma chamada sem limite. Isso é uma requisição extra a cada 128 opções. É um detalhe genuinamente útil, e é exatamente o tipo de coisa que só existe no repositório.

O único número publicado associado a este adaptador é o Decision Index (JEV), edição v0.3, subconjunto público rápido de 1.068 linhas: Geral 42,9, Conhecimento 29,1, Linguagem 48,9, Recuperação 49,8, Ferramentas 59,8, Artes 18,0. Trate isso como informado pelo fornecedor, porque é: a IBM o executou, o publicou, e nenhum terceiro o reproduziu. Também vale a pena ler a forma em vez da manchete — 59,8 em Ferramentas ao lado de 18,0 em Artes é um perfil muito desigual, e o próprio cartão adverte que as probabilidades das opções são "uma priori para informar uma decisão, não uma classificação certificada" em domínios para os quais o adaptador não foi treinado.

O reconhecimento de fala para texto é real, e mais restrito do que a manchete.

O caminho de áudio incorpora o Granite Speech 5.0 TurboCTC, um codificador CTC conformer não autorregressivo de 470M de parâmetros, e transcreve o áudio recebido antes de inserir a transcrição no contexto do chat no lugar da parte de conteúdo de áudio. Chamá-lo não altera o formato da solicitação: é uma input_audio parte de conteúdo em uma conclusão de chat normal, e a transcrição é executada no mesmo endpoint que o chat e as decisões, portanto não há um segundo servidor de fala para implantar.

As ressalvas, todas elas do próprio cartão da IBM e não de um crítico: o codificador é apenas em inglês, sua saída é em minúsculas e sem pontuação, não há direcionamento no momento da decodificação e — a que deveria fazer você parar — o codificador de fala e o LLM não são treinados conjuntamente. Não há uma projeção treinada que os acople. Um erro de transcrição pode, portanto, alterar silenciosamente aquilo a que o modelo, ou um adaptador, responde. Se você está construindo qualquer coisa em que um erro de transcrição tenha consequências, essa frase é toda a revisão de segurança.

O que está confirmado, o que é relatado pelo fornecedor, o que ninguém verificou

• Confirmado no repositório — identidade do modelo base e número de camadas, os dois ranks dos adaptadores e seus módulos-alvo, os IDs dos tokens de controle, a contagem de parâmetros compostos, a janela de 131.072 tokens, o licenciamento Apache-2.0 e as versões documentadas do vLLM e do Transformers solicitadas no card.

• Relatado pelo fornecedor, não reproduzido — as pontuações do Decision Index, a alegação de que o Granite Speech 5.0 TurboCTC é o modelo de ASR mais rápido do ranking OpenASR, a alegação de "mesma VRAM do que o modelo base" e o comentário do post de lançamento de que um modelo Granite Switch 3B personalizado joga Doom a 60–100 decisões por segundo, contra 10 por segundo relatadas para um modelo de decisão fechado. A IBM afirma que publicará mais dados "nas próximas semanas", o que é uma admissão de que as evidências atuais são escassas.

• Ninguém verificou — todo o resto. Não há avaliação independente, nenhuma entrada em leaderboard de terceiros, nenhuma API hospedada pela IBM e nenhuma medição publicada de latência ou throughput por qualquer pessoa que não seja da IBM. O repositório no Hub mostra algumas dezenas de downloads e um punhado de curtidas: este modelo tem dois dias e é amplamente não lido.

Quanto custa operar, e onde o OrcaRouter se encaixa

O Granite Switch 4.1 8B é, no momento, um caso de auto-hospedagem. A ficha lista HuggingFace Transformers e vLLM como backends, fixa uma janela de suporte bastante estreita (Transformers 5.16–5.17, vLLM 0.26–0.28), e o checkpoint funciona com ambos sem alterações no código. Não há endpoint gerenciado para o qual apontar, o que, para a maioria das equipes, significa uma GPU e um contêiner antes da primeira requisição.

Falando com franqueza sobre o resto: o Granite Switch não está no catálogo do OrcaRouter hoje, e nenhum outro modelo Granite também não — então, se você quer este checkpoint, o caminho é o lançamento do próprio fornecedor e o seu próprio hardware, não nós. O que o OrcaRouter oferece é a decisão em torno disso. A plataforma roteia mais de 200 modelos por trás de uma única chave, com failover automático, e repassa o preço de tabela do provedor com 0% de margem, então quando um modelo que você está avaliando ganhar um endpoint hospedado, compará-lo com o incumbente no seu próprio tráfego será uma mudança de configuração, e não um segundo contrato. Isso importa sobretudo exatamente nesta situação: um checkpoint de dois dias, sem avaliação independente, é um candidato, não um incumbente, e a coisa barata a fazer com um candidato é mantê-lo em uma comparação lado a lado, em vez de reconfigurar um caminho de produção em torno dele.

A questão em aberto

Granite Switch 4.1 8B é uma aposta de que a composição supera a escala para uma classe específica de trabalho: aplicações que precisam responder, decidir e transcrever, em que executar três modelos significa três implantações, três latências e três faturas. A engenharia para tornar essa aposta barata — cache KV compartilhado, troca de adaptador por token, tokens de controle resolvidos no template de chat — é genuinamente incomum, e é a parte deste lançamento que ainda importará daqui a um ano.

O que ainda não está resolvido é se a resposta composta é boa. O perfil publicado do adaptador de decisão é irregular, o caminho de fala é somente em inglês e não foi treinado em conjunto, e a coisa toda tem apenas dois dias, sem nenhuma execução independente por trás. Leia o manifesto de build, execute o comando compose por conta própria e faça benchmark do adaptador de decisão no seu próprio conjunto de rótulos antes de acreditar no 42,9 de qualquer pessoa.