Nemotron-3.5-Lightning-30B-A3B · file← Nemotron-3.5-Lightning-30B-A3B

MLX 4-bit

An MLX copy, the base for a small fine-tuning trial, then tested. Its deletion left that trial with nothing to run on.

Size: 16.6 GB
Status: Deleted 8 Sep 2026
Scored runs: 3
Smallest Mac: 32 GB estimate, 8K context

Results3 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
groundingnemotron-lightning-30b-mlx-4bitunenforced	56.8%	48.0–65.2	Passed 71/125	mlx_lmextraction	2026-09-08
nullschemanemotron-lightning-30b-mlx-4bitunenforced	9.7%	4.8–18.7	Passed 7/72	mlx_lmextraction	2026-09-08
screeningnemotron-lightning-30b-mlx-4bit	90.0%	79.9–95.3	Passed 54/60	mlx_lmextraction	2026-09-08

Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.

The recordHow it was made · how it was served · what went wrong · what happened to it

Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.

File	folder `nemotron-lightning-30b-mlx-4bit`, about 16.6 GB (`du`), size in bytes not on record
Format	MLX 4-bit (`model_type` nemotron_h)
Where from	origin not on record (download or local convert; present by 2026-08-13 because it was the LoRA base)
Status	deleted 2026-09-08
Hugging Face	not on record

How it was made

Folder: models/nemotron-lightning-30b-mlx-4bit, config.json model_type nemotron_h, 4-bit; about 16.6 GB (du), 17 GB in the later inventory. Size in bytes, file list and sha256: not on record, and the folder is gone.
Date: it existed by 2026-08-13 evening, because lora/adapters/smoke was trained on it at 21:42 local (BST) and adapter_config.json names it as model. A runbook line on 2026-08-23 lists it among "MLX weights on disk".
Why it was made or fetched: as the base for an MLX LoRA of nemotron on Hermes tool traces (reconstructed from lora; the lab's plan named a CUDA-style fused-MoE route, but the work that actually ran was mlx_lm). The assistant did not know this on 2026-09-05 or 2026-09-07: it reported the folder as having "neither a router preset nor a single runlog entry" and as "the MLX copy is redundant unless SwiftLM ever gets built".

How it was served

label	dates (UTC)	binary	ctx / -np / KV / -fa / --jinja / --reasoning-format	harness profile	why this label exists
`nemotron-lightning-30b-mlx-4bit`	2026-09-07 23:28Z to 23:34Z (run-log ts 00:30:54 to 00:34:14 BST on 09-08)	`mlx-venv/bin/python -m mlx_lm server --model <folder>`; mlx_lm 0.31.3 (run-log); the script comment says "pinned 0.31.3 for comparability" and does not say which package	not applicable to mlx_lm; no ctx flag; `response_format` is accepted and not applied	extraction (thinking off, max_tokens 2048); harness `--model-id` was the folder path, so the result files are named `...nemotron-lightning-30b-mlx-4bit...`	Alan: "running the mlx versions of models to test speed & accuracy"; the serial compute chain ran it beside granite and qwen3-8b MLX builds

Other uses, none of them in the run log: LoRA base for lora/adapters/{smoke,run1,i150,i450}; an mlx_lm server on 2026-08-14 22:58 local, which served the Mac Studio and the M4 Mac mini (lora/mlx_server.log).

Decisions

Made or fetched as a LoRA base (reconstructed).
Benched on Alan's queued request; not seated; no router preset ever pointed at it.
2026-09-05 17:41Z the assistant left it; 17:34Z on 09-07 listed it for deletion; on 2026-09-08 07:47Z recommended deleting it and keeping the GGUF.
Deleted 2026-09-08 07:48Z along with the GGUF on Alan's "Kill Nemotron thinking cap and Gemma dense"; rm -rf. Not published.

What went wrong

Unenforced schema (above): the 9.7% is not comparable and the MLX/GGUF pair is two measurements on two runtimes, two quants, one set of labels.
Orphaned adapters. Deleting the base broke the only way to run or merge run1, i150 and i450. Nobody connected the two: neither the 09-07 triage nor the 09-08 recommendation mentions lora.
MLX server memory. The 2026-08-23 runbook warns that idle MLX servers hold memory ps cannot see; not specific to this run.
Throughput table artefact (above). Partial runs: none. Stale build stamps: run-log llama_build is empty for the MLX rows and runtime_versions says mlx_lm 0.31.3, from a note source (runtime_source: note), not from a stamped manifest.

What happened to it

Fetched or converted by 2026-08-13 → LoRA smoke (2026-08-13 21:42) and run1 (2026-08-13 22:30 to 2026-08-14 07:41) → control test 2026-08-14 → on disk through the 2026-08-23 runbook → benched 2026-09-07 → deleted 2026-09-08 07:48Z. No RESTORE-deleted-*.sh entry. Re-obtainable from: probably mlx-community/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-4bit; the HF cache stub suggests that repo, but the id has not been verified, and the folder may have been a local mlx_lm convert. Results in the run log survive.