Azure AI 搜索中的服务限制

存储、工作负荷和索引数量和其他对象的最大限制取决于Azure AI 搜索服务的定价模型。

Azure AI 搜索支持两种定价模型，每个模型都有关联的服务层。 选择的层会影响本指南中概述的服务限制。

• 专用：按搜索单位（SU）计量的固定定价。 服务层级选项包括：基本、标准（S1-S3，包括 S3 HD）、存储优化（L1-L2），以及具有有限搜索服务功能的免费层。
• 无服务器（预览版）：基于用量的定价，按每小时计算单元（CU/小时）和索引存储每 GB/月计费。 当前预览层为：无服务器开发人员。 限制由每个索引上限、每个服务对象计数和无服务器限制行为共同定义。

若要了解详细信息，请参阅 “选择定价模型和服务层”。

排查配额、容量或限制导致的失败

配额和容量失败分别由不同的控制机制引起。 使用已完成的操作中的错误来确定适用的是哪一种。

如果创建、缩放或升级操作仍在运行，请等待预配状态变为 Succeeded 或 Failed。 某项操作正在进行中并不表示存在配额或容量不足问题。 如果缩放操作失败，请参阅 缩放过程中的错误。

可用的订阅配额不能保证区域容量，请求更多配额不会解决容量约束。 如果问题仍然存在，请提交 Azure 支持请求，并在请求中提供订阅、区域、层级、所请求的配置、完整的错误文本、UTC 时间以及任何关联 ID 或操作 ID。

订阅限制

可创建多个可计费的搜索服务（基本层和更高层级），最多可创建每个区域每层允许的服务数上限。 例如，可以在基本层创建最多 16 个服务，在同一订阅和区域中的 S1 层创建另外 16 个服务。 然后，您可以在另一个区域中再创建 16 个基本服务，这样在同一订阅下，基本服务总数可达到 32 个。 有关服务层的详细信息，请参阅 “选择定价模型和服务层”。

可以按请求提高最大服务限制。 如果需要在同一订阅中使用更多服务，请提交支持请求。

¹ 每个 Azure 订阅可以有一个免费的搜索服务。 免费层基于与其他客户共享的基础结构。 硬件不是专用的，因此不支持纵向扩展，并且存储限制为 50 MB。 长时间处于非活动状态后，可能会删除免费搜索服务，以便为更多服务腾出空间。

² 搜索单位 (SU) 即计费单位，以副本或分区形式分配。 两者都是必需项。 若要了解有关 SU 组合的详细信息，请参阅估计和管理搜索服务的容量。

服务限制

在专用定价模型中，通过将副本数乘以分区（搜索单位）来规划容量。

¹ 基本层支持三个分区和三个副本，在 2024 年 4 月 3 日之后创建 的新搜索服务 上总共有 9 个搜索单位（SU）。 较旧的 Basic 服务仅支持一个分区和三个副本。

搜索服务受最大存储限制（分区大小乘以分区数）或 最大索引数 或 索引器 最大数量的硬性上限限制，以先达到的限制为准。

服务级别协议（SLA）适用于具有两个或多个查询工作负荷副本的计费服务，或者适用于查询和索引工作负荷的三个或更多个副本。 分区数不属于 SLA 相关考虑因素。 有关详细信息，请参阅 Azure AI 搜索中的可靠性。

免费服务没有固定分区或副本，并且与其他订阅者共享资源。

分区存储 (GB)

每个服务存储限制因两个因素而异： 服务创建日期 和 区域。 大多数受支持的区域为 较新的服务提供更高的限制。

此表显示了存储配额随时间推移以 GB 为增量不断递增的情况。 从 2024 年 4 月开始，在脚注中列出的区域中，更高的容量分区处于联机状态。 如果在受支持的区域中有较旧的服务，请检查是否可以 升级服务 以获得更高的存储限制。

¹ 这些区域中基本、S1、S2 和 S3 的容量存储更高。 美洲：巴西南部、加拿大中部、加拿大东部、美国东部、美国东部 2、美国中部、美国中北部、美国中南部、美国西部 2、美国西部 3、美国中西部。 欧洲：法国中部。 意大利北部、北欧、挪威东部、波兰中部、瑞士北部、瑞典中部、英国南部、英国西部。 中东：阿联酋北部。 非洲：南非北部。 亚太地区：澳大利亚东部、澳大利亚东南部、印度中部、Jio 印度西部、东亚、东南亚、日本东部、日本西部、韩国中部、韩国南部。

² L1 层和 L2 层具有更高容量的存储。 更多区域将在每个可计费层提供更高的容量。 美洲：美国东部 2 EUAP。 欧洲：德国北部、德国中西部、瑞士西部。 Azure 政府：得克萨斯州、亚利桑那州、弗吉尼亚州。 非洲：南非北部。 亚太地区：中国北部 3、中国东部 3。

³ 西欧有更高容量的存储可用。

索引限制

² 在 2017 年 12 月之前创建的基本服务对索引数的限制较低（为 5 个而不是 15 个）。

² 字段的上限包括复杂集合中的一级字段和嵌套子字段。 例如，如果一个索引包含 15 个字段，并且有两个复杂集合，每个集合有 5 个子字段，则索引的字段计数为 25。 具有非常大字段集合的索引可能很慢，尤其是在较旧的基本服务上。 将字段和属性限制 为只需要的字段和属性，并运行索引和查询测试，以确保性能是可接受的。

³ 2024 年 4 月 3 日之前创建的基本服务支持每个索引最多 100 个字段。 较新的基本服务支持每个索引 1,000 个字段。

⁴ 元素存在上限，因为具有大量元素会显著增加索引所需的存储。 复杂集合的元素定义为该集合的成员。 例如，假设某酒店文档包含“客房”复杂集合。 每个“Rooms”集合中的房间都被视为一个元素。 编制索引期间，索引编制引擎一次可最多安全地处理整个文档中的 3000 个元素。 中引入了api-version=2019-05-06，且仅适用于复杂集合，不适用于字符串集合或复杂字段。

⁵ 对于大多数层，最大索引大小是搜索服务上可用的总存储。 对于具有多个分区的 S2、S3 和 S3 HD 服务，因此存储更多，表中提供了单个索引的最大大小。 适用于 2024 年 4 月 3 日之后创建的搜索服务。 为采用无服务器模型（预览版）设置的服务创建的索引具有固定的最大大小，详见下表。

如果你的服务恰好是在更强大的群集上预配的，你可能会发现最大限制有所不同。 这里的限制代表了共同点。 根据上述规范构建的索引可以跨任何区域的等效服务层移植。

文档限制

每个索引最多支持以下文档数：

• 基本层、S1、S2 和 S3 为 240 亿
• 在 S3 HD 层级上，为 20 亿个
• 在 L1 层级上，为 2880 亿个
• 在 L2 层级上，为 5760 亿个

每个文档的大小最多可为 16 MB。 文档大小限制实际上适用于索引 API 请求有效负载的大小，即 16 MB。 该有效负载可以是单个文档或一批文档。 对于具有单个文档的批次，最大文档大小是 16 MB JSON。

文档大小限制适用于将文档上传到搜索服务的 推送模式 索引。 如果使用索引器进行拉取模式索引，则源文件可以是任意文件大小，但需符合索引器限制。 对于 Blob 索引器，文件大小的限制在更高层中更大。 例如，S1 限制为 128 MB，S2 限制为 256 MB。

估算文档大小时，请务必仅索引能为搜索场景创造价值的字段。 排除在要运行的查询中没有用途的源字段。

矢量索引大小限制

使用矢量字段为文档编制索引时，Azure AI 搜索会使用提供的算法参数构建内部矢量索引。

这些向量索引的大小受以下限制：

• 在专用定价模型中，为服务层级（或 SKU）的矢量搜索预留的内存。
• Serverless 定价模型中每个索引的存储上限。

有关管理矢量存储以及使其实现最大化的指导，请参阅矢量索引大小和保持在限制范围内。

矢量限制因以下情况而异：

• 服务创建日期
• 区域
• 已选择定价模型和服务层

从 2024 年 4 月开始，新的搜索服务在提供额外容量的区域（即大部分）中具有更高的矢量上限。 如果支持区域中有较旧的服务，请检查是否可以将 服务升级到 更高的向量限制。

在无服务器定价模型中，矢量限制是按索引而不是每个分区定义的。

• 每个索引的最大矢量索引大小（无服务器）： 300 MB
  • 此大小表示大约 30% 的总索引存储，与专用服务层中使用的矢量到存储比率一致。
  • 此大小是每个索引的硬限制。 在建立索引时，任何试图超出该限制的操作都会失败。

此表显示了矢量配额随时间以 GB 为单位增加的进展情况。 配额是每个分区，因此，如果将新的标准（S1）服务缩放为 6 个分区，则向量配额总数为 35 乘以 6。

¹ 早期预览期的初始矢量限制。

² 后期预览期的矢量限制。 以下三个区域没有更高的限制：德国中西部、印度西部、卡塔尔中部。

³ 对于受支持的层级和区域，分区越大，矢量配额越高。

⁴ 根据分区大小更新为其他层和区域分配的更高矢量配额。

该服务强制实施向量索引大小配额：

• 专用： 搜索服务中的每个分区
• 无服务器： 按索引计

此配额是确保服务保持正常运行的硬性限制。 超出限制后，进一步的索引尝试会导致失败。 释放可用配额后，可以通过以下方法恢复索引：

• 删除矢量文档
• 减小矢量大小或维度
• （仅限专用）横向扩展分区

索引器限制

“最长运行时间”存在的目的是在总体上为服务提供平衡和稳定性，但较大的数据集所需的索引编制时间可能会超过最大值允许的时间。 如果在允许的最长时间内无法完成索引作业，请尝试按计划运行。 计划程序将跟踪索引的状态。 如果计划的索引作业因某种原因而中断，则索引器可以在下一次计划运行时从它上次停止的位置重新开始。

索引器对象和吞吐量限制

¹ 对于免费服务，对于 blob 源，索引器最长执行时间为 3 分钟；对于所有其他数据源，索引器最长执行时间为为 1 分钟。 索引器调用每 180 秒一次。 对于调用 Foundry Tools 的 AI 索引，免费服务限制为每个索引器每天 20 次免费事务处理（其中事务定义为成功通过扩充管道的文档）。 （提示：可以重置索引器以重置其计数。

² 在 2017 年 12 月之前创建的基本服务在索引器、数据源和技能组方面的限制较低（为 5 个而不是 15 个）。

³ S3 HD 索引器支持处于预览状态，需要 2025-11-01-preview REST API 版本或更高版本。 S3 HD 索引器仅在 多租户执行环境中 运行，不支持 共享专用链接资源。 在预览期间，S3 HD 索引器支持最适合没有或几乎没有技能组的小型工作负荷（约 1 GB 索引大小）。 有关整体行为、监控和规划方面的指导，请参阅 Serverless 和 S3 HD 上的索引器执行。

⁴ 每个技能组最多拥有 30 项技能。

⁵ 关于索引器的 2 或 24 小时最长持续时间：2 小时的最长持续时间是最常见的，这是你应计划的内容。 它是指在 公共环境中运行的索引器，该索引器卸载计算密集型处理，并为查询留出更多资源。 如果将索引器配置为仅使用分配给搜索服务的基础结构在专用环境中运行，则 24 小时限制适用。 某些较旧的索引器无法在公共环境中运行，并且这些索引器始终具有 24 小时的处理范围。 如果有连续 24 小时运行的未计划索引器，则可以假定这些索引器无法迁移到较新的基础结构。 一般情况下，对于无法在两小时内完成的索引编制作业，请将索引器置于 5 分钟计划中，以便索引器可以从上次中断位置快速继续。 在免费层中，3-10 分钟的最大运行时间针对具有技能组的索引器。

⁶ 在 S3 HD 和无服务器服务上，所有索引器在每个 24 小时 UTC 窗口中共享每个服务的累积运行时 24 小时。 有关配额行为、监控和规划指南，请参阅 Serverless 和 S3 HD 上的索引器执行（预览版）。

类似 Blob 的索引器的源文件限制

文件处理分阶段进行，每个阶段都有自己的限制：

1. 数据源连接器下载源项时，会受到源特定的连接器限制。
2. Azure AI 搜索 提取该项的内容，但受下表中所示的最大源文件大小和可提取字符数限制。
3. （可选）技能集将该内容发送到下游服务，其中单个技能的输入限制可以小于索引器提取的内容。

下表中的源文件最大大小和提取字符数限制适用于 Azure Blob 存储、ADLS Gen2、Microsoft 365 中的 SharePoint、OneLake 和 Azure 文件存储 索引器。 有关各项技能的限制，请查看您的技能组合中各项技能对应的参考文章。

¹ 最大字符数基于 Unicode 代码单元，特别是 UTF-16。

² 对 CSV 文件使用 delimitedText 分析模式时，每个文件行的缓冲区大小限制为 10MB。

³ 对 CSV 文件使用 delimitedText 分析模式时，“最大提取的内容大小”限制不适用。

⁴ 个 Blob 类索引器包括 Azure Blob 存储 索引器（blob 索引器）、ADLS Gen2 索引器、Microsoft 365 中的 SharePoint 索引器、OneLake 索引器和 Azure 文件存储 索引器。 直接上传文件知识源不使用索引器，并且具有 单独的限制。

共享专用链接资源限制

索引器可访问专用终结点上通过共享专用链接资源 API 管理的其他 Azure 资源。 本部分介绍与此功能相关的限制。

¹ AI 扩充和图像分析属于计算密集型功能，会消耗过多的可用处理能力。 因此，在较低层上禁用了专用连接以确保搜索服务本身的性能和稳定性。 在基本服务上，不支持与 Microsoft Foundry 资源的专用连接，以保持服务稳定性。 对于 S1 层级，请确保在 2024 年 4 月 3 日之后创建了限制更高的服务。 超过 2 个 Azure OpenAI 嵌入或 Azure 视觉多模式嵌入技能的索引器，将只能在专用环境中运行，且无法使用专用连接。

² 2024 年 4 月 3 日之后创建的基本和 S1 高容量搜索服务支持专用连接到嵌入模型，其中对存储和计算处理的限制更高。

³ 不同资源类型的数量计算为在给定搜索服务的所有共享专用链接资源中使用的唯一 groupId 值的数量，而与资源的状态无关。

同义词限制

同义词映射的最大数量因层级而异。 每个规则最多可以有 20 个扩展，其中一个扩展是一个同义词。 例如，在指定“猫”的情况下，与“猫咪”、“猫科动物”和“猫属”（猫的属）的关联将算作 3 个扩展。

索引别名限制

索引别名的最大数目因层和服务创建日期而异。 在所有层上，如果服务是在 2022 年 10 月之后创建的，则允许的最大别名数是允许的最大索引数的两倍。 如果服务是在 2022 年 10 月之前创建的，则限制是允许的索引数。

² 在 2017 年 12 月之前创建的基本服务对索引数的限制较低（为 5 个而不是 15 个）。

代理检索限制

知识库指定一个或多个知识源和检索推理工作（预览版），用于控制大型语言模型（LLM）的处理级别，以便进行代理检索。 限制因定价层、API 版本和推理工作级别而异。

¹ 在 2024 年 4 月 3 日之前创建的基本服务，其知识源和知识库的上限较低（5）。

² 这些限制适用于支持知识库和知识源的 S3 HD 服务。 某些较旧的 S3 HD 服务不支持这些资源。

检索期间的知识源选择

无论 API 版本或检索推理工作如何，知识库最多可以包含上面所示的特定于层的最大值。 API 版本和推理强度转而会影响在检索时可选择的知识源数量。

2025-08-01-preview 使用旧版知识代理契约，不支持 retrievalReasoningEffort。

² 推理 minimal 工作使用知识库中的所有知识源，因为它绕过基于 LLM 的查询规划。

检索请求运行时

maxRuntimeInSeconds 限制在所有受支持的层级中均相同。

最大值仅适用于Azure AI 搜索检索请求。 有关配置示例，请参阅 替代默认推理工作并设置请求限制。

数据限制（AI 扩充）

数据限制适用于调用 Foundry 工具中Azure语言的 AI 扩充管道。 最大输入为 50,000 个字符，根据String.Length实体识别技能、实体链接技能、关键短语提取技能、语言检测技能以及 PII 检测技能进行测量。 情绪技能的最大字符数为 5,000 个字符。

如果需要在下游处理之前划分较大的文本，请使用 文本拆分技能 。

这些限制适用于专用和无服务器定价模型。

限制

限流限制通过控制 API 请求速率来帮助确保服务的稳定性。

在专用定价模型中，限制基于搜索单位（副本 × 分区）。

在无服务器定价模型中，限制并非基于搜索单位。 相反，服务级别操作限制和总体消耗行为控制吞吐量。 使用情况和服务限制管理容量，而不是副本和分区的配置。

语义排序器限制

语义排序器使用队列系统来管理并发请求。 此系统允许搜索服务获取每秒可能的最大查询数。 达到并发请求的限制后，系统会在队列中放置其他请求。 如果队列已满，系统将拒绝进一步的请求，并且必须重试这些请求。

每秒语义排名器查询总数因以下因素而异：

• 搜索服务的等级。 队列容量和并发请求限制因层而异。
• 搜索服务中的搜索单位数。 增加并发语义排序器查询最大数量的最简单方法是向搜索服务添加其他搜索单位。
• 区域中可用的语义排序器容量总数。
• 使用语义排序器提供查询所需的时间。 此时间因搜索服务繁忙程度而异。

下表按层描述了在区域可用容量限制下的语义排名器节流限制。 可以联系 Microsoft 支持部门请求提高限制。

API 请求限制

查询存在限制，因为未绑定的查询可能会破坏搜索服务的稳定性。 通常，这样的查询是以编程方式创建的。 如果应用程序以编程方式生成搜索查询，请对其进行设计，使其不会生成无限大小的查询。

存在对有效负载的限制的原因类似，确保搜索服务的稳定性。 此限制适用于整个请求，包括其所有组件。 例如，如果请求批处理多个文档或命令，则整个请求必须符合支持的限制。

如果必须超出受支持的限制，请 测试工作负荷 ，以便了解预期内容。

除非另有说明，否则以下 API 请求适用于所有可编程接口，包括 Azure SDK。

常规：

• 支持的最大有效负载限制为 16 MB，用于通过 REST API 和 SDK 编制索引和查询请求。
• 最大 8 KB 的 URL 长度（仅适用于 REST API）。

索引 API：

• 每个索引上传、合并或删除的批次最多支持 1,000 个文档。
• 每个请求支持 1 到 32,000 个索引操作。

查询 API：

• 矢量查询中最多 10 个字段
• $orderby 子句中最多 32 字段。
• 搜索子句中最多 100,000 个字符。
• 搜索中的子句数不超过 3,000 个。
• 对通配符和正则表达式查询的最大限制，由 Lucene 强制实施。 它会将模式、变体或匹配数上限设为 1,000 个实例。 此限制已实施，以避免引擎过载。

搜索词：

• 支持的最大搜索词大小为 UTF-8 编码文本的 32,766 字节（32 KB 减 2 个字节）。 适用于关键字搜索和矢量搜索的文本属性。
• 支持的前缀搜索和正则表达式搜索的最大搜索词大小为 1,000 个字符。

API 响应限制

• 搜索结果的每页最多返回 1,000 个文档。
• 每个建议 API 请求最多返回 100 条建议。

默认情况下，搜索引擎返回 50 个结果，但最多可以覆盖此参数的最大限制。

API 密钥限制

使用 API 密钥进行服务身份验证。 存在两种类型的 API 密钥。 在请求标头中指定的管理密钥提供对服务的完整读写访问权限。 在 URL 上指定的查询密钥是只读的，通常分发给客户端应用程序。

• 每个服务最多支持两个管理密钥。
• 每个服务最多支持 50 个查询密钥。