sskj/experiments/pro6000/glm53_nvfp4_pro6000d_sglang_dual_scenario_bench

GLM-5.3-NVFP4 (Pro6000D×8) SGLang 双场景压测标准

• 日期：2026-09-04 ~ 09-08（09-07 真实语料修正版定稿）　机器：174.1.60.5（生产）/ 174.1.60.7（实验）
• 硬件：8×RTX 6000D 96GB（SM120，PCIe Gen5，无 NVLink）　模型：/data/hf_models/GLM-5.3-NVFP4
• 推理栈：SGLang lmsysorg/sglang:nightly-dev-20260828-daf63171（容器入口必须 python3 -m sglang.launch_server，镜像 entrypoint 无 shebang）
• 完整报告：飞书 wiki https://gcn673xpgdxn.feishu.cn/wiki/NzbMwzmKviYidRkZYRrc8GYQnrf （revision 20，真实语料版）；本地副本 D:\sskj\reports\GLM53_NVFP4_双场景压测报告_2026-09-07.md

目的

把 09-04~09-08 多轮压测沉淀为可复用的双场景测试标准：任何同事按本目录脚本与纪律执行， 即可得到与基线可比的数字。压测核心是自研 bench_corpus.py（真实 PG19 语料，input_ids 直发 原生 /generate），配套固定的语料窗口分配（run-id）、命中率日志核验、质量门禁与重跑纪律。

两场景定义

	场景一：长上下文低并发	场景二：16k 独立输入高并发
输入	131072 (128k) / 65536 (64k) token	16384 (16k) token，全独立
输出	512 token（ignore_eos）	同左
并发	cc 1/2/3/4	cc 8/16/32（扩展点 cc40/64）
每点请求数	8	cc8→16、cc16→32、cc32→32
前缀命中	--shared-frac 0.9（90% 共享前缀 + 10% 唯一后缀，页 16 对齐）	--shared-frac 0（命中率必须为 0）
实测命中率	128k 89.99% / 64k 89.94%（日志核验）	0.0
负载形态	prefill 占 10%，decode（EAGLE）主导	100% 新 token，串行 chunk prefill 主导
推荐配置	配置 A（TP8+EAGLE 生产标准）	配置 B（TP4PP2+IndexCache）

标准命令（= run_s1_corpus.sh / run_s2_corpus.sh 的内容）：

# 场景一（8 点，run-id 9301-9308 与语料窗口一一绑定）
python3 scripts/bench_corpus.py --corpus /root/corpus_ids.json \
  --input-len 131072 --concurrency 1 --num-requests 8 --run-id 9301 \
  --shared-frac 0.9 --output-len 512        # 128k cc1；其余点换 cc 与 run-id

# 场景二（3 点，run-id 9311-9313）
python3 scripts/bench_corpus.py --corpus /root/corpus_ids.json \
  --input-len 16384 --concurrency 8 --num-requests 16 --run-id 9311 \
  --shared-frac 0 --output-len 512

bench_hit90.py / bench_report.sh / bench_matrix.sh 是合成随机 id 的快速对照工具： 随机 id 语义不通顺会使 EAGLE accept 虚高（3.46/3.88 vs 自然文本 2.29），decode 类指标只作 参考，正式口径一律用真实语料版。

测量口径（必须遵守，否则数字不可比）

1. 输出吞吐 = 服务端 meta_info.completion_tokens 总和 / 墙钟。EAGLE 投机解码下客户端 流式 chunk 计数会低估，一律以服务端计数为准（bench_corpus.py 已按此实现）。
2. TTFT = 客户端发出到首个流式响应，并发 >1 时含排队；TPOT = (首响应→末响应)/(completion_tokens−1)， 并发下含交错停转，非纯 decode 步时。
3. 命中率只能从容器日志 TP0 "Prefill batch" 行核验：正则 #new-token: (\d+).*?#cached-token: (\d+)， 按运行窗口 docker logs --since/--until（RFC3339，结束 +2s 边距）截取，剔除每分钟 64-token 监控心跳（特征 #new-token: 64）。响应内 cached_tokens 字段恒为 0，不可用。
4. 配置对比用 TPOT×accept（步时），抵消 accept 长度的内容运气（真实语料 accept 范围 2.13-2.92）； 吞吐/e2e 跨语料窗口噪声带 ±8%，同窗口背靠背 A/B（交替顺序）用于终局对比。
5. 单点验收：ok=nreq, failed=0, retractions=0，SUMMARY 字段完整；命中率偏离预期、retractions>0、 OOM 或机器有外部负载（见下）→ 停下排查，数据作废。

语料（corpus_ids.json，不入库 ~97MB）

真实语料 = PG19 英文长书（GCS deepmind-gutenberg，路径 train/{id}.txt）用服役模型自己的 tokenizer 分词得到的平坦 token 序列：{"ids": [...21,296,780 tokens...], "books": [[start,end),...]}。 两种获取方式：

# 方式一（推荐）：从 60.7 拷贝现成语料（与基线逐字节一致）
scp root@174.1.60.7:/root/corpus_ids.json /root/     # md5 a8f3909211adb92501cf007ab71d3b29

# 方式二：重建（换 tokenizer / 语料损坏时）
python3 scripts/fetch_pg19_v2.py                      # 下载最长 12 本书 ~85MB 到 /root/bench_corpus/books/
docker cp /root/bench_corpus glm53-nvfp4:/tmp/        # 需一个运行中的 GLM-5.3-NVFP4 容器
docker exec -i glm53-nvfp4 python3 - < scripts/tokenize_corpus.py \
    > /root/corpus_ids.json 2> /root/tokenize_progress.log

注意：bench_corpus.py 的窗口布局是固定 token 偏移（见下表），语料长度必须 ≥ 2,071,040 + 余量； 换模型/分词器重建后长度不同，超界会报错（此时用 --pool-override 指定窗口起点）。

run-id 窗口与重跑纪律

窗口	token 区间	绑定 run-id	用途
共享前缀	[0, 117968) / [0, 58976)	—	128k / 64k 场景一的 90% 共享前缀
pool A	[131072, 550400)	9301-9304	128k 唯一后缀（每点 8×13104）
pool B	[550400, 760320)	9305-9308	64k 唯一后缀（每点 8×6560）
pool C	[760320, 2071040)	9311-9313	16k 全独立输入（16/32/32×16384）
spare	[2071040, 语料尾)	—	warmup 切片 + 重跑余量

纪律：每个 run-id 绑定唯一不重叠窗口，复用窗口会虚高命中率 → 数据无效。重跑某点取新鲜 文本时用 --pool-override <起始偏移>（run-id 退化为标签），惯例起点 = 2200000 起步、每轮 +700000。 bench tag 每轮必换、绝不覆盖旧日志（日志目录默认 /root/bench_logs，可用 LOG_DIR 覆盖）。

部署配置（三套正式 + 一个实验补丁）

配置	脚本	要点	适用
A：TP8+EAGLE 生产标准	scripts/deploy_glm53_605.sh	TP8；EAGLE 4/1/5；KV fp8_e4m3 + hicache 3；mem 0.90（池 276,864）；mrr 16；chunk 8192；max-prefill 16384；decode 图 bs{1,2,3,4,6,8}；ctx 270336；parser glm45/glm47	场景一；两类负载混跑的折中（60.5 在役）
A-s2：场景二高并发变体	同上脚本 + EXTRA	仅两处不同：mrr 16→32、decode 图 bs{4,8,12,16}（池 276,864÷16,896=16.4 驻留上限，decode 批自然 ≤16，图覆盖到 bs16 即可；bs24/32 图纯耗显存且会运行时 OOM）	场景二用配置 A 跑时
B：TP4PP2+IndexCache	scripts/deploy_glm53_optimal.sh	TP4 PP2；mem 0.85（池 569,600=2.06×）；mrr 48；chunk 16384；index_topk_freq=4；禁 radix；禁投机（PP2 与投机框架不兼容）；--disable-custom-all-reduce	场景二最优（吞吐 +41~79%）
B-s1：B 的场景一形态	scripts/deploy_glm53_optimal_s1.sh	与 B 唯一差异：启用 radix cache（90% 命中前提）	场景一 A/B 对比时
CAR 补丁（实验性）	scripts/deploy_glm53_607_exp.sh + scripts/car_patch/	E7b custom-AR 1stage：小 AR（≤8MB，decode AR ≤1MB）走 one-shot 自定义核而非 NCCL RING_LL；cc1 decode 每步 −14~−16%，cc3-4 中性；仅 cc1-2 验证过，未上生产	低并发场景一的实验优化

SM120 必需三项（所有配置一致）：--disable-shared-experts-fusion --moe-runner-backend flashinfer_cutlass --disable-flashinfer-autotune。EAGLE draft 模型自动从主权重加载，无需额外参数。

配置 B 已知缺口：脚本未带 --tool-call-parser glm47 --reasoning-parser glm45，质量门 6/7 （tool call 失败纯属参数缺失，非模型问题）；上生产必须补 parser。

deploy 脚本内置集群踩坑防护：docker rm -f 异步滞留 → 轮询等容器对象消失 + 等显存排空 （<2000 MiB，最长 15 分钟）。不等显存归零就重部署会把新容器 KV 池压小。脚本支持环境变量 调参（MEMFRAC/STEPS/TOPK/DRAFT/CTXLEN/CHUNK/MAXPRE/EXTRA/RESTART），用法见脚本头注释。

基线数字（2026-09-07，真实语料，60.7 干净机器）

场景一 · 配置 A（run-id 9301-9308；命中率 89.99%/89.94%，0 失败 0 回撤）：

场景	cc	输入 tok/s	输出 tok/s	单请求 decode tok/s	TTFT mean/p50 s	TPOT ms	accept
128k	1	12,581	49.1	89.8	4.51 / 4.51	11.6	2.84
128k	2	14,622	57.1	48.7	5.68 / 4.54	22.8	2.45
128k	3	16,972	66.3	40.4	7.14 / 4.52	29.3	2.55
128k	4	17,625	68.9	28.8	9.12 / 7.64	37.8	2.32
64k	1	7,090	55.4	72.3	1.96 / 1.96	14.2	2.22
64k	2	10,236	80.0	50.1	2.41 / 2.01	20.3	2.13
64k	3	13,803	107.8	54.3	3.11 / 2.03	19.4	2.92
64k	4	13,927	108.8	38.2	4.11 / 3.76	27.0	2.31

场景二 · 配置 A（真实语料）vs 配置 B（A：run-id 9311-9313；B 无投机解码，合成/真实语料等价）：

cc	A 输出 tok/s	B 输出 tok/s	B 增益	A 输入 tok/s	B 输入 tok/s	A TTFT mean s	B TTFT mean s	A/B TPOT ms
8	77.1	108.6	+41%	2,468	3,474	18.8	12.3	64.5 / 49.6
16	95.3	146.2	+53%	3,050	4,678	20.1	18.9	123.5 / 72.7
32	96.2	171.9	+79%	3,078	5,501	75.6	35.0	123.7 / 117.7

场景一 · A vs B 输出吞吐（tok/s）：A 为真实语料，B 无投机解码口径等价——A 7/8 占优， 唯一例外 128k cc4（B 75.9 vs A 68.9，B 略优 10%，cc4 聚合被四路交错 prefill 主导，换窗口复测稳定）：

场景	cc1	cc2	cc3	cc4
128k A / B	49.1 / 24.2	57.1 / 48.5	66.3 / 58.7	68.9 / 75.9
64k A / B	55.4 / 27.8	80.0 / 59.4	107.8 / 74.0	108.8 / 95.2

选型结论：场景一用配置 A、场景二用配置 B；混跑负载用 A 折中。共同瓶颈是 8192-chunk 串行 prefill 有效速率 ~2.8-2.9k tok/s（DSA 计算 ~65% + TP8 AR over PCIe ~30%），场景一 90% 命中把 prefill 降到 10% 所以 TTFT 只有 2-4.6s；场景二该墙被 B（TP4 AR + IndexCache）推到 ~5.5k tok/s。

CAR 补丁（E7b）单独基线：cc1 decode 每步 −14~−16%（步时口径），e2e −6~−14%；cc3-4 中性。

质量门禁与运维纪律

• 每次部署后、压测前跑 bash scripts/quality_gate_605.sh（GSM8K×5 + 中文推理鸡兔同笼 + tool call），PASS=7 FAIL=0 方可用/可压；实验结束后恢复生产配置并再次 7/7。
• 压测机必须干净：60.2 曾因他人训练任务混跑出现 prefill 双峰，数据污染弃用——压测前确认 nvidia-smi 无外部进程。
• 实验后收尾：恢复生产配置 + 质量门 7/7 + （可选）清空 GPU（docker rm 后等显存 0 MiB）。
• 结果日志：/root/bench_logs/r1_run*.log（场景一）、r2_run*.log（场景二）；汇总表用 python3 scripts/summarize_bench.py '/root/bench_logs/r1_run*.log'，字段核对用 bench_fields.py。

复现步骤

# 0) 语料（见上节）+ 脚本就位（本目录 = 服务器上的实验目录，或整体拷到 /root/）
# 1) 部署生产配置 A 并过质量门
bash scripts/deploy_glm53_605.sh && bash scripts/quality_gate_605.sh
# 2) 场景一：8 点（约 25 分钟）
bash scripts/run_s1_corpus.sh
# 3) 场景二：换高并发变体 → 3 点 → 恢复生产
MEMFRAC=0.90 EXTRA='--max-running-requests 32 --cuda-graph-max-bs-decode 16 --cuda-graph-bs-decode 4 8 12 16' \
  RESTART=yes bash scripts/deploy_glm53_605.sh
bash scripts/run_s2_corpus.sh
RESTART=yes bash scripts/deploy_glm53_605.sh && bash scripts/quality_gate_605.sh
# 4) 命中率核验（以 9301 为例，窗口 = 该点起止时间 +2s 边距）
docker logs glm53-nvfp4 --since '<start RFC3339>' --until '<end RFC3339>' 2>&1 \
  | grep 'Prefill batch' | grep -oP '#new-token: \d+.*?#cached-token: \d+'
# 期望：场景一 89.99%/89.94%，场景二 0.0；心跳行（#new-token: 64）不计
# 5) 配置 B（场景二专用）
bash scripts/deploy_glm53_optimal.sh && bash scripts/quality_gate_605.sh   # 预期 6/7（parser 缺口）
bash scripts/run_s2_corpus.sh

CAR 补丁（实验性）用法：先在运行中的原生容器上生成补丁 bash scripts/car_patch/prep_car_patch.sh （docker cp 原件 + sed 注入 + py_compile 校验，产物默认 /root/patches/），再用 bash scripts/deploy_glm53_607_exp.sh 部署（默认 CAR_PATCH=1 自动注入后重启容器；CAR_PATCH=0 部署原生）。验证：容器日志出现 SSKJ_CAR_PATCH_ACTIVE ws=8 full_nvlink=False。补丁随容器消亡， 镜像不受影响。

目录与文件对照（原版 md5 = 服务器实测，仓库版即标准）

文件	60.7/集群原版 md5	仓库版处理
scripts/bench_corpus.py	c6d92126ab518c5b1936841f869e4b35	逐字保留（压测核心）
scripts/bench_hit90.py	fd1903969fa101ca43347e6d91ba05e0	逐字保留
scripts/summarize_bench.py	1a265978538dec9eefc6cfb0e6fad281	逐字保留
scripts/bench_fields.py	aba7adcd21448b8e21ba8974e5326cf6	逐字保留
scripts/fetch_pg19_v2.py	3dccd45d7fa3b556094d55f3141d7249	逐字保留
scripts/tokenize_corpus.py	266097bfa08d02b9d7d7e87e77d77b97	逐字保留
scripts/quality_gate_605.sh	0bada531dda12cb982d9b2b36695b809	逐字保留
scripts/deploy_glm53_605.sh	fcd9109b2121c6aea2e913ce612fa63f（全 8 台一致）	逐字保留
scripts/deploy_glm53_optimal.sh	22685f56b28a54216accbe479fba86b4	逐字保留
scripts/deploy_glm53_optimal_s1.sh	6f1ee9ae5d404914f914320dd218bea4	逐字保留
scripts/deploy_glm53_607_exp.sh	21db641f1d997e26fcf1ddc97163b87e	逐字保留
scripts/car_patch/custom_all_reduce.py	a8fc9a504c041acc40831a848b4985d8	逐字保留（60.7:/root/patches）
scripts/car_patch/custom_all_reduce_utils.py	65a4d22bd87ae343e7d68c4879c14f98	逐字保留
scripts/car_patch/prep_car_patch.sh	9578fe4b1f2443ccecd2cc3e0b660fb0	逐字保留
scripts/run_s1_corpus.sh	5b2534f4c2e2f5760c453abb00dc32a2	仅路径适配¹
scripts/run_s2_corpus.sh	8965a71edef6b1cf406496f0362a5d05	仅路径适配¹
scripts/bench_report.sh	282f8cdf5873d3a3eb8a950a1564acae	仅路径适配¹
scripts/bench_matrix.sh	b961a56bc7c8f26c519fdc7f5f627ba1	仅路径适配¹

¹ 仓库规范（README 注意事项）要求脚本不写绝对路径：bench 脚本改按脚本所在目录解析， 语料/日志目录可用 CORPUS/LOG_DIR 环境变量覆盖，默认仍为 /root（服务器原布局，行为不变）。

语料 corpus_ids.json（97MB）不入库；历史原始日志不入库（.gitignore 排除 *.log）， 基线以本 README 表格 + 飞书报告为准。

关联

• 部署 profile（python -m sskj.deploy 消费）：deploy/profiles/pro6000/glm53_nvfp4_pro6000_sglang_tp8eagle.env、 deploy/profiles/pro6000/glm53_nvfp4_pro6000_sglang_tp4pp2_indexcache.env
• 前序实验：experiments/pro6000/glm53_nvfp4_pro6000d_sglang_tp4pp2_profile/（profile 与配置级证伪）、 experiments/pro6000/glm53_nvfp4_pro6000d_sglang_ppmtp_deepdive/（PP+MTP 深挖，均在 hzy 分支）
• 场景一深度优化报告（E7b CAR 补丁出处）：D:\sskj\reports\GLM53_NVFP4_60.7_场景一优化实验报告_2026-09-07.md