NVIDIA Nemotron Labs Dory 1.0 4B Landed on Hugging Face With Four Checkpoints and No Announcement

N​VIDIA N​emotron Labs Dory 1.0 4B is on Hugging Face right now, in four quantisations, and N​VIDIA has not said a word about it. The checkpoint nvidia/N​VIDIA-N​emotron-Labs-Dory1.0-4B-MXFP8 went up with a model card that stamps the build "GA (10/16/2026)"; its three siblings — N​VIDIA-N​emotron-Labs-Dory1.0-4B-BF16, N​VIDIA-N​emotron-Labs-Dory1.0-4B-NVFP4 and N​VIDIA-N​emotron-Labs-Dory1.0-4B-GGUF — were pushed inside the same 36-minute window either side of midnight UTC on 16–17 October 2026. There is no corresponding post on N​VIDIA's developer blog, no entry on the N​emotron research landing page, and no reference to a model called Dory anywhere on either. The card itself is unusually complete — a full benchmark table, serving instructions for two engines, a checksum — but the marketing scaffolding around it, the thing that normally tells you a model exists, is entirely absent.

So it is worth being exact about what that does and does not license you to say. What is knowable: the weights exist, they are downloadable, the licence is stated, the architecture is described in enough detail to reproduce, and the vendor published its own numbers alongside a note that it measured them itself. What is not yet confirmed: whether this is the start of a N​emotron Labs family or a one-off experiment, whether a paper or a blog post is coming, and whether the numbers hold up under anyone else's harness. N​VIDIA has not framed this as a launch, so neither does this piece. It is a reading of a repository that appeared overnight.

What is actually in the repository

The artifacts are four checkpoints and one model card. The card is the substantive document, and it is where nearly everything below comes from.

• Formats — BF16 (W16A16), MXFP8 (W8A16), NVFP4 (W4A16) and a Q5_K_M GGUF export for llama.cpp. The MXFP8 checkpoint is the subject of this piece only because it is the one that carries the canonical repository id; the benchmarks in the card were measured on BF16.

• Size and shape — 4B total parameters, a dense stack rather than a mixture of experts, split into an 8-layer input block, a 20-layer recurrent block and an 8-layer output block.

• Context — up to 256K tokens, with 262,144 positions validated in vLLM under the launch command N​VIDIA ships on the card.

• Licence — OpenMDW 1.1, a permissive, redistributable model licence with the text linked from the card. The card states plainly that the model is "ready for commercial or non-commercial use".

• Language — English only, though pre-training data covers 43 programming languages.

• Training budget — 6 trillion pre-training tokens, of which roughly the first 4.5 trillion were run natively in NVFP4 before the remainder switched to BF16, followed by a 300-billion-token context-extension phase. Data spans 2013 to December 2025. Post-training is a supervised fine-tune on an N​VIDIA-curated set, then multi-environment reinforcement learning with GRPO.

• Repository activity — eight commits on `main` and two contributors at the time of writing, the newest of them a README edit. The first, "Upload Dory 4B MXFP8 checkpoint and tokenizer", is hours old. This is not a repository that has been sitting quietly in public for months and was just noticed; it is one that was populated today.

One detail that the card gets right and most cards do not: it lists the exact byte size and SHA-256 of the GGUF export so you can verify what you downloaded. 3,673,288,864 bytes, with the hash printed in the launch instructions.

The architecture is the whole reason to care

Strip away the benchmark table and the interesting fact about N​VIDIA N​emotron Labs Dory 1.0 4B is that it is not one fixed model. It is a looped, or latent-recurrent, network: the 20-layer recurrent block is applied repeatedly between the input and output blocks, and the input is reinjected at every loop. The same checkpoint therefore behaves differently depending on how many loops you ask for, and you choose that at serving time rather than at training time.

Three consequences follow, all of them from the model card rather than from anyone's testing:

• Elastic inference compute — one weight file serves several compute budgets. Loop count 1 for latency, 2 as the recommended default, 4 when accuracy on agentic tasks matters more than tokens per second. No retraining, no second checkpoint to download and keep in sync.

• Token efficiency — N​VIDIA claims the extra compute per token goes into latent reasoning rather than into a longer visible chain of thought, so higher loop counts can produce fewer output tokens for the same task. The card ships an output-token-factor chart to make that case. That claim has a direct cost consequence, which is the reason it is worth flagging rather than dismissing.

• Memory-efficient looping — this is the one that answers the obvious objection. Standard looping keeps a separate KV cache per loop, so memory grows with every added pass. Dory supports a last-loop KV-caching mode that keeps a single cache per recurrent attention layer and overwrites it each pass, holding the footprint at roughly the one-loop size no matter how many loops you run. N​VIDIA says accuracy with last-loop caching stays close to per-loop caching with nearly unchanged output lengths, and describes that as its own experimental result.

The attention stack is hybrid: interleaved sliding-window and full-attention layers, the same broad pattern the 2026 crop of long-context small models has converged on. None of this is exotic on its own. What is less common is shipping the loop count as a deployment knob on a 4B model with a 256K window.

The benchmark table, read as a vendor table

Every figure here was produced by N​VIDIA under what the card calls "a consistent harness (NeMo Gym / Nemo Evaluator SDK)". No outside party has reproduced any of it, the model is roughly a day old, and the download counters on all four repositories read zero. Treat the numbers as a claim about direction, not as a scoreboard.

The comparison set N​VIDIA chose is revealing in itself: Qwen3.5-4B, Qwen3.5-9B, Gemma 4 26B A4B and Qwen3.6-35B-A3B. Notably, the two 4B-class comparators are from the previous Q​wen generation, and every other comparator is substantially larger. Read across the three loop settings:

• SWE-bench Verified — 50.3 at one loop, 59.5 at two, 61.8 at four, against 54.7 for Qwen3.5-4B, 61.0 for Qwen3.5-9B, 57.40 for Gemma 4 26B A4B and 73.4 for Qwen3.6-35B-A3B.

• Terminal-Bench 2.1 — 12.5 / 18.1 / 22.2 against 15, 24, 35 and 43. This is the row where looping buys the most and where Dory is still furthest behind the field.

• τ³-bench (Banking) — 11.6 / 12.89 / 14.69 against 5.03 for Qwen3.5-4B, 7.22 for Qwen3.5-9B, 13.66 for Gemma 4 26B A4B and 9.54 for Qwen3.6-35B-A3B. Dory leads the 4B and 9B Q​wen models here by a wide margin.

• GDPval-AA-V2 (Elo) — 815 / 946 / 967 against 424, 546, 751.6 and 987. The jump from one loop to two is 131 Elo points, which is the single largest loop-to-loop movement anywhere in the table.

• GPQA Diamond, no tools — 69.19 / 72.41 / 72.16 against 77.71, 80.93, 80.43 and 85.35. Dory loses this one to every comparator, including the 4B Q​wen.

• HLE, text-only, no tools — 8.25 / 10.89 / 10.43 against 11.31, 15.43, 17.79 and 19.18. Same story.

• IFBench — 74.29 / 77.94 / 79 against 53.83, 59, 77.89 and 57.44. Instruction following is Dory's strongest relative result; at four loops it edges the 26B G​emma 4.

• AA-LCR — 63 / 71 / 73 against 64.7, 68.4, 64.6 and 68.5. Long-context retrieval improves markedly with loops and ends up ahead of all four comparators.

• AA-Omniscience (accuracy) — 10.03 / 10.08 / 10.03 against 15.02, 18.05, 21.13 and 19.95. Looping does essentially nothing for stored knowledge, which is the expected result and a useful sanity check on the rest of the table.

The shape of the pattern is what matters. Looping buys the most on agentic and tool-use tasks, the least on encyclopaedic recall, and the second loop is worth far more than the third and fourth everywhere. That is consistent with the card's own recommendation to default to two loops.

Four caveats that sit inside N​VIDIA's own footnotes

This is where the card is more honest than most, and where a reader skimming the table would be misled.

• The AA figures are not Artificial Analysis figures. N​VIDIA's comparison against an AA score index is explicitly labelled "internal estimates computed under a consistent evaluation harness" that "may deviate from official Artificial Analysis (AA) scores". They are a like-for-like internal measurement, not an external ranking.

• The long-context column uses a hybrid setup. For AA-LCR the card says it used corrected answer keys from AA-LCR v1.1 but kept an older judge model rather than the newer one. Mixing a corrected key set with an older judge makes that column comparable to N​VIDIA's other rows and not necessarily comparable to anyone else's.

• Repeat counts are all over the place. SciCode runs eight times, AA-LCR sixteen, AA-Omniscience ten, GDP.pdf five, and HLE, Terminal-Bench 4.0 and the GDPval-AA variants run once. A single run on a benchmark with meaningful variance is a point estimate, not a score.

• One row in the table is marked with a dagger as a reported rather than measured figure — Qwen3.6-35B-A3B's 73.4 on SWE-bench Verified. Which means the largest-looking number on the board is the one N​VIDIA did not run itself.

None of this makes the table wrong. It makes it one lab's internal snapshot, and the honest reading is that Dory looks genuinely competitive with 4B and 9B models from the previous Q​wen generation on agentic tasks while staying behind the 26B and 35B models it is placed beside.

What you can run today, and what you cannot

There is no hosted endpoint for this model that we can verify, from N​VIDIA or anyone else. Dory is weights-only, and the two serving paths in the card both require building from an unmerged pull request:

• vLLM — support is "under review" in pull request 60149. Until it lands in a release you install vLLM from that branch, then serve with overrides that set the loop count and the KV-cache mode. The card notes that the precompiled-kernel environment flag avoids a local CUDA build.

• llama.cpp — support lives in pull request 30306, and the card pins a specific revision rather than the moving PR head, which is the right instinct for a reference setup. The instructions target native ARM64 macOS on Apple Silicon, and the GGUF path expects the Q5_K_M export at the byte size printed above.

Nothing in the card suggests either project has merged, and there is no entry in either engine's release notes to suggest otherwise. If you want to run Dory this week you are building from a PR.

Hardware notes worth keeping: N​VIDIA tested on H100, B200, B300 and DGX Spark, and the only speed numbers published are quantisation speedups on the Spark rather than throughput figures. On that device MXFP8 shows 1.69× and 1.84× over BF16 depending on the input/output length mix, and NVFP4 reaches 2.17× and 2.44×. Recommended sampling is temperature 1.0 with top-p 0.95, and reasoning is always on in the vLLM path.

Why a quiet 4B release is still worth your afternoon

The interesting thing about a model that arrives without a launch is that its claim is checkable in a way a launch claim is not. There is no keynote asserting a category win; there is a card asserting a specific, falsifiable mechanism — that one 4B checkpoint scales its own accuracy with compute at inference time. You can test that on one GPU with the loop-count flag, and the answer is either visible in your own eval or it is not.

That is also the situation a routing layer is built for, and it is worth being precise about what we do here rather than gesturing at it. OrcaRouter does not serve N​VIDIA N​emotron Labs Dory 1.0 4B — the model is not on our catalogue and there is no hosted endpoint for it anywhere we can confirm. What a single key does give you is the other half of the comparison: the hosted models you would benchmark a self-hosted 4B against are reachable through one API at provider list price with 0% markup, so a self-hosted experiment does not need a second contract or a second SDK. Automatic failover covers the window where your own GPU pool is saturated, and the routing DSL lets a self-hosted call sit beside hosted ones behind one endpoint. If you are testing whether elastic depth is worth the operational complexity, at least the control group is one key away.

What would turn this into a real story

Three things, none of them present yet.

First, an announcement. The card is dated 16 October and the repositories were populated overnight; N​VIDIA's developer feed ran a N​emotron post on 15 October that was about a different model entirely. A blog post, a paper or a N​emotron Labs family page could appear at any point, and it would likely carry the training details and the model's intended role that the card leaves implicit.

Second, engine support. Both vLLM and llama.cpp are sitting on unmerged pull requests. The day either merges, "you can run it" stops meaning "you can build it from a branch".

Third, and most valuable, an independent evaluation. The claims most worth reproducing are the ones the vendor highlighted: the SWE-bench and Terminal-Bench movement across loop counts, and the assertion that last-loop KV caching preserves accuracy. Both are testable with published tooling, and neither has been tested by anyone outside N​VIDIA.

The accurate summary today is this: real weights in four formats, a permissive licence, a genuinely unusual architecture, a serving path that exists only as two open pull requests, and a benchmark sheet that is one lab's own harness with the caveats printed in its own footnotes. It is the most interesting 4B model N​VIDIA has published this year and the company has not yet decided to tell anyone about it.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.