GLM-5.3-Flash本地部署：NVIDIA FP4需两张Blackwell

GLM-5.3-Flash 是一个 320B 总参数、每 token 激活 18B 的多模态 MoE 模型，MIT 许可，支持 1M token 上下文。NVIDIA 为它发布了一版名为 FP4-Local 的检查点，号称能在“本地”跑——但翻开模型卡会发现，验证过的硬件只有两种：两张 RTX PRO 6000 Blackwell，或两台 DGX Spark。

“Flash”在这个版本里指的是 API 上每 token 便宜，不是模型变小；而“Local”这个词，承担的营销成分比技术成分更多。

GLM-5.3-Flash 到底是什么

上一代 GLM-4.7-Flash 是 30B-A3B 的文本 MoE，单张消费级 GPU 就能跑。GLM-5.3-Flash 完全不是同一个量级：320B 总参数、18B 激活，Z.ai 称其为 GLM-5 系列首个原生多模态模型，支持图文输入。

架构上采用混合稀疏加线性注意力，外加 Manifold-Constrained Hyper-Connections（mHC）。上下文窗口 1M token，reasoning_effort 可选 low、high、max，默认 max。

Z.ai 宣称它在编程和 agent 基准上接近 Claude Opus 4.8，且价格只有 GLM-5.2 的十分之一。这些是厂商数字，模型卡给出的 Terminal-Bench 2.1 为 84.3、DeepSWE 为 63.4，可以自行对照。

两个 NVIDIA 量化版本，别搞混

NVIDIA 发布了两份量化权重，用途完全不同。

nvidia/GLM-5.3-Flash-NVFP4 是常规的训练后量化（ModelOpt 0.47.0），在 GB200 上测试，示例用 4 路张量并行，面向数据中心。

nvidia/GLM-5.3-Flash-FP4-Local 才是本文关注的版本。它用上了量化感知蒸馏（QAD）：BF16 模型当教师，学生模型的路由专家权重在每次前向时被量化到 NVFP4，梯度更新的是底层 BF16 权重。换句话说，量化模型被训练去恢复量化破坏掉的能力，这是一次性舍入做不到的。

精度配比上，解码器路由专家用 NVFP4（E2M1 数值、E4M3 块缩放），解码器注意力和视觉注意力用 MXFP8，视觉 MLP 与 merger 线性层用 NVFP4，其余视觉张量和 norm 保持 BF16。

NVFP4 是 Blackwell 张量核格式，模型卡明确指出 Blackwell 是唯一支持的微架构，没提 Hopper 或 Ampere。卡上还提到缩放因子用了“新的无损压缩格式”，这正是上游 vLLM 暂时无法加载、必须用社区容器的原因。你手里是 H100 或 4090，无论显存多大，这个检查点都跟你无关。

量化感知蒸馏（QAD） 与常见训练后量化（PTQ）的区别值得展开。PTQ 是一次性的舍入：把训练好的 BF16 权重直接压到低精度，然后测一测掉了多少点，掉多少就是多少。QAD 在量化过程中保留梯度更新——前向时用一个“假量化”的算子把权重舍入到 FP4 再反量化回来，反向时梯度穿过这个算子写回底层 BF16 权重，再由 BF16 教师模型提供软标签约束。学生模型因而被显式训练去补偿量化误差，尤其是在路由决策、注意力数值这些对精度敏感的位置。代价是蒸馏需要额外的训练算力和数据管线，这也是 NVIDIA 能给出 0.8 点差距、而多数 GGUF 发布只报文件体积的原因。

显存账：FP4-Local 并不比 4-bit GGUF 小

把各版本的体积与内存需求摆在一起，结论会有点反直觉（GiB 与 GB 混用是因为原始来源就混用，166 GiB 约合 178 GB）：

版本	体积/内存	运行平台
BF16（Unsloth GGUF 仓库）	642 GB	多卡服务器
Q8_0 GGUF	341 GB	服务器/大内存机器
NVIDIA FP4-Local	约 166 GiB 显存	2× RTX PRO 6000 Blackwell、2× DGX Spark
UD-Q4_K_XL GGUF	200 GB	llama.cpp，内存+显存足够即可
UD-IQ4_XS GGUF	157 GB	llama.cpp
UD-Q2_K_XL GGUF	109 GB	llama.cpp
UD-IQ1_S GGUF	93.1 GB	llama.cpp
MLX 4-bit	约 204 GB 磁盘、224 GB 内存	Apple Silicon

两张 RTX PRO 6000 合计 192 GB 显存，扣掉约 166 GiB 权重和运行时开销，NVIDIA 验证配置还能放下 1.8M token 的 FP8 KV cache；双 Spark 方案（各 128 GB）能到 2M token。线性注意力层是百万上下文在这套硬件上不至于成为空谈的原因。

关键点在于：FP4-Local 并不比 4-bit GGUF 小，IQ4_XS 是 157 GB。FP4 真正买到的是 Blackwell 上的原生张量核计算，以及一个公开的精度数字——后者才是值得关注的部分。

精度损失：两个基准上几乎为零

FP4-Local 模型卡给出的对比：

精度	GPQA Diamond	ToolEvalBench
BF16	92.1%	91.9%
FP4-Local	91.3%	92.4%

GPQA 掉 0.8 个点，工具调用反而涨 0.5 个点。PTQ 版 NVFP4 在更多基准上也是类似故事：GPQA Diamond 0.9211 对 0.9217，MMMU Pro 0.763 对 0.7688，Terminal Bench 2.1 的 0.8315 对 0.8258。

但对一个视觉语言模型来说，两个基准的评测偏薄。Local 卡上没有 MMMU，也没有长上下文数字，而这两处恰恰是激进量化最容易露馅的地方。同时，Unsloth 的 GGUF 只公布文件体积、完全不公布精度，纸面上你是在拿一个实测的 0.8 点下降，去对比一个“不知道”。

GPQA Diamond 是研究生级物理、化学、生物选择题集，每题由领域专家撰写并经过多轮校验，设计上要求模型无法靠检索或记忆作答，因此常被用作衡量“真实推理能力不掉点”的代理指标。ToolEvalBench 则评测函数调用与工具选择：给定工具描述和用户意图，模型需输出结构正确的调用参数。两者分别覆盖推理与 agent 行为，但都不测试视觉理解或长上下文检索——这也正是文章指出“两个基准对 VLM 偏薄”的原因。

在 RTX PRO 6000 上怎么起服务

Local 卡没有提供 TensorRT-LLM 或 SGLang 的说明，容器里的 vLLM 是唯一路径。

双卡 RTX PRO 6000 Blackwell 使用镜像 ghcr.io/local-inference-lab/vllm。模型卡的简化运行方式用标签 release-10152026 配 PRESET=glm53-tp2，但另一行又写成 release-10142026——拉取之前先确认哪个标签真实存在。

详细路径是带约 40 个参数的 vllm serve，从模型卡摘出的关键项如下（完整命令请从模型卡复制，不要照抄这里）：

vllm serve nvidia/GLM-5.3-Flash-FP4-Local \
  --tensor-parallel-size 2 \
  --decode-context-parallel-size 2 \
  --quantization modelopt_mixed \
  --kv-cache-dtype fp8 \
  --max-model-len 1048576 \
  --max-num-seqs 8 \
  --gpu-memory-utilization 0.985 \
  --attention-backend B12X \
  --moe-backend b12x \
  --linear-backend b12x \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --enable-auto-tool-choice \
  --default-chat-template-kwargs '{"reasoning_effort":"max","clear_thinking":false}' \
  --speculative-config '{"method":"mtp","draft_sample_method":"probabilistic","rejection_sample_method":"standard","moe_backend":"b12x","attention_backend":"B12X","num_speculative_tokens":3}'

--max-num-seqs 8 暴露了目标用户：一个开发者或一支小团队。

双 DGX Spark 方案则指向 eugr/spark-vllm-b12x:latest，跨两节点张量并行 2，--max-model-len 设为 500,000，--max-num-seqs 4，用 spark-vllm-docker 仓库里的 run-recipe.sh --setup 启动。模型卡提醒要先起 worker 再起 head 节点。

用于聊天场景时有两处值得调整：模型卡本身建议聊天用 clear_thinking: true，而这份配置给的是 false；另外 reasoning_effort 默认 max，如果延迟比最后一个基准点更重要，可以降到 high 或 low。

命令里的 --speculative-config 启用的是多 token 预测（MTP）投机解码：模型自带一个轻量草稿头，一次前向先猜出若干个后续 token，再由主模型并行验证，被接受的部分直接跳过逐 token 解码。对 18B 激活的大 MoE 来说，每步解码都要搬运大量专家权重，投机解码能把“每 token 一次权重读取”摊薄到“每几步一次”，是低并发场景下提速最显著的手段之一。num_speculative_tokens: 3 表示每次猜 3 个，取值过高会让接受率下降、反而拖慢。--decode-context-parallel-size 2 则是把 KV cache 沿序列维切到两张卡上，配合张量并行共同撑起百万级上下文。

没有 Blackwell：llama.cpp 或 MLX

llama.cpp 这边的状态比应有的更乱。Unsloth 仓库仍提示使用其 PR #27754 或 Unsloth Desktop，而该 PR 已于 2026 年 10 月 1 日关闭且未合并。维护者留言称：“支持已经进去了，但在 Unsloth 的 GGUF 更新之前不兼容。”所以在下载 200 GB 之前，先确认 Unsloth 文件是否已按上游 llama.cpp 重新上传，或者自己构建 PR 分支。

无论如何，先读该 PR 里的注意事项再动手，否则得到的输出可能是一堆乱码：设置 NVIDIA_TF32_OVERRIDE=0 并使用 -fa off。作者称 TF32 这个开关把测试夹具上的 top-1 一致率从 0.896 拉到 0.9995，而 flash attention 会把 F32 latent 转成 F16，MLA 无法容忍这一点。PR 同时加入了视觉塔，图像输入有覆盖。

NVIDIA_TF32_OVERRIDE=0 llama-server -hf unsloth/GLM-5.3-Flash-GGUF:UD-Q4_K_XL -fa off

考虑到这是 18B 激活的 MoE，把专家卸载到系统内存、注意力留在 24-32 GB 显卡上，是现实中的低成本路线。会慢，但跑得起来。

Mac 上有两个选择。MLX 路线要注意这是视觉模型，需要 mlx-vlm 0.6.17 或更新版本，而不是 mlx-lm。4-bit MLX 构建约 204 GB 磁盘、需要 224 GB 内存，对应 256 GB 的 Mac Studio。Orcarouter 的指南把 128 GB 机器导向约 102 GB 的“2bit-lite”构建，前提是先用 sudo sysctl iogpu.wired_limit_mb=114688 抬高 wired memory 上限，而模型卡本身也警告该精度下长代码生成不可靠。

Metal 上的 llama.cpp 现在也是选项。Issue #29867 曾报告 M5 上每 token 出现 1 到 9 秒的解码停顿，归因于融合的 Lightning Indexer 回退到 CPU。ggerganov 未能复现，并指向 master 上已有的修复；随后报告者测得低上下文约 31 t/s、高上下文约 25 t/s，且不再停顿。该 issue 仍未关闭，但如果你在旧构建上，先更新再怪模型。

值得为 FP4 买 Blackwell 吗

QAD 这部分工作是整个发布里最诚实的：NVIDIA 把量化模型训练回 BF16 的行为，并公开了差值，这是大多数 GGUF 发布做不到的。但“Local”这个标签的前提是你已经拥有两张工作站级 Blackwell 卡或两台 Spark，而且检查点依赖社区 vLLM 容器，同一张模型卡上还出现两个镜像标签。把它称作面向极少数已拥有该硬件人群的预览版，更符合实际。

如果你有一张 4090 加 192 GB DDR5，这个月真正能跑的其实是 UD-Q4_K_XL（200 GB 对 216 GB 总量），留给上下文的空间非常有限；在这台机器上，157 GB 的 IQ4_XS 是更稳妥的选择。

所以回到本地模型的老问题：带公开精度数字的 FP4，值不值得为它升级 Blackwell？还是说你手头的 Q4 GGUF 已经够用？如果你跑过其中任一版本，欢迎留下你的 tokens/sec 和硬件配置。