D2D

towncharlie[Feature] 推理大EP场景下支持DP域缩容运行

8fb640a4创建于 29 天前历史提交

文件	最后提交记录	最后更新时间
api_client	[Feature] 推理大EP场景下支持DP域缩容运行 Co-authored-by: yilunh<hanyilun1@huawei.com> Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !964 merge scaledown into master [Feature] 推理大EP场景下支持DP域缩容运行 Created-by: yilunh Commit-by: yilunh;Jechin Merged-by: towncharlie Description: ## **1. 合入背景** MoE/EP 推理实例中部分 DP rank 因 NPU、网络或引擎故障失效时，现网主要走隔离实例后的引擎重拉起、Pod 重调度或 Scale P2D。单 rank 死亡也会扰动全部健康 Pod，恢复偏慢。 本 PR 在 **引擎 FT + external-lb + EPLB 冗余专家** 等条件满足时，由 Controller 编排 **DP 域缩容**：只移除权威故障原始 DP rank，存活 rank 重建通信域后继续服务，实际缩容可行性由引擎在 apply 后做最终可执行判断。 Fixes [#575](https://gitcode.com/Ascend/MindIE-Motor/issues/575) ## **2. 修改内容** 领域与策略： - motor/controller/fault_tolerance/dp_scale_down.py（新增） - motor/controller/fault_tolerance/serving_overlay.py（新增） - motor/controller/fault_tolerance/pod_lifecycle.py（新增） - motor/controller/fault_tolerance/strategy/dp_scale_down.py（新增） - motor/controller/fault_tolerance/strategy/fast_recovery.py - motor/controller/fault_tolerance/strategy/reconfiguration.py - motor/controller/fault_tolerance/strategy/engine_relaunch.py - motor/controller/fault_tolerance/strategy/strategy.py - motor/controller/fault_tolerance/fault_manager.py - motor/controller/fault_tolerance/fault_types.py - motor/controller/fault_tolerance/mixin/persistence.py 控制面衔接： - motor/controller/core/instance_manager.py - motor/controller/core/event_pusher.py - motor/controller/core/instance_assembler.py - motor/controller/api_server/controller_api.py - motor/controller/api_client/node_manager_api_client.py - motor/controller/controller.py NodeManager： - motor/node_manager/api_server/node_manager_api.py - motor/node_manager/core/engine_ft_manager.py（新增） - motor/node_manager/core/fault_reporter.py - motor/node_manager/core/heartbeat_manager.py - motor/node_manager/core/register_manager.py - motor/node_manager/core/daemon.py 公共与配置： - motor/common/http/engine_ft_client.py - motor/common/resources/instance.py - motor/common/resources/http_msg_spec.py - motor/common/constants.py - motor/config/controller.py - motor/config/node_manager.py - examples/features/config_sample.json - docs/zh/user_guide/configuration/config_reference.md - .agents/skills/motor-dev/references/controller.md - .agents/skills/motor-dev/references/nodeman.md **FaultManager**：当前仅占位，is_applicable() 为 false 时，有 DEAD 或可映射硬件候选则进 DpScaleDownStrategy；仅 UNHEALTHY 且无权威候选时不猜 rank、不启动 30 秒 apply-ready 计时器，等待后续 DEAD / 硬件候选或故障清除事件；其他不能缩容的故障走原 fallback。硬件 L4–L6 可映射时推迟 separate_instance。失败绑定进入缩容前的 fallback_strategy，不重复本轮缩容。抢占时同时等 is_finished() 与执行器 Future。 异步策略完成时，FaultManager 先结算完成结果并清理上一轮软件故障，再构建下一轮恢复计划，避免残留 survivor UNHEALTHY 把已提交的 SCALED_DOWN_RUNNING 覆盖回 WAITING_ENGINE_FAULT。 **DpScaleDownStrategy**：门禁 → 按完整 NM 拓扑分组 → guard(request_id, lease) → 等到 survivor UNHEALTHY 且无 ft_state（引擎 id 必须等于全局 DP rank）→ ServingOverlay.withdraw → 一次 scale_down apply → 轮询至全部 HEALTHY → finalize(commit) → 可选 stop_recyclable_pods → publish。finally 未 commit 则 finalize(abort)；NM 拒绝 stale request_id。 **ServingOverlay / EventPusher / InstanceManager**：权威拓扑不变；Coordinator 只看到过滤后的 endpoint。缩容事务中抑制 partial-loss shutdown；SCALED_DOWN_RUNNING 心跳允许且仅允许 dead_committed 缺失。 **FtRuntimeStore**：进程内原子状态；etcd 开启时只持久 phase/original_dp_ranks/dead_committed/fallback_strategy。中断事务恢复为 RECONFIGURING，不重放 apply。连续缩容由累计 dead_committed 表达，不设置人工轮数上限；旧快照中的 generation 被忽略。实例删除时同步删除对应 runtime；同 Job 的最新替代实例 Ready 后清理旧 instance id 的 runtime，删除结果同步持久化。 **NodeManager**：enable_dp_scale_down_proxy 由 Controller 的 enable_fault_tolerance && enable_dp_scale_down 派生，客户不单独配。四条 FT 路由；guard/finalize 带事务 id。commit 后 retired ranks 从心跳、EngineFtManager 轮询和进程死亡上报中过滤。EngineFtManager 仅在引擎 readiness 成功后启动，运行期首次 status 请求失败即上报 DEAD；遗留 max_poll_failures 当前不参与判定。 **FtGate**：校验引擎 FT、external-lb、scale_down_supported、auto recovery 冲突、enable_eplb 与 eplb_config.num_redundant_experts > 0。不再校验 additional_config.enable_fused_mc2，也不引入私有「可删 DP 预算」；apply 后由引擎对算子兼容性和真实专家槽位做最终判断。 **查询**：GET /controller/fault_tolerance/status；开关关闭返回 DISABLED。接口只返回当前生命周期内的 runtime：活动重配置状态保持可观察，已删除或已被 Ready 新实例替代的旧实例状态不再残留。 ## **3. 资料变更** - 更新 examples/features/config_sample.json 与配置参考，说明缩容/扩容控制项统一位于 Controller 的 fault_tolerance_config。 - 更新 Controller、NodeManager 开发参考，记录 FT runtime、服务视图投影、NM proxy、guard/finalize、retired endpoint 过滤及测试入口。 - RFC 补充状态机、事务一致性窗口、失败语义、REST 状态示例和 E2E 验收矩阵。 ## **4. 接口变更** 新增客户面可见配置开关 json "fault_tolerance_config": { "enable_fault_tolerance": true, "enable_dp_scale_down": false, "enable_dp_scale_up": false, "dp_scale_down_config": { "request_timeout_sec": 5.0, "poll_interval_sec": 1.0, "execution_deadline_sec": 30.0 } } NodeManager 的代理开关由上述两项派生，不必在 NM 配置里再写一份。 enable_dp_scale_up 是暂定内部名称。本 PR 中它只控制“缩容成功后是否允许 stop 已收空 Pod、交给集群补充资源”，不代表 Motor 已实现 DP rank 扩容事务。 | 类型 | 变化 | 开关关闭时行为 | |---|---|---| | Controller REST | 新增 GET /controller/fault_tolerance/status[?instance_id=] | 返回 phase=DISABLED，不进入缩容编排 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/status | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/apply | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/guard | proxy 未派生启用时返回 404，不冻结 suicide | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/finalize | proxy 未派生启用时返回 404，不维护 retired endpoint | | NodeManager 注册 | 注册信息携带 ft_capability，包括引擎是否支持 scale_down 及静态门禁能力 | 不驱动缩容逻辑 | | 实例组装 | 同一实例各 Pod 的 FT capability 必须一致；缺失或不一致时失败封闭 | 不影响未开启缩容的既有服务路径 | | 内部配置 | enable_dp_scale_down_proxy = enable_fault_tolerance && enable_dp_scale_down | 客户无需单独配置；结果为 false | ## **5. 测试结果** Kill worker_dp1  Curl四个dp的status，由healthy变unhealthy  dp3同步hccl状态后也变成unhealthy，检测到dead+unhealthy之后触发dp缩容，NM下发apply：  缩容结束，健康rank的status状态变为healthy，   推理恢复正常  精度正常  缩容状态查询，由SCALING_DOWN更新为SCALED_DOWN_RUNNING  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!964	29 天前
api_server	[Feature] 推理大EP场景下支持DP域缩容运行 Co-authored-by: yilunh<hanyilun1@huawei.com> Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !964 merge scaledown into master [Feature] 推理大EP场景下支持DP域缩容运行 Created-by: yilunh Commit-by: yilunh;Jechin Merged-by: towncharlie Description: ## **1. 合入背景** MoE/EP 推理实例中部分 DP rank 因 NPU、网络或引擎故障失效时，现网主要走隔离实例后的引擎重拉起、Pod 重调度或 Scale P2D。单 rank 死亡也会扰动全部健康 Pod，恢复偏慢。 本 PR 在 **引擎 FT + external-lb + EPLB 冗余专家** 等条件满足时，由 Controller 编排 **DP 域缩容**：只移除权威故障原始 DP rank，存活 rank 重建通信域后继续服务，实际缩容可行性由引擎在 apply 后做最终可执行判断。 Fixes [#575](https://gitcode.com/Ascend/MindIE-Motor/issues/575) ## **2. 修改内容** 领域与策略： - motor/controller/fault_tolerance/dp_scale_down.py（新增） - motor/controller/fault_tolerance/serving_overlay.py（新增） - motor/controller/fault_tolerance/pod_lifecycle.py（新增） - motor/controller/fault_tolerance/strategy/dp_scale_down.py（新增） - motor/controller/fault_tolerance/strategy/fast_recovery.py - motor/controller/fault_tolerance/strategy/reconfiguration.py - motor/controller/fault_tolerance/strategy/engine_relaunch.py - motor/controller/fault_tolerance/strategy/strategy.py - motor/controller/fault_tolerance/fault_manager.py - motor/controller/fault_tolerance/fault_types.py - motor/controller/fault_tolerance/mixin/persistence.py 控制面衔接： - motor/controller/core/instance_manager.py - motor/controller/core/event_pusher.py - motor/controller/core/instance_assembler.py - motor/controller/api_server/controller_api.py - motor/controller/api_client/node_manager_api_client.py - motor/controller/controller.py NodeManager： - motor/node_manager/api_server/node_manager_api.py - motor/node_manager/core/engine_ft_manager.py（新增） - motor/node_manager/core/fault_reporter.py - motor/node_manager/core/heartbeat_manager.py - motor/node_manager/core/register_manager.py - motor/node_manager/core/daemon.py 公共与配置： - motor/common/http/engine_ft_client.py - motor/common/resources/instance.py - motor/common/resources/http_msg_spec.py - motor/common/constants.py - motor/config/controller.py - motor/config/node_manager.py - examples/features/config_sample.json - docs/zh/user_guide/configuration/config_reference.md - .agents/skills/motor-dev/references/controller.md - .agents/skills/motor-dev/references/nodeman.md **FaultManager**：当前仅占位，is_applicable() 为 false 时，有 DEAD 或可映射硬件候选则进 DpScaleDownStrategy；仅 UNHEALTHY 且无权威候选时不猜 rank、不启动 30 秒 apply-ready 计时器，等待后续 DEAD / 硬件候选或故障清除事件；其他不能缩容的故障走原 fallback。硬件 L4–L6 可映射时推迟 separate_instance。失败绑定进入缩容前的 fallback_strategy，不重复本轮缩容。抢占时同时等 is_finished() 与执行器 Future。 异步策略完成时，FaultManager 先结算完成结果并清理上一轮软件故障，再构建下一轮恢复计划，避免残留 survivor UNHEALTHY 把已提交的 SCALED_DOWN_RUNNING 覆盖回 WAITING_ENGINE_FAULT。 **DpScaleDownStrategy**：门禁 → 按完整 NM 拓扑分组 → guard(request_id, lease) → 等到 survivor UNHEALTHY 且无 ft_state（引擎 id 必须等于全局 DP rank）→ ServingOverlay.withdraw → 一次 scale_down apply → 轮询至全部 HEALTHY → finalize(commit) → 可选 stop_recyclable_pods → publish。finally 未 commit 则 finalize(abort)；NM 拒绝 stale request_id。 **ServingOverlay / EventPusher / InstanceManager**：权威拓扑不变；Coordinator 只看到过滤后的 endpoint。缩容事务中抑制 partial-loss shutdown；SCALED_DOWN_RUNNING 心跳允许且仅允许 dead_committed 缺失。 **FtRuntimeStore**：进程内原子状态；etcd 开启时只持久 phase/original_dp_ranks/dead_committed/fallback_strategy。中断事务恢复为 RECONFIGURING，不重放 apply。连续缩容由累计 dead_committed 表达，不设置人工轮数上限；旧快照中的 generation 被忽略。实例删除时同步删除对应 runtime；同 Job 的最新替代实例 Ready 后清理旧 instance id 的 runtime，删除结果同步持久化。 **NodeManager**：enable_dp_scale_down_proxy 由 Controller 的 enable_fault_tolerance && enable_dp_scale_down 派生，客户不单独配。四条 FT 路由；guard/finalize 带事务 id。commit 后 retired ranks 从心跳、EngineFtManager 轮询和进程死亡上报中过滤。EngineFtManager 仅在引擎 readiness 成功后启动，运行期首次 status 请求失败即上报 DEAD；遗留 max_poll_failures 当前不参与判定。 **FtGate**：校验引擎 FT、external-lb、scale_down_supported、auto recovery 冲突、enable_eplb 与 eplb_config.num_redundant_experts > 0。不再校验 additional_config.enable_fused_mc2，也不引入私有「可删 DP 预算」；apply 后由引擎对算子兼容性和真实专家槽位做最终判断。 **查询**：GET /controller/fault_tolerance/status；开关关闭返回 DISABLED。接口只返回当前生命周期内的 runtime：活动重配置状态保持可观察，已删除或已被 Ready 新实例替代的旧实例状态不再残留。 ## **3. 资料变更** - 更新 examples/features/config_sample.json 与配置参考，说明缩容/扩容控制项统一位于 Controller 的 fault_tolerance_config。 - 更新 Controller、NodeManager 开发参考，记录 FT runtime、服务视图投影、NM proxy、guard/finalize、retired endpoint 过滤及测试入口。 - RFC 补充状态机、事务一致性窗口、失败语义、REST 状态示例和 E2E 验收矩阵。 ## **4. 接口变更** 新增客户面可见配置开关 json "fault_tolerance_config": { "enable_fault_tolerance": true, "enable_dp_scale_down": false, "enable_dp_scale_up": false, "dp_scale_down_config": { "request_timeout_sec": 5.0, "poll_interval_sec": 1.0, "execution_deadline_sec": 30.0 } } NodeManager 的代理开关由上述两项派生，不必在 NM 配置里再写一份。 enable_dp_scale_up 是暂定内部名称。本 PR 中它只控制“缩容成功后是否允许 stop 已收空 Pod、交给集群补充资源”，不代表 Motor 已实现 DP rank 扩容事务。 | 类型 | 变化 | 开关关闭时行为 | |---|---|---| | Controller REST | 新增 GET /controller/fault_tolerance/status[?instance_id=] | 返回 phase=DISABLED，不进入缩容编排 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/status | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/apply | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/guard | proxy 未派生启用时返回 404，不冻结 suicide | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/finalize | proxy 未派生启用时返回 404，不维护 retired endpoint | | NodeManager 注册 | 注册信息携带 ft_capability，包括引擎是否支持 scale_down 及静态门禁能力 | 不驱动缩容逻辑 | | 实例组装 | 同一实例各 Pod 的 FT capability 必须一致；缺失或不一致时失败封闭 | 不影响未开启缩容的既有服务路径 | | 内部配置 | enable_dp_scale_down_proxy = enable_fault_tolerance && enable_dp_scale_down | 客户无需单独配置；结果为 false | ## **5. 测试结果** Kill worker_dp1  Curl四个dp的status，由healthy变unhealthy  dp3同步hccl状态后也变成unhealthy，检测到dead+unhealthy之后触发dp缩容，NM下发apply：  缩容结束，健康rank的status状态变为healthy，   推理恢复正常  精度正常  缩容状态查询，由SCALING_DOWN更新为SCALED_DOWN_RUNNING  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!964	29 天前
core	[Feature] 推理大EP场景下支持DP域缩容运行 Co-authored-by: yilunh<hanyilun1@huawei.com> Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !964 merge scaledown into master [Feature] 推理大EP场景下支持DP域缩容运行 Created-by: yilunh Commit-by: yilunh;Jechin Merged-by: towncharlie Description: ## **1. 合入背景** MoE/EP 推理实例中部分 DP rank 因 NPU、网络或引擎故障失效时，现网主要走隔离实例后的引擎重拉起、Pod 重调度或 Scale P2D。单 rank 死亡也会扰动全部健康 Pod，恢复偏慢。 本 PR 在 **引擎 FT + external-lb + EPLB 冗余专家** 等条件满足时，由 Controller 编排 **DP 域缩容**：只移除权威故障原始 DP rank，存活 rank 重建通信域后继续服务，实际缩容可行性由引擎在 apply 后做最终可执行判断。 Fixes [#575](https://gitcode.com/Ascend/MindIE-Motor/issues/575) ## **2. 修改内容** 领域与策略： - motor/controller/fault_tolerance/dp_scale_down.py（新增） - motor/controller/fault_tolerance/serving_overlay.py（新增） - motor/controller/fault_tolerance/pod_lifecycle.py（新增） - motor/controller/fault_tolerance/strategy/dp_scale_down.py（新增） - motor/controller/fault_tolerance/strategy/fast_recovery.py - motor/controller/fault_tolerance/strategy/reconfiguration.py - motor/controller/fault_tolerance/strategy/engine_relaunch.py - motor/controller/fault_tolerance/strategy/strategy.py - motor/controller/fault_tolerance/fault_manager.py - motor/controller/fault_tolerance/fault_types.py - motor/controller/fault_tolerance/mixin/persistence.py 控制面衔接： - motor/controller/core/instance_manager.py - motor/controller/core/event_pusher.py - motor/controller/core/instance_assembler.py - motor/controller/api_server/controller_api.py - motor/controller/api_client/node_manager_api_client.py - motor/controller/controller.py NodeManager： - motor/node_manager/api_server/node_manager_api.py - motor/node_manager/core/engine_ft_manager.py（新增） - motor/node_manager/core/fault_reporter.py - motor/node_manager/core/heartbeat_manager.py - motor/node_manager/core/register_manager.py - motor/node_manager/core/daemon.py 公共与配置： - motor/common/http/engine_ft_client.py - motor/common/resources/instance.py - motor/common/resources/http_msg_spec.py - motor/common/constants.py - motor/config/controller.py - motor/config/node_manager.py - examples/features/config_sample.json - docs/zh/user_guide/configuration/config_reference.md - .agents/skills/motor-dev/references/controller.md - .agents/skills/motor-dev/references/nodeman.md **FaultManager**：当前仅占位，is_applicable() 为 false 时，有 DEAD 或可映射硬件候选则进 DpScaleDownStrategy；仅 UNHEALTHY 且无权威候选时不猜 rank、不启动 30 秒 apply-ready 计时器，等待后续 DEAD / 硬件候选或故障清除事件；其他不能缩容的故障走原 fallback。硬件 L4–L6 可映射时推迟 separate_instance。失败绑定进入缩容前的 fallback_strategy，不重复本轮缩容。抢占时同时等 is_finished() 与执行器 Future。 异步策略完成时，FaultManager 先结算完成结果并清理上一轮软件故障，再构建下一轮恢复计划，避免残留 survivor UNHEALTHY 把已提交的 SCALED_DOWN_RUNNING 覆盖回 WAITING_ENGINE_FAULT。 **DpScaleDownStrategy**：门禁 → 按完整 NM 拓扑分组 → guard(request_id, lease) → 等到 survivor UNHEALTHY 且无 ft_state（引擎 id 必须等于全局 DP rank）→ ServingOverlay.withdraw → 一次 scale_down apply → 轮询至全部 HEALTHY → finalize(commit) → 可选 stop_recyclable_pods → publish。finally 未 commit 则 finalize(abort)；NM 拒绝 stale request_id。 **ServingOverlay / EventPusher / InstanceManager**：权威拓扑不变；Coordinator 只看到过滤后的 endpoint。缩容事务中抑制 partial-loss shutdown；SCALED_DOWN_RUNNING 心跳允许且仅允许 dead_committed 缺失。 **FtRuntimeStore**：进程内原子状态；etcd 开启时只持久 phase/original_dp_ranks/dead_committed/fallback_strategy。中断事务恢复为 RECONFIGURING，不重放 apply。连续缩容由累计 dead_committed 表达，不设置人工轮数上限；旧快照中的 generation 被忽略。实例删除时同步删除对应 runtime；同 Job 的最新替代实例 Ready 后清理旧 instance id 的 runtime，删除结果同步持久化。 **NodeManager**：enable_dp_scale_down_proxy 由 Controller 的 enable_fault_tolerance && enable_dp_scale_down 派生，客户不单独配。四条 FT 路由；guard/finalize 带事务 id。commit 后 retired ranks 从心跳、EngineFtManager 轮询和进程死亡上报中过滤。EngineFtManager 仅在引擎 readiness 成功后启动，运行期首次 status 请求失败即上报 DEAD；遗留 max_poll_failures 当前不参与判定。 **FtGate**：校验引擎 FT、external-lb、scale_down_supported、auto recovery 冲突、enable_eplb 与 eplb_config.num_redundant_experts > 0。不再校验 additional_config.enable_fused_mc2，也不引入私有「可删 DP 预算」；apply 后由引擎对算子兼容性和真实专家槽位做最终判断。 **查询**：GET /controller/fault_tolerance/status；开关关闭返回 DISABLED。接口只返回当前生命周期内的 runtime：活动重配置状态保持可观察，已删除或已被 Ready 新实例替代的旧实例状态不再残留。 ## **3. 资料变更** - 更新 examples/features/config_sample.json 与配置参考，说明缩容/扩容控制项统一位于 Controller 的 fault_tolerance_config。 - 更新 Controller、NodeManager 开发参考，记录 FT runtime、服务视图投影、NM proxy、guard/finalize、retired endpoint 过滤及测试入口。 - RFC 补充状态机、事务一致性窗口、失败语义、REST 状态示例和 E2E 验收矩阵。 ## **4. 接口变更** 新增客户面可见配置开关 json "fault_tolerance_config": { "enable_fault_tolerance": true, "enable_dp_scale_down": false, "enable_dp_scale_up": false, "dp_scale_down_config": { "request_timeout_sec": 5.0, "poll_interval_sec": 1.0, "execution_deadline_sec": 30.0 } } NodeManager 的代理开关由上述两项派生，不必在 NM 配置里再写一份。 enable_dp_scale_up 是暂定内部名称。本 PR 中它只控制“缩容成功后是否允许 stop 已收空 Pod、交给集群补充资源”，不代表 Motor 已实现 DP rank 扩容事务。 | 类型 | 变化 | 开关关闭时行为 | |---|---|---| | Controller REST | 新增 GET /controller/fault_tolerance/status[?instance_id=] | 返回 phase=DISABLED，不进入缩容编排 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/status | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/apply | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/guard | proxy 未派生启用时返回 404，不冻结 suicide | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/finalize | proxy 未派生启用时返回 404，不维护 retired endpoint | | NodeManager 注册 | 注册信息携带 ft_capability，包括引擎是否支持 scale_down 及静态门禁能力 | 不驱动缩容逻辑 | | 实例组装 | 同一实例各 Pod 的 FT capability 必须一致；缺失或不一致时失败封闭 | 不影响未开启缩容的既有服务路径 | | 内部配置 | enable_dp_scale_down_proxy = enable_fault_tolerance && enable_dp_scale_down | 客户无需单独配置；结果为 false | ## **5. 测试结果** Kill worker_dp1  Curl四个dp的status，由healthy变unhealthy  dp3同步hccl状态后也变成unhealthy，检测到dead+unhealthy之后触发dp缩容，NM下发apply：  缩容结束，健康rank的status状态变为healthy，   推理恢复正常  精度正常  缩容状态查询，由SCALING_DOWN更新为SCALED_DOWN_RUNNING  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!964	29 天前
fault_tolerance	[Feature] 推理大EP场景下支持DP域缩容运行 Co-authored-by: yilunh<hanyilun1@huawei.com> Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !964 merge scaledown into master [Feature] 推理大EP场景下支持DP域缩容运行 Created-by: yilunh Commit-by: yilunh;Jechin Merged-by: towncharlie Description: ## **1. 合入背景** MoE/EP 推理实例中部分 DP rank 因 NPU、网络或引擎故障失效时，现网主要走隔离实例后的引擎重拉起、Pod 重调度或 Scale P2D。单 rank 死亡也会扰动全部健康 Pod，恢复偏慢。 本 PR 在 **引擎 FT + external-lb + EPLB 冗余专家** 等条件满足时，由 Controller 编排 **DP 域缩容**：只移除权威故障原始 DP rank，存活 rank 重建通信域后继续服务，实际缩容可行性由引擎在 apply 后做最终可执行判断。 Fixes [#575](https://gitcode.com/Ascend/MindIE-Motor/issues/575) ## **2. 修改内容** 领域与策略： - motor/controller/fault_tolerance/dp_scale_down.py（新增） - motor/controller/fault_tolerance/serving_overlay.py（新增） - motor/controller/fault_tolerance/pod_lifecycle.py（新增） - motor/controller/fault_tolerance/strategy/dp_scale_down.py（新增） - motor/controller/fault_tolerance/strategy/fast_recovery.py - motor/controller/fault_tolerance/strategy/reconfiguration.py - motor/controller/fault_tolerance/strategy/engine_relaunch.py - motor/controller/fault_tolerance/strategy/strategy.py - motor/controller/fault_tolerance/fault_manager.py - motor/controller/fault_tolerance/fault_types.py - motor/controller/fault_tolerance/mixin/persistence.py 控制面衔接： - motor/controller/core/instance_manager.py - motor/controller/core/event_pusher.py - motor/controller/core/instance_assembler.py - motor/controller/api_server/controller_api.py - motor/controller/api_client/node_manager_api_client.py - motor/controller/controller.py NodeManager： - motor/node_manager/api_server/node_manager_api.py - motor/node_manager/core/engine_ft_manager.py（新增） - motor/node_manager/core/fault_reporter.py - motor/node_manager/core/heartbeat_manager.py - motor/node_manager/core/register_manager.py - motor/node_manager/core/daemon.py 公共与配置： - motor/common/http/engine_ft_client.py - motor/common/resources/instance.py - motor/common/resources/http_msg_spec.py - motor/common/constants.py - motor/config/controller.py - motor/config/node_manager.py - examples/features/config_sample.json - docs/zh/user_guide/configuration/config_reference.md - .agents/skills/motor-dev/references/controller.md - .agents/skills/motor-dev/references/nodeman.md **FaultManager**：当前仅占位，is_applicable() 为 false 时，有 DEAD 或可映射硬件候选则进 DpScaleDownStrategy；仅 UNHEALTHY 且无权威候选时不猜 rank、不启动 30 秒 apply-ready 计时器，等待后续 DEAD / 硬件候选或故障清除事件；其他不能缩容的故障走原 fallback。硬件 L4–L6 可映射时推迟 separate_instance。失败绑定进入缩容前的 fallback_strategy，不重复本轮缩容。抢占时同时等 is_finished() 与执行器 Future。 异步策略完成时，FaultManager 先结算完成结果并清理上一轮软件故障，再构建下一轮恢复计划，避免残留 survivor UNHEALTHY 把已提交的 SCALED_DOWN_RUNNING 覆盖回 WAITING_ENGINE_FAULT。 **DpScaleDownStrategy**：门禁 → 按完整 NM 拓扑分组 → guard(request_id, lease) → 等到 survivor UNHEALTHY 且无 ft_state（引擎 id 必须等于全局 DP rank）→ ServingOverlay.withdraw → 一次 scale_down apply → 轮询至全部 HEALTHY → finalize(commit) → 可选 stop_recyclable_pods → publish。finally 未 commit 则 finalize(abort)；NM 拒绝 stale request_id。 **ServingOverlay / EventPusher / InstanceManager**：权威拓扑不变；Coordinator 只看到过滤后的 endpoint。缩容事务中抑制 partial-loss shutdown；SCALED_DOWN_RUNNING 心跳允许且仅允许 dead_committed 缺失。 **FtRuntimeStore**：进程内原子状态；etcd 开启时只持久 phase/original_dp_ranks/dead_committed/fallback_strategy。中断事务恢复为 RECONFIGURING，不重放 apply。连续缩容由累计 dead_committed 表达，不设置人工轮数上限；旧快照中的 generation 被忽略。实例删除时同步删除对应 runtime；同 Job 的最新替代实例 Ready 后清理旧 instance id 的 runtime，删除结果同步持久化。 **NodeManager**：enable_dp_scale_down_proxy 由 Controller 的 enable_fault_tolerance && enable_dp_scale_down 派生，客户不单独配。四条 FT 路由；guard/finalize 带事务 id。commit 后 retired ranks 从心跳、EngineFtManager 轮询和进程死亡上报中过滤。EngineFtManager 仅在引擎 readiness 成功后启动，运行期首次 status 请求失败即上报 DEAD；遗留 max_poll_failures 当前不参与判定。 **FtGate**：校验引擎 FT、external-lb、scale_down_supported、auto recovery 冲突、enable_eplb 与 eplb_config.num_redundant_experts > 0。不再校验 additional_config.enable_fused_mc2，也不引入私有「可删 DP 预算」；apply 后由引擎对算子兼容性和真实专家槽位做最终判断。 **查询**：GET /controller/fault_tolerance/status；开关关闭返回 DISABLED。接口只返回当前生命周期内的 runtime：活动重配置状态保持可观察，已删除或已被 Ready 新实例替代的旧实例状态不再残留。 ## **3. 资料变更** - 更新 examples/features/config_sample.json 与配置参考，说明缩容/扩容控制项统一位于 Controller 的 fault_tolerance_config。 - 更新 Controller、NodeManager 开发参考，记录 FT runtime、服务视图投影、NM proxy、guard/finalize、retired endpoint 过滤及测试入口。 - RFC 补充状态机、事务一致性窗口、失败语义、REST 状态示例和 E2E 验收矩阵。 ## **4. 接口变更** 新增客户面可见配置开关 json "fault_tolerance_config": { "enable_fault_tolerance": true, "enable_dp_scale_down": false, "enable_dp_scale_up": false, "dp_scale_down_config": { "request_timeout_sec": 5.0, "poll_interval_sec": 1.0, "execution_deadline_sec": 30.0 } } NodeManager 的代理开关由上述两项派生，不必在 NM 配置里再写一份。 enable_dp_scale_up 是暂定内部名称。本 PR 中它只控制“缩容成功后是否允许 stop 已收空 Pod、交给集群补充资源”，不代表 Motor 已实现 DP rank 扩容事务。 | 类型 | 变化 | 开关关闭时行为 | |---|---|---| | Controller REST | 新增 GET /controller/fault_tolerance/status[?instance_id=] | 返回 phase=DISABLED，不进入缩容编排 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/status | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/apply | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/guard | proxy 未派生启用时返回 404，不冻结 suicide | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/finalize | proxy 未派生启用时返回 404，不维护 retired endpoint | | NodeManager 注册 | 注册信息携带 ft_capability，包括引擎是否支持 scale_down 及静态门禁能力 | 不驱动缩容逻辑 | | 实例组装 | 同一实例各 Pod 的 FT capability 必须一致；缺失或不一致时失败封闭 | 不影响未开启缩容的既有服务路径 | | 内部配置 | enable_dp_scale_down_proxy = enable_fault_tolerance && enable_dp_scale_down | 客户无需单独配置；结果为 false | ## **5. 测试结果** Kill worker_dp1  Curl四个dp的status，由healthy变unhealthy  dp3同步hccl状态后也变成unhealthy，检测到dead+unhealthy之后触发dp缩容，NM下发apply：  缩容结束，健康rank的status状态变为healthy，   推理恢复正常  精度正常  缩容状态查询，由SCALING_DOWN更新为SCALED_DOWN_RUNNING  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!964	29 天前
observability	[feature]增加告警清除逻辑 Co-authored-by: hxy<huxinyi9@huawei.com> # message auto-generated for no-merge-commit merge: !598 merge feat/hybrid-precision-detection into master [feature]增加告警清除逻辑 Created-by: hu-xinyi_555 Commit-by: hxy Merged-by: towncharlie Description: ## **1. 合入背景** 可见https://gitcode.com/Ascend/MindIE-Motor/issues/359 精度检测特性（前序合入 61b0475 [feature]支持混布场景的精度异常检测）已具备 **告警产生** 与 **auto-recovery 实例终止** 能力，但缺少完整的 **告警清除（CLEAR）闭环**： - auto-recovery 终止 P/D 实例后，OM 侧精度告警仍可能残留； - CCAE 手动下发 precision control 终止实例后，未同步清除对应 PD Group 告警； - 未开启 auto-recovery 时，实例恢复后无法通过连续正常检测自动清除活动告警； - Coordinator Scheduler 侧 alarm_active 状态无统一清理入口，影响后续同 PD Group 重复告警。 ## **2. 修改内容** 详细设计见：[docs/zh/design/fault_tolerance/precision_detection.md](../../pymotor/MindIE-PyMotor_8989/docs/zh/design/fault_tolerance/precision_detection.md)（告警清除章节） ### 2.1 三条清除路径 | 路径 | 触发方 | 行为 | |------|--------|------| | **auto-recovery 清除** | Controller | 精度 ALARM 触发终止 P/D 全部成功后，上报 CLEAR 至 OM，并通知 Coordinator 清理 Scheduler 活动状态 | | **CCAE 手动清除** | CCAE Reporter → Controller | 终止 P/D 时携带 precision_alarm_clear=true，复用统一恢复入口清除 OM 告警 + 通知 Coordinator | | **连续正常清除** | Coordinator | 活动告警下连续 precision_clear_threshold（默认 10）次有效正常检测后，上报 CLEAR | ### 2.2 组件交互（实现要点） 1. **Controller recovery_service.py（新增统一入口）** - complete_precision_pd_group_recovery()：可选终止 P/D → 从 AlarmStore 查找活动精度告警 → 深拷贝原 Alarm 并 clear() 上报 OM → 调用 CoordinatorApiClient.notify_precision_alarm_cleared() 清理 Scheduler 状态 - terminate_pd_group() / is_precision_raise_alarm() 等辅助函数供 API 层复用 2. **Controller alarm_store.py** - 新增 _active_precision_alarms 索引与 find_active_precision_alarm(p_id, d_id)，按 PD Group 追踪活动精度告警及其 moi 3. **Controller controller_api.py** - 精度 auto-recovery 成功后走 complete_precision_pd_group_recovery，响应携带 precision_alarm_cleared / precision_alarm_cleared_by_auto_recovery - POST /controller/terminate_instance 支持 precision_alarm_clear=true，CCAE 手动清除走同一恢复入口 4. **Coordinator Scheduler（scheduler.py + runtime）** - 新增 alarm_active、clear_probing、clear_tokens 等 per-PD-Group 状态 - record_precision_result() 在活动告警下累计连续正常样本，达 clear_threshold 触发 clear action - finish_precision_action(action_type=clear|raise) 提交 action 结果；auto-recovery 已清除时直接删除整组状态 - 新增 ZMQ 协议与 client/server 透传 finish_precision_action / record_precision_result(clear_threshold=...) 5. **Coordinator PrecisionReporter + PrecisionAlarm** - Reporter 支持 raise / clear 双 action 编排，clear_threshold_hit 时异步触发 CLEAR 上报 - PrecisionAlarm.execute(action=clear) 构造 build_precision_issue_clear_alarm() 并上报 Controller；CLEAR 必须使用与产生告警相同的 moi 6. **Coordinator Management API（新增）** - POST /precision/alarm_cleared：Controller 通知 Coordinator 删除 Scheduler 活动告警状态（Mgmt 进程 → Scheduler） 7. **CCAE Reporter + MotorBackend** - precision control 终止成功后调用带 precision_alarm_clear=true 的 group terminate - 新增 precision task 上报窗口与 controlCode 抑制逻辑 8. **公共层** - 新增 motor/common/alarm/deserialize.py：告警反序列化 - precision_issue_alarm.py：新增 build_precision_issue_clear_alarm() - coordinator.py：新增 precision_clear_threshold 配置项 ### 2.3 时序（auto-recovery 清除） mermaid sequenceDiagram participant CR as Coordinator PrecisionAlarm participant CT as Controller participant OM as OM/CCAE participant SCH as Coordinator Scheduler CR->>CT: POST report_alarms (ALARM) CT->>CT: terminate P/D instances CT->>OM: report ALARM + CLEAR (same moi) CT->>SCH: POST /precision/alarm_cleared SCH->>SCH: clear alarm_active state CT-->>CR: precision_alarm_cleared_by_auto_recovery=true --- ## **3. 资料变更** **涉及**，修改如下： | 文件 | 变更说明 | |------|----------| | docs/zh/design/fault_tolerance/precision_detection.md | 补充告警清除设计：三条清除路径、moi 一致性约束、Scheduler 状态清理、CCAE 手动清除时序 | | docs/zh/user_guide/features/precision_detection.md | 补充 precision_clear_threshold 配置说明 | | docs/zh/user_guide/api/observability_interface.md | 补充 CCAE precision control 调用 /controller/terminate_instance 时 precision_alarm_clear 字段说明 | --- ## **4. 接口变更** **涉及**，均为客户面/跨组件可见接口： | 接口 | 变更类型 | 说明 | |------|----------|------| | POST /controller/terminate_instance | **请求体扩展** | 新增可选字段 precision_alarm_clear: bool（默认 false）。为 true 时按 PD Group 终止 P/D 并清除精度告警；响应 data 新增 precision_alarm_cleared、scheduler_state_cleared、moi | | POST /controller/report_alarms（精度 ALARM 响应） | **响应扩展** | auto-recovery 成功后 data 新增 precision_alarm_cleared、precision_alarm_cleared_by_auto_recovery、scheduler_state_cleared | | POST /precision/alarm_cleared（Coordinator Mgmt） | **新增** | Controller → Coordinator，请求体 {p_instance_id, d_instance_id}，清除 Scheduler 侧活动精度告警状态 | | Coordinator 配置 | **新增字段** | precision_detection_config.precision_clear_threshold（默认 10） | | CCAE precision control → MotorBackend | **行为变更** | 终止实例时携带 precision_alarm_clear=true | --- ## **5. 测试结果**  --- ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!598	2 个月前
__init__.py	[refractor] 删除旧FaultManager代码 ，重命名ft为fault_tolerance Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !219 merge k8s_feature_br_2 into master [refractor] 删除旧FaultManager代码 ，重命名ft为fault_tolerance Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: ascend-robot Description: ## **1. 合入背景** 该PR为需求ISSUE的前置PR之一：https://gitcode.com/Ascend/MindIE-pyMotor-private/issues/113 ## **2. 修改内容** 删除旧的FaultManager代码内容 ## **3. 资料变更** 不涉及 ## **4. 接口变更** 不涉及 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-pyMotor-private!219	8 个月前
controller.py	[Feature] 推理大EP场景下支持DP域缩容运行 Co-authored-by: yilunh<hanyilun1@huawei.com> Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !964 merge scaledown into master [Feature] 推理大EP场景下支持DP域缩容运行 Created-by: yilunh Commit-by: yilunh;Jechin Merged-by: towncharlie Description: ## **1. 合入背景** MoE/EP 推理实例中部分 DP rank 因 NPU、网络或引擎故障失效时，现网主要走隔离实例后的引擎重拉起、Pod 重调度或 Scale P2D。单 rank 死亡也会扰动全部健康 Pod，恢复偏慢。 本 PR 在 **引擎 FT + external-lb + EPLB 冗余专家** 等条件满足时，由 Controller 编排 **DP 域缩容**：只移除权威故障原始 DP rank，存活 rank 重建通信域后继续服务，实际缩容可行性由引擎在 apply 后做最终可执行判断。 Fixes [#575](https://gitcode.com/Ascend/MindIE-Motor/issues/575) ## **2. 修改内容** 领域与策略： - motor/controller/fault_tolerance/dp_scale_down.py（新增） - motor/controller/fault_tolerance/serving_overlay.py（新增） - motor/controller/fault_tolerance/pod_lifecycle.py（新增） - motor/controller/fault_tolerance/strategy/dp_scale_down.py（新增） - motor/controller/fault_tolerance/strategy/fast_recovery.py - motor/controller/fault_tolerance/strategy/reconfiguration.py - motor/controller/fault_tolerance/strategy/engine_relaunch.py - motor/controller/fault_tolerance/strategy/strategy.py - motor/controller/fault_tolerance/fault_manager.py - motor/controller/fault_tolerance/fault_types.py - motor/controller/fault_tolerance/mixin/persistence.py 控制面衔接： - motor/controller/core/instance_manager.py - motor/controller/core/event_pusher.py - motor/controller/core/instance_assembler.py - motor/controller/api_server/controller_api.py - motor/controller/api_client/node_manager_api_client.py - motor/controller/controller.py NodeManager： - motor/node_manager/api_server/node_manager_api.py - motor/node_manager/core/engine_ft_manager.py（新增） - motor/node_manager/core/fault_reporter.py - motor/node_manager/core/heartbeat_manager.py - motor/node_manager/core/register_manager.py - motor/node_manager/core/daemon.py 公共与配置： - motor/common/http/engine_ft_client.py - motor/common/resources/instance.py - motor/common/resources/http_msg_spec.py - motor/common/constants.py - motor/config/controller.py - motor/config/node_manager.py - examples/features/config_sample.json - docs/zh/user_guide/configuration/config_reference.md - .agents/skills/motor-dev/references/controller.md - .agents/skills/motor-dev/references/nodeman.md **FaultManager**：当前仅占位，is_applicable() 为 false 时，有 DEAD 或可映射硬件候选则进 DpScaleDownStrategy；仅 UNHEALTHY 且无权威候选时不猜 rank、不启动 30 秒 apply-ready 计时器，等待后续 DEAD / 硬件候选或故障清除事件；其他不能缩容的故障走原 fallback。硬件 L4–L6 可映射时推迟 separate_instance。失败绑定进入缩容前的 fallback_strategy，不重复本轮缩容。抢占时同时等 is_finished() 与执行器 Future。 异步策略完成时，FaultManager 先结算完成结果并清理上一轮软件故障，再构建下一轮恢复计划，避免残留 survivor UNHEALTHY 把已提交的 SCALED_DOWN_RUNNING 覆盖回 WAITING_ENGINE_FAULT。 **DpScaleDownStrategy**：门禁 → 按完整 NM 拓扑分组 → guard(request_id, lease) → 等到 survivor UNHEALTHY 且无 ft_state（引擎 id 必须等于全局 DP rank）→ ServingOverlay.withdraw → 一次 scale_down apply → 轮询至全部 HEALTHY → finalize(commit) → 可选 stop_recyclable_pods → publish。finally 未 commit 则 finalize(abort)；NM 拒绝 stale request_id。 **ServingOverlay / EventPusher / InstanceManager**：权威拓扑不变；Coordinator 只看到过滤后的 endpoint。缩容事务中抑制 partial-loss shutdown；SCALED_DOWN_RUNNING 心跳允许且仅允许 dead_committed 缺失。 **FtRuntimeStore**：进程内原子状态；etcd 开启时只持久 phase/original_dp_ranks/dead_committed/fallback_strategy。中断事务恢复为 RECONFIGURING，不重放 apply。连续缩容由累计 dead_committed 表达，不设置人工轮数上限；旧快照中的 generation 被忽略。实例删除时同步删除对应 runtime；同 Job 的最新替代实例 Ready 后清理旧 instance id 的 runtime，删除结果同步持久化。 **NodeManager**：enable_dp_scale_down_proxy 由 Controller 的 enable_fault_tolerance && enable_dp_scale_down 派生，客户不单独配。四条 FT 路由；guard/finalize 带事务 id。commit 后 retired ranks 从心跳、EngineFtManager 轮询和进程死亡上报中过滤。EngineFtManager 仅在引擎 readiness 成功后启动，运行期首次 status 请求失败即上报 DEAD；遗留 max_poll_failures 当前不参与判定。 **FtGate**：校验引擎 FT、external-lb、scale_down_supported、auto recovery 冲突、enable_eplb 与 eplb_config.num_redundant_experts > 0。不再校验 additional_config.enable_fused_mc2，也不引入私有「可删 DP 预算」；apply 后由引擎对算子兼容性和真实专家槽位做最终判断。 **查询**：GET /controller/fault_tolerance/status；开关关闭返回 DISABLED。接口只返回当前生命周期内的 runtime：活动重配置状态保持可观察，已删除或已被 Ready 新实例替代的旧实例状态不再残留。 ## **3. 资料变更** - 更新 examples/features/config_sample.json 与配置参考，说明缩容/扩容控制项统一位于 Controller 的 fault_tolerance_config。 - 更新 Controller、NodeManager 开发参考，记录 FT runtime、服务视图投影、NM proxy、guard/finalize、retired endpoint 过滤及测试入口。 - RFC 补充状态机、事务一致性窗口、失败语义、REST 状态示例和 E2E 验收矩阵。 ## **4. 接口变更** 新增客户面可见配置开关 json "fault_tolerance_config": { "enable_fault_tolerance": true, "enable_dp_scale_down": false, "enable_dp_scale_up": false, "dp_scale_down_config": { "request_timeout_sec": 5.0, "poll_interval_sec": 1.0, "execution_deadline_sec": 30.0 } } NodeManager 的代理开关由上述两项派生，不必在 NM 配置里再写一份。 enable_dp_scale_up 是暂定内部名称。本 PR 中它只控制“缩容成功后是否允许 stop 已收空 Pod、交给集群补充资源”，不代表 Motor 已实现 DP rank 扩容事务。 | 类型 | 变化 | 开关关闭时行为 | |---|---|---| | Controller REST | 新增 GET /controller/fault_tolerance/status[?instance_id=] | 返回 phase=DISABLED，不进入缩容编排 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/status | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/apply | proxy 未派生启用时返回 404 | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/guard | proxy 未派生启用时返回 404，不冻结 suicide | | NodeManager REST | 新增 POST /node-manager/fault-tolerance/finalize | proxy 未派生启用时返回 404，不维护 retired endpoint | | NodeManager 注册 | 注册信息携带 ft_capability，包括引擎是否支持 scale_down 及静态门禁能力 | 不驱动缩容逻辑 | | 实例组装 | 同一实例各 Pod 的 FT capability 必须一致；缺失或不一致时失败封闭 | 不影响未开启缩容的既有服务路径 | | 内部配置 | enable_dp_scale_down_proxy = enable_fault_tolerance && enable_dp_scale_down | 客户无需单独配置；结果为 false | ## **5. 测试结果** Kill worker_dp1  Curl四个dp的status，由healthy变unhealthy  dp3同步hccl状态后也变成unhealthy，检测到dead+unhealthy之后触发dp缩容，NM下发apply：  缩容结束，健康rank的status状态变为healthy，   推理恢复正常  精度正常  缩容状态查询，由SCALING_DOWN更新为SCALED_DOWN_RUNNING  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!964	29 天前
main.py	[refractor] Controller代码微重构，提升代码可维护性 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !623 merge refractor/controller into master [refractor] Controller代码微重构，提升代码可维护性 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: # Controller 重构 PR 说明 ISSUE：https://gitcode.com/Ascend/MindIE-Motor/issues/368 关联 PR：[NodeManager 重构](https://gitcode.com/Ascend/MindIE-Motor/pull/620) ## 1. 合入背景 Controller 的 main.py 将模块管理、配置更新传播、daemon loop、信号处理等逻辑全部写在模块级全局变量和函数中，与 NodeManager 的 main.py 存在大量重复代码。此前 NodeManager 已完成重构（提取 Application 基类和 NodeManager 类），本次将相同模式应用到 Controller，并同步 daemon_loop_interval 热更新能力。 ## 2. 修改内容 ### 2.1 ControllerConfig 新增 daemon_loop_interval 配置 **文件**: motor/config/controller.py 新增 ControllerConfig.daemon_loop_interval: float = 5.0，支持在 user_config.json 中配置 daemon loop 检查间隔，默认 5 秒。 ### 2.2 Controller 类同步 check_interval 能力 **文件**: motor/controller/controller.py 1. Controller.__init__ 传入 check_interval=config.daemon_loop_interval 到 Application 基类。 2. 重写 _refresh_check_interval()，配置热更新时自动同步间隔。 ### 2.3 改动文件清单 | 文件 | 改动类型 | |------|----------| | motor/config/controller.py | 新增 daemon_loop_interval 字段 | | motor/controller/controller.py | 传入 check_interval + 重写 _refresh_check_interval | ## 3. 资料变更 不涉及。 ## 4. 接口变更 不涉及。 ## 5. 测试结果  python -m pytest tests/controller/ -q 544 passed in 12.37s ## 6. CheckList - [x] 代码注释完备 - [x] 正确记录维测日志 - [x] 是否有UT用例（全量 544 passed） - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!623	2 个月前