Bottom line up front
Nemotron 3.5 Lightning is a 30-billion-parameter mixture-of-experts model that activates roughly 3 billion parameters per token, using a hybrid architecture of Mamba-2, attention, and MoE layers. NVIDIA documents a 1-million-token context at the model level, OpenMDW-1.1 licensing that permits commercial use, five released checkpoints including NVFP4 and GGUF builds, and a native multi-token-prediction head that provides speculative decoding out of the box. NVIDIA positions it for high-volume, well-scoped agent steps rather than complex reasoning, which makes it a candidate execution model rather than a replacement for a larger reasoning model.
Why 30B total and 3B active matters
Nemotron 3.5 Lightning is a sparse mixture-of-experts model with about 30 billion parameters in total and roughly 3 billion active per token. Active parameters drive per-token compute, so the model behaves like a mid-sized model for cost and latency while its capability ceiling comes from the full parameter pool. NVIDIA's own framing is that this makes it suitable for high-volume execution rather than for the hardest reasoning steps.
The architecture is hybrid: interleaved Mamba-2 and mixture-of-experts layers with selective attention layers. For a team, the architecture matters mainly for one reason — it constrains which runtimes and serving paths are available. A hybrid Mamba model needs a runtime that supports it, which is a practical filter when you are choosing between self-hosting stacks.
- Confirm your serving runtime supports the hybrid Mamba-2 architecture before planning self-hosting.
- Treat active parameter count as the cost and latency signal, not total parameters.
- Match the model to the step: high-volume execution is not the same job as deep reasoning.
The model-level context is not the served context
NVIDIA documents up to a 1-million-token context at the model level. Third-party indexes record that providers commonly serve a smaller window — one gateway recorded 262,144 tokens on its standard endpoints and completion limits ranging from roughly 32,768 to 235,929 tokens depending on provider. A context figure without the provider's completion limit is not actionable.
NVIDIA's own local guidance makes the same point in a different form: the default context in its Ollama guidance scales with available VRAM, with lower defaults on smaller cards and larger ones with more memory. Running a model locally does not automatically mean you can use its maximum documented context.
- Record the context window and the completion limit separately for your provider.
- Test at the context length you actually intend to use, not the maximum documented.
- Confirm memory headroom for the KV cache at that context, not just for the weights.
OpenMDW-1.1 is permissive but not MIT
NVIDIA releases Nemotron 3.5 Lightning under OpenMDW-1.1, and states the model is ready for commercial use. NVIDIA publishes five checkpoints: a BF16 reference build, an NVFP4-quantised build tuned for inference, a base BF16 build for further training, and two draft-model variants for speculative decoding. Weights, training data descriptions, and recipes are published alongside them.
OpenMDW-1.1 is permissive but it is not the MIT licence, and the distinction matters if you plan to redistribute a modified model. Read the licence before making a deployment or redistribution decision; a model card's summary of its own licence is not the licence.
- Read OpenMDW-1.1 directly rather than relying on a summary.
- Record which checkpoint you adopted and its licence.
- Check the hardware guidance for the specific checkpoint, which differs between BF16 and NVFP4.
Treat throughput as a claim you can test
NVIDIA states that Lightning reaches up to four times the throughput of similarly sized open models, and third-party analysis recorded performance comparable to a much larger model at roughly a quarter of the parameters. Those are the developers' and analysts' claims, produced on their own configurations. They are useful for deciding whether the model class is worth evaluating; they are not a prediction for your hardware.
There is one claim that is unusually checkable. The model ships with a native multi-token-prediction head providing speculative decoding enabled by default, and an independent engineering write-up reported that a purpose-trained EAGLE-3 draft head could only match the built-in head. If speculative decoding matters to your latency, that is a specific thing to verify on your own serving stack rather than a claim to accept.
- Run a short throughput test on the hardware you actually intend to use.
- Record hardware, precision, context length, and batching alongside any number.
- Verify whether the built-in speculative decoder is active in your serving configuration.
