| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
【docs】设计文档优化：扩缩容文档合一为 scaling.md、主备倒换设计文档归位 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !679 merge docs/design_doc_opt into master 【docs】设计文档优化：扩缩容文档合一为 scaling.md、主备倒换设计文档归位 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ### 变更说明 关联 ISSUE：[#450 [Documentation|文档反馈]: 设计文档优化：扩缩容文档合一为 scaling.md、主备倒换设计文档归位](https://gitcode.com/Ascend/MindIE-Motor/issues/450) 1. **文档归位**： docs/zh/design/standby.md 移至 docs/zh/design/fault_tolerance/standby.md，与 fault_manager、precision_detection 等容错设计文档归入同组，并修正文档内图片相对路径（../imgs/ → ../../imgs/）。 2. **扩缩容文档合一**：design/manual_scaling.md 与 user_guide/features/auto_scaling.md 合并为 docs/zh/design/scaling.md： - 章节顺序为先自动扩缩容（特性概述、工作原理、指标设计、策略配置、关键设计考虑），后手动扩缩容； - 手动扩缩容部分重写为设计思路（集群 ConfigMap 基线机制、单一变更维度约束、增量式调整、部署模式自适应、成功即刷新基线、前置校验），删除原文档中的代码级实现细节（具体函数名、报错文案、YAML 生成逻辑）。 3. **清理与链接同步**：删除两份旧文件，更新 user_guide/features/fault_tolerance/standby.md 中指向设计文档的链接。 4. **导航同步**：同步更新 docs/zh/.nav.yaml（docs 站点导航，由 mkdocs awesome-nav 加载，不更新则文档网页 404）： - 「主备倒换」设计文档条目：design/standby.md → design/fault_tolerance/standby.md； - 「手动扩缩容」设计条目（原文件已删除）：→ design/scaling.md，条目名改「扩缩容」； - 删除特性指南中已移走的 user_guide/features/auto_scaling.md 条目； - 顺带修复 2 处历史断链：release_note.md / communication_matrix.md 实际文件名带 _motor 后缀（release_note_motor.md / communication_matrix_motor.md）。 纯文档变更，无代码改动。 See merge request: Ascend/MindIE-Motor!679 | 17 天前 | |
[feature]mooncake standalone部署模式适配 Co-authored-by: WZN-JJB<wuzhineng@huawei.com> Co-authored-by: qq_46749096<qq_46749096@noreply.gitcode.com> # message auto-generated for no-merge-commit merge: !783 merge mooncake_standalone into master [feature]mooncake standalone部署模式适配 Created-by: qq_46749096 Commit-by: WZN-JJB;qq_46749096 Merged-by: towncharlie Description: ## **1. 合入背景** Mooncake 池化后端原仅有 in-process（embedded）模式：池化内存由引擎进程贡献，引擎故障则池内存失效，且大块内存与引擎权重 / KV 内存同进程竞争。本 PR 为 mooncake 池化后端适配 **standalone 部署模式**：由 NodeManager 在每个引擎 Pod 内拉起独立 mooncake_store_service 进程贡献池化内存，与引擎生命周期解耦，引擎仅作为纯请求方。 Fixes #511 ## **2. 修改内容** 1. 新增 motor/node_manager/core/services/mooncake/（lifecycle.py + bootstrap/ + __init__.py）：通过 service registry 注册 backend="mooncake" 的 KV store 服务，管理 mooncake_store_service 子进程生命周期： - prepare 阶段只生成 store 配置（mooncake_store_config.json，local_hostname 取 POD_IP、master 地址取 KVS_MASTER_SERVICE），不启动进程，避免引擎启动等待 store； - start 流程引擎拉起后（pull_kv_store）启动 store 进程；protocol=ascend 时经 bootstrap/ascend_800I.py / bootstrap/ascend_850.py 启动：进程内创建 ACL device context（store 自身不调用 aclrtSetDevice），**保持 comm-free 不建 HCCL comm**（store 与引擎 worker 同节点同卡时，comm 会使 adxl P2P 握手合并 ranktable 出现重复 device IP，HCCL 校验报 EI0014）；bootstrap 初始化失败非致命（stderr 告警后 store 照常启动）； - store 通信环境自动配置：HIXL comm_resource_config.listen_port=26666（merge 进 ASCEND_GLOBAL_RESOURCE_CONFIG，保留 UBOE protocol_desc 等既有项），使 store 在 ranktable 中携带独立 device_port，与同卡 worker 区分；HCCL socket 端口段避开引擎（A2：HCCL_NPU_SOCKET_PORT_RANGE=16700-16800；A5：host socket 段 +2000），防止与引擎 16666/RA socket 冲突（EI0020）；REST 端口默认 0 由内核分配临时端口（hostNetwork 同机端口安全）； - health_check 监视进程，死亡即原地重拉并重新注册 master（受 MOTOR_RESTART_LOCAL_SERVICE 控制，默认开启）； 2. motor/config/node_manager.py：KVCacheStoreConfig 新增 store_mode / global_segment_size / local_buffer_size / store_http_port / metadata_server / protocol / device_name 配置项及解析、校验（store_mode 非法值回退 embedded）、配置打印； 3. motor/common/utils/env.py：新增 MOONCAKE_CONFIG_PATH 环境变量； 4. motor/node_manager/core/services/registry.py：注册 mooncake 服务模块； 5. 资料变更：mooncake.md 新增 standalone 模式章节与环境变量说明、kv_cache_store README 参数表更新、nodeman.md 引用同步。 ## **3. 资料变更** 涉及： - docs/zh/user_guide/features/kv_cache_store/backend/mooncake.md：新增「standalone 模式（独立 store 进程）」章节（部署架构、P/D 配置示例、字段说明）；环境变量章节明确所有硬件必配 HCCL_INTRA_ROCE_ENABLE=1 与 ASCEND_LOCAL_COMM_RES={"version":"1.3"}（v1.3 格式本地通信资源，走 client-server 单边通信，ranktable 携带 device_port，是同卡多进程建链的前提，缺失报 EI0014）；补充 store 侧通信环境由 NodeManager 自动配置、无需手工干预的说明； - docs/zh/user_guide/features/kv_cache_store/README.md：参数表新增 store_mode / local_buffer_size / store_http_port； - .agent/skills/motor-dev/references/nodeman.md：同步更新。 ## **4. 接口变更** 涉及（客户面可见配置接口变更，已在资料中体现）： - kv_cache_store_config 新增字段：store_mode（""/embedded/standalone，默认 embedded）、global_segment_size、local_buffer_size、store_http_port（默认 0）、metadata_server、protocol、device_name； - 新增可选环境变量 MOONCAKE_CONFIG_PATH； - env.json 引擎角色（motor_engine_prefill_env / motor_engine_decode_env）新增必配项：HCCL_INTRA_ROCE_ENABLE=1、ASCEND_LOCAL_COMM_RES={"version":"1.3"}（所有硬件，Prefill/Decode 保持一致）。 ## **5. 测试结果** - **UT**（bash tests/run_tests.sh）：新增 tests/node_manager/core/services/mooncake/test_lifecycle.py（覆盖 prepare 配置生成、pull 幂等启动、stop、health_check 原地重拉、非 standalone 模式不拉起、store listen_port merge 覆盖等场景）与 tests/node_manager/core/services/mooncake/test_store_bootstrap.py（覆盖两个 bootstrap 的 ACL context 初始化与失败非致命）；tests/node_manager/test_config.py、tests/node_manager/core/services/test_registry.py 同步更新，模块 23 个用例全部通过，pre-commit 全绿。 - **实机验证**（800I A2，P/D 分离 standalone 部署）：基础推理正常；>128 token 请求触发入池，prefill 入池 / decode 出池正常（重复请求 kvpool hit tokens: 256, need to load: 0，decode External prefix cache hit rate 100%）；store 与 worker 同卡共存无 EI0014/EI0020；kill 掉 store 进程后 NodeManager 原地重拉成功。 ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!783 | 3 天前 | |
[feature] 示例与文档默认 KV Connector 切换为 MooncakeConnectorV1 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !769 merge bugfix/layerwise2v1 into master [feature] 示例与文档默认 KV Connector 切换为 MooncakeConnectorV1 Created-by: Jechin Commit-by: Jechin Merged-by: tobking Description: ## **1. 合入背景** Fixes [#502](https://gitcode.com/Ascend/MindIE-Motor/issues/502) 产品侧确定 MooncakeConnectorV1 为 PD KV 传输主推方案，需将官方示例与用户文档中的默认 Connector 从 MooncakeLayerwiseConnector 统一切换为 V1，避免新用户按示例部署时仍使用 Layerwise。 ## **2. 修改内容** 1. **示例配置**（examples/infer_engines/vllm/） - user_config.json、user_config_pd_hetero.json、single_container/user_config.json 中 Prefill/Decode 的 kv_connector 改为 MooncakeConnectorV1 2. **用户指南文档** - docs/zh/user_guide/configuration/config_reference.md：PD 混部与 PD 分离配置示例同步更新 - docs/zh/user_guide/quick_start_motor.md：快速入门 PD 配置示例同步更新 - docs/zh/user_guide/features/EPD_disaggregation.md：EPD 分离配置示例同步更新 - docs/zh/user_guide/features/tracing.md：Tracing 场景配置示例同步更新 ## **3. 资料变更** 涉及，均为上述文档与示例 JSON 中 kv_connector 默认值变更。 ## **4. 接口变更** 不涉及跨代码仓或客户面 API 变更；仅示例与文档中的配置项默认值调整。 ## **5. 测试结果** （自行补充） ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!769 | 10 天前 | |
支持引擎原生拉起：删除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 | 11 天前 | |
支持引擎原生方式拉起：Coordinator 支持独立部署 Co-authored-by: tobking<wangjun292@huawei.com> # message auto-generated for no-merge-commit merge: !771 merge feat/coordinator-standalone-deploy-guide into master 支持引擎原生方式拉起：Coordinator 支持独立部署 Created-by: tobking Commit-by: tobking Merged-by: towncharlie Description: ## **1. 合入背景** 引擎改为由 NodeManager 原生拉起 vLLM/SGLang、Engine Server 下线后，Endpoint、配置及注册路径中仍残留不再使用的 mgmt_port 控制面字段。同时，已有原生 Prefill/Decode 引擎的用户需要一种不依赖 Controller、NodeManager 和 Kubernetes、仅部署 Coordinator 的 PD 调度方式。 本 PR 清理废弃字段，补齐 Coordinator 独立部署、实例管理和管理面安全能力，并根据检视意见加固实例注册一致性。 关联 ISSUE：#394。 ## **2. 修改内容** 1. **清理废弃控制面字段** - 从 Endpoint、配置、NodeManager 注册/心跳、Controller 组装及相关测试中删除 mgmt_port / mgmt_ports。 - Endpoint 不再吞掉未知参数；mgmt_port、拼写错误字段等直接校验失败。 - Controller、Coordinator、NodeManager 需同步升级，不支持混合版本。 2. **Coordinator 独立部署与注册 CLI** - 新增 python3 -m motor.coordinator.register，支持 set、add、del、list。 - 实例 ID 使用独立高位命名空间，由 role 与排序后的完整 endpoint 组派生；endpoint 输入顺序不影响 ID、job name 和 endpoint ID。 - CLI 提交前查询 GET /instances 检查已有冲突；按 endpoint 或 ID 删除时先获取真实注册身份，未知 ID 拒绝删除。 - /v1/models 返回空列表时判定为不健康；可通过 --no-health-check 显式跳过探测。 3. **实例管理一致性加固** - InstanceManager 在全部角色和状态池中保证实例 ID 全局唯一。 - SET 请求内重复 ID 返回 400；ADD 的同 ID 异身份冲突返回 409；DEL 校验角色、名称和 endpoint 身份。 - Scheduler 接受刷新后才更新管理面镜像，避免两侧状态不一致。 - endpoint 匹配改为顺序无关，并通过惰性导出消除 Coordinator models/domain 循环导入。 4. **Controller 最终一致性兜底** - ADD、DEL、PAUSE、RESUME 增量刷新失败时，合并排队一次全量 SET 对账。 - SET 失败不递归排队，也不更新已同步指纹。 5. **管理面安全与可观测性** - 新增 GET /instances，汇总 available、unavailable、paused 实例摘要。 - 管理面支持独立 API Key 文件；对外监听时可使用 X-Motor-Management-Key 保护管理接口。 - 独立部署主流程默认监听 127.0.0.1，跨主机、Docker、Kubernetes 监听和 API Key 配置移至附录。 6. **依赖约束** - 对齐 grpcio/grpcio-tools/protobuf 生成与运行时版本。 - FastAPI 最低版本提升至 0.100.0；Pydantic 限定为 >=2.0.0,<3.0.0。 ## **3. 资料变更** 涉及资料变更： - 新增 docs/zh/user_guide/deployment/standalone.md，并补充部署导航入口。 - 管理接口文档补充 GET /instances、管理 API Key 和同步升级要求。 - 配置参考、NodeManager、Controller、Coordinator 开发资料同步删除废弃字段并说明注册一致性机制。 ## **4. 接口变更** 涉及客户面可见接口变更： - Endpoint 注册协议删除 mgmt_port，未知字段严格拒绝；所有组件必须同步升级。 - Coordinator 管理面新增 GET /instances。 - Coordinator 管理面可配置独立 API Key，请求使用 X-Motor-Management-Key。 - 新增独立部署注册命令 python3 -m motor.coordinator.register。 ## **5. 测试结果** - Controller 事件兜底、注册 CLI、服务端实例冲突及删除校验联合回归：122 passed。 - Endpoint/Instance 严格字段校验：25 passed。 - 最终直接受影响测试复跑：49 passed。 - Ruff 静态检查及 git diff --check 通过。 - 本次改动集中在管理面、注册和资料路径，不涉及模型精度、显存或硬件性能变化。 ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有 UT 用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!771 | 4 天前 | |
[docs] 补充自动弹性扩缩容文档 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !490 merge docs/auto_scaler into master [docs] 补充自动弹性扩缩容文档 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ## **1. 合入背景** https://gitcode.com/Ascend/MindIE-PyMotor/issues/290 补充自动弹性扩缩容功能使用文档 ## **2. 修改内容** 补充自动弹性扩缩容功能使用文档 ## **3. 资料变更** 涉及 ## **4. 接口变更** 不涉及 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!490 | 1 个月前 | |
[bugfix] ZJ部署过程遇到的若干问题Bug Co-authored-by: zhoujing101<zhoujing101@huawei.com> # message auto-generated for no-merge-commit merge: !842 merge zijie_to_master into master [bugfix] ZJ部署过程遇到的若干问题Bug Created-by: zhoujing101 Commit-by: zhoujing101 Merged-by: tobking Description: https://gitcode.com/Ascend/MindIE-Motor/issues/530 ## **1. 合入背景** 本次 PR 主要解决流式推理场景下 infer_timeout 超时配置未生效的问题：原超时仅作用于单次转发，流式响应由 uvicorn 在 handler 返回后继续发送，timeout_handler 装饰器无法约束整个流式请求的 E2E 时长。同时修复流式超时后的日志与错误信息展示、重复 Event.SET 误清理熔断器、以及 max_tokens 入参合法性校验缺失等问题。 ## **2. 修改内容** 1. **流式整体超时（infer_timeout E2E）**：BaseRouter 新增 _stream_overall_timeout()，自请求到达时间（ReqState.ARRIVE）起计算 infer_timeout 剩余预算并下发给 CommitAwareStreamingResponse；后者新增 timeout 参数，通过 loop.call_later 设置整体墙钟截止时间，超时后以 INFER_TIMEOUT 原因取消当前任务，使取消原因级联透传到上游生成器；超时后 commit 前返回 JSON 504、commit 后通过 SSE 发送 504 错误帧。PD 混合路由与 Unified PD 路由均接入该机制。 2. **流式超时日志与错误信息**：motor/common/utils/error.py 新增 INFER_TIMEOUT 取消原因；check_cancel_error 识别该原因不再归为通用 Exception；AttemptStopReason 新增 TIMEOUT，Unified PD 路由将 INFER_TIMEOUT 映射为 TIMEOUT，超时后日志与返回错误信息正确体现"超时"。 3. **重复 Event.SET 不处理**：_SchedulerRequestDispatcher 仅当实例刷新有变化（changed=True）时才快照并清理熔断器，重复 SET 事件不再误清熔断器。 4. **max_tokens 入参合法性校验**：OpenAI 请求校验新增 _validate_positive_int_field，max_tokens/max_completion_tokens 为非正整数（0、负数、布尔、非 int）时从请求体移除并记录 warning，避免非法参数透传引擎。 5. **门禁修复**：修复 test_ccae_motor_backend.py 缺失 Log mock 导致的门禁问题，并补充上述功能的 UT 用例。 ## **3. 资料变更** 涉及：docs/zh/user_guide/configuration/config_reference.md 更新 infer_timeout 字段说明——非流式场景作用于单次转发；流式场景作为整个流式请求的整体墙钟超时（从请求到达算起，超时后中断并返回 504）。 ## **4. 接口变更** 不涉及跨代码仓或客户面可见的接口变更。流式超时返回码与既有约定一致（504 Gateway Timeout），未改变对外 API 形态。 ## **5. 测试结果** 新增/更新 UT 用例（通过 bash tests/run_tests.sh 全量验证，含 pre-commit 门禁）： - test_stream_response.py：流式整体超时取消上游（取消原因为 INFER_TIMEOUT）、commit 前返回 JSON 504、commit 后 SSE 发送 504 错误帧、预提交/已提交场景 RequestCancelledError(INFER_TIMEOUT) 均返回 504； - test_base_router_request_timeout.py：_stream_overall_timeout 剩余预算计算（满预算、扣除已用时间、超期归零、无 ARRIVE 时间兜底）； - test_cancel_error.py：INFER_TIMEOUT 原因识别与 RequestCancelledError 携带该原因； - test_unified_pd_router.py：INFER_TIMEOUT 映射为 AttemptStopReason.TIMEOUT； - test_http_server.py：_validate_positive_int_field 对 max_tokens/max_completion_tokens 合法值保留、非法值移除并告警； - test_scheduler_server_main.py：重复 SET 无变化不清熔断器、有变化仍快照并清理； - test_ccae_motor_backend.py：补充 Log mock 修复门禁。 测试维度覆盖：功能（流式超时、参数校验、熔断器行为）、错误码（504 返回路径）、并发场景（超时取消与流式任务并发，无死锁）。  ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!842 | 5 小时前 | |
[文档] 环境准备与快速入门文档可读性优化 Co-authored-by: weixin_63825906<gaopeng140@huawei.com> # message auto-generated for no-merge-commit merge: !348 merge master into master [文档] 环境准备与快速入门文档可读性优化 Created-by: weixin_63825906 Commit-by: weixin_63825906 Merged-by: towncharlie Description: ## **1. 合入背景** > 文档易读性需要改进 Fixes [#223](https://gitcode.com/Ascend/MindIE-PyMotor/issues/223) ## **2. 修改内容** > 重写quick_start，优化整体结构 ## **3. 资料变更** > 涉及 ## **4. 接口变更** > 不涉及 ## **5. 测试结果** > 正常拉起  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!348 | 1 个月前 | |
[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 | 1 个月前 | |
[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 | 10 天前 | |
[docs]刷新D2D特性说明文档 Co-authored-by: yilunh<hanyilun1@huawei.com> # message auto-generated for no-merge-commit merge: !627 merge D2D into master [docs]刷新D2D特性说明文档 Created-by: yilunh Commit-by: yilunh Merged-by: towncharlie Description: ## **1. 合入背景** 刷新D2D特性说明文档 fixes [#370](https://gitcode.com/Ascend/MindIE-Motor/issues/370) ## **2. 修改内容** 1、刷新配置int8_cache配置建议值，默认使用no cache直通 2、MTP叠加时建议端口预留，防止端口非法，elastic server无法启动 3、刷新支持的模型 4、刷新文档位置至docs/user_guide/features ## **3. 资料变更** 否 ## **4. 接口变更** > 请确认<ins>**是否涉及跨代码仓或者客户面可见的接口变更**</ins>。\ > 如涉及，需详细说明接口以及对应的变更内容，同时需要在资料中体现。\ > 如不涉及，需填写“不涉及”。 ## **5. 测试结果** 否 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!627 | 18 天前 | |
支持引擎原生拉起：删除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 | 11 天前 | |
[feature] 示例与文档默认 KV Connector 切换为 MooncakeConnectorV1 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !769 merge bugfix/layerwise2v1 into master [feature] 示例与文档默认 KV Connector 切换为 MooncakeConnectorV1 Created-by: Jechin Commit-by: Jechin Merged-by: tobking Description: ## **1. 合入背景** Fixes [#502](https://gitcode.com/Ascend/MindIE-Motor/issues/502) 产品侧确定 MooncakeConnectorV1 为 PD KV 传输主推方案，需将官方示例与用户文档中的默认 Connector 从 MooncakeLayerwiseConnector 统一切换为 V1，避免新用户按示例部署时仍使用 Layerwise。 ## **2. 修改内容** 1. **示例配置**（examples/infer_engines/vllm/） - user_config.json、user_config_pd_hetero.json、single_container/user_config.json 中 Prefill/Decode 的 kv_connector 改为 MooncakeConnectorV1 2. **用户指南文档** - docs/zh/user_guide/configuration/config_reference.md：PD 混部与 PD 分离配置示例同步更新 - docs/zh/user_guide/quick_start_motor.md：快速入门 PD 配置示例同步更新 - docs/zh/user_guide/features/EPD_disaggregation.md：EPD 分离配置示例同步更新 - docs/zh/user_guide/features/tracing.md：Tracing 场景配置示例同步更新 ## **3. 资料变更** 涉及，均为上述文档与示例 JSON 中 kv_connector 默认值变更。 ## **4. 接口变更** 不涉及跨代码仓或客户面 API 变更；仅示例与文档中的配置项默认值调整。 ## **5. 测试结果** （自行补充） ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!769 | 10 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 17 天前 | ||
| 3 天前 | ||
| 10 天前 | ||
| 11 天前 | ||
| 4 天前 | ||
| 1 个月前 | ||
| 5 小时前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 10 天前 | ||
| 18 天前 | ||
| 11 天前 | ||
| 10 天前 |