[issue9] KV Cache 通信组件多表 destination-major 字节打包参考实现

[shsaihdsaiudh]

关联 Issue

#9

提交内容

src/code/issue9/fused_alltoallv_reference.py：多表 AlltoAllv 聚合融合的布局与正确性参考实现。

核心是打包布局：把各表数据按 destination-major、table-minor 顺序打成一个连续字节 buffer，使每个目标 rank 对应且仅对应一个连续 segment——这是"多表合并为一次 AlltoAllv"能够成立的前提。接收端按每表的 dtype、尾部 shape 与 split 元数据还原出与逐表方案完全一致的结果。

本机模拟覆盖：

• 多张表 first-dim 大小不同；
• 表间 hidden shape 与 dtype 不同（混合 dtype）；
• split 中存在零长度消息；
• 接收顺序与逐表 AlltoAllv 基线一致，且逐位相等。

验证

python -m pytest src/code/issue9/test_fused_alltoallv_reference.py -q   # 2 passed
python src/code/issue9/fused_alltoallv_reference.py

结果写入 src/code/issue9/results/。默认演示把 8 次逐表 launch 合成 1 次，按启动次数模型对应控制面开销下降 87.5%。

当前边界

本 PR 覆盖验收要求 1 中的正确性部分：融合布局与逐表基线逐位一致，且在混合 dtype / 混合 shape / 零长度 split 下成立。

需要说明的是：这是 CPU 参考实现 + 启动开销模型，不是接入 NCCL/DeepEP 数据面的算子；87.5% 是由 launch 次数（8→1）推出的模型值，不是实测的控制面开销或端到端通信时间，README 与结果文件中已标注。

验收要求 2（相对逐表基线在 kernel launch 次数、控制面开销、端到端通信时间上的实测改善）需要多机多卡环境，把同一布局接到真实 all-to-all 数据面后采集。提交者当前为单机单卡环境。本 PR 的布局设计与元数据组织可直接复用到该阶段。