企业官网建设流程全解析

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 profiling（round0）、分析 profiling、候选发现、初始化 Plan Dashboard、Plan 实施 / review / 派生循环、最终验收等阶段。

本文聚焦的"确认推理场景与性能目标"是流程总览中的第 1 步，也是唯一由主 agent 直接做、且与用户交互的起步步骤。它的边界非常清晰：

• 只锁定场景——不写 Dashboard（Dashboard 要等候选发现完成、第 6 步才初始化）；
• 不跑推理——本步不执行infer.sh，推理与 profiling 由第 2、3 步的 scenario / profiling-instrumenter subagent 负责；
• 不采集——本步只确认"优化什么、目标是什么、用什么判定"，不落 profiling 数据。

2. 三条操作原则

本步的推进遵循三条原则：

1. 先勘察后提问：不要空手问用户。先从仓库找出候选场景，带着候选清单去确认，让用户的每次回答都落在具体选项上。
2. 一次问清：能批量确认的，用一次结构化提问（AskUserQuestion）把所有问题一次性摆出来，不逐条盘问，避免来回打断。
3. 前置条件优先：高阶流程必须建立在已有可运行 baseline 之上；如果没有 baseline，就先走model-infer-migrator或model-infer-optimize阶段 0 建好 baseline 再回来，不要硬启动后续流程。

3. 自动勘察候选场景（先做功课）

进入交互前，先从仓库收集信息、整理成候选清单。候选清单的每条记录结构为：{YAML 名, phase, 卡数, 并行, 量化, 是否已有 baseline}。勘察的素材来源有三类。

3.1 模型目录models/<model>/

（1）infer.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_NAME=glm_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.sh：

export IPs=('xx.xx.xx.xx' 'xx.xx.xx.xx') # IPs of all servers. The first one is the master server. # 多机场景：每个节点都要执行 bash infer.sh cann_path="your_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_NAME=ep8_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即为该模型当前默认场景。

（2）config/*.yaml—— 每个 YAML 文件名编码一个场景

这是候选场景最丰富的来源。YAML 文件名本身就编码了关键场景维度：

• phase：prefill/decode；
• 卡数：rank_16、rank_32、rank_64、rank_128等；
• 并行：16ep（专家并行）、16tp（张量并行）、32dp（数据并行）、32sp（序列并行）、attndp（attention 数据并行）等，也常见组合如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.yaml（decode 阶段 / 16 卡 / 16 EP / A8W8）、prefill_r1_rank_32_32dp_32ep_a8w8.yaml（prefill / 32 卡 / DP+EP 组合），以及 models/glm_5_2/config 下的glm_5_2_rank_32_32ep_w8a8_offload.yaml（32 卡 / 32 EP / W8A8 / KV offload）。勘察时应逐个列出所有可选场景。

（3）README.md—— 推荐场景说明

模型 README 通常会说明推荐部署形态与场景。例如 models/glm_5_2/README.md 中明确"默认的 yaml 路径为 32 卡推理"，并给出修改示例：

# 默认 32 卡部署（W8A8 + KV offload） export YAML_FILE_NAME=glm_5_2_rank_32_32ep_w8a8_offload.yaml

3.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. 前置条件检查

在进入提问前，必须确认三项前置：

1. 模型已框架适配（models/<model>/结构完整，入口存在）；
2. infer.sh能跑通；
3. 有可复现精度的 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 / 文本做逐字对比，附最低可用性门槛（可读、不重复、非全零、不提前 EOS）；
• MoE / 量化模型：同上，量化基线允许与浮点有界误差，记录可接受的误差范围；
• 图像 / 视频生成：固定 seed 和 step 数，比对输出图 / 帧的关键指标或可视一致，记录采样器和 step。

可复现性的技术基础在仓库中确实存在：例如 models/glm_5_2/infer.py 在入口处固定随机种子（torch.manual_seed(42)+torch.npu.manual_seed_all(42)），且推理入口支持显式指定 YAML（python 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）。本步仍不写 Dashboard（Dashboard 在候选发现完成后、第 6 步才初始化）、不跑推理。

8. 本步输出

本步的最终产出只有两样，可直接喂给后续流程：

1. 锁定的场景定义（可直接喂给 scenario subagent）；
2. 前置条件结论（满足 / 需先建 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