Intern-Decision: one forward pass, many typed answers, and calibrated probabilities

One JSON skeleton for a state, images, and typed questions

Intern-Decision takes a state, optional images and a set of typed questions, and returns a decision per question together with a probability. The project describes itself as a fast multi-modal decision model, though the scope is narrower than that phrase suggests. It answers three kinds of question: `choice`, where options are offered, `score`, where a graded value is expected, and `noul`, the yes/no case spelled out in the readme. The model fine-tunes the language backbone of Qwen3.5 while freezing the vision tower and the projector, so the visual side is inherited rather than learned. That split has a practical consequence for upgrades: a change in the backbone changes text behaviour, while the frozen tower keeps emitting the same visual features. The output is a probability distribution rather than a hard label, and most of the repository exists to make those probabilities measurable.

The logit before each decision marker carries the answer

The training objective is autoregressive masked language modeling, and the mechanism is worth reading closely. The assistant input is a complete JSON skeleton with one `<decision>` token per field. Ground truth answer symbols appear only in the labels, never in the input, so a model cannot read the answer out of its own prompt. Training uses ordinary causal next-token alignment: the logit immediately before a marker predicts that field's answer, and all fields share one causal forward pass. That last point is why the reported latency looks good, since three fields come out of a single pass rather than three sequential generations. At inference time the logits are restricted to the legal single-token answer symbols, softmax is applied, and the result is mapped back to the original labels. Training cross-entropy, by contrast, uses the full vocabulary. One constraint is easy to miss: question and option ordering must be preserved, so any reordering in your own pipeline changes the label mapping the model was trained against.

No install command, three requirement files

The readme gives no install command and names no package index entry. What it points to is a Hugging Face collection holding the model weights and a demo space, both linked from the top of the file. The repository root is where the environment story lives: requirements-inference.txt, requirements-eval.txt and requirements-xtuner.txt split the three jobs of running inference, scoring benchmarks and fine-tuning. The pyproject.toml configures linting and nothing else, which tells you a hand-built environment is expected rather than a wheel:

[tool.ruff]
line-length = 120
target-version = "py310"

[tool.ruff.lint]
select = ["E", "F", "I", "UP"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"
indent-style = "space"

The target-version setting points at Python 3.10, and that is the only interpreter hint given. For a first real use, the practical path is to pull the weights from the linked collection, build an environment from requirements-inference.txt, and read docs/DATA.md for the runtime schema before writing any adapter of your own.

Seven suites and a 90.02 percent average

Intern-Decision-4B reaches 90.02% average accuracy across the seven displayed suites, and the readme defines that average as the unweighted mean. Jev is the strongest of the five external baselines at 88.74%, while Laya, SemIf, Kev and JevK5 range from 57.77% to 85.16%. The seven suites contain 10,751 rows and 12,351 decisions in total, with per-suite denominators listed under the evaluation section. The spread across suites matters more than the mean. The 4B model reaches 73.87% on the Hard suite, 80.55% on Typed Decision and 90.82% on AG News, so the distance between the easiest and hardest suite is wide inside a single model. One caveat applies to the calibration columns: baselines use their reported or default probabilities with no extra temperature fitted, while the Intern-Decision rows use fitted temperatures, so those columns compare setups that are not identical. docs/EVALUATION.md is the reproduction guide for the whole table.

Fitting temperature on a 96-case calibration pilot

The calibration work is the part of the project that decides whether the probabilities are worth having. A bundled 96-case benchmark lives under benchmarks/known-distribution-pilot-v1 and is described as a small calibration pilot with six categories, 24 families and 48 paired settings. The questions ask for random outcomes, and the exact reference distributions are stored separately from the model inputs, so a model never sees the answer it is graded against. The readme is explicit that this benchmark is evaluation-only: do not fit temperatures on it and do not train on its references. That rule is narrow but honest, and it also caps how much you can read into the numbers. On the pilot, the 4B model reports 0.550 Brier and 0.089 ECE, against 0.595 and 0.130 for Jev, and all three settings give 96/96 valid predictions with 16 cases per category. Temperature presets ship per checkpoint: 1.992418 for the 4B model, 2.100509 for 2B and 2.747761 for 0.8B.

Latency scales with the checkpoint, not the field count

The latency figures come from a single NVIDIA RTX 4090 running BF16 with SDPA, native Hugging Face inference, Transformers 5.14.1 and flash-linear-attention 0.4.2. Each request carries 289 input tokens and three fields, one choice, one yes/no and one score, answered in one forward pass with the checkpoint-specific temperature applied. The 0.8B and 2B checkpoints sit at 33.98 ms and 33.28 ms mean, while the 4B checkpoint lands at 44.16 ms mean with a P95 of 44.60 ms. The tight spread between median and P95 on the Intern-Decision rows contrasts with the 109.70 ms mean of the Jev baseline, whose P95 reaches 146.70 ms. The engineering consequence is that the gap between the 2B and 4B checkpoints is roughly eleven milliseconds, small enough that the accuracy difference usually decides the choice before latency does.

Apache-2.0, no releases, and a last push on 2026-09-29

Intern-Decision is released under Apache-2.0, and the LICENSE file sits at the repository root. That is a permissive grant covering both the code and the weights, though the licence file itself says nothing about how the model should be used. The repository is not archived and the last push was on 2026-09-29, so the code itself is recent. There are no GitHub releases, which means there is no tagged version to pin against and no changelog to read when something changes, so an upgrade is a git pull plus whatever your own requirements files have drifted toward. Several pieces a production user would expect are absent by design: training data, private calibration and validation records, images, the preparation pipelines, and the model weights. The readme also notes that demo examples are synthetic interface illustrations, and that the runtime schema, tokenization and collation support your own records.

Editorial conclusion

Intern-Decision suits engineers who need a probability next to every answer, especially for typed questions where one wrong choice is expensive, and who can build their own environment and supply their own records. It does not suit anyone who wants weights and training data inside the repository, or a tagged release to pin against, because the weights live on Hugging Face and the repository ships no GitHub releases. Before adopting it, check three things in order: that the seven suite protocols in docs/EVALUATION.md resemble your own task mix, that 96 cases are enough to trust the fitted temperature preset for your task, and that your data pipeline preserves question and option ordering exactly as the model expects.

Frequently asked questions

Official sources

1. InternLM/Intern-Decision on GitHub
2. Issues
3. License: Apache-2.0
4. README