CollectiveSpec P2：logical-plan 对照的审计与停止门槛

决策

不启动正式的 P1/P2 SLO-goodput sweep，也不把 compact-vs-padded 作为 CollectiveSpec 的研究主线。

原因不是这条机制一定没有工程收益，而是它的核心研究主张已经无法排除公开工作的覆盖：

DSpark 已明确采用每请求的动态 verification length，并把逻辑 sequence tracking 与物理 execution 解耦、flatten variable-length token；
SGLang 的 DSpark 集成说明已公开 static、compact 与 cap-accept 三种 verify mode。其中 cap-accept 执行完整 block、但只提交 compact window，且说明其输出与 compact 相同。这正是 “同一语义下 full/padded 与 compact”的 counterfactual；
该实现还公开了 DP attention 下各 rank 使用最大 graph tier 的处理。因此，仅在 vLLM/H20 上再复现 compact 比 padded 快，只是环境复现，不是新的系统贡献。

P0 还独立否定了原来的 liveness 动机：目标 runtime 已经以 scalar DP metadata 协调不同 DP replica 的物理 shape；异构 verifier candidate 没有引起运行期 collective 错误。故不能再把“必须新增 canonical header 才能避免死锁”作为论文 premise。

术语：什么必须相同

Logical plan（也称 semantic plan）

logical plan 是一次 speculative verification 应当计算和提交什么的不可变记录；它不包含 padding、CUDA graph tier、物理 rank 行数、worker PID 或耗时。每一个 verifier epoch 的最小条目为：

(global_epoch, dp_rank, ordered request id,
 logical_output_offset_before, scheduled_seq_len,
 available_candidate_token_ids, requested_k, effective_k,
 visible_candidate_token_ids_hash)

请求层还必须固定 client_request_id、server request id、prompt/body hash、arrival、DP assignment、提交顺序、temperature/seed 与预期 completion length。最终还要逐请求验证 output token-id hash、completion length、finish reason、usage，以及 endpoint semantic transcript hash（content/reasoning/tool-call 的 canonical JSON）。

这里的关键是 k_i 的 key 必须是 (server_request_id, logical_output_offset_before)，而不是只有 request id：同一请求会经历多个 verification epoch。只有两个 cell 的这些事实都相同，才称为 same logical plan。

Compact vs. padded：只是同一 plan 的两个 lowering

给定同一组 non-dummy logical entries：

PaddedSync-semantic：保留这些 entries，但为同步域插入 masked dummy rows，使各 DP peer 的 physical shape 对齐；
CompactSync：保留完全相同的 entries、candidate 和 commit semantics，用 ragged packing / split vector 执行真实 rows，不计算 dummy rows。

因此 static K=3 不能当作 padded 对照：它改变了每个请求可见 candidate prefix，改变了 logical algorithm，而不是只改变 physical lowering。真实 physical-row 公式也不能简单写成 N * (1 + max k_i)；普通 decode、TP alignment 和 CUDA-graph alignment 都要从 runner 的 row map 分开计数。

当前 P0 对 P2 的限制

P0 heterogeneous policy 按 vLLM 随机生成的 server request id 哈希，而 client 没有发送 X-Request-Id。所以即使 trace 和 seed 相同，两个 cell 的每个 request/epoch 的 k_i 也不可保证相同；日志只有 aggregate digest/histogram，也没有 per-row candidate token、assignment 或最终 token-id hash。P0 因而不能充当 same-logical-plan 的 P2 A/B。

P0 的 padding 上界也已校正。66 个 target epoch 中 62 个 raw DP counts 不等：

raw logical rows                 6,276
local non-DP-aligned rows        6,536
PaddedSync physical rows         7,024
DP-global-max attributable rows    488  (= 6.95% of physical rows)

此前的 748 / 10.65% 将 260 行本地 TP/CUDA-graph alignment 混入 DP max padding。即使 488 行都可回收，它仍只是 target verifier row-count 的上界：EAGLE3 仍按 Kmax=3 完成 drafter 工作，也没有测得 EP bytes、collective critical path 或 E2E SLO-goodput。

若未来重新打开，先补齐的测量契约

不应先实现 compact lowering。先添加只用于 audit 的 telemetry：

client 对每个请求发送固定 X-Request-Id、X-Data-Parallel-Rank 和 return_token_ids=true；记录 response id、prompt/output token-id hash、semantic transcript hash 和 finish reason；
scheduler 作为 semantic ledger 的唯一 writer，记录 per-epoch ordered entries、候选 token、requested/effective K、logical cursor 与 sampled token hash；
worker 只记录物理事实：每 rank physical rows、DP/TP/graph padding 的原因、packed row map；若要主张 EP 收益，额外记录 DeepEP all-to-all split vector、bytes、duration 和 rank wait；
汇总器先给出第一个 semantic/output diff，任一 mismatch 即标为 invalid，禁止读取性能数字。

最小 reproducibility smoke（仅在发现 topology gap 后执行）是 fresh engine 上的 16 个 decode-only requests、每个 64 output tokens、temperature=0、DP0/DP1 各 8 个、显式 {0,3} alternating manifest。先连续跑两次 同一个 padded cell；只有 ledger 和逐请求 token hash 全等，才允许运行 padded/compact mechanism probe。return_token_ids 会改变 SSE 负担，故最终 latency cell 必须关掉该字段、改以 scheduler-side hash 审计。

唯一尚可证伪的拓扑假设

公开材料没有证明、也没有否定下列特殊情形：独立 standard-DP scheduler 共享同一个 EP all-to-all domain 时，DP global-max graph tier 之外仍有 EP split-vector / collective ordinal 的关键路径浪费。这不能从“论文没有写”推断为新颖性。

只有一次短的 topology reconnaissance 观测到该额外瓶颈，才重新进行文献审计并考虑下列顺序严格的 gates：

与 SGLang-style DP global-max tier / current runtime 相比，compact plan 降低实际 EP bytes、split imbalance 或 collective critical-path time；仅少几个 rows 不够；
在相同 semantic plan、token-exact 输出和无 tail-latency 退化下，至少三次 fresh-engine paired runs 显示 E2E SLO-goodput 增益 >=10%；
topology ablation 支持因果归因：DP=1 或 EP 不跨 DP 时收益消失或显著缩小，而 DP×shared-EP 时出现；
重新完成与 DSpark/SGLang 的逐项差异审计，证明贡献是 topology-aware collective scheduling，而不是已有 ragged packing。

任一 gate 不成立即结束 CollectiveSpec；不以 controller/K/queue knob 调优替代证据。

如果 gate 重开时的固定环境与 setup

下列是 P0 实际使用、后续必须 provenance-pin 的环境，而不是当前已启动的实验：

项目	固定值
host / accelerator	`dash0`，8 × NVIDIA H20
target / draft	Qwen3-235B-A22B FP8；EAGLE3，Kmax=3
parallelism	TP=4，DP=2，EP=8；`VLLM_MOE_USE_DEEPEP=1`
engine	dash0 live installed vLLM wheel；记录 wheel metadata、import path、launch command 与 commit；不能以本地 checkout API 代替
execution	`FULL_DECODE_ONLY` CUDA graphs、FP8 KV cache、block size 64、`max-num-batched-tokens=1024`、`max-num-seqs=192`、max model len 262144
workload	immutable materialized `thinking_w20260327_1000` 的 decode-only window；机制 smoke 使用固定 burst，E2E 使用完整、session-closure 状态明确的 trace
reproducibility	fresh engine per cell、temperature=0、固定 seed、固定 request ids/DP assignment、prefix-cache state 从空开始、ABBA cell order
SLO（若进入 E2E）	预注册 TPOT <= 40 ms、pass rate >= 0.95；同时报告 completion success、p50/p95/p99、deadline failures 与 output equivalence

remote source 必须从 Git 同步到 /home/admin/cpfs/wjh/collectivespec-pilot/20260713T054328Z/source，并记录运行时实际 source revision；任何远端 job 启动前在 artifact 中写明 resolved command、模型/trace path、预计 GPU 时间和结果目录。

审计数据健全性

新增实验数：n=0；本文件不报告任何新的性能数字。
已复核的 P0 target epochs：n=66；两个 DP rank 的 raw row values 共 n=132， min=1、max=77、distinct=35；physical rows 则 n=66，min=4、max=80、distinct=14。原始 JSONL 可复核，不以 aggregate 值伪造每 epoch 分布。
已用 aggregate row totals：n=4，min=488，max=7,024，distinct=4；均为非负。校正后的关系 6,276 <= 6,536 <= 7,024 成立，且 7,024 - 6,536 = 488。
外部材料覆盖判断区分为“论文明确描述”“官方公开实现明确描述”和“未公开拓扑细节”；未从缺失的 EP 细节推导新颖性或性能收益。

8.8 KiB Raw Blame History Unescape Escape