背景与目标

arch35 Sort 在短轴多行、非末轴、以及可在 UB 内完成整行归并的场景中，存在归并中间数据搬运、逐行控制和索引构造开销。本次优化按 dtype、轴长、行数及 UB 容量选择路径，减少设备执行开销，并保持 stable、升降序、values/indices 和浮点特殊值语义。

关键方案

1. 归并过程使用 ping-pong proposal 缓冲：抽取公共归并辅助实现，交替使用输入与输出缓冲，减少阶段间回拷；在适用的 FP16/int64 索引路径批量处理多行，摊薄逐行归并控制开销。队列深度为 2，使用 EnQue/DeQue 管理数据搬运依赖。
2. 按实际 UB 布局选择整行归并：统一通过 SetMergeSortTiling 计算容量，useUbCapacity 路径计入输入、proposal、输出及索引缓冲。满足条件的 FP32 大轴可直接走单核整行归并；保留小轴原有策略和容量不足时的回退。多核归并在适用场景细化末轮任务划分。
3. 优化非末轴小轴路径：使用紧凑 UB 布局与批次规划，改进 NDDMA 搬运和索引构造；向量化生成索引，并处理 int64 索引高低位及尾块掩码。Host 容量预算与 kernel 实际分配对应。
4. 消除尾随单例维引起的冗余转置：仅在 IsRegBase() 且排序轴之后全为 1 时，通过 Reshape 转为末轴 Sort，再恢复输出形状；Reshape 保持连续数据顺序。其他平台和不满足条件的输入沿用原路径。
5. 维护共享调用与特殊值语义：配套调整 TopKV2 使用的归并模板；处理 NaN 排序 key 与原值回读，覆盖正负零、稳定索引、尾块及多核同步边界。NN 中重复的公共归并实现同步维护。

验证与验收口径

• 本机 Ascend950PR_9579、CANN 9.3.0、TTK v3.0.0：Sort kernel 395 条、正负零逐位比较 18 条、Sort ACLNN 40 条、TopKV2 受影响集合 177 条，合计 630 条精度全部通过；Sort 同时校验 values 和 indices。
• 性能与前一版已验证实现对照：对超过 5% 且超过 0.5 μs 的设备耗时异常项复测，未确认稳定回退。此结论不等同于全部 case 达到 910B 的 2.45×，也不包含 ACLNN 主机侧 API 耗时持平承诺。
• 完整提交检查通过。扩展 ST 与结果保留在本地，仓内保留少量代表性看护用例。

实现 PR：https://gitcode.com/cann/ops-math/pull/5672
关联的 NN 优化 PR：https://gitcode.com/cann/ops-nn/pull/10411