# CollectiveSpec P2:logical-plan 对照的审计与停止门槛 ## 决策 **不启动正式的 P1/P2 SLO-goodput sweep,也不把 `compact-vs-padded` 作为 CollectiveSpec 的研究主线。** 原因不是这条机制一定没有工程收益,而是它的核心研究主张已经无法排除公开工作的 覆盖: - [DSpark](https://arxiv.org/html/2607.05147) 已明确采用每请求的动态 verification length,并把逻辑 sequence tracking 与物理 execution 解耦、flatten variable-length token; - SGLang 的 [DSpark 集成说明](https://www.lmsys.org/blog/2026-07-06-dspark-sglang/) 已公开 `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 的最小条目为: ```text (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 不等: ```text 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: 1. client 对每个请求发送固定 `X-Request-Id`、`X-Data-Parallel-Rank` 和 `return_token_ids=true`;记录 response id、prompt/output token-id hash、semantic transcript hash 和 finish reason; 2. scheduler 作为 semantic ledger 的唯一 writer,记录 per-epoch ordered entries、候选 token、requested/effective K、logical cursor 与 sampled token hash; 3. worker 只记录物理事实:每 rank physical rows、DP/TP/graph padding 的原因、packed row map;若要主张 EP 收益,额外记录 DeepEP all-to-all split vector、bytes、duration 和 rank wait; 4. 汇总器先给出第一个 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: 1. 与 SGLang-style DP global-max tier / current runtime 相比,compact plan 降低实际 EP bytes、split imbalance 或 collective critical-path time;仅少几个 rows 不够; 2. 在相同 semantic plan、token-exact 输出和无 tail-latency 退化下,至少三次 fresh-engine paired runs 显示 E2E SLO-goodput 增益 >=10%; 3. topology ablation 支持因果归因:DP=1 或 EP 不跨 DP 时收益消失或显著缩小,而 DP×shared-EP 时出现; 4. 重新完成与 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 细节推导新颖性或性能收益。