尧图网页设计 
CANN 推理优化之场景确认操作细则如何锁定优化场景与性能目标cann-recipes-infer 高阶流程第一步【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer本篇技术指南讲解 cann-recipes-infer 仓库中model-infer-sota-approach模型推理优化编排高阶流程的第一步——确认推理场景与性能目标。该步骤由主 agent 交互式执行核心是先勘察仓库、后结构化提问把优化哪个场景、目标是什么、用什么尺子判定敲定为一份可下传给下游 subagent 的场景定义。读完本文你将掌握如何从models/model/目录自动勘察候选场景、如何做前置条件检查、如何用一次结构化提问锁定场景并理解锁定的场景定义如何驱动后续 baseline 建立与 profiling 驱动的探索式优化。1. 这一步在整个高阶流程中的定位model-infer-sota-approach是一个在已可运行的 baseline 之上、由 profiling 数据驱动的高阶优化编排流程在多个尚不确定的优化方向上并行发现候选再用 Plan 自循环实施 → 复核 → 派生 → 淘汰逐步逼近最优方案。流程总览见 SKILL.md共分为确认场景、构造输入跑通精度基线、采集 baseline profilinground0、分析 profiling、候选发现、初始化 Plan Dashboard、Plan 实施 / review / 派生循环、最终验收等阶段。本文聚焦的确认推理场景与性能目标是流程总览中的第 1 步也是唯一由主 agent 直接做、且与用户交互的起步步骤。它的边界非常清晰只锁定场景——不写 DashboardDashboard 要等候选发现完成、第 6 步才初始化不跑推理——本步不执行infer.sh推理与 profiling 由第 2、3 步的 scenario / profiling-instrumenter subagent 负责不采集——本步只确认优化什么、目标是什么、用什么判定不落 profiling 数据。2. 三条操作原则本步的推进遵循三条原则先勘察后提问不要空手问用户。先从仓库找出候选场景带着候选清单去确认让用户的每次回答都落在具体选项上。一次问清能批量确认的用一次结构化提问AskUserQuestion把所有问题一次性摆出来不逐条盘问避免来回打断。前置条件优先高阶流程必须建立在已有可运行 baseline 之上如果没有 baseline就先走model-infer-migrator或model-infer-optimize阶段 0 建好 baseline 再回来不要硬启动后续流程。3. 自动勘察候选场景先做功课进入交互前先从仓库收集信息、整理成候选清单。候选清单的每条记录结构为{YAML 名, phase, 卡数, 并行, 量化, 是否已有 baseline}。勘察的素材来源有三类。3.1 模型目录models/model/1infer.sh中的YAML_FILE_NAME—— 当前默认跑哪个场景每个模型的推理入口统一是bash infer.sh。以 models/glm_5_2/infer.sh 为例脚本先解析自身路径source 仓库统一的executor/scripts/set_env.sh与executor/scripts/function.sh再通过YAML_FILE_NAME指定config/下的目标 YAML最后调用launch启动SCRIPT_PATH$(cd $(dirname ${BASH_SOURCE[0]}) /dev/null pwd) SET_ENV_ABS_PATH${SCRIPT_PATH}/../../executor/scripts/set_env.sh FUNCTION_ABS_PATH${SCRIPT_PATH}/../../executor/scripts/function.sh source ${SET_ENV_ABS_PATH} source ${FUNCTION_ABS_PATH} export MODEL_DIR$(basename $SCRIPT_PATH) export YAML_PARENT_PATH${SCRIPT_PATH}/config export YAML_FILE_NAMEglm_5_2_rank_32_32ep_w8a8_offload.yaml # modify to your yaml file name export YAML${YAML_PARENT_PATH}/${YAML_FILE_NAME} launch其中set_env.sh负责配置环境多机 IP、CANN 路径等详见 executor/scripts/set_env.shexport IPs(xx.xx.xx.xx xx.xx.xx.xx) # IPs of all servers. The first one is the master server. # 多机场景每个节点都要执行 bash infer.sh cann_pathyour_cann_pkgs_path source $cann_path/bin/setenv.bash export ASCEND_HOME_PATH$cann_path不同模型的infer.sh在写法上略有差异有的直接写死如 models/hunyuan-image-3.0/infer.sh 中的export YAML_FILE_NAMEep8_cfg.yaml有的支持环境变量覆盖默认值如 models/kimi_k3/infer.sh 中的export YAML_FILE_NAME${YAML_FILE_NAME:-kimi_k3_rank_32_mxfp4_npugraph_ex.yaml}有的由脚本模式动态决定如 models/davinci-magihuman/infer.sh 中的export YAML_FILE_NAME${MODE}_runtime.yaml。勘察时以实际模型的infer.sh为准读出其默认YAML_FILE_NAME即为该模型当前默认场景。2config/*.yaml—— 每个 YAML 文件名编码一个场景这是候选场景最丰富的来源。YAML 文件名本身就编码了关键场景维度phaseprefill/decode卡数rank_16、rank_32、rank_64、rank_128等并行16ep专家并行、16tp张量并行、32dp数据并行、32sp序列并行、attndpattention 数据并行等也常见组合如32dp_32ep、128_128ep量化a8w8、w8a8、w8a8c8、mxfp4、mxfp8等附加特性关键词mtp多 token 预测、offload、npugraph_ex、eplb、benchmark等。仓库中大量真实配置文件名印证了这一编码约定例如 models/deepseek_r1/config 下的decode_r1_rank_16_16ep_a8w8.yamldecode 阶段 / 16 卡 / 16 EP / A8W8、prefill_r1_rank_32_32dp_32ep_a8w8.yamlprefill / 32 卡 / DPEP 组合以及 models/glm_5_2/config 下的glm_5_2_rank_32_32ep_w8a8_offload.yaml32 卡 / 32 EP / W8A8 / KV offload。勘察时应逐个列出所有可选场景。3README.md—— 推荐场景说明模型 README 通常会说明推荐部署形态与场景。例如 models/glm_5_2/README.md 中明确默认的 yaml 路径为 32 卡推理并给出修改示例# 默认 32 卡部署W8A8 KV offload export YAML_FILE_NAMEglm_5_2_rank_32_32ep_w8a8_offload.yaml3.2 已有产物判断是否已有 baseline、是否定过场景progress.md共享状态文件存在则从中直接取模型 / 权重 / 部署配置等前置信息作为场景定义的默认值不重新推导optimization-analysis/高阶流程的默认输出归档目录存放各阶段分析产物baseline/baseline_metadata.json判定是否已有可复现精度的 baseline。仓库真实示例见 models/gemma_4/baseline/baseline_metadata.json其中记录了运行环境NPU 型号、卡数、CANN/torch_npu 版本、执行模式、模型配置模型名、权重来源以及性能采样prefill 耗时、decode 平均耗时、输出文本样本{ timestamp: 2026-04-15T09:38:43, environment: { npu_model: Ascend 910B4, num_cards: 8, cann_version: 8.5.0, pytorch_version: 2.8.0, torch_npu_version: 2.8.0.post2, exe_mode: eager }, model_config: { model_name: gemma-4-26B-A4B }, performance: { prefill_ms: 312.51, decode_avg_ms: 98.47, output_text: A model is a set of key-value pairs to an output, ... } }这份元数据恰好说明已有 baseline在仓库中的实际形态环境 模型 可复现的性能采样三者齐备。4. 前置条件检查在进入提问前必须确认三项前置模型已框架适配models/model/结构完整入口存在infer.sh能跑通有可复现精度的 baseline或至少能现采。不满足时代码缺失 / 跑不通 / 无 baseline停在这一步告诉用户高阶流程的前置未满足先走model-infer-migrator或model-infer-optimize阶段 0 建好 baseline 再回来。不要在没 baseline 时硬启动后续流程——这是本步最重要的一条刹车。5. 和用户确认一次结构化提问带着候选清单用一次 AskUserQuestion 把下面五项敲定。规则是已能从仓库确定的项给默认值让用户确认只对真正缺失的信息追问。Q1 优化哪个场景从候选 YAML 里选一个或用户自定义。这一项决定 phase / 卡数 / 并行 / 量化候选 YAML 直接作为选项。Q2 workload 侧重decode 单步时延 / prefill 吞吐 / 长序列 / batch·并发 / 整体。它决定后续 profiling 采哪个阶段、候选发现往哪个方向使劲。Q3 精度 / 功能判定口径默认贪心逐 token 与 baseline 对齐 可读 / 不重复 / 非全零 / 不提前 EOS量化或生成类模型按模态调整。口径细节见 scenario-setup.md。让用户确认或修改。Q4 性能目标可选给具体数值目标TPOT / 吞吐 / E2E 时延和无硬目标、尽量榨两类。无目标不阻塞标为可选。Q5 输出归档目录默认optimization-analysis/case/确认或修改。5.1 判定口径为什么强调可机判Q3 的口径不是看起来对这种主观描述而是能被后续所有 round 自动判定的规则。结合 scenario-setup.md 的细化说明按模态分三档LLM贪心可复现以基线输出的 token ids / 文本做逐字对比附最低可用性门槛可读、不重复、非全零、不提前 EOSMoE / 量化模型同上量化基线允许与浮点有界误差记录可接受的误差范围图像 / 视频生成固定 seed 和 step 数比对输出图 / 帧的关键指标或可视一致记录采样器和 step。可复现性的技术基础在仓库中确实存在例如 models/glm_5_2/infer.py 在入口处固定随机种子torch.manual_seed(42)torch.npu.manual_seed_all(42)且推理入口支持显式指定 YAMLpython infer.py --yaml_file_path config/scenario.yaml这为贪心逐 token 对齐提供了前提。6. 处理只给了泛化目标的情况用户只说帮我优化 XX 模型 / 提速时不要直接开盘问也不要擅自决定。正确做法是主 agent 从第 1 步候选里挑最可能的场景通常是infer.sh当前的 YAML或 README 主推场景作为推荐连同其它候选一起摆给用户在 Q1 里选。这样既给出了专业默认值又把最终决定权留给用户。7. 锁定并交棒产出场景定义确认后把结果整理成一份场景定义至少包含以下字段模型 / case、代码目录、推理入口选用 YAML标明 phase / 卡数 / 并行 / 量化workload 侧重精度 / 功能判定口径性能目标或标可选输出归档目录progress.md共享状态文件路径找得到就记录其实际位置找不到就按model-infer-optimize约定创建一份后记录。该路径后续作为progress_path下传给各 subagent位置不在 skill 里钉死。关于progress.md的创建约定可参考 progress_template.md它规定了常驻区模型信息、运行环境、部署基线、进度概览等长期有效信息阶段推进不清除与工作区阶段推进时归档并清空的分层写法和写入 / 排除范围。这份场景定义是第 2 步scenariosubagent 的输入——它据此构造可复现输入、跑基线、落scenario.md执行细节见 scenario-setup.md。本步仍不写 DashboardDashboard 在候选发现完成后、第 6 步才初始化、不跑推理。8. 本步输出本步的最终产出只有两样可直接喂给后续流程锁定的场景定义可直接喂给 scenario subagent前置条件结论满足 / 需先建 baseline。其中需先建 baseline是流程的合法出口它明确告诉用户当前不满足高阶流程的前置应当先回到model-infer-migrator或model-infer-optimize阶段 0。场景确认完成后后续编排按流程总览推进scenario subagent 构造输入并跑通精度基线 → profiling-instrumenter 采集 round0 → profile-analyzer 分析 → 候选发现 → Dashboard 初始化 → Plan 循环具体编排规则均见 SKILL.md 及 decision-rules.md、plan-dashboard-template.md、plan-file-template.md 等配套参考文档。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN 推理优化之场景确认操作细则：如何锁定优化场景与性能目标（cann-recipes-infer 高阶流程第一步）
CANN 推理优化之场景确认操作细则如何锁定优化场景与性能目标cann-recipes-infer 高阶流程第一步【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer本篇技术指南讲解 cann-recipes-infer 仓库中model-infer-sota-approach模型推理优化编排高阶流程的第一步——确认推理场景与性能目标。该步骤由主 agent 交互式执行核心是先勘察仓库、后结构化提问把优化哪个场景、目标是什么、用什么尺子判定敲定为一份可下传给下游 subagent 的场景定义。读完本文你将掌握如何从models/model/目录自动勘察候选场景、如何做前置条件检查、如何用一次结构化提问锁定场景并理解锁定的场景定义如何驱动后续 baseline 建立与 profiling 驱动的探索式优化。1. 这一步在整个高阶流程中的定位model-infer-sota-approach是一个在已可运行的 baseline 之上、由 profiling 数据驱动的高阶优化编排流程在多个尚不确定的优化方向上并行发现候选再用 Plan 自循环实施 → 复核 → 派生 → 淘汰逐步逼近最优方案。流程总览见 SKILL.md共分为确认场景、构造输入跑通精度基线、采集 baseline profilinground0、分析 profiling、候选发现、初始化 Plan Dashboard、Plan 实施 / review / 派生循环、最终验收等阶段。本文聚焦的确认推理场景与性能目标是流程总览中的第 1 步也是唯一由主 agent 直接做、且与用户交互的起步步骤。它的边界非常清晰只锁定场景——不写 DashboardDashboard 要等候选发现完成、第 6 步才初始化不跑推理——本步不执行infer.sh推理与 profiling 由第 2、3 步的 scenario / profiling-instrumenter subagent 负责不采集——本步只确认优化什么、目标是什么、用什么判定不落 profiling 数据。2. 三条操作原则本步的推进遵循三条原则先勘察后提问不要空手问用户。先从仓库找出候选场景带着候选清单去确认让用户的每次回答都落在具体选项上。一次问清能批量确认的用一次结构化提问AskUserQuestion把所有问题一次性摆出来不逐条盘问避免来回打断。前置条件优先高阶流程必须建立在已有可运行 baseline 之上如果没有 baseline就先走model-infer-migrator或model-infer-optimize阶段 0 建好 baseline 再回来不要硬启动后续流程。3. 自动勘察候选场景先做功课进入交互前先从仓库收集信息、整理成候选清单。候选清单的每条记录结构为{YAML 名, phase, 卡数, 并行, 量化, 是否已有 baseline}。勘察的素材来源有三类。3.1 模型目录models/model/1infer.sh中的YAML_FILE_NAME—— 当前默认跑哪个场景每个模型的推理入口统一是bash infer.sh。以 models/glm_5_2/infer.sh 为例脚本先解析自身路径source 仓库统一的executor/scripts/set_env.sh与executor/scripts/function.sh再通过YAML_FILE_NAME指定config/下的目标 YAML最后调用launch启动SCRIPT_PATH$(cd $(dirname ${BASH_SOURCE[0]}) /dev/null pwd) SET_ENV_ABS_PATH${SCRIPT_PATH}/../../executor/scripts/set_env.sh FUNCTION_ABS_PATH${SCRIPT_PATH}/../../executor/scripts/function.sh source ${SET_ENV_ABS_PATH} source ${FUNCTION_ABS_PATH} export MODEL_DIR$(basename $SCRIPT_PATH) export YAML_PARENT_PATH${SCRIPT_PATH}/config export YAML_FILE_NAMEglm_5_2_rank_32_32ep_w8a8_offload.yaml # modify to your yaml file name export YAML${YAML_PARENT_PATH}/${YAML_FILE_NAME} launch其中set_env.sh负责配置环境多机 IP、CANN 路径等详见 executor/scripts/set_env.shexport IPs(xx.xx.xx.xx xx.xx.xx.xx) # IPs of all servers. The first one is the master server. # 多机场景每个节点都要执行 bash infer.sh cann_pathyour_cann_pkgs_path source $cann_path/bin/setenv.bash export ASCEND_HOME_PATH$cann_path不同模型的infer.sh在写法上略有差异有的直接写死如 models/hunyuan-image-3.0/infer.sh 中的export YAML_FILE_NAMEep8_cfg.yaml有的支持环境变量覆盖默认值如 models/kimi_k3/infer.sh 中的export YAML_FILE_NAME${YAML_FILE_NAME:-kimi_k3_rank_32_mxfp4_npugraph_ex.yaml}有的由脚本模式动态决定如 models/davinci-magihuman/infer.sh 中的export YAML_FILE_NAME${MODE}_runtime.yaml。勘察时以实际模型的infer.sh为准读出其默认YAML_FILE_NAME即为该模型当前默认场景。2config/*.yaml—— 每个 YAML 文件名编码一个场景这是候选场景最丰富的来源。YAML 文件名本身就编码了关键场景维度phaseprefill/decode卡数rank_16、rank_32、rank_64、rank_128等并行16ep专家并行、16tp张量并行、32dp数据并行、32sp序列并行、attndpattention 数据并行等也常见组合如32dp_32ep、128_128ep量化a8w8、w8a8、w8a8c8、mxfp4、mxfp8等附加特性关键词mtp多 token 预测、offload、npugraph_ex、eplb、benchmark等。仓库中大量真实配置文件名印证了这一编码约定例如 models/deepseek_r1/config 下的decode_r1_rank_16_16ep_a8w8.yamldecode 阶段 / 16 卡 / 16 EP / A8W8、prefill_r1_rank_32_32dp_32ep_a8w8.yamlprefill / 32 卡 / DPEP 组合以及 models/glm_5_2/config 下的glm_5_2_rank_32_32ep_w8a8_offload.yaml32 卡 / 32 EP / W8A8 / KV offload。勘察时应逐个列出所有可选场景。3README.md—— 推荐场景说明模型 README 通常会说明推荐部署形态与场景。例如 models/glm_5_2/README.md 中明确默认的 yaml 路径为 32 卡推理并给出修改示例# 默认 32 卡部署W8A8 KV offload export YAML_FILE_NAMEglm_5_2_rank_32_32ep_w8a8_offload.yaml3.2 已有产物判断是否已有 baseline、是否定过场景progress.md共享状态文件存在则从中直接取模型 / 权重 / 部署配置等前置信息作为场景定义的默认值不重新推导optimization-analysis/高阶流程的默认输出归档目录存放各阶段分析产物baseline/baseline_metadata.json判定是否已有可复现精度的 baseline。仓库真实示例见 models/gemma_4/baseline/baseline_metadata.json其中记录了运行环境NPU 型号、卡数、CANN/torch_npu 版本、执行模式、模型配置模型名、权重来源以及性能采样prefill 耗时、decode 平均耗时、输出文本样本{ timestamp: 2026-04-15T09:38:43, environment: { npu_model: Ascend 910B4, num_cards: 8, cann_version: 8.5.0, pytorch_version: 2.8.0, torch_npu_version: 2.8.0.post2, exe_mode: eager }, model_config: { model_name: gemma-4-26B-A4B }, performance: { prefill_ms: 312.51, decode_avg_ms: 98.47, output_text: A model is a set of key-value pairs to an output, ... } }这份元数据恰好说明已有 baseline在仓库中的实际形态环境 模型 可复现的性能采样三者齐备。4. 前置条件检查在进入提问前必须确认三项前置模型已框架适配models/model/结构完整入口存在infer.sh能跑通有可复现精度的 baseline或至少能现采。不满足时代码缺失 / 跑不通 / 无 baseline停在这一步告诉用户高阶流程的前置未满足先走model-infer-migrator或model-infer-optimize阶段 0 建好 baseline 再回来。不要在没 baseline 时硬启动后续流程——这是本步最重要的一条刹车。5. 和用户确认一次结构化提问带着候选清单用一次 AskUserQuestion 把下面五项敲定。规则是已能从仓库确定的项给默认值让用户确认只对真正缺失的信息追问。Q1 优化哪个场景从候选 YAML 里选一个或用户自定义。这一项决定 phase / 卡数 / 并行 / 量化候选 YAML 直接作为选项。Q2 workload 侧重decode 单步时延 / prefill 吞吐 / 长序列 / batch·并发 / 整体。它决定后续 profiling 采哪个阶段、候选发现往哪个方向使劲。Q3 精度 / 功能判定口径默认贪心逐 token 与 baseline 对齐 可读 / 不重复 / 非全零 / 不提前 EOS量化或生成类模型按模态调整。口径细节见 scenario-setup.md。让用户确认或修改。Q4 性能目标可选给具体数值目标TPOT / 吞吐 / E2E 时延和无硬目标、尽量榨两类。无目标不阻塞标为可选。Q5 输出归档目录默认optimization-analysis/case/确认或修改。5.1 判定口径为什么强调可机判Q3 的口径不是看起来对这种主观描述而是能被后续所有 round 自动判定的规则。结合 scenario-setup.md 的细化说明按模态分三档LLM贪心可复现以基线输出的 token ids / 文本做逐字对比附最低可用性门槛可读、不重复、非全零、不提前 EOSMoE / 量化模型同上量化基线允许与浮点有界误差记录可接受的误差范围图像 / 视频生成固定 seed 和 step 数比对输出图 / 帧的关键指标或可视一致记录采样器和 step。可复现性的技术基础在仓库中确实存在例如 models/glm_5_2/infer.py 在入口处固定随机种子torch.manual_seed(42)torch.npu.manual_seed_all(42)且推理入口支持显式指定 YAMLpython infer.py --yaml_file_path config/scenario.yaml这为贪心逐 token 对齐提供了前提。6. 处理只给了泛化目标的情况用户只说帮我优化 XX 模型 / 提速时不要直接开盘问也不要擅自决定。正确做法是主 agent 从第 1 步候选里挑最可能的场景通常是infer.sh当前的 YAML或 README 主推场景作为推荐连同其它候选一起摆给用户在 Q1 里选。这样既给出了专业默认值又把最终决定权留给用户。7. 锁定并交棒产出场景定义确认后把结果整理成一份场景定义至少包含以下字段模型 / case、代码目录、推理入口选用 YAML标明 phase / 卡数 / 并行 / 量化workload 侧重精度 / 功能判定口径性能目标或标可选输出归档目录progress.md共享状态文件路径找得到就记录其实际位置找不到就按model-infer-optimize约定创建一份后记录。该路径后续作为progress_path下传给各 subagent位置不在 skill 里钉死。关于progress.md的创建约定可参考 progress_template.md它规定了常驻区模型信息、运行环境、部署基线、进度概览等长期有效信息阶段推进不清除与工作区阶段推进时归档并清空的分层写法和写入 / 排除范围。这份场景定义是第 2 步scenariosubagent 的输入——它据此构造可复现输入、跑基线、落scenario.md执行细节见 scenario-setup.md。本步仍不写 DashboardDashboard 在候选发现完成后、第 6 步才初始化、不跑推理。8. 本步输出本步的最终产出只有两样可直接喂给后续流程锁定的场景定义可直接喂给 scenario subagent前置条件结论满足 / 需先建 baseline。其中需先建 baseline是流程的合法出口它明确告诉用户当前不满足高阶流程的前置应当先回到model-infer-migrator或model-infer-optimize阶段 0。场景确认完成后后续编排按流程总览推进scenario subagent 构造输入并跑通精度基线 → profiling-instrumenter 采集 round0 → profile-analyzer 分析 → 候选发现 → Dashboard 初始化 → Plan 循环具体编排规则均见 SKILL.md 及 decision-rules.md、plan-dashboard-template.md、plan-file-template.md 等配套参考文档。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考