Intern-Decision-0.8B chegou sem anúncio: o que a InternLM colocou silenciosamente no Hugging Face

O link do GitHub no cartão do modelo retorna 404. O Space de demonstração retorna 401. Não há coleção, post de blog, relatório técnico nem resultado de busca em lugar algum para a string "Intern-Decision" que não seja um anúncio de vaga de estágio — e, ainda assim, o Intern-Decision-0.8B está no Hugging Face agora mesmo como um checkpoint completo, baixável, Apache-2.0, ajustado a partir do Qwen3.5-0.8B, enviado nas primeiras horas de 26 de setembro de 2026 com dois irmãos maiores que apareceram nos mesmos três minutos: Intern-Decision-2B e Intern-Decision-4B. A InternLM já lançou dessa forma antes, e é por isso que tudo abaixo é montado a partir do próprio repositório, e não de um post de lançamento. A distinção importa aqui mais do que o habitual: um repositório diz o que existe, e só o fornecedor pode dizer para que serve.

O que o repositório de fato diz, em detalhes, é incomum o suficiente para valer a leitura. Estes não são modelos de chat e não são modelos de linguagem pequenos no sentido usual. O Intern-Decision-0.8B recebe um estado, um esquema de perguntas nomeadas que você escreve com antecedência e, opcionalmente, até oito imagens, e retorna uma distribuição de respostas para cada pergunta em uma única passagem direta. Ele nunca chama generate(). Ele nunca faz amostragem. Não há saída de texto para analisar, nenhum JSON para corrigir, nenhum loop de nova tentativa em torno de uma chave que nunca fechou. A estreiteza é a arquitetura inteira, e isso coloca este modelo na mesma pequena categoria que o Jev 1.13 da TypeSafe e o Laya da Convai — uma categoria contra a qual a InternLM evidentemente fez benchmark de propósito, porque o Jevbench é o benchmark da própria TypeSafe e é a primeira coluna da tabela.

Aqui está o que é possível saber a partir do checkpoint, o que é apenas afirmado pelo checkpoint, e o que ninguém fora da InternLM pode dizer atualmente de forma alguma.

O que está realmente no repositório

A ficha é curta e franca sobre a linhagem. O Intern-Decision-0.8B é descrito como "um modelo de decisão estruturado multimodal ajustado a partir do Qwen3.5-0.8B" — a base Qwen lançada em 28 de fevereiro de 2026 — e o repositório traz um segundo arquivo de licença, LICENSE-QWEN, ao lado dos termos Apache-2.0, que é o que um modelo derivado deve fazer e é um pequeno sinal de honestidade por si só. O índice do Hugging Face reporta 852.985.920 parâmetros em três shards: um shard de linguagem de 1,50 GB, um shard de visão de 176 MB e um projetor de 25 MB. O armazenamento total do repositório é de cerca de 1,73 GB, incluindo os arquivos do tokenizador, o que coloca tudo confortavelmente em uma única GPU de consumidor ou em um laptop bem equipado.

A configuração revela uma arquitetura que a Qwen vem enviando ao longo da geração 3.5, em vez de uma rede de decisão sob medida. Trata-se de um Qwen3_5ForConditionalGeneration com 24 camadas organizadas em um padrão repetido de três camadas de atenção linear para uma camada de atenção completa, tamanho oculto de 1.024, 8 cabeças de atenção contra 2 cabeças de chave-valor, uma dimensão de cabeça de 256 e um embedding de posição máxima de 262.144 tokens. Uma única camada de previsão de múltiplos tokens é mantida. O caminho de visão é real: o texto do cartão descreve o manuseio de imagens, o processador recebe imagens e o checkpoint inclui uma torre de visão e um projetor para atendê-lo — portanto, a tag multimodal no repositório é respaldada por pesos, não apenas por tags.

O panorama da família merece atenção porque molda a forma de ler todo o resto. A InternLM enviou três tamanhos em 40 segundos: 0,8B, depois 2B, depois 4B. As contagens de parâmetros são 852.985.920, 2.213.241.664 e 4.539.265.536. O cartão do modelo 4B traz uma seção extra — um piloto de calibração de distribuição conhecida com 96 casos, com pontuações antes e depois — que o cartão do 0,8B não traz. Essa assimetria não é evidência de um defeito no modelo pequeno; é evidência de que a documentação do modelo pequeno foi escrita com um orçamento menor, que é o tipo de coisa que um lançamento discreto costuma apresentar.

Como o caminho de inferência realmente funciona

O inference.py incluído é o arquivo mais informativo do repositório, porque documenta um contrato em vez de um prompt. A sequência funciona assim:

• Você fornece uma solicitação com estado (a coisa sendo julgada), perguntas (um esquema) e, opcionalmente, imagens.

• As opções de cada pergunta são mapeadas para símbolos de token único — de A a Z, depois minúsculas, depois dígitos, até 62 opções por pergunta.

• O prompt do sistema, o estado, o esquema e um esqueleto JSON completo do assistente são renderizados com um espaço reservado <decision> por campo.

• Uma passagem direta causal é executada. Os logits são lidos na posição imediatamente antes de cada placeholder.

• Uma softmax é calculada apenas sobre os símbolos candidatos permitidos desse campo, a calibração do checkpoint é aplicada, e os símbolos são mapeados de volta para os valores das suas opções originais.

O motor expõe três tipos de pergunta. choice recebe um objeto ordenado que mapeia valores de opção para descrições. score recebe uma lista — que se torna os valores de string "0", "1", "2" e assim por diante — ou um objeto ordenado com chaves de string numéricas finitas, permitindo que o modelo retorne um valor esperado ponderado por probabilidade e não apenas uma categoria. noul é uma decisão binária sem antes de sim. A resposta retorna, por campo, a distribuição de probabilidade calibrada, uma confiança igual à probabilidade máxima entre os candidatos, a decisão argmax com desempate lexical e, para perguntas do tipo score, o valor numérico esperado e uma legenda. Os limites são explícitos: de uma a dezesseis perguntas por requisição, até 62 opções cada, um teto padrão de entrada de 8.192 tokens que é rejeitado em vez de truncado, e um máximo de oito imagens cujos tokens contam para esse teto.

Dois detalhes nessa lista merecem atenção porque determinam se você pode confiar na saída. O primeiro é que nenhuma resposta de referência é inserida no prompt — o modelo está pontuando candidatos sem que lhe tenha sido mostrada a resposta. O segundo é que usage.output_tokens não é uma contagem de tokens de texto; ele conta campos pontuados. Qualquer pessoa que conecte isto a um cálculo de orçamento de tokens existente ficará surpresa com isso, e o card diz isso em vez de deixar para ser descoberto.

A tabela de benchmark, e quanto dela se deve acreditar

Cuidado, leitor, nesta seção: todos os números abaixo são informados pelo fornecedor e não foram reproduzidos. A InternLM selecionou os benchmarks, selecionou os modelos de comparação, executou as avaliações e publicou a tabela. Não há nenhuma execução independente do Intern-Decision-0.8B em qualquer ranking público, e uma busca no Artificial Analysis não retorna absolutamente nada para o modelo. Isso não torna a tabela falsa. Torna-a não auditada, e significa que as colunas são mais úteis para ler a forma do resultado do que o seu nível.

• Jevbench, três divisões — Intern-Decision-0.8B registra 97,92 em Easy, 80,56 em Original e 52,25 em Hard. O Jev da TypeSafe fica em 100,00, 98,61 e 72,07 nas mesmas divisões.

• Decisão Tipada — o 0.8B pontua 77,35 contra os 73,35 do Jev. Esta é a única coluna em que o menor modelo do campo supera o modelo que dá nome ao benchmark.

• ToolACE — 94,52 para o 0,8B contra 91,29 do Jev. ToolACE é um benchmark de chamada de funções, e uma cabeça de decisão que supera o Jev na seleção de ferramentas é a afirmação mais substantiva da tabela.

• AG News — 88,61 contra os 89,57 do Jev. Efetivamente no mesmo nível da fronteira desta categoria na classificação de tópicos em quatro classes.

• WildJailBreak — 64,48 contra os 96,29 do Jev. Este é o colapso. Provavelmente a coluna que mais importa para um modelo que você apontaria para entradas não confiáveis, e aquela em que o 0.8B está mais distante da referência.

• Média — 79,38 para o 0,8B, 84,68 para o seu próprio irmão de 2B, 90,02 para o 4B. A família sobe de forma acentuada, o que é exatamente o que se esperaria e é, por si só, um argumento leve de que a tabela não foi feita de engenharia reversa para adular o carro-chefe.

• Calibração — Brier 0,530 e erro de calibração esperado 0,066 para o 0.8B. O Jev reporta 0,358 e 0,095. Lidos em conjunto, esses dois números revelam um quadro mais claro do que qualquer um deles isoladamente: o 0.8B está melhor calibrado que o Jev no sentido da ECE — suas confianças declaradas acompanham sua acurácia mais de perto — embora seja consideravelmente menos preciso no geral. Esse é um perfil plausível para um modelo pequeno com uma temperatura deliberadamente ajustada, e não é uma combinação lisonjeira de se publicar por acidente.

O conjunto de comparação tem uma propriedade notável: é dominado por modelos de decisão. Jev, Laya, SemIf, Kev e JevK5 aparecem todos; o benchmark da própria tabela é o da TypeSafe. A InternLM escolheu ser medida no território de um concorrente, usando o harness de um concorrente, e depois publicou as colunas em que seu menor modelo perde. É o tipo de decisão que uma equipe toma quando não está planejando uma campanha de marketing em torno do lançamento — o que é consistente com todo o resto sobre como isso foi lançado.

A temperatura de calibração é o número mais interessante

O Intern-Decision-0.8B ajusta uma temperatura padrão de 2,747760550703, por minimização de NLL em 1.728 casos de calibração designados, com 1.693 casos de validação separados. O cartão deixa explícito que os rótulos do conjunto de testes não foram usados para selecioná-la. A transformação aplicada é p = softmax(candidate_logits.float()) seguida de calibrated_p = softmax(log(p) / T).

Isso é calibração de probabilidades de candidatos, não uma temperatura de amostragem, e a distinção não é pedantismo. Como a transformação é aplicada depois do softmax e preserva a ordenação, ela não pode alterar de forma alguma a decisão do argmax. Ela altera a confiança, a probabilidade de sim noul e o valor esperado de uma questão de pontuação — e deixa a decisão principal idêntica. Se o seu fluxo de trabalho lê o rótulo, a temperatura não tem efeito algum. Se o seu fluxo de trabalho lê a probabilidade — aplica-lhe limiares, ordena por ela ou alimenta um cálculo de valor esperado a jusante —, a temperatura é a diferença entre um número que significa algo e um número que não significa nada. Passar temperature=1 retorna a distribuição não calibrada, o que é uma válvula de escape útil para quem quiser aplicar a própria calibração por cima.

A temperatura é ajustada por checkpoint em vez de ser compartilhada. O modelo 4B usa um valor diferente, 1.99241824, e o card orienta que você use o módulo de inferência fornecido com o tamanho que você baixou, para que sua calibração padrão corresponda. Qualquer pessoa que copie um wrapper de inferência de um modelo irmão para outro aplicará silenciosamente a temperatura errada.

Trinta e quatro milissegundos, e um resultado que não deveria ser possível

O InternLM mediu a latência ponta a ponta por consulta em uma única RTX 4090 usando o caminho local do Hugging Face — uma medição real, mas também a configuração de serving mais lenta possível, já que uma implantação em produção usaria um runtime compilado ou com batching. O Jev está listado com média de 109,70 ms e mediana de 106,30 ms, com p95 de 146,70 ms. O Intern-Decision-0.8B fica em 33,98 / 33,44 / 37,50 ms.

O número no qual vale a pena parar é o modelo irmão de 2B: 33,28 ms de média, 33,15 ms de mediana. O 2B é mais rápido que o 0,8B, por uma margem pequena o suficiente para ser ruído, mas não na direção que as contagens de parâmetros preveem. Isso não é um erro na tabela e não se trata realmente dos modelos. Um modelo de decisão faz exatamente uma passagem direta sobre um prompt cujo comprimento é definido pelo estado, pelo esquema e pelas descrições das opções — não por qualquer coisa que o modelo escreva, porque ele não escreve nada. Para prompts nesse regime, o processamento do prompt domina e a contagem de parâmetros é um custo de segunda ordem. A consequência prática é que o motivo habitual para recorrer ao menor checkpoint — você está pagando por token — não se aplica aqui. O verdadeiro motivo para escolher o 0,8B em vez do 2B é o consumo de memória e o fato de que todo o repositório dele cabe em 1,73 GB, não a taxa de transferência.

O que ainda não pode ser

Esta é a parte que um post de lançamento teria respondido e que um repositório não consegue.

Não há data de lançamento declarada, nenhum anúncio e nada nos canais públicos da InternLM descrevendo a família. A URL do GitHub impressa na ficha do modelo não resolve. O Space de demonstração referenciado na ficha não é legível publicamente. Não há uma coleção que reúna os três checkpoints, o que significa que a única forma de encontrar o 2B ou o 4B é consultar a lista de modelos da organização. Não há artigo, então os dados de treinamento, a receita de ajuste, o número de passos de treinamento e o que o "decision tuning" modificou nos pesos não são declarados. Não há avaliação independente, nem replicação de latência por terceiros, e ainda não há nenhuma evidência de que alguém fora da InternLM tenha executado o checkpoint.

Há também duas questões que o cartão levanta sem responder. A primeira é o que a lacuna do WildJailBreak significa na prática: um défice de robustez a recusas dessa dimensão é uma propriedade do ajuste fino, e se isso reflete o modelo base, o objetivo de ajuste de decisão ou o pequeno número de parâmetros não é algo que o repositório lhe diga. A segunda é o que acontece no limite de entrada. Solicitações com mais de 8,192 tokens são rejeitadas em vez de truncadas, o que é o comportamento correto para um modelo de pontuação, mas significa que a janela de contexto prática não é os 262,144 que a configuração anuncia — é aquilo que couber em 8,192 tokens de estado, esquema, opções e patches de imagem. Para documentos longos com esquemas ricos, esse limite chega mais cedo do que o diagrama da arquitetura sugere.

Onde isto se encaixa e como experimentá-lo sem apostar nele

O enquadramento honesto é que o Intern-Decision-0.8B é um checkpoint lançado com alegações não auditadas e nenhuma documentação de apoio. Essa combinação não é motivo para ignorá-lo — um lançamento de pesos Apache-2.0 que você pode baixar e medir em uma tarde é uma situação melhor do que uma API com lista de espera —, mas significa que o ônus da validação é seu. O motor carrega de um diretório local, roda em uma GPU da classe 4090 ou menor, e o card fornece uma requisição de exemplo que você pode colar. Um dia de avaliação com seus próprios casos rotulados lhe dirá mais sobre a coluna WildJailBreak do que a tabela do fornecedor.

Se a camada de decisão é a parte que você está avaliando, o alvo de comparação útil é um serviço hospedado. O Jev 1.13 da TypeSafe é o modelo contra o qual a InternLM fez o benchmark, e ele pode ser chamado hoje por meio de um único endpoint compatível com OpenAI a $0.042 por milhão de tokens de entrada, com a saída cobrada a zero — o mesmo preço que o fornecedor publica, porque a OrcaRouter repassa o preço de tabela do provedor sem markup em vez de adicionar uma margem por cima. Colocar uma cabeça de decisão de 0,8B auto-hospedada e uma API de decisão hospedada na mesma chave, na mesma tarde, é um experimento consideravelmente mais barato do que montar dois contratos separados para responder à mesma pergunta.

O que mudaria este quadro não é um benchmark. É o repositório do GitHub aparecer, ou a InternLM publicar a receita de ajuste, ou uma primeira execução independente do checkpoint chegar a um leaderboard. Até que uma dessas coisas aconteça, a descrição precisa do Intern-Decision-0.8B é limitada e pouco lisonjeira e inteiramente a seu favor: os pesos são reais, o contrato de inferência está documentado melhor do que a maioria dos modelos lançados consegue, e o marketing ainda não começou.