Open Model WeightsNVIDIA · FIELD VERIFIED
Primary sources last checked on 18 Oct 2026. Verification freshness is tracked separately from factual change, and unknown values remain explicit rather than inferred.
FRESHNESS & VERIFICATION
A verification check does not pretend the model changed. Open Model Weights updates the verification date after a real primary-source check, while factual-update dates move only when retained source evidence changes.
CONFLICT INTELLIGENCE
+ Save to my shortlistMonitor changes →Local browser monitoring · no background email alerts
DIRECT ANSWER · FEATURED MODEL BRIEFING
Source-grounded editorial layer · reviewed 2026-10-18
Nemotron Labs Dory 1.0 GGUF Q5_K_M is a publisher-released open-weight checkpoint in the Nemotron Labs Dory 1.0 family. This GGUF Q5_K_M export provides an alternative model file format, but the 256K BF16 reference context and runtime loop support cannot be assumed for an unverified GGUF configuration. OMW verified its exact publisher repository revision, 1 recognized weight artifacts, openmdw-1.1 license evidence and no independently confirmed numeric context in this checkpoint on 18 October 2026. This source-based review does not represent an independent model inference, speed or quality benchmark.
WHY IT MATTERS
A 4B-class checkpoint with configurable latent recurrent loops is an unusually clear research target for measuring inference-time compute against latency and output quality.
Four official formats allow controlled portability experiments; the GGUF export in particular must not inherit unverified BF16 context or engine assumptions.
MODEL-SELECTION VIEW
The Q5_K_M GGUF export is intended for a compatible llama.cpp path. A GGUF extension alone does not guarantee recurrent-loop support in an arbitrary build, and OMW does not have a separately verified numeric context field for this export.
The checked GGUF repository lists 1 recognized weight file(s). Pin its official SHA, document hardware and runtime versions, then evaluate latency, output fidelity, loop options and cache behavior rather than generalizing from BF16.
NVIDIA's Dory 4B model card documents a recurrent neural computation block that can run multiple times before generating an output token. Changing loop count adjusts internal computation without downloading an entirely new checkpoint.
Publisher documentation mentions one, two and four recurrent loops. OMW does not treat these settings as distinct model weights or as guaranteed accuracy improvements; performance and speed must be measured for chosen tasks.
Dory's documentation describes keeping cache states from individual loops and an alternative last-loop cache strategy. The latter is designed to constrain the incremental cache cost of repeated computation.
Whether the scheme helps an application depends on exact input length, cache implementation, attention pattern and batch size. Benchmark peak memory and responses under both modes without mixing multiple runtime versions.
NVIDIA publishes BF16, MXFP8, NVFP4 and GGUF Q5_K_M representations of its Dory architecture. These are different storage and inference paths, not sequential generations claiming independently proven reasoning improvements.
Start from the BF16 behavior as a source reference, then check which loop options and attention kernels each other format can run. Different quantization methods can change output fidelity and compatibility, so file format must not stand in for an actual test.
The official BF16 model card discusses a 256K context configuration. OMW records a 262,144-token config for applicable Safetensors checkpoints, but a separately exported GGUF does not automatically have the same verifiable metadata.
The card links model-specific vLLM support work rather than proving universal readiness in all stable versions. An accurate deployment report must name the exact runner, revision, loop setting, attention implementation, caching policy and successful test case.
Measure the same fixed tasks under one, two and four loops; keep temperature, input examples and output criteria constant and capture total latency, number of generated tokens and task pass rate. Then repeat the experiment with documented cache modes.
Our editorial position is that adaptive internal compute is interesting only when better task performance justifies added latency and memory. NVIDIA's charts motivate these tests, but no independent OMW Dory benchmark is claimed.
IMPLEMENTATION & EVALUATION
Reproduction checklist for Nemotron Labs Dory 1.0 GGUF Q5_K_M, not an OMW inference run. Keep the exact GGUF checkpoint, tokenizer, media processing, tool harness, software revision and hardware in the report.
Record the official repository SHA, artifact manifest and applicable weight-specific license before benchmarking.
Save a reproducible revision and artifact checksum list together with the exact license source and date.
Model branches may change, and third-party conversions or processors can alter the tested input without notice.
Reproduce the model-card tokenizer, multimodal preprocessing, serving code, precision and tool-call format.
Run at least one positive and one failure-mode task with pinned environment and exact model implementation, or record incompatibility.
Declared library tags do not prove a given package version supports this architecture or compressed format.
Use representative prompt lengths, media dimensions and tool interactions while instrumenting actual memory, latency and correctness.
Retain raw input/output pairs, peak memory, prefill/decode latency, error logs and infrastructure specification.
A configured context limit, weight-only arithmetic or publisher chart is not an independent memory or throughput benchmark.
Run the same acceptance set on a source-linked alternative with aligned prompt budgets and evaluation rules.
Publish both revision IDs, model formats, test harness, pass/fail criteria, observed variance and unsupported cases.
Different engines, sampling strategies, modal input processing and agent permissions confound naive rankings.
Proposed tests, not OMW benchmark results. Read the official model card at the pinned source revision ↗ Inspect OMW field evidence ↗
PRIMARY & INDEPENDENT SOURCES
FAQ
Not in OMW's separate GGUF source record. NVIDIA documents 256K for the BF16 reference, which must not silently be asserted for every GGUF runtime.
Dory uses a shared recurrent computation block that can run multiple times per generated token, allowing an adjustable internal compute budget.
No universal gain is established. More internal computation may improve some publisher-tested tasks but also increases latency; reproduce results on a fixed workload.
Official NVIDIA repositories provide BF16, MXFP8, NVFP4 and a GGUF Q5_K_M export. Each requires a compatible inference path.
The publisher documents 256K for its BF16 reference. OMW records each artifact's verified config separately; do not transfer this claim to GGUF without evidence.
The NVIDIA model card references Dory-specific vLLM implementation work. Check the exact merged software version, kernel and loop flags before assuming compatibility.
NVIDIA documents last-loop caching as a strategy to retain a final recurrent-block cache rather than independent cache copies for all loops; this is runtime-dependent.
Its official model repositories declare NVIDIA's OpenMDW v1.1 terms, which are not the same as permissive MIT or Apache-2.0.
MODEL INTELLIGENCE · SOURCE-FIRST
Open Model Weights records Nemotron Labs Dory 1.0 GGUF Q5_K_M as a 4B (publisher-declared)-parameter text → text open-weight model in the Nemotron Labs Dory 1.0 family, with NVIDIA listed as the developer. The checked source repository provides 1 recognized weight artifacts, format evidence for GGUF and a context window that is not declared in the checked standard sources. Values that are not evidenced in the checked sources remain explicitly undisclosed or unknown.
The repository declares NVIDIA OpenMDW License Agreement v1.1. Commercial and non-commercial use declared by NVIDIA; applicable OpenMDW-1.1 model terms still govern. Open Model Weights reports the checked license evidence and classification; this is not legal advice.
No base model is declared in the checked standard lineage metadata, so Open Model Weights does not infer one. Training recipe status: training-described-in-model-card; data disclosure status: dataset-metadata-declared.
DEPLOYMENT PROFILE
These bars visualize weight-only decimal-GB estimates. They exclude KV cache, activations, runtime overhead, optimizer state and sharding.
LICENSE & USE
Commercial and non-commercial use declared by NVIDIA; applicable OpenMDW-1.1 model terms still govern
This section summarizes the checked repository evidence. It is not legal advice.
LINEAGE & PROVENANCE
Open Model Weights does not infer a hidden base model or training corpus when the checked sources do not declare one.
RUNTIME SIGNALS
Declared and model-card-mentioned runtimes are discovery signals. They are not treated as Open Model Weights runtime tests unless explicitly measured.
EVIDENCE TRAIL
This is where the article remains auditable: source links on one side, the registry's observed change history on the other.
Checked Hugging Face API metadata, exact repository file list, model card and config when accessible.
01 · WEIGHTS
02 · LICENSE
Classification describes the checked license terms; it is not legal advice.
03 · HARDWARE
Weight-only decimal-GB estimate from total parameter count; excludes KV cache, activations, runtime overhead, optimizer state and sharding.
04 · FORMATS
“Not observed” means no matching repository artifact/name/dtype signal was found; it does not prove no third-party conversion exists.
05 · LINEAGE
06 · TRAINING ASSETS
07 · RUNTIME SUPPORT
Open Model Weights separates model-repository evidence from external runtime-release evidence. An external support statement does not change the official model repository's weight formats and does not imply an Open Model Weights inference benchmark.
08 · SOURCES
09 · VERIFICATION HISTORY
Checked Hugging Face API metadata, exact repository file list, model card and config when accessible.