Well-Architected Framework:コストの柱

トークンエコノミクス

Model Studio は、100万トークンあたりの単価でサービス料金を設定しています。主流のテキスト生成モデルでは、32K 未満の階層における qwen3-max の料金は入力が CNY 2.5、出力が CNY 10 です。128K 未満の階層における qwen-plus の料金は入力が CNY 0.8、出力が CNY 2 です (単位：100万トークンあたり CNY)。軽量階層とフラッグシップ階層の価格差は、数倍から 1 桁以上に及ぶ場合があります。そのため、モデルの選定は影響力の大きい意思決定となります。

料金には 2 つの特性があります。1 つ目は、出力のほうが入力より高いことです。主流のテキストモデルでは、出力と入力の価格比は通常 2.5 倍から 4 倍です。見積もりでは入力トークンと出力トークンを分ける必要があります。トークン数を単一の平均値で扱うと、出力トークンのコストの高さが見えにくくなります。2 つ目は、一部のモデルが段階的価格設定を採用していることです。単価は 1 回のリクエストに含まれる入力トークン総数に依存し、そのリクエスト内のすべてのトークンが同じ階層の単価で課金されます。qwen3-max の入力は、最大 32K トークンまでは CNY 2.5、32K から 128K は CNY 4、128K から 256K は CNY 7 です。つまり、コンテキスト長によるコストへの影響は、連続的でも線形でもありません。階層の境界を超えると、リクエスト全体の課金ベースラインが上がります。この仕組みは、アテンションの複雑さなどの理論的要因よりも、請求額に直接影響します。

カスタマーサービスの見積もり例：月あたり 100万件の会話を処理し、各会話で入力トークン 2,000、出力トークン 500 を消費するとします。qwen3-max の場合、入力コストは 1,000,000 × 2,000 ÷ 1,000,000 × 2.5 = CNY 5,000 です。出力コストは 1,000,000 × 500 ÷ 1,000,000 × 10 = CNY 5,000 です。合計は月あたり約 CNY 10,000 です。

計算コスト

企業が推論をセルフホストする、または自社でファインチューニングを行う場合、GPU の計算能力は最も高価なリソースです。Alibaba Cloud は、L20、A10、V100、T4 などの GPU タイプに対応する gn8is、gn7i、gn6v、gn6e、gn6i といった GPU コンピュートインスタンスファミリーを提供しています。大規模なトレーニングと高コンカレントな推論は、一般販売されている GPU Elastic Compute Service (ECS) インスタンスファミリーではなく、通常、Lingjun Intelligent Computing Service上で実行されるのが一般的です。メモリとスループットの要件を満たす範囲で、最小の選択肢を選んでください。リアルタイムの料金はECS コンソールと料金計算ツールで確認します。コストの目安として、Platform for AI-Elastic Algorithm Service (PAI-EAS)のパブリックリソースは vCPU コア/時あたり CNY 0.194、メモリは GB/時あたり CNY 0.024 で課金されます。

ファインチューニングのコストは、概ねモデルサイズに対して線形です。パラメーター数が 1 桁異なる 2 つのモデル階層では、必要な GPU 時間と並列 GPU 数も通常は同程度のオーダーで異なります。ファインチューニングを開始する前に、十分なチューニングを行ったうえで、より小さい階層で目標を満たせるかを検証してください。推論の計算量は、おおむね次のように見積もれます：密なモデルでは、生成トークンあたりのフォワード計算量はパラメーター数のおよそ 2 倍です。つまり、70億パラメーターのモデルはトークンあたり約 14 GFLOPs、720億パラメーターのモデルはトークンあたり約 144 GFLOPs です。これはリクエスト単位ではなく、トークン単位のスケールです。単一のリクエストでは、この値に出力長を掛け、さらに入力側の prefill オーバーヘッドを加算します。

セルフホストの推論クラスターでは、GPU 使用率が低いことが一般的です。主な要因として、トラフィック分布の偏り、コールドスタート時の待機、非効率なバッチ処理、チームごとに個別のスタックをデプロイすることによる断片化が挙げられます。監視データを使用して使用率を評価し、リソースをプールすることによる効果を定量化してください。

ストレージコスト

text-embedding-v4 を例にします。デフォルトの出力は 1,024 次元です。各ベクトルを 4 バイト浮動小数点として保存する場合、1 つのベクトルは 4,096 バイト (約 4 KB) を使用します。メタデータとインデックスのオーバーヘッドを含めると、各テキストチャンクは通常約 5 KB から 6 KB を消費します。1,000万のテキストチャンクでは、生のベクトルだけで約 40 GB のストレージが必要なです。HNSW グラフのインデックスを追加すると、合計は通常さらに 10% から 30% 増加します。このモデルは 2,048 から 64 次元まで複数の出力サイズをサポートします。次元数を減らすと、ストレージと取得コストが直接削減されます。1,024 から 512 に減らすとストレージは半減します。これは見落とされがちなコストレバーです。

モデルファイルも重要です。FP16 で保存した 70億パラメーターのモデルは約 14 GB です。720億パラメーターのモデルは約 144 GB です。A/B テストやロールバックのために複数のファインチューニング済みのバージョンを保持すると、コストは急増します。トレーニングセット、評価セット、および中間のチェックポイントもコスト増の大きな要因となります。

隠れたコスト

評価のコンピューティングコスト。モデルを変更するたびに、数百から数千のテストケースを再実行する必要があります。評価セットが 1,000 サンプルで、各サンプルが入力トークン 800、出力トークン 200 を使用する場合、qwen-plus による 1 回のフル評価は約 CNY 1 です。反復が速い場合、1 チームが 1 日に 10 回以上実行することもあります。複数モデルの比較やリグレッションチェックを加えると、月間の合計コストは無視できない規模になります。評価はレイテンシー要件が厳しくないため、単価の低いバッチ推論で実行してください。

chain-of-thought 出力によるコスト増幅。推論モデルでは、chain-of-thought は出力トークンとして課金されます。モデルが思考プロセスを出力すると、すべての出力トークンが thinking-mode の出力単価で課金されます。Alibaba Cloud の公式例では、1 回の呼び出しで約 360 の出力トークンが生成され、そのうち 286 が thinking トークンで、80%近くを占めます。単純なタスクでデフォルトで deep thinking を有効化すると、出力コストが何倍にも増える可能性があります。これは現在、最も管理が難しくなりがちな隠れたコストです。thinking モードはタスクの種類ごとにのみ有効化し、思考プロセスの長さに上限を設定してください。

失敗した実験によるサンクコスト。ファインチューニング実験の相当数は本番環境に導入されませんが、計算能力を消費します。実験による損失を、予算の明示的な項目として計上してください。過剰にプロビジョニングされた開発環境も一般的です。チームはデバッグのために本番と同じコンピュート階層を要求しがちですが、使用率は低いままです。スケールトゥゼロが可能な弾性リソースを優先してください。さらに、Model Studioは、有効化後の一定期間、多くのモデルに対して無料の呼び出しクォータを提供しており、POC の試行錯誤コストの削減に役立ちます。

エネルギー使用量とグリーンコンピューティング

大規模言語モデル (LLM)ワークロードのカーボンフットプリントは、現在、ESG レポーティングのトピックとなっています。トレーニングのエネルギー使用量は、パラメーター数、データ量、期間と相関します。呼び出しあたりの推論エネルギーは小さいものの、スケールすると蓄積します。排出量を定量化する必要がある場合は、一般化された類推ではなく、実際の計算能力時間と、リージョンの電力系統の排出係数に基づいて見積もってください。グリーンコンピューティングのコア原則は、モデルを適正なサイズにすることです。70億パラメーターのモデルで要件を満たせるなら、720億パラメーターのモデルを使用すると、計算能力の消費量はおおむね 1 桁増え、排出量も同程度に増加します。

BP-COST-01：タスクの複雑さに合わせたモデルティアの選択

ベストプラクティス：タスクとモデルのマッピングマトリクスを構築します。認知的な複雑さに基づいて、最も費用対効果の高いティアを選択します。すべてのシナリオで最大のモデルを使用することは避けてください。

キーポイント：タスクを 4 つの複雑さレベルに分割します。レベル 1 は、構造化タスク (分類、エンティティ抽出、フォーマット変換、キーワード抽出) を対象とします。ロジックは単純でパターンは安定しているため、軽量ティア (Qwen Flash シリーズなど) または特化された小規模モデルを使用します。レベル 2 は、標準的な会話タスク (簡単な Q&A、情報検索、テンプレート化された返信) を対象とし、Qwen Plus ティアに適しています。レベル 3 は、複雑な推論タスク (複数ステップの推論、創造的な生成、複雑な要約、ドキュメント横断の統合) を対象とし、Qwen Max ティアが必要です。レベル 4 は、専門的なタスク (コード生成、数学的証明、専門分野の分析) を対象とし、ドメインにファインチューニングされたモデルまたは最大の汎用ティアが必要になる場合があります。マトリクスには、バージョン番号をハードコーディングする代わりに、モデルファミリーと能力レベルを記録し、新しいバージョンがリリースされたときに再テストします。アンチパターン：POC で最強のモデルを使用して品質を最大化し、スケール時にダウングレードの 評価 をスキップします。

Alibaba Cloud での実装：AI Gateway を使用して、複数ティアのモデル呼び出しと API 認証情報を一元管理します。シナリオベースのモデル選択ポリシーを設定し、モデルの 評価 機能を使用して、下位ティアが品質基準を満たしていることを確認します。

BP-COST-02：モデルルーティングによるコストと品質のバランス調整

ベストプラクティス：リクエスト分類器をデプロイして、各 推論 リクエストをスコアリングし、最も費用対効果の高いモデル インスタンス にルーティングします。

キーポイント：アーキテクチャは 3 つのコンポーネントで構成されます。リアルタイムで入力を評価し、複雑さスコアを出力するリクエスト分類器、スコアとしきい値に基づいて適切なエンドポイントにディスパッチするルーティング決定エンジン、そして品質メトリクスを継続的に収集し、しきい値を調整する品質監視モジュールです。節約額は直接測定できます。6.1.1 のカスタマーサービスの例では、すべてのリクエストで qwen3-max を呼び出すベースラインのコストは月額約 CNY 10,000 です。リクエストの 70% を qwen-plus にルーティングし、30% を qwen3-max に維持する場合、合計入力コストは CNY 2,620 (qwen3-max が CNY 1,500、qwen-plus が CNY 1,120)、合計出力コストは CNY 2,200 (qwen3-max が CNY 1,500、qwen-plus が CNY 700) となり、合計は約 CNY 4,820/月で、約 52% の節約になります。節約額は、ダウンルーティング率とティア間の価格比に依存します。モデルのペアについては、実際の単価を使用し、経験則に基づく乗数に頼らないでください。軽量な分類器 (小規模な事前学習済みエンコーダーまたはロジスティック回帰) をトレーニングできます。その 推論 レイテンシーは数ミリ秒以内に収まります。また、入力長、インテントタイプ、構造化出力が必要かどうかに基づくヒューリスティックスも使用できます。これには トレーニング は不要ですが、精度は低くなります。アンチパターン：品質監視なしでルーティングを開始します。誤分類によって複雑なリクエストがより性能の低いモデルに送られ、品質の低下はユーザーからの苦情の後に初めて発覚することがよくあります。

Alibaba Cloud での実装：Model Studio でティアードモデルのエンドポイントを管理します。Function Compute (FC) 3.0 に軽量な分類器をルーティングのプレゲートウェイとしてデプロイします。AI Gateway をリクエストのディスパッチと 負荷分散 に使用します。

BP-COST-03：蒸留と量子化によるコスト削減

ベストプラクティス：社内向け、または顧客向けではなく、かつクリティカルでもない AI 機能には、知識蒸留 と モデルの量子化 を使用して 推論 リソースの使用量を削減します。デプロイコストを削減しつつ、品質の低下を許容範囲内に抑えます。

キーポイント：知識蒸留 は、大規模な教師モデルからの出力を トレーニング シグナルとして使用し、より小さな学生モデルをトレーニングします。ハードラベルだけでなく、教師の確率分布を学習することで、学生は教師の能力の一部を継承します。典型的なパターンは、大規模なティアの教師を使用し、特定のタスクで教師の品質のほとんどを維持しながら、パラメーター数が 1 桁少ない学生を蒸留することです。モデルの量子化 は、重みを高精度の浮動小数点数 (FP16/FP32) から低精度の整数に圧縮します。INT8 は通常、モデルサイズと 推論 のメモリ使用量を半分にします。INT4 は約 4 倍の圧縮を達成できますが、ビット幅が減少するにつれて品質の低下が大きくなります。これらの手法は、社内ツールや運用バックエンド、顧客向けでないデータパイプライン (バッチ分類、ラベル生成)、および開発/テスト用のモデルサービスに使用します。中核となるユーザー向けエクスペリエンスパスでのアグレッシブな量子化は避けてください。アンチパターン：ビジネス用の 評価 セットでテストせずに、量子化されたモデルを出荷します。精度の低下に対する感度はタスクによって大きく異なり、一般的なベンチマークがビジネス上の検証の代わりになることはありません。

Alibaba Cloud での実装：PAI-Model Gallery のモデル圧縮機能を使用して、量子化を実行します。これは Weight-only Quantization テクノロジーに基づいており、MinMax-8Bit および MinMax-4Bit 戦略を提供します。量子化をデプロイ前の個別のジョブとして実行し、圧縮されたアーティファクトを PAI-EAS を介してオンラインサービスとしてデプロイします。PAI-EAS は、BladeLLM や vLLM などの 推論エンジン をサポートしており、スループットをさらに向上させます。

BP-COST-04：推論用のGPUプールの共有

ベストプラクティス：別々のチームによるデプロイで作成された リソースサイロ を統合します。統一された GPU 推論 リソースプールを構築します。複数モデルの共有とインテリジェントなスケジューリングを使用して、使用率を向上させます。

キーポイント：典型的なアンチパターンは、5 つのチームがそれぞれ 2-GPU の 推論 サービスをデプロイし、合計 10 個の GPU を使用しますが、ピーク時間が異なるケースです。平均使用率は約 30% にとどまります。プーリングの利点を有効負荷で測定します。30% の使用率での 10 個の GPU は、全負荷での約 3 個の GPU に相当します。プーリング後、4 個の GPU を設定してピークの重複に対応し、平均使用率を約 75% に引き上げることができます。元の 10 個の GPU と比較して、これは約 60% の投資節約になります。実際の削減量は、ピークがどのように重複するかに依存します。比率をコピーするのではなく、過去のトラフィック曲線に基づいてこれをモデル化してください。Kubernetes の GPU 共有スケジューリングでソリューションを実装してください。GPU ごとに複数のコンテナをサポートするために GPU 共有および分離コンポーネントをデプロイし、複数モデルのエンドポイントルーティングのために統一されたモデルサービスゲートウェイをデプロイし、キューの深さと GPU 使用率に基づいて水平スケーリングを設定してください。GPU が少ないことは、エネルギー使用量と排出量の削減にもつながります。アンチパターン：重複するピークではなく、平均使用率に基づいて GPU 数を積極的に削減します。複数のサービスが同時に急増すると、パフォーマンスが全体的に低下します。

Alibaba Cloud での実装：Container Service for Kubernetes (ACK) の Shared GPU Scheduling を使用して、1 つの GPU を複数のサービスで共有します。cGPU コンポーネントは、メモリとコンピューティングの両方を分離します。共有 GPU スケジューリングと、分散 トレーニング を高速化するためのトポロジー対応スケジューリングは、別々の機能であることに注意してください。PAI 側では、PAI-EAS の 専用リソースグループ と GPU スライシング を使用して統一された 推論 プールを構築し、Virtual Resource Group を使用して混合リソースのスケジューリングと優先度管理を行います。

BP-COST-05 プロンプトと出力予算の設計

ベストプラクティス：プロンプト と出力長を、測定可能なコスト要因として扱ってください。体系的なトリミング、構造化出力の制約、思考予算の制御を用いて、品質を損なわずにリクエストあたりのトークン使用量を最小化してください。

要点：システム プロンプト は、すべてのリクエストに含まれる固定のオーバーヘッドです。冗長な説明や繰り返しの指示を削除してください。長い自然言語の文は、簡潔で構造化された形式に置き換えてください。低頻度のルールは条件分岐に移してください。

重要：システム プロンプト のトリミング効果は、コンテキストキャッシュと合わせて評価してください。Model Studio は、対応モデルに対してデフォルトで暗黙的キャッシュを有効化します。キャッシュされた入力プレフィックスは、入力単価の一定割合で課金されます (BP-COST-06 を参照)。システム プロンプト はプレフィックスの先頭にあり、最もキャッシュしやすい部分です。キャッシュヒットが安定している場合、システム プロンプト をトリミングして節約できるコストは、フル単価で節約できる金額のごく一部にとどまります。順序が重要です。まず長く安定したプレフィックスでキャッシュヒットを確保し、その後、キャッシュ対象外の部分をトリミングします。逆の順序で進めると、削減効果を過大に見積もる原因になります。

出力側の最適化は、出力が入力より数倍高価で、かつ入力キャッシュの影響を受けないため、より大きな削減につながることがよくあります。冗長な説明を避けるため、構造化出力 (JSON、リスト) を必須にしてください。推論モデルでは、タスク種別に応じて思考モードを制御してください。単純なタスクではディープシンキングを無効化してください。やむを得ず有効化する場合は、思考予算パラメーターを使用して Chain-of-Thought の長さに上限を設定してください。思考トークンが出力の大半を占めることがあるため、これは出力側で最も効果の高い単一の制御です。ほかにも、長文ドキュメントをモデルに送る前に要約する、スライディングウィンドウでチャット履歴を圧縮する、シナリオ別のコンパクトなテンプレートライブラリを維持する、といった戦略があります。これらは 段階的価格設定 の境界を超えるのを避けるのにも役立ちます。アンチパターン：キャッシュヒットを検証せずに、削減したトークン数にフル単価を掛けて削減効果を報告します。これにより、削減効果を大幅に過大評価する可能性があります。計算は、使用状況レポートの課金対象トークンに基づいて行ってください。

Alibaba Cloud の実装：Model Studio の Prompt Management を使用して、バージョン管理されたテンプレートライブラリを構築してください。ディープシンキングのパラメーターを使用して Chain-of-Thought の支出を制御してください。Model Usage レポートを使用して、ワークスペース、API キー、モデル別に、各テンプレートの課金状況を監視してください。

BP-COST-06 コンテキストキャッシュとセマンティックキャッシュによる再利用

ベストプラクティス：2 層キャッシュシステムを構築してください。プラットフォームネイティブのコンテキストキャッシュでリクエストプレフィックスの計算を再利用し、アプリケーション層の セマンティックキャッシュ をデプロイして、意味的に等価な繰り返しリクエストをインターセプトしてください。

要点：2 つのキャッシュは動作が異なり、見込める削減幅も異なります。最大の効果を得るには、組み合わせて使用してください。

レイヤー 1 はプラットフォームのコンテキストキャッシュです。共有リクエストプレフィックスを再利用し、入力側のコストを削減します。暗黙的キャッシュは対応モデルでデフォルトで有効になっており、変更は不要です。キャッシュされた部分は、入力単価の一部で課金されます (多くのモデルでは 20%、一部のモデルではさらに低い割合です)。明示的キャッシュでは、リクエスト内でキャッシュ対象コンテンツをマークする必要があります。キャッシュヒット時の課金率はより低く (通常は入力単価の 10%) なりますが、キャッシュ作成は入力単価の 125% で課金され、TTL と巻き戻し範囲に制限があります。コンテキストキャッシュはプレフィックスベースです。システム プロンプト やナレッジスニペットなどの安定したコンテンツはメッセージシーケンスの先頭に配置し、ツール定義はリクエスト間で完全に同一の構造でシリアライズされた状態を維持してください。コストとレイテンシーの予測可能性が求められるクリティカルパスでは、明示的キャッシュを使用してください。ほとんどのユースケースでは、暗黙的キャッシュで十分です。

レイヤー 2 はアプリケーション層の セマンティックキャッシュ です。過去の結果を直接返し、呼び出し全体の入力および出力コストを回避できるため、より大きな削減余地があります。自然言語では、同じ意図でも表現が多様なため、完全一致キャッシュのヒット率は低くなります。セマンティックキャッシュ はリクエストテキストをベクトルにエンコードし、類似度でマッチングします (コサイン類似度のしきい値は 0.95 以上に設定されることが一般的です)。無効化戦略は 3 つの次元をカバーする必要があります。時間：古い回答を防ぐための TTL と、市況や天気など時間依存データに対する短い TTL。ナレッジ更新：基盤となるナレッジベースが変更された際に、関連エントリを能動的にクリアすること。品質フィードバック：ユーザーのネガティブシグナルに基づき、低品質エントリを削除すること。ヒット率はシナリオによって大きく異なります。FAQ クエリは最も集中しており、ヒット率が最も高くなります。一般的なカスタマーサービスは中間です。自由度の高いクリエイティブライティングは固有の出力が必要なため適しません。リリース前に、過去のリクエストログを使用してヒット率をオフラインで評価してください。アーキテクチャとしては、モデルサービスの前段にインターセプターとしてキャッシュを配置してください。リクエストベクトルをキー、出力とメタデータ (タイムスタンプ、モデルバージョン、信頼度) を値として保存してください。ヒット率とユーザー満足度を継続的に監視してください。アンチパターン：出力の多様性が必要なシナリオ、またはユーザー固有のプライベートコンテキストを含むシナリオで セマンティックキャッシュ を使用します。無関係な回答や、ユーザー間のデータ漏えいにつながる可能性があります。キャッシュキーにはテナントと権限の次元を含めてください。

Alibaba Cloud の実装：コンテキストキャッシュは Model Studio にネイティブで提供されています。暗黙的キャッシュは変更なしで動作します。明示的キャッシュはリクエストパラメーターで有効化してください。アプリケーション層の セマンティックキャッシュ には、(Redis 互換の) Tair の TairVector ベクトルデータ構造を使用してください。HNSW インデックス とキー単位の TTL をサポートします。リクエストのベクトル化には、Model Studio のテキスト埋め込みモデルを組み合わせてください。

BP-COST-07 バッチ推論と非同期推論の活用

ベストプラクティス：リアルタイムではないシナリオでは、バッチ推論 と 非同期推論 を使用してください。プラットフォームの バッチ推論 割引を優先し、オフピークのスケジューリングと スポットインスタンス オプションを組み合わせて、さらにコストを削減してください。

要点：多くの 推論 ワークロードでは、リアルタイム応答は不要です。代表的なシナリオには、ドキュメントのバッチ処理 (契約書分析、履歴書スクリーニング、コンテンツモデレーション)、オフラインデータパイプライン (ログ分析、プロファイル更新)、定期レポート生成、モデル 評価 とデータラベリングがあります。Model Studio の API 呼び出しでは、バッチ推論 が最も直接的な削減につながります。一連のリクエストを JSONL ファイルとして送信し、非同期に処理します。課金はリアルタイム料金の 50% です。最大待機時間は 1 日から 14 日まで設定できます。期限までにジョブが完了しない場合は終了され、正常に実行されたリクエストのみが課金対象になります。評価、ラベリング、ドキュメントのバッチ処理をこの API に移行すれば、モデルや プロンプト を変更せずに、これらのタスクのコストを半減できます。なお、ディープシンキングを有効化している場合でも、Chain-of-Thought トークンは出力単価で課金されます。

セルフホストの 推論 では、効果は 3 つの領域から得られます。スポットインスタンス の料金は 従量課金 より大幅に安く、中断される可能性はあるものの、バッチジョブは通常チェックポイントと再開に対応します。次に、緊急性の低いジョブを需要が低いオフピーク時間帯にスケジューリングし、リソースの可用性を高めます。さらに、バッチ処理で多数の小さなリクエストを 1 つのバッチに統合し、GPU スループットを高め、通信とスケジューリングのオーバーヘッドを削減します。非同期設計のコアはシンプルです。フロントエンドがリクエストを メッセージキュー に送信し、推論 ワーカーがキューからリクエストを取得して処理します。完了後は、コールバックで通知するか、結果を ストレージ に書き込み、下流のプロセスでプルされます。この設計は、トラフィックの平滑化、リトライと耐障害性、水平スケーリング をサポートします。アンチパターン：割引を得る目的だけで、エンドユーザーの対話パスを バッチ推論 に変換します。待機ウィンドウは日単位であり、レイテンシーの影響を受けないワークロードにのみ適します。

Alibaba Cloud の実装：オフラインタスクには Model Studio の バッチ推論 API を呼び出すと、割引料金が適用されます。セルフホストの 推論 では、PAI-EAS の LLM バッチ推論 機能を使用してください (LLM インテリジェントルーティングにより OpenAI 互換の Batch API を提供します)。音声・動画処理など、AIGC と長時間実行の準リアルタイムシナリオでは、PAI-EAS の非同期推論サービスとキューサービスを使用してください。Function Compute (FC) 3.0 は、非同期呼び出しと遅延呼び出しをサポートします。非同期結果は、疎結合レイヤーとして Message Service、EventBridge、または ApsaraMQ for RocketMQ に配信できます。

BP-COST-08 コミットメントによるコスト予測可能性の向上

ベストプラクティス：過去の使用量と成長予測に基づき、Savings Plans または リソースプラン により割引を確保してください。使用量の監視とキャパシティプランニングを確立し、コミットメントが実際の消費量と整合するようにしてください。

要点：Model Studio は、大規模言語モデル (LLM) の 従量課金 利用向けに設計された割引オプションとして、AI 汎用の Savings Plans を提供します。契約期間 (3、6、12、24 か月) に対して、月間の支出額をコミットします。従量課金 の柔軟性を維持しながら、段階的な割引を受けられるため、モデル利用コストを削減できます。

Model Studio は、AI コーディングおよびエージェントツール向けに Token Plan サブスクリプションも提供しています。これは、一定期間の固定枠を持つクレジットを使用し、枠を使い切ると呼び出しが停止されます。開発者ツール向けであり、企業の API 利用におけるコスト最適化モデルとは異なります。選択時にこれらのオプションを混同しないでください。

Alibaba Cloud の実装：Model Studio コンソール で Savings Plans または リソースプラン を購入してください。Model Usage レポートを使用して、ワークスペース、API キー、モデル別に、支出の進捗と残りクォータを監視してください。Billing Management の Budget Management を使用して、しきい値アラート (実績値または予測値に基づく) を設定してください。

BP-COST-09 オートスケーリングを活用した従量課金

ベストプラクティス： 推論 トラフィックのパターンに基づき、多層的なエラスティシティを構成します。SLO を満たしつつ、アイドルキャパシティを最小化してください。開発環境では、トラフィックがない場合に スケールトゥゼロ して、未使用リソースへの支出をなくします。

要点：AI 推論 のトラフィックは、周期的かつバースト的になることがよくあります。固定サイジングでは、ピークに合わせて過剰プロビジョニングして大半の時間がアイドルになるか、平均に合わせてピーク時に性能が劣化するかのどちらかになりがちです。エラスティシティは 3 層で適用します。第 1 に スケールトゥゼロ：開発／テストや低頻度サービスでは、一定期間リクエストがない場合にレプリカ数を 0 までスケールダウンします。トレードオフは コールドスタート です。最初のリクエストは数十秒から数分かかる場合があります。事前ウォームアップで軽減してください。第 2 に予測スケーリング：過去のパターンに基づいて負荷を予測し、ピーク前にスケールアウトします。リアクティブスケーリングの遅延を回避するため、定常的なトラフィックがある本番サービスで使用します。第 3 に クールダウン期間 を伴うリアクティブスケーリング：リアルタイムメトリクス (GPU 使用率、キュー深度、応答レイテンシー) に基づいてスケーリングをトリガーし、スラッシングを避けるために適切な クールダウン期間 を設定します。アンチパターン：顧客向けのリアルタイムパスで スケールトゥゼロ を有効化することです。トラフィックが戻ると、初期リクエストで コールドスタート レイテンシーが発生します。顧客向けサービスでは、常時稼働の最小レプリカを維持してください。

Alibaba Cloud の実装： PAI-EAS は水平 オートスケーリング とスケジュール オートスケーリング を提供します。最小 インスタンス 数を 0 に設定して スケールトゥゼロ できます (専用ゲートウェイを持つサービスではサポートされません)。トリガーメトリクスには、QPS、CPU、GPU 使用率、キューのバックログ (非同期サービスの場合)、カスタムメトリクスが含まれます。Function Compute (FC) はリクエスト単位で課金され、自動的にスケールします。GPU インスタンス は準リアルタイムの 推論 を処理でき、予約コストを削減するための浅いスリープ インスタンス も提供します。ACK と ACK Serverless では Advanced Horizontal Pod Autoscaler (AHPA) をデプロイできます。AHPA は過去の Prometheus メトリクスを使用して予測スケーリングを行います。履歴は少なくとも 7 日分保持してください。

BP-COST-10 トレーニングデータライフサイクルの管理

ベストプラクティス：アクセス頻度とビジネス価値に基づき、 トレーニング 関連データをホット、ウォーム、コールド、削除の 4 つの階層に分類します。ストレージ階層化 とクリーンアップを自動化してください。コンプライアンス要件を満たしつつ、 ストレージ コストを最小化します。

要点：ホット階層には、アクティブなファインチューニングの トレーニング セット、アクティブな 評価 ベンチマーク、進行中の トレーニング チェックポイント が含まれます。この階層では高スループットかつ低レイテンシーのアクセスが必要なため、パフォーマンスまたはアドバンスト NAS、Extreme NAS、またはローカル SSD を使用します。大規模なインテリジェントコンピューティングの トレーニング では、 Cloud Paralleled File System (CPFS) を使用します。ウォーム階層には、最近完了した実験データ、過去の 評価 結果、オンラインモデルの元の トレーニング データ (再現性と監査のため) が含まれます。Object Storage Service (OSS) の標準 ストレージ を使用します。コールド階層には、長期間使用されていない履歴データ、退役したモデルの チェックポイント、およびコンプライアンスまたは再現性のために保持が必要な初期の実験データセットが含まれます。OSS の低頻度アクセス、アーカイブ、コールドアーカイブ、またはディープコールドアーカイブ ストレージ を使用します。削除階層には、保持ポリシーに基づき恒久的に削除する必要があるデータが含まれます。例えば、保持期間を超えた個人データ ( 個人情報保護法 (PIPL) への準拠)、再利用価値のない失敗実験の中間アーティファクト、新バージョンで完全に置き換えられた旧データセットなどです。

コールド ストレージ タイプを選定する際は、見積もりに隠れたコストを含めてください。ストレージ 単価だけを比較すると、総支出を過小評価することになります。中国本土における 従量課金 のローカル冗長 ストレージ を参考にすると、標準 ストレージ は GB 月あたり約 CNY0.12、低頻度アクセスは約 CNY0.08 (標準の約 3 分の 2)、アーカイブは約 CNY0.033、コールドアーカイブは約 CNY0.015、ディープコールドアーカイブは約 CNY0.0075 です。最小 ストレージ 保持期間 (低頻度アクセスは 30 日、アーカイブは 60 日、コールドアーカイブとディープコールドアーカイブは 180 日) も考慮してください。早期削除では差額の支払いが必要です。データ取得には取得料金が発生します。コールドアーカイブとディープコールドアーカイブは、読み取り前に解凍が必要です。ウォーム／コールドデータであっても、時折読み取る場合は低頻度アクセスを使用してください。長期間アクセスしないと確信できる一方で保持が必要なデータにのみ、アーカイブまたはそれより低コストのクラスを使用します。アンチパターン：単価だけを根拠に、近い将来に必要なデータをアーカイブまたはコールドアーカイブへ移行することです。取得料金と最小期間の料金により、総コストが増加する可能性があります。

Alibaba Cloud の実装： OSS の Lifecycle Rules を使用して、 ストレージ クラスの移行と期限切れ削除を自動化します。ルールはプレフィックスまたはタグによるマッチングをサポートします。低頻度アクセス、アーカイブ、コールドアーカイブ、ディープコールドアーカイブへ移行できます。期限切れオブジェクト、不完全なマルチパートアップロード、履歴バージョン、削除マーカーも削除できます。データレイク シナリオでは、 Data Lake Formation (DLF) を使用してメタデータとアクセスポリシーを一元管理し、 DataWorks と組み合わせてデータ品質とライフサイクルのプロセスを実装します。

BP-COST-11 ベクトルストレージのデータ階層化

ベストプラクティス：クエリ頻度に基づいて データ階層化 を実装してください。パフォーマンスのためにホットなベクトルはメモリインデックスに保持し、低頻度のベクトルはディスクインデックスまたは圧縮 ストレージ に移行してください。また、エンベディング次元を下げて全体規模を縮小してください。

要点： ベクトルデータベース のコストには、 ストレージ コストとコンピュートコスト ( インデックス 作成とクエリ) が含まれます。インメモリインデックス (HNSW など) は最良のクエリレイテンシーを提供しますが、メモリはディスクよりはるかに高価です。数千万から数億のベクトルを持つナレッジベースでは、全インメモリの インデックス は維持できません。階層化の前に、まずベクトルそのものを縮小してください。text-embedding-v4 は 2,048 から 64 次元までの出力をサポートします。次元削減は、 ストレージ と取得コストを比例して削減します。ビジネス用の検索 評価 セットで次元ごとの再現率品質を検証し、品質しきい値を満たす最小の次元を選択してください。この手順は、後続の階層化作業よりも大きな削減につながることがよくあります。階層化戦略では、頻繁に参照されるナレッジチャンクとコア業務ナレッジ (製品マニュアル、ポリシードキュメント) をホット階層としてインメモリ インデックス に保持します。ウォーム階層にはディスク インデックス を使用し、低頻度であるものの必要な履歴エンベディングを格納します。レイテンシーは増加しますが、単価は大幅に低下します。コールド階層は圧縮形式でオフラインアーカイブします。必要時にオンデマンドでロードしてください。アクセスレイテンシーは秒単位になりますが、 ストレージ コストは最小になります。取得ゲートウェイ層で各ベクトル ID のアクセス頻度を記録して追跡し、スケジュールに基づいて移行します。アンチパターン： ストレージ エンジンが自動的に階層化を処理すると想定することです。現時点では、ほとんどのベクトルストアは頻度ベースの自動階層化を提供していません。アプリケーション層で、ヒート統計と移行オーケストレーションを実装する必要があります。

Alibaba Cloud の実装： DashVector は、サーバーレス オートスケーリング を備えたフルマネージドのベクトル検索サービスを提供します。AnalyticDB for PostgreSQL はベクトル分析を提供し、製品レベルで データ階層化 をサポートしますが、階層化には ストレージ 移行関数の明示的な呼び出しが必要です (パーティション単位でスケジュールジョブを実行できます)。アクセスヒートに基づく自動移行は行いません。ホットテーブルをコールドテーブルに移行すると、主キー、インデックス、シーケンスが削除される点に注意してください。移行設計には インデックス作成 戦略を含めてください。Alibaba Cloud Elasticsearch では、 インデックスライフサイクル管理 (ILM) によりホット／コールド分離を行うか、OpenStore エンジンによるストレージとコンピュートの分離を使用して、検索可能な状態を保ちながら大規模な履歴データを低コストで格納できます。

5 層ガバナンスアーキテクチャの活用

レイヤー 1：コールレイヤーでの使用量ガバナンス。これは最も直接的な削減につながり、インフラストラクチャの変更も不要です。タスクの複雑さに応じた モデルルーティング を使用し、コンテキストキャッシュで安定したプレフィックスを再利用します。評価 とドキュメントのバッチ処理は バッチ推論 に移行して 50% の割引を適用します。タスクごとに思考モードを制御し、思考予算を設定します。また、コンテキスト長に上限を設けて 段階的価格設定 のしきい値を超えないようにします。

レイヤー 2：コミットメントによる割引。使用量のベースラインが安定したら、Savings Plans または リソースプラン を使用して割引を確保します。確約利用には安定したベースラインのみを含め、変動部分は 従量課金 のままにしてください。未使用のクォータはサイクルごとにリセットされるためです。中核となる価値は、不確実な消費支出を、予算化可能な計画支出へ変換することです。

レイヤー 3：エラスティックコンピュートと スポットインスタンス の活用。セルフホストのオンライン 推論 では、3 層のエラスティシティ戦略を構成します。オフラインのバッチジョブでは、スポット GPU インスタンス を優先します。

レイヤー 4：GPU プーリング。Container Service for Kubernetes (ACK) の共有 GPU スケジューリングと cGPU 分離を使用して 1 つの GPU 上で複数サービスを実行するか、PAI-EAS の 専用リソースグループ で GPU スライシング を使用します。vLLM または BladeLLM と組み合わせて、GPU あたりのスループットを向上させます。

レイヤー 5：ストレージ階層化、可観測性、ガバナンス。Object Storage Service (OSS) の Lifecycle Rules を使用して、ストレージクラスの移行と期限切れ削除を自動化します。ベクトル次元を削減し、ベクトルデータに対してホット／ウォーム／コールドの階層化を実装します。モデル側の使用量は Model Studio の Model Usage と Application Monitoring で把握し、コスト分析、コスト配分、予算アラートには Billing Management の Cost Management を使用します。コスト異常検出 を有効化し、異常な増加とアイドルリソースを検知します。

典型的な中堅企業におけるコスト見積もり

月間 100 万コールの中堅企業をベースラインシナリオとして想定します。主に Model Studio API を呼び出し、推論 クラスターをセルフホストしないものとします。前提：アプリケーションは 3 つ (インテリジェントカスタマーサービス、ドキュメント処理、社内ナレッジベース Q&A) で、コール数の配分は 60%、25%、15% です。各コールでは、平均して入力 2,000 トークン、出力 500 トークンを使用します。未最適化のベースラインでは、すべてのコールで qwen3-max (32K 未満の階層) を使用します。

ベースラインコスト：モデル 推論 の入力が CNY 5,000、出力が CNY 5,000、合計で月あたり約 CNY 10,000 です。ベクトル検索は月あたり約 CNY 4,000 です。OSS は月あたり約 CNY 300 です。評価 と実験用コンピュートは月あたり約 CNY 1,500 です。ベースライン合計は月あたり約 CNY 15,800 で、このうちモデル 推論 が約 63% を占め、最大のコスト項目になります。

推論 コストは次の順序で最適化します。ステップ 1：モデルルーティング。リクエストの 70% を qwen-plus にルーティングし、30% は qwen3-max のままにします。入力は CNY 2,620、出力は CNY 2,200、小計は約 CNY 4,820 です。ステップ 2：コンテキストキャッシュ。入力の約 60% が安定したプレフィックスで、そのプレフィックスの約 80% が暗黙的キャッシュにヒットし、キャッシュ部分は入力単価の 20% で課金されると仮定します。実効的な入力課金係数は約 0.62 となり、入力は約 CNY 1,614、小計は約 CNY 3,814 に低下します。ステップ 3：バッチ推論。ドキュメント処理 (約 25%) を 50% 割引の バッチ推論 に移行し、小計は約 CNY 3,337 に低下します。ステップ 4：確約利用。安定したベースラインに Savings Plans を適用します。保守的に 10% の割引を見込むと、推論 コストは月あたり約 CNY 3,000 まで低下し、ベースラインから約 70% の削減になります。実際の割引率は、確約利用の階層に基づいて コンソール で確認してください。

その他のコスト項目：次元削減と階層化によりベクトル検索を月あたり約 CNY 2,000 に削減します。ライフサイクルルールにより OSS を月あたり約 CNY 150 に削減します。バッチ推論 により 評価 のコンピュートを月あたり約 CNY 750 に削減します。最適化後の合計は月あたり約 CNY 5,900 で、総削減率は約 63% です。

これらの数値は、あくまで見積もりのフレームワークです。実際のコストは、ユースケース、トラフィックパターン、品質目標、技術選択によって大きく変動します。推論 クラスターをセルフホストする場合は、常時稼働の GPU コストが支配的になり、コスト構造と最適化の焦点も変わります。このフレームワークの価値は、コスト分析、会計範囲、最適化の順序を定義する点にあります。

コストガバナンスのための組織的メカニズムの確立

コスト最適化は技術課題だけではありません。組織ガバナンスの課題でもあります。4 つのメカニズムを確立してください。アーキテクト、財務、ビジネスのステークホルダーが定期的に支出トレンドと最適化機会をレビューする仮想 AI FinOps チームを編成します。コスト配分 を実装し、コール数に基づいて各事業ラインに 推論 コストを配賦し、事業オーナーに可視性を提供します。各アプリケーションに対してインタラクションあたりのコストメトリクスと最適化目標を設定し、ユニットエコノミクスを定義します。さらに、月次の コスト監査 を実施し、異常な増加、アイドルリソース、最適化機会を特定します。

コストの柱 の目的は、支出を最小化することではありません。支出 1 ドルあたりのビジネスリターンを最大化することです。優れた AI アーキテクチャは、コスト、パフォーマンス、品質の間で動的なバランスを取ります。削減のためにユーザー体験を犠牲にせず、わずかな品質向上を追い求めてコストを暴走させないでください。