Decision 3.0 vs Intern-Decision-4B: Duas equipes fizeram ajuste fino no mesmo modelo e discordaram sobre todo o resto

Coloque d3-mini, o membro de 4B do Decision 3.0, ao lado do Intern-Decision-4B e a primeira coisa que você nota não é uma diferença. Ambos são fine-tunes do mesmo checkpoint base, Qwen3.5-4B. Ambos estão listados com 4,54 bilhões de parâmetros. Ambos recebem um estado, um esquema de perguntas nomeadas e um conjunto de respostas candidatas, e retornam uma probabilidade calibrada por candidato sem gerar um token. Ambos são Apache-2.0. Ambos foram lançados sem anúncio — a InternLM enviou três checkpoints em quarenta segundos em 26 de setembro de 2026, e a família Decision 3.0 da vLLM-SR chegou ao Hugging Face em 10 de outubro de 2026, com a notícia divulgada apenas pela conta X do projeto vLLM.

Tudo o que vem depois disso é uma discordância. Eles discordam sobre como extrair uma probabilidade do modelo, sobre se vídeo conta como entrada, sobre quão longa uma requisição pode ser e — de forma mais incisiva — sobre se a equipe está disposta a publicar o número que atesta que sua própria confiança é confiável. Este artigo é sobre essas quatro discordâncias e o que cada uma custa a você, não sobre qual modelo é "melhor", porque os dois não são medidos na mesma escala e não podem ser classificados um contra o outro sem que se faça um trabalho que nenhum dos fornecedores fez.

A coincidência que vale a pena entender primeiro

Dois laboratórios escolherem o mesmo backbone de 4B em um intervalo de duas semanas não é de todo surpreendente — o Qwen3.5-4B é uma base razoável para um modelo de saída estruturada, e ambas as equipes claramente recorreram a ele porque é pequeno o suficiente para rodar barato e forte o suficiente para ler instruções. O surpreendente é que tenham chegado à mesma contagem de parâmetros com quatro algarismos significativos. Isso mostra que o ajuste fino preservou a arquitetura, e que nenhum dos dois adicionou uma torre de visão separada grande o suficiente para alterar o total. Ambos incorporam sua capacidade multimodal nos mesmos pesos.

A parte interessante é a leitura. Ambos os modelos respondem às perguntas da mesma forma, em princípio — pontuam respostas candidatas em vez de gerá-las — e de modo completamente diferente no mecanismo:

• Intern-Decision-4B — mapeia cada opção para um único símbolo de token (A–Z, depois a–z, depois 0–9), renderiza um esqueleto JSON no prompt com um placeholder por campo e executa uma única passagem forward causal, lendo os logits na posição imediatamente antes de cada placeholder. O mecanismo está documentado passo a passo na ficha do modelo, incluindo a etapa exata de softmax e temperatura.

• d3-mini — traz uma arquitetura personalizada em modeling_d3.py com uma cabeça de leitura separada em seu próprio readout.safetensors, um decision_config.json declarando noncausal_full_attention e pooling do último token, e um mapeamento de token para código definido na configuração em vez de descrito em prosa.

Nenhuma das abordagens é obviamente melhor. A rota do InternLM tem a vantagem de rodar em uma classe de modelo padrão do Hugging Face com uma sequência numérica documentada — você pode conferir o trabalho dela. A rota do vLLM-SR tem a vantagem de que a leitura é uma cabeça treinada, e não uma projeção de um embedding de token existente, o que é um ajuste mais livre, e o custo é que você precisa definir trust_remote_code=True e executar o código deles para fazer qualquer coisa.

Os limites que cada um publica

É aqui que uma verdadeira preferência começa a se formar, porque um cartão é bem mais específico do que o outro quanto ao ponto em que deixa de funcionar.

• Limite de entrada — Intern-Decision-4B: 8.192 tokens por padrão e solicitações acima disso são rejeitadas de imediato, nunca truncadas, com o limite definido por um argumento de construtor. d3-mini: max_length é null na configuração fornecida e nenhum orçamento de tokens aparece em lugar algum do cartão.

• Perguntas por solicitação — Intern-Decision-4B: 1 a 16, com um máximo declarado de 62 opções em qualquer pergunta individual. d3-mini: nenhum limite declarado; a ficha informa apenas que as perguntas são respondidas em conjunto, cada uma a partir de sua própria passagem direta.

• Imagens — Intern-Decision-4B: até oito por solicitação, ordenadas por uma lista fornecida por você, com o processador de checkpoint cuidando do redimensionamento e da expansão de tokens. d3-mini: várias por solicitação como caminhos, URLs, imagens PIL ou URLs de dados base64, cada uma lida com até 1,6 megapixels, com cada pergunta vendo cada imagem.

• Vídeo — Intern-Decision-4B: nenhum. d3-mini: vários vídeos, lidos a 2 quadros por segundo, limitados a 32 quadros distribuídos ao longo do clipe e 0,2 megapixels por quadro.

O teto de entrada é a linha que decidirá isso para a maioria das pessoas. Um orçamento de 8.192 tokens compartilhado entre estado, instruções da pergunta e descrições de candidatos é uma restrição real ao trabalho de avaliação de documentos e roteamento de contexto longo para o qual esses modelos são vendidos, e a InternLM merece crédito por dizer isso claramente em vez de deixar que seja descoberto. O vLLM-SR deixar isso não declarado é o oposto: não um limite oculto, mas um desconhecido, e nenhuma quantidade de leitura do repositório resolve isso.

A calibração é a verdadeira divisão

Todo modelo de decisão faz a mesma promessa: o número que ele retorna é uma probabilidade, e os limiares definidos nele significam algo. Quase nenhum deles prova isso. É aqui que os lançamentos mais divergem, e a divergência segue na direção oposta à que você suporia pelas datas de lançamento.

O Intern-Decision-4B publica, em seu próprio card, uma pontuação de Brier de 0,347 e um erro de calibração esperado de 0,065 em sua média de sete benchmarks, uma temperatura ajustada de 1,99241824 derivada por minimização da NLL em 1.728 casos de calibração designados com 1.693 casos de validação separados, uma declaração explícita de que os rótulos do conjunto de testes não foram usados para selecionar essa temperatura, e um diagnóstico de 96 casos mostrando sua calibração passando de 0,628 de Brier / 0,213 de ECE antes do escalonamento de temperatura para 0,550 / 0,089 depois. Ele também declara o padrão e diz que a calibração é por checkpoint, portanto usar outro tamanho com este módulo não corresponderá.

O Decision 3.0 publica um índice de acurácia e uma alegação de cobertura — todas as 140.178 solicitações públicas respondidas, nenhuma sem suporte — e nenhum valor de calibração. Nenhuma pontuação de Brier, nenhum ECE, nenhuma temperatura declarada, em nenhum dos seis checkpoints. A temperatura no arquivo enviado pelo d3, decision_config.json, é 1.0, que é a identidade e pode ou não ser o valor ajustado; o arquivo não diz.

Leia as duas manchetes do índice lado a lado e a assimetria piora. O cartão do d3-mini reporta uma pontuação de 54,90 na suíte pública do Jev Decision Index 0.3, descrita como medida com o kit oficial nos pesos publicados, enquanto as linhas de comparação no mesmo painel são descritas como dados do painel ao vivo. O Intern-Decision-4B reporta uma média de 90,02 em seus próprios sete benchmarks. Esses dois números não estão na mesma escala, não usam as mesmas tarefas, e colocá-los em uma única frase como comparação seria desonesto. O que é comparável é a divulgação: um cartão informa o quanto suas confianças estão erradas, e o outro não sabe ou não quer dizer.

Latência, e por que os dois conjuntos de milissegundos também não são comparáveis

Ambos os cartões publicam latência por requisição, e aceitá-los pelo valor nominal seria um erro pela mesma razão pela qual os números de precisão não são comparáveis.

• Intern-Decision-4B — média de 44,16 ms, mediana de 44,03 ms, p95 de 44,60 ms, medidos em uma única RTX 4090 por meio do caminho local do Hugging Face, descritos como dependentes da carga de trabalho e do hardware.

• d3-mini — mediana de 17,5 ms para texto, 96,2 ms com uma imagem, 371,5 ms com um vídeo de dez segundos, em uma AMD Instinct MI325X, uma requisição por vez.

Duas coisas tornam esses incomparáveis. A primeira é o hardware e o caminho de software: uma 4090 contra uma MI325X, um forward pass padrão do Hugging Face contra uma implementação de atenção personalizada com kernels de camadas mascaradas disponíveis via flash-linear-attention. A segunda é a carga de trabalho: o número do InternLM é descrito como ponta a ponta por consulta em um mix não declarado, e o do vLLM-SR é discriminado por modalidade de entrada, então a comparação apenas de texto é a única linha comparável e mesmo essa cruza dois fabricantes de GPU.

O valor a extrair de ambos os cartões não é o ranking, é a forma. Um modelo de decisão é chamado repetidamente dentro de um único fluxo de trabalho — um registo de suporte pode precisar de um destino, uma verificação de reembolso, uma decisão de escalonamento e uma pontuação de prioridade, quatro perguntas, e um lote de 128 registos transforma isso em 512 decisões. A esse volume, 17 ms e 44 ms desaparecem ambos face ao que quer que o modelo generativo a jusante custe. Os valores dependentes da modalidade são os que merecem atenção, porque um pedido de imagem ou de vídeo custa entre cinco e vinte vezes o de um pedido de texto, segundo os próprios números do d3-mini, e se a sua decisão estiver a ser tomada com base numa captura de ecrã, importou um perfil de custos que a maioria das implementações de modelos de decisão não tem.

Qual deles escolher de verdade?

Se a decisão que você precisa tomar depende de um vídeo, não há disputa nem análise necessária: o Decision 3.0 lê vídeo e o Intern-Decision-4B não. Essa é a resposta completa para qualquer coisa que envolva gravações de tela, clipes de câmera ou sequências de quadros, e é a lacuna de capacidade que, por si só, justifica a existência da família mais recente.

Se as suas entradas forem texto e imagens ocasionais, a escolha depende de duas coisas e nenhuma delas é a tabela de classificação.

Use o Intern-Decision-4B quando precisar de raciocinar sobre limiares. É o único dos dois que lhe diz se um 0,9 significa nove em cada dez vezes, declara a sua temperatura, indica em que casos essa temperatura foi ajustada e documenta a sua inferência como um breve procedimento numerado que pode reimplementar numa classe de modelo padrão. Para um scorer colocado à frente de uma ação automatizada, é essa a propriedade que importa, e é mais rara do que pontos de acurácia.

Adote o Decision 3.0 quando precisar da amplitude de tamanhos ou das modalidades. Ter seis checkpoints de 0,59B a 26,09B significa que o mesmo formato de requisição pode ser atendido por um modelo de edge de 6,7 ms e por um de 27B, e a família compartilha uma única interface, de modo que passar de um nível para outro é uma mudança de configuração, e não uma reescrita. O porém é que você está confiando num orçamento de entrada não declarado e numa alegação de calibração não auditada, e o maior modelo da família é justamente aquele cujo número de índice o fornecedor mediu na própria bancada de testes.

Nenhum dos dois é um padrão seguro hoje. O checkpoint mais baixado do d3 está no Hugging Face há cerca de um dia; o Intern-Decision-4B está disponível há duas semanas e acumulou aproximadamente 3.200 downloads e 83 curtidas, o que é atenção, mas não tráfego de produção. Ambos são baratos o suficiente para testar, e nenhum dos dois tem uma avaliação de terceiros por trás. Se você está colocando um scorer na frente de algo que gasta dinheiro, o movimento certo é rodar os dois nos seus próprios casos rotulados e comparar as curvas de calibração, não as linhas do índice.

Onde um roteador se encaixa, honestamente

O OrcaRouter não disponibiliza nenhum desses dois modelos. Os checkpoints do Decision 3.0 são um caminho de inferência local em Python em um repositório do Hugging Face, sem endpoint HTTP publicado, e o Intern-Decision-4B é fornecido como uma classeDecisionEngine que você mesmo instancia. Nenhum deles é algo que poderíamos rotear hoje, e nenhuma parte deste artigo deve ser interpretada como uma alegação de disponibilidade.

O que nós oferecemos é a versão hospedada da mesma família. typesafe/jev-1.13 está no nosso catálogo, disponibilizado via POST /v1/systemone — o mesmo contrato de estado e perguntas nomeadas que ambos os modelos abertos acima implementam — a US$ 0,042 por milhão de tokens de entrada, sem cobrança de conclusão, já que ele nunca gera uma. Ele fica ao lado de mais de 200 outros modelos, e esse é o ponto prático para quem compara esses dois: o pontuador é a parte barata do ciclo, e o modelo que age sobre a decisão é a parte cara. Encaminhar ambos por uma única chave, com failover automático quando um provedor oscila e preço de tabela do provedor repassado com 0% de markup, significa que avaliar um modelo de decisão não exige assinar um segundo contrato nem reescrever o ponto de chamada quando você troca de backend. Se você está no meio de uma avaliação — que é onde ambos esses modelos estão hoje —, essa é a parte que vale a pena configurar antes de se comprometer com qualquer um dos dois.

A questão em aberto

Os dois cartões discordam sobre o que um autor de modelo deve a um leitor, e essa discordância é mais interessante do que os modelos. A InternLM publicou uma temperatura e os casos sobre os quais ela foi ajustada, depois publicou o diagnóstico que mostra o quanto a calibração melhorou. A vLLM-SR publicou hashes de arquivos, revisões de base fixadas, um alvo de hardware declarado, uma alegação de cobertura — trabalho de proveniência real — e nenhum número de calibração em absoluto.

O teste de qual lançamento amadurece não é qual deles vence um quadro. É se o próximo checkpoint do Decision é lançado com uma pontuação de Brier nele, e se o próximo upload do InternLM chega a vídeo. Ambos são visíveis de fora, ambos são baratos de verificar, e nenhum dos dois aconteceu ainda.