作者：来自 Elastic Sander Philipse 及 Pete Galeotti

了解 Elasticsearch Serverless 定价如何运作，这是 Elastic 的全托管部署方案。我们解释 VCUs（ Search、 Ingest、 ML ）和 ECUs，并详细说明用量如何基于实际分配的资源、工作负载复杂度以及 Search Power 。

刚接触 Elasticsearch？加入我们的 Elasticsearch 入门 网络研讨会。你也可以现在开始免费云试用，或者在你的机器上试用 Elastic。

---

从用量角度来看，按每次查询收费可能更容易理解，但从计算角度来看就要困难得多。我们是否应该对包含全文搜索、向量搜索、learning-to-rank 和 rerank 步骤的混合查询，与一个简单的 terms 查询收取相同的费用？我们是否应该对需要扫描 3 TB 索引的搜索，与只需要扫描 100 MB 索引的搜索收取相同的费用？这些都是困难而复杂的问题，我们当时并没有一个有把握的答案。

因此，我们决定根据为满足你请求的工作负载而实际分配的资源向终端用户收费。这意味着你可以确信，我们收取的费用对应的是你的实际工作负载。

但不幸的是，这也意味着我们的定价理解起来会比较复杂：要完全弄清楚我们如何确定所使用的资源，你需要对我们的内部系统有完整的了解。

VCU、ECU 以及其他术语

我们先来定义一些在本文中会反复出现的术语。

VCU

VCU 是 Virtual Compute Unit。一个 VCU 表示一个虚拟主机切片，包含 1 GB 内存 以及相应的 CPU 和 存储。我们根据所支持的工作负载来区分计算资源，因此有三种 VCU 类型：

• Search VCU
• Ingest VCU
• ML VCU

VCU 按小时计费。

区域 定价

我们根据云服务提供商向我们收取的费用向你收费。这意味着在不同区域和不同云服务提供商下，价格会有所不同。你可以在此页面找到完整的价格列表。

ECU

ECU 是 Elastic Consumption Unit，是我们向你计费时使用的单位。ECU 的名义价值是 $1.00 USD。所有不同的消耗组件都会按每个时间单位对应的 ECU 费率计费。例如，1 Gigabyte 的 存储 可能每月花费 0.047 ECU，因此 100 GB 的 存储 每月将花费你 4.7 ECU = $4.70。同样，如果你的 Search 工作负载在一天内消耗了 10 个 VCU，而你所在区域的 Search VCU 费率是 0.09 ECU，那么你当天的成本将是 $0.90。

价格组成

Serverless Elasticsearch 包含许多不同的定价组成部分。对于大多数用例，你最关心的组件是 Search、 Ingest 和 ML VCUs，以及 Elastic Inference Service 的 token 消耗。

Search VCUs

Search VCU 的消耗是定价中最复杂的部分。从本质上讲，一个 Search VCU 是一个正在执行搜索、包含 1 GB RAM 的虚拟主机切片。复杂之处在于，我们需要考虑许多不同的因素来确定为满足你的工作负载需要多少个 VCUs。有关我们自动扩缩容逻辑如何工作的更多细节，请参阅我们之前关于该主题的博客。

Search VCU 输入

Search VCUs 的分配基于一组复杂的因素，但就本文而言，可以大致归结为三个输入：交互式数据集大小、系统上的搜索负载，以及 Search Power。

交互式数据集大小是我们需要保持缓存、以便立即可用于搜索的数据部分。对于传统搜索用例，这通常是你的整个数据集。对于时间序列用例，这是你的数据集中位于 Boost Window 内的部分，也就是需要可用的数据天数。默认情况下，boost window 是七天，你可以在项目设置中进行更改。

搜索负载衡量的是当前活动搜索对系统造成的负载量。主要影响因素包括每秒搜索次数、搜索的复杂度（需要计算的内容越多，负载越高），以及为获得结果所需搜索的数据集大小。如果我们只需扫描 10% 的数据集就能获得正确数量的结果，那么负载将远低于需要扫描整个数据集的情况。

最后，Search Power 会影响我们分配的 VCUs 的最小值和最大值。在默认设置 Performant 下，我们会为每 1 GB 的交互式数据分配至少 1 个 VCU，并根据需求进行扩展。在最低设置 On Demand 下，我们永远不会扩展到超过每 1 GB 交互式数据对应 1 个 VCU 的 RAM。在最高设置 High Throughput 下，我们会为每 1 GB 交互式数据分配至少 2.5 个 VCUs，并根据需求进行扩展。

简而言之，需要缓存的数据集越大，我们就需要越多的 RAM（因此也需要更多的 VCU）。搜索负载越高，我们就需要越多的 CPU（因此也需要更多的 VCU）来满足搜索请求。Search Power 允许你调节我们在多大程度上进行扩缩容。

最小 VCUs

我们并没有为搜索分配一个固定的最小 VCU 数量。如果你存储的数据很少，并且没有执行任何搜索，我们会将 VCUs 完全缩减。这会在十五分钟无活动后发生。请注意，这里的无活动指的是完全没有任何用户发起的搜索。一旦需要处理任何类型的搜索，我们就必须分配硬件资源来执行该搜索。

有一个复杂因素：如果你的交互式数据集足够大（大约 60 GB 或更多），即使没有对这些数据执行搜索，我们也需要开始分配最少数量的 VCUs 来保持这些数据可用。在没有搜索请求进入的情况下，我们会尽量保持这种扩展最小化，这也是为什么在这些情况下，你可能会在第一次搜索时看到一次扩容。

VCU 消耗不是线性的

由于我们的硬件是按阶梯方式分配的，VCU 的消耗并不一定会随着工作负载规模线性增长。每一个扩展阶梯都可以容纳很大范围的工作负载，如果你的工作负载处在该范围的下限，那么在需要跳到下一个扩展阶梯之前，仍然有很大的增长空间。

这会使基于非代表性工作负载进行估算变得困难：例如，你在一个小工作负载下可能每小时消耗 2 个 VCUs，而这其实是我们的最小扩展阶梯。在开始增加为你的工作负载分配的 VCUs 之前，你完全有可能将工作负载规模提高 100 倍，仍然维持在每小时 2 个 VCU 的消耗。

我们知道这会让你更难估算成本，我们也正在努力让这件事对你来说更容易。如果你需要更多关于价格估算的帮助，随时可以联系我们的客户团队，获得更个性化的支持。

Ingest VCUs

Ingest VCUs 比 Search VCUs 简单得多。

Ingest VCU 输入

Ingest VCUs 本质上有三个输入：索引数量、 ingest 速率，以及 ingest 复杂度。我们需要为系统中的每个索引分配少量内存，这就是索引数量很重要的原因。数据流中的只读索引不计入此计算。

你 ingest 得越快，我们就需要越多的 CPU 来处理这些 ingest。你的 ingest 请求越复杂，我们就需要越多的 CPU。一些会让 ingest 请求执行成本更高的因素包括复杂的字段映射，或者大量的后处理。

最小 Ingest VCUs

我们不会为你的 ingest 分配一个最小的 VCU 数量。如果你不 ingest 数据，我们就不需要分配任何 VCU 来处理 ingest。

VCU 消耗不是线性的

与 Search VCUs 一样，我们也是基于阶梯函数来分配 Ingest VCUs。每一个阶梯都可以容纳很大范围的工作负载：如果你的 ingest 量非常小，你完全有可能将 ingest 速率提高 100 倍，仍然处在第一个扩展阶梯中，从而实际上并不会增加你的成本。

AI 工作负载

在 Serverless 中运行机器学习任务时，我们提供三种选项：

• 你使用我们的 Elastic Inference Service ( EIS ) 来运行推理和 completion 工作负载。我们负责一切，你按 token 收费。
• 你使用传统的 Elasticsearch Machine Learning 功能来运行你的工作负载。这些使用我们的 Trained Models 功能。我们会根据你的机器学习工作负载需求进行扩缩容。
• 你自己在我们的系统之外操作，只需将你的向量或其他推理结果存储并在 Elasticsearch 中搜索。

EIS

EIS 的定价非常直接：按每消耗一百万 token 收费。对于推理工作负载， token 消耗容易预测。对于基于 LLM 的任务，特别是 agentic 任务，情况可能更复杂，进行一些实验和试运行可能有助于确定你的工作负载通常消耗多少 token。

ML VCUs

Machine Learning VCUs 只依赖一个简单输入：机器学习工作负载。你需要的推理越多，我们消耗的 VCUs 就越多。一旦你停止推理，我们会缩减资源。我们会在你最后使用训练模型后的约 24 小时内将其保存在内存中以保持响应，这意味着保持该模型可用所需的最小 VCU 会在 24 小时内保持，之后才会完全缩减。

我们通常建议客户在推理时使用 EIS 而不是 Machine Learning 节点，特别是当你的使用是周期性的。通过切换到 EIS，你无需等待机器学习节点启动，也不会在缩减之前为未使用的 ML 节点时间付费。EIS 按 token 收费。

存储

我们按每月每 GB 收费。存储确实会作为系统其他部分的输入，尤其是 Search Tier 自动扩缩容（见上文 Search VCU），但存储本身的定价相当直接。

数据输出（egress）

我们会对你从系统中取出的数据收费。

为了降低 egress 成本，我们建议对查询进行以下优化：

• 不在查询响应中返回向量。对于 2025 年 10 月之后创建的索引，这是默认设置。如果需要，你可以显式返回向量。

• 只返回应用程序需要的字段。可以通过使用 fields 和 _source 参数实现。

支持

我们按总 ECU 使用量的一定比例收费。目前我们有四个支持级别：

1. Limited support
2. Base support
3. Enhanced support
4. Premium support

项目设置

我们有三个项目设置，可以让你控制项目的使用情况。

Search power

Search power 决定了搜索自动扩缩容的最小值和最大值，相对于项目的交互式数据集大小。在默认设置 Performant 下，我们为每 1 GB 的交互式数据分配至少 1 个 Search VCU，并根据需求进行扩展。在最低设置 On Demand 下，我们永远不会超过每 1 GB 交互式数据分配 1 个 Search VCU 的 RAM。在最高设置 High Throughput 下，我们为每 1 GB 交互式数据分配至少 2.5 个 VCUs，并根据需求进行扩展。

Boost window

对于时间序列用例，boost window 是构成交互式数据集大小的数据天数。交互式数据集是我们保持缓存的数据部分，并用于确定如何为你的项目扩缩容 Search 层。默认情况下，boost window 为七天。

数据保留

你可以设置项目中数据的保留天数，这将影响我们所需的存储量。你可以在项目中按每个数据流进行设置。

基础设施配置

我们目前为 Serverless Elasticsearch 提供两种基础设施选项，称为 “General Purpose” 和 “Vector Optimized”。通过云控制台 UI 创建的所有 Serverless Elasticsearch 项目都将使用 “General Purpose” 选项。你也可以通过直接调用 API 并使用 optimized_for 参数创建 “Vector Optimized”（查看文档了解所有选项）。

两者的区别在于资源分配。我们为 “Vector Optimized” 配置分配大约四倍的资源（即 VCUs），这会导致你的成本最多增加四倍。这就是为什么我们建议从 “General Purpose” 配置开始，只有在用例需要使用高维未压缩密集向量，并且量化和 DiskBBQ 无法满足需求时才使用 “Vector Optimized” 配置。

几年前设计 Serverless Elasticsearch 时，我们认为向量工作负载需要更多资源才能保持性能。然而，随着 semantic_text、sparse_vector 模型和 Better Binary Quantization (BBQ) 等创新的出现，我们发现许多向量工作负载在 “General Purpose” 配置上就能以很低成本获得良好性能。因此，不要被 “Vector Optimized” 标签迷惑……在 “General Purpose” 配置上，你也能获得向量工作负载的出色性价比。

成本监控

我们意识到，尤其是对于刚接触 Serverless Elasticsearch 的用户，跟踪成本非常重要。我们为此构建了一些工具，并不断改进以提供更高的可视性。

云控制台计费使用情况

Elastic Cloud Console 提供了云账户的所有计费详情，涵盖所有基于云的资源，包括 Serverless Elasticsearch。在这里，你可以找到本文介绍的所有价格组成部分的明细。强大的过滤功能允许你聚焦特定时间段和资源。

为了进一步监控成本，你还可以在 Billing and subscriptions 页面下的 Budgets and notifications 标签中配置自定义预算提醒。

AutoOps 监控

我们正在将 AutoOps 引入 Serverless！Serverless Elasticsearch 的核心价值之一是确保一切顺利运行，但这也意味着你对基础设施的可观测性有限。Serverless 的 AutoOps 为用户提供使用情况的可视性，从而了解成本来源。

AutoOps 会在新的 Serverless 区域定期推出，我们也在不断增加新的监控工具。请确保查看区域覆盖情况以及未来计划的监控工具。

原文：https://www.elastic.co/search-labs/blog/elasticsearch-serverless-pricing-vcus-ecus