SGLang 与 vLLM 在昇腾 910B4 上的一组对比实测:100K 上下文 Agent 负载

本文来源： vLLM 生产工程（公众号：vLLM 生产工程）
原文链接： https://mp.weixin.qq.com/s/RnwPOMv_pf-yWhAn44nrvA
发布时间： 2026-08-24 06:55

作者： vLLM 生产工程　　发布时间： 2026-08-24 06:55

推理引擎的评测口径正在换一批:从"单轮定长提示"换成"真实 coding agent 的多轮轨迹回放"。这套新口径的公开数据目前全产在 B300、GB300、H200、MI355X 上,昇腾侧还是一张白纸——正好自己填一张。

我们把它原样搬到昇腾 910B4 上跑了一遍:先照着公开资料的做法把 SGLang 那一臂跑出来,再用同一套工具去打 vLLM,最后把两组数放在一起看能读出什么。

前九节是这次实测的完整过程和数据,最后两节是边界与结论。家底先一次交代完:

一、公开资料在做什么,为什么值得在昇腾上跟一遍

这套新口径由三份公开资料撑起来:LMSYS 的 GLM-5.2 优化记录、Artificial Analysis 的 AA-AgentPerf、Thoughtworks 开源的 15,000 条 coding agent 轨迹。

跟一遍的理由很直接:方法是公开的、数据集是公开的、工具是公开的,而国内落地要回答的恰恰是"910B4 到底扛不扛得住 Agent 负载"。该有的材料都齐了,缺的只是有人去跑。

二、选型:模型、引擎版本、配方

模型选 Qwen3.6-27B-w8a8。它是 Mamba 混合架构,2 卡 TP2 起得来,--context-length 131072 能开满,单卡 60.53 GB 分下来是权重 17.22 GB + Mamba 状态缓存 13.62 GB + KV 15.16 GB + 运行余量 14.58 GB,KV 池 496,768 token。

引擎版本选 SGLang 0.5.17 的昇腾镜像 lmsysorg/sglang:v0.5.17-cann9.0.0-910b。集群里的 pod 访问不了 docker.io,先用本机 skopeo 搬运到内部镜像仓。

配方这一项有一处不对称,必须在看任何数据之前说清楚:vLLM 这一臂有官方配方可依,SGLang 那一臂没有。

跑完之后我们回头挑了其中两项做干预(KV 池、昇腾 env),结果在后面。两臂实际执行的启动脚本如下,vLLM 臂:

export ASCEND_RT_VISIBLE_DEVICES=2,3export HCCL_SOCKET_IFNAME=bond1export TASK_QUEUE_ENABLE=1export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True# 必须是 block size 的整数倍;Mamba 混合架构下 vllm-ascend 会把 block 强制成 1536export VLLM_PREFIX_CACHE_RETENTION_INTERVAL=4608python3 -m vllm.entrypoints.openai.api_server \  --model /models/Eco-Tech/Qwen3.6-27B-w8a8 \  --served-model-name q27 --host 0.0.0.0 --port 8077 \  --tensor-parallel-size 2 --quantization ascend \  --max-model-len 131072 --max-num-batched-tokens 8192 --max-num-seqs 64 \  --gpu-memory-utilization 0.9 \  --enable-prefix-caching --trust-remote-code --seed 1024 \  --reasoning-parser qwen3 \  --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \  --additional-config '{"enable_cpu_binding":true}'

SGLang 臂:

export TASK_QUEUE_ENABLE=1export PYTORCH_NPU_ALLOC_CONF=expandable_segments:Trueexport HCCL_SOCKET_IFNAME=bond1python3 -m sglang.launch_server \  --model-path /models/Eco-Tech/Qwen3.6-27B-w8a8 \  --served-model-name q27 --host 0.0.0.0 --port 6688 \  --tp-size 2 --device npu \  --attention-backend ascend \  --trust-remote-code \  --quantization modelslim \  --mem-fraction-static 0.76 \  --context-length 131072 \  --enable-metrics \  --reasoning-parser qwen3 --tool-call-parser qwen25 \  --chunked-prefill-size 16384 \  --max-running-requests 50

选型阶段有一条预判被实测推翻,值得单独提醒:SGLang 官方 14 份昇腾最佳实践里有 12 份带 --disable-radix-cache,很容易让人以为昇腾侧的 RadixAttention 不可用。实测能开、也真的命中——协议层原样重发命中 99.3%,多轮增长命中 99.2%。那些配方关掉它,更可能是 PD 分离或超长上下文吞吐场景下的取舍。看到官方配方里普遍带某个禁用开关时,先验证它是不是真的不可用,再决定跟不跟。

三、把负载定下来

工具、场景、数据全部取现成的:SGLang 官方 sglang.bench_serving,官方内置的 --dataset-name agentic-trace,数据来自 Thoughtworks 那份开源轨迹。

先把官方命令原样跑通,2 分 11 秒:

python3 -m sglang.bench_serving \  --backend sglang-oai-chat \  --dataset-name agentic-trace \  --dataset-path /tmp/agentic/trace_n256.json \  --base-url http://127.0.0.1:6688 \  --model /models/Eco-Tech/Qwen3.6-27B-w8a8 \  --num-prompts 4 --agentic-max-turns 8

agentic-trace 与普通多轮数据集的本质区别在这里:每轮只发该轮新增的非 assistant 消息,原始 assistant 回复丢弃,由服务端实时生成的回复顶替、再喂回下一轮历史。所以回放的是真实的上下文增长过程,而不是把一段固定长文本发过去。

两个坑要先避开。

SGLang 不附带 trace 数据。loader 只接受本地文件,官方文档写的是 /path/to/trace.json——方法开源,数据自备,得自己写转换脚本把上游 parquet 转成官方期望的格式。转换时注意上游 parquet 按 max_isl 排序,不打散只会拿到最短的那批;另外 Qwen 分词比上游用的 cl100k_base 少约 22%,上游标注的 ISL 不能直接当自己的 ISL 用,必须用服务模型自己的分词器重数。

墙钟由最长会话的轮数决定,不是请求总数。每条会话是串行链:第 N+1 轮必须等第 N 轮生成完,一条 100 轮的会话就是 100 次串行往返,加再多并发也压不动。实测反例:32 条完整会话(最长 100 轮)共 1,274 请求,单个并发档就要跑 2.3 小时。定负载时先定轮数上限,再定会话数。

据此定下正式负载:8 条会话,按"用最少轮数达到 100K"挑出(全集里能到 100K 的会话总轮数中位为 72,这 8 条只用 17–35 轮),共 187 请求,末轮上下文 101,074~118,965 token。并发档取 2 / 4 / 8。

四、SGLang 臂:第一组数据

三个并发档跑完,服务端 /metrics 增量口径:

第一件事是拿它跟公开资料对一下量级。LMSYS 那份 OpenHands 回放报的聚合前缀命中率约 92%,负载是 80K 输入、13 轮;我们这批会话更深(17–35 轮)、上下文更长(中位 107K),测到 86.4%。同一量级,方向也对——说明回放确实跑在了它该有的工作模式上,而不是退化成了一堆互不相干的长提示。

86% 和"Agent 负载命中率普遍 90% 以上"矛盾吗?不矛盾——这两个数说的是不同深度的会话。同一套工具、同一份数据集,换成浅一档的负载(16 条会话截到 32 轮、452 请求、末轮上下文 p50 23,774),三个并发档测到的是 93.0% / 93.1% / 93.5%,正落在那个区间里。

区别在选样。100K 这一档的 8 条会话是按"用最少轮数达到 100K"挑出来的——17~35 轮,而全集里能到 100K 的会话中位要 72 轮。命中率约等于 1 减去"每轮新增内容总量 ÷ 每轮完整提示总量":轮数越多、每轮增量越小,可复用的比例就越高。挑最陡的那批,等于主动把命中率的上限压低。

命中率能不能再高?做一次纯记账就知道这一档的天花板在哪。理论最小冷预填充量 = 8 条会话末轮 ISL 之和,减去其中由解码产生的回复 token(它们的 KV 在解码时已写入缓存,永远不需要预填充):

862,796 − 220 × Σ(轮数−1) = 862,796 − 39,380 = 823,416 token

SGLang 实测未命中 886,513 token,比这个下限高 7.7%;换算成命中率,这一档的上限是 87.40%,实测 86.43%,只差 0.97 个百分点。

⇒ 这一档拿不到 90%,不是缓存没做好,是负载本身只给到这么多可复用的量。"因为缓存不完美而多算"的部分最多只有 7.7% 可省。这笔账只覆盖重算这一条通道,不覆盖"池装不下就少跑并发"——后者产生零个额外未命中。

为什么生成 token 不算进下限:命中率 86% 本身就是证据。如果生成的回复不进缓存,前缀匹配会断在第 0 轮回复处,命中率只能是 2% 量级——8 条会话第 0 轮 ISL 合计仅 6,504 token。

五、同一套工具能不能打 vLLM

sglang.bench_serving 支持 --backend vllm-chat,是官方文档写明的用法。源码里 sglang-oai-chat 和 vllm-chat 映射到同一个请求函数、同一条 /v1/chat/completions 路径,载荷构造、TTFT 打点、ITL 累加是同一份代码,没有后端特化分支。工具里唯一的后端特化是 _extract_cache_from_sglext(),只影响 bench 自报的缓存字段。

接过来要处理三处,每一处都值得记一笔。

第一处:vLLM 这个构建没有 /reset_prefix_cache 路由,GET 和 POST 都返回 404。SGLang 靠 --flush-cache 每档从冷缓存起步,vLLM 只能改成每档重启引擎。副作用是 vLLM 每档从 num_reqs=0 全新起步,而 SGLang 引擎已累计服务过 2,502 个请求——这项不对等在方向上对 SGLang 不利。

第二处:bench 自报的命中率不能用。agentic_trace.py 的 loader 里:

prompt_len = int(conversation[0].get("prompt_tokens", 0))   # 只取第 0 轮

整条会话所有轮共用第 0 轮那一个值,而多轮提示是单调增长的。这个偏差有多大:同一份负载,只改数据文件里这个字段的填法,--cache-report 报出来的命中率能从 11.4% 跳到 96.0%,真实值两者都不是。同版本 Total input tokens 恒为 0,也印证多轮模式没做输入侧计量。

判断办法很简单:看 --output-details 落盘的 input_lens,如果是同一个数字重复 N 次,分母就不对。

所以吞吐和命中率全部改取服务端 /metrics 的窗口增量,两臂取同构指标——SGLang 用 cached_tokens_total / prompt_tokens_total,vLLM 用 prompt_tokens_cached_total / prompt_tokens_total。延迟类(TTFT / TPOT / ITL / E2E)是客户端实测,可以直接用。

第三处:冷启动核验不能信 OpenAI 标准响应里的 usage.prompt_tokens_details.cached_tokens——SGLang 这个字段恒为 0。要确认某一跑是不是真冷启动,只能取服务端 /metrics 增量。

六、两边的数能比吗:先过三道核验

请求数与生成 token。两臂均为 187 请求、41,140 生成 token,后者完全相等——--sharegpt-output-len 220 锁死的必然结果。

提示 token。这一项不等,而且不等的方式值得记一笔:

回放是确定性的、生成 token 三档完全相等,负载本身不应该随并发变化。SGLang 三档贴着独立记账(跨档漂移 0.09%),vLLM 三档低 1.9~2.9% 且随并发单调漂移 1.06%,成因指向 vLLM 侧的计量口径,不是负载本身。vLLM 的命中率与提示吞吐都以这个分母计算,带同量级不确定性;墙钟不经过该分母。

方差。同配方重复跑:吞吐类在 CC=4 / CC=8 稳(差 2.9% / 1.7%),CC=2 达 13.5%;TTFT 中位波动 7%~35%;TPOT 极稳(<0.3%)。吞吐类结论可靠,TTFT 的具体倍数应当按量级读,不按精确值读。

三道核验过了,两组数放在一起——八项指标 × 三个并发档,完整测量数据在下图里(墙钟含每档约 40 秒与引擎无关的固定开销,来自 kubectl exec;改用 bench 自报时长,CC=8 的比值从 2.21× 变成 2.30×;p95 由 187 个样本估计,重复跑实测漂移可达 16%)。

三件事值得挑出来说。

一、墙钟差 1.7× / 2.0× / 2.2×,而且随并发拉大,方向是 vLLM 更快。并发扩展性也不同:每翻一倍并发,SGLang 吞吐涨约 15%,vLLM 涨 27~38%。

二、差距全部集中在 TTFT,解码侧两臂基本打平。TPOT 在 CC=2 时 35.37 vs 35.27 ms,并发升高后 SGLang 反而更低(43.59 vs 47.58);ITL p95 三档 SGLang 均更低,优 20.1% / 14.0% / 3.4%。而 TTFT 中位差了 5.3~6.7 倍。

三、SGLang 前缀命中率三档均高约 2 个百分点,但这 2 个点没换来性能。它对应的实算量是实打实的:

SGLang 少算了 9~12% 的提示 token,墙钟还是慢 2 倍多。这条线索直接指向下一步:既然不是"算得多",那就去看"算得慢"。

顺带一提,这 2 个百分点的来源是清楚的:SGLang 的缓存粒度是 page=128,vLLM 因 Mamba 混合架构对齐被强制成 block=1536。平均提示 33.8K token,粒度从 128 涨到 1536 的期望边界损失增量约 (1536−128)/2 ÷ 33,800 ≈ 2.1%,与实测 2.16 个百分点的命中率差几乎重合。

七、先排掉两个最像的原因

在往"算得慢"上追之前,得先排掉"是不是我们给 SGLang 配少了"。两个最像的嫌疑各做了一次干预。

第一个:KV 池。两边 KV 池差 2.29 倍(SGLang 496,768 / vLLM 1,136,907),来自两份配方里的显存参数——vLLM 侧的 gpu-memory-utilization 0.9 照官方,SGLang 侧的 mem-fraction-static 0.76 是按显存账定的。把 --max-mamba-cache-size 从 189 砍到 64,腾出的显存全给 KV,池涨到 790,400(+59%),运行余量不变。

结果是驱逐 token 从 816,370 掉到 218,500,降 73%,而性能指标全部落在噪声内:命中率 −0.25 pp、提示吞吐 +1.3%、墙钟 −1.3%、TTFT 中位 +9.7%。TTFT 那 +9.7% 看着像退化,但同配方同并发档的重复跑实测到过 −9.8% 的自然波动,量级相同方向相反。

这一档的三个限定要一并给出:池扩到 790,400 仍低于 CC=8 末期约 880K 的活跃工作集,跨过门槛的那一档(988,800)会在 171 秒 OOM;池 +59% 是靠 Mamba 槽位 −66% 换来的,在这个模型上两者绑死;结束快照是事后补采的,墙钟等于 bench 自报时长加 39 秒标定常数,所以那 ±1.3% 不具分辨力。

第二个:昇腾侧环境变量。vLLM 的启动脚本有 5 个 export,SGLang 一个都没有(镜像 entrypoint 与 CANN set_env.sh 也不带)。其中 TASK_QUEUE_ENABLE=1 是昇腾的异步算子下发队列,直接作用在预填充路径上。

补齐 3 个后重跑 CC=8,启动参数一字未动:命中率 −0.02 pp、提示吞吐 +0.1%、墙钟 −0.1%、TPOT −0.6%。全部在噪声内,与 vLLM 的墙钟差 2.21× → 2.21×。

伴随变量两个:expandable_segments 让 KV 池从 496,768 涨到 505,344(+1.7%);这一跑是全新引擎,基线那跑是温机。另外这一档是 CC=8,而 TASK_QUEUE_ENABLE 的收益本应在设备未饱和时最大——CC=8 恰是最不利于看出效果的工况。

剩下两个 export 没补:ASCEND_RT_VISIBLE_DEVICES 刻意不补(补了会换卡,引入硬件位置变量);VLLM_PREFIX_CACHE_RETENTION_INTERVAL=4608 是 vLLM 专属的前缀缓存保留策略,SGLang 无对应项。

两次干预的收获很明确:KV 池和昇腾侧配方这两个最大的嫌疑都被降了级,搜索范围收窄到预填充路径上。(严格地说,"没测到变化"不等于"这不是原因"——扩池那次没跨过工作集门槛,补 env 那次的 CC=8 也是最不利于看出效果的工况,所以是降级而不是结案。)

八、把预填充单独拎出来量

既然差距在 TTFT,那就把缓存、多轮、并发调度全部剥掉,单独量预填充本身:单请求、无并发、max_tokens=1、每次全新随机提示、冷启动由 /metrics 增量核验(六档两臂全部 0.0%),每档 5 次取中位。六档里摘四档看绝对耗时,完整六档与吞吐对照在下图:

vLLM 的预填充吞吐在 4K~100K 区间基本平坦(3,830~4,791 tok/s),SGLang 从约 3,300 降到 1,810。差距不是一个常数倍,而是随上下文单调放大:8K 时只有 1.20×,到 100K 才 2.12×。

这组数能解释主表里多少差距?拿探针速率做一次加性时间预算(CC=8):

单请求预填充速率差对应 767 秒墙钟差里的约 230 秒,三成。剩下约 646 秒还没有归因(而且这是下界——并发下分块预填充的聚合吞吐只会高于单请求探针)。两个候选很具体:调度与排队开销(实测平均排队 3.30 秒),以及"在 109K 已缓存历史之上继续预填充新 token"与"独立预填充一段等长提示"本就不是同一件事——探针测的是后者。这是个足够窄的靶子,下一轮直接打它。

对六个探针点做一次拟合(TTFT = c + a·n + b·n²,最大残差 SGLang 0.41 s、vLLM 0.12 s),能看出差异落在哪一项上:

逐 token 的线性通路两臂基本相同,差异几乎全部集中在二次项——这把靶子进一步缩到了与序列长度平方相关的那部分。作为拟合它还不能当机制判定:两臂的分块预填充粒度是 16384 vs 8192,100K 提示分别切成约 7 块和 13 块,chunk 边界开销同样能拟合这六个点,要分开需要同分块的对照。

另外补一条采样纪律,做这类探针时很容易栽:重复采样要换掉整个提示,不能只换尾巴。前缀相同的话第二次开始就会命中缓存,取中位数等于把热的当冷的用。

九、这个倍数对每轮输出长度极其敏感

两臂差距集中在 TTFT,那是每轮只付一次的固定开销,而解码侧两边接近。所以输出越长,这笔开销被摊得越薄,倍数越小。

用 CC=8 的实测 TTFT / TPOT 外推:

两列的模型:中位口径 = TTFT中位 + (n−1)×TPOT中位;墙钟口径 = 187 × (TTFT均值 + (n−1)×TPOT均值) ÷ 8 并发。同一件事换个口径就差 25%,引用时必须带口径。外推只在 n=220 这一点做过校验,那近乎恒等式,斜率没验证过;而且闭环回放里输出变长会推高后续轮的上下文(n=1,000 时末轮多约 18%),这一项外推没有计入。

220 token/轮是 SGLang bench 的默认值,也是 LMSYS 那份公开报告用的值,所以它是一个有业内依据的工作点,不是我们随手挑的。但真实 coding agent 的单轮回复——思考链加 diff 加工具参数——常常远超 220 token。本文这组数据测的是"每轮回复很短"的 Agent,恰好是让 TTFT 差距最大化的设定。

十、已知差异清单

一臂照官方配方、一臂自配,这张清单就是它的使用说明书——想把上面的数搬到自己的环境里,对着它逐条比一遍就知道哪些还成立。每一项都可能贡献了数据里的一部分,本轮都没有单独隔离:

配置未对齐

• 分块预填充:SGLang 16384 vs vLLM 8192(100K 提示约 7 块 vs 13 块)
• 显存参数:mem-fraction-static 0.76 vs gpu-memory-utilization 0.9,KV 池 496,768 vs 1,136,907
• --enable-mixed-chunk:vLLM V1 默认混批 prefill+decode,SGLang 默认不混,未开
• 分层缓存(HiCache):SGLang 未开
• enable_torch_compile:vLLM 默认开,SGLang 未开
• CPU 绑核:只有 vLLM 有(enable_cpu_binding)
• VLLM_PREFIX_CACHE_RETENTION_INTERVAL=4608:vLLM 专属,SGLang 无对应项
• 算子路径:SGLang mamba_backend='triton'、attention_backend='ascend';vLLM 走 vllm-ascend 的 Mamba 适配
• seed:vLLM --seed 1024,SGLang 为启动时随机种子,SGLang 臂不具备位级可复现性

测量环境不对等

• 冷启动方式:SGLang 每档 --flush-cache;vLLM 无该路由,改为每档重启引擎。vLLM 每档从 num_reqs=0 全新起步,SGLang 引擎已累计服务 2,502 个请求
• 墙钟含约 40 秒 kubectl exec 固定开销,占短的那一臂 6.5%、长的那一臂 2.8%
• 两臂固定在同节点的不同卡对(SGLang NPU 0/1,vLLM NPU 2/3),未做换位对照;测量相隔约一天,同节点其余 4 卡占用未记录
• 压测客户端与 SGLang 引擎同 pod、共享同一份 cgroup CPU 配额;vLLM 引擎在另一 pod 独占自己的配额。昇腾的 host 侧算子下发吃 CPU,这是一条系统性作用于两臂的不对称,方向可能对 SGLang 不利,幅度未测
• 权重同为 w8a8,但反量化实现不同(modelslim vs ascend),输出质量未做核验

统计与负载

• 各档 n=1;重复跑只在 SGLang 臂做过,vLLM 臂方差未测
• 8 条会话全部来自同一上游生成器(swe-smith-claude-3-7-sonnet),且按"最少轮数达到 100K"挑出,每轮新增内容偏大——这个方向放大而非缩小实测到的差距

十一、这套跑法能带走什么

方法这一层已经是业内共识。用真实 agent 轨迹回放来测推理系统,LMSYS、Artificial Analysis、Thoughtworks 三家在各自的位置上做的是同一件事;SGLang 把它做进了 bench_serving 的内置数据集,220 token/轮成了默认值。要判断一套部署扛不扛得住 Agent 负载,这已经是该用的口径。

这套口径在昇腾 910B4 上完整跑通了。官方工具、官方数据格式、公开数据集,两个引擎共用同一份测量代码,从 2 分钟的 MVP 一路到 100K × 187 请求的正式负载,再到单请求冷预填充探针,整条链路可复现。作为量级校准,SGLang 臂测到的 86.4% 前缀命中率对得上公开报告的约 92%。

这一轮最值得带走的是定位,不是倍数。三条通道逐一排掉,只剩长上下文的预填充那一段——加上四条可以直接搬走的做法,都在下面这张图里。

这组数字本身怎么用:照着差异清单在你自己的配置上重测,而不是直接搬倍数。换稠密模型(本文不少现象与 Mamba 混合架构直接相关)、换输出长度、换上下文量级、换镜像版本,数据都可能不同。

关于作者

vLLM 生产工程。本文数据全部来自 2026-08-21 至 08-23 在昇腾 910B4 上的实测,原始日志、配方与逐请求明细均已归档。

免责:本文实测环境为昇腾 910B4 × 2 + Qwen3.6-27B-w8a8,结论不外推至其他硬件、模型或引擎版本。

本文转载自微信公众号「vLLM 生产工程」，仅供学习交流使用。