Microsoft-Decision-1 vs. Intern-Decision-2B: Nove milissegundos mais rápido e mensuravelmente pior calibrado

Há um número na própria tabela da InternLM que não deveria existir, e é a razão pela qual esta comparação vale mais do que a ficha técnica. Intern-Decision-2B — 2.213.241.664 parâmetros, ajustado fino a partir de Qwen/Qwen3.5-2B, enviado ao Hugging Face em 26 de setembro de 2026 às 05:36:19 UTC sem nenhum anúncio — registra 33,28 ms de latência média por consulta em uma única RTX 4090, o que é marginalmente mais rápido do que seu próprio irmão de 852 milhões de parâmetros, com 33,98 ms. Ele também registra a pior calibração de sua família: um erro de calibração esperado de 0,100 contra 0,066 do 0.8B, com uma temperatura ajustada de 2,100509348278 contra 2,747760550703 do 0.8B. Enquanto isso, Microsoft-Decision-1, disponível de forma geral no Microsoft Foundry desde 8 de outubro de 2026, não publica nem um valor de latência nem um erro de calibração — apenas um parágrafo de metodologia descrevendo como ambos foram medidos. Portanto, a pergunta que este confronto realmente faz não é qual dos dois é melhor. É o que você está comprando quando compra o tamanho intermediário de qualquer coisa.

Ambos os modelos são pontuadores de decisão: estado de entrada, conjunto limitado de perguntas de entrada, probabilidades calibradas de saída, sem texto gerado e sem tokens para analisar. Esse contrato compartilhado é o que torna as diferenças legíveis. O Microsoft-Decision-1 é uma API Foundry hospedada, apenas de texto, com base no Qwen3.5-9B, com uma janela de 32.768 tokens, sem pesos distribuídos e sem caminho de fine-tuning. O Intern-Decision-2B é um checkpoint Apache-2.0 com a licença upstream do Qwen preservada como LICENSE-QWEN, aproximadamente 4,46 GB de repositório, código de inferência personalizado e nenhum endpoint hospedado em lugar algum.

Para que serve realmente o tamanho médio

InternLM lançou três checkpoints em quarenta segundos: o 0.8B às 05:35:57, este às 05:36:19, o 4B às 05:36:37. Na média das sete suítes do próprio fornecedor, a família sobe na ordem que você esperaria — 79,38, 84,68, 90,02 —, que é o único ponto em que o 2B parece uma compra sensata. Em todo o resto, ele parece o tamanho que ninguém teria escolhido de propósito.

O processamento do prompt domina uma chamada de decisão, e essa é a explicação mecânica para a inversão de latência, e não um mistério. Um scorer faz exatamente uma passagem direta sobre um prompt cujo comprimento é definido pelo estado, pelo schema e pelas descrições das opções — nunca por qualquer coisa que o modelo escreva, porque ele não escreve nada. Nesse regime, a contagem de parâmetros é um custo de segunda ordem, então o motivo usual para recorrer ao menor checkpoint não se aplica: você não está economizando tempo, está economizando memória. O repositório inteiro do 0.8B tem cerca de 1,73 GB, contra os 4,46 GB deste modelo, e essa é a razão honesta para preferi-lo. A única alegação real do 2B é que ele por acaso é o mais rápido dos rápidos, por uma margem pequena o suficiente para ser ruído.

Em comparação com o Microsoft-Decision-1, essa afirmação é quase irrelevante, porque os dois modelos não estão no mesmo regime de latência. A velocidade de um endpoint hospedado é função do formato da sua implantação — serverless versus throughput provisionado no mesmo SKU padrão — antes de ser função do modelo, e a Microsoft não publica nenhum número por chamada para comparação. O que a Microsoft publica é uma restrição operacional rígida que atua em sentido contrário: a inferência em lote está desabilitada. Não há canal offline para amortizar uma execução de pontuação em massa, então um pipeline do Microsoft-Decision-1 paga o custo interativo de cada decisão, enquanto um checkpoint auto-hospedado paga em horas de GPU, esteja ou não pontuando.

A coluna de calibração, onde o meio perde

Leia os três cartões Intern-Decision em conjunto e a família deixa de se comportar de forma previsível. A acurácia é monotônica em relação ao tamanho; a calibração não é. O 2B apresenta um ECE de 0,100 — o mais fraco dos três — e uma temperatura ajustada de 2,100509348278, bem abaixo da temperatura de 2,747760550703 do 0.8B. O cartão instrui você a usar o módulo de inferência fornecido com o tamanho que você baixou, porque as calibrações padrão são por checkpoint; quem copia um wrapper de um modelo irmão para outro aplica silenciosamente a temperatura errada.

Vale a pena entender a própria transformação antes de tratar esse 0,100 como um veredito sobre os pesos. Trata-se de um softmax sobre os logits candidatos do campo, seguido por um segundo softmax sobre o logaritmo dessa distribuição dividido pela temperatura. Como é executado depois do primeiro softmax e preserva a ordenação, não consegue alterar o argmax de forma alguma. Ele desloca a confiança, a probabilidade de sim e o valor esperado de uma pergunta de pontuação, e deixa o rótulo idêntico. Se o seu pipeline lê rótulos, a temperatura não tem efeito e o ECE é uma curiosidade. Se o seu pipeline lê probabilidades — aplica limiares a elas, ordena por elas, alimenta um cálculo de valor esperado com elas —, então um ECE de 0,100 é a diferença entre um limiar que significa o que você escreveu e um que não significa. A resposta certa é ajustar a sua própria temperatura nos seus próprios casos rotulados, e não concluir que os pesos são ruins.

O Microsoft-Decision-1 exige exatamente o mesmo trabalho, com menos com que começar. A aba Benchmarks dele afirma que acurácia, erro de calibração, recall de segurança, taxas de falsos positivos e consistência de equidade foram medidos em benchmarks de decisão públicos e da comunidade, além de conjuntos de teste internos reservados; que a ordem das opções foi variada; que testes estatísticos pareados foram aplicados; e que o modelo “tem desempenho equivalente ao de modelos de decisão líderes e à frente de outros modelos de decisão abertos avaliados com a mesma metodologia”. Sem ECE. Sem Brier. Sem temperatura. Sem tabela de acurácia. O modelo cuja proposta de valor inteira é uma probabilidade confiável é justamente aquele que, nesta comparação, não tem absolutamente nenhum número de calibração publicado.

Limites de contrato: quatro coisas que o modelo hospedado não fará

Os dois modelos recebem o que parece ser a mesma chamada, e as divergências ficam nas suas bordas.

• Modalidade — Microsoft-Decision-1 é explicitamente somente texto e não aceita imagem, áudio ou vídeo. Intern-Decision-2B aceita até oito imagens juntamente com o estado, o que o torna um candidato para triagem de capturas de tela e verificações de layout que a API hospedada não consegue atender com precisão alguma.

• Teto de entrada e modo de falha — Microsoft-Decision-1 executa uma única invocação sobre até 32.768 tokens. Intern-Decision-2B declara DecisionEngine(max_length=8192) e rejeita entrada grande demais em vez de truncá-la, o que é o comportamento correto para um pontuador e também um limite rígido, porque o estado, o esquema e o esqueleto devem estar todos presentes em uma única passagem; nenhuma estratégia de fragmentação preserva o contrato.

• Formato da pergunta — A InternLM documenta de uma a dezesseis perguntas por chamada, com até 62 opções cada, distribuídas em três tipos de campo (choice, score, noul), em que noul é um sim/não binário que retorna uma probabilidade e score retorna um valor esperado ponderado por probabilidade em uma escala que você define. A Microsoft documenta os formatos — sim/não, múltipla escolha, avaliação, classificação, rubrica — além de uma opção de abstenção explicitamente suportada, como "não é possível dizer", quando as evidências são insuficientes, o que é a linha mais útil da página para quem escreve lógica de escalonamento.

• Preço — a página do modelo Microsoft-Decision-1 não exibe uma tarifa; os preços direcionam para a área de preços da Microsoft, então o custo por decisão é algo que você consulta no Azure ou em uma fatura, com 0% dele atribuível a tokens de saída, porque não há nenhum. O Intern-Decision-2B não custa nada por chamada e custa tudo em tempo de GPU, e não tem provedor hospedado. Seu armazenamento é de aproximadamente 4,46 GB, distribuídos entre um shard de linguagem de 3,76 GB, uma torre de visão de 612,5 MB e um projetor de 50,3 MB.

O que está confirmado e o que é apenas conversa do fornecedor

Manter essas duas categorias separadas é a disciplina inteira desta família. Confirmado por uma listagem de arquivos ou uma resposta HTTP: a contagem de parâmetros, o mapa de shards, o par de licenças, o modelo base, a arquitetura subjacente — um Qwen3_5ForConditionalGeneration com 24 camadas, um tamanho oculto de 2.048, 8 cabeças de consulta contra 2 cabeças de chave-valor, uma dimensão de cabeça de 256, um padrão repetitivo de três camadas de atenção linear para uma camada de atenção completa, uma camada de predição multi-token mantida e um teto de embedding de 262.144 posições que o teto de 8.192 tokens do motor torna praticamente irrelevante.

Relatado pelo fornecedor e não reproduzido: cada número de acurácia, cada valor de latência e a temperatura. Não há artigo, nem entrada no arXiv, nem post de lançamento, nem changelog, nem avaliação independente. O Space de demonstração responde 401, o que significa que ele não é público, e não que está quebrado. O repositório do GitHub que surgiu depois do modelo — três commits, código de treinamento, dois backends de inferência, um pacote de avaliação com 10.751 linhas de teste, um benchmark de calibração de 96 casos e um guia de reprodução — é mais documentação do que a maioria dos lançamentos discretos recebe, e não traz pesos, dados de treinamento nem licença de código. A Microsoft está em uma posição diferente, mas adjacente: sua metodologia é real e sua alegação é qualitativa, e nenhuma das empresas está atualmente em posição de ter seu número central verificado por qualquer pessoa que não seja você.

Onde o OrcaRouter se encaixa em um pipeline como este

Nenhum dos dois modelos está no nosso catálogo, e nada aqui deve ser interpretado como uma afirmação de disponibilidade. Um modelo que devolve probabilidades em vez de texto não é algo para onde se encaminham conclusões de chat, e isso vale para ambos. O que nós oferecemos é a metade generativa do ciclo que esses avaliadores existem para servir: os mais de 200 modelos por trás de uma única chave compatível com a OpenAI que escrevem a rubrica, redigem as respostas candidatas e emitem a chamada de ferramenta que um avaliador depois classifica antes de a executar. O preço de tabela do fornecedor é repassado com 0% de margem, por isso um corte de preço do fornecedor no lado generativo fica ativo no nosso no mesmo dia, e se preferir não apostar o seu limiar num único juiz, a DSL de encaminhamento compõe vários modelos numa única chamada e a fusão de modelos reporta a concordância entre eles como um campo que pode pontuar. O failover automático mantém esse lado vivo quando um único fornecedor se degrada, o que importa mais num ciclo que pontua tudo o que vê do que num que responde a um utilizador de vez em quando.

Conclusão

O Microsoft-Decision-1 está em disponibilidade geral no Microsoft Foundry desde 8 de outubro de 2026: hospedado, apenas texto, 32.768 tokens, uma base Qwen3.5-9B pós-treinada pela Microsoft, sem pesos distribuídos, e uma seção de benchmark que documenta sua metodologia sem apresentar um número — incluindo a ausência de latência, com a inferência em lote desativada. O Intern-Decision-2B é um checkpoint Apache-2.0 com 2.213.241.664 parâmetros, de 26 de setembro de 2026, que é o mais rápido dos seus três irmãos, com 33,28 ms numa 4090, e o pior calibrado, com um ECE de 0,100, com uma temperatura ajustada de 2,100509348278 que não consegue alterar um rótulo, mas alterará todas as confianças sobre as quais você aplicar um limiar. Se você quiser o tamanho intermediário, a justificativa honesta para escolhê-lo é tênue: pague os 2,7 GB extra pela precisão do 4B ou aceite a pegada do 0.8B e, em qualquer dos casos, ajuste sua própria calibração antes que um limiar sequer se aproxime da produção.

O que nós de fato fornecemos é a metade generativa do ciclo que esses avaliadores existem para servir: os mais de 200 modelos por trás de uma única chave compatível com a OpenAI que escrevem a rubrica, redigem as respostas candidatas e emitem a chamada de ferramenta que um avaliador então pontua antes de executá-la.