For the complete documentation index, see llms.txt. This page is also available as Markdown.

ワークフローのプロファイリング

Chrome互換のプロファイリングトレースで、ワークフロー実行時間を測定し、ボトルネックを特定します。

プロファイリングを有効にすると、ワークフローの実行時間を測定し、パフォーマンスのボトルネックを特定できます。プロファイリングのトレースは、可視化のために Chrome の内蔵トレースツールと互換性があります。

例のワークフロー

このガイドのスクリーンショットでは、以下のワークフローを例として使用しています。これには、2回のオブジェクト検出、動的クロッピング、Google Gemini 呼び出し、およびいくつかの可視化ステップが含まれます:

Example workflow in the Roboflow editor
以下のプロファイリング用スクリーンショットで使用されている例のワークフロー

Inference SDK によるプロファイリング

HTTP クライアント経由でワークフローを実行する際にプロファイリングを有効にするには、まずセルフホストの Inference ServerENABLE_WORKFLOWS_PROFILING=True 環境変数を設定して実行する必要があります。その後、HTTP クライアント経由でワークフローを実行する際に、次を設定してプロファイリングを有効にできます。 enable_profiling=True:

プロファイリングが有効な場合、トレースファイルは自動的に ./inference_profiling/ に保存されます。デフォルトでは、各トレースファイルは workflow_execution_tack_{timestamp}.json.

プロファイリングトレースの表示

プロファイリングトレースは Chrome Tracing Format で保存されます。可視化するには:

  1. Chrome を開き、次へ移動します chrome://tracing/.

  2. クリックして Load を選び、トレースファイルを選択します(例: workflow_execution_tack_2026_03_30_10_46_04.json).

  3. タイムライン表示を使って、各ワークフローステップの実行タイミングを確認します。

任意のスパンをクリックすると、その継続時間、カテゴリ、引数が表示されます - たとえば、どのブロックの step_execution を見ているのかがわかります:

Chrome tracing timeline with a selected step

ほとんどの時間は 2 回のオブジェクト検出(process 57)と Gemini 呼び出し(process 78)に費やされています。拡大すると、オブジェクト検出ステップの間にある他のステップ(検出オフセット、動的クロッピング、可視化など)を確認できます:

Chrome tracing aggregated statistics view

重要な詳細

詳細

トレース形式

JSON、Chrome の chrome://tracing/ ツールと互換性あり

出力先

./inference_profiling/ デフォルトでは(設定可能)

ファイル名規則

workflow_execution_tack_{YYYY_MM_DD_HH_MM_SS}.json

制限事項

  • コンパイルのオーバーヘッド: ワークフローのコンパイルにより 10〜25ms のレイテンシが追加されます。これは、GPU 推論時間がそれに匹敵する小規模・高速モデルでは大きな影響があります。このオーバーヘッドは、ビデオ処理では開始時に一度だけ発生します。

  • 実行エンジンのレイテンシ: Workflows Execution Engine は、フレームごとに約 1〜2ms の名目上のレイテンシを追加します。

  • 動的ブロック: 動的ブロックを使用するセルフホスト型デプロイでは、pydantic モデルの再構築により、リクエストごとに +100〜140ms のレイテンシが発生する場合があります。これはホスト型プラットフォームには当てはまらず、コンパイルが一度だけ行われるビデオ処理にも当てはまりません。

  • モデルブロックの支配的な割合: 通常、実行時間の約 95% はモデル推論そのものに費やされます。これには追加のデータ変換とメタデータ管理が含まれます。

パフォーマンス向上のヒント

  • ワークフロー定義はデフォルトで 15 分間キャッシュされます。必要に応じて use_cache=Falserun_workflow() で使用して、キャッシュをバイパスしてください。

  • ビデオ処理では、オーバーヘッドは開始時に一度だけ発生するため、コンパイルのオーバーヘッドは無視できるほど小さいです。

  • ワークフローをプロファイリングして、ボトルネックがモデル推論、データ変換、またはワークフローのオーケストレーションのどこにあるかを特定してください。

最終更新

役に立ちましたか?