Most current fine-tuners therefore get the open model but not the fast one.
Summary
NVIDIA published BF16 reference weights for Nemotron 3.5 Lightning under the OpenMDW 1.1 license. It is a 30B-parameter hybrid of Mamba-2, mixture-of-experts and attention layers, with 3B parameters active per token. The model card says the BF16 checkpoint is meant for post-training and for building derivatives. It sends latency- and throughput-sensitive deployment to a separate NVFP4 release. NVIDIA's own posts describe NVFP4 as a quantized build distilled from the BF16 original. Its native speed depends on Blackwell-generation GPUs, so the split decides who gets the open model and who also gets the fast one.
What happened
The Lightning card lists an August 11, 2026 release date. It says the model runs on one 80GB H100 or A100, with 256K context validated on a single H100. The 1M-token context is listed for GB200, B200, or eight H100s. The card documents a configurable reasoning mode and a vLLM serving recipe. It names SFT, RL, distillation, domain adaptation and quantized or GGUF variants as uses for the BF16 checkpoint, and points latency- and throughput-oriented serving to the NVFP4 release. Benchmarks come from NVIDIA's own NeMo Gym and NeMo Evaluator harnesses, and the card warns they may differ from vendors' self-reported figures.
Two other items in the cluster follow a similar pattern, though they are not NVIDIA's own models. NVIDIA's deployment guide for Meta's Muse Spark Open is for an MoE coding model with 816B total and 42B active parameters. The guide offers NVFP4 checkpoints "optimized for Blackwell Ultra" and claims up to 50,000 tokens/s per GPU on GB300 NVL72. Liquid AI's RIPL engine reports 34.56 ms p95 latency for LFM2.5-1.2B at 1,000 req/s on one B200. RIPL is for enterprise deployments on H100, H200, B200 and RTX PRO 6000. Both performance claims come from the vendors and have not been reproduced independently.
What the archive adds
Our archive explains why the two checkpoints are not equal. NVIDIA's Nemotron 3.5 Super VL post describes NVFP4 as 4-bit weights with 16-bit activations, with precision chosen separately for sensitive components. Accuracy is recovered through quantization-aware distillation (QAD), in which the quantized model learns to match the outputs of the BF16 original. QAD also lets the KV cache be stored in NVFP4 instead of FP8. On that description, the BF16 checkpoint is the teacher and the NVFP4 checkpoint is the distilled product. According to NVIDIA's NIM support matrix (d3), precision support depends on GPU generation. It lists BF16 and W4A16 on Ampere-class or newer GPUs and lists Lightning's NVFP4 profile separately. NVIDIA's blog (d2) pitches Lightning for high-volume, low-latency execution in long-running agents, and its research page (d1) lists context up to 1M tokens.
Early third-party signals are thin but real. According to Vercel's changelog, Lightning is free on AI Gateway as nvidia/nemotron-3.5-lightning-free, served by NVIDIA. Kilo added the model to its CLI and VS Code extension. In its own tests, Instant mode scored 100% on deterministic labeling and Thinking mode scored 73% exact match on a personal git-eval.
Trend signal
NVIDIA's open-model releases now ship as two artifacts: an open, portable reference checkpoint and a deployment checkpoint in a number format tied to a specific GPU generation. The Super VL post shows the method (QAD into NVFP4), and Lightning's card makes the split explicit in its recommended uses. The Muse Spark Open guide applies the same treatment to another lab's model by publishing NVFP4 checkpoints tuned for Blackwell Ultra. That makes it a weaker but consistent example. RIPL is weaker still: it is Liquid's own engine and supports Hopper as well as Blackwell. What Liquid shares with NVIDIA is the choice to compete on latency and serving rather than on weights.
Why now
1) NVFP4 needs reference workloads. The Super VL post presents QAD and an NVFP4 KV cache as the way to keep accuracy at 4 bits, and the Lightning card sends throughput-sensitive serving to the NVFP4 release. 2) Precision support depends on GPU generation. The NIM support matrix (d3) offers BF16 and W4A16 on Ampere and newer and lists NVFP4 separately, which divides the users of the tuning checkpoint from the users of the serving checkpoint. 3) Agent workloads are long-context and inference-heavy. NVIDIA (d2) pitches Lightning for long-running, high-volume agent execution, and the card ties 1M context to GB200/B200 or eight H100s. 4) A small active footprint widens adoption. With 3B active parameters, single-GPU post-training on Ampere and Hopper is practical, and partners such as Vercel and Kilo are already distributing the model.
Connections to other events
Lightning was built to be fine-tuned widely. With 3B active parameters and a card that says it fits on one 80GB A100 or H100, it is cheap to post-train on hardware many teams already own. The open part is real: the BF16 weights, an open license, and an explicit invitation to build GGUF variants.
Most of those owners are on Hopper or Ampere. NVFP4 is a Blackwell format, and Hopper has no native FP4 tensor-core path. The NIM support matrix (d3) is consistent with this: it gives Ampere-and-newer GPUs BF16 and W4A16 and handles the NVFP4 profile separately. In practice, an H100 team that fine-tunes Lightning ends up with a BF16 model or a weight-only 4-bit build. It does not get the QAD-tuned NVFP4 checkpoint with its NVFP4 KV cache. The long-context story splits the same way: 256K on one H100, but 1M tokens needs a GB200 or B200, or eight H100s.
Our read of the motive is that NVIDIA wants many teams post-training on the hardware they already have. The production version, with long context, high concurrency and a 4-bit KV cache, is then documented and packaged for Blackwell. The fine-tuning step is portable. The fast deployment step is not, unless you rebuild the quantization yourself. This is an inference from how the releases are shaped, not something NVIDIA has said. Separately, the free Vercel endpoint served by NVIDIA probably works more as a showcase and adoption signal than as a revenue line.
Why it matters
Builders: treat the two checkpoints as two decisions. Post-training Lightning in BF16 on A100/H100 fleets is well supported and worth doing. Do not assume NVIDIA's NVFP4 accuracy and throughput numbers carry over to your hardware. If you serve on Hopper, AMD, Apple silicon or CPU through GGUF, you are quantizing yourself without QAD, so measure what you lose. If you plan for 1M-token agent contexts, budget for Blackwell or an eight-GPU Hopper node. One H100 does not cover it.
Buyers: when you compare Lightning with portable open MoEs of similar size, compare the deployment you will actually run, not the best case on the card. Ask hosted providers which precision and GPU generation sit behind a given price or latency.
What happens next
- NVIDIA releases at least one more open-weight model whose card pairs a BF16 checkpoint for post-training with a separate NVFP4 deployment release. (6 months, 80%). Watch for: A new NVIDIA Hugging Face card with paired BF16 and NVFP4 repositories and the same split in recommended uses.
- An independent third party publishes accuracy comparisons for Nemotron 3.5 Lightning across precisions (BF16 vs NVFP4 or a Hopper-compatible 4-bit build) showing a measurable drop on at least one long-context or coding task. (12 months, 50%). Watch for: A non-NVIDIA eval post or leaderboard listing two or more Lightning precisions side by side.
- Vercel's free nvidia/nemotron-3.5-lightning-free endpoint gets tighter limits, becomes paid, or is retired. (6 months, 40%). Watch for: A Vercel changelog entry or AI Gateway model page changing the pricing or status of the free model ID.
Limits and uncertainty
The evidence we have cannot show how much accuracy is lost when quantizing Lightning outside NVFP4, or how much NVFP4 itself gives up against BF16. NVIDIA reports results only on its own harnesses. The only third-party data in our pack is Kilo's small self-run eval and Vercel's distribution, and neither measures cross-hardware performance. The editor pointed to an independent desktop throughput test and to Qwen-class MoE competitors, but those findings were not in the dossier we received, so we make no claims about them. Any single-device test would also mix up model effects with hardware effects. The Blackwell point rests on NVFP4 being a Blackwell-generation format and on d3's precision listing, not on a statement in the card. The motive is our inference. NVIDIA may simply be meeting demand for efficient deployment. If a well-made weight-only 4-bit build on Hopper turns out to match NVFP4 closely on real tasks, the gap this take describes shrinks to a speed difference.
Skill to build now
Learn to measure what quantization costs on your own workload, separately for each GPU generation you run. First exercise: pick 50 real tasks. Serve Lightning's BF16 checkpoint with the card's vLLM recipe, then serve the 4-bit build your hardware actually supports (W4A16 or GGUF on Ampere/Hopper, NVFP4 only on Blackwell). Record exact-match accuracy and p95 latency at your typical context length, and write down which build you would ship and why.
Reader takeaway
Before you commit Lightning to production, run the same task set three ways: the BF16 checkpoint, the 4-bit build you can actually serve on your hardware (W4A16 or GGUF on Hopper and older, NVFP4 only on Blackwell), and your current portable open model at the context length you really use. The difference between the first two runs is what Blackwell is worth to you. The difference against the third shows whether Lightning beats your current model on your own tasks.
Open question
On Hopper, the GPUs most teams own today, does a self-made weight-only 4-bit build of Lightning come close to the QAD-tuned NVFP4 checkpoint on real agent tasks, or does the open model only reach its documented performance on Blackwell?