扩展你的解决方案架构
当为使用我们API的生产应用程序或服务设计时，考虑如何扩展以满足流量需求非常重要。无论您选择哪个云服务提供商，都需要考虑以下几个关键领域：
-
水平扩展：您可能希望水平扩展应用程序以适应来自多个来源的请求。这可能涉及部署其他服务器或容器以分配负载。如果选择此类型的扩展，请确保您的架构设计能够处理多个节点，并且已经采取了机制来在它们之间平衡负载。
-
垂直扩展：另一种选择是垂直扩展应用程序，这意味着可以增加单个节点可用资源。这将涉及升级服务器的功能以处理额外负载。如果选择此类型的缩放，请确保您的应用程序被设计为利用这些额外资源。
-
缓存：通过存储频繁访问数据，可以提高响应时间，而无需重复调用API。您的应用程序需要被设计为尽可能使用缓存数据，并在添加新信息时使缓存失效。有几种不同方法可以做到这一点。例如，根据对于你的应用最合理方式，你可以将数据存储在数据库、文件系统或内存中进行缓存。
-
负载均衡：最后，请考虑使用负载均衡技术来确保请求均匀地分布在可用服务器上。这可能涉及使用一个负载均衡器作为服务器前端或使用DNS轮询算法等方式实现 。平衡负载将有助于提高性能并减少瓶颈。
管理速率限制
在使用我们的API时，了解和规划速率限制非常重要。
改善延迟
延迟是请求被处理并返回响应所需的时间。在本节中，我们将讨论一些影响文本生成模型延迟的因素，并提供有关如何减少延迟的建议。
完成请求的延迟主要受两个因素影响：模型和生成的标记数。完成请求的生命周期如下：
网络 最终用户到API的延迟 $\downarrow$ 服务器 处理提示令牌所需时间 $\downarrow$ 服务器 采样/生成令牌所需时间 $\downarrow$ 网络 API到最终用户的延迟
大部分的延迟通常来自令牌生成步骤。
直觉：提示令牌对完成调用的延迟影响很小。生成完成令牌所需的时间要长得多，因为每次只生成一个令牌。较长的生成长度会累积延迟，因为需要为每个令牌进行生成。
影响延迟的常见因素和可能的缓解技术
现在我们已经了解了延迟的基础知识，让我们来看一下各种影响延迟的因素，从最具影响力到最不具影响力进行广泛排序。
模型
我们的API提供不同复杂度和普适性水平的模型。最强大的模型，例如gpt-4，可以生成更复杂和多样化的完成结果，但处理查询所需时间也更长。像gpt-3.5-turbo这样的模型可以生成更快速、更便宜的聊天完成结果，但可能会产生与您查询不太准确或相关的结果。您可以选择最适合您用例以及在速度和质量之间权衡取舍的模型。
完成令牌数量
请求大量生成的完成令牌可能会导致延迟增加：
-
降低最大令牌数：对于具有相似的令牌生成计数的请求，那些具有较低
max_tokens参数的请求会产生更少的延迟。 -
包括停止序列：为了防止生成不必要的标记，请添加一个停止序列。例如，您可以使用停止序列来生成一个特定数量项目的列表。在这种情况下，通过使用
11.作为停止序列，您可以只生成10个项目的列表，因为当到达11.时完成将停止。请阅读我们关于停止序列帮助文章以获取更多上下文信息。 -
减少完成次数：尽可能降低
n和best_of值，在此处n是指每个提示要生成多少个完成项，并且best_of用于表示每个标记中具有最高对数概率结果。
如果n和best_of都等于1（这是默认值），生成的标记数量最多为max_tokens。
如果n（返回的完成数）或best_of（用于考虑生成的完成数）设置为> 1，则每个请求将创建多个输出。在这里，您可以将生成的标记数量视为[max_tokens * max(n, best_of)]
流式传输
在请求中设置stream: true会使模型尽快返回可用的令牌，而不是等待生成完整的令牌序列。它不会改变获取所有令牌所需的时间，但可以减少第一个令牌的时间，适用于需要显示部分进度或将停止生成的应用程序。这可以提供更好的用户体验和UX改进，因此值得尝试流式传输。
基础设施
我们的服务器目前位于美国。虽然我们希望未来能够实现全球冗余，但在此期间，您可以考虑将基础设施的相关部分放置在美国，以最小化您的服务器和OpenAI服务器之间的往返时间。
批处理
根据您的使用情况，批处理可能会有所帮助。如果您要向同一端点发送多个请求，则可以将提示批量发送到同一请求中。这将减少您需要进行的请求数量。提示参数最多可以容纳20个唯一的提示。我们建议您测试此方法并查看是否有所帮助。在某些情况下，您可能会增加生成令牌的数量，从而降低响应时间。
管理成本
为了监控您的成本，您可以在账户中设置一个软限制，一旦超过某个使用阈值就会收到电子邮件警报。您还可以设置硬限制。请注意，硬限制可能会对应用程序/用户造成干扰，请谨慎使用。使用使用跟踪仪表板来监视当前和过去计费周期内的令牌使用情况。
文本生成
将原型转化为生产应用的挑战之一是预算运行应用程序所需的成本。OpenAI 提供按使用量计费的定价模式，每 1,000 个标记（大约相当于 750 字）收取一定价格。要估算您的成本，您需要预测标记利用率。考虑因素包括流量水平、用户与应用程序交互频率以及您将处理的数据量。
一个有用的框架来思考降低成本是将成本视为标记数量和每个标记的成本函数。使用此框架可以通过两种潜在途径降低成本。首先，您可以尝试通过切换到较小模型来减少某些任务中每个令牌的成本以降低成本。或者，您可以尝试减少所需令牌数目。有几种方法可以做到这一点，例如使用更短提示、微调模型或缓存常见用户查询以避免重复处理。
你可以尝试我们交互式分词工具来帮助你估算费用。API 和 playground 还会返回 token 计数作为响应的一部分。一旦你已经成功地使用了我们最强大的模型，请查看其他模型是否能够以更低延迟和更低费用产生相同的结果。在我们的标记使用帮助文章中了解更多信息。
MLOps策略
当您将原型转移到生产环境时，您可能需要考虑开发MLOps策略。 MLOps（机器学习运营）是指管理机器学习模型的端到端生命周期的过程，包括使用我们的API进行微调的任何模型。 设计MLOps策略时需要考虑许多方面，其中包括：
- 数据和模型管理：管理用于训练或微调模型的数据，并跟踪版本和更改。
- 模型监控：随着时间推移跟踪您的模型性能并检测任何潜在问题或退化。
- 重新训练模型：确保您的模型与数据变化或不断发展的要求保持最新，并根据需要重新训练或微调它。
- 部署模型：自动化部署您的模型及相关工件到生产环境中。
思考应用程序中这些方面将有助于确保您的模型随着时间推移保持相关且表现良好。
安全和合规性
当您将原型转移到生产环境时，您需要评估并解决可能适用于应用程序的任何安全和合规要求。这将涉及检查您正在处理的数据，了解我们的API如何处理数据，并确定您必须遵守哪些法规。供参考，这是我们的隐私政策和使用条款。
一些常见的考虑因素包括数据存储、数据传输和数据保留。在可能情况下，您还可能需要实施数据隐私保护措施，例如加密或匿名化。此外，您应该遵循安全编码的最佳实践，例如输入过滤和正确错误处理等方面。
安全最佳实践
在使用我们的API创建应用程序时，请考虑我们的安全最佳实践，以确保您的应用程序是安全和成功的。这些建议强调了广泛测试产品、积极解决潜在问题以及限制误用机会的重要性。