fix: fit planning block size to device SMEM limit

[Truth-Ke]

背景

现在一些新型 MoE（如 Mobius、MoRE、MoUE）开始通过跨层共享 Expert，把原本分散在不同深度上的专家容量合并成更宽的全局/共享 Expert Pool，因此单次路由可面对的 Expert 数会显著增加，达到数千级。

MoonEP 的 planning kernel 目前固定使用 512 个线程，也就是 16 个 warp。其中最大的 scratch 项为：

(E + 1) * (num_warps + 1)

此外，kernel 还会在 shared memory 中分配三个长度为 E 的完整数组：s_hist、s_bp 和 s_col。在固定 512 个线程时，这些分配会随着 E 近似线性增长，最终超过单个 block 的 shared-memory 上限。

以 H200 为例，其单个 block 可使用的 opt-in shared memory 上限为 232,448 B。原版在 E=2880 时需要 232,272 B，仍可运行；到 E=2888 时增加到 232,976 B，已经无法编译或启动。E=6144 时，原版需要的 shared memory 达到 494,992 B。

修改方案

本 PR 根据当前设备的 shared-memory 容量动态选择 planning block：

• 根据 E、R、num_sms 和 block_dim 预估 kernel 的 shared-memory 用量，计算过程与 kernel 内的实际分配及对齐规则保持一致。
• 读取当前设备的 opt-in 单 block shared-memory 上限。
• 从 512 个线程开始，每次减少一个完整 warp（32 个线程），选择能够满足 shared-memory 上限的最大 block；最小保留一个 warp，也就是 32 个线程。这样可以在不超限的前提下尽量保留线程并行度，并尽可能利用可用的 shared memory。
• 将 kernel 中的 warp 数、scratch layout、每线程工作量和 launch block 改为使用选出的 block_dim。
• 原本能够使用 512-thread block 的 shape 继续使用 512，不改变已有执行路径。

如果只保留一个 warp（32 个线程）时仍然超过设备上限，则让生成的 kernel 直接报告资源超限。

正确性验证

测试环境：8× H200。

torchrun --standalone --nproc_per_node=8 \
  -m pytest -q -s tests/test_planning.py

每个 rank 的结果均为 23 passed, 1 skipped。所有成功运行的 planning 输出在 8 个 rank 上均与独立 PyTorch reference 完全一致，所有 planning invariant 检查也全部通过。

大 Expert 数边界

E	原版 block / SMEM	修改版 block / SMEM	结果
2880	512 / 232,272 B	512 / 232,272 B	原版边界保持不变
2888	512 / 232,976 B	480 / 221,392 B	原版超限，修改后通过
3072	512 / 247,696 B	448 / 223,056 B	原版超限，修改后通过
4608	512 / 371,344 B	256 / 223,824 B	原版超限，修改后通过
6144	512 / 494,992 B	160 / 224,592 B	原版超限，修改后通过
9216	512 / 742,288 B	64 / 226,128 B	原版超限，修改后通过

原本能够使用 512-thread block 的 shape 在修改后仍选择 512。对这些模型分组进行配对测试后，耗时变化中位数位于 -0.11% 到 +0.16% 之间，原有性能基本不受影响。

性能测试

SMEM 为 benchmark 记录的 shared-memory 字节数。精度列写“与 PyTorch reference 完全一致”，表示 8 个 rank 的全部输出元素都与 reference 相同。没有执行 reference 检查时，不推断该版本的精度通过。

“模型 / 倍率”（Model / scale）表示测试 shape 的来源和 Expert Pool 的扩展倍率。例如，Kimi-K2.5 E×8 表示以 Kimi-K2.5 的模型参数为基础，仅将 Routed Expert 数量扩大到原配置的 8 倍；TopK、H 等参数保持原模型配置，token 数使用表中的 S。这些倍率用于模拟跨层共享后更宽的 Expert Pool，不表示对应公开模型本身采用了该 Expert 数量。

模型 / 倍率	Experts	S	原版耗时/状态	修改版耗时/状态	耗时变化	block：原版 → 修改版	Shared memory：原版 → 修改版	精度
GLM-5.2 E×8	2048	16384	76.885 μs	76.989 μs	+0.14%	512 → 512	165,264 → 165,264 B	修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×4	1536	123	36.658 μs	36.658 μs	+0.00%	512 → 512	124,048 → 124,048 B	修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×4	1536	4096	46.202 μs	46.288 μs	+0.19%	512 → 512	124,048 → 124,048 B	修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×8	3072	4096	SMEM 超限，无法运行	59.989 μs	修改版恢复可运行	512 → 448	247,696 → 223,056 B	原版：—；修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×8	3072	16384	SMEM 超限，无法运行	93.574 μs	修改版恢复可运行	512 → 448	247,696 → 223,056 B	原版：—；修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×16	6144	123	SMEM 超限，无法运行	117.863 μs	修改版恢复可运行	512 → 160	494,992 → 224,592 B	原版：—；修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×16	6144	4096	SMEM 超限，无法运行	128.203 μs	修改版恢复可运行	512 → 160	494,992 → 224,592 B	原版：—；修改版：与 PyTorch reference 完全一致
Kimi-K2.5 E×16	6144	16384	SMEM 超限，无法运行	138.650 μs	修改版恢复可运行	512 → 160	494,992 → 224,592 B	原版：—；修改版：与 PyTorch reference 完全一致
Qwen3.5-397B-A17B E×1	512	131072	415.935 μs	415.455 μs	-0.12%	512 → 512	41,616 → 41,616 B	修改版：与 PyTorch reference 完全一致

下面是附件的全量测试（含 kimi系列 DeepSeek-V4-Pro GLM-5.2 GLM-5.3-Flash Qwen3.5）
全量测试.md