两个 MoE 算子的输入都有单区间 value_range 表达不了的结构约束，通用生成器与现有 get_input 都没兜住。

1. MoeFinalizeRouting：expanded_src_to_dst_row 应为单射映射

该输入是 MoeInitRouting 产出的"源行 → 展开缓冲区行"映射，每个源行 (token, k) 占据展开缓冲区中互不相同的一行：

• drop_less（mode 0/2）：[0, NK) 的完整置换
• drop_pad（mode 1/3）：到 [0, E*C) 的单射，容量溢出的源行取 -1 表示丢弃

而通用生成器按 randint 独立有放回采样，重复量很大（约 37% 的条目落在已被占用的目的行上）：

这不是"当前判错"，但有两个实质问题

golden 与真实 MoeFinalizeRoutingV2 都做 gather，重复索引下数值仍然可比（现网用例即如此通过）。然而：

1. 访存模式失真 —— 真实场景每行恰好读一次，重复采样把它变成随机重复读，L2 命中率虚高，perf 数据不具代表性。
2. 契约站在候选一边 —— 任何采用 scatter 方向实现的候选（遍历展开行写回目的行，与 gather 等价当且仅当映射单射）都会与 golden 分叉。

修法

新增 get_input：按 case 实际形状推导目的空间 num_dst（drop_less 下 == NK，drop_pad 下 == E*C），为非 -1 位置分配 [0, num_dst) 的互异值；-1 的位置原样保留，维持 drop_pad 用例既有的丢弃覆盖与随种子可复现的行为。其余 6 个输入原样透传。

未做的部分已在注释中写明：drop_pad 的完整契约还要求目的行落在该源行所属专家的容量块 [e*C, (e+1)*C) 内。golden 不校验这一点，且按专家分配会让丢弃率降到近乎 0（当前用例 E*C 远大于 NK），反而削弱 -1 路径覆盖，故只做单射重建；专家对齐应由用例设计连同容量一并调整。

2. MoeReRouting：get_input 自身会静默违反契约

proto.yaml:39 声明 expert_token_num_per_rank 的元素必须大于 0，而 get_input 用 base_value = A // (N*E) 平铺 —— A < N*E 时 base_value 为 0，除最后一格外全是 0，静默产出违反契约的输入。候选 kernel 在"某张卡的某个专家分到 0 个 token"上的行为未定义，失败会表现为莫名的精度不符而非配置错误。

当前用例集最小 base_value = 4（c20: A=64, NE=16），不会触发；这是为后续新增小 A 用例设的护栏：base_value < 1 时直接抛 ValueError 并指明 A 与 NE 的具体数值。不改既有的余数分配方式，20 个用例行为完全不变。

验证

• MoeFinalizeRouting 20 个用例：重复数全部归零、无越界、-1 位置与数量保持不变、golden 输出 shape 不变。
• MoeReRouting 20 个用例：sum == A、min > 0，与修复前逐位一致。
• 新增 tests/ut/test_moe_get_input.py（15 项）：drop_less 满置换、drop_pad 非 -1 项互异、-1 位置保留、目的空间取值域、shape/dtype 契约、跨调用可复现、其余输入透传、抽屉原理兜底、golden 可执行；以及 ReRouting 的可行/边界/不可行三态与透传。
• tests/ut 全量 1069 passed / 6 skipped。

顺带记录一个用例设计层面的覆盖缺口（本次不改）

MoeReRouting 20 个用例里 18 个的 expert_token_num_per_rank 是完全均匀分布，专家负载不均的场景没有覆盖。这属于用例设计范畴，建议由算子 owner 评估是否补充。