docs: identify AI tool in finals report

docs/finals/决赛项目结项书.md

@@ -8,27 +8,23 @@
 
 **项目分支：** `feature/offload-group-num-v018-optimized`
 
-**优化提交：** `f0ab80524e2088763ab1e9859534f05912850194`
+**代码与复现套件提交：** `851feb5`
 
-**精度协议与验收加固提交：** `e2cd297c5e5756e0908707a647251c278027dbbf`
+**7B 实测部署提交：** `ec673f8`
 
-**结项日期：** 2026 年 7 月
+**结项日期：** 2026 年 8 月
 
 ---
 
 ## 摘要
 
-本项目面向 vLLM Ascend v0.18.0，适配 vLLM 权重卸载配置中的 `offload_group_size` 与 `offload_num_in_group` 两个参数。实现按照 decoder layer 分组，在每组末尾选择固定数量的层，将权重保存在 CPU 侧，并通过 Ascend NPU 独立复制流、事件同步和静态缓冲槽位在执行前进行预取。该方案的目标不是无条件提升吞吐，而是在 NPU HBM 紧张时提供可配置、可复现的权重常驻空间与推理吞吐权衡。
+本项目面向 vLLM Ascend v0.18.0，适配 vLLM 权重卸载配置中的 `offload_group_size` 与 `offload_num_in_group` 两个参数。实现按 decoder layer 分组，在每组末尾选择固定数量的层，将权重保存在 CPU 侧，并通过 Ascend NPU 独立复制流、事件同步和静态缓冲槽位在执行前进行预取。目标是在 NPU HBM 紧张时提供可配置、可复现的容量与吞吐权衡，而不是无条件提升吞吐。
 
-项目完成了参数语义与边界校验、Ascend Prefetch Offloader、vLLM 官方 `auto/prefetch/uva` 后端契约兼容、CPU pinned storage 能力探测、shape/stride/dtype 保真、设备健康检查、性能矩阵、GSM8K 与 GPQA Diamond 全量精度验证，以及统一复现脚本。
+在 `Qwen2.5-1.5B-Instruct` 的正式 `qwen-chat-v1` 精度协议下，`baseline_0_1`、`group_8_num_1` 与 `group_8_num_2` 的 GSM8K 均为 953/1319（72.2517%），GPQA Diamond 均为 47/198（23.7374%）；两个 offload case 相对 baseline 的精度下降均为 0，且同数据集逐题输出 SHA-256 一致。
 
-在 `Qwen2.5-1.5B-Instruct` 的正式单卡测试中：
+独立的 `Qwen/Qwen2.5-7B-Instruct` 性能证据覆盖 63 个同运行时进程、15 个长窗口进程和 12 个 native v0.18 辅助观察进程，共 90 条记录。当前负载下，`(28,1)` 释放约 0.434 GiB 权重容量，将可用 KV cache 提升至 16.09 GiB，并保留约 85.77% 吞吐，是实际容量膝点。同运行时 current/latest 的中位数差范围为 -0.086595% 至 +0.043851%，未确认当前实现相对 official latest 存在稳定速度优势；7B 运行未采集精度结果。
 
-- `group_8_num_1` 节省约 0.2615 GB 权重存储空间，可用 KV cache 从 27.27 GiB 增至 27.53 GiB，吞吐为 678.85 tok/s，相对 baseline 下降 8.61%。
-- `group_8_num_2` 节省约 0.5230 GB 权重存储空间，可用 KV cache 增至 27.79 GiB，吞吐为 383.49 tok/s，相对 baseline 下降 48.37%。
-- 修复后的 `qwen-chat-v1` 正式协议下，GSM8K 三组均为 953/1319（72.2517%），GPQA Diamond 三组均为 47/198（23.7374%），相对 baseline 的精度差均为 0。
-
-结果表明，两个参数在目标版本上能够正确工作并保持确定性推理结果，但更激进的卸载会增加 CPU-NPU 权重传输开销。实际使用时应根据模型是否能够装入 HBM、KV cache 需求和吞吐目标选择参数，而不能将 offload 简化为单一的性能开关。
+项目同时完成参数语义与边界校验、Ascend Prefetch Offloader、官方 `auto/prefetch/uva` 后端契约兼容、CPU pinned storage 能力探测、shape/stride/dtype 保真、设备健康检查、运行时证据 hook、身份绑定和独立重算。实际使用应按模型可用 HBM、KV cache 需求和吞吐目标选取参数，不能将 offload 简化为单一性能开关。
 
 **关键词：** vLLM Ascend；权重卸载；预取；NPU；HBM；GSM8K；GPQA
 
@@ -79,7 +75,16 @@ vLLM 提供 CPU weight offload 能力。`offload_group_size` 与 `offload_num_in
 
 前期版本调研显示，后续 vLLM Ascend 版本已逐步出现官方 NPU Prefetch Offloader，其中首个包含相关实现的发布序列为 v0.21.0rc1。由于本项目必须继续基于 v0.18.0，工作重点是将参数语义、后端兼容和复现体系稳定适配回目标版本，而不是直接依赖后续主仓实现。
 
-## 1.4 决赛阶段工作定位
+## 1.4 开发历程与证据演进
+
+决赛材料按以下四个阶段组织，避免将不同模型、协议或运行时的数据混为同一次实验：
+
+1. **v0.18.0 参数适配。** 在竞赛目标版本实现 `offload_group_size` 与 `offload_num_in_group` 的选择、预取、runner 集成和边界测试。
+2. **`qwen-chat-v1` 精度协议修复。** 固定 chat template、样本数、生成预算和评分规则，使用 1.5B 全量 GSM8K/GPQA 矩阵确认两个 offload case 的零额外精度下降。
+3. **Qwen2.5-7B 同运行时 current/latest 对比。** 在相同 v0.23.0rc1/CANN 9.0.1 运行时中比较 current 与 official latest，重点验证容量/吞吐权衡，不从该实验推导精度结论。
+4. **hardened-v6 身份绑定与独立重算。** 将 CANN、package/source tree、模型、runner 和部署身份 fail-closed 绑定，并从原始记录独立重算结果与比较差值。
+
+## 1.5 决赛阶段工作定位
 
 当前核心 offloader 文件与初赛最终提交包文本等价，因此本结项书不把核心算法表述为“决赛重新实现”或“相对初赛新增提速”。决赛阶段的实质工作集中在：
 
@@ -275,7 +280,13 @@ export NPU_CHIP_INDEX=0
 
 并将三个值写入复现记录。
 
-## 3.7 异常与降级策略
+## 3.7 运行时证据与身份绑定
+
+7B 对比不由报告端按参数标签推导选层。只读 runtime evidence hook 直接从实际 offloader 对象捕获 `selected_layers`、`wrapped_count`、`offloaded_bytes` 和实际类名；每个进程的 record、sidecar 与过程日志中的结构化 payload 必须完全一致才发布记录。baseline 具有明确空选择证据，正参数 case 的实际类、选层列表、包裹数和卸载字节均可逐条核验。
+
+正式 runner 在任何 benchmark 写入前执行 fail-closed 身份绑定：CANN 权威安装文件和环境脚本、official latest 的 wheel/package tree 与 native source tree、v0.18 source tree、模型 revision 与 SHA-256 清单、项目 worker/offloader/runner 均必须匹配固定 hash。调用者不可替换这些路径；任一检查失败即停止。该链路确保性能数字能够追溯到确定的运行时和模型，而不是仅依赖命令行标签或可漂移的 editable-Git 元数据。
+
+## 3.8 异常与降级策略
 
 - 参数非法：抛出明确 `ValueError`。
 - 后端非法：在 offloader 工厂阶段拒绝。
@@ -303,6 +314,8 @@ export NPU_CHIP_INDEX=0
 | runner 集成 | `tests/model_executor/offloader/test_runner_integration.py` |
 | 精度复现结构 | `tests/model_executor/offloader/test_accuracy_repro.py` |
 | 脚本验收 | `tests/model_executor/offloader/test_acceptance_scripts.py` |
+| 7B 对比与身份绑定 | `tests/model_executor/offloader/test_large_model_parameter_comparison.py` |
+| 参数优化分析 | `tests/model_executor/offloader/test_parameter_optimization_analysis.py` |
 
 ## 4.2 性能与精度脚本
 
@@ -317,6 +330,10 @@ export NPU_CHIP_INDEX=0
 | `scripts/check_npu_health.sh` | 正式测试前 NPU 健康门禁 |
 | `scripts/detect_npu_index.py` | 获取物理 NPU index |
 | `scripts/install_v018_runtime_compat.sh` | 安装并重建 v0.18.0 兼容运行环境 |
+| `scripts/run_large_model_parameter_comparison.sh` | fail-closed 运行 7B current/latest 对比并生成运行时证据 |
+| `scripts/analyze_large_model_parameter_comparison.py` | 从原始 7B 记录重算容量、吞吐与 current/latest 差值 |
+| `scripts/run_current_vs_latest_performance.sh` | 按当前实现与 official latest 的固定环境运行对比入口 |
+| `scripts/run_parameter_optimization_benchmark.sh` | 运行 v0.18 参数容量/吞吐矩阵 |
 
 ## 4.3 文档交付
 
@@ -332,65 +349,28 @@ export NPU_CHIP_INDEX=0
 
 # 五、测试结论
 
-## 5.1 测试环境
+## 5.1 测试环境与模型边界
 
-| 组件 | 版本 |
-| --- | --- |
-| vLLM | `0.18.0+empty` |
-| vLLM Ascend 包 | `0.1.dev1+g72dc68973.d20260720` |
-| vLLM Ascend 源码基线 | `72dc68973bd7e6ceef9a122de316a7ee9c9a84aa` |
-| CANN | `8.5.1` |
-| Python | `3.11` |
-| torch | `2.9.0+cpu` |
-| torch-npu | `2.9.0` |
-| triton-ascend | `3.2.0.dev20260322` |
-| 模型 | `Qwen2.5-1.5B-Instruct` |
+本章使用两套互不混用的证据。1.5B 证据只回答 offload 是否引入额外精度下降；7B 证据只回答固定负载下的容量/吞吐权衡与 current/latest 比较，不将 7B 性能 run 表述为精度测试。
 
-上表对应 7 月 21 日正式性能环境。2026 年 7 月 30 日修复精度协议后，在迁移服务器上使用 CANN 9.0.0、Python 3.11.6、vLLM 0.18.0+empty、vLLM Ascend `0.1.dev1+g72dc68973.d20260729`、torch 2.9.0+cpu、torch-npu 2.9.0.post2、triton-ascend 3.2.1 和 Ascend 910B2C 重新执行三组完整精度矩阵。三组 case 使用同一环境，因此精度差值不受跨环境比较影响；本报告不据此推导跨 CANN 版本的性能结论。
+| 证据 | 模型与运行边界 | 用途 |
+| --- | --- | --- |
+| 1.5B 精度 | `Qwen2.5-1.5B-Instruct`，vLLM Ascend v0.18.0，正式 `qwen-chat-v1` 协议 | GSM8K/GPQA 的零额外精度下降 |
+| 7B 同运行时 | `Qwen/Qwen2.5-7B-Instruct`，28 个 decoder layers，FP16，Ascend 910B2C，CANN 9.0.1，v0.23.0rc1 | current 与 official latest 的公平容量/吞吐比较 |
+| 7B native 辅助观察 | 同一 7B 模型，native v0.18 源码与固定运行栈 | 跨栈辅助观察，不作 current/latest 主结论 |
 
-## 5.2 功能测试
+7B 部署身份为 `ec673f8`；代码和复现套件身份为 `851feb5`。latest、native、CANN、模型、wheel/package tree 和 runner 的固定 hash 在启动时校验，后续文档提交不作为代码身份。
 
-精度协议和脚本验收相关 unittest（2026 年 7 月 30 日）：
+## 5.2 功能与证据测试
 
-```text
-test_accuracy_repro.py: 26/26 passed
-test_*scripts.py: 18/18 passed
-compileall: passed
-```
+- hardened-v6 远端明确列出的 8 个非 Windows offloader 测试文件：`87 passed in 18.89s`。
+- 本地 focused suite：`41 tests passed`。
+- runtime evidence hook 对每个 7B 进程记录实际 offloader 类、`selected_layers`、`wrapped_count` 和 `offloaded_bytes`；record、sidecar 与过程日志必须一致。
+- `validation.json` 检查为 `valid: true`、`model_files_verified: true`，并确认 63 + 15 + 12 = 90 条记录、90 份独立日志和 90 份运行时证据。
 
-实际 Ascend 环境中的完整 offloader suite：
+远端整目录诊断中的 15 个失败来自 Windows 本地路径或打包流程断言，不计为 Linux/Ascend 运行时失败。独立重算从原始记录得到 `MAX_PROCESS_DIFF=0.000000000000`、`MAX_POOLED_DIFF=0.000000000000` 和 `MAX_COMPARISON_DIFF=0.000000000000`。
 
-```text
-78 passed in 11.77s
-```
-
-两组 `unittest` 属于不同测试范围，不相加。`test_accuracy_repro.py` 也在服务器单独复跑并通过 26/26。
-
-## 5.3 性能测试
-
-正式配置：
-
-- 三个 case，每个 case 3 次独立模型加载。
-- 每次 1 个 warmup round、3 个 measured rounds。
-- 每轮 8 prompts。
-- 输入 128 tokens，最大输出 64 tokens。
-- 共 9 条原始运行记录，表中按 case 取中位数。
-
-| Case | 选中层 | 权重存储节省 | 可用 KV cache | 输出吞吐 | 相对 baseline | P50 延迟 |
-| --- | --- | ---: | ---: | ---: | ---: | ---: |
-| `baseline_0_1` | 无 | 0.0000 GB | 27.27 GiB | 742.77 tok/s | 0.00% | 0.6927 s |
-| `group_8_num_1` | 7、15、23 | 0.2615 GB | 27.53 GiB | 678.85 tok/s | -8.61% | 0.7501 s |
-| `group_8_num_2` | 6、7、14、15、22、23 | 0.5230 GB | 27.79 GiB | 383.49 tok/s | -48.37% | 1.3351 s |
-
-结论：
-
-1. 两个参数能够按预期增加被卸载层数和权重 storage 节省。
-2. 新释放的空间被 vLLM 用于增加 KV cache 可用容量。
-3. `group_8_num_1` 是本次固定负载下较温和的容量/吞吐折中。
-4. `group_8_num_2` 获得约两倍权重 storage 节省，但传输开销显著增加。
-5. 参数适合 HBM 容量优先场景，不适合作为纯吞吐优化开关。
-
-## 5.4 GSM8K 和 GPQA 精度测试
+## 5.3 1.5B GSM8K/GPQA
 
 正式精度设置：
 
@@ -429,39 +409,37 @@ GPQA:
 0f403ae99640dde7c6c27bd993da9acc62752b87a1f81a655ede98de058914aa
 ```
 
-三组 case 在每个数据集上记录了相同哈希，说明保存的预测输出逐字节一致。当前 `verify_accuracy_matrix.py` 不自动复算 example JSONL 哈希，因此正式复现时仍应保留原始 JSONL，并通过 `sha256sum` 或等价工具再次核验。本次最终归档的 `formal-run-manifest.json` 已记录两组 example 哈希和其余关键产物哈希。
+三组 case 在每个数据集上记录相同哈希，说明保存的预测输出逐字节一致。该结论只表示 offload 未引入额外精度损失，不表示该 1.5B 模型的绝对任务精度可以泛化到其他模型或提示协议。
 
-生成诊断同样在三组 case 间一致：
+## 5.4 7B 参数容量/吞吐
 
-| 数据集 | 可解析答案 | 达到 token 上限 | 每组输出 token 总数 |
-| --- | ---: | ---: | ---: |
-| GSM8K | 1319/1319 | 12/1319 | 266776 |
-| GPQA Diamond | 198/198 | 0/198 | 396 |
+7B 固定负载为每个进程 8 个 prompts、128 输入 tokens、64 最大输出 tokens、`max_model_len=512`、`gpu_memory_utilization=0.5` 和 seed 0；各 case 独立加载模型，按三次重复的进程级吞吐中位数统计。
 
-旧脚本直接向 instruct 模型输入原始文本，GSM8K 默认 128 tokens 导致 1304/1319 个输出被截断；GPQA 又要求整段输出只能是单个字母，带解释的明确答案也会被判为无法解析。修复后统一应用 Qwen chat template，明确答案格式，并仅解析独立、带标签或完整括号包围的开头选项；`A careful...`、`C or D` 和未闭合括号等含糊文本均拒绝评分，避免虚高。归档中的三组 GPQA 输出各有 198/198 个纯单字母预测，收紧解析后仍各为 47/198。23.7374% 是该 1.5B 模型在本次固定协议下的 baseline 表现，不能泛化为其他模型或提示协议；矩阵能够证明的是两个 offload case 没有引入额外精度下降。
+| 参数 `(group,num)` | 实际选中层 | 释放权重 | 可用 KV cache | current 吞吐 | 吞吐保留 |
+| --- | --- | ---: | ---: | ---: | ---: |
+| baseline | `[]` | 0.000 GiB | 15.66 GiB | 522.718551 tok/s | 100.000000% |
+| `(28,1)` | `[27]` | 0.434 GiB | 16.09 GiB | 448.335942 tok/s | 85.770046% |
+| `(14,1)` | `[13,27]` | 0.868 GiB | 16.52 GiB | 233.570208 tok/s | 44.683742% |
 
-## 5.5 精度验收标准
+`(28,1)` 的实际证据为 1 个包裹、466,115,584 offloaded bytes。它以约 0.434 GiB 容量换取约 85.77% 吞吐保留，是当前负载的实际容量膝点；容量要求更高时可评估 `(14,1)`，但其吞吐代价显著。该判断不把低密度点的微小波动表述为提速。
 
-两个参数 case 通过精度验证必须同时满足：
+## 5.5 current/latest 公平对比
 
-1. 数据集名称、正式行数和 SHA-256 与内置正式合同一致。
-2. 记录的 `offload_group_size` 与 `offload_num_in_group` 与 case 定义一致。
-3. prompt protocol、temperature、生成预算和 seed 与正式合同一致。
-4. 三组 case 的 model、seed 和 dataset source 完全一致。
-5. 结果中的 `correct/total` 与 accuracy 计算一致。
-6. 相对 baseline 的 accuracy drop 不大于 0。
-7. 保存的 example JSONL 哈希与 baseline 一致。
+同运行时主比较将 current 与 official latest 固定在同一 v0.23.0rc1/CANN 9.0.1 运行时，仅覆盖项目 offloader。10 组正参数对的进程吞吐中位数差范围为 **-0.086595% 至 +0.043851%**；长窗口复测中，`(14,1)` 为 +0.003119%，`(28,1)` 为 -0.299468%。
 
-## 5.6 证据限制
+这些微小正值小于或接近进程间运行变化，且 `(28,1)` 在短、长窗口均未优于 latest。因此，当前实现相对 official latest **未确认稳定速度优势**。主结论是可复现的容量/吞吐取舍与公平比较链路，而不是 current-over-latest 的性能领先。
 
-当前 Git 仓库仍未包含体积较大的正式原始归档。7 月 21 日九次性能原始记录仍需从远端归档取得；修复后的六组精度 JSONL、结果 JSON、严格汇总、完整日志、运行清单和测试 XML 已下载到 Git 工作区外的 `D:\PDSL\Ascend\reproduction-results-20260730`。最终归档名为 `accuracy-fixed-bc33c33-formal-20260730-e2cd297.tar.gz`，SHA-256 为 `b95b3c0ccc5b30ab166c058ba5e3fb7ca14e91197f35f514486b177512ca571f`。
+## 5.6 native v0.18 辅助观察
 
-正式评审复现应以一键脚本重新生成结果，或将以下远端归档制作成不可变提交附件：
+native v0.18 的 12 个进程覆盖 baseline、`(28,1)`、`(14,1)` 和 `(8,1)`，用于确认目标版本路径在固定环境中的辅助表现。该对照混合 vLLM、vLLM Ascend、Torch、Python 和打包状态，不能将跨栈吞吐差异归因于 offloader；同运行时 current/latest 配对仍是唯一的主比较证据。
 
-```text
-/data/v018-performance-formal-20260721
-/data/reproduction-results/accuracy-fixed-bc33c33-formal-20260730
-```
+native 日志中的 sleep mode 禁用提示不等同于 offloader 失败，但进一步限制了跨栈表的解释范围。
+
+## 5.7 归档与限制
+
+最终 hardened-v6 结果归档为 `qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-results.tar.gz`，SHA-256 为 `a8cc0ae4aa506d5c75f97d891001006889554e6b4b14603758e0a5e2014521f3`。其 `validation.json` 必须保持 `valid=true` 与 `model_files_verified=true`；正式复核还应检查 90 条记录、90 份日志、90 份 runtime evidence 和独立重算的零差值。
+
+大型原始归档不纳入 Git。性能结论仅适用于单卡、固定输入输出长度和固定负载；该性能实验未采集 GSM8K 或 GPQA，因此不得从容量/吞吐结果推导精度结论。
 
 ---
 
@@ -469,7 +447,9 @@ GPQA:
 
 ## 6.1 参与环节
 
-AI 工具用于：
+本项目使用的 AI 工具为 **OpenAI Codex**。Codex 主要用于代码调用链分析、实现差异梳理、测试与复现脚本辅助编写、远程环境问题排查，以及测试结果和材料数据交叉审计。所有技术结论均以实际代码、运行日志和复现结果为准。
+
+具体参与环节如下：
 
 - 阅读 vLLM、vLLM Ascend 的参数和 offloader 调用链。
 - 梳理 v0.18.0 与后续版本的实现差异。
@@ -506,8 +486,10 @@ AI 工具用于：
 3. 设备 index 自动探测只取首个 Ascend 映射，多卡需要显式配置。
 4. 健康检查可通过 `SKIP_NPU_HEALTH_CHECK=1` 跳过，正式复现必须记录该变量未设置。
 5. example JSONL 哈希尚未被 `verify_accuracy_matrix.py` 自动强制校验。
-6. 正式原始结果尚未进入当前 Git 仓库。
-7. 同步 offloader 不是 `offload_backend` 可选择的正式用户后端。
+6. 正式原始结果尚未进入当前 Git 仓库，必须按归档 hash 与 `validation.json` 复核。
+7. 大模型性能证据覆盖容量与吞吐，不包含 GSM8K 或 GPQA 精度运行。
+8. current/latest 的微小差异未建立稳定速度优势，不能据此推广为实现提速。
+9. 同步 offloader 不是 `offload_backend` 可选择的正式用户后端。
 
 ## 7.2 后续优化方向
 
@@ -536,11 +518,11 @@ AI 工具用于：
 
 ## 7.3 最终结论
 
-本项目在 vLLM Ascend v0.18.0 上完成了 `offload_group_size` 与 `offload_num_in_group` 的参数适配、Ascend 分组预取卸载和完整测试复现链。
+本项目在 vLLM Ascend v0.18.0 上完成了 `offload_group_size` 与 `offload_num_in_group` 的参数适配、Ascend 分组预取卸载和完整复现链。修复后的 `qwen-chat-v1` 协议下，1.5B 三组 GSM8K 均为 72.2517%、GPQA Diamond 均为 23.7374%，两个 offload case 的额外精度下降为 0，且逐题输出哈希一致。
 
-两个参数均通过 GSM8K 和 GPQA Diamond 全量矩阵的零精度下降验证；在修复后的 `qwen-chat-v1` 协议下，三组成绩分别稳定为 72.2517% 和 23.7374%，且每个数据集的逐题输出哈希一致。正式性能结果量化了权重 storage、KV cache 和吞吐之间的权衡。最温和的 `group_8_num_1` 组合节省约 0.2615 GB 权重 storage，吞吐下降 8.61%；更激进的 `group_8_num_2` 节省约 0.5230 GB，但吞吐下降 48.37%。
+独立的 7B 证据表明，`(28,1)` 在当前负载下释放约 0.434 GiB 权重容量、将 KV cache 提升至 16.09 GiB，并保留约 85.77% 吞吐，是实际容量膝点。current/latest 同运行时与长窗口证据均未确认稳定速度优势，因此本项目不宣称提速。
 
-因此，本项目的主要价值是把“是否卸载、每组卸载多少层”从不可控行为转化为可配置、可测试、可复现的工程能力，并明确给出适用边界：在 HBM 容量成为主要约束时使用，在吞吐优先且模型可直接装入时保持 baseline。
+项目的主要价值是把“是否卸载、每组卸载多少层”转化为可配置、可测试、可复现且可审计的工程能力。应在 HBM 容量成为主要约束时选择合适参数；吞吐优先且模型可直接装入时保持 baseline，并在目标负载上重新验证。
 
 ---
 
@@ -676,13 +658,41 @@ sha256sum \
 
 每组数据集的三个哈希应完全相同。
 
+## A.8 7B current/latest 对比与归档复核
+
+在精确项目根执行前，三个 runner-owned 目录必须不存在：
+
+```text
+/data/reproduction-results/qwen25-7b-current-vs-latest-20260731-rerun
+/data/reproduction-results/qwen25-7b-current-vs-latest-20260731-rerun.current_impl_overlay
+/data/reproduction-results/qwen25-7b-current-vs-latest-20260731-rerun.cache
+```
+
+随后执行精确对比命令：
+
+```bash
+cd /data/ccf-vllm-ascend-ec673f8-exact
+RESULTS_DIR=/data/reproduction-results/qwen25-7b-current-vs-latest-20260731-rerun \
+bash /data/ccf-vllm-ascend-ec673f8-exact/scripts/run_large_model_parameter_comparison.sh
+```
+
+产物目录包含 `same-runtime-runs.jsonl`、`long-window-runs.jsonl`、`native-v018-runs.jsonl`、对应 `*-logs/`、runtime evidence sidecar、`comparison-summary.json`、`comparison-summary.csv`、`comparison-summary.md`、`validation.json` 和 `independent-verification.log`。复核 `validation.json` 的 `valid=true`、`model_files_verified=true`，确认 63 + 15 + 12 = 90 条记录与日志计数，再检查独立重算的三个 `MAX_*_DIFF` 均为 0。
+
+最终归档为 `qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-results.tar.gz`，SHA-256：
+
+```text
+a8cc0ae4aa506d5c75f97d891001006889554e6b4b14603758e0a5e2014521f3
+```
+
 ---
 
-# 附录 B：答辩参数建议
+# 附录 B：Qwen2.5-7B 固定负载参数建议
+
+下表仅适用于本报告的单卡 Qwen2.5-7B 固定负载：8 个 prompts、128 输入 tokens、64 最大输出 tokens、`max_model_len=512` 和 `gpu_memory_utilization=0.5`。它描述容量与吞吐边界，不表示当前实现相对 official latest 存在速度优势。
 
 | 场景 | 建议 |
 | --- | --- |
-| 模型和 KV cache 均可直接装入，吞吐优先 | 保持 `baseline_0_1` |
-| 需要温和释放权重空间，允许约 10% 吞吐代价 | 优先评估 `group_8_num_1` |
-| 容量优先，baseline 无法满足 HBM 约束 | 评估 `group_8_num_2` 或其他组合，并重新压测 |
-| 多卡、长上下文或高并发 | 不直接套用本报告数字，必须在目标负载复现 |
+| 模型和 KV cache 均可直接装入，吞吐优先 | 保持 `baseline`；可用 KV cache 为 15.66 GiB，作为 100% 吞吐参考。 |
+| 需要约 0.434 GiB 额外容量，且可接受约 14.23% 吞吐代价 | 优先评估 `(28,1)`；可用 KV cache 为 16.09 GiB，吞吐保留约 85.77%，是本负载的实际容量膝点。 |
+| baseline 和 `(28,1)` 均无法满足容量约束 | 在容量优先条件下评估 `(14,1)`；可用 KV cache 为 16.52 GiB、额外释放约 0.868 GiB 权重容量，但吞吐仅保留约 44.68%。 |
+| 多卡、长上下文、高并发或不同模型 | 不直接套用本表数字；必须在目标负载重新压测，并且不将微小 current/latest 差异解释为稳定提速。 |

docs/superpowers/plans/2026-08-03-finals-materials-refresh.md

@@ -0,0 +1,392 @@
+# 决赛结项材料更新 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 将决赛结项书与 12 页答辩 PPT 更新为同时覆盖 Qwen2.5-1.5B 正式精度验证和 Qwen2.5-7B current/latest 性能对比的最终材料。
+
+**Architecture:** 以结构化事实清单作为单一数据源，先更新 Markdown，再从 Markdown 重建 DOCX，并使用同一事实清单更新模板继承式 PPT。最后通过 OOXML 文本抽取、全页渲染、边界检查和人工视觉审查验证三份材料的内容与版式。
+
+**Tech Stack:** Markdown、Git、Python 3、python-docx、OOXML、LibreOffice/Poppler、Node.js、`@oai/artifact-tool`、赛事 PPTX 模板。
+
+## Global Constraints
+
+- 主标题保持为 `[功能] 适配 offload_group_size 和 offload_num_in_group 到 Ascend NPU`。
+- 副标题保持为 `vLLM Ascend 权重分组预取卸载参数适配与优化`。
+- 团队名称保持为 `乘风破浪的大学生`。
+- 目标版本是 vLLM Ascend v0.18.0；性能对比的 official latest 固定为 v0.23.0rc1 提交 `f4a08bd`。
+- 精度证据来自 Qwen2.5-1.5B-Instruct；7B 性能实验未采集精度，不得写成 7B 通过 GSM8K/GPQA。
+- 当前实现相对 official latest 没有可确认的稳定速度优势，不得将微小正差包装为提速结论。
+- PPT 使用 `D:\PDSL\Ascend\CCF大赛-vLLM Ascend赛道PPT模板.pptx`的主题、比例和品牌元素，保持 12 页。
+- 三份最终交付物位于 `docs/finals/`；内部构建与渲染文件位于 `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\`。
+- 不修改核心实现、测试脚本和原始实验证据；不把大型结果归档加入 Git。
+- 完成后可提交到本地当前分支；未经用户明确要求不执行远程推送。
+
+---
+
+## File Map
+
+- Modify: `docs/finals/决赛项目结项书.md` - 三份材料的内容权威源。
+- Modify: `docs/finals/决赛项目结项书.docx` - 从 Markdown 重建的正式报告。
+- Modify: `docs/finals/决赛答辩PPT.pptx` - 沿用赛事模板的 12 页答辩文件。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\evidence.json` - 可机器校验的版本、精度、性能和归档事实。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\evidence-summary.md` - 供人工审阅的事实清单。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_report_refresh.py` - 更新版 Markdown→DOCX 构建器。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck_refresh.mjs` - 更新版模板继承式 PPT 构建器。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\verify_final_materials.py` - 抽取 Markdown/DOCX/PPTX 文本并检查关键口径。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\docx-render\` - DOCX 全页 PNG 和 PDF。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-render\` - PPT 全页 PNG。
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\visual-review.md` - 逐页视觉审查记录。
+
+### Task 1: 建立双证据事实清单
+
+**Files:**
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\evidence.json`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\evidence-summary.md`
+- Read: `docs/finals/qwen25-7b-current-vs-latest-parameter-performance.md`
+- Read: `docs/finals/parameter-optimization-performance.md`
+- Read: `docs/v018-test-evidence.md`
+- Read: `docs/finals/决赛项目结项书.md`
+- Read: `D:\PDSL\Ascend\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-results.tar.gz`
+
+**Interfaces:**
+- Consumes: 仓库内已提交报告、Git 历史和 hardened-v6 最终归档。
+- Produces: `evidence.json` 中的 `versions`、`accuracy`、`performance`、`validation`、`archive` 对象，供后续文档和校验器使用。
+
+- [ ] **Step 1: 固定 Git 身份和开发时间线**
+
+  Run: `git rev-parse HEAD`
+
+  Run: `git log --reverse --oneline f0ab805..HEAD`
+
+  Expected: HEAD 包含设计提交 `49065ee`，时间线覆盖精度协议修复、7B runner/analyzer、hardened-v6 证据加固与最终复现套件。
+
+- [ ] **Step 2: 复核最终 7B 归档身份**
+
+  Run: `Get-FileHash 'D:\PDSL\Ascend\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-results.tar.gz' -Algorithm SHA256`
+
+  Expected: `A8CC0AE4AA506D5C75F97D891001006889554E6B4B14603758E0A5E2014521F3`。
+
+- [ ] **Step 3: 复核最终 validation 与独立重算证据**
+
+  Run: `Get-Content -Raw 'D:\PDSL\Ascend\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-final-verified-extracted\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8\validation.json'`
+
+  Run: `Select-String -Path 'D:\PDSL\Ascend\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-final-verified-extracted\qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8\independent-verification.log' -Pattern 'MAX_PROCESS_DIFF|MAX_POOLED_DIFF|MAX_COMPARISON_DIFF'`
+
+  Expected: `valid` 为 true，`model_files_verified` 为 true，记录/日志计数为 63 + 15 + 12；三个 `MAX_*_DIFF` 均为 `0.000000000000`。
+
+- [ ] **Step 4: 写入 `evidence.json` 和 `evidence-summary.md`**
+
+  记录以下精确值：
+
+  ```json
+  {
+    "accuracy_model": "Qwen2.5-1.5B-Instruct",
+    "gsm8k": {"correct": 953, "total": 1319, "accuracy_pct": 72.2517},
+    "gpqa_diamond": {"correct": 47, "total": 198, "accuracy_pct": 23.7374},
+    "performance_model": "Qwen/Qwen2.5-7B-Instruct",
+    "processes": {"same_runtime": 63, "long_window": 15, "native_v018": 12, "total": 90},
+    "same_runtime_diff_pct_range": [-0.086595, 0.043851],
+    "knee": {"group": 28, "num": 1, "offloaded_gib": 0.434, "kv_cache_gib": 16.09, "throughput_retained_pct": 85.770046},
+    "archive_sha256": "a8cc0ae4aa506d5c75f97d891001006889554e6b4b14603758e0a5e2014521f3"
+  }
+  ```
+
+- [ ] **Step 5: 扫描事实清单的占位符和数字矛盾**
+
+  Run: `rg -n "51/1319|0/198|3\.8666|742\.77|678\.85|383\.49" 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh'`
+
+  Expected: 无占位符；旧精度和旧 PPT 主性能数字不出现在新事实清单中。
+
+### Task 2: 更新结项书 Markdown
+
+**Files:**
+- Modify: `docs/finals/决赛项目结项书.md`
+- Read: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\evidence.json`
+- Read: `docs/finals/qwen25-7b-current-vs-latest-parameter-performance.md`
+- Read: `docs/finals/parameter-optimization-performance.md`
+- Read: `docs/superpowers/specs/2026-08-03-finals-materials-refresh-design.md`
+
+**Interfaces:**
+- Consumes: Task 1 的固定事实。
+- Produces: 七章结构的最新 Markdown，供 DOCX 和 PPT 构建器使用。
+
+- [ ] **Step 1: 更新封面元数据与摘要**
+
+  将代码与复现套件提交写为 `851feb5`，将 7B 实测部署提交单独写为 `ec673f8`，避免将后续文档提交写成代码身份。日期更新为 `2026 年 8 月`。摘要先给出 1.5B 零精度下降，再给出 7B `(28,1)` 容量膝点和“无稳定速度优势”结论。
+
+- [ ] **Step 2: 更新项目概述与开发历史**
+
+  在第一章加入四阶段历程：v0.18.0 参数适配、`qwen-chat-v1` 精度协议修复、Qwen2.5-7B 同运行时 current/latest 对比、hardened-v6 身份绑定与独立重算。
+
+- [ ] **Step 3: 补充技术方案中的证据链**
+
+  说明 runtime evidence hook 直接从实际 offloader 对象捕获 `selected_layers`、`wrapped_count`、`offloaded_bytes` 和实际类名；说明 CANN、wheel/package tree、latest/native source tree、模型清单和 runner 的 fail-closed 身份绑定。
+
+- [ ] **Step 4: 更新实际交付清单**
+
+  补充 `scripts/run_large_model_parameter_comparison.sh`、`scripts/analyze_large_model_parameter_comparison.py`、`scripts/run_current_vs_latest_performance.sh`、`scripts/run_parameter_optimization_benchmark.sh` 及对应单测。
+
+- [ ] **Step 5: 重写测试结论为双证据结构**
+
+  第五章固定为：测试环境与模型边界、功能/证据测试、1.5B GSM8K/GPQA、7B 参数容量/吞吐、current/latest 公平对比、native v0.18 辅助观察、归档与限制。
+
+- [ ] **Step 6: 更新总结、限制与复现附录**
+
+  最终结论不宣称提速；将 `(28,1)` 定义为当前负载的实际容量膝点。附录增加 7B 对比精确命令、产物目录、`validation.json` 检查和最终归档 SHA-256。
+
+- [ ] **Step 7: 执行 Markdown 事实与格式检查**
+
+  Run: `rg -n "72\.2517|23\.7374|90 条|0\.434 GiB|85\.77|v0\.23\.0rc1|-0\.086595|\+0\.043851|a8cc0ae4" docs/finals/决赛项目结项书.md`
+
+  Run: `rg -n "51/1319|0/198|3\.8666|优于 official latest|7B.*GSM8K|7B.*GPQA" docs/finals/决赛项目结项书.md`
+
+  Expected: 第一条命中所有关键事实；第二条不出现旧分数或越界表述。
+
+  Run: `git diff --check -- docs/finals/决赛项目结项书.md`
+
+  Expected: 无空白错误或冲突标记。
+
+- [ ] **Step 8: 提交 Markdown 内容更新**
+
+  Run: `git add docs/finals/决赛项目结项书.md`
+
+  Run: `git commit -m "docs: refresh finals report evidence"`
+
+### Task 3: 重建并验证 DOCX 结项书
+
+**Files:**
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_report_refresh.py`
+- Modify: `docs/finals/决赛项目结项书.docx`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\docx-render\`
+
+**Interfaces:**
+- Consumes: Task 2 的 Markdown。
+- Produces: 内容一致、可打印且经过全页渲染的 DOCX。
+
+- [ ] **Step 1: 阅读 `documents` skill 并加载工作区依赖**
+
+  使用本会话的 `documents:documents` skill，并调用 `codex_app__load_workspace_dependencies`。固定 Python 为 `C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe`。
+
+- [ ] **Step 2: 从旧构建器创建 refresh 副本**
+
+  Source: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_report.py`
+
+  Destination: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_report_refresh.py`
+
+  保留封面、目录、页眉页脚、表格宽度、代码块和 Markdown 解析逻辑；将封面日期更新为 `2026 年 8 月`。
+
+- [ ] **Step 3: 构建 DOCX**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_report_refresh.py'`
+
+  Expected: `docs/finals/决赛项目结项书.docx` 可正常打开，且文件大小大于 50 KB。
+
+- [ ] **Step 4: 执行 DOCX 可访问性审计**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'C:\Users\30780\.codex\plugins\cache\openai-primary-runtime\documents\26.802.11031\skills\documents\scripts\a11y_audit.py' 'docs/finals/决赛项目结项书.docx' --out_json 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\docx-a11y.json'`
+
+  Expected: 无阻断级错误；任何非阻断项写入视觉审查记录。
+
+- [ ] **Step 5: 渲染 DOCX 全部页面**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'C:\Users\30780\.codex\plugins\cache\openai-primary-runtime\documents\26.802.11031\skills\documents\render_docx.py' 'docs/finals/决赛项目结项书.docx' --output_dir 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\docx-render' --emit_pdf`
+
+  Expected: 每页均有 `page-*.png`，同目录生成 `决赛项目结项书.pdf`。
+
+- [ ] **Step 6: 生成接触表并逐页审查**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'D:\PDSL\Ascend\.codex_tmp\finals-materials\make_contact_sheets.py' 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\docx-render'`
+
+  使用 `view_image` 检查所有 `contact-*.png`，再对密度过高、表格跨页或代码换行页查看原始 `page-*.png`。检查封面、目录、孤立标题、表格截断、页眉页脚和异常空白页。
+
+- [ ] **Step 7: 修复所有视觉问题并重新执行 Step 3-6**
+
+  Expected: 视觉审查记录中每个 DOCX 问题都标记为已修复或可接受且给出理由。
+
+- [ ] **Step 8: 提交 DOCX**
+
+  Run: `git add docs/finals/决赛项目结项书.docx`
+
+  Run: `git commit -m "docs: rebuild finals report document"`
+
+### Task 4: 重建 12 页决赛答辩 PPT
+
+**Files:**
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck_refresh.mjs`
+- Modify: `docs/finals/决赛答辩PPT.pptx`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-artifact-preview\`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-artifact-layout\`
+
+**Interfaces:**
+- Consumes: Task 1 事实清单、Task 2 Markdown 和现有 `template-starter.pptx`。
+- Produces: 12 页模板继承式 PPTX，每页含建议时长、讲述要点和证据来源备注。
+
+- [ ] **Step 1: 阅读 `presentations` skill 并固定 Node 运行时**
+
+  使用本会话的 `presentations:Presentations` skill。固定 Node 为 `C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe`，并复用 `D:\PDSL\Ascend\.codex_tmp\finals-materials\node_modules\@oai\artifact-tool`。
+
+- [ ] **Step 2: 从旧构建器创建 refresh 副本**
+
+  Source: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck.mjs`
+
+  Destination: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck_refresh.mjs`
+
+  保留颜色、字体、模板导入、标题替换、讲者备注、预览和 layout 导出工具函数。
+
+- [ ] **Step 3: 更新 12 页内容结构**
+
+  使用以下固定页序与时长，合计 680 秒：
+
+  | 页 | 主题 | 秒 |
+  | ---: | --- | ---: |
+  | 1 | 封面 | 20 |
+  | 2 | 决赛成果总览 | 45 |
+  | 3 | 参数语义与容量边界 | 45 |
+  | 4 | Ascend 分组预取卸载架构 | 60 |
+  | 5 | 开发历程与版本对比 | 55 |
+  | 6 | 设计实现 | 75 |
+  | 7 | 功能与证据验证 | 50 |
+  | 8 | GSM8K / GPQA 精度 | 60 |
+  | 9 | Qwen2.5-7B 容量与吞吐权衡 | 90 |
+  | 10 | 当前实现 vs official latest | 75 |
+  | 11 | 决赛阶段提升与工程价值 | 80 |
+  | 12 | 总结与致谢 | 25 |
+
+  第 11 页必须将 AI 辅助定位为调用链阅读、可证伪假设、测试生成和证据审计工具，并明确所有结论由代码、日志和复现脚本约束。
+
+- [ ] **Step 4: 更新精度与性能可视化**
+
+  第 8 页展示 1.5B 三组均为 GSM8K 953/1319（72.2517%）与 GPQA 47/198（23.7374%）。第 9 页展示 7B baseline、`(28,1)`、`(14,1)` 的 KV cache、吞吐与释放容量；将 `(28,1)` 标为当前负载膝点。第 10 页展示同运行时差范围 -0.086595% 至 +0.043851% 和长窗口 `(14,1)` +0.003119% / `(28,1)` -0.299468%。
+
+- [ ] **Step 5: 写入讲者备注和证据来源**
+
+  每页备注包含 `建议时长`、`讲述要点`、`证据来源`。第 8 页来源为结项书和精度报告；第 9-10 页来源为 `docs/finals/qwen25-7b-current-vs-latest-parameter-performance.md` 和 hardened-v6 归档。
+
+- [ ] **Step 6: 构建 PPTX 和 Artifact Tool 预览**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe' 'D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck_refresh.mjs'`
+
+  Expected: `docs/finals/决赛答辩PPT.pptx` 为 12 页，且 refresh 预览目录有 12 张 PNG 和 12 份 layout JSON。
+
+### Task 5: 渲染和修复 PPT 版式
+
+**Files:**
+- Modify: `D:\PDSL\Ascend\.codex_tmp\finals-materials\build_final_deck_refresh.mjs`
+- Modify: `docs/finals/决赛答辩PPT.pptx`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-render\`
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\visual-review.md`
+
+**Interfaces:**
+- Consumes: Task 4 PPTX。
+- Produces: 无溢出、无遮挡、可在 12 分钟内讲完的最终 PPTX。
+
+- [ ] **Step 1: 使用 LibreOffice/Poppler 渲染全部幻灯片**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'C:\Users\30780\.codex\plugins\cache\openai-primary-runtime\presentations\26.802.11031\skills\presentations\container_tools\render_slides.py' 'docs/finals/决赛答辩PPT.pptx' --output_dir 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-render'`
+
+  Expected: 生成 12 张 `slide-*.png`。
+
+- [ ] **Step 2: 执行画布边界检查**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'C:\Users\30780\.codex\plugins\cache\openai-primary-runtime\presentations\26.802.11031\skills\presentations\container_tools\slides_test.py' 'docs/finals/决赛答辩PPT.pptx'`
+
+  Expected: 不报告内容超出原始画布。
+
+- [ ] **Step 3: 生成接触表并逐页审查**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'D:\PDSL\Ascend\.codex_tmp\finals-materials\make_contact_sheets.py' 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\ppt-render'`
+
+  使用 `view_image` 检查所有接触表和数据密集页原图，重点检查第 5、8、9、10、11 页的文本边界、图表标签、颜色区分、单位和结论可读性。
+
+- [ ] **Step 4: 修复溢出、重叠和密度问题**
+
+  仅修改 refresh 构建器。每轮修改后重新执行 Task 4 Step 6 和本 Task Step 1-3，直到所有 12 页合格。
+
+- [ ] **Step 5: 提交 PPTX**
+
+  Run: `git add docs/finals/决赛答辩PPT.pptx`
+
+  Run: `git commit -m "docs: refresh finals defense deck"`
+
+### Task 6: 跨文件一致性与最终验收
+
+**Files:**
+- Create: `D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\verify_final_materials.py`
+- Verify: `docs/finals/决赛项目结项书.md`
+- Verify: `docs/finals/决赛项目结项书.docx`
+- Verify: `docs/finals/决赛答辩PPT.pptx`
+
+**Interfaces:**
+- Consumes: Task 1-5 的事实清单和三份交付物。
+- Produces: 一致性报告、最终 Git 变更范围和可交付材料。
+
+- [ ] **Step 1: 实现 OOXML 文本抽取与断言**
+
+  `verify_final_materials.py` 使用 `zipfile` 和 `xml.etree.ElementTree` 抽取 DOCX `word/document.xml` 以及 PPTX `ppt/slides/slide*.xml`/`ppt/notesSlides/notesSlide*.xml`。断言：
+
+  ```python
+  REQUIRED_ALL = [
+      "[功能] 适配 offload_group_size 和 offload_num_in_group 到 Ascend NPU",
+      "乘风破浪的大学生",
+      "v0.18.0",
+  ]
+  REQUIRED_REPORT_AND_DECK = [
+      "72.2517%",
+      "23.7374%",
+      "0.434 GiB",
+      "85.77",
+      "v0.23.0rc1",
+  ]
+  FORBIDDEN = [
+      "51 / 1319",
+      "0 / 198",
+      "3.8666%",
+      "当前实现优于 official latest",
+      "7B 已通过 GSM8K",
+      "7B 已通过 GPQA",
+  ]
+  ```
+
+  同时断言 PPTX 有 12 个 slide XML，备注中的建议时长之和为 680 秒。
+
+- [ ] **Step 2: 运行跨文件校验器**
+
+  Run: `& 'C:\Users\30780\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe' 'D:\PDSL\Ascend\.codex_tmp\finals-materials-refresh\verify_final_materials.py'`
+
+  Expected: 报告 Markdown/DOCX/PPTX 关键事实齐全、无禁止表述、PPT 12 页、建议时长 680 秒。
+
+- [ ] **Step 3: 重跑与本次材料相关的仓库测试**
+
+  Run: `python -m unittest tests.model_executor.offloader.test_accuracy_repro tests.model_executor.offloader.test_parameter_optimization_analysis`
+
+  Run: `python -m unittest tests.model_executor.offloader.test_large_model_parameter_comparison`
+
+  Expected: 两组命令均返回 0，证明文档所引复现契约仍可用。
+
+- [ ] **Step 4: 检查仓库差异和文件大小**
+
+  Run: `Get-Item docs/finals/决赛项目结项书.md,docs/finals/决赛项目结项书.docx,docs/finals/决赛答辩PPT.pptx | Select-Object Name,Length,LastWriteTime`
+
+  Run: `git diff --check`
+
+  Run: `git status --short --branch`
+
+  Expected: 三份交付物均非空；仅存在计划内的文档变更；核心代码和测试文件无变更。
+
+- [ ] **Step 5: 记录最终视觉审查结果**
+
+  在 `visual-review.md` 写入 DOCX 页数、PPT 12 页、已查看的接触表、修复过的页面和剩余非阻断风险。不得使用“大概”、“应该”或“未检查”作为通过依据。
+
+- [ ] **Step 6: 提交验收修复（仅在最终验收产生额外交付文件变更时）**
+
+  Run: `git add docs/finals/决赛项目结项书.md docs/finals/决赛项目结项书.docx docs/finals/决赛答辩PPT.pptx`
+
+  Run: `git commit -m "docs: finalize finals materials refresh"`
+
+- [ ] **Step 7: 确认最终分支状态**
+
+  Run: `git status --short --branch`
+
+  Run: `git log --oneline -6`
+
+  Expected: 工作区干净，当前分支包含设计、计划和材料更新提交，但未自动推送。

docs/superpowers/specs/2026-08-03-finals-materials-refresh-design.md

@@ -0,0 +1,107 @@
+# 决赛结项材料更新设计说明
+
+## 1. 目标与范围
+
+本次更新基于远端分支 `feature/offload-group-num-v018-optimized` 的已同步提交 `851feb5`，将 2026 年 7 月 29 日版决赛结项书和答辩 PPT 更新为反映完整决赛开发历史、精度验证与 Qwen2.5-7B 最终性能对比的正式材料。
+
+交付物保持在 `docs/finals/`：
+
+1. `决赛项目结项书.md`：内容权威源和可版本追踪文本。
+2. `决赛项目结项书.docx`：正式排版和可打印版本。
+3. `决赛答辩PPT.pptx`：沿用赛事模板的 12 页、12 分钟答辩材料。
+
+不修改核心实现、测试脚本或原始实验证据。不将工作区外的大型结果归档加入 Git。
+
+## 2. 统一事实与证据口径
+
+材料采用“双证据主线”，不把不同模型的精度和性能数据混为同一次实验。
+
+### 2.1 精度证据
+
+- 模型：`Qwen2.5-1.5B-Instruct`。
+- 数据集：GSM8K test 1319 条，GPQA Diamond 198 条。
+- 参数组：`baseline_0_1`、`group_8_num_1`、`group_8_num_2`。
+- GSM8K：三组均为 953/1319，即 72.2517%。
+- GPQA Diamond：三组均为 47/198，即 23.7374%。
+- 结论：两个参数 case 相对 baseline 的精度下降为 0，且同数据集的逐题输出 SHA-256 一致。该结论只证明 offload 未引入额外精度损失，不表示模型的绝对任务精度达到其他模型水平。
+
+### 2.2 性能证据
+
+- 模型：`Qwen/Qwen2.5-7B-Instruct`，28 个 decoder layers，benchmark 转为 `float16`。
+- 硬件：Ascend 910B2C，逻辑卡 0，物理 NPU 6。
+- 运行栈：CANN 9.0.1；同运行时主对比基于 vLLM Ascend v0.23.0rc1（`f4a08bd`）。
+- 当前实现性能证据所用项目部署提交：`ec673f8`；材料更新分支 HEAD：`851feb5`。
+- 证据规模：63 个同运行时进程、15 个长窗口进程、12 个 native v0.18 进程，共 90 条记录、90 份日志和 90 份运行时 offloader 证据。
+- 最终归档：`qwen25-7b-current-vs-latest-20260731-hardened-v6-ec673f8-results.tar.gz`，SHA-256 为 `a8cc0ae4aa506d5c75f97d891001006889554e6b4b14603758e0a5e2014521f3`。
+- 主结论：当前实现相对 official latest 未建立可测量、稳定的速度优势。同运行时 10 组正参数对的中位数差范围为 -0.086595% 至 +0.043851%。
+- 推荐点：`(28,1)` 释放约 0.434 GiB 权重容量，KV cache 从 15.66 GiB 增加至 16.09 GiB，吞吐保留约 85.77%，是本负载的实际容量膝点。
+- 限制：7B 运行未采集精度，不从该实验推导 accuracy 结论。
+
+### 2.3 测试与验证证据
+
+- hardened-v6 远端明确列出的 8 个非 Windows offloader 测试文件：87 passed in 18.89s。
+- hardened-v6 本地 focused suite：41 tests passed。
+- 最终归档 `validation.json`：`valid: true`、`model_files_verified: true`，63 + 15 + 12 条记录与日志计数一致。
+- 远端整目录诊断中的 15 个失败均来自 Windows 本地路径或打包流程断言，不计为 Linux/Ascend 运行时失败。
+
+## 3. 结项书设计
+
+结项书沿用原七章结构，避免为追加新实验而破坏初赛到决赛的文档延续性：
+
+1. 项目概述：更新版本、提交、决赛阶段定位和 latest 对比结论。
+2. 参数理解与技术难点：保留参数语义、边界、存储布局和 NPU 异步依赖。
+3. 技术方案：保留 selection/prefetch/runner 架构，增加运行时证据 hook 和 fail-closed 身份绑定。
+4. 实际交付：补充大模型对比 runner、analyzer、独立校验和报告路径。
+5. 测试结论：先给出 1.5B 精度，再给出 7B 容量/吞吐与 current/latest 结论，并明确实验不同源。
+6. AI 工具使用经验：从“生成脚本”扩展至证据身份、失败关闭和独立重算审计。
+7. 限制与后续工作：明确无速度领先结论、7B 无精度数据、单卡固定负载以及大型原始归档位于 Git 之外。
+
+Markdown 作为三份材料的内容权威源。DOCX 从更新后的 Markdown 重新生成，不直接在旧 DOCX 中手工修改数字。
+
+## 4. PPT 设计与答辩节奏
+
+PPT 继续使用赛事模板、12 页和原标题，副标题保持“vLLM Ascend 权重分组预取卸载参数适配与优化”。页面结构为：
+
+1. 封面。
+2. 决赛成果总览：2 个参数、2 个精度数据集、90 个 7B 实验进程、1 套完整复现链。
+3. 参数语义与容量边界。
+4. Ascend 分组预取卸载架构。
+5. 开发历程与版本对比：v0.18.0 适配、精度协议修复、7B 公平对比、证据加固。
+6. 设计实现：selection、storage、stream/event 和 runner 契约。
+7. 功能与证据验证：87 项 Ascend 有关测试、41 项本地 focused tests、90 份 runtime evidence。
+8. GSM8K / GPQA 精度：展示 72.2517% / 23.7374% 与三组输出一致。
+9. Qwen2.5-7B 容量与吞吐权衡：以 baseline、`(28,1)`、`(14,1)` 为主视图。
+10. 当前实现 vs official latest：明确无可确认速度优势，展示同运行时和长窗口结论。
+11. 决赛阶段提升与工程价值：回溯适配、官方契约、证据身份和可复现性。
+12. 总结与致谢。
+
+建议讲述总时长约 11 分 20 秒，预留约 40 秒。性能主结论不表述为“当前实现优于 latest”，而表述为“在 v0.18.0 上完成参数能力回溯，并建立与后续官方实现的可复现公平对比”。
+
+## 5. 文档与演示文件生成
+
+- DOCX 保持 A4 正式技术报告风格，含封面、目录、页眉页脚、页码、表格和代码块。
+- PPT 保留原模板主题、比例、封面和结束页品牌识别；只替换内容区与讲者备注。
+- 表格和图表的数据从统一事实源生成，避免 Markdown、DOCX 与 PPT 之间的数字漂移。
+- 内部构建脚本和渲染中间件位于 `.codex_tmp/finals-materials-refresh/`，不作为决赛交付上传。
+
+## 6. 验收与风险控制
+
+### 6.1 内容验收
+
+- 三份材料的主标题、副标题、团队、目标版本和关键结论一致。
+- 性能与精度段落每处都明确标注模型和实验协议。
+- 不出现“当前实现速度优于 official latest”或“7B 已通过 GSM8K/GPQA”等超出证据的表述。
+- 归档 SHA-256、样本数、准确率、进程数和主要吞吐数据均与仓库报告或本地最终归档一致。
+
+### 6.2 文档验收
+
+- Markdown 通过差异格式和占位符扫描。
+- DOCX 经过结构检查、全页渲染和逐页视觉检查，无截断、重叠、孤立标题或异常空白页。
+- PPT 保持 12 页，经过全页渲染、边界/溢出检查和视觉审查，不遮挡模板标识、页码或关键数据。
+- 从 DOCX/PPTX 提取文本，与 Markdown 交叉校验标题、版本和关键数字。
+
+### 6.3 仓库验收
+
+- 完成后仅包含设计、计划和三份交付材料的预期变更。
+- 核心代码、测试脚本和原始实验证据保持不变。
+- 不在未经用户明确要求时自动推送最终材料。