Granite 4.2 raciocina em três tamanhos — e mira agentes executados localmente

A IBM lançou em 25 de agosto de 2026 a família IBM Granite 4.2, composta por modelos densos de 3 bilhões, 8 bilhões e 30 bilhões de parâmetros. O anúncio da IBM Research apresenta raciocínio nativo, chamada de ferramentas, licença Apache 2.0 e implantação em nuvem, infraestrutura local ou dispositivos de borda.

Os pesos estão disponíveis para download, o que permite executar os modelos em infraestrutura privada, enquanto serviços hospedados oferecem o caminho de uma API. Uma análise independente publicada no lançamento também registra os três tamanhos, os modos de raciocínio, a chamada nativa de ferramentas e o suporte a mecanismos de inferência autogerenciados; avaliações externas amplas de qualidade, velocidade e memória, porém, ainda são escassas.

Os três tamanhos dividem tarefas e custos operacionais

O Granite 4.2 3B é a opção compacta da família e a candidata mais direta para dispositivos de borda ou ambientes com recursos limitados. Ele oferece raciocínio e uso de ferramentas, mas não recebeu a etapa adicional de aprendizado por reforço agêntico aplicada às duas variantes maiores.

O Granite 4.2 8B ocupa a faixa intermediária. Além do treinamento básico compartilhado pela família, passou por uma etapa voltada a tarefas de engenharia de software, operação em terminal e busca, nas quais o modelo precisa observar resultados e escolher ações subsequentes.

O Granite 4.2 30B recebeu o mesmo treinamento agêntico adicional e concentra a maior capacidade da linha, acompanhada por demanda superior de processamento e memória. A diferença não está apenas no espaço ocupado pelos pesos: contexto, cache de atenção, concorrência e mecanismo de inferência também alteram o consumo total.

• 3B: prioriza menor ocupação e execução em ambientes restritos.
• 8B: equilibra porte e treinamento específico para fluxos com ferramentas.
• 30B: destina mais capacidade a raciocínio, código e sequências complexas, com custo operacional maior.

Essa divisão é uma orientação de posicionamento, não uma especificação de hardware. Formato quantizado, precisão numérica e extensão real do contexto podem fazer a mesma variante caber ou não em uma máquina, além de mudar latência e qualidade.

Raciocínio pode ser ajustado a cada solicitação

Os modelos trabalham com raciocínio completo, resposta sem raciocínio explícito e um modo de baixo esforço. A seleção permite reservar mais processamento para problemas de várias etapas e reduzir a deliberação em chamadas simples, sem manter um endpoint diferente para cada comportamento.

O modo completo pode ser relevante quando o agente precisa examinar um repositório, planejar alterações e verificar o resultado. O modo direto reduz etapas em pedidos simples, enquanto o baixo esforço ocupa uma posição intermediária. O ganho real de latência ou qualidade depende do prompt, do limite de geração e da infraestrutura empregada.

A chamada de ferramentas também não equivale à execução autônoma e irrestrita. O modelo pode selecionar uma função e gerar seus argumentos, mas o sistema hospedeiro continua responsável por credenciais, permissões, validação dos parâmetros, acesso a arquivos e limites de repetição.

Resultados publicados ainda são medições do fornecedor

A tabela de benchmarks mantida pela IBM atribui aos modelos 3B, 8B e 30B, respectivamente, resultados pass@1 de 78,33, 86,67 e 89,17 no AIME25, além de 52,41, 50,29 e 61,39 no BFCL v4. No SWE-Bench Verified, a página informa 47,67 para o 8B e 57,00 para o 30B, sem resultado para o 3B; no IFBench, aparecem 74,33, 79,33 e 77,17.

A ordem entre os tamanhos muda conforme a tarefa: o 8B supera o 30B no IFBench, enquanto o modelo maior fica à frente no AIME25, no BFCL v4 e no SWE-Bench Verified. Isso impede transformar a escala de parâmetros em uma classificação universal de qualidade.

Até que laboratórios e usuários reproduzam os testes em maior escala, esses valores devem ser tratados como resultados publicados pelo fornecedor. Uma comparação controlada precisa manter o mesmo checkpoint, precisão ou quantização, template de conversa, modo de raciocínio e mecanismo de inferência. Em agentes, também devem permanecer constantes as ferramentas disponíveis, as permissões, o limite de etapas e o critério de conclusão.

Execução local oferece controle, mas exige operação própria

A licença Apache 2.0 e a distribuição dos pesos abrem três rotas: execução em uma estação ou servidor próprio, hospedagem em nuvem privada ou data center e consumo por uma API. As opções não são equivalentes em privacidade, manutenção e previsibilidade de custos.

Na implantação local, entradas e resultados podem permanecer dentro da infraestrutura administrada pela organização. Em contrapartida, a própria equipe assume dimensionamento, atualizações, observabilidade, isolamento das ferramentas e disponibilidade do serviço. Uma API reduz esse trabalho inicial, mas submete a aplicação aos preços, limites técnicos e políticas de dados do provedor escolhido.

A escolha reproduzível começa pela carga de trabalho: memória ocupada com o contexto esperado, latência sob concorrência, proporção de chamadas de ferramentas válidas, taxa de conclusão e custo por tarefa. Esses mesmos critérios permitem comparar os três tamanhos e uma API sem presumir que o maior modelo será sempre a melhor opção.

O lançamento deixa estabelecida uma família de três escalas com raciocínio configurável, chamada nativa de ferramentas e pesos adequados à implantação privada. O que permanece em aberto é seu comportamento fora das avaliações da IBM: medições independentes de memória, velocidade, qualidade e estabilidade em agentes prolongados ainda serão necessárias para delimitar onde cada variante compensa.