[fivechenxi]

概要

整理 6000D GLM-5.3 NVFP4 最新已验证优化，单独叠加在 #25 分支，不改写 #25/#26/#27。8 个独立提交，所有新增文件位于 benchmark/glm53_pd_7k/。

这是固定运行版本的增量研究补丁包，不是把这些修改自动启用到当前核心源码，也不是新的完整镜像。 实测 P 是 v0.5.19/Torch 2.13，D 是 v0.5.17/Torch 2.11 + legacy overlays。每个运行文件 patch 有严格 pre/post SHA；不能直接覆盖当前 #25 后续 L3 修复或任意 release。

提交划分

1. P InputSP：ReduceScatter → 局部 LayerNorm → AllGather，保留完整 residual。
2. 完整 KV / PCP4 → DCP2 的窄拓扑许可，默认关闭。
3. PD 有界打包与同步完成后复用 buffer，失败不继续复用。
4. 固定 16K profile 的 gather kernel 预加载。
5. D 跨阶段 draft seed 重算，保留迭代内 IndexShare 和 target verification。
6. 精确 Top-K CUDA 源码与 D 确定性 tie-break，标注社区来源；不含 .so。
7. Router 流式 dispatch 负载计数最小回移与 mock 回归脚本。
8. 脱敏配置、源码校验工具、验收数据、限制和恢复说明。

既有 RS、DCP/索引池能力分别依赖 #26/#27，不重复计入单项收益。未纳入失败的 MoE tactic、FI 0.7 MLA、FP8 wire 等候选。未包含地址、账号、凭据、私有镜像、真实请求或环境部署脚本。

已有端到端验收

• 4P1D，全部 40 GPU 计入分母。
• 每请求 81920 input / 73728 cached / 600 output；四组独立可复用前缀，真实 EAGLE 5/1/6，无 synthetic acceptance。
• 3.40 req/s 开环，两轮各 2072 请求，4144/4144 严格 DONE、零错误。
• 预先固定 120–540 秒窗口，保守 7014.18 / 7009.29 total tokens/s/GPU。
• 每个 P 每轮 518 条准确 8192-fresh/73728-cached 请求；全局及四组队列检查通过。
• 这是含缓存输入的经济总吞吐，不是物理算力提升。R66 半窗约 7083/6936，余量很薄；不是每短窗 7K 或多小时 SLA。保留约 20s 有效文本间隙的限制，不声称通用准确率/自然语言时延 SLA。

本次重新执行的验证

• 25 项 CPU 单元测试通过。
• 4 个源码 patch 逆向/正向还原后，与实测完整文件 SHA 一致。
• Router patch 在公开固定 base 0bcd822377da7b5718e674eaf9c870d349424dd1 上检查和往返通过。
• 3 个抽取函数与实际运行源码 AST 一致。
• CUDA 源码和保留 hook 的字节哈希与归档一致；脱敏检查通过。
• 本 PR 未重新构建统一版本镜像，未重新 GPU 压测或重启服务。后续正式集成需要重新做冷/热前缀、L3 restore、真实层/Top-K、流式取消和开环回归。

审阅入口：benchmark/glm53_pd_7k/README.md。check_sources.py 只读且 fail-closed。保留原始研究 hook 是为了字节可追溯，未将实验日志/控制文件轮询混入核心源码。

[fivechenxi]

已补充 5 个独立提交，最新 HEAD 634fa4c21a098fa6c0d5101eabd8e744160bc37b：

• 5574c6010a：DCP MLA CPU retraction 的逻辑→物理索引映射。
• e32787342a：独立 MTP draft KV 与 target 同步备份/恢复。
• 08cc168a70：PD retraction 前对齐 overlap 输出历史和 KV 边界。
• 04932aebeb：完整校验 P 非流式确认响应，P 错误取消配对 D；另存评测用负载均衡阈值配置。
• 634fa4c21a：固定源码 SHA、回归脚本、脱敏证据和应用/回退说明。

内容在 benchmark/glm53_pd_7k/recovery/。延续本 PR 的固定 legacy runtime 补丁包形式，不把旧版本文件覆盖到当前核心源码。

复现：旧 Router 对 P 的 HTTP 200 SSE 错误没有及时联动，mock 客户端超时；C32 共享前缀在默认阈值下全部进入单 DP。

验证：

• 原 25 项 + 新 6 项打包 CPU 回归通过；4 个 patch / 7 个文件正反应用逐字节一致。
• PR 内的实际方法测试在 6000D 重跑，6 项 CPU/CUDA 通过。真实 37 次强制 retraction 下 32/32 算术请求正确并完成；关闭注入后 4/4 正常流通过。
• 新 Router 锁定依赖离线编译成功。脱敏 mock 脚本重跑通过：8 类 P 故障取消 D、正常流/非流/取消、32 请求 8/8/8/8 分布及最终负载归零。
• 真实模型 32/32 HTTP 200 + SSE DONE，四 DP 峰值 8/8/8/8。
• 隔离故障 P + 真实 D：HTTP500/HTTP200 SSE error 均约 1 秒返回错误；D 日志确认随后 3–4 秒内 AbortReq 并排空队列。

边界：这不是新的 7K 性能或完整精度验收；路由均衡不等于 token-budget admission。GPQA 长循环仍未归因，下一步按同题、同采样、固定 P/DP、C1 对比保留的 RS+DCP2 基线与优化版，结果另报。未将未验证的 A/B 辅助脚本、内部地址或请求内容提交到 PR。

[fivechenxi]

InputSP 通信量分析：当前实现按标准模型增加 12.5%，需要补充性能归因

基于 head 634fa4c21a098fa6c0d5101eabd8e744160bc37b，对比 原 communicator 与 InputSP transformed()。这是一项通信成本与性能证据分析，不是在断言输出错误或实测收益不存在。

统计口径

• 固定本实现的 TP8 / CP4 / attention-TP2 / DP1。
• S 表示一个 CP 分片的完整 activation 字节数；residual 同形状、同为 BF16。
• 统计每 rank 的发送 payload；理想均衡算法下接收量相同。发送与接收不重复累加。
• 使用标准点对点 collective 的带宽模型，参见 NCCL tests 性能说明。不将协议开销、硬件 multicast、实际物理链路经过的跳数、HBM 读写或 NCCL 算法选择混入这个数。

改前：TP2 AllReduce + CP4 AllGather

TP2 AllReduce，输入 S：     2 × (2−1)/2 × S = S
CP4 AllGather，每卡输入 S： (4−1) × S       = 3S
合计：4S / rank

旧路径只 gather hidden_states；更新后的 residual 保持 CP-local，不参与 CP4 AllGather。CP 组分别是 [0,2,4,6] 与 [1,3,5,7]，所以最终每卡得到 [x,y,z,w]，不会重复收集同一 CP 分片的两个副本。

改后：TP2 ReduceScatter + TP8 AllGather + residual TP2 AllGather

TP2 ReduceScatter，输入 S：         (2−1)/2 × S   = 0.5S
TP8 AllGather，每卡输入 S/2：       (8−1) × S/2   = 3.5S
residual TP2 AllGather，输入 S/2：  (2−1) × S/2   = 0.5S
合计：4.5S / rank

每 rank 发送量	改前	改后
attention 输出归约	S	0.5S
聚合完整 MoE 输入	3S	3.5S
恢复 residual	0	0.5S
合计	4S	4.5S

因此：

(4.5S − 4S) / 4S = 12.5%

前两个 collective 的替换本身在该模型下通信量持平；增加的部分来自恢复完整 CP-local residual。不能因为 AR 换成 RS，就将这项优化描述为减少总通信量。

例如 16K chunk、CP4、hidden=6144、BF16：

S = 4096 × 6144 × 2 = 48 MiB
改前：每 rank 发送 192 MiB
改后：每 rank 发送 216 MiB
增加：每 rank 发送  24 MiB；接收方向也同样增加

这是每层该边界的通信量。代码另外还有 residual slice 的 .clone()，属于本地显存流量，不包含在上面的网络 payload 里。

+5.3% 需要怎样的证据解释

InputSP 确实将每 rank 的 residual + RMSNorm 处理行数减半，但没有减少 attention/MoE GEMM。结合额外 residual gather 和复制，净收益需要实际 profile 归因。

当前 README 记录了配对 P 测试约 +5.3%，归档中未见 InputSP 的原始 profiler trace 或这几个算子的前后耗时分解；整套优化后的 7K 结果也不能用于单项归因。更多 payload 并不必然更慢，但仅凭当前材料无法确认收益主要来自 Norm/显存访问，还是 collective 分组、算法或有效带宽变化。

建议补充同 shape、同负载下的 baseline/candidate 数据：

1. TP2 AR/RS、CP4/TP8 AG、residual TP2 AG 各自耗时与有效带宽。
2. residual + RMSNorm、clone/复制及整个 attention→MoE 边界的耗时。
3. 配对 P 测试的指标定义、样本数和波动，说明上述边界变化能解释多少端到端收益。

本评论只做源码和理论字节数核算，未重新执行 GPU 性能测试。

[fivechenxi]

InputSP 社区调研：持续分片 residual，以及通信与 GEMM 融合

补充前面的 InputSP 通信量分析。以下状态核对于 2026-10-19，本 PR 对照版本为 634fa4c21a098fa6c0d5101eabd8e744160bc37b。

社区已经有同类 SP 实现，但尚不能将其收益或适用范围直接套到当前 GLM-5.3 NVFP4、CP4×attention-TP2 的局部 hook。值得借鉴的两个方向是：让 residual 的分片布局延续到后续层，或者将通信与相邻 GEMM 融合。两者都需要扩大集成范围。

1. SGLang sgl-project#30915：LayerNorm SP，已合并

PR #30915 于 2026-09-01 合并，实现 --enable-layernorm-sp；本地 v0.5.19 基线已包含这项功能。

它将 row-parallel AllReduce 拆为 ReduceScatter / AllGather，让 Norm 与 residual 在分片 token 上处理，并通过整个 SP 区域的布局管理延续这种状态。线性层在需要完整输入时 gather；支持条件下，使用 torch symmetric-memory 的 GEMM+ReduceScatter、AllGather+GEMM 融合路径。

这与 #28 的局部 InputSP 有一处关键差别：中间边界无需每次将 residual 聚合回原来的复制布局，因而不会天然带上当前 hook 的那次额外 residual TP2 AllGather。标准纯 TP SP 的 RS+AG 与原 AR 在带宽模型下通信量相同；这个结论不能直接套到本 PR 的混合 CP/TP 数据流。

PR 报告的 Qwen3-8B、16K prefill 结果：

配置	结果
2×H100	0.28173 → 0.27180 s，约 −3.5%
2×B200，融合开启	0.14388 → 0.13589 s，约 −5.6%
2×B200，强制关闭融合	0.1421–0.1442 s，基本与 baseline 持平

这是比“SP 理论上更快”更有用的对照：在该 B200 配置中，融合才是主要收益来源，单独改写 RS/AG 没有稳定明显收益。 这是社区报告结果，本轮没有复测。

适用范围也要区分：合并时主要支持 Qwen3 dense；截至核对的 当前实现，允许列表为 Qwen3 dense 与 Muse Spark，仍没有 GLM DSA。配置检查 还限制 attention-DP、speculative 等组合。因此不能在当前配置上仅打开这个开关。也不能把 B200/BF16 的融合收益直接外推到 6000D/SM120/NVFP4。

2. vLLM：DeepSeek V3.2 的模型内 SP

当前 DeepSeek V3.2 NVIDIA 模型实现 使用如下数据流：

分片 residual + Norm
    → AllGather
    → Attention
    → ReduceScatter
    → 分片 residual + Norm
    → MoE(already_sequence_parallel=True)

它显式适配了 MoE 的分片输入，residual 继续跨层保留分片，在这个边界没有额外 residual AllGather。模型入口/出口、padding、辅助 hidden states 等也配套处理；不是只替换一个 Norm 前后的通信函数。

版本注意：搜索结果里常见的 SequenceParallelismPass / AsyncTPPass 已在 #60517 于 2026-10-08 移除，模型内手工 SP 保留。应参考当前模型级路径，不能直接复用已删除的 compile-SP 配置和旧文件路径。

3. SGLang sgl-project#44034：SP + 复制 MoE，尚未合并

PR #44034 当前 OPEN，针对 Qwen3.5 MoE 的小 TP、长 prefill 场景：

• 每个 rank 保存完整 experts，包括 shared expert。
• 每卡只处理自己的 token，MoE 本身不再需要输出归约。
• attention 一侧保留 AG/RS。

PR 报告 2×B200、TP2、约 60K prompt 的 TTFT 从约 420 ms 降到 383 ms，约 −8.6%；同时付出完整专家权重显存和 decode 性能退化的代价。

它说明了另一种真正减少通信的办法，但需要复制模型权重，并明确排除 attention CP/DP 等组合，不是当前 GLM TP8 配置可直接套用的选项。

对 #28 的集成建议

维度	社区完整 SP 思路	当前 InputSP hook
改动范围	跨层布局、linear，部分还涉及 MoE	attention→MoE 单个入口
residual	在 SP 区域持续保持分片	当场恢复完整 CP 分片
额外 residual gather	中间边界通常不需要	每次增加 TP2 AG
融合机会	GEMM+RS / AG+GEMM	当前使用分离的 collective 与 Norm

可考虑两个独立候选，并分别测量：

1. 延续 residual 分片。 配套调整 MoE 出口、下一层 attention 入口的 token 所属关系与形状，使 residual 可以留在 TP 子分片上。不能只删掉当前恢复 AG；也不能仅把 AG 挪到下一处就声称节省，必须核算完整一层的通信量，并验证 token 顺序、padding 与数值。
2. 通信与相邻 GEMM 融合。 先检查 SM120、NVFP4 权重和当前 GEMM backend 是否有可用融合实现，再测 overlap、kernel 时间、整个边界时间与配对 P 延迟，避免直接沿用其他硬件/精度的收益数字。

当前 hook 为保持下游原接口而恢复 residual，是局部实验的取舍；若希望去掉额外通信，或获得社区融合路径的收益，应作为新的核心集成与验收工作。以上为源码和公开 PR 调研，没有新增 GPU 性能结论。

[fivechenxi]

完整 KV + PCP4：建议补充容量/并发边界与 CP0-only 发送负载评估

基于 head 634fa4c21a098fa6c0d5101eabd8e744160bc37b。关闭 LayerSplit 可以消除逐层历史缓存广播，但会增加每 token 的本地缓存成本，并将 PD 发送来源集中到 CP0。这是需要量化的性能取舍，本评论不把它直接判定为正确性 bug。

1. 固定显存预算下，可容纳的 token 数会下降

LayerSplit 开启时，每卡主要保存约 1/4 层的完整 KV/index，加上远端层 scratch；关闭后每卡保存全部层。因此下降的是同样显存预算能容纳的 token 容量/独立前缀工作集，不是缓存字节占用变小。

README 已报告完整 KV 约多占 4.7 GiB/rank，但归档没有列出 LayerSplit on/off 在相同 mem_fraction_static、workspace 与其他条件下的 profiled token capacity、峰值 free tokens 和占用对照。不能仅根据 4.7 GiB 推断实际容量下降比例，也不能把固定 token 数下的内存增长与固定显存下的容量变化混在一起。

2. 现有 P 容量大致能承载什么？

config.json 记录：每个 P 为 DP1、PCP4/attention-TP2，pool_tokens_observed=110464，每步最多一个新 prefill，max_running_requests=64。

这些 token 容量在各卡上是对应的缓存副本，不能乘以 8 当作不同 token 的容量。按历史 7K 负载的一个共享前缀粗算：

P token pool                110464
一个共享前缀                 73728
剩余                         36736
每条独立 suffix               8192

prefix + 4 条完整 suffix = 106496，理论能放下
prefix + 5 条完整 suffix = 114688，超过 pool
两个无共享的 81920-token 输入 = 163840，也超过 pool

这是忽略其他存活 KV、预留与页对齐等开销的静态驻留上界，不是实测 C4 上限，也不等于 max_running_requests=64 能同时放下 64 条长请求。P 会在传输结束后解除该请求的缓存锁，未锁定缓存可被驱逐；P 无需为所有仍在 D 生成的请求持续保留锁定的完整 KV。所以端到端 inflight 数不能直接等同于 P 同时驻留的请求数。

3. 当前“够用”的证据范围

两轮 7K 验收 使用四组固定可复用前缀、四个 P，3.40 req/s；README 记录每个 P 每轮 518 条准确的 73728-cached/8192-fresh 请求。4144/4144 完成、零错误，队列检查通过。这支持该前缀放置、到达率和有限时间窗口内容量与调度足以运行。

但以下证据仍缺少：

• 每个 P 增加第二个或更多独立长前缀后的缓存命中、驱逐/重算、排队和 TTFT。
• 冷请求比例增加、前缀分布不均、突发并发和较慢 PD 传输导致 KV 锁定时间延长时的表现。
• LayerSplit on/off 的容量与吞吐/延迟拐点扫描，而非只看固定热前缀负载的单项 +10.9%。

后续 recovery 的 C32/四 DP 均衡与强制 retraction 是恢复/路由正确性验证，配置和目的不同，不能替代 P 的独立长前缀容量测试。P 侧关闭 LayerSplit 也不会直接缩小 D 的 DCP pool；两侧瓶颈应分别观测。

4. CP0-only 确实会集中源端负载

窄拓扑许可 要求关闭 LayerSplit 且不启用 all-CP transfer；rank mapping 此时只选择 P 的 CP rank 0。

在当前 P PCP4×attention-TP2、D attention-TP2 的配置中，CP0 是两张对应 attention-TP 卡（通常 P rank0/1），不是只有一张 GPU，也不是 D 只使用一个 DP。它们的本地显存成为相应 KV 的源，gather/pack 后再发送；其他 CP 的缓存副本不承担这条来源路径。

	LayerSplit	完整 KV、CP0-only
源端层数据分工	四个 CP owner 各发送自己拥有的层	CP0 对应的两卡提供全部层
传输 token/层数相同时	来源负载分散	来源负载集中
P 内历史层广播	有	省掉

在层大小近似相同、分工均匀等理想条件下，活跃源卡每请求处理的层数据量可接近原来的 4 倍；这不代表总 RDMA payload 变成 4 倍，也不意味着传输耗时必然变成 4 倍。实际还取决于 NIC/PCIe 拓扑、pack kernel、传输线程并发和计算重叠。

因此完整 KV 带来的收益，可能同时伴随 CP0 的 HBM 读取、gather/pack GPU 工作、PCIe/NIC 流量及发送队列集中。现有 +10.9% 的 P 代理结果包含交接，但没有提供逐源 rank 的利用率/字节数，尚不足以证明 CP0 在更高负载下仍有余量。

另外，P 命中 73728 tokens 不等于 PD 只发送 8192 tokens；实际传输跨度还取决于 D 的可复用前缀。请分别记录 P 命中、D 命中与实际 KV/index 传输字节数。

建议补充的评估

1. LayerSplit on/off 在相同预算下的每卡 KV/index/scratch 字节数、pool token capacity、最小 free tokens、locked/evictable tokens。
2. 每 P 的独立前缀数量、冷/热比例和并发扫描，记录驱逐/重算、排队、TTFT P50/P99 与可持续吞吐。
3. CP0 两张卡与其他 CP 卡的 pack 时间、显存带宽、PCIe/NIC 实际发送量、transfer queue 等待和传输 P50/P99。
4. 慢 D、慢网络或突发流量下，P 的目的数据保持时间是否使较小 token pool 成为瓶颈。
5. 如 CP0 成为瓶颈，再考虑按请求选择不同完整副本或按传输块分担来源；这需要同步修改路由、完成计数及源数据生命周期，不能直接打开现有 all-CP 开关（本窄拓扑许可明确排除了它）。

结论：当前记录支持“四个固定热前缀”的已测运行点；完整 KV 对更大独立前缀工作集和更高发送并发的容量/负载代价，建议作为独立验收项补齐。本评论为源码、配置和已有验收记录分析，未执行新的 GPU 压测。

[fivechenxi]

PCP 按 token/page 分片保存 KV：社区已有直接相关工作，建议作为完整 KV / CP0-only 的替代候选

调研日期：2026-10-19。本 PR 对照 head：634fa4c21a098fa6c0d5101eabd8e744160bc37b。承接前面的 完整 KV 容量与 CP0 来源负载分析。

核心想法：D 最终需要得到未命中部分所需的全部层、全部 token KV（在 DCP 下可以分布于多个 D rank），并不要求先由 P 的 CP0 持有并发送全部数据。除了保留完整副本、按请求轮换发送 CP，也可以让 P 沿 token/page 维度持久分片，由各 owner 直接发送自己的数据。

1. 社区已经做到了哪些部分？

最直接的参考是 SGLang 的 kv-shard 系列：

社区工作	当前状态	与这个想法的关系
#38356：Logical-page placement	MERGED，2026-09-11	扩大的逻辑地址空间、按页 ownership、owner-class allocator 与 prefix-cache rotation metadata
#37615：Sharded pools	MERGED，2026-09-16	每 rank 只持久保存自己拥有的 KV 行；attention 使用按层组装的 scratch
#40102：Control Plane C	MERGED，2026-10-10	--enable-kv-cache-sharding 运行时配置、pool/allocator 接入及预算；与前序 #38468 配套
#40925：DSA indexer pool sharding	MERGED，2026-10-12	latent KV 与 index K/scale 共用 ownership 和 scratch 方案；这是 pool 层支持
#38473：PD transfer and e2e	OPEN	各 P owner 过滤并发送自己拥有的页，D 从整个 shard group 收取，直接对应多来源 PD 交接
#44280：DSA attention/indexer 接入	OPEN	GLM-5.2 的逻辑页与 scratch 地址区分、fused indexer 写入及 attention 接入
#40929：MTP pool sharding	OPEN	draft 共享 target allocator/ownership，但持有独立 KV 与 scratch；描述范围是 dense MLA/MHA 的 pool 层

不能将“这些基础 PR 已合并”理解成“GLM-5.3 + MTP + PCP4 → DCP2 已可直接开启”。截至核对的 main 834bfe4ef0ec11ac5625fac3f94f60c041a36cb8，kv_shard_hook.py 仍拒绝 DSA、speculative decoding、HiCache 等组合，并限定 attention backend。它也禁止在同一 worker 同时启用该 sharded allocator 和 DCP；这条本地限制不等于已经判断了独立 D 端 DCP2 的可行性，跨 P/D 布局还需单独适配。

另外，#43778：HiCache with KV sharding 当前 OPEN，方案仍拒绝 L3；不能沿用当前未分片缓存的备份/恢复假设。

2. 社区的实现方式：持久分片，计算时临时聚合

以四个 shard 为例，每张卡保存所有层中自己拥有的那部分 token/page：

P CP0：所有层的 owner-0 页
P CP1：所有层的 owner-1 页
P CP2：所有层的 owner-2 页
P CP3：所有层的 owner-3 页

这与 LayerSplit 的“每张卡保存一部分层的全部 token”不同，也与当前“每张卡保存全部层、全部 token”不同。

社区已合并的 pool 方案在 prefill attention 前，将所需 cached prefix 从各 owner AllGather 到按层复用的 scratch，和当前 chunk 拼成 attention 可读取的视图；支持提前一层预取，并复用 scratch。DSA pool 方案也聚合 index K/scale。

因此，持久 KV 分片不等于 attention 无需跨卡 KV 通信。 它能减少长期缓存副本、提高同预算下的逻辑容量，并分散来源；但相较当前 full-KV 本地读取，会重新引入前缀 gather、scratch 显存和同步成本。社区另有 #44029：Zero-SM KV gather（OPEN）尝试降低 gather 对计算资源的干扰，这也说明该成本仍需要优化。其硬件/NCCL条件需在 SM120 上单独核对。

不要把 PCP 的计算分片直接等同于物理缓存 ownership：interleave PCP 可能按 token 位置分配计算，而社区 KV ownership 按逻辑页地址分配并携带 rotation metadata。应复用明确的页映射规则，保证 prefix 命中、续接、驱逐和回收都遵守同一个 ownership。

3. 针对本 PR 的建议方案

建议比较两个不同规模的候选：

A. 完整副本 + 每请求选择来源 CP

• 各 CP 仍保存完整 KV，容量成本不变。
• 每个请求固定选一个 CP，多个请求分散到不同来源，减轻 CP0 热点。
• 需要把当前进程级 dummy、CP0-only state/index 发送规则改为请求级选择，并统一握手、完成计数、取消/drain。
• 单个大请求仍只由一个 CP 分片承担发送，按请求均衡也不等于按字节均衡。

B. 持久 KV 按页分片 + 各 owner 直接向 D 发送

• 尽量复用社区 page-interleave allocator/pool，而不是另起一套物理索引规则。
• 每个 P owner 提供自己保存的页；D 最终收到所需 KV 的并集，不先汇聚到 CP0。
• 为当前 P PCP4、D DCP2 建立明确的地址转换链：

请求 token / 全局逻辑 loc
    → P owner + P 本地物理地址
    → DCP owner + D 本地物理地址

• DCP 按 token 交错的布局与 P 按页分片的布局可能不同，一张 P 页可能需要分送给多个 DCP rank；不能复用 CP0 完整源的偏移假设，也不能仅按源页列表的位置取模。
• latent KV、DSA index K/scale、MTP draft KV/state 必须分别明确 ownership、复制需求和传输单位。D 当前的 DSA index 布局若仍是复制的，就必须在各需要的目标 rank 上恢复完整 index；不能照搬 latent KV 的 DCP 路由。
• 接入真实 DSA backend metadata、fused store、top-k 地址转换、PD 发送过滤/完成计数，以及 abort/drain 和 prefix/retraction 生命周期。

这是“完整副本轮换来源”之外的容量方案，需要更大的集成工作；两者不应混为同一个开关。

4. 成本模型与验收

按页分片后的容量收益应扣除 prefix scratch、index scratch、draft pools、pack buffers 和 workspace；不能直接宣称每卡容量精确增加四倍。全套传输字节数也取决于 D 的已有前缀命中与 index/draft 的复制需求。

建议在相同显存预算、真实 GLM-5.3 NVFP4/FP8 KV、MTP 配置下对照：

1. LayerSplit；
2. 当前 full KV + CP0-only；
3. full KV + 每请求来源轮换；
4. page-sharded KV + owner 直接发送。

分别测独立长前缀与共享热前缀、冷/热请求、并发与突发流量；记录逻辑 token 容量、最小 free tokens、各来源 pack/发送量、前缀 gather 时间、PD 传输延迟和端到端 TTFT/吞吐。正确性至少覆盖页边界/复用、各 CP→DCP 映射、index/draft 数据、分块与取消、回收恢复；启用 HiCache/L3 前再完成对应支持。

结论：社区已有按 token/page 持久分片的直接实现基础，方向值得评估；当前还不是 GLM-5.3 PCP4/MTP→DCP2 的即用方案。它有机会缓解 full-KV 容量代价和 CP0 来源集中，但不能预先认定比当前本地完整缓存读取更快。 本评论为社区源码/PR调研与设计建议，未实施改动或新增 GPU 验证。

[fivechenxi]

有界打包提交需要补充明确的单项收益；暂不推进双 buffer

针对提交 835ccf9673（当前 PR head 634fa4c21a098fa6c0d5101eabd8e744160bc37b）。

目前代码机制是清楚的：原路径已经有固定大小、预注册的 pack buffer；本提交在一次数据装不下时分块复用，避免退回大量不连续的小块 RDMA。它没有减少必须传输的 KV 字节数，而是用 GPU gather/复制及多轮同步发送，换取更少、更大的传输块。

但 README 目前没有给出这个提交独立的性能收益。字节复制、边界和失败停止的回归能证明对应逻辑，不能代替性能对照；整套优化后的 7K 结果也不能归因到这一项。建议补充以下证据后，再判断是否值得正式集成。

1. 先证明实测负载确实使用了这条路径

新分支仅在开关开启且 src_rows × sum(token_item_lens) > pack_buffer_bytes 时触发。请记录：

• 7K 负载中实际触发次数、占传输调用的比例、每次拆成几块。
• 实际待传 token/字节数，以及 P/D 各自的前缀命中情况。
• 若该负载基本不超过 buffer 容量，应明确本项主要改善哪类大请求，不能将整体吞吐提升归到它上面。

2. 相同配置下，仅切换本提交的 A/B

保持模型、拓扑、量化、队列数、pack buffer 容量、缓存状态及其他优化不变：

• baseline：原有单次 pack，超过容量后走原回退路径。
• candidate：开启 SGLANG_RESEARCH_DCP_BOUNDED_PACK，超过容量后有界分块。

至少给出容量内、刚超过容量、数倍容量，以及连续/碎片页的代表用例，记录样本数和波动。

3. 把收益与新增成本分开量化

请列出前后对照：

指标	需要回答的问题
整段 PD transfer latency P50/P99	从源数据可读到全部目标写入完成，究竟节省多少时间？
gather/pack GPU 时间、同步等待、RDMA 时间	是减少描述符管理成本，还是实际提高链路利用率？本地复制占了多少？
描述符数量、发送批次数、payload bytes	小块减少幅度，以及分块后新增同步调用的代价
CPU 时间、PCIe/NIC 带宽、P 计算受干扰程度	传输优化是否挤占 prefill 资源？
同负载 TTFT / 可持续请求吞吐	单项传输收益最终能转化多少服务收益？

4. 显存成本请按每个源 GPU 报告

列出 worker/queue 数、单 buffer 大小、总注册 buffer 显存及峰值临时分配。区分基线已有的 pack buffer 成本与本提交新增的临时开销：本提交复用旧 buffer，不应误记成新增一整套 buffer，但这些常驻资源仍会影响可用 KV 容量和并发。

本轮先保持单 buffer 方案，暂不推进双 buffer 或扩大 buffer 预算。 双 buffer 可能重叠 pack 与传输，但额外显存会进一步挤压 KV pool；在现有 commit 的收益和瓶颈尚未量化前，不应继续叠加这项复杂度。

希望最终补一张单项对照表，给出明确结论：哪些请求规模/页布局下改善多少，哪些情况持平或退化，以及对应显存预算。当前评论是要求补齐性能证据，不是在否定已有正确性回归或预先断言该优化无效。

[fivechenxi]

还有一个问题需要确认，kv layersplit是之前pr #25 优化的一个重要手段，这个分析关闭了，要参考下之前分析为什么要开启，确认关闭真的有收益。

[fivechenxi]

已逐条核对上述评论，提交 1c5d13ca31 补充脱敏证据、收紧 README 结论；同步到新仓库 TokenVolt-ai/sglang #4 的 1dc97943d7。本次没有改运行时补丁、重启模型或干预进行中的 GPQA。

1. InputSP 的 12.5% 通信增量计算正确。 旧路径4S，新路径4.5S，额外量来自恢复residual；不能称“减少总通信”。本地找回了当时未放进PR的R5逐step profile摘要：排除candidate中的1-token探针后，rank0大step的GPU时间并集均值1440.734→1364.046ms，通信独占813.190→737.978ms，计算独占620.348→620.471ms。支持收益主要表现于通信/同步路径，不支持“Norm减半就是收益来源”。这是插桩归因，不是吞吐测量；NCCL算法/等待/物理链路带宽仍未分清，Norm/clone单独计时仍缺。原始临时trace已不在本地，本次没有声称重新解析了trace。
2. +5.3%有短轮配对证据，但不是稳态或整机单项收益。 R2 BAAB四臂×128请求，首有效增量速率均值0.687809→0.724529 req/s（+5.339%），双方都积队列。R3 0.70/s下candidate短窗队列较平，仍不是长稳SLA。已补源文件SHA与逐臂数据。
3. LayerSplit之前开启是必要的容量优化，不是走错方向。 历史PCP4池约217K会在当时C16负载thrash；启用LayerSplit后历史部署池约806K，16K/mem0.90时约540K。之后R27/R28显式固定110464-token池，用闲余显存把每卡KV从1.54–1.62GiB增到6.33GiB，换取省掉历史KV广播。它不是等实际显存预算的A/B。
4. 原“关闭LayerSplit +10.9%”表述过强，已更正。 原对照是LayerSplit与“完整KV＋有界打包”组合，窗口完成46→51，双方backlog均增长；且输入约85.2K，并非后来的严格81920/73728资格负载。不能把组合短窗收益独立归因给LayerSplit，也不能证明更大独立前缀工作集下仍优。继续保留容量优先的LayerSplit基线。CP0对应两张attention-TP卡，发送热点和等预算容量扫描仍待验收。
5. 有界打包没有可发布的独立性能百分比。 已有完整KV的第二条P热/D冷请求在超buffer回退时约32s超时；候选16条冷/热自然结束、35568次实际KV字节比对及后续96条短轮通过。缺少R65/R66触发率、逐源buffer总量、pack/同步/RDMA分解和单变量A/B，均明确标“未测”，不拿整套7K归因。本轮不做双buffer或扩大buffer预算。
6. 持续residual分片、通信/GEMM融合、page-sharded KV先不直接合入。 需要跨层布局、MTP/aux、PD ownership和L3生命周期的独立适配验证；不能直接删residual AG或兼容guard。后续先补单项归因和等预算工作集扫描，再决定实现。

详情见本PR benchmark/glm53_pd_7k/REVIEW_20261020.md 与 results/review_evidence_20261020.json。本地32项包/审阅测试＋6项recovery包测试通过，其中新增7项是算术/数据一致性检查，不是新增GPU性能或精度验收。7个历史文件SHA及96对layout输入hash/token数核对一致；runtime/kernel/patch原字节哈希未变。