Model Card: NVIDIA Nemotron Labs Dory 1.0

🌏 中文版

Model Info

Capability Highlights

• Elastic Inference Compute: a single checkpoint can trade accuracy for compute by changing how many times the shared recurrent block is applied (1/2/4 loops), with no retraining or model swap required
• Token Efficiency: extra compute goes into "thinking" in latent space across loops rather than into longer generated output; higher loop counts need fewer output tokens to solve the same task
• Last-Loop KV Caching: instead of storing a separate KV cache per loop, Dory keeps only the final loop's cache, so KV-cache overhead stays fixed at single-loop size regardless of loop count
• Native NVFP4 Pretraining: of the 6 trillion pretraining tokens, roughly the first 4.5 trillion were trained natively in NVIDIA's own 4-bit floating-point format NVFP4, before continuing in BF16 — an uncommon "native low-precision pretraining" approach

Benchmark Results

⚠️ All numbers above are NVIDIA's own measurements under a consistent harness (NeMo Gym / NeMo Evaluator SDK); none have been independently replicated yet. † The 4-loop SWE-bench Verified score is separately flagged on the official model card as a "reported score," measured differently from the other numbers, so it carries lower confidence. IFBench is the only metric in the table that drops as loop count increases — down to 57.44 at 4 loops, below even the 1-loop score of 74.29.

Versus Prior Generation / Competitors

Dory 1.0 is Nemotron Labs' first public model, so there's no prior generation to compare against. Against similarly sized models: at 2 loops, Dory roughly matches or exceeds dense models Qwen3.5-4B/Qwen3.5-9B on SWE-bench Verified (57.4%) and GPQA Diamond (80.43%), but on Terminal-Bench 2.1 (an agentic task) it only barely catches up to Qwen3.6-35B-A3B's score (43) even at 4 loops — still trailing much larger models overall.

Dory's real pitch isn't winning benchmark scores — it's that the same set of weights is adjustable at inference time. Normally, trading speed for accuracy means deploying a different (smaller or larger) checkpoint; with Dory you just change the n_recurrent_loops parameter. But IFBench's drop as loop count rises shows this knob isn't "more is always better" — instruction-following and reasoning/coding tasks may respond to loop count in opposite directions, so it needs per-task tuning rather than cranking it to the max by default.

Implications for Agent Development

Dory's significance is more about "a new inference-time knob in the architecture" than "a new leaderboard score":

• If you're building an agent router that dynamically sizes compute to query complexity: loop count is a compute/accuracy trade-off you can adjust without swapping models or retraining — conceptually similar to a reasoning budget, but it operates at the model-architecture level rather than the output-token level. In theory, a single 4B checkpoint could serve both "fast, simple queries" and "tasks needing deeper reasoning"
• If you're building edge or single-GPU agents: 4B parameters + 256K context + native NVFP4 quantization + last-loop KV caching keeps the memory footprint for long-context serving manageable — worth a proof of concept in resource-constrained environments
• Not yet production-ready: vLLM support is still under PR review (vllm-project/vllm#60149), and llama.cpp support hasn't landed in a release either (ggml-org/llama.cpp#30306) — both require building from development branches. And the IFBench counter-example is a reminder not to assume "more loops = better"; you need to benchmark different loop counts against your own task distribution before shipping

Today's Takeaway

Most "model efficiency" narratives I've seen boil down to either "pack more capability into the same parameter count" or "quantize to trade accuracy for speed." Dory 1.0 offers a third path: turn "recurrence depth" into a knob you can still adjust after deployment. The same weights, with a shared block applied repeatedly, let you decide at inference time how much compute to spend for how much accuracy — instead of that trade-off being locked in at training time. But IFBench dropping instead of rising with more loops is also a reminder that "architecturally adjustable" doesn't mean "turning it up is always better" — this kind of elastic knob still needs per-task-type validation, and assuming a single-direction scaling law is a trap.

References

• NVIDIA-Nemotron-Labs-Dory1.0-4B-BF16 (Hugging Face model card)
• NVIDIA's official Nemotron product page (Dory not listed, supporting the "quiet release" characterization)
• explainx.ai: NVIDIA Dory 4B: A Looped Model You Can Dial Up at Inference
• AICoder: NVIDIA quietly releases Dory1.0-4B, a looped model with adjustable inference depth