Summary
Ollama now lists NVIDIA Nemotron 3.5 Bolt E4B as nemotron-3.5-bolt:e4b. It has 8B total parameters and 4B effective, and NVIDIA post-trained it from Gemma 4 E4B for multi-turn tool use, instruction following and grounding. NVIDIA also published a technical report, a Q4_K_M GGUF aimed at about 4 GB, a BF16 checkpoint, DFlash speculative-decoding drafters and a NIM endpoint. The report's headline goal is speed and intelligence per GB of memory. Our read is that this is a latency-and-footprint product first and a capability upgrade second.
What happened
Ollama's library page gives a one-line local command and API examples. It describes Bolt E4B as 8B total and 4B effective parameters, with text and image input, a 128K context window, a 7.2–7.9 GB download, support on Windows, Linux and Apple Silicon, and a DFlash draft model for speculative decoding. The page warns that usable context depends on memory, and that images, history, tool results and output all share one budget. A larger Bolt 74B-A9B variant (9B active per token, 256K context) is also listed, but it does not currently support Apple Silicon or Metal. The license is OpenMDW-1.1.
NVIDIA's technical report and Hugging Face card cover the "4GB" release: a Q4_K_M GGUF with a target of about 4 GB of memory, 64K input and 64K output tokens, chat-template switches for thinking and conversational modes, and both commercial and non-commercial use. The llama.cpp recipe is still marked pending. On an RTX 5090, NVIDIA reports 285 ms time to first token for the Q4_K_M model, a 70.2 average on its representative benchmark set, and 2.74x per-user decode speed with DFlash at concurrency one. The card includes NVIDIA-run comparisons against Gemma, Qwen and an earlier Nemotron Nano model. Nobody outside NVIDIA has validated any of these results.
In the same window, NVIDIA opened a gated early-access programme for its Factory Operations Blueprint (FOX), an agent harness that connects Cosmos and Nemotron models with CAD, PLM and operational-technology systems. No source links FOX to Bolt.
What the archive adds
Our archive has NVIDIA's Bolt project page, dated October 23, 2026, and it explains how the model was trained. NVIDIA ran every sample in its RLVR/RLHF blend in both reasoning and non-reasoning modes and profiled rewards for each dataset separately in each mode. Every training batch kept a 2:1 ratio of non-reasoning to reasoning samples. As training went on, reasoning traces and final answers grew substantially longer, so NVIDIA raised group-relative length penalties to keep verbosity down. According to NVIDIA's Nemotron page (d2), Nemotron is an open model family for agent workflows that spans edge-to-cloud deployment and is offered as NIM microservices. NVIDIA's FOX blog (d1) describes an autonomous factory-manager agent that coordinates specialist agents. The artifacts disagree on specs. Ollama lists 128K context, image input and a 7.2–7.9 GB download. The 4GB card lists 64K-in/64K-out, text only, at about 4 GB. This suggests the Ollama tag is not the same file as the Q4_K_M "4GB" release.
Trend signal
Small open models are now competing on the cost of running them per turn, not on leaderboard peaks. For a voice assistant or an on-device agent, the numbers that matter are time to first token, tokens per turn and whether the model fits next to everything else in memory. NVIDIA's own framing, "intelligence per GB" and "fast conversational agents", names that axis directly. The dossier's GLM-5.3 item (d3) shows open-weight releases being pitched on agentic use rather than general chat. Bolt applies the same pitch at the 4 GB end and adds an inference-side speedup in DFlash. The pattern is that post-training labs now ship a model, a quantization and a drafter together, and treat the bundle as the product.
Why now
1) Gemma-4-E4B-it gives NVIDIA a strong small base, so its effort goes into RL post-training. The project page documents reward profiling across both modes, the 2:1 batch ratio and length penalties. 2) NVIDIA positions Nemotron as an edge-to-cloud agent family delivered through NIM (d2), and Bolt fills the edge tier. 3) On-device conversational agents depend on TTFT and memory, which is why the release targets about 4 GB at Q4_K_M and reports 285 ms TTFT on an RTX 5090. 4) Speculative decoding with NVIDIA's own DFlash drafters adds a claimed 2.74x single-user decode speedup, which ties the speed story to NVIDIA tooling.
Connections to other events
Taken together, the RL recipe, the 4 GB target and the 285 ms TTFT claim suggest what NVIDIA is optimising for.
Start with the batch mix. Two non-reasoning samples for every reasoning sample means most of the training signal rewards answering directly, without a long thinking trace. That is the right trade for a voice or device assistant, where every reasoning token adds latency before the user hears anything. A lab chasing capability gains would usually lean the other way.
Next, the length penalties. NVIDIA writes that outputs grew substantially longer during RL and that it responded by raising group-relative length penalties. Accepting a cap on how far the model can reason in exchange for shorter turns is a deliberate trade of capability for latency.
Then the memory target. The model is shipped as Q4_K_M at about 4 GB, and NVIDIA picked that quantization itself. Most labs leave quantization to the community. Here the low-precision artifact is the main deliverable, with BF16 as the companion.
Finally, the drafter. DFlash's reported 2.74x is a per-user speedup at concurrency one, which is the single-user, on-device case and not server throughput.
Our read is that NVIDIA's contribution on top of Gemma is mainly a cheaper turn: fewer tokens, less memory and faster first output, plus tool-use tuning. NVIDIA's comparisons against Gemma and Qwen are what would show whether that cost comes with a capability gain. Because NVIDIA ran them on its own harness, they show what it chose to optimise more than how much it gained.
The strategic motive follows, and we flag it as inference. A model sold on speed per GB, benchmarked on an RTX 5090, with an NVIDIA drafter and a NIM route, makes NVIDIA's stack look like the natural runtime for small agents. NVIDIA's edge-to-cloud Nemotron framing (d2) fits that reading. Whether NVIDIA also chose to post-train rather than pretrain to save money is not stated anywhere, and we treat it as speculation.
Why it matters
For builders, Bolt is worth testing wherever latency per turn matters more than depth of reasoning: voice front-ends, device assistants, personas, and narrow tool-routing agents. It is weaker for tasks that need long reasoning chains, because its training penalised them. Measure end-to-end turn latency and token counts, not only accuracy, since that is where the claimed advantage sits. Budget context carefully: on Ollama, images, history and tool results all draw from the same memory-bound window. For buyers, the OpenMDW-1.1 license allows commercial use, but you now depend on two vendors, Google for the base and NVIDIA for post-training, and neither has committed to a joint roadmap. Companies selling agent-tuned Gemma fine-tunes are now competing with a hardware vendor that gives its version away.
What happens next
- An independent multi-turn tool-use evaluation lists Bolt E4B and Gemma 4 E4B-it on the same harness and shows Bolt ahead by a small margin rather than a large one. (3 months, 45%). Watch for: A third-party leaderboard or write-up reporting both models at comparable quantization with per-task scores.
- llama.cpp or vLLM merges native support for DFlash drafters, so Bolt's speculative decoding works outside NVIDIA's own recipes. (6 months, 40%). Watch for: A merged upstream PR or release note naming DFlash, or NVIDIA replacing 'pending' on the Hugging Face card with a working llama.cpp recipe.
- NVIDIA ships another Bolt-line model post-trained from a non-NVIDIA open base. (6 months, 50%). Watch for: A new nvidia-org Hugging Face card in the Bolt line stating it was post-trained from a third-party base model.
Limits and uncertainty
Every number here comes from NVIDIA. The latency figures are from a single GPU (an RTX 5090), and the Gemma, Qwen and Nemotron Nano comparisons ran on NVIDIA's own harness, so harness choices may favour Bolt. Our evidence notes that these comparisons exist but does not give per-benchmark figures, so we cannot say how large Bolt's lead over Gemma is or where Qwen beats it. A small margin would weaken the case that post-training adds capability and strengthen our reading that it mainly adds efficiency. Reading the 2:1 ratio and length penalties as "latency-first" is our interpretation; NVIDIA may present them as a way to keep both modes accurate. We have not confirmed which artifact the Ollama tag serves. No source connects Bolt to FOX, and the cost-saving motive is not documented.
Skill to build now
Learn to measure a local agent model's cost per turn as well as its accuracy. First exercise: write 20 multi-turn tool-calling traces from your real workflow. Run them through Ollama on nemotron-3.5-bolt:e4b and on Gemma 4 E4B, and log tool-selection accuracy, schema-valid arguments, output tokens per turn and time to first token. Then rerun Bolt in thinking mode and again with the DFlash drafter, so you can see how much accuracy each mode buys and what it costs in latency.
Reader takeaway
Run Bolt E4B and plain Gemma 4 E4B side by side on your own multi-turn tool traces, at the same quantization. Record three numbers for each: tool-call correctness, tokens per turn, and time to first token. Adopt Bolt if it wins on the latency columns without losing correctness. Do not expect it to beat Gemma on hard reasoning, because it was trained to keep answers short.
Open question
If Bolt's main advantage is shorter, faster turns from length-penalised RL, could a well-prompted Gemma 4 E4B in non-thinking mode, with its own drafter, close most of the gap? And if it could, what is the Nemotron label adding?