[Docs] Attribute Kimi-K3 Prefill collectives

experiments/pro6000/kimi3_pro6000_sglang_tp_reduce_scatter_prefill/README.md

@@ -134,6 +134,56 @@ Ring collective 的每 rank 主量级可写为：
 反而比原始路径多约 14.7%。实际延迟还会叠加跨四节点 collective 的固定
 开销，因此没有理由期待它改善当前以通信为目标的 Prefill。
 
+## Prefill 通信归因
+
+复用既有 `16K -> 256、C=8、Chunk=8K、TP32、无 MoE A2A` 的
+PyTorch Trace，并用 `record_shapes + with_stack` 原始事件重新统计。虽然该
+Trace 使用 EP32/Marlin，而当前验收配置为 EP4/FlashInfer，但两者均为
+`TP32 + moe_a2a_backend=none`；MoE runner 和 EP 值会改变专家计算，不改变
+下列 TP32 collective 的调用位置与张量形状。
+
+原始 Trace：
+
+```text
+/data/yy/sskj/experiments/pro6000/kimi3_pro6000_decode_profile/
+  trace/1786591959.655009/
+  decode_c8_i16384_o256-1786591959.6615255-TP-0-EP-0-EXTEND.trace.json.gz
+```
+
+Trace 捕获了 9 个 Prefill engine step。每个 step 的主 AllReduce 构成为：
+
+| 通信来源 | 每 step 次数 | `M=8192` 单次输入 | 每 step 输入量 | 占比 |
+|---|---:|---:|---:|---:|
+| Embedding + 93 层 Attention `o_proj` + 首层 dense MLP | 95 | `[8192,7168]`，112 MiB | 10.39 GiB | 40.8% |
+| 92 个 MoE 层的 routed latent + shared expert | 92 | `8192x(3584+7168)`，168 MiB | 15.09 GiB | 59.2% |
+| 合计 | 187 | - | 25.48 GiB | 100% |
+
+这也解释了旧资料里的约 187 次 collective：它不是“全部来自 MoE”，而是
+95 次完整 hidden 归约和 92 次 MoE 尾部归约之和。Kimi-K3 配置有 93 层，
+`first_k_dense_replace=1`，因此只有后 92 层走 MoE。
+
+当前 SM120 四机部署不会启用 `k3_ar_fusion`：该路径只在 SM100/SM103 且
+CustomAllReduceV2 multicast 可用时自动开启；跨节点日志也明确显示
+`CustomAllreduce is disabled because this process group spans across nodes`。
+所以以上标准 NCCL 调用仍是当前 EP4/FlashInfer 配置的真实结构。
+
+### 优化优先级
+
+1. **MoE A2A / SP-MoE 优先验证。** 它瞄准占输入字节 59.2% 的 MoE 尾部
+   collective，并可避免每个 TP rank 对同一批 token 的重复路由与专家计算。
+   但 A2A 会引入 dispatch/combine，必须以四机实测判断净收益。
+2. **Pipeline Parallelism 第二。** 用 TP16/PP2 或 TP8/PP4 缩小 TP
+   collective 通信域，同时只增加少数 stage-boundary P2P；需验证流水线空泡
+   对 TTFT 的影响。
+3. **通信量化作为独立高风险项。** 它能同时压缩两类大消息，但需要准确性与
+   backend 支持验证。
+4. **不优先做 NCCL 算法或 launch fusion。** Prefill 单消息为 112/168 MiB，
+   首要矛盾是字节量和 32-rank 跨节点通信域，不是小消息启动延迟。
+
+因此，通用 TP Reduce Scatter 即使成功，也只触及约 40.8% 的 hidden 路径，
+且 K3 gate/KDA 又迫使完整 hidden 存在；它不如先处理占比更大的 MoE 尾部
+通信。
+
 ## FlashInfer MoE 的关系
 
 当前 `flashinfer_mxfp4` 是 MoE runner，且实验配置保持
@@ -170,4 +220,3 @@ All-Reduce 并新增 latent All-Gather。分支仅作为否决证据保留，不
    继续使用固定口径 `16K -> 1、C=8/16、Chunk=8K`。
 4. 只有出现 gate-aware 的实现（例如低成本复制/重排 gate 权重，且通信模型
    明确优于原始 All-Reduce）时，才重新开启 TP Reduce Scatter 方向。
-