使用类型

资源透明度报告可以在资源管理应用程序中查看，用户可以看到项目和Ontology消耗的计算和存储资源的细分。

Foundry计算

Foundry是一个在数据之上运行计算工作的平台。这项工作是通过Foundry 计算秒进行衡量的。计算秒代表平台中的一个计算工作单位，并被批处理（长时间运行）和交互式（即席）应用程序所使用。这些计算秒可以由多种因素驱动，包括并行计算执行器的数量、计算执行器的大小、正在处理的数据大小以及计算任务的复杂性。

Foundry中的许多计算框架以"并行"方式运行，这意味着多个执行器同时处理同一个任务。并行化显著加速了大多数任务的执行，但每单位时间消耗更多的计算秒。

实时时间

一个重要的术语是实时时间。实时时间，也称为经过的实际时间，是从开始到测量点的过程中，墙上的时钟或秒表测得的实际时间。换句话说，实时时间是任务开始和任务结束之间的时间差（以秒为单位）。需要注意的是，每秒实时时间可以使用许多Foundry计算秒，并且不同的任务类型根据其配置以不同的速率使用计算秒。

实时时间与Foundry计算秒的一个有用的类比是人力小时。两个人每人工作8小时工作日，即使他们工作的实时时间只有8小时，他们也产生了16小时的人力工作量。

并行批处理计算

并行批处理计算代表以"批处理"方式运行的查询或任务，这意味着它们在某个计划的节奏或即席基础上在后台触发运行。批处理计算任务在不运行时不消耗任何计算资源。Foundry会在这些任务被触发时自动分配计算资源。计算使用在资源被配置时开始计量，直到它们被从任务中释放。

为了提供平台上计算资源使用的洞察，vCPU和内存使用情况会针对单个任务进行测量，并在数据集和对象级别上报告。

目前，以下批处理计算任务被监控：

• 所有变换任务（Java，Python，SQL，Mesa，GPU）
• Pipeline Builder
• 从Contour保存的数据集构建（不包括Contour预览、分析或报告）
• 代码工作簿
• 同步到Ontology和索引存储（例如对象存储和时间序列同步）
• 对象存储V1 (Phonograph)数据输出任务
• 数据健康检查

并行交互式计算

交互式计算代表实时评估的查询，通常是交互式用户会话的一部分。为了提供快速响应，交互式计算系统保持始终在线的空闲计算，这意味着交互式查询比批处理评估更昂贵。

交互式使用情况针对每个查询进行报告 - 一个查询消耗其调度的后端应用程序的公平份额。然后，这种使用情况在项目级别汇总，就像批处理计算一样。

目前，以下应用程序的查询包含在交互式计算使用中：

• Contour仪表盘、分析和预览。
• Ontology查询
• 时间序列查询
• 代码工作区

并行持续计算

持续计算由始终在线的处理任务使用，这些任务始终可用以接收消息并使用任意逻辑处理它们。

持续计算是根据任务准备接收消息和执行工作的时间长度来衡量的。

目前，以下应用程序的使用情况包含在持续计算中：

• 流处理
• Foundry机器学习

并行计算的计量单位

对于并行处理计算，我们通过测量两个指标生成计算秒：核心秒和内存到核心比率。

并行核心秒

核心秒反映了任务持续时间内使用的vCPU核心数量。例如，2个核心使用3秒会产生6个核心秒。任务的持续时间是提交任务和任务报告完成之间的时间。这包括启动时间和任务清理时间。

为了确定某个任务使用了多少核心，检查任务的属性。具体来说，考虑执行器的数量、执行器的vCPU核心数量以及驱动程序。

平台中常见的并行计算引擎是Spark。一些用户可能只与Spark配置服务配置文件交互，这些配置文件以“大小”提供预先确定的Spark配置。通常，这些属性在任务的Spark配置文件中指定，或设置为系统默认值。

例如：

spark.driver.cores = 3  # 设置Driver的CPU核心数为3
spark.executor.cores = 2  # 设置Executor的CPU核心数为2

在此示例中，总核心秒数可以通过以下方式计算：

Copied!
1
2
3
4
5
6
core_seconds = (num_driver_cores + num_executor_cores * num_executors) * job_duration_in_seconds
# 计算任务所消耗的核心秒数
# num_driver_cores: 驱动程序使用的核心数
# num_executor_cores: 每个执行器使用的核心数
# num_executors: 执行器的数量
# job_duration_in_seconds: 任务执行的时间长度（秒）

内存与核心比率

鉴于实时计算主机具有固定的内存与核心比率，我们必须考虑每个核心使用多少GiB的内存。假设我们有一个具有四个核心和32GiB内存的主机。在这个主机上，我们可以安排四个任务，每个任务请求一个核心和8GiB内存。然而，如果其中一个任务请求更多的内存，如16GiB，其它任务将无法利用额外的核心，因为内存不足。这意味着其余的任务之一将需要额外的容量。因此，内存与核心的比率是计算秒计算的关键部分。

在Foundry中，默认的内存与核心比率是每个核心7.5 GiB。

并行化核心秒到计算秒

Foundry的计算秒反映了vCPU核心的数量和为任务保留的内存量。计算秒将核心秒与保留的内存量结合起来。

总结来说，我们通过取两个因素的最大值来计算计算秒：

• 每个任务使用的核心数量，以及
• 任务执行者的内存与核心比率。

这可以用以下表达式表示：max(num_vpcu, gib_ram / 7.5)

请考虑以下具有以下特征的示例：

• 两个执行者，每个具有一个核心和12GiB内存
• 总的挂钟计算时间为5秒

Copied!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
vcpu_per_executor = 1  # 每个执行器的虚拟CPU数
ram_per_executor = 12  # 每个执行器的内存（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

# 计算作业的计算秒数
job_compute_seconds = max(num_vcpu, job_memory_multiplier) * num_executors * num_seconds
job_compute_seconds = max(1vcpu, 1.6mem-to-core) * 2executors * 5sec
job_compute_seconds = 16 compute-seconds

注意：代码中变量num_vcpu在计算job_core_seconds时未定义，应该是vcpu_per_executor。请将num_vcpu替换为vcpu_per_executor。此外，变量num_excutors拼写错误，应为num_executors。 我们可以看到，虽然任务只使用了10核秒，但由于过大的内存请求，总共使用了16计算秒。

查询计算秒

在Foundry中，有各种可按需查询的索引存储。每个索引存储在执行查询时使用计算秒。有关查询如何使用计算秒的文档，请参阅以下文档。

• Foundry Ontology
• Foundry Timeseries

Ontology体积

Foundry的Ontology和索引数据格式提供了用于快速、以组织为中心的查询和操作的工具。这些支持系统以显著更灵活的格式存储数据，以便于临时操作和分析应用案例。Ontology体积以千兆字节-月为单位衡量。

Ontology体积的使用情况在以下系统中跟踪：

• Ontology对象（v1 & v2）
• Postgate（Postgres接口，不适用于所有Foundry配置）
• Lime（没有Ontology映射的传统文档存储）

Foundry存储

Foundry存储测量存储在Foundry中非Ontology变换层的一般用途数据。磁盘使用量以千兆字节-月为单位衡量。

每个数据集的存储使用量是单独计算的。数据集分支和先前的事务（和视图）会影响单个数据集消耗的磁盘空间。当通过DELETE事务从视图中移除文件时，文件不会从基础存储中移除，因此继续累积存储成本。总磁盘使用量通过两个步骤计算：

• 查看在数据集上提交或中止的所有事务，并汇总添加的基础文件的大小。
• 使用保留来删除所有删除的事务以获得实际使用的磁盘空间。

减少大小的唯一方法是使用保留来清理不必要的事务。提交一个DELETE事务或更新分支不会减少使用的存储。

Ontology体积使用归属

Ontology体积使用主要归属于每个对象输入数据源的项目。在查看任何项目的细粒度使用详情时，Foundry资源和对象会并排显示，如下所示。

有些对象无法归属于单个项目；例如，一个对象可能有多个跨多个项目的输入数据源。在这种情况下，使用归属于Ontology本身，如下所示。

通常，对象累积以下类型的使用：

• Foundry计算捕获用于将数据集索引到对象类型的计算；换句话说，同步Ontology的成本。
• Ontology体积捕获所有对象类型索引的大小。
• Foundry存储为空对象。

使用单位

计算秒

Foundry所有产品完成的所有计算工作都表示为计算秒。在Foundry平台中，计算秒不是时间的度量，而是平台执行的工作单位。计算秒是平台中的原子工作单位，意味着它是Foundry中计算测量的最小粒度。请参见下表，了解每种Foundry产品类型如何使用计算秒。

千兆字节-月

Foundry所有产品的所有存储使用都表示为千兆字节-月，这是对分配存储随时间推移的度量。1GB的数据文件每月消耗1GB月的使用量。

存储体积是按小时计算的，而千兆字节-月值是从该月期间的总小时测量中计算得出的。例如，对于一个有30天的月份：

Days 0-3      - 0GB volume
Day 4, 06:00  - 3GB volume (3GB added)  # 第4天上午6点增加了3GB
Days 5-10     - 3GB volume (no change from day 3)  # 第5到第10天保持3GB，不变
Day 11, 00:00 - 6GB volume (3GB added)  # 第11天凌晨增加了3GB，总共6GB
Days 11-20    - 6GB volume (no change)  # 第11到第20天保持6GB，不变
Day 21, 00:00 - 3GB volume (3GB deleted)  # 第21天凌晨删除了3GB，剩余3GB
Days 21-30    - 3GB volume (no change)  # 第21到第30天保持3GB，不变

Total:
(0GB * 4 days + 3GB * (18hrs/24) days + 3GB * 6 days + 6GB * 10 days + 3GB * 10 days) / 30 days
   = 3.675 gigabyte-months of usage  # 平均使用量为3.675 GB-月

由于每月的天数不同，相同存储量每天产生的千兆字节-月将会随每月而变化。例如：

Copied!
1
2
3
4
5
6
7
8
9
10
11
90GB stored for 1 day in a month with 30 days will consume:
(90GB * 1 day) / 30 days = 3 gigabyte-months

# 在一个有30天的月份中储存90GB数据1天将消耗：
# (90GB * 1天) / 30天 = 3 gigabyte-months

90GB stored for 1 day in a month with 31 days will consume:
(90GB * 1 day) / 31 days = 2.90 gigabyte-months

# 在一个有31天的月份中储存90GB数据1天将消耗：
# (90GB * 1天) / 31天 = 2.90 gigabyte-months

这意味着，当查看一个固定大小数据集的存储使用时，按天或按周计算的 gigabyte-months 会有一些波动；整个月份消耗的 gigabyte-months 则不会波动。

Foundry应用程序及相关使用列表

数据变换

分析

模型和AI集成

Ontology和应用程序搭建

备注：

是 (数据输出) 指的是将用户编辑或用户创建的对象存储到Foundry中的对象集的过程。

是 (导出) 指的是将用户编辑存储到Foundry中指定的数据输出数据集的过程。

是 (来自其他应用程序) 指的是由其他嵌入的Foundry应用程序产生的使用，例如嵌入在笔记本文档中的Contour面板。

AIP计算使用

AIP计算使用涉及大型语言模型（LLM）。基本上，LLM将文本作为输入，并以文本作为输出。文本输入和输出的量以词元衡量。 LLM的计算使用以每一定数量的词元的计算秒数衡量。不同的模型可能有不同的计算使用率，如下所述#measuring-compute-with-aip。

AIP中的词元

词元定义为构成基础LLM可计数单位的单词（或部分单词）。不同的模型提供者对构成词元的定义各不相同；例如，OpenAI ↗ 和 Anthropic ↗。平均来说，词元大约为4个字符长，其中字符是单个字母或标点符号。

在AIP中，词元被应用程序消耗，这些应用程序向LLM发送提示并接收提示。这些提示和响应都包含可测量数量的词元。这些词元可以发送到多个LLM提供者；由于提供者之间的差异，这些词元会转换为计算秒数以匹配基础模型提供者的价格。

所有提供LLM支持功能的应用程序在使用时都会消耗词元。请参阅以下可能在与其LLM支持功能交互时使用词元的应用程序列表。

• AIP助手
• AIP逻辑
• AIP错误增强器
• AIP代码助手
• 研讨会LLM支持工具
• Quiver LLM支持工具
• Pipeline搭建器LLM支持工具
• 直接调用语言模型服务（包括Python和TypeScript库）

用AIP测量计算

下表列出了可用模型的计算秒数费率。价格以每10,000个词元的计算秒数为单位。请注意，输入和输出词元的定价因模型提供者而异，这意味着它们的计算秒数等价也将不同。

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个词元，并将使用以下数量的计算秒数：

Copied!
1
2
3
4
5
6
compute-seconds = 10 tokens * 504 compute-seconds / 10,000 tokens
# 计算compute-seconds的公式：10个tokens乘以每10,000个tokens需要的compute-seconds数504
compute-seconds = 10 * 504 / 10,000
# 执行计算，得到结果
compute-seconds = 0.504
# 计算结果为0.504 compute-seconds

使用AIP理解计算使用的驱动因素

由LLM词元导致的计算秒数的使用直接附加到请求使用的单个应用资源上。例如，如果您使用AIP在Pipeline Builder中自动解释一个管道，LLM用于生成该解释的计算秒数将归属于该特定管道。这在整个平台中都是如此；牢记这一点将帮助您跟踪您在哪些地方使用了词元。

在某些情况下，计算使用并不归属于平台中的单个资源；例如AIP Assist和错误解释器等。当使用不归属于单个资源时，词元将归属于发起使用词元的用户文件夹。

我们建议您保持对代表您发送到LLM的词元的关注。通常，您在使用LLM时包含的信息越多，使用的计算秒数就越多。例如，以下场景描述了不同的计算秒数使用方式。

• 在Pipeline Builder中，您可以请求AIP解释您的变换节点；所选节点的数量会影响LLM生成响应所用的词元数量，从而影响计算秒数的使用。这是因为随着节点数量的增加，LLM必须处理的关于这些节点配置的文本量也随之增加。
• 在AIP Assist中，要求LLM生成大块代码需要更多的输出词元。较短的响应使用的词元更少，因此计算也更少。
• 在AIP Logic中，发送大量文本与您的提示一起需要更多的词元，因此需要更多的计算秒数。