Treat the label as a design goal and measure the model on your own device.
Summary
NVIDIA released Nemotron 3.5 Bolt E4B 4GB, a Q4_K_M-quantized model post-trained from Google's Gemma 4 E4B-it for multi-turn tool use, instruction following and input grounding. It ships under OpenMDW-1.1 with a technical report, a BF16 checkpoint and DFlash drafters for speculative decoding. It is on Hugging Face, NVIDIA NIM and Ollama. The "4GB" in the name is hard to square with the published specs: Ollama lists a 7.2–7.9 GB download, and every speed and quality number comes from NVIDIA testing on one high-end GPU.
What happened
According to the Hugging Face model card, Bolt E4B has 8B total parameters and 4B effective. It supports up to 64K input and 64K output tokens, takes text in and puts text out, and has chat-template switches for thinking and conversational modes. NVIDIA aims it at local voice and device assistants, interactive personas and embedded interfaces. The technical report says the target memory footprint is "about 4 GB."
NVIDIA's own RTX 5090 measurements for the Q4_K_M build show a 285 ms time to first token and a 70.2 "representative benchmark average." With the DFlash drafter, a GGUF companion model for speculative decoding in llama.cpp, NVIDIA reports 2.74x per-user decode speed over non-speculative inference at concurrency one. The card gives llama.cpp launch commands but says a full llama.cpp recipe is still pending. NVIDIA's research page describes the RL blend: a 2:1 ratio of non-reasoning to reasoning samples, and group-relative length penalties added after reasoning traces and answers grew longer during training.
Ollama is a third party, so its listing is an independent check on packaging, though not on quality. It lists nemotron-3.5-bolt:e4b as a 7.2–7.9 GB download with text and image input and a 128K context window. It also says usable context depends on available memory, because images, history, tool results and output share the same budget. It gives no fixed memory requirement and no benchmarks.
In the same cycle NVIDIA opened gated early access to FOX, a harness for factory manager agents built on Cosmos and Nemotron models. The announcement gives no list of model versions.
What the archive adds
The archive gives some background, and it should be read carefully. NVIDIA's local-AI blog (d2) maps where local agents are meant to run: RTX PCs for personal compute, Jetson for edge and robotics, and DGX Spark for compact, always-on inference. A model that really fits in 4 GB would serve the small end of that map, which is why the label matters. NVIDIA's earlier Nemotron 3.5 Super VL (d3) is a different kind of release. According to NVIDIA it was co-built with partners (Mistral, Black Forest Labs, H-Company), whereas Bolt post-trains a released Google checkpoint. So Super VL shows only that Nemotron is not always built from NVIDIA-pretrained weights from scratch. It does not show a pattern of post-training other labs' models. NVIDIA's Super VL technical blog (d1) shows the company habitually pairs its models with serving tools and reports vendor-run speed gains, in that case for Dynamo. Bolt's DFlash numbers follow the same habit of vendor-measured speedups.
Trend signal
Small-model launches are more and more marketed with one headline resource number: a parameter count, an "effective" count, or a gigabyte figure. Each of these measures something different. Gemma's E-series "effective parameters" already separate the parameters that do compute from the parameters that have to be stored, which is why Bolt reads "8B total, 4B effective." Adding a gigabyte figure to the product name stacks a third abstraction on top. The practical problem is that the number in the name is the one deployment teams copy into hardware specs, and for local agents memory is the binding constraint. NVIDIA is also tuning for "intelligence per GB" in its own words. That is the right goal, but it makes how the GB is counted the most important detail on the card.
Why now
1) NVIDIA is pushing local agents across RTX, Jetson and DGX Spark (d2). That gives it a reason to brand a model by the memory it fits in. 2) Gemma 4 E4B-it already supplied a capable small base, so NVIDIA put its effort into RL post-training for tool use and grounding (primary evidence; technical report). 3) NVIDIA frames the work as optimizing "intelligence per GB," which pulls the gigabyte figure into the product name (technical report abstract). 4) NVIDIA habitually publishes vendor-measured speedups alongside its serving tools (d1). That pattern is repeated here with DFlash on an RTX 5090.
Connections to other events
Here is a check of the headline numbers against what each one measures.
The weights. 8B total parameters at Q4_K_M, which averages a little under 5 bits per weight in llama.cpp's scheme, comes to roughly 4.5–5 GB for the weights alone. That is our arithmetic, not a published figure. It already exceeds 4 GB before any KV cache. Ollama's 7.2–7.9 GB download is larger again, which suggests that tag bundles more than the text-only Q4_K_M file, perhaps vision components or different quantization. Our read is that "4GB" most likely refers to a runtime target that counts only part of the weights, such as the 4B effective set with embeddings handled separately. The card does not state how the figure is counted.
The context. The card allows 64K in and 64K out, and Ollama lists 128K. KV cache grows with context, and Ollama itself warns that history, tool results and images share the memory budget. A multi-turn tool-using agent is exactly the workload that fills context. So even if the weights fit a 4 GB envelope, a long agent session will not.
The speed. 285 ms TTFT and the 2.74x DFlash gain were measured on an RTX 5090, a 32 GB card, at concurrency one. Those numbers are real for that setup. They say nothing about a 4–8 GB laptop GPU, a Jetson or Apple Silicon, which are the devices the "4GB" label is meant to attract. Speculative decoding also needs the drafter in memory next to the main model, and that adds to the footprint.
The quality. 70.2 is NVIDIA's "representative average" against baselines NVIDIA chose. It ranks Bolt inside NVIDIA's own table and nowhere else yet.
None of this makes the release weak. The RL recipe and the dataset list are published, which is more transparency than usual. But each headline number is true only under a stated condition, and the name drops those conditions.
Why it matters
If you are a builder targeting real 4 GB devices, size your plans from your own peak-memory measurement at the context length you actually use, not from the model name. Start from the Ollama figure (7.2–7.9 GB) as a pessimistic bound and the "about 4 GB" target as an optimistic one. If you already run Gemma 4 E4B-it, the comparison is cheap. Same base, so the question is only whether NVIDIA's RL improves your tool-call traces enough to justify a new dependency. Teams evaluating FOX should ask NVIDIA directly which models and memory profiles it supports, because the announcement names none. Buyers specifying edge hardware should insist that vendors quote memory at a stated context length and concurrency.
What happens next
- NVIDIA publishes the pending llama.cpp recipe on the Bolt E4B model card. (3 months, 65%). Watch for: The Hugging Face card's 'recipe pending' note is replaced by a linked recipe or documentation page.
- NVIDIA updates the Bolt E4B card or report to state explicitly how the 4 GB figure is counted (context length, embeddings, drafter included or not). (6 months, 30%). Watch for: A model card revision adding a memory table with context length and component breakdown.
- FOX reaches general availability with a Nemotron 3.5 Bolt model named among supported models. (12 months, 25%). Watch for: An NVIDIA GA announcement or FOX documentation page that lists Bolt by name.
Limits and uncertainty
We have not loaded the model ourselves. The weight-size arithmetic is an estimate from the standard Q4_K_M bit rate, not a measurement. Exact per-file GGUF sizes we could not trace to sources in our pack are left out. NVIDIA may count "4GB" in a defensible way, for example by excluding offloadable per-layer embeddings, and simply not say so on the card. If so, the label is under-documented rather than wrong. The Ollama tag may bundle different components than the Hugging Face Q4_K_M file, so the two sizes may not be directly comparable. Ollama is independent on packaging but runs no benchmarks. All quality and latency numbers remain NVIDIA-run. FOX's link to Bolt is not stated anywhere.
Skill to build now
The skill: profiling memory for a local model at realistic context lengths. Exercise: pick one quantized model you already ship. Run it in llama.cpp or Ollama at 4K, 16K and 32K context, and replay a real multi-turn tool-calling session at each length. Log peak resident memory, TTFT and tokens per second. Repeat with Bolt E4B, plus its DFlash drafter if your runtime supports it. You end up with a memory-versus-context curve to put in your hardware spec, in place of the number in the model's name.
Reader takeaway
Before you put Bolt E4B into a device spec, run ollama run nemotron-3.5-bolt:e4b, or the llama.cpp commands on the card, on your target hardware. Record peak resident memory at 4K, 16K and 32K context, with and without the DFlash drafter. If peak memory at your real agent context is above your device's budget, the "4GB" label does not apply to your use case. Then compare Bolt against Gemma 4 E4B-it at the same quantization.
Open question
If memory-branded model names spread, should the industry settle on a standard way to count them (weights only, weights plus KV cache at a stated context, or peak resident memory under a reference workload), and who would enforce it: runtimes like Ollama and llama.cpp, or the model vendors?