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

@jiangkuaixue123

Current state: 截至 2026-11-03 18:30 UTC，负责人公布 FSQ 父版本无插桩六档探索性 sweep：C1/2/4/8/16/32 为 63.97 / 62.80 / 65.26 / 67.42 / 69.03 / 88.14 ms/token，全部高于 25。63 个测量请求成功、每个 1024 入/1024 出，显式 FlashComm1 开、fused MC2=0；启动门禁验证四个 DP 的 FULL replay，但 C4/C8/C16 的测量采样窗口只覆盖部分活跃 DP。此轮是 FSQ 父版本，不是 compact 候选；compact 原单波筛选仍为 C1/C32 59.86 / 80.42，对应当轮 FSQ 对照 64.26 / 86.59，compact 中间四档未测。作者提供完整 FSQ 工作树清单及客户端回执摘要，但不是可检出提交；没有新精度分数或已接受优化提交。新同版本校准仍仅已公布第 1/3 组，未见后续封存，其与历史两组调整的生效关系仍待明确。早前诊断、筛选、失败和取消记录保留，整体 INCONCLUSIVE。
Decision needed: 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。
Next action: 现有负责人 @jiangkuaixue123 继续在原线程记录已启动工作的结果及证据，区分筛选、算子探针、正式六档配对和精度；保留失败、取消及版本边界。本次同步不授权新增运行或改变范围。

Campaign

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

当前开关要求

按最新要求，显式开启 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（工作源码清单 SHA-256）。原配置的基线与单轮筛选数据保留在下方；新增测量须标明 FlashComm1 显式开启、fused MC2 关闭。比较 KV 读取优化时两个版本使用同一配置。

初始修订与基线运行配置

项目	冻结值
vllm-ascend 初始基线	`d4ac4319acdaf480689c39b6320a998712f80523`
上游 vLLM / InferRSI	`6e448d0ea9bf3d88d898b65449ca6dc2aec170ac` / `919ed42c0d01dc0aa3b613085b9041d735d2d4db`
候选 Git SHA	待正式验收后提交。目前按工作树源码清单的 SHA-256 标记候选，每轮另记其父版本和变化范围。
设备与精度	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%, 两组内以先测轮为分母的绝对相对差最大值)。第三组启动期停止。该调整仅用于本次初始校准。
每个保留的优化提交记录单一假设、预设受益档位、直接父版本和完整的六档交替配对。正式协议至少三组，阈值附近或方向不稳定时追加。预设档至少一档在多数配对中改善、配对改善率中位数超过该档门槛；各档回退中位数不得超过门槛，父版本已达 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。

已封存基线

全服务并发	第 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、正式验收的父/候选提交和对应结果。当前已有筛选结果，正式候选提交与最终六档验收仍待完成。

候选进度 · 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

本 Issue 跟踪 DeepSeek V4.1 Flash 在 910C 上六档 decode TPOT ≤25 ms/token 与 GSM8K ≥292/300 的验收；本次正文编辑把 B→F2（70.87/95.63 ms/token）与 F2→FS（65.52/92.59）两轮单波筛选及其测试结果写入状态块，数值与对应评论一致，整体仍自述 INCONCLUSIVE。结论：needs information / 需 owner 决策——候选仍不可检出、证据树仍不在仓库、精度门禁顺序与跨配置门槛归属仍无记录；正文没有请求代码变更的句子，不构成开发授权。上轮 F14（状态块落后于已公布结果）已修正为 fixed；F1、F2、F9、F5、F12、F13、F8、F3、F7、F4 以及 F6/F11 仍 open。

F1 — 阻塞性前提：F2/FS/FSQ 仍只有 12 位工作树清单前缀，没有可检出的提交（上轮 F1 仍 open）

位置： 正文状态块「候选仍以工作树清单标识，未记录正式候选提交及最终六档验收」与表格「候选 Git SHA | 待正式验收后提交」；本轮筛选的 3c4e0c00dab6（F2）、43419c27e273（FS）、b054b5a45f45（FSQ）只以 12 个十六进制字符出现；AGENTS.md:87、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32（candidate_sha 要求 Full git SHA）。
问题： 这些前缀既不是完整清单摘要（正文只对 B 保留完整摘要 4a06cea113696b…），也不对应任何提交；评论 6610001726 明说 FS「frozen from the local codex/dsv41-0day worktree」。验收条件第 3 条要求记录「直接父版本」，第 4 条要求在「最终提交」上重测，而正文又把正式候选 SHA 排到验收之后，形成循环。
影响： 即使 FS 的 7.56%/3.18% 被保留，六档、功能测试与精度都无法在具名修订上复现，PASS 前提不成立。
修复： 在任何「保留」判定前把 F2/FS/FSQ 落成 codex/dsv41-0day 上的提交，记录完整 SHA、父 SHA 与全 64 位清单摘要。

F2 — campaign 证据仍不在仓库，本轮也没有任何归档路径或 SHA-256（上轮 F2 仍 open）

位置： 正文「证据索引」（perf25/release.json、perf25/results/…，声明为「相对实验归档根目录」）；本轮 F2/FS 两臂原始波、16 rank 的 dispatch 日志、3 UT / 4 A3 图测试与 FSQ 的 9 UT / 16 A3 ST 回执均无路径或摘要；AGENTS.md:89、docs/contributing.md:105-107,117。
本次实际核实： 运行 python tools/validate_evidence.py → errors: []、21 个 bundle、430 个已校验哈希，其中没有 dsv41/perf25 条目；本检出没有 perf25/ 目录，evidence/dsv41-910c-decode-tpot25 不存在；tools/validate_evidence.py:126 对未知 bundle kind 直接抛错，故日后导入也须先登记分类。
影响： 决定本轮走向的 11.44%/14.81% 与 7.56%/3.18% 只存在于评论正文，无法复核、无法作下游引用；正文又要求下游引用这些结果。
修复： 补写 results/、trials/、preflights/ 的路径与 SHA-256，失败/跳过测试单列 failure receipt；判 PASS 前把归档导入 evidence/dsv41-910c-decode-tpot25/ 并在 tools/evidence_inventory.json 登记（外部原件按 external 声明）。

F9 — 精度门禁被改为「性能通过后再测」，但冻结验收条件仍要求每个保留提交 ≥292/300（上轮 F9 仍 open；需 owner 决定）

位置： 正文验收条件第 4 条（「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」）；新状态块「精度仍待正式性能门禁」；评论 6607845822「The updated validation controller gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:100-101。
问题： 冻结门禁清单要求每个保留提交都有 300 题结论，控制器却在候选搜索之后把精度改成性能配对通过后的后置项；被取消的 298 条轨迹既未计入 300 题，也没有归档或作废说明。F2（融合索引读取与 BF16 score、按 visible length 提前结束内循环）与 FS（选中 KV 与稀疏 ID 直接由两个 page bank 准备）、FSQ（FP8 算术）都属数值/语义路径改动，本轮均无精度结果。
影响： 可能出现「性能通过但从未产出 300 题结论」的候选；现有 294/300 距门槛只有 2 题余量，这类改动的精度回退只能在测试集上暴露。
修复： 由 owner 二选一并写入正文与 plan/：(a) 确认「性能通过后再测 300 题」为正式协议，并写明最终版本仍独立跑 300 题与 298 条轨迹的处置；(b) 维持「每个保留提交即测 300 题」。改算术/改可见长度计算的候选在保留前必须跑冻结 300 题。

F5 — 封存波动门槛仍绑定 FlashComm1 关的旧配置，本轮却已用它判断 FS 的 3.18%（上轮 F5 仍 open；需 owner 决定）

位置： 正文「初始修订与基线运行配置」表仍写「Ascend 开关 | DSA CP 开、显式 FlashComm1 关」「环境校验 | 公共环境签名 44411269…」，「已封存基线」表门槛 C1 1.000% / C32 2.248%；而「当前开关要求」与全部测量轮次为显式 FlashComm1 开、enable_fused_mc2=0，环境签名已出现 a3d9fcf0…、da05a8aa…。
问题： 门槛来自 FC1 关的两组四服务校准，正式比较却在 FC1 开下进行，正文冻结值表与「当前开关要求」并存，同一门槛可被绑到两套配置。本轮 C32 的 FS 3.18% 仅比旧门槛 2.248% 高 0.93pp，是否「改善」完全取决于口径；新状态块又写「原提交同版本六档噪声校准另行安排」，等于承认当前配置尚无自己的门槛。AGENTS.md:64、docs/contributing.md:100-101 要求门禁在候选搜索前冻结，事后沿用须显式记录。
影响： FS 的保留/淘汰会取决于口径选择而非测量；PASS 时阈值版本、环境签名与基线批次各自绑定哪套配置无法追溯。
修复： 由 owner 在正文与 plan/ 记录其一：(a) 声明封存门槛对 FC1-on/fused-MC2-off 继续有效（注明其来自两组四服务、第三组启动期停止、C4/C8/C16 限频日志缺口使完整性标志为 false）；(b) 按第 2 条同一公式在 FC1-on 下先发布门槛。并说明「另行安排的六档噪声校准」是否就是正式阈值、在哪个判定前生效。

F12 — FS 的 F2 对照臂数值与 16:32 评论逐位相同，配对可能跨会话；本轮仍未按正文要求标明开关与环境签名（上轮 F12 复发）

位置： 新状态块「70.87→65.52 / 95.63→92.59」「每档只有一波」；评论 6609641928（16:32）的 F2 同为 70.87 / 95.63；正文「当前开关要求」与「新增测量须标明 FlashComm1 显式开启、fused MC2 关闭」。
问题： (a) F2 臂两个档位与上一轮精确相同（0.00 ms），而 B 自身跨会话重复已有约 1.0%（C1 79.23→80.04）、1.24%（C32 110.89→112.26）的波动，因此更像沿用旧波而非本轮同会话重测；若为沿用，C32 3.18% 的降幅有相当部分可由会话漂移解释。(b) 正文只写「每档只有一波」，未给 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0 的实际取值，也没有环境签名。
影响： FS 的收益无法绑定到具体 RunSpec/配置版本，而 C32 只有 3.18% 时，跨会话漂移正是唯一能决定去留的差异。
修复： 明确 F2 臂是本轮同会话重测还是引用 16:32 的波；若沿用，补一次 F2→FS 同会话重测（或标注为跨会话并给出漂移对照），并在报告中补环境签名与两个开关实际取值。

F13 — FS 的等价性证据没有覆盖它改动的语义面：C32 为 0/32 输出哈希相同，且缺噪声底（上轮 F13 未决，本轮风险更高）

位置： 新状态块「C1 输出一致，FS 的 C32 完整输出哈希 0/32 一致」；评论 6610001726「prepares selected KV and logical sparse IDs directly from both page banks」「3 targeted UTs and 4 A3 graph tests」；正文冻结配置（block 128、每请求精确 1,024 入 / 1,024 出，即 8 个整块、无前缀缓存）。
问题： FS 改的是选中 KV 与逻辑稀疏 ID 的准备路径（两个 page bank），语义影响大于此前 F2 的截断改动，但等价性证据只有 C1 逐 token 相同与 3 UT / 4 A3 图测试。性能负载从不出现尾部不完整块或 KV 复用，C32 又是 0/32 哈希相同，且没有 B-vs-B 的 C32 控制臂建立哈希一致率噪声底（历史同版本重复为 5/32、2/32、1/32）。
影响： 若 KV 准备在两 bank 下的掩码/稀疏 ID 语义有偏差，聚合 TPOT 不会暴露，而会在固定 300 题精度（294/300，距门槛 2 题）或下游质量上出现；FS 还会作为后续合并候选的对照臂。
修复： 补一组 F2 对 FS 的逐 token 对照：不同 visible length、非 128 整数倍提示长度、带前缀缓存命中；再加一次 B-vs-B 的 C32 重复作为噪声底，并在保留 FS 前跑冻结 300 题（顺序依 F9 结论）。

F8 — Decision needed 行仍不是可判定问题、也没有决策人（上轮 F8 仍未解决）

位置： 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:216 要求 **Decision needed:** <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 记 approval owner 为 Dong1017。
问题： 该行既不是可判定的问题，也没有决策人；F5（跨配置门槛归属）、F9（精度门禁顺序）、F4（另一 RunSpec 记录归属）、F1（候选 pin 时机）等待决项仍只散落在评论里。
影响： 读者与后续评审无法区分「已定」与「未定」，也无法判断是否具备推进正式配对的条件。
修复： 改写为逐项问题并指定 owner（Dong1017 或指派的验收负责人）；Next action 写谁做什么。

F3 — 历史评论 6602376192 仍未脱敏（上轮 F3 仍 open）

位置： 评论 6602376192 第 3.2、3.3、3.5、5.2、10–12 节及其文件链接（用户专属绝对路径、本地用户名、Pod 全名、两个节点 IP、模型挂载路径）；docs/privacy-security.md:12-13；AGENTS.md:119-125。
问题： 该评论未被编辑，真实 IP、主机名、用户名与个人绝对路径仍公开可见。本轮状态块只用相对描述与清单前缀，未新增泄漏（这点正确）。
影响： 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
修复： 编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 等占位符替换；此后粘贴记录前先脱敏，并在导入证据树前复查同源文件。

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

位置： 正文验收条件第 4 条（AISBench 原生 Gsm8kEvaluator、zero-shot CoT、thinking/low、贪心、4096 上限、并发 32、seed 42）；「初始修订与基线运行配置」表只列 CANN/驱动/Python/torch/torch-npu；本轮 FS 无精度结论，后续仍沿用 C 的 294/300。
本次实际核实： 本检出中 grep 不到任何 AISBench 引用，Issue 也未给出其 revision 或 Gsm8kEvaluator 抽取/判分代码摘要，因此该 294/300 无法从仓库侧复算。
影响： CoT 截断、答案抽取或 4096 上限处理的版本差异足以翻转 2 题，届时无法区分差异来自候选代码还是判分实现。
修复： 在精度证据中记录 AISBench revision 与抽取/判分代码摘要（关联 PR Add an optional AISBench service benchmark adapter #326 已把 v3.1-20261013-master@5a63d936… 作为 pin，可作候选），并写进环境表。

F4 — 另一 RunSpec 的 0-day 适配记录仍与本 campaign 证据混在同一 Issue（上轮 F4 仍 open；需 owner 决定）

位置： 评论 6602376192《0-day 适配任务记录》第 2.1、5.4、10 节与「PD 混部 8192」段；对比正文「初始修订与基线运行配置」表与「验收条件」。
问题： 该记录定位为「不要求优化性能」、精度门禁 GPQA 88.89、并行策略 TP8/DP2/EP16，实测 GPQA 163/198（82.32%）；本 Issue 冻结的是 TP4/DP4/EP16、FC1 开 + enable_fused_mc2=0、GSM8K 292/300 与六档 TPOT ≤25 ms/token，两者不是同一 RunSpec 也不是同一组门禁。
影响： 记录中的 43.60 ms/token、82.32% 与六档表并列时会被下游误读为本 campaign 的进展。
修复： 由 owner 决定：把该记录移入独立 Issue/归档并在此只留指针，或在本 Issue 声明它不属于本 campaign 证据；在此之前不要并入证据索引。

F6/F11 — 步级归因与探针口径仍未对账（上轮 F6、F11 仍 open）

位置： 评论 6606963791「每个验证步的 13 次长索引读取合计 49.74–49.76 ms」「12 行、ratio 1、约 1029 上下文的索引路径中位数由 9.13 降至 2.84 ms」；评论 6608856036「At 12 rows and ~1K context the two-layer graph took 46.65 → 31.51 ms for ratio 1」；评论 6600643803「target FULL 回放中位数 293.12 ms/次、草稿提议 65.54 ms/次、C32 102.116 ms/token」。
问题： (a) 293.12 ms/step → 102.1 ms/token 仍缺对算式与推导步数，65.54 ms 的单位（每步一次 vs 每次提议）未标；(b) 同为 12 行、ratio 1、约 1K 上下文，基线一为 9.13 ms、一为 46.65 ms（5.1 倍），降幅一为约 69%、一为 32.5%，未说明「two-layer graph」范围与旧数值是否作废；(c) 本轮 FS 对两 bank selected-KV 准备的收益也无法与归因量对账。
影响： 单 rank 归因无法换算成可核算的 TPOT 收益上限，F2/FS 的选择依据缺少可核对的量级，G 的整模回归已证明这类外推会失效。
修复： 补一张单位表（per graph / per step / per token）与对算式，给出探针完整形状表（rows、ratio、context、层数、单次/批量、对应图中哪个算子），并说明 profile 服务与正式计时在 capture size、预热、并发构成上的一致性。

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

本 Issue 跟踪 dsv41-910c-decode-tpot25 的六档 decode TPOT ≤25 ms/token 与 GSM8K ≥292/300；17:01 更新新增 FSQ（FS 上加 BF16 group32 E4M3 的 raw KV/输出投影路径）C1/C32 单波筛选 64.26/86.59 ms/token（相对 FS 1.93%/6.48%），仍自述 INCONCLUSIVE、无提交晋升、精度未测。结论：needs information / 需 owner 决策——正文无请求代码变更的句子，不构成开发授权；F1、F2、F9、F5、F12、F13、F14、F8、F3、F4、F7、F15、F6、F11 仍 open（F14 收窄为 FSQ 计时与已启动校准未同步；F12 因 FS 臂沿用 16:47 数值而直接决定 C1 结论）。我实跑 python tools/validate_evidence.py：errors: []、21 个 bundle、430 个哈希，仍无本 campaign 条目。未返回标签（kind:acceptance、area:workbench 已由人设置；priority:* 依 .github/labels.json:73-84 须配合 status 标签，本 Issue 无）。

F1 — high, must-fix — 候选仍只有 12 位工作树清单前缀（上轮 F1 open，连续第五轮）

Where: 触发评论 b054b5a45f45、「frozen from the local development branch」、「No optimization commit has been promoted」；正文表「候选 Git SHA | 待正式验收后提交」；AGENTS.md:87；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32。
Problem: 12 位十六进制既不是完整 64 位清单摘要，也不对应 git 提交，无法表达验收条件第 3 条的「直接父版本」。
Impact: FSQ 的 1.93%/6.48%、9 UT/16 ST、精度复测与最终六档都无法在具名修订上复跑或引用，PASS 前提不成立。
Fix: 任「保留」判定前把 FS/FSQ 落成 codex/dsv41-0day 上的提交，记录完整 SHA 与父 SHA，保留完整清单摘要作交叉校验。

F2 — high, must-fix — 本轮仍无归档路径或 SHA-256，证据树与清单条目仍缺（上轮 F2 open，连续第四轮无归档）

Where: 触发评论全文（没有 perf25/... 路径、64 位摘要、9 UT/16 ST 与 16 rank dispatch 回执位置）；正文「证据索引」；AGENTS.md:89；docs/contributing.md:105-107。
本次核实： python tools/validate_evidence.py → errors: []、21 个 bundle、430 个哈希；无 perf25/，evidence/ 下无 dsv41-910c-decode-tpot25；tools/validate_evidence.py:126 拒绝未知 kind、:147 报告未分类 manifest。
Impact: 1.93%/6.48% 与 FSQ 功能测试只存在于评论正文，无法复核或作下游引用。
Fix: 补 results/、trials/、preflights/ 路径与 SHA-256、跳过/失败回执；判 PASS 前导入 evidence/dsv41-910c-decode-tpot25/ 并在 tools/evidence_inventory.json 登记（外部原件可用 external）。

F9 — high, must-fix (需 owner 决定) — 精度门禁顺序仍未记录，而 FSQ 是改算术的候选却只有 UT/ST（上轮 F9 open）

Where: 触发评论「The BF16 group32 E4M3 path … raw KV and output projection」「Accuracy remains unmeasured on FSQ」；评论 6607845822（控制器把 300 题改为「配对性能通过后」才跑）；正文验收条件第 4 条（每个保留提交及最终版本 ≥292/300）；docs/contributing.md:100-101。
Problem: 冻结门禁要求每个保留提交都有 300 题结论，控制器在候选搜索后被改动且未入 plan/；G 轮被取消的 298 条轨迹无处置；FSQ 改 KV 与输出投影数值路径，却只有 9 UT/16 A3 ST，正文的 294/300 属于 C 而非 FSQ。
Impact: 会出现「性能通过但无 300 题结论」的候选；当前余量仅 2 题。
Fix: 由 owner 在 plan/ 记录：维持「每个保留提交即测 300 题」，或确认新顺序并写明 298 条轨迹处置；两者都要求改算术候选在保留前跑冻结 300 题。

F5 — high, must-fix (需 owner 决定) — 封存门槛归属仍未记录，而正式同版本六档校准现在才开始（上轮 F5 open）

Where: 正文冻结表（显式 FlashComm1 关、环境签名 44411269…）、「已封存基线」门槛 1.000%–2.526% 与验收条件第 2–3 条；触发评论「the original d4ac commit's first formal six-tier calibration pair」；评论 6608856036、6609641928 两臂为 FC1 开、enable_fused_mc2=0。
Problem: 门槛来自 FC1 关的校准，全部候选却在 FC1 开下测量；本轮启动的 d4ac 六档校准未写配置/签名、是否即「另行安排」的噪声校准、其阈值是否取代封存表。若新阈值在五轮筛选后才用于 3.18%/1.93% 这类判定，就成事后阈值（AGENTS.md:64、docs/contributing.md:100-101）。
Impact: FS/FSQ 去留取决于口径而非测量：C1 1.93% 仅略高于旧门槛 1.000%，与 B 约 1% 的跨会话漂移同量级。
Fix: owner（.github/knowledge-model-policy.json:50 为 Dong1017）记录其一：封存门槛继续有效（注明来源与完整性标志 false），或按第 2 条公式另发布阈值并把先前各轮标为探索性；并写明这次校准的配置与生效时点。

F12 — high, must-fix — FSQ 的对照臂是 16:47 的 FS 数值，属跨会话配对，且开关与环境签名仍未标明（上轮 F12 open，现直接决定 C1 结论）

Where: 触发评论表 FS 65.52/92.59 与评论 6610001726 逐位相同，而该评论称「The service was reaped and B restored」；触发评论仅写「same environment」；正文「当前开关要求」要求新增测量标明 FC1 显式开、fused MC2 关。
Problem: FS 臂未重测、FSQ 在另一台服务上测得，1.93%/6.48% 是跨会话差值；仍未给 enable_flashcomm1/VLLM_ASCEND_ENABLE_FLASHCOMM1/enable_fused_mc2 取值与环境签名（冻结表为 44411269…）。B 跨会话已见 79.23→80.03（C1 约 1.0%）、110.89→112.26（C32 约 1.24%）。
Impact: C32 6.48% 超出噪声，但 C1 1.93% 与旧门槛 1.000% 及已观测漂移同量级，不能支撑 FSQ 在 C1 的保留；收益绑定不到 RunSpec。
Fix: 明确 FS 臂是否沿用；若沿用则标为跨会话并给漂移对照，或补一次 FS→FSQ 同会话配对；补环境签名与两个开关实际取值。

F13 — high, must-fix — FSQ 的等价性证据不覆盖它改动的数值面：C32 0/32 输出哈希相同，且无噪声底（上轮 F13 open，本轮风险最高）

Where: 触发评论「At C1 outputs … identical. At C32 … no complete output hashes matched」「Accuracy remains unmeasured on FSQ」；正文冻结配置（block 128、1,024 入/1,024 出 = 8 个整块）；历史 C32 一致数为 C 8/32、G 4/32、R 1/32、F2 1/32、FS 0/32，同版本重复只有 5/32、2/32。
Problem: 改动是 KV 与输出投影的数值路径，等价性证据仅 C1 逐 token 相同与 9 UT/16 A3 ST；负载无部整块尾部、无前缀缓存；0/32 无控制臂噪声底，也未覆盖部分块与投机接受不齐。
Impact: E4M3 量化偏差不会体现在 TPOT，只会暴露在固定 300 题（294/300，余量 2 题）；FSQ 还会作为后续对照臂。
Fix: 补 FS 对 FSQ 逐 token 对照（不同 visible length、非 128 倍数提示、前缀缓存命中），加重复波哈希一致率噪声底，保留前跑冻结 300 题（顺序依 F9）。

F14 — medium, must-fix — 正文状态块仍落后一步：FSQ 计时已公布、正式校准已开始（上轮 F14 收窄）

Where: 正文 **Current state:** 的「FSQ …尚未公布端到端计时或精度；作者称原提交同版本六档噪声校准另行安排」；触发评论给出 FSQ 64.26/86.59 并称已启动 d4ac 首次正式六档校准；docs/agent-collaboration.md:213-218。
Problem: 正文称 FSQ 计时未公布、校准另行安排，两者均已与最新评论不符（精度确实仍缺）。
Impact: 权威状态行误导读者，看不出当前最优筛选值与校准进度。
Fix: 更新 Current state/Next action：写入 FSQ 单波数值并标注「单波筛选、非配对」、精度未测、校准已启动（配置/档位/责任人）及距 25 ms/token 的倍数。

F8 — medium, must-fix (需 owner 决定) — Decision needed 行仍不是可执行问题、也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 为 Dong1017。
Problem: 该行不是可判定问题，也无决策人；F5、F9、F4、F1 等待决项仍散落在评论里。
Impact: 读者无法区分已定与未定，也无法判断是否具备推进正式配对的条件。
Fix: 改写为逐项问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F3 — medium, must-fix — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

Where: 评论 6602376192 的第 3.2、3.3、3.5、5.2、10–12 节及其文件链接（个人绝对路径、本地用户名、Pod 全名、节点 IP、模型挂载路径）；docs/privacy-security.md:10-16；AGENTS.md:120-125。
Problem: 该评论未被编辑，敏感值仍公开；本轮触发评论只用清单前缀与相对描述，未新增泄漏。
Impact: 个人路径与内部拓扑持续公开；未脱敏记录若导入 evidence/ 会把泄漏固化。
Fix: 编辑该评论，用 <REMOTE_HOST>/<REMOTE_USER>/<MODEL_PATH> 等占位符替换，并在导入证据树前复查同源文件。

F4 — medium, must-fix (需 owner 决定) — 另一 RunSpec 的 0-day 适配记录仍混在同一 Issue（上轮 F4 open）

Where: 评论 6602376192 第 2.1、5.4、10 节与「PD 混部 8192」段；对比正文冻结表与验收条件。
Problem: 该记录定位为「不要求优化性能」、GPQA 88.89、TP8/DP2/EP16；本 Issue 冻结 TP4/DP4/EP16、FC1 开、GSM8K 292/300 与六档 ≤25 ms/token，并非同一 RunSpec 或门禁。
Impact: 43.60 ms/token、82.32% 与六档表并列会被误读为本 campaign 进展。
Fix: 由 owner 决定移入独立 Issue/归档并只留指针，或在本 Issue 声明其不属于本 campaign 证据；此前不并入证据索引。

F7 — medium, must-fix — 计分工具身份仍未 pin，294/300 不可复算（上轮 F7 open）

Where: 验收条件第 4 条（AISBench 原生 Gsm8kEvaluator、CoT、贪心、4096、并发 32、seed 42）与证据索引 aisbench/gsm8k/subset300/…；环境表只有 CANN/驱动/Python/torch/torch-npu。
Problem: 没有 AISBench revision 或抽取/判分代码摘要；FSQ 精度未测，后续任何 300 题运行仍不可复算，而余量仅 2 题。
Impact: 版本差异（CoT 截断、答案抽取、上限处理）足以翻转 2 题且无法归因。
Fix: 在精度证据与环境表记录 AISBench revision 与判分代码摘要；已核对 Add an optional AISBench service benchmark adapter #326 为 open draft、未合并，其 docs/aisbench.md 以 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为 pin 可作候选；[RFC] Integrate AISBench as an optional benchmark tool #289 为 open RFC。

F15 — medium, suggestion — FSQ 的唯一运行时改动定义不清：量化对象、粒度与开关未给（新）

Where: 触发评论「The BF16 group32 E4M3 path ran at both full-decode buckets for raw KV and output projection across all 16 ranks」「adds one runtime change to FS」；验收条件第 3 条要求每次迭代单一假设与预设受益档。
Problem: 未说明量化的是 KV 值、输出投影权重还是其输入/输出，group32 沿哪个轴分组、scale 来源，是否由配置开关控制、默认是否改变；「BF16 group32 E4M3」本身也存歧义。
Impact: 无法判断这是数值近似（精度风险面）还是仅存储格式变化，也无法按验收条件核对假设与受益档。
Fix: 写明精确数值改动（输入/输出 dtype、分组轴与 scale 来源）、配置开关与默认值，以及预先声明的受益档。

F6 — medium, suggestion — C32 步级归因仍无法换算成 TPOT（上轮 F6 open）

Where: 评论 6606963791「每个验证步的 13 次长索引读取合计 49.74–49.76 ms」；评论 6600643803（target FULL 293.12 ms/次、草稿提议 65.54 ms/次、C32 102.116 ms/token）；本轮 FSQ C32 约 3.04 ms/token 收益。
Problem: 仍缺 293.12 ms/step → 102.1 ms/token 的对算式与推导步数，65.54 ms 的单位未标，31.68–31.71 ms per graph 又引入第三种口径。
Impact: 单 rank 归因无法换算成可核算的 TPOT 收益上限，下一步优化依据不完整。
Fix: 补单位表（per graph/step/token）与对算式，并说明 profile 服务与计时服务在 capture size、预热、并发构成上的一致性。

F11 — medium, suggestion — 同一索引图形状的基线在两条评论间相差 5 倍（上轮 F11 open）

Where: 评论 6608856036「12 rows and ~1K context the two-layer graph took 46.65 → 31.51 ms」；评论 6606963791「12 行、ratio 1、约 1029 上下文的索引路径中位数由 9.13 降至 2.84 ms」。
Problem: 同形状基线一为 9.13 ms、一为 46.65 ms，降幅一为 69%、一为 32.5%；未说明层数、是否含 score/bitmap/top-512、哪个数值作废。
Impact: 探针收益上限无法与 C32 归因或 TPOT 对齐。
Fix: 给形状表（rows、ratio、context、层数、单次/批量、对应算子）并说明旧数值是否作废或收窄适用范围。

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

Initial commit, formal same-version calibration pair 1 of 3

Both fresh services used the original local commit d4ac4319a, identical source manifest 837262142355 and restored common environment da05a8aa0892. Each completed all six warmed, cold-prefix 1024-input/1024-output waves. All requests succeeded, all measured token counts and SSE times were audited, both owners released and the B tree was restored.

Global concurrency	First arm (ms/token)	Second arm (ms/token)	Absolute difference vs first
1	94.05	94.31	0.28%
2	95.75	95.71	0.04%
4	97.24	97.20	0.04%
8	101.66	102.18	0.51%
16	103.33	102.10	1.19%
32	129.23	128.25	0.76%

This is one observed pair. Per-tier acceptance thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor. The calibration remains unsealed. The current FSQ product's fresh C32 profile is being collected separately from client timing.

触发更新在同环境 da05a8aa0892、原始提交 d4ac4319a 上完成首对同版本六档校准（C1 94.05/94.31 … C32 129.23/128.25），我按「先测轮为分母」复算了六档差值与表中 0.28%/0.04%/0.04%/0.51%/1.19%/0.76% 逐一相符，数值自洽，这是对上一轮门槛口径问题的实质推进。但该评论把门槛定义为「三对完整日历校准的最大值」，与正文已勾选的验收条件第 2 条（两组/四服务）不同，且其 TPOT 水平与冻结的 FlashComm1-关基线一致、与全部 FC1-开测量相差 15%–19%，因此这批阈值很可能仍绑定在旧配置上；候选 pin、证据树、精度门禁顺序三项前提依旧不成立，整体只能维持 INCONCLUSIVE / needs information。结论：needs information / human decision required；正文没有任何请求修改代码的句子，不构成开发授权。

F5 — high，must-fix（需 owner 决定）— 门槛公式在候选筛选后被改为「三对最大值」，与已冻结的验收条件第 2 条不符

Where: 触发评论末段「Per-tier acceptance thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor.」；正文验收条件第 2 条（已勾选 [x]）：「本次同版本基线取两组、共四个独立服务；各档门槛为 max(1%, 两组内以先测轮为分母的绝对相对差最大值)……第三组启动期停止。该调整仅用于本次初始校准。」
Problem: 冻结的基线校准是两组（4 台独立服务）并对组内差取最大值；本评论改为「三对完整校准的最大值」。样本数由 4 台变 6 台，统计量也不同，而且是在第五至第六轮候选筛选之后、FSQ 的 1.93%/6.48% 已公布之后才首次给出。对更多对取最大值只会使阈值不减（现有封存值 C4 1.138%、C8 2.526%、C16 1.353%、C32 2.248% 均由两对得出），方向上是系统性放宽保留门槛。
Conditions / impact: 当配对降幅落在门槛附近时结论会翻转——FSQ C1 1.93%、FS R 2.82%–3.29%、FS C32 3.18% 都属于该区间。AGENTS.md:64（Freeze gates before search）与 docs/contributing.md:100-101（numeric gates 在候选搜索前冻结）要求这类改动被显式记录，否则保留/淘汰取决于事后选哪套公式。
Fix: 由 owner 在正文与 plan/ 记录其一：(a) 维持第 2 条的两对公式；(b) 确认改为三对最大值，并同时把一至六轮标为探索性、写明新阈值发布时间与生效判定。附注：仅按本对计算时各档门槛为 C1/C2/C4/C8/C32=1.000%（1% 下限）、C16=1.190%，第二、三对完成后才能给出三对最大值。

F16 — high，must-fix（需 owner 决定）— 校准对的 TPOT 水平指向 FlashComm1-关的旧配置，而非全部候选筛选所用的 FC1-开配置，且未标开关取值（新）

Where: 触发评论表（C1 94.05/94.31、C2 95.75/95.71、C4 97.24/97.20、C8 101.66/102.18、C16 103.33/102.10、C32 129.23/128.25）；正文「已封存基线」C1 93.862 / C32 129.043（该表由 显式 FlashComm1 关 的配置测得）；评论 6599190290 与 6608856036 中 FC1 开的 B 臂为 C1 79.23–80.03、C32 110.89–112.26；正文「当前开关要求」：「新增测量须标明 FlashComm1 显式开启、fused MC2 关闭」。
Problem: 本对的绝对水平与 FC1-off 封存基线几乎重合（C1 +0.20%/+0.48%，C32 +0.14%/−0.61%），却比每一轮 FC1-on 的 B 臂慢 17.5%/18.7%（C1）与 16.5%/15.1%（C32）。因此这批校准极可能仍跑在旧的 FC1-off 开关下——正是候选筛选已不再使用的那套配置。若如此，它产生的阈值不能用于 FC1-on/fused-MC2-off 下的配对判定，F5 的开放问题（阈值归属）并未解决；若确实是 FC1-on，则其水平与全部历史 FC1-on 测量矛盾，需要解释。评论同时未写 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0 的实际取值，违反正文自己的报告要求。
补充: 配对臂在候选轮次中是 B（工作树清单 4a06cea11369，含分页 KV 读优化），而本次噪声是在 pristine d4ac4319a 上校准的，B 上的噪声底与被测父版本未必相同。
Fix: 在报告中写明两个开关的实际取值；明确本次校准所用配置，若为 FC1-off 则须在同一配置下补一次校准，或说明正式配对将以哪个版本/配置为父臂并据此选定阈值。

F1 — high，must-fix — 候选仍只有 12 位工作树清单前缀，没有可检出的提交（上轮 F1 open，本轮基线侧有进展）

Where: 触发评论「Both fresh services used the original local commit d4ac4319a」；正文表「候选 Git SHA | 待正式验收后提交」；F2 3c4e0c00dab6、FS 43419c27e273、FSQ b054b5a45f45 均只有 12 个十六进制字符；AGENTS.md:87；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-35（candidate_sha 要求 Full git SHA）。
Problem: 正面进展是基线已用完整 SHA d4ac4319acdaf480689c39b6320a998712f80523 标定，本轮校准可追溯；但被比较的三个候选仍只有清单前缀，既不是完整 64 位摘要，也不对应任何提交，无法表达验收条件第 3 条的「直接父版本」。
Impact: 即便 FS/FSQ 的降幅被保留，六档、功能测试与精度都无法在具名修订上复跑或引用，PASS 前提不成立。
Fix: 在任何「保留」判定前把 F2/FS/FSQ 落成 codex/dsv41-0day 上的提交，记录完整 SHA、父 SHA 与全 64 位清单摘要。

F2 — high，must-fix — campaign 证据仍不在仓库，本轮校准也没有归档路径或 SHA-256（上轮 F2 open）

Where: 正文「证据索引」（perf25/release.json、perf25/results/…，声明为「相对实验归档根目录」）；触发评论只给 837262142355（清单前缀）与 da05a8aa0892（环境签名），没有 perf25/... 路径、64 位摘要、原始波或释放回执位置；AGENTS.md:89、docs/contributing.md:119-122。
本次实际核实: python tools/validate_evidence.py → errors: []、21 个 bundle、430 个已校验哈希；tools/evidence_inventory.json 中 dsv41/perf25 均不存在；检出中没有 perf25/，evidence/dsv41-910c-decode-tpot25 也不存在；tools/validate_evidence.py:124-127 对未知 bundle kind 直接抛错，故日后导入也须先登记分类。
Impact: 本轮 12 个正式波、6 个预热波与两次 audited 计时的结论只存在于评论正文，无法复核或作下游引用，而正文要求下游引用这些结果。
Fix: 补写本轮 results/、trials/、preflights/ 的路径与 SHA-256；判 PASS 前把归档导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记（外部原件可按 external 声明）。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，FSQ 改的是数值路径却没有精度结论（上轮 F9 open）

Where: 正文验收条件第 4 条「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」；正文状态块「精度仍待正式性能门禁」；评论 6607845822「gates the fixed 300-item accuracy run on passing paired performance」；触发评论未提 FSQ 精度；docs/contributing.md:100-101。
Problem: 冻结门禁要求每个保留提交都有 300 题结论，控制器在候选搜索后把精度改成性能配对通过后的后置项，正文与 plan/ 均未记录；G 轮被取消的 298 条轨迹既未计入 300 题，也无归档或作废说明。FSQ 在 FS 之上改了 raw KV 与输出投影的 FP8 算术，正是最需要冻结精度门禁兜底的改动，却只有 9 UT / 16 A3 ST。
Impact: 会出现「性能通过但从未产出 300 题结论」的候选；现有 294/300 距门槛仅 2 题余量，算术近似造成的回退只能靠该测试集暴露。
Fix: 由 owner 二选一并写入 plan/：(a) 确认「性能通过后再测 300 题」为正式协议，并写明最终版本仍独立跑 300 题、298 条轨迹如何处置；(b) 维持「每个保留提交即测 300 题」。两者都应要求改算术/改 KV 路径的候选（FS、FSQ）在保留前跑冻结 300 题。

F13 — high，must-fix — FSQ 的等价性证据不覆盖它改动的数值面：C32 0/32 输出哈希相同，且无噪声底（上轮 F13 open）

Where: 触发评论「The BF16 group32 E4M3 path ran at both full-decode buckets for raw KV and output projection」「At C32 … no complete output hashes matched」「Accuracy remains unmeasured on FSQ」；正文冻结配置（block 128、每请求精确 1,024 入/1,024 出，即 8 个整块、无前缀缓存）；历史 C32 一致数为 C 8/32、G 4/32、R 1/32、F2 1/32、FS 0/32，同版本重复本身只有 5/32、2/32。
Problem: 改动直接落在 KV 值与输出投影的数值路径上，等价性证据只有 C1 逐 token 相同与 9 UT / 16 A3 ST；性能负载从不出现尾部不完整块或 KV 复用，且没有 B-vs-B（或 FS-vs-FS）的 C32 控制臂建立哈希一致率噪声底，因此 0/32 既不能证明等价也不能证明差异只是批处理噪声。
Impact: E4M3 量化偏差不会体现在 TPOT，只会暴露在固定 300 题（294/300，余量 2 题）或下游质量上，而 FSQ 还会被当作后续合并候选的对照臂。
Fix: 补一组 FS 对 FSQ 的逐 token 对照：不同 visible length、非 128 整数倍提示长度、带前缀缓存命中；加一次同版本 C32 重复以建立哈希一致率噪声底；保留前跑冻结 300 题（顺序依 F9 的结论）。

F12 — medium，must-fix — FSQ 的对照臂沿用 16:47 的 FS 数值，属跨会话配对（上轮 F12 open）

Where: 触发评论表 FS 65.52/92.59 与评论 6610001726 逐位相同，后者亦称「The service was reaped and B restored」；触发评论只写「same environment」。
Problem: FS 臂未在本轮重测，FSQ 在另一台服务上测得，1.93%/6.48% 是跨会话差值；B 自身跨会话重复已见约 1.0%（C1 79.23→80.03）与 1.24%（C32 110.89→112.26）的波动，而 C1 的 1.93% 与新校准的 1% 下限、旧门槛 1.000% 都在同一量级。
Impact: C32 的 6.48% 超出噪声，但 C1 的 1.93% 不足以支撑 FSQ 在 C1 的保留判定；收益也无法绑定到具体 RunSpec。
Fix: 明确 FS 臂是否沿用；若沿用则标为跨会话并给出漂移对照，或补一次 FS→FSQ 同会话配对。

F14 — medium，must-fix — 正文状态块仍落后于已公布结果（上轮 F14 收窄，本轮复发）

Where: 正文 **Current state:** 的「FSQ 另有 9 UT / 16 A3 ST 通过，尚未公布端到端计时或精度；作者称原提交同版本六档噪声校准另行安排」；对比评论 6610322256（17:01，FSQ 64.26/86.59）与触发评论（17:27，校准对 1/3 已完成）；docs/agent-collaboration.md:212-218。
Problem: 状态行称 FSQ 计时未公布、校准另行安排，两项均已与最新评论不符（精度确实仍缺）。
Impact: 权威状态行让读者看不出当前最优筛选值（FSQ 64.26/86.59，距 25 ms/token 仍有 2.6–3.5 倍）与校准进度。
Fix: 更新 Current state / Next action，写入 FSQ 单波数值并标注「单波筛选、非配对」、精度未测、校准对 1/3 已完成及配置归属结论。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定的问题，也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:212-217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 记 approval_owners 为 Dong1017。
Problem: 该行既不是可判定问题，也无决策人；F5（门槛公式）、F16（校准配置归属）、F9（精度门禁顺序）、F4（另一 RunSpec 记录归属）等待决项仍只散落在评论里。
Impact: 读者无法区分「已定」与「未定」，也无法判断是否具备推进正式配对的条件。
Fix: 改写为逐项问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F3 — medium，must-fix — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

Where: 评论 6602376192 第 3.2、3.3、3.5、5.2、10–12 节及其文件链接（用户专属绝对路径、本地用户名、Pod 全名、两个节点 IP、模型挂载路径）；docs/privacy-security.md:10-13；AGENTS.md:124。
Problem: 该评论未被编辑，敏感值仍公开可见。本轮与触发评论均只使用清单前缀与相对描述，未新增泄漏（这点正确）。
Impact: 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
Fix: 编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 等占位符替换；导入证据树前再做一次脱敏复查。

F4 — medium，must-fix（需 owner 决定）— 另一 RunSpec 的 0-day 适配记录仍与本 campaign 证据混在同一 Issue（上轮 F4 open）

Where: 评论 6602376192《0-day 适配任务记录》第 2.1、5.4、10 节与「PD 混部 8192」段；对比正文「初始修订与基线运行配置」表与「验收条件」。
Problem: 该记录定位为「不要求优化性能」、精度门禁 GPQA 88.89、并行策略 TP8/DP2/EP16，实测 GPQA 163/198；本 Issue 冻结的是 TP4/DP4/EP16、FC1 开 + enable_fused_mc2=0、GSM8K 292/300 与六档 TPOT ≤25 ms/token，两者不是同一 RunSpec 也不是同一组门禁。
Impact: 记录中的 43.60 ms/token、82.32% 与六档表并列时会被下游误读为本 campaign 的进展。
Fix: 由 owner 决定：把该记录移入独立 Issue/归档并在此只留指针，或在本 Issue 声明其不属于本 campaign 证据；在此之前不并入证据索引。

F7 — medium — 计分工具身份仍未 pin，294/300 不可复算（上轮 F7 open）

Where: 验收条件第 4 条（AISBench 原生 Gsm8kEvaluator、zero-shot CoT、thinking/low、贪心、4096 上限、并发 32、seed 42）；正文「初始修订与基线运行配置」表只列 CANN 9.1.0、驱动 25.5.1.1、Python 3.12.13、torch/torch-npu。
Problem: 没有 AISBench revision 或抽取/判分代码摘要；FSQ 精度未测，后续任何 300 题运行仍不可复算，而余量仅 2 题。
Impact: CoT 截断、答案抽取或 4096 上限处理的版本差异足以翻转 2 题且无法归因。
Fix: 在精度证据与环境表记录 AISBench revision 与判分代码摘要；已核对 Add an optional AISBench service benchmark adapter #326 为 open draft、未合并，其 docs/aisbench.md 以 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为 pin 可作候选；[RFC] Integrate AISBench as an optional benchmark tool #289 仍为 open RFC。

F15 — medium，suggestion — FSQ 的唯一运行时改动定义仍不清：量化对象、粒度与开关未给（上轮 F15 open）

Where: 触发评论「The BF16 group32 E4M3 path … raw KV and output projection」「adds one runtime change to FS」；验收条件第 3 条要求每个保留提交记录单一假设与预设受益档。
Problem: 未说明量化的是 KV 值、输出投影权重还是其输入/输出，group32 沿哪条轴分组、scale 来源，是否由配置开关控制、默认是否改变；「BF16 group32 E4M3」本身也存歧义。
Impact: 无法判断这是数值近似（精度风险面）还是仅存储格式变化，也无法按验收条件核对假设与受益档。
Fix: 写明精确数值改动（输入/输出 dtype、分组轴与 scale 来源）、配置开关与默认值，以及预先声明的受益档。

F6 / F11 — medium，suggestion — 步级归因与探针口径仍未对账（上轮 F6、F11 open）

Where: 评论 6606963791「每个验证步的 13 次长索引读取合计 49.74–49.76 ms」「12 行、ratio 1、约 1029 上下文的索引路径中位数由 9.13 降至 2.84 ms」；评论 6608856036「12 rows and ~1K context the two-layer graph took 46.65 → 31.51 ms」；评论 6600643803「target FULL 回放中位数 293.12 ms/次、草稿提议 65.54 ms/次、C32 102.116 ms/token」。
Problem: (a) 293.12 ms/step → 102.1 ms/token 仍缺对算式与推导步数，65.54 ms 的单位（每步一次 vs 每次提议）未标，31.68–31.71 ms per graph 又是第三种口径；(b) 同为 12 行、ratio 1、约 1K 上下文，基线一为 9.13 ms、一为 46.65 ms（5.1 倍），降幅一为约 69%、一为 32.5%，未说明二者范围与哪个数值作废。
Impact: 单 rank 归因无法换算成可核算的 TPOT 收益上限，G 的整模回归已证明这类外推会失效；FSQ 的 1.93%/6.48% 也缺少可核对的量级依据。
Fix: 补一张单位表（per graph / per step / per token）与对算式，给出探针完整形状表（rows、ratio、context、层数、单次/批量、对应图中哪个算子），并说明 profile 服务与正式计时在 capture size、预热、并发构成上的一致性。

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

本次正文编辑把 17:30 状态同步写入首行三行块：FS→FSQ 的 64.26/86.59 ms/token（相对 FS 1.93%/6.48%）、9 UT/16 A3 ST、C32 0/32 输出哈希一致，以及原提交同版本六档校准第 1/3 组（逐档差 0.04%–1.19%）均与评论 6610322256、6610897338 逐项相符，我按「先测轮为分母」复算了六档差值（0.28%/0.04%/0.04%/0.51%/1.19%/0.76%）与「0.04%–1.19%」一致，整体仍自述 INCONCLUSIVE。结论：needs information / human decision required——正文没有请求代码变更的句子，不构成开发授权，PASS 前提仍未补齐。上轮 F14（状态块落后于已公布结果）已 fixed；F5 在本轮正文被部分澄清（声明三对校准不替换旧调整与封存阈值），但与负责人 17:27 评论的「三对最大值」口径直接冲突，仍 open；F16、F1、F2、F9、F13、F12、F8、F3 以及 F4/F7/F15/F6/F11 仍 open 且本轮未回应。未新增标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json:73-84 须配合 status:proposed/accepted，本 Issue 无 status 标签。未在正文或评论中发现引导自动评审的文本。

F5 — high，must-fix（需 owner 决定）— 门槛公式出现正文与负责人评论相互矛盾的两种口径，且仍无 FC1 开配置下的门槛（上轮 F5 open，本轮只澄清了一半）

位置: 新状态块「新评论所述三组校准是当前执行记录，不自动替换下方历史『两组、四服务』调整或已封存阈值」；验收条件第 2 条（[x]，两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)、第三组启动期停止）；评论 6610897338「Per-tier acceptance thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor」；「已封存基线」表 1.000%–2.526%，其来源配置为「显式 FlashComm1 关」。依据：AGENTS.md:64、docs/contributing.md:100-101。
问题: 正文现在说三对校准不改门槛，而负责人最新评论把三对最大值定义为逐档验收门槛——两者不可能同时是验收条件第 3 条的「该档门槛」。按正文口径，全部候选在 FC1 开下测量、判保留却仍用 FC1 关的封存阈值，且三对校准即便完成也不产生可用于判定的阈值；按评论口径，则是在五至六轮筛选与 1.93%/6.48% 公布之后才首次给出新公式。
条件/影响: FSQ 的 C1 1.93% 与 FS 的 3.18%/3.53% 都落在 1.000%–2.526% 临近区间，选哪套公式会直接翻转保留/淘汰结论。
修复: 由 owner（.github/knowledge-model-policy.json:50 为 Dong1017）在正文与 plan/ 明确：哪一套公式是唯一验收门槛、它是否适用于 FC1 开/fused-MC2 关的测量、三对校准被封存后替换旧表的生效时点，以及此前各轮是否标为探索性。

F16 — high，must-fix（需 owner 决定）— 六档校准仍未写开关取值，其绝对水平与 FC1 关的封存基线重合（上轮 F16 open）

位置: 新状态块对新校准只写「两新服务全部请求成功，逐档观测差为 0.04%–1.19%」；评论 6610897338 只写 original local commit d4ac4319a、identical source manifest 837262142355、restored common environment da05a8aa0892；正文「当前开关要求」要求新增测量标明 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0。
问题: 本对 C1 94.05/94.31、C32 129.23/128.25 与「已封存基线」（FC1 关）93.862/129.043 几乎重合，却比全部 FC1 开的 B 臂（C1 79.23–80.03、C32 110.89–112.26）慢 15%–19%。若该对在 FC1 关下测得，它既不是候选轮次的配置，也不能提供候选判定可用的阈值；若确实是 FC1 开，则与全部历史 FC1 开测量矛盾，需要解释。
修复: 在正文与归档中写明两个开关的实际取值与环境签名；若为 FC1 关，则在 FC1 开下按冻结的同一公式补一次校准，或说明正式配对的父臂与阈值来源。

F1 — high，must-fix — 候选仍只有清单前缀，没有可检出的提交（上轮 F1 open，连续多轮）

位置: 正文表「候选 Git SHA | 待正式验收后提交」、状态块「候选仍以工作树清单标识，未记录正式候选提交及最终六档验收」；各轮候选仅以 3c4e0c00dab6（F2）、43419c27e273（FS）、b054b5a45f45（FSQ）、837262142355（校准清单）出现；AGENTS.md:87、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32（candidate_sha 要求 Full git SHA）。
问题: 12 位十六进制前缀既不是 64 位清单摘要，也不对应任何提交，无法表达验收条件第 3 条的「直接父版本」；而正文又把正式候选 SHA 排到验收之后，形成循环。
影响: 即便 FS/FSQ 的降幅被保留，六档、功能测试与精度都无法在具名修订上复跑或引用，PASS 前提不成立。
修复: 在任何「保留」判定前把 F2/FS/FSQ 落成 codex/dsv41-0day 上的提交，记录完整 SHA、父 SHA 与全 64 位清单摘要。

F2 — high，must-fix — campaign 证据仍不在仓库，本轮校准与 FSQ 也没有归档路径或 SHA-256（上轮 F2 open）

位置: 正文「证据索引」（perf25/release.json、perf25/results/…，声明为「相对实验归档根目录」）；新状态块与评论 6610897338 只给清单/环境前缀；AGENTS.md:89、docs/contributing.md:105-107。
本次实际核实: python tools/validate_evidence.py → errors: []、21 个 bundle、430 个已校验哈希；其中无 dsv41/perf25 条目；检出中没有 perf25/，evidence/ 下没有 dsv41-910c-decode-tpot25；tools/evidence_inventory.json 也未登记该 campaign。
影响: 本轮 12 个正式波与 6 个预热波、两次 audited 计时、校准对 1/3 的结论只存在于评论正文，无法复核或作下游引用，而正文要求下游引用这些结果。
修复: 补写 results/、trials/、preflights/ 的路径与 SHA-256，失败/跳过回执单列；判 PASS 前导入 evidence/dsv41-910c-decode-tpot25/ 并在 tools/evidence_inventory.json 登记（外部原件可按 external 声明）。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，FSQ 改的是数值路径却只有新状态块「精度未测」（上轮 F9 open）

位置: 验收条件第 4 条（「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」）；新状态块「FSQ 精度未测」；评论 6607845822「gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:100-101。
问题: 冻结门禁要求每个保留提交都有 300 题结论，控制器在候选搜索之后把精度改成性能配对通过后的后置项，正文与 plan/ 均未记录；G 轮被取消的 298 条轨迹无归档或作废说明。FSQ 在 FS 之上改了 raw KV 与输出投影的 FP8 算术，正是最需要冻结精度门禁兜底的改动，却只有 9 UT / 16 A3 ST。
影响: 会出现「性能通过但从未产出 300 题结论」的候选；现有 294/300 距门槛仅 2 题余量。
修复: 由 owner 二选一并写入正文与 plan/：(a) 确认「性能通过后再测 300 题」为正式协议，写明最终版本仍独立跑 300 题及 298 条轨迹处置；(b) 维持「每个保留提交即测 300 题」。两者都应要求改算术/改 KV 路径的候选（FS、FSQ）在保留前跑冻结 300 题。

F13 — high，must-fix — FSQ 的等价性证据不覆盖它改动的数值面：C32 0/32 输出哈希相同且无噪声底（上轮 F13 open，本轮正文已确认 0/32）

位置: 新状态块「C32 完整输出哈希 0/32 一致」；评论 6610322256（The BF16 group32 E4M3 path … raw KV and output projection）；正文冻结配置（block 128、每请求精确 1,024 入/1,024 出，即 8 个整块、无前缀缓存）；历史同版本 C32 重复本身一致数只有 5/32、2/32。
问题: 改动直接落在 KV 值与输出投影的数值路径上，等价性证据只有 C1 逐 token 相同与 9 UT / 16 A3 ST；性能负载从不出现尾部不完整块或 KV 复用，且没有 FS-vs-FS（或 B-vs-B）的 C32 控制臂建立哈希一致率噪声底，因此 0/32 既不能证明等价，也不能证明差异只是批处理噪声。
影响: E4M3 量化偏差不会体现在 TPOT，只会暴露在固定 300 题（294/300，余量 2 题）或下游质量上，而 FSQ 还会被当作后续合并候选的对照臂。
修复: 补一组 FS 对 FSQ 的逐 token 对照：不同 visible length、非 128 整数倍提示长度、带前缀缓存命中；加一次同版本 C32 重复以建立哈希一致率噪声底；保留前按 F9 的结论跑冻结 300 题。

F12 — medium，must-fix — FSQ 的对照臂沿用 16:47 的 FS 数值，属跨会话配对（上轮 F12 open）

位置: 评论 6610322256 表中 FS 65.52/92.59 与评论 6610001726 逐位相同，后者亦称服务已回收并恢复 B；新状态块只写「每档仅一波」「服务释放后恢复 B」，未说 FS 臂是否重测。
问题: FS 臂未在本轮重测、FSQ 在另一台服务上测得，1.93%/6.48% 是跨会话差值；B 自身跨会话重复已见约 1.0%（C1 79.23→80.03）与 1.24%（C32 110.89→112.26）的波动，而 C1 的 1.93% 与新校准的 1% 下限、旧门槛 1.000% 都在同一量级。
影响: C32 的 6.48% 超出噪声，但 C1 的 1.93% 不足以支撑 FSQ 在 C1 的保留判定。
修复: 明确 FS 臂是否沿用；若沿用则标为跨会话并给出漂移对照，或补一次 FS→FSQ 同会话配对。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定的问题，也没有决策人（上轮 F8 open）

位置: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:212-218 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 记 approval_owners 为 Dong1017。
问题: 该行既不是可判定问题，也无决策人；F5（门槛公式）、F16（校准配置归属）、F9（精度门禁顺序）等待决项仍只散落在评论里。
影响: 读者无法区分「已定」与「未定」，也无法判断是否具备推进正式配对的条件。
修复: 逐项改写为问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F3 — medium，must-fix — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

位置: 评论 6602376192 第 3.2、3.3、3.5、5.2、10–12 节及其文件链接（用户专属绝对路径、本地用户名、Pod 全名、两个节点 IP、模型挂载路径）；docs/privacy-security.md:10-13；AGENTS.md 的 Privacy and security 段。
问题: 该评论未被编辑，敏感值仍公开可见。新正文与 17:27 评论只使用清单前缀与相对描述，本轮未新增泄漏（这点正确）。
影响: 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
修复: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 等占位符替换；导入证据树前再做一次脱敏复查。

F4 / F7 / F15 / F6 / F11 — medium，suggestion — 上轮遗留项本轮未回应（保持 open）

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25 ms/token）混在同一 Issue；需 owner 决定移出或以指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/代码摘要，294/300 不可复算；Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 可作候选 pin。
F15: FSQ 的「BF16 group32 E4M3」仍未说明量化对象（KV 值/权重/输入输出）、分组轴与 scale 来源、开关与默认值，无法按验收条件第 3 条核对假设与预设受益档。
F6/F11: per-graph / per-step / per-token 单位换算与 12 行 ratio 1 约 1K 上下文的两次基線（9.13 ms 与 46.65 ms）仍未对账，单 rank 归因无法换算成 TPOT 收益上限。
修复: 按各项原建议逐条回应或在正文记录处置。

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

Compact candidate mask on FSQ

The new FSQ C32 profile sampled all 16 ranks in FULL48. The rank-zero trace contained four complete target graphs. Each retained a single layer-20 mask expansion from 2,048 candidate blocks to 16,384 columns, costing 26.78–27.99 ms per graph. All eight fused index-score kernels together cost 0.68–0.76 ms per graph. Across ranks, the median target replay event was 225.42 ms and the median complete draft proposal event was 66.07 ms. This was a dedicated diagnostic service, separate from client timing.

The candidate keeps one decision per block and broadcasts it when four follower layers mask scores. It was frozen from the local working branch at manifest 47e9c767307e, directly against FSQ b054b5a45f45. Product tests passed, 37 UTs and 7 A3 STs. The first two gate transactions stopped because the controller expected 36 UT cases. The final transaction verified every collected CPU/NPU fixture node against JUnit before starting the benchmark.

Global concurrency	FSQ TPOT (ms/token)	Compact TPOT (ms/token)	Reduction
1	64.26	59.86	6.84%
32	86.59	80.42	7.12%

One matched 1024-input/1024-output client wave per tier, identical frozen common environment. C1 output IDs and speculative metrics matched. For C32 all input hashes matched and six full output hashes matched. No new accuracy run or performance commit. Service release, restoration to B and device idle checks passed. The next DSpark diagnostic uses its independently frozen FSQ parent and includes a fresh six-tier uninstrumented FSQ sweep.

本次更新新增 FSQ 上的「compact candidate mask」候选（C1/C32 为 64.26→59.86、86.59→80.42 ms/token，6.84%/7.12%）、一份 C32 设备 profile，以及 37 UT/7 A3 ST 回执；作者自述无精度、无性能提交，整体仍为 INCONCLUSIVE。结论：needs information / human decision required——候选仍无 pin、证据树仍不在仓库、门槛公式与校准配置归属、精度门禁顺序仍未决，另新增「UT 计数门禁在两次失败后被改为匹配候选」。早前项状态：F5、F16、F1、F2、F9、F13、F12、F6/F11、F3、F4、F7、F15 仍 open；F13 有改善（C32 输出哈希一致由 0/32 升至 6/32，落在历史同版本 5/32、2/32 的噪声区间）；F14 上轮已修、本轮因状态块未写入 compact 结果而复发。正文没有请求代码变更的句子，不构成开发授权；未发现引导自动评审的文本，也未新增脱敏泄漏。Labels: 无（kind:acceptance、area:workbench 已由人设置；priority:* 依 .github/labels.json 须配合 status 标签）。

F5 — high，must-fix（需 owner 决定）— 门槛公式仍是正文与负责人评论两套口径，且没有 FC1 开配置下的阈值（上轮 F5 open，本轮未回应）

位置: 新状态块「新评论所述三组校准是当前执行记录，不自动替换下方历史『两组、四服务』调整或已封存阈值」；验收条件第 2 条（[x]，两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)）与第 3 条「该档门槛」；评论 6610897338「thresholds use the maximum across the three complete chronological same-version pairs」；「已封存基线」表 1.000%–2.526%（来源配置为「显式 FlashComm1 关」）；AGENTS.md:64、docs/contributing.md:100-101。
问题: 正文说三对校准不替换旧门槛，负责人评论却把三对最大值定义为逐档验收门槛——两者不可能同时是第 3 条的「该档门槛」。按正文口径，全部候选（FC1 开）仍用 FC1 关的封存阈值；按评论口径，则是在六轮筛选和 6.84%/7.12% 公布后才首次给出公式，属事后阈值。
影响: 本轮收益较大、两套口径同向，但下一批更小的收益（FSQ 的 1.93%、FS 的 3.18%）会被口径直接翻转，正式六档仍需唯一阈值。
修复: 由 owner（.github/knowledge-model-policy.json:50 为 Dong1017）在正文与 plan/ 明确唯一门槛公式、是否适用于 FC1-on/fused-MC2-off、三对校准封存后的生效时点，以及此前各轮是否标为探索性。

F16 — high，must-fix（需 owner 决定）— 校准与新一轮测量仍不写开关取值/环境签名，校准对水平与 FC1 关基线重合（上轮 F16 open）

位置: 触发评论只写「identical frozen common environment」与清单前缀 47e9c767307e、父版本 b054b5a45f45；评论 6610897338 的校准对 C1 94.05/94.31、C32 129.23/128.25 与已封存基线（FC1 关）93.862/129.043 几乎重合，却比所有 FC1 开 B 臂（C1 79.23–80.03、C32 110.89–112.26）慢 15%–19%；正文「当前开关要求」要求新增测量标明 FlashComm1 显式开启、fused MC2 关闭。
问题: 校准对与本轮 compact 测量都未写 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0 的实际取值，也未给环境签名（此前为 a3d9fcf0…、da05a8aa0892，冻结表仍是 44411269…）。若校准跑在旧配置，其阈值不能用于 FC1 开下的候选判定。
影响: 6.84%/7.12% 与门槛无法绑定到同一 RunSpec，PASS 时阈值、基线批次与环境身份不可追溯。
修复: 写明每轮（含校准对、compact 两臂）的开关取值与环境签名；若校准为 FC1 关，则在 FC1 开下按冻结公式补一次校准。

F17 — high，must-fix（需 owner 决定）— UT 计数门禁在两次失败后被改为匹配候选，测试范围也从 9 UT/16 ST 变为 37 UT/7 ST，未记录（新）

位置: 触发评论「The first two gate transactions stopped because the controller expected 36 UT cases. The final transaction verified every collected CPU/NPU fixture node against JUnit before starting the benchmark.」「37 UTs and 7 A3 STs」；对照评论 6610322256 的 FSQ「9 UTs and 16 A3 STs」；docs/contributing.md:100-101（validator 与 input hashes 在候选搜索前冻结）、:106（保留全部尝试与被拒改动）。
问题: 冻结门禁对 UT 用例数有预期；本轮该预期与候选不符导致两次事务中止，第三次改为「按 JUnit 核验已收集的 fixture 节点」后放行，外观上是把门禁调整为匹配候选输出。同时候选的 37 UT/7 A3 ST 与父版本 FSQ 的 9 UT/16 A3 ST 数量结构完全变化，评论未说明两套套件的逐项对应关系。
影响: 「37 UT/7 ST 通过」这一保留依据由事后调整的门禁自证，无法判断门禁仍在独立校验候选，也无法判断 FSQ 的 16 项 ST 覆盖是否被 7 项替代后仍有同等保护。
修复: 由 owner 在正文与 plan/ 记录门禁期望用例清单是否冻结、为何允许在候选搜索后改变、两次失败事务的回执位置，以及 9 UT/16 ST → 37 UT/7 ST 的对应表；失败事务按 docs/contributing.md:106 归档。

F1 — high，must-fix — 候选仍只有 12 位工作树清单前缀，没有可检出的提交（上轮 F1 open，连续多轮）

位置: 触发评论「manifest 47e9c767307e, directly against FSQ b054b5a45f45」「frozen from the local working branch」；正文表「候选 Git SHA | 待正式验收后提交」；AGENTS.md:87；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32（candidate_sha 要求 Full git SHA）。
问题: 12 位十六进制既不是完整 64 位清单摘要，也不对应任何提交；FSQ 同样只有前缀。验收条件第 3 条要求记录「直接父版本」，第 4 条要求在最终提交上重测，而正文把正式候选 SHA 排到验收之后，形成循环。
影响: 即使 compact 的 6.84%/7.12% 被保留，六档、37 UT/7 ST 与精度都无法在具名修订上复跑或引用，PASS 前提不成立。
修复: 在任何「保留」判定前把 compact、FS、FSQ 落成 codex/dsv41-0day 上的提交，记录完整 SHA、父 SHA 与全 64 位清单摘要。

F2 — high，must-fix — campaign 证据仍不在仓库，本轮 compact 筛选与 C32 profile 也没有归档路径或 SHA-256（上轮 F2 open）

位置: 正文「证据索引」（perf25/...，声明为相对实验归档根目录）；触发评论只有清单前缀与聚合数值，没有 perf25/... 路径、64 位摘要、16 rank 采样文件或两次失败门禁事务的回执位置；AGENTS.md:89；docs/contributing.md:117。
本次实际核实: python tools/validate_evidence.py → errors: []、21 个 bundle、430 个已校验哈希；tools/evidence_inventory.json 无 dsv41/perf25 条目；检出中没有 perf25/，evidence/dsv41-910c-decode-tpot25 不存在；tools/validate_evidence.py:126 对未知 bundle kind 直接抛错，日后导入须先登记分类。
影响: 决定下一步的 6.84%/7.12%、layer-20 mask 26.78–27.99 ms/graph、225.42/66.07 ms 中位数都只存在于评论正文，无法复核或作下游引用，而正文要求下游引用这些结果。
修复: 补写本轮 results/、trials/、preflights/ 的路径与 SHA-256（失败门禁事务单列 failure receipt）；判 PASS 前导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记（外部原件可按 external 声明）。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，新候选改掩码语义却只报「无新精度运行」（上轮 F9 open）

位置: 验收条件第 4 条（每个保留提交及最终版本须 ≥292/300）；触发评论「No new accuracy run or performance commit」；评论 6607845822「gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:100-101。
问题: 冻结门禁要求每个保留提交都有 300 题结论，控制器在候选搜索后被改成「配对性能通过后才测精度」，正文与 plan/ 未记录；G 轮取消的 298 条轨迹仍无归档或作废说明。compact 改动的是掩码语义（每块一次决策并向下四层广播），正是最需要精度兜底的一类改动。
影响: 可能出现「性能通过但从未产出 300 题结论」的候选；294/300 距门槛仅 2 题余量，掩码语义偏差只能靠该测试集暴露。
修复: 由 owner 二选一并写入正文与 plan/：(a) 确认「性能通过后再测 300 题」为正式协议，写明最终版本仍独立跑 300 题及 298 条轨迹处置；(b) 维持「每个保留提交即测 300 题」。两者都要求改掩码/算术的候选在保留前跑冻结 300 题。

F13 — high，must-fix — compact 的等价性证据仍无控制臂噪声底，也不覆盖它与 FSQ 的语义差异面（上轮 F13 open，本轮有改善）

位置: 触发评论「keeps one decision per block and broadcasts it when four follower layers mask scores」「C1 output IDs and speculative metrics matched. For C32 all input hashes matched and six full output hashes matched.」「No new accuracy run」；正文冻结配置（block 128、每请求精确 1,024 入/1,024 出 = 8 个整块、无前缀缓存）。
改善: C32 完整输出哈希一致由 FS 的 0/32 升至 6/32，已落在历史同版本重复 5/32、2/32 的噪声区间内，比上一轮更可信。
仍缺: 没有 FSQ-vs-FSQ（或 B-vs-B）的 C32 控制臂给出哈希一致率噪声底，因此 6/32 既不能证明等价也不能证明差异全部来自批处理噪声；性能负载从不出现尾部不完整块与 KV 复用，而改动恰好影响「每块一次决策 + 四层跟随掩码」在部分块、可见长度不齐、投机接受长度不齐时的语义；此前提出的非 128 整数倍提示长度 + 前缀缓存逐 token 对照仍未补。
影响: 掩码广播若在部分块或复用路径与逐 token 掩码不同，TPOT 不会暴露，只会出现在固定 300 题（余量 2 题）或下游质量上，而 compact 还会作为后续合并候选的对照臂。
修复: 补 FSQ 对 compact 的逐 token 对照（不同 visible length、非 128 整数倍提示长度、前缀缓存命中），加一次同版本 C32 重复作为哈希一致率噪声底，并按 F9 的结论在保留前跑冻结 300 题。

F12 — medium，must-fix — compact 的对照臂沿用 17:01 的 FSQ 数值，属跨会话配对（上轮 F12 open）

位置: 触发评论表 FSQ 64.26/86.59 与评论 6610322256 逐位相同，后者亦称「released the service normally and restored B」；触发评论只写「One matched 1024-input/1024-output client wave per tier, identical frozen common environment」。
问题: FSQ 臂未在本轮重测、compact 在另一台服务上测得，6.84%/7.12% 是跨会话差值；B 自身跨会话重复已见约 1.0%（C1 79.23→80.03）与 1.24%（C32 110.89→112.26）的波动。
影响: 6.84%/7.12% 均明显高于已观测漂移，方向性结论比上一轮（1.93%）稳健，但「同一会话作差」的前提仍不成立，收益无法绑定到 RunSpec。
修复: 明确 FSQ 臂是否沿用；若沿用则标为跨会话并给出漂移对照，或补一次 FSQ→compact 同会话配对。

F6 / F11 — medium，suggestion — 新 profile 与既往归因直接矛盾：融合索引打分内核 0.68–0.76 ms/graph 无法解释 F2 的 9.2/16.6 ms/token 收益（上轮 F6、F11 open，本轮有新反证）

位置: 触发评论「All eight fused index-score kernels together cost 0.68–0.76 ms per graph」「Each retained a single layer-20 mask expansion … 26.78–27.99 ms per graph」「median target replay event was 225.42 ms」「median complete draft proposal event was 66.07 ms」；评论 6606963791「每个验证步的 13 次长索引读取合计 49.74–49.76 ms」；评论 6609641928（F2 相对 B 11.44%/14.81%）；评论 6608856036「12 rows … 46.65 → 31.51 ms」vs 6606963791「9.13 → 2.84 ms」。
问题: (a) 本轮测得索引打分内核合计不足 1 ms/graph，与此前「每步 49.74 ms」及 F2 的 9.2/16.6 ms/token 收益相差一到两个数量级，两者不能同时成立，说明探针与图中算子不是同一形状/口径。(b) 掩码展开记为 26.78–27.99 ms/graph，而候选只保留每块一次展开，实测收益 4.40/6.17 ms/token（按约 3.3–3.4 token/步约 15–21 ms/step），被改动路径的实际节省量仍未算清。(c) per graph、per step、per token 三种口径仍无统一单位表与对算式。
影响: 单 rank 归因仍不能换算成可核算的 TPOT 收益上限；G 的整模回归已证明这类外推会失效，而本轮又新增一组互相冲突的数值。
修复: 给出一张单位表与探针形状表（rows、ratio、context、层数、单次/批量、对应图中哪条算子），说明旧的 49.74 ms/step 与 9.13→2.84 ms 是否作废，并给出 226–293 ms/step → 实际 TPOT 的对算式。

F14 — medium，must-fix — 正文状态块再次落后：未写 compact 候选 59.86/80.42 与门禁事务事件（上轮已修，本轮复发）

位置: 正文 **Current state:**（截至 17:30，只写 FS→FSQ 与校准第 1/3 组、「FSQ 的新 C32 profile 在与客户端计时分离的运行中收集」）与 **Next action:**；对比触发评论（17:57，已给出 compact 6.84%/7.12%、C32 profile 数值、37 UT/7 ST 与两次门禁中止）；docs/agent-collaboration.md:216-218。
问题: 状态块未反映 compact 候选已成为当前最优筛选值，也未提门禁两次中止；profile 仍写作「收集中」，实际已发布数值。
影响: 权威状态行会让人把 FSQ 64.26/86.59 当成当前最优，并误以为 profile 与门禁情况无变化。
修复: 更新 Current state/Next action：写入 compact 单波数值并标注「单波筛选、非配对」、精度未测、门禁事务与 37 UT/7 ST，补一张「当前最优筛选值」表并给出距 25 ms/token 的倍数（约 2.4–3.2 倍）。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定的问题，也没有决策人（上轮 F8 open）

位置: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 为 Dong1017。
问题: 该行不是可判定问题，也无决策人；F5（门槛公式）、F16（校准配置归属）、F9（精度门禁顺序）、F17（UT 计数门禁）、F4（另一 RunSpec 记录归属）等待决项仍只散落在评论里。
影响: 读者无法区分已定与未定，也无法判断是否具备推进正式配对的条件。
修复: 逐项改写为问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F3 — medium，must-fix — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

位置: 评论 6602376192 第 3.2、3.3、3.5、5.2、10–12 节及其文件链接（用户专属绝对路径、本地用户名、Pod 全名、节点 IP、模型挂载路径）；docs/privacy-security.md:10-16；AGENTS.md:124。
问题: 该评论未被编辑，敏感值仍公开可见；本轮与上一轮新评论只用清单前缀与相对描述，未新增泄漏（这点正确）。
影响: 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
修复: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 等占位符替换；导入证据树前再做一次脱敏复查。

F4 / F7 / F15 — medium，suggestion — 上轮遗留项本轮未回应（保持 open）

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25 ms/token）混在同一 Issue；需 owner 决定移出或以指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/代码摘要，294/300 不可复算；本检出中 grep 不到任何 AISBench 引用。Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 可作候选 pin。
F15: FSQ/compact 的数值改动仍未说明量化对象（KV 值/权重/输入输出）、分组轴与 scale 来源、开关与默认值，无法按验收条件第 3 条核对单一假设与预设受益档。
修复: 按各项原建议逐条回应或在正文记录处置。

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

本 Issue 跟踪 dsv41-910c-decode-tpot25（DeepSeek V4.1 Flash on 910C，六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300），本次 18:04 正文编辑把 17:57 的 FSQ→compact-mask 筛选（64.26→59.86 / 86.59→80.42，6.84%/7.12%）、C32 profile（单层 mask expansion 26.78–27.99 ms/graph）与 37 UT/7 A3 ST 写入状态块，逐项与评论 6611525929 相符，F14 fixed。结论维持 needs information / human decision required：正文没有任何请求修改代码的句子，不构成开发授权，PASS 前提（候选 pin、仓库内证据树、门槛与配置绑定、精度/UT 门禁处置）均仍缺。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 按 .github/labels.json:73-84 须配合 status 标签，而本 Issue 无 status 标签。

F1 — high，must-fix，验收绑定 — 候选仍只有 12 位工作树清单前缀，没有可检出的提交（上轮 F1 仍 open，正文编辑未涉及）

Where: 正文表「候选 Git SHA | 待正式验收后提交」与状态块「正式提交……未完成」；评论 6611525929 的 compact 47e9c767307e、父版本 FSQ b054b5a45f45；AGENTS.md:87（PASS 需 pinned baseline and candidate revisions）；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32（candidate_sha 必填「Full git SHA」）。
Problem: 12 位十六进制既不是 64 位清单摘要，也不对应任何提交，无法表达验收条件第 3 条的「直接父版本」；正文把正式候选 SHA 排到验收之后，形成「最终提交在验收前不存在」的循环。
Impact: 即便 compact 的 6.84%/7.12% 被保留，六档、37 UT/7 ST 与固定 300 题都无法在具名修订上复跑或引用，PASS 不成立。
Fix: 在任何「保留」判定前把 compact、FS、FSQ 落成 codex/dsv41-0day 上的提交，逐轮记录完整 SHA、父 SHA 与全 64 位清单摘要。

F2 — high，must-fix，证据完整性 — campaign 证据仍不在仓库，compact 轮与 C32 profile 也没有路径/摘要（上轮 F2 仍 open）

Where: 正文「证据索引」仍只写 perf25/release.json、perf25/results/…（声明为「相对实验归档根目录」）；评论 6611525929 的 perf25/results/... 路径、16 rank 采样与两次失败门禁事务的回执均未给出；AGENTS.md:89、docs/contributing.md:105-107。
本次实际核实（本检出 663f3b3）： 运行 python tools/validate_evidence.py → errors: []、21 个 bundle、430 个已校验哈希，其中没有 dsv41/perf25 条目；tools/evidence_inventory.json 无本 campaign；evidence/dsv41-910c-decode-tpot25 与 perf25/ 均不存在；tools/validate_evidence.py:126 对未知 bundle kind 直接抛错，日后导入须先登记分类。
Impact: 决定下一步的 6.84%/7.12%、26.78–27.99 ms/graph、225.42/66.07 ms 中位数只存在于评论正文，无法复核或作下游引用，而正文要求下游引用这些结果。
Fix: 补写本轮 results/、trials/、preflights/ 路径与 SHA-256（失败门禁事务单列 failure receipt）；判 PASS 前导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记。

F5 — high，must-fix（需 owner 决定）— 逐档波动门槛仍存在两套口径，且没有 FC1 开配置下的阈值（上轮 F5 仍 open）

Where: 新状态块「新同版本校准仍仅已公布第 1/3 组，尚未封存，其与下方历史两组调整的生效关系未记录明确决定」；验收条件第 2 条（[x]，两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)）与第 3 条「该档门槛」；评论 6610897338「thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor」；「已封存基线」表 1.000%–2.526%（来源配置为「显式 FlashComm1 关」）。
Problem: 正文承认三对校准与旧阈值的生效关系未决，负责人评论却已把三对最大值定义为逐档验收门槛——两者不可能同时是第 3 条的「该档门槛」；按正文口径，FB 开的候选仍用 FC1 关的阈值。依据 AGENTS.md:64、docs/contributing.md:101（数值门禁在候选搜索前冻结）。
Impact: compact 的 6.84%/7.12% 两套口径同向，但 FSQ 的 1.93%、FS 的 3.18% 会因口径而翻转。
Fix: 由 owner（.github/knowledge-model-policy.json:50 为 Dong1017）在正文与 plan/ 明确唯一公式、是否适用于 FC1-on/fused-MC2-off、三对校准封存后的生效时点，以及此前各轮是否标为探索性。

F16 — high，must-fix（需 owner 决定）— 校准对与 compact 轮仍未写开关取值/环境签名，校准对水平与 FC1 关基线重合（上轮 F16 仍 open）

Where: 新状态块只写「逐档观测差为 0.04%–1.19%」；评论 6610897338 只写 original local commit d4ac4319a、清单 837262142355、环境 da05a8aa0892；评论 6611525929 只写「identical frozen common environment」；正文「当前开关要求」要求新增测量标明 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0。
Problem: 校准对 C1 94.05/94.31、C32 129.23/128.25 与「已封存基线」（FC1 关）93.862/129.043 几乎重合，却比全部 FC1 开 B 臂（C1 79.23–80.03、C32 110.89–112.26）慢 15%–19%；若校准跑在旧配置，其阈值不能用于 FC1 开下的候选判定。冻结表环境签名仍是 44411269…。
Impact: 6.84%/7.12% 与门槛无法绑定到同一 RunSpec，PASS 时基线批次与环境身份不可追溯。
Fix: 每轮（含校准对、compact 两臂）写明两个开关实际取值与环境签名；若校准为 FC1 关，则在 FC1 开下按冻结公式补一次校准，或说明正式配对的父臂。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，而 compact 改的是掩码语义却「没有新精度运行」（上轮 F9 仍 open）

Where: 正文验收条件第 4 条（每个保留提交及最终版本须 ≥292/300）与状态块「没有新精度运行」；评论 6607845822「The updated validation controller gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:101（validator 与输入在搜索前冻结）。
Problem: 冻结门禁要求每个保留提交都有 300 题结论，控制器在候选搜索后被改成「配对性能通过后才测精度」，正文与 plan/ 未记录；G 轮取消的 298 条轨迹仍无归档或作废说明。compact 每块一次决策并向四层跟随广播，正是最需要精度兜底的改动。
Impact: 可能出现「性能通过但从未产出 300 题结论」的候选；294/300 距门槛仅 2 题余量，掩码语义偏差只能靠该测试集暴露。
Fix: 由 owner 二选一并写入正文与 plan/：(a) 确认新顺序为正式协议并写明最终版本仍独立跑 300 题及 298 条轨迹处置；(b) 维持「每个保留提交即测 300 题」；两者都要求改掩码/算术候选在保留前跑冻结 300 题。

F17 — high，must-fix（需 owner 决定）— UT 计数门禁在两次失败后被改为匹配候选，测试范围从 9 UT/16 ST 变为 37 UT/7 ST（上轮 F17 仍 open；正文编辑只复述事件）

Where: 新状态块「前两次门禁因预期 36 项与实际收集数不符而停止，最终运行在计时前按 JUnit 核验全部收集节点，失败记录保留」；评论 6611525929「The first two gate transactions stopped because the controller expected 36 UT cases… 37 UTs and 7 A3 STs」；对照评论 6610322256 的 FSQ「9 UTs and 16 A3 STs」；docs/contributing.md:105-106（全部尝试、被拒改动与慢/失败试验均须保留）。
Problem: 正文现在记录「门禁当时被调整过」这一事实，但未记录处置决定：期望用例清单是否冻结、为何允许在候选搜索后改变校验方式、两次失败事务的回执位置、以及 9 UT/16 ST → 37 UT/7 ST 的逐项对应。
Impact: 「37 UT/7 ST 通过」这一保留依据仍由事后调整的门禁自证，也无法判断 FSQ 的 16 项 ST 覆盖被 7 项替代后保护是否等效。
Fix: 由 owner 在正文与 plan/ 记录上述四项，并按 docs/contributing.md:106 给两次失败事务的归档路径/摘要。

F3 — high，must-fix，隐私 — 历史评论 6602376192 仍未脱敏（上轮 F3 仍 open）

Where: 评论 6602376192 的 3.2/3.3/3.5/5.2/10–12 节：节点 IP 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-jcz02615514-…、/a3_inference/itask/workdir/jcz02615514/jcz-afd1、用户专属绝对路径 /Users/jiangchenzhou/... 与模型挂载路径；docs/privacy-security.md:10-13；AGENTS.md:121-124。
Problem: 该评论未被编辑，敏感值仍公开可见；本次正文编辑与 17:57 评论只用清单前缀与相对描述，未新增泄漏（这点正确）。
Impact: 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 占位符替换；导入证据树前再做一次脱敏复查。

F13 — medium，must-fix — compact 的等价性证据仍无控制臂噪声底，也不覆盖它与 FSQ 的语义差异面（上轮 F13 open，6/32 有改善）

Where: 正文状态块「C1 输出及投机指标一致，C32 完整输出哈希 6/32 一致」；正文冻结配置（block 128、每请求精确 1,024 入/1,024 出 = 8 个整块、无前缀缓存）；评论 6611525929「No new accuracy run」。
改善: C32 哈希一致由 FS 的 0/32 升至 6/32，落在历史同版本重复 5/32、2/32 的噪声区间内，比上一轮更可信。
仍缺: 没有 FSQ-vs-FSQ（或 B-vs-B）C32 控制臂给出哈希一致率噪声底；性能负载不出现尾部不完整块与 KV 复用，而改动恰好影响「每块一次决策 + 四层跟随掩码」在部分块、可见长度不齐、投机接受长度不齐时的语义。
Impact: 掩码广播若在部分块或复用路径与逐 token 掩码不同，TPOT 不会暴露，只会出现在固定 300 题（余量 2 题）或下游质量上。
Fix: 补 FSQ→compact 逐 token 对照（非 128 整数倍提示长度、前缀缓存命中、不同 visible length）与一次同版本 C32 重复作为噪声底，并按 F9 结论在保留前跑冻结 300 题。

F12 — medium，must-fix — compact 的对照臂沿用 17:01 的 FSQ 数值，6.84%/7.12% 是跨会话差值（上轮 F12 open）

Where: 正文状态块与评论 6611525929 的 FSQ 列 64.26/86.59 与评论 6610322256 逐位相同，后者亦称「released the service normally and restored B」；本轮只说「One matched 1024-input/1024-output client wave per tier, identical frozen common environment」。
Problem: FSQ 臂未在本轮重测，compact 在另一台服务上测得；已观测 B 跨会话漂移约 1.0%（C1 79.23→80.03）与 1.24%（C32 110.89→112.26）。
Impact: 收益虽明显高于漂移、方向性稳健，但「同一会话作差」的前提不成立，收益无法干净地绑定到 RunSpec。
Fix: 明确 FSQ 臂是否沿用（沿用则标为跨会话并附漂移对照），或补一次 FSQ→compact 同会话配对。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定问题，也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:213-218 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 为 Dong1017。
Problem: 该行只是「仍待证据」，没有具体问题与决策人；F5（门槛公式）、F16（校准配置归属）、F9（精度门禁顺序）、F17（UT 门禁）、F4（另一 RunSpec 记录归属）等待决项仍散落在评论里。
Impact: 读者仍无法区分已定与未定，也无法判断是否具备开始正式配对的条件；本轮正文虽然把「生效关系未决」写进状态，但没落到这一行。
Fix: 把待决项逐条改写为问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F6 / F11 — medium，suggestion — 新 profile 与既往归因仍无法对账（上轮 F6、F11 open，本轮新增正文引用）

Where: 正文状态块「独立 FSQ C32 profile 报告单层 mask expansion 为 26.78–27.99 ms/graph；这与客户端计时分开，不单独证明收益」（方向正确）；评论 6606963791「每个验证步的 13 次长索引读取合计 49.74–49.76 ms」；评论 6609641928（F2 相对 B 11.44%/14.81%）；本轮「八组融合索引打分内核合计 0.68–0.76 ms/graph」。
Problem: (a) 本轮索引打分内核不足 1 ms/graph，与此前 49.74 ms/step 及 F2 的 9.2/16.6 ms/token 收益差一到两个数量级，说明探针与图中算子不是同一形状；(b) 掩码展开记为 26.78–27.99 ms/graph，而 compact 实测收益约 4.40/6.17 ms/token，被改动路径的实际节省量仍未算清；(c) per graph / per step / per token 三种口径仍无统一单位表与对算式。
Impact: 单 rank 归因无法换算成可核对的 TPOT 收益上限；G 的整模回归已证明这类外推会失效。
Fix: 补一张单位表与探针形状表（rows、ratio、context、层数、单次/批量、对应图中算子），说明旧数值是否作废，并给出 ms/step → TPOT 的对算式。

F4 / F7 / F15 — medium，suggestion — 遗留项本轮未回应（保持 open）

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25 ms/token）混在同一 Issue；需 owner 决定移出或以指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/代码摘要；本次在实际检出中 grep -ri aisbench 无任何引用，294/300 不可复算。可考虑以 Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为候选 pin。
F15: FSQ/compact 的数值改动仍未说明量化对象（KV 值/权重/输入输出）、分组轴与 scale 来源、开关与默认值，无法按验收条件第 3 条核对单一假设与预设受益档。
Fix: 按各项原建议逐条回应，或在正文记录处置。

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

Uninstrumented FSQ six-tier sweep

One exploratory round at each tier on a fresh FSQ parent service using working-source manifest b054b5a45f45272b3a6786e5a4eb148ece3d08434de67d26bcb3379526589646. TP4 / DP4 / EP16, DSpark5, FULL_DECODE_ONLY, explicit FlashComm1 and fused MC2=0. Each measured request had 1,024 input and 1,024 output tokens after a separate warmup. All 63 measured requests completed with cold prefixes and no errors.

Global concurrency	Mean client TPOT (ms/token)	Above 25 (ms/token)
1	63.97	38.97
2	62.80	37.80
4	65.26	40.26
8	67.42	42.42
16	69.03	44.03
32	88.14	63.14

The six waves produced 64,512 output tokens. DSpark accepted 45,441 of 95,605 proposed tokens. The startup gate verified FULL replay on all four DPs. The sampled measurement windows at 4, 8 and 16 showed only a subset of their active DPs. The window at 32 showed all four. The uninstrumented timing capture exited successfully. Each wave was independently recalculated from its retained client SSE token and EOF timestamps.

The prior compact-mask screen remains 59.86 / 80.42 ms/token at 1 / 32 concurrency, with direct FSQ controls of 64.26 / 86.59. Middle tiers of that compact candidate remain unmeasured. Both screens are exploratory. The paired performance gate must pass before starting the fixed GSM8K-300 evaluation. No new accuracy score or accepted optimization commit.

Six-tier client receipt SHA-256 9dbe29b334fbf6bbea32e03d33eb1e9fd328b7e0620991c148b8f60303c1bf2b.

意图：维护本条 campaign 验收（DeepSeek V4.1 Flash / 910C，六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300）及其证据。触发评论新增父版本 FSQ（非任何候选）的无插桩六档 sweep：63.97 / 62.80 / 65.26 / 67.42 / 69.03 / 88.14 ms/token，token 数与投机接受率（45,441/95,605 = 47.53%）自洽，但最好的一档仍是目标的 2.5 倍，候选中间档仍未测，故整体维持 INCONCLUSIVE。结论：needs information / human decision required——正文没有任何请求修改代码的句子，不构成开发授权；未发现引导自动评审的文本。

F1 — high，must-fix — 六档 sweep 的父版本仍只有 64 位清单摘要，没有可检出提交（上轮 F1 open，本轮未涉及）

Where: 触发评论首段 working-source manifest b054b5a45f45…；正文表「候选 Git SHA | 待正式验收后提交」；AGENTS.md:87（PASS 需 pinned baseline and candidate revisions）、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-32（candidate_sha 必填 Full git SHA）。
Problem: 64 位清单摘要是工作树源码的哈希，不是提交；验收条件第 3 条要求记录「直接父版本」，而本轮连父版本也只用摘要标识。
Impact: 63.97–88.14 这一组首个全档数据无法在具名修订上复跑或被下游引用，PASS 不成立。
Fix: 在任何「保留」判定前把 FSQ 及后续候选落成 codex/dsv41-0day 上的提交，逐轮记录完整 SHA、父 SHA 与清单摘要。

F2 — high，must-fix — campaign 证据树仍不在仓库，本轮只给了一个无路径的客户端回执哈希（上轮 F2 open）

Where: 触发评论末行 Six-tier client receipt SHA-256 9dbe29b3…；正文「证据索引」仍只列 perf25/… 相对路径；AGENTS.md:89、docs/contributing.md:117-122。
本次实际核实（检出 663f3b3，与上轮同一提交）： 运行 python tools/validate_evidence.py → {"errors": [], … "checked_hashes": 430}、21 个 bundle，其中无本 campaign；evidence/dsv41-910c-decode-tpot25 与 perf25/ 均不存在（ls 报 No such file or directory）；tools/evidence_inventory.json 无 dsv41/perf25 条目。
Impact: 决定下一步的六档数值、逐波重算（SSE token/EOF 时间戳）与 DP 采样覆盖只存在于评论正文，无法复核。
Fix: 补写本轮 results/、trials/、preflights/ 路径与 SHA-256，客户端回执给出相对路径；判 PASS 前按 evidence/<campaign-id>/{plan,results,patch,validator} 导入并登记 tools/evidence_inventory.json。

F3 — high，must-fix，隐私 — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

Where: 评论 6602376192 的 3.2/3.3/3.5/5.2/10–12 节：节点 IP 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-…、/a3_inference/itask/workdir/…、/Users/jiangchenzhou/…；docs/privacy-security.md:10-13、AGENTS.md:121-124。
本次核实： 该评论 updated_at 仍等于 created_at（2026-11-03T11:15:56Z），即从未编辑，敏感值仍公开；触发评论与正文只用清单前缀，未新增泄漏（这点正确）。
Impact: 个人身份路径与内部拓扑持续公开；同一份记录若作为证据导入会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 替换；导入证据树前再脱敏复查。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍被重述为「性能通过后才测 300 题」，与已勾选条件冲突（上轮 F9 open）

Where: 触发评论「The paired performance gate must pass before starting the fixed GSM8K-300 evaluation」；正文验收条件第 4 条（「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」）；评论 6607845822「The updated validation controller gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:100-101（数值门禁与 validator 在搜索前冻结）。
Problem: 本轮再次把顺序说成性能优先，但正文与 plan/ 仍未记录该变更，冻结条件要求的是每个保留提交都产出 300 题结论。
Impact: 可能出现「性能通过但从未产出 300 题结论」的保留；compact 掩码语义改动尤其依赖该测试集兜底。
Fix: 由 owner 二选一并写入正文与 plan/：(a) 确认新顺序为正式协议且最终版本仍独立跑 300 题；(b) 维持「每个保留提交即测 300 题」。

F5 — high，must-fix（需 owner 决定）— 逐档波动门槛仍有两套口径，且无 FC1 开配置下的阈值（上轮 F5 open，本轮未提门槛）

Where: 正文验收条件第 2 条（[x]，两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)）与第 3 条「该档门槛」；评论 6610897338「thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor」；「已封存基线」表 1.000%–2.526%（来源为 FlashComm1 关）。
Problem: 触发评论与本轮正文都没有回应，两套公式不可能同时是第 3 条的「该档门槛」；FC1 开配置下仍无由冻结公式得到的阈值。
Impact: compact 的 6.84%/7.12% 两套口径同向，但 FSQ 的 1.93%、FS 的 3.18% 会因口径翻转。
Fix: 由 owner（.github/knowledge-model-policy.json:50 approval_owners: ["Dong1017"]）在正文与 plan/ 写明唯一公式、是否适用于 FC1-on/fused-MC2-off、三对校准封存后的生效时点。

F17 — high，must-fix（需 owner 决定）— UT 计数门禁在两次失败后被改为匹配候选，处置决定仍未记录（上轮 F17 open）

Where: 正文状态块「前两次门禁因预期 36 项与实际收集数不符而停止…」；评论 6611525929「The first two gate transactions stopped because the controller expected 36 UT cases… 37 UTs and 7 A3 STs」；对照评论 6610322256 的 FSQ「9 UTs and 16 A3 STs」；docs/contributing.md:105-106（全部尝试与被拒改动须保留）。
Problem: 本轮未提及测试，正文只复述「门禁被调整过」，没有决定：期望用例清单是否冻结、为何允许改校验方式、两次失败事务的回执位置、9 UT/16 ST → 37 UT/7 ST 的逐项对应。
Impact: 「37 UT/7 ST 通过」仍由事后调整的门禁自证，无法判断 FSQ 的 16 项 ST 被 7 项替代后保护是否等效。
Fix: 由 owner 在正文与 plan/ 记录上述四项，并给出两次失败事务的归档路径/摘要。

F16 — high，must-fix（需 owner 决定）— 本轮六档 sweep 只写了开关取值，未写环境签名/服务身份，仍无法绑定 RunSpec（上轮 F16 收窄）

Where: 触发评论「TP4 / DP4 / EP16, DSpark5, FULL_DECODE_ONLY, explicit FlashComm1 and fused MC2=0」「fresh FSQ parent service」；正文「当前开关要求」要求新增测量标明 enable_flashcomm1=true、VLLM_ASCEND_ENABLE_FLASHCOMM1=1、enable_fused_mc2=0；评论 6610897338 的校准对只写环境 da05a8aa0892。
改善: 本轮首次按正文要求写明两个开关的实际取值（这点正确）。
仍缺: 未写环境签名、服务实例标识，也未写模型长度 16,384 / block 128 / capture 24-48 / 每 DP 最多 8 序列等冻结服务参数；校准对 C1 94.05/C32 129.23 仍与 FC1 关基线 93.862/129.043 重合，而比全部 FC1 开 B 臂慢 15%–19%，配置归属依旧无记录。
Impact: 63.97–88.14 与门槛、与 compact 的 6.84%/7.12% 无法证明处于同一 RunSpec。
Fix: 每轮（含校准对、六档 sweep）写明环境签名与服务参数；若校准跑在 FC1 关，则在 FC1 开下按冻结公式补一次校准，并说明正式配对的父臂。

F12 — medium，must-fix — 本轮给出新的 FSQ 父臂读数，却仍以旧读数作 compact 对照，收益值取决于用哪一组（上轮 F12 open，新增证据）

Where: 触发评论「The prior compact-mask screen remains 59.86 / 80.42 ms/token at 1 / 32 concurrency, with direct FSQ controls of 64.26 / 86.59」与其自身新测的父臂 C1 63.97、C32 88.14；评论 6611525929 的 FSQ 列同为 64.26/86.59。
Problem: 同一 manifest b054b5a4… 现在有两个 C32 读数（86.59、88.14，相差 1.79%）与两个 C1 读数（64.26、63.97，相差 0.45%）。若用本轮新父臂，compact 收益应为 6.42% / 8.76%，而非评论仍引用的 6.84% / 7.12%；且 compact 测于 17:57 的独立服务，父臂测于 18:10 的「fresh」服务，仍是跨会话作差。
Impact: 收益幅度可在 6.4%–8.8% 间浮动而无人记录哪个父臂是协议对照，保留判定与门槛比较都不唯一。
Fix: 明确 compact 的对照父臂是哪一次测量并标注跨会话漂移，或补一次 FSQ→compact 同会话配对（每档至少一波）。

F13 — medium，must-fix — compact 的等价性证据仍无控制臂噪声底、不覆盖语义差异面（上轮 F13 open）

Where: 正文状态块「C1 输出及投机指标一致，C32 完整输出哈希 6/32 一致」；冻结配置为 block 128、每请求精确 1,024 入/1,024 出（8 个整块、无前缀缓存）；评论 6611525929「No new accuracy run」；本轮同样「No new accuracy score」。
改善: C32 哈希一致由 FS 的 0/32 升至 6/32，落在历史同版本重复 5/32、2/32 的噪声区间内。
仍缺: 没有同版本 C32 重复给出哈希一致率噪声底，也没有非 128 整数倍提示长度、前缀缓存命中、可见长度不齐时的逐 token 对照，而改动恰好影响「每块一次决策 + 四层跟随掩码」在这些情形下的语义。
Impact: 掩码广播若在部分块或复用路径不同，TPOT 不暴露，只会出现在 300 题（余量 2 题）或下游质量上。
Fix: 补噪声底重复与部分块/复用/不等长可见性的对照，并按 F9 结论在保留前跑冻结 300 题。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定问题，也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:216-217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 为 Dong1017。
Problem: 该行没有具体问题与决策人；F5（门槛公式）、F16（配置归属）、F9（精度门禁顺序）、F17（UT 门禁）、F4（另一 RunSpec 记录归属）仍散在评论里。
Impact: 读者无法区分已定与未定，也无法判断是否具备开始正式配对的条件。
Fix: 把待决项逐条改写为问题并指定 owner，Next action 写明谁做什么。

F18 — medium，suggestion — 本轮六档 sweep 的逐档 FULL 回放/DP 覆盖与预热规模仍不完整

Where: 触发评论「The startup gate verified FULL replay on all four DPs. The sampled measurement windows at 4, 8 and 16 showed only a subset of their active DPs. The window at 32 showed all four.」与「after a separate warmup」；正文验收条件第 4 条要求逐档核对「DSpark 提议/接受和 decode FULL 回放」；「已封存基线」对此保留 证据完整性标志 = false。
Problem: FULL 回放只在启动门禁上确认，C4/C8/C16 的测量窗口只覆盖「部分」活跃 DP 且未给出是几/4，也没有像基线那样记录完整性标志；每档预热请求数/输出长度同样未写。
Impact: 六档中三档的 FULL 回放无法与计时窗口对齐，PASS 时无法证明测量期确实走在 FULL 路径。
Fix: 逐档记录采样到的活跃 DP 数与 FULL 回放条数（含完整性标志），并写明每档预热请求数与输出长度。

F6 / F11 — medium，suggestion — 单 rank 归因仍无法与客户端收益对账（上轮 F6、F11 open，本轮未回应）

Where: 正文状态块「单层 mask expansion 为 26.78–27.99 ms/graph」；评论 6606963791「13 次长索引读取合计 49.74–49.76 ms」；评论 6609641928（F2 相对 B 11.44%/14.81%）；评论 6611525929「八组融合索引打分内核合计 0.68–0.76 ms/graph」。
Problem: 索引打分内核不足 1 ms/graph 与 49.74 ms/step、F2 的 9–16 ms/token 收益差一到两个数量级，说明探针与图中算子不是同一形状；掩码展开 26.78–27.99 ms/graph 对应 compact 的 4.40/6.17 ms/token，节省量仍未算清；per graph / per step / per token 三种口径无统一换算。
Impact: 单 rank 归因无法换算成可核对的上限，G 的整模回归已证明这类外推会失效。
Fix: 补单位表与探针形状表，说明旧数值是否作废，并给出 ms/step → TPOT 的对算式。

F4 / F7 / F15 — medium，suggestion — 遗留项本轮仍未回应

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25 ms/token）混在同一 Issue；需 owner 决定移出或以指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/代码摘要；本次检出 grep -rn "aisbench|AISBench"（md/py/json）无任何引用，294/300 不可复算。可考虑以 Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为候选 pin。
F15: FSQ/compact 的数值改动仍未说明量化对象（KV 值/权重/输入输出）、分组轴与 scale 来源、开关与默认值，无法按验收条件第 3 条核对单一假设与预设受益档。
Fix: 按各项原建议逐条回应，或在正文记录处置。

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

DSpark live batch shadow and three-stage replay

On the FSQ plus batched-draft-attention candidate, 24 UT and 3 A3 system tests passed. Live side-by-side attention used the same worker, Q, KV and page tables. Across 16 ranks, all 672 stage comparisons were finite and bitwise equal. On the unchanged parent service the 96-token repeated greedy waves matched 1/1 complete output hashes at concurrency 1, 0/32 at balanced concurrency 32, and 1/12 for the mixed layout. Candidate vs both parent repeats matched at concurrency 1, including per-DP counters. Cross-service equivalence under concurrency remains inconclusive.

The isolated, fixed-state three-stage graph was captured at one request and passed four transitions on all 16 ranks. The fifth triggered the intended all-rank eager fallback. On DP3's one live request, two eager executions differed in 21,901 of 25,600 BF16 hidden elements on all four TP ranks. The five Markov proposal IDs agreed, both tensors were finite, and the private cache write checks passed. Investigation stopped there. Larger draft buckets and model timing were not reached. The original source and native installation have been restored. No measured gain or new accuracy score for this candidate.

Separately, both independently launched initial calibration services and the plain FSQ six-tier sweep missed the same active DPs in the sampled replay logs at 4/8/16. Raw log scans including all TP ranks confirmed the missing markers. The next old-protocol pair is on hold while an independently identified per-worker counter observer is being validated. A different observation environment requires fresh calibration.

意图：维护 dsv41-910c-decode-tpot25 验收（六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300）。18:30 编辑把 18:10 的 FSQ 父版本探索性六档 sweep（63.97/62.80/65.26/67.42/69.03/88.14，63 个请求，C4/C8/C16 采样只覆盖部分活跃 DP）写入状态块，逐项与评论 6611796086 相符（1+2+4+8+16+32=63），F14 已修；但候选仍无提交、证据仍不在仓库、门槛与精度门禁顺序仍未决，且编辑删除了此前的 UT/ST 回执、两次门禁失败、C32 profile 与服务释放检查，结论维持 needs information / human decision required。正文没有请求修改代码的句子，不构成开发授权；未发现引导自动评审的文本或新增脱敏泄漏。不返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status 标签。

F1 — high — 六档 sweep 的父版本仍只有工作树摘要，没有可检出提交（上轮 open）

Where: 状态块「不是可检出提交」、候选表「待正式验收后提交」；评论 6611796086 的 b054b5a45f45…；AGENTS.md:87、campaign-acceptance.yml:29-32。
Problem: 首个全六档数据仍绑定源码摘要，正文把候选 SHA 排到验收之后。
Impact: 六档、测试与 300 题无法在具名修订上复跑，PASS 不成立。
Fix: 保留判定前把 FSQ 及候选落成 codex/dsv41-0day 提交，记录完整 SHA、父 SHA、64 位清单摘要。

F2 — high — 证据仍不在仓库，本轮也未给 sweep 路径/摘要（上轮 open）

Where: 正文「证据索引」只写 perf25/...；评论 6611796086 的客户端回执 9dbe29b3… 无路径；AGENTS.md:89、docs/contributing.md:107。
本次核实（663f3b3）：python tools/validate_evidence.py → errors: []、21 bundle、430 哈希，无 dsv41/perf25；ls perf25、ls evidence/dsv41-910c-decode-tpot25 均不存在；tools/evidence_inventory.json 无本 campaign。
Impact: 六档数值、逐波 SSE/EOF 重算与 DP 覆盖只存在于评论。
Fix: 补本轮 results/、trials/、preflights/ 路径与 SHA-256，PASS 前导入 evidence/<campaign-id>/ 并登记清单。

F3 — high — 历史评论 6602376192 仍未脱敏（上轮 open）

Where: 评论 6602376192 的 3.2/3.3/3.5/5.2/10–12 节（节点 IP、Pod 全名、/a3_inference/...、/Users/jiangchenzhou/...）；docs/privacy-security.md:10-16、AGENTS.md:119-124。
本次核实：updated_at == created_at（11:15:56Z），从未编辑；本次正文未新增泄漏（这点正确）。
Impact: 个人路径与内部拓扑持续公开，导入证据树会固化泄漏。
Fix: 作者编辑该评论改用 <REMOTE_HOST>/<REMOTE_USER>/<MODEL_PATH>，导入前再复查。

F5 — high（需 owner）— 逐档门槛仍两套口径，且无 FC1 开下的阈值（上轮 open）

Where: 状态块「生效关系仍待明确」；验收条件第 2 条（两组/四服务、max(1%, 两组内…)）与第 3 条「该档门槛」；评论 6610897338（三对最大值、1% 底）；封存表 1.000%–2.526%（FC1 关）。
Problem: 编辑只是把矛盾写进状态块；两种公式不可能同时是第 3 条门槛，FC1 开下无冻结阈值（AGENTS.md:87、docs/contributing.md:100-101）。
Impact: FSQ 1.93%、FS 3.18% 会因口径翻转。
Fix: owner（.github/knowledge-model-policy.json:50 为 Dong1017）在正文与 plan/ 定唯一公式、适用配置与生效时点。

F9 — high（需 owner）— 精度门禁顺序仍与已勾选条件冲突（上轮 open）

Where: 评论 6611796086「The paired performance gate must pass before starting the fixed GSM8K-300 evaluation」；验收条件第 4 条（每个保留提交 ≥292/300）；评论 6607845822；docs/contributing.md:100-101。
Problem: 控制器在搜索后被改成性能优先，正文与 plan/ 未记录；G 轮 298 条轨迹仍无归档或作废说明。
Impact: 可能出现「性能通过但从未产出 300 题结论」的保留；掩码语义改动余量仅 2 题。
Fix: owner 二选一并写入正文/plan/：(a) 确认新顺序且最终版本独立跑 300 题并处置 298 条轨迹；(b) 每个保留提交即测 300 题。

F16 — high（需 owner）— sweep 写了开关，但仍无环境签名与服务参数，校准配置归属未记（上轮 F16 收窄）

Where: 状态块「显式 FlashComm1 开、fused MC2=0」；评论 6611796086「fresh…service」「TP4/DP4/EP16」；评论 6610897338 的校准对 C1 94.05/C32 129.23 与 FC1 关基线 93.862/129.043 重合，却比 FC1 开 B 臂慢 15%–19%。
改善: 首度写明两个开关取值（正确）。
仍缺: 环境签名、服务实例、模型长度/block/capture/每 DP 序列数，以及校准对跑在哪种开关组合。
Impact: 63.97–88.14 与门槛、与 compact 收益无法证明同一 RunSpec。
Fix: 每轮写明环境签名与服务参数；若校准为 FC1 关，则在 FC1 开下补一次校准并说明父臂。

F17 — high（需 owner）— UT 计数门禁两次失败后被改为匹配候选，处置决定未记（上轮 open，本次连事件也被删）

Where: 评论 6611525929（控制器期望 36 项、两次事务中止、改为按 JUnit 核验后放行、37 UT/7 A3 ST）对照评论 6610322256 的 9 UT/16 ST；本次状态块已不提；docs/contributing.md:105-106。
Problem: 期望清单是否冻结、为何允许改校验方式、两次失败回执位置、9 UT/16 ST → 37 UT/7 ST 对应表都缺失。
Impact: 通过结论由事后调整的门禁自证，无法判断 ST 覆盖是否等效。
Fix: owner 在正文与 plan/ 记录上述四项并给出失败事务归档路径/摘要。

F12 — medium — compact 的对照父臂用旧读数，而本次编辑自带同 manifest 的新父臂（上轮 open，新增证据）

Where: 状态块「59.86 / 80.42 对应当轮 FSQ 对照 64.26 / 86.59」对照同段新 sweep 的 C1 63.97、C32 88.14（同一 b054b5a4…）。
Problem: 同父 manifest 现有两个 C32 读数（86.59、88.14，差 1.79%）与两个 C1 读数（64.26、63.97）；用新父臂收益应为 6.42% / 8.76%，且两臂仍跨会话。
Impact: 收益可在 6.4%–8.8% 浮动，保留判定不唯一。
Fix: 指明哪次测量是协议对照并标注漂移，或补一次同会话 FSQ→compact 配对。

F19 — medium（新）— 本次编辑删除了此前写在状态块里的失败与收尾证据

Where: 17:57 版状态块含「37 UT / 7 A3 ST 报告通过，前两次门禁因预期 36 项与实际收集数不符而停止…」「单层 mask expansion 26.78–27.99 ms/graph」「服务释放、B 恢复及设备空闲检查通过」；18:30 正文均已删除，仅剩「早前…失败和取消记录保留」；docs/contributing.md:105-106。
Problem: 这三项是上轮保留判定的直接依据（门禁失败正是 F17 的待决对象，profile 是 compact 的动机来源），删除后正文自称的保留承诺与内容不符。
Impact: 从正文无法看到门禁被调整、compact 归因来源与服务已释放。
Fix: 恢复一行紧凑的证据/失败摘要并指向对应评论。

F13 — medium — compact 等价性证据仍无噪声底、不覆盖语义差异面（上轮 open）

Where: 状态块「C32 完整输出哈希 6/32 一致」；冻结配置 block 128、每请求 1,024/1,024（8 个整块、无前缀缓存）；评论 6611796086「No new accuracy score」。
改善: 6/32 已落在历史同版本 5/32、2/32 的噪声区间。
仍缺: 同版本 C32 重复给出的哈希一致率噪声底，以及非 128 整数倍提示长度、前缀缓存命中、可见长度不齐时的逐 token 对照；改动恰影响「每块一次决策 + 四层跟随掩码」在这些情形的语义。
Impact: 广播掩码若在部分块/复用路径不同，TPOT 不会暴露，只会在 300 题（余量 2 题）出现。
Fix: 补噪声底重复与上述对照，并按 F9 结论在保留前跑冻结 300 题。

F8 — medium（需 owner）— Decision needed 行仍不可判定，无决策人（上轮 open）

Where: 首行「最终是否满足下方既有验收条件仍待证据…」；docs/agent-collaboration.md:213-217 要求 <question>, from <decision owner> / none；policy approval_owners: ["Dong1017"]。
Problem: 只写「仍待证据」，F5/F16/F9/F17/F4 等未决项散在评论里。
Impact: 读者无法区分已定与未定，也无法判断能否开始正式配对。
Fix: 逐条改写为问题并指定 owner，Next action 写明谁做什么。

F18 — medium，suggestion — 六档 sweep 的逐档 DP/FULL 回放与预热规模仍不完整（上轮 open，本次编辑有改善）

Where: 状态块现已写入「C4/C8/C16 测量采样窗口只覆盖部分活跃 DP」（改善，方向正确）；评论 6611796086 只写「a subset of their active DPs」「after a separate warmup」。
仍缺: 每档采样到的活跃 DP 数（几/4）、逐档 FULL 回放条数与完整性标志、每档预热请求数与输出长度、逐档 DSpark 接受比（评论仅给合计 45,441/95,605）。
Impact: 三档的 FULL 回放无法与计时窗口对齐，PASS 时无法证明测量期走在 FULL 路径。
Fix: 按验收条件第 4 条逐档补齐上述记录。

F6/F11 — medium，suggestion — 单 rank 归因仍无法与客户端收益对账（上轮 open）

Where: 评论 6606963791「13 次长索引读取合计 49.74–49.76 ms/step」；评论 6609641928（F2 相对 B 11.44%/14.81%）；评论 6611525929「八组融合索引打分内核合计 0.68–0.76 ms/graph」。
Problem: 不足 1 ms/graph 与 49.74 ms/step、9–16 ms/token 收益差一到两个数量级；掩码展开 26.78–27.99 ms/graph 与 compact 的 4.40/6.17 ms/token 也对不上；per graph / per step / per token 无统一换算。
Fix: 补单位表与探针形状表，说明旧数值是否作废，并给出 ms/step → TPOT 对算式。

F4 / F7 / F15 — medium，suggestion — 遗留项仍未回应（保持 open）

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign 混在同一 Issue，需 owner 决定移出或用指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/摘要；本次检出 grep -ri aisbench 无任何引用，294/300 不可复算；可考虑以 Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为候选 pin。
F15: FSQ/compact 的数值改动仍未说明量化对象、分组轴与 scale 来源、开关与默认值，无法核对「单一假设 + 预设受益档」。
Fix: 逐条回应或在正文记录处置。

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

意图：维护 dsv41-910c-decode-tpot25 验收；18:30 评论新增 FSQ+batched-draft-attention 候选的 24 UT/3 A3 ST、16 rank 672 项逐阶段 bitwise 相等、父服务重复波哈希一致率（C1 1/1、C32 0/32、混合 1/12），并记录 DP3 两次 eager 执行有 21,901/25,600 BF16 元素不同后停止排查；同时确认两台独立校准服务与六档 sweep 在 C4/8/16 都缺同一批活跃 DP 的 replay 标记，下一对校准暂停等待新观察器、环境变化需重新校准。结论：needs information / human decision required，整体维持 INCONCLUSIVE；正文没有请求修改代码的句子，不构成开发授权，也未发现引导自动评审的文本。前轮结论：F13 的「无噪声底」部分由本轮父服务重复波回答（C32 同版本重复 0/32），其余 open 项已在 findings 中按原编号更新实例，本轮新增 F19–F22。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 须配合 status 标签而本 Issue 无。

F19 — high，must-fix（需 owner 决定）— 唯一已公布的同版本校准组同样缺 C4/8/16 的活跃 DP replay 标记

Where: 触发评论「both independently launched initial calibration services and the plain FSQ six-tier sweep missed the same active DPs in the sampled replay logs at 4/8/16」；评论 6610897338（三对校准中的 pair 1/3）；正文验收条件第 2 条已 [x]、第 4 条要求逐档核对 decode FULL 回放；已封存基线保留 证据完整性标志 = false。
Problem: 此前只把缺 DP 当作 sweep 的瑕疵；本轮确认两台独立校准服务同缺陷，而三对校准正是第 2 条已勾选的阈值来源，其唯一已公布组无法证明 C4/8/16 的测量窗口走在 FULL 路径上。
Impact: 逐档阈值可能来自未验证 FULL 路径的窗口，第 2 条不应保持 [x]；据此判候选保留/淘汰时判定与测量条件不对应。
Fix: 由 owner 决定 pair 1 是否作废、第 2 条是否退回未完成，并在正文与 plan/ 逐档记录采样到的活跃 DP 数、FULL 回放条数与完整性标志（AGENTS.md:64）。

F20 — high，must-fix（需 owner 决定）— 新候选 eager 回退路径两次执行有 85.6% 隐藏元素不同，排查停止且无归档

Where: 触发评论「two eager executions differed in 21,901 of 25,600 BF16 hidden elements on all four TP ranks … Investigation stopped there」；同评论的 672 项 bitwise 相等只覆盖图路径。
Problem: 同一固定状态、同一请求的两次 eager 执行差异 21,901/25,600（约 85.6%），而五个提案 ID 相同、两tensor 均 finite，说明差异在 hidden 数值而非采样；评论未给 dump/日志路径，也未按 docs/contributing.md:105-106 保留失败试验回执。
Impact: 若 eager 是全 rank 回退时的正确性兜底，则兜底与图路径不等价，候选在触发回退时静默产出不同数值；无根因的候选不能进入性能或精度比较。
Fix: 标为失败试验并归档两份张量（dtype/形状、逐 rank dump 路径 + SHA-256）；由 owner 二选一：放弃该候选，或先定位差异（初始化/未定义行为/算子选择）再恢复测量。

F1 — high，must-fix — 第四轮候选连清单摘要都没有，只有一个描述性名字（上轮 F1 open）

Where: 触发评论首句「On the FSQ plus batched-draft-attention candidate」；正文表「候选 Git SHA | 待正式验收后提交」；AGENTS.md:87、.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33（candidate_sha 必填 Full git SHA）。
Problem: 前三轮至少给了工作树清单 SHA-256，本轮只给名称，未写父版本与改动文件。
Impact: 24 UT/3 A3 ST、672 项逐阶段比较、DP3 两份张量都无法绑定到可检出或可校验的对象。
Fix: 保留判定前把该候选落成 codex/dsv41-0day 上的提交，逐轮记录完整 SHA、父 SHA 与 64 位清单摘要。

F2 — high，must-fix — 本轮所有新证据都只有评论正文，没有仓库内路径/摘要（上轮 F2 open）

Where: 触发评论的 672 项比较、24 UT/3 ST、DP3 两种 eager 张量、两次校准服务的原始日志扫描均无路径或哈希；正文「证据索引」仍只列 perf25/… 相对路径；AGENTS.md:89、docs/contributing.md:117-122。
本次实际核实（检出 663f3b3）： python tools/validate_evidence.py → errors: []、21 个 bundle、checked_hashes: 430，无本 campaign；evidence/dsv41-910c-decode-tpot25 不存在；tools/evidence_inventory.json 无 dsv41/perf25 条目；tools/validate_evidence.py:10-16 要求先登记 kind，campaign 需 plan/results/patch/validator。
Impact: 决定「候选是否作废、校准是否重做」的原始比对、dump 与日志扫描无法复核或下游引用。
Fix: 给本轮 results/trials/preflights 路径与 SHA-256（失败试验单列 receipt），判 PASS 前按 evidence/<campaign-id>/{plan,results,patch,validator} 导入并登记清单。

F3 — high，must-fix，隐私 — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

Where: 该评论 3.2/3.3/3.5/5.2/10–12 节含节点 IP 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-jcz02615514-…、/a3_inference/itask/workdir/jcz02615514/jcz-afd1、/Users/jiangchenzhou/…；docs/privacy-security.md:10-13、AGENTS.md:121-124。
本次核实： 该评论 created_at=updated_at=2026-11-03T11:15:56Z，从未编辑；本轮评论与正文未新增泄漏（这点正确）。
Impact: 个人身份路径与内部拓扑持续公开；导入证据树会把泄漏固化进仓库。
Fix: 由作者编辑该评论，以 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 替换；导入前再脱敏复查。

F5 — high，must-fix（需 owner 决定）— 门槛仍两套口径，且本轮要求重新校准后仍无 FC1 开配置下的阈值（上轮 F5 open）

Where: 正文验收条件第 2 条（[x]，两组/四服务 max(1%, …)）与第 3 条「该档门槛」；评论 6610897338「maximum across the three complete chronological same-version pairs, with a 1% floor」；已封存基线 1.000%–2.526%（FlashComm1 关）；触发评论「A different observation environment requires fresh calibration」。
Problem: 两套公式不可能同时是第 3 条的门槛；现在又追加「需重新校准」，但正文与 plan/ 未写新校准的档位、公式、环境与生效时点。
Impact: FSQ 的 1.93%、FS 的 3.18% 会因口径翻转；重新校准未先冻结则后续配对失去稳定判据（docs/contributing.md:101）。
Fix: 由 owner（.github/knowledge-model-policy.json:50 为 Dong1017）在正文与 plan/ 写明唯一公式、是否适用 FC1-on/fused-MC2-off、重新校准范围与环境签名，并标注此前各轮为探索性。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，本轮又一次「没有新精度运行」（上轮 F9 open）

Where: 正文验收条件第 4 条（每个保留提交及最终版本 ≥292/300）；触发评论「No measured gain or new accuracy score for this candidate」；评论 6611796086「The paired performance gate must pass before starting the fixed GSM8K-300 evaluation」；docs/contributing.md:101。
Problem: 控制器把 300 题移到配对性能之后，正文与 plan/ 未记录；本轮一个改动 draft attention 批处理的候选做了两轮等价性却没有精度结论。
Impact: 可能出现「性能通过但从未产出 300 题结论」的保留；294/300 距门槛仅 2 题，语义偏差只能靠该测试集暴露。
Fix: 由 owner 二选一并写入正文与 plan/：(a) 确认新顺序且最终版本仍独立跑 300 题；(b) 维持「每个保留提交即测 300 题」。

F16 — high，must-fix（需 owner 决定）— 本轮测量完全没写开关取值与环境签名，RunSpec 绑定回退（上轮 F16 open）

Where: 触发评论未写 enable_flashcomm1=true / VLLM_ASCEND_ENABLE_FLASHCOMM1=1 / enable_fused_mc2=0、环境签名与模型长度 16,384 / block 128 / capture 24-48 / 每 DP 最多 8 序列；正文「当前开关要求」要求新增测量标明；冻结表环境签名 44411269…，第二、三轮 a3d9fcf0…，校准对 da05a8aa0892。
Problem: 上一轮至少写了开关取值，本轮连这点也缺失；评论又称环境变化需重新校准，却不给新签名。
Impact: 672 项比较、24 UT/3 ST 与后续 TPOT 无法证明与 compact 的 6.84%/7.12% 或门槛处于同一 RunSpec。
Fix: 每轮写明两个开关实际取值、环境签名与服务参数；若环境变化，先按冻结公式补校准并说明正式配对的父臂。

F17 — high，must-fix（需 owner 决定）— 用例计数第三次变化（9/16 → 37/7 → 24/3），仍无冻结清单与对应关系（上轮 F17 open）

Where: 触发评论「24 UT and 3 A3 system tests passed」；评论 6611525929 的 compact「37 UTs and 7 A3 STs」与两次失败事务；评论 6610322256 的 FSQ「9 UTs and 16 A3 STs」；docs/contributing.md:105-106。
Problem: 每轮期望用例数都在变（本轮 A3 ST 由 7 降到 3、UT 由 37 降到 24），正文只复述「门禁被调整过」，无冻结清单、无逐项对应、无失败事务归档路径。
Impact: 「测试通过」由事后调整的门禁自证；无法判断 FSQ 的 16 项 ST 被更少用例替代后保护是否等效，尤其本轮还伴随一次未定位的数值分歧（F20）。
Fix: 由 owner 冻结每轮期望用例清单与计数规则，记录为何改校验方式、两次失败事务 receipt 路径与摘要，并给出三组计数对应关系。

F21 — medium，must-fix（需 owner 决定）— 观察器与校准环境在冻结后被更换，正文未记录新协议

Where: 触发评论「The next old-protocol pair is on hold while an independently identified per-worker counter observer is being validated. A different observation environment requires fresh calibration.」；正文冻结表「公共环境签名 44411269…」；AGENTS.md:64、docs/contributing.md:105。
Problem: 冻结的 replay 日志观察方式被判不可用，改用 per-worker 计数器观察器，并要求重新校准；但正文与 plan/ 未给新观察器身份/摘要、新环境签名，也未说明第 1 组校准与旧阈值在新环境下的效力。
Impact: 第 2、3 对校准与后续正式配对将处于不同观察环境，逐档阈值与 FULL 回放核对无法对齐同一 RunSpec。
Fix: 由 owner 在正文与 plan/ 记录新观察器（代码/版本/摘要）、新环境签名、重新校准范围与旧校准的作废或沿用。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定问题，也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:213-217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 为 Dong1017。
Problem: 该行只是「仍待证据」，无具体问题与决策人；本轮待决项至少四项：F5（门槛与重新校准）、F19（pair 1 是否作废）、F9（精度门禁顺序）、F20（候选是否放弃）。
Impact: 读者无法区分已定与未定，也无法判断正式配对何时可开始；这四项恰好都阻塞下一步。
Fix: 把待决项逐条改写为问题并指定 owner，Next action 写明谁做什么。

F12 — medium，must-fix — compact 的对照父臂仍不唯一，本轮又添一个新的 FSQ 读数（上轮 F12 open）

Where: 触发评论仍引用「direct FSQ controls of 64.26 / 86.59」；新测父臂为 C1 63.97、C32 88.14（同一清单 b054b5a4…）；评论 6611525929 的 FSQ 列同为 64.26/86.59。
Problem: 同一 manifest 现有两个 C32 读数（86.59、88.14，差 1.79%）与两个 C1 读数（64.26、63.97）；用新父臂则 compact 收益为 6.42%/8.76%，而非仍引用的 6.84%/7.12%，且三次测量在不同会话/服务。
Impact: 收益在 6.4%–8.8% 间浮动而无人记录哪个父臂是协议对照，保留判定与门槛比较都不唯一。
Fix: 标注对照父臂是哪一次测量并给出跨会话漂移，或补一次 FSQ→compact 同会话配对。

F13 — medium，must-fix（部分回答）— 噪声底已由本轮父服务重复波回答，部分块/前缀缓存语义面仍缺（上轮 F13 open）

Where: 触发评论「On the unchanged parent service the 96-token repeated greedy waves matched 1/1 … at concurrency 1, 0/32 at balanced concurrency 32, and 1/12 for the mixed layout」；正文状态块「C32 完整输出哈希 6/32 一致」；冻结配置 block 128、每请求 1,024 入/1,024 出（8 个整块、无前缀缓存）。
已回答部分: 同版本父服务 C32 重复波 0/32 给出噪声底，说明 compact 的 6/32 高于该底，但也说明 C32 整段输出哈希不是可靠的等价性信号（候选对父重复仅在 C1 匹配）。
仍缺: 非 128 整数倍提示长度、前缀缓存命中、可见长度不齐时的逐 token 对照，而改动恰好影响「每块一次决策 + 四层跟随掩码」在这些情形下的语义。
Fix: 补上述场景的逐 token 对照，并按 F9 结论在保留前跑冻结 300 题。

F22 — medium，must-fix — 同一次 18:30 正文更新仍未包含本评论的新候选、eager 失败与校准暂停

Where: 正文 **Current state:**（只写到 18:10 的 FSQ sweep 与「新同版本校准仍仅已公布第 1/3 组」）、**Next action:**（「继续在原线程记录已启动工作的结果及证据」）；docs/agent-collaboration.md:213（执行方保持三行块最新）。
Problem: 18:30 评论新增第四轮候选、其 eager 失败、观察器更换与重新校准要求、下一对校准暂停，均未进入状态块；Next action 也未反映校准依据正在失效。
Impact: 按状态块判断进展会漏掉当前唯一阻塞（校准依据失效 + 候选失败），也无法据 Next action 判断谁在等什么。
Fix: 更新三行块：写入 pair 1 的 FULL 回放缺口、观察器与重新校准、eager 失败候选的处置。

F18 — medium，suggestion — 六档 sweep 的逐档 DP/FULL 计数与预热规模仍不完整（上轮 F18 open）

Where: 评论 6611796086「Only a subset of their active DPs … The window at 32 showed all four」「after a separate warmup」；验收条件第 4 条要求逐档核对 FULL 回放；已封存基线保留完整性标志 false。
Problem: C4/C8/C16 未写「几/4」DP、FULL 条数与完整性标志，预热请求数与输出长度也未写。
Impact: 三档的 FULL 回放无法与计时窗口对齐，PASS 时无法证明测量期走在 FULL 路径。
Fix: 逐档记录采样到的活跃 DP 数、FULL 回放条数与完整性标志，并写明预热规模（F19 的校准部分单独处理）。

F6 / F11 — medium，suggestion — 单 rank 归因与客户端收益仍无法对账（上轮 open，本轮未回应）

Where: 正文状态块「单层 mask expansion 26.78–27.99 ms/graph」；评论 6606963791「13 次长索引读取合计 49.74–49.76 ms」；评论 6609641928（11.44%/14.81%）；评论 6611525929「八组融合索引打分内核合计 0.68–0.76 ms/graph」。
Problem: 打分内核不足 1 ms/graph 与 49.74 ms/step、9–16 ms/token 收益差一到两个数量级，探针与图中算子形状不同；掩码展开与 compact 的 4.40/6.17 ms/token 之间无换算。
Fix: 补单位表与探针形状表，说明旧数值是否作废，并给出 ms/step → TPOT 的对算式。

F4 / F7 / F15 — medium，suggestion — 遗留项本轮仍未回应（保持 open）

F4: 评论 6602376192 的《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25）混在同一 Issue，需 owner 移出或以指针声明。
F7: 第 4 条的 AISBench 判分工具仍无 revision/摘要；本次检出 grep -rn "aisbench\|AISBench\|Gsm8kEvaluator"（md/py/json）无任何命中，294/300 不可复算，可考虑以 Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为候选 pin。
F15: FSQ/compact 的数值改动仍未说明量化对象、分组轴与 scale 来源、开关与默认值，无法按第 3 条核对单一假设与预设受益档。

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

Single-pass E4M3 QDQ on the compact candidate

The four production WO/KV shapes at FULL widths 24 and 48 dispatched the single-pass kernel on all 16 ranks. The measured service used the same TP4/DP4/EP16, DSpark5, 16K, explicit FlashComm1 and disabled fused MC2 configuration as the compact-mask control. Each request used 1,024 input and 1,024 output tokens.

Global concurrency	Direct compact control (ms/token)	Single pass (ms/token)	Single-round reduction
1	59.86	55.50	7.30%
32	80.42	74.46	7.41%

C1 produced identical output and accepted 717/1,540 draft tokens in both arms. At C32 the input set matched, 2/32 complete outputs matched and total acceptances were 23,068 and 23,047 respectively. These are initial screening measurements. The intermediate four tiers on this candidate, three formal pairs and GSM8K-300 remain pending.

The first system-test run stopped on a fixture that requested a physically blocked input but obtained ND. The revised test directly allocated FRACTAL_NZ and verified format 29. The production code was byte-identical between the two runs. The final source manifest is f070ea2af1371240ef1397647caf05a5d02cfb3b4a53ecadcc9ec99285e8da71. Its 13 UT and 29 A3 ST passed including the actual blocked-format fallback. The completed InferRSI capture returned 0 and the original device installation was restored.

A subsequent single-device test kept stock sparse attention at 38 calls per arm and reused physical KV slots across layers. Correctness checks passed for both 4,096 and 194,176 physical rows. On the large table, the 38-layer subgraph at six verification rows went from 20.69–20.72 to 13.68–13.72 ms, and at twelve rows from 27.69–27.76 to 17.12–17.16 ms. All seven pairs at each combination of width and length improved. These local replay times do not contribute to the client TPOT table above. Product integration and a 16-rank service measurement are pending.

意图：维护 dsv41-910c-decode-tpot25 验收（DeepSeek V4.1 Flash / 910C，六档 decode TPOT ≤25 ms/token + 固定 GSM8K ≥292/300），并持续记录候选筛选与校准证据。触发评论新增「compact 上的 single-pass E4M3 QDQ」候选（C1 59.86→55.50、C32 80.42→74.46，7.30%/7.41%）与 13 UT / 29 A3 ST 回执，作者自述仅为初筛、中间四档／三组正式配对／GSM8K-300 均未做，整体仍 INCONCLUSIVE。结论：needs information / human decision required——正文没有请求代码变更的句子，不构成开发授权；未发现引导自动评审的文本。早前项：F22 部分 fixed（18:10 六档 sweep 已写入状态块），F1–F21 其余仍 open，本轮新证据的问题集中在对照臂跨会话复用（F12）与被改写的测试夹具（F17）。未返回标签：kind:acceptance、area:workbench 已由人设置，priority:* 依 .github/labels.json 须配合 status 标签，而本 Issue 无 status 标签。

F20 — high，must-fix（需 owner 决定）— eager 回退路径两次同态执行有 85.6% BF16 元素不同，本轮直接换候选、无处置记录

Where: 评论 6612233089「two eager executions differed in 21,901 of 25,600 BF16 hidden elements on all four TP ranks … Investigation stopped there」「The fifth triggered the intended all-rank eager fallback」；触发评论全文未提该候选或其失败，直接转向 compact 上的 single-pass 候选。
Problem: 图不可用时的全 rank eager 回退是协议级路径；同一固定状态、同一请求的两次执行差异 21,901/25,600（约 85.6%），而五个提案 ID 相同、两 tensor 均 finite，说明差异在 hidden 数值而非采样，属非确定性或未初始化状态。评论既无根因，也无 dump/日志路径与「放弃／继续」决定。
Impact: 任何触发该回退的候选，其计时与输出都建立在不可重复的执行上；24 UT/3 A3 ST 与 672 项 bitwise 只覆盖图路径，兜底路径未被等价性证据覆盖，却可能被用于后续正式配对。
Fix: 按 docs/contributing.md:105-106 标为失败试验并归档两份张量（dtype、形状、逐 rank dump 路径 + SHA-256）；由 owner 决定放弃该分支或先定位差异（初始化／未定义行为／算子选择），再恢复测量。

F19 — high，must-fix（需 owner 决定）— 唯一已公布的第 1/3 组校准同样缺 C4/C8/16 的活跃 DP replay 标记，本轮仍未处置

Where: 评论 6612233089「both independently launched initial calibration services and the plain FSQ six-tier sweep missed the same active DPs in the sampled replay logs at 4/8/16」；评论 6610897338（pair 1/3：C1 94.05/94.31、C8 101.66/102.18、C16 103.33/102.10、C32 129.23/128.25）；正文验收条件第 2 条已标 [x]、第 4 条要求逐档核对 decode FULL 回放。
Problem: 三对校准是第 2 条阈值的唯一来源，而其中唯一已公布组无法证明 C4/8/16 的测量窗口走在 FULL 路径上；「下一对校准暂停、等新观察器」只写在评论里，正文与 plan/ 未记录。触发评论提交的 7.30%/7.41% 正是拿这些门槛来读的。
Impact: 逐档阈值可能取自未验证 FULL 路径的窗口，验收条件第 2 条不应保持 [x]；保留/淘汰判定与测量条件不对应，PASS 时阈值来源不可追溯。
Fix: 由 owner 决定 pair 1 是否作废、第 2 条是否退回未完成，并在正文与 plan/ 逐档记录采样到的活跃 DP 数、FULL 回放条数与完整性标志（AGENTS.md:64）。

F5 — high，must-fix（需 owner 决定）— 逐档门槛仍存在两套公式，且没有 FlashComm1 开配置下的阈值（上轮 F5 open，本轮未回应）

Where: 正文验收条件第 2 条（[x]，两组/四服务、max(1%, 两组内以先测轮为分母的绝对相对差最大值)）与第 3 条「该档门槛」；评论 6610897338「thresholds use the maximum across the three complete chronological same-version pairs, with a 1% floor」；「已封存基线」表 1.000%–2.526%（来源配置为「显式 FlashComm1 关」，环境 44411269…）；AGENTS.md:64、docs/contributing.md:100-101。
Problem: 两套公式不可能同时是第 3 条的「该档门槛」；而第 2 条的阈值来自 FC1 关的校准，全部候选轮次（含本轮 single-pass）都在 FC1 开、enable_fused_mc2=0 下测量。触发评论的 7.30%/7.41% 虽在两种口径下都过线，但口径仍未定，且新校准已被确认有 DP 覆盖缺口（F19）。
Impact: 一旦收益落到 1%–3% 区间（FSQ 1.93%、FS 3.18%），保留/淘汰结论会因口径翻转；事后沿用旧阈值属 docs/contributing.md:100-101 禁止的候选搜索后改门禁。
Fix: 由 owner（.github/knowledge-model-policy.json 的 approval_owners: ["Dong1017"]）在正文与 plan/ 写明唯一公式、是否适用于 FC1-on/fused-MC2-off、三对校准封存后的生效时点，以及此前各轮是否标为探索性。

F1 — high，must-fix — 本轮候选给了完整 64 位工作树摘要，但仍不是可检出的提交（上轮 F1 open）

Where: 触发评论「The final source manifest is f070ea2af1371240ef1397647caf05a5d02cfb3b4a53ecadcc9ec99285e8da71」；正文表「候选 Git SHA | 待正式验收后提交」；AGENTS.md:87；.github/ISSUE_TEMPLATE/campaign-acceptance.yml:29-33（candidate_sha 必填「Full git SHA」）。
Problem: 相比此前只给 12 位前缀，本轮首次给出完整 64 位工作树清单摘要（这点是改进），但它仍是文件清单哈希，无法从任何提交重算，也表达不出验收条件第 3 条要求的「直接父版本」（本轮只写「on the compact candidate」）。
Impact: 55.50/74.46、13 UT/29 A3 ST 与后续 300 题都无法在具名修订上复跑或被下游引用，PASS 前提不成立。
Fix: 在任何「保留」判定前把该候选及其父版本落成 codex/dsv41-0day 上的提交，逐轮记录完整 SHA、父 SHA，并把清单摘要保留为交叉校验。

F2 — high，must-fix — campaign 证据仍不在仓库，本轮两个臂与测试回执也没有路径/摘要（上轮 F2 open）

Where: 正文「证据索引」仍只列 perf25/…（声明为「相对实验归档根目录」）；触发评论的 55.50/74.46、两个臂的原始波、16 rank dispatch 记录、13 UT/29 A3 ST 与那次被改写的夹具失败均无路径或 SHA-256；AGENTS.md:89、docs/contributing.md:117-122。
本次实际核实（检出 663f3b3）： 运行 python tools/validate_evidence.py → errors: []、21 个 bundle、checked_hashes: 430，其中没有 dsv41/perf25 条目；tools/evidence_inventory.json 无本 campaign；检出中没有 perf25/，evidence/dsv41-910c-decode-tpot25 也不存在；tools/validate_evidence.py:10-16 要求先登记 kind（campaign 需 plan/results/patch/validator），故日后导入也须先登记分类。
Impact: 决定下一步的 7.30%/7.41%、内核 dispatch 覆盖与测试回执只存在于评论正文，无法复核、无法作下游引用，而正文要求下游引用这些结果。
Fix: 补写本轮 results/、trials/、preflights/ 路径与 SHA-256（被改写的夹具失败单列 failure receipt）；判 PASS 前导入 evidence/dsv41-910c-decode-tpot25/{plan,results,patch,validator} 并在 tools/evidence_inventory.json 登记（外部原件可按 external 声明）。

F17 — high，must-fix（需 owner 决定）— 测试夹具在失败后被改写，用例计数第四次变化（9/16 → 37/7 → 24/3 → 13/29）

Where: 触发评论「The first system-test run stopped on a fixture that requested a physically blocked input but obtained ND. The revised test directly allocated FRACTAL_NZ and verified format 29. The production code was byte-identical between the two runs. Its 13 UT and 29 A3 ST passed」；对照评论 6611525929（37 UT/7 A3 ST，两次门禁因预期 36 项中止）、6610322256（9 UT/16 A3 ST）、6612233089（24 UT/3 A3 ST）；docs/contributing.md:105-106。
Problem: 失败方是测试而非产品代码（产品代码 byte-identical），随后夹具被改写以直接分配 FRACTAL_NZ 并核验 format 29——这可能是合理的测试修正，但本轮仍未记录：期望用例清单是否冻结、允许改夹具/校验方式的依据、原失败回执位置，以及 9/16 → 37/7 → 24/3 → 13/29 四套计数的逐项对应关系。
Impact: 「13 UT/29 A3 ST 通过（含 blocked-format fallback）」这一保留依据仍由事后调整的测试自证；无法判断 FSQ 的 16 项 ST 被替代后保护是否等效，尤其本轮改动还涉及数值路径（F13/F15）。
Fix: 由 owner 冻结每轮期望用例清单与计数规则，记录两次失败事务与被改写夹具的回执路径/摘要，并给出四套计数的对应表。

F9 — high，must-fix（需 owner 决定）— 精度门禁顺序仍未记录，而本轮候选改的是量化算术、只有初筛（上轮 F9 open）

Where: 正文验收条件第 4 条（「每个保留提交及最终版本的 GSM8K 固定 300 题必须至少 292/300」）；触发评论「These are initial screening measurements. The intermediate four tiers on this candidate, three formal pairs and GSM8K-300 remain pending」；评论 6607845822「The updated validation controller gates the fixed 300-item accuracy run on passing paired performance」；docs/contributing.md:100-101。
Problem: 冻结门禁要求每个保留提交都有 300 题结论，控制器却在候选搜索之后把精度移到「配对性能通过后」，正文与 plan/ 均未记录；G 轮被取消的 298 条轨迹仍无归档或作废说明。本轮候选替换 WO/KV 的量化-反量化路径，是最需要精度兜底的一类改动。
Impact: 可能出现「性能通过但从未产出 300 题结论」的候选；现有 294/300 距门槛仅 2 题余量，量化偏差只能靠该测试集暴露。
Fix: 由 owner 二选一并写入正文与 plan/：(a) 确认「性能通过后再测 300 题」为正式协议并写明最终版本仍独立跑 300 题、298 条轨迹如何处置；(b) 维持「每个保留提交即测 300 题」。两者都要求改算术的候选在保留前跑冻结 300 题。

F16 — high，must-fix（需 owner 决定）— 本轮写了两个开关，但仍无环境签名/服务标识，校准对的配置归属依旧无记录（上轮 F16 open，本轮部分改善）

Where: 触发评论「the same TP4/DP4/EP16, DSpark5, 16K, explicit FlashComm1 and disabled fused MC2 configuration as the compact-mask control」；正文「当前开关要求」要求新增测量标明开关取值；正文冻结表环境签名 44411269…，第二、三轮 a3d9fcf0…，校准对 da05a8aa0892；评论 6610897338 的校准对 C1 94.05/94.31、C32 129.23/128.25 与 FC1 关基线 93.862/129.043 重合，却比全部 FC1 开 B 臂慢 15%–19%。
改善: 与 18:10 sweep 一样写明了显式 FlashComm1 开、enable_fused_mc2=0 与 16K。
仍缺: 环境签名、服务实例标识，以及校准对究竟跑在哪种开关组合下；评论 6612233089 又称「A different observation environment requires fresh calibration」，却未给新签名。
Impact: 55.50/74.46 与门槛、与 compact 的对照无法证明处于同一 RunSpec；若校准是 FC1 关测的，其阈值不能用于该候选判定。
Fix: 每轮（含校准对、本轮两臂）写明环境签名与服务参数；若校准为 FC1 关，则在 FC1 开下按冻结公式补一次校准并说明正式配对的父臂。

F3 — high，must-fix，隐私 — 历史评论 6602376192 仍未脱敏（上轮 F3 open）

Where: 评论 6602376192 第 3.2、3.3、3.5、5.2、10–12 节及其文件链接：节点 IP 10.30.13.138、10.30.12.215、Pod 全名 itask-jcz-dsv41-jcz02615514-…、/a3_inference/itask/workdir/jcz02615514/jcz-afd1、/Users/jiangchenzhou/… 与模型挂载路径；docs/privacy-security.md:10-13、AGENTS.md:119-125。
本次核实: 该评论 created_at = updated_at = 2026-11-03T11:15:56Z，从未编辑，敏感值仍公开可见。触发评论与本次正文只用清单摘要与相对描述，未新增泄漏（这点正确）。
Impact: 个人身份路径与内部拓扑持续公开；同一份未脱敏记录若被当作证据导入 evidence/，会把泄漏固化进仓库。
Fix: 由作者编辑该评论，用 <REMOTE_HOST> / <REMOTE_USER> / <MODEL_PATH> 等占位符替换；导入证据树前再做一次脱敏复查。

F12 — medium，must-fix — 本轮「直接 compact 对照」逐位复用了 17:57 的读数，7.30%/7.41% 仍是跨会话差值（上轮 F12 复发，本轮最直接）

Where: 触发评论表「Direct compact control 59.86 / 80.42」；评论 6611525929 的 compact 列同为 59.86 / 80.42，且该轮已「Service release, restoration to B and device idle checks passed」；评论 6611796086 亦称「The prior compact-mask screen remains 59.86 / 80.42」。
Problem: 对照臂数值与上一会话逐位相同（0.00 ms），而同一 manifest 的父臂读数在本 campaign 内已见 86.59 vs 88.14（C32，1.79%）、64.26 vs 63.97（C1，0.45%）的跨会话漂移，B 臂也有约 1.0%/1.24% 的漂移。评论只写「same … configuration as the compact-mask control」，未说明是本轮同会话重测还是引用旧波；被测臂与服务都在另一会话。
Impact: 7.3%/7.4% 明显高于已观测漂移、方向性稳健，但「同一会话作差」这一 docs/contributing.md:103（identical controls）要求的前提不成立；若对照改用同会话 compact，收益幅度可能落在 5.5%–9% 区间而无人记录。
Fix: 明确对照臂是本轮重测还是引用；若引用，标为跨会话并给出同档漂移对照，或补一次 compact→single-pass 同会话配对（每档至少一波）。

F13 — medium，must-fix — 本轮等价性证据仍不覆盖量化算术，且 C32 输出哈希在本 campaign 已无判别力（上轮 F13 open，本轮有新反证）

Where: 触发评论「calls … dispatched the single-pass kernel on all 16 ranks」「C1 produced identical output … At C32 the input set matched, 2/32 complete outputs matched」；评论 6612233089「On the unchanged parent service the 96-token repeated greedy waves matched 1/1 … 0/32 at balanced concurrency 32」；正文冻结配置（block 128、每请求精确 1,024 入/1,024 出 = 8 个整块、无前缀缓存）。
Problem: (a) 同一父服务对自身重复在 C32 只有 0/32 完整输出哈希一致，说明该指标在 C32 基本无判别力，因此本轮的 2/32「一致」不构成等价性证据，也没有给 FSQ/compact 控制臂的一致率噪声底；(b) 替换 QDQ 路径属数值改动，却只有 C1 逐 token 相同与 13 UT/29 A3 ST，未给两臂输出的位级/容差对照；(c) 性能负载无尾部不完整块与 KV 复用，也未补非 128 整数倍提示长度与前缀缓存命中的逐 token 对照。
Impact: 量化偏差不会体现在 TPOT，只会暴露在固定 300 题（294/300，余量 2 题）或下游质量上，而该候选还会被当作后续合并的对照臂。
Fix: 补 compact 对 single-pass 的逐 token/位级对照（不同 visible length、非 128 整数倍提示长度、前缀缓存命中），加一次同版本 C32 重复建立哈希一致率噪声底，并按 F9 的结论在保留前跑冻结 300 题。

F21 — medium，must-fix（需 owner 决定）— 观察器与校准环境在冻结后被更换，正文/plan/ 无新协议记录（上轮 F21 open，本轮未回应）

Where: 评论 6612233089「The next old-protocol pair is on hold while an independently identified per-worker counter observer is being validated. A different observation environment requires fresh calibration」；正文冻结表「公共环境签名 44411269…」与「验收条件」第 2–3 条。
Problem: 冻结的 replay 日志观察方式被判不可用，改用 per-worker 计数器观察器并要求重新校准，但未给新观察器身份/代码摘要、新环境签名，也未说明第 1 组校准与旧阈值在新观察环境下是否仍有效。
Impact: 第 2、3 对校准与后续正式配对将处于不同观察环境，逐档阈值与 FULL 回放核对无法对齐同一 RunSpec；PASS 时环境身份不可追溯。
Fix: 由 owner 在正文与 plan/ 记录新观察器（代码/版本/摘要）、新环境签名、重新校准范围，以及旧校准作废或沿用的结论。

F8 — medium，must-fix（需 owner 决定）— Decision needed 行仍不是可判定问题，也没有决策人（上轮 F8 open）

Where: 正文首行 **Decision needed:** 最终是否满足下方既有验收条件仍待证据；本次状态同步不改变验收门槛、当前配置要求或现有负责人。；docs/agent-collaboration.md:212-217 要求 <question>, from <decision owner> / none；.github/knowledge-model-policy.json:50 记 approval_owners 为 Dong1017。
Problem: 该行只是「仍待证据」，无具体问题与决策人；本轮待决项至少五项：F5（门槛公式与适用配置）、F19（pair 1 是否作废）、F9（精度门禁顺序）、F17（测试门禁处置）、F20（eager 分歧候选是否放弃）。
Impact: 读者与后续评审无法区分「已定」与「未定」，也无法判断正式配对何时可以开始；这五项恰好都阻塞下一步。
Fix: 把待决项逐条改写为问题并指定 owner（Dong1017 或指派的验收负责人），Next action 写明谁做什么。

F15 — medium，suggestion — 「single-pass E4M3 QDQ」仍是未定义的数值改动（上轮 F15 open）

Where: 触发评论标题段「Single-pass E4M3 QDQ on the compact candidate」与「The four production WO/KV shapes at FULL widths 24 and 48」；正文验收条件第 3 条要求每个候选记录单一假设与预设受益档。
Problem: 未说明「single-pass」是相对哪个两遍实现，量化对象（WO 权重／输入激活／KV 值）、分组粒度与 scale 来源、是否由配置开关控制及默认值是否改变，也未预先声明受益档；E4M3 QDQ 的语义（仅存储格式 vs 数值近似）因此不可判断。
Impact: 无法判断该候选的精度风险面，也无法按验收条件第 3 条核对「单一假设 + 预设受益档」；若进入合并链，后续对照臂的语义不清。
Fix: 写明精确数值改动（输入/输出 dtype、分组轴与 scale 来源）、配置开关与默认值、与旧路径的位级/容差关系，以及预先声明的受益档位。

F22 — medium，must-fix — 状态块部分更新：18:10 sweep 已写入，但 18:30 的 eager 失败与 18:45 的本轮结果仍缺（上轮 F22 部分 fixed）

Where: 正文 **Current state:**（截至 18:30，写入 FSQ 六档 sweep 63.97–88.14、C4/C8/C16 采样缺口、「新同版本校准仍仅已公布第 1/3 组」）与 **Next action:**；对比评论 6612233089（18:30，DSpark shadow、85.6% eager 分歧、观察器更换、下一对校准暂停）与触发评论（18:45，55.50/74.46）。docs/agent-collaboration.md:212-218 要求执行方保持三行块最新。
已解决: 18:10 六档 sweep 与校准进度已进入状态块，措辞与评论相符。
仍缺: 当前唯一阻塞（校准依据失效 + 观察器更换）、eager 失败候选的处置、以及本轮 single-pass 结果均未进入状态块；Next action 仍写「继续在原线程记录」，未反映下一对校准已暂停在观察器验证上。
Impact: 按状态块判断进展会漏掉「校准依据正在失效」与「一个候选已出现未定位数值分歧」这两个关键事实。
Fix: 把 F19/F21/F20 与本轮 single-pass 结果写进三行块，并在 Next action 写明观察器验证与新校准的责任人。

F4 / F7 / F6 / F11 — medium，suggestion — 遗留项本轮仍未回应（保持 open）

F4: 评论 6602376192《0-day 适配任务记录》（TP8/DP2/EP16、GPQA 88.89、43.60 ms/token）仍是另一套 RunSpec，与本 campaign（TP4/DP4/EP16、GSM8K ≥292/300、六档 ≤25 ms/token）混在同一 Issue；需 owner 决定移出或以指针声明。
F7: 验收条件第 4 条的 AISBench 判分工具仍无 revision/代码摘要；本次检出 grep -ril "aisbench|Gsm8kEvaluator"（md/py/json）无任何命中，294/300 不可复算。可考虑以 Add an optional AISBench service benchmark adapter #326 的 v3.1-20261013-master@5a63d936e40dd04addfcffb2401f84cd0e53bb46 为候选 pin。
F6/F11: per-graph / per-step / per-token 三种口径仍无统一换算表，12 行 ratio 1 约 1K 上下文的两次基线（9.13 ms 与 46.65 ms）也未说明哪个作废；本轮 7.30%/7.41% 同样缺 ms/step → TPOT 的对算式。
Fix: 按各项原建议逐条回应，或在正文/plan/ 记录处置结论。

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

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

Description

Campaign

当前开关要求

初始修订与基线运行配置

验收条件

已封存基线

证据索引

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

GPQA V006 主动停测

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

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

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

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

13 remaining items

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

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

jiangkuaixue123 commented on Nov 3, 2026

Initial commit, formal same-version calibration pair 1 of 3

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

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

jiangkuaixue123 commented on Nov 3, 2026

Compact candidate mask on FSQ

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

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

jiangkuaixue123 commented on Nov 3, 2026