Function Compute:課金概要

試用クォータ

Function Compute は、初めて利用するユーザー向けに試用クォータ (CU の試用リソースプラン) を提供します。他の種類のリソースプランを購入していない場合、各課金サイクルでは、試用クォータを超えた使用量は従量課金で請求されます。

従量課金

実際に消費したコンピューティングリソースに基づいて課金されます。デフォルトでは、最小インスタンス数が 0 の場合、関数呼び出しがないときは課金されません。ただし、最小インスタンス数を 1 以上に設定すると、インスタンスは 24 時間 365 日稼働し、継続的に課金されます。具体的には、リクエスト処理中はエラスティックインスタンス (アクティブ) の料金が適用され、アイドル期間 (保留中のリクエストがない状態) にはエラスティックインスタンス (アイドル) の料金が適用されます。詳細については、「最小インスタンス数のスケーリングポリシーを設定する」をご参照ください。

リソースプラン

Function Compute は、月額および年額の CU リソースプランを提供します。リソースプランを購入すると、リソース消費はまずリソースプランから相殺されます。プランを使い切ると、請求は自動的に従量課金に切り替わります。リソースプランは単価が低いため、全体のコストを削減できます。

常駐リソースプール (サブスクリプション)

常駐リソースプールは、月額サブスクリプションを通じて GPU コンピューティングキャパシティを予約します。プールを購入し、GPU 関数に常駐インスタンスを割り当てることで、コールドスタートなしで予測可能なコストを実現できます。

課金項目

Function Compute (FC) の料金は、次の 2 つの部分で構成されます。

• CU 使用量：FC では、CU 使用量を統一された課金項目として使用します。すべてのリソース使用量は、固定の換算係数を使用して CU 使用量に変換されます。このトピックでは、CU 使用量の測定と課金方法について説明します。

• アウトバウンドインターネットトラフィック：アウトバウンドインターネットトラフィックは、他の Alibaba Cloud インターネット対応製品と集約され、CDT 側で課金されます。詳細については、「CDT の課金」をご参照ください。アウトバウンドインターネットトラフィックは、次の 3 つの部分で構成されます。

  1. 関数内のデータ転送トラフィック：関数がインターネットへのリクエストを開始したときに生成されるトラフィック。

  2. 関数のリクエスト/レスポンス トラフィック：関数がインターネット経由で呼び出され、レスポンスを返すときに生成されるトラフィック。

  3. CDN からの back-to-origin トラフィック：FC が CDN のオリジンサーバーとして機能し、CDN のオリジンフェッチが発生したときに生成されるトラフィック。

単価

CU 使用量は、月単位の階層制で課金され、リージョンごとに個別に計算されます。各リージョンの CU 使用量は個別に累積され、リージョン間で統合されることはありません。詳細については、「課金例」をご参照ください。

課金サイクル

FC は、1 時間ごとに課金します。関数ごとの 1 時間あたりの CU 使用量は切り上げられ、すべての関数で合計されて、1 時間あたりの合計 CU 使用量が算出されます。リソースプランをお持ちの場合、最初に CU 使用量が相殺されます。プランを使い切った後、従量課金が適用されます。

計算式

すべてのリソース使用量は、固定の変換係数を使用して CU 使用量に変換され、合計されて総 CU 使用量となります。

CU 使用量 = Σ (リソース使用量 × CU 変換係数)

リソース使用量

エラスティックインスタンスには、アクティブとアイドルの 2 つの状態があります。 インスタンスが処理するリクエストや実行中のバックグラウンドタスクがない場合、自動的にアイドル状態になります。 次の表では、各状態のシナリオについて説明します。

アクティブ状態とアイドル状態の判定しきい値

システムは、次の指標を使用して、インスタンスがアイドル状態に入ったかどうかを判断します。 すべての条件を同時に満たす必要があります。

• CPU 使用率 — インスタンスの vCPU 使用率が継続的に 0.01 vCPU コア (単一コアの 1% の使用率に相当) を下回ると、アイドル状態の CPU 条件が満たされます。

• GPU 使用率 — インスタンスの GPU ストリームプロセッサ、デコーダ、およびその他のコンポーネントがシステムのしきい値を下回ると、アイドル状態の GPU 条件が満たされます。 しきい値は GPU シリーズによって異なります。

• ネットワークトラフィック — インスタンスのインバウンドおよびアウトバウンドのネットワークトラフィックが継続的に 1,000 バイト/秒 を下回ると、ネットワークに関するアイドル条件が満たされます。

• リクエスト処理 — インスタンスは HTTP リクエストやバックグラウンドタスクを処理していません。

アクティブ時間とアイドル時間は、呼び出しログに直接表示されません。 コンソールの [ログ] ページの [呼び出しリクエスト] リストには、実行時間やメモリ使用量などのフィールドが表示されますが、インスタンスのアクティブ時間やアイドル時間は表示されません。 リクエストの実行時間を表示するには、関数設定でリクエストレベルのメトリクスを有効にしてから、 [ログ] ページの [呼び出しリクエスト] リストで実行時間を確認します。

リソース使用量 = エラスティックインスタンス (アクティブ) 使用量 + エラスティックインスタンス (アイドル) 使用量。 インスタンスがアイドル状態の場合、システムは自動的に一部のリソースをフリーズし、最小のキープアライブレートで課金します。

• vCPU リソース：課金されません。

• GPU リソース：GPU シリーズに応じて、アクティブ料金の 11.7% から 23% で課金されます。

  Ada.1シリーズ	Ada.2シリーズ	Ada.3シリーズ	Teslaシリーズ	Hopperシリーズ	Hopper.1シリーズ	Hopper.2シリーズ	Ampereシリーズ	Blackwell.1シリーズ	Xpu.1シリーズ
  11.7%	11.7%	11.7%	23%	13%	14%	14%	16%	13%	19%

最小インスタンス数を 1 以上に設定することは、レイテンシーの影響を受けやすいワークロード (セッションアフィニティ、永続的な接続など) やバックグラウンドタスクのシナリオに適しています。 これには次の利点があります。

• ウォームスタート：ミリ秒レベルのウォームスタートを実現し、サービスを中断することなく実行し続けます。

• 配信保証：エラスティックリソースをロックして、リソースの可用性を保証します。

• ビジー期間とアイドル期間のスマートな課金：リクエストやバックグラウンドタスクがない場合、自動的にアイドル課金に切り替わり、コストをさらに削減します。

MCP セッションアフィニティシナリオにおける呼び出しの課金

Function Compute (FC) に MCP Server をデプロイし、Streamable HTTP のセッションアフィニティを有効にすると、MCP プロトコルの initialize リクエストとその後の tools/call リクエストは別々の HTTP リクエストとなり、それぞれが個別の FC 関数呼び出しをトリガーします。 各呼び出しは、実際の CU 使用量に基づいて個別に課金されます。 その結果、1 回のツール呼び出し (initialize + tools/call) で 2 回の関数呼び出しが生成されます。 initialize リクエストは通常、コールドスタートをトリガーし、その後のリクエストは同じインスタンスを再利用しますが、それでも独立した呼び出しとして課金されます。

CU 変換係数

エラーステータスコードの課金

CU 使用量は、関数が返す HTTP ステータスコードではなく、リクエストが関数インスタンスに到達し、インスタンスが実行されるかどうかに基づいています。リクエストが関数インスタンスに到達し、関数が実行されると、その呼び出しは、関数が 200、404、401、またはその他の HTTP ステータスコードを返すかどうかに関係なく、実際の実行時間とリソース消費量に基づいて課金されます。

リクエストが関数インスタンスに到達する前にゲートウェイレイヤーで拒否された場合 (たとえば、HTTP トリガー が設定されていないために 404 が返された場合など)、関数インスタンスは実行されず、CU 使用量は発生しません。