| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 | 23 天前 | |
[Feature] 引擎重启兜底策略：容器不重启重拉引擎 + 自杀裁决收敛 Daemon Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !710 merge feature/engine_relaunch into master [Feature] 引擎重启兜底策略：容器不重启重拉引擎 + 自杀裁决收敛 Daemon Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ### 1. 合入背景 引擎进程死亡后，当前唯一兜底是「NodeManager 心跳 abnormal ×5（约 15s）→ 自杀 → k8s 重启 pod」，代价是全容器重建。本 PR 实现「容器不重启重拉引擎」：Controller 协同实例的**所有** NodeManager 一起重拉全部引擎（rank 集合通信组一致性），重拉失败再回退到容器重启；同时把自杀裁决权收敛到 Daemon（进程生命周期管理者）。 本 PR 基于最新主线：原生引擎拉起（#698：NodeManager 直接 spawn 原生 vLLM/SGLang，删除 EngineServer 层）与 EngineServer 删除收尾（#717）均已合入，重拉链路已对接原生拉起路径。 关联 ISSUE：#472 ### 2. 修改内容 1. **Controller 引擎重启兜底策略**（ motor/controller/fault_tolerance/strategy/engine_relaunch.py，两阶段）： - Phase 1 重启引擎：探活实例全部 NodeManager（任一不可达 → 直接 Phase 2，保证 rank 一致性）→ 逐个下发 POST /node-manager/engine-restart → 轮询 /node-manager/status 全部 NORMAL → 成功 - Phase 2 重启容器：仅对**未成功派发重启**的 NM 发 abort 解冻自杀（已派发 NM 保持 freeze，避免打断正在恢复的引擎）→ 心跳机制触发容器重启（k8s）；abort 发送失败补 error 日志指名 NM；实例 DELETED/消失提前结束 - stop() 被打断时 fire-and-forget 发 abort（防冻结窗口内 NM 自杀被延迟） 2. **策略失败升级机制（可复用）**：StrategyBase.mark_failed() + InstanceMetadata.prev_strategy_failed——token 重推/UCE/弹性扩缩容等「期望引擎不重启快速恢复」的策略失败后，策略中心自动降级到 EngineRelaunchStrategy（兜底链）；升级分支同样受 enable_engine_relaunch 门控 3. **level2_strategy 挂钩**：ENGINE_DEAD 软件故障直接触发 EngineRelaunchStrategy（开关关闭 → None） 4. **NodeManager 新路由** POST /node-manager/engine-restart（node_manager_api.py）：body {"action": "restart"|"abort", "instance_id"}；**薄路由**——restart 整体委托 Daemon.restart_engine（Daemon 内部解析启动参数、冻结自杀、暂停/恢复 FaultReporter、只停引擎服务重拉不动 KV store/监控线程），路由只做 HTTP 语义映射（并发 409、快照恢复中 409、未 start 400、失败 500，零锁零状态）。部分失联协同**复用既有 /node-manager/stop**（不在 restart 路由新加 shutdown action） 5. **自杀冻结**（daemon.py）：截止时间制 freeze/unfreeze（abort 丢失自动过期，容器重启兜底永存）；**freeze 仅在死亡上报成功后才执行**（上报失败 → Controller 不可达 → 不冻结，仲裁继续计数，容器重启兜底不被拖死）；**freeze 受 enable_engine_relaunch 门控**（未开开关 → 不上报后不冻结，pod 快速自终止走 k8s 容器重启，不被 180s 冻结窗口拖延） 6. **FaultReporter 重拉编排**：重拉期间由 Daemon 暂停轮询（引擎被杀期间 FT 端口不可达，poll 失败会被误报死亡），重拉成功后 Daemon 恢复轮询并清空轮询状态（新引擎自然重新起算启动宽限）；另修复首次 poll 失败即冻结自杀的时序竞态（自杀 ~15s vs DEAD 上报 15-30s） 7. **自杀裁决收敛 Daemon**：心跳模块收敛为状态源（has_abnormal_endpoints/endpoints_generation/is_within_grace_period），Daemon 独立 3s 仲裁线程统一裁决（5×3s≈15s，间隔跟随 heartbeat_interval_seconds 配置）+ 统一 freeze/should_suicide；**冷启动误判门槛**：只有「曾经 NORMAL」的 endpoint 异常才上报死亡（模型加载期不误报） 8. **引擎就绪等待下沉**：_engine_ready 握手事件 + Daemon 后台 wait_ready——heartbeat 不再感知引擎就绪、不再 import Daemon（循环依赖解除），状态线程在探测前等待握手 9. **改名**：EngineManager → RegisterManager（register_manager.py，职责=注册/元数据管理，与 Daemon 进程管理区分） 10. **结构**：StrategyBase 移至 strategy/base.py（消除循环 import） 11. **配置收敛（唯一开关）**：enable_engine_relaunch（默认开）为「容器不重启重拉引擎」唯一开关——Controller 侧 fault_tolerance_config（策略选择门控）+ NodeManager 侧 fault_tolerance_config（同名配置，freeze 门控）；**删除 MOTOR_RESTART_ENGINE 环境变量及 health_check 的 SIGTERM 自杀快路径**，恢复路径统一由 Daemon 按开关决策 12. **重拉日志分隔标记**：旧引擎 stop 后、新引擎 pull 前，print 直达容器 stdout 打印 [ENGINE RELAUNCH #N] banner（容器生命周期内重拉计数 + 时间），多次重拉日志按次分区检索 13. **原生拉起适配（rebase #698/#717）**：重拉/就绪握手/死亡上报链路对接 native_engine；心跳经 RuntimeState probe 查询（STARTING/STOPPING 保留原状态）；进程组清理（start_new_session + killpg + 退出等待 + 僵尸收割）；bootstrap_port 字段；过时 EngineServer 提法清理 ### 3. 资料变更 涉及，同步更新： - docs/zh/developer_guide/components/node_manager.md：模块表（RegisterManager）、自杀裁决章节 - docs/zh/design/fault_tolerance/overview.md / fault_manager.md：策略/模块引用同步 - examples/features/config_sample.json：两侧 fault_tolerance_config 新字段 - skill refs（nodeman.md、controller.md、code-style.md）——nodeman.md 已随 #717 文档清理合并 ### 4. 接口变更 涉及（NodeManager 管理面接口 + 配置）： - 新增 POST /node-manager/engine-restart：body {"action": "restart"|"abort", "instance_id": int?}，200/400/409/500 - /node-manager/stop 语义补全为「自杀」：停引擎后延时 SIGTERM 自身（退出 -1 → k8s 重启 pod）。部分失联时 Controller 对存活 NM 复用该接口下发自杀（不再依赖引擎重拉路由） - 新增 Controller 配置 fault_tolerance_config.enable_engine_relaunch（默认 true）/ engine_relaunch_complete_timeout_sec / engine_relaunch_poll_interval_sec / engine_relaunch_dispatch_retries / engine_relaunch_nm_unreachable_threshold - 新增 NodeManager 配置 fault_tolerance_config.enable_engine_relaunch（默认 true，与 Controller 对齐）/ engine_restart_wait_timeout_sec（180s）/ engine_restart_freeze_sec（720s） - **删除** MOTOR_RESTART_ENGINE 环境变量（配置收敛，统一由 enable_engine_relaunch 决策） ### 5. 测试结果 **单测**（bash tests/run_tests.sh 全量）：**2665 passed**（rebase #698/#717 后全量基线之上） 新增/重写测试覆盖： - EngineRelaunchStrategy：Phase 1 探活全部 NM / 探活失败直接 Phase 2 / 下发全部 NM / 轮询成功 / NM 连续不可达进 Phase 2 / 超时 abort / 实例消失提前结束 / event 打断 / Phase 2 只 abort 未派发 NM - 策略失败升级：StrategyBase 失败标记 / 策略中心 prev_strategy_failed 置位与清除 / 升级选择 EngineRelaunchStrategy - level2_strategy 挂钩：ENGINE_DEAD → EngineRelaunchStrategy、开关关闭 → None、UNHEALTHY → None - engine-restart 路由：restart/abort/400/409（并发、快照恢复中）/500（pull 失败且解冻） - /node-manager/stop 自杀语义：停引擎 + 延时 SIGTERM 自身（pod 重启） - 自杀冻结与裁决：freeze 清零复位 / 冻结期不计数 / 解冻恢复 / 冻结到期自动恢复 / generation 变化重置 / grace 期跳过 / 阈值触发 / **上报失败不冻结** / **未开 enable_engine_relaunch 不冻结** - 引擎死亡双信号源：PID 死亡事件（monitor health_check 返回死亡列表 + pid 去重）/ 心跳 ABNORMAL 上报（ep 去重 + 恢复清除 + 失败重试） - FaultReporter：回归纯 FT 状态上报 - 心跳状态源：has_abnormal_endpoints / abnormal_endpoint_ids / endpoints_generation / grace getter - daemon：restart_engine 只动引擎服务（KV/监控线程不动）/ 裁决（阈值、重置条件、冻结窗口与过期）/ PID 死亡上报去重与失败重试 / 冷启动不误报、曾 NORMAL 后异常上报 / 重拉分隔标记（计数 + banner 打印） - RegisterManager：master_dp_ip/role 持久化、get_restart_params - 配置：两侧新字段默认值与校验 **静态检查**：pylint / ruff 通过 **K8s e2e（infer195，A2 跨机 EP16 = 2 pod × 8 卡）**：已验证通过—— - 杀 vLLM 进程 → 双信号检测 → EngineRelaunchStrategy 协同两个 pod 一起重拉全部引擎 → 实例回 ACTIVE - 杀 NodeManager 进程 → 实例稳定 INACTIVE（无 ACTIVE↔INACTIVE 震荡）→ volcano podgroup 自动重启两个 pod（既有机制）→ 新实例组装恢复 - 冷启动加载期（30B 模型 > grace 120s）不再被误判死亡：新增「曾 NORMAL 门槛」——e2e 对比：修复前加载期多条误报触发重拉打断加载（恶性循环），修复后误报 0、实例平滑 ACTIVE e2e 定位并修复的问题： - engine-restart 路由快照恢复检查条件错误（非快照部署误拒 409） - EngineServer SIGKILL 后子进程孤儿残留（占旧 ZMQ 端口 → 重拉引擎握手 5 分钟超时）——进程组管理修复（start_new_session + killpg + 退出等待 + 僵尸收割） - 重拉与 FaultReporter 解耦：PID 级检测 + 心跳 ABNORMAL 双信号源，不依赖 FT 配置 - 部分节点失联防震荡：转 ACTIVE 加心跳新鲜度门槛 + 存活 NM 经既有 /node-manager/stop（自杀语义）协同退出（volcano 兜底） - daemon 职责收敛：engine 重启生命周期（stop/分隔标记/pull）下沉 EngineService.restart，daemon 回归 service 无关的编排者 ### 6. CheckList - [x] 代码注释完备 - [x] 正确记录维测日志（错误场景 error_window 防刷屏） See merge request: Ascend/MindIE-Motor!710 | 2 天前 | |
[fix]修复Controller 若干问题 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !447 merge fix_controller_log into master [fix]修复Controller 若干问题 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: towncharlie Description: ## **1. 合入背景** https://gitcode.com/Ascend/MindIE-PyMotor/issues/245 https://gitcode.com/Ascend/MindIE-PyMotor/issues/246 https://gitcode.com/Ascend/MindIE-PyMotor/issues/256 ## **2. 修改内容** 1、修复Controller组件日志打印逻辑 2、修复configmap解析json的bug，如果不是json，就不要强制解析 3、node manager的心跳发送机制增强 4、ETCD续约机制增强，增加续约重试，避免误发送主降备 ## **3. 资料变更** 不涉及 ## **4. 接口变更** 不涉及 ## **5. 测试结果** 已修复场景： 1、实例重启，不再刷屏Controller的日志 2、Coordinator重启，推送功能正常 3、心跳超时后不再持续刷屏 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!447 | 1 个月前 | |
[Feature] FaultReporter 对齐 vLLM FT 框架：ZMQ 订阅改为 HTTP 轮询 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !678 merge feature/fault_reporterV2 into master [Feature] FaultReporter 对齐 vLLM FT 框架：ZMQ 订阅改为 HTTP 轮询 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ### 1. 合入背景 vLLM FaultTolerance 框架（vllm-project/vllm#44428）最终实现不再通过 ZMQ 广播引擎故障状态，改为外部轮询 REST 接口（ GET /fault_tolerance/status）。Motor 侧 FaultReporter 仍基于旧版 ZMQ 设计将无法感知引擎故障。本 PR 将 FaultReporter 重构为 HTTP 轮询模式并上报软件故障。 关联 ISSUE：#448 ### 2. 修改内容 1. **NodeManager FaultReporter 重构**（motor/node_manager/core/fault_reporter.py）： - ZMQ SUB 订阅 → HTTP 轮询每个 endpoint 的 GET /fault_tolerance/status（business_port） - 连续轮询失败 max_poll_failures 次按 dead 上报；_STARTUP_GRACE_SEC（300s）冷启动宽限期防误报；去重 key 统一为受管 endpoint id（多 endpoint 不互相覆盖）；状态解析异常不杀死轮询线程 - 自动启用：检测 user config 引擎段 FT 开关（enable-fault-tolerance/enable_fault_tolerance 为 true 或 1），无需 NodeManager 显式配置 2. **引擎 FT 协议层**（motor/common/constants.py + motor/common/http/engine_ft_client.py）：FT 状态路径/状态词/超时协议常量收敛为共享模块，query_engine_ft_status 为 FaultReporter 状态轮询入口 3. **配置变更**（NodeManager）：zmq_pub_port 删除，新增 poll_interval_sec（5.0）/ poll_timeout_sec（5.0）/ max_poll_failures（3） ### 3. 资料变更 涉及，同步更新： - docs/zh/developer_guide/components/node_manager.md：软件故障上报章节（轮询模式 + 自动启用）、配置表 - docs/zh/design/fault_tolerance/fault_manager.md：FaultReporter 架构与上报链路（HTTP 轮询）、NodeManager 侧配置表 - examples/features/config_sample.json：NodeManager 段 fault_tolerance_config 字段同步 ### 4. 接口变更 涉及（NodeManager 管理面接口）： - 删除 NodeManager 配置字段 fault_tolerance_config.zmq_pub_port，新增 poll_interval_sec / poll_timeout_sec / max_poll_failures ### 5. 测试结果 **单测**（bash tests/run_tests.sh tests/controller/ tests/node_manager/ tests/config/）：**839 passed** 新增/重写测试覆盖： - FaultReporter：轮询 healthy/unhealthy/dead 处理、fault_info 传递、去重、连续失败上报 dead、恢复清计数、上报失败重试、user_config 自动启用检测、malformed payload 不死线程、多 endpoint dedup 互不覆盖、冷启动宽限期（宽限期内外）、1 值检测、非引擎段忽略（14 项） - NodeManager 配置：poll_interval_sec / poll_timeout_sec / max_poll_failures 字段与校验 **静态检查**：pylint / ruff 通过 ### 6. CheckList - [x] 代码注释完备 - [x] 正确记录维测日志（错误场景 error_window 防刷屏） - [x] 是否有 UT 用例（839 passed） - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题（FaultReporter 锁内快照 endpoints、stop/start 防双线程） See merge request: Ascend/MindIE-Motor!678 | 7 天前 | |
支持引擎原生拉起：删除Engine Server冗余代码 Co-authored-by: tobking<wangjun292@huawei.com> # message auto-generated for no-merge-commit merge: !717 merge feat/pr3-remove-engine-server into master 支持引擎原生拉起：删除Engine Server冗余代码 Created-by: tobking Commit-by: tobking Merged-by: towncharlie Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. 在 NodeManager 原生拉起 vLLM/SGLang、Coordinator 直连原生推理端口（前序原生引擎 / PD 路由能力）落地后，motor/engine_server 已不再承担启动、推理转发与管理面职责，继续保留会带来： 1. **双栈维护成本**：EngineServer 与 Native Runtime 两套启动、健康检查与错误处理路径并存； 2. **架构不一致**：文档与部署仍暗示存在独立 EngineServer 进程，而实际链路为 Controller → NodeManager → 原生引擎； 3. **遗留协议负担**：EngineServer 侧 dispatch 信封、管理 HTTP、虚推（sim_inference）等与原生路径无关的代码/文档仍残留。 本 PR 是「删除 EngineServer、收敛到 Native Runtime」系列的收尾重构：删除 motor/engine_server 及其测试/入口，清理仅服务于 EngineServer 的 dispatch/配置/文档。容器快照中，显存保存/恢复由具备快照能力的引擎镜像自闭环完成；NodeManager 不再触发 /suspend、/device_unlock、/resume，只保留框架侧状态刷新、元数据准备和完成态感知。 - **关联前序能力**：NodeManager 原生拉起引擎、解除 Engine Server 层依赖；同系列 PR2（原生引擎直连 / PD 路由）。 - **关联 Issue**：[\#486](https://gitcode.com/Ascend/MindIE-Motor/issues/486) ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 1. **删除 EngineServer 组件** 移除 motor/engine_server/（CLI、推理/管理 Endpoint、dispatch adapter、vLLM/SGLang 封装、sim_inference、snapshot_sentinel 等）、setup.py 入口及相关 UT；进程模型收敛为 NodeManager 直接拉起 vllm serve / sglang.launch_server。 2. **容器快照职责切分（vLLM 快照镜像）** 显存快照保存/恢复是引擎原子能力，由支持快照的独立引擎镜像自闭环完成。NodeManager 在整个快照生命周期只做框架侧编排： - 快照前后刷新服务框架状态（Controller 域名、job_name、pod_ip），保证恢复后能向 Controller 注册； - 准备显存快照所需元数据（model_save_path / model_load_path、data_parallel_master_ip 等）； - 通过引擎就绪状态和 Host 侧 checkpoint 标记感知保存/恢复是否完成（心跳屏障、readiness）。 因此删除 native_engine/snapshot.py（SnapshotOrchestrator / NativeSnapshotControl）及其在 EngineManager、Daemon、NativeEngineService 上的触发接线。原先 EngineServer 的 snapshot_sentinel 下沉到引擎原生 server（如 api_server），不在 NodeManager 中重建。 总开关 motor_container_snapshot_config.enable_snapshot 默认 false；SGLang 开启该开关时配置校验失败。 3. **配置与公共协议精简** - 去掉 EndpointConfig 的 EngineServer CLI / init_endpoint_config / snapshot_metadata 等入口；TLS 更新改为 _update_native_engine_tls_config； - 删除 engine_constants 中仅 EngineServer 使用的常量； - 精简 dispatch.py：移除 EngineServer 侧 dispatch 信封模型与相关 helper，保留原生路由所需的 DispatchProfile / capability 分类。 4. **资料与开发指南同步** 删除 EngineServer 架构/接口/虚推文档与插图；更新 architecture、NodeManager/Coordinator 开发指南、container_snapshot、部署与配置参考；管理面文档补充原生场景下 mgmt_port / bootstrap_port 语义说明，并修正失效链接。快照文档改为：引擎负责 Device 侧 suspend/resume/unlock，NodeManager 负责元数据、注册与状态感知。 5. **测试** 删除 tests/engine_server/** 以及 NodeManager 侧 snapshot orchestrator UT（test_snapshot.py 及 snapshot_targets 相关用例）；保留 metadata 准备、restore 注册刷新、checkpoint 屏障等框架侧 UT。 ### 上下游关系（简要） text Controller └─ start/stop/pause → NodeManager API ├─ NativeEngineService → ProcessSupervisor → vLLM/SGLang ├─ HeartbeatManager → Controller（checkpoint 屏障、restore 后重新注册） └─ snapshot metadata / job_name / pod_ip 刷新 Coordinator └─ 直连原生 business_port（不再经 EngineServer） Engine（快照能力镜像） └─ Device 侧 suspend / device_unlock / resume 自闭环 Host/MindCluster └─ checkpoint 元数据 ↔ NodeManager readiness/status ### 设计文档位置 - .agent/skills/motor-dev/references/nodeman.md（Native Runtime + Snapshot Boundary） - docs/zh/user_guide/features/container_snapshot.md - docs/zh/developer_guide/components/node_manager.md - docs/zh/architecture.md / docs/zh/design/pd_disaggregation.md ### DFX - 快照框架侧日志前缀 [snapshot]；恢复后刷新注册信息并重试向 Controller 注册； - 健康探测仍走原生 /health；pause 返回原生 metrics URL； - 不引入 EngineServer 管理端口，也不由 NodeManager 调用引擎快照 HTTP 接口。 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 涉及。删除 EngineServer 文档与插图；更新 NodeManager / 容器快照 / 架构与配置说明，明确显存快照由引擎自闭环、NodeManager 只做框架侧编排。 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 不涉及对外客户面接口变更。删除的是 Motor 内部 EngineServer 进程及 NodeManager 对引擎 /suspend、/device_unlock、/resume 的主动调用；容器快照仍通过 motor_container_snapshot_config.enable_snapshot 显式打开，默认关闭。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 - 单元测试：tests/node_manager/core/test_engine_manager.py、test_daemon.py、native_engine/test_service.py 等框架侧用例通过（含 snapshot metadata / restore 准备、原生拉起与恢复门闩）。 - 删除 EngineServer 及 snapshot orchestrator 后，不再保留对 NodeManager 主动调用 /suspend /resume 的 UT。 - 容器快照端到端需使用支持镜像快照的引擎独立镜像，并显式打开 enable_snapshot 后验证：冷启动稳态点、Host checkpoint、恢复后重新注册与推理恢复。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!717 | 3 天前 | |
[Feature] 引擎重启兜底策略：容器不重启重拉引擎 + 自杀裁决收敛 Daemon Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !710 merge feature/engine_relaunch into master [Feature] 引擎重启兜底策略：容器不重启重拉引擎 + 自杀裁决收敛 Daemon Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ### 1. 合入背景 引擎进程死亡后，当前唯一兜底是「NodeManager 心跳 abnormal ×5（约 15s）→ 自杀 → k8s 重启 pod」，代价是全容器重建。本 PR 实现「容器不重启重拉引擎」：Controller 协同实例的**所有** NodeManager 一起重拉全部引擎（rank 集合通信组一致性），重拉失败再回退到容器重启；同时把自杀裁决权收敛到 Daemon（进程生命周期管理者）。 本 PR 基于最新主线：原生引擎拉起（#698：NodeManager 直接 spawn 原生 vLLM/SGLang，删除 EngineServer 层）与 EngineServer 删除收尾（#717）均已合入，重拉链路已对接原生拉起路径。 关联 ISSUE：#472 ### 2. 修改内容 1. **Controller 引擎重启兜底策略**（ motor/controller/fault_tolerance/strategy/engine_relaunch.py，两阶段）： - Phase 1 重启引擎：探活实例全部 NodeManager（任一不可达 → 直接 Phase 2，保证 rank 一致性）→ 逐个下发 POST /node-manager/engine-restart → 轮询 /node-manager/status 全部 NORMAL → 成功 - Phase 2 重启容器：仅对**未成功派发重启**的 NM 发 abort 解冻自杀（已派发 NM 保持 freeze，避免打断正在恢复的引擎）→ 心跳机制触发容器重启（k8s）；abort 发送失败补 error 日志指名 NM；实例 DELETED/消失提前结束 - stop() 被打断时 fire-and-forget 发 abort（防冻结窗口内 NM 自杀被延迟） 2. **策略失败升级机制（可复用）**：StrategyBase.mark_failed() + InstanceMetadata.prev_strategy_failed——token 重推/UCE/弹性扩缩容等「期望引擎不重启快速恢复」的策略失败后，策略中心自动降级到 EngineRelaunchStrategy（兜底链）；升级分支同样受 enable_engine_relaunch 门控 3. **level2_strategy 挂钩**：ENGINE_DEAD 软件故障直接触发 EngineRelaunchStrategy（开关关闭 → None） 4. **NodeManager 新路由** POST /node-manager/engine-restart（node_manager_api.py）：body {"action": "restart"|"abort", "instance_id"}；**薄路由**——restart 整体委托 Daemon.restart_engine（Daemon 内部解析启动参数、冻结自杀、暂停/恢复 FaultReporter、只停引擎服务重拉不动 KV store/监控线程），路由只做 HTTP 语义映射（并发 409、快照恢复中 409、未 start 400、失败 500，零锁零状态）。部分失联协同**复用既有 /node-manager/stop**（不在 restart 路由新加 shutdown action） 5. **自杀冻结**（daemon.py）：截止时间制 freeze/unfreeze（abort 丢失自动过期，容器重启兜底永存）；**freeze 仅在死亡上报成功后才执行**（上报失败 → Controller 不可达 → 不冻结，仲裁继续计数，容器重启兜底不被拖死）；**freeze 受 enable_engine_relaunch 门控**（未开开关 → 不上报后不冻结，pod 快速自终止走 k8s 容器重启，不被 180s 冻结窗口拖延） 6. **FaultReporter 重拉编排**：重拉期间由 Daemon 暂停轮询（引擎被杀期间 FT 端口不可达，poll 失败会被误报死亡），重拉成功后 Daemon 恢复轮询并清空轮询状态（新引擎自然重新起算启动宽限）；另修复首次 poll 失败即冻结自杀的时序竞态（自杀 ~15s vs DEAD 上报 15-30s） 7. **自杀裁决收敛 Daemon**：心跳模块收敛为状态源（has_abnormal_endpoints/endpoints_generation/is_within_grace_period），Daemon 独立 3s 仲裁线程统一裁决（5×3s≈15s，间隔跟随 heartbeat_interval_seconds 配置）+ 统一 freeze/should_suicide；**冷启动误判门槛**：只有「曾经 NORMAL」的 endpoint 异常才上报死亡（模型加载期不误报） 8. **引擎就绪等待下沉**：_engine_ready 握手事件 + Daemon 后台 wait_ready——heartbeat 不再感知引擎就绪、不再 import Daemon（循环依赖解除），状态线程在探测前等待握手 9. **改名**：EngineManager → RegisterManager（register_manager.py，职责=注册/元数据管理，与 Daemon 进程管理区分） 10. **结构**：StrategyBase 移至 strategy/base.py（消除循环 import） 11. **配置收敛（唯一开关）**：enable_engine_relaunch（默认开）为「容器不重启重拉引擎」唯一开关——Controller 侧 fault_tolerance_config（策略选择门控）+ NodeManager 侧 fault_tolerance_config（同名配置，freeze 门控）；**删除 MOTOR_RESTART_ENGINE 环境变量及 health_check 的 SIGTERM 自杀快路径**，恢复路径统一由 Daemon 按开关决策 12. **重拉日志分隔标记**：旧引擎 stop 后、新引擎 pull 前，print 直达容器 stdout 打印 [ENGINE RELAUNCH #N] banner（容器生命周期内重拉计数 + 时间），多次重拉日志按次分区检索 13. **原生拉起适配（rebase #698/#717）**：重拉/就绪握手/死亡上报链路对接 native_engine；心跳经 RuntimeState probe 查询（STARTING/STOPPING 保留原状态）；进程组清理（start_new_session + killpg + 退出等待 + 僵尸收割）；bootstrap_port 字段；过时 EngineServer 提法清理 ### 3. 资料变更 涉及，同步更新： - docs/zh/developer_guide/components/node_manager.md：模块表（RegisterManager）、自杀裁决章节 - docs/zh/design/fault_tolerance/overview.md / fault_manager.md：策略/模块引用同步 - examples/features/config_sample.json：两侧 fault_tolerance_config 新字段 - skill refs（nodeman.md、controller.md、code-style.md）——nodeman.md 已随 #717 文档清理合并 ### 4. 接口变更 涉及（NodeManager 管理面接口 + 配置）： - 新增 POST /node-manager/engine-restart：body {"action": "restart"|"abort", "instance_id": int?}，200/400/409/500 - /node-manager/stop 语义补全为「自杀」：停引擎后延时 SIGTERM 自身（退出 -1 → k8s 重启 pod）。部分失联时 Controller 对存活 NM 复用该接口下发自杀（不再依赖引擎重拉路由） - 新增 Controller 配置 fault_tolerance_config.enable_engine_relaunch（默认 true）/ engine_relaunch_complete_timeout_sec / engine_relaunch_poll_interval_sec / engine_relaunch_dispatch_retries / engine_relaunch_nm_unreachable_threshold - 新增 NodeManager 配置 fault_tolerance_config.enable_engine_relaunch（默认 true，与 Controller 对齐）/ engine_restart_wait_timeout_sec（180s）/ engine_restart_freeze_sec（720s） - **删除** MOTOR_RESTART_ENGINE 环境变量（配置收敛，统一由 enable_engine_relaunch 决策） ### 5. 测试结果 **单测**（bash tests/run_tests.sh 全量）：**2665 passed**（rebase #698/#717 后全量基线之上） 新增/重写测试覆盖： - EngineRelaunchStrategy：Phase 1 探活全部 NM / 探活失败直接 Phase 2 / 下发全部 NM / 轮询成功 / NM 连续不可达进 Phase 2 / 超时 abort / 实例消失提前结束 / event 打断 / Phase 2 只 abort 未派发 NM - 策略失败升级：StrategyBase 失败标记 / 策略中心 prev_strategy_failed 置位与清除 / 升级选择 EngineRelaunchStrategy - level2_strategy 挂钩：ENGINE_DEAD → EngineRelaunchStrategy、开关关闭 → None、UNHEALTHY → None - engine-restart 路由：restart/abort/400/409（并发、快照恢复中）/500（pull 失败且解冻） - /node-manager/stop 自杀语义：停引擎 + 延时 SIGTERM 自身（pod 重启） - 自杀冻结与裁决：freeze 清零复位 / 冻结期不计数 / 解冻恢复 / 冻结到期自动恢复 / generation 变化重置 / grace 期跳过 / 阈值触发 / **上报失败不冻结** / **未开 enable_engine_relaunch 不冻结** - 引擎死亡双信号源：PID 死亡事件（monitor health_check 返回死亡列表 + pid 去重）/ 心跳 ABNORMAL 上报（ep 去重 + 恢复清除 + 失败重试） - FaultReporter：回归纯 FT 状态上报 - 心跳状态源：has_abnormal_endpoints / abnormal_endpoint_ids / endpoints_generation / grace getter - daemon：restart_engine 只动引擎服务（KV/监控线程不动）/ 裁决（阈值、重置条件、冻结窗口与过期）/ PID 死亡上报去重与失败重试 / 冷启动不误报、曾 NORMAL 后异常上报 / 重拉分隔标记（计数 + banner 打印） - RegisterManager：master_dp_ip/role 持久化、get_restart_params - 配置：两侧新字段默认值与校验 **静态检查**：pylint / ruff 通过 **K8s e2e（infer195，A2 跨机 EP16 = 2 pod × 8 卡）**：已验证通过—— - 杀 vLLM 进程 → 双信号检测 → EngineRelaunchStrategy 协同两个 pod 一起重拉全部引擎 → 实例回 ACTIVE - 杀 NodeManager 进程 → 实例稳定 INACTIVE（无 ACTIVE↔INACTIVE 震荡）→ volcano podgroup 自动重启两个 pod（既有机制）→ 新实例组装恢复 - 冷启动加载期（30B 模型 > grace 120s）不再被误判死亡：新增「曾 NORMAL 门槛」——e2e 对比：修复前加载期多条误报触发重拉打断加载（恶性循环），修复后误报 0、实例平滑 ACTIVE e2e 定位并修复的问题： - engine-restart 路由快照恢复检查条件错误（非快照部署误拒 409） - EngineServer SIGKILL 后子进程孤儿残留（占旧 ZMQ 端口 → 重拉引擎握手 5 分钟超时）——进程组管理修复（start_new_session + killpg + 退出等待 + 僵尸收割） - 重拉与 FaultReporter 解耦：PID 级检测 + 心跳 ABNORMAL 双信号源，不依赖 FT 配置 - 部分节点失联防震荡：转 ACTIVE 加心跳新鲜度门槛 + 存活 NM 经既有 /node-manager/stop（自杀语义）协同退出（volcano 兜底） - daemon 职责收敛：engine 重启生命周期（stop/分隔标记/pull）下沉 EngineService.restart，daemon 回归 service 无关的编排者 ### 6. CheckList - [x] 代码注释完备 - [x] 正确记录维测日志（错误场景 error_window 防刷屏） See merge request: Ascend/MindIE-Motor!710 | 2 天前 | |
[fix]修复Controller 若干问题 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !447 merge fix_controller_log into master [fix]修复Controller 若干问题 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: towncharlie Description: ## **1. 合入背景** https://gitcode.com/Ascend/MindIE-PyMotor/issues/245 https://gitcode.com/Ascend/MindIE-PyMotor/issues/246 https://gitcode.com/Ascend/MindIE-PyMotor/issues/256 ## **2. 修改内容** 1、修复Controller组件日志打印逻辑 2、修复configmap解析json的bug，如果不是json，就不要强制解析 3、node manager的心跳发送机制增强 4、ETCD续约机制增强，增加续约重试，避免误发送主降备 ## **3. 资料变更** 不涉及 ## **4. 接口变更** 不涉及 ## **5. 测试结果** 已修复场景： 1、实例重启，不再刷屏Controller的日志 2、Coordinator重启，推送功能正常 3、心跳超时后不再持续刷屏 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!447 | 1 个月前 | |
[feature] 支持引擎原生拉起： layerwise CDP调度模式适配 Co-authored-by: tobking<wangjun292@huawei.com> # message auto-generated for no-merge-commit merge: !773 merge master_0819 into master [feature] 支持引擎原生拉起： layerwise CDP调度模式适配 Created-by: tobking Commit-by: tobking Merged-by: towncharlie Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. vLLM layerwise P/D 由 Decode 先接收请求，再通过 metaserver callback 触发 Prefill 和逐层 KV 传输。Coordinator 当前缺少完整的 Trigger 调度链路，无法保证 callback 回到持有原始请求状态的 Worker，也无法将异步 Prefill 纳入原请求的取消、重试和 workload 回收生命周期。 本改动补齐 vLLM concurrent_engine_sync 的端到端调度，并处理 callback 并发幂等、资源回滚以及 IPv4/IPv6 回调地址可达性。 [#503](https://gitcode.com/Ascend/MindIE-Motor/issues/503) ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 1）增加 vLLM P/D 协同模式选择： prefill_handoff_decode 继续使用现有 handoff 流程。 concurrent_engine_sync 使用 Trigger 流程，先分配并请求 Decode，再由 Decode callback 触发 Prefill。 对同一拓扑中 handoff/trigger 能力混用返回 HTTP 503。 2）增加 Trigger 协议适配： Decode 请求注入 do_remote_prefill 和 metaserver URL。 callback 携带的远端 block、host、port 参数转换为 Prefill 请求。 NodeManager 原生 vLLM backend 根据 layerwise 配置上报对应 dispatch capability。 3）增加每 Worker 独立 metaserver： 新增 inference_workers_config.worker_metaserver_base_port，默认 0 表示关闭。 Worker i 使用 base_port + i，独立 uvicorn app 仅暴露 POST /v1/metaserver。 callback 通过 request_id + attempt 找到发起 Decode 的同一 Worker 和当前 attempt。 4）完善 callback 生命周期： 使用 AttemptContext.trigger_lock 串行化并发 callback。 将 callback task 注册为 Prefill task，客户端断开、Decode 失败或 callback 取消时停止整个 attempt。 Prefill 已完成后的重复 callback 返回幂等成功，不重复分配实例。 Scheduler 分配成功但 Worker 本地 workload 登记失败时立即回滚。 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 更新 P/D 分离设计文档，说明 vLLM layerwise Trigger 调度流程。 更新 Coordinator 开发文档，说明每 Worker metaserver、attempt 校验、callback 生命周期和地址选择。 更新配置参考及示例配置，说明 worker_metaserver_base_port 的用途和端口范围。 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 不涉及 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!773 | 10 小时前 | |
update license Co-authored-by: y1lou<louyi6@huawei.com> # message auto-generated for no-merge-commit merge: !185 merge update_license into master update license Created-by: y1lou Commit-by: y1lou Merged-by: ascend-robot Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-pyMotor!185 | 6 个月前 | |
支持引擎原生拉起：删除Engine Server冗余代码 Co-authored-by: tobking<wangjun292@huawei.com> # message auto-generated for no-merge-commit merge: !717 merge feat/pr3-remove-engine-server into master 支持引擎原生拉起：删除Engine Server冗余代码 Created-by: tobking Commit-by: tobking Merged-by: towncharlie Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. 在 NodeManager 原生拉起 vLLM/SGLang、Coordinator 直连原生推理端口（前序原生引擎 / PD 路由能力）落地后，motor/engine_server 已不再承担启动、推理转发与管理面职责，继续保留会带来： 1. **双栈维护成本**：EngineServer 与 Native Runtime 两套启动、健康检查与错误处理路径并存； 2. **架构不一致**：文档与部署仍暗示存在独立 EngineServer 进程，而实际链路为 Controller → NodeManager → 原生引擎； 3. **遗留协议负担**：EngineServer 侧 dispatch 信封、管理 HTTP、虚推（sim_inference）等与原生路径无关的代码/文档仍残留。 本 PR 是「删除 EngineServer、收敛到 Native Runtime」系列的收尾重构：删除 motor/engine_server 及其测试/入口，清理仅服务于 EngineServer 的 dispatch/配置/文档。容器快照中，显存保存/恢复由具备快照能力的引擎镜像自闭环完成；NodeManager 不再触发 /suspend、/device_unlock、/resume，只保留框架侧状态刷新、元数据准备和完成态感知。 - **关联前序能力**：NodeManager 原生拉起引擎、解除 Engine Server 层依赖；同系列 PR2（原生引擎直连 / PD 路由）。 - **关联 Issue**：[\#486](https://gitcode.com/Ascend/MindIE-Motor/issues/486) ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 1. **删除 EngineServer 组件** 移除 motor/engine_server/（CLI、推理/管理 Endpoint、dispatch adapter、vLLM/SGLang 封装、sim_inference、snapshot_sentinel 等）、setup.py 入口及相关 UT；进程模型收敛为 NodeManager 直接拉起 vllm serve / sglang.launch_server。 2. **容器快照职责切分（vLLM 快照镜像）** 显存快照保存/恢复是引擎原子能力，由支持快照的独立引擎镜像自闭环完成。NodeManager 在整个快照生命周期只做框架侧编排： - 快照前后刷新服务框架状态（Controller 域名、job_name、pod_ip），保证恢复后能向 Controller 注册； - 准备显存快照所需元数据（model_save_path / model_load_path、data_parallel_master_ip 等）； - 通过引擎就绪状态和 Host 侧 checkpoint 标记感知保存/恢复是否完成（心跳屏障、readiness）。 因此删除 native_engine/snapshot.py（SnapshotOrchestrator / NativeSnapshotControl）及其在 EngineManager、Daemon、NativeEngineService 上的触发接线。原先 EngineServer 的 snapshot_sentinel 下沉到引擎原生 server（如 api_server），不在 NodeManager 中重建。 总开关 motor_container_snapshot_config.enable_snapshot 默认 false；SGLang 开启该开关时配置校验失败。 3. **配置与公共协议精简** - 去掉 EndpointConfig 的 EngineServer CLI / init_endpoint_config / snapshot_metadata 等入口；TLS 更新改为 _update_native_engine_tls_config； - 删除 engine_constants 中仅 EngineServer 使用的常量； - 精简 dispatch.py：移除 EngineServer 侧 dispatch 信封模型与相关 helper，保留原生路由所需的 DispatchProfile / capability 分类。 4. **资料与开发指南同步** 删除 EngineServer 架构/接口/虚推文档与插图；更新 architecture、NodeManager/Coordinator 开发指南、container_snapshot、部署与配置参考；管理面文档补充原生场景下 mgmt_port / bootstrap_port 语义说明，并修正失效链接。快照文档改为：引擎负责 Device 侧 suspend/resume/unlock，NodeManager 负责元数据、注册与状态感知。 5. **测试** 删除 tests/engine_server/** 以及 NodeManager 侧 snapshot orchestrator UT（test_snapshot.py 及 snapshot_targets 相关用例）；保留 metadata 准备、restore 注册刷新、checkpoint 屏障等框架侧 UT。 ### 上下游关系（简要） text Controller └─ start/stop/pause → NodeManager API ├─ NativeEngineService → ProcessSupervisor → vLLM/SGLang ├─ HeartbeatManager → Controller（checkpoint 屏障、restore 后重新注册） └─ snapshot metadata / job_name / pod_ip 刷新 Coordinator └─ 直连原生 business_port（不再经 EngineServer） Engine（快照能力镜像） └─ Device 侧 suspend / device_unlock / resume 自闭环 Host/MindCluster └─ checkpoint 元数据 ↔ NodeManager readiness/status ### 设计文档位置 - .agent/skills/motor-dev/references/nodeman.md（Native Runtime + Snapshot Boundary） - docs/zh/user_guide/features/container_snapshot.md - docs/zh/developer_guide/components/node_manager.md - docs/zh/architecture.md / docs/zh/design/pd_disaggregation.md ### DFX - 快照框架侧日志前缀 [snapshot]；恢复后刷新注册信息并重试向 Controller 注册； - 健康探测仍走原生 /health；pause 返回原生 metrics URL； - 不引入 EngineServer 管理端口，也不由 NodeManager 调用引擎快照 HTTP 接口。 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 涉及。删除 EngineServer 文档与插图；更新 NodeManager / 容器快照 / 架构与配置说明，明确显存快照由引擎自闭环、NodeManager 只做框架侧编排。 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 不涉及对外客户面接口变更。删除的是 Motor 内部 EngineServer 进程及 NodeManager 对引擎 /suspend、/device_unlock、/resume 的主动调用；容器快照仍通过 motor_container_snapshot_config.enable_snapshot 显式打开，默认关闭。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 - 单元测试：tests/node_manager/core/test_engine_manager.py、test_daemon.py、native_engine/test_service.py 等框架侧用例通过（含 snapshot metadata / restore 准备、原生拉起与恢复门闩）。 - 删除 EngineServer 及 snapshot orchestrator 后，不再保留对 NodeManager 主动调用 /suspend /resume 的 UT。 - 容器快照端到端需使用支持镜像快照的引擎独立镜像，并显式打开 enable_snapshot 后验证：冷启动稳态点、Host checkpoint、恢复后重新注册与推理恢复。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!717 | 3 天前 | |
支持引擎原生拉起：删除Engine Server冗余代码 Co-authored-by: tobking<wangjun292@huawei.com> # message auto-generated for no-merge-commit merge: !717 merge feat/pr3-remove-engine-server into master 支持引擎原生拉起：删除Engine Server冗余代码 Created-by: tobking Commit-by: tobking Merged-by: towncharlie Description: ## **1. 合入背景** > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 请通过#ISSUE ID关联issue。\ > 注意： Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. 在 NodeManager 原生拉起 vLLM/SGLang、Coordinator 直连原生推理端口（前序原生引擎 / PD 路由能力）落地后，motor/engine_server 已不再承担启动、推理转发与管理面职责，继续保留会带来： 1. **双栈维护成本**：EngineServer 与 Native Runtime 两套启动、健康检查与错误处理路径并存； 2. **架构不一致**：文档与部署仍暗示存在独立 EngineServer 进程，而实际链路为 Controller → NodeManager → 原生引擎； 3. **遗留协议负担**：EngineServer 侧 dispatch 信封、管理 HTTP、虚推（sim_inference）等与原生路径无关的代码/文档仍残留。 本 PR 是「删除 EngineServer、收敛到 Native Runtime」系列的收尾重构：删除 motor/engine_server 及其测试/入口，清理仅服务于 EngineServer 的 dispatch/配置/文档。容器快照中，显存保存/恢复由具备快照能力的引擎镜像自闭环完成；NodeManager 不再触发 /suspend、/device_unlock、/resume，只保留框架侧状态刷新、元数据准备和完成态感知。 - **关联前序能力**：NodeManager 原生拉起引擎、解除 Engine Server 层依赖；同系列 PR2（原生引擎直连 / PD 路由）。 - **关联 Issue**：[\#486](https://gitcode.com/Ascend/MindIE-Motor/issues/486) ## **2. 修改内容** > 请<ins>**描述修改内容的具体实现**</ins>，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。 > 如果是需求或者重构类的PR，需要<ins>**补充详细设计文档**</ins>（说明上下游组件关系、时序图、类图、DFX能力等内容）。 1. **删除 EngineServer 组件** 移除 motor/engine_server/（CLI、推理/管理 Endpoint、dispatch adapter、vLLM/SGLang 封装、sim_inference、snapshot_sentinel 等）、setup.py 入口及相关 UT；进程模型收敛为 NodeManager 直接拉起 vllm serve / sglang.launch_server。 2. **容器快照职责切分（vLLM 快照镜像）** 显存快照保存/恢复是引擎原子能力，由支持快照的独立引擎镜像自闭环完成。NodeManager 在整个快照生命周期只做框架侧编排： - 快照前后刷新服务框架状态（Controller 域名、job_name、pod_ip），保证恢复后能向 Controller 注册； - 准备显存快照所需元数据（model_save_path / model_load_path、data_parallel_master_ip 等）； - 通过引擎就绪状态和 Host 侧 checkpoint 标记感知保存/恢复是否完成（心跳屏障、readiness）。 因此删除 native_engine/snapshot.py（SnapshotOrchestrator / NativeSnapshotControl）及其在 EngineManager、Daemon、NativeEngineService 上的触发接线。原先 EngineServer 的 snapshot_sentinel 下沉到引擎原生 server（如 api_server），不在 NodeManager 中重建。 总开关 motor_container_snapshot_config.enable_snapshot 默认 false；SGLang 开启该开关时配置校验失败。 3. **配置与公共协议精简** - 去掉 EndpointConfig 的 EngineServer CLI / init_endpoint_config / snapshot_metadata 等入口；TLS 更新改为 _update_native_engine_tls_config； - 删除 engine_constants 中仅 EngineServer 使用的常量； - 精简 dispatch.py：移除 EngineServer 侧 dispatch 信封模型与相关 helper，保留原生路由所需的 DispatchProfile / capability 分类。 4. **资料与开发指南同步** 删除 EngineServer 架构/接口/虚推文档与插图；更新 architecture、NodeManager/Coordinator 开发指南、container_snapshot、部署与配置参考；管理面文档补充原生场景下 mgmt_port / bootstrap_port 语义说明，并修正失效链接。快照文档改为：引擎负责 Device 侧 suspend/resume/unlock，NodeManager 负责元数据、注册与状态感知。 5. **测试** 删除 tests/engine_server/** 以及 NodeManager 侧 snapshot orchestrator UT（test_snapshot.py 及 snapshot_targets 相关用例）；保留 metadata 准备、restore 注册刷新、checkpoint 屏障等框架侧 UT。 ### 上下游关系（简要） text Controller └─ start/stop/pause → NodeManager API ├─ NativeEngineService → ProcessSupervisor → vLLM/SGLang ├─ HeartbeatManager → Controller（checkpoint 屏障、restore 后重新注册） └─ snapshot metadata / job_name / pod_ip 刷新 Coordinator └─ 直连原生 business_port（不再经 EngineServer） Engine（快照能力镜像） └─ Device 侧 suspend / device_unlock / resume 自闭环 Host/MindCluster └─ checkpoint 元数据 ↔ NodeManager readiness/status ### 设计文档位置 - .agent/skills/motor-dev/references/nodeman.md（Native Runtime + Snapshot Boundary） - docs/zh/user_guide/features/container_snapshot.md - docs/zh/developer_guide/components/node_manager.md - docs/zh/architecture.md / docs/zh/design/pd_disaggregation.md ### DFX - 快照框架侧日志前缀 [snapshot]；恢复后刷新注册信息并重试向 Controller 注册； - 健康探测仍走原生 /health；pause 返回原生 metrics URL； - 不引入 EngineServer 管理端口，也不由 NodeManager 调用引擎快照 HTTP 接口。 ## **3. 资料变更** > 请确认<ins>**是否涉及资料变更**</ins>。\ > 如涉及，需要在PR中体现，并简要说明修改内容。\ > 如不涉及，需填写“不涉及”。 涉及。删除 EngineServer 文档与插图；更新 NodeManager / 容器快照 / 架构与配置说明，明确显存快照由引擎自闭环、NodeManager 只做框架侧编排。 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 不涉及对外客户面接口变更。删除的是 Motor 内部 EngineServer 进程及 NodeManager 对引擎 /suspend、/device_unlock、/resume 的主动调用；容器快照仍通过 motor_container_snapshot_config.enable_snapshot 显式打开，默认关闭。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 - 单元测试：tests/node_manager/core/test_engine_manager.py、test_daemon.py、native_engine/test_service.py 等框架侧用例通过（含 snapshot metadata / restore 准备、原生拉起与恢复门闩）。 - 删除 EngineServer 及 snapshot orchestrator 后，不再保留对 NodeManager 主动调用 /suspend /resume 的 UT。 - 容器快照端到端需使用支持镜像快照的引擎独立镜像，并显式打开 enable_snapshot 后验证：冷启动稳态点、Host checkpoint、恢复后重新注册与推理恢复。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!717 | 3 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 23 天前 | ||
| 2 天前 | ||
| 1 个月前 | ||
| 7 天前 | ||
| 3 天前 | ||
| 2 天前 | ||
| 1 个月前 | ||
| 10 小时前 | ||
| 6 个月前 | ||
| 3 天前 | ||
| 3 天前 |