【RFC】分布式算子 ST 测试架构重构

0. RFC 摘要

本 RFC 面向 HyperParallel 分布式算子系统测试（ST），将原有“每个算子独立 launcher + worker”的
脚本式测试方式重构为声明式、跨平台、可调度的测试架构。

核心目标是让算子开发者只描述：

• 测试哪个算子；
• 输入张量如何构造；
• 输入如何切分到 DeviceMesh；
• 结果采用何种比较方式；
• 用例进入哪个平台和门禁等级。

测试框架统一承担单卡参考计算、分布式执行、结果汇聚、数值比较、进程编排、设备分配和报告聚合。

范围

• 分布式算子 ST 的声明模型、注册发现、分组、调度、执行和报告；
• Torch CPU（gloo）、Torch Ascend（hccl）和 MindSpore Ascend 三种后端；
• 2/4/8 卡 DeviceMesh、level0/level1 门禁路由和 8 卡资源调度；
• 存量 Torch/MindSpore 分布式算子 ST 用例迁移；
• CLI、本地过滤和 CI 门禁入口。

非目标

• 不替代算子 UT：参数校验、Layout 推导和错误路径仍由 UT 覆盖；
• 不改变分布式算子实现及其数学语义；
• 不把所有测试抽象为完全相同的用例，保留 derived_inputs、needs_mesh、solo_launcher 等必要扩展点；
• 不要求不同框架共享同一段算子调用函数，平台差异由后端适配和各自 case 文件表达。

---

1. 背景与问题

旧框架采用 test_parallel_op_X.py（pytest launcher）与 _test_parallel_op_X.py
（torchrun/msrun worker）双文件模式。每个算子和场景都重复实现初始化通信、创建 DeviceMesh、
构造输入、切分张量、汇聚输出和比较结果。

1.1 原框架问题

问题	根因	架构影响
样板代码重复	每个 worker 独立实现相同的分布式执行流程	用例维护成本高，修复需要霰弹式修改
launcher 启动成本高	每组少量用例独立启动 torchrun/msrun	CANN/HCCL 初始化耗时占总耗时主体
设备利用率低	缺少按卡数和 mesh 拓扑统一规划	8 卡环境无法自动并发运行两个 4 卡 group
门禁路由分散	marker、level 和用例分组散落在不同入口	用例覆盖范围难审计，新增场景容易漏入门禁
跨平台逻辑重复	Torch、MindSpore 分别手写构造、切分、汇聚、比较	相同测试语义在不同后端出现实现漂移
失败诊断困难	多 rank 输出分散，缺少统一结果聚合	CI 失败难以快速定位到具体 case 和 rank
特殊场景缺少统一模型	派生输入、多输出、MC2、随机结果各自临时处理	扩展能力不可复用，测试语义不清晰

1.2 分布式测试硬约束

编号	约束	说明
C1	外部启动器	分布式 ST 必须由 torchrun 或 msrun 创建多个独立 rank 进程
C2	多 rank 协同	同一 case 必须在所有 rank 上以一致顺序执行，通信失败可能破坏整个进程组
C3	设备隔离	同批 group 必须使用互不重叠的设备切片
C4	启动昂贵	框架、CANN 和通信域初始化远慢于单个算子计算
C5	跨平台	同一测试语义要覆盖 Torch CPU、Torch NPU 和 MindSpore NPU
C6	混合 mesh	同一套件可能同时包含 2、4、8 卡用例，无法由一次固定 nproc 的 launcher 全部承载
C7	CI 兼容	新框架需要继续通过 @arg_mark 接入现有 level0/level1 门禁

---

2. 架构目标与质量属性

质量属性	质量属性场景	设计响应与验收方式
正确性	一个算子在指定切分策略下执行	对同一份完整输入先计算单卡参考，再切分执行并汇聚，比较完整输出
确定性	随机初始化用例重复运行	InputSpec.seed 固定输入；数值可比较场景必须得到稳定参考结果
性能	大量同拓扑 case 进入同一套件	同 mesh 用例共享 launcher，减少重复初始化；以 suite wall-clock 验收
资源效率	8 卡机器同时存在多个 2/4 卡 group	按卡数装箱，同一 batch 在不重叠设备切片上并发执行
可移植性	同一测试模型运行于三个后端	平台无关核心只依赖 ShardBackend 接口，后端独立完成设备操作
可扩展性	新增后端、新比较方式或特殊输入	通过 Backend、CompareSpec、DerivedSpec 等扩展点实现，不修改 case 执行骨架
可靠性	某个 case 断言失败或通信异常	聚合所有 rank 状态；非断言异常后执行通信健康探测，避免污染后续 case
可诊断性	CI 中某个 rank 失败	Reporter 记录 case、rank、状态、耗时和错误，并汇总为人类可读结果
易用性	开发者新增算子 ST	只需创建 case_{op}.py 并声明 OpShardCase，无需手写 launcher/worker 样板
可维护性	调整公共执行或门禁策略	在 framework/suite/runner 中集中修改，存量 case 无需同步改写

2.1 关键性能目标

• launcher 启动成本由“每个用例或小组重复支付”变为“同一 group 内用例共享”；
• 支持按 8 卡预算并发调度多个 2/4 卡 group；
• 新框架运行完整 level0 套件的耗时应低于旧框架运行少量代表用例的耗时；
• 性能结论使用 wall-clock、用例数量、串行 batch 数和后端环境共同描述，避免只比较单 case 时间。

---

3. 4+1 架构视图

3.1 逻辑视图

框架由声明模型、注册发现、套件规划、父进程调度、rank 执行、后端适配和报告聚合组成。

classDiagram
    direction LR

    class OpShardCase {
        +name
        +fn
        +inputs
        +placements
        +mesh_shape
        +tags
    }

    class InputSpec
    class DerivedSpec
    class CompareSpec
    class Registry {
        +register(case)
        +load_cases_from_package(package)
    }
    class SuitePlanner {
        +build_suite_groups(...)
        +pack_into_batches(...)
    }
    class Runner {
        +run_groups(groups, framework, device_type)
    }
    class ShardBackend {
        <<interface>>
        +maybe_init_dist()
        +make_tensor(spec)
        +distribute(tensor, mesh, placement)
        +local_to_global(tensor)
        +assert_close(expected, actual, compare)
        +recover_after_failure()
    }
    class TorchHcclBackend
    class TorchGlooBackend
    class MindSporeAscendBackend
    class Reporter

    OpShardCase *-- InputSpec
    OpShardCase *-- DerivedSpec
    OpShardCase *-- CompareSpec
    Registry o-- OpShardCase
    SuitePlanner --> Registry
    Runner --> SuitePlanner
    Runner --> ShardBackend
    Runner --> Reporter
    ShardBackend <|.. TorchHcclBackend
    ShardBackend <|.. TorchGlooBackend
    ShardBackend <|.. MindSporeAscendBackend

核心职责边界：

• OpShardCase 只描述测试意图，不处理进程、设备和通信；
• SuitePlanner 只规划 case、group、batch 和设备预算，不执行算子；
• Runner 管理 launcher 生命周期和设备隔离，不包含平台张量操作；
• ShardBackend 封装平台张量、分布式初始化、切分、汇聚和比较；
• entry 在各 rank 上执行统一流水线，并将结果交给 Reporter。

3.2 开发视图

tests/
├── shard_ops/framework/                    # 平台无关核心
│   ├── case_spec.py                        # OpShardCase/InputSpec/DerivedSpec/CompareSpec
│   ├── registry.py                         # 注册和发现
│   ├── backend.py                          # ShardBackend ABC 与后端注册
│   ├── suite.py                            # 分桶、group 和并发规划
│   ├── runner.py                           # 父进程、launcher、设备分配和超时
│   ├── entry.py                            # rank 进程执行入口
│   ├── reporter.py                         # JSONL 和汇总
│   └── cli.py / __main__.py                # 本地运行入口
├── torch/shard/ops/
│   ├── test_shard_ops_suite.py             # Torch CI 入口
│   ├── cases/case_{op}.py                  # Torch 声明式用例
│   └── framework/backend_torch.py          # gloo/hccl 适配
└── mindspore/st/shard/ops/
    ├── test_shard_ops_suite.py             # MindSpore CI 入口
    ├── cases/case_{op}.py                  # MindSpore 声明式用例
    └── framework/backend_mindspore.py       # Ascend 适配

平台无关共享框架本身不直接依赖 PyTorch 或 MindSpore；平台张量和通信操作统一通过
ShardBackend 实现。case package 在用例发现阶段注册声明，真正的分布式初始化和设备执行发生在
launcher 创建的 rank 进程中。

3.3 进程视图

sequenceDiagram
    actor CI as CI / Developer
    participant Pytest as pytest parent
    participant Suite as SuitePlanner
    participant Runner
    participant Launcher as torchrun / msrun
    participant Rank as rank processes
    participant Backend as ShardBackend
    participant Report as Reporter

    CI->>Pytest: run suite entry or CLI
    Pytest->>Suite: build_suite_groups(tags, filter)
    Suite-->>Pytest: GroupSpec list
    Pytest->>Runner: run_groups(groups)
    Runner->>Runner: pack groups into 8-card batches

    loop each serial batch
        par non-overlapping device groups
            Runner->>Launcher: start group with assigned devices
            Launcher->>Rank: create N rank processes
            Rank->>Backend: init distributed and DeviceMesh

            loop each case in group
                Rank->>Backend: build full tensors
                Rank->>Rank: derive full inputs if configured
                Rank->>Rank: run standalone reference
                Rank->>Backend: distribute inputs
                Rank->>Rank: run distributed function
                Rank->>Backend: gather distributed output
                Rank->>Backend: compare expected and actual
                Rank->>Report: append per-rank JSONL result
            end

            Launcher-->>Runner: group exit status
        end
    end

    Runner->>Report: summarize all groups and ranks
    Report-->>Pytest: pass or aggregated failure

不包含派生输入时，每个 case 执行原稿定义的基础六步流水线：

build → reference → distribute → run → gather → compare

配置 derived_inputs 后，在 build 与 reference 之间增加 derive，扩展为七步流程：

build → derive → reference → distribute → run → gather → compare

derive 必须在完整主输入上执行一次，再按声明的 placement 切分；不能在各 rank 的局部分片上重算
依赖全局信息的派生量。七步流程是六步基础模型对 attention 等场景的兼容扩展，不是两套执行架构。

3.4 部署视图

部署组合	launcher	Backend	设备/通信
Torch CPU	torchrun	TorchGlooBackend	CPU + gloo
Torch Ascend	torchrun	TorchHcclBackend	Ascend NPU + hccl
MindSpore Ascend	msrun	MindSporeAscendBackend	Ascend NPU + HCCL/通信接口

一台 8 卡节点同时承担两类角色：

• 控制面：单个 pytest 父进程负责 suite 规划、batch 装箱、设备切片和 launcher 生命周期；
• 执行面：一个或多个 launcher 分别创建 2/4/8 个 rank，使用互不重叠的设备集合执行 group。

mesh_shape 决定 num_proc，必须满足 num_proc == math.prod(mesh_shape)。对普通算子，mesh 轴名是
文档标签并可按 ndim 归一化；对 needs_mesh=True 的 MC2 算子，轴名参与通信组解析，必须保留真实名称。

3.5 场景视图（+1）

场景	关键机制	预期结果
新增普通算子用例	register(OpShardCase(...))	自动发现并按 tags/mesh 进入对应 suite
多输出算子	compare_outputs=(...)	只汇聚和比较指定输出，忽略随机或非关注输出
不可确定值	CompareSpec.shape()	只验证 shape 和 dtype，不伪造数值正确性
Attention 派生统计	DerivedSpec	在完整 Q/K 等输入上计算统计量，再切分到各 rank
MC2 算子	needs_mesh、真实 mesh_dim_names	case 取得正确通信组，并遵守 launcher 隔离约束
本地复现	CLI 或 HYPER_PARALLEL_SHARD_CASE_FILTER	无需修改 suite 即可只运行单文件或单 case
通信异常	recover_after_failure()	判断进程组是否可继续使用，避免后续 case 产生级联失败

---

4. 架构模式

模式	在本方案中的体现	目的
Declarative Model / Internal DSL	OpShardCase、InputSpec、CompareSpec	将“测试什么”与“如何启动和执行”分离
Ports and Adapters	ShardBackend 为端口，三个 Backend 为适配器	平台无关核心复用，后端差异受控
Strategy	根据 framework/device_type 选择 Backend，根据 CompareSpec 选择比较策略	避免在执行流程中散布平台判断
Registry	register() 和 case/backend 注册表	支持声明式发现和扩展
Pipeline	六步基础模型 + 可选 derive 扩展	固化参考、分布式执行和比较的对称语义
Parent-Worker	pytest/Runner 为控制面，launcher/rank 为执行面	隔离进程生命周期、设备环境和分布式状态
Batch Scheduler	mesh 分桶、并发槽位和 8 卡首次适应装箱	减少串行 launcher 数并提高设备利用率
Aggregator	Reporter 聚合多 rank JSONL	输出单一、可诊断的 suite 结果

---

5. 架构决策与权衡

5.1 ADR：自定义 Runner 还是 pytest fixture

备选方案 A：纯 pytest conftest + fixture

将 torchrun/msrun 放在最外层，由 session fixture 初始化通信和 DeviceMesh，使用
pytest_generate_tests/parametrize 驱动全部 case。

优点：

• 标准 pytest 语义，IDE、coverage、--lf、--durations 等生态能力可直接使用；
• 框架代码更少，开发者学习成本低；
• 单一 mesh_shape、单 launcher 场景下同样能实现启动复用。

局限：

• 一个 launcher 的 nproc 固定，无法自动承载混合 2/4/8 卡用例；
• 多 group 并发、设备切片和装箱需要移到 shell/CI 外部实现；
• 通信组损坏后的恢复和跨 rank 报告需要额外机制；
• 现有 CI 需要从普通 pytest 入口改为 launcher 包裹 pytest。

备选方案 B：自定义 Suite + Runner + Entry

普通 pytest 父进程完成分桶、装箱和调度，每个 group 启动独立 torchrun/msrun，rank 进程通过统一 entry
执行声明式 case。

优点：

• 一次 pytest 调用自动覆盖混合 mesh；
• 内建 8 卡装箱、设备隔离、通信健康探测和跨 rank 报告；
• 保持 @arg_mark 门禁入口，CI 无需重构；
• 对 launcher 数和 suite wall-clock 具有统一优化空间。

代价：

• 自建框架代码和环境协议更多；
• case 不是原生 pytest item，部分 pytest/IDE 生态能力不能直接使用；
• 需要维护调度、超时、进程清理和报告组件。

决策

采用方案 B。当前项目同时存在 2/4/8 卡 case、设备并发调度和通信恢复的真实需求，调度是框架的核心能力，
不能简单外移给 CI。对于只含单一 mesh 的新项目，方案 A 仍然是更轻量的选择。

5.2 其他关键决策

决策点	选择	原因与代价
用例表达	声明式 OpShardCase，而非每个 case 手写流程	消除样板；代价是复杂场景必须设计明确扩展点
参考值生成	完整输入上执行同一 fn	保证单卡/多卡路径对称；要求 fn 尽量保持纯算子语义
派生输入	完整输入预计算后切分	保留全局统计语义；代价是需要额外的 DerivedSpec 模型
门禁路由	case tags + suite tag_include	路由集中可审计；需要维护标签命名约定
mesh 分组	普通算子归一化轴名，MC2 保留真实轴名	减少无意义分桶；对读取通信组名称的算子保留语义
失败策略	level0 fail-fast，level1 收集全部失败	兼顾 PR 反馈速度和日级诊断完整性
特殊硬件限制	solo_launcher 作为隔离逃生口	避免少数 MC2 冲突污染通用调度；代价是增加 launcher 数

---

6. 设计与交付过程

阶段	主要工作	交付物 / 验证
需求分析	统计旧用例重复、启动次数、门禁路由和跨平台差异	ISSUE 223 背景、目标和硬约束
方案设计	设计声明模型、Backend 端口、执行流水线和进程协议	架构分层、接口定义、时序和目录设计
方案权衡	对比自定义 Runner 与 conftest/fixture	ADR，明确采纳理由和已知代价
框架实现	实现 framework 核心及三个 Backend	tests/shard_ops/framework/ 和平台适配层
试点验证	选择典型单输出、多输出、attention、MC2 用例	验证扩展点和异常路径
全量迁移	将 Torch/MindSpore 存量 ST 转为声明式 case	248 个 Torch case、238 个 MindSpore case
性能调优	合并 launcher、mesh 分桶、8 卡装箱、轴名归一化	减少串行 batch 和 suite wall-clock
验收交付	三后端 level0/level1 回归、门禁和文档	PR 857 合入，pr-check-pass 与 ci-pipeline-passed

这套过程体现了“问题与约束识别 → 质量属性定义 → 多方案权衡 → 架构设计 → 试点 → 全量迁移 →
量化验证 → 门禁交付”的架构设计和交付闭环。

---

7. 风险与缓解

风险	缓解措施
placement 元组与 mesh 维数不匹配	注册时校验；文档明确“每个 mesh 轴一个 placement”
num_proc 与 mesh 大小不一致导致 HCCL 挂起	由 mesh_shape 推导并在 CLI/Runner 边界校验
用例发现阶段加载平台 case 增加收集成本	平台无关核心不直接依赖后端；控制 case package 的导入边界，必要时演进为元数据扫描
不同 rank 执行 case 顺序不一致	group 使用统一 case 清单和确定性排序
通信异常污染后续 case	非断言失败后执行健康探测，必要时终止当前 group
派生输入在分片上重算导致语义错误	DerivedSpec 强制在完整输入上计算一次后再切分
多个高卡 MC2 共用 launcher 触发 CANN 限制	保留真实 mesh 轴名，限制同组数量，必要时 solo_launcher=True
声明模型扩展过度	只有可复用且具备明确语义的场景才新增字段，特殊逻辑优先留在 case fn
自定义框架维护成本高	用 ADR 明确适用边界，核心模块保持单一职责，并提供 CLI/实践指南

---

8. 接口与执行规范

8.1 最小用例

import torch

from hyper_parallel.core.dtensor.placement_types import Replicate, Shard
from tests.shard_ops.framework import CompareSpec, InputSpec, OpShardCase, register


def _cat_dim1(x, y):
    return torch.cat((x, y), dim=1)


register(OpShardCase(
    name="cat_ops_dp_dim1",
    fn=_cat_dim1,
    inputs=[
        InputSpec(shape=(8, 16), init="randn", seed=42),
        InputSpec(shape=(8, 8), init="randn", seed=43),
    ],
    placements=[
        (Shard(0), Replicate()),
        (Shard(0), Replicate()),
    ],
    compare=CompareSpec.allclose(rtol=1e-4, atol=1e-4),
    mesh_shape=(2, 2),
    mesh_dim_names=("dp", "tp"),
    tags=("cpu_level0", "npu_level0"),
))

8.2 InputSpec 字段

字段	默认值	说明
shape	必填	张量维度；空 tuple () 表示标量张量
init	"randn"	randn / uniform / ones / zeros / arange
seed	None	随机种子，用于确定性构造输入
dtype	"float32"	平台无关 dtype 名
data	None	np.ndarray 精确值，设置后覆盖 init

8.3 平台抽象接口

ShardBackend 定义统一端口，各后端独立实现：

接口	Torch（hccl）	Torch（gloo）	MindSpore（Ascend）
maybe_init_dist()	init_dist()	init_dist_gloo()	D.init() + ms.set_device("Ascend")
make_tensor(spec)	torch.from_numpy().npu()	torch.from_numpy()	Tensor(arr)
distribute(...)	distribute_tensor()	同左	distribute_tensor()
local_to_global(...)	local_to_global()	同左	dist_tensor.full_tensor()
assert_close(...)	torch.equal/allclose	同左	np.array_equal/allclose
recover_after_failure()	dist.barrier()	同左	comm_func.all_reduce

8.4 Placement 约定

placement 元组长度必须等于 mesh 维数，而不是张量维数：

# 4-D tensor on a 2-D mesh (dp, tp)
mesh_shape = (2, 2)
placements = [(Shard(0), Shard(1))]

# 2-D tensor on a 1-D mesh (tp)
mesh_shape = (2,)
placements = [(Shard(1),)]

8.5 门禁路由

标签	入口	语义
cpu_level0	Torch CPU level0	PR 快速门禁，fail-fast
npu_level0	Torch/MS NPU level0	PR 快速门禁，fail-fast
cpu_level1	Torch CPU level1	扩展回归，收集全部失败
npu_level1	Torch/MS NPU level1	扩展回归，收集全部失败

tag 采用 {platform}_{level} 约定：

tags=("cpu_level0", "npu_level0")   # CPU/NPU 均进入 level0
tags=("cpu_level0", "npu_level1")   # 不同硬件进入不同等级
tags=("npu_level0",)                 # 仅 NPU

suite entry 通过 tag_include 进行单一入口过滤，再使用 @arg_mark 对接现有 CI：

_GROUPS_CPU_LEVEL0 = build_suite_groups(
    cases_pkg=CASES_PKG,
    tag_include={"cpu_level0"},
    fail_fast=True,
)


@arg_mark(
    plat_marks=["cpu_linux"],
    level_mark="level0",
    card_mark="allcards",
    essential_mark="essential",
)
def test_shard_ops_cpu_level0():
    _run_groups(_GROUPS_CPU_LEVEL0, "torch", "cpu", fail_fast=True)

8.6 8 卡并发调度

• _plan_group_count 按 global_num_proc // num_proc 计算并发槽位；4 卡 case 最多两路并发；
• _pack_into_batches 按 num_proc 降序，以 first-fit 方式装箱到 8 卡 batch；
• 同一 batch 内的 group 由 mp.Process 并行启动，并分配互不重叠的设备切片；
• max_cases_per_group=256 控制单组容量、避免过度碎片化；实际 group 数还会根据并发槽位规划；
• 2/4/8 卡 group 分别按 batch 执行，墙钟时间主要由串行 batch 数和 launcher 初始化成本决定。

8.7 子进程执行流程

基础六步模型：

1. build_numpy(spec) → make_tensor
2. fn(*full_tensors) → expected
3. distribute(tensor, mesh, placements) → dist_inputs
4. fn(*dist_inputs) → actual
5. local_to_global(actual) → gathered
6. assert_close(expected, gathered)

配置 derived_inputs 时，在第 1、2 步之间增加 derive：在完整主输入上计算派生值，再分别供参考路径使用
并按 placement 切分到分布式路径。

8.8 本地运行

# CLI：运行文件内全部 case
python -m tests.shard_ops.framework tests/torch/shard/ops/cases/case_sort.py

# CLI：运行文件内单个 case
python -m tests.shard_ops.framework \
  tests/torch/shard/ops/cases/case_sort.py::sort_ops_2d_dp

# CLI：显式切换框架
python -m tests.shard_ops.framework --framework mindspore --case sort_ops_2d_dp

# Suite entry + 环境变量过滤
HYPER_PARALLEL_SHARD_CASE_FILTER="sort_ops_*" \
  pytest tests/torch/shard/ops/test_shard_ops_suite.py::test_shard_ops_cpu_level0 -vs

完整字段、特殊场景和排错说明见
OpShardCase 介绍与实践指导。

---

9. 验收结果

9.1 功能与迁移

• 声明式用例模型：OpShardCase + InputSpec + CompareSpec + register()；
• 平台无关核心与 Torch/MindSpore 后端适配分层；
• Torch CPU、Torch Ascend、MindSpore Ascend 三后端；
• 2/4/8 卡混合 mesh 自动分桶和 8 卡并发规划；
• tags 门禁路由、CLI 和环境变量过滤；
• derived_inputs、compare_outputs、needs_mesh、solo_launcher 等扩展场景；
• 248 个 Torch case、238 个 MindSpore case 完成迁移。

迁移覆盖 elementwise、reduce、view、index、embedding、matmul、softmax、attention、MC2，以及
DFunction DSA/MHC 等算子。确认属于 CANN/ACLNN 层且无法在 HyperParallel 测试框架内解决的问题，
单独记录为 D 类问题，不通过放宽断言或静默跳过掩盖。

9.2 回归与性能

PR 857 记录的六组回归结果：

套件	level0	level1
Torch CPU（gloo）	48.7s	72.4s
Torch NPU（hccl）	58.8s	86.2s
MindSpore NPU	70.8s	302.0s

level0 与旧框架代表用例对比：

后端	旧框架	新框架
Torch CPU	6 个用例 122s	201 个用例 48.7s
Torch NPU	6 个用例 158s	201 个用例 58.8s
MindSpore NPU	6 个用例 295s	105 个用例 70.8s

性能收益主要来自 launcher 启动合并和设备调度，而不是单个算子计算加速。评估时必须同时说明用例数量、
后端环境和 wall-clock，不能将两组数据误写成同规模 benchmark。

9.3 交付状态

• 架构方案经过 Maintainer 评审；
• 存量用例与新框架随 PR 857 一并交付；
• 六组后端/等级回归通过；
• pr-check-pass；
• ci-pipeline-passed；
• PR 857 已合入主干。

---

10. 影响范围

• 新增平台无关核心：tests/shard_ops/framework/ 11 个文件；
• 新增后端适配：Torch、MindSpore framework/ 共 4 个文件；
• 迁移用例：Torch 248 个、MindSpore 238 个声明式 case；
• 新增本地入口：python -m tests.shard_ops.framework；
• 新增过滤接口：HYPER_PARALLEL_SHARD_CASE_FILTER；
• 新增扩展能力：derived_inputs、CompareSpec.shape()、compare_outputs、needs_mesh、
  solo_launcher 和非 MC2 mesh 轴名归一化；
• 兼容性：PR 857 采用增量交付，旧 _test_parallel_op_*.py 文件未在该 PR 中破坏性删除；
• 外部接口：不涉及 HyperParallel 用户态算子 API 变更。

---

11. 总结

本次重构将分布式算子 ST 从分散的 launcher/worker 脚本集合，演进为声明式测试平台：

• 用例层聚焦测试意图；
• Backend 层隔离平台差异；
• Suite/Runner 层承担混合 mesh 和设备资源调度；
• Entry 层保证单卡参考与多卡执行的对称语义；
• Reporter 层统一多 rank 结果和失败诊断。

该架构以更多框架代码换取跨平台复用、自动调度、通信恢复和可量化的执行效率。ADR 明确了这一选择的
适用边界：HyperParallel 当前复杂的混合 mesh 和门禁场景需要自定义调度；对于单一 mesh、无设备并发
需求的新项目，应优先评估更轻量的 pytest fixture 方案。