qqtang/sskj
1
3
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
sskj/experiments/pro6000/glm53_nvfp4_pro6000d_sglang_dual_scenario_bench
History
yy-fighting 5c749cda03 feat(pro6000/GLM-5.3): 方案 D/E/F 部署资产入库（TP2PP4 生产配方 / TP8+DFlash2 / PD 分离四角色链） 
- scripts: 11 个服务器原样脚本入库（md5 对照表更新至 README）；D=60.1 生产原样配方、
  E=v5 DFlash 底稿、F=PD 链四角色部署+launch+双场景压测驱动
- profiles: 新增 6 个 .env（D/E 单机 + F 四角色，均带镜像 digest
  sha256:28e0d260…，对齐 kimi3 PD 多角色先例）
- deploy/PD_CHAIN.md: 方案 F 编排手册（启动顺序 mc-master→prefill→decode→router、
  基础设施依赖表、质量门口径、拆链恢复、÷2 单机等效判决）
- platforms/patches/pro6000/glm53_pd_chain/: sglang 补丁树 vs 镜像原版 11 文件
  unified diff 快照——宿主树无 .git，此为唯一版本记录（DFlash+PP+PD 解锁全集）
- deploy/manifests/: GLM-5.3-NVFP4(47分片)/GLM-5.3-DFlash2(单分片) 权重 md5 清单
- deploy/CURRENT.md: 全集群现役状态页（2026-09-08 八机实测）
- deploy/verify_profile.sh: 防漂移核验工具（digest+参数 token 比对+端口/health，
  已在 60.1 生产容器实测 PASS）
2026-09-08 16:36:15 +08:00
..
scripts
feat(pro6000/GLM-5.3): 方案 D/E/F 部署资产入库（TP2PP4 生产配方 / TP8+DFlash2 / PD 分离四角色链）
2026-09-08 16:36:15 +08:00
config.env
feat(pro6000/GLM-5.3): 双场景压测标准入库（bench_corpus 真实语料工具链 + run-id 窗口纪律 + 质量门禁 + 语料构建链）
2026-09-08 11:37:54 +08:00
README.md
feat(pro6000/GLM-5.3): 方案 D/E/F 部署资产入库（TP2PP4 生产配方 / TP8+DFlash2 / PD 分离四角色链）
2026-09-08 16:36:15 +08:00

README.md

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），用法见脚本头注释。

方案 A-F 总表（2026-09-08 六方案报告口径）

双场景报告（飞书 SZUSdEqY1oRVxGxgILBcHqPJnEc，wiki NzbMwzmKviYidRkZYRrc8GYQnrf）已从 A/B 两配置扩展为六方案对比，D/E/F 部署资产 09-08 入库。方案 F（PD 分离链）占两台机， 吞吐须 ÷2 换算单机等效后才与单机方案可比。

方案 部署脚本（scripts/） profile（deploy/profiles/pro6000/） 实测机器 一句话结论
A：TP8+EAGLE deploy_glm53_605.sh glm53_nvfp4_pro6000_sglang_tp8eagle.env 60.5/60.7 基准；场景一最优，60.5 生产在役
B：TP4PP2 deploy_glm53_optimal.sh glm53_nvfp4_pro6000_sglang_tp4pp2_indexcache.env 60.7 场景二最优（吞吐 +41~79%）
C：B+IndexCache 同 B（index_topk_freq=4） 同 B 60.7 freq=4 为原生默认，与 B 恒等；报告口径保留
D：TP2PP4 deploy_glm53_pp4.sh glm53_nvfp4_pro6000_sglang_tp2pp4.env 60.1 串行 prefill 有效速率最高（6.5-6.7k）；场景二 cc32+ 反超 B、场景一 8/8 败；60.1 生产在役
E：TP8+DFlash2 deploy_glm53_tp8_dflash2.sh glm53_nvfp4_pro6000_sglang_tp8dflash2.env 60.2 场景一 8 点全败于 A/C（DFlash accept 2.53 < EAGLE 2.84，劣势全在接受率）；投机栈维持 EAGLE
F：PD 分离链 deploy_pd_smoke_master.sh+deploy_pd_probe.sh+deploy_s1_decode.sh+deploy_pd_smoke_router.sh（launch 脚本×3） glm53_nvfp4_pro6000_pd_{master,prefill,decode,router}.env 60.1+60.2 128k cc1 TTFT 3.91s 六方案最低；÷2 后吞吐仅为 A 的 30-96%——"两机买 TTFT、不买吞吐"

方案 F 配套资产：

  • 链编排手册（启动顺序 mc-master→prefill→decode→router、基础设施依赖表、质量门、拆链恢复）： deploy/PD_CHAIN.md
  • sglang 补丁树快照（宿主树无 .git，此 patch 是唯一版本记录）：platforms/patches/pro6000/glm53_pd_chain/
  • 压测驱动：scripts/run_pd_s1.sh / run_pd_s2.sh（经 router :31000，命中率读 prefill 日志、 accept 读 decode 日志）
  • 防漂移核验：bash deploy/verify_profile.sh <profile.env>（2026-09-08 已在 60.1 生产容器实测 PASS）
  • 现役状态页：deploy/CURRENT.md

基线数字（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 仅路径适配¹

09-08 新增（方案 D/E/F，服务器原版 md5 = 仓库版，逐字保留）：

文件 60.1/60.2 原版 md5 说明
scripts/deploy_glm53_pp4.sh def3c64c5dc19e1d507080e3366c3762 方案 D 部署（60.1 生产原样配方；脚本头注释为早期 TP4PP2 版残留，以 docker run 段为准）
scripts/deploy_glm53_tp8_dflash2.sh 5bf2b47c9349e5855b963e571e35c096 方案 E v5 底稿（含四轮 OOM 教训；bench 变体 4 处 delta 见 profile 注释）
scripts/deploy_pd_smoke_master.sh 6e406234ba3c1634899dc89950d0139b 方案 F 角色1：mc-master
scripts/deploy_pd_probe.sh 0d44fc8bf5b577ca0ea77c99f8f574cd 方案 F 角色2：prefill 通用探针（参数=launch 脚本名）
scripts/p1b_prefill_tp4pp2_cps8k_launch.sh 006ffa5851eb188b19dde8c5b5dc296e prefill launch 基线（radix off）
scripts/p1b_prefill_tp4pp2_cps8k_radix_launch.sh 17822f059a93ecd54d0e309f8ef4ae02 prefill launch 场景一变体（唯一差异=去 --disable-radix-cache）
scripts/deploy_s1_decode.sh 10ae7a186eb6eb309f1098c65fd87e1b 方案 F 角色3：decode 部署
scripts/s1_decode_launch.sh 932410b846f91ead3108122585c3cc34 decode launch（v5 配方+PD flags；头注释"1 个文件改动"已过时，实为 11 文件，见补丁快照）
scripts/deploy_pd_smoke_router.sh 77b3242ec6890402cbb4d28d79113fbb 方案 F 角色4：MiniLB router
scripts/run_pd_s1.sh 889adc7aa9a75b58275e32052cebb2b8 方案 F 场景一压测驱动（经 router :31000）
scripts/run_pd_s2.sh 980b74bb7b6fb3daa3e987d138b2c8ce 方案 F 场景二压测驱动

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

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

关联

  • 部署 profile：方案 A-F 全量见上文"方案 A-F 总表"；文件在 deploy/profiles/pro6000/ （A=tp8eagle、B/C=tp4pp2_indexcache、D=tp2pp4、E=tp8dflash2、F=pd_* 四角色）
  • 方案 F 编排：deploy/PD_CHAIN.md；补丁快照：platforms/patches/pro6000/glm53_pd_chain/
  • 权重完整性清单：deploy/manifests/GLM-5.3-NVFP4.md5、GLM-5.3-DFlash2.md5
  • 防漂移核验工具：deploy/verify_profile.sh；现役状态页：deploy/CURRENT.md
  • 前序实验：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