I tried NVIDIA Nemotron 3.5 Lightning 30B-A3B-NVFP4

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Division.

NVIDIA has released Nemotron 3.5 Lightning. It is a 30B MoE with 3B active parameters per token and a 1M token context.

https://blogs.nvidia.com/blog/nemotron-lightning-switchyard-rtx-dgx/

Up until now, I had been following the Nemotron family from Nano through Super and Ultra on the DGX Spark. The previous Ultra was 550B, and even with NVFP4 the weights were 335GB, which meant the weights alone wouldn't fit on the 128GB DGX Spark.

https://dev.classmethod.jp/articles/dgx-spark-nemotron3-ultra-nvidia-api/

This time, Lightning is the opposite. The model card includes a dedicated launch recipe for "1x DGX Spark (GB10)", and a draft adjusted specifically for the DGX Spark for speculative decoding was released at the same time. The vendor explicitly named my local machine and wrote "run it this way." There was no choice but to try it.

To state the conclusion upfront: the speed lived up to its billing. With speculative decoding enabled, 115.75 tok/s for a single request and a combined 421.85 tok/s for 8 concurrent requests. That's 27% faster single-threaded than the previous generation with the same skeleton, and the KV cache pool is 24 times larger than Gemma 4. However, this speed comes with prerequisites for how you use it. This model thinks extensively, and if you're stingy with the token budget, the thinking alone exhausts the budget and the actual response never appears. Opening it up to NVIDIA's assumed value (16,000) lets it perform. "Fast, but a model with prerequisites for use" is my honest impression.

There's one more prerequisite I want to establish before measuring. NVIDIA is not positioning this model as "a model that handles everything on its own." In the developer-facing documentation, the roles are clearly divided.

Frontier reasoning models such as Nemotron 3 Ultra handle orchestration and complex planning, while smaller, more efficient models handle the high-volume execution layer.

What Lightning is meant to handle is high-volume execution: tool calls, validation of their results, delegation to subagents, and formatting. Planning goes to the upper model; execution goes to Lightning. The routing agent for that division is NeMo Switchyard, which was announced simultaneously. Keeping this premise in mind significantly changes how the benchmark results look.

In this article, I'll present the results of running Nemotron 3.5 Lightning on a DGX Spark on its release day, measuring speed, Japanese language, code generation, and tool calling under the same conditions.

What Nemotron 3.5 Lightning Is

First, let me pin down what it is using primary sources. The numbers are taken from the model card and config.json.

Looking at the layer arrangement via layers_block_type in config.json, mamba and moe alternate, with attention appearing in only 6 places in between. Of the 52 layers, only 6 are attention layers. This ratio comes into play later.

To choose a comparison target, I also opened the previous generation's config.json and found they were more closely related than I had expected.

The skeleton is the same, with only the context quadrupled. This makes it an ideal comparison target for seeing where the generational difference shows up. In this article, I'll compare these two side by side using the same vLLM, the same tasks, and the same conditions.

There is more than one published checkpoint.

The last two are drafts, not the main model. The DSpark one has 967M parameters, and the model card states it is "for DGX Spark and data center GPUs with low concurrency."

The model card provides a comparison table with the BF16 version for degradation due to quantization.

Aside from a 2.8-point drop in long-context reading comprehension (AA-LCR), everything is within margin of error, and SWE-bench even comes out higher for NVFP4. As someone who regularly uses quantized versions, this is a reassuring lineup.

Getting It Running

It ran surprisingly easily.

Until now, when running a new model on the DGX Spark, the standard approach was to build an arm64 image yourself or find an image ported to GB10 by community contributors. This time, the model card specifies vllm/vllm-openai:v0.27.1, and an arm64 version is available as an official image. There's also a tag called v0.27.1-aarch64, which was pushed on the same day the model was released.

The launch command can also be used almost as-is from the "1x DGX Spark (GB10)" block on the model card.

vllm serve --model $MODEL_CKPT \
  --moe-backend marlin \
  --kv-cache-dtype fp8 \
  --max-model-len 1048576 \
  --enable-prefix-caching \
  --speculative_config.num_speculative_tokens 3 \
  --mamba-backend flashinfer \
  --mamba-cache-mode align \
  --reasoning-parser nemotron_v3 \
  --speculative_config.method dspark \
  --tool-call-parser qwen3_coder \
  --enable-auto-tool-choice

--moe-backend marlin and --mamba-backend flashinfer are the GB10-specific settings. For this test, I lowered --max-model-len to 65536 to match conditions with other models, and speculative decoding was kept as a separate condition. I left --kv-cache-dtype to the engine's discretion (the startup log shows fp8_e4m3 is chosen even without specifying it, apparently determined by the model's own quantization settings).

The Draft Must Be Named Explicitly

There is one part that won't work as-is. Running the command above stops with this error:

ValueError: Model config must specify `dflash_config.mask_token_id`, `mask_token_id`,
`dspark_noise_token_id`, `pard_token`, or `ptd_token_id` for parallel drafting.

This is because only the speculative decoding method (dspark) is specified without specifying which draft to use. Without a specification, vLLM selects the MTP head bundled with the main model as the draft, but it doesn't have the dedicated token IDs required by the DSpark method, so it stops.

Naming the draft explicitly makes it work.

  --speculative_config.method dspark \
  --speculative_config.model nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark \
  --speculative_config.num_speculative_tokens 3

All speculative decoding numbers in this article were measured using this configuration.

Here are the actual measured values from download to startup.

Muse Glimmer took 371 seconds to start with vLLM, so this is about 1.3x faster to launch.

The KV Cache Is Dramatically Larger

What caught my eye in the startup log was this:

GPU KV cache size: 18,448,384 tokens

Here it is compared with other models measured on the same DGX Spark with the same --max-model-len 65536 / --gpu-memory-utilization 0.85.

24 times Gemma4, and 3.8 times Muse Glimmer. The reason is visible in config.json. Of the 52 layers, only 6 are attention layers, and the rest are Mamba-2 and MoE. Since only attention layers hold KV cache, the layer ratio directly determines the pool size.

There are other models that advertise a 1M token context, but whether memory actually holds up when 1M is actually allocated is a separate question. With this pool, the math works out to holding over 17 simultaneous 1M-token contexts. This shows that the advertised 1M is realistic, at least in terms of capacity.

Incidentally, this isn't something special about Lightning. The previous-generation Nemotron 3 Nano 30B-A3B with the same skeleton also had nearly the same 18,298,197 tokens. It's a property of the Mamba hybrid architecture.

Measurement Conditions

Unless otherwise noted, all numbers below were measured with the same vLLM (v0.27.1-aarch64), the same maximum length (65,536), and the same number of slots (8). Only the SGLang comparison used a dedicated image (dev-nemotron3-5-lightning), with the max length and slot count aligned to the vLLM side. Since the two models are loaded on separate DGX Sparks, speed comparisons are only made within the same machine.

Sampling uses the official recommended values for each respective model. Lightning uses temperature 1.0 / top_p 0.95, and Nano uses temperature 1.0 / top_p 1.0. Only speed measurements use fixed temperature 0 conditions and can be directly compared, but please be aware that the recommended value difference is a factor in Japanese and code comparisons.

I used 16,000 as the baseline token budget. The sample code on NVIDIA's model card uses this value, and the model is designed with it in mind. For tables that line up side-by-side with other models, I used values measured at 4,096 to match past articles. This model thinks at length, so a narrow budget won't show its true capability (more on that later).

Speed

I measured with forced length of 256 tokens and temperature 0, varying the number of concurrent requests.

Here it is alongside other models measured on the same DGX Spark with the same harness.

6.8x faster than Muse Glimmer, and 11.6x faster than Gemma4.

NVIDIA describes this model as offering "up to 4x output speed compared to models of equivalent size." The actual measurements exceeded that claim. However, this is not a fair comparison. The bottom three are dense models that pass all 30B worth of weights for each token generation. Lightning is MoE, so only 3B worth is active. For models both called "30B class," if only one-tenth the amount is active, of course it's faster.

In fact, Qwen3.6-35B-A3B, another MoE with Active 3B, measured around 76.7 tok/s in baseline conditions when I measured it previously under different conditions. That's nearly on par with Lightning's 79.59 tok/s (the vLLM version and KV settings differ, so treat this as a reference value). Most of the speed advantage comes from the "MoE with Active 3B" design, not any magic specific to Lightning — that's the honest assessment.

That said, from the perspective of someone deploying on a DGX Spark, "which of the models using roughly the same memory is fastest?" is a practical question. In that sense, this difference translates directly to a felt difference.

What's interesting is the TTFT (time to first token): 0.071 seconds at C=1. That's 5.7x faster than Muse Glimmer's 0.406 seconds, and the felt experience of "got a response" in conversation is completely different. Moreover, even scaling up to 8 concurrent requests stays within 0.212 seconds — you're not waiting any longer at 8 concurrent than at 1.

At 43.0 tok/s per request with 8 concurrent requests, that's faster than other models' single-request performance (6.8–12.4 tok/s). In a shared-machine team environment, this difference matters even more.

Adding DSpark Speculative Decoding

Here's where things get interesting. NVIDIA released a DGX Spark-optimized speculative decoding draft alongside the Lightning main model. Since it's included in the official GB10 recipe from the start, this combined configuration represents the intended setup.

The draft is a small 967M model that generates candidate tokens ahead of time, which the main model then verifies. When hits occur, multiple tokens advance in a single computation pass, which is how it speeds things up.

115.75 tok/s for single requests, and 421.85 tok/s total for 8 concurrent requests. Memory increases from 17.62 GiB to 19.14 GiB for the draft, but that's negligible against the 128GB unified memory.

I also confirmed there was no quality degradation. Re-running the Japanese 10 tasks with speculative decoding enabled, all 10 results matched those without speculative decoding. I also re-ran with Lightning's assumed budget of 16,000, and Japanese (8/9), code generation (5 tasks fully solved, all 49 tests passing), and all 6 agent suitability probes all matched the non-speculative results. Speculative decoding only "outputs faster" without changing the output — exactly as theory predicts.

Note that the draft's stated performance on SPEED-Bench is an acceptance length of 3.75 (7 lookahead stages). An acceptance length of 3.75 theoretically means up to 3.75x speedup, but the actual result was 1.45x. The startup log shows this warning:

max_num_scheduled_tokens is set to 2032 based on the speculative decoding settings.
This may lead to suboptimal performance. Consider increasing max_num_batched_tokens
to accommodate the additional draft token slots, or decrease num_speculative_tokens
or max_num_seqs.

This says that enabling speculative decoding limits the number of tokens that can be handled in a single scheduling pass.

Three Speculative Tokens Seems Optimal

The model card specifies 3 for num_speculative_tokens, but the draft's config.json lists a block_size of 8. Curious whether more would be faster, I also measured at 8.

Three was faster. Increasing to 8 drops single-request speed from 115.75 to 93.54 tok/s. More lookahead means more waste when a miss occurs, so 3 appears to be the balance point for this model and hardware combination. It's best to simply use the model card value.

DSpark Also Works with SGLang

DSpark isn't vLLM-exclusive. The SGLang section of the model card only covers the EAGLE configuration, but the official cookbook includes a DSpark launch command, and a community recipe (MiaAI-Lab) wrapping it in DGX Spark-specific parameters was published on the day of the model's release. The SGLang side uses a dedicated image lmsysorg/sglang:dev-nemotron3-5-lightning, and the arm64 version was also pushed on the same day as the model.

The speculation-related settings require only three flags. Unlike vLLM, the draft specification is a separate required flag, so the earlier problem of forgetting to name the draft and crashing structurally cannot occur.

--speculative-algorithm DSPARK \
--speculative-draft-model-path nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark \
--speculative-dspark-block-size 3

I compared vLLM and SGLang side-by-side on the same machine with the same conditions (max length 65,536, 8 slots).

Single-request performance is nearly identical (1.6% difference). The DSpark effect is consistent regardless of the stack. For parallel requests, vLLM leads by about 10%. A spot check of the Japanese tasks found only one question — one with long thinking — exhausted the 4,096 budget, with all other results matching vLLM.

The difference emerged in memory design. Looking at the KV cache pool under the same conditions, vLLM has approximately 18.45 million tokens while SGLang has approximately 5.44 million tokens — a 3.4x gap. SGLang allocates a separate bf16 KV cache for the draft, which reduces the main model's pool. Even with the recipe's default 1M context setting, it was approximately 5.05 million tokens and 48 simultaneous requests. This matters when you want to take advantage of 1M context.

The benefit of measuring with SGLang was the acceptance length. SGLang outputs acceptance length and acceptance rate per batch in its logs, letting me directly verify "how often the draft is hitting" — something invisible in vLLM. Across 60 samples generated during Japanese tasks, the acceptance length had a median of 3.27 (upper limit with 3 lookahead stages is 4.0), and the acceptance rate had a median of 0.76. The draft itself is hitting well enough. This is corroborating evidence that the main reason the local speedup ratio is more modest than the stated figure is the scheduling limitation mentioned earlier, not draft accuracy.

Japanese

I submitted 10 Japanese tasks. The budget is 16,000, aligned with NVIDIA's assumption. Evaluation is automated, scoring on mechanically verifiable conditions such as character count, presence of required words, and whether JSON can be parsed.

The free description task is excluded from the total since it cannot be evaluated mechanically. The Nano column was measured at budget 4,096 for side-by-side comparison (thinking there is short, and no cutoffs occur at this budget).

8 out of 9 mechanically evaluable questions were correct. The one it failed was the task of summarizing while preserving proper nouns — it spent 20,678 characters of thinking and still failed to retain a single one of the six proper nouns. The budget still had room (12,112 tokens), so it's not a question of running out of paper; this task is simply a weakness.

Measuring with different budgets changed the picture here. When measured at 4,096 — the side-by-side budget — the same task fails because "thinking fills the budget and zero characters of response appear." The total is 8/9 either way, but the content is completely different. Measuring with a narrow budget makes it impossible to distinguish between "bad at this task" and "not enough paper."

Where the difference stood out clearly was the amount of deliberation before arriving at an answer. For the same problem, Lightning thinks 3–6 times as much as Nano. For the 50-character answer task, Nano uses 385 tokens while Lightning uses 1,402; for the table transcription task, it's 854 vs. 5,286.

However, since Lightning generates 1.3x faster, the felt waiting time doesn't open up as much as the token count ratio would suggest. Thinking more means consuming more tokens, but being fast means you don't wait that much longer — that seems to be this model's character.

Code Generation

Two parts: 5 questions written from scratch from Japanese specifications, and a task fixing a mini-repository containing bugs. Scoring is not model self-report — I run pytest to judge.

Writing from Scratch from Specifications

All problems correct, with all 49 tests passing. The previous generation scored 3/5, so this is where the generational difference is clearly apparent.

Particularly noteworthy is parse_duration (the task of converting strings like "1h30m" to seconds), which required 17,582 characters of thinking. When measured at the side-by-side budget of 4,096, this problem alone had the thinking hit 13,091 characters at the budget limit, and it couldn't produce a single line of code. It was simply a problem requiring over 10,000 characters of thinking, and the narrow budget just wasn't enough to get there.

Nano produced an answer in 1,438 tokens but all 16 tests failed. One couldn't reach the answer for lack of paper; the other produced an answer before thinking enough — a contrasting pair of failure modes.

The difference in thinking length is also striking. Nano produces answers in 331–4,226 characters, while Lightning uses 3,702–17,582 characters. Even with the same skeleton, the newer generation is clearly designed to think more deeply — and the numbers show it.

Fixing Existing Bugs

I gave a mini-repository where 5 of 12 tests are failing and had the model fix it using only file read/write tools.

This was a tie. Both got all 12 tests passing. For tasks where the model uses tools to find and apply fixes itself, both generations performed without issue.

Suitability as a Tool

I look at whether it can be used as an agent component. Reading the chat template, the tool calling format is XML rather than JSON.

<tool_call>
<function=get_weather>
<parameter=city>
Tokyo
</parameter>
</function>
</tool_call>

This is the same format as Qwen3-Coder, and the vLLM side specifies --tool-call-parser qwen3_coder.

Basic calls passed all 5 questions.

The task of finding a bug with a pseudo-filesystem also succeeded in 6 turns and 5 tool calls. Zero malformed calls (unparseable output). Both tool calls and thinking come through in chunks during streaming.

Setting required Causes It to Loop

There was one clear problem. Submitting tool_choice: required — which specifies "you must call a tool" — results in the same tool call being returned 159 times.

It is following the instruction (it is calling a tool). But instead of calling once and stopping, it doesn't stop, and keeps emitting the same call until the token budget runs out. Since it's outputting with almost no thinking (474 characters), it appears to have lost track of when to stop.

I've seen this behavior with other models too. Muse Glimmer and Gemma4-31B return 0 results without erroring when required is submitted. The direction is opposite, but both cases have "the client's contract silently breaking" in common. When writing a client that uses required, there's no choice but to verify on real hardware for each model.

To check whether this runaway behavior is specific to Lightning, I tested the same-skeleton predecessor Nemotron 3 Nano 30B-A3B with the same vLLM, same parser, and same task. The result was 150 calls with finish_reason: length — it also didn't stop. This appears to be an issue with the combination of the Nemotron series and the qwen3_coder parser, not specific to any one model.

How Multiple Tools Are Called Changed Between Generations

There was one more place where the difference from the previous generation appeared. For a question like "Tell me the weather in Tokyo and Osaka" that requires two separate queries, the calling approach reversed.

Both eventually reach both cities, so it's not a question of correctness. However, in environments where tool calls take time, the previous generation that can bundle calls may be advantageous in some situations. When I measured Muse Glimmer previously, it sometimes called one at a time and sometimes bundled four at once depending on the situation, so it's best not to conclude a model's character from a single observation.

Suitability as Agent Components

We examine suitability for loading onto harnesses like opencode and Hermes Agent using six probes. Note in advance that what we are measuring here are the capabilities that each harness depends on, not the results of actually running the harness itself.

For tool selection, we load 40 tool definitions and issue 6 requests, checking whether the expected tool is selected. Both generations missed the same one question. For "Set this to run every morning at 9," it called the directory listing tool instead of the cron creation tool. Sharing the same skeleton, they appear to share the same weakness.

The stumbling block was fixed format reproduction. This task involves having the model write a daily report template 5 times and checking whether the structure is the same each time, but all 5 times took 53.2 seconds with 0 characters of body text. Here too, thinking is consuming the entire budget.

We tried two conditions here. Thinking that turning off thinking might help if it was the problem, we tested with enable_thinking disabled, and conversely, with the budget expanded to 16000 as used in NVIDIA's own sample code.

Expanding the budget to NVIDIA's intended level improved results from 0/5 to 3–4/5. It was indeed a budget issue. However, this does not reach the level of "able to write in the same format every time." Running 3 sets of 5 runs each yielded 3/5 · 3/5 · 4/5, totaling 10/15. In every set, the structure broke down 1–2 times. Elapsed time also ranged from 34–207 seconds, a 6-fold spread.

With thinking turned off, responses come back in 1–2 seconds, but the structure is unstable and rules in long system prompts are no longer followed. Ironically, thinking appears to have been used to comply with instructions.

For use cases that continuously produce fixed-format documents unattended, the previous-generation Nano, which was stable 5/5 under the same conditions, is still more reliably entrusted with the task.

Recalling the premise from the beginning changes the picture. NVIDIA's intended role for Lightning is execution work—calling tools, verifying results, and passing them along. Viewed through that lens, tool calls 5/5, pseudo-filesystem exploration, and bug fixes 5/5 show it handles execution-layer work properly. What it dropped was "continuously writing a daily report template in the same structure every time"—a task closer to clerical work.

NVIDIA also writes that it was "trained for harnesses like OpenClaw and Hermes Agent." Since what we are measuring here are probes of the capabilities each harness requires—not the results of actually running the harness—actual behavior when loaded will need to be verified separately. That remains a task for a follow-up.

The Next Battleground for the 30B Class Looks to Be Specialized Agents

Everything discussed so far can be distilled into a single point: viewing models as "sources of specific capabilities." Extending this perspective, the models you line up will likely no longer be just a single column ranked by intelligence. Around the time this article was being written, Fastino, in collaboration with NVIDIA, released models that applied domain-specific training of Nemotron 3.5 Lightning to finance and healthcare respectively, under Apache 2.0. The base is a lightweight MoE (Mixture of Experts) model with 30B parameters and 3B active, but according to Fastino's announcement, the financial benchmark FinQA moved from 15.9% to 59.2%. This is a real-world example of a lightweight model, with a narrowed domain, matching large models in that area. This is a use case only possible with open models whose weights are published, and this approach will only increase in industries with strong privacy and regulatory requirements.

https://fastino.ai/blog/fastino-nemotron-3-5-lightning-finance-and-healthcare

What becomes interesting then is the idea of treating a business domain or an organization itself as one large model. The specialized lightweight models become the experts within it, and the router deciding which expert to call corresponds to the gating mechanism. It is a structure where the MoE architecture moves from inside a single model to being externalized as the overall system architecture. Looking at the combination of Nemotron 3.5 Lightning as the "lightweight execution handler" and Switchyard as the "supervisor routing tasks," NVIDIA may have already moved beyond the competition of "choosing the single best model" and into agent design that decomposes planning, execution, and verification across separate models.

As with the recently published Muse Glimmer 30B from Meta Superintelligence Labs in open weights, it is becoming difficult for models of this size to compete at the top in overall intelligence rankings. The battleground is shifting to "which domain to become an expert in," and the next frontier for the 30B class looks to be as specialized agents. The day when domain-specialized Lightning models line up on a local DGX Spark does not feel that far off.

https://dev.classmethod.jp/articles/dgx-spark-nemotron-lightning-switchyard-classifier-finetune/

Summary

Nemotron 3.5 Lightning clearly stands out in speed among 30B-class models for the DGX Spark. Without speculative decoding, 79.59 tok/s standalone; with DSpark loaded, 115.75 tok/s; with 8 concurrent, a total of 421.85 tok/s. The response speed of 0.071 seconds to the first token is also effective in interactive use. With a KV cache pool of 18 million tokens, the headline 1M context was realistic in terms of capacity.

There are quirks to handling it. This model thinks a great deal, and if the token budget is set too narrow, it never reaches the body. When measured at 4,096 for side-by-side comparison, thinking consumed the budget in 3 tasks. Conversely, expanding to NVIDIA's intended 16,000 eliminated cutoffs, code generation achieved all 5 correct answers (all 49 tests passing), and fixed format improved from 0/5 to 10/15. The correct understanding is that given enough budget, it can deliver.

Even so, with fixed formats, the structure breaks down 1–2 times out of 5. Yet turning off thinking causes it to stop following constraints like 50-character limits or JSON formatting. It is an all-or-nothing binary, with no dial in the model to find a middle ground. At first, this seemed like a weakness.

However, I think this is because the premise of having a single model handle everything was simply wrong to begin with. NVIDIA's division of labor assigns complex planning to higher-tier models like Nemotron 3 Ultra, while Lightning handles high-volume execution. Rather than adjusting inference intensity within a single model, the design is to switch models per task. The switching role belongs to NeMo Switchyard, and LangChain validation figures show 74% cost reduction by routing between Lightning and Claude Opus 4.8, sending only 7% of tasks to the higher-tier model.

With this division of labor as the premise, the hands-on measurements fit neatly. Tasks involving calling tools and verifying results had no misses, code generation scored 5/5, and speed was 27% faster than the previous generation. As a "handler for running large volumes of routine tasks quickly," this is what was expected. Conversely, for work like continuously producing fixed-format documents unattended, the previous-generation Nano with the same skeleton was more stable. Selecting based on use case is the correct way to read this model.

NVIDIA's claim of "up to 4x output speed compared to same-class models" was actually conservative in our measurements—6.8–11.6x against dense 30B-class models. Regarding the claim of being 30% faster than Qwen3.6 35B in agent task completion time, raw generation speed was roughly matched, so any difference would likely come from harness optimization. That was not measured this time.

What I want to do as a follow-up is precisely that combination with Switchyard. Since I have already tested Switchyard on its own previously, setting up a configuration with Lightning as the execution layer routing with a higher-tier model should let the speeds measured in this article directly apply. Testing actual performance when the 1M context is genuinely filled also remains on the to-do list.

Reference Links

• NVIDIA Nemotron 3.5 Lightning announcement blog (2026-08-11)
• Developer explanation of Nemotron 3.5 Lightning — Positioning as an execution layer and explanation of harness optimization
• Routing agent workloads across models with NeMo Switchyard — Explanation of the side that handles routing with higher-tier models
• Specialized finance and healthcare models released by Fastino based on Lightning — Apache 2.0. A real-world example of how far domain specialization can push performance
• nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 — The main model measured this time. DGX Spark startup recipe also here
• nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark — Speculative decoding draft for DGX Spark
• nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-NVFP4 — Previous generation used for comparison
• NVIDIA-NeMo/Nemotron vLLM cookbook — Speculative decoding settings are explained in more detail here than in the model card, but the description of the lookahead step count differed from actual hardware
• NVIDIA-NeMo/Nemotron SGLang cookbook — The DSpark flag for SGLang is not in the model card; it is listed here
• MiaAI-Lab SGLang recipe for DGX Spark — Starting point for this SGLang verification. Includes memory settings for GB10
• vLLM v0.27.1 release (2026-08-11) — Includes support for quantized DSpark head
• OpenMDW-1.1 license
• Article measuring Muse Glimmer 30B on DGX Spark — Muse Glimmer / Gemma4-31B figures in the comparison table were measured here
• Article measuring Qwen3.6-35B-A3B-NVFP4 on DGX Spark — Comparison with another Active 3B MoE