アカウント使用状況によるCortex AI関数のコスト管理¶
Snowflake Cortex AI関数(AI_COMPLETE、AI_SUMMARIZE、AI_TRANSLATE、AI_SENTIMENTなど)は、トークンまたはページの使用状況に基づいてクレジットを消費します。モニタリングや制御を行わない場合、これらの関数を使用するためのコストは、次の理由によりすぐに上昇する可能性があります。
過剰なトークンを生成する最適化されていないプロンプト
長時間実行または暴走クエリ
ユーザーごとの支出制限がないこと
使用パターンの可視性が不十分であること
このトピックでは、Snowflake Cortex AI関数に関連するコストをモニタリング、管理、制御するための戦略を提案します。CORTEX_AI_FUNCTIONS_USAGE_HISTORYビューを使用すると、使用パターンを追跡し、自動コスト管理を実装できます。これらのテクニックは、使用状況をモニタリングし、支出制限を超えた場合にアラートを発出し、月間の上限に基づいて関数へのアクセスを制御し、暴走クエリを停止するのに役立ちます。
使用履歴ビュー¶
SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORYビューは、SQL経由で呼び出されるすべてのCortex AI関数について詳細なテレメトリーを提供します。ビューの最大レイテンシは60分ですが、データは関数実行開始からわずか10分で利用可能になる場合があります。このビューについて詳しくは、:doc:`/sql-reference/account-usage/cortex_ai_functions_usage_history`を参照してください。
基本的な使用状況のモニタリング¶
次のクエリは、AI関数の使用パターンを理解するのに役立ちます。これらを定期的に自分で実行するか、ダッシュボードに統合して継続的な可視化を行います。
関数やモデルごとの毎日のクレジット消費¶
毎日の支出傾向を追跡して、使用量の急増を特定し、最も多くのクレジットを消費している関数やモデルを把握します。
ユーザーごとの月間クレジット消費¶
上位のコンシューマーを特定し、ユーザーごとの支出を経時的に追跡します。このクエリは、USERSビューとの結合により、メールや既定のロールなどのユーザーの詳細を提供します。これにより、識別とフォローアップが容易になります。
コスト管理¶
過剰な支出を検出し、是正措置を講じる自動メカニズムを定義します。これらのクエリは、互いに独立して使用することも、包括的なコストガバナンスのために組み合わせて使用することもできます。
アカウントレベルでの月間支出アラート¶
アカウント全体におけるAI関数クレジットの月間の合計消費をモニタリングする自動アラートを設定します。支出が定義されたしきい値を超えると、アラートは指定された管理者にメール通知を送信します。アラートを設定するには、次の前提条件が必要です。
ACCOUNTADMINロール、または:ref:`通知統合<label-create_email_notification_integration>`および:ref:`アラート<label-alerts_privileges_granting>`を作成するための適切な権限
アラート条件チェックを実行するウェアハウス
アラート受信者の検証済みメールアドレス
まず、通知統合がまだ存在しない場合は作成します。この例では、``ai_cost_alerts``という名前の既存の統合を置き換えます。
次に、各月のアラートがいつ送信されたかを追跡するテーブルを作成します。これは、1か月以内の重複アラートを防ぐために使用されます。
次に、アラートが今月すでに送信されたかどうかを確認し、アラートの状態を記録してメール通知を送信するストアドプロシージャを作成します。
最後に、支出しきい値に対して使用状況を1時間ごとにチェックし、必要に応じてプロシージャを呼び出して通知を送信するアラートを作成します。以下の例の2か所に表示されている1000クレジットの制限を、目的のしきい値に調整する必要があります。
Tip
テストの目的で、まず制限を0に設定して、アラートをすぐにトリガーします。アラートが期待どおりに機能することを確認した後、目的のしきい値でアラートを再作成します。
しきい値を0に設定したテストの後、次のSQLを実行して、今月アラートが再度トリガーされるようにします。
次のようにアラート履歴とアラート状態テーブルをクエリすると、アラートが動作していることを確認できます。
ユーザーごとの月間支出制限¶
この例では、ユーザーごとの月間の支出制限を実装します。ユーザーには、Cortex AI関数へのアクセスを提供するカスタムの専用AI_FUNCTIONS_USER_ROLEが付与されます。テーブルには、個々のユーザーの月間トークン予算が格納されます。ユーザーがその月の予算を超えると、1時間ごとのタスクによってAI_FUNCTIONS_USER_ROLEが削除され、AI関数へのアクセスが取り消されます。月ごとのタスクによって、ロールは翌月の初めに復元されます。
重要
デフォルトでは、SNOWFLAKE.CORTEX_USERデータベースロールがPUBLICロールに付与されているため、すべてのユーザーがAI関数(およびSnowflake Cortexの他の機能)にアクセスできます。ユーザーごとの制限を適用するには、PUBLICからSNOWFLAKE.CORTEX_USERを取り消し、AI_FUNCTIONS_USER_ROLEを通じてのみ付与する必要があります。次のSQLを使用して、PUBLICからロールを取り消します。
Cortexの機能へのアクセスが必要なすべてのユーザーに対して、AI_FUNCTIONS_USER_ROLEのみが付与されていることを確認してください。SNOWFLAKE.CORTEX_USERを含むその他のロールを使用すると、ユーザーはこの例で実装された支出制限の制御を回避できるようになります。場合によっては、より具体的なロールを使用できます。例えば、Cortex Analystへのアクセスのみが必要なユーザーには、SNOWFLAKE.CORTEX_USERの代わりにSNOWFLAKE.CORTEX_ANALYST_USERロールを付与できます。
ユーザーごとの支出制限を設定するには、まずAI関数へのアクセスを制御するロールを作成し、このアクセスを他の権限とは別に管理できるようにします。
次に、アクセス制御テーブルを設定します。これは、AI関数へのアクセス権を持っているユーザー、個々の支出制限、個々の取り消し履歴を追跡するものです。これは自動モニタリングとアクセス復元のプロセスにおける信頼できる情報源となります。
次に、ユーザーにAI関数へのアクセスを付与し、個々の支出制限とともにアクセス制御テーブルに登録するストアドプロシージャを作成します。このコードは、モニタリングクエリでの効率的な結合を可能にするために、アカウント使用状況ビューからユーザーのIDを検索します。
このストアドプロシージャを使用して、ユーザーとそのクレジットクォータをアクセス制御テーブルに追加します。
次に、月ごとのアクセス更新タスクを作成します。このタスクは毎月1日に実行され、資格のあるすべてのユーザーに対してAI関数へのアクセスを復元します。前の月に制限を超えたためにユーザーのアクセスが取り消された場合、このタスクは、そのユーザーに新しい月の新たな予算を付与します。
最後に、ユーザーの支出をモニターし、月間の制限を超えたユーザーのアクセスを取り消す1時間ごとのタスクを作成します。
暴走クエリの検出とキャンセル¶
長時間実行されるAI関数クエリは、かなりのコストを蓄積する可能性があります。この例では、クレジットのしきい値を超えるクエリを検出し、さらにリソースを消費する前にキャンセルする自動システムを実装します。クエリの完全な詳細が記載されたメールアラートが送信されます。
注釈
クエリがキャンセルされた場合でも、クライアントはキャンセルの瞬間までに消費されたすべてのリソースに関して課金されます。暴走クエリをキャンセルすると、コストがさらに蓄積されることはありませんが、すでに使用されたクレジットは払い戻しされません。
このプロシージャは、過去48時間以内のAI関数クエリのうち、クレジットのしきい値を超えたもの、かつ実行中のものを検索してキャンセルし、管理者にレポートします。
Tip
If you already know that some of your queries will run a long time, define a special role for these queries, and then exclude that role from the cancellation logic. For example, to create the role:
このロールを持つユーザーが実行したクエリをキャンセルから除外するには、プロシージャのWHERE句に次の条件を追加します。
これで、ユーザーはロールを引き受けて、キャンセルされることなく長時間実行されるクエリを実行できます。
ベストプラクティス¶
AI関数の使用状況に関するコスト管理戦略を開発する際は、次のベストプラクティスに留意してください。
**モニタリング開始:**自動制御を実装する前に、:ref:`label-ai_functions_basic_usage_queries`のクエリを使用してベースラインの使用パターンを確立します。
**クエリタグの使用:**プロジェクトやチームごとのコスト配分を可能にするために、QUERY_TAGセッションパラメーターを使用するようチームに推奨します。
**アラートのテスト:**重要なアラートの通知手段として運用を開始する前に、メール通知が正しく機能することを確認します。
**レイテンシの考慮:**ACCOUNT_USAGEビューには最大60分のレイテンシがあります。これをモニタリング戦略に組み込みます。