使用タイプ

リソースの透明性レポートは、Resource Managementアプリで表示でき、ユーザーはここでプロジェクトとオントロジーによるコンピュートリソースとストレージリソースの使用状況を確認できます。

Foundryのコンピュート

Foundryはデータの上で計算作業を実行するプラットフォームです。この作業はFoundryの compute-seconds を使用して測定されます。コンピュート秒はプラットフォーム内の計算作業の単位を表し、バッチ（長時間実行）とインタラクティブ（アドホック）の両方のアプリケーションで使用されます。これらのコンピュート秒は、並列化されたコンピュートエグゼキュータの数、コンピュートエグゼキュータのサイズ、作業対象のデータのサイズ、計算ジョブの複雑さなど、さまざまな要素によって引き起こされます。

Foundry内の多くのコンピュートフレームワークは「並列」方式で動作し、つまり、複数のエグゼキュータが同時に同じジョブを処理します。並列化はほとんどのジョブの実行を大幅に高速化しますが、単位時間あたりのコンピュート秒の使用量を増加させます。

実時間

定義する重要な用語は実時間です。実時間、または実経過時間とも呼ばれるこの時間は、プロセスが開始から測定点までに要した実際の時間で、壁掛け時計やストップウォッチで測定されます。言い換えれば、実時間はタスクが開始した時間とタスクが完了した時間の差（秒）です。なお、1秒あたりの実時間に対して多くのFoundryコンピュート秒が使用され、ジョブタイプによっては、その設定に応じてコンピュート秒を異なる速度で使用することに注意が必要です。

実時間とFoundryのコンピュート秒の概念について有用な例え話は、人間の時間という概念です。それぞれが8時間勤務した2人の人間は、実時間としては8時間しか働かなかったにもかかわらず、16人間時間分の仕事を生み出します。

並列化バッチコンピュート

並列化バッチコンピュートは、「バッチ」方式で実行されるクエリやジョブを表しており、これらは特定のスケジュールの周期またはアドホックな基準でバックグラウンドで実行されるように設定されます。バッチコンピュートジョブは実行されていないときにはコンピュートを消費しません。Foundryはこれらのジョブがトリガーされるとすぐに計算リソースを自動的に割り当てます。コンピュートの使用は、リソースがプロビジョニングされた時点から、ジョブから解放されるまで計量されます。

プラットフォーム全体でコンピュートリソースがどのように使用されているかを把握するために、個々のジョブのvCPUとメモリ使用量が測定され、データセットとオブジェクトレベルで報告されます。

現在、以下のバッチコンピュートジョブが監視されています：

• すべてのTransformsジョブ（Java、Python、SQL、Mesa、GPU）
• Pipeline Builder
• Contourから保存されたデータセットのビルド（Contourのプレビュー、解析、レポートは除く）
• Code Workbooks
• Ontologyとインデックス付きストレージへの同期（例：オブジェクトストレージや時系列同期）
• オブジェクトストレージV1（Phonograph）の書き戻しジョブ
• データヘルスチェック

並列化インタラクティブコンピュート

インタラクティブコンピュートは、リアルタイムで評価されるクエリを表しており、通常はインタラクティブなユーザーセッションの一部としています。迅速な応答を提供するために、インタラクティブコンピュートシステムは常時アイドル状態のコンピュートを維持します。これは、インタラクティブクエリがバッチ評価よりも高価であることを意味します。

インタラクティブ使用は、各クエリごとに報告されます - クエリは、スケジュールされたバックエンドアプリケーションの公正なシェアを消費します。その使用は、バッチコンピュートと同様に、プロジェクトレベルで集計されます。

現在、以下のアプリケーションからのクエリがインタラクティブコンピュート使用に含まれています：

• Contourのダッシュボード、分析、プレビュー.
• Ontologyのクエリ
• 時系列クエリ
• Code Workspaces

並列化連続コンピュート

連続コンピュートは、メッセージを常時受信可能で、そのメッセージを任意のロジックを使用して処理する常時稼働の処理ジョブに使用されます。

連続コンピュートは、ジョブがメッセージを受信し、作業を実行できる状態にある時間の長さについて測定されます。

現在、以下のアプリケーションからの使用が連続コンピュートに含まれています：

• ストリーミング
• Foundry Machine Learning

並列化コンピュートの計測単位

並列処理コンピュートでは、コア秒とメモリーからコアへの比率という2つのメトリクスを測定してコンピュート秒を生成します。

並列化コア秒

コア秒は、ジョブの期間中に使用されたvCPUコアの数を反映しています。例えば、2コアが3秒間使用された場合、結果は6コア秒となります。ジョブの期間は、ジョブの提出からジョブが完了を報告するまでの時間です。これには、スピンアップ時間とジョブのクリーンアップ時間も含まれます。

特定のジョブがどの程度のコアを使用したかを判断するために、ジョブのプロパティが調査されます。具体的には、エグゼキュータの数、エグゼキュータのvCPUコアの数、ドライバが考慮されます。

プラットフォーム内の一般的な並列化コンピュートエンジンはSparkです。一部のユーザーはSpark Configuration Serviceプロファイルのみを使用しているかもしれませんが、これらのプロファイルは「サイズ」で事前に決定されたSparkの設定を提供します。通常、これらのプロパティはジョブのSparkプロファイルで指定されているか、システムのデフォルトに設定されています。

例えば：

# SparkのドライバプログラムのCPUコア数を設定します。この数は3に設定されています。
spark.driver.cores = 3
# SparkのエグゼキュータのCPUコア数を設定します。この数は2に設定されています。
spark.executor.cores = 2

この例では、合計コア秒は次の方法で計算できます：

# コア秒数 (core_seconds) を計算するための式
# num_driver_cores: ドライバーコア数
# num_executor_cores: エグゼキューターコア数
# num_executors: エグゼキューター数
# job_duration_in_seconds: ジョブの実行時間（秒）
core_seconds = (num_driver_cores + num_executor_cores * num_executors) * job_duration_in_seconds

メモリとコアの比率

リアルタイムの計算ホストは固定のメモリとコアの比率を持っているため、1つのコアあたりにどれだけのGiBのメモリが使われるかを考慮する必要があります。例えば、4つのコアと32GiBのメモリを持つホストがあるとします。このホストでは、それぞれ1つのコアと8GiBのメモリをリクエストする4つのジョブをスケジュールできます。しかし、これらのジョブのうち1つが16GiBのメモリをリクエストする場合、他のジョブは追加のコアを利用できません。これは、残りのジョブのうちの1つに追加の容量が必要になることを意味します。そのため、メモリとコアの比率は、コンピュート秒の計算の重要な部分です。

Foundryでは、デフォルトのメモリとコアの比率は 7.5 GiB per core です。

並列化されたコア秒からコンピュート秒へ

Foundryのコンピュート秒は、ジョブのために予約されたvCPUコア数とメモリ量の両方を反映しています。コンピュート秒は、コア秒と予約されたメモリ量を組み合わせたものです。

要約すると、コンピュート秒は以下の2つの要素の最大値を取ることで計算されます。

• タスクごとに使用されるコア数、および
• タスクのエグゼキュータのメモリとコアの比率。

これは次の式で表すことができます。max(num_vpcu, gib_ram / 7.5)

以下の特徴を持つ例を考えてみましょう。

• それぞれ1つのコアと12GiB RAMを持つ2つのエグゼキュータ
• 合計の実時間計算時間は5秒

vcpu_per_executor = 1  # エグゼキュータごとのvCPU数
ram_per_executor = 12  # エグゼキュータごとのRAM (GB)
num_executors = 2  # エグゼキュータの数
num_seconds = 5  # 計算時間 (秒)

default_memory_to_core_ratio = 7.5  # デフォルトのメモリからコアへの比率
job_memory_multiplier = 12 / 7.5 = 1.6  # ジョブのメモリ乗数

job_core_seconds = num_vcpu * num_excutors * num_seconds  # ジョブのコア秒
job_core_seconds = 1 * 2 * 5 = 10  # 10コア秒

job_compute_seconds = max(num_vcpu, job_memory_multiplier) * num_executors * num_seconds  # ジョブの計算秒
job_compute_seconds = max(1vcpu, 1.6mem-to-core) * 2executors * 5sec  # 16計算秒

ジョブは10コア秒しか使用していなかったものの、大きなメモリ要求により、合計で16コンピュート秒を使用しました。

クエリのコンピュート秒

Foundry では、オンデマンドでクエリを実行できるさまざまなインデックス付きストアがあります。これらのインデックス付きストアは、クエリを実行する際にコンピュート秒を使用します。クエリがコンピュート秒を使用する方法についてのドキュメントは、以下のドキュメントを参照してください。

• Foundry オントロジー
• Foundry タイムシリーズ

オントロジーの容量

Foundry のオントロジーとインデックス付きデータ形式は、高速で組織中心のクエリやアクションを行うためのツールを提供しています。これらの基盤システムは、データをアドホックな運用や分析ユースケースに適した形式で保存します。オントロジーの容量は、月あたりのギガバイト（GB/月）で測定されます。

オントロジーの容量使用は、以下のシステムで追跡されます。

• オントロジーオブジェクト（v1 & v2）
• Postgate（Postgres インターフェース、すべての Foundry 構成で利用可能ではありません）
• Lime（オントロジーマッピングのないレガシードキュメントストア）

Foundry ストレージ

Foundry ストレージは、Foundry の非オントロジー変換レイヤーに保存される汎用データを測定します。ディスク使用量は、月あたりのギガバイト（GB/月）で測定されます。

各データセットのストレージ使用量は個別に計算されます。データセットのブランチや過去のトランザクション（およびビュー）は、1つのデータセットが消費するディスクスペースに影響します。DELETE トランザクションを使用してビューからファイルが削除された場合でも、ファイルは基本ストレージから削除されず、ストレージコストが蓄積され続けます。ディスク使用量の合計は、以下の2つのステップで計算されます。

• あるデータセットに対してコミットされたか中止されたトランザクションをすべて見て、追加された基本ファイルのサイズを合計します。
• リテンションを使用して削除されたすべてのトランザクションを差し引いて、使用されている実際のディスクスペースを算出します。

サイズを削減する唯一の方法は、リテンションを使用して不要なトランザクションをクリーンアップすることです。DELETE トランザクションをコミットしたり、ブランチを更新したりしても、使用しているストレージは削減されません。

オントロジーの容量使用の帰属

オントロジーの容量使用は、主に各オブジェクトの入力データソースのプロジェクトに帰属されます。Foundry のリソースとオブジェクトは、以下に示すように、プロジェクトの詳細な使用状況を表示する際に並列して表示されます。

一部のオブジェクトは、単一のプロジェクトに帰属できない場合があります。たとえば、オブジェクトには、複数のプロジェクトにまたがる複数の入力データソースがある場合があります。このような場合、使用状況は以下のようにオントロジー自体に帰属されます。

一般的に、オブジェクトは以下のタイプの使用状況が発生します。

• Foundry コンピュート は、データセットをオブジェクトタイプにインデックス化するために使用されるコンピュートを捉えます。つまり、オントロジーを同期するためのコストです。
• オントロジーの容量 は、すべてのオブジェクトタイプのインデックスのサイズを捉えます。
• Foundry ストレージ は、オブジェクトには空です。

使用単位

コンピュート秒

Foundry のすべての製品で行われる計算作業は、コンピュート秒で表現されます。Foundry プラットフォームでは、コンピュート秒は時間の測定ではなく、プラットフォームが実行する作業の単位です。コンピュート秒はプラットフォームの原子単位であり、Foundry でコンピューティングが測定される最小の粒度を意味します。以下の表に、各 Foundry 製品タイプがコンピュート秒をどのように使用するかの詳細が記載されています。

ギガバイト・月

Foundry のすべての製品によるストレージ使用量は、月あたりのギガバイト（GB/月）で表現されます。これは、割り当てられたストレージを時間経過で測定したものです。1GB のデータファイルは、1か月あたり1 GB/月の使用量を消費します。

ストレージ容量は1時間ごとに計算され、その月の期間中の合計1時間ごとの測定値から 月あたりのギガバイト（GB/月）の値が計算されます。たとえば、30日間の月の場合：

Days 0-3      - 0GB volume
Day 4, 06:00  - 3GB volume (3GB added)                 # 3GB追加
Days 5-10     - 3GB volume (no change from day 3)      # 3日目から変更なし
Day 11, 00:00 - 6GB volume (3GB added)                 # 3GB追加
Days 11-20    - 6GB volume (no change)                 # 変更なし
Day 21, 00:00 - 3GB volume (3GB deleted)               # 3GB削除
Days 21-30    - 3GB volume (no change)                 # 変更なし

合計:
(0GB * 4 日 + 3GB * (18hrs/24) 日 + 3GB * 6 日 + 6GB * 10 日 + 3GB * 10 日) / 30 日
   = 3.675 ギガバイト月の使用量

月の日数が異なるため、同じ量のストレージによって生成される1日あたりの gigabyte-months は月ごとに変動します。例えば：

1ヶ月のうち1日だけ90GBを保存した場合、30日の月では以下のように消費されます:
（90GB * 1日）/ 30日 = 3 ギガバイト・月

1ヶ月のうち1日だけ90GBを保存した場合、31日の月では以下のように消費されます:
（90GB * 1日）/ 31日 = 2.90 ギガバイト・月

これは、データセットのサイズが変わらない場合のストレージ使用量を見るとき、日や週ごとの ギガバイト/月 の消費量には多少の変動があるが、月全体での ギガバイト/月 の消費量には変動がないことを意味します。

Foundry アプリケーションの一覧とそれに関連する使用量

データ変換

分析

モデルと AI の統合

Ontology とアプリケーション構築

注釈：

はい（書き戻し） は、ユーザーの編集やユーザーが作成したオブジェクトを Foundry のオブジェクトセットに保存するプロセスを指します。

はい（エクスポート） は、ユーザーの編集を Foundry の指定された書き戻しデータセットに保存するプロセスを指します。

はい（他のアプリケーションから） は、他の埋め込み型 Foundry アプリケーション、例えば Notepad ドキュメント内の Contour ボードなど、により生成される使用量を指します。

AIP でのコンピュート使用量

AIP のコンピュート使用量には大規模言語モデル（LLMs）が関与します。基本的に、LLMs はテキストを入力として受け取り、テキストを出力として返します。テキストの入力量と出力量は トークン という単位で測定されます。これは、単語（または単語の一部）で、基本的な LLM のカウント可能な単位を構成します。モデルプロバイダーによってトークンとは何かの定義は異なります。例えば、OpenAI と Anthropic です。平均的に、トークンは約 4 文字で、文字は単一の文字や句読点です。

AIP では、トークンは LLMs へのプロンプトを送信し、LLMs からのプロンプトを受信するアプリケーションによって消費されます。これらのプロンプトとレスポンスはそれぞれ計測可能な数のトークンから構成されます。これらのトークンは複数の LLM プロバイダーに送信することができます。プロバイダー間の違いにより、これらのトークンは基礎となるモデルプロバイダーの価格に合わせて コンピュート秒 に変換されます。

LLM を利用した機能を提供するすべてのアプリケーションは、使用時にトークンを消費します。以下のリストには、ユーザーが LLM を利用した機能と対話するときにトークンを使用する可能性のあるアプリケーションのセットを示します。

• AIP Assist
• AIP Logic
• AIP Error Enhancer
• AIP Code Assist
• Workshop LLM を利用したツール
• Quiver LLM を利用したツール
• Pipeline Builder LLM を利用したツール
• Language Model Service への直接呼び出し（Python と TypeScript ライブラリを含む）

AIP でのコンピュートの測定

以下の表は、Azure ベースの OpenAI モデルのコンピュート秒レートを示しています。これらの価格は、10,000 トークンあたりのコンピュート秒で表示されています。Azure では入力トークンと出力トークンが異なる価格設定になっているため、そのコンピュート秒相当も異なります。

AIP はテキストを直接バックエンドの LLM にルーティングし、LLM 自体がトークン化を実行します。テキストのサイズは、バックエンドのモデルがレスポンスを提供するために使用するコンピュートの量を決定します。

また、トークン化を理解することも重要です。以下に GPT-4 モデルに送信される例文を示します。

The quick brown fox jumps over the lazy dog.

この文は 44 文字を含み、次のようにトークン化されます。各トークンは | 文字で区切られています：

The| quick| brown| fox| jumps| over| the| lazy| dog|.

したがって、この文は 10 のトークンを含み、次の数のコンピュート秒を使用します：

# 英語のコードのコメントを日本語に翻訳します。
# コードの計算は次のとおりです。

compute-seconds = 10 tokens * 480 compute-seconds / 10,000 tokens # 10トークンを1つとして、480コンピュート秒を10,000トークンで割ります。
compute-seconds = 10 * 480 / 10,000 # 上記の計算を具体的な数字で表します。
compute-seconds = 0.48 # 結果は0.48コンピュート秒になります。

AIPを使ってコンピュート利用の要因を理解する

大規模言語モデル（LLM）のトークンによるコンピュート秒の使用は、使用を要求する個々のアプリケーションリソースに直接付与されます。例えば、Pipeline BuilderでAIPを使ってパイプラインを自動的に説明させる場合、その説明を生成するためにLLMが使用したコンピュート秒は、その特定のパイプラインに帰属します。これはプラットフォーム全体で同じであり、これを念頭に置くことで、どこでトークンを使用しているかを追跡するのに役立ちます。

場合によっては、コンピュートの使用がプラットフォーム内の単一のリソースに帰属しないことがあります。例としては、AIP AssistやError Explainerなどがあります。使用が単一のリソースに帰属しない場合、トークンは、トークンの使用を開始するユーザーのフォルダーに帰属します。

ユーザーに代わってLLMに送信されるトークンを把握することをお勧めします。一般的に、LLMを使用する際に含める情報が多いほど、使用されるコンピュート秒が多くなります。例えば、以下のシナリオでは、コンピュート秒を使用するさまざまな方法を説明しています。

• Pipeline Builderでは、AIPに変換ノードの説明を依頼することができます。選択されたノードの数が、LLMが回答を生成するために使用するトークンの数に影響し、それによってコンピュート秒の使用量も変わります。これは、ノードの数が増えることで、LLMが処理しなければならないノードの設定に関するテキストの量も増えるためです。
• AIP Assistでは、LLMに大きなコードブロックを生成させると、出力トークンが多く必要になります。短い回答では、トークンが少なく済むため、コンピュートが少なくなります。
• AIP Logicでは、プロンプトに大量のテキストを送信すると、トークンが多く必要になり、それによってコンピュート秒も増えます。