NVIDIA Nemotron Labs Dory 1.0 4B vs Gemma 4 12B: Three Times the Parameters, None of the Same Job

The obvious way to read a comparison between N​VIDIA N​emotron Labs Dory 1.0 4B and G​emma 4 12B is as a size fight — 4B against 12B, small against mid — and that framing wastes the comparison, because the two models do not accept the same inputs, do not hold the same licence posture, and do not get faster in the same way. Dory is a text-only, English-only, looped network whose defining feature is that one download serves several compute budgets. G​emma 4 12B is a multimodal any-to-any model that takes text, images and audio through a single encoder-free stack and returns text. The parameter gap is real, but it is the least informative difference between them. Here is what actually separates the two, including the parts where nobody has run the experiment yet.

What each one is, in one pass

N​VIDIA N​emotron Labs Dory 1.0 4B is a 4B dense model trained by N​VIDIA and published to Hugging Face in four quantisations — BF16, MXFP8, NVFP4 and a Q5_K_M GGUF — under the OpenMDW 1.1 licence. Its card stamps the build "GA (10/16/2026)". It handles text in and text out, English only, at up to 256K tokens of context. The architecture is the point: a 20-layer recurrent block applied a variable number of times between an 8-layer input block and an 8-layer output block, so loop count becomes a serving-time knob rather than a training-time decision. N​VIDIA recommends two loops as the default and four when agentic accuracy matters more. Nothing about the release was announced; the repositories were populated overnight and the vendor has published no accompanying post.

G​emma 4 12B is G​oogle DeepMind's 11.95B dense multimodal model, Apache 2.0, 256K context, 48 layers with hybrid attention and a 1024-token sliding window, and a 262K vocabulary. It is described as encoder-free: image patches and audio waveforms are projected directly into the language model's embedding space rather than through separate vision and audio encoders. Text, image and audio in; text out. Video is handled as sampled frames, with the card capping audio at about 30 seconds and video at about 60 seconds at roughly one frame per second. It supports configurable thinking modes and a native system role, and it has been public and widely downloaded since the middle of 2026.

One clarification worth making before any number appears: Dory ships in four variants and the one whose repository id is most often quoted is the MXFP8 build, but the benchmarks N​VIDIA published were measured on BF16. The MXFP8 checkpoint is a quantisation of the same weights, not a different model.

The benchmark problem: these two have never been run against each other

This is the part a comparison article usually papers over, so it is worth stating flatly. There is no shared harness result for Dory 1.0 4B and G​emma 4 12B. N​VIDIA's benchmark table for Dory compares it against Qwen3.5-4B, Qwen3.5-9B, Gemma 4 26B A4B and Qwen3.6-35B-A3B — it reaches for the 26B G​emma, not the 12B, and it does not include the 12B at all. G​oogle's published figures for the 12B come from a different harness, against a different comparison set, in a document published months earlier and covering a different task mix.

Placing the two cards' numbers side by side produces a table that looks authoritative and means nothing, because a two-point difference between two harnesses is not a two-point difference between two models. So the honest version is this: Dory's own card claims roughly Qwen3.5-9B-class agentic behaviour at four loops while trailing every one of its own comparators on knowledge-heavy benchmarks, and G​emma 4 12B's card claims a multimodal profile with a 256K window and instruction-tuned variants across the G​emma 4 line. Whether either claim survives contact with the other's task set is untested.

Where they genuinely overlap, and where the overlap ends

Four dimensions matter for a real decision, and they point in different directions.

• Modality — G​emma 4 12B takes text, images and audio. Dory 1.0 4B takes text. This is not a benchmark gap that a harness could close; it is a capability one model has and the other does not, and if your workload has a screenshot, a scanned page or a voice clip anywhere in it, the comparison is over.

• Language — Dory is English-only. G​emma 4's line is multilingual, and its 12B card carries multilingual evaluation and speech results including non-English translation benchmarks. A second language anywhere in production rules Dory out.

• Context — both advertise 256K, and this is the one place the specs genuinely match. Dory's card says 262,144 positions are validated in vLLM under the shipped launch command; G​emma 4 12B states 256K with a 1024-token sliding window inside a hybrid attention stack. Published long-context evaluation exists for G​emma; for Dory the only long-context row is N​VIDIA's own, measured with corrected answer keys and an older judge model, which the card discloses.

• Compute behaviour — this is Dory's asymmetric advantage and it has nothing to do with quality. G​emma 4 12B is a conventional dense model: fixed depth, fixed cost per token, scale the hardware or shorten the context to change the bill. Dory's depth is a runtime parameter. Run it at one loop when latency is the constraint and at four when accuracy is, without downloading a second checkpoint. N​VIDIA also ships a last-loop KV-caching mode intended to hold the cache footprint at roughly the one-loop size regardless of loop count, which — if it holds up — removes the standard objection to recurrent architectures. It is the claim in the card most worth an independent check.

• Licence — OpenMDW 1.1 for Dory, Apache 2.0 for G​emma 4 12B. Both permit commercial use. If your legal review treats Apache 2.0 as the path of least resistance, G​emma starts with an advantage that has nothing to do with the weights.

Running them: one is routine, the other is a build

G​emma 4 12B is a standard L​lama-family-shaped download. It is in Transformers format, it runs on the engines you already have, and the quantised builds — the QAT GGUF and w4a16 variants — have been public since shortly after the model itself.

Dory 1.0 4B is not there yet and the card says so plainly. vLLM support sits "under review" in an open pull request; until it merges you install vLLM from that branch with the precompiled-kernel flag and then pass loop-count and KV-cache overrides at serve time. llama.cpp support is in a second open pull request, and N​VIDIA pins a specific commit rather than the moving head, which is the right call for a reference setup but still means building from source. There is no hosted endpoint for Dory anywhere we can verify — from N​VIDIA or from anyone else — and the download counters on all four of its repositories were still at zero when this was written. G​emma 4 12B, by contrast, has been pulled well over a million times in the last month and has an ecosystem of finetunes and quantisations built on it. That maturity gap is, for most teams, larger than any benchmark delta on either card.

Hardware specifics are thin on both sides. N​VIDIA's only published Dory speed figures are quantisation speedups on a DGX Spark — 1.69× and 1.84× for MXFP8 over BF16 depending on the input/output mix, 2.17× and 2.44× for NVFP4 — not throughput numbers. For G​emma 4 12B the corresponding question, VRAM at a given context length, is answerable from a year of community measurement rather than from the card.

Where a router enters the picture, honestly

Neither of these models is something we serve, and saying so is more useful than implying otherwise. N​VIDIA N​emotron Labs Dory 1.0 4B is not on the OrcaRouter catalogue and has no hosted endpoint anywhere; G​emma 4 12B specifically is not on the catalogue either, though its larger siblings google/gemma-4-26b-a4b-it and google/gemma-4-31b-it are.

What that leaves is the practical shape of the decision. If you are choosing between a 4B you have to self-host and a 12B you can rent, the self-hosted side carries a GPU bill and an ops burden that the rented side does not, and the only way to price that honestly is to run both against your own task set. OrcaRouter is useful for the half of that experiment that is hosted: one API key reaches the open-weight Google models we do carry, at provider list price with 0% markup, so the comparison does not require a second contract or a second SDK. Automatic failover covers the window where your own GPU pool is saturated mid-benchmark, and the routing DSL lets a self-hosted call and a hosted one sit behind a single endpoint, so switching sides is a config change rather than a rewrite. None of that tells you which model wins. It removes the excuse for not finding out.

So which one

If your task is text-only, English-only and long-context, and especially if it is agentic — tool calls, multi-step workflows, structured output — Dory 1.0 4B is the more interesting bet and the one whose architecture gives you something the 12B cannot offer: a compute dial. Take the bet with your eyes open about the maturity gap, the two unmerged pull requests, the total absence of independent evaluation, and the fact that its own card places it behind every comparator on GPQA and HLE.

If your task involves an image, a sound, a second language, or a production deadline inside the next month, G​emma 4 12B is the answer and the comparison was never close. It is a larger, more expensive, more capable model with an ecosystem behind it and no build step in front of it.

The thing to watch is not a benchmark number — it is whether the vLLM and llama.cpp pull requests merge. The day Dory loads from a released binary rather than a branch, the self-hosting side of this comparison stops being a project and starts being a config change. Until then, the honest verdict is that one of these models is a product and the other is a repository that appeared overnight, and which one you want depends entirely on whether you are shipping or testing.

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.