Why weight-only (W4A16), not W4A4

The "obvious" full NVFP4 (W4A4 = weight + activation both 4-bit) is worse on every axis for this model:

• It breaks the multimodal capabilities — image/audio/video collapse to empty or garbled output. W4A4 quantizes activations using text-only calibration, so the image/audio embeddings are out-of-distribution and get clipped by the 4-bit activation range.
• It is also slightly slower (23.9 vs 24.9 tok/s) — on a bandwidth-bound dense model, the weight-only dequant-to-BF16 path beats the W4A4 path.

So this build is weight-only NVFP4 (NVFP4A16): 4-bit weights, BF16 activations. Omni intact, faster, same file size.

Benchmark (GB10 / DGX Spark, vLLM 0.22.1 native, single-stream decode, warm)

Note: in plain transformers (HF eager) all quantized formats run slower than BF16 because there is no native FP4/FP8 kernel — the speedups above are real only under vLLM.

Accuracy (MMLU + TMMLU+) — the honest tradeoff

Speed and size are not free. I scored all three formats on MMLU (English, 57 subjects) and TMMLU+ (Traditional Chinese, 66 subjects) with lm-evaluation-harness, 5-shot, chat template applied, limit=30 (N ≈ 1,710 EN / 1,980 TC, ±~1.0 pt), through transformers:

The tax is real and uneven. This weight-only NVFP4 build costs ~2.7 points on English but ~6.0 on Traditional Chinese (−3.5% vs −12.6% relative) — the lower-resource language pays roughly twice as much. If your workload is English-heavy and you want the smallest/fastest build, that's a fair trade. If it's Traditional-Chinese-heavy, the sibling FP8 build is near-lossless on TC (−0.24). Single model, single recipe, limit=30 — indicative, not a universal law. Full writeup.

Quantization recipe

llmcompressor, scheme NVFP4A16, basic pipeline (the sequential pipeline hits a UserDict tracing error on this brand-new arch). The ignore list must match vLLM's native module quantization or the model will not load:

python
Copy code
QuantizationModifier(targets="Linear", scheme="NVFP4A16",
    ignore=["lm_head", "re:.*embedding_projection.*"])

i.e. quantize the text tower + the vision patch_dense; keep lm_head and both embedding_projections in BF16.

Serving (vLLM)

Needs vLLM with native Gemma4UnifiedForConditionalGeneration (~0.22.x / main) and the TRITON_ATTN backend — Gemma 4 has heterogeneous head dims (head_dim 256 x 16 heads = 4096 != hidden 3840) that other attention backends mishandle:

bash
Copy code
VLLM_ATTENTION_BACKEND=TRITON_ATTN \
vllm serve coolthor/gemma-4-12B-it-NVFP4A16 --max-model-len 4096

Text and image serve through vLLM today; vLLM's generic multimodal wrapper is image-only for now, so full audio/video serving is pending upstream. All four modalities work through transformers.

Environment (exact versions — this model is version-sensitive)

This is a brand-new arch on a brand-new GPU, so the toolchain matters more than usual. The versions I actually ran:

On a normal CUDA GPU (Hopper/Ada/Blackwell desktop) you don't need the torch-ABI overlay — that pain is specific to building vLLM from source for sm_121. A recent pip install vllm (with the native Gemma4Unified class) plus VLLM_ATTENTION_BACKEND=TRITON_ATTN is enough.

The exact quantization config is in recipe.yaml in this repo (scheme + ignore list), so you can reproduce the build.

Validation (GB10, transformers)

• Text: coherent EN + ZH.
• Image: accurately described a studio-podcast photo (animals, headphones, studio mics, "ON AIR" sign, laptops).
• Audio: transcribed a LibriSpeech clip — "Mr. Quilter is the apostle of the middle classes...".
• Video: correctly described a night-street clip.

Credits

• Base model: google/gemma-4-12B-it (Apache 2.0, Google DeepMind)
• Quantization: llmcompressor + compressed-tensors
• Quantized & benchmarked by coolthor on a DGX Spark (GB10)

Support

One-person effort on a single DGX Spark, no sponsor. If it saved you time, a coffee ☕ is appreciated.