Intern-Decision-0.8B Arrived With No Announcement: What InternLM Quietly Put on Hugging Face

The GitHub link on the model card returns 404. The demo Space returns 401. There is no collection, no blog post, no technical report, and no search result anywhere for the string "Intern-Decision" that is not a job listing for an internship — and yet Intern-Decision-0.8B is sitting on Hugging Face right now as a complete, downloadable, Apache-2.0 checkpoint, fine-tuned from Qwen3.5-0.8B, uploaded in the small hours of September 26, 2026 with two larger siblings that appeared in the same three minutes: Intern-Decision-2B and Intern-Decision-4B. InternLM has shipped this way before, and it is why everything below is assembled from the repository itself rather than from a launch post. The distinction matters here more than usual: a repo tells you what exists, and only the vendor can tell you what it is for.

What the repo does say, in detail, is unusual enough to be worth the read. These are not chat models and not small language models in the usual sense. Intern-Decision-0.8B takes a piece of state, a schema of named questions you write in advance, and optionally up to eight images, and returns an answer distribution for every question in one forward pass. It never calls generate(). It never samples. There is no text output to parse, no JSON to repair, no retry loop around a brace that never closed. The narrowness is the entire architecture, and it puts this model in the same small category as TypeSafe's Jev 1.13 and Convai's Laya — a category InternLM evidently benchmarked against on purpose, because Jevbench is TypeSafe's own benchmark and it is the first column of the table.

Here is what is knowable from the checkpoint, what is only claimed by the checkpoint, and what nobody outside InternLM can currently say at all.

What is actually in the repository

The card is short and candid about lineage. Intern-Decision-0.8B is described as "a multimodal structured decision model fine-tuned from Qwen3.5-0.8B" — the Qwen base released on February 28, 2026 — and the repository carries a second licence file, LICENSE-QWEN, alongside the Apache-2.0 terms, which is what a derived model is supposed to do and is a small honesty signal in its own right. Hugging Face's index reports 852,985,920 parameters across three shards: a 1.50 GB language shard, a 176 MB vision shard, and a 25 MB projector. Total repository storage is about 1.73 GB including tokenizer files, which puts the whole thing comfortably on a single consumer GPU or a well-provisioned laptop.

The config reveals an architecture Qwen has been shipping across the 3.5 generation rather than a bespoke decision network. It is a Qwen3_5ForConditionalGeneration with 24 layers arranged in a repeating pattern of three linear-attention layers to one full-attention layer, 1,024 hidden size, 8 attention heads against 2 key-value heads, a head dimension of 256, and a maximum position embedding of 262,144 tokens. A single multi-token-prediction layer is retained. The vision path is a real one: the card's text describes image handling, the processor takes images, and the checkpoint ships a vision tower and projector to serve it — so the multimodal tag on the repo is backed by weights, not just by tags.

The family picture is worth noting because it shapes how to read everything else. InternLM uploaded three sizes in 40 seconds: 0.8B, then 2B, then 4B. Parameter counts are 852,985,920, 2,213,241,664 and 4,539,265,536. The 4B model's card carries an extra section — a 96-case known-distribution calibration pilot with before-and-after scores — that the 0.8B card does not. That asymmetry is not evidence of a defect in the small model; it is evidence that the small model's documentation was written to a shorter budget, which is the kind of thing a quiet release looks like.

How the inference path actually works

The bundled inference.py is the most informative file in the repo, because it documents a contract rather than a prompt. The sequence runs like this:

• You supply a request with state (the thing being judged), questions (a schema), and optionally images.

• Each question's options are mapped to single-token symbols — A through Z, then lowercase, then digits, up to 62 options per question.

• The system prompt, state, schema and a complete assistant JSON skeleton are rendered with one <decision> placeholder per field.

• One causal forward pass runs. Logits are read at the position immediately before each placeholder.

• A softmax is taken over only that field's allowed candidate symbols, the checkpoint's calibration is applied, and symbols are mapped back to your original option values.

The engine exposes three question types. choice takes an ordered object mapping option values to descriptions. score takes a list — which becomes the string values "0", "1", "2" and so on — or an ordered object with finite numeric string keys, letting the model return a probability-weighted expected value and not only a category. noul is a binary decision with no before yes. The response returns, per field, the calibrated probability distribution, a confidence equal to the maximum candidate probability, the argmax decision with lexical tie-breaking, and for score questions the expected numeric value and a legend. Limits are explicit: one to sixteen questions per request, up to 62 options each, a default input ceiling of 8,192 tokens that is rejected rather than truncated, and a maximum of eight images whose tokens count toward that ceiling.

Two details in that list deserve attention because they determine whether you can trust the output. The first is that no gold answers are inserted into the prompt — the model is scoring candidates it has not been shown the answer to. The second is that usage.output_tokens is not a text-token count; it counts scored fields. Anyone who wires this into an existing token-budget calculation will be surprised by that, and the card says so rather than leaving it to be discovered.

The benchmark table, and how much of it to believe

Reader beware on this section: every number below is vendor-reported and unreproduced. InternLM selected the benchmarks, selected the comparison models, ran the evaluations, and published the table. There is no independent run of Intern-Decision-0.8B on any public leaderboard, and a search of Artificial Analysis returns nothing for the model at all. That does not make the table false. It makes it unaudited, and it means the columns are most useful for reading the shape of the result rather than its level.

• Jevbench, three splits — Intern-Decision-0.8B posts 97.92 on Easy, 80.56 on Original and 52.25 on Hard. TypeSafe's Jev sits at 100.00, 98.61 and 72.07 on the same splits.

• Typed Decision — the 0.8B scores 77.35 against Jev's 73.35. This is the one column where the smallest model in the field beats the model the benchmark is named after.

• ToolACE — 94.52 for the 0.8B against 91.29 for Jev. ToolACE is a function-calling benchmark, and a decision head that outperforms Jev on tool selection is the most substantive claim in the table.

• AG News — 88.61 against Jev's 89.57. Effectively level with the frontier of this category on four-way topic classification.

• WildJailBreak — 64.48 against Jev's 96.29. This is the collapse. Arguably the column that matters most for a model you would point at untrusted input, and the one where the 0.8B is furthest from the reference.

• Average — 79.38 for the 0.8B, 84.68 for its own 2B sibling, 90.02 for the 4B. The family climbs steeply, which is exactly what you would expect and is itself a mild argument that the table was not reverse-engineered to flatter the flagship.

• Calibration — Brier 0.530 and expected calibration error 0.066 for the 0.8B. Jev reports 0.358 and 0.095. Read those two together and a clearer picture emerges than either number gives alone: the 0.8B is better calibrated than Jev in the ECE sense — its stated confidences track its accuracy more closely — while being meaningfully less accurate overall. That is a plausible profile for a small model with a deliberately fitted temperature, and it is not a flattering combination to publish by accident.

The comparison set has one conspicuous property: it is dominated by decision models. Jev, Laya, SemIf, Kev and JevK5 all appear; the table's own benchmark is TypeSafe's. InternLM chose to be measured on a competitor's turf, using a competitor's harness, and then published the columns where its smallest model loses. It is the sort of decision a team makes when it is not planning a marketing campaign around the release — which is consistent with everything else about how this shipped.

The calibration temperature is the most interesting number

Intern-Decision-0.8B fits a default temperature of 2.747760550703, by NLL minimisation over 1,728 designated calibration cases with 1,693 separate validation cases. The card is explicit that test-suite labels were not used to select it. The applied transform is p = softmax(candidate_logits.float()) followed by calibrated_p = softmax(log(p) / T).

That is candidate probability calibration, not a sampling temperature, and the distinction is not pedantry. Because the transform is applied after the softmax and preserves ordering, it cannot change the argmax decision at all. It moves confidence, the noul yes-probability, and the expected value of a score question — and leaves the headline decision identical. If your workflow reads the label, the temperature is a no-op. If your workflow reads the probability — thresholds it, ranks by it, or feeds it into a downstream expected-value calculation — the temperature is the difference between a number that means something and a number that does not. Passing temperature=1 returns the uncalibrated distribution, which is a useful escape hatch for anyone who wants to apply their own calibration on top.

The temperature is fitted per checkpoint rather than shared. The 4B model uses a different value, 1.99241824, and the card instructs you to use the inference module shipped with the size you downloaded so that its default calibration matches. Anyone who copies an inference wrapper from one sibling to another will silently apply the wrong temperature.

Thirty-four milliseconds, and a result that should not be possible

InternLM measured per-query end-to-end latency on a single RTX 4090 using the local Hugging Face path — a real measurement, but also the slowest possible serving configuration, since a production deployment would use a compiled or batching runtime. Jev is listed at 109.70 ms mean and 106.30 ms median with a p95 of 146.70 ms. Intern-Decision-0.8B comes in at 33.98 / 33.44 / 37.50 ms.

The number worth stopping on is the 2B sibling: 33.28 ms mean, 33.15 ms median. The 2B is faster than the 0.8B, by a margin small enough to be noise but not in the direction the parameter counts predict. That is not an error in the table and it is not really about the models. A decision model does exactly one forward pass over a prompt whose length is set by the state, schema and option descriptions — not by anything the model writes, because it writes nothing. For prompts in that regime, prompt processing dominates and parameter count is a second-order cost. The practical consequence is that the usual reason to reach for the smallest checkpoint — you are paying per token — does not apply here. The real reason to choose the 0.8B over the 2B is memory footprint and the fact that its whole repository fits in 1.73 GB, not throughput.

What cannot be established yet

This is the part a launch post would have answered and a repository cannot.

There is no stated release date, no announcement, and nothing on InternLM's public channels describing the family. The GitHub URL printed on the model card does not resolve. The demo Space referenced in the card is not publicly readable. There is no collection gathering the three checkpoints, which means the only way to find the 2B or the 4B is to look at the org's model list. There is no paper, so the training data, the tuning recipe, the number of training steps, and what "decision tuning" modified in the weights are all unstated. There is no independent evaluation, no third-party latency replication, and no evidence yet that anyone outside InternLM has run the checkpoint.

There are also two questions the card raises without answering. The first is what the WildJailBreak gap means in practice: a refusal-robustness deficit of that size is a property of the fine-tune, and whether it reflects the base model, the decision-tuning objective, or the small parameter count is not something the repository tells you. The second is what happens at the input ceiling. Requests beyond 8,192 tokens are rejected rather than truncated, which is the right behaviour for a scoring model, but it means the practical context window is not the 262,144 the config advertises — it is whatever fits in 8,192 tokens of state, schema, options and image patches. For long documents with rich schemas, that ceiling arrives sooner than the architecture diagram suggests.

Where this sits, and how to try it without betting on it

The honest framing is that Intern-Decision-0.8B is a released checkpoint with unaudited claims and no supporting documentation. That combination is not a reason to ignore it — an Apache-2.0 weights release you can download and measure in an afternoon is a better situation than a waitlisted API — but it does mean the burden of validation is on you. The engine loads from a local directory, runs on a 4090-class GPU or smaller, and the card provides a worked request you can paste in. A day of evaluation against your own labelled cases will tell you more about the WildJailBreak column than the vendor table can.

If the decision layer is the part you are evaluating, the useful comparison target is a hosted one. TypeSafe's Jev 1.13 is the model InternLM benchmarked against, and it is callable today through a single OpenAI-compatible endpoint at $0.042 per million input tokens with output billed at zero — the same price the vendor publishes, because OrcaRouter passes provider list price through with no markup rather than adding a margin on top. Putting a self-hosted 0.8B decision head and a hosted decision API on the same key, in the same afternoon, is a considerably cheaper experiment than wiring up two separate contracts to answer the same question.

What would change this picture is not a benchmark. It is the GitHub repository appearing, or InternLM publishing the tuning recipe, or a first independent run of the checkpoint landing on a leaderboard. Until one of those happens, the accurate description of Intern-Decision-0.8B is narrow and unflattering and entirely in its favour: the weights are real, the inference contract is documented better than most launched models manage, and the marketing has not started.