huawei-cloud-ascend-profiler-db-explorer

Huawei Cloud Ascend Profiler DB Explorer

概要

このスキルは、プロファイリングデータに関する自然言語の質問を、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 のディスパッチ時間の差を確認して」
• 「オペレーターデータのテーブルスキーマを表示して」
• 「オペレーター？」
• 「オペレーターのパフォーマンスを分析して」
• 「プロファイリングデータベースをクエリして」

スキルの目標

• 自然言語の質問を SQL の下書きに変換する：事前設定済みの CTE マクロと辞書ルールに基づいて、安全で読みやすいプロファイリングクエリをすばやく作成します。
• 統一されたエントリーポイント：「オペレーター時間」、「通信時間」、「ディスパッチ分析」、または特定のプロファイリング DB クエリに関する質問では、必ず最初にこのスキルのみを起動する必要があります。
• 場当たり的な 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

必須の制限事項

• メインクエリは、次のいずれかを少なくとも1つ満たす必要があります。
  • 集計関数（例：SUM、AVG、COUNT など）を含む、または
  • ORDER BY ... LIMIT 20（または20以下の LIMIT）を明示的に含む。
• ユーザーがファイルへの出力を指示した場合に限り、msprof_mcp が提供する execute_sql_to_csv ツールを使用し、テーブル全体のスキャンを許可します。
• このスキルでは、テーブル構造の説明をまず scripts/get_schema.py から取得してください。ドキュメントにテーブル情報がない場合に限り、補足として PRAGMA table_info(TABLE) を使用しますが、通常の手段として使用してはいけません。

トラックA：Golden Views／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. 現在のDBから実際のテーブル名を取得する（推奨）

まず、対象DBに対してsqliteクエリを実行し、現在のバージョンに存在する実際のテーブルを取得します。

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

注：この手順は「現在のDBに実際に存在するテーブル」の取得のみに使用し、フィールドレベルのスキーマ解析には使用しません。フィールドの説明には、get_schema.py --table_name を使用してください。

2. スクリプトでドキュメントとDBを照合する（推奨）

• 目的：ドキュメントのテーブル名や現在のDBのテーブル名を自動で一覧表示するか、両者の共通部分を直接比較し、手作業での絞り込みを減らします。
• コマンドラインの例：

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 で再利用必須）

【最重要の警告】以下は Ascend Profiling 専用のマクロブロック（CTE）です。 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 搭載のボトルネック診断システムが含まれています。

機能：

• 根本原因の自動分析：プロファイリングデータからパフォーマンスのボトルネックを特定します
• ボトルネックの分類：ボトルネックをメモリ律速、計算律速、通信律速、演算子フォールバックの各タイプに分類します
• 実行可能な推奨事項：優先度付きの最適化推奨事項を提示します
• パターンマッチング：既知のパフォーマンス上のアンチパターンを検出し、修正方法を提案します
• 影響評価：各最適化によって見込まれるパフォーマンス改善を推定します

ボトルネックの分類：

カテゴリ	特徴	原因	戦略
メモリ律速	高いメモリ帯域幅	TransData ops	転送を削減
計算律速	高い AI_CORE 使用率	大規模な matmul	演算を最適化
通信律速	HCCL ops の割合が高い	非効率な coll	通信を最適化
演算子フォールバック	AI_CPU で実行	NPU 実装がない	AscendC ops

ボトルネック診断の出力：

## 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"

パラメーターの確認

パラメーター	説明	必須
db	Profiler データベースのパス	はい
query	自然言語によるクエリ	はい
output	出力形式	いいえ