| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[doc]docker only文档优化 Co-authored-by: ganglv<lvgang1@huawei.com> # message auto-generated for no-merge-commit merge: !481 merge docker_only into master [doc]docker only文档优化 Created-by: ganglv Commit-by: ganglv Merged-by: towncharlie Description: ## **1. 合入背景** 当前 docker-only 部署指导和基于 vllm-ascend/sglang 基础镜像安装 Motor 的文档步骤不够清晰，离线依赖准备、容器启动脚本、configmap 目录组织等信息需要补充完善。 同时，deployer 在生成节点选择器时从集群节点获取 accelerator-type 的逻辑未结合用户配置的 hardware_type，在集群同时存在 A2/A3/A5 等不同硬件标签时，可能选取到不匹配的 accelerator-type，影响部署 YAML 中节点调度标签的准确性。 暂无关联 issue。 ## **2. 修改内容** 1. 优化 docs/zh/developer_guide/build_motor_image_from_vllm_ascend.md，补充基于 vllm-ascend/sglang 镜像安装 Motor 的在线/离线依赖下载、Motor whl 构建、pciutils 安装、镜像保存和导入流程。 2. 优化 docs/zh/user_guide/deployment/docker/single_container.md，补充 docker-only 部署目录结构、examples 准备方式、configmap 生成流程、start_motor.sh 与 start_docker.sh 示例，并明确 mooncake 池化相关环境变量说明。 3. 调整 deployer 获取 accelerator-type 的实现： - get_accelerator_type_from_cluster 新增 hardware_type 入参； - A2/A3 场景按 accelerator=huawei-Ascend910 过滤节点，并根据 hardware_type 匹配对应代际的 accelerator-type； - A5 场景按 accelerator=huawei-AscendA5,accelerator-type=<hardware_type> 精确过滤； - 缓存 key 从通用 accelerator-type 调整为 hardware_type，避免不同硬件类型复用错误结果； - 当无匹配节点、缺少标签、存在多个无法确定的匹配值时抛出明确异常。 4. 更新 config_validator.py 和 engine.py 中的调用链，生成硬件节点标签和 engine pod nodeSelector 时均传入 hardware_type，并补充 A2/A3 的 accelerator=huawei-Ascend910 标签设置。 5. 补充和调整 UT，覆盖 A2/A3/A5 的 accelerator-type 解析、缓存命中、标签缺失、硬件代际不匹配等场景，并同步更新相关 mock 签名。 ## **3. 资料变更** 涉及。 本 PR 修改了以下资料： - docs/zh/developer_guide/build_motor_image_from_vllm_ascend.md - docs/zh/user_guide/deployment/docker/single_container.md 主要补充 docker-only 部署、基础镜像安装 Motor、在线/离线依赖准备、启动脚本和环境变量说明。 ## **4. 接口变更** 不涉及跨代码仓或者客户面可见的接口变更。 本 PR 仅调整 deployer 内部函数 get_accelerator_type_from_cluster 的调用方式和实现逻辑，不新增或修改对外 API。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!481 | 1 个月前 | |
[doc]docker only文档优化 Co-authored-by: ganglv<lvgang1@huawei.com> # message auto-generated for no-merge-commit merge: !481 merge docker_only into master [doc]docker only文档优化 Created-by: ganglv Commit-by: ganglv Merged-by: towncharlie Description: ## **1. 合入背景** 当前 docker-only 部署指导和基于 vllm-ascend/sglang 基础镜像安装 Motor 的文档步骤不够清晰，离线依赖准备、容器启动脚本、configmap 目录组织等信息需要补充完善。 同时，deployer 在生成节点选择器时从集群节点获取 accelerator-type 的逻辑未结合用户配置的 hardware_type，在集群同时存在 A2/A3/A5 等不同硬件标签时，可能选取到不匹配的 accelerator-type，影响部署 YAML 中节点调度标签的准确性。 暂无关联 issue。 ## **2. 修改内容** 1. 优化 docs/zh/developer_guide/build_motor_image_from_vllm_ascend.md，补充基于 vllm-ascend/sglang 镜像安装 Motor 的在线/离线依赖下载、Motor whl 构建、pciutils 安装、镜像保存和导入流程。 2. 优化 docs/zh/user_guide/deployment/docker/single_container.md，补充 docker-only 部署目录结构、examples 准备方式、configmap 生成流程、start_motor.sh 与 start_docker.sh 示例，并明确 mooncake 池化相关环境变量说明。 3. 调整 deployer 获取 accelerator-type 的实现： - get_accelerator_type_from_cluster 新增 hardware_type 入参； - A2/A3 场景按 accelerator=huawei-Ascend910 过滤节点，并根据 hardware_type 匹配对应代际的 accelerator-type； - A5 场景按 accelerator=huawei-AscendA5,accelerator-type=<hardware_type> 精确过滤； - 缓存 key 从通用 accelerator-type 调整为 hardware_type，避免不同硬件类型复用错误结果； - 当无匹配节点、缺少标签、存在多个无法确定的匹配值时抛出明确异常。 4. 更新 config_validator.py 和 engine.py 中的调用链，生成硬件节点标签和 engine pod nodeSelector 时均传入 hardware_type，并补充 A2/A3 的 accelerator=huawei-Ascend910 标签设置。 5. 补充和调整 UT，覆盖 A2/A3/A5 的 accelerator-type 解析、缓存命中、标签缺失、硬件代际不匹配等场景，并同步更新相关 mock 签名。 ## **3. 资料变更** 涉及。 本 PR 修改了以下资料： - docs/zh/developer_guide/build_motor_image_from_vllm_ascend.md - docs/zh/user_guide/deployment/docker/single_container.md 主要补充 docker-only 部署、基础镜像安装 Motor、在线/离线依赖准备、启动脚本和环境变量说明。 ## **4. 接口变更** 不涉及跨代码仓或者客户面可见的接口变更。 本 PR 仅调整 deployer 内部函数 get_accelerator_type_from_cluster 的调用方式和实现逻辑，不新增或修改对外 API。 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!481 | 1 个月前 | |
修复 A2 上 sp-block 删除整个 annotations 问题 Co-authored-by: jingyp<jingyp@chinatelecom.cn> # message auto-generated for no-merge-commit merge: !644 merge bugfix/fix-sp-block-annotations into master 修复 A2 上 sp-block 删除整个 annotations 问题 Created-by: gcw_gxG14I7x Commit-by: jingyp Merged-by: towncharlie Description: ## **1. 合入背景** Fixes https://gitcode.com/Ascend/MindIE-Motor/issues/377 ## **2. 修改内容** A2 上仅删除可能的 sp-block annotation，不影响其他 ## **3. 资料变更** 无 ## **4. 接口变更** 不涉及 ## **5. 测试结果** 修复前：  修复后：  ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!644 | 16 天前 | |
[refractor]重构motor与memcache的交互逻辑 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !530 merge feat/memcache_ssd into master [refractor]重构motor与memcache的交互逻辑 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: tobking Description: ## **1. 合入背景** https://gitcode.com/Ascend/MindIE-Motor/issues/353 ## **2. 修改内容** 1、完全重构motor与memcache的对接逻辑，解耦组件的交互 2、local service独立为单独的进程，由daemon拉起，提升拉起速度 ## **3. 资料变更** 涉及 ## **4. 接口变更** 不涉及 ## **5. 测试结果** 使用新拉起方式后A3拉起正常（standalone） HELP motor:prompt_tokens_per_second Prompt tokens per second computed from vllm:prompt_tokens_total counter deltas # TYPE motor:prompt_tokens_per_second gauge motor:prompt_tokens_per_second 0.0 # HELP motor:generation_tokens_per_second Generation tokens per second computed from vllm:generation_tokens_total counter deltas # TYPE motor:generation_tokens_per_second gauge motor:generation_tokens_per_second 0.0 # HELP vllm:prefix_cache_hit_rate Prefix cache hit rate (cached tokens / queried tokens). # TYPE vllm:prefix_cache_hit_rate gauge vllm:prefix_cache_hit_rate 0.0 # HELP motor:active_prefill_workers Number of active prefill instances # TYPE motor:active_prefill_workers gauge motor:active_prefill_workers 1 # HELP motor:active_decode_workers Number of active decode instances # TYPE motor:active_decode_workers gauge motor:active_decode_workers 1 # HELP motor:inactive_prefill_workers Number of inactive prefill instances # TYPE motor:inactive_prefill_workers gauge motor:inactive_prefill_workers 0 # HELP motor:inactive_decode_workers Number of inactive decode instances # TYPE motor:inactive_decode_workers gauge motor:inactive_decode_workers 0 # HELP kv_store_size KV store size in GB (layer=cpu|ssd|all, stat=usage|total) # TYPE kv_store_size gauge kv_store_size{layer="cpu",stat="usage"} 0.0 kv_store_size{layer="cpu",stat="total"} 64.0 kv_store_size{layer="ssd",stat="usage"} 0.0 kv_store_size{layer="ssd",stat="total"} 0.0 kv_store_size{layer="all",stat="usage"} 0.0 kv_store_size{layer="all",stat="total"} 64.0 # HELP kv_store_ratio KV store used ratio 0-1 (layer=cpu|ssd|all, stat=usage_rate) # TYPE kv_store_ratio gauge kv_store_ratio{layer="cpu",stat="usage_rate"} 0.0 kv_store_ratio{layer="ssd",stat="usage_rate"} 0.0 kv_store_ratio{layer="all",stat="usage_rate"} 0.0 # HELP kv_store_keys KV store number of stored keys # TYPE kv_store_keys gauge kv_store_keys 0.0 # HELP kv_store_eviction KV store eviction counters (stat=success|attempts) # TYPE kv_store_eviction gauge kv_store_eviction{stat="success"} 0.0 kv_store_eviction{stat="attempts"} 0.0 # HELP motor:memcache_segment_capacity_bytes Segment total capacity in bytes # TYPE motor:memcache_segment_capacity_bytes gauge motor:memcache_segment_capacity_bytes{segment="rank-0-dram"} 17179869184 motor:memcache_segment_capacity_bytes{segment="rank-1-dram"} 17179869184 # HELP motor:memcache_segment_allocated_bytes Segment allocated bytes # TYPE motor:memcache_segment_allocated_bytes gauge motor:memcache_segment_allocated_bytes{segment="rank-0-dram"} 0 motor:memcache_segment_allocated_bytes{segment="rank-1-dram"} 0 # HELP motor:memcache_total_capacity_bytes Total capacity by medium in bytes # TYPE motor:memcache_total_capacity_bytes gauge motor:memcache_total_capacity_bytes{medium="hbm"} 0 motor:memcache_total_capacity_bytes{medium="dram"} 34359738368 # HELP motor:memcache_allocated_bytes Allocated bytes by medium 压测性能： ╒══════════════════════════╤═════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤═════╕ │ Performance Parameters │ Stage │ Average │ Min │ Max │ Median │ P75 │ P90 │ P99 │ N │ ╞══════════════════════════╪═════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪═════╡ │ E2EL │ total │ 6848.4 ms │ 4251.6 ms │ 7985.9 ms │ 7590.0 ms │ 7717.7 ms │ 7879.3 ms │ 7975.2 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ TTFT │ total │ 422.2 ms │ 253.7 ms │ 733.2 ms │ 369.6 ms │ 486.8 ms │ 637.4 ms │ 723.6 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ TPOT │ total │ 14.4 ms │ 14.1 ms │ 14.5 ms │ 14.4 ms │ 14.5 ms │ 14.5 ms │ 14.5 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ ITL │ total │ 14.3 ms │ 0.0 ms │ 62.8 ms │ 13.8 ms │ 14.1 ms │ 15.3 ms │ 27.8 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ InputTokens │ total │ 1491.5 │ 1460.0 │ 1545.0 │ 1490.5 │ 1499.25 │ 1515.6 │ 1542.06 │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ OutputTokens │ total │ 448.375 │ 245.0 │ 512.0 │ 512.0 │ 512.0 │ 512.0 │ 512.0 │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────┤ │ OutputTokenThroughput │ total │ 65.0576 token/s │ 57.6249 token/s │ 68.1729 token/s │ 65.8792 token/s │ 66.6954 token/s │ 67.1812 token/s │ 68.0737 token/s │ 8 │ ╘══════════════════════════╧═════════╧═════════════════╧═════════════════╧═════════════════╧═════════════════╧═════════════════╧═════════════════╧═════════════════╧═════╛ inprocess 模式测试如下： # HELP motor:memcache_segment_capacity_bytes Segment total capacity in bytes # TYPE motor:memcache_segment_capacity_bytes gauge motor:memcache_segment_capacity_bytes{segment="rank-0-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-1-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-2-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-3-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-4-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-5-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-6-dram"} 2147483648 motor:memcache_segment_capacity_bytes{segment="rank-7-dram"} 2147483648 # HELP motor:memcache_segment_allocated_bytes Segment allocated bytes # TYPE motor:memcache_segment_allocated_bytes gauge motor:memcache_segment_allocated_bytes{segment="rank-0-dram"} 12582912 motor:memcache_segment_allocated_bytes{segment="rank-1-dram"} 37748736 motor:memcache_segment_allocated_bytes{segment="rank-2-dram"} 37748736 motor:memcache_segment_allocated_bytes{segment="rank-3-dram"} 25165824 motor:memcache_segment_allocated_bytes{segment="rank-4-dram"} 50331648 motor:memcache_segment_allocated_bytes{segment="rank-5-dram"} 44040192 motor:memcache_segment_allocated_bytes{segment="rank-6-dram"} 56623104 motor:memcache_segment_allocated_bytes{segment="rank-7-dram"} 25165824 # HELP motor:memcache_total_capacity_bytes Total capacity by medium in by 压测性能一致 ``` ╒══════════════════════════╤═════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤═════════════════╤════════════════╤═════════════════╤═════╕ │ Performance Parameters │ Stage │ Average │ Min │ Max │ Median │ P75 │ P90 │ P99 │ N │ ╞══════════════════════════╪═════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪═════════════════╪════════════════╪═════════════════╪═════╡ │ E2EL │ total │ 6847.9 ms │ 4285.2 ms │ 8056.9 ms │ 7528.6 ms │ 7755.3 ms │ 7959.6 ms │ 8047.2 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼────────────────┼─────────────────┼─────┤ │ TTFT │ total │ 431.8 ms │ 259.8 ms │ 723.0 ms │ 414.1 ms │ 458.9 ms │ 614.0 ms │ 712.1 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼────────────────┼─────────────────┼─────┤ │ TPOT │ total │ 14.4 ms │ 13.9 ms │ 14.7 ms │ 14.4 ms │ 14.7 ms │ 14.7 ms │ 14.7 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼────────────────┼─────────────────┼─────┤ │ ITL │ total │ 14.3 ms │ 0.0 ms │ 71.6 ms │ 13.8 ms │ 14.2 ms │ 15.4 ms │ 24.7 ms │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼────────────────┼─────────────────┼─────┤ │ InputTokens │ total │ 1491.5 │ 1460.0 │ 1545.0 │ 1490.5 │ 1499.25 │ 1515.6 │ 1542.06 │ 8 │ ├──────────────────────────┼─────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼─────────────────┼────────────────┼─────────────────┼─────┤ │ OutputTokens │ total │ 448.375 │ 245.0 │ 512.0 │ 512.0 │ 512.0 │ 512.0 │ 512.0 │ 8 │ ├──────────────────────────┼─────────┼── See merge request: Ascend/MindIE-Motor!530 | 24 天前 | |
[feature] 多kv池化后端支持 Co-authored-by: 吕有辉<lvyouhui@huawei.com> # message auto-generated for no-merge-commit merge: !382 merge memcache into master [feature] 多kv池化后端支持 Created-by: codeDogPro Commit-by: 吕有辉 Merged-by: towncharlie Description: ## **1. 合入背景** 适配多个池化后端【当前PR适配Memcache，yuanrong后端后续支持】 ## **2. 修改内容** 1、特性文档优化，多后端可拓展 2、startup脚本抽象kv_store_backends/，提升可维护性 3、添加memcache的metaservice，local service的脚本支持； 4、A2的聚合拉起；A3，A5的聚合、分离拉起local service的能力支持 ## **3. 资料变更** 设计 ## **4. 接口变更** 不涉及 ## **5. 测试结果** 能正常拉起memcache池化，压测请求无报错。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!382 | 1 个月前 | |
[bugfix] deployer NodePort 冲突检测：CRD 重命名 Service 误判导致扩缩容失败 Co-authored-by: yangan7<yangan7@h-partners.com> # message auto-generated for no-merge-commit merge: !776 merge fix/nodeport-crd-self-owned into master [bugfix] deployer NodePort 冲突检测：CRD 重命名 Service 误判导致扩缩容失败 Created-by: mindie_yangan Commit-by: yangan7 Merged-by: towncharlie Description: ### 问题 服务部署成功后执行 --update_instance_num 扩缩容，NodePort 冲突检测会把**本服务自己占用的端口**判为冲突，导致交互改端口或报冲突，扩缩容拉不起来。 Related Issue：https://gitcode.com/Ascend/MindIE-Motor/issues/506 ### 根因 _is_self_owned 只认「同 namespace + Service 名完全相同」。但 InferServiceSet 模式下 CRD 会重命名 Service： text {service_name}-{InferServiceSet 名}-{索引}-{role} 例：mindie-motor-coordinator-infer -> mindie-motor-coordinator-infer-vllm-0-coordinator 集群里的实际名字与生成 yaml 中声明的短名永远不相等，自有端口因此被误判为他人占用。首次部署时集群还没有这些端口，检测通过，问题只在重复部署 / 扩缩容时暴露。 ### 修改 - PlannedNodePort 增加 infer_set_name / role_name，解析 InferServiceSet 时记录 CRD 上下文 - _is_self_owned 在名字完全相同之外，额外匹配 CRD 命名规则；索引用 \\d+ 而非写死 -0-，兼容 InferServiceSet 副本数大于 1 - 跨 namespace 判断不变，他人占用的端口仍正常报冲突 - README 补充自有端口与 CRD 命名说明 ### 测试 tests/examples/deployer/test_nodeport_allocator.py 新增 1 条端到端用例：模拟服务已运行、三个 NodePort 均被本服务的 CRD Service 占用，断言不弹窗、不改写端口。 用例强制 sys.stdin.isatty() 为 True 走交互路径，修复被回退时会因弹窗而失败；其中一个 Service 使用非 0 索引，覆盖副本数大于 1 的命名。 See merge request: Ascend/MindIE-Motor!776 | 11 小时前 | |
[Feature] 增加云原生部署器 Co-authored-by: sceneryback<afterbreeze@hotmail.com> # message auto-generated for no-merge-commit merge: !67 merge feature/add-deployer into master [Feature] 增加云原生部署器 Created-by: gcw_gxG14I7x Commit-by: sceneryback Merged-by: zhoujing101 Description: ## **1. 合入背景** 本次改动提供一套面向 examples/deployer/deploy.py 的云原生部署方式。它的目标是让部署过程不再依赖人工登录宿主机，也不依赖宿主机上的本地配置文件，而是能够被云平台直接触发。来自真实的云厂商部署需求，在内部平台已验证。 项目原始部署方式默认由运维人员登录某个 Kubernetes 节点，手工执行 examples/deployer/deploy.py，并从本地目录读取配置文件。 这种方式适合开发调试和人工验证，但在云平台场景下会遇到明显问题： * 集群通常是多租户的，同一集群内会并行部署多个推理服务，并通过 namespace 做隔离。 * 云平台用户不应被要求拥有节点登录权限。 * 部署请求通常来自平台控制面或 API，而不是人工在宿主机执行脚本。 * 交付物应该是容器镜像和 Kubernetes 清单，而不是依赖宿主机本地状态。 * 扩缩容、清理等动作也应该被表达为 Kubernetes Job，便于平台统一审计、重试和观测。 因此，这里把现有的部署逻辑封装成了适合容器执行的形式。对云平台而言，只需要两步： 1. 准备一个包含 user_config.json 和 env.json 的 ConfigMap。 2. 创建对应的 deploy / scale / cleanup Job。 底层真正执行部署的仍然是现有的 examples/deployer/deploy.py，这样可以保持与当前人工部署行为一致，同时把入口改造成云原生形态。示意如图：  Fixes https://gitcode.com/Ascend/MindIE-PyMotor/issues/345 ## **2. 修改内容** 本次仅涉及 deployer 部分。 1. 新增 examples/cloud_native_deploy 云原生部署目录，补齐 deployer 镜像 Dockerfile、deploy/scale/cleanup 入口脚本，以及对应的 Kubernetes Job、RBAC 和配置清单；同时将 user_config.json 与 env.json 统一封装进同一个 ConfigMap，并在 Job 中映射为容器内配置文件，使云平台可以通过 “ConfigMap + Job” 方式直接触发部署、扩缩容和清理，而不再依赖人工登录宿主机。 2. 在 user_config.json 中新增 scheduling_queue、coordinator_service_name、prefill_node_selector 和 decode_node_selector 等配置 3. 调整云原生 cleanup 逻辑，使用独立 cleanup.sh 按 namespace 清理集群资源，而不是依赖宿主机上的 output_yamls 4. 修正多服务并存时的 RBAC 冲突问题：保留共享的 ClusterRole，将生成出来的 ClusterRoleBinding 改为按 namespace 唯一化，并让 cleanup 只删除当前 namespace 对应的 binding，不再删除共享的 ClusterRole 5. 新增根目录 Makefile，统一提供 wheel 构建、云原生 deployer 镜像本地构建和 buildx 多架构推送入口，默认镜像仓库为 Docker Hub（在另一个 PR 提交）。 6. 新增 helm 部署，通过 helm install 一键部署，更符合云原生组件的部署规范 ## **3. 资料变更** 涉及部署方式变更，已描述 ## **4. 接口变更** 涉及 user_config.json 变更 ## **5. 测试结果** > 需体现<ins>**测试场景，测试方法以及测试结果**</ins>。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。 ## **6. CheckList** > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] [ ] 代码注释完备 [ ] 正确记录维测日志 [ ] 是否有UT用例 [ ] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!67 | 28 天前 | |
fix: multi_deployment 静态扩缩容基于集群 index 动态 list 统一扩缩容决策 Co-authored-by: lbr711<liuboru1@huawei.com> # message auto-generated for no-merge-commit merge: !686 merge pr/fix-static-scale into master fix: multi_deployment 静态扩缩容基于集群 index 动态 list 统一扩缩容决策 Created-by: lbr711 Commit-by: lbr711 Merged-by: towncharlie Description: ## **1. 合入背景** > multi_deployment 静态扩缩容原先扩/缩不对称：扩容部分看集群，缩容仍按配置 reversed(range(base)) 推断，Pending 场景会误删健康实例；稀疏 index 下扩容无法补洞、缩容可能删不到实际 Deployment。 > > 本 PR 以**集群实际 Deployment index 集合**为动态 list，统一 P/D/U 扩缩容 index 选择逻辑。 > > Fixes #454 ## **2. 修改内容** 1. 新增 get_pending_engine_instance_indices()：查询 Pending Pod 对应 index（无 idx < base 限制）。 2. 新增 compute_scale_in_delete_indices() / compute_scale_out_add_indices()：纯函数，基于 live index set 计算删/增列表。 3. 重构 get_instance_scale_in_delete_order()：删除数量 = len(现有) - target；删序 Pending 优先 → 高位优先；deployment 查询失败回退 reversed(range(base))。 4. 重构 get_instance_scale_out_indices()：在 [0, total) 内从低到高补缺失 index。 5. scale_engine_by_type() 中 P/D/U 接入上述逻辑；E 保持原有行为。 6. 扩展 UT tests/examples/deployer/test_scale_in.py（含稀疏 index 全链路、orphan 高位回收等场景）。 ## **3. 资料变更** 不涉及。 ## **4. 接口变更** 不涉及。 ## **5. 测试结果** - 部署方式：multi_deployment - 测试方法：pytest 单元测试 - 测试场景： 1. Pending 优先于 Running 删除（P/D/U） 2. 无 Pending 时高位优先删除 3. 稀疏 index 扩容补洞（如 {0,4} → 补 index 1） 4. 稀疏 index 缩容回收 orphan 高位（如 {0,1,4} 3→2 删 index 4） 5. 全链路：5→2 Pending 删洞 → 2→3 补位 → 3→2 正常缩容 6. deployment 查询失败回退旧逻辑 - 测试结果：21/21 passed（test_scale_in.py） bash pytest tests/examples/deployer/test_scale_in.py -v ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!686 | 12 天前 | |
[feature] Docker-only PD 混部推理部署支持 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !469 merge docs/docker-pd-aggregation-deployment into master [feature] Docker-only PD 混部推理部署支持 Created-by: Jechin Commit-by: Jechin Merged-by: towncharlie Description: ## **1. 合入背景** Fixes [#263](https://gitcode.com/Ascend/MindIE-PyMotor/issues/263) 当前 Docker-only 部署指南仅覆盖 PD 分离，缺少 PD 混部的单容器、多容器端到端部署方式；原有示例在单容器 union 实例拉起、环境变量注入、端口偏移和可选 KV 端口处理方面也不完整。本 PR 统一整理两种 PD 模式的部署指导，并补齐 PD 混部所需的启动与配置支持。 ## **2. 修改内容** 1. **统一 Docker 部署指南** - 将 PD 分离与 PD 混部整合到单容器、多容器两篇指南中，按“PD 分离在前、PD 混部在后”的顺序说明配置和启动差异。 - 增加 examples 获取方式、推荐端口规划、Coordinator 对外端口映射、服务验证及 A5 环境说明。 - 启动示例增加 CONFIGMAP_PATH 和 WEIGHT_MOUNT_PATH 挂载，模型权重使用只读挂载。 2. **支持单容器 union 实例拉起** - all_combine_in_single_container.sh 根据 motor_engine_union_config 识别 PD 混部模式。 - 校验 hybrid_instances_num，按实例设置 ROLE=union、INDEX、JOB_NAME 和 ranktable 路径并拉起 NodeManager。 3. **支持 union 环境变量注入** - set_env_docker.py 支持从 motor_engine_union_config 解析 engine 类型和模型名称。 - 为单容器、多容器启动脚本生成 set_union_env；未配置 motor_engine_union_env 时兼容复用 Prefill 环境配置。 4. **完善单容器混部端口与设备分配** - NodeManager 根据 union 实例索引计算管理端口、业务端口、设备及 DP RPC 端口偏移。 - EngineService 仅在端口配置有效时传递 --kv-port 和 --dp-rpc-port，避免生成 --kv-port None 导致 Engine Server 参数解析失败。 - EndpointConfig 将偏移后的 dp_rpc_port 应用到 union 并行配置，避免多 union 实例复用同一 DP RPC 端口。 5. **补充自动化测试** - 覆盖 union 环境注入、单容器 union 端口与设备偏移、混部/分离配置摘要、可选 KV 端口省略及 union DP RPC 端口覆盖。 6. **文档站点配置** - 修正 mkdocs.yml 中的站点地址。 ## **3. 资料变更** - docs/zh/user_guide/deployment/docker/single_container.md：统一单容器 PD 分离/混部部署流程，补充端口映射、挂载与服务验证。 - docs/zh/user_guide/deployment/docker/multi_container.md：统一多容器 PD 分离/混部部署流程，补充端口规划、挂载与服务验证。 - mkdocs.yml：更新文档站点地址。 ## **4. 接口变更** 不涉及跨代码仓 API 变更。Docker 启动流程新增对现有 motor_engine_union_config、motor_engine_union_env 和 hybrid_instances_num 配置的支持；文档启动示例新增 WEIGHT_MOUNT_PATH 变量及 31015:1025 服务端口映射。 ## **5. 测试结果** - 相关 NodeManager、EndpointConfig 测试：108 个用例通过。 - 相关文件 pre-commit 检查全部通过。 - 按部署文档验证服务能够成功拉起。 ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-PyMotor!469 | 1 个月前 | |
add storage feature Co-authored-by: supermario_leo<leo.stack@outlook.com> # message auto-generated for no-merge-commit merge: !440 merge feature_add_ucm into master add storage feature Created-by: leo6393 Commit-by: supermario_leo Merged-by: towncharlie Description: ## **1. 合入背景** 在分布式 PD 架构上接入 **UCMConnector** 作为 KV 存储层,为 Prefill 节点提供前缀缓存(prefix cache)复用能力,降低重复前缀的 TTFT、提升整体吞吐。 由于 UCM 的 storage_backends 需要一块 **P/D 跨节点共享**的持久化存储,本分支同时补齐了通用的**引擎 Pod 存储能力**(不绑定 UCM),作为 UCM 前缀缓存池的落盘载体。 - 关联特性:UCM 前缀缓存接入(分布式 PD) - 不涉及对既有 PR 问题的修复 ## **2. 修改内容** 1. **UCM Connector 接入(motor/engine_server/core/vllm/vllm_config.py)** - MultiConnector 场景下识别 connectors[1] = UCMConnector:提前处理并强制 kv_role = kv_both(UCM 在 P/D 两端均双向 store),**不注入任何 rpc port**,避免污染 UCM 的内联 kv_connector_extra_config,处理后 return early。 - 独立 UCMConnector 在 prefill/decode 角色下 **fail loud**(该拓扑需额外 dispatch/profile 工作,当前不支持);union 角色原样透传。 - AscendStoreConnector / MooncakeStore 分支行为保持不变,报错信息修正为打印实际 connector 名。 2. **端口注入适配(motor/config/endpoint.py、motor/config/node_manager.py)** - MultiConnector 组装时,UCM store 无 lookup_rpc_port。改用 .get() 判断 connector 类型,**仅跳过 UCM**;其余 store(如 AscendStore)保持直接索引 —— 真正缺失端口时仍按原逻辑 fail fast,不被静默跳过。 3. **常量新增(motor/engine_server/constants/constants.py、motor/config/node_manager.py)** - UCM_CONNECTOR = "UCMConnector"、KV_BOTH = "kv_both"、KV_CONNECTOR_MODULE_PATH。 4. **通用引擎 Pod 存储能力(新增 examples/deployer/lib/generator/storage.py)** - motor_deploy_config.storage 为**列表**,每条目必须声明 type: - pvc —— 两种互斥模式:storage_class_name 动态创建 PVC / claim_name **挂载已有 PVC**(不生成 PVC 对象,且与 size/access_mode/storage_class_name 互斥,混填/漏填均 fail loud;claim_name 用于非 pvc 类型也会被拒绝)。 - nfs —— k8s 原生 NFS 卷直挂(server+path),无需 CSI/供给器。 - hostpath —— 节点本地目录直挂。 - dshm_size —— 独立抬高 /dev/shm emptyDir sizeLimit(容纳 UCM CacheStore),带无单位值校验。 - 挂载逻辑幂等,复用到 engine.py / infer_service.py / single_container.py 三条部署路径;卷名/动态 PVC 名按序号自动生成(mindie-motor-store-<i>)。 5. **示例与镜像** - examples/infer_engines/vllm/ucm_pd/(README + user_config.json):分布式 PD + UCM 内联配置示例。 - docker/mindie-motor-vllm-ucm/(Dockerfile + README):UCM 叠加镜像。 ## **3. 资料变更** **涉及。** - 新增 examples/infer_engines/vllm/ucm_pd/README.md:UCM 前缀缓存拓扑、存储三种类型(pvc/nfs/hostpath)字段表、动态创建 / 挂已有 PVC(claim_name)两种写法示例、dshm_size 说明及硬约束(storage_backends == mount_path)。 - 新增 docker/mindie-motor-vllm-ucm/README.md:UCM 叠加镜像构建说明。 ## **4. 接口变更** **涉及客户面可见的配置项变更(user_config.json),不涉及跨代码仓 API 变更。** - kv_connector 支持 UCMConnector,及 MultiConnector 中内嵌 UCM 作为 connectors[1];需配套 kv_connector_module_path。 - motor_deploy_config 新增 storage 列表(type: pvc/nfs/hostpath,pvc 支持 claim_name 挂已有卷)与 dshm_size。 - 均为新增可选项,对存量配置向后兼容。 ## **5. 测试结果** 新增 / 覆盖 UT: | 用例文件 | 用例数 | 覆盖场景 | |---|---|---| | tests/examples/deployer/test_storage.py | 22 | pvc/nfs/hostpath 三类挂载;pvc 动态创建 vs claim_name 挂已有;参数互斥与缺失校验;非 pvc 类型拒绝 claim_name;多条目/同 claim 多挂载点;挂载幂等;dshm_size 设置与无单位校验 | | tests/engine_server/core/test_vllm_config.py | 13 | UCM kv_role=kv_both、不注入端口;独立 UCM 在 P/D 角色 fail loud;MultiConnector 内嵌 UCM;既有 mooncake/ascend 分支回归 | | tests/node_manager/test_config.py | 33 | MultiConnector 组装跳过 UCM 端口注入;非 UCM store 缺端口仍 fail fast | - 部署方式维度:覆盖 Deployment(engine)、InferServiceSet、single-container 三条路径的存储挂载。 - 本地已执行 deployer UT 套件:54 passed;test_vllm_config.py / test_config.py 依赖运行时环境,请在集成环境执行确认。 - 建议补充:UCM 叠加镜像 + 实机分布式 PD 端到端前缀缓存命中 / TTFT 验证。 ## **6. CheckList** - [x] 代码注释完备 - [x] 正确记录维测日志 - [x] 是否有UT用例 - [x] 若涉及多线程场景,考虑了并发场景,不存在死锁问题(本次改动为配置解析 / YAML 生成,无新增多线程逻辑) See merge request: Ascend/MindIE-PyMotor!440 | 1 个月前 | |
[feature] 支持 Prefill 跨机 Pipeline Parallel 拉起 Co-authored-by: Jechin<yuzechen1@huawei.com> # message auto-generated for no-merge-commit merge: !653 merge feature/prefill-cross-node-pp into master [feature] 支持 Prefill 跨机 Pipeline Parallel 拉起 Created-by: Jechin Commit-by: Jechin Merged-by: towncharlie Description: ## **1. 合入背景** Fixes [#389](https://gitcode.com/Ascend/MindIE-Motor/issues/389) Prefill 跨机 Pipeline Parallel（如 TP=16、PP=2、nnodes=2）场景下，控制面仍按“单机并行积”计算 local_world_size（pcp×tp×pp），导致本机设备数校验失败、Endpoint 为空；同时 master_addr=placeholder / 静态 node_rank 会盖住运行时注入，分布式初始化无法连通。Assembler 在无 Endpoint 时还会误报 start 成功。本 PR 补齐跨机 PP 与跨机 PCP 共用的 nnodes 路径，并让 Deployer 从 vLLM 脚本正确生成 PP/nnodes 配置；并行度读取统一为 CLI 整数优先、缺省回退 kv_connector_extra_config（含 pp_size）。 ## **2. 修改内容** 1. **NodeManager 配置**（motor/config/node_manager.py） - 跨机时按 (pcp×tp×pp)//nnodes 折算本机 local_world_size（覆盖 PP/PCP） - pcp×pp 不能被 nnodes 整除时直接报错，避免错误拓扑静默通过 2. **EngineServer VLLMConfig**（motor/engine_server/core/vllm/vllm_config.py） - 跨机场景强制覆盖 master_addr / node_rank / headless，不再被 placeholder 挡住 - Mooncake kv extra 合并并行度时保留用户字段（如 pp_layer_partition） 3. **Controller InstanceAssembler**（motor/controller/core/instance_assembler.py） - 所有 NodeManager 均无 Endpoint 时，_send_start_command 返回失败并打 ERROR，禁止假成功 4. **Deployer 转换**（examples/deployer/config_tool/vllm_to_motor.py） - 保留并正确写出 pipeline_parallel_size，按 tp×pp 推导 Pod / nnodes - 跨机时写入 nnodes / master-port；不写 master-addr / node-rank（运行时注入） - **dp/tp/pp 统一读取优先级**：命令行给了正整数用 CLI，否则回退 kv_connector_extra_config 的 dp_size / tp_size / pp_size（kv 中的 size 在写出前剥离） - 去除硬件侧强制 remap tp/dp；infer_*_motor_deploy_config 回传 nnodes，与跨机 engine 注入共用一次 _infer_pod_layout - 抽取 hybrid 默认 deploy / 权重挂载路径 / preset+cards 等重复逻辑，降低漂移风险 5. **UT** - 覆盖 PP 折算、不可整除、placeholder 覆盖、kv 字段保留、空 Endpoint start 失败 - Deployer：CLI>kv、仅 kv 回退（含 pp_size）、跨机 nnodes/master-port、跳过脚本透传多机键等 **进程视图** mermaid flowchart LR subgraph deploy [Deploy] script["vLLM serve 脚本\nCLI 与 kv extra"] conv["vllm_to_motor\nCLI大于kv"] uc["user_config\nPP nnodes master-port"] end subgraph control [Control Plane] nm0["NodeManager node_rank=0"] nm1["NodeManager node_rank=1"] asm["InstanceAssembler"] end subgraph engine [Engine] es0["EngineServer PP stage0"] es1["EngineServer PP stage1 headless"] end script --> conv --> uc uc --> nm0 uc --> nm1 nm0 -->|"Register local_world_size"| asm nm1 -->|"Register local_world_size"| asm asm -->|"StartCmd master_dp_ip/node_rank"| nm0 asm -->|"StartCmd"| nm1 nm0 --> es0 nm1 --> es1 es0 <-->|"master-port rendezvous"| es1 ## **3. 资料变更** 不涉及仓库内用户文档更新（Deployer README / 跨机说明未改）。 ## **4. 接口变更** 涉及配置约定（客户面可见）： - Prefill 跨机 PP 需配置 pipeline_parallel_size、nnodes、master-port；**不要**配置 master-addr / node-rank - Deployer 从 vLLM 脚本转换时会自动生成上述项；pipeline_parallel_size 不再被强制改写为 1 - Deployer 并行度语义：--data/tensor/pipeline-parallel-size 正整数优先于 kv extra 的 dp_size/tp_size/pp_size；二者皆无时 dp/tp 走手动占位提示，pp 缺省为 1 - 无新增/变更 HTTP API ## **5. 测试结果** （自行补充） ## **6. CheckList** [x] 代码注释完备 [x] 正确记录维测日志 [x] 是否有UT用例 [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 See merge request: Ascend/MindIE-Motor!653 | 13 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 16 天前 | ||
| 24 天前 | ||
| 1 个月前 | ||
| 11 小时前 | ||
| 28 天前 | ||
| 12 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 13 天前 |