压测配置

本次压测对比原生与 3 种投机解码方案在 Qwen3.6-35B-A3B 上的吞吐、延迟与接受率。所有服务运行在同一台 4 × NVIDIA L20X (144 GB) 机器上，每张卡承载一个 vLLM 服务（TP=1），对 4 个服务串行压测。

1.1 部署的 4 个服务

使用 vLLM 官方镜像：hub.docker.alibaba-inc.com/aone-base-global/vllm-openai:v0.21.0 部署服务，确保环境统一。

1.2 vLLM 统一参数（4 个服务一致）

• --tensor-parallel-size 1 — 单卡 TP
• --max-model-len 32768
• --max-num-seqs 64 / --max-num-batched-tokens 16384 — 为 DFlash spec=15 留够批 token 预算
• --gpu-memory-utilization 0.85
• --trust-remote-code --reasoning-parser qwen3

1.3 evalscope 客户端参数

• --max-tokens 512（每条请求最大输出）
• --temperature 0（确定性输出，便于复现）
• --stream（SSE 流式以测量 TTFT）
• 关闭 thinking：--extra-args '{"chat_template_kwargs": {"enable_thinking": false}}'
• 并发档：1 / 4 / 16 / 32
• 对应请求总数：32 / 80 / 160 / 320

1.4 数据集

规划压测时，优先选投机解码论文标准集（MT-Bench / HumanEval / GSM8K / CNN-DM）覆盖 4 类典型分布，避免用 random 数据集——投机解码效果对数据分布敏感，随机 token 上拿不到加速。

1.5 关键指标说明

• 输出吞吐（Output tok/s）：每秒生成的输出 token 总数。
• TTFT（Time To First Token）：从请求发出到第一个 token 返回的延迟。
• TPOT（Time Per Output Token）：除去 TTFT 后，每个输出 token 的平均生成耗时。
• 真实接受率（Real Acceptance Rate）：每个 draft token 被接受的概率，由 vLLM /metrics 直接读取（spec_decode_num_accepted_tokens_total / spec_decode_num_draft_tokens_total 在压测前后做差）。
• Mean Acceptance Length（MAL）：每次 verify 步骤实际产出的 token 数（含 base token），公式 MAL = 1 + accepted_draft_tokens / drafts。这是投机解码论文里的标准指标。
• evalscope 接受率：evalscope 根据 SSE chunk 数推断的近似接受率（1 - 1 / Decoded_Tok_per_Iter），仅作对照。当 num_speculative_tokens > 3 时此估计常会显著偏离真值。

压测结果

总览

2.1.1 各数据集最大吞吐加速比

2.1.2 Mean Acceptance Length

每次 verify 实际产出的 token 数（含 base token）；对所有并发档求均值

2.1.3 真实接受率（vLLM /metrics 指标）

图表

2.2.1 输出吞吐 tok/s

数值越大越好

2.2.2 Mean Acceptance Length

每次 verify 实际产出 token 数，含 base token

并发为 4 时，DFlash 的 MAL 跌到 1 附近，应该是 vLLM 实现存在 bug，输出变为重复字符，可以忽略。

2.2.3 接受率（vLLM 指标）

2.2.4 各位置 draft token 接受率衰减曲线

2.2.5 TPOT

2.2.6 TTFT

总结

3.1 加速效果横向对比

各投机解码方案在所有 (数据集 × 并发) 组合上的平均输出吞吐加速比，相对不开投机采样：

1. MTP（自带，step=5）：平均 1.86×
2. Eagle3（step=5）：平均 1.81×
3. DFlash（step=15）：平均 1.49×

3.2 数据集敏感性：投机解码收益与数据分布强相关

按 3 种投机方案的平均真实接受率排序（接受率高的数据集，3 种方案都能拿到更大的加速比）：

1. HumanEval（代码补全）：平均接受率 63.7%
2. GSM8K（数学链式推理）：平均接受率 55.6%
3. MT-Bench（多轮对话）：平均接受率 33.5%
4. CNN-DailyMail（长文本摘要）：平均接受率 28.6%

规律：结构化、模式重复的文本（代码、数学公式）接受率最高，开放生成（多轮对话、自由摘要）接受率较低。这与投机解码的核心机制一致，草稿模型在分布更窄的语料上更容易猜中下一批 token。

例子：

HumanEval 直接给代码补全：“def f(x):\n return ...” —— 大量语法 token 重复

GSM8K 直接给求解：“Step 1: ... = 12\nStep 2: ...” —— 数字 + 算式 + 固定模板

3.3 选型建议

• 首选 MTP：模型自带草稿头、在所有数据集上加速比稳定（本次平均 1.86×、峰值 2.79×@HumanEval conc=32），且接受率最高（0.45-0.86）。
• Eagle3 备选：与 MTP 速度接近，在代码/数学场景几乎打平（HumanEval 2.82× / GSM8K 2.72×），但需要单独训练并部署 Eagle3 草稿权重。如果模型没有自带 MTP，EAGLE3 是首选。
• DFlash 目前无优势：效果大幅低于预期，吞吐远不如前两者，虽然支持并行预测，但每一步的接受率都很低，远不如前两者。

3.4 备注

• 当前 Eagle3 模型训练时直接使用了 open-perfectblend 数据集中的 140 万条数据，考虑时间关系，没有对这 140 万条数据使用 Qwen3.6-35B-A3B 模型做 regenerate 后再训练。如果使用重新生成的数据，还会有 5% 以上的提升。
• 本次测试关闭了 thinking，如果开启 thinking，加速效果要降低不少。这主要是因为 thinking 输出的 reasoning 看似模式化，但本质是自由发挥的自然语言推理，token 分布广，不容易猜中。

附： 每个数据集的详细数据

4.1 数据集：MT-Bench（多轮对话）

4.1.1 原始指标

4.1.2 吞吐加速比（相对 native）

4.2 数据集：HumanEval（代码补全）

4.2.1 原始指标

4.2.2 吞吐加速比（相对 native）

4.3 数据集：GSM8K（数学链式推理）

4.3.1 原始指标

4.3.2 吞吐加速比（相对 native）

4.4 数据集：CNN-DailyMail（长文本摘要）

4.4.1 原始指标

4.4.2 吞吐加速比（相对 native）