Qwen3.8-27B 四方横评:昇腾 910B3、A100 与 PPU

本文来源： ModelDoctor（公众号：ModelDoctor）
原文链接： https://mp.weixin.qq.com/s/N71xEbg6GJURbcjZ_XA2Hw
发布时间： 2026-08-25 15:27

作者： ModelDoctor　　发布时间： 2026-08-25 15:27

本次横评在同一模型、同一配方、同一压测工具与同一批场景规格下执行四轮,构成三条横比线:

每条线只引入一个变量,因此观测到的差异可归因于该变量。

第三条横比线源于横评过程中的一次异常排查:PPU 首轮的 MTP 接受率出现断崖式下降,定位后确认为引擎缺陷,更换配方重跑,该轮数据构成本条横比线。

下面先交代装置与测试方法,给出全量数据,再按三条横比线逐条解读。

一、实验装置与校准

四轮的被测对象、硬件与引擎、五个用例的规格与并发、以及各轮引擎启动日志中的实测 KV 池:

跨硬件性能对比的主要风险在于两侧测量口径不一致:压测工具口径、投机解码是否实际生效、前缀缓存状态,任一项差异均可造成数十个百分点的偏差,且不会触发错误。

因此开跑前先将 A100 一轮与同型号卡上已公开的一组 Qwen3.8-27B 实测数据🔗1对账。判据取单流延迟用例——五个用例中唯一规格明确、可严格对账的一个:

三项偏差都在 7% 以内。

第二个校准点是 MTP 接受率:

四轮逐用例相差不到 3 个百分点。接受率由模型决定,不随硬件与量化改变;四轮一致,可确认投机解码在四轮中均已生效。

二、测试方法

压测工具:guidellm🔗2 0.7.3,四轮同一份脚本、同一份配置,通过 OpenAI 兼容接口打服务端。

数据集:五个用例均由 guidellm 的 synthetic_text 生成,token 规格与并发见图 1,四轮之间逐字一致。短对话用例是按公开数据反推的合成分布(87±120 入 / 250±180 出),不是真实 ShareGPT 数据集。

每轮的执行规程:

1. 起服务,等 /health 就绪
2. 每个用例开跑前打一次 /metrics 快照
3. 跑 guidellm,固定 --seed 0,max_requests 与 max_duration 双约束
4. 跑完再打一次 /metrics,取增量得到该用例的前缀命中率、抢占次数、MTP 接受率
5. 落盘 bench.json 原始件 + 前后快照 + 完整启动参数

指标口径:TTFT = 首 token 延迟;TPOT = 逐输出 token 延迟(不含首 token);E2E = 单请求端到端;分位数取自 guidellm 的 successful 请求集合。四轮全部用例 rc 为 0、无失败请求。

MTP 接受率不是压测工具的输出项,而是从引擎计数器 spec_decode_num_accepted_tokens / num_draft_tokens 在测量点前后取差值算出的,四轮各组数均通过计数器自洽校验。

四轮 × 五用例的完整指标如下,后面三节是对它的分线解读:

三、横比一:三种卡

权重同为 BF16、配方同一份,变量仅为硬件。四轮均为 TP2,每方两张卡。

A100 与 PPU 处于同一量级。单流两项指标均为 1.05×(TTFT 99.0 vs 94.6 ms,逐 token 7.66 vs 7.3 ms)。高并发四个用例中,高并发长输出与长上下文预填充用例 PPU 更优(0.64× / 0.94×),短对话与满载吞吐用例 A100 更优(1.29× / 1.48×);输出吞吐 A100 在全部用例领先。二者在不同负载形态下各有优势,无法归结为单一倍数。

PPU 与 A100 的软件栈同源,依据为引擎自报值:device_config=cuda、nccl 2.27.3、all-reduce 走 PYNCCL、vLLM 官方主线 0.26.0(A100 为 0.25.1)。

910B3 的首 token 显著偏高:单流延迟用例 514.0 ms,为 A100 的 5.43×;而同一用例的逐 token 仅差 2.04×。两个指标的倍数不在同一量级,成因见第六节。

四、横比二:两个权重文件

同一套 910B3(2 张卡)、同一份配方,只把权重从 BF16(52 GB)换成 w8a8(30 GB)。

权重由 52 GB 降至 30 GB,释放的显存进入 KV 池(+46%,658,178 → 964,013 token)。结果呈两个方向:

首 token 在全部用例下降:高并发长输出用例 TTFT 由 65.8 s 降至 11.6 s(−82%),满载吞吐用例抢占由 103 次降至 0。

但逐 token 在高并发用例上升 21–31%。机制:TTFT 下降使单位时间进入系统的请求增多,批量增大,KV 压力回升。抢占次数由 272 增至 372 支持这一解释——池容量提高,但请求增量更大。

因此 w8a8 并非无代价的加速,而是一次交换:以逐 token 延迟换取首 token 延迟与吞吐。低并发用例两项指标同时改善(−17% / −25%),长上下文预填充用例无收益(±4%,该用例抢占为 0,不受 KV 约束)。

五、横比三:两个配方

本条横比线源于一次异常排查。

PPU 首轮五个用例中,除单流延迟用例(91.32%)外,MTP 接受率均降至 0.00–0.54%:长上下文预填充用例 76,500 个草稿 token,接受 0 个;而另外三轮同用例为 44–62%。该结果不符合预期,遂展开定位。

先排除采样与内容两项。固定负载形态、仅改温度:temperature=0 为 73.62%,1.0 为 43.97%,0.1–1.0 之间无单调趋势,均在 40–50% 区间——温度使接受率下降一档,但不产生 0。更换提示词同样无效:连贯文本与随机词串逐用例一致。

决定变量是并发,且呈断崖而非渐降。固定提示词与温度,仅扫并发:

并发 20 至 24 之间下降两个数量级,此后稳定在 ~1%。而 24 正是该引擎 CUDA graph 捕获档位表 [1, 2, 4, 8, 16, 24, 32, …] 中 16 之后的下一档。

将 cudagraph_mode 由 FULL_AND_PIECEWISE 改为 PIECEWISE,其余配置不变,断崖消失:全并发段稳定在 53–56%。

vLLM 0.26.0 的 full CUDA graph decode 路径,在 MTP 下批大小 ≥24 时接受率塌到 ~1%。上游 vllm-project/vllm#48494 报告的是同一路径上的 capture 崩溃,其规避方案同为回退至 PIECEWISE;症状不同,规避方案一致。

更换图模式对性能的影响不止于接受率:

图内存由 32.16 GiB/卡降至 0.16 GiB,KV 池由 560,208 增至 1,504,844(2.69×)。并发 1 的单流延迟用例几乎不变(97.4 → 99.0 ms),与断点在并发 24 一致;高并发四个用例的首 token 下降 42–84%、输出吞吐上升 13–235%。逐 token 延迟并非全面改善:长上下文预填充用例由 363 ms 升至 797 ms、满载吞吐用例由 205 ms 升至 313 ms,这两个用例的 KV 池扩大后批量随之增大。

横比一中 PPU 的全部数据取自更换配方后重跑的一轮。三条横比线中,本条决定了横比一的输入配置。

六、910B3 首 token 差距的成因

910B3 两轮的首 token 显著偏高:单流延迟用例 514.0 ms,为 A100 的 5.43×;同一用例逐 token 仅差 2.04×。

两个指标受不同因素约束。逐 token 受访存带宽约束,910B3 的 HBM 带宽为 A100 的 1/1.70,按规格应慢 1.70×,实测 2.04×,超出 20%,在合理范围内。首 token 为算力密集,910B3 的纸面 BF16 算力(313 TFLOPS)与 A100(312 TFLOPS)基本持平,按规格不应差 5.43×」。纸面规格无法解释该缺口。

该缺口与三轮的图捕获配置一致:

将 TTFT 按 固定项 + 每 token 边际项 拟合(数据来自另一轮根因定位实验,在 128–32,768 token 区间扫描):A100 为 130 ms + 13.05 μs/token,910B3 为 384 ms + 16.76 μs/token。边际项仅差 1.28×,差距集中在固定项。

该 384 ms 的来源已实测确认:vllm-ascend 在平台初始化阶段关闭可打断图且无配置开关,prefill 的 64 层逐个 eager 下发,单次前向 3,357 个 kernel,实测下发速率约 100 μs/kernel。

该开销按每次前向计,而非按每请求计,因此可被摊薄:prompt 由 128 增至 32,768,差距由 5.36× 收敛至 1.95×;并发由 1 增至 16,收敛至 2.23×。单流延迟用例的 5.43× 是固定开销占比最高的工作点,不代表常规负载下的表现。

七、测量边界

各轮使用各自的最优配方,不做强制对齐。四轮的引擎版本与图模式确实不同(vLLM 0.25.1 / 0.26.0 / vllm-ascend 0.23.0rc1;FULL_AND_PIECEWISE / PIECEWISE / FULL_DECODE_ONLY),但这是有意的:横评比较的是「各硬件在其当前可用的最佳配置下能达到什么水平」,而非「同一份参数在不同硬件上的表现」。若某一轮的配方尚未调到最优,该差距也应计入该方案的评价——横比三就是一个实例:PPU 首轮配方存在缺陷,更换后五个用例全面改善。

五个用例中仅单流延迟用例的 token 规格明确,其余四个由公开数据反推,短对话用例为合成分布而非真实数据集。因此跨来源比值不可靠,本文的比较仅在这四轮之间进行。

接受率仅在固定温度下可比。本文使用 guidellm,该工具不发送 temperature,测得的是模型默认采样下的值;sglang.bench_serving 默认发送 temperature=0,同一部署实测相差一档(73.62% vs 43.97%),且两个默认值均不在命令行上显示。

前缀缓存四轮均开启,但合成随机 prompt 之间无共享前缀,实测命中率均为 0%。因此吞吐数据不含缓存带来的虚高,同时也未覆盖真实 agent 场景下的高命中情形。

复现所需配方。下图为四轮的完整启动命令,橙色行即各轮独有的参数:

关于作者

聚焦 LLM 推理的生产工程:让 vLLM / SGLang / MindIE 在国产卡、多集群网关(Higress)、P/D 分离下稳定落地。长期做推理编排(Dynamo / llm-d / AIBrix)、runtime 数据面验证、可观测性与 SRE。相关实践沉淀成部署配方库 recipes.mcpinfra.net 与压测工具 ModelDoctor。让推理服务从「能跑」到「敢上线」。

文中数字均来自单次真实压测,并非普适「标准答案」——换数据集 / 参数,结论可能就变。欢迎拿你自己的流量复现、指正。

参考链接

🔗1  https://mp.weixin.qq.com/s/uLnPevDpk_70FSFMKaWcSQ

🔗2  https://github.com/vllm-project/guidellm

本文转载自微信公众号「ModelDoctor」，仅供学习交流使用。