mcpField
C
cpu-gpu-performance

cpu-gpu-performance

github.com/atholaクラウド・DevOps343111 回インストール1 日前に更新
リポジトリ

cpu-gpu-performance について

CPU や GPU を多く使うビルド、学習、テストを管理するエージェント向けワークフロースキルです。実行前の使用状況確認から、対象の絞り込み、計測、負荷制御、コスト記録までを扱います。

主な機能

  1. 01CPU と GPU の使用状況確認
  2. 02対象を絞ったテスト実行
  3. 03計算と I/O のプロファイリング
  4. 04高負荷タスクの制御と順序付け
  5. 05使用量と次の作業の記録

活用シーン

  1. 01長時間のビルドやテストの前
  2. 02GPU 学習や評価の準備時
  3. 03高負荷コマンドが失敗した後

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athola/claude-night-market --skill cpu-gpu-performance

インストール後、Claude Code で/cpu-gpu-performanceを入力して読み込まれたか確認します。

詳細

CPU/GPU パフォーマンス管理

使用するタイミング

  • 各セッションの開始時（token-conservation とともに自動で読み込みます）。
  • CPU コアまたは GPU を 1 分以上占有する可能性があるものを、ビルド、トレーニング、またはテストする予定があるとき。
  • 以前に大きなリソースを消費したコマンドが失敗し、再実行する前。

使用しないタイミング

  • リソースに影響しない単純な操作
  • すぐに終わる単一ファイルの操作

必須の TodoWrite 項目

  1. cpu-gpu-performance:baseline
  2. cpu-gpu-performance:scope
  3. cpu-gpu-performance:instrument
  4. cpu-gpu-performance:throttle
  5. cpu-gpu-performance:log

ステップ 1：現在のベースラインを確立する

  • 現在の使用率を取得します。

    • uptime
    • ps -eo pcpu,cmd | head
    • nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv

    すでに負荷の高いホストや GPU を記録します。

  • 作業を開始する前に、CI／クラスターの割り当て制限（時間制限、GPU 時間）を記録します。

  • それらの制限を守るタスクごとの CPU 分／GPU 分の予算を設定します。

ステップ 2：対象範囲を絞る

  • 小さな修正の後に「全範囲」のジョブを実行するのは避けます。差分ベースまたはタグベースでテスト対象を選択します。
    • pytest -k
    • Bazel のターゲットパターン
    • cargo test <module>
  • 複数の低レベルの修正をまとめ、対象を絞ったコマンドを 1 回実行して検証します。
  • GPU ジョブでは、トレーニング／評価の全実行を予定する前に、ユニット規模のスモークテスト用入力や少ないエポック数を優先します。

ステップ 3：最適化の前に計測する

  • 適切なプロファイラー／モニターを選びます。
    • CPU 処理：
      • perf
      • intel vtune
      • cargo flamegraph
      • 言語固有のプロファイラー
    • GPU 処理：
      • nvidia-smi dmon
      • nsys
      • nvprof
      • DLProf
      • フレームワークのタイムライン・トレーサー
  • スロットリングや並列化の根拠となるよう、カーネル／オペレーションのタイムライン、メモリ使用量、データパイプラインのレイテンシーを記録します。
  • 今後の再実行で原因箇所をすぐに特定できるよう、ホットパスや I/O のボトルネックをメモに記録します。

ステップ 4：作業を制限して順序立てる

  • nice、ionice、または Kubernetes／Slurm の割り当て制限を使い、共有ノードのリソースが独占されないようにします。
  • 重いタスクはガードレールを設けて順に実行します。
    • 失敗したテスト／モジュールだけを再実行する
    • その後、必要に応じて次に広いシャードへ拡大する
    • 全テストスイートの実行は最終確認用に確保する
  • メモリ圧迫によって GPU から追い出されるおそれがある場合は、GPU カーネルの実行を段階化します（バッチサイズを小さくする、または勾配を蓄積する）。再起動よりチェックポイントからの復元を優先します。

ステップ 5：判断と次の手順を記録する

実行したコマンドとそのリソースコスト（所要時間、CPU%、GPU%）を記録し、タスクごとの予算内に収まったかを確認して締めくくります。全テストスイートや長時間のトレーニングを実行する必要があった場合は、選択的または段階的なアプローチが実行できなかった理由を説明します。今後のセッションを簡素化するため、新しいテストマーカーやプロファイリングのドキュメント作成など、フォローアップタスクを記録します。

出力への期待事項

  • 次の内容を含む簡潔な概要：
    • ベースラインの指標
    • 選択した対象範囲
    • 実施した計測
    • スロットリングの手法
    • フォローアップ項目
  • 実行した内容の具体例（例）：
    • 「pytest -m slow の代わりに pytest tests/test_orders.py -k test_refund を再実行した」
    • 「スケールアップ前に GPU のアイドル時間を示すため、nvidia-smi dmon の出力をプロファイリングした」

完了条件

  • ビルド、トレーニング、またはテストスイートを開始する前に、uptime と ps のベースラインを取得して記録している
  • 対象範囲を差分ベースまたはタグベースのターゲット（例：pytest -k、cargo test <module>）に絞っている。選択的なアプローチが実行できなかった場合は、全テストスイートを実行する理由を記録している
  • 出力の概要に、所要時間、消費した CPU% または GPU%、およびタスクごとの予算内に収まったかどうかが含まれている
  • 新しいテストマーカーやプロファイリングのドキュメントなどのフォローアップタスクを、セッション後も残るよう Todo または課題に記録している

コメント

Markdown 対応