# 数据来源与核验记录（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）。