master

文件	最后提交记录	最后更新时间
deployer	[feature] NodeManager 原生引擎虚推健康探测 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !750 merge feature/native-engine-virtual-inference-split into master [feature] NodeManager 原生引擎虚推健康探测 Created-by: Jechin Commit-by: Jechin Merged-by: tobking Description: ## **1. 合入背景** Fixes [#486](https://gitcode.com/Ascend/MindIE-Motor/issues/486) 原生拉起模式下，引擎由 NodeManager 直接管理，不再经过 Engine Server，原有虚推健康探测因此失去承载位置。本 PR 将这项能力迁移到 NodeManager：在普通 /health 正常但引擎已经无法完成真实推理时，通过轻量推理请求和 NPU 利用率识别静默故障。 vLLM 使用 Motor 主动虚推；SGLang 使用自身的生成式 /health。虚推只负责将实例状态降级为异常，不直接杀进程或重启引擎，后续恢复仍由现有故障处理链路统一决策。 ## **2. 修改内容** 1. 在 NodeManager 原生引擎服务中新增 vLLM 虚推能力： - 每个实例只为有效的 DP0 endpoint 创建一个 VirtualInferenceWorker。 - 首次 /health READY 后启动，先执行 180 秒 warmup，再按配置周期探测 POST /v1/completions。 - 结合 AI Cube 利用率和连续失败阈值判断静默故障，异常时仅将运行状态降级为 UNHEALTHY。 2. 完善虚推生命周期和并发保护： - 使用不可变 target/spec 识别 monitor，重复拉起时幂等复用，配置或 endpoint 变化时安全替换。 - pull、stop、回滚及 monitor 替换之间增加串行和 CAS 保护，避免旧 worker 覆盖新 worker 或泄漏异常状态。 - worker 构造、配置解析和采样异常与引擎进程隔离，不因辅助探测失败停止已启动引擎。 3. 收敛不同引擎的健康探测方式： - vLLM 由 Motor 发送轻量 completion 请求，并通过 npu-smi info watch -s u 采集 AI Cube 利用率。 - SGLang 不创建 Motor 虚推 worker，启动时固定启用 SGLANG_ENABLE_HEALTH_ENDPOINT_GENERATION=true，继续由 NodeManager 轮询 GET /health。 - AI Cube 流读取使用原始字节缓冲，避免文本缓冲与 select 状态不同步导致漏读数据行。 4. 扩展健康检查配置： - 新增 virtual_inference_timeout，默认 5 秒，仅用于 vLLM 周期虚推；首次 warmup 仍固定为 180 秒。 - enable_virtual_inference、NPU 阈值、失败次数和日志级别共同决定是否启用 vLLM 虚推。 - SGLang 心跳继续使用 health_collector_timeout，不受 virtual_inference_timeout 影响。 5. 补充并精简单元测试，覆盖能力开关、请求构造、AI Cube 解析、状态合并、资源清理、失败回滚和并发竞态等关键场景。 **进程视图** mermaid flowchart TB subgraph nodeManager["NodeManager 进程"] daemon["Daemon 故障处理"] service["NativeEngineService"] worker["VirtualInferenceWorker<br/>仅 vLLM DP0"] requester["VllmCompletionsRequester"] end subgraph engines["原生推理引擎"] vllmHealth["vLLM GET /health"] vllmCompletion["vLLM POST /v1/completions"] sglangHealth["SGLang 生成式 GET /health"] end aiCube["npu-smi AI Cube 采样"] abnormal["状态降级为 UNHEALTHY"] daemon --> service service --> vllmHealth service --> sglangHealth service -->|首次 READY| worker worker --> requester --> vllmCompletion worker --> aiCube worker -->|达到失败阈值| abnormal ## **3. 资料变更** - docs/zh/user_guide/features/sim_inference.md：说明原生拉起模式下 vLLM 虚推和 SGLang 生成式健康检查的工作方式。 - docs/zh/user_guide/configuration/config_reference.md：补充虚推开关、超时、阈值及适用范围。 - docs/zh/user_guide/deployment/k8s/pd_disaggregation_deployment.md：补充部署配置示例和日志级别限制。 - docs/zh/developer_guide/components/node_manager.md：更新 NodeManager 健康探测职责。 - .agent/skills/motor-dev/references/nodeman.md：同步原生引擎虚推架构与生命周期。 ## **4. 接口变更** - health_check_config 新增 virtual_inference_timeout，类型为正数，默认值为 5 秒，仅影响 vLLM 周期虚推。 - 原生拉起 SGLang 时固定注入 SGLANG_ENABLE_HEALTH_ENDPOINT_GENERATION=true。 - 不涉及跨代码仓或客户面 HTTP API 变更。 ## **5. 测试结果** - 虚推能力、requester、worker、NativeEngineService、SGLang backend 和 AI Cube 工具均已补充单元测试。 - 覆盖功能开关、DP0/headless 判定、日志级别门禁、warmup/周期超时、失败阈值、状态合并、monitor 替换、pull/stop 并发、失败回滚和资源清理。 - pre-commit 与远端 Git Hooks 通过。 - 文档 markdownlint、链接有效性和资源存在性检查已按流水线意见修复。 ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!750	3 小时前
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	21 天前