2.4 KiB
2.4 KiB
数据来源与核验记录（provenance）
原始 csv/log 按仓库惯例不入库（.gitignore *.csv/*.log），完整文件在 60.8
/root/bench_logs/b300eq_{tp2pp4_20260910_1138,e7b_20260910_1428}/ 与本地镜像
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）。
质量门判决
- TP2PP4 臂：
PASS=6 FAIL=1（唯一失败 = tool-call，D 口径无 parser，历史已知；GSM8K×5 + 中文推理全过） - E7b 臂：
PASS=7 FAIL=0（含 tool-callget_weather{"city": "北京"}）
在役容器保全与恢复（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 池未回填，正常）；容器口径未变
- 僵尸 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）。