已关闭
[Feature]: optx工具使用过于繁琐,希望优化 #279
xuzuq创建于  7月28日关闭于  7 天前
xuzuq
xuzuq
7月28日 创建

Problem/Pain Point Description | 问题/痛点描述

当前optx工具使用,需要配置config,toml,其中服务化配置尤其繁琐,希望能优化vllm寻优配置和固定配置输入方式

Proposed Solution | 建议方案

【功能点1】config.toml中vllm Related Configuration 部分新增vllm serve启动配置文件传入
config.toml中vllm Related Configuration新增 [vllm.serve_file],工具读取vllm_serve_file中内容完成解析,原有[vllm.commad]可做条件判断选择
[vllm]
[vllm.serve_file]
vllm_serve_file ="./vllm_serve_file.sh"

vllm_serve_file.sh内容为实际vllm启动命令,格式参考vllm-ascend官方文档https://docs.vllm.ai/projects/ascend/en/v0.23.0/tutorials/models/Qwen3.5-27B-Qwen3.6-27B.html。方便用户实际部署和使用调优工具间转换使用

vllm_serve_file.sh中为实际vllm服务化启动配置,其中包含固定配置和需寻优的参数配置,寻优参数根据[[vllm.target_field]]中获取用户配置参数,工具完成替换参数覆盖

#!/bin/sh
# Load model from ModelScope to speed up download
export VLLM_USE_MODELSCOPE=True
# To reduce memory fragmentation and avoid out of memory
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export HCCL_BUFFSIZE=512
export OMP_PROC_BIND=false
export OMP_NUM_THREADS=1
export TASK_QUEUE_ENABLE=1

vllm serve Eco-Tech/Qwen3.6-27B-w8a8 \
--host 0.0.0.0 \
--port 8000 \
--data-parallel-size 1 \
--tensor-parallel-size 2 \
--seed 1024 \
--quantization ascend \
--served-model-name qwen3.6 \
--max-num-seqs 32 \
--max-model-len 262144 \
--max-num-batched-tokens 8096 \
--trust-remote-code \
--gpu-memory-utilization 0.90 \
--no-enable-prefix-caching \
--speculative-config '{"method": "qwen3_5_mtp", "num_speculative_tokens": 3, "enforce_eager": true}' \
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
--additional-config '{"enable_cpu_binding":true}' \
--async-scheduling

【优化点】

  1. 工具易用性提升:用户可快速转换实际部署和工具使用,不需要再config,toml中来回手动配置、转义、根据不同寻优参数增删。

【功能点2】[[vllm.target_field]]中新增组合参数类,通过config_position区分,
举个例子:
比如常见组合dp、tp
--data-parallel-size 2
--tensor-parallel-size 4 \

[[vllm.target_field]]
name = "data-parallel-size, tensor-parallel-size"
config_position = "combine.config"
dtype = "enum"
value = ["2,4","4, 2","1, 8"]

【优化点】

  1. 更贴合实际使用场景,多个参数组合寻优时,往往不需要很多组合,只需要固定几个组合即可。

Alternative Solutions | 替代方案

Expected Value | 预期价值

【功能点1】1. 工具易用性提升:用户可快速转换实际部署和工具使用,不需要再config,toml中来回手动配置、转义、根据不同寻优参数增删。
【功能点2】1. 更贴合实际使用场景,多个参数组合寻优时,往往不需要很多组合,只需要固定几个组合即可。

Contribution Intent | 贡献意向

Welcome to join the community and thank you for your contribution 🎉!

欢迎加入社区,感谢您对社区的贡献 🎉!

likedislike
kai1949
kai1949成员
7月28日 评论:

/label add triaged
👋 您好,欢迎向 MindStudio-Modeling 提交 Issue!
我们已收到您的反馈,感谢你对开源社区的支持。🎉

📅处理时效: 维护团队将在8小时内 查看并回复您的问题(工作日)。
🔍自助查询: 在等待期间,建议您先查阅以下资料,可能已有解决方案:

📖 MindStudio-Modeling官方文档
📝 贡献者指南

请确保 Issue 描述清晰,包含复现步骤和日志,这将帮助我们更快定位问题。谢谢!

likedislike
ascend-robotascend-robot成员
7月28日 添加了label:feature
ascend-robotascend-robot成员
7月28日 添加了label:triaged
jiangruitaojiangruitao成员
10 天前 将 tt0cool 设为负责人
ttcool成员
7 天前 评论:

感谢反馈,服务化参数迁移和配置维护的成本确实值得优化。结合目前工具已有能力,我们建议优先复用现有配置机制,暂不新增这两个配置入口。

  1. 关于直接读取 vLLM 启动脚本
    目前我们正在通过 Agent 辅助配置降低使用门槛:用户提供已有启动命令及寻优需求,由 Agent 协助整理固定参数、环境变量和搜索空间,生成并校验 config.toml,减少手动转换、JSON 转义及参数增删的工作。
    因此,现阶段更倾向于完善这条配置流程,继续以 config.toml 作为统一的运行配置。新增脚本读取入口还需要明确脚本与 TOML 的优先级,以及环境变量展开、Shell 语法支持等规则,会增加配置行为和维护成本。
  2. 关于 DP、TP 等参数组合寻优
    当前已有 enum 枚举类型和 factories 乘积约束类型,可以覆盖示例中的组合,无需新增 combine.config。
    例如,将 DP 限定为 [1, 2, 4],再通过 TP = 8 / DP 派生 TP:
    [[vllm.target_field]]
    name = "dp"
    config_position = "env"
    dtype = "enum"
    dtype_param = [1, 2, 4]
    min = 1
    max = 4
    value = 2

[[vllm.target_field]]
name = "tp"
config_position = "env"
dtype = "factories"
dtype_param = { target_name = "dp", product = 8, dtype = "int" }
min = 0
max = 0
value = 4
这样只会产生 (DP, TP) = (1, 8)、(2, 4)、(4, 2) 三种组合,不会对 DP、TP 分别枚举后搜索全部交叉组合。

likedislike
ttcool成员
7 天前 评论:

/resolved

likedislike
Tttcool成员
7 天前 issue状态由 TODO 改变为 DONE
Tttcool成员
7 天前 关闭了 issue
ascend-robotascend-robot成员
7 天前 添加了label:resolved