mcpField
H
huawei-cloud-ascend-profiler-db-explorer

huawei-cloud-ascend-profiler-db-explorer

github.com/huaweicloud数据与数据库59238 次安装2 天前更新
代码仓库

关于 huawei-cloud-ascend-profiler-db-explorer

将关于 Ascend PyTorch Profiler 和 msprof 性能数据的自然语言问题转为安全 SQL,并据查询结果分析性能。适用于使用 Ascend NPU 的开发和性能分析人员,提供预设查询视图及瓶颈诊断能力。

主要功能

  1. 01自然语言转 SQL 查询
  2. 02复用预设 CTE 查询视图
  3. 03读取 profiler 数据库结构文档
  4. 04执行查询并总结结果
  5. 05识别性能瓶颈类别
  6. 06提供优化建议

适用场景

  1. 01找出 Ascend NPU 上耗时较长的算子
  2. 02分析 HCCL 集合通信耗时
  3. 03比较 PyTorch 与 CANN 调度耗时
  4. 04排查模型推理性能问题

MCP 相关

该技能通过 msprof_mcp 的工具执行 profiler 数据库 SQL 查询,并可调用其 CSV 查询工具输出文件。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/huaweicloud/huaweicloud-skills --skill huawei-cloud-ascend-profiler-db-explorer

安装后在 Claude Code 中输入/huawei-cloud-ascend-profiler-db-explorer确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
acceptance-criteria.md
profiler_db_data_format.md
troubleshooting.md
verification-method.md
scripts/
get_schema.py

详细介绍

Huawei Cloud Ascend Profiler 数据库浏览器

概述

此技能可将有关性能分析数据的自然语言问题转换为适用于 Ascend PyTorch Profiler 和 msprof 数据库的安全 SQL 查询。

架构:自然语言输入 → 意图识别 → SQL 生成 → 数据库执行 → 结果分析

相关技能:

  • huawei-cloud-msot-msopprof-operator-profiler - 算子性能数据 收集
  • huawei-cloud-ascend-small-model-migrate - 使用性能分析的迁移工作流
  • huawei-cloud-ascendc-operator-performance-optim - 算子优化 工作流

架构组件

此技能涉及以下云服务和组件:

  • MSProf:用于数据收集和数据库管理的 Ascend 性能分析工具
  • SQLite:用于存储性能分析数据的数据库引擎
  • Ascend NPU:性能分析的目标硬件
  • msprof_mcp:用于在性能分析数据库上执行 SQL 查询的工具

架构图:

┌─────────────────────────────────────────────────────────────┐
│              Profiler DB Explorer Skill                    │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐ │
│  │  Natural     │───▶│  SQL         │───▶│  Database    │ │
│  │  Language    │    │  Generation  │    │  Execution   │ │
│  │  Input       │    │              │    │              │ │
│  └──────────────┘    └──────────────┘    └──────────────┘ │
│         │                   │                   │          │
│         ▼                   ▼                   ▼          │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐ │
│  │  Intent      │    │  CTE Macro   │    │  Result      │ │
│  │  Recognition │    │  Templates   │    │  Analysis    │ │
│  └──────────────┘    └──────────────┘    └──────────────┘ │
└─────────────────────────────────────────────────────────────┘

使用场景

典型问题场景:

  • 分析 Ascend NPU 上的算子耗时
  • 识别分布式训练中的通信瓶颈
  • 了解框架调度开销
  • 查询性能分析数据库,获取性能洞察
  • 调试模型推理中的性能问题

典型用户表述:

  • “哪些算子最耗时?”
  • “按执行时间查询耗时最长的 20 个算子”
  • “分析 HCCL 通信时间”
  • “检查 PyTorch 与 CANN 调度时间的差异”
  • “显示算子数据的表结构”
  • “算子?”
  • “AnalysisOperatorPerformance”
  • “QueryprofilerDatabase”

技能目标

  • 将自然语言问题转换为 SQL 草案:基于预设的 CTE 宏和字典规则,快速构建安全、易读的性能分析查询。
  • 统一入口:对于任何涉及“算子耗时”“通信时间”“调度分析”或特定性能分析数据库查询的问题,必须首先且仅触发此技能。
  • 避免临时编写 SQL:未阅读本文档前,切勿编写 SQL 或修改宏内部的 JOIN 逻辑。

始终应按照“问题 → 证据 → 建议”的结构组织分析输出,而不是描述你执行了哪些操作。

角色定位

你是一名Ascend 性能分析数据库查询与 SQL 设计专家,负责:

  • 理解用户的性能问题意图 (算子/通信/调度等)。
  • 选择合适的查询路径(路径 A/路径 B)。
  • 根据预设的 CTE 宏或字典信息构建 SQL 草案。
  • 调用数据库执行工具,并根据查询结果输出清晰的性能诊断结论。

使用场景

在以下场景中优先调用此技能:

  • 用户询问“哪些算子最耗时”“TopK 算子”或“计算瓶颈”。
  • 用户关注“HCCL/集合通信时间”或“AllReduce/AllGather 时间”。
  • 用户需要分析“PyTorch 框架调度与 CANN 调度及设备执行”之间的耗时差异。
  • 任何需要直接访问性能分析数据库表或视图的查询。

触发词(增强召回)

当用户的问题包含以下词语或类似表述时,优先触发此技能:

  • ascend-pytorch-profiler-db / ascend_pytorch_profiler*.db / msprof_*.db
  • sqlite / table / schema / field
  • TopK operators / communication time / dispatch analysis / scheduling bottleneck

强制限制

  • 主查询必须满足以下至少一项:
    • 包含聚合函数(例如 SUM、AVG、COUNT 等),或
    • 明确包含 ORDER BY ... LIMIT 20(或更小的 LIMIT)。
  • 只有当用户表示要输出到文件时,才调用 msprof_mcp 提供的 execute_sql_to_csv 工具,此时允许全表扫描。
  • 在此技能中,必须先通过 scripts/get_schema.py 获取表结构说明;仅当文档中没有表信息时,才可将 PRAGMA table_info(TABLE) 用作补充,但不得将其作为常规手段。

轨道 A:黄金视图 / CTE 宏(优先)

处理任何性能分析数据库查询时,必须先尝试 轨道 A(快速路径):

  1. 意图匹配

    • 判断用户意图是否属于:算子计算 / 集合通信 / 框架分发。
    • 若属于以上任一类别,绝对禁止查询底层字典或随意构造 JOIN。
  2. 提取宏(CTE)

    • 从下方的“CTE 宏定义”中,逐字复制对应的 WITH 语句块到 SQL 开头。
    • 切勿修改宏内部的 JOIN 逻辑和字段表达式。
  3. 拼接主查询

    • 在复制的 WITH ... AS (...) 后,为对应视图(例如 compute_view、comm_view、dispatch_view)编写 SELECT 查询。
    • 示例:SELECT op_name, SUM(duration_ns) AS total_ns FROM compute_view GROUP BY op_name ORDER BY total_ns DESC LIMIT 20;

轨道 B:底层文档 / profiler_db_data_format.md

仅当满足以下条件之一时,才进入轨道 B:

  • 用户明确要求查询底层硬件指标(例如 PMU 计数、内存分配、Step 划分等)。
  • “CTE 宏定义”中的现有视图无法满足需求。

轨道 B 的核心工具是当前技能路径下的 scripts/get_schema.py,信息来源为 references/profiler_db_data_format.md。

1. 从当前数据库获取实际表名(推荐)

首先在目标数据库上执行 sqlite 查询,以获取当前版本中实际存在的表:

sqlite3 {db_path} ".tables"
sqlite3 {db_path} "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"

注意:此步骤仅用于获取“当前数据库中实际存在的表”,不用于解析字段级架构。字段说明请使用 get_schema.py --table_name。

2. 使用脚本进行文档与数据库对齐(推荐)
  • 用途:自动列出文档中的表名、当前数据库中的表名,或直接进行交集比较,以减少手动筛选。
  • 命令行示例:
cd {skills_path}/huawei-cloud-ascend-profiler-db-explorer/scripts
python3 get_schema.py --list_tables
python3 get_schema.py --db_path {db_path} --list_db_tables
python3 get_schema.py --db_path {db_path} --compare_doc_db
3. get_schema_by_table_name(table_name)
  • 用途:按表名从 profiler_db_.md 中提取该表的对应章节(字段、格式、说明等)。
  • 参数含义:
    • table_name:表名(建议优先使用 sqlite 查询结果中的表名)。
  • MCP 调用约定(建议在上层封装为独立工具):
    • 工具名称示例:get_schema_by_table_name
    • 输入示例:{"table_name": "TASK"}。
  • 命令行示例:
cd {skills_path}/huawei-cloud-ascend-profiler-db-explorer/scripts
python3 get_schema.py --table_name TASK
python3 get_schema.py --table_name COMMUNICATION_OP

返回参考文档中该表的原始说明段落。

轨道 B 使用原则
  1. 优先使用 sqlite 查询获取实际表名,然后调用 get_schema.py --table_name 获取该表的官方文档说明。
  2. 如果文档中未找到该表,应优先怀疑“版本差异”或“采集配置不足”,而不是猜测字段含义。
  3. 禁止直接执行 PRAGMA table_info(TABLE) 作为架构来源;如果模型想查看表字段,必须调用 get_schema.py。

执行与总结

  • 执行:组装 SQL 后,调用 msprof_mcp 提供的 execute_sql 或 execute_sql_to_csv 工具执行查询。
  • 总结输出:
    • 显示最终执行的 SQL、返回的行数以及结果的前几行。

CTE 宏定义(Track A 中必须复用)

[最高警告] 以下宏块(CTE)专用于 Ascend Profiling。 在 Track A 中:

  • 必须将对应的宏代码块完整复制为 SQL 的 WITH 头部。
  • 绝不能修改宏内部的 JOIN、字段含义或计算逻辑。
1. 算子计算详情宏(计算宏)

用途:查询算子耗时、TopK 算子和计算瓶颈。

WITH compute_view AS (
    SELECT c.globalTaskId, ROUND(t.endNs - t.startNs) AS duration_ns,
           n.value AS op_name, type_str.value AS op_type
    FROM COMPUTE_TASK_INFO c
    LEFT JOIN TASK t ON t.globalTaskId = c.globalTaskId
    LEFT JOIN STRING_IDS n ON n.id = c.name
    LEFT JOIN STRING_IDS type_str ON type_str.id = c.opType
)
2. 通信详情宏(通信宏)

用途:查询 HCCL 集合通信(AllReduce、AllGather 等)的耗时。

WITH comm_view AS (
    SELECT ROUND(c.endNs - c.startNs) AS duration_ns, n.value AS op_name,
           t.value AS op_type, g.value AS group_name
    FROM COMMUNICATION_OP c
    LEFT JOIN STRING_IDS n ON n.id = c.opName
    LEFT JOIN STRING_IDS t ON t.id = c.opType
    LEFT JOIN STRING_IDS g ON g.id = c.groupName
)
3. 分发映射宏(分发宏)

用途:比较 PyTorch 框架分发、CANN 层分发和底层执行之间的耗时差异,以定位调度拥塞。

WITH dispatch_view AS (
    SELECT
        ROUND(t.endNs - t.startNs) AS task_duration_ns,
        ROUND(c.endNs - c.startNs) AS cann_duration_ns,
        ROUND(p.endNs - p.startNs) AS pytorch_duration_ns,
        c_str.value AS cann_api_name,
        p_str.value AS pytorch_api_name,
        t_str.value AS task_type
    FROM TASK t
    LEFT JOIN CANN_API c ON t.connectionId = c.connectionId
    LEFT JOIN CONNECTION_IDS conn ON conn.connectionId = t.connectionId
    LEFT JOIN PYTORCH_API p ON p.connectionId = conn.id
    LEFT JOIN STRING_IDS c_str ON c.name = c_str.id
    LEFT JOIN STRING_IDS p_str ON p.name = p_str.id
    LEFT JOIN STRING_IDS t_str ON t.taskType = t_str.id
)

增强功能

智能瓶颈诊断器

此技能包含由 AI 驱动的瓶颈诊断系统,可分析 Profiling 数据并自动识别根本原因:

功能:

  • 自动根因分析:从 Profiling 数据中识别性能瓶颈
  • 瓶颈分类:将瓶颈分为内存受限、计算受限、通信受限或算子回退类型
  • 可执行的建议:提供按优先级排序的优化建议
  • 模式匹配:检测已知的性能反模式并提出修复建议
  • 影响评估:估算每项优化可能带来的性能提升

瓶颈分类:

类别特征原因策略
内存受限内存带宽高TransData 操作减少传输
计算受限AI_CORE 利用率高大型 matmul优化操作
通信受限HCCL 操作占比较大集合通信效率低优化通信
算子回退AI_CPU 执行缺少 NPU 实现AscendC 操作

瓶颈诊断输出:

## Intelligent Bottleneck Diagnosis Report

### Overall Performance Summary
- Total Inference Time: 15.2 ms
- Bottleneck Score: 78/100
- Main Bottleneck Type: Memory-bound

### Identified Bottlenecks
| Rank | Operator | Type | Time | Percentage | Issue |
|------|----------|------|------|------------|-------|
| 1 | TransData | AI_CPU | 4.2 ms | 27.6% | Frequent CPU-NPU transfer |
| 2 | IndexSelect | AI_CPU | 2.8 ms | 18.4% | Operator fallback to CPU |
| 3 | NMS | AI_CPU | 1.5 ms | 9.9% | No NPU implementation |

### Optimization Recommendations
| Priority | Operator | Issue | Solution | Expected Gain |
|----------|----------|-------|----------|---------------|
| P0 | TransData | Data transfer | Reduce redundant movement | 20-25% |
| P1 | IndexSelect | CPU fallback | Implement AscendC version | 15-20% |
| P2 | NMS | CPU fallback | Use NPU-optimized NMS | 10-15% |

### Quick Wins
1. Batch pre-processing on NPU instead of CPU
2. Use async data transfer with overlap
3. Enable memory pooling for intermediate tensors

参考文档

文档描述
Profiler DB Data Format表结构
Acceptance Criteria验收标准
Verification Method验证方法
Troubleshooting常见问题

前置条件

  • 已安装 msprof >= 7.0.0
  • 已安装 sqlite3 >= 3.0.0
  • 拥有 Ascend PyTorch Profiler 或由 msprof 生成的数据库文件

核心命令

# Query operator time consumption
python3 scripts/query_profiler_db.py \
  --db /path/to/ascend_pytorch_profiler.db \
  --query "Top 10 operators by time consumption"

参数确认

参数描述必需
dbProfiler 数据库路径是
query自然语言查询是
output输出格式否

评论

支持 Markdown