本文由 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 为例）：
bash
--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 的表现「两面性」很明显：
- 单并发 / 低并发 ：投机解码收益显著，实测能到原生 GLM-5.2-FP8 的 1.2--2.2 倍，适合交互式、对单路吞吐和响应速度敏感的场景。
- 高并发：本次这份外置草稿模型在 Random 数据集上的接受率偏低，吞吐几乎没有本质提升，甚至低于原生 MTP 方案，暂不建议直接用于同类高并发生产。
- 建议 ：就本次实测的模型与场景来看，现阶段更适合科研验证与低并发场景；高并发生产上线，建议等待在这类负载上接受率更高的草稿模型版本。（以上仅针对本次所用草稿模型与数据集，不代表 DSpark 投机解码方案本身的上限。）
得益于 GPUStack 可插拔的 vLLM 后端，无论是加镜像版本、挂外置草稿模型还是切换对比方案，整个过程都在 Web 界面点几下就能完成，Day 0 就能把新模型跑起来做客观评测。
实测环境：8 卡 H20-141G ｜ GPUStack v2 ｜ vLLM v0.25.0（25-custom 镜像）
感谢社区用户的实测分享。