以前は Azure AI サービスまたは Azure Cognitive Services と呼ばれていたもので、Microsoft Foundry プラットフォームに含まれる事前構築済みの AI 機能の統合コレクションです
おもや omoya Mikoshiba
ご返信が遅れてしまい、申し訳ございません。
計算負荷の高い入力については、応答時間やトークン数の増加を指標として測定することが可能です。
トークン数は、クエリの複雑さや長さに応じて増加します。
診断設定を有効にすることで、さまざまなメトリクスを収集でき、複雑または長文のクエリごとに異なるトークン量を可視化することができます。
promptTokens
completionTokens
処理済みトークン数
タイムスタンプ
デプロイメント名
また、KQL クエリを使用してカスタム監視ダッシュボードを作成することも可能です。
https://learn.microsoft.com/ja-jp/azure/data-explorer/azure-data-explorer-dashboards
https://learn.microsoft.com/ja-jp/azure/foundry/observability/concepts/trace-agent-concept
レイテンシの間接的な制御について
トークン消費量および応答時間は、以下のようなパラメータを調整することで制御することが可能です:
max_completion_tokens
temperature
また、複雑なプロンプトをよりシンプルなものに分割することや、モデルルーターを使用することでも改善が可能です。
以下は、同僚が説明した手順および設定(Azure OpenAI → メトリクス → レイテンシ → アラート)を直接裏付ける Microsoft 公式リファレンスです。
1. Azure OpenAI のレイテンシメトリクス(Time to Response)
✅ メトリクス: Time to Response(応答時間)
Microsoft は、Azure OpenAI ワークロードにおける正しいレイテンシ指標として Time to Response を明示しており、従来の Cognitive Services のレイテンシメトリクスは使用しないよう注意喚起しています。
公式リファレンス Azure OpenAI の監視データ リファレンス
「Azure OpenAI のレイテンシ監視には、Time to Response、Time to Last Byte、Time Between Tokens、または Normalized Time to First Byte を使用してください。」
2. メトリック名前空間とディメンション
✅ メトリック名前空間 Azure OpenAI – Latency
✅ サポートされるディメンション
deploymentName
modelName
これらのディメンションは、Azure OpenAI メトリクスでサポートされているものとして明示されています。
公式リファレンス 監視データ リファレンス – メトリック ディメンション
これは次の説明を裏付けます: 「これにより、高負荷なプロンプトを受信している特定のデプロイメントやモデルを特定・切り分けることができます。」
3. 集計方法(Avg / P95 / P99)
Microsoft は、テールレイテンシや異常なスパイクを特定するために、パーセンタイルを使用した分析を推奨しています。
公式リファレンス Azure OpenAI のパフォーマンスとレイテンシ
平均レイテンシ → ベースラインの挙動
P95 / P99 → 外れ値や負荷集中のシナリオ
✅ 以下が有効であることを示しています:
平均(Avg)
パーセンタイル(P95 / P99)
4. ベースライン レイテンシの確立
Microsoft は、しきい値を定義する前に、実際のワークロードの挙動を観察することを明確に推奨しています。
公式リファレンス レイテンシの評価 – Azure OpenAI
レイテンシはモデル、トークンサイズ、同時実行数によって変動するため、ベースラインは Azure Monitor の過去データに基づいて算出する必要があり、仮定すべきではありません。
✅ 以下の指示を裏付けます: 「まず通常どおりにワークロードを実行し、ベースラインのレイテンシグラフを観察してください。」
5. しきい値(例:> 2000 ms)
Microsoft は固定のレイテンシ SLA を公開しておらず、しきい値はワークロードに依存すると明示しています。
公式リファレンス Azure OpenAI のパフォーマンスとレイテンシ
例: 「応答時間が 2000 ms を超える(またはワークロードに応じてそれ以上)」
✅ これは固定値ではなく例として提示されているため、適切な説明です。
6. Azure Monitor メトリック アラートの作成
✅ メトリックベースのアラートは完全にサポートされています。
Azure Monitor では、以下を含むアラートを作成できます:
メトリック条件
集計方法(Avg / P95 / P99)
ディメンション フィルター
公式リファレンス Azure Monitor メトリック アラートの作成
✅ 以下の内容を裏付けます:
Time to Response をシグナルとして使用
しきい値ベースのアラート
デプロイメント/モデル単位のアラート設定
7. Azure OpenAI のエンドツーエンド監視
Microsoft は包括的な監視ガイドも提供しています。
公式リファレンス Microsoft Foundry における Azure OpenAI の監視
このドキュメントでは以下を統合的に説明しています:
メトリクス
アラート
Log Analytics
パフォーマンス診断
お役に立てば幸いです。
よろしくお願いいたします。以下が日本語(ja‑JP)への翻訳です:
おもや 御柴様
ご返信が遅れてしまい、申し訳ございません。
計算負荷の高い入力については、応答時間やトークン数の増加を指標として測定することが可能です。
トークン数は、クエリの複雑さや長さに応じて増加します。
診断設定を有効にすることで、さまざまなメトリクスを収集でき、複雑または長文のクエリごとに異なるトークン量を可視化することができます。
promptTokens
completionTokens
処理済みトークン数
タイムスタンプ
デプロイメント名
また、KQL クエリを使用してカスタム監視ダッシュボードを作成することも可能です。
https://learn.microsoft.com/ja-jp/azure/data-explorer/azure-data-explorer-dashboards
https://learn.microsoft.com/ja-jp/azure/foundry/observability/concepts/trace-agent-concept
レイテンシの間接的な制御について
トークン消費量および応答時間は、以下のようなパラメータを調整することで制御することが可能です:
max_completion_tokens
temperature
また、複雑なプロンプトをよりシンプルなものに分割することや、モデルルーターを使用することでも改善が可能です。
以下は、同僚が説明した手順および設定(Azure OpenAI → メトリクス → レイテンシ → アラート)を直接裏付ける Microsoft 公式リファレンスです。
1. Azure OpenAI のレイテンシメトリクス(Time to Response)
✅ メトリクス: Time to Response(応答時間)
Microsoft は、Azure OpenAI ワークロードにおける正しいレイテンシ指標として Time to Response を明示しており、従来の Cognitive Services のレイテンシメトリクスは使用しないよう注意喚起しています。
公式リファレンス
Azure OpenAI の監視データ リファレンス
「Azure OpenAI のレイテンシ監視には、Time to Response、Time to Last Byte、Time Between Tokens、または Normalized Time to First Byte を使用してください。」
2. メトリック名前空間とディメンション
✅ メトリック名前空間
Azure OpenAI – Latency
✅ サポートされるディメンション
deploymentName
modelName
これらのディメンションは、Azure OpenAI メトリクスでサポートされているものとして明示されています。
公式リファレンス
監視データ リファレンス – メトリック ディメンション
これは次の説明を裏付けます:
「これにより、高負荷なプロンプトを受信している特定のデプロイメントやモデルを特定・切り分けることができます。」
3. 集計方法(Avg / P95 / P99)
Microsoft は、テールレイテンシや異常なスパイクを特定するために、パーセンタイルを使用した分析を推奨しています。
公式リファレンス
Azure OpenAI のパフォーマンスとレイテンシ
平均レイテンシ → ベースラインの挙動
P95 / P99 → 外れ値や負荷集中のシナリオ
✅ 以下が有効であることを示しています:
平均(Avg)
パーセンタイル(P95 / P99)
4. ベースライン レイテンシの確立
Microsoft は、しきい値を定義する前に、実際のワークロードの挙動を観察することを明確に推奨しています。
公式リファレンス
レイテンシの評価 – Azure OpenAI
レイテンシはモデル、トークンサイズ、同時実行数によって変動するため、ベースラインは Azure Monitor の過去データに基づいて算出する必要があり、仮定すべきではありません。
✅ 以下の指示を裏付けます:
「まず通常どおりにワークロードを実行し、ベースラインのレイテンシグラフを観察してください。」
5. しきい値(例:> 2000 ms)
Microsoft は固定のレイテンシ SLA を公開しておらず、しきい値はワークロードに依存すると明示しています。
公式リファレンス
Azure OpenAI のパフォーマンスとレイテンシ
例:
「応答時間が 2000 ms を超える(またはワークロードに応じてそれ以上)」
✅ これは固定値ではなく例として提示されているため、適切な説明です。
6. Azure Monitor メトリック アラートの作成
✅ メトリックベースのアラートは完全にサポートされています。
Azure Monitor では、以下を含むアラートを作成できます:
メトリック条件
集計方法(Avg / P95 / P99)
ディメンション フィルター
公式リファレンス
Azure Monitor メトリック アラートの作成
✅ 以下の内容を裏付けます:
Time to Response をシグナルとして使用
しきい値ベースのアラート
デプロイメント/モデル単位のアラート設定
7. Azure OpenAI のエンドツーエンド監視
Microsoft は包括的な監視ガイドも提供しています。
公式リファレンス
Microsoft Foundry における Azure OpenAI の監視
このドキュメントでは以下を統合的に説明しています:
メトリクス
アラート
Log Analytics
パフォーマンス診断
お役に立てば幸いです。
よろしくお願いいたします。