你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

性能和延迟

项目
09/20/2024

本文将提供有关 Azure OpenAI 中延迟和吞吐量的工作原理以及如何优化环境以提高性能的背景信息。

了解吞吐量与延迟

在调整应用程序大小时，需要考虑两个关键概念：(1) 系统级别吞吐量和 (2) 每个调用响应时间（也称为延迟）。

系统级吞吐量

这将查看部署的总体容量 - 每分钟请求数和可处理的标记总数。

对于标准部署，分配给部署的配额部分决定了可以实现的吞吐量。但配额仅确定对部署进行调用的允许逻辑，并且不会直接强制实施吞吐量。由于每调用延迟的变化，可能无法达到与配额一样高的吞吐量。详细了解如何管理配额。

在预配的部署中，会将一组模型处理容量分配给终结点。可以在终结点上实现的吞吐量是输入大小、输出大小、调用速率和缓存匹配率的一个因素。所处理的并发调用数和标记总数可能因这些值而异。以下步骤逐步介绍如何评估预配部署中获取给定工作负载的吞吐量：

使用容量计算器进行大小调整估算。
使用实际流量工作负载对负载进行基准测试。测量 Azure Monitor 中处理指标的利用率和标记。延长运行时间。 Azure OpenAI 基准测试存储库包含用于运行基准的代码。最后，最准确的方法是使用自己的数据和工作负载特征运行测试。

下面是 GPT-4 0613 模型的几个示例：

提示大小（标记数）	生成大小（标记数）	每分钟调用数	需要 PTU
800	150	30	100
1000	50	300	700
5000	100	50	600

当工作负载分布保持不变时，PTU 数大致岁调用速率线性缩放（可能是子线性）。

延迟：每调用响应时间

此上下文中的延迟的概括性定义是从模型获取响应所需的时间。对于补全和聊天补全请求，延迟主要取决于模型类型、提示中的标记数和生成的标记数。通常，与生成的每个增量标记相比，每个提示标记会增加很少的时间。

估算每个调用的预期延迟对于这些模型来说可能很困难。补全请求的延迟可能因四个主要因素而异：(1) 模型、(2) 提示中标记数、(3) 生成的标记数，以及 (4) 部署和系统上的总体负载。其中第一项和第三项通常是总时间的主要因素。下一部分将更详细地分析大语言模型推理调用。

提高性能

可以通过控制多种因素来提高应用程序的每调用延迟。

模型选择

延迟将会因所使用的模型而异。对于相同的请求，不同的模型对聊天补全调用应会具有不同的延迟。如果你的用例需要具有最快响应时间的最低延迟模型，我们建议使用最新的 GPT-4o mini 模型。

生成大小和最大标记数

当你向 Azure OpenAI 终结点发送补全请求时，你的输入文本将转换为标记，然后发送到已部署的模型。模型会接收输入标记，然后开始生成响应。它是一个迭代、按顺序的过程，一次一个标记。另一种理解的方式是将它看作使用 n tokens = n iterations 的 for 循环。对于大多数模型，生成响应是过程中最慢的步骤。

在请求时，请求的生成大小（max_tokens 参数）将用作生成大小的初始估计值。在处理请求时，模型会预留生成完整大小的计算时间。生成完成后，将释放剩余配额。减少令牌数量的方法：

将每次调用的 max_tokens 参数设置得尽可能小。
包括停止序列以防止生成额外内容。
生成较少的响应：best_of 和 n 参数可能会大大增加延迟，因为它们会生成多个输出。对于最快的响应，请不要指定这些值或将其设置为 1。

总之，减少每个请求生成的标记数可以减少每个请求的延迟。

流式处理

在请求中设置 stream: true 将导致服务在标记可用后立即返回标记，而不是等待生成完整的标记序列。它不会更改获取所有标记的时间，但可以减少首次响应的时间。此方法可提供更好的用户体验，因为最终用户可以在生成响应时读取响应。

流式处理对于需要很长时间进行处理的大型调用也很有用。许多客户端和中间层在单个调用上会发生超时。由于客户端超时，可能会取消长时间的生成调用。通过将数据流式传输返回，可以确保接收增量数据。

关于何时使用流式处理的示例：

聊天机器人和对话接口。

流式处理会影响感知延迟。如果已启用流式传输，则只要标记可用，就会按区块接回标记。对于最终用户来说，此方法通常会让人感觉模型的响应速度变快了，即使完成请求的总体时间保持不变。

流式处理不那么重要的情况示例：

情绪分析、语言翻译、内容生成。

在许多执行批量任务的用例中，你只关心已完成的结果，而不关心实时响应。如果禁用流式处理，则在模型完成整个响应之前，你不会收到任何标记。

内容筛选

Azure OpenAI 包含一个适配核心模型的内容筛选系统。该系统通过一系列分类模型来运行提示和补全，旨在检测和防止有害内容的输出。

内容筛选系统会在输入提示和输出补全中检测特定类别的潜在有害内容并对其采取措施。

配备内容筛选功能会增加安全性，但也会增加延迟。在许多应用程序中，这种对性能的权衡是有必要的，但在某些低风险的用例中，禁用内容筛选器以提高性能的做法可能也值得探索。

详细了解如何请求对默认内容筛选策略进行修改。

工作负载分离

在同一终结点上混合不同的工作负载可能会对延迟产生不利影响。这是因为 (1) 它们在推理期间分批，并且短时调用可以等待较长时间的补全，(2) 混合调用可以减少缓存命中率，因为它们会争用相同的空间。如果可能，建议为每个工作负载进行单独部署。

提示大小

虽然提示大小对延迟的影响小于生成大小，但它会影响总体时间，尤其是在大小增大时。

批处理

如果要将多个请求发送到同一终结点，可以将请求批处理到单个调用中。这减少了需要发出的请求数，并且基于该情况，它可能会改善总体响应时间。建议测试此方法，已确定此方法是否有用。

如何测量吞吐量

建议使用两个度量值测量部署的总体吞吐量：

每分钟调用数：每分钟发出的 API 推理调用数。可以使用 Azure OpenAI 请求数指标和按 ModelDeploymentName 拆分在 Azure Monitor 中度量此值
每分钟标记总数：部署每分钟处理的标记总数。这包括提示标记和生成的标记。这通常会进一步拆分为同时测量两者，以便更深入地了解部署性能。这可以在 Azure Monitor 中使用处理的推理标记数指标进行度量。

可以详细了解监视 Azure OpenAI 服务。

如何度量每调用延迟

每次调用所需的时间取决于读取模型、生成输出和应用内容筛选器所需的时间。测量时间的方法将会因是否使用流式传输而不同。我们建议针对每个用例使用不同的度量值集。