NVIDIA FP4版Qwen3.8本地部署：Blackwell独占与55个环境变量

NVIDIA把Qwen3.8-Flash-Next压到了96 GiB，原版BF16是355 GB，GPQA Diamond精度只掉0.7个点。听起来像是本地部署的性价比之选，但模型卡第一行就写着：上游vLLM读不了这个权重，只有Blackwell架构能跑，而且RTX PRO 6000的启动脚本要在vllm serve之前导出55个环境变量。

NVIDIA到底改了什么

底层模型是阿里Qwen3.8-Flash-Next，一个125B总参数、6B激活参数的MoE，额外带51B的n-gram嵌入表（卡片里叫PLE）和4B的MTP头。它带视觉编码器和混合注意力（Gated DeltaNet加Qwen Sparse Attention），原生上下文262K tokens，可扩展到1M。

NVIDIA这个FP4版本最值得看的是量化感知蒸馏（QAD），用的是Model Optimizer v0.47.0，而不是普通的训练后量化。BF16模型当teacher，低精度权重被训练去匹配教师的token概率和隐藏状态，甚至对"结束思考"和"结束回复"分别设了loss，专门针对量化模型"想个不停"或"停不下来"的毛病。训练预算是3个epoch共500M tokens，先2500次主干更新，再1500次联合精调更新。

精度分配上不是全部FP4：解码器路由专家和MTP路由专家用NVFP4，解码器注意力和视觉注意力线性层用MXFP8，视觉MLP和merger用NVFP4，其余视觉张量和norm保持BF16/FP32。注意力留在8-bit、专家层吃FP4收益，这个切分是合理的，因为字节大头在路由专家。

量化感知蒸馏（QAD） 是一种在量化约束下直接训练低精度模型的压缩方法，区别于常见的训练后量化（PTQ）。PTQ 先训练好 BF16 权重再压低精度，校准数据通常只有几百到几千条样本，量化误差无法回传修正；QAD 则把量化算子嵌入训练图，让低精度权重在前向中被真正使用，再用全精度 teacher 的输出作为监督信号，通过反向传播更新权重。常见损失包括 token 概率的 KL 散度、中间隐藏状态的余弦相似度，以及针对具体行为的任务损失。NVIDIA 在卡片中额外对"结束思考"和"结束回复"分别设 loss，正是用蒸馏数据约束量化模型在推理模式下的终止行为，这类细粒度行为对齐是普通 PTQ 校准无法覆盖的。代价是训练算力显著增加，且需要 teacher 全程参与。

NVFP4 与 MXFP8 是两种不同的低精度数值格式。FP4 指 4-bit 浮点，NVFP4 是 NVIDIA 定义的块缩放 4-bit 格式，每 16 个数共享一个 FP8 scale，兼顾动态范围和小数精度，主要适合权重方差大的层。MXFP8 则是 OCP 定义的 8-bit 块浮点，每 32 个数共享一个 E8M0 scale，精度更高但占用翻倍。文章提到注意力留在 MXFP8、路由专家用 NVFP4，正是依据两者在精度与体积上的取舍：注意力对数值扰动敏感，用 8-bit 保险；专家层参数占比最大，用 4-bit 才能拿到主要压缩收益。

FP4比BF16和GGUF省多少显存

版本	大小	来源
BF16原版	355 GB	Unsloth文档
GGUF Q8_0	188.26 GB	bartowski
GGUF Q4_K_M	119.60 GB	bartowski
GGUF UD-Q4_K_XL	111.3 GB	Unsloth
GGUF IQ4_XS	97.68 GB	bartowski
NVIDIA FP4-Local	~96 GiB	NVIDIA卡片
GGUF UD-IQ1_S	72.5 GB	Unsloth

单位上有个坑：96 GiB约等于103 GB，落在IQ4_XS和UD-Q4_K_XL之间，比bartowski的IQ4_NL（100.29 GB）还大。所以它并没有"96"听起来那么小。选它的理由应该是训练方法，不是文件大小。

算术也值得算一下：96 GiB权重放在96 GB的RTX PRO 6000上，KV cache没有余量。NVIDIA验证配置把n-gram嵌入表offload到CPU（VLLM_PLE_CPU_OFFLOAD=1），宣称这样能腾出850K tokens的FP8 KV cache。DGX Spark上开不开PLE offload都能跑，表放到磁盘时有1M tokens的FP8 KV cache。

NVIDIA公布的精度数字

精度	GPQA Diamond	ToolEvalBench
BF16	92.2%	89.4%
FP4-Local	91.5%	88.7%

两项都掉0.7个点。GPQA Diamond只有198题，0.7点约等于1.4题，落在单次采样噪声范围内，既证明不了损失小，也证明不了损失大。

还有个对照问题：NVIDIA的BF16基线是92.2，Qwen自己的卡片报的是91.7，大概harness或设置不同。拿FP4和NVIDIA的BF16比才对，跟Qwen的数字比会得出"只掉0.2点"的错误结论。

视觉部分是明显的空白。卡片列了图像和视频输入，把视觉MLP量化成NVFP4，但一个视觉benchmark都没发，蒸馏数据也全是文本。如果你冲图像输入来选这个版本，你就是那个eval。

作为对比，Unsloth公开了自家量化的KL散度：UD-Q4_K_XL平均KLD 0.046893，与BF16的top-1一致率92.255%。这是另一个维度的指标，两边公开的数字不足以判定谁更好。

GPQA Diamond 是 GPQA 基准中最难的一档子集，题目为研究生水平的物理、化学、生物多选题，由领域专家撰写并经过验证，设计上要求模型具备专家级推理而非检索能力。Diamond 子集共 198 题，正因题量小，评估结果的统计波动很大：在 95% 置信区间下，单次采样的标准误约为 2 个百分点，0.7 点的差值远在噪声之内。因此这类小样本高难度基准更适合作为"未出现明显崩塌"的证据，而不是精细的精度分档依据。若要判断 FP4 与 BF16 的真实差距，需要用更大规模的基准或多次采样取均值，并公开采样温度、few-shot 数量和答案抽取方式。

KL 散度（KLD） 衡量两个概率分布之间的差异，在量化评估中常被用来对比量化模型与 BF16 模型在同一批输入上的输出分布。Unsloth 报告 UD-Q4_K_XL 平均 KLD 0.046893，意味着量化模型与全精度模型的 token 分布差异较小，但 KLD 对分布尾部和长序列敏感，且高度依赖评估数据集与 prompt 长度，不同厂商的校准集和评测集不一致时，数值不可直接横向比较。与 top-1 一致率配合看更完整：KLD 低而 top-1 一致率高，说明量化在多数情况下不改变首选 token，但在低概率分支上仍有偏移，这类偏移在长链推理中可能被放大。

哪些GPU和运行时支持FP4

Blackwell加vLLM，而且只在社区容器里。

• 运行时：仅vLLM。卡片说NVFP4 scale factors用了"一种新的无损压缩格式"，"上游vLLM对此格式的支持尚未落地"，必须用Local Inference Lab社区组织构建的两个容器之一。
• 已验证硬件：RTX PRO 6000 Blackwell（单卡）和DGX Spark。
• 未提及：RTX 5090、任何Hopper或Ada卡、SGLang、TensorRT-LLM、llama.cpp、Ollama。"支持的硬件微架构：NVIDIA Blackwell"就是全部清单。

原始Qwen权重则支持vLLM、SGLang、Transformers和TokenSpeed，SGLang在发布当天就有day-0支持。

NVIDIA这个版本也不是唯一的NVFP4 checkpoint。LMSYS博客提到RadixArk/Qwen3.8-Flash-Next-NVFP4，一个SGLang checkpoint，LMSYS说和模型同日可用。它是普通的训练后量化：只量化路由专家，用128篇截断到512 tokens的CNN/DailyMail文章做校准，在GB300和B300上验证。LMSYS报告B200 TP4加MTP时batch size 1达到540 tok/s。这是数据中心硬件，但说明NVIDIA的QAD在跟什么竞争：一边是128条短校准样本，一边是500M tokens的蒸馏。

Blackwell 是 NVIDIA 的 GPU 微架构代际名称，对应数据中心级的 B100、B200、GB200、GB300 和桌面级的 RTX PRO 6000 Blackwell、RTX 50 系列等。其第五代 Tensor Core 原生支持 FP4 矩阵运算，并引入块缩放格式的硬件加速路径，NVFP4 的 scale factors 解压和乘加可以在 tensor core 内完成，这是 Hopper 与 Ada 架构不具备的。文章所说的"Blackwell 独占"正源于此：即便把权重文件放到 Hopper 卡上，也缺少对应的指令与容器运行时支持，无法执行 FP4 计算。DGX Spark 使用 GB10 超级芯片，同属 Blackwell 家族，因此被列入已验证硬件。

n-gram 嵌入表（PLE） 是文章中反复出现的 offload 对象。PLE 通常指 Per-Layer Embedding 或类似的词元级嵌入结构，模型为每个 token 维护额外的高维向量表，参数量可达数十亿。这部分是纯查表操作，不参与矩阵乘，因此可以放到 CPU 内存甚至磁盘上按需读取，而不显著拖慢 GPU 计算。NVIDIA 通过 VLLM_PLE_CPU_OFFLOAD 将 51B 的 PLE 表移出显存，腾出的空间用于 KV cache，这才有了卡片宣称的 850K tokens FP8 KV cache。代价是每次前向都可能触发 CPU 到 GPU 的数据搬运，实际吞吐受 PCIe 带宽和内存延迟影响，长上下文场景下需实测。

运行命令：RTX PRO 6000 Blackwell

卡片上的简化一行命令，原样复制：

docker run -d --name qwen38-tp1 --init --gpus '"device=0"' \
  --restart on-failure --network host --ipc host --shm-size 32g --stop-timeout 30 \
  --ulimit memlock=-1 --ulimit stack=67108864:67108864 \
  -v model-cache:/root/.cache/huggingface -v qwen38-runtime:/cache \
  -e PROFILE=qwen38-flash-next -e PORT=8000 \
  ghcr.io/local-inference-lab/vllm:release-10152026

即使你用一行命令，也建议读一下卡片上的详细版，它展示了profile开了什么：--quantization modelopt_mixed、--kv-cache-dtype fp8、--max-model-len 262144、--max-num-seqs 16、--gpu-memory-utilization 0.975，以及"num_speculative_tokens":3的MTP投机解码。显存利用率0.975几乎不留桌面余量，要么用无头机器，要么另配一张卡负责显示。

运行命令：DGX Spark

先在宿主机设好HF_TOKEN，然后启动容器：

mkdir -p $HOME/.cache/huggingface $HOME/.cache/vllm $HOME/.cache/flashinfer $HOME/.triton $HOME/.cache/b12x

docker run --rm -it \
  --gpus all \
  --ipc host \
  --network host \
  --shm-size=16g \
  --ulimit memlock=-1 \
  --ulimit stack=67108864 \
  --security-opt seccomp=unconfined \
  --security-opt apparmor=unconfined \
  -e HF_TOKEN=$HF_TOKEN \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v $HOME/.cache/vllm:/root/.cache/vllm \
  -v $HOME/.cache/flashinfer:/root/.cache/flashinfer \
  -v $HOME/.triton:/root/.triton \
  -v $HOME/.cache/b12x:/root/.cache/b12x \
  --entrypoint /bin/bash \
  eugr/spark-vllm-b12x:latest

容器内卡片导出14个变量（包括VLLM_PLE_TABLE_MEMORY="disk"和CUTE_DSL_ARCH="sm_121a"），然后跑vllm serve nvidia/Qwen3.8-Flash-Next-FP4-Local，参数为--load-format b12x、--max-num-seqs 8、--gpu-memory-utilization 0.8和4个投机token的MTP。建议直接从卡片复制整块，不要手敲。

两套配置都用--reasoning-parser qwen3和--tool-call-parser qwen3_xml，工具调用通过8000端口的OpenAI兼容API可用。Qwen推荐thinking模式用temperature=1.0, top_p=0.95, top_k=20。

不在Blackwell上的便宜替代

GGUF加llama.cpp。Unsloth的运行命令：

unsloth run --model unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

Unsloth速度帖里的人都用的不是Blackwell工作站。有人报告RTX 3090配128 GB DDR4跑Q4_K_XL解码19 t/s；有人用带Metal优化的llama.cpp分支在M1 Ultra 128GB上跑IQ4_NL，depth 0时39.48 t/s；还有人在RTX 6000 PRO上跑Q4_K_XL，TG 59.70 t/s。Unsloth文档引用单张RTX 6000 PRO加MTP达到170 t/s，基线100 t/s，但没说明量化级别。NVIDIA对FP4版本一个吞吐数字都没发，对一个面向本地推理的发布来说这算是奇怪的遗漏。

GGUF 与 llama.cpp 是本地推理中与 vLLM 路线相对的生态。GGUF 是 llama.cpp 使用的单文件模型格式，把权重、tokenizer、量化元数据和元信息打包在一起，支持从 Q8_0 到 IQ1_S 等多种量化级别，并可在 CPU、Metal、CUDA、Vulkan 等后端上运行。由于格式开放、工具链成熟，社区量化发布者如 bartowski、Unsloth 能快速产出多档量化文件，用户按显存和精度需求选择即可。llama.cpp 主线合并速度快，不依赖厂商专有容器，也不需要导出大量环境变量，这与 NVIDIA FP4 版本的部署门槛形成鲜明对比。缺点是对新架构的算子优化通常滞后于 vLLM，MoE 与混合注意力的调度效率可能不如专用运行时，因此吞吐数据需要在同一硬件和量化级别下才能公平比较。

我的看法

如果你手里有RTX PRO 6000或DGX Spark，可以试试NVIDIA这个版本。QAD是真实的方法，0.7点下降差不多是4-bit级别量化能做到的水平。其他人还是用GGUF吧，它在主线llama.cpp上跑，用你现有的硬件，一个环境变量都不用导。等上游vLLM合并那个scale格式后再回看，因为那55个变量的设置是最不想长期维护的部分。

所以问题留给你：你信任厂商的FP4量化，还是更信unsloth和bartowski的社区GGUF？有没有人把FP4-Local和Q4_K_XL在同一批prompt上并排跑过，看出质量差异？欢迎贴数字，尤其是图像输入，因为NVIDIA没给。

来源

• nvidia/Qwen3.8-Flash-Next-FP4-Local模型卡
• Qwen/Qwen3.8-Flash-Next模型卡
• Qwen博客：Qwen3.8-Flash-Next
• Unsloth：Qwen3.8-Flash-Next本地运行指南
• bartowski/Qwen3.8-Flash-Next-GGUF
• Unsloth GGUF速度讨论帖
• LMSYS：Day-0 SGLang支持
• RadixArk/Qwen3.8-Flash-Next-NVFP4