Day 0 实测｜在 GPUStack 上部署 GLM-5.2-FP8-DSpark

本文由 GPUStack 社区用户实测分享整理。GLM-5.2-FP8-DSpark 是在 GLM-5.2-FP8 基础上，通过挂载 RedHatAI 提供的外置草稿模型（Speculator）做投机解码（Speculative Decoding）的增强方案——同一份主模型权重，额外加载一个草稿模型，用来提升解码吞吐。社区用户在模型放出当天（Day 0）就在 8 卡 H20-141G 环境上，通过 GPUStack 完成了部署，并和原生 GLM-5.2-FP8 做了同硬件对比压测。

先把结论放在最前面，这次的结果比较「两面」，建议客观看待：

• 单并发：试验场里 DSpark 约 171 TPS，原生 GLM-5.2-FP8 约 72 TPS，快到约 2.2 倍；
• 高并发（64K/3K）：DSpark 输出吞吐 59.8 TPS，反而低于原生 MTP 方案的 99.2 TPS——外置草稿模型对 Random 数据集接受率偏低，高并发下不但没有提升，甚至出现回退；
• 一句话建议：就本次这份外置草稿模型 + GLM-5.2-FP8 的组合而言，目前更适合单并发 / 低并发、对首 Token 和交互式吞吐敏感的场景，或用于科研验证；高并发生产建议再等接受率更高的草稿模型版本。（以上结论仅针对本次实测所用的草稿模型与数据集，不代表 DSpark 投机解码方案本身的上限。）

下面是完整的部署与实测过程。

---

一、在 GPUStack 上部署 GLM-5.2-FP8-DSpark

DSpark 需要一个较新的 vLLM 镜像（v0.25.0）来支持外置草稿模型的投机解码。我们只需为 GPUStack 中可插拔的 vLLM 后端增加一个镜像版本，整个过程在 Web 界面上点几下即可完成。

① 进入「推理后端」，为 vLLM 添加版本

左侧菜单进入 推理后端，找到 vLLM 卡片点「编辑」，在「版本配置」里点「添加版本」，新增一个版本号为 25 的版本，镜像名称填写：

vllm/vllm-openai:v0.25.0

框架选择 CUDA，保存后即得到一个可选的 25-custom 版本。

② 新建部署，选模型与后端

回到 部署 页面，点右上角「部署模型」，按下图填写基本信息：

• 来源选择 ModelScope，仓库 ID 填 ZhipuAI/GLM-5.2-FP8
• 后端选 vLLM
• 后端版本选刚才添加的 25-custom

③ 配置后端参数

在「高级」里逐项填入后端参数（以 8 卡 H20-141G 为例）：

--max-model-len 131072
--tensor-parallel-size 8
--tool-call-parser glm47
--enable-auto-tool-choice
--reasoning-parser glm45
--enable-expert-parallel
--trust-remote-code
--gpu-memory-utilization=0.9
--max-num-batched-tokens 32768
--max-num-seqs 16
--speculative-config '{"model":"/var/lib/gpustack/cache/model_scope/RedHatAI/GLM-5.2-speculator.dspark","num_speculative_tokens":7,"method":"dspark"}'

关键在于 --speculative-config：method 设为 dspark，model 指向下载好的外置草稿模型路径。若引擎加载较慢，可加一个环境变量 VLLM_ENGINE_READY_TIMEOUT_S=3600 放宽就绪超时。

草稿模型下载地址：
https://modelscope.cn/models/RedHatAI/GLM-5.2-speculator.dspark

提交后实例进入 Running 即部署完成。

---

二、性能实测：DSpark vs 原生 GLM-5.2-FP8

在**相同硬件（8 卡 H20-141G）**下，分别从「单并发交互」和「高并发批量」两个角度做了对比。

场景 1：单并发（试验场交互）

直接在 GPUStack 试验场里对话，观察右下角实时输出吞吐。

GLM-5.2-FP8-DSpark： 输出吞吐 171.6 Tokens/s，稳定在 170+ 区间。

原生 GLM-5.2-FP8： 输出吞吐 71.81 Tokens/s。

单并发下 DSpark ≈ 171 TPS，是原生版本（≈72）的约 2.2 倍——这是投机解码在低并发场景最典型的收益。

场景 2：高并发批量（64K / 3K，10 请求）

用 GPUStack 内置基准测试跑 64K 输入 / 3K 输出、10 个请求（实测并发均值约 6）的 Random 数据集。这里的对比基线是同样开启了投机解码的原生 MTP 方案。

原生 MTP（method: mtp, num_speculative_tokens: 5）： 总吞吐 2216.39 Tokens/s，输出吞吐 99.22 Tokens/s，TPOT 63.92 ms。

DSpark（method: dspark, num_speculative_tokens: 7）： 总吞吐 1336.12 Tokens/s，输出吞吐 59.82 Tokens/s，TPOT 103.08 ms。

高并发场景下 DSpark 的输出吞吐（59.8）不升反降，明显低于原生 MTP（99.2），TPOT 也更高。原因是 RedHatAI 提供的外置草稿模型对 Random 数据集的接受率偏低——投机解码一旦命中率不足，额外的草稿计算反而会拖累整体吞吐。

数据汇总

场景	指标	原生 GLM-5.2-FP8	GLM-5.2-FP8-DSpark	对比
单并发（试验场）	输出 TPS	≈ 71.8	≈ 171.6	≈ 2.2×
高并发 64K/3K	总吞吐 (TPS)	2216.39（MTP）	1336.12	≈ 0.60×
高并发 64K/3K	输出吞吐 (TPS)	99.22（MTP）	59.82	≈ 0.60×
高并发 64K/3K	TPOT (ms)	63.92（MTP）	103.08	更高

总结

GLM-5.2-FP8-DSpark 的表现「两面性」很明显：

1. 单并发 / 低并发：投机解码收益显著，实测能到原生 GLM-5.2-FP8 的 1.2–2.2 倍，适合交互式、对单路吞吐和响应速度敏感的场景。
2. 高并发：本次这份外置草稿模型在 Random 数据集上的接受率偏低，吞吐几乎没有本质提升，甚至低于原生 MTP 方案，暂不建议直接用于同类高并发生产。
3. 建议：就本次实测的模型与场景来看，现阶段更适合科研验证与低并发场景；高并发生产上线，建议等待在这类负载上接受率更高的草稿模型版本。（以上仅针对本次所用草稿模型与数据集，不代表 DSpark 投机解码方案本身的上限。）

得益于 GPUStack 可插拔的 vLLM 后端，无论是加镜像版本、挂外置草稿模型还是切换对比方案，整个过程都在 Web 界面点几下就能完成，Day 0 就能把新模型跑起来做客观评测。

实测环境：8 卡 H20-141G ｜ GPUStack v2 ｜ vLLM v0.25.0（25-custom 镜像）

感谢社区用户的实测分享。