yy-fighting 97c208cfdb b300eq: TP2PP4 MRR64 retest (pass-1 + ordered v2 + MRR48 control) — c64 gains +27%/+19%, TTFT collapse, -14% 1K c32 config cost attributed

- deploy_glm53_pp4_mrr64.sh: byte-diff vs original = MRR 48->64 only; decode graph
  stack-default bs<=256 (no graph change needed, arm never fell off graph)
- pass-1 + v2 (fresh instance, retraction-prone 16K c64 ordered last): all 6 points
  aligned <=1.8% -> post-retraction contamination hypothesis disproved; anchor
  regression is reproducible MRR64 behavior
- MRR48 fresh-instance control (4.1 c32 = 266.42): decomposes -17% anchor into
  -3.3% instance freshness + -14.4% MRR64 config cost (per-req TPOT p50 87->102ms,
  three instances, mechanism unidentified)
- 16K c64: pool-capped ~59 active, 3 retractions both runs (deterministic);
  out -5% vs MRR48 queue-mode but TTFT P95 135->89s
- report/README/provenance/CURRENT.md overwritten in place per user instruction;
  feishu wiki revision 13

2026-09-10 21:29:05 +08:00

6.0 KiB

Raw Blame History

数据来源与核验记录（provenance）

原始 csv/log 按仓库惯例不入库（.gitignore *.csv/*.log），完整文件在 60.8 /root/bench_logs/b300eq_{tp2pp4_20260910_1138,e7b_20260910_1428,e7b64_20260910_1732}/ 与本地镜像 D:/sskj/b300eq/。本文件固化其中的关键事实。

GPU 清单（nvidia-smi，8×RTX 6000D，总 85,651 MiB/卡）

TP2PP4 臂（mem0.85，加载后空载 → 矩阵结束）

GPU	空载 MiB	结束 MiB
0/1	64,613	79,391
2/3	70,867	81,751
4/5	74,499	84,439 / 84,631
6/7	75,361	84,491

vram_timeline.csv（30s 采样）全程峰值 85,013 MiB（主场景 C=64，最紧张卡余量 ~638 MiB）。

E7b 臂（mem0.90 + EAGLE 草稿权重，空载更高）

GPU	空载 MiB	结束 MiB
0	77,861	83,477
1/2/5/6	77,955	83,551 / 83,553
3/4/7	77,859	83,477 / 83,479

全程峰值 83,553 MiB（余量 ~2.1 GiB）。

E7b64 复测臂（MRR64 + decode 图桶 1–64，20260910_1732）

部署：deploy_glm53_e7b_hicc.sh（md5 165db732…），与 E7b 初测唯一差异 = MRR 16→64 + 图参数 --cuda-graph-max-bs-decode 64 --cuda-graph-bs-decode "1 2 3 4 6 8 12 16 24 32 48 64"；KV 池 276,480 不变，server_args 核验 max_running_requests=64、图桶 13 档
启动计时（09:30:27）：load_weight=217.07 s；cuda_graph={prefill=94.48, target_verify=35.95, draft_decode=13.40, draft_extend=1.85}；捕获后 avail_gpu_mem=6.11 GB
空载 79,317~79,411 MiB/卡；复测矩阵（16K/1K 场景，vram_timeline 30s 采样 116 帧）全程峰值 83,627 MiB（余量 ~3.9 GiB）
10 点全部 OK、命中核验全 0.0（全新容器实例=回收窗口重新处女文本）、0 retraction；run-id 9601-9610
C=8 锚点 vs 初测偏差：16K 81.4→83.9（+3%）、1K 152→151（−1%）、1K→4K 412→402（−2%）→ 两轮环境无漂移
前后对比表：retest_compare.md（本目录镜像 = 60.8 /root/bench_logs/retest_compare.md）

质量门判决

TP2PP4 臂：PASS=6 FAIL=1（唯一失败 = tool-call，D 口径无 parser，历史已知；GSM8K×5 + 中文推理全过）
E7b 臂：PASS=7 FAIL=0（含 tool-call get_weather{"city": "北京"}）
E7b64 复测臂：PASS=7 FAIL=0（部署后以 "The server is fired up" 真就绪信号判定后跑门，7/7）

在役容器保全与恢复（60.8，TP4PP2-nomtp@0.90 口径）

停役流程：docker stop glm53-nvfp4 → docker rename glm53-nvfp4 glm53-nvfp4-insvc（先改名，防 E7b 部署脚本 rm -f 同名容器）；inspect/启动命令/挂载/镜像归档于 60.8 /root/bench_logs/b300eq_meta/
镜像：lmsysorg/sglang:nightly-dev-cu13-20260901-07c8f729（sha256:eb090e39…）
停役前显存：82,221~82,395 MiB/卡
恢复流程：E7b 测试容器 rm（显存排干 0 MiB）→ docker rename glm53-nvfp4-insvc glm53-nvfp4 && docker start
恢复核验第一轮（09-10 午，初测后）：health 200（启动后 ~4 min）；16K/16tok 冷抽测 ok=1/1、wall 3.59 s；显存 GPU4-7 与停役前持平（82,2xx MiB）、GPU0-3 低 ~5 GiB（重启后 radix 池未回填，正常）；容器口径未变
恢复核验第二轮（09-10 晚，e7b64 复测拆台后，restore_insvc_e7b64.sh 自动化）：fired up（start 后 ~4 min）→ health 200 → 16K/32tok 抽测 ok + C=4×16K/256tok 抽测 ok；KV 池 647,040 tokens（8 rank 一致）+ server_args 与归档启动命令逐字一致（TP4PP2/mem0.90/MRR16/cps8192/hicache×3/ctx 1,048,576）；显存 GPU4-7 82,2xx MiB 持平、GPU0-3 77.2 GiB = mem0.90 静态预算水位（较停役前热稳态多 ~5 GiB 余量，与第一轮同象）
僵尸 PID 现象记录：docker stop/rm 偶发 "container PID xxx is zombie and can not be killed"，实为收尾边界现象（容器终态 exited 137、显存归零），等待 ~20s 重试即成功

执行资产 md5（60.8 = 本目录 = 60.7 原件，三方一致）

见 md5_ledger.txt。corpus 语料：/root/corpus_ids.json（21,296,780 tokens，消费至 21,235,008，回收窗口协议见 REPORT.md 附录 A）。

PP4MRR64 复测臂（MRR 48→64；pass-1 20260910_1927 + v2 20260910_2021 + MRR48 对照 20260910_2112）

部署：deploy_glm53_pp4_mrr64.sh（md5 533440ef…），与 deploy_glm53_pp4.sh（def3c64c）逐 token diff 仅 MRR=48→64 一处；KV 池 1,040,384 / mem0.85 / cps16384 / radix 关全部不变；decode 图保持栈默认（max_bs 256、桶含 56/64）——本臂从未掉图，MRR 才是初测 C=64 点的活跃上限（48 活跃+16 排队）
pass-1（19:27–20:14，run-id 9661–9666）：6 点全 OK、命中核验全 0.0；16K c64 出现 3 次 retraction（64×17.4K≈1.11M tokens > 池 1,040,384，活跃封顶 ~59 条）
v2（20:21–21:07，run-id 9671–9676，正文采用值）：全新实例 + 易回退点 16K c64 排末位，用于排除"retraction 后遗污染后续点"假设；6 点与 pass-1 全部对齐 ≤1.8%（4.1 c32 228.08 vs 230.2、4.1 c64 433.2 vs 429.2、4.2 c32 346.69 vs 340.6、4.2 c64 572.01 vs 571.4、16K c32 192.38 vs 192.0、16K c64 200.58 vs 200.6）→ 污染假设否证，1K 锚点回退为 MRR64 部署的可复现行为；16K c64 再次 3 次 retraction（确定性行为）
v2 矩阵 VRAM 峰值 84,791 MiB（GPU2，16K c64 池顶运行时采样）；QG 复验 PASS=6 FAIL=1（tool-call 已知项）
MRR48 归因对照（21:12–21:14，run-id 9681）：原版 deploy_glm53_pp4.sh 全新实例跑 4.1 c32 单点 = 266.42 tok/s（TPOT p50 87.8ms，复现初测 87ms 水平）→ −17% 锚点分解：275.6（初测，第 9 点热实例）→ 266.4（新鲜度 −3.3%）→ 228.1（MRR64 配置代价 −14.4%）；逐请求 TPOT p50 87→102ms 均匀抬高、三实例可复现、机制未定位
恢复核验第三轮（21:13–21:17，control_mrr48_41c32.sh 自动链）：rm glm53-pp4 → VRAM 排干 → rename 回 + start → fired up → health 200 → 16K/32tok 抽测 ok；KV 池 647,040（8 rank 一致）；显存 GPU0-3 77.2 GiB / GPU4-7 82.3 GiB 与停役前一致

6.0 KiB Raw Blame History Unescape Escape