动机（Motivation）

Multicore 已进入 MegaMoE 托管接口与 native 编译可交付阶段，但实现、Platform 适配、symmetric memory、资料、测试和构建职责仍分散在多个目录。继续保留双框架分发与公共单边通信接口，会让后续 A5 适配同时承担无效的 MindSpore/Platform 兼容债务。

本 ISSUE 继承 #333 已建立的 native 源码可重建、统一 payload 和显式激活基线，并重新限定 Multicore 自身的产品边界。

目标设计

• Multicore 只支持 Torch，业务实现唯一位于 hyper_parallel/core/multicore/。
• 删除 Multicore 的 HyperParallel Platform handler、Torch/MindSpore Platform adapter，以及全部 MindSpore 实现、资料和用例。
• symmetric_memory 整体迁入 core/multicore/shmem/，成为 Multicore 私有组件；不提供独立开关或公共 API。
• HyperParallel 根包不导出任何 Multicore 接口；独立组件提供 from hyper_parallel.core.multicore import MegaMoeExperts。
• 根 build.sh 只解析公共开关、调用业务编译脚本、合并本轮成功产物并生成完整 wheel。Multicore、SHMEM、indexed helper 和 custom ops 各自维护业务编译入口。
• Multicore 对外开关收敛为 --multicore on|off；SHMEM 随 Multicore 一起编译和交付。
• UT 在 tests/ut/core/multicore/ 镜像业务目录；Multicore ST 只存在于 tests/torch/multicore/。
• 主 README 只保留 Multicore 跳转链接，其余资料和样例内聚到 Multicore 目录。

设计边界与兼容性

这是有意的不兼容清理，不保留旧 Platform handler、MindSpore 实现、core.symmetric_memory 路径、根包导出或兼容别名。CANN SDK 自身的 platform_ascendc/opdev/platform.h 以及 benchmark 中独立 Common-MoE Torch 对照不属于 HyperParallel Platform 分发层。

正常 wheel 使用预编译 native payload；indexed helper 在源码/PYTHONPATH/editable 场景缺少扩展时可按既有 Makefile JIT。Multicore vendor/OPP 仍显式预编译并在导入 Torch 前激活。A5 不在本次范围。

验证要求

• 根构建入口、Multicore/私有 SHMEM、indexed 和 custom ops 业务入口均能独立完成各自职责。
• PYTHONPATH 与隔离 wheel 消费同一份 native payload。
• Multicore UT、Torch MegaMoE ST、Torch SHMEM 单边通信 ST 全部通过，JUnit 零失败、错误和跳过。
• 静态扫描确认生产实现无 HyperParallel Platform 或 MindSpore import，旧路径、旧开关和根导出均不存在。
• CODEOWNERS 为 Multicore 代码及 UT/ST 增加 @david_he91、@probiotics_53，编译打包路径维护人不变。

相关 RFC 和 API

• #333：native 可重建、payload 与 wheel 打包基线；本 ISSUE 覆盖其 Multicore/SHMEM 双框架与独立组件假设。
• #312：HyperMegaMoE 正反向融合算子基线。
• 对外新增的唯一便捷入口为 hyper_parallel.core.multicore.MegaMoeExperts；HyperParallel 根 API 不增加接口。

CC List

@david_he91 @probiotics_53