NVIDIA released Nemotron 3.5 Bolt E4B 4GB on October 23, 2026, for local conversational agents with multi-turn tool use. The model targets assistants running on supported NVIDIA hardware, with configurable reasoning and concise responses. Its compact-memory positioning depends on the workload and serving configuration.
From an October announcement to downloadable weights
NVIDIA’s October 15 family announcement named E4B but explicitly said it was coming October 23. That was advance notice, not evidence that E4B weights were already available. The subsequent model card labels the October 23 version GA, rather than a preview.
As checked on November 1, NVIDIA’s Hugging Face repository contains the Q4_K_M GGUF file, while a separate repository provides the BF16 checkpoint. These are downloadable artifacts, not merely a research demonstration or waitlist.
The hosted route is distinct: NVIDIA Build offers a prototype API using the model identifier nvidia/nemotron-3.5-bolt-e4b. Its page currently marks the free endpoint available and the partner endpoint unavailable. Although that page also marks its download option unavailable, this does not negate the separately published Hugging Face weights. A prototype endpoint should not be mistaken for a production service commitment.
The 4GB name is not a complete hardware budget
The downloadable GGUF file is 6.18 GB. NVIDIA’s approximately 4GB positioning describes a target runtime-memory envelope, not the file size or total memory required by an assistant. Its published Q4_K_M, batch-one measurements range from 3.5 GB to 4.3 GB on an RTX 5070 and from 4.2 GB to 4.9 GB on a Jetson Orin Nano, depending on the workload. These are NVIDIA’s measurements, not Nerova tests.
The latency difference is equally consequential: NVIDIA reports 548 milliseconds to first token on the RTX 5070 versus 5,785 milliseconds on the Orin Nano for the listed uncached 3K-input, 50-output workload. Both can run the model; they do not offer the same interaction speed.
Our operational reading: do not approve a hardware purchase from the model name alone. Require a memory budget for the application around it and a response-time target for the complete interaction. A model fitting on a device is a different acceptance criterion from an assistant feeling responsive.
A conversational controller, not a complete voice assistant
E4B is post-trained from Gemma-4-E4B-it, with 8B total and 4B effective parameters. The released GGUF card specifies text input and output, a 64K context, switchable thinking and a conversational mode. It lists OpenMDW-1.1 as the governing model license and describes commercial use as supported.
That text-only boundary matters for a business evaluating a spoken assistant: treat speech recognition, speech synthesis and application actions as separate acceptance tests, rather than assuming the checkpoint supplies the entire experience. For a reception kiosk, for example, our proposed pilot would first handle a small set of read-only questions, then draft an appointment request for confirmation—not immediately receive unrestricted booking privileges.
What the release proves—and what a pilot still must prove
The official benchmark table separates BF16 from Q4_K_M results. In the latter group, E4B scores 52.32 on Tau2-Bench versus Qwen3.5 4B’s 61.74. That is a useful counterweight to an overall improvement narrative: the smaller deployment target does not establish universal tool-use superiority.
For this release, our recommended go/no-go evidence is deliberately narrow:
- Conversation: can it clarify an ambiguous request instead of guessing an action?
- Execution: does the application validate arguments and require confirmation before a consequential change?
- Device performance: does the full assistant meet its latency target while the normal application is running?
- Recovery: can a failed tool call or interrupted conversation return safely to a human?
The October 23 release makes a local evaluation possible now. It does not settle those operational questions. For businesses, the strongest reason to revisit E4B is the availability of inspectable deployment artifacts—not an assumption that a compact model automatically becomes a reliable employee.