单并发提速73%，多并发能力达原来2.4倍：Qwen3.8-27B性能优化实践

在同一张 GPU 上，如何让大模型响应更快，同时承载更多请求？

Qwen3.8-27B 是企业私有化部署中较为常用的模型之一。围绕实际部署中的性能优化需求，我们选取其 FP8 量化版本，在单张 RTX PRO 6000 上开展了一轮推理优化。相比 vLLM 社区推荐配置，单并发生成速度从 79.6 提升到 137.7 token/s，提升约 73%。

多请求场景下，相比各速度档位对应的社区推荐配置，以单会话生成速度不低于 50 token/s 为目标时，单卡可支持的并发请求数从约 14 路增加到约 33–34 路，达到原来的约 2.4 倍；在 20 token/s 档位下，则从约 57 路增加到约 95–97 路，达到原来的约 1.7 倍。

这些收益来自多个层次：根据负载调整配置、减少投机解码的额外开销，以及修复引擎和底层计算路径中的性能问题。下面介绍其中的关键发现、优化方案及适用条件。

测试背景与优化目标

模型部署运行之后，性能需求通常分为两类：单个请求尽快完成生成，以及多个用户同时使用时保持足够的服务能力。两类场景面对的瓶颈不同，适合的优化方案也会变化。

本次实验使用以下环境：

项目	配置或要求
GPU	单张 RTX PRO 6000
模型	Qwen3.8-27B 的 FP8 量化版本
推理引擎	vLLM v0.32.0
对照基线	vLLM 社区推荐配置
测试数据	ShareGPT
质量验收	不更换主模型量化版本，GSM8K 准确率下降小于 1 个百分点

单并发测试关注生成速度；高并发对比则以单会话生成速度不低于 50、20 token/s 为目标，观察单卡可以同时处理多少路请求。

这里的并发请求数指同一张卡同时处理的请求数量，不等同于在线用户总数。评价服务能力时，还需结合首 token 等待时间和实际流量特征。

为保证比较可靠，我们对测量工具进行了标定，并通过重复启动和测试区分真实收益与编译、运行波动。下文各项优化的收益来自对应实验条件，不能直接相加。

单并发优化：提高每步有效产出

社区推荐配置默认使用 MTP 投机解码，草稿长度为 3。投机解码先生成多个候选 token，再由主模型验证，尝试通过一次验证产出多个有效 token。

这一机制能否提速，取决于每步接受多少 token，以及生成和验证草稿需要付出多少成本。

基线测量显示，每步平均产出约 2.26 个 token，需要读写约 36.9 GB 数据。其中，目标模型约占 26.9 GB，三步 MTP 草稿生成额外读取约 9.1 GB。草稿头每一步都需要读取完整词表，是额外数据搬运的重要来源。

我们沿着两个方向优化：

使用 DFlash2 替换 MTP，通过一次前向并行生成一块草稿，并调整草稿采样方式和长度，提高每步有效产出。在本次单并发负载下，草稿长度为 7 的综合表现更好；继续增加长度，新增的有效 token 已不足以抵消额外验证时间。
降低草稿生成和候选打分的数据读取开销，包括对 drafter 使用 FP8，以及采用“FP8 粗筛候选、BF16 精确打分”的两阶段方案。后者在减少数据读取的同时，控制了低精度打分对草稿接受率的影响。

在执行后端方面，单并发配置采用 Marlin，省去激活量化，并减少每步约 176 次 kernel 启动。在对应测试配置下，每步耗时缩短约 0.26 毫秒，吞吐提升约 2.9%。这一收益具有场景依赖性，高并发下的对比结果见后文。

最终，几个关键指标发生了以下变化：

指标	社区推荐配置	最终配置
每步产出 token 数	约 2.26	约 3.16
每步读写数据量	36.9 GB	30.2 GB
带宽利用率	81.5%	83.0%
单并发生成速度	79.6 token/s	137.7 token/s

带宽利用率变化不大，主要收益来自每步产出更多 token，并减少为这些产出搬运的数据。

算子优化：修复窄矩阵乘的异常耗时

定位瓶颈时，耗时占比最大的部分不一定拥有最大的优化空间。

在一组测量中，读取权重的矩阵乘占了每步约 89% 的时间，但已经接近带宽决定的下限。即使进一步改善实现，对整步耗时的收益也较为有限。

相比之下，GDN 中一个窄矩阵乘出现了明显异常：不开启 MTP 时，单次耗时约为 3 微秒；开启后，在特定的小矩阵形状下，耗时增加到约 26.5 微秒。

进一步深入 NVIDIA CUDA 计算库的执行路径，我们定位到其在 M=2–7 的区间选择了不合适的 kernel。针对这一形状改用 Triton GEMV 后，该部分累计耗时从每步约 1.27 毫秒降至 0.17 毫秒，在对应实验配置下带来约 4.9% 的吞吐提升。

这项优化从模型算子深入到 CUDA 计算库的执行路径，体现了底层性能问题定位与优化的价值。除了调整模型和引擎参数，还需要检查具体计算形状与底层实现是否匹配。整体计算量不大的算子，也可能因为执行方式不合适而成为可观的额外开销。

高并发优化：重新平衡算力与显存容量

高并发时，多个请求共享 GPU 资源。因此单并发下适合的方案，在高并发时需要重新评估。

例如，较长草稿能够提高每步产出，但被拒绝的候选 token 同样消耗验证算力。随着并发增加，这部分开销会挤占其他请求的计算资源。在本次测试中，单并发适合的 k=7，到了高并发场景下不如 k=2。

前述单并发测试中，Marlin 通过减少激活量化和 kernel 启动带来 2.9% 的收益，但在并发 64 时反而慢约 24%。因此，高并发配置改回了默认的 CUTLASS FP8 后端。

显存容量同样影响总吞吐。社区推荐配置默认支持 262K 长上下文并开启 prefix caching。在本次负载下，相关状态和缓存分配限制了可同时运行的请求数量，更多请求只能排队。

针对本次测试负载，我们进行了以下配置调整。其中，缩短最大上下文和关闭 prefix caching 用于展示这些参数对性能的影响，不是对所有应用场景的通用建议。

配置调整	优化目的	使用条件
最大上下文从 262K 调整为 8K	观察上下文上限对并发容量的影响	应用能够接受 8K 上下文上限
关闭 prefix caching	观察缓存开关对于状态占用和并发容量的影响	需要结合实际前缀复用收益判断
GDN 状态使用 BF16 存储	降低状态占用和读写量	需通过质量回归验证
草稿长度调整为 k=2	控制额外验证计算	针对本次高并发负载
调大 CUDA graph 捕获规模	减少超出捕获范围后的执行开销	与实际批次规模匹配

仅使用官方镜像、调整配置，50 token/s 档位下的总吞吐就从约 1.56k 提高到了 2.56k token/s。

这部分收益来自配置与业务需求的匹配。上下文上限和缓存开关都会影响应用能力，需要根据实际流量选择。

引擎优化：减少状态存储与内存浪费

完成配置调整后，我们继续检查投机解码在引擎内部带来的额外开销。

在本次测试版本中，GDN 投机解码需要保存多个中间状态，每验证一个 token 都会产生状态写入。草稿越长，状态占用和读写开销越大，既影响执行时间，也限制并发容量。

我们参考 replay 思路，将每个请求保留的状态槽减少为一份，同时记录本步各 token 的输入。下一步开始时，根据实际接受的 token 重放，恢复需要继续计算的状态。

这一改动以重放计算换取更少的状态存储与读写。在并发 64、k=7 的测试中，每层 GDN 耗时从约 0.66 毫秒降至 0.19 毫秒。收益会随并发和草稿长度变化，不能直接等同于整体吞吐提升。

另外，我们发现 drafter 与目标模型的 KV 块大小不匹配时，会产生明显的页面补齐浪费。通过设置 --block-size 64，可以绕开本次组合中的问题。在对应的 k=7 配置下，最大并发从 31 提高到 95，与容量分析的预测一致。

这一项最终只需要修改参数，但找到有效取值，需要理解引擎内部的内存组织方式。

优化结果与部署建议

从部署容量看，在两档单会话生成速度目标下，单卡可支持的并发请求数如下：

单会话生成速度目标	社区推荐配置并发请求数	优化后配置并发请求数	并发能力变化
≥ 50 token/s	约 14 路	约 33–34 路	达到原来的约 2.4 倍
≥ 20 token/s	约 57 路	约 95–97 路	达到原来的约 1.7 倍