你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
什么是预配的吞吐量？
注意
Azure OpenAI 预配产品/服务已于 2024 年 8 月 12 日收到重大更新，包括将购买模型与 Azure 标准保持一致，并迁移到与模型无关的配额。 强烈建议在此日期之前加入的客户阅读 Azure OpenAI 预配 8 月更新，了解有关这些更改的详细信息。
借助预配的吞吐量功能，可以指定部署中所需的吞吐量。 然后该服务会分配必要的模型处理容量，并确保随时可用。 吞吐量是根据预配的吞吐量单位 (PTU) 定义的，是表示部署吞吐量的规范化方式。 每个模型版本对需要不同的 PTU 量来部署，并提供不同的每 PTU 吞吐量。
预配和全局预配的部署类型提供哪些内容？
- 可预测的性能：适用于统一工作负载的稳定最大延迟和吞吐量。
- 预留处理容量：部署会配置吞吐量。 部署后，无论是否使用，都可以使用吞吐量。
- 成本节省：与基于令牌的消耗相比，高吞吐量工作负载可能节省成本。
Azure OpenAI 部署是特定 OpenAI 模型的管理单元。 部署会向客户提供模型访问权限以进行推理，并集成内容审查等更多功能（请参阅内容审查文档）。 全球部署可在与非全球部署类型相同的 Azure OpenAI 资源中使用，但前者允许利用 Azure 的全球基础结构将流量动态路由到可为每个请求提供最佳可用性的数据中心。
结果如何？
| 主题 | 已预配 |
|---|---|
| 这是什么？ | 提供增量小于现有预配套餐的保证吞吐量。 对于给定的模型版本，部署具有一致的最大延迟。 |
| 适用对象是哪些人？ | 希望保证吞吐量且延迟差异最小的客户。 |
| 配额 | 预配的托管吞吐量单位或为每个区域分配的全局预配托管吞吐量单位。 配额可用于任何可用的 Azure OpenAI 模型。 |
| 延迟 | 模型的存在限制的最大延迟。 总体延迟是调用形状的一个因素。 |
| 利用率 | Azure Monitor 中提供的预配托管利用率 V2 度量值。 |
| 估计大小 | 工作室和基准测试脚本中提供的计算器。 |
| 提示缓存 | 对于支持的模型，我们最多提供 100% 折扣的缓存输入令牌。 |
每个模型的每个 PTU 的吞吐量是多少
部署的每个 PTU 的吞吐量（每分钟标记数 (TPM)）取决于每分钟的输入和输出标记数。 生成输出标记比生成输入标记需要更多的处理，因此生成的输出标记越多，整体 TPM 就越低。 服务会动态平衡输入和输出成本，因此用户无需设置特定的输入和输出限制。 这种方法意味着部署能够灵活应对工作负载形态的波动。
为了帮助简化大小调整工作，下表概述了 gpt-4o 和 gpt-4o-mini 模型的每个 PTU 的最大 TPM。所有流量均为输入流量或输出流量。 该表还显示每个模型的服务级别协议 (SLA) 延迟目标值。 有关 Azure OpenAI 服务的 SLA 的详细信息，请参阅 [联机服务的服务级别协议 (SLA) ]。(https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1)
| gpt-4o、2024-05-13 和 gpt-4o、2024-08-06 | gpt-4o-mini，2024-07-18 | |
|---|---|---|
| 可部署增量 | 50 | 25 |
| 每个 PTU 的最大输入 TPM | 2,500 | 37,000 |
| 每个 PTU 的最大输出 TPM | 833 | 12,333 |
| 延迟目标值 | 每秒 25 个标记* | 每秒 33 个标记* |
有关完整列表，请参阅 AOAI Studio 计算器。
关键概念
部署类型
在 Azure OpenAI Studio 中创建预配部署时，“创建部署”对话框中的部署类型是“预配托管”。 在 Azure Open Studio 中创建全局预配托管部署时，“创建部署”对话框中的部署类型是“全局预配托管”。
在 Azure OpenAI 中通过 CLI 或 API 创建预配部署时，需要将 sku-name 设置为 ProvisionedManaged。 在 Azure OpenAI 中通过 CLI 或 API 创建全局预配部署时，需要将 sku-name 设置为 GlobalProvisionedManaged。 sku-capacity 指定为部署分配的 PTU 数。
az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613 \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged
配额
预配吞吐量单位
预配吞吐量单位 (PTU) 是模型处理容量的通用单位，可用于调整预配部署的大小，以实现处理提示和生成补全所需的吞吐量。 预配吞吐量单位以配额的形式授予订阅。 每个配额特定于一个区域，定义了可分配给该订阅和区域中的部署的最大 PTU 数量。
与模型无关的配额
与其他 Azure OpenAI 产品/服务使用的每分钟标记 (TPM) 配额不同，PTU 与模型无关。 PTU 可用于部署区域中任何受支持的模型/版本。
对于预配部署，新配额在 Azure OpenAI Studio 中显示为名为“预配托管吞吐量单位”的配额项。 对于全局预配托管部署，新配额在 Azure OpenAI Studio 中显示为名为“全局预配托管吞吐量单位”的配额项。 在“Studio 配额”窗格中，展开配额项会显示组成各个配额用量的部署。
获取 PTU 配额
默认情况下，PTU 配额在许多区域中可用。 如果需要更多配额，客户可以通过“请求配额”链接请求配额。 此链接显示在 Azure OpenAI Studio 中“预配托管吞吐量单位”或“全局预配托管吞吐量单位”配额选项卡的右侧。 客户可以利用表单请求增加给定区域的指定 PTU 配额。 一旦请求获得批准，客户将在包含的地址收到一封电子邮件（通常在两个工作日内收到）。
每模型的 PTU 最小值
与每个单元关联的最小 PTU 部署、增量和处理容量因模型类型和版本而异。
容量透明度
Azure OpenAI 是一项备受追捧的服务，客户需求可能超过服务 GPU 容量。 Microsoft 努力为所有需求旺盛的区域和模型提供容量，但但某个区域总是有售罄的可能。。 此约束可能会限制某些客户在所需区域中创建所需模型、版本或 PTU 数目部署的能力，即使他们在该区域中具有可用配额也是如此。 一般而言：
- 配额对可在订阅和区域中部署的最大 PTU 数施加限制，但不能保证容量可用性。
- 容量是在部署时分配的，其保留的时间与部署的存在时间一样长。 如果服务容量不可用，部署将失败
- 客户使用有关配额/容量可用性的实时信息，为具有所需模型容量的方案选择适当的区域
- 纵向缩减或删除部署会将容量释放回区域。 如果以后纵向扩展或重新创建部署，则不能保证容量可用。
区域容量指南
若要确定部署所需的容量，请使用容量 API 或 Studio 部署体验来提供有关容量可用性的实时信息。
在 Azure OpenAI Studio 中，部署体验可以确定某个区域何时缺少部署模型所需的容量。 为此，它会分析所需的 PTU 模型、版本和数量。 如果容量不可用，该体验会引导用户选择其他区域。
有关新部署体验的详细信息，请参阅 Azure OpenAI 预配入门指南。
新的模型容量 API 可用于以编程方式确定指定模型的最大规模部署。 该 API 会同时考虑区域中的配额和服务容量。
如果可接受的区域无法支持所需模型、版本和/或 PTU 数，客户还可以尝试以下步骤：
- 尝试使用较少的 PTU 进行部署。
- 尝试在不同的时间部署。 容量可用性根据客户需求动态变化，以后可能提供更多容量。
- 确保在所有可接受的区域中都有可用配额。 模型容量 API 和 Studio 体验在创建部署时会考虑返回的备用区域中的配额可用性。
确定工作负载所需的 PTU 数
PTU 表示模型处理容量。 与计算机或数据库类似，对模型的不同工作负载或请求将消耗不同的基础处理容量。 从调用形状特征（提示大小、生成大小和调用速率）到 PTU 的转换是复杂且非线性的。 若要简化此过程，可以使用 Azure OpenAI 容量计算器来调整特定工作负载形状的大小。
一些笼统的注意事项：
- 生成比提示需要更多的容量
- 对于 GPT-4o 及更新的模型，将分别为输入和输出标记设置每个 PTU 的 TPM。 对于较旧的模型，越大的调用计算起来越昂贵。 例如，100 个具有 1000 标记提示大小的调用所需的容量小于提示中具有 100,000 个标记的 1 个调用。 这种分层意味着这些调用形态的分布对于整体吞吐量来说很重要。 平均提示和补全标记大小相同的情况下，分布广泛的流量模式（包含一些较大的调用）可能比分布较窄的模式经历更低的每 PTU 吞吐量。
使用率性能的工作原理
预配和全球预配的部署提供分配的模型处理容量，用于运行给定的模型。
在预配托管部署和全局预配托管部署中，当超过容量时，API 将返回 429 HTTP 状态错误。 这种快速响应使用户能够决定如何管理其流量。 用户可以将请求重定向到单独的部署、标准即用即付实例，或使用重试策略来管理给定的请求。 服务将持续返回 429 HTTP 状态代码，直到利用率下降到 100% 以下。
如何监视容量？
Azure Monitor 中的预配托管使用率 V2 指标以 1 分钟的增量度量给定的部署使用率。 预配托管部署和全球预配托管部署经过优化，可确保使用一致的模型处理时间处理接受的调用（实际的端到端延迟取决于调用的特征）。
收到 429 响应时该怎么办？
429 响应不是错误，而是一个设计，旨在告知用户给定的部署在某个时间点被充分利用。 通过提供快速故障响应，可以控制如何以最符合应用程序要求的方式处理这些情况。
响应中的 retry-after-ms 和 retry-after 标头指示下一次调用接受前等待的时间。 选择如何处理此响应取决于应用程序要求。 下面是一些注意事项：
- 可考虑将流量重定向到其他模型、部署或体验。 此选项是最低延迟的解决方案，因为只要收到 429 信号，就可以立即执行该操作。 有关如何有效实现此模式的想法，请参阅此社区帖子。
- 如果可以接受更长的每次调用延迟，可实现客户端重试逻辑。 此选项提供每个 PTU 的最大吞吐量。 Azure OpenAI 客户端库包含用于处理重试的内置功能。
服务如何决定何时发送 429？
在预配托管和全球预配托管产品/服务中，每个请求都根据其提示大小、预期生成大小和模型单独进行评估，以确定其预期使用率。 这与即用即付部署形成鲜明对比，即用即付部署具有基于估计流量负载的自定义速率限制行为。 对于即用即付部署，这可能会导致在超出定义的配额值之前生成 HTTP 429 错误（如果流量分布不均匀）。
对于预配托管和全球预配托管，我们通过使用漏桶算法的变体，将使用率保持在 100% 以下，同时允许出现一些流量突发。 宏观层面的逻辑如下：
每个客户都有可在部署中利用的容量且是固定的
发出请求时：
a. 当前利用率超过 100% 时，服务会返回一个 429 代码，其
retry-after-ms标头设置为 100%，并一直持续到利用率低于 100% 为止b. 其他情况下，服务会结合提示令牌和调用中的指定
max_tokens来估计满足请求所需的利用率的增量更改。 对于至少包含 1024 个缓存令牌的请求，将从提示令牌值中减去缓存的令牌。 根据缓存令牌的大小，客户最多可以收到其提示令牌的 100% 折扣。 如果未指定max_tokens参数，则服务将估算一个值。 当实际生成的令牌数量较少时，此估计可能会导致并发低于预期。 为实现最高的并发，请确保max_tokens值尽可能接近实际生成大小。请求完成后，我们现在可知调用的实际计算成本。 为了确保计帐准确，我们使用以下逻辑更正利用率：
a. 如果估计了实际 >，则向部署的利用率添加差值
b. 如果估计了实际 <，则减去差值。
总体利用率根据部署的 PTU 数以连续速率递减。
注意
在利用率达到 100% 之前会接受调用。 在短时间内，可能会允许超过 100% 的突发，但随着时间的推移，流量上限为 100%。
在部署中可以进行多少次并发调用？
可以达到的并发调用数量取决于每个调用的形状（提示大小、max_token 参数等）。 服务会持续接受调用，直到利用率达到 100%。 若要确定并发调用的大致数量，可以在容量计算器中为特定调用形态模拟出每分钟的最大请求数。 如果系统生成的令牌数量少于采样令牌数量（例如 max_token），则会接受更多请求。
哪些模型和区域可用于预配的吞吐量？
| 区域 | gpt-4o，2024-05-13 | gpt-4o，2024-08-06 | gpt-4o-mini，2024-07-18 | gpt-4，0613 | gpt-4，1106-Preview | gpt-4，0125-Preview | gpt-4，turbo-2024-04-09 | gpt-4-32k，0613 | gpt-35-turbo，1106 | gpt-35-turbo，0125 |
|---|---|---|---|---|---|---|---|---|---|---|
| australiaeast | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 巴西南部 | ✅ | - | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | - |
| canadacentral | - | - | - | ✅ | - | - | - | ✅ | - | ✅ |
| canadaeast | ✅ | - | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | - |
| eastus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| eastus2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| francecentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | - | ✅ |
| germanywestcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - |
| 日本东部 | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | - | - | ✅ |
| koreacentral | ✅ | ✅ | ✅ | ✅ | - | - | ✅ | ✅ | ✅ | - |
| northcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| norwayeast | ✅ | - | ✅ | ✅ | - | ✅ | - | ✅ | - | - |
| polandcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| southafricanorth | ✅ | - | - | ✅ | ✅ | - | ✅ | ✅ | ✅ | - |
| southcentralus | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| southindia | ✅ | - | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| 瑞典中部 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 瑞士北部 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| switzerlandwest | - | - | - | - | - | - | - | - | - | ✅ |
| uaenorth | ✅ | - | - | - | ✅ | - | - | - | ✅ | ✅ |
| uksouth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| westus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| westus3 | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
注意
gpt-4 版本： turbo-2024-04-09 的预配版本当前仅限于文本。