acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32

@jiangkuaixue123

本次 8K/1K、C1/C4/C16/C32 续轮已迁至 #353 单独跟踪；首次优化前先完成新负载基线及校准。本 issue 保留历史 1K/1K 六档记录，以下历史计划快照不作为新轮次执行契约。

Current state: 2026-11-04（Asia/Shanghai）按 owner 在关联聊天中的续轮意图刷新计划：从已交付 77a4dfde962c2c99d2b69b1879e97b3fcc4209ca 继续优化，目标仍为 C1–C32 六档各自 TPOT ≤25 ms/token、固定 GSM8K ≥292/300。最新精度 294/300（98.00%）通过；两轮性能中位为 46.514 / 45.691 / 47.131 / 49.001 / 50.814 / 63.922 ms/token，六档均未达 25。历史第三轮已按用户指示中断，不计入统计。整体 INCONCLUSIVE。本次核对本地提交与最终核验引用的 12 份证据文件哈希，全部一致；未重跑设备实验或 AISBench 原生评分器。
Decision needed: 本次文档与 issue 刷新无待决问题。续轮采用当前配置重新 A/A 校准后冻结门槛的流程，具体门槛尚未实测；历史逐提交配对/精度与证据公开可访问性缺口继续保留，不由当前精度通过代替。
Next action: 负责人 @jiangkuaixue123 后续按下方“续轮优化实验罗盘”完成运行前环境/源码/资料隔离核验，冻结 RunSpec、validator 及当前配置校准，再推进单假设优化。本次立即交付为新的 Markdown 与本 issue 刷新，没有启动新性能/精度运行。

Campaign

dsv41-910c-decode-tpot25 · 跟踪人 @jiangkuaixue123 · 当前验收结论 INCONCLUSIVE。本 issue 跟踪 vllm-ascend 分支 codex/dsv41-0day 上 DeepSeek V4.1 Flash 的 decode 性能与精度。#289 和 #326 跟踪 AISBench 适配。

2026-11-04 续轮授权与资料边界

Owner 最新要求允许读取 InferRSI 和 vllm-ascend 中除 DeepSeek V4.1 专属知识、DeepInfer 相关知识之外的所有知识，不限于通用知识；其他模型专属知识、案例及优化经验均可按需读取。禁止读取 DeepInfer 相关知识库和 DSV4.1 专属知识库，包括派生摘要、缓存、语义检索和代理间接访问。允许使用本次关联聊天、当前分支源码与本任务自身实验记录；它们不等同于模型专属知识库。允许文件按排除两类禁止内容的来源白名单选择；既有测量运行器继续关闭自动知识检索。外部 V4.1 实现仍沿用原任务仅指定 HF 仓库的限制。

本次明确为继续优化的准备阶段：整理实验配置、精度/性能测试、目标并刷新任务记录。最新起点已有十个 signed-off checkpoint；保留其历史谱系与缺少正式逐提交验收的边界。旧基线的两组例外、旧开关、旧候选身份不作为续轮默认值。续轮固定 FlashComm1 开、fused MC2=0、TP4/DP4/EP16、DSpark5、FULL_DECODE_ONLY。

当前开关要求

按最新要求，显式开启 FlashComm1（additional_config.enable_flashcomm1=true、服务进程 VLLM_ASCEND_ENABLE_FLASHCOMM1=1），关闭 fused MC2（additional_config.enable_fused_mc2=0，整数）。DSA CP、shared expert DP、TP4 / DP4 / EP16、DSpark5、FULL_DECODE_ONLY 与 16K 配置沿用原方案。V4.1 目标模型和草稿使用现有 Ascend grouped MoE 路径。

V4.1 fused MC2 接入仍维持撤回。早期 HC + 分页 KV 工作源码清单 4a06cea113696b87244db790a57c23349e9065a89dad1300d45ad80cce50ba82 是历史候选，不是当前交付版本。当前续轮起点为 77a4dfde962c2c99d2b69b1879e97b3fcc4209ca，部署源码清单 SHA-256 为 99a5d50c7c55ff95dd2af700a22c85e9c883915ebfbe76f4e13ab29b1fed3ee0。新增父/候选两臂须使用相同固定配置。

历史初始修订与基线运行配置（不作为续轮当前配置）

项目	冻结值
vllm-ascend 初始基线	`d4ac4319acdaf480689c39b6320a998712f80523`
上游 vLLM / InferRSI	`6e448d0ea9bf3d88d898b65449ca6dc2aec170ac` / `919ed42c0d01dc0aa3b613085b9041d735d2d4db`
当前交付 / 续轮起点 Git SHA	`77a4dfde962c2c99d2b69b1879e97b3fcc4209ca`；新候选另记直接父提交、候选提交及部署清单。已有提交不等于逐提交正式验收完成。
设备与精度	Ascend 910C，单机 8 卡、16 die，W8A8，PD 混部；TP4、DP4、EP16
服务	DSpark5，`FULL_DECODE_ONLY`，capture sizes 24/48，模型长度 16,384，block 128，batched tokens 8,192，每 DP 最多 8 个序列
Ascend 开关	DSA CP 开、显式 FlashComm1 关、shared expert DP 开
软件	CANN 9.1.0、驱动 25.5.1.1、Python 3.12.13、torch 2.10.0+cpu、torch-npu 2.10.0.post4
环境校验	公共环境签名 `44411269e2ef51b0c24ae8c4b4bea603f1dea6f8645f828b79d9081d6eff791b`。权重按索引、全部分片元数据和采样字节校验。

验收条件

锁定输入、输出、采样、计分和初始精度。每个性能请求精确 1,024 入、1,024 出；全服务并发 1、2、4、8、16、32。每档先独立预热（C 条、32 输出），测量波为 C 条。流式客户端按每个请求的 (E2E − TTFT) / (实际输出 tokens − 1) 计算 ms/token，再对该轮请求取算术平均。
根据用户调整，本次同版本基线取两组、共四个独立服务；各档门槛为 max(1%, 两组内以先测轮为分母的绝对相对差最大值)。第三组启动期停止。该调整仅用于历史初始校准，不适用于续轮。续轮从当前交付版本按当前配置做至少三组 A/A，实际新门槛尚待实测冻结。
每个保留的优化提交记录单一假设、预设受益档位、直接父版本和完整的六档交替配对。正式协议至少三组，阈值附近或方向不稳定时追加。预设档至少一档在多数配对中改善、配对改善率中位数超过该档门槛；各档回退中位数不得超过门槛，父版本已达 25 的档位不得失守。单轮筛选单列。
每个保留提交及最终版本的 GSM8K 固定 300 题必须 至少 292/300。AISBench 原生 Gsm8kEvaluator，zero-shot CoT，thinking/low，贪心，4096 输出上限，并发 32。取原 test 集 1,319 行，按 sorted(random.Random(42).sample(range(1319), 300)) 固定顺序。基线 295/300（98.33%）。
在最终提交独立重测精度与全部六档。六档各自的轮均 TPOT 中位数均 ≤25 ms/token；核对实际长度、零失败、DSpark 提议/接受和 decode FULL 回放。完成对应功能测试并归档签署提交及逐轮数据后，再判定 PASS。

历史四服务封存基线（FlashComm1 关）

全服务并发	第 1 对先 / 后	第 2 对先 / 后	基线中位数（ms/token）	波动门槛
1	94.008 / 93.591	93.897 / 93.828	93.862	1.000%
2	95.546 / 95.362	95.250 / 95.659	95.454	1.000%
4	97.542 / 96.432	97.186 / 97.841	97.364	1.138%
8	100.295 / 99.697	99.917 / 102.442	100.106	2.526%
16	101.543 / 102.474	103.579 / 102.177	102.325	1.353%
32	129.766 / 127.840	128.321 / 131.205	129.043	2.248%

24 个正式波、24 个预热波，各 252 个请求，504 个请求均零缓存命中。每档正式窗口都观测到 FULL 回放。限频日志未覆盖 C4、C8、C16 的全部活跃 DP，此项证据完整性标志保留为 false。

证据索引

下列位置相对实验归档根目录。每轮在本 issue 补充公开汇总、校验值、保留或淘汰原因及可用的提交 SHA。

记录	路径	SHA-256
计时协议与输入 release	`perf25/release.json`、`perf25/plan/`	`cb07c2c6badc9ff45dd97eef37617a0326dd61052caa0bd9a57405a5d8b13519`（release）
固定 300 样本	`aisbench/gsm8k/subset300/selection-manifest.json`、`data/test.jsonl`	`ad6bc9a92ac8716846871d881e1442d97a2546aeafb75bfbfd6d09b90c591e26`（子集）
初始精度	`perf25/validator/initial-accuracy.json`	`cda4bc3afb63c78e85d9ff03e2bf00bbb7ed199ddf293da3eb1e4892966bae65`
基线统计	`perf25/results/baseline-calibration/calibration.json`	`a209ab9144d4ea0140938031620bcf5d5cc8607669b5a9f6f7cbc6b4e9ae76a4`
原始计时归档	`perf25/results/baseline-calibration/raw-evidence.tar.gz`	`cc9b66b76e620019e328ac261fe6eeb9643054dafe6d13997123e4883bbf7b99`
源码、环境与执行回执	`perf25/patch/`、`perf25/preflights/`、`perf25/trials/`	按轮次绑定

下游引用请携带本 issue、正式验收的父/候选提交和对应结果。当前已有十个可检出的优化 checkpoint 和最终叠加版本精度结果；逐提交正式验收仍有缺口，最终六档性能目标尚未完成。

后续轮次新增规则（2026-11-04）

按 owner 最新要求，以下规则适用于后续优化轮次，并补充原有验收流程：

逐轮记录知识命中。 每轮在 plan/knowledge-hits.md 明确 InferRSI、vllm-ascend 各自命中的库/分类、条目标题与路径/URL、revision/哈希、查询或阅读原因、实际阅读状态、采用内容或未采用原因、对应假设/改动/测试结果。未查询、无命中、未采用分别记录；筛选、失败、淘汰、中止及复用旧知识的轮次也须记录。该轮 issue 汇总链接记录。DeepInfer 与 DSV4.1 专属知识及间接访问仍然禁止。
先性能，后精度。 中间候选先通过冻结的正式收益/回退门槛及已达 25 档位不失守条件，再测 GSM8K；最终版本先通过六档各自 ≤25 ms/token，再测最终精度。性能未通过则无需精度测试，记 NOT_RUN 及性能失败原因/run ID/门槛/档位；性能 INCONCLUSIVE 时先补性能判定，暂不自动测精度。未测不能记精度 PASS 或 FAIL。性能通过后精度 ≥292/300 的门槛不变；用户单独明确要求精度时按该次请求执行，已有历史结果不改写。

续轮详细口径快照

本地文件：INFERRSI_DSV41_OPTIMIZATION_PLAN_20261104.md。SHA-256：6e2223bad3c1a9be0e98c62a4dc8340fe5244bd3c98d44dcd1519b3aad481262。

展开：DSV4.1 续轮优化实验罗盘（2026-11-04）

DSV4.1 续轮优化实验罗盘

记录日期：2026-11-04（Asia/Shanghai）。治理记录：InferRSI #329。

本文件整理“开始 DSV41 适配”聊天的续轮优化口径。当前阶段是计划与 issue 刷新；本轮没有启动设备测试、修改模型代码或产生新的性能结果。下述目标和测试门槛沿用原任务，续轮从已交付版本开始。运行前仍须生成并冻结实际 RunSpec、校准结果和 validator；本文不代表这些执行产物已经完成。

1. 目标、起点与结论

目标是在同一台 Ascend 910C、TP4 / DP4 / EP16、DSpark5 和 FULL_DECODE_ONLY 下，将全服务并发 1、2、4、8、16、32 六档各自的 TPOT 降至 ≤25 ms/token，同时保持固定 GSM8K 300 题 ≥292/300，相关功能正确。

项目	当前口径
主指标	每档每轮所有请求 TPOT 的算术平均，再对至少 3 个有效轮均值取中位数
性能完成条件	六档分别 ≤25 ms/token；不能用六档平均值替代
精度完成条件	AISBench 原生 Gsm8kEvaluator 答对数 ≥292/300；相对最初 295/300 最多少 3 题，即最多下降 1 个百分点
续轮起点	`codex/dsv41-0day@77a4dfde962c2c99d2b69b1879e97b3fcc4209ca`
当前精度	已归档 294/300（98.00%），少于初始基线 1 题、下降 0.333 个百分点；精度子项 PASS
当前性能	两轮完整结果，用户要求停止性能后第三轮首档中断；不能当作三轮最终验收或三组父子配对
整体验收	INCONCLUSIVE，目标未完成，issue 保持打开

最新结果来自当前提交测评报告及本任务本地归档。本轮核对了最终核验文件引用的 12 份证据文件 SHA-256，全部一致；未重新调用模型，也未重新运行 AISBench 原生评分器。

全局并发	第 1 轮 TPOT	第 2 轮 TPOT	两轮中位 TPOT	高于 25 的差值	从当前值降到 25 还需降低
1	46.550	46.478	46.514	21.514	46.25%
2	45.734	45.649	45.691	20.691	45.29%
4	47.380	46.882	47.131	22.131	46.96%
8	48.506	49.496	49.001	24.001	48.98%
16	50.817	50.812	50.814	25.814	50.80%
32	63.996	63.849	63.922	38.922	60.89%

TPOT 与差值单位均为 ms/token；最后一列为 100 × (当前 TPOT − 25) / 当前 TPOT，是目标距离，不是已实现收益。正式判定使用未四舍五入的原始值。

2. 资料访问边界

本次最新授权：允许读取 InferRSI 和 vllm-ascend 中除 DeepSeek V4.1 专属知识、DeepInfer 相关知识之外的所有知识；不限于通用知识，其他模型专属知识、案例和优化经验也在允许范围内。

资料类型	处理
InferRSI 和 vllm-ascend 中未涉及两类禁止内容的所有知识	允许，包括通用方法、其他模型专属知识、案例、优化经验、证据规范和 benchmark 设计；按需记录具体条目和版本
通用 Ascend / CANN / torch_npu / ACLGraph / Triton、vLLM 框架知识	允许；内容来源仍须不属于下方禁止范围
本次关联聊天、#329、本任务已产生的实验配置/日志/结果、当前分支源码	允许，作为续轮自身的工作上下文和证据，不等同于读取模型专属知识库
DeepInfer 相关知识、案例、摘录、派生总结或镜像	禁止，即使存放在 InferRSI 通用目录下也不读取
DSV4.1 / DeepSeek V4.1 专属知识、历史知识包、现成解法、派生总结	禁止；不能用别名、共享目录、缓存或别的代理绕过
外部 V4.1 实现	保留原任务边界：仅原先指定的 HF 模型仓库属于允许来源；本轮未访问它或其他外部实现

执行方式：先由路径/元数据选定允许文件，再读取正文；不对全库执行会返回正文片段的搜索，不开启无过滤的语义检索、向量召回、缓存注入或自动知识装载。对来源混杂、无法确认是否含禁止材料的文件跳过。允许条目中的禁止来源链接不继续打开。

研究阶段可以手动读取排除两类禁止内容后的知识文件。若以后需要自动检索，必须先有可验证的来源白名单及排除机制；不能仅凭自然语言提示认为隔离已生效。

2.1 每轮知识命中记录

后续每个优化轮次必须记录命中了 InferRSI 或 vllm-ascend 的哪些知识库及具体条目。 覆盖快速筛选、正式配对、失败、淘汰和中止轮次；在该轮 plan/knowledge-hits.md 中记录检索/阅读，在轮次结束时补全采用情况及结果，并在 #329 的该轮汇总中给出记录路径和摘要。

每份记录绑定轮次 ID、优化假设、父/候选版本。按条目填写下表，不能只写“使用了 InferRSI”或“参考了 vllm-ascend”：

来源与知识库	具体条目	版本身份	命中方式与问题	阅读状态	采用情况	实验关联
InferRSI / vllm-ascend，以及库/分类名称	条目标题、相对路径或 URL、相关章节	commit/revision；未提交内容另记 SHA-256	查询词或人工阅读原因；复用旧轮知识时引用原记录	仅定位元数据 / 返回摘要 / 已读正文 / 复用已读知识	已采用 / 部分采用 / 未采用，并说明采用的建议或不采用原因	对应假设、改动路径、测试 run ID、结果/证据路径

将检索返回、实际阅读和采用分开记录；只看到路径不代表读过内容，读过不代表已采用，命中也不代表产生了性能收益。
InferRSI 与 vllm-ascend 两个来源分别列明状态。没有查询写“未查询”，查询后没有相关条目写“无命中”，有命中但未使用写“未采用”；不能留空或编造条目。只依据源码、profiling 或本任务日志时说明这一点，不将普通代码阅读冒充知识库命中。
采用上一轮读过的知识也需登记，引用原轮次的条目与版本，不要求为填表重复读取。经多个库转引同一内容时保留原始来源及转引关系。
记录机制不扩大访问权限：InferRSI 和 vllm-ascend 的所有知识均遵守第 2 节边界，DeepInfer 和 DSV4.1 专属知识仍禁止读取；不为补记录进行全库检索或打开禁止材料。
计划阶段先记实际查阅项；结束时补充真实采用与证据关联。失败或性能未通过、因此跳过精度的轮次，也必须留下知识命中记录。

3. 版本与环境身份

原始精度基线、续轮性能起点和每次候选的直接父版本必须分别记录。

对象	已核对的记录
原始 vllm-ascend 基线	`d4ac4319acdaf480689c39b6320a998712f80523`
续轮起点 / 最新交付提交	`77a4dfde962c2c99d2b69b1879e97b3fcc4209ca`
最新提交的 tree	`d59177636cf98a18f15e40985919f5eb87d5425f`
最新部署源码清单 SHA-256	`99a5d50c7c55ff95dd2af700a22c85e9c883915ebfbe76f4e13ab29b1fed3ee0`
上游 vLLM	`6e448d0ea9bf3d88d898b65449ca6dc2aec170ac`，历史任务记录为 v0.27.1
原实验 InferRSI pin	`919ed42c0d01dc0aa3b613085b9041d735d2d4db`；续轮记录实际执行版本，不把本地当前 main 当作该版本
最新精度服务环境签名	`da05a8aa0892ac286bc098d6d288d015099eb69e21fce7e4745eb52b7790c32f`
最新服务 argv SHA-256	`e06a0d4a2e33386e92650ea0f8996bd69cf95e5ae6b24325002f72749478a4f6`
硬件	单机 Ascend 910C，8 卡 / 16 die；使用原任务设备分配，续轮前复核拓扑、健康、占用与隔离
权重	原任务已有的 DeepSeek V4.1 Flash W8A8 权重；沿用原索引/分片身份，不更换或重新量化
软件快照	CANN 9.1.0、驱动 25.5.1.1、Python 3.12.13、torch 2.10.0+cpu、torch-npu 2.10.0.post4；这是归档快照，续轮需重新核对实际版本与固件

远端曾在既有插件基座上部署文件覆盖层；必须同时记录远端 Git HEAD、部署 manifest、实际文件哈希和目标 release commit。不能把远端 Git HEAD 冒写成最新提交。环境签名不同须解释差异，不能仅用“同一机器”认定可比。

已有十个带 sign-off 的优化 checkpoint：HC Sinkhorn、分页字段读取、分页索引评分、选中 KV gather、decode FP8 QDQ 优化、块掩码压缩、QDQ 融合、slot buffer 复用、partial RoPE、stock cache scatter。公开提交链可检出；这不证明十个直接父子比较和逐提交精度都已正式通过，现有缺口继续保留。

4. 固定服务配置

项目	续轮固定值
部署方式	单机 PD 混部，TP=4、DP=4、EP=16，开启 expert parallel
投机解码	`method=dspark`、`num_speculative_tokens=5`；核验实际提议/接受行为
图模式	`mode=0`、`cudagraph_mode=FULL_DECODE_ONLY`、capture sizes `[24,48]`
上下文 / KV block	`max_model_len=16384`、`block_size=128`
调度	`max_num_seqs=8`（每 DP）；`max_num_batched_tokens=8192`，最近运行实际调度上限 8160，记录请求值和生效值
DSA CP	`enable_dsa_cp=true`
FlashComm1	`enable_flashcomm1=true` 且服务进程 `VLLM_ASCEND_ENABLE_FLASHCOMM1=1`
Shared expert DP	`enable_shared_expert_dp=true`
fused MC2	`enable_fused_mc2=0`，整数；已撤回的接入不属于续轮配置
MoE 路径	target / draft 沿用 Ascend grouped W8A8 路径，运行日志与 hook 核验
前缀缓存	服务开启；性能请求用唯一 `cache_salt` 强制冷前缀并检查零命中
模板 / parser	既有冻结 chat template；`reasoning-parser=deepseek_v3`，content format `openai`
客户端连接	本机 loopback，服务别名 `dsv41-0day`；正式测量不并行发送其他流量
输入范围	本 campaign 为文本；原服务参数保留 image limit 不构成图片输入或 OCRBench 验收

以下是从已执行 argv 整理的脱敏参数模板。DSV41_MODEL_DIR、DSV41_CHAT_TEMPLATE 由原任务运行环境提供；先由唯一设备负责人完成预检、部署身份核验及服务租约，再启动。模板不代替这些步骤，本文未执行该命令。

VLLM_ASCEND_ENABLE_FLASHCOMM1=1 vllm serve "$DSV41_MODEL_DIR" \
  --served-model-name dsv41-0day --host 127.0.0.1 --port 8000 \
  --tensor-parallel-size 4 --data-parallel-size 4 --enable-expert-parallel \
  --max-model-len 16384 --max-num-seqs 8 --max-num-batched-tokens 8192 \
  --enable-prefix-caching --block-size 128 \
  --chat-template "$DSV41_CHAT_TEMPLATE" --reasoning-parser deepseek_v3 \
  --chat-template-content-format openai --limit-mm-per-prompt '{"image":1}' \
  --enable-prompt-tokens-details \
  --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY","cudagraph_capture_sizes":[24,48]}' \
  --additional-config '{"enable_dsa_cp":true,"enable_flashcomm1":true,"enable_shared_expert_dp":true,"enable_fused_mc2":0}' \
  --speculative-config '{"method":"dspark","num_speculative_tokens":5}'

其他已存在的运行环境、加载路径与算子库也需绑定预检快照；两臂一致。不在此新增生产环境变量，不以关闭 DSpark、FULL 图或更换精度来替代既定优化目标。

5. 性能工作负载与计时

六档是全服务总并发 C=1/2/4/8/16/32，不是每 DP 的并发。每档先 C 条独立预热，再同时发 C 条正式请求；按档位升序执行。
预热为 1024 输入 / 32 输出；正式请求精确 1024 输入 / 1024 输出。预热与正式各有冻结的 32 条请求库，二者不重叠；各档使用对应库的前 C 条。输入来自 GSM8K train 的 question 字段，冻结为 raw token IDs，不使用精度 test 答案。
性能接口为 /v1/completions，stream、include_usage、return_token_ids 开启；echo=false、add_special_tokens=false、ignore_eos=true、temperature=0、top_p=1、seed=0、n=1；正式请求 min_tokens=max_tokens=1024。
发送前 barrier 同步；X-data-parallel-rank = slot % 4。每次 HTTP attempt 使用新的唯一 cache_salt，逐请求检查 usage.prompt_tokens_details.cached_tokens=0。
使用客户端 perf_counter_ns：start 为 HTTP 打开前；first 为首个包含生成 token ID 的完整 SSE frame 到达时刻；end 为读到 HTTP EOF 的时刻，含最终 usage 与 [DONE]。不能将首字节、首个无 token 元数据 frame 当作首 token。

TTFT_i = (first_i − start_i) / 1e6                 # ms
E2E_i  = (end_i − start_i) / 1e6                   # ms
TPOT_i = (end_i − first_i) / 1e6 / (output_i − 1) # ms/token
round_mean(C,r) = sum(TPOT_i for all C requests) / C
version_TPOT(C) = median(round_mean(C,r) for all valid rounds)

投机解码一帧可能携带多个 token，它们共享客户端到达时刻；不能把 SSE 帧数当作输出 token 数。不得以平均 ITL、设备 kernel 时长、吞吐倒数、全部请求混合中位数或最快请求替代上述 TPOT。

全部请求参与该轮均值，不裁剪慢请求或排除尾部 drain。每轮检查请求数、实际 token IDs/长度、错误、缓存、源码/配置身份和原始 SSE 可复算性。失败或长度不符时保留原轮，说明原因后以新 attempt 重跑完整该档；不能只挑成功请求补齐。原 runner HTTP timeout 为 1800 秒，barrier 为 60 秒；续轮冻结实际采用的超时，不在看到结果后修改。

一遍六档共 63 条正式请求、63 条预热；三遍共 189+189 条。三组父/候选正式配对共六个服务、378 条正式+378 条预热；同版本三组校准也是这一数量。额外健康探针单独记录并排除出正式计时。

本协议是固定请求波的服务端到端延迟实验，包含 admission、执行和 drain；不据此宣称持续负载 goodput、真实线上 SLO 或其他输入长度已改善。TTFT、E2E、吞吐、投机接受率、显存峰值和各 DP 完成量作为辅助指标，不更换主目标。

6. 校准、历史参照与正式配对

现有材料有两套历史校准，不能混用或挑选更有利的门槛：

C	早期四服务中位 TPOT	早期门槛	后续六服务中位 TPOT	后续门槛
1	93.862	1.000%	94.009	1.000%
2	95.454	1.000%	95.735	1.000%
4	97.364	1.138%	97.430	1.000%
8	100.106	2.526%	100.476	1.683%
16	102.325	1.353%	103.515	4.349%
32	129.043	2.248%	128.602	1.076%

早期四服务为 FlashComm1 关的历史配置，用户当时仅对该次初始校准允许两组。后续六服务校准见封存报告，校准对象 SHA-256 为 4fd871e7372b77a935b951c0c5e53433a583785a6a721c01473c200edaadf853，含 v3 回放观察器条件。后续六服务的当前配置适用性不能仅凭封存摘要推定；它是最新两轮报告中“原始代码参考”列的来源。两轮当前值与历史参考相减只作描述，不构成新正式配对。

续轮采用以下明确流程，避免继承上述适用性歧义：

从 77a4dfde9 建立新的当前配置基线，在相同资源时段、相同观测条件下做至少三组同版本 A/A 校准；每个角色新启动服务并完成全部六档。旧数据保留，不改写。
每档每组波动 jitter = abs(后测轮均值 − 先测轮均值) / 先测轮均值；续轮门槛 threshold_C = max(1%, max(各组 jitter))。先归档所有原始值和环境/配置/观察器哈希，再冻结具体数值。本文不虚构尚未测出的门槛。
校准时若设备占用、功耗/频率、通信环境或运行配置异常，查明原因并完整留证后重新校准；不能仅为压低门槛删除高波动对。
每个候选比较其直接父提交，预先写明一个优化假设和目标档位。至少三组顺序为父→候选、候选→父、父→候选；两臂同机同权重同配置且无竞争服务。
每档每组 gain = (父轮均 TPOT − 候选轮均 TPOT) / 父轮均 TPOT。至少一个预设目标档在多数配对中改善，且 median(gain) > threshold_C，才通过收益条件。
任一档配对回退中位数超过门槛，或父版本已 ≤25 的档位在候选中失守，则不通过。展示 TPOT 时分别使用两臂轮均值中位数；展示改善率时用逐组 gain 的中位数，二者不能互相替代。
接近门槛或改善方向不稳定时追加完整配对，冻结追加规则并保留所有有效结果；不挑有利轮次。仍无法区分噪声时 INCONCLUSIVE。

新校准只服务于续轮判定，不追认历史 checkpoint。若将来修改 TP/DP、DSpark 数、图模式、权重、上下文或基准工作负载，必须另记实验配置和对照，不能混入本协议。

7. 精度测试

精度比较始终锚定原始 295/300，续轮起点的 294/300 不重新定义允许下降的范围。

项目	冻结口径
数据源 revision	GSM8K `3101c7d5072418e28b9008a6636bde82a006892c`，原 test 1319 行
子集选择	`sorted(random.Random(42).sample(range(1319), 300))`，零基索引，题序固定
AISBench revision	`5a63d936e40dd04addfcffb2401f84cd0e53bb46`
提示	`gsm8k_gen_0_shot_cot_chat_prompt`，zero-shot CoT；复用冻结模板和 wire prompts
推理	`thinking_mode=thinking`、`enable_thinking=true`、`reasoning_effort=low`
采样	temperature=0、top_p=1、seed=0
请求	C32；每题一次；0 次预热；上下文 16384；输出上限 4096
主评分	AISBench 原生 `Gsm8kEvaluator`；不替换提取规则或选择另一评分方式提高分数
辅助核验	final 正文评分、原生与 final 差异、无法提取数、截断数及逐题错因单列
有效性	300 个唯一题目，300 个唯一 attempt/response，对应关系完整，零请求失败
门槛	原生答对数 ≥292/300，包含 292；用整数判定，不用四舍五入后的百分比

冻结资产	SHA-256
原始 test	`3730d312f6e3440559ace48831e51066acaca737f6eabec99bccb9e4b3c39d14`
300 题子集	`ad6bc9a92ac8716846871d881e1442d97a2546aeafb75bfbfd6d09b90c591e26`
selection manifest	`95486fe9084728511d1f45bffce5b602b13ec8dc6710456ee90e4e77c193e302`
子集 release	`ea793e1e1a55d412568b16774ef8651d07d0c5c8835c1df6ebd57b40e3d26f1b`
有序 wire prompt mapping	`e45a5066f46e0f2f1c8633c802a9b5faefd8737b01c62509a483f8eead83139b`
有效 AISBench config	`3e2d219e2f8cad118b87b6be82b159e6f5fd47202a469cdeb9d7c9637d5c9f4e`
初始精度 reference	`cda4bc3afb63c78e85d9ff03e2bf00bbb7ed199ddf293da3eb1e4892966bae65`

4096 截断请求仍按原评分规则计分，不剔除，不单独追加 token 或重试到答对。请求失败、漏题、重复题、来源身份不匹配或部分执行均不能宣称精度 PASS；保留原结果、定位后以新的 run ID 做一致的完整复测。

当前已归档 294/300 中，6 道错题含 5 道正常结束和 1 道 4096 截断；原生与 final 正文答对数均为 294。原始结果已有复算记录与 300 个唯一请求核验，本轮只核对其记录与哈希。后续按“先性能、后精度”执行：每个通过该阶段性能门槛、准备正式保留的新提交，以及通过最终性能门槛的交付提交，都要完成此精度测试。

7.1 性能未通过时跳过精度

后续优化轮次如果性能没有通过该阶段已冻结的门槛，就不需要启动 GSM8K 精度测试。 先完成性能判定，再决定是否进入精度阶段：

阶段	进入精度测试的性能前提	未满足时
中间优化候选	第 6 节的正式直接父子配对通过：预设目标档收益过门槛，六档回退不超门槛，父版本已达 25 的档位不失守	跳过精度，保留性能失败/淘汰记录
快速筛选	快筛有利后仍需完成正式性能配对，才满足上行条件	快筛淘汰则跳过精度；快筛有利本身不构成正式性能 PASS
最终交付	最终 exact commit 的六档有效轮均 TPOT 中位数各自 ≤25 ms/token，满足完整轮数及配置/证据要求	跳过本次最终精度测试，继续记录未达档位与后续优化需求

中间候选的精度前提是该轮收益/回退门槛；六档绝对 25 ms/token 是最终阶段门槛。性能证据不完整、环境不匹配或结果为 INCONCLUSIVE 时，先补齐性能判定，暂不自动启动精度。

跳过时记录精度执行状态 NOT_RUN，原因为“性能门槛未通过”或“性能判定未完成”，附性能 run ID、门槛版本与未通过档位。不能把精度未测记成精度 FAIL 或沿用父版本结果记作候选精度 PASS；性能已确定失败与精度未测分别报告，整体验收不能 PASS。性能通过后精度 ≥292/300 的要求不变。

本规则适用于后续默认优化流程；用户单独明确要求精度测试时按该次请求执行。此前按用户指示完成的 294/300 属于历史事实，原结果与当时执行顺序保留。

GPQA 属于原先 0-day 适配阶段的记录；本次 decode 优化使用 #329 已固定的 GSM8K 契约，不混入旧 GPQA 参考分数或 OCRBench。

8. 实际生效与功能核验

正式测量同时记录服务请求配置和实际生效配置：源码身份、16 个 rank 拓扑、target/draft grouped W8A8、FlashComm1、fused MC2=0、DSpark 提议/接受计数、decode FULL 回放与实际活动桶。按测量窗口保存计数增量或 trace，覆盖该档实际活跃 ranks；不能要求低并发不存在请求的 DP 产生同样活动，也不能以启动时 capture 日志代替运行时 replay。

当前历史精度 ready 后日志覆盖 16 ranks、24/48 两桶；历史性能第二轮 C1/C16 窗口没有新增限频 FULL 标记。保留此区别，不能补写成性能每个窗口都有全 rank 计数。新增观察器先检查开销，两臂及校准使用相同条件；带 profiler 数据用于归因，正式主计时保持既定无 profiler 条件。

按实际改动补回归验证：算子数值与 shape/dtype/stride 边界、分页 KV 与有效/填充行、图 capture/replay 缓冲区与地址稳定性、TP/DP/EP 通信正确性、投机接受/回退路径及相关已有测试。共享组件要覆盖受影响消费者，不能由单模型通过推断其他消费者通过。NPU 变更在实际设备验证；在热路径避免新增 device .item() 或不必要 CPU/NPU 同步。

沿用 vllm-ascend 的插件/已有 patch/算子扩展边界，不增加独立模型副本作为默认实现。新增环境变量须集中定义与记录；本文件没有引入新的运行时环境变量实现。必要的架构评审属于代码交付阶段，本轮只整理计划。

9. 续轮执行顺序与判定

**恢复执行前预检：**核对当前工作树、已部署文件、模型/软件/硬件身份、服务租约、设备健康、无其他请求和知识隔离；重新采集快照，不能把历史 idle 当作当前状态。
**冻结续轮计划：**在 acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32 #329 登记阶段 resume-20261104、当前起点、唯一设备负责人、允许资料、六档、统计公式、质量配置和执行工具哈希。生成 RunSpec 与 validator，搜索前冻结。
**当前起点校准：**按第 6 节完成同配置 A/A，登记新门槛。历史 294/300 作为已验证参考保留；源码、权重、配置或环境实质变化需重新验证对应精度适用性。
**定位瓶颈：**从当前版本 C1/C32 的实机 profiling 入手，必要时补中档；按 host 调度、通信、target/draft、算子和图执行拆分，区分测得耗时和未验证假设。本轮没有新 profiling 结果。
**单假设实验：**明确优化平面、直接父版本、预设目标档、功能回归范围和预期影响。按第 2.1 节记录本轮命中的 InferRSI / vllm-ascend 知识条目及实际采用情况。快速筛选仅作排序；保留失败、无收益和回退记录。
**正式晋级：**先完成六档三组直接父子配对的性能验收；性能未通过则按第 7.1 节跳过精度，通过后再运行完整 GSM8K-300。性能、精度、相关功能和配置核验均通过才标记正式保留。冻结工作源码可先测，提交后核对树与部署字节等价；如内容改变，刷新受影响证据。
**提交：**独立、可回退、Conventional Commits、git commit -s；正文写父 SHA、假设、目标档、六档两臂中位 TPOT/配对改善率/门槛/判定、精度、配置及证据位置。工作性 checkpoint 必须与正式通过区分。
**最终验收：**在最终 exact commit 重新启动服务，先完成六档至少三轮性能测试；六档均通过 ≤25 ms/token 门槛后，再运行完整固定 300 题。性能未通过则记录未达档位并跳过该次精度。核对实际配置、日志与功能并归档；单个版本测试完成不自动补齐历史逐提交缺口。

状态	定义
PASS	指定验收范围的证据完整，冻结门槛全部满足；整体验收包括六档 ≤25、精度、功能、配置和必要逐提交证据
FAIL	有效完整证据表明该验收范围不满足门槛，例如完整精度 <292，或候选发生超过门槛的回退
INCONCLUSIVE	缺冻结/版本身份、部分运行、用户中止、环境不可比、噪声无法判断或必要证据缺失

NOT_RUN、STOPPED、CANCELLED 可作为执行状态，验收 verdict 只用上表三种。当前精度子项 PASS、性能两轮未达数值目标、完整 campaign INCONCLUSIVE 三者同时成立。

10. 执行入口与证据归档

以下路径相对既有实验根目录 dsv41-0day-20261102/。真实用户名、设备地址、私有权重路径与凭证不进入公开 issue；本文件不包含这些值。

用途	已有路径或接口
性能协议与输入	`perf25/protocol.json`、`perf25/release.json`、`perf25/input_ids.json`
计时与复算	`perf25/bench.py`、`perf25/stats.py`
精度 release 与题序	`aisbench/gsm8k/subset300/release.json`、`selection-manifest.json`、`data/test.jsonl`
初始精度	`perf25/validator/initial-accuracy.json`
后续六服务校准摘要	`perf25/formal-v3-arm-review/sealed-summary.json`
最新两轮汇总	`perf25/scratch/current-head-results-001/rounds-02.json`
最新窗口核验	`perf25/scratch/current-head-results-001/log-window-audit.json`
最新综合核验	`perf25/scratch/current-head-results-001/final-assessment.json`
最新精度	`perf25/quality/current-head-quality-001-gsm8k300/{summary,manifest}.json`
原始精度复算记录	`perf25/scratch/current-head-quality-001/raw-rescore-audit.json`
执行/回收	`perf25/results/current-head-quality-001/owner.json`、对应 `perf25/trials/` 和 `perf25/services/`

现有接口示例，均须在已冻结新计划、已取得所属 live service 后使用；占位符不是已存在的新实验 ID：

# 在实验根目录、正确运行环境中，由唯一设备负责人调用
python -B perf25/bench.py \
  --release <frozen-client-release-sha256> \
  --service-id <owned-live-service-id> --campaign <frozen-campaign-id> \
  --pair <pair-index> --role <parent-or-candidate> \
  --levels 1,2,4,8,16,32 --timeout 1800

validation-venv/bin/python -B perf25/resumed1_quality.py \
  --id <new-quality-run-id> --service-id <owned-live-service-id> \
  --source-sha <actual-live-source-manifest-sha256>

bench.py 的既有 frozen plan/环境校验不能通过覆盖旧文件或 relabel 旧 ID 绕过；续轮需生成匹配当前配置的新计划与执行封装，保持原始计时语义。fast_screen.py 独立 CLI 只测 C1/C32 且有旧环境默认值，不能直接充当本次六档正式入口。旧 v3_quality.py 带历史 HC 性能前置条件，不能据此跳过当前提交精度。

新阶段按 InferRSI 规范组织 evidence/dsv41-910c-decode-tpot25/resume-20261104/{plan,results,patch,validator}/，或以已审核、脱敏的清单映射到受控原始归档；本轮尚未创建该新证据树或公开上传历史原始证据。

plan/：RunSpec、来源白名单、逐轮 knowledge-hits.md（按第 2.1 节记录命中条目及版本/采用情况）、数据/提示/工具哈希、假设/目标档、校准、执行顺序、追加与失败规则。
results/：每轮所有请求和 SSE、usage、逐 DP 指标、日志窗口、原生精度输出或跳过原因与对应性能判定、复算、rc/停止状态、资源回收与 verdict；轮次总结链接知识命中记录及其对应实验结果。
patch/：父/候选 SHA、源码与部署清单、完整改动、已安装库身份。
validator/：冻结计时/评分/完整性检查程序及哈希；不得看完候选结果后改规则。

新结果记录原始路径、SHA-256 与可访问性。仅有哈希而无可访问原始文件不代表第三方已独立复核；隐私原件保留在受控位置，公开提供脱敏副本及明确的验证范围。微基准或 profiling 不能升级为服务性能 PASS。

11. 本轮完成项与下一步

读取用户引用聊天，定位 acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32 #329 与本任务最新证据。
核对当前交付提交、两轮性能、固定 300 题精度与 12 份证据文件哈希。
写明允许 InferRSI 和 vllm-ascend 中除 DeepInfer/DeepSeek V4.1 专属知识之外的所有知识，禁止间接访问被排除内容。
整理目标、配置、数据、统计公式、校准/配对、精度、运行入口与证据边界。
增加逐轮 InferRSI / vllm-ascend 知识命中记录，以及性能未通过时跳过精度的规则。
续轮执行前生成并冻结当前配置的 RunSpec、校准与 validator。
在当前版本开展新 profiling、候选实现和正式测量。
完成逐提交证据与最终六档 ≤25 ms/token 验收。

本轮不会将原来停止的第三轮追认为已完成。后续优化继续以 #329 为治理记录；本文件与 issue 新增续轮说明共同记录本次准备结果，历史实验事实和原始证据不改写。

候选进度 · 2026-11-03

第一轮 · Model · 融合 HC Sinkhorn 归一化

父提交 d4ac4319acdaf480689c39b6320a998712f80523。工作树源码清单 SHA-256 ee625c96e840768bf793f0c8b1ae420006898ba82d0a444175e80e167062928a。目标档为 C1、C32。只融合固定 4×4 FP32 comb 的行 softmax 和 39 次归一化，保留投影与 pre/post gates。

DP0/TP0 的四次活跃 target 图重放共观察到 320 条连续 HC 链，每条 119 个设备任务。链首尾跨度平均为 28.74 ms/验证步。首次诊断在 HTTP 请求完成后漏传收尾参数，原回执保留 INCOMPLETE；上述归因来自绑定 rank 和 PID 的原始 CANN 副本。恢复汇总 perf25/results/recovered-profile-baseline-c01-001/recovery-summary.json，SHA-256 153e7ff219aaa641abd8c6a7e4abe850e452d84ac2121db7943baa304d92567b。

全局并发	初始四轮中位数	候选单轮筛选（ms/token）	相对该基线中位数
1	93.862	87.743	6.52% 改善
32	129.043	119.636	7.29% 改善

两个筛选波均满足实际 1,024 入、1,024 出，记录到 DSpark 和 FULL 回放。原始波在 perf25/results/hc-comb-screen-001/。控制器第一次释放服务时拒绝了服务类型，随后独立核验并回收，见该目录的 handoff.json。
GSM8K 固定子集 294/300（98.00%），初始 295/300（98.33%），少 1 题，精度门槛通过。300 次请求均成功，1 次触及输出上限且答错。评分文件 perf25/quality/hc-comb-fixed300-001/summary.json，SHA-256 5dc0c377e87cc069743246f5dda334ded15afb58ad9e636fb9e8284b946bbb65。19 项 UT、9 项真实 NPU ST 通过。
为优先进入下一轮，长配对在首个父服务完成六档后中止，完整父/候选配对为 0。这一轮的正式性能结论为 INCONCLUSIVE。保留为下一轮的探索性对照，尚无正式保留提交。中断审计 perf25/results/hc-comb-paired-001/interrupted-audit.json，SHA-256 d37534bf00490a335f882da9dfef470d5a1c07777f9720204bff2ac8487caa37。

第二轮 · Model · 按字段 stride 读取分页 KV

以第一轮候选为对照，HC 字节保持一致。第二轮源码清单 SHA-256 4f48956bfd73bbcdeed611c2294d73db1fb0d61dcbd99a210b8779d61e86680c。目标档为 C1、C32。此前 C1 单 rank 的四个验证步中，读侧 188 次整列 512 宽 Slice 合计 89.66 ms。候选直接根据槽位、有效掩码和物理 stride 读取需要的列，避免先复制整列。归因见 perf25/scratch/attention_decode/C1-CANN-page-audit.md。

第 1 次算子探针在掩码类型编译检查失败。第 2 次发现 BF16 全位型与原路径的 where 行为有差异。修正后，第 3 次 A3 探针通过了图输入更新重放及全部 65,536 种 BF16 编码的检查。下表仅为独立设备算子结果。

输入形状与类型	原读法（ms/次）	直接按 stride 读（ms/次）
48 × 512 FP32	0.6882	0.0171
3,840 × 512 FP32	0.7390	0.0513
3,840 × 512 BF16	0.4365	0.0814
49,152 × 128 BF16	1.7507	1.4489

对应 InferRSI trial 为 paged-read-probe-003。第二轮整模 TPOT、固定 300 题与正式提交仍待验证。当前整轮结论 INCONCLUSIVE。

P2｜切换通信/融合配置后，波动门槛的适用范围需要明确。

本 Issue 的六档基线波动门槛（1.000%–2.526%）来自 FlashComm1 关闭的初始两组/四服务校准；下一阶段则要求显式开启 FlashComm1 和 fused MC2。正文已经正确要求 target / draft 在同配置下比较，避免把跨配置性能差归因于 KV 优化。但若正式保留判据仍使用旧配置得出的“该档门槛”，通信路径改变后各并发档的运行波动可能不同，导致候选被错误保留或淘汰。

建议在验收契约中区分历史配置的校准表与新配置的正式配对门槛：注明旧表是否仅适用于原配置；新阶段如需据波动决定保留，应按冻结的相同校准公式获得同配置门槛，并将配置签名、档位、基线批次及阈值版本绑定至配对证据。若决定跨配置沿用旧阈值，请明确由 owner 记录适用性依据/敏感性边界。这不改变独立的最终目标“六档 TPOT 均 ≤25 ms/token”。

依据：#329 的“当前开关要求”“已封存基线”“验收条件”及候选进度。第一轮正式父/候选完整配对仍为 0，第二轮仅有算子探针；现阶段继续 INCONCLUSIVE。此为设计评审建议，不是执行实验或改变门禁的授权。

第二轮短对照完成 · 显式 FlashComm1 开，fused MC2 关

两臂均实测 VLLM_ASCEND_ENABLE_FLASHCOMM1=1、enable_flashcomm1=true、enable_fused_mc2=0（整数）、DSA CP 与 shared expert DP 开。四个 DP 均确认 target / DSpark 的 grouped MoE、真实投机与 FULL 回放。环境签名 a3d9fcf09617501b80f8b6fbeb1107178cb70822ac5ca27b522f4bd2012a9f57。

V4.1 fused MC2 实验代码已按要求回退，14 个跟踪文件恢复，3 个实验新增文件移除。节点未部署该原生库。1134 个宿主二进制、OPP 文件与链接逐项对照构建前清单无变化。分页 KV 读取候选只加速字段列步长为 1 的布局；非单位列步长保留原读取路径。修正版本通过 116 项功能测试、另有 2 项预期平台跳过。

全服务并发	A · HC	B · HC + 按 stride 读取 KV	B 相对 A 的 TPOT 降幅
1	87.79 ms/token	80.04 ms/token	8.83%
32	122.04 ms/token	110.89 ms/token	9.13%

每臂使用独立服务，实测次序 B → A。每档一次预热后测一轮，每条请求实际 1024 入、1024 出，缓存命中为零。C1 两臂逐 token 输出相同，投机接受计数同为 717/1540。C32 有 2/32 条逐 token 完全相同，投机接受比例 A 为 46.71%、B 为 47.63%；此前同版本重复的 C32 也仅有 5/32 和 2/32 条完全相同。此次 C32 差值包含生成轨迹与投机接受差异。

B 的冻结 GSM8K 子集由 AISBench 评得 294/300（98.00%），比初始基线少 1 题，达到 292 题门槛。300 次请求全部成功，两题达到 4096 输出上限并答错。按本次安排，A 仅测性能。两次服务已释放，节点已恢复 B 的工作源码。

A 源码清单 ee625c96e840768bf793f0c8b1ae420006898ba82d0a444175e80e167062928a，B 源码清单 4a06cea113696b87244db790a57c23349e9065a89dad1300d45ad80cce50ba82。两者仅有三个 KV 读取相关文件差异，含测试。
单轮对照 perf25/results/fc1-off-short-comparison-001/comparison.json，SHA-256 b692263ed97e3286050cb79113d44fe50a429154a28f7037a90fefcc8ed01abf。A/B 逐请求流记录分别位于 perf25/results/hc-control-fc1off-timing-001/ 与 perf25/results/hc-paged-fc1off-screen-001/。
精度 perf25/quality/hc-paged-fc1off-quality-001/summary.json，SHA-256 e1cb792640a9022c53e41c08d331448a74f9ff4d50de8b6f01a8ac87e1646b9e。

当前正式验收 INCONCLUSIVE。本次为两个目标档各一轮的筛选，C1、C32 距 25 ms/token 分别仍差 55.04、85.89 ms/token。

更正前述评审的配置事实（不重复提出新门禁）。

我在上一条 P2 意见中写到下一阶段同时开启 FlashComm1 和 fused MC2；这已不符合本 Issue 的最新方案。当前明确为 FlashComm1 开、fused MC2 关（enable_fused_mc2=0），fused MC2 接入已撤回。此前关于 fused MC2 开启的表述作废。

剩余的窄范围问题仍是跨配置校准口径：封存的 1.000%–2.526% 波动门槛来自 FlashComm1 关的初始样本，而新增短对照已在 FlashComm1 开、fused MC2 关下测量。短对照每档只有一次 B→A 筛选，不能据此证明旧阈值适用于新配置，也不构成正式配对或整项验收。建议原验收负责人仅明确旧门槛在当前配置下的适用性或另行记录依据；最终六档 TPOT ≤25 ms/token 目标及当前 INCONCLUSIVE 不变。这是对历史意见的事实修正和未决边界说明，不授权实验或改变验收标准。

第三轮筛选 · 以每块一个布尔值表示 decode 索引候选

候选 C 的工作源码清单为 f5f49cbab260ab8b1794cfa5253bab2f6a3455e69217af73eccee6461e229cb1，对照 B 为 4a06cea113696b87244db790a57c23349e9065a89dad1300d45ad80cce50ba82。唯一运行时变化是在后续层直接广播块掩码，去掉 repeat_interleave 生成的逐 token 掩码。两者的真实服务配置为显式 FlashComm1 开、enable_fused_mc2=0、TP4/DP4/EP16、DSpark5、FULL_DECODE_ONLY。目标档在测试前指定为 C1、C32。

并发	B（ms/token）	C（ms/token）	单轮降幅	C 距目标
1	80.04	75.24	6.00%	50.24 ms/token
32	110.89	102.89	7.22%	77.89 ms/token

每档各一轮，1024 入、1024 出。C1 两臂输出逐 token 相同，C32 逐 token 相同的为 8/32 条。固定 GSM8K 子集 C 答对 294/300（98.00%），与 B 的正确数相同，初始基线为 295/300；C 的 300 题均成功，1 题达到 4096 输出上限。35 项 CPU 回归及 3 项真实 NPU 图回归通过。当前保留为探索候选，正式六档配对和签署提交均未完成；测量后节点已恢复 B。

候选对 B 的完整差异包含产品实现和测试，归档于 perf25/results/block-mask-c-qualification-001/C-on-B-with-tests.patch。独立设备算子结果 perf25/results/block-mask-a3-001/result.json，SHA-256 c821c4514dc4e4e015ebc97510f5c89b4d3f7d0e40d0b5688a7e709d491caed5。
C 的整模筛选 perf25/results/block-mask-fc1off-001/screen.json，SHA-256 b6c900bef86dbca96357e0f04af002880f2eb4013e4bd1f354d46e5c2f36dabf。精度 perf25/quality/block-mask-fc1off-quality-001/summary.json，SHA-256 6b9f51a53309806b6dc11530e62a19f25f8cb5adaee675f38e6ea8cc464623e7。

另行检查的 WO 输入 FP8 QDQ 单核原型 wo-fp8-qdq-a3-001 通过 BF16 位级与图重放校验，但 24 行形状的独立设备耗时比原实现增加 10.57%，48 行增加 91.48%。该实现未进入整模。整体验收仍为 INCONCLUSIVE。

本 Issue 跟踪 DeepSeek V4.1 Flash 在 910C 上 decode TPOT ≤25 ms/token 的验收；第三轮更新新增块掩码广播候选 C 的 C1/C32 单轮筛选，并自认仍为 INCONCLUSIVE。复核结论：needs information / 需 owner 决策——我重算了基线表中位数与各档门槛百分比，数值自洽无误，但候选仍只以工作树源码清单 SHA-256 标识、仓库内没有 evidence/dsv41-910c-decode-tpot25 归档与清单条目、第三轮父臂数值与第二轮完全相同、旧阈值与当前 FlashComm1 开配置的绑定仍无人负责，PASS 前提均不成立；前一条评审意见中的窄范围问题（跨配置波动门槛适用性）仍未得到回答。本 Issue 没有请求代码变更的句子，因此不构成开发授权；现有 kind:acceptance、area:workbench 已覆盖分类，无需新增标签（priority 依仓库规则须配合 status:* 标签）。

F1 — 验收绑定：候选只有工作树清单 SHA-256，没有可检出的 git 提交，且顺序自相矛盾

Where: Issue 正文「初始修订与基线运行配置」中「候选 Git SHA | 待正式验收后提交」一行；验收条件第 4 条（「在最终提交独立重测精度与全部六档」）；仓库契约 AGENTS.md:87（PASS 需要 pinned baseline and candidate revisions）、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35（candidate_sha 必填的「Full git SHA」）。
Problem: 三轮候选分别以源码清单 ee625c96…、4a06cea1…、f5f49cba… 标识，每次测量后节点都恢复为 B；这些都是工作树文件清单摘要，不是任何人能 checkout 或下游能引用的修订。同时正文把正式候选 SHA 排到「正式验收后」，形成循环：第 4 条要求在最终提交上重测，但该提交在验收前不存在。
Impact: 即便六档均 ≤25 ms/token，也缺少可复现的 pinned comparison，无法判 PASS；工作树重建若有未跟踪文件或测试文件差异，最终六档结果将不可复核。
Fix: 每个保留候选及最终候选先在该 vllm-ascend 分支上形成提交并记录完整 SHA（源码清单 SHA-256 作为交叉校验保留），再在该确切提交上执行最终六档与精度复测。

F2 — 证据树不在仓库契约位置，且无 inventory 条目

Where: Issue「证据索引」（所有路径声明为「相对实验归档根目录」，形如 perf25/results/...）；AGENTS.md:89；docs/contributing.md:116-122 与 :126；tools/evidence_inventory.json；evidence/ 目录。
Problem: 我实际运行 python tools/validate_evidence.py：errors=[]、21 个 bundle、无 dsv41 条目，evidence/ 下也没有本 campaign 目录。也就是说 Issue 中列出的全部 SHA-256 都无法由仓库自身校验，也没有 plan/、results/、patch/、validator/ 归档。仓库已有可照抄的先例（qwen21-turbo-b300-20261010 为 archive kind、drama3-b300-scale150、qwen3-tts-ascend-import 均以 external 声明保留外部/私有原件）。此外基线声明「限频日志未覆盖 C4、C8、C16 的全部活跃 DP，证据完整性标志保留为 false」，该未决标志目前也没有承载位置。
Impact: 即使性能与精度门槛达标，缺少 evidence/<campaign-id>/ 与清单条目即无法判 PASS，下游引用会指向不可校验的路径；基线控制条件的已知缺口也没有被归档为可追踪状态。
Fix: 建立 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator}（plan/ 放冻结 RunSpec 与门槛、patch/ 放每轮 C-on-B 差异指针、results/ 放各轮汇总与逐轮数据摘要），在 tools/evidence_inventory.json 登记（外部原件用 external 声明），并把基线完整性标志与其原因写入 bundle。

F3 — 第三轮证据既非配对测量、也未与新配置绑定；旧波动门槛的适用性仍无人负责

Where: 触发评论表格（B 的 80.04 / 110.89 ms/token 与第二轮 B 臂的 80.04 / 110.89 在公布精度上完全相同）；Issue「已封存基线」门槛 1.000%–2.526% 系 FlashComm1 关配置得出，而第二、三轮为 FlashComm1 开、enable_fused_mc2=0（新环境签名 a3d9fcf0… vs 冻结 44411269…）；Issue「初始修订与基线运行配置」表仍写「显式 FlashComm1 关」；第二轮评论给出的 C32 同版本重复输出一致性仅 5/32、2/32。
Problem: (a) 未说明 B 是否与 C 在同一次会话内重测。若父臂数值是沿用第二轮的，则 6.00% / 7.22% 的降幅混杂了跨会话漂移，C1 档 1.000% 的门槛根本无法套用，也无法排除「先把两臂作差再读」的误读。(b) 同一 Issue 中「冻结值」表仍声明 FlashComm1 关，与「当前开关要求」和实测配置冲突，两个读者可把同一门槛绑到不同配置。(c) 上一轮评审提出的窄范围问题（旧校准门槛是否适用于 FlashComm1 开的新配置，或需重新校准）在本条更新中未被回答，也无责任人。
Impact: 候选的保留/淘汰可能被归因到错误的配置；该轮只能停留在探索性筛选，无法升级为正式配对证据。
Fix: 在报告中明确 B 为本轮重测还是引用，并给出同会话配对；维护一张「当前」RunSpec 表（含每轮环境/配置签名），历史配置标注为历史；由验收 owner（Dong1017）记录旧 1.000%–2.526% 门槛在新配置下的适用性依据或重新校准结论。

F4 — 缺少 kind:acceptance Issue 必需的三行状态块

Where: Issue 正文（以「## Campaign」开头，无状态块）；仓库约定 docs/agent-collaboration.md:211-218。
Problem: kind:task、kind:acceptance、kind:tracking、kind:rfc 的开放 Issue 必须以 **Current state:** / **Decision needed:** …, from <决策人> / none / **Next action:** 三行开头并由执行方保持更新。本 Issue 缺失，正因如此，跨配置门槛这个待决问题没有登记为「Decision needed」及其 owner。
Impact: 待决问题散落在评论中，读者与后续评审难以区分「已定」与「未定」，也不便据此判断是否具备推进条件。
Fix: 在正文顶部补三行状态块：当前状态为第三轮单轮筛选、INCONCLUSIVE；Decision needed 写跨配置波动门槛适用性，owner Dong1017；Next action 写候选提交 pin 与配对测量。

F5 — 块掩码广播改动在性能工作负载下未覆盖非整块边界（建议补充等价性检查）

Where: 触发评论（「唯一运行时变化是在后续层直接广播块掩码，去掉 repeat_interleave 生成的逐 token 掩码」）；Issue 冻结配置「block 128」；测量协议「每个性能请求精确 1,024 入、1,024 出」。
Problem: 1,024 / 128 = 8 个完整块，性能工作负载从不出现尾部不完整块，也不含前缀缓存复用；第三轮给出的等价性证据是 C1 逐 token 输出相同、GSM8K 294/300 与 35 项 CPU + 3 项 NPU 图回归。第二轮为该类改动设立过更强的先例（65,536 种 BF16 枚举、图输入更新重放）。若按块广播与按 token 掩码在部分块或 KV 复用场景下语义不同，聚合精度只能弱暴露。
Impact: 潜在的部分块/缓存路径行为差异不会出现在 C1/C32 的 TPOT 数字中，可能被带入后续正式配对。
Fix: 补一项针对非 128 整数倍提示长度、以及带前缀缓存命中场景的逐 token 输出对照（对 B 臂），与第三轮证据一并归档；该检查不影响当前 INCONCLUSIVE 结论。

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

本次更新是评审者对自身先前 P2 意见的事实更正：当前冻结配置为显式 FlashComm1 开、enable_fused_mc2=0，与正文「当前开关要求」一致，正文从未要求开启 fused MC2，故「同时开启两者」的旧表述作废后不影响任何门禁。更正后剩下的窄问题——封存的 1.000%–2.526% 波动门槛（FlashComm1 关时测得）是否适用于 FlashComm1 开下的正式配对——截至最新一轮（第三轮块掩码筛选）仍未由 owner 明确，且目前还没有任何一轮真正用它做过保留/淘汰判定，现在正是固化口径的窗口。本 Issue 是验收跟踪，正文没有任何一句要求修改代码；结论维持 INCONCLUSIVE（完整父/候选配对 0 组、候选无 git SHA、验收证据不在本仓库）。未提标签建议：kind:acceptance 与 area:workbench 已由人设置，priority:* 依 .github/labels.json 需配合 status:proposed/accepted，而本 Issue 没有 status 标签。

F1 — 跨配置的波动门槛适用口径仍未决（需 owner 决策）

位置： 正文「初始修订与基线运行配置」（Ascend 开关：显式 FlashComm1 关）、「已封存基线」表（1.000%–2.526%）、「验收条件」第 2–3 条；对应触发评论。
事实核对： 更正后的配置与「当前开关要求」完全一致，且正文要求「比较 KV 读取优化时两个版本使用同一配置」——只约束同配置对比，没有说门槛归属哪套配置，所以 Issue 内部不存在与更正冲突的要求，无需改动门禁。
问题： 封存门槛来自 FlashComm1 关的四台服务，而第一至第三轮（HC 融合、按 stride 读 KV、块掩码）全部在 FlashComm1 开下测量。验收条件第 3 条只写「该档门槛」，两种读法（跨配置沿用 / 按配置重算）会给出不同的保留或淘汰结论。
仓库约束： docs/contributing.md:137-138 要求按 repo/revision/backend/device/model/scenario 组合分别标注；AGENTS.md:64 与 docs/contributing.md:100-101 要求数值门禁在候选搜索前冻结。因此现在用 FC1-on 数据反过来推导门槛属事后调整，必须显式记录而不是悄悄替换。
需要记录其一： (a) 声明封存门槛对当前配置继续有效（保守，仍为冻结值）；或 (b) 按第 2 条同一公式在 FC1-on/fused-MC2-off 下另做校准，先发布门槛再继续候选比较，并把第一至第三轮标为探索性；两者都应把配置签名与阈值版本写入每轮证据绑定。若选 (a)，请一并记下该门槛自身来自「两组共四台服务、第三组启动期停止」的初始校准，且 C4/C8/C16 限频日志缺口使完整性标志为 false。

F2 — 候选只有工作树清单 SHA-256，没有可引用的提交，「直接父版本」要求无法满足

位置： 正文表格「候选 Git SHA」行；「验收条件」第 3 条；证据索引 perf25/patch/。
问题： AGENTS.md:87 要求 PASS 具备 pin 的 baseline/candidate revision，campaign 表单把 full git SHA 设为必填（.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32），evidence patch/ 段要求候选 diff 或精确 revision 指针（evidence/README.md:9）。目前候选只以工作树源码清单 SHA-256 标记（如 4a06cea1…、f5f49cba…）：该摘要无法从任何 git 提交重算，也表达不出第 3 条要求的「直接父版本」。
影响： 第一至第三轮的单轮筛选既不可复算也不可引用；正文要求下游引用「正式验收的父/候选提交」，届时没有可引用的对象。
建议： 最迟在第一次「保留提交」判定前把候选落成 vllm-ascend 上的提交（或归档带父 SHA 的 patch），并在每轮记录父提交与变化范围；清单摘要保留为附加校验即可。

F3 — 验收证据留在本仓库之外，未进入 evidence 树与清单

位置： 证据索引表（perf25/release.json、perf25/results/…，明确「相对实验归档根目录」）。
核实： 本检出没有 perf25/；evidence/ 下没有 dsv41-910c-decode-tpot25；tools/evidence_inventory.json 的 21 个 bundle 中也没有该 campaign。tools/validate_evidence.py:124-127 拒绝未知 bundle kind，:147 报未分类 manifest，因此即便日后导入也必须先登记分类。
影响： docs/contributing.md:112-118 与 AGENTS.md:87-89 要求 PASS 具备 evidence/<campaign-id>/ 下完整证据树；若字节始终在仓库外，「六档 ≤25 ms/token」与「292/300」都无法被本仓库任何检查复核，只能作为外部归档声明，正文又要求下游引用这些结果。
需要决定： 在判定 PASS 前把归档导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并登记清单，或明确按外部归档登记（保留已记录摘要）并在正文声明该范围；两种做法都应在 PASS 之前写进 Issue。

F4 — 计分工具版本未 pin，精度门禁不可复现

位置： 「验收条件」第 4 条与证据索引（aisbench/gsm8k/subset300/…、perf25/quality/…）。
问题： 292/300 的协议冻结得很细（原生 Gsm8kEvaluator、zero-shot CoT、thinking/low、贪心、4096 上限、并发 32、seed 42 的 300 题），但 AISBench 自身的 revision 与 Gsm8kEvaluator 代码身份没有 pin；环境表只列 CANN/驱动/Python/torch/torch-npu，没有计分工具版本。
影响： 不同 AISBench 版本在 CoT 截断、答案抽取或 4096 上限处理上可能给出不同分数；一旦结果贴近 292/300，就无法区分差异来自候选代码还是计分实现。本轮 HC/B/C 都是 294/300，离门槛只有 2 题余量。
建议： 在精度证据中记录 AISBench revision 与抽取/判分代码摘要，这不是新门禁，只是补齐已冻结协议的工具身份。关联核对：[RFC] Integrate AISBench as an optional benchmark tool #289（RFC，open）与 Add an optional AISBench service benchmark adapter #326（open draft，AISBench 适配器尚未合并）；本 Issue 走原生 evaluator，故不依赖该适配器，但 Add an optional AISBench service benchmark adapter #326 引用的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 可作为候选 pin。

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

六档单轮结果与 C32 设备归因

候选 C 为 f5f49cbab260ab8b1794cfa5253bab2f6a3455e69217af73eccee6461e229cb1（工作源码清单），enable_flashcomm1=true、enable_fused_mc2=0。在独立新服务上按档位递增各预热一次，再发送 C 个同时在途的 1024 入、1024 出请求。

全局并发	实测平均 TPOT（ms/token）	高于 25 ms/token
1	75.326	50.326
2	73.909	48.909
4	75.766	50.766
8	78.635	53.635
16	82.294	57.294
32	102.116	77.116

正式 63 个请求共生成 64,512 个 token，另有 63 个预热请求。126 个请求均零缓存命中。测量期 DSpark 接受 45,488/95,485 个提议 token（47.64%）。启动时四个 DP 均观测到 FULL48；测量窗口内 C4、C8、C16 的限频日志仅覆盖部分活跃 DP。固定 GSM8K 子集沿用该候选已完成的 294/300（98.00%）。

正式验收为 INCONCLUSIVE。六档是独立复算的单轮筛选，均未达到 25 ms/token；尚无通过约定逐提交配对验收的优化 commit。原始波与日志为 perf25/results/block-mask-six-fc1off-001/raw-evidence.tar.gz，SHA-256 1a9c8d8f44a2039136fad9bdf7df6eafff7f62cdaa3adb991e5763603fbb95f0。独立复算 independent-screen.json，SHA-256 f25ba454b7f982313eb24b828b4a95d9adecbd94e8a7de581eabd9e31bb4d51e。

另起专用 C32 服务采集设备时间线。首次采样因客户端 SSE 转发错误，在启动 profiler 前结束，原回执保留。修复后在 block-mask-profile-c32-fc1off-002 收到 32 个完整响应、16 个 rank 的 FULL48 回放记录，DP0/TP0 以 rank 和 PID 绑定到 CANN 原始轨迹。正式计时均来自普通服务。

4 次 target FULL 回放的当前流事件中位数 293.12 ms/次，草稿提议 65.54 ms/次。后者包含草稿模型时间；这些数值包含依赖等待。
单 rank 主流的目标图窗口平均 296.60 ms，其中 AI 计算 244.14 ms，主流等待 34.90 ms。集合通信与主流等待的交集为 34.54 ms。
该 rank 每次目标遍历约 20,310 个可见算子记录。类型合计中，Cast 19.66 ms、Mul 16.75 ms、SelectV2 12.95 ms。写入 KV 子字段产生的大底表 Slice 和 ViewCopy 分别为 7.85 与 7.32 ms。这里记录的是单 rank、C32 的归因，不能相加当作新优化可节省的端到端 TPOT。诊断后已恢复 B 并释放设备。
WO 输入量化融合的追加 tiling 初筛也未过门槛，24 个有效配对均慢于原实现，保留原路径。perf25/results/wo-fp8-qdq-a3-002/result.json 的 SHA-256 为 57d391c833ee072a9130f91fedaccf3f0cc3bfa3c2588192d1e615019fa93d9b。

本 Issue 跟踪 DeepSeek V4.1 Flash 在 910C 上 decode TPOT ≤25 ms/token 的验收；最新评论新增候选 C 的六档单轮筛选（75.3–102.1 ms/token）、C32 设备时间线归因和 WO tiling 淘汰结果，并自述仍为 INCONCLUSIVE。我复算了「已封存基线」六档的中位数与门槛百分比（C1 93.862/1.000% … C32 129.043/2.248%），数值自洽；本轮 C1/C32 与第三轮同候选重复相差 0.11%/0.75%，无内部矛盾，但四项结构性前提自上轮评审以来未变，另新增两条证据对齐问题。结论：needs information / 需 owner 决策，本轮不构成开发授权（正文无请求代码变更的句子），也未发现引导自动评审的文本。上轮 F1（跨配置波动门槛口径）、F2（候选无 git 提交）、F3（证据不在仓库/未登记清单）、F4（AISBench 计分工具未 pin）全部仍 open，本轮更新未回应；更早一轮的「缺三行状态块」仍未补。未新增标签：kind:acceptance 与 area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status:proposed/accepted，而本 Issue 无 status 标签。

F1 — 跨配置波动门槛的适用性仍未决（需 owner 决策；与上轮 F1 相同）

位置： 正文「初始修订与基线运行配置」表（Ascend 开关 | DSA CP 开、显式 FlashComm1 关）、「已封存基线」表（1.000%–2.526%）、「验收条件」第 2–3 条；触发评论的六档表（enable_flashcomm1=true、enable_fused_mc2=0）。
事实： 六档门槛来自 FlashComm1 关的四台服务校准，而第一至第四轮全部在 FlashComm1 开下测量；验收条件第 3 条只写「该档门槛」，两种读法（跨配置沿用 / 按配置重算）会给出不同的保留或淘汰结论。
新增数据： 本轮 C1 75.326 / C32 102.116 与第三轮 75.24 / 102.89 是同一候选的跨会话重复（偏差 0.11% / 0.75%，均落在旧门槛 1.000% / 2.248% 内）。这是首个同配置重复点，但只覆盖两档、两次会话，不能替代按第 2 条同一公式在新配置下重新校准。
仓库约束： docs/contributing.md:98-101 要求数值门禁随 RunSpec 在候选搜索前冻结；:137-138 要求按 repo/revision/backend/device/model/scenario 分别标注。用 FC1-on 数据反推旧门槛属事后调整。
需要记录其一： (a) 声明封存门槛对当前配置继续有效，并注明它来自「两组共四台服务、第三组启动期停止」且 C4/C8/C16 限频日志缺口使完整性标志为 false；或 (b) 按第 2 条同一公式在 FC1-on/fused-MC2-off 下先发布新门槛再继续候选比较，并把第一至第四轮标为探索性。两者都应把配置签名与阈值版本写入每轮证据绑定。
需人工决策： 是。责任方应为 repo approval owner（.github/knowledge-model-policy.json 记为 Dong1017）或指派的验收负责人；Issue 正文与状态块均未登记该 owner（见 F6）。

F2 — 候选仍只有工作树清单 SHA-256，没有可检出的提交（上轮 F2 未决）

位置： 正文表「候选 Git SHA | 待正式验收后提交」；「验收条件」第 3 条（每个保留提交须记录「直接父版本」）与第 4 条（「在最终提交独立重测」）；AGENTS.md:87；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35（candidate_sha 必填「Full git SHA」）。
问题： 四轮候选分别以 ee625c96…、4a06cea1…、f5f49cba… 工作树清单摘要标识，每次测量后节点恢复为 B。该摘要无法从任何 git 提交重算，也表达不出「直接父版本」；同时正文把正式候选 SHA 排到验收之后，形成循环：第 4 条要求在最终提交上重测，而该提交在验收前不存在。
影响： 即使六档全部 ≤25 ms/token，也缺少可复现的 pinned comparison，无法判 PASS；工作树重建若含未跟踪文件或测试文件差异，结果不可复核，下游也无「父/候选提交」可引用。
修复： 在每个保留判定前把候选落成 vllm-ascend codex/dsv41-0day 上的提交并记录完整 SHA 与父 SHA（perf25/patch/ 中的源码清单摘要保留为交叉校验）。

F3 — 验收证据仍在本仓库之外，也未进入 evidence 树与清单（上轮 F3 未决）

位置： 正文「证据索引」（perf25/release.json、perf25/results/…，明确「相对实验归档根目录」）；AGENTS.md:89；docs/contributing.md:118-122（evidence/<campaign-id>/{plan,results,patch,validator}）；tools/evidence_inventory.json。
本次实际核实： 运行 python tools/validate_evidence.py → errors: []、21 个 bundle，无 dsv41/perf25 条目；本检出没有 perf25/ 目录；evidence/ 下没有 dsv41-910c-decode-tpot25。仓库已有外部件先例：qwen3-tts-ascend-import（kind import）、qwen21-turbo-b300-20261010（kind archive）。
影响： Issue 列出的全部 SHA-256 无法由仓库自身校验，PASS 只能停留在外部归档声明，而下文又要求下游引用这些结果；本轮再次出现的「测量窗口内 C4、C8、C16 的限频日志仅覆盖部分活跃 DP」完整性缺口同样没有承载位置。
需要决定： PASS 之前把归档导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记（外部原件用 external 声明），或明确按外部归档登记并在正文声明该范围；两种做法都要把完整性标志及其原因写入 bundle。

F4 — 计分工具身份未 pin，294/300 不可复算（上轮 F4 未决）

位置： 「验收条件」第 4 条（AISBench 原生 Gsm8kEvaluator、zero-shot CoT、thinking/low、贪心、4096 输出上限、并发 32、seed 42）；证据索引 aisbench/gsm8k/subset300/…、perf25/quality/…。
问题： 冻结的环境表只列 CANN 9.1.0、驱动 25.5.1.1、Python 3.12.13、torch/torch-npu，没有 AISBench revision 或抽取/判分代码摘要；本轮精度直接「沿用该候选已完成的 294/300」，其中两题触及 4096 输出上限而答错，距 292 门槛仅 2 题余量。
影响： 不同 AISBench 版本在 CoT 截断、答案抽取与上限处理上的差异足以翻转 2 题，届时无法区分差异来自候选代码还是判分实现。
修复： 在精度证据中记录 AISBench revision 与 Gsm8kEvaluator 抽取/判分代码摘要。相关工作（已核对）：#326 是 open draft PR、未合并，其示例已把 AISBench v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 作为 pin，可作候选；#289 为 open RFC。本 Issue 走原生 evaluator，不依赖该适配器，因此这不是新门禁，只是补齐已冻结协议的工具身份。

F5 — C32 设备归因与实测 TPOT 无法对齐（新增）

位置： 触发评论「六档单轮结果」表（C32 102.116 ms/token；DSpark 接受 45,488/95,485）与其后的 C32 诊断条目（target FULL 回放中位数 293.12 ms/次、草稿提议 65.54 ms/次、单 rank 目标图窗口 296.60 ms 中含主流等待 34.90 ms；仅 4 次回放）。
问题： 63 × 1,024 = 64,512 输出 token，减去接受 45,488 得约 19,024 步（按提案数推算为 95,485/5 = 19,097 步，两者差 73，需说明末步处理），约 3.38 token/步。以 293.12 ms/步计，即使只算 target 也约 86.5 ms/token，与实测 102.116 相差约 15 ms/token 未归因；若每次 target 步前串行 5 次草稿提议，5 × 65.54 = 328 ms 已超过整步时间，两个数值不可能同时都在关键路径上。
影响： 这份归因是下一轮优化的选择依据（Cast 19.66 ms、Mul 16.75 ms、SelectV2 12.95 ms、KV 子字段 Slice 7.85 ms / ViewCopy 7.32 ms 均为单 rank）；步级数字无法与 TPOT 对上账时，任何「该改动可省多少 TPOT」的推断都不可核算，也无法判断瓶颈在 target 算子还是草稿路径。
修复： 在报告中写明 profile 窗口的接受 token/步与提案/步的推导、草稿提议是否串行、以及 profile 服务与正式计时服务在配置（capture size、预热、并发构成、是否同一 RunSpec 签名）上的一致性，并给出 293 ms/步与 102.1 ms/token 的对算式；4 次回放不足以支撑「中位数」结论时补充样本或降级为定性说明。

F6 — 缺 kind:acceptance 必需的三行状态块（此前一轮提出，仍未补）

位置： 正文以「## Campaign」开头，无状态块；docs/agent-collaboration.md:211-218 要求开放 kind:task、kind:acceptance、kind:tracking、kind:rfc Issue 以 **Current state:** / **Decision needed:** …, from <决策人> / none / **Next action:** 三行开头并由执行方保持更新。
问题： 本 Issue 缺失该块，导致 F1 这类待决问题只散落在评论里，没有登记「Decision needed」与 owner；正文「候选 Git SHA：待正式验收后提交」与「当前验收结论 INCONCLUSIVE」也没有权威状态行。
修复： 补三行：Current state 为第四轮六档单轮筛选、INCONCLUSIVE（六档 75.3–102.1 ms/token，距 25 ms/token 仍有 2.9–4.1 倍）；Decision needed 写「封存 1.000%–2.526% 波动门槛是否适用于 FlashComm1 开、fused MC2 关的正式配对（沿用还是按同一公式重校准）」，owner 由 approval owner 指定；Next action 写候选提交 pin、同配置门槛结论与六档交替配对测量。

F7 — 六档单轮是单服务升序扫描，不能用于保留/淘汰判断（新增）

位置： 触发评论第一段（「按档位递增各预热一次」）与六档表（C1 → C32 依次递增）。
问题： 升序单次扫描把并发效应与时间漂移混在一起，C32 在最后测量且显著高于 C16（102.116 vs 82.294）；验收条件第 3 条要求六档交替配对、正式协议至少三组，并在阈值附近或方向不稳定时追加。
影响： 该表本轮已自述为筛选；若后续用这张表的档间差额或与后续轮次的差值做保留判断，就会把顺序/漂移/服务实例差异算成并发或代码差异。
修复： 保留该表但在证据中标注「单轮筛选、非配对、升序、单服务」；正式配对按交替顺序执行，或至少记录档位测量顺序并给出同档重复以分离漂移。

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

InferRSI：DeepSeek-V4.1-Flash 在 vLLM Ascend 上的 0-day 适配任务记录

1. 记录用途与当前阶段

记录日期：2026-11-02，时区 Asia/Shanghai。
用途：保存本次任务的目标、资料边界、环境快照、已知事实和待确认事项，供后续执行与交接使用。
当前阶段：适配已全部迁入 vllm-ascend，原版 vLLM v0.27.1 保持干净。FULL_DECODE_ONLY 已在 TP8/DP2/EP16 实机验证，三开关、Ascend fused MoE 和 DSpark 已完成实机单请求对照。GPQA 全开 V006 已启动，最新状态见第 17 节，前期记录保留作历史快照。
用户最新补充：远端 vLLM 与 vllm-ascend 位于 /vllm-workspace 且已经安装；要求核实本地开发代码的上传方式。实查与传输验证见 3.5、3.6。
本文中的“已确认要求”“已观察事实”“建议”和“待确认”分别标注；建议不代表用户已经接受。
任务、设备和服务状态均为前期检查时的快照，后续实际使用前需要重新核实。

2. 用户目标与明确要求

2.1 任务目标

使用 InferRSI，在 vllm-ascend v0.27.1rc1 上实现 DeepSeek-V4.1-Flash 的适配。

本次定位为 0-day 模型适配实验，用于检验 InferRSI 的能力。
用户明确要求本版做到：

精度正确。
基本功能正常。
不要求优化性能。
本版不要求图片输入。
精度通过数据集评测验收；保留不需要图片输入的 GPQA，参考分数为 88.89。

OCRBench 需要图片输入，按用户明确的排除条件不列入本版验收。
GPQA 的具体子集、评测配置与参考分数的比较口径仍需落实，不能自行把建议值当作验收约定。

2.2 用户提供的硬件条件

项目	用户提供的信息
机器数量	1 台
硬件	Ascend 910C
物理卡数	8 卡
Die 数量	16 die

用户已指定本次目标 Pod 为 jcz-dsv41；其实际设备分配、每个 die 的可用显存、设备拓扑、驱动和固件版本尚待实机核实。
不能仅凭“16 die”就预先确定 TP、EP 或其他并行配置。

2.3 严格资料限制

用户原始要求：

你不可以看当前 InferRSI 中 dsv4.1 的知识库。

你不可以去查找网上已有的 dsv4.1 的各种实现，只可以看指定 Hugging Face 仓库里面的相关实现。

唯一获准查阅的外部 V4.1 实现来源：

https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/tree/main

后续执行应保持以下边界：

不读取 InferRSI 现有 V4.1 知识库。
不把现有 V4.1 历史实验结论、适配补丁、缓存答案等作为本次实验输入；这是为落实用户实验意图所采用的隔离方式。
不搜索或阅读其他网站、仓库、PR、分支中的现成 V4.1 实现。
可查阅上述 HF 仓库内部的模型配置、官方参考代码和相关说明。
HF 页面或文档中的外部链接不自动获得访问授权，不沿链接查找其他 V4.1 实现。
在运行 InferRSI 前，需要核实其知识检索和自动上下文注入入口，防止间接加载被排除的材料。
记录实际读取的资料、采用的代码版本和实验产生的新证据，便于追溯。

既有框架通用代码的使用方式、修改范围以及 InferRSI 自身是否固定版本，见待确认事项。

2.4 已确认的精度与输入范围

用户补充原文：

精度只需要参考数据集即可：GPQA 88.89 OCRBench 84.5. 由于这一版不要求图片输入如果这两个数据集要求图片则不要求

数据集	用户给定参考分数	是否需要图片输入	本版处理
GPQA	88.89	否，文本选择题	纳入精度验收，按准确率百分制记录参考分数
OCRBench	84.5	是，评估图像中的文字识别和相关视觉问答能力	排除，不要求达到该分数

输入类型依据：GPQA 官方项目说明及 OCRBench 原始论文。
此次额外查询仅用于核实数据集的输入模态，不涉及任何外部 V4.1 实现。

不要求图片理解、视觉输入链路或 OCRBench 验收。
精度验收采用 GPQA 数据集结果，不再把官方模型的 logits、逐 token 对齐或额外参考设备作为验收前置条件。
不把任何尚未实测的分数写作本次适配结果；88.89 和 84.5 均为用户提供的参考值。
GPQA 的 Main / Diamond 等具体子集尚未确定，不能仅凭 88.89 推定是 Diamond。
正式评测应记录数据版本、子集、样本数、提示模板、推理与采样设置、输出长度限制、答案解析和计分方法，以便与参考值比较。
用户未另行指定允许下降的幅度；不自行添加容差或降低参考要求。

2.5 已确认的开发基线、Pod 与模型路径

用户明确指定：

项目	已确认值
开发基线	在 `vllm-ascend v0.27.1rc1` 之上开发
iTASK 目标 Pod	`jcz-dsv41`
模型位置	使用 `jcz-dsv41` 内下列现有模型目录
远端上游源码	`/vllm-workspace/vllm`，已安装
远端插件源码	`/vllm-workspace/vllm-ascend`，已安装

/home/admin/model-csi/models/modelhub_77300004_deepseek-v4-1-flash-1017-w8a8-154300046_20261018125324/model

上述 Pod 和路径来自用户明确指定，已经解决“使用哪个任务”和“权重在哪里”的问题。
开发前需记录 v0.27.1rc1 对应的准确 commit；当前本地 main 或 Pod 内现有代码不能未经核实就当作目标基线。
已通过 iTASK 进入目标任务只读检查：模型目录和 config.json 存在；尚未读取模型配置内容或核实权重完整性、实际量化格式及来源 revision。
目录名包含 w8a8，但不能仅据目录名认定具体量化方案，也不能直接认定与 HF 原始检查点的 FP8 / FP4 配置一致。
指定 Pod 内已只读核实代码版本和安装入口，不再以新建任务或下载另一份权重为默认前置步骤。
配套上游 vLLM 已核实为 v0.27.1；其必要修改范围，以及 InferRSI 是否固定版本，仍按后文记录落实。

3. 已执行的前期检查

3.1 iTASK 使用规范

已使用用户明确指定的 itask-cli-guide 技能。
已阅读其命令与参数参考，并核对本机命令帮助。
文件传输检查还阅读了进阶使用说明。

与后续任务相关的规范：

任务操作使用 iTASK CLI。
创建任务前区分普通任务和策略任务；本次已由用户指定现有 Pod jcz-dsv41，当前不需要新建任务。
普通任务需要名称、A2/A3 类型、资源规格和业务镜像；模型镜像可选。
优先使用 itask describe 诊断任务，使用 itask logs 查看运行日志。
常用交互入口为 itask exec -it <任务名> bash。
不默认使用跳过所有者检查等参数，不改动尚未确认用于本次实验的任务。
不记录或输出 token、证书、密钥等凭证内容。

3.2 本地工具与身份快照

项目	检查结果
iTASK 可执行文件	`/Users/jiangchenzhou/.local/bin/itask`
iTASK 版本	`0.4.3-20261026`
iTASK 构建 commit	`c9683a05e84e52faca4b81b9b57ab8f9c25cdbc6`
iTASK 构建日期	`2026-10-26T09:04:27+08:00`
客户端平台	`darwin/arm64`
鉴权状态	已登录
当前用户名	`jcz02615514`
InferRSI 本地目录	`/Users/jiangchenzhou/code/InferRSI`
InferRSI 命令发现	当前 shell 的 `command -v InferRSI` 和 `command -v inferrsi` 未找到命令

未找到 PATH 命令不代表 InferRSI 未安装；虚拟环境、模块入口和实际启动方法尚未检查。

对 InferRSI 仅查看了顶层目录和文件名称，没有读取其项目文档、知识库内容、历史实验材料或源代码。
其版本、commit、通用运行流程和知识隔离机制仍未核实。

3.3 指定目标前的 iTASK 任务列表快照

来源：首次检查的 itask list，查询范围为当前用户，未使用全用户查询。
该快照早于用户指定 jcz-dsv41，仅保留为历史检查记录；以下任务均不是本次默认操作目标。

任务名	类型	部署模式	状态	资源请求
`afd-v032-rebase-20261101`	A3	standard	Running	128C、1600Gi、16 × hpu910a3
`afd-cross-v4-megamoe-20261025`	A3	standard	Stopped	128C、1600Gi、16 × hpu910a3
`afd-mrv2-async`	A3	standard	Stopped	128C、1600Gi、16 × hpu910a3

运行任务的列表信息：

Pod IP：10.30.13.138。
超节点标识：43117103。
当前用户资源占用汇总：A3 为 1 个节点、16 个设备；A2 为 0。

注意：

这些是 CLI 展示的资源请求和状态，不是对物理内存、HBM 容量或设备拓扑的实测。
用户后续指定了 jcz-dsv41；不将本表中任务的 IP、资源或运行状态套用于该目标 Pod。
没有进入上述任务，没有读取其实验代码或日志，没有停止、重启、删除或修改任务。

3.4 vllm-ascend 工作区快照

项目	检查结果
本地路径	`/Users/jiangchenzhou/code/vllm-ascend`
当前分支	`main`
当前 HEAD	`60cba9393c54a8e43d1e4cdc4517be877f899429`
origin	`https://github.com/jiangkuaixue123/vllm-ascend.git`
创建本记录前的工作区	`git status --short` 无输出
目标 tag 本地检查	`git rev-parse --verify refs/tags/v0.27.1rc1` 未解析成功

本地没有解析到该 tag，不代表远端不存在该版本。
当前 HEAD 尚未证明对应目标基线，尚未获取或切换 v0.27.1rc1。
后续实查已取得远端两个仓库的准确基线，见 3.5。
本地 git cat-file -e 检查确认，当前 vllm-ascend 仓库尚无远端 v0.27.1rc1 commit 对象；开发前应获取该版本并建立独立工作树。

本地上游目录 /Users/jiangchenzhou/code/vllm 存在，检查时 HEAD 为 4e4eab73ed2b4e00931a4636e926b8df1cb1fe50。
该 HEAD 与远端上游基线不同，尚未切换或修改。

3.5 目标任务、远端仓库与安装方式实查

来源：itask describe jcz-dsv41，以及通过 itask exec jcz-dsv41 --tty=false 执行的 Git 和 Python 安装元数据查询。

jcz-dsv41 实际可作为 iTASK 任务名解析，具体 Pod 为 itask-jcz-dsv41-jcz02615514-20261102124051-pf7ss。
后续命令使用任务名即可，不需要硬编码完整 Pod 名。

项目	实查结果
任务状态	Running，Ready 为 True
所有者	`jcz02615514`
资源分配	128 CPU、1600Gi 内存、16 × hpu910a3
Pod / 节点 IP	`10.30.12.215`
任务启动命令	`sleep infinity`
工作目录	`/a3_inference/itask/workdir/jcz02615514/jcz-afd1`
Python	`/usr/local/python3.12.13/bin/python3`
模型目录	用户指定目录存在，`config.json` 存在

仓库	Git tag	HEAD	安装元数据版本	安装方式
`/vllm-workspace/vllm`	`v0.27.1`	`6e448d0ea9bf3d88d898b65449ca6dc2aec170ac`	`0.27.1+empty`	editable
`/vllm-workspace/vllm-ascend`	`v0.27.1rc1`	`3b31886237ed65c435e0965b10e8002ff5769766`	`0.27.1rc1`	editable

两个仓库均可写，git status --porcelain --untracked-files=normal 都为空。
direct_url.json 的 editable 标记均为 True，源码位置分别指向上述两个目录。
模块查找位置分别为 /vllm-workspace/vllm/vllm/__init__.py 和 /vllm-workspace/vllm-ascend/vllm_ascend/__init__.py。
查询使用包元数据和模块定位，没有导入模型、读取现有 V4.1 实现或启动推理服务。
远端有 git、tar、sha256sum 和 scp，没有 rsync。
本次只检查资源分配，尚未执行 NPU 显存与拓扑实测。

3.6 本地代码上传方案与验证结果

推荐：基于相同 commit 开发，上传本轮代码补丁，在远端检查后应用。

适用条件与步骤：

本地先为 vllm-ascend 建立以 3b31886237ed65c435e0965b10e8002ff5769766 为基线的独立工作树；如修改上游 vLLM，使用远端对应的 6e448d0ea9bf3d88d898b65449ca6dc2aec170ac 基线。
只打包本次源代码差异，包含新增、修改、删除和必要的二进制差异。普通 git diff 不包含未跟踪新文件，生成补丁时必须显式纳入新文件。
传输前确认补丁小于 50 MB，通过非 TTY 的 iTASK exec 或 SSH 隧道传输。
上传到远端 /tmp 暂存，核对大小和 SHA-256，再执行 git apply --check。
检查成功后应用补丁，查看远端差异，保留补丁和同步版本记录。
后续每轮基于上一次已同步状态生成增量，不向已修改工作树重复应用从初始基线生成的全量补丁。

以下是补丁文件已经生成后的示例，尚未对源码执行：

# 本地补丁路径：/tmp/inferrsi-vllm-ascend.patch
# 上传前确认文件小于 50 MB，并记录本地 SHA-256。
shasum -a 256 /tmp/inferrsi-vllm-ascend.patch

itask exec jcz-dsv41 --tty=false -- sh -c \
  'cat > /tmp/inferrsi-vllm-ascend.patch' \
  < /tmp/inferrsi-vllm-ascend.patch

itask exec jcz-dsv41 --tty=false -- \
  sha256sum /tmp/inferrsi-vllm-ascend.patch

itask exec jcz-dsv41 --tty=false -- \
  git -C /vllm-workspace/vllm-ascend apply --check \
  /tmp/inferrsi-vllm-ascend.patch

# 仅在哈希一致且检查成功后执行。
itask exec jcz-dsv41 --tty=false -- \
  git -C /vllm-workspace/vllm-ascend apply \
  /tmp/inferrsi-vllm-ascend.patch

上游 vLLM 补丁使用独立文件，并将目标目录改为 /vllm-workspace/vllm。
如需多个独立文件上传，可按技能说明使用 itask ssh-tunnel jcz-dsv41 --port 7890 配合 scp -P 7890；该 SSH 方式尚未在本次任务启动或验证。
50 MB 及以上文件按技能要求走 OBS/OSS 中转，不能通过 exec 或 SSH 隧道传输，也不以拆包方式绕过限制。

已完成的传输验证：

项目	结果
通道	`itask exec jcz-dsv41 --tty=false`，二进制 stdin
测试内容	临时 287 字节文件，包含完整 0–255 字节值
本地与远端 SHA-256	`30e105ea86308f79038530512f3a8f5e8160a0c02d84283cd0923c8d6960783b`，一致
清理状态	本地与远端临时测试文件均已清理
源码影响	未上传或应用业务补丁，未修改远端两个源码仓库

安装与生效方式：

两个包均为 editable 安装，纯 Python 源码修改在新启动的 Python / 推理进程中生效；已启动进程不会自动重新加载修改。
若修改 C++、AscendC、自定义算子或其他编译产物，需要在远端按项目构建流程重新编译；不能上传本地 macOS 构建产物代替。
不上传本地 .git、虚拟环境、缓存、模型权重或无关实验资料。
/tmp 仅用于传输暂存；需要持久保存的补丁、基线记录和日志应存放在任务专用的个人持久目录，避免与现有共享工作目录中的实验混用。

4. 指定 HF 仓库中已核实的信息

4.1 模型与权重配置

来源：官方 config.json。

配置项	已读取的值
architecture	`DeepseekV41ForCausalLM`
model_type	`deepseek_v41`
dtype	`bfloat16`
配置中记录的 transformers_version	`5.6.0`
quant_method	`fp8`
activation_scheme	`dynamic`
weight_block_size	`[32, 32]`
scale_fmt	`ue8m0`
expert_dtype	`fp4`
文本层数	40
最大位置配置	1,048,576
路由专家 / 共享专家	384 / 1
每 token 激活的路由专家数	6
视觉配置	存在 `vision_config`
其他相关配置	包含 Engram、稀疏索引、Hyper-Connections 和 DSpark 配置

上述内容是官方模型配置，不表示本地框架已支持这些能力。
配置中的最大长度也不等于本次单机实验已经承诺或验证的上下文长度。
不能仅根据 dtype=bfloat16 将原始检查点视为全量 BF16 权重。

4.2 官方参考实现的用途与限制

来源：inference/README.md。

官方提供可读的最小参考实现。
说明列出的模块包括视觉编码与投影、滑窗及压缩稀疏注意力、两级索引、Engram、MoE、Hyper-Connections 和 DSpark 前向路径。
生成流程采用普通自回归采样。
运行前需要转换 HF 权重，按张量并行 rank 输出检查点。
文档给出了 FP4 专家权重转换示例和文本、JSON 输入示例。
model.py 自测使用未初始化权重，覆盖 prefill 和 decode 的形状、kernel 调用流程，不验证数值精度。

本次适配按用户后续指定的 GPQA 数据集结果验收精度，不能以该自测通过作为精度通过的证据。

4.3 资料访问记录

本次初查访问了以下指定仓库内部页面：

资料	本次用途
仓库文件列表	确认官方文件结构
模型 README	了解模型及功能范围
config.json	核实架构、量化和视觉配置
inference 文件列表	确认参考实现入口
inference/README.md	核实运行、自测说明
evaluation 文件列表	查看官方评测材料入口
evaluation/README.md	确认该说明涉及 DeepSWE 评测流程，未运行

HF 根目录页面当时显示最新短 commit 为 314113f。
目前访问使用的是可变的 main，尚未取得完整 revision 并冻结文件快照；后续实验应记录完整 commit 和文件校验值。

尚未逐行分析 inference/model.py、kernel.py、engram.py、vision.py 等实现文件，也未下载权重。
没有访问上述说明中指向其他实现仓库的链接。

5. 六项问题及当前确认状态

用户已明确开发基线、目标 Pod、模型路径、无图片输入范围和数据集精度参考值。
仍需落实其余功能与评测细节、配套上游 vLLM 修改范围和 InferRSI 版本边界。

5.1 使用哪个任务

已确认：使用用户指定的 iTASK Pod jcz-dsv41。

不再询问使用历史列表中的任务还是新建任务。
已通过 iTASK 核实任务为 Running、属于当前用户并分配 16 个 A3 设备，见 3.5；NPU 显存与拓扑仍待实测。

5.2 权重位置和版本

已确认：模型使用 jcz-dsv41 内 2.5 所列目录，不需要用户再次提供路径。

已核实模型目录及 config.json 存在；后续检查权重索引、配置内容和实际量化格式，确认是原始还是转换后的检查点。
若已有元数据不足以确认来源 revision 或转换过程，再记录具体缺失项。
当前目录名中的 w8a8 仅为路径信息，不作为已验证的权重格式结论。

5.3 基本功能范围

已确认：本版不要求图片输入；依赖图片的 OCRBench 排除。

仍需确定工具调用、reasoning 参数是否属于首版必需功能，以及最小验收上下文长度和并发规模。

此前提出的建议，尚未获用户确认：

通过 vllm serve 提供服务。
覆盖文本多轮对话、流式输出和少量并发。
例如先以 8K 上下文为验收起点，实际值待定。
首版不把投机解码和性能优化列入验收；其中“不要求性能优化”已由用户明确，投机解码是否排除仍待确认。

5.4 精度验收依据

已确认：精度只需要参考数据集。GPQA 参考分数为 88.89；OCRBench 参考分数为 84.5，但因需要图片而排除。

此前“同时使用数值对齐和任务集评测”“先建立独立参考”的建议，已由这次用户补充替代，不再作为必需验收项。
不再要求用户提供官方 logits、token 序列或额外的参考运行设备。

仍需落实的评测细节：

GPQA 使用哪个具体子集，以及对应的数据版本。
与 88.89 参考分数匹配的提示模板、reasoning / 采样配置、生成长度和计分方法。
参考分数的最终通过判定口径；目前未约定额外容差。

所有正式验收结论须附实际评测结果，不能只凭回答通顺判定精度通过。

5.5 代码修改边界

已确认：必须基于 vllm-ascend v0.27.1rc1 之上开发。

配套上游 vLLM 已实查为 v0.27.1，准确 commit 见 3.5；是否允许必要的上游修改尚未单独明确。

此前提出的建议，尚未获用户确认：允许必要的两边补丁，记录准确 commit，不通过升级到其他版本取得现成 V4.1 支持。

5.6 InferRSI 的实验边界

需要确定：

固定当前 InferRSI 版本测试能力，还是允许过程中修复通用框架？
如允许修复，如何区分框架修复、模型适配和人工介入？

此前提出的建议，尚未获用户确认：固定并记录初始版本，单独记录框架问题、修复和人工介入，保留可追溯的实验过程。

6. 仓库开发约束

已阅读当前工作区 AGENTS.md。
后续实现须遵守其中适用的要求，主要包括：

模型适配遵循硬件插件架构，采用必要的 patch、继承、组合或上游修改；不直接在插件中堆入新模型文件。
新 patch 和 model runner 新行为需要架构审查，保持改动集中并解释必要性。
新功能配套测试，缺陷修复配套回归测试，NPU 相关行为需要在实际硬件验证。
新环境变量集中定义在 vllm_ascend/envs.py，记录默认值、范围和敏感性。
避免设备 tensor.item() 等不必要同步，关注 CPU/NPU 传输和内存占用。
本次无性能优化目标，但精度和功能验证不能由未说明的模型语义简化代替。
如果提交代码，遵循 Conventional Commits，并带 Signed-off-by。
如果推送和创建 PR，使用 fork，遵循 PR 模板和版本信息保留要求。
推送前按仓库要求执行 bash format.sh ci；Markdown 也属于格式检查范围。

用户尚未要求提交、推送或创建 PR。本次记录文件的创建不表示已经进入这些阶段。

7. 后续建议执行顺序

以下是待范围明确后采用的建议顺序，不代表已经执行：

补齐剩余问题的答案；基于“无图片输入、GPQA 参考 88.89”落实功能范围和评测配置。
在指定 Pod jcz-dsv41 核实设备可见性、HBM、主机内存、存储、软件栈及指定模型目录。
固定 vllm-ascend v0.27.1rc1 的准确 commit，记录 InferRSI、配套 vLLM、现有权重和 HF 参考代码版本。
在不读取被排除材料的前提下核实 InferRSI 的通用入口，隔离 V4.1 既有知识和实验产物。
核对权重及 tokenizer，准备 GPQA 数据集和可复现的评测配置。
仅依据指定 HF 实现分析适配差异，落实权重加载、算子与框架接入。
在目标 910C 设备上验证单请求 prefill/decode，再覆盖约定的服务功能与并发场景。
执行 GPQA 评测并与 88.89 参考分数比较，记录配置、实际结果、失败原因、修复及未通过项。
汇总代码改动、启动命令、版本清单和可复现的验收证据。

任何尚未运行或未通过的项目，都应保留明确状态，不写作“已完成”或“精度正确”。

8. 当前完成状态

9. 更新记录

日期	更新
2026-11-02	建立任务记录，保存首次沟通、前期检查结果和待确认问题；未进行模型适配或运行验收。
2026-11-02	根据用户补充，确定本版不要求图片输入；精度采用 GPQA 88.89 参考值，OCRBench 84.5 因依赖图片而排除；撤销数值对齐和额外参考设备的必需验收要求。
2026-11-02	用户确认基于 `v0.27.1rc1` 开发，指定 iTASK Pod `jcz-dsv41` 及其中的模型目录；同步移除任务选择、权重位置的待确认状态，保留实际环境和权重格式核验项。
2026-11-02	用户补充远端代码位于 `/vllm-workspace` 且已安装；实查两个 Git 基线和 editable 安装，确认模型路径存在，并完成 287 字节上传与哈希校验，记录基于补丁的同步方式。
2026-11-02	按用户指令正式开始使用隔离 InferRSI 执行；用户固定并行策略为 TP8/DP2/EP16。完成首个配置补丁、远端回归与 Engram 数值探针；完整模型和 GPQA 尚未通过。

10. 首轮执行进展

本节更新当前执行状态；上文前期观察和未确认事项保留为历史记录。

用户新增明确约束：TP8、DP2、EP16。后续不得自行换成 TP16 或 PP2。
实验目录：/Users/jiangchenzhou/code/dsv41-0day-20261102；远端个人持久目录：/a3_inference/itask/workdir/jcz02615514/dsv41-0day-20261102。
已固定 InferRSI commit 919ed42c0d01dc0aa3b613085b9041d735d2d4db，只导出通用源码及 vLLM repo pack，禁用知识检索。实际运行 doctor、plan 和 InferRSI 执行 API；未读取已有 V4.1 知识或历史适配。
官方 HF 参考固定为 314113f8a7dadb388215396ba5fbee2c610a04d6，17 个参考文件逐项记录 SHA-256；未下载官方权重。
原始两个仓库的准确基线再次核实，创建独立本地工作树；远端上游采用 codex/dsv41-0day 分支。未升级 Transformers。
实机检查为 16 个健康 die，每个 64 GiB HBM；权重实际包含 W8A8_DYNAMIC 线性量化与 INT8/E8M0 Engram 表。143,324 个索引项、142 个分片通过索引/头/边界检查，但没有对全部权重做校验和或确认转换来源。
首个补丁已应用到远端 /vllm-workspace/vllm：独立 V4.1 配置类与注册，含 7 项远端通过的回归测试；Ruff 检查通过。修改后的 5 个文件本地/远端哈希一致。
启动结果从“无法识别 deepseek_v41 配置”推进到“尚无 DeepseekV41ForCausalLM 模型实现”。服务尚未启动成功，模型权重尚未完整加载。
Engram 原型只读取每表 4 行；修正 NPU exp2 的 FP32 近似误差后，精确位模式解码在 NPU 对实际抽样和合成边界均零差异。未证明 hash、rotation、门控或完整前向。
GPQA Diamond（198题）、Main（448题）均已本地下载并上传，校验和一致。独立评测器及探针工具共 29 项测试在远端通过；Diamond dry-run 通过。没有真实 GPQA 分数，也没有宣称达到 88.89。
首轮默认准备 Diamond 探索评测；用户只询问了两个子集的区别，尚未确认正式比较口径。主模型、注意力/缓存、HC/MoE 与完整 Engram 集成仍待完成。

详细证据、待完成矩阵和执行边界见首轮执行报告。模型接入方案见架构审核记录。全部状态保持 INCONCLUSIVE；未提交或推送代码。

11. 模型本体实现进展

本节承接第 10 节，记录后续执行中的结果，不表示适配已经完成。

已在独立上游工作树实现并注册 DeepseekV41ForCausalLM：HC 跨子层 pre-mix、窗口/压缩稀疏注意力、分页状态、按请求恢复 Engram 三 token 历史，以及按权威索引加载本 rank 权重。
MoE 使用 TP8/DP2/EP16 的独立通信范围，每个 EP rank 持有 24 个 routed experts。路由权重在 down projection 前施加；按实际 DP token 数汇集 packed batch，避免不等长请求触发不同次数的 EP collective。
已有局部实测：primitives/core/Engram 65 项通过、HC 独立 NPU 18 项通过、分页注意力 CPU/NPU 24 项通过、权重加载 CPU 11 项通过、MoE CPU/模拟通信 19 项通过。各轮之间存在重复覆盖，不能简单相加作为独立用例数；真实 EP16 尚待服务验证。
后续测试使用 uv 创建的 validation-venv，继承现有安装依赖，不升级 Transformers、torch 或 vLLM。
单层 dummy 服务已经通过模型识别，首轮在量化描述读取阶段失败：仅有 quant_method: ascend 的配置被误认为完整描述。最小通用修复已应用到远端插件，相关回归 8 项通过，第二轮单层服务正在执行。
Engram 表继续保留 CPU mmap，只按 hash 读取对应行。两份重复 Wkv 实测相同，不能拿旧分片作为未旋转基准；正从唯一获准的官方 HF revision 获取少量权重范围，核实全局旋转方向。未验证方向前不允许真实 Engram 前向猜测运行。
本阶段仍没有真实权重生成或 GPQA 分数。ACLGraph、MTP、完整上下文容量等均未通过；图片输入按用户要求排除。所有代码尚未提交或推送。

局部试验证据汇总：primitive_test_summary.json。

12. 真实 40 层服务验证

单层 W8A8 dummy 在 TP8/DP2/EP16 下通过 /v1/models 和非空文本生成。随后完整真实权重在每个 rank 严格加载 9,860 个必要参数，16 个 rank 均通过，无未加载参数；Engram 表驻留 host mmap。每 rank 权重占用约 35.12 GiB，首轮可用 KV 约 19.94 GiB。
第一轮真实 /v1/completions HTTP 200，The capital of France is 返回 Paris.。检查点未附聊天模板，/v1/chat/completions 返回 400；不将该轮记为聊天通过。
第二轮显式指定获准 HF revision 的 chat_template.jinja，保持 TP8/DP2/EP16，使用 --max-model-len 32768 --max-num-batched-tokens 128 --max-num-seqs 8 --enforce-eager --no-enable-prefix-caching。聊天 2 + 2 返回 4，HTTP 200。
中文单句、多轮记忆（7 的两倍返回 14）、流式输出（1, 2, 3，收到 [DONE]）、不等长并发（18 与 499 输入 token，返回 9 与 12）均实际通过。首个开放式流式探针达到 64-token 上限，保留原始结果；有明确短答要求的复测正常结束。
同一上游候选补丁本地与远端 SHA-256 均为 4d60c1bfd57cbb9c6ab3d612ce42f9d5f896d9a11823e446081040fbc629578e。插件 ModelSlim 修复实际源码两端哈希一致。详情见候选版本记录。
已核对 Diamond 198 题模板化输入长度 111–2593 token，最大输入加 16,384 输出为 18,977，低于服务 32,768 上限。精度结果以完整 198 题为分母；目前不宣称达到 88.89。服务步骤见 RUNBOOK.md。

13. GPQA 全量实测已启动

北京时间 2026-11-02 14:15，在 jcz-dsv41 通过隔离 InferRSI 启动独立的持久任务 gpqa-diamond198-campaign-002（capture PID/PGID 72635）。真实 40 层 W8A8 模型沿用 TP8 / DP2 / EP16，评测使用 Diamond 198 题、seed 0、temperature 0、top-p 1、thinking/high、最多 16,384 输出 token、并发 8。

首轮长测启动在任何 GPQA 请求发出前停止，因为没有 reasoning parser 时推理中间选项可能被误计。002 使用官方模板及基线 --reasoning-parser deepseek_v3；一道人造选择题验证了推理字段独立、最终内容是正确选项、finish_reason 为 stop。2026-11-02 14:20:55 的服务指标显示两 DP 各处理 4 道真实评测题，已发出 8，已完成 0。全量结果将写入远端 evidence/results/gpqa-diamond198-campaign-002/result.json；此时不报告准确率，也不宣称达到参考值 88.89。

首批真实请求快照 · 查看最新进度的命令与结果路径

14. 插件迁移与 FULL_DECODE_ONLY

用户明确指定全部实现在 vllm-ascend。如需修改上游行为，遵循插件 vllm_ascend/patch/ 的机制。旧原型补丁仅供历史追溯。本地和远端 vLLM 工作树均恢复到原版 v0.27.1，commit 6e448d0ea9bf3d88d898b65449ca6dc2aec170ac，状态干净。配置、模型、注意力、Engram、MoE、测试及图输入准备均迁至插件。注册使用 Transformers AutoConfig.register 和插件现有 ascend_model entry point。

GPQA 任务 gpqa-diamond198-campaign-002 已结束，状态为 INTERRUPTED。14 题曾发出，7 题有完整结果，另外 7 题在暂停时没有终态。后续保持暂停。新的单请求 TPOT 使用两次独立服务，固定 TP8/DP2/EP16、同一提示、256 上下文、单请求、预热 1 次、测 3 次，每次输出 32 token。

当前插件源码 · 执行记录

15. 多尺寸 FULL_DECODE_ONLY 与 16 并发实测

单一签名提交 6fce64b5934af03195c9109aba8974a55a8c0b31 位于本仓库的 codex/dsv41-0day 分支。所有实现、注册、测试和部署教程都在插件，上游 vLLM 无改动。完整模型目录测试 179 项通过、1 项跳过，仓库全量格式检查 18 项均通过。

32,768 上下文的正式服务使用 FULL_DECODE_ONLY，捕获尺寸 [1,2,4,8]，每个 DP 最多 8 行，客户端并发 16；prefill 和混合步使用 eager。先通过两个 DP 各 8 行的非数据集实机验证。北京时间 15:39:53，V005 开始正式 Diamond 198，之后日志也确认两个 DP 均重放了 capture_size=8 active_rows=8。完整准确率尚待测得。

同一 32K 服务的单请求 TPOT 中位数 340.80 ms/token，TTFT 中位数 1246.51 ms。单行阶段在 256 上下文做的同源 A/B 为 eager 501.30、FULL_DECODE_ONLY 289.30 ms/token，下降 42.29%。15:41:07–15:42:21 实际 GPQA 合计生成 1,536 token（20.75 token/s），两次快照均为 8+8 个活跃请求。

执行报告 · 实时进度命令 · 16 并发重放证据

16. 并行优化与 DSpark

北京时间 16:38，GPQA V005 已停止派题并退出，监控已关闭。共发出 33 题，17 题有终态，其中 16 题正确，另有 16 题没有终态。最终状态 INTERRUPTED，完整 198 题准确率为空。结果记录

在 jcz-dsv41 使用 InferRSI、原版 vLLM、TP8 / DP2 / EP16，对比旧部署和开启 enable_dsa_cp、enable_flashcomm1、enable_shared_expert_dp 的插件。512 上下文、FULL_DECODE_ONLY [8] 的三开关服务完成 DP 1/0、3/1、8/8 三波共 21 条合成请求，输出 token 与旧部署逐个相同；8/8 的总吞吐从 21.75 增至 26.99 输出 token/s。三开关实机记录

实机检查点含 3,554 个草稿参数索引项，DSpark 块大小为 5。新增适配覆盖目标第 37/38/39 层辅助状态、独立草稿权重、Markov 采样以及 6 位置的整图目标校验。草稿接受计数与端到端输出由后续实机验证记录。执行报告

带有 Signed-off-by 的提交 ef85e46d73b21d93245a36a9d77ce01e3f49ebad 位于插件分支 codex/dsv41-0day。目标和草稿路由专家均使用 AscendMoERunner，真实工作中观察到 W8A8 grouped W2 执行和整图重放。每组预热一次并串行测五次，相同的 20 个输入和 32 个生成 token 在三组中逐项相同。TPOT 中位数为全关 209.41、三开关 344.89、三开关加 DSpark 59.16 ms/token。最后一组较全关降低 71.75%，较只开三开关降低 82.85%，正式单请求的草稿接受数为 150/150。三组结果 · 提交和补丁清单

独立同源复核成功，21/21 个合成请求的提示和输出 token 完全一致，1/0、3/1、8/8 三波均在原始窗口观察到 FULL 重放，草稿累计接受 614/630 个提议。独立复核

17. 全开配置的 GPQA Diamond 198

V006 于北京时间 18:46:55 启动。使用提交 ef85e46d7 的 TP8 / DP2 / EP16 服务，三个并行开关和 DSpark 全开，目标校验为 FULL_DECODE_ONLY，图尺寸 24/48。独立评测同一 198 题，评分协议、选项顺序、并发和最大输出与 V005 相同。运行手册 · 冻结发布

北京时间 18:52:14 通过 32K 服务的 thinking/parser 与 8+8 实机验证后开始派发真实题目。18:53:23 快照为 17 题发出、1 题完成、16 题在途；两个 DP 各有 8 个活跃请求，并已在正式 GPQA 后重放 48 行 FULL 图。正式运行快照

GPQA V006 主动停测

2026-11-02 北京时间 19:36 按用户要求停止派题。InferRSI 以 130 退出，评测状态为 INTERRUPTED。198 题中派出 52 题，36 题有终态，其中 34 对、2 错，16 题已派且没有终态，146 题未派。没有完整准确率。未重发已派题目。19:37:48 核实服务进程、16 个 NPU rank、8000 端口及实验锁均已释放，定时监控已关闭。停测审计

图像 encoder、前缀缓存与 A3 原生 SWA/DSA

交付插件提交 c17d9e6e1da3d9909d6bce30bf7b6a2ea5802ce4，上游 vLLM 6e448d0ea9bf3d88d898b65449ca6dc2aec170ac 保持干净。在 jcz-dsv41 的 TP8、DP2、EP16 上开启三个并行开关、Ascend fused MoE、DSpark5、前缀缓存和 FULL_DECODE_ONLY 24/48。红、蓝图片均被正确识别，长文本和相同图片热请求命中 128 个 token，换图及跨 DP 首次命中 0。相同的 20-token 输入和 32-token 贪心输出，单请求 TPOT 从 58.51 降到 43.38 ms/token，改善 25.86%，TTFT 从 968.27 降到 812.37 ms。5 次正式请求的 150 个提议全部被接受。GPQA 保持停测。执行报告 · 对照结果

2026-11-03 · PD 混部 8192 的 Diamond 198 完整重测

jcz-dsv41 上按 TP4 / DP4 / EP16、全局并发 32、原生 DSA/SWA、Ascend fused MoE、DSpark5 和 FULL_DECODE_ONLY 24/48 运行。单请求矩阵中 TPOT 最低的开关组合为 DSA-CP 开、FlashComm1 显式关、共享专家 DP 开，TP8 / DP2 下测得 43.60 ms/token。DP4 服务配置 max-num-batched-tokens=8192，投机预留后调度上限为 8160；修复 eager 工作区后每个 DP 有 33,920 个 KV token，四组均通过 8208-token 冷 prefill 和 FULL48 实测。

独立批次 gpqa-diamond198-native-mask101-tp4dp4-c32-b8192-008b 完成 198 个唯一终态，163/198 正确，准确率 82.32%。其中 9 题正常结束但答错，26 题达到 16,384-token 上限后截断；HTTP 错误为 0。完整评测用时 152 分钟。两轮达到 100 题时，预算 8192 用时 59.6–61.4 分钟，预算 128 用时 69.7–71.8 分钟。88.89% 参考值的完整口径仍待核实。公开结果 · 执行报告

8192 工作区优化签署提交为 e7ea11c4b86e9e7ca37a2e19c66b83df4de78a4a（vllm-ascend 的 codex/dsv41-0day）。313 项 CPU 定向回归、29 项已部署 A3 数值测试及 16 卡 8192 大 prefill nightly 均通过；最终资源已释放。

2026-11-03 · 150,000-token 上下文 / 128-token 块

jcz-dsv41 实机沿用 TP4 / DP4 / EP16、并发上限 32、DSpark5、开关 101、预算 8192 和 FULL_DECODE_ONLY 24/48。V4.1 缓存按层分配，每个 DP 实测可容纳 194,027–194,155 token。DP0 单条冷请求逐项确认 149,887 个输入 token，成功生成 113 个 token，总长 150,000，耗时 620.99 秒，跨越 149,888 的页界，decode 实际重放 FULL24。32 路短请求在各 DP 上重放 FULL48，另一次前缀对照的实际命中为 0 和 128 个 token。InferRSI 实机记录

交付提交 d4ac4319acdaf480689c39b6320a998712f80523 位于 vllm-ascend 的 codex/dsv41-0day。独立实机 nightly 再次验证相同请求边界，pytest 通过，测试后资源已释放。nightly 执行记录

本 Issue 跟踪 DeepSeek V4.1 Flash 在 910C 上六档 decode TPOT ≤25 ms/token 与固定 GSM8K 精度验收，当前仍为 INCONCLUSIVE；本次触发评论没有提供新的 campaign 测量，而是粘贴了一份属于另一套 RunSpec 的适配任务记录。结论：needs information / 需 owner 决策——该更新引入新的越界与合规问题，而此前各轮评审的验收前提仍未被回应。正文没有请求代码变更的句子，不构成开发授权；kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 需配合 status 标签，故不新增标签。

F1 — 触发评论属于另一项工作的任务记录，与本 Issue 冻结的 RunSpec 和门禁不一致（需 owner 决策）

Where: 触发评论《InferRSI：DeepSeek-V4.1-Flash 在 vLLM Ascend 上的 0-day 适配任务记录》（2.1、5.4、第 10 节、2026-11-03 · PD 混部 8192 段）；对比本 Issue「初始修订与基线运行配置」表与「验收条件」。
Problem: 该记录自述的定位是 0-day 适配：2.1 节把用户要求写为「不要求优化性能」，5.4 节把精度门禁定为 GPQA 88.89（OCRBench 84.5 排除），第 10 节起并行策略为 TP8/DP2/EP16；实测精度为 GPQA 163/198（82.32%）。本 Issue 冻结的是 TP4/DP4/EP16、显式 FlashComm1 开 + enable_fused_mc2=0、GSM8K 292/300 与六档 TPOT ≤25 ms/token。两者既不是同一 RunSpec，也不是同一组门禁，资料边界（只允许指定 HF 仓库）也是另一项约定。
Impact: 记录中的 43.60 ms/token、82.32% 等数字一旦与六档表并列，下游会误读为本 campaign 的进展或证据；而「不要求优化性能」与本 Issue 的目标直接冲突，后续读者无法判断哪个约定有效。
Fix: 由验收 owner 决定其一：把该记录移入独立 Issue/归档目录，此处只留指针；或在正文声明「TP8/DP2/EP16、FlashComm1 关的适配记录与 GPQA 结果不属于本 campaign 证据」。在此之前不要并入证据索引或与六档数据同表发布。

F2 — 该记录在公开 Issue 中写入个人绝对路径、内部主机名与 IP（需修改评论）

Where: 触发评论 3.2、3.3、3.5、5.2、第 10–12 节及其中的文件链接（含 /Users/<user>/code/... 形式的用户专属路径、本地用户名、Pod 全名、两个节点 IP、模型挂载路径）。
Problem: docs/privacy-security.md:3-12 明确该规则适用于 Issues，禁止真实 IP、主机名、用户名与用户专属绝对路径；AGENTS.md:119-125 要求对地址、IP、主机名、用户名和个人路径使用占位符。当前评论把这些内部标识直接公开在该 Issue 上。
Impact: 公开了个人身份路径与内部拓扑（节点 IP、Pod 命名、存储路径），且同一份未脱敏记录若被当作证据导入 evidence/，会把该泄漏固化进仓库。
Fix: 编辑该评论，用 <REMOTE_USER> / <REMOTE_HOST> / <MODEL_PATH> 等占位符替换；此后粘贴记录前先做脱敏，并对同源文件做一次检查再决定是否入证据树。

F3 — 记录中测得最优的单请求配置，正是本 Issue 明令关闭的方向

Where: 触发评论 2026-11-03 · PD 混部 8192 段（「单请求矩阵中 TPOT 最低的开关组合为 DSA-CP 开、FlashComm1 显式关、共享专家 DP 开，TP8 / DP2 下测得 43.60 ms/token」）；对比正文「当前开关要求」（显式开 FlashComm1）。
Problem: 正文把显式 FlashComm1 开、fused MC2 关定为当前要求，并要求比较 KV 优化时两版使用同一配置；而记录显示该项自测中拿到最低单请求 TPOT 的组合是 FlashComm1 关。两个陈述不能同时代表「当前配置」。
Impact: 若 FlashComm1 开是硬约束，这里缺少「为何不采用 43.60 ms/token 那套配置」的记录，后续配对会在未说明的前提下继续按较慢的通信配置推进；若不是硬约束，冻结的开关要求就需要重新决策，否则六档结论建立在一个可能被推翻的前提上。
Fix: 由 owner 在 Decision needed 中明确 FlashComm1 开是否为不可协商的冻结条件；若保留，记录不采用 FC1-off 数据的理由与适用边界。

F4 — 更新未回答任何未决验收前提，Issue 仍缺权威状态块

Where: 正文以「## Campaign」开头，无 **Current state:** / **Decision needed:** … from <决策人> / none / **Next action:**；docs/agent-collaboration.md:212-218 要求开放 kind:acceptance Issue 以此三行开头并由执行方保持更新。相关正文位置：表格「候选 Git SHA | 待正式验收后提交」、「已封存基线」门槛 1.000%–2.526%、「证据索引」。
Problem: 本轮我实际运行 python tools/validate_evidence.py，结果为 21 个 bundle、无 dsv41 条目；本检出没有 perf25/，evidence/ 下也没有 dsv41-910c-decode-tpot25。因此先前各轮指出的前提仍全部开放且没有承载位置：封存门槛对 FlashComm1 开配置的适用性未决、候选仍只有工作树清单 SHA-256（.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35 把 full git SHA 设为必填，docs/contributing.md:98-101 要求 pinned revision 与冻结门禁）、验收证据不在仓库、AISBench 计分工具未 pin。触发评论没有更新其中任何一项。
Impact: 未决问题只散落在评论里，读者与后续评审无法区分「已定」与「未定」；即便六档达标，也仍缺少 pinned comparison 与可校验证据树，无法判 PASS。
Fix: 在正文顶部补三行状态块：Current state 写第四轮六档单轮筛选、INCONCLUSIVE；Decision needed 写「封存波动门槛是否适用于 FlashComm1 开配置」和「F1 记录归属」，owner 由 approval owner（.github/knowledge-model-policy.json 记为 Dong1017）指定；Next action 写候选提交 pin、门槛结论与六档交替配对。

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

Full-model rotary and ordinal screens

All three sources were measured on the same 16-rank node with DP4/TP4/EP16, DSpark-5, FULL_DECODE_ONLY and identical 1,024-in / 1,024-out synthetic input sets. The plain client ran one complete exploratory sweep per source, with separate warmups. The three-service comparison does not set formal performance or quality scores.

Concurrency	Slot reuse (ms/token)	+ stock partial RoPE	+ stock FP32 ordinal	Ordinal reduction from RoPE
1	53.437	51.183	49.580	3.13%
2	52.893	50.155	48.878	2.55%
4	54.948	51.980	50.187	3.45%
8	56.160	54.544	51.975	4.71%
16	58.495	57.571	59.311	-3.02%
32	73.246	70.858	69.646	1.71%

The stock rotary path passed 7 unit tests, 8 A3 system tests and all three required dispatch signatures on all 16 ranks. It improved all six observed tiers over the physical-slot parent. The ordinal implementation passed 6 unit tests, 4 A3 system tests and all four dispatch geometries on all 16 ranks. All owners were released.

At C16 ordinal increased whole-wave TPOT by 3.02%. The interval from each first token until all streams had their first token contributed 0.88 ms/token on the parent versus 4.02 on ordinal. The common output interval contributed 52.14 versus 50.81. The per-request timing decomposition locates the difference without establishing a device-level cause. The predeclared parent-selection rule therefore keeps the rotary source for the next full-model change. Neither experiment ran GSM8K-300.

A separate A3 cache-write probe retained the original shape-specific ScatterUpdate kernel at each of 18 sites and removed 18 pairs of full-table copies. All six geometry cases matched the original backing bytes in eager and graph replay, including NaN payloads and idle slots. At the production table size with 24/48 verification rows, the eighteen-write graph took 16.79→1.34 / 16.92→1.81 ms (9/9 faster pairs for each). The measured allocation peak increased by about 16 MiB, with 17 KiB extra retained. This remains a single-device subgraph result.

Rotary source 10b66820a051f414d987e7421aee934eb7dfa288d83efcf8863bd28c7ff93c6d. Ordinal source f4c276568bec021bfa9f0876edb8a8be085c3131b8a2ebe2f1803e590db0558f. Ordinal complete raw-client audit SHA-256 cee63495dc3a5caa30fa41e402ac799821a132c4dccc5d1fd31ea7b4eb09d0f4.

意图：继续维护 dsv41-910c-decode-tpot25 验收，本轮新增 rotary/ordinal 全模型六档比较与 A3 ScatterUpdate 写缓存探针，并据此保留 rotary 作为下一轮父臂，整体仍为 INCONCLUSIVE。结论：needs information / human decision required——两项新结果分别存在会话归属和指标口径问题（见 findings），F19/F24/F5/F1/F2/F9/F3 等保持 open，F26 仅部分回应，F22 上轮 fixed 后再次回退。正文没有请求修改代码的句子，不构成开发授权，未发现引导自动评审的文本；未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 按 .github/labels.json 须配合 status 标签而本 Issue 无 status 标签。

F27（新）— high，must-fix，测量 — 新表首列与 19:52 评论逐位相同，本轮并非三源同会话各一轮

Where: 触发评论「All three sources were measured on the same 16-rank node … one complete exploratory sweep per source」及其表首列 53.437 / 52.893 / 54.948 / 56.160 / 58.495 / 73.246；评论 6613949877 的「With slot reuse」列同值；正文验收条件第 1、3 条。
Problem: 六档读数小数点后三位全部相同，而 19:52 的两个服务已被回收（该评论「Both services were reaped」）；服务重建后的计时不可能六档全部重合，故父臂列复用了 19:52 的历史读数。于是 rotary 相对父臂的 1.58%–5.40% 与 ordinal 相对 rotary 的 1.71%–4.71% 都是跨会话相减，既非同一会话配对，也无同臂重复噪声底。
Impact: 保留 rotary 作为下一轮父臂建立在跨会话单轮比较上，正是正文第 3 条交替配对要排除的漂移来源。
Fix: 同一会话内三臂交替/配对重测六档，给出逐档配对计数与同臂噪声底；若确实复用历史父臂读数，就在表中标注该列来自 19:52 会话并把差值降级为探索性、不用于选择父臂。

F28（新）— high，must-fix，需 owner 决定 — 保留 rotary 用的是未冻结的 whole-wave TPOT，且该规则此前未登记

Where: 触发评论「At C16 ordinal increased whole-wave TPOT by 3.02% … The interval from each first token until all streams had their first token contributed 0.88 … versus 4.02 … The common output interval contributed 52.14 versus 50.81 … The predeclared parent-selection rule therefore keeps the rotary source」；正文验收条件第 1 条「按每个请求的 (E2E − TTFT) / (实际输出 tokens − 1) 计算 ms/token，再对该轮请求取算术平均」与第 3 条；docs/contributing.md:98-101。
Problem: 冻结指标是逐请求均值且排除 TTFT，评论却把 C16 的 3.02% 损失归到「各请求首 token 到所有流产生首 token」这一 TTFT 展宽区间；同一分解中 ordinal 的 common output interval 反而快 1.33 ms/token（50.81 对 52.14），按冻结指标 ordinal 很可能更优。(b) 两臂没有给出六档逐请求算术均值。(c) 全量检索正文、plan/ 与 21:15 之前所有评论，predeclared parent-selection rule 只出现在 21:15 这条评论，阈值与预设受益档是事后给出的。(d) 分解不闭合：0.88+52.14=53.02 对 57.571，4.02+50.81=54.83 对 59.311，两臂各约 4.5 ms/token 未解释。
Impact: 下一轮父臂的选择建立在与冻结门禁不同的指标和事后规则上；若按正文指标 ordinal 更优，把 rotary 作为父臂会把更差的实现带进正式配对。
Fix: 给出两臂六档逐请求 (E2E−TTFT)/(tokens−1) 均值与噪声底并用冻结指标重做保留判定；在正文与 plan/ 预先登记保留规则后再测量；若要改用 wave 指标，须由 owner 改写第 1 条并说明与 25 ms 门槛的关系。

F19 — high，must-fix，需 owner 决定 — 正文仍一边说阈值还要两组，一边把 1.000%–2.526% 当第 3 条唯一门槛（上轮 open，本轮未改）

Where: 正文 **Current state:**「仍需另外两组才能设定逐档波动阈值，不能与先前观察条件下的校准混算」；同一正文验收条件第 2 条仍 [x]、第 3 条「该档门槛」与「## 已封存基线」表（1.000%–2.526%）；AGENTS.md:64、docs/contributing.md:98-101。
Problem: 该自相矛盾上轮已写入正文，本轮触发评论没有处置：旧两组是否作废、第 2 条是否退回 [ ]、三对校准如何生效均未记录。下一轮 rotary/ordinal 的保留与正式配对仍要用这套门槛判读。
Impact: 候选保留/淘汰与最终 PASS 失去可追溯的判读基准，plan/ 冻结值与正文判为未定型的表冲突。
Fix: 由 owner 明确旧两组封存是否作废、第 2 条是否退回 [ ]、新三对校准的公式与生效时点，并把逐档活跃 DP 数、FULL 回放条数与完整性标志写入正文与 plan/。

F24 — high，must-fix，需 owner 决定 — 物理 selected-KV slot 复用仍是这两个新候选的父臂，C≥2 别名安全证据仍无（上轮 open）

Where: 触发评论表首列即评论 6613949877 的 slot-reuse 候选；该评论「At concurrency 32, the two services matched on 0 of 32 complete output hashes」；评论 6612233089 中同一父服务自比也是 0/32；docs/contributing.md:103-106。
Problem: 复用改变 decode 实际读取的物理 KV 位置，正确性取决于「被复用 slot 仍被在途序列引用时不得被覆写」。唯一多序列等价性指标在父臂自比时即为 0/32，已无判别力；C1 哈希只覆盖单序列；16 rank refresh/reuse pattern 是插桩计数而非别名安全证明。本轮把 rotary 与 ordinal 都建立在这个父臂上。
Impact: 若复用落在仍被引用的 slot 上，输出会无报错地被污染，并同时出现在两个新候选的对照里，使跨臂差值失真。
Fix: 写明复用不变量（可复用条件、引用计数/失效规则），补专门验证别名安全的 C≥2 测试（每序列与不复用臂逐 token 对照并给同臂噪声底），证据与冻结 300 题齐备前不把复用臂当作父臂或保留。

F5 — high，must-fix，需 owner 决定 — 正文对 FlashComm1 仍取互斥值，本轮新扫测也没写 FC1、enable_fused_mc2 与环境签名（上轮 open）

Where: 正文「## 当前开关要求」（显式 FlashComm1 开、enable_fused_mc2=0，并要求新增测量标明这两项）对「## 初始修订与基线运行配置」表「Ascend 开关 … 显式 FlashComm1 关」；触发评论只写「DP4/TP4/EP16, DSpark-5, FULL_DECODE_ONLY」，无 FC1、enable_fused_mc2、环境签名与服务实例；评论 6613949877 写明父臂是 FC1 开、fused_mc2=0。
Problem: 冻结表与当前要求给出相反取值，读者无法判断 1.000%–2.526% 属于哪套配置；本轮 C1 49.58–51.18、C32 70.86 与 FC1-关封存基线 93.86–129.04 不在同一量级，评论又没写开关，故无法证明属于当前要求的 RunSpec，也违反正文自己的标注要求。
Impact: 同一配对会因阈值口径与配置归属翻转被保留或淘汰（历史上 FSQ 1.93%、FS 3.18% 正落在翻转区间）；阈值来源与下一轮父臂都无法复核。
Fix: 由 owner（.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]）把冻结表开关行改成实际生效值并固定唯一门槛公式与生效时点；此后每轮必须写 FC1、enable_fused_mc2、环境签名、服务实例与冻结参数（并入此前 F16）。

F1 — high，must-fix — rotary/ordinal 仍只有工作树清单摘要，没有可检出提交（上轮 open）

Where: 触发评论「Rotary source 10b66820…」「Ordinal source f4c27656…」；正文表「候选 Git SHA | 待正式验收后提交」；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33（candidate_sha 必填 Full git SHA）；AGENTS.md:87。
Problem: 两个 64 位值都是文件清单 SHA-256，无法从任何提交重算，也表达不出第 3 条要求的直接父版本；评论没有给出各自提交/分支与父 SHA，本轮 18-site 写缓存探针连清单摘要都没有。
Impact: 49.58–73.25 的读数与 7/8、6/4 用例回执都无法在具名修订上复跑，后续 300 题与正式六档无法绑定，PASS 前提不成立。
Fix: 在任何保留/下一轮父臂判定前，把 rotary、ordinal 与写缓存探针落成 codex/dsv41-0day 上的真实提交，逐轮记录候选 SHA 与父 SHA；清单摘要保留作交叉校验。

F2 — high，must-fix — 仓库内仍无本 campaign 证据，本轮所有新数字只在评论里（本次实测复核，上轮 open）

Where: 正文「## 证据索引」只列相对实验归档根目录的 perf25/…；触发评论的 10b66820…、f4c27656…、cee63495… 与写缓存探针结果均无路径；AGENTS.md:89、docs/contributing.md:117-122。
本次实测（检出 663f3b3）: python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；evidence/ 下无 dsv41/perf25/tpot25 目录，grep -ril "dsv41\|perf25\|tpot25" 在 json/md/py 中无命中。
Impact: 决定下一轮父臂的读数、六档逐项值与配对回执无法复核，也无法按正文要求被下游引用；单值摘要不能定位原始波与失败/回滚记录。
Fix: 登记 evidence/dsv41-910c-decode-tpot25/（plan/、results/、patch/、validator/），原始波按 tools/evidence_inventory.json 既有 external 先例说明，导入前做脱敏复查。

F9 — high，must-fix，需 owner 决定 — 精度门禁顺序仍只是评论口径，本轮再次跳过 300 题（上轮 open）

Where: 触发评论「Neither experiment ran GSM8K-300.」；评论 6613949877「The acceptance workflow skips accuracy on a performance regression…」「GSM8K-300 was not launched.」；正文验收条件第 4 条仍为 [ ]「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」；docs/contributing.md:100-101、:180。
Problem: 冻结文本要求每个保留提交都有 300 题结论，控制器却把精度改成配对性能通过后的后续步骤；保留、性能回归的判定口径与 G 轮被取消的 298 条轨迹如何处置仍未记录。rotary 与 ordinal 是功能性算子改动，本轮同样没有精度或 L3 结论。
Impact: 可能出现性能改善却从未产出 300 题结论的候选进入下一轮；现有 294/300 距门槛仅 2 题余量。
Fix: 由 owner 在正文与 plan/ 二选一：(a) 正式确认先性能后精度的顺序并写明可跳过范围、最终版本独立重测与取消轨迹处置；(b) 恢复每个保留提交即测 300 题。

F3 — high，must-fix，隐私 — 11:15:56 的历史任务记录评论仍未脱敏（上轮 open）

Where: 评论 6602376192（created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑）；docs/privacy-security.md:10-13、AGENTS.md:119-125。
本次核实: 仍含 10.30.13.138 1 处、10.30.12.215 1 处、Pod 全名 itask-jcz-… 1 处、/a3_inference/… 2 处、/Users/jiangchenzhou/… 37 处、用户名 jcz02615514 5 处。本轮评论与正文只用清单摘要与相对描述，未新增泄漏。
Impact: 个人路径与内部拓扑持续公开；该记录若被当作证据导入 evidence/ 会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F17 — medium，must-fix，需 owner 决定 — 同一评论出现两套新用例计数，仍无期望清单与逐项对应（上轮 open）

Where: 触发评论「7 unit tests, 8 A3 system tests and all three required dispatch signatures」「6 unit tests, 4 A3 system tests and all four dispatch geometries」；历史计数 9/16 → 37/7 → 24/3 → 13/29 → 51/3；docs/contributing.md:103-106。
Problem: 同时新增 7/8 与 6/4 两套组合（第 6、7 套），都没有期望用例清单、冻结时点或逐项对应；rotary 要求 three dispatch signatures、ordinal 要求 four dispatch geometries，数量差异也未说明。
Impact: 无法证明新增算子路径受到与上一候选同等的保护，也无法判断两套计数是否覆盖同一功能面；这正是 F24/F28 所缺证据中最直接的一项。
Fix: 冻结每轮期望用例清单与计数规则，给出各次计数的逐项对应表，并说明 3 与 4 个 dispatch 签名的定义与来源。

F8 — medium，must-fix，需 owner 决定 — Decision needed 仍不可判定，本轮新增的保留规则与指标口径也没有记为待决（上轮 open）

Where: 正文 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛…、**Next action:** 现有负责人 … 继续在原线程记录…本次同步不授权新增运行；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> 与 <who does what next>；.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]。
Problem: 该行仍不是问题也没有决策人。本轮至少新增三项待决：保留规则能否用 wave 指标（F28）、slot-reuse 父臂是否可继续使用（F24）、两套新用例计数如何冻结（F17）；加上既有阈值（F19）、FC1（F5）、精度顺序（F9）。同时 Next action 只授权记录结果，而正文说还需两对校准，campaign 实际停摆却未记为决策。
Impact: 读者与后续评审无法区分已定与未定，也无法判断正式配对何时能开始。
Fix: 把待决项逐条改写为「问题 + owner」，Next action 写明谁在何时补 slot 复用正确性证据、谁负责剩余两对校准与保留规则。

F22 — medium，must-fix — 三行块再次落后，且正文仍写「全模型 TPOT 尚待验证」（上轮曾 fixed，本轮回退）

Where: 正文 **Current state:** 仍为「截至 2026-11-03 21:01 UTC」并只链接 20:47 评论，同时写「全模型 TPOT 尚待验证」；触发评论（21:15）已给出 rotary/ordinal 全模型六档 TPOT、C16 分解与 18-site 写缓存探针；docs/agent-collaboration.md:213-218 要求执行方保持三行块最新。
Problem: 状态块没有反映当前唯一的新结果，且「尚待验证」与触发评论直接冲突；下一轮父臂已由该评论选定，Issue 顶部却看不出来。
Impact: 从 Issue 顶部判断进展会漏掉本轮两项候选、保留决定与它们的证据缺口。
Fix: 把 rotary/ordinal 六档读数、C16 异常与保留决定、写缓存探针、精度未跑写入状态块，并在 Next action 写明谁补哪项证据。

F26 — medium，suggestion — eight-index-producer 仍无定义，新增 18-site 写缓存探针也没有路径、每步换算与内存预算（上轮 open）

Where: 触发评论「A separate A3 cache-write probe retained the original shape-specific ScatterUpdate kernel at each of 18 sites and removed 18 pairs of full-table copies … 16.79→1.34 / 16.92→1.81 ms … allocation peak increased by about 16 MiB, with 17 KiB extra retained. This remains a single-device subgraph result.」；此前的 eight-index-producer 结果仍无定义；正文验收条件第 3 条。
Problem: 未说明 18 个 site 是哪些算子、每 decode step 调用几次、「eighteen-write graph」是一次还是整轮、与 25 ms 门槛的换算；+16 MiB 分配峰值未按 16 rank × 每 DP 8 序列评估；也没有归档路径或摘要。
Impact: 该探针若用于选择下一轮源，既不可复核也无法判断内存代价是否可接受。
Fix: 给出 site 定义与每步调用次数、单位换算、内存峰值口径与归档路径/摘要，并说明与 eight-index-producer 结果的关系。

F4 / F6 / F7 / F11 / F12 / F13 / F15 / F20 / F21 — 早前项本轮仍未回应（保持 open）

Where: 评论 6602376192（另一 RunSpec：TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）、AISBench Gsm8kEvaluator 无 revision、per-graph/per-step/per-token 换算表与两次基线（9.13 ms 与 46.65 ms）、single-pass E4M3 QDQ 未定义、eager 回退 21,901/25,600 元素分歧、观察器身份与新环境签名。
Problem: 本轮触发评论没有回应其中任何一项，也未在正文或 plan/ 记录处置结论；slot-reuse 的数值等价性问题（F13）仍并入 F24。
Impact: 下游引用与 PASS 判定仍缺少可复算的判分工具、单位换算与数值等价性依据。
Fix: 按各项原建议逐条回应，或在正文/plan/ 记录处置结论。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

意图：继续维护 dsv41-910c-decode-tpot25 验收，本次编辑把 21:15 的 rotary/ordinal 探索性 sweep、C16 异常与 ScatterUpdate 探针写入三行状态块，结论仍为 INCONCLUSIVE。结论：needs information / human decision required——编辑只刷新了状态块，正文的指标口径、开关归属、门槛与证据缺口均未处置，且正文没有请求代码改动的句子，不构成开发授权，未发现引导自动评审的文本。F22：fixed——状态块已更新到 21:30 并纳入本轮两项结果；F28 部分回应（正文已称"不是正式性能验收"）但仍 open；F1/F2/F3/F5/F8/F9/F17/F19/F24/F26/F27 等保持 open，见下。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 按 .github/labels.json 须配合 status 标签而本 Issue 无 status 标签。

F28 — high，must-fix，测量/需 owner 决定 — 新编辑把「预设选父规则」写进正文，但仍用整波 TPOT 决定下一轮源，冻结指标是逐请求均值

Where: 正文第 1 段「Ordinal 在 C16 整波 TPOT 回退 3.02%；计时分解定位到首 token 到齐区间差异，但不证明设备原因，因此作者按其预设选父规则保留 rotary 作为下一轮源」；验收条件第 1 条 (E2E − TTFT) / (实际输出 tokens − 1) 均值与第 3 条；评论 6615622965 的分解 0.88 vs 4.02 与 52.14 vs 50.81；docs/contributing.md:98-102。
Problem: (a) 冻结指标排除 TTFT，而正文自述 C16 差异落在「首 token 到齐」区间；同一分解中 ordinal 的公共输出区间是 50.81 对 rotary 52.14，按冻结指标 ordinal 在 C16 很可能并不落后。(b) 两臂仍无六档逐请求均值与同臂噪声底。(c) 「预设选父规则」仍只出现在评论与本段叙述里，正文和 plan/ 都没有登记该规则、阈值与预设受益档，违反正文第 3 条的先冻结要求。(d) 分解不闭合：0.88 + 52.14 = 53.02 对 57.571，4.02 + 50.81 = 54.83 对 59.311，两臂各约 4.5 ms/token 未解释。
Impact: 下一轮全模型改动会从 rotary 出发；若按冻结指标 ordinal 更优，正式配对将以更慢的实现为父臂。
Fix: 给出两臂六档逐请求 (E2E−TTFT)/(tokens−1) 均值与噪声底并用冻结指标重做保留判定；在正文与 plan/ 预先登记保留规则后再用于选源；若要改用 wave 指标，须由 owner 改写第 1 条并说明与 25 ms 门槛的关系。

F5 — high，must-fix，配置/需 owner 决定 — 正文开关要求与冻结表仍相反，本轮头条数字也没写 FC1、enable_fused_mc2、环境签名

Where: 正文「## 当前开关要求」（显式开 FlashComm1、additional_config.enable_fused_mc2=0）对「## 初始修订与基线运行配置」表「Ascend 开关 | DSA CP 开、显式 FlashComm1 关、shared expert DP 开」；正文第 1 段引用的评论 6615622965 只写「DP4/TP4/EP16, DSpark-5, FULL_DECODE_ONLY」；评论 6613949877 写明父臂 FC1 显式开启、fused_mc2=0；docs/contributing.md:98-101。
Problem: 冻结表与当前要求给出互斥取值，读者无法判断 1.000%–2.526% 属于哪套配置；新的 rotary/ordinal 读数没有 FC1、enable_fused_mc2、环境签名与服务实例，直接违反正文自己新增的标注要求，也无法证明与 slot-reuse 父臂同配置。
Impact: 49.580–70.858 无法归属到任何 RunSpec，既不能与 FC1-关的封存基线（93.862–129.043）比较，也不能与 25 ms 门槛比较。
Fix: 由 owner（.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]）把冻结表开关行改成实际生效值并固定唯一门槛公式与生效时点；此后每轮必须写 FC1、enable_fused_mc2、环境签名与服务实例。

F19 — high，must-fix，门槛/需 owner 决定 — 正文一边说校准后续两组未完成，一边把 1.000%–2.526% 当第 3 条唯一门槛

Where: 正文第 1 段「校准后续两组/封存、配置门槛关系……仍未完成」；验收条件第 2 条仍为 [x]；验收条件第 3 条「该档门槛」与「## 已封存基线」表（1.000%–2.526%）；评论 6615050799「Two further calibration pairs are required before setting the per-tier variability thresholds」；AGENTS.md:64。
Problem: 20:47 的 fresh 校准明确说还需两对才能设定逐档阈值，正文却继续把旧两组算出的阈值当唯一判读基准，且没有记录旧两组是否作废、第 2 条是否退回 [ ]、新三对如何生效；本次编辑新增的「配置门槛关系」仍未完成也没写成待决项。
Impact: 下一轮保留/淘汰与最终 PASS 都失去可追溯的判读基准，plan/ 冻结值与正文未定型的表冲突。
Fix: 由 owner 明确旧两组封存是否作废、第 2 条状态、新三对校准的公式与生效时点，并把逐档活跃 DP 数、FULL 回放条数与完整性标志写入正文与 plan/。

F24 — high，must-fix，正确性/需 owner 决定 — 下一轮父臂仍是 slot-reuse，C≥2 别名安全证据仍无，本轮两个新候选都建在它上面

Where: 正文第 1 段保留「[slot-reuse 六档记录]」作为轮次底稿；评论 6613949877「At concurrency 32, the two services matched on 0 of 32 complete output hashes」；评论 6612233089 同一父服务自比在 C32 也是 0/32；评论 6615622965 的三源 sweep 未给 C≥2 逐 token 对照；docs/contributing.md:103-106。
Problem: 复用改变 decode 实际读取的物理 KV 位置，正确性取决于「被复用 slot 仍被在途序列引用时不得被覆写」；唯一的多序列等价性指标在父臂自比时即为 0/32，已无判别力，C1 哈希只覆盖单序列，16 rank refresh/reuse pattern 是插桩计数而非别名安全证明。
Impact: 若复用落在仍被引用的 slot 上，输出会无报错地被污染，并同时出现在 rotary 与 ordinal 两个新候选的对照里，使跨臂差值失真。
Fix: 写明复用不变量（可复用条件、引用计数/失效规则），补专门验证别名安全的 C≥2 测试（每序列与不复用臂逐 token 对照并给同臂噪声底）；证据与冻结 300 题齐备前不把复用臂当作父臂或保留。

F1 — high，must-fix，可复现性 — 仍只有工作树清单摘要，没有可检出提交

Where: 正文表「候选 Git SHA | 待正式验收后提交」；评论 6615622965 的 10b66820…、f4c27656…、cee63495…；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33（candidate_sha 必填 Full git SHA）；AGENTS.md:87。
Problem: 三个 64 位值都是文件清单/审计 SHA-256，无法从任何提交重算，也表达不出第 3 条要求的直接父版本；评论没有给出各自提交/分支与父 SHA，18-site 写缓存探针连清单摘要都没有。
Impact: 49.580–70.858 的读数与 7/8、6/4 用例回执无法在具名修订上复跑，后续 300 题与正式六档无法绑定，PASS 前提不成立。
Fix: 在任何保留/下一轮父臂判定前，把 rotary、ordinal 与写缓存探针落成 codex/dsv41-0day 上的真实提交，逐轮记录候选 SHA 与父 SHA；清单摘要保留作交叉校验。

F2 — high，must-fix，证据 — 仓库内仍无本 campaign 证据，本轮所有新数字只在评论里（本次实测复核）

Where: 正文「## 证据索引」只列相对实验归档根目录的 perf25/…；本轮 10b66820…、f4c27656…、cee63495… 与写缓存探针结果均无路径；AGENTS.md:87-89、docs/contributing.md:114-121。
本次实测（检出 663f3b3）: python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；ls evidence 无 dsv41*；grep -ril "dsv41\|perf25\|tpot25" --include=*.json --include=*.md --include=*.py . 无命中。
Impact: 决定下一轮父臂的读数、六档逐项值与配对回执无法复核，也无法按正文要求被下游引用；单值摘要不能定位原始波与失败/回滚记录。
Fix: 登记 evidence/dsv41-910c-decode-tpot25/（plan/、results/、patch/、validator/），原始波按 tools/evidence_inventory.json 既有 external 先例说明，导入前做脱敏复查。

F9 — high，must-fix，门禁顺序/需 owner 决定 — 两个功能性算子候选再次跳过 GSM8K-300

Where: 正文第 1 段「仅单次探索性 sweep，未运行 GSM8K-300」；验收条件第 4 条仍为 [ ]（每个保留提交至少 292/300）；评论 6613949877「The acceptance workflow skips accuracy on a performance regression」；docs/contributing.md:100-101、:183-184。
Problem: 冻结文本要求每个保留提交都有 300 题结论，实际做法把精度改成配对性能通过后的后续步骤，但该顺序没有任何 owner 记录；rotary 与 ordinal 是功能性算子改动，本轮同样没有精度或 L3 结论；基线 295/300 距 292 门槛仅 3 题余量。
Impact: 可能出现性能改善却从未产出 300 题结论的候选进入下一轮，最终 PASS 的精度证据链断裂。
Fix: 由 owner 在正文与 plan/ 二选一并写明可跳过范围、最终版本独立重测与取消轨迹处置：(a) 正式确认先性能后精度的顺序；(b) 恢复每个保留提交即测 300 题。

F3 — high，must-fix，隐私 — 11:15:56 的历史任务记录评论仍未脱敏（本次核实）

Where: 评论 6602376192（created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑）；docs/privacy-security.md:8-14、AGENTS.md:119-125。
本次核实: 仍含 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-…、/a3_inference/…、/Users/jiangchenzhou/… 多份、用户名 jcz02615514；本次编辑与 21:15 评论只用清单摘要与相对描述，未新增泄漏。
Impact: 个人路径与内部拓扑持续公开；该记录若被当作证据导入 evidence/ 会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F8 — medium，must-fix，协作/需 owner 决定 — Decision needed 仍不可判定，本轮新增的选源决定也没记进去

Where: 正文 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛…、**Next action:** 现有负责人 @jiangkuaixue123 继续在原线程记录…本次同步不授权新增运行；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> 与 <who does what next>；.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]。
Problem: 该行仍不是问题也没有决策人；本轮编辑反而新增一项未登记的保留决定（用 wave 指标/「预设规则」保留 rotary，见 F28），加上 slot-reuse 父臂（F24）、两套新用例计数（F17）、阈值（F19）、FC1（F5）、精度顺序（F9）。Next action 只授权记录结果，campaign 实际停在选源上却未记为决策。
Impact: 读者与后续评审无法区分已定与未定，也无法判断正式配对何时能开始。
Fix: 把待决项逐条改写为「问题 + owner」，Next action 写明谁在何时补 slot 复用正确性证据、谁负责剩余校准、选源规则与精度顺序。

F17 — medium，must-fix，测试账目/需 owner 决定 — 两套新用例计数仍无期望清单与逐项对应

Where: 正文第 1 段「Rotary 7 UT / 8 A3 ST、ordinal 6 UT / 4 A3 ST 及对应 16-rank dispatch 检查」；评论 6615622965「all three required dispatch signatures」/「all four dispatch geometries」；历史计数 9/16 → 37/7 → 24/3 → 13/29 → 51/3；docs/contributing.md:103-106。
Problem: 两套新组合都没有期望用例清单、冻结时点与逐项对应；rotary 要求 three dispatch signatures、ordinal 要求 four dispatch geometries，数量差异也未说明。
Impact: 无法证明新增算子路径受到与上一候选同等的保护，也无法判断两套计数是否覆盖同一功能面。
Fix: 冻结每轮期望用例清单与计数规则，给出各次计数的逐项对应表，并说明 3 与 4 个 dispatch 签名的定义与来源。

F26 — medium，suggestion — 18-site 写缓存探针仍无 site 定义、单位换算与归档路径

Where: 正文第 1 段「十八次写图为 16.79→1.34 / 16.92→1.81 ms，同时分配峰值约增 16 MiB」；评论 6615622965「retained the original shape-specific ScatterUpdate kernel at each of 18 sites」；正文验收条件第 3 条。
Problem: 未说明 18 个 site 是哪些算子、每 decode step 调用几次、「eighteen-write graph」是一次还是整轮、与 25 ms 门槛的换算；+16 MiB 分配峰值未按 16 rank × 每 DP 8 序列评估；也没有归档路径或摘要。
Impact: 该探针若用于选择下一轮源，既不可复核也无法判断内存代价是否可接受。
Fix: 给出 site 定义与每步调用次数、单位换算、内存峰值口径与归档路径/摘要，并说明与此前 eight-index-producer 结果的关系。

F27 及 F4/F6/F7/F11/F12/F13/F15/F20/F21 — 早前项本轮仍未回应（保持 open）

Where: 评论 6615622965 表首列 53.437 / 52.893 / 54.948 / 56.160 / 58.495 / 73.246 与评论 6613949877「With slot reuse」列逐位相同，而 19:52 的两个服务已回收（F27）；评论 6602376192 的另一 RunSpec（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）；AISBench Gsm8kEvaluator 无 revision；per-graph/per-step/per-token 换算表与两次基线（9.13 ms 与 46.65 ms）；single-pass E4M3 QDQ 未定义；eager 回退 21,901/25,600 元素分歧；观察器身份与新环境签名。
Problem: 本轮编辑只刷新状态块，未回应其中任何一项；正文把该表相关结果提为头条，却没有标注父臂列来自 19:52 会话、差值不可用于选父臂。
Impact: 下游引用与 PASS 判定仍缺少可复算的判分工具、单位换算与数值等价性依据；跨会话相减仍被当作选源依据。
Fix: 按各项原建议逐条回应或在正文/plan/ 记录处置结论；F27 须在同一会话内三臂交替重测六档，或在表中标注父臂列来源并把差值降级为探索性、不用于选择父臂。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

Stock cache scatter on the partial RoPE candidate

On the same 16-rank NPU host, the plain client ran a separate warmup and one 1,024-in / 1,024-out measured wave at each concurrency. Both arms used TP4 / DP4 / EP16, DSpark-5, FULL_DECODE_ONLY, explicit FlashComm1 and fused MC2 disabled.

Concurrency	Partial RoPE parent	+ stock cache scatter	Observed reduction
1	51.183	46.814	8.54%
2	50.155	46.225	7.84%
4	51.980	47.442	8.73%
8	54.544	49.979	8.37%
16	57.571	50.986	11.44%
32	70.858	62.891	11.24%

Units are client ms/token. All six exploratory tiers improved. Seven unit tests and four A3 system tests passed. Capture on every rank showed all 18 expected cache writes in each of the 24- and 48-row buckets. The preregistered rule selected this build as the parent for the batched draft attention screen. Source manifest cd0d8f731c83f02e871b0880b356ae1dbcca218c97960165d5c263951ef096b0. No quality result or signed optimization commit is claimed for this screen.

The second original-source A/A calibration pair also completed under the fixed in-window observation protocol. Absolute paired differences at C1/2/4/8/16/32 were 0.041/0.436/0.352/0.272/4.349/0.119%. At C16 the spread between the first output arrivals was 5.692 s in the first arm and 0.004 s in the second. A third pair is required to determine the noise thresholds.

In a separate private DSpark three-layer diagnostic, the median slowest-rank stream times were 24.170 ms for batched eager and 11.016 ms for staged replay. A repeated eager reference changed hidden values on one balanced-layout request. Replay differed from eager in four proposal positions on another balanced request and two on a mixed-layout request. The private replay remains unscored, with no production substitution or accuracy run. Its startup diagnostics completed before the child service was ready, so it was reaped with a failed service receipt. The outer controller restored the verified source and stock runtime.

TPOT screen receipts 16b160cc6afc088ec56beb9c6a99247fff02f081a35729f446de4d8bfd0c0257, b082aea2c2eba1463099e0e922a2ee17b14d900e611df648c361f9b6364e5b3e. Restored scatter owner 01909f65d04251d5d12b33a7feb5c4e9bb4f97115326815753006890b8f29d45.

意图：继续维护 dsv41-910c-decode-tpot25 验收（六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300），22:27 的评论新增 partial RoPE 上的 stock cache scatter 六档探索性屏、A/A 校准第 2 对与私有 DSpark 三层诊断。结论维持 needs information / human decision required、整体 INCONCLUSIVE：新屏父臂列与 21:15 会话逐位相同（跨会话相减），新 A/A 对的 C16 4.349% 噪声使「按哪套门槛」直接决定 ordinal 的保留结论，DSpark 诊断的时间数来自 service receipt 失败且参考臂不可复现的运行。正文没有任何请求修改代码的句子，不构成开发授权；未发现引导自动评审的文本，本轮评论也未新增敏感信息泄漏（历史评论 6602376192 的泄漏仍在，见 F3）。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 按 .github/labels.json 须配合 status 标签而本 Issue 无 status 标签。

F29 — high — 新表父臂列与 21:15 会话逐位相同，8.4–11.4% 仍是跨会话相减（F27 复发）

Where: 22:27 评论「Stock cache scatter on the partial RoPE candidate」表的 Partial RoPE parent 列 51.183 / 50.155 / 51.980 / 54.544 / 57.571 / 70.858；评论 6615622965 的「+ stock partial RoPE」列六值逐位相同，而该评论同时写明「All owners were released」；docs/contributing.md:100-106。
Problem: 评论自述两臂「ran a separate warmup and one 1,024-in / 1,024-out measured wave at each concurrency」，但父臂六档与已回收的 21:15 会话小数后三位全同；服务重建后的独立测量不可能六档全部重合，因此父臂列只能复用 21:15 的读数。于是 8.54 / 7.84 / 8.73 / 8.37 / 11.44 / 11.24% 是跨会话相减，每档只有一次测量波，没有配对计数与同臂噪声底。
Impact: 该 build 被判为 batched draft attention 屏的父臂，选源依据不是同会话交替配对，正是验收条件第 3 条要排除的漂移来源（第 2 条新 A/A 对在 C16 已达 4.349%，见 F30）。
Fix: 在同一会话内两臂交替重测六档，给出逐档配对计数与同臂重复噪声底；若确实沿用 21:15 读数，就在表下标注父臂列来源，并把差值降级为探索性、不用于选源。

F30 — high — 新 A/A 第 2 对把 C16 噪声量化为 4.349%，是封存 C16 门槛的 3.2 倍，也大于用来淘汰 ordinal 的 3.02%（需 owner 决定）

Where: 22:27 评论「Absolute paired differences at C1/2/4/8/16/32 were 0.041/0.436/0.352/0.272/4.349/0.119%. At C16 the spread between the first output arrivals was 5.692 s in the first arm and 0.004 s in the second. A third pair is required…」；正文验收条件第 2 条（[x]，门槛 max(1%, 两组内以先测轮为分母的绝对相对差最大值)）与「## 已封存基线」表 C16 = 1.353%；正文第 1 段以「Ordinal 在 C16 整波 TPOT 回退 3.02%」作为保留 rotary 的依据；.github/knowledge-model-policy.json:50（approval_owners: ["Dong1017"]）。
Problem: 按第 2 条自己的公式，把这对 A/A 数据用于校准时 C16 门槛为 max(1%, 4.349%) = 4.349%，ordinal 的 3.02% 落在门槛内、不构成回退；按封存的 1.353% 则构成回退。同一份数据因门槛来源不同得出相反的选父结论，而门槛来源正是 F19/F5 未决项。另外首 token 到齐跨度 5.692 s 对 0.004 s 说明 C16 仍被启动/调度瞬态支配，再补一对校准不会消掉这一档的系统性展宽。
Impact: 下一轮父臂与将来 PASS 的判读基准取决于尚未决定的阈值口径，plan/ 冻结值也无法与正文口径对齐。
Fix: 由 owner 先固定唯一公式、适用配置与生效时点，并先修 C16 观察协议（按正文第 1 条冻结指标逐请求 (E2E − TTFT)/(实际输出 tokens − 1) 计，或明确排除首 token 到齐区间），再用它重做 ordinal/rotary 的保留判定。

F33 — medium — 新屏对 KV 写路径只有「18 次写」计数，没有全模型取值/输出等价与 C≥2 对照

Where: 22:27 评论「Capture on every rank showed all 18 expected cache writes in each of the 24- and 48-row buckets.」与「No quality result or signed optimization commit is claimed for this screen.」；正文验收条件第 4 条（每个保留提交及最终版本 ≥292/300）；docs/contributing.md:103-107。
Problem: 该改动改的是 cache 写入方式。全模型侧只证明 18 处写在每个 bucket 都执行了，没有证明写入内容与目标 slot 与父臂一致，也没有 C≥2 的逐序列输出对照；此前的 backing-bytes 相等是单设备子图级结果（评论 6615622965 自述）。
Impact: 写错 slot 或写错值可以在不报错的情况下改变输出，而计数检查不会发现；该 build 已被定为下一屏父臂。
Fix: 补同父臂、同配置下 C≥2 的逐序列输出对照（含同臂重复噪声底）与 cache 内容摘要比对，并按第 4 条跑冻结 300 题后再用于选源。

F31 — medium — 私有 DSpark 诊断的时间数来自 service receipt 失败、且参考臂不可复现的一次运行

Where: 22:27 评论「the median slowest-rank stream times were 24.170 ms for batched eager and 11.016 ms for staged replay. A repeated eager reference changed hidden values on one balanced-layout request. … Its startup diagnostics completed before the child service was ready, so it was reaped with a failed service receipt.」
Problem: (a) 重复的 eager 参考自身改变了 hidden 值，说明参考臂没有确定的噪声底，因此「Replay differed from eager in four proposal positions / two on a mixed-layout request」不能归因到 replay；(b) 子服务未就绪、receipt 记为失败，却仍把该次运行的 24.170 / 11.016 ms 当作结果写出，没有说明这两条时间取自哪一段可信区间。诊断自述 unscored、无替代、无精度，这点表述正确。
Impact: 2.2× 的 stream 时间差与 4/2 处 proposal 差异都不可判读；若后续据此选择 staged replay，会继承同一不确定性（与 open 的 F20 eager 不可复现同源）。
Fix: 先做多次 eager 重复给确定性与同臂噪声底，再逐 proposal position 归因差异；把 failed service receipt 明确记为失败运行，只引用其中确实完成的诊断读数并写明口径。

F32 — medium — 第二次用「preregistered rule」选父臂，规则与新屏均未登记（F28 复发，需 owner 决定）

Where: 22:27 评论「The preregistered rule selected this build as the parent for the batched draft attention screen.」；正文第 1 段「作者按其预设选父规则保留 rotary」；正文与 plan/ 中仍无该规则的文本、阈值或预设受益档；正文验收条件第 3 条。
Problem: 规则内容（阈值、预设受益档、并列如何处置）仍未在测量前登记；「batched draft attention screen」又是新出现的筛查线，没有假设、目标档或判据，与 F28 的问题同源。
Impact: 选源决定无法按第 3 条复核，「保留」的含义继续漂移，下一轮的父臂链条也无法追。
Fix: 把规则文本与 batched draft attention 屏的假设、预设受益档、判据写入正文与 plan/ 后再测量；需要改规则时先改文本。

F1 / F2 / F3 / F5 / F8 / F9 / F17 / F19 / F22 / F24 / F26 / F27 / F28 — 早前项本轮状态（逐条核实）

F27（high）： open 且复发，见 F29。
F19（high，需 owner）： open——正文第 2 条仍 [x]、「已封存基线」C16 仍为 1.353%，而本轮 A/A 对给出 4.349%，见 F30。
F5（high，需 owner）： 部分回应——本轮 TPOT 屏首次写明「explicit FlashComm1 and fused MC2 disabled」，满足正文自己的标注要求；但「## 初始修订与基线运行配置」表仍写「显式 FlashComm1 关」，本轮仍无环境签名与服务实例，唯一公式与生效时点未定，保持 open。
F1（high）： open——cd0d8f731c83…、01909f65d042… 仍是 64 位清单/工作树摘要，没有提交与父 SHA；正文「候选 Git SHA」仍为「待正式验收后提交」。
F2（high）： open，本次实测复核——python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；evidence/ 下无 dsv41/perf25/tpot25 目录，grep -ril "dsv41\|perf25\|tpot25\|910c-decode" 在 json/md/py 中无命中；本轮 16b160cc…、b082aea2… 两个回执没有路径。
F3（high）： open，本次核实——评论 6602376192 仍 created_at = updated_at = 2026-11-03T11:15:56Z，仍含 10.30.13.138 / 10.30.12.215 各 1、/Users/jiangchenzhou 37、jcz02615514 5、/a3_inference 2、itask-jcz 1；本轮评论未见新增泄漏（0 命中），这点正确。
F24（high，需 owner）： open——本轮父臂链（partial RoPE ← slot-reuse 臂）仍未提供 C≥2 别名安全证据。
F9（high，需 owner）： open——本轮仍「No quality result」，300 题序列未推进。
F17（medium，需 owner）： open——又出现第 8 套计数「Seven unit tests and four A3 system tests」，仍无期望用例清单与逐项对应。
F22（medium）： open——三行块仍停在 21:30 UTC，22:27 评论的 scatter 表、A/A 第 2 对与 DSpark 诊断均未写入。
F8（medium，需 owner）： open——Decision needed 仍不是问题也没有决策人；本轮新增待决项：C16 门槛来源（F30）与选父规则（F32）。
F26（medium）： 部分回应——本轮给出全模型六档 TPOT，回答了「如何换算到 ms/token」的一半；18 处 site 定义、每 decode step 调用次数与 +16 MiB 峰值在 16 rank × 每 DP 8 序列下的预算仍缺。
F28（high，需 owner）： open，见 F32。
F4 / F6 / F7 / F11 / F12 / F13 / F15 / F20 / F21： 本轮未回应，保持 open。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

意图：继续以 dsv41-910c-decode-tpot25 验收跟踪 DeepSeek V4.1 Flash 在 910C 上六档 decode TPOT ≤25 ms/token 与固定 GSM8K ≥292/300；本次正文编辑把 22:27 的 stock cache scatter 单波筛选、fresh A/A 第 2 组与私有 DSpark 诊断写入三行状态块，读数与评论 6617042949 逐项相符（我复算六档降幅为 8.54/7.84/8.73/8.37/11.44/11.24%，自洽），结论仍为 INCONCLUSIVE。结论：needs information / human decision required——新数据同时暴露两处判读硬冲突（C16 fresh A/A 4.349% 已超过正文冻结的 1.353%，也超过被用来淘汰 ordinal 的 3.02%；scatter 父臂列与 21:15 的 rotary 列逐位相同），既有待决项一条未处置；正文没有请求代码改动的句子，不构成开发授权，未发现引导自动评审的文本或新增脱敏泄漏。F29、F30 为新发现；F1/F2/F3/F5/F8/F9/F17/F19/F24/F26/F27/F28 仍 open（本轮编辑只刷新状态块）；F4/F6/F7/F11/F12/F13/F15/F20/F21 未见回应。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status 标签，而本 Issue 无 status 标签。

F29 — high，must-fix（需 owner 决定）— fresh 同源 A/A 的 C16 4.349% 已超过正文冻结的 1.353%，也超过被用来淘汰 ordinal 的 3.02%

Where: 正文第 1 段「fresh 原始源码 A/A 第 2 组已完成，C16 绝对差 4.349%，两臂首 token 到齐跨度为 5.692 / 0.004 s；……尚未封存，不能替换下方既有初始校准门槛」；正文第 2 条 [x] 与「## 已封存基线」C16 门槛 1.353%；评论 6617042949 的 0.041/0.436/0.352/0.272/4.349/0.119%；正文保留的前轮 rotary/ordinal 表 C16 为 −3.02%。
Problem: 同一原始源码的 C16 差值是冻结门槛约 3.2 倍，也大于当时判 ordinal 在 C16 回退、据此保留 rotary 的 3.02%；正文一边说第 3 组才定阈值、第 2 组不能替换旧门槛，一边仍用旧表作第 3 条唯一判据，未说明定型前 C16 按什么判。两臂首 token 到齐 5.692 s 对 0.004 s 的极端不对称也说明该对 C16 不宜直接当噪声底。
Impact: 若 3.02% 落在同源噪声内，rotary 相对 ordinal 的 C16 优势不成立；而 rotary 正是本轮 scatter 的父版本，下一 screen 也建在其上，C16 判读缺少有效门槛。
Ask: owner（.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]）明确旧 C16 门槛是否生效、第 3 组如何定型、定型前 C16 的保留/淘汰规则，并写进正文与 plan/。

F27 — high，must-fix（测量口径，上轮 open，本轮同缺陷新实例）— scatter 父臂列与 21:15 的 rotary 列逐位相同，8.54%–11.44% 很可能是跨会话相减

Where: 正文第 1 段「在 partial RoPE 父版本上，C1/2/4/8/16/32 为 46.814 / 46.225 / 47.442 / 49.979 / 50.986 / 62.891 …较直接父版本改善 8.54 / 7.84 / 8.73 / 8.37 / 11.44 / 11.24%」；评论 6617042949 的父臂列 51.183 / 50.155 / 51.980 / 54.544 / 57.571 / 70.858；评论 6615622965「+ stock partial RoPE」列逐位相同；该轮已「All owners were released」；验收条件第 1、3 条。
Problem: 六档父臂读数与上一会话小数点后三位全部相同，服务重建后的计时不可能六档全部重合，故父臂列复用了 21:15 的历史读数，「one measured wave」只覆盖候选臂；8.54%–11.44% 是跨会话差值，既非同会话配对，也无同臂噪声底。
Impact: 「scatter build 已优于父版本、选作下一 screen 父版本」这一决定，建立在第 3 条明确要排除的漂移来源上。
Fix: 明确父臂列是本轮重测还是引用；若引用，表中标注来源并把差值降级为探索性、不用于选父臂，或补一次同会话 parent→scatter 配对（每档至少一波）。

F28 — high，must-fix（需 owner 决定，上轮 open）— 「预设选父规则」仍未登记，选父仍基于单波筛选

Where: 正文第 1 段「作者按其预设选父规则选作 batched draft attention screen 的父版本，不是正式验收」；验收条件第 3 条（记录单一假设、预设受益档、直接父版本与完整六档交替配对；单轮筛选单列）；评论 6617042949「The preregistered rule selected this build as the parent」；AGENTS.md:64。
Problem: 该规则仍只出现在评论与本段叙述里，正文与 plan/ 没有阈值、预设受益档与冻结时点；选父依据是每档单次测量波，评论只写「client ms/token」，未说明是否用第 1 条 (E2E−TTFT)/(实际输出 tokens−1) 逐请求均值。上一轮 F28 的整波/逐请求口径问题在新一轮选父中沿用。
Impact: 下一轮 batched draft attention screen 已固定在单波筛出的父版本；若正式配对反转或改用冻结指标，下游工作要重做。
Fix: 在正文/plan/ 预先登记选父规则与阈值、冻结时点与所用指标；单波结果按第 3 条标注为「单轮筛选，不用于保留」。

F5 — high，must-fix（需 owner 决定，上轮 open）— 冻结表与「当前开关要求」对 FlashComm1 仍互斥，本轮头条段未按正文要求标注开关与环境签名

Where: 正文「## 当前开关要求」（显式开 FlashComm1、additional_config.enable_fused_mc2=0，并要求新增测量标注两项）对「## 初始修订与基线运行配置」表「Ascend 开关 | DSA CP 开、显式 FlashComm1 关、shared expert DP 开」；正文第 1 段三段新结果未写 FC1、enable_fused_mc2、环境签名；评论 6617042949 写明 FC1 开与 fused MC2 关但无环境签名。
Problem: 两处取值相反，读者无法判断 1.000%–2.526% 属于哪套配置；正文摘要把 scatter、A/A 与 DSpark 并入首段却不写这两项与环境签名，违反正文自己的标注要求。
Impact: 46.814–62.891 与 FC1-关封存基线（93.862–129.043）无法判定同配置可比，也无法与 25 ms 门槛绑定同一 RunSpec。
Fix: owner 把冻结表开关行改为实际生效值或标注为历史配置，并给每轮新增测量统一标注 FC1/fused_mc2/环境签名/服务实例。

F19 — high，must-fix（需 owner 决定，上轮 open，本轮有数值反证）— 第 2 条仍 [x]，而 fresh 同源 A/A 已突破封存 C16 门槛

Where: 正文第 1 段「校准后续两组/封存、配置门槛关系……仍未完成」「不能替换下方既有初始校准门槛」；验收条件第 2 条仍 [x]（两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)）、第 3 条「该档门槛」与「## 已封存基线」1.000%–2.526%；评论 6615050799「Two further calibration pairs are required before setting the per-tier variability thresholds」；评论 6617042949 的 C16 4.349%。
Problem: 旧两组阈值仍被当作唯一判据，而 fresh 同源 A/A 按第 2 条同一公式会把 C16 门槛抬到 ≥4.349%；旧两组是否作废、第 2 条是否退回 [ ]、新三对如何生效均无记录。
Impact: 后续保留/淘汰与最终 PASS 失去可追溯判读基准，plan/ 冻结值与正文未定型的表冲突。
Fix: owner 明确旧两组封存是否作废、第 2 条状态、新三对校准公式与生效时点，并把逐档活跃 DP 数、FULL 回放条数与完整性标志写入正文与 plan/。

F1 — high，must-fix（可复现性，上轮 open）— 候选/父版本仍无可以检出的提交，本轮又新增四个摘要

Where: 正文表「候选 Git SHA | 待正式验收后提交」；正文第 1 段与评论 6617042949 的 cd0d8f731c83…（工作树清单）、16b160cc…/b082aea2…（TPOT screen 回执）、01909f65…（restored scatter owner）；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33；AGENTS.md:87。
Problem: 四个 64 位值是清单/回执/owner 摘要，无法从任何提交重算，也表达不出第 3 条的「直接父版本」；partial RoPE→stock cache scatter 的谱系没有提交链。
Impact: 46.814–62.891、7 UT/4 A3 ST 与后续 300 题都无法在具名修订上复跑或被引用，PASS 前提不成立。
Fix: 在任何保留/下一轮父臂判定前把 scatter 候选与父版本落成 codex/dsv41-0day 上的提交，记录候选 SHA 与父 SHA，摘要保留作交叉校验。

F2 — high，must-fix（证据完整性，上轮 open，本次实测复核）— 仓库内仍无本 campaign 证据

Where: 正文「## 证据索引」只列相对实验归档根目录的 perf25/…；本轮 scatter 两臂原始波、16 ranks × 24/48 bucket 的 capture 检查、7 UT/4 A3 ST、A/A 第 2 组与 DSpark 诊断均无路径或摘要；AGENTS.md:89、docs/contributing.md:114-121。
本次实测（检出 663f3b3）： python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；ls evidence 无 dsv41*；grep -ril "dsv41\|perf25\|tpot25"（json/md/py）无命中。
Impact: 决定下一 screen 父臂的读数与九项回执无法复核；单个摘要不能定位原始波与失败/回滚记录（DSpark 的 failed service receipt 也没有位置）。
Fix: 登记 evidence/dsv41-910c-decode-tpot25/（plan/、results/、patch/、validator/），原始波按 tools/evidence_inventory.json 既有 external 先例说明，失败回执单列，导入前脱敏复查。

F9 — high，must-fix（需 owner 决定，上轮 open）— scatter 改动被选为下一 screen 父版本，却仍无 GSM8K-300

Where: 正文第 1 段「当前无精度结果或签署优化提交」；评论 6617042949「No quality result or signed optimization commit is claimed for this screen」；验收条件第 4 条（每个保留提交及最终版本 ≥292/300）；评论 6613949877「The acceptance workflow skips accuracy on a performance regression」；docs/contributing.md:100-101。
Problem: 冻结文本要求每个保留提交都有 300 题结论，实际做法把精度改成配对性能通过后的后续步骤，且没有 owner 记录。stock cache scatter 改的是 18 处缓存写路径（功能性改动），并被选为下游父版本，同样没有精度或 L3 结论。
Impact: 可能出现性能改善却从未产出 300 题结论的候选进入下一轮；基线 295/300 距门槛仅 3 题余量，写路径偏差只能靠该集合暴露。
Fix: owner 在正文与 plan/ 二选一并写明可跳过范围、最终版本独立重测与取消轨迹处置；作为父版本的候选在保留前至少要有精度结论。

F24 — high，must-fix（需 owner 决定，上轮 open）— 新父版本是否含 slot-reuse 未说明，C≥2 别名安全证据仍无

Where: 正文第 1 段只写「partial RoPE 父版本」，未说明是否包含 19:52 的 physical selected-KV slot reuse；评论 6613949877「At concurrency 32, the two services matched on 0 of 32 complete output hashes」；评论 6612233089 同一父服务自比在 C32 也是 0/32；docs/contributing.md:103-106。
Problem: 复用改变 decode 实际读取的物理 KV 位置，正确性取决于「被复用 slot 仍被在途序列引用时不得被覆写」；唯一多序列等价性指标在父臂自比时即为 0/32，已无判别力。正文未说明谱系是否含该改动：若含，别名安全证据仍缺；若不含，应明确该支已退出。
Impact: 若复用留在谱系里，输出可能无报错地被污染，并影响 scatter 与后续 screen 的跨臂差值。
Fix: 明确谱系是否含 slot reuse；若含，写明复用不变量（可复用条件、引用计数/失效规则），补专门验证别名安全的 C≥2 测试，并与不复用臂逐 token 对照、给同臂噪声底。

F8 — medium，must-fix（需 owner 决定，上轮 open）— Decision needed 仍不可判定，本轮新增的两项决定也没记进去

Where: 正文 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；……、**Next action:** 现有负责人 @jiangkuaixue123 继续在原线程记录…本次同步不授权新增运行或改变范围；docs/agent-collaboration.md:214-218 要求 <question>, from <decision owner> 与 <who does what next>；.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]。
Problem: 该行仍不是问题也没有决策人；本轮至少新增两项未登记决定：用单波筛选（F27/F28）把 scatter build 定为下一 screen 父版本、私有 replay 不替换生产。加上门槛（F19）、FC1（F5）、精度顺序（F9）、谱系（F24），读者无法区分已定与未定。
Impact: 无法判断正式配对何时能开始；Next action 只授权记录结果，campaign 实际停在选父与阈值上却未记为决策。
Fix: 把待决项逐条改写为「问题 + owner」，Next action 写明谁补 slot 复用正确性证据、谁负责剩余校准与阈值/选父规则。

F30 — medium（新增，需补充证据）— 私有 DSpark 诊断的 24.170 / 11.016 ms 来源进程与可重复性未说明

Where: 正文第 1 段「eager / staged replay 最慢 rank 流时间中位数 24.170 / 11.016 ms，但 repeated eager hidden 值及 replay proposal 存在差异；replay 未评分、未替换生产或运行精度，child 启动诊断在 ready 前结束并被回收为失败 service receipt」；评论 6617042949 同段（重复 eager 在一条 balanced 请求上改变 hidden 值；replay 与 eager 在 4 / 2 个 proposal 位置不同）。
Problem: 没有说明 24.170 / 11.016 ms 出自哪个进程/窗口——若出自未 ready 就被回收的子服务，它不构成可用测量；重复 eager 自身已改 hidden 值，4/2 个 proposal 差异缺少同请求重复 eager 基线，无法判断是否超出自身噪声。此前多轮把逐阶段 bitwise 相等/输出哈希一致当作正确性证据，本条正说明该口径在这些路径上可能不成立。
Impact: 该诊断现被当作逐层性能收益的早期信号，证据链不足以支撑复用；也可能让后续保留判定继续误用哈希/位级一致性判据。
Fix: 标注每项数字的来源进程与 ready 状态（给出失败 service receipt 位置），补重复 eager 基线后再谈 replay 差异，并明确该诊断不进入保留/PASS 判据。

F17 / F26 — medium（上轮 open）— 新用例计数与 18 处缓存写仍无期望清单与 site 定义

Where: 正文第 1 段「7 UT / 4 A3 ST 及全部 16 ranks 的 24/48-row buckets 各 18 次缓存写 capture 检查报告通过」；评论 6617042949 同段；历史计数 9/16 → 37/7 → 24/3 → 13/29 → 51/3 → 7/8、6/4 → 7/4；上一轮正文的 18-site ScatterUpdate 探针（16.79→1.34 / 16.92→1.81 ms、+16 MiB）已从正文移除；docs/contributing.md:103-106。
Problem: 第 7、8 套计数仍无期望用例清单、冻结时点与逐项对应；「18 expected cache writes」没有 site 定义（哪些算子、每 decode step 调用几次）、单位换算、内存口径与归档路径；上一轮探针从正文消失后，其证据缺口更不可追踪。
Impact: 无法证明新增写路径受到与上一候选同等的保护，也无法判断「各 18 次写」是否覆盖同一功能面；该探针若用于选源既不可复核也无法评估内存代价。
Fix: 冻结每轮期望用例清单与计数规则并给出逐项对应表；给出 18 个 site 的定义、每步调用次数、单位换算、内存峰值口径与归档路径。

F3 — high，must-fix，隐私（上轮 open，本次核实）— 11:15:56 的历史任务记录评论仍未脱敏

Where: 评论 6602376192（created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑）；docs/privacy-security.md:10-14、AGENTS.md:119-125。
本次核实: 仍含 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-…、/a3_inference/…、多份 /Users/jiangchenzhou/… 与用户名 jcz02615514；本次编辑与 22:27 评论只用清单摘要与相对描述，未新增泄漏（这点正确）。
Impact: 个人路径与内部拓扑持续公开；该记录若被当作证据导入 evidence/ 会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F4 / F6 / F7 / F11 / F12 / F13 / F15 / F20 / F21 — medium（早前项本轮仍未回应，保持 open）

Where/Problem: 评论 6602376192 的另一 RunSpec（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍与本 campaign 混在同一 Issue（F4）；AISBench Gsm8kEvaluator 无 revision/抽取判分摘要，294/300 不可复算（F7）；per-graph / per-step / per-token 换算表与两次基线（9.13 ms 与 46.65 ms）未处置（F6/F11）；18:45 的 compact 对照仍是 17:57 跨会话读数（F12）；数值等价性证据仍不足，C32 输出哈希在本 campaign 已无判别力（F13）；single-pass E4M3 QDQ 未定义（F15）；eager 回退 21,901/25,600 元素分歧无根因与处置（F20）；新 per-worker 观察器身份与环境签名未记录（F21）。
Impact: 下游引用与 PASS 判定仍缺可复算的判分工具、单位换算与数值等价性依据；本轮新增的 DSpark 诊断（F30）也沿用「未定义口径」的老问题。
Fix: 按各项原建议逐条回应，或在正文/plan/ 记录处置结论；F4 需 owner 决定移出或以指针声明，F20/F21 需 owner 说明放弃或继续。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

意图：继续维护 dsv41-910c-decode-tpot25 验收（六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300）；本次 Dong1017 的正文编辑把 scatter 父臂六值与 21:15 rotary 表逐位相同、8.54%–11.24% 仅为作者报告的探索性差值、以及本轮两臂显式 FlashComm1 开、fused MC2 关写进首段——我按评论 6615622965 复核，前两点陈述与公开记录一致（父臂列 51.183/50.155/51.980/54.544/57.571/70.858 逐位重合，降幅自洽）。结论：needs information / human decision required，整体仍 INCONCLUSIVE。F27 的「未标注来源就当同会话配对」这一半已修；F5 的逐轮标注要求部分满足，但冻结表仍写「显式 FlashComm1 关」，F5/F19 保持 open；F1/F2/F3/F9/F28/F8 与 F4/F6/F7/F11/F12/F13/F15/F17/F20/F21/F24/F26 本轮仍未见处置。正文没有请求代码改动的句子，不构成开发授权；未发现引导自动评审的文本，本次编辑也未新增敏感信息。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status 标签而本 Issue 无 status 标签。

F19 — high（需 owner 决定，上轮 open，本轮编辑加深矛盾）— 正文新写「两臂显式 FlashComm1 开」，冻结表却写「显式 FlashComm1 关」，C16 判读门槛仍无有效来源

Where: 正文第 1 段「（本轮两臂显式 FlashComm1 开、fused MC2 关）」；「## 初始修订与基线运行配置」表「Ascend 开关 | DSA CP 开、显式 FlashComm1 关、shared expert DP 开」；验收条件第 2 条仍为 [x] 与「## 已封存基线」C16 = 1.353%；评论 6617042949 的 0.041/0.436/0.352/0.272/4.349/0.119%；docs/contributing.md:100-101。
Problem: 同一正文两处开关取值互斥；1.000%–2.526% 这套门槛出自 FC1 关的封存基线，而编辑确认新测量在 FC1 开下取得，门槛与数据不同配置。fresh 同源 A/A 的 C16 4.349% 仍是封存 1.353% 的约 3.2 倍，也大于据以淘汰 ordinal 的 3.02%。
Impact: 46.814–62.891 无法归属到与门槛同配置的 RunSpec；C16 的保留/淘汰与将来 PASS 判读仍取决于临时选哪套门槛。
Fix: owner（.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]）先把冻结表开关行改为实际生效值或标为历史配置，写明唯一门槛公式、适用配置与生效时点，并说明第 3 组定型前 C16 按什么判。

F2 — high（证据完整性，上轮 open，本次实测复核）— 仓库内仍无本 campaign 证据树，本轮所有新数字与九项回执都只在评论里

Where: 正文「## 证据索引」只列相对实验归档根目录的 perf25/…；本轮「父臂六值 / 46.814–62.891 / 7 UT / 4 A3 ST / 各 18 次缓存写 / 16b160cc…/b082aea2…/01909f65…/cd0d8f73…」均无路径或摘要；AGENTS.md:67（verdict 依 evidence/<campaign-id>/ 判定）、docs/contributing.md:107。
本次实测（检出 663f3b3）： python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；ls evidence 无 dsv41*；grep -ril "dsv41\|perf25\|tpot25\|910c-decode"（json/md/py）无命中。
Impact: 决定下一 screen 父版本的读数、A/A 第 2 组与私有诊断无法复核，失败的 DSpark child service receipt 也没有落点，INCONCLUSIVE 无法收敛。
Fix: 登记 evidence/dsv41-910c-decode-tpot25/（plan/、results/、patch/、validator/），原始波按 tools/evidence_inventory.json 既有 external 先例说明，失败回执单列，导入前做脱敏复查。

F1 — high（可复现性，上轮 open）— 候选/父版本仍无可以检出的提交，本轮编辑又引入四个摘要值

Where: 正文表「候选 Git SHA | 待正式验收后提交」；正文第 1 段引用的评论 6617042949 中 cd0d8f731c83…（工作树清单）、16b160cc…/b082aea2…（TPOT screen 回执）、01909f65…（restored scatter owner）；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35（candidate_sha 必填 Full git SHA）；AGENTS.md:66。
Problem: 这些都是清单/回执/owner 摘要，无法从任何提交重算，也表达不出验收条件第 3 条要求的「直接父版本」；partial RoPE → stock cache scatter 的谱系没有提交链。
Impact: 编辑部头条的 46.814–62.891、7/4 用例与后续 300 题都无法在具名修订上复跑或被下游引用。
Fix: 在任何保留或下一 screen 父臂判定前，把 scatter 候选与父版本落成 codex/dsv41-0day 上的真实提交，逐轮记录候选 SHA 与父 SHA，摘要保留作交叉校验。

F9 — high（需 owner 决定，上轮 open）— 被选作下一 screen 父版本的 scatter build 仍无 GSM8K-300

Where: 正文第 1 段「当前无精度结果或签署优化提交」「作者按其预设选父规则选作 batched draft attention screen 的父版本」；验收条件第 4 条仍为 [ ]；评论 6617042949「No quality result or signed optimization commit is claimed for this screen」；docs/contributing.md:100-101。
Problem: 冻结文本要求每个保留提交都有 300 题结论；stock cache scatter 改的是 18 处缓存写路径（功能性改动），现已被选为下游父版本，却仍把精度当作性能通过后的后续步骤，且该顺序没有 owner 记录。
Impact: 性能改善但从未产出 300 题结论的候选会进入下一轮；基线 295/300 距门槛仅 3 题余量，写路径偏差只能靠该集合暴露。
Fix: owner 在正文与 plan/ 二选一并写明可跳过范围与生效时点：(a) 正式确认先性能后精度；(b) 恢复每个保留提交即测 300 题。

F27 — high（测量口径，上轮 open，本轮部分修复）— 父臂来源现已如实标注（已修），但该单波屏仍被用作选父依据（未修）

Where: 正文第 1 段新增「父臂六值与[前轮 rotary 表]（#issuecomment-6615622965）完全相同；公开记录未明确是本轮重测还是引用，不能据此确认同窗口交替配对，所列百分比仅作作者报告的探索性差值」；同段仍写「作者按其预设选父规则选作 batched draft attention screen 的父版本」；验收条件第 3 条「单轮筛选单列」。
已修： 来源与降级标注已写入正文，我复核评论 6615622965 的「+ stock partial RoPE」列 51.183/50.155/51.980/54.544/57.571/70.858 与 6617042949 的父臂列逐位相同，编辑陈述准确。
仍未修： 选父动作依然建立在这组不可确认配对、每档单波的差值上，与第 3 条「单轮筛选单列、不用于保留/选源」不一致；正文没有写「该屏不设父版本」。
Impact: 若同会话配对反转，下一 screen 与后续正式配对要从错的父版本重做。
Fix: 同一会话内 parent→scatter 交替重测六档（每档至少一波，给同臂噪声底）；或在正文明确记录该探索性屏不改变父版本。

F28 — high（需 owner 决定，上轮 open，反复出现）— 「预设选父规则」第三次只以叙述出现，正文与 plan/ 仍无规则文本、阈值与冻结时点

Where: 正文第 1 段「作者按其预设选父规则选作 batched draft attention screen 的父版本，不是正式验收」；评论 6617042949「The preregistered rule selected this build as the parent for the batched draft attention screen」；验收条件第 3 条；AGENTS.md:64（Freeze gates before search）。
Problem: 规则内容（阈值、预设受益档、并列处置、所用指标是逐请求 (E2E−TTFT)/(tokens−1) 还是整波 TPOT）仍未在任何冻结位置登记；「batched draft attention screen」也没有假设与判据。
Impact: 「保留」的含义继续漂移，下一轮父臂链条无法按第 3 条复核。
Fix: 把规则文本与新屏的假设、预设受益档、判据写入正文与 plan/ 后再测量；需要改规则时先改文本。

F3 — high（隐私，上轮 open，本次核实）— 11:15:56 的历史任务记录评论仍未脱敏

Where: 评论 6602376192（created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑）；docs/privacy-security.md:8-14、AGENTS.md:119-125。
本次核实： 仍含 10.30.13.138、10.30.12.215 各 1、/Users/jiangchenzhou/… 37、用户名 jcz02615514 5、/a3_inference/… 2、Pod 名 itask-jcz-dsv41-… 1；本次编辑与 22:27 评论只用清单摘要与相对描述，未新增泄漏（这点正确）。
Impact: 个人路径与内部拓扑持续公开；该记录若被当作证据导入 evidence/ 会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F34 — medium（本轮新增）— 编辑给「两臂」标注 FC1 开/fused MC2 关，但父臂列很可能引自未记录这两项开关的 21:15 会话

Where: 正文第 1 段「（本轮两臂显式 FlashComm1 开、fused MC2 关）」与「父臂六值与[前轮 rotary 表] 完全相同」；评论 6615622965 的三源表只写「same 16-rank node with DP4/TP4/EP16, DSpark-5, FULL_DECODE_ONLY」，未记 enable_flashcomm1 / enable_fused_mc2 / 环境签名；评论 6617042949 写两臂 FC1 开、fused MC2 关。
Problem: 两种情形都不支持「两臂」说法：若父臂确实引自 21:15 会话，则该会话未记录 FC1/fused_mc2，父臂的配置归属未证明；若父臂是本轮重测，六档又不可能与旧表逐位相同。
Impact: 8.54%–11.24% 可能把配置切换（FC1 关→开）与 scatter 改动混在一起，选父依据的归因不清。
Fix: 在表下逐臂写明来源会话、enable_flashcomm1、enable_fused_mc2、环境签名与服务实例；父臂若为引用，需证明与 21:15 同配置，否则改为同会话重测。

F8 — medium（需 owner 决定，上轮 open）— Decision needed 仍不是问题也没有决策人，累计待决项未记入

Where: 正文 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；……、**Next action:** 现有负责人 @jiangkuaixue123 继续在原线程记录……本次同步不授权新增运行或改变范围；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> 与 <who does what next>；.github/knowledge-model-policy.json:50。
Problem: 该三行块无法判读谁在何时决定什么；累计未登记决定至少四项：C16 门槛来源（F19）、选父规则与单波屏是否设父（F27/F28）、精度顺序（F9）、谱系是否含 slot reuse（F24）。
Impact: 读者与后续评审无法区分已定与未定，也无法判断正式配对何时能开始。
Fix: 把待决项逐条改写为「问题 + owner」，Next action 写明谁补 slot 复用正确性证据、谁负责剩余校准与阈值/选父规则。

F4 / F6 / F7 / F11 / F12 / F13 / F15 / F17 / F20 / F21 / F24 / F26 — medium（早前项本轮仍未回应，保持 open）

Where / Problem: 评论 6602376192 的另一 RunSpec（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍混在同一 Issue（F4）；AISBench Gsm8kEvaluator 无 revision/抽取判分摘要（F7）；per-graph/per-step/per-token 换算表与两次基线（9.13 ms 与 46.65 ms）未处置（F6/F11）；compact 对照仍是跨会话读数（F12）；数值等价性证据不足、C32 输出哈希已无判别力（F13）；single-pass E4M3 QDQ 未定义（F15）；新一轮「7 UT / 4 A3 ST」与「各 18 次缓存写」仍无期望清单、site 定义与归档路径（F17/F26）；eager 回退 21,901/25,600 元素分歧无根因（F20）；观察器身份与环境签名未记录（F21）；partial RoPE 父版本是否含 slot reuse 仍未说明、C≥2 别名安全证据仍无（F24）。
Impact: 下游引用与 PASS 判定仍缺可复算的判分工具、单位换算与数值等价性依据；父臂链正确性未封口。
Fix: 按各项原建议逐条回应，或在正文/plan/ 记录处置结论；F24 需明确谱系是否含 slot reuse 并补 C≥2 别名安全对照。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

Six-tier baseline calibration sealed and first direct-parent candidate declared

All six original-source services completed and were reaped. The independent review reproduced 36 measured windows, matched the worker counters inside those windows, and recalculated all three chronological A/A differences at each tier from the stored client waves.

Global concurrency	1	2	4	8	16	32
Frozen gain/regression threshold	1.000%	1.000%	1.000%	1.683%	4.349%	1.076%
Initial TPOT, median of six service means (ms/token)	94.009	95.735	97.430	100.476	103.515	128.602

The first direct-parent candidate fuses the fixed 4×4, twenty-round HC Sinkhorn operation. The frozen targets are C1 and C32. The plan compares the original signed branch head at d4ac4319a and HC source manifest ee625c96e840768bf793f0c8b1ae420006898ba82d0a444175e80e167062928a in parent/candidate, candidate/parent, parent/candidate order. Only a formal performance PASS and a complete fixed-300 result of at least 292 correct allow retention. The scatter and private draft results reported above are separate exploratory experiments.

Sealed calibration SHA-256 4fd871e7372b77a935b951c0c5e53433a583785a6a721c01473c200edaadf853. Direct-parent plan SHA-256 8074a88c1c9656c719e2927ba861ca906b5c98d9f1b28786d776f130ba8dc99a.

意图：继续以 dsv41-910c-decode-tpot25 验收 DeepSeek V4.1 Flash 在 910C 上六档 decode TPOT ≤25 ms/token 与固定 GSM8K ≥292/300；23:12 的评论首次把三对同源 A/A 校准封存为六档门槛（1.000/1.000/1.000/1.683/4.349/1.076%）与六服务 TPOT 中位数，并宣布 HC Sinkhorn 为相对 d4ac4319a 的首个直接父版本候选、保留需同时满足正式性能 PASS 与 292/300。这是对上轮门槛口径与选父的实质推进，但封存只写在评论里：正文第 2 条 [x] 仍是两组/四服务旧公式与旧表（C16 1.353%）、正文仍写「尚未封存，不能替换下方既有初始校准门槛」，第三对逐档差值与封存摘要均无可定位归档，候选仍非提交。结论：needs information / human decision required，整体 INCONCLUSIVE；正文无请求代码改动的句子，不构成开发授权，未发现引导自动评审的文本。F19 因封存值加深；F1/F2/F3/F5/F8/F9/F27/F28/F34 仍 open，F4/F6/F7/F11/F12/F13/F15/F17/F20/F21/F24/F26 未见处置。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status 标签，本 Issue 无 status 标签。

F19 — high，需 owner 决定（上轮 open，本轮因封存值加深）— 封存门槛只写在评论里，与正文第 2 条 [x] 的旧公式/旧表以及正文「尚未封存」表述三者互斥，且封存值无法复算

Where: 23:12 评论表 1.000/1.000/1.000/1.683/4.349/1.076% 与 94.009/95.735/97.430/100.476/103.515/128.602、4fd871e7…；正文验收条件第 2 条（[x]，「两组、共四个独立服务」「max(1%, 两组内以先测轮为分母的绝对相对差最大值)」）；正文「## 已封存基线」C8 2.526% / C16 1.353% / C32 2.248%；正文第 1 段「作者报告仍需第 3 组才确定噪声阈值，尚未封存，不能替换下方既有初始校准门槛」；评论 6610897338（17:27 另一份「pair 1 of 3」，837262142355/da05a8aa0892，差值 0.28/0.04/0.04/0.51/1.19/0.76%）；AGENTS.md:64。
Problem: 评论宣布 sealed，正文（编辑于本轮评论前数分钟）仍说未封存、仍以旧两组公式和旧表为唯一判据；同一原始源码现在有两套共存门槛（C8 2.526%→1.683%、C32 2.248%→1.076%、C16 1.353%→4.349%，相差 2–3 倍）和两套基线中位数（93.862–129.043 与 94.009–128.602）。评论只给封存后的 max 值，没有公布三对（尤其第 3 对）的逐档绝对差，第 2 条公式无法复算；「All six original-source services」也未说明是否含 17:27 那份同版本对。
Impact: 首个正式直接父版本（HC vs d4ac4319a）的保留/淘汰取决于临时选哪套门槛；若以 4.349% 为 C16 门槛，上轮据以保留 rotary、淘汰 ordinal 的 −3.02% 回退落在门槛内，选父结论随之反转。PASS 判读失去唯一、可复算的基准。
Ask: owner（.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]）在正文与 plan/ 登记唯一公式（两对还是三对）、六档门槛与基线中位数、生效时点及旧表作废方式，公布三对逐档差值，并明确 C16 的 −3.02% 在新门槛下如何处置。

F1 — high，可复现性（上轮 open）— 首个「正式直接父版本」候选仍是工作树清单，d4ac4319a 之外没有提交

Where: 23:12 评论「The first direct-parent candidate … HC source manifest ee625c96e840…」「compares the original signed branch head at d4ac4319a and HC source manifest …」；正文表「候选 Git SHA | 待正式验收后提交」；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33（candidate_sha 必填 Full git SHA）；评论 6598050871 首轮 HC 融合用同一 ee625c96…。
Problem: 要据以裁决「正式性能 PASS + 292/300 才可保留」的对象是一个 64 位工作树清单，不是可 checkout 的修订；该清单与 07:35 首轮同值，说明候选仍是当时的工作树，无法表达验收条件第 3 条要求的直接父版本链。
Impact: 36 个正式窗口与后续 300 题都无法在具名修订上复跑或被下游引用，PASS 前提不成立。
Fix: 在正式配对开始前把 HC 候选与父链落成 codex/dsv41-0day 上的真实提交，正文登记候选 SHA 与父 SHA，清单保留作交叉校验。

F2 — high，证据完整性（上轮 open，本次实测复核）— 封存校准与直接父版本计划都没有可定位的归档

Where: 23:12 评论 4fd871e7…（封存校准）、8074a88c…（direct-parent plan）与「The independent review reproduced 36 measured windows…」均无路径/回执；正文「## 证据索引」只列仓库外相对路径 perf25/…；AGENTS.md:67、docs/contributing.md:107。
本次实测（检出 663f3b3）： python3 tools/validate_evidence.py → exit 0、errors: []、21 个 bundle、checked_hashes: 430；ls evidence 无 dsv41*；grep -ril "dsv41\|perf25\|tpot25\|910c-decode"（json/md/py）无命中。
Problem: 「independent review」没有身份、方法与回执；封存所依赖的 36 个窗口、三对 A/A 差值与计划文本都不在仓库任何位置，读者无法复算或审计封存行为。
Impact: 门槛封存与首个正式候选都建立在不可复核的叙述上，按 AGENTS.md:67 无法把 verdict 从 INCONCLUSIVE 推进。
Fix: 登记 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator}，把封存校准、三对原始波、计划文本与独立复核回执落盘；外部原始波按 tools/evidence_inventory.json 既有 external 先例说明，导入前做脱敏复查。

F3 — high，隐私（上轮 open，本次核实）— 11:15:56 的历史任务记录评论仍未脱敏

Where: 评论 6602376192（created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑）；docs/privacy-security.md:10-14、AGENTS.md:119-125。
本次核实: 仍含 10.30.13.138、10.30.12.215 各 1、/Users/jiangchenzhou 37、用户名 jcz02615514 5、itask-jcz… 1；23:12 评论与正文未新增泄漏（0 命中），这点正确。
Impact: 个人路径与内部拓扑持续公开；该记录一旦被当作证据导入 evidence/ 会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F28 — high，需 owner 决定（上轮 open）— 直接父版本计划与判定式仍只以评论 + 摘要出现，没有在 plan/ 中于测量前冻结

Where: 23:12 评论「Direct-parent plan SHA-256 8074a88c…」「Only a formal performance PASS and a complete fixed-300 result of at least 292 correct allow retention」；AGENTS.md:64（Freeze gates before search — checklist 与 validator/ 在候选实验前锁进 plan/）；正文验收条件第 3 条；仓库内无 plan/ 相关文件（grep 无命中）。
Problem: 计划内容（三对交替顺序、判定式、阈值来源、C1/C32 预设受益方向、父版本已达 25 的处置）只存在于评论与一个无路径的摘要里；此前两次「预设选父规则」也从未登记。无法证明这些判据在测量开始前已冻结。
Impact: 正式配对一旦开始，结果不合意时无法判断规则是否被改过；验收条件第 3 条要求的「记录单一假设、预设受益档、直接父版本」仍不可复核。
Fix: 把计划与判定式（含阈值来源、预设受益档、交替顺序、精度门禁）写入 evidence/dsv41-910c-decode-tpot25/plan/ 并在正文引用路径，然后再开始正式六档配对。

F5 / F34 — high，需 owner 决定（上轮 open）— 封存校准没有记录运行配置，其 TPOT 水平只与「FlashComm1 关」的旧基线相符

Where: 23:12 评论通篇无 enable_flashcomm1 / enable_fused_mc2 / 环境签名 / 服务实例；正文「## 初始修订与基线运行配置」表写「Ascend 开关 | DSA CP 开、显式 FlashComm1 关、shared expert DP 开」，而「## 当前开关要求」要求显式开 FC1、enable_fused_mc2=0（整数）；封存中位数 94.009–128.602 与 FC1 关旧基线 93.862–129.043 同水平，与全部 FC1 开测量 46.8–62.9 相差约 1.5–2 倍；FC1 开只在评论 6617042949 的探索性 scatter 屏中写明。
Problem: 门槛绑定的配置仍未记录。若 /d4ac4319a/ vs HC 的正式配对在 FC1 开下运行，封存门槛来自另一配置；若在 FC1 关下运行，父版本 94–129 ms 与 25 ms 目标不在同一量级，且与当前开关要求矛盾。F34 指出的父臂配置归属问题因此仍未消解。
Impact: 首个正式 PASS 的判读基准无法与 RunSpec 绑定；正文两处开关取值互斥，读者无法确定当前生效要求。
Ask: 在正文冻结表与 plan/ 按实际值登记 FC1/fused_mc2、环境签名与服务实例，给每轮测量统一标注，并写明封存门槛只适用于哪套配置。

F9 — high，需 owner 决定（上轮 open，本轮部分回答）— 新计划把 292/300 并入保留条件（已答），但已「保留」的改动与探索性父臂仍无精度

Where: 23:12 评论「Only a formal performance PASS and a complete fixed-300 result of at least 292 correct allow retention」；正文验收条件第 4 条（[ ]）与「本次 V4.1 fused MC2 接入已撤回，保留 HC 融合和已通过功能复验的分页 KV 读取修正版 4a06cea1…」；评论 6617042949「No quality result or signed optimization commit is claimed for this screen」。
Problem: 新规则把精度并入保留条件，方向正确且与第 4 条一致；但正文已列「保留」的两项改动与仍被写成 batched draft attention 屏父版本的 scatter build 都没有 GSM8K-300，也没说明新规则是否追溯适用。
Impact: 性能改善但从未产出 300 题结论的改动会继续留在谱系里；基线 295/300 距门槛仅 3 题余量，写路径或数值路径偏差只能靠该集合暴露。
Fix: owner 明确新规则是否追溯适用于已保留项，并在正文为每项保留登记 300 题结果或退出记录。

F27 — high（上轮 open）— 评论把 scatter/private 结果降级为「探索性」，却没有撤回把它选为 batched draft attention 屏父版本的动作

Where: 23:12 评论「The scatter and private draft results reported above are separate exploratory experiments」；正文第 1 段「作者按其预设选父规则选作 batched draft attention screen 的父版本」；验收条件第 3 条「单轮筛选单列」；评论 6617042949「The preregistered rule selected this build as the parent」。
Problem: 降级只改口径，没有改选父；正文仍把跨会话单波差值选出的 build 当作下一屏父版本。同时新计划的正式谱系从 d4ac4319a 重起 HC，于是同一 Issue 里并存两条父链，正文没有写哪条继续。
Impact: 下一屏若按 scatter 父臂做，仍建在第 3 条要排除的漂移来源上；若按正式 HC 链做，正文里的 scatter 父臂声明就是失效文本。
Fix: 在正文明确「该探索性屏不改变父版本」或撤回该选父，并写明 batched draft attention 屏的父版本是否随正式链重起。

F35 — medium，需 owner 决定（本轮新增）— 正式计划只覆盖 d4ac4319a → HC，未覆盖正文声称「保留」的分页 KV 读取修正 4a06cea1

Where: 23:12 评论「The plan compares the original signed branch head at d4ac4319a and HC source manifest ee625c96…」；正文「保留 HC 融合和已通过功能复验的分页 KV 读取修正版 4a06cea1…」；验收条件第 3 条（每个保留的优化提交都要记录直接父版本与完整六档交替配对）。
Problem: 正文的保留集合是 {HC, 分页 KV}，正式计划的第一条链只有 {d4ac4319a → HC}。分页 KV 修正要么已不在保留集合，要么需要自己的直接父版本与正式配对，两种处置都未记录；若它仍在谱系里，HC 的直接父版本就应包含它，计划中的父 SHA 即写错。
Impact: 「保留」集合与正式谱系不一致，后续候选的直接父版本与配对位置无法确定。
Fix: owner 在正文与 plan/ 明确保留集合与顺序，并为 4a06cea1 登记直接父版本与配对位置，或写明其已退出。

F8 — medium，需 owner 决定（上轮 open，本轮新增待决项）— Decision needed 仍不是问题也没有决策人

Where: 正文 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；……、**Next action:** 现有负责人 @jiangkuaixue123 继续在原线程记录……本次同步不授权新增运行或改变范围；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> 与 <who does what next>；.github/knowledge-model-policy.json:50。
Problem: 本轮至少新增三项决定：封存门槛替换旧表（F19）、正式谱系重起并把 HC 定为首个直接父版本（F1/F35）、精度门禁追溯适用（F9）；连同 F5 配置归属与 F27 父臂处置，均未登记为「问题 + owner + 时点」。
Impact: 读者与后续评审无法区分已定与未定，也无法判断正式配对何时能开始。
Fix: 把待决项逐条改写为「问题 + owner」，Next action 写明谁补 plan/ 与证据树、谁负责门槛与选父决定。

F4 / F6 / F7 / F11 / F12 / F13 / F15 / F17 / F20 / F21 / F24 / F26 — medium（早前项本轮仍未回应，保持 open）

Where / Problem: 评论 6602376192 的另一 RunSpec（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍与本 campaign 混在同一 Issue（F4）；AISBench Gsm8kEvaluator 无 revision 与抽取/判分摘要，294/300 不可复算（F7）；per-graph / per-step / per-token 换算表与两次基线（9.13 ms 与 46.65 ms）未处置（F6/F11）；compact 对照仍是跨会话读数（F12）；数值等价性证据不足、C32 输出哈希在本 campaign 已无判别力（F13）；single-pass E4M3 QDQ 未定义（F15）；「7 UT / 4 A3 ST」与「各 18 次缓存写」仍无期望清单、site 定义与归档路径（F17/F26）；eager 回退 21,901/25,600 元素分歧无根因（F20）；观察器身份与环境签名未记录（F21）；父版本是否含 slot reuse 未说明、C≥2 别名安全证据仍无（F24）。
Impact: 下游引用与 PASS 判定仍缺可复算的判分工具、单位换算与数值等价性依据；父臂链正确性未封口。
Fix: 按各项原建议逐条回应，或在正文与 plan/ 记录处置结论；F4 需 owner 决定移出或以指针声明，F20/F21 需 owner 说明放弃或继续。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

@jiangkuaixue123

本 Issue 跟踪 DeepSeek V4.1 Flash 在 910C 上六档 decode TPOT ≤25 ms/token 与固定 GSM8K ≥292/300 的验收；本次正文编辑把 23:12 的三对 A/A 校准与首个直接父版本计划写入开头状态块，并把「新三对校准与既有两组校准及当前配置的适用关系」登记为待明确事项，但未改动验收条件、冻结配置表或候选 SHA 状态。结论维持 needs information / human decision required：门槛口径、配置归属与「保留」判据互相牵连，未定前不应开始正式配对或判 PASS。早前项：F19 部分回应（「尚未封存」矛盾已删、关系已登记为待决，但唯一生效公式/阈值与三对逐档差值仍未登记）、F27 可视为已答（scatter/private 明确为探索，正式谱系从 d4ac4319a→HC 重起）；F1/F2/F3/F5/F8/F28/F34/F9/F35 仍 open，上轮归并的中等项（F4/F6/F7/F11–F17/F20/F21/F24/F26）仍无处置。正文没有请求改代码的句子，不构成开发授权；未发现引导自动评审的文本，未返回新标签。

F3 — high, 隐私 — 11:15:56 的历史任务记录评论仍未脱敏（open）

Where: 评论 6602376192（created_at = updated_at，未编辑）；docs/privacy-security.md:10-13。
Problem: 本次复核仍命中 2 个内网 IPv4、5 个用户名实例、37 处 /Users/jiangchenzhou 个人绝对路径；本次正文编辑与 23:12 评论未新增泄漏（0 命中）。
Impact: 内部拓扑与个人路径持续公开，导入 evidence/ 会把泄漏固化。
Fix: 作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 替换；导入证据树前再复查。

F36 — high, 需 owner 决定（新增）— 「保留」判据写成正式性能 PASS，与验收条件第 3 条冲突

Where: 正文 Current state「作者明确仅正式性能 PASS 且固定 300 题至少 292 正确才保留」；验收条件第 3 条（预设档配对改善、各档回退中位数不超门槛）与第 5 条（最终提交六档中位数均 ≤25 才判 PASS）；AGENTS.md:85。
Problem: 若「正式性能 PASS」指第 5 条，则任何中间候选都要六档 ≤25 才能保留：新封存中位数 94.009–128.602、FC1 开下最好 46.8–62.9 ms/token 都离 25 有 1.5–5 倍，首个直接父版本 HC 不可能保留，而 HC 正是后续候选的父版本，谱系无法累积。若指第 3 条，则「保留」与 PASS 混为同义，下游会误读为已达最终目标。
Impact: 首个正式候选能否保留、后续能否叠加优化取决于未定义判据。
Fix: owner 写成「保留按第 3 条，PASS 按第 5 条」，并在 plan/ 与正文同文登记。

F19 — high, 需 owner 决定（上轮 open，本次部分回应）— 同一原始源码并存两套「封存」门槛与两份基线，唯一生效口径未登记

Where: 正文 Current state「报告阈值为 1.000 / 1.000 / 1.000 / 1.683 / 4.349 / 1.076%」「六服务均值的中位 TPOT 94.009 … 128.602」；验收条件第 2 条仍为 [x]「两组、共四个独立服务」「max(1%, 两组内以先测轮为分母的绝对相对差最大值)」；「已封存基线」表仍为 C8 2.526% / C16 1.353% / C32 2.248%、中位数 93.862–129.043。
Problem: 编辑删去了「尚未封存」的矛盾表述并把关系登记为待明确（这点已改善），但同一 d4ac4319a 现在有两套门槛与两份基线，第 2 条仍是 [x] 的生效公式，而新值是三对口径；正文只给六档最大值，未公布三对逐档差值，1.683 / 4.349 / 1.076 无法复算。C16 从 1.353% 变为 4.349%，直接决定上一轮 −3.02% 的 rotary/ordinal 选父结论是否成立，也决定首个正式候选的回退判定。
Impact: 保留/淘汰与 PASS 判读没有唯一、可复算的基准。
Fix: owner 在正文与 plan/ 登记唯一公式（两对或三对）、六档门槛与基线中位数、生效时点与旧表作废/适用范围，公布三对逐档差值并写明 C16 处置。

F5 / F34 — high, 需 owner 决定（上轮 open）— 封存门槛绑定的配置仍未记录，正文两处开关取值互斥

Where: 正文「初始修订与基线运行配置」表「Ascend 开关 | DSA CP 开、显式 FlashComm1 关」；「当前开关要求」要求显式开 FC1、enable_fused_mc2=0；新封存中位数 94.009–128.602 与 FC1 关旧基线 93.862–129.043 同水平，而全部 FC1 开测量为 46.8–62.9（评论 6617042949）。
Problem: 编辑声明「不改写…配置」，两处互斥取值因此仍在同一正文；封存校准未写 FC1/fused_mc2、环境签名与服务实例，其量级只与 FC1 关相符。若正式配对在 FC1 开下跑，门槛来自另一配置；若在 FC1 关下跑，父版本 94–129 ms/token 与 25 ms/token 目标及当前要求都不一致。
Impact: 首个正式 PASS 的判读基准无法与 RunSpec 绑定。
Fix: 在正文冻结表与 plan/ 按实际值登记开关、环境签名、服务实例，并声明正式配对使用哪套配置、门槛只适用于哪套配置。

F1 — high（上轮 open）— 首个「正式直接父版本」候选仍只有工作树清单，没有可检出提交

Where: 正文表「候选 Git SHA | 待正式验收后提交」；Current state「源码清单不是可检出候选提交」，清单 ee625c96… 与 07:35 首轮同值；AGENTS.md:87、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35。
Problem: 要据以裁决保留的对象是一个 64 位工作树清单，既不能 checkout，也表达不出第 3 条要求的直接父版本链；把候选 SHA 排到验收之后还形成循环。
Impact: 正式配对结果无法复跑、无法被下游引用，PASS 前提不成立。
Fix: 配对开始前把 HC 候选与父链落成 codex/dsv41-0day 上的提交，正文登记候选 SHA 与父 SHA，清单保留作交叉校验。

F28 — high（上轮 open）— 直接父版本计划仍只以评论 + 无路径摘要存在，未在测量前冻结进 plan/

Where: 正文「校准与计划 SHA-256 已附原评论」与 Current state 的计划描述；AGENTS.md:64；验收条件第 3 条；仓库内无该 campaign 的 plan/ 文件（grep 无 dsv41/perf25/tpot25 命中）。
Problem: 三对顺序、判定式、阈值来源、预设受益档、C≥2 精度门禁都只在评论与一个无路径的摘要里，无法证明在测量开始前已冻结；正文却已宣布将据此开始正式配对。
Impact: 结果不合意时无法判断规则是否被改过。
Fix: 把计划与判定式写入 evidence/dsv41-910c-decode-tpot25/plan/（含 validator），正文引用路径，然后再开始配对。

F2 — high（上轮 open，本次实测复核）— 封存校准与计划仍无可定位归档；36 窗口与「独立复核」都不可审计

Where: 正文「证据索引」（全部为仓库外相对路径）与 Current state「校准与计划 SHA-256 已附原评论」；AGENTS.md:89、docs/contributing.md:117。
本次实测（检出 663f3b3）： python3 tools/validate_evidence.py → errors: []、21 个 bundle、checked_hashes: 430；evidence/ 无 dsv41*；grep dsv41|perf25|tpot25 无命中。
Problem: 36 个正式窗口、三对 A/A 差值、封存值 4fd871e7…、计划 8074a88c… 与「independent review」都没有路径、身份、方法或回执；旧基线遗留的「C4/C8/C16 限频日志未覆盖全部活跃 DP」完整性标志在新封存集中是否已解决也未说明。
Impact: 门槛封存与首个正式候选都建立在不可复核的叙述上。
Fix: 在 PASS 前建立 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并登记 tools/evidence_inventory.json（外部原件用 external 声明），把封存校准、三对原始波、复核回执与完整性标志落盘。

F37 — medium, 建议（新增）— 公布的计划只写两个预设目标，未写每个配对是否覆盖全部六档

Where: 正文 Current state「预设目标 C1/C32，顺序 parent/candidate、candidate/parent、parent/candidate」；验收条件第 3 条要求「完整的六档交替配对」且「各档回退中位数不得超过门槛」。
Problem: 计划文本只点名 C1/C32 两个预设受益档与三对顺序，没写每对是否测六档、逐档判定用哪套门槛（见 F19）。而 C8 1.683%、C16 4.349% 恰是上一轮选父结论会翻转的档位，若正式配对只测 C1/C32 就无法执行「各档回退」判据。
Impact: 计划不足以支撑第 3 条的保留判定，可能测完仍需重跑。
Fix: 在计划中写明每对六档覆盖、逐档判定阈值与预设受益档的区分；该检查不改变当前 INCONCLUSIVE。

F8 — medium, 需 owner 决定（上轮 open）— Decision needed 仍无决策人，Next action 未写谁补 plan/ 与证据树

Where: 正文「Decision needed: 新三对校准与下方既有两组初始校准及当前配置的适用关系尚待明确…」与「Next action: 现有负责人 @jiangkuaixue123 继续在原线程记录…」；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 记 approval_owners: ["Dong1017"]。
Problem: 编辑第一次把门槛/配置关系写成待明确（方向正确），但仍不是「问题 + 决策人」，也没写谁负责 F19/F36 的口径决定、谁写 plan/ 与证据树。
Impact: 读者无法判断正式配对何时可以开始，也无法追责。
Fix: 把待决项逐条写成「问题 + owner + 时点」，Next action 写明谁补 plan/、谁做口径决定。

F9 / F35 — medium, 需 owner 决定（上轮 open）— 正文「保留」集合与正式谱系不一致，精度门禁是否追溯未定

Where: 正文「本次 V4.1 fused MC2 接入已撤回，保留 HC 融合和已通过功能复验的分页 KV 读取修正版 4a06cea1…」；Current state 计划只覆盖 d4ac4319a → HC；验收条件第 3、4 条。
Problem: 保留集合是 {HC, 分页 KV}，正式谱系是 {d4ac4319a, HC}：4a06cea1 若仍在谱系内，HC 的直接父版本就不止 d4ac4319a，计划里的父 SHA 即写错；若已退出，正文应写明。同时两项「保留」改动与 scatter build 都没有 300 题结果，也未说明新精度规则是否追溯适用。
Impact: 后续候选的直接父版本与配对位置无法确定。
Fix: owner 在正文与 plan/ 声明保留集合与顺序，为 4a06cea1 登记直接父版本与配对位置或标记退出，并为保留项补 300 题结论。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

First formal direct-parent pair and a separate rejected kernel

The first of three predeclared Sinkhorn pairs completed on the same node. Each service ran a separate warmup and then a 1,024-in / 1,024-out measured wave at every tier. All twelve measured windows had the required FULL worker counter deltas. Both processes were reaped and the previous deployment was restored.

Concurrency	Initial parent	Sinkhorn candidate	Reduction
1	93.768	87.832	6.33%
2	95.801	86.283	9.94%
4	97.061	89.123	8.18%
8	100.556	88.965	11.53%
16	101.936	93.578	8.20%
32	128.018	124.272	2.93%

TPOT is in ms/token. This is one paired observation. The second pair reverses service order. No fixed-300 quality score or signed optimization commit has been produced for this formal campaign.

A separate previous-pre plus RMS normalization kernel reduced twelve physical tasks to one on A3. It failed the predeclared raw FP32 boundary test: of 432 word pairs, two means differed by one ULP and 26 reciprocal RMS values differed by one or two ULP. All differing words represented positive finite numbers. All 24 final BF16 fixture outputs matched. This kernel is excluded from service and quality tests. It is separate from the Sinkhorn candidate above.

Formal pair checksums: owner ea70a2a8aa7d9ea3e6579db08ac414b23eab20d19392f516ed785144510a05bc and restoration 2056155f2bda598b6600c0676fc841e2be1fcf5b243e9e9d5291c4bfc52523d1. Raw FP32 report SHA-256: 7afa3db2c5ec9428f2c62db637156c4c5722dec09fc371e48c49250b65fd2336.

意图：继续维护 dsv41-910c-decode-tpot25 验收（六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300）；23:52 评论报告三对正式直接父版本配对中的第 1 对并淘汰一个 ULP 边界失败的 A3 kernel。我复算六档降幅（6.33/9.94/8.18/11.53/8.20/2.93%）与表逐个相符，但父臂读数落在 FC1 关基线水平而正文「当前开关要求」要求显式 FC1 开，且候选仍非提交、证据仍无归档，故维持 INCONCLUSIVE。结论：needs information / human decision required，冻结 plan/、登记配置与候选 SHA 前不应继续判读正式配对。早前项：F37 已答（本对覆盖六档）；F5/F34、F2、F1、F28、F36、F19、F9/F35、F3、F8 及归并中等项（F4/F6/F7/F11–F17/F20/F21/F24/F26）仍 open。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 需配 status:*，而状态块缺决策人（F8）。

F5 / F34 — high，需 owner 决定 — 首个正式配对的配置未记录；父臂读数落在 FC1 关的封存基线水平

Where: 23:52 评论「completed on the same node」及其表（父臂 93.768/95.801/97.061/100.556/101.936/128.018）；正文「## 当前开关要求」（显式 FC1 开、enable_fused_mc2=0）与「## 初始修订与基线运行配置」表（「显式 FlashComm1 关」）；评论 6617042949（FC1 开：父臂 51.183–70.858、候选 46.814–62.891）。
Problem: 评论未写 enable_flashcomm1 / enable_fused_mc2 / 环境签名 / 服务实例。我复算父臂相对封存三对中位数（94.009–128.602）差 0.07%–1.53%、相对旧两组中位数差 0.10%–0.79%，即与 FC1 关基线同水平；全部 FC1 开测量在 46.8–70.9，候选 C32 124.272 是 FC1 开 C32 62.891 的 1.98 倍。
Conditions: 若正式配对在 FC1 关下运行，则与正文「当前开关要求」及全部 FC1 开结果不同配置；若申报为 FC1 开，则与既有 FC1 开证据相差约 1.4–2 倍。
Impact: 第 1 对的 6.33/9.94/8.18/11.53/8.20/2.93% 无法绑定 RunSpec，也无法对齐 25 ms/token 目标；后两对沿用同一歧义。
Fix: 在评论、正文冻结表与 plan/ 逐臂登记开关、环境签名、服务实例与时间，写明正式链用哪套配置；若为 FC1 关，需 owner 说明为何「当前开关要求」与 46.8–62.9 的结果不作判读基准。

F2 — high — 第 1 对的 12 个窗口、回执、恢复摘要与被淘汰 kernel 报告仍无归档路径

Where: 23:52 评论「twelve measured windows」「owner ea70a2a8…」「restoration 2056155f…」「Raw FP32 report 7afa3db2…」，以及 23:12 的 4fd871e7…/8074a88c…；正文「## 证据索引」仅列仓库外 perf25/…；AGENTS.md:67、AGENTS.md:89、docs/contributing.md:96。
本次实测（检出 663f3b3）： python3 tools/validate_evidence.py → errors: []、checked_hashes: 430；evidence/ 无 dsv41*；grep -ril "dsv41|perf25|tpot25"（json/md/py）无命中。
Problem: 原始波、两条回执、恢复摘要、23:12 所称「independent review」与被淘汰 kernel 的报告都只有裸摘要；封存基线遗留的「限频日志未覆盖 C4/C8/C16 全部活跃 DP」完整性标志，本评论只写 FULL worker counter 增量，未说明该标志是否转 true。
Impact: 12 个窗口与恢复动作不可审计，INCONCLUSIVE 无法按 AGENTS.md:67 收敛；「7 UT / 4 A3 ST」「12 任务合 1」「432 word pairs / 24 fixture」也无落点（接 F17/F26）。
Fix: 建 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记（外部原件标 external），落盘本对窗口、回执、恢复与 kernel 报告，导入前脱敏，并写明完整性标志现状。

F1 — high — 正式配对已开始，但候选仍是工作树清单、父 SHA 未具名

Where: 23:52 评论表列「Initial parent」/「Sinkhorn candidate」但无任何 SHA；23:12 候选为清单 ee625c96…；正文表「候选 Git SHA | 待正式验收后提交」；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35；AGENTS.md:87。
Problem: 第 1 对父臂未写是否为 d4ac4319a，候选不可 checkout，AGENTS.md:87 要求的 pinned candidate 不存在；把候选 SHA 排到验收之后形成循环。
Impact: 六档差值与后续 300 题无法在具名修订上复跑或被下游引用。
Fix: 继续配对前把 HC 候选与父链落成 codex/dsv41-0day 上的提交，正文登记父/候选 SHA，并回溯标注第 1 对所用修订。

F28 — high — 第 1 对在计划未冻结进 plan/ 前已测完

Where: 23:52 评论报告正式配对结果；23:12 评论「Direct-parent plan SHA-256 8074a88c…」；AGENTS.md:64（gates 在候选实验前锁进 plan/）；验收条件第 3 条；仓库内无该 campaign 的 plan/。
Problem: 三对顺序、判定式、阈值来源与 C1/C32 预设目标只在评论与裸摘要中，而测量已经开始，无法证明判据未随后续结果调整。
Impact: 后两对与保留判定缺少可核验的冻结时点。
Fix: 立即把计划与判定式（六档覆盖、逐档阈值、精度门禁）写入 plan/ 并在正文引用，明确第 1 对按冻结后判据计入还是按 pilot 处理。

F36 — high，需 owner 决定 — 「保留＝正式性能 PASS」与第 3 条冲突，本对数据已给出后果

Where: 正文 Current state「仅正式性能 PASS 且固定 300 题至少 292 正确才保留」；验收条件第 3 条与第 5 条（六档中位数均 ≤25 才判 PASS）；23:52 候选 87.832–124.272。
Problem: 若「正式性能 PASS」指第 5 条，第 1 对候选六档为目标 3.5–5 倍，任何中间候选都不能保留，而后续候选以被保留者为父，谱系无法累积；若指第 3 条，则「保留」与 PASS 被写成同义。
Impact: 第 1 对能否进入下一轮、HC 是否成为后续父版本取决于未定义口径。
Fix: 写成「保留按第 3 条、PASS 按第 5 条」，在正文与 plan/ 同文登记，并给出第 1 对在该口径下的结论。

F19 — high，需 owner 决定 — 正文第 2 条仍是旧两对公式与旧表，与 Current state 的三对新阈值并存

Where: 验收条件第 2 条（[x]，「两组、共四个独立服务」、max(1%, 两组内…)）；「## 已封存基线」C8 2.526% / C16 1.353% / C32 2.248%；Current state 与 23:12 评论 1.683 / 4.349 / 1.076%；评论 6617042949 记录 C16 那对首个输出到达相差 5.692 s。
Problem: 两套门槛与两份基线（93.862–129.043 与 94.009–128.602）并存，唯一生效公式未登记；三对逐档差值未公布，1.683/4.349/1.076 无法复算。本轮六档全部改善，暂不需回退判定，但下一对仍需选定一套。
Impact: 后续配对与最终 PASS 判读没有唯一、可复算基准。
Fix: owner 在正文与 plan/ 登记唯一公式、六档阈值与基线、生效时点及旧表适用范围，公布三对逐档差值。

F9 / F35 — medium，需 owner 决定 — 正式谱系只有 d4ac4319a → HC，正文「保留」集合与精度门禁未对齐

Where: 23:52 评论「No fixed-300 quality score or signed optimization commit … for this formal campaign」；正文「保留 HC 融合和…分页 KV 读取修正版 4a06cea1…」；23:12 计划只比较 d4ac4319a 与 HC。
Problem: 若 4a06cea1 仍在谱系内，HC 的直接父版本就不是 d4ac4319a；若已退出，正文应写明。两项「保留」项与本对候选都无 300 题结论，也未说明新精度规则是否追溯。
Impact: 下一候选的直接父版本与配对位置无法确定。
Fix: 声明保留集合与顺序，为 4a06cea1 登记直接父版本或标记退出，并给出保留项的 300 题结论/时间表。

F3 — high，隐私 — 11:15:56 的任务记录评论仍未脱敏（open）

Where: 评论 6602376192（created_at = updated_at，未编辑）；docs/privacy-security.md:8-13。
本次核实: 仍命中 2 个内网 IPv4、37 处 /Users/jiangchenzhou、5 个用户名实例、1 个 Pod 名；23:12 与 23:52 评论未新增泄漏（0 命中）。
Impact: 内网拓扑与个人路径持续公开，导入 evidence/ 会固化泄漏。
Fix: 作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 替换；导入证据树前复查。

F8 — medium，需 owner 决定 — 状态块仍无决策人，本轮新增待决项未登记

Where: 正文 **Decision needed:** … 与 **Next action:** …；docs/agent-collaboration.md:213-218；.github/knowledge-model-policy.json:50。
Problem: 未写 <question>, from <decision owner>；本轮至少新增正式链配置（F5）与保留口径（F36），连同门槛来源（F19）与保留集合（F9/F35）都未落成「问题 + owner + 时点」。
Impact: 读者无法判断正式配对何时可判读，status:proposed 也因缺决策人不能合法提出。
Fix: 逐条写「问题 + owner」，Next action 写明谁补 plan/、证据树与配置登记。

F38 — medium，建议 — 预热形状未按冻结条件 1 记录

Where: 23:52 评论「Each service ran a separate warmup and then a 1,024-in / 1,024-out measured wave at every tier」；正文验收条件第 1 条「每档先独立预热（C 条、32 输出），测量波为 C 条」。
Problem: 只写「a separate warmup」，没有写每档预热请求数（应为 C）与输出长度（应为 32），也没写测量波请求数是否等于该档 C；这是冻结协议的一部分，首对正式证据缺此记录。
Impact: 无法核对首对是否按冻结协议采集，只能靠父臂与基线量级接近间接推断可比性。
Fix: 在评论与 results/ 逐档记录预热请求数、输出长度与测量波请求数。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

意图：把 23:52 评论的首个正式 direct-parent Sinkhorn 配对结果写入正文状态块，作为本轮 campaign 的公开记录。该编辑只是把已复核过的评论同步进正文：六档降幅 6.33/9.94/8.18/11.53/8.20/2.93% 我逐项复算与表相符，正文也如实标注「仅一对观察、仍全部高于 25、无固定 300 题精度与签署提交」，因此结论仍为 needs information / human decision required，不是正式 PASS。早前项除 F37（已答）外均仍 open：F5/F34、F1、F2、F28、F19、F36、F9/F35、F38、F8、F3（隐私评论仍未脱敏，2 个内网 IPv4 / 37 处 /Users/…）；本次编辑未解决任何一项，并新增一处正文记录回退（F39）。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 需配 status:*，而状态块仍未写决策人，status:* 属决策人判断；本轮仍无任何正文句子请求代码改动（「本次同步不授权新增运行或改变范围」）。

F5/F34（继续，仍 open）— high，需 owner 决定 — 正文现在直接承载第 1 对六档数值，却未写该对的 FlashComm1/MC2 开关，父臂量级仍与 FC1 关基线一致

Where: 正文 Current state 的 93.768→87.832 … 128.018→124.272；正文「## 当前开关要求」（显式 FC1 开、enable_fused_mc2=0）；「## 初始修订与基线运行配置」表（「显式 FlashComm1 关」）；评论 6617042949（FC1 开父臂 51.183–70.858 / 候选 46.814–62.891）。
Problem: 父臂 93.768–128.018 落在 FC1 关封存基线（93.862–129.043）的 0.1%–1.5% 内，而全部 FC1 开读数在 51–71；正文既没有记录该对实际 enable_flashcomm1 / enable_fused_mc2，也没有环境签名与服务实例，编辑只把结果搬进正文而未补配置。
Conditions: 若该对在 FC1 关下运行，正文「当前开关要求」与该数据不是同一配置；若申报为 FC1 开，则同一 node 上既有 FC1 开证据相差约 1.4–2 倍。
Impact: 下游引用正文六档数值时无法绑定 RunSpec，也无法判断候选距 25 ms/token 目标的真实差距；第 2/3 对沿用同一歧义。
Fix: 在正文冻结表与评论逐臂写 enable_flashcomm1 / enable_fused_mc2、环境签名、服务实例与时间，并明确正式链采用哪套配置、旧 FC1 开读数为何不作判读基准。

F39（本次编辑新增）— medium — 正文改写删掉了候选定义与既有证据边界，正文不再自洽

Where: 正文 Current state 仅保留「d4ac4319a 对 HC 源码清单 ee625c96…、预设目标 C1/C32」；被删去的上一版文字包括候选定义「固定 4×4、20-round HC Sinkhorn 融合」、配对顺序「parent/candidate、candidate/parent、parent/candidate」、计划 SHA-256 指针，以及私有 replay「保留数值/提议差异、失败 service receipt 和未评分边界」的细节。对照 docs/contributing.md:96（记录全部尝试、拒绝项、原始样本与清理记录）与验收条件第 3 条（单一假设、预设受益档位）。
Problem: 在报告结果的同时，正文删去了该结果所测优化器的假设参数与配对顺序，把三对计划压缩为「预设三对中的第 1 对」，并把 replay 边界压成「仍为探索」；这些信息现在只存在于评论，不在正文。
Conditions: 后续配对或下游引用若只读正文，无法确认第 1 对测的是哪种 Sinkhorn 配置、第 2/3 对的确切顺序与计划摘要，也无法看出 replay 的失败 receipt 与未评分边界仍被保留。
Impact: 正文作为 campaign 的唯一公开入口，其冻结判据与边界记录回退到评论，可核验性下降（接 F28 与 F2）。
Fix: 在 Current state 恢复「4×4、20 轮 HC Sinkhorn、三对顺序、计划 SHA-256 指针」与 replay 失败 receipt / 未评分边界，或改为指向 plan/ 的稳定路径，使正文与评论不再分叉。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

当前最终提交 77a4dfde9 的固定 GSM8K 300 题精度已完成，294/300（98.00%），通过 ≥292/300 门槛。相比初始 295/300 少 1 题，下降 0.333 个百分点。此前保留的十项优化已形成 signed-off commits，本次测的是它们叠加后的最终提交。

按用户最新指示，性能在两轮完整测量后停止，直接切换独立精度服务。第三轮首档在停止信号到达时已启动，该部分已中断、保留且排除出统计，没有继续其他性能波。

并发	第1轮 TPOT	第2轮 TPOT	两轮中位 TPOT
1	46.550	46.478	46.514
2	45.734	45.649	45.691
4	47.380	46.882	47.131
8	48.506	49.496	49.001
16	50.817	50.812	50.814
32	63.996	63.849	63.922

单位 ms/token。两轮共126条正式请求、126条独立预热，正式均为1024入/1024出、零失败、零缓存命中，原始SSE逐请求复算通过。这是同一服务两次重复，不是直接父提交的三组配对验收。六档仍未达到25 ms/token，整体性能目标尚未达成。

配置为 TP4/DP4/EP16、DSpark5、FULL_DECODE_ONLY 24/48、16K、block128、batched8192（有效8160）、每DP最多8条。DSA CP、显式FlashComm1、shared expert DP开启，fused MC2关闭。committed source SHA为 99a5d50c7c55ff95dd2af700a22c85e9c883915ebfbe76f4e13ab29b1fed3ee0，73个部署文件匹配该提交。

精度沿用冻结 seed42 子集、题序、提示、AISBench原生Gsm8kEvaluator、thinking/low、贪心、4096输出上限及C32。300个唯一题目各有一次唯一请求与响应，无重发、请求错误0。6道错题中5道正常结束，1道达到4096上限并答错。原生与final正文评分均为294，原生无法提取数0，final正文无法提取数1。读取现有原始文件复算与汇总一致，没有重新请求模型。

精度服务ready之后的实际FULL日志覆盖16个rank，观察到24/48两桶。性能限频日志的覆盖按原样归档，第二轮C1/C16无新增标记，不声称同步全rank窗口计数。精度、服务及外层InferRSI均rc0，服务正常reaped、B/stock/idle恢复，无pending部署。

公开证据相对实验根目录：

perf25/scratch/current-head-results-001/final-assessment.json
perf25/scratch/current-head-results-001/rounds-02.json
perf25/quality/current-head-quality-001-gsm8k300/summary.json，SHA 60a9910946874edf2bee38c35c5f58983a07546bab18ab921858dba61c453b14
perf25/scratch/current-head-quality-001/raw-rescore-audit.json
perf25/results/current-head-quality-001/owner.json

EXECUTION_REPORT.md 和 RUNBOOK.md 已同步，原始题目与响应继续留在私有证据目录。

acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32 #329

Description

Campaign

2026-11-04 续轮授权与资料边界

当前开关要求

历史初始修订与基线运行配置（不作为续轮当前配置）

验收条件

历史四服务封存基线（FlashComm1 关）

证据索引

后续轮次新增规则（2026-11-04）

续轮详细口径快照

DSV4.1 续轮优化实验罗盘

1. 目标、起点与结论

2. 资料访问边界

2.1 每轮知识命中记录

3. 版本与环境身份

4. 固定服务配置

5. 性能工作负载与计时

6. 校准、历史参照与正式配对

7. 精度测试

7.1 性能未通过时跳过精度

8. 实际生效与功能核验

9. 续轮执行顺序与判定

10. 执行入口与证据归档

11. 本轮完成项与下一步

Activity

jiangkuaixue123 commented on Nov 3, 2026

候选进度 · 2026-11-03

第一轮 · Model · 融合 HC Sinkhorn 归一化

第二轮 · Model · 按字段 stride 读取分页 KV

Dong1017 commented on Nov 3, 2026

jiangkuaixue123 commented on Nov 3, 2026

第二轮短对照完成 · 显式 FlashComm1 开，fused MC2 关

Dong1017 commented on Nov 3, 2026

jiangkuaixue123 commented on Nov 3, 2026

第三轮筛选 · 以每块一个布尔值表示 decode 索引候选

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

jiangkuaixue123 commented on Nov 3, 2026

六档单轮结果与 C32 设备归因

agent-ci-infra-bot commented on Nov 3, 2026

jiangkuaixue123 commented on Nov 3, 2026

InferRSI：DeepSeek-V4.1-Flash 在 vLLM Ascend 上的 0-day 适配任务记录

1. 记录用途与当前阶段

2. 用户目标与明确要求

2.1 任务目标

2.2 用户提供的硬件条件

2.3 严格资料限制

2.4 已确认的精度与输入范围

2.5 已确认的开发基线、Pod 与模型路径

3. 已执行的前期检查

3.1 iTASK 使用规范

3.2 本地工具与身份快照

3.3 指定目标前的 iTASK 任务列表快照

3.4 vllm-ascend 工作区快照

3.5 目标任务、远端仓库与安装方式实查

3.6 本地代码上传方案与验证结果

4. 指定 HF 仓库中已核实的信息

4.1 模型与权重配置

4.2 官方参考实现的用途与限制

4.3 资料访问记录

5. 六项问题及当前确认状态

5.1 使用哪个任务

5.2 权重位置和版本

5.3 基本功能范围

5.4 精度验收依据

5.5 代码修改边界

5.6 InferRSI 的实验边界

6. 仓库开发约束

7. 后续建议执行顺序

8. 当前完成状态

9. 更新记录

10. 首轮执行进展

11. 模型本体实现进展

12. 真实 40 层服务验证

13. GPQA 全量实测已启动

14. 插件迁移与 FULL_DECODE_ONLY

15. 多尺寸 FULL_DECODE_ONLY 与 16 并发实测

16. 并行优化与 DSpark

17. 全开配置的 GPQA Diamond 198