local-ai · review · first seen Oct 24, 01:28 UTC
Ollama adds NVIDIA Nemotron 3.5 Bolt E4B
Ollama v0.40.10 shipped NVIDIA Nemotron 3.5 Bolt E4B, a local vision-language model described for conversations, image understanding, and tool use. For a builder, the reason to look now is that the release gives a model name and a run command for testing those tasks locally.
In short
- Ollama v0.40.10 shipped Nemotron 3.5 Bolt E4B and provides a run command.
- The model supports a 128K-token context window; usefulness at your required length needs testing.
- A DFlash draft is included, but this source provides no measured benefit.
What shipped
The v0.40.10 release notes include NVIDIA Nemotron 3.5 Bolt E4B. They describe it as NVIDIA’s smaller, Gemma 4-based vision-language model for local conversations, image understanding, and tool use. The concrete starting point in the notes is `ollama run nemotron-3.5-bolt:e4b`. This is a shipped release entry, not a scheduled feature or an announcement of a future model. The notes do not provide a worked image or tool-use example, so the run command is the reproducible starting point they establish. [1]
The model supports a 128K-token context window. That is a stated model capability, not evidence that every prompt near that limit will be useful in your application. If your workflow carries long instructions, conversation history, or image-related context, the stated window makes the model worth testing against your own inputs. The release excerpt does not say how the model behaves as inputs approach the limit, or give an example of a task that requires it. [1]
The model also includes a DFlash draft for speculative decoding. The release identifies the draft but supplies no measured comparison with and without it. Treat its inclusion as a feature to inspect during evaluation, not as a demonstrated latency improvement. The relevant question for a builder is whether this model, as shipped through Ollama, meets the response and output requirements of the workflow at hand. These notes alone cannot answer that question. [1]
Why it matters if you build
If you are choosing a local model for an image-and-text workflow, this release gives you a specific candidate to put through your existing checks. Start with the conversations, images, and tool-use requests that represent your application, rather than treating the three use cases in the release description as proof of performance. Record where the outputs are usable and where they need correction. The source establishes the intended use cases and the run command; it does not establish accuracy on your material. [1]
The 128K-token window may matter when your workflow keeps substantial context in one request. It does not, by itself, settle how much context you should send, what the model will retain reliably, or the cost of doing so. Test the amount of context your application actually needs and compare the resulting answers with shorter inputs. That gives you a decision about your workflow instead of a decision based only on the published window size. [1]
Do not budget around an assumed speed gain from DFlash. Its presence in the model is confirmed; its effect in your setup is not quantified here. Likewise, the release excerpt gives no hardware requirement or operating-cost figure. If either is a condition for adoption, measure it in your environment before committing to this model. A useful first decision is whether the model clears your task-quality threshold; performance and resource checks should follow on the same workload. [1][2]
How to try it today
- Use Ollama v0.40.10, the release that includes the model.
- Run `ollama run nemotron-3.5-bolt:e4b`, the command given in the release notes.
- Try a representative local conversation and check the answer against your requirements.
- Try an image-understanding task drawn from your workflow; assess the output yourself.
- Try a tool-use request relevant to your workflow, then test the amount of context you expect to supply.
- If response time affects your decision, measure it rather than assuming a benefit from the included DFlash draft.
What we checked
Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.
-
shipped L0 · primary
Ollama v0.40.10 includes NVIDIA Nemotron 3.5 Bolt E4B.
per GitHub releases · ollama/ollama (L0) -
shipped L0 · primary
Nemotron 3.5 Bolt E4B supports a 128K-token context window.
per GitHub releases · ollama/ollama (L0) -
shipped L0 · primary
Nemotron 3.5 Bolt E4B includes a DFlash draft for speculative decoding.
per GitHub releases · ollama/ollama (L0)
What is not confirmed
The supplied release excerpt does not establish image-understanding accuracy, tool-use reliability, hardware requirements, operating cost, or measured latency. It does not quantify a benefit from the DFlash draft or show how answer quality changes near the 128K-token limit. Those are open evaluation questions, not defects established by this source. [1][2][3]
Who should act, who should wait
Move now if you can test a local vision-language candidate against your own images, conversations, and tool-use requests before adopting it. The shipped model and its run command are enough to begin that evaluation. Wait on an adoption decision if you first need verified accuracy, resource costs, or a measured decoding benefit: none is established by the supplied release excerpt. Keep the 128K-token window as a test condition, not a substitute for a test result. [1][2][3]
Sources
- v0.40.10 — GitHub releases · ollama/ollama L0 · primary