0
0

昇腾推理性能分析：msprof、PyTorch Profiler 与服务时间线

2026-10-17
工程实践与复盘

整理日期：2026-09-16。依据北京时间 2026-09-15 的可见提问摘录及本次核查的一手资料补写；未取得完整原始回答，非逐字转录。命令为操作示例，本次未在用户服务器执行。

问题起点

你问 910C 八卡集群推理 GLM 时如何采集和分析 profiling，以及 msprof 与 torch profiler 是否替代。还问到 Fabric、HDK 和“性能劣化”相关术语。

工具分工

torch.profiler 是 PyTorch 的性能分析接口体系；昇腾场景需看 torch_npu.profiler 与具体框架接入。Ascend PyTorch Profiler 可关联框架、CANN 和 NPU 侧事件。msprof 是昇腾性能采集/分析工具入口，两者存在底层能力交集，但不能简单理解为互斥替代。Ascend PyTorch Profiler 官方说明

vLLM-Ascend 还提供面向服务函数和调度过程的 MS Service Profiler。定位算子时间与定位排队/调度时间，需要不同观察层次。

当前官方服务采集路径

核查于 2026-09-16。当前服务指南使用 --profiler-config 配置 torch profiler，并通过 /start_profile 与 /stop_profile 控制采集。示意配置：

--profiler-config '{"profiler":"torch","torch_profiler_dir":"./vllm_profile","torch_profiler_with_stack":false}'

服务需以相应配置启动；随后在服务所在网络环境中执行：

curl -X POST http://localhost:8077/start_profile
# 发送少量有代表性的推理请求
curl -X POST http://localhost:8077/stop_profile

端口沿用你的服务场景，命令尚未实测。旧镜像可能采用不同入口，先查 vllm serve --help 和该版本文档。当前指南强调 PD 两侧独立配置与控制，代理不一定转发采集接口。官方服务性能分析指南

看时间线之前先明确问题

TTFT 高：区分排队、tokenization、prefill、图编译/预热和 KV 交接。

TPOT 高：看每步算子、KV 读取、通信等待、Host 下发间隙及并发变化。

多卡不均衡：区分某 rank 做的计算多、链路慢，还是在等待另一个慢 rank。

这三组是分析框架，不是对当前 GLM 问题的根因判断。

最小实验闭环

先记录无 profiler 的稳定负载指标；预热后采集短窗口；保存所有相关 rank 的输出；比较 kernel、通信和 Host 时间；每次只调整一个主要变量，再回到无 profiler 的吞吐和延迟验证。

多 rank 时间需要正确对齐。各 kernel 时长相加可能超过墙钟时间，因为存在并行和重叠；调用次数和等待时间也不能直接当作算子计算量。Profiler 本身可能改变开销，采集结果用于定位，最终性能仍以正常运行测量为准。

术语与边界

Fabric 通常指互连网络体系；HDK 在本场景对应昇腾硬件配套开发/驱动固件组件，不能与 CANN 或整个推理框架混为一谈。

原提问中的“MAL 劣化”缺少原始上下文，不能确认缩写含义，更不能自动改写为 MLA。已在总览保留待确认项。

关联：昇腾 NPU 监控工具选型：从 npu-smi 到 nputop 与集群可观测性。

2026-09-17 增量：从性能截图到可复用分析 Skill

你要求创建与截图类似的 Ascend/vLLM-Ascend 性能分析表格流程。当前已能读取已安装的 ascend-inference-profiler-analysis 技能说明；本次核对的是技能规范，没有重新读取或验证昨天导出的 Excel 文件，也没有新增实测数据。

规范把分析链组织为：模型模块 → 逻辑算子 → 底层 Kernel → 热点 → 验证动作，并要求保留原始数据、算子分析、热点 TopN、规则与假设四类工作表。

最值得保留的方法

测量值、计算值、命名映射、源码确认和优化假设必须分开。单位缺失就标待确认；仅凭 kernel 名不能断言 C8、融合方案或特定模型路径已经启用。Avg×Calls 与累计时间要检查一致性，占比必须写清分母。

算子累计耗时不是墙钟延迟；跨 Stream 或 rank 的重叠不能重复算作串行关键路径。小算子既要单项排序，也要按子路径合计判断是否值得融合；没有性能计数器时，计算受限/带宽受限只能作为待验证判断。

实际使用时输入原始 trace/summary、场景与统计口径，再把建议转成“预期信号＋对照实验”：kernel 数量、搬运字节、通信等待、TTFT/TPOT、数值误差分别如何改变。本次只有流程规范核查，不把模板交付说成优化已取得收益。