Nemotron 3.5 Lightning on Mac: published tests vs Qwen 3.8

Research checked 2 November 2026. Compiled from published tests. No hardware benchmarks were run for this article; measurements belong to the credited testers.

Short answer

Nemotron 3.5 Lightning needs a Mac with at least 32 GB of memory. The smallest standard 4-bit files are 17.8 to 19 GB, and a measured run used 19.6 to 21.3 GB. Published runs put it near 100 tokens per second on an M4 Max, and more than twice Qwen 3.8 27B’s speed on the same MacBook Pros. In the one public side-by-side test both models scored 14 of 16; Lightning lost its two by reasoning until it hit the token limit.

Mac speeds ↓Against Qwen 3.8 27B ↓Check if it fits your Mac →

NVIDIA released Lightning on 11 August 2026: an open mixture-of-experts model with 30B parameters, about 3B of them active for each token, a context window of up to 1M tokens, text in and text out, under the OpenMDW License 1.1. NVIDIA pitches it as the fast worker inside an agent system, the model that takes many small calls. I have not run it on my own M4 Max. Every figure below comes from someone who has, with their hardware, runtime and date next to the number. My own Qwen 3.8 27B measurements are in the M4 Max review and the coding test.

Memory requirements: will it fit your Mac?

A mixture-of-experts model keeps every expert in memory even though each token only passes through a few of them. So Lightning needs the memory of a 30B model and generates at something closer to the speed of a 3B one. The Hugging Face repository counts 31.6B parameters in total, and Artificial Analysis lists 3.6B active; NVIDIA rounds both down in the name.

Download sizes on 2 November 2026, from the Hugging Face file listings and the Ollama library. The MLX rows run through Apple’s MLX framework; the GGUF rows run in llama.cpp, LM Studio and Ollama.
File	Format	Download
mlx-community 4-bit	MLX	17.8 GB
ggml-org Q4_0	GGUF, plus a separate 1.2 GB MTP file	18.9 GB
Ollama `nemotron-3.5-lightning:30b-mlx`	NVFP4 on MLX, 256K context	19 GB
lmstudio-community Q4_K_M	GGUF	24.5 GB
mlx-community 8-bit	MLX	33.6 GB
ggml-org Q8_0	GGUF	33.6 GB
ggml-org BF16	GGUF, unquantized	63.2 GB

One published Mac run reported memory directly: a 4-bit build on a 36 GB M4 Max held 19.6 GB at a 1K-token context and 21.3 GB at 128K. Add what macOS and your open apps need, and the practical tiers look like this:

16 GB: no. The standard low-bit files are still about 18 to 19 GB. A Reddit thread reports an 11.77 GiB community build for 16 GB machines; I could not check the file or what it needs to run.
24 GB: a stretch. The 4-bit file fits on paper, but macOS keeps part of unified memory for itself, so there is little left for the context cache.
32 to 36 GB: the 4-bit files work. A 32 GB Mac mini M6 ran the Q4_K_M file at about 45 tokens per second.
48 GB and up: room for the 8-bit files (33.6 GB) or long contexts at 4-bit.

The 4-bit files are not interchangeable: NVFP4, MLX 4-bit and Q4_K_M round the weights differently, which the quantization guide explains. The model-fit calculator works out the memory for your machine and context length, and the Apple Silicon guide covers which Mac to buy for local models.

How fast Nemotron 3.5 Lightning runs on Apple Silicon

Published decode speeds (tokens generated per second) for Nemotron 3.5 Lightning on Macs. The Kapitsa rows come from one harness: a 4K-token prompt and a 512-token answer at temperature 0.6.
Mac	Runtime and file	Tokens/s	Measured by
M4 Max, 36 GB	oMLX 0.5.7, 4-bit	100 at 1K context, 85 at 32K, 59 at 128K	Anonymous oMLX benchmark entry, 12 Aug
M5 Max, 128 GB	LM Studio, NVIDIA’s build	about 100	Simon Willison, Hacker News, 11 Aug
M5 Max, 128 GB	Ollama 0.40.5	153	Kapitsa developers
M5 Max, 128 GB	llama.cpp b11669	159	Kapitsa developers
M5 Max, 128 GB	oMLX 0.7.1rc1	190	Kapitsa developers
M5 Pro, 48 GB	Ollama	92	Kapitsa developers
M4 Pro, 48 GB	mlx-vlm with NVIDIA’s DSpark drafter	65	Kapitsa developers
M3 Pro, 36 GB	mlx-vlm with DSpark	39	Kapitsa developers
Mac mini M6, 32 GB	LM Studio, Q4_K_M GGUF	45	Hans-Dieter Zucht’s repository (runs made by an AI agent for him), 3–4 Oct
M1 Max, 64 GB	LM Studio, NVIDIA’s build	about 50	Hacker News user dofm, 11–12 Aug

Kapitsa is an inference engine for Apple Silicon, and its developers publish these tables to show it off. On their own engine they report 287 tokens per second on the M5 Max and 112 on the M4 Pro. Read those as a vendor’s figures. Their Ollama, llama.cpp and oMLX columns are a fair comparison, because every runtime ran the same prompt on the same machine, each with its own 4-bit file.

The runtime matters about as much as the chip. On the same M5 Max, the spread runs from 110 tokens per second in LM Studio’s llama.cpp runtime to 190 in oMLX. Context length matters too: the M4 Max run fell from 100 to 59 tokens per second between a 1K and a 128K context. Prompt processing on that Mac ran at about 1,150 tokens per second for short prompts and 915 at 32K, so a 32K-token prompt waits about 35 seconds before the first word appears.

Nemotron 3.5 Lightning vs Qwen 3.8 27B

For speed, the cleanest comparison is the Kapitsa README, which ran both models through the same runtimes on the same two MacBook Pros. Qwen ran with its MTP draft head in every cell, which speeds up a dense model. Lightning ran without one in three of its four cells (the M5 Pro llama.cpp run also used MTP) and still came out more than twice as fast.

Decode speed in tokens per second from the Kapitsa README (4K-token prompt, 512-token answer, temperature 0.6), checked 2 November 2026. The two models were measured in different sessions, so runtime versions differ on the M5 Max (Ollama 0.40.5 against 0.40.11, llama.cpp b11669 against b11871).
Mac and runtime	Qwen 3.8 27B	Lightning
M5 Max, Ollama	71	153
M5 Max, llama.cpp	48	159
M5 Pro, Ollama	40	92
M5 Pro, llama.cpp	30	101

The prompt-processing gap is wider. On the M5 Pro in Ollama, Lightning read the 4K prompt at 2,369 tokens per second against Qwen’s 470. For an agent that rereads a long context on every call, that is the gap that decides the wait. For comparison, Qwen 3.8 27B decoded at about 55 tokens per second on my M4 Max through Ollama’s MLX engine during the coding test. The M4 Max Lightning run above used a different runtime, so treat the gap between the two as rough.

On accuracy the picture changes. The only public head-to-head I found is from Laxmi Kant Tiwari of KGP Talkie, published 15 August. He gave Qwen 3.8 27B, Lightning and Muse Glimmer the same 16 hard problems with exact answers, on one RTX 5090 PC. He used Ollama’s Q4_K_M build, the same quantization level Ollama and LM Studio offer on a Mac.

KGP Talkie’s run: Ollama 0.32.12 on Windows 11, Q4_K_M files, temperature 0.2, a 65,536-token context and one run per task, on an RTX 5090.
Model	Correct / 16	Whole suite	GPU memory
Qwen 3.8 27B	14	6.3 min	16.3 GB
Nemotron 3.5 Lightning	14	8.3 min	23.7 GB
Muse Glimmer 30B	15	16.2 min	15.7 GB

Lightning generated at 216 tokens per second, the fastest of the three, and still finished the suite two minutes behind Qwen. Twice it kept reasoning until it hit the output limit and returned nothing usable, which cost 310.9 seconds on those two tasks. It also won the 64K three-hop retrieval task. With one run per task, a single flipped answer moves the score, so read 14 against 14 as a tie. The misses differ in kind, though. Both of Qwen’s were confident wrong answers, and one cited a real integer sequence that does not contain its number. Lightning and Muse Glimmer gave no wrong answers; their misses were blanks at the token limit.

The aggregate scores point the same way. At launch, Artificial Analysis gave Lightning 24 on its Intelligence Index, level with gpt-oss-120b and behind Qwen3.6 35B A3B at 32. On the current version of the index it shows 6, against a median of 13 for comparable open models. The index changed between those two readings, so 24 and 6 cannot be compared with each other; why local LLM benchmark charts disagree covers how to read scores like these. NVIDIA’s own headline result is 86 percent on PinchBench, finishing 10,000 tasks 30 percent faster than Qwen3.6 35B at similar accuracy.

What people report about quality and tool calling

On launch day, Simon Willison ran it in LM Studio on an M5 Max and called it “a bit of an over-thinker”: it sketched four SVG drawings in its reasoning before returning a weak one. Its answer to a question about a codebase through his coding-agent tool was solid and took just under a minute. Hacker News user dofm, on an M1 Max, found the code good and the tool call correct on a SQL puzzle. The model second-guessed itself in its reasoning, though, and failed a trick logic question even after repeated nudges. For now dofm prefers Muse Glimmer, which is slower.

The pattern across these reports is the same: fast tokens, too many of them spent thinking. On the model card, NVIDIA recommends temperature 1.0 and top_p 0.95, and reasoning is switched on and off with enable_thinking. For short, well-defined agent calls, I would start by turning thinking off or capping the output length. I have not tested whether it helps. Before trusting any local model with tools in a long session, my tool-calling test at 250K context lists what to check.

Running it in Ollama, LM Studio and MLX

Ollama: the default tag, or the Q4_K_M GGUF pinned

ollama run nemotron-3.5-lightning
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M

Ollama. The default tag holds two builds: a 19 GB one for Ollama’s MLX runner and a 25 GB Q4_K_M GGUF for llama.cpp. Since version 0.40, Ollama runs supported models on MLX by default on Apple Silicon, so a current Mac gets the 19 GB build; the :30b-mlx tag pins it and is listed with a 256K context, while the library lists 1M for the GGUF. Update Ollama first: version 0.32.14 crashed with a Metal GPU timeout when loading the MLX tag (the same bug hit qwen3.8:27b-mlx), and the fix landed on 26 August.
LM Studio. LM Studio’s catalogue lists a build under NVIDIA’s name; that is the file Simon Willison used.
MLX directly. mlx-community publishes 4-bit and 8-bit conversions, and oMLX and mlx-serve tied as the fastest general-purpose runtimes (190 tokens per second) in the Kapitsa M5 Max table.

LM Studio vs Ollama on a Mac covers the setup differences between the two apps.

FAQ: Nemotron 3.5 Lightning on a Mac

Is Nemotron 3.5 Lightning free?

The weights are free to download under the OpenMDW License 1.1. Hosted APIs charge per token; Artificial Analysis lists a typical $0.06 per million input tokens and $0.20 per million output tokens, and OpenRouter also offers a free endpoint.

Can Nemotron 3.5 Lightning run on a 16 GB Mac?

Not with a standard file. The smallest ones are around 18 to 19 GB. A Reddit thread reports an 11.77 GiB community build, which I could not check, so plan on 32 GB.

Is Nemotron 3.5 Lightning multimodal?

No. It takes text and returns text. NVIDIA’s vision model in the same family is Nemotron 3.5 Super VL, a much larger 120B model.

Does Nemotron 3.5 Lightning support MTP or speculative decoding on a Mac?

The model has a multi-token prediction head, and ggml-org ships it as a separate 1.2 GB file for llama.cpp. NVIDIA’s DSpark drafter also runs through mlx-vlm, but in the Kapitsa tests that path was slower on an M4 Pro (65 tokens per second) than Kapitsa’s own engine (112). My speculative decoding note measures what a drafter does for Qwen on an M4 Max.

Is Nemotron 3.5 Lightning better than Qwen 3.8 27B?

It is more than twice as fast on the same Macs, and no more accurate. They tied 14 to 14 in the one public head-to-head. Qwen finished that suite sooner because Lightning overthought two problems, while Qwen’s two misses were confident wrong answers.

Read the series

Mac Studio and RTX cards: reading published LLM tests
DGX Spark 64GB: what published tests can tell us
AMD local LLM tests: the configuration behind the score
Why local LLM benchmark charts disagree
Local AI cost calculations: power, usage and payback
Nemotron 3.5 Lightning on Mac: published tests vs Qwen 3.8 (this article)

Sources

Suhail Mohebi · published 2 November 2026 · the cover is a generated illustration