TL;DR: NVIDIA Model Optimizer (ModelOpt) is the Apache 2.0 toolkit NVIDIA uses to produce its official FP8 and NVFP4 model checkpoints, and it hit GitHub’s trending page this week. Its output runs on vLLM, SGLang, and TensorRT-LLM — not on llama.cpp or Ollama — and its speed wins are locked to RTX 40/50-series tensor cores. Most home labbers should consume its checkpoints, not run the toolkit.

	llama.cpp GGUF (status quo)	ModelOpt, DIY quantization	Pre-quantized ModelOpt checkpoints
Best for	Single user, any GPU (or no GPU)	Quantizing your own fine-tunes for vLLM	RTX 40/50 owners serving via vLLM
Runs on	llama.cpp, Ollama, LM Studio	vLLM, SGLang, TensorRT-LLM only	vLLM 0.10.1+, SGLang, TensorRT-LLM
Hardware needed	Any 8GB+ card, even CPU	24GB+ VRAM plus 64GB RAM to calibrate a 27B	RTX 40-series for FP8, 50-series for NVFP4
The catch	Slower at batch/concurrent serving	Hours of setup for formats GGUF users can’t load	NVFP4 speed win is Blackwell-only

Honest take: If you run one model for one user through Ollama, ModelOpt changes nothing — Q4_K_M GGUF remains the right format, and no amount of NVIDIA tooling makes your RTX 3090 grow FP8 tensor cores. The people who should care are RTX 50-series owners serving models through vLLM, and even they should download NVIDIA’s pre-made NVFP4 checkpoints instead of running the quantizer themselves.

NVIDIA’s Model Optimizer repository picked up hundreds of GitHub stars in a single day this week (359 on September 26 alone), which means a lot of home labbers are about to pip install a datacenter tool and wonder why their Ollama setup can’t load the output. Before you spend an evening on it, here’s what the toolkit actually does, which of its three legs — quantization, pruning, distillation — you can realistically use on consumer hardware, and where it genuinely beats the GGUF workflow you already have.

What Model Optimizer actually is

ModelOpt (nvidia-modelopt on PyPI, version 0.47.0 as of September 23, 2026) is NVIDIA’s unified library for compressing models before deployment. It bundles post-training quantization (FP8, NVFP4, INT8, INT4 AWQ, W4A16), quantization-aware training, pruning, knowledge distillation, neural architecture search, sparsity, and speculative-decoding module training behind one Python API. License is Apache 2.0 — genuinely open source, no gated weights or NVIDIA developer account required.

Install is one line:

pip install -U "nvidia-modelopt[all]"

It requires Python 3.10–3.13 and a CUDA-capable PyTorch — this is a Linux-first tool, and every workflow assumes an NVIDIA GPU is present. Model support covers the families you’d expect: Llama 3.x and 4, Qwen 2/3, Mixtral, Phi-3/4, DeepSeek, Gemma, GLM-4, plus Whisper and several VLMs. You point it at any Hugging Face checkpoint on local disk, so quantizing a model you fine-tuned yourself works the same as quantizing a stock download.

The critical fact buried in the deployment docs: the exported “unified Hugging Face checkpoint” loads into TensorRT-LLM, vLLM (0.10.1 or later), and SGLang. llama.cpp and Ollama are not on the list and can’t read these checkpoints — ModelOpt’s FP8/NVFP4 formats and GGUF are entirely separate ecosystems. If your whole stack is Ollama, the toolkit produces files you cannot use. That single sentence decides the question for most readers.

The hardware matrix: what your card can actually execute

ModelOpt will happily produce any format on any GPU. Whether the result runs fast depends on which tensor cores your card physically has:

Your card	FP8	NVFP4	What you actually get
RTX 3090 24GB (Ampere, sm_86)	No native FP8	No	vLLM falls back to weight-only FP8 via Marlin — weights stored in 8-bit, dequantized to FP16 for compute. VRAM savings, zero compute speedup
RTX 4090 24GB (Ada, sm_89)	Native tensor cores	No	FP8 is the ceiling — real throughput gains in vLLM, roughly half the VRAM of FP16
RTX 5090 32GB (Blackwell, sm_120)	Native	Native tensor cores	The full menu. NVFP4 is where the headline numbers live

Ada Lovelace (RTX 40-series) added FP8 tensor cores; Blackwell (RTX 50-series) added the FP4 datapath on top. Ampere has neither — vLLM’s FP8-Marlin path (merged in vLLM PR #5975) lets a 3090 load FP8 checkpoints as W8A16, but the math still runs in FP16, so you save memory and gain no speed. This is the same story we documented for image generation in our ComfyUI NVFP4 guide: 50-series gets the speed, 40-series gets FP8 as a consolation, 30-series gets smaller files at best.

What NVFP4 delivers when the hardware is there is real. The community-benchmarked Qwen3.6-27B NVFP4 dynamic quants hit ~160 tok/s on a desktop RTX 5090 under native Ubuntu, with the 27B’s weights compressed to about 14GB — against roughly 70 tok/s for the same model as Q4_K_M GGUF on an RTX 4090. That’s the kind of number that sells the format. It’s also Blackwell-exclusive, and the same rig measured only 85 tok/s under WSL, so the 2× is contingent on both the right silicon and a native Linux install.

Quantizing your own model: the real workflow and the real cost

The main entry point is the hf_ptq.py example script. Quantizing a Hugging Face model to FP8 looks like this:

python hf_ptq.py --pyt_ckpt_path ./my-finetuned-qwen \
    --qformat fp8 --export_path ./my-model-fp8

Swap --qformat for nvfp4_mlp_only, int4_awq, or w4a16_nvfp4 for the other formats. Under the hood, post-training quantization runs calibration: the model processes 128–512 sample prompts (ModelOpt defaults to a mix of cnn_dailymail and NVIDIA’s Nemotron post-training dataset) while the toolkit measures activation ranges to place the quantization scales. Then you serve the export directly:

vllm serve ./my-model-fp8 --quantization modelopt
# NVFP4 checkpoints use: --quantization modelopt_fp4

Here’s the cost nobody puts in the README’s first paragraph: calibration wants the model in BF16. A 27B model is ~54GB of weights before quantization — more than any consumer card holds. ModelOpt’s own docs concede that “FP8 calibration over a large model with limited GPU memory is not recommended but possible with the accelerate package.” If you try it on a 24GB card and hit the inevitable CUDA out-of-memory during calibration, the fixes that exist are --low_memory_mode, which compresses weights to low precision before calibration, and --use_seq_device_map, which spills the model across GPU and system RAM sequentially. Both work; both are slow; and the second one turns your system RAM into the bottleneck — at current DDR5 pricing ($680–$1,070 for a 64GB kit, per Tom’s Hardware’s RAM index), provisioning RAM just to quantize models is an expensive hobby.

Which is why the honest recommendation for stock models is: don’t quantize them yourself. NVIDIA publishes ready-made ModelOpt checkpoints on Hugging Face — nvidia/Qwen3.8-27B-NVFP4 (NVFP4 MLP layers with FP8 attention, produced with modelopt 0.48), nvidia/Llama-3.1-8B-Instruct-FP8, an FP4 DeepSeek-R1, and a growing catalog. Downloading one of those and pointing vLLM at it gets you the identical artifact with zero calibration time.

The one genuinely good home-lab reason to run the toolkit yourself: you fine-tuned a model and want to serve it fast. A QLoRA-tuned 7–8B model merges to ~16GB of BF16 weights — that calibrates comfortably on a single 24GB card, and no one on Hugging Face is going to publish an FP8 quant of your checkpoint for you.

Pruning and distillation: read the fine print before you dream

The repo’s pitch — “quantization, pruning, distillation” — reads like three tools you’ll use. For a home lab it’s one tool and two spectator sports.

NVIDIA’s own showcase for the pruning + distillation pipeline is Minitron, where Llama 3.1 8B was pruned to 4B and distilled back to competitive accuracy. The published recipe (arXiv 2408.11796) starts by fine-tuning the unpruned 8B on a 94-billion-token dataset to correct distribution shift, then runs distillation on top. That’s a datacenter training job — multiple orders of magnitude past what any $3,000 rig does. The efficiency claim (“only ~100B tokens versus 15T from scratch”) is real and impressive for NVIDIA; it is not a weekend project. ModelOpt exposes these APIs because the same library serves NeMo and Megatron users on GPU clusters. Unless you have training budget on rented A100s/H100s, pruning and distillation are features you’ll read about, not run.

Quantization is the leg that works on your desk. Calibration is inference, not training — 512 short prompts through the model, minutes on a consumer card for a model that fits.

Does it beat llama.cpp’s built-in methods?

Wrong question, mostly — the two toolchains don’t compete on the same field.

Single user, one prompt at a time: decode speed on a local LLM is memory-bandwidth-bound — the GPU reads every weight for every token. Q4_K_M GGUF stores weights in ~4.85 bits; FP8 stores them in 8. On the same card, the 8-bit model simply has more bytes to move per token, so an FP8 checkpoint does not out-decode a Q4 GGUF for solo chat. You’d switch for quality (FP8 is nearer-lossless than Q4; see our quantization quality-loss numbers) — not for speed. NVFP4 at ~4 bits is the format that matches GGUF’s size and engages Blackwell’s FP4 tensor cores, which is exactly why the 5090’s 160 tok/s on a dense 27B was news.

Serving multiple users or an agent fleet: this is vLLM territory, and here ModelOpt formats win decisively. Published RTX 4090 numbers for Llama 3.1 8B under vLLM run from ~100 tok/s single-stream to 579–599 tok/s of batched throughput with 4-bit Marlin kernels — llama.cpp on the same card sits at 90–110 tok/s and falls 2–3× behind vLLM once 32+ concurrent requests pile up. And loading GGUF inside vLLM to split the difference is the worst of both worlds — community benchmarks put GGUF-in-vLLM roughly 8× behind vLLM’s native quantized paths. If you’re on vLLM, you want vLLM-native formats, and ModelOpt is NVIDIA’s official pipeline for producing them. Our vLLM vs Ollama breakdown covers when the serving-stack switch is worth it at all.

Model coverage: llama.cpp’s GGUF ecosystem quantizes practically everything within hours of release, runs on AMD, Apple Silicon, and CPUs, and needs no calibration step. ModelOpt is CUDA-only — AMD ROCm is not supported, so the R9700 crowd has no stake in this at all.

Who should actually buy hardware over this?

Almost nobody — and definitely not sight unseen. ModelOpt shifts the calculus in exactly one scenario: you already serve models to multiple users or agents through vLLM, and NVFP4’s throughput-per-dollar on Blackwell makes the RTX 5090 earn its street price in a way solo Ollama use never will.

What to actually buy

Prices as of September 2026, from the comparisons above:

Your situation	The move	Price	Where
Solo Ollama/llama.cpp user, any card	Nothing — GGUF Q4 stays correct; ModelOpt output won’t even load	$0	—
Own an RTX 3090, tempted to upgrade “for FP8”	Don’t — Marlin fallback already gives you FP8’s VRAM savings; the used 3090 stays the value hold	$1,150–$1,350 (used)	Check price
Serving vLLM to multiple users on Ada	Used RTX 4090 + NVIDIA’s FP8 checkpoints	$2,150–$2,350 (used)	Check price
Want the NVFP4 fast path (160 tok/s on a 27B)	RTX 5090 — the only consumer card with FP4 tensor cores	$3,822–$5,000	Check price
Want to test FP8/NVFP4 serving before spending anything	Rent a 4090 or 5090 by the hour, run the exact vLLM command above	4090 from $0.14/hr, 5090 from $0.25/hr	Vast.ai

Run your own model-plus-context numbers through the VRAM calculator before deciding any of this justifies new silicon.

FAQ

Can Ollama or LM Studio load Model Optimizer output? No. ModelOpt exports unified Hugging Face checkpoints for TensorRT-LLM, vLLM (0.10.1+), and SGLang. Ollama and LM Studio consume GGUF, which ModelOpt does not produce. The two pipelines don’t intersect.

Does ModelOpt work with AMD GPUs? No — it’s CUDA-only, and the acceleration story depends on NVIDIA tensor-core formats. AMD users get quantization through llama.cpp’s GGUF tooling and ROCm builds; see our ROCm setup guide.

Is FP8 faster than Q4_K_M GGUF on my card? For single-user decode, no — FP8 weights are ~twice the bytes of Q4, and decode is bandwidth-bound. FP8’s wins are quality (nearer-lossless than 4-bit) and batched serving throughput in vLLM on RTX 40/50-series. NVFP4 on a 50-series card is the format that’s both small and fast.

Do I need ModelOpt to use NVFP4 models? No. Pre-quantized checkpoints — NVIDIA’s official ones like nvidia/Qwen3.8-27B-NVFP4 and community builds like Unsloth’s dynamic quants — download and run in vLLM directly. You only run the toolkit to quantize a model nobody has published, which in practice means your own fine-tune.

What about using a quantized local model as a coding backend? An FP8/NVFP4 model served through vLLM exposes an OpenAI-compatible endpoint, which plugs into Cline or Continue.dev as a BYOK backend the same way an Ollama endpoint does — the editor doesn’t care which engine answers. For the self-hosted serving stack itself, aifoss.dev’s vLLM review covers the operational side.

Recommended Gear

Products linked in this article:

• RTX 3090 24GB (used) — the Ampere hold: no FP8 cores, but Marlin fallback still shrinks checkpoints
• RTX 4090 24GB (used) — cheapest native-FP8 serving card
• RTX 5090 32GB — the only consumer NVFP4 card, and the only one this article gives a speed reason to buy

Sources

• NVIDIA Model Optimizer — GitHub repository (Apache 2.0)
• nvidia-modelopt 0.47.0 — PyPI
• Model Optimizer hf_ptq examples: commands, calibration defaults, low-memory flags — GitHub
• Unified Hugging Face Checkpoint deployment (TensorRT-LLM / vLLM / SGLang) — NVIDIA ModelOpt docs
• NVIDIA Model Optimizer quantization support (modelopt / modelopt_fp4, vLLM 0.10.1+) — vLLM docs
• Expand FP8 support to Ampere GPUs using FP8 Marlin — vLLM PR #5975
• NVFP4 Explained: Blackwell’s 4-Bit Format for LLM Inference — Nota AI
• Introducing NVFP4 for Efficient and Accurate Low-Precision Inference — NVIDIA Developer Blog
• Qwen3.8-27B-NVFP4 official checkpoint — Hugging Face
• Qwen3.6-27B NVFP4 ~160 tok/s community reports (RTX 5090, Ubuntu) — Hugging Face discussions
• LLM Pruning and Distillation in Practice: The Minitron Approach — arXiv 2408.11796
• llama.cpp vs vLLM: choosing the right local inference engine — Red Hat Developer
• RTX 4090 Llama 3.1 8B format benchmark (FP16/FP8/AWQ/GPTQ/GGUF) — GIGAGPU
• RAM Price Index September 2026 — Tom’s Hardware

Last updated September 26, 2026. Prices and software versions change; verify current rates before purchasing.

Get the numbers before you buy

New GPU and mini-PC benchmarks, VRAM thresholds, and price checks — sent when there's something worth acting on, not on a schedule. No spam, unsubscribe anytime.

Email address Subscribe