在 Azure AI 搜索 中优化无服务器定价模型的成本

注释

Azure AI 搜索可通过Azure门户、REST API 和Azure SDK获取。 它也是 Foundry IQ 的基础；Foundry IQ 是一个托管式知识层，可将企业内容转化为供 Microsoft Foundry 门户中的智能体使用的、可复用且具备权限感知能力的知识库。

Azure AI 搜索支持两种定价模型，每个模型设计用于不同的工作负荷模式：

• 专用：按搜索单位（SU）计量的固定定价。 选择一个服务层级，并根据预配的单位按小时计费。

• 无服务器（预览版）：基于用量的定价，按每小时计算单位（CU/hr）和索引存储每 GB/月计费。

Important

无服务器开发者层级目前为预览版。 此预览版在没有服务级别协议的情况下提供，不建议用于生产工作负荷。 某些功能可能不受支持，或者可能具有受限功能。 有关详细信息，请参阅 Microsoft Azure 预览版补充使用条款。

预览期间尚未启用无服务器开发人员层的计费。 你的使用量的预估费用可在 Azure 门户和遥测数据中查看，但在此初始阶段，这部分使用量不会显示在 Azure 账单中。 Microsoft将在计费开始前至少提供 30 天的通知。 此预览版期间的计费延迟是临时的。 Serverless Developer 是付费层级，一旦开始计费，你将承担所产生的任何费用。

无服务器开发人员层不支持迁移到其他定价层或从其他定价层迁移，其他层上提供的某些功能在公共预览版期间不受支持。 正式发布之前，服务限制、支持的功能和定价详细信息可能会更改。

预览版目前仅在美国中西部、瑞士北部和日本东部提供。

有关定价模型和服务层差异的详细信息，请参阅 “选择定价模型和服务层”。

无服务器模型中的成本如何确定

在无服务器模型中， 性能优化直接影响成本。 成本直接绑定到工作负荷执行：

• 查询和索引使用以每小时计算单位（CU/h）为单位的计算。
• 存储根据磁盘上的索引大小单独计费。
• 当服务处于空闲状态且没有活动查询或索引时，计算使用情况为零。 没有预留容量费用或最低容量费用。

无服务器定价模型对于流量可变、间歇性或不可预测的工作负载最具成本效益，因为在这种情况下，预配置容量往往无法得到充分利用。

Important

每小时计算单位 (CU/h) 费用不包括语义排名器、智能体检索、图像提取和技能执行。 这些功能单独计费。

了解计算单元（CUs）

计算单元（CU）表示在无服务器模型中执行搜索和索引操作所需的测量系统资源。 CU 成本主要由 CPU、内存和 IO 利用率驱动，其次由索引大小和文档有效负载大小驱动，使用量按小时计算单位（CU/h） 计费。

计算成本随以下因素变化：

• 查询复杂性
• 索引大小（GB）和结构
• 文档有效负载大小（KB）
• 字段数和检索的结果数

不同的操作具有不同的成本特征：

• 查找：低成本。 按 ID 检索单个文档是最高效的操作。
• 关键字搜索：低成本。 文本搜索使用反转索引，这些索引针对速度和计算使用率低进行了优化。
• 矢量搜索：高成本。 矢量查询的计算成本很高，因为它们需要跨高维嵌入的相似性计算。 与关键字搜索相比，它们消耗的计算量要大得多。
• 混合搜索：其成本结合了关键词搜索和矢量搜索的成本，因为每个查询都会运行这两条处理管道，外加用于合并结果的倒数排名融合 (RRF) 所带来的一小部分额外开销。

监视计算使用情况

监视计算消耗有助于识别成本高昂的操作、优化查询模式和估算成本。 每个请求的计算单位（CU）成本以浮点数的形式返回在 HTTP 响应标头中 x-ms-request-charge 。 使用此标头可识别成本高昂的操作并优化查询模式。 可以通过检查Azure Monitor中的 HTTP 响应标头和操作事件来跟踪每个请求的 CU 成本。 有关可用的监控数据类型以及分析这些数据的方法的更多信息，请参阅监视 Azure AI 搜索。

• 标头：x-ms-request-charge: <value>
• 值：表示所消耗 CUs 的浮点数。

Example:

Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45

在此示例中，请求消耗了 12.45 个计算单元。 可以使用此值来确定高成本操作，并比较不同查询模式的相对成本。

若要查看无服务器搜索服务的历史计算消耗量，请在Azure门户中使用Azure Monitor指标：

1. 访问你的搜索服务。
2. 选择 指标。
3. 选择 “+ 添加指标”。
4. 从指标列表中，选择 “计算单位使用情况”。
5. 使用图表分析使用情况趋势，并确定计算消耗量增加的时间段。

监视聚合使用情况有助于了解整体服务成本，并确定消耗最多计算资源的工作负荷。 有关可用监视指标的说明，请参阅 “监视数据参考”。 可以使用Azure Monitor日志跟踪一段时间内的聚合 CU 使用情况，并将其与查询量和工作负荷更改相关联。

为计算使用情况配置警报

可以在Azure门户中创建一个警报规则，以在计算消耗量达到指定阈值时收到通知。

1. 转到搜索服务中的 警报 。
2. 选择“+ 创建警报规则”。
3. 在 “条件”下，选择 “计算单位使用情况 ”作为信号。
4. 定义警报逻辑。 例如，当总使用量大于指定值时触发。
5. 配置 操作，例如电子邮件、短信或 Webhook 通知。
6. 完成其余步骤，然后选择“ 查看 + 创建”。

警报可帮助你主动响应意外的使用高峰并管理成本。

估算无服务器成本

基于Azure定价计算器和搜索单元（SU）的容量规划指南不适用于使用无服务器定价模型的服务。

若要估算无服务器成本，请执行以下操作：

1. 为代表性的示例数据编制索引。
2. 运行典型的索引编制和查询工作负荷。
3. 记录每个操作返回的 x-ms-request-charge 值。
4. 使用Azure Monitor指标来度量随时间推移的聚合使用情况。
5. 根据预期的生产流量推断成本。

由于针对相同数据执行的相同请求通常会产生类似的计算消耗量，因此代表性工作负荷可以提供可靠的成本估算依据。

无服务器使用量会被持续计量并汇总用于计费。 计算资源消耗会按分钟持续跟踪，并且仅在使用了计算资源时才会上报。

估算成本时，请使用请求费用值来了解单个操作的成本，并Azure Monitor指标来了解整体服务消耗模式。

计费基于聚合计算使用情况，而不是单个请求。 使用情况以一分钟为单位进行计量，并向上取整至最接近的每分钟 0.25 CU。 这些每分钟的使用量会在一小时内累计，用于确定可计费的 CU/小时用量。 在内部，用量会从毫计算单位 (mCU) 汇总到计算单位 (CU)，并换算为用于计费的按小时报告用量。

不同的操作使用不同的计算量。 一般而言：

• 关键字搜索通常使用最少的计算资源。
• 矢量搜索通常使用比关键字搜索更多的计算资源。
• 混合搜索结合了关键字和矢量搜索执行，因此通常使用比任何一种技术更多的计算资源。

实际计算消耗取决于查询复杂性、索引大小、数据量、矢量配置和返回的结果数等因素。 监视请求费用和聚合使用情况指标有助于识别优化机会并更好地预测生产成本。

通过优化降低计算成本

高效的查询和索引设计可降低计算消耗和降低成本。

优化架构

索引架构确定基线计算和存储成本：

• 限制字段属性：仅在需要时启用属性（可搜索、可筛选、可分面、可排序）。 每个属性都会增加索引大小和索引成本。
• 平展复杂类型：尽可能将嵌套 JSON 结构映射到简单字段或集合。
• 为仅用于筛选或排序的字段将 retrievable 设置为 false：如果某个字段用于筛选或排序，但不需要在结果中返回，请保留其索引，并将 retrievable=false 设置为 false，以减少磁盘占用以及每 GB / 每月的存储成本。
• 尽可能使用仅检索字段：例如，仅用于显示（如图像 URL）的字段不应可搜索。
• 减少矢量维度：高维向量会增加存储和查询成本。 适当时使用较小的嵌入模型或量化。
• 在编制索引之前最小化文档有效负载大小：较大的文档对索引的成本更高。 在将文档发送到索引之前，请删除不必要的字段，裁剪过长文本，并去除 HTML 标记。

优化索引请求

将数据发送到索引的方式会影响成本和吞吐量：

• 尽可能使用更大的批次：批量索引通过将网络和处理成本分摊到更多文档上，来降低每个请求的开销。 通常，最多 1,000 个文档或大约 16 MB 的批处理比许多小型请求更高效。 但是，最佳批大小取决于工作负荷。 测试以平衡吞吐量、延迟和可靠性。

• 仅为新数据或更改的数据编制索引：尽可能避免完全重新编制索引。 仅发送添加和更新可减少处理的文档数、降低计算成本并提高引入速度。

• 对增量索引使用更改检测：在重新处理内容之前检测更改的内容。 增量索引可避免对未更改的文档重复工作，并降低重新处理成本。

• 跳过图像提取，除非需要它：图像提取增加了额外的处理工作，并可能成为单独的成本驱动因素。 仅对实际需要图像内容的文档或工作流启用它。

• 使技能面向相关领域和文档：将技能扩充范围限定到其所需的特定领域或文档。 避免对不需要扩充处理的内容运行技能，尤其是在下游并不会使用这些输出时。

• 考虑索引大小增长：尽可能创建较小的索引。 随着索引的增长，索引成本增加，因为必须存储和维护更多的数据，并且操作需要更多的计算。 对于非常大的数据集，请考虑将数据分区到多个索引，以帮助管理性能和成本。 虽然成本随着索引大小而上升，但增加是子线性的。 较大的索引每次操作的成本更高，但并不会成比例地增加。

如需更多指导，请参阅 提高 Azure AI 搜索 性能的技巧。

优化查询

查询设计是影响可变成本的主要因素：

• 用于 $select 限制返回的字段：这将减少序列化所需的有效负载大小和计算。

  GET /docs?search=test&$select=id,title,url
  

• 使用 searchFields 限定搜索文本的位置：将查询时的匹配限制在与具体场景相关的字段中。 每个额外的可搜索字段都会增加查询工作，并可以增加 CU/h。

• 首选完全匹配或简单的关键字查询：模糊、通配符、正则表达式和前缀样式查询可以强制进行广泛的索引扫描，并消耗更多的 CU/h。 仅当需要部分匹配行为时使用它们，并尽可能选择完全匹配或更简单的关键字查询。

• 尽可能使用查找而不是搜索：按 ID 检索文档比运行搜索查询更有效。 如果已知文档 ID，请使用查找，而不要使用搜索查询。 查找效率更高，因为它们直接按键检索文档，而搜索查询则调用完整的查询管道（分析、索引遍历、评分和排名），这会增加计算成本。

• 避免深入分页（$skip）：较大的 $skip 值会增加计算，因为引擎必须处理并排名上述所有结果（例如， $skip=5000 需要评分至少 5,000 个未返回的文档）。 这会浪费计算资源（CU）并增加成本。 请改用筛选器缩小结果范围，并限制返回 $top的数字。 将 $top 调整为适合界面显示的大小。 例如， $top=10 成本低于 $top=50 因为评分和返回的结果更少。 仅请求尽可能多的结果，并避免需要引擎处理大量未使用的结果的模式。

• 尽量减少分面数量并缩小分面范围：仅请求界面中显示的分面，并将每个分面的 count 值尽可能设低。 分面需要按查询进行聚合，高计数会增加计算成本。

• 用于 search.in 筛选：按 ID 或值列表进行筛选时，请使用 search.in 函数而不是多个 or 条件（例如， id eq '1' or id eq '2'）。 此方法更高效，可降低计算开销。 还应避免将高基数字段（即包含大量唯一值的字段，例如唯一 ID 或自由文本描述）标记为可筛选或可分面，除非确有必要，因为这会增加索引大小和查询成本。

优化管理请求

除了查询和索引操作，Azure AI 搜索还包括对象级和服务级别管理操作（例如检索索引架构或服务统计信息）。 这些请求的单次请求费用是固定的。 虽然每个请求都是廉价的，但重复的或不必要的调用可能会随着时间的推移累积并增加总体计算使用量。

• 避免过多的管理请求：客户端上的缓存元数据（如索引架构），而不是重复检索。 例如，在每次写入操作之前获取索引架构会带来不必要的开销。 在无服务器模型中，此模式直接增加计算费用，而在专用服务中，影响通常由固定的每小时计费隐藏。

优化向量成本

矢量工作负荷通常是搜索无服务器定价模型的成本最高的组件，因为它们会影响计算单元（查询和索引）和存储（磁盘上的矢量大小）。 为了降低成本，请优化矢量的存储方式和查询方式。

优化矢量存储和架构

矢量字段可以显著增加索引大小和索引成本。 使用以下技术来降低存储开销：

• 使用压缩来减小矢量大小：应用量化来减少存储占用量，并降低相关性影响。 例如，标量量化最多可减少 4×矢量存储，对搜索质量的影响最小。

• 在不需要时禁用向量存储：如果只需要搜索的矢量，而不是检索，请在向量字段上设置 stored=false。 这可以避免将原始向量存储在索引中，从而降低存储成本，而不会影响查询行为。

• 尽可能使用较小的嵌入维度：高维向量会增加存储和查询成本。 对于非关键工作负荷，请使用较小的嵌入模型（例如 384 或 768 维度而不是 1536）来降低成本。

优化矢量查询执行

矢量查询是计算密集型的，因为它们需要对高维数据结构进行相似性计算。

• 选择性地使用混合搜索：混合查询同时运行关键字和矢量检索。 仅在相关性需要时才使用。

• 在矢量查询之前应用筛选器：缩小在矢量搜索之前设置的候选项，以减少处理的数据量。 请参阅 筛选在矢量查询中的工作原理。

通过最大程度地减少使用来降低成本

无服务器模型仅对消耗的资源收费。 如果没有请求，则计算使用量会相应地下降。

若要最大程度地降低使用成本，可：

• 仅在需要时运行查询。
• 避免冗余或过于频繁的请求。
• 按需监视使用情况和优化工作负荷。

小窍门

根据服务处于预热状态还是冷启动状态，同一查询可能具有不同的延迟和 CU 配置文件。 在无读取或写入流量的时间段后，无服务器定价模型中的计算使用情况降至零。 下一个请求的延迟可能会更高，并且在数据路径预热期间会消耗更多 CU。 较大的索引通常比小型索引需要更长时间预热，因此冷启动效应在规模较大的服务中往往更为明显。

优化存储成本

存储根据磁盘索引大小按 GB/月计费，该大小可能超过原始数据大小。 若要降低存储成本，请执行以下操作：

• 删除未使用的索引。
• 最小化存储的字段。
• 设计模式时要考虑存储开销。
• 有选择地使用建议器，因为它们可以显著增加存储大小。

有关特定于矢量的技术（压缩、修剪和存储设置），请参阅 “优化矢量存储和处理”。

有关存储与查询性能之间的权衡的更多指导，请参阅Azure AI 搜索 中提升性能的技巧。