延迟优化
本指南涵盖了您可以应用的核心原则，以在各种 LLM 相关用例中改善延迟。这些技巧源于与广泛的客户和开发人员合作在生产应用程序上，因此它们应该无论您正在构建什么都适用——从粒度工作流到端到端聊天机器人！
七个原则
- 更快地处理令牌。
- 生成较少的令牌。
- 使用较少的输入令牌。
- 做更少的请求。
- 并行化。
- 让您的用户等待的时间更少。
- 不要将 LLM 作为默认选择。
示例
我们将通过一个示例来了解如何应用这些原则。
体系结构和提示
以下是一个假想的客户服务机器人的初始体系结构。这是我们将要进行更改的内容。
在高级别上，流程图描述了以下过程：
- 用户在正在进行的对话中发送消息。
- 将最后一条消息转换为自包含的查询（参见提示中的示例）。
- 我们确定是否需要其他（检索到的）信息来回答该查询。
- 执行检索，产生搜索结果。
- 助手推理用户的查询和搜索结果，并产生响应。
- 将响应发送回用户。
下面是流程图中使用的提示。虽然它们仍然只是假想的和简化的，但它们是用与生产应用程序中所找到的相同的结构和词汇编写的。
分析和优化
第 1 部分：查看检索提示
体系结构中最突出的是连续的 GPT-4 调用，这表明存在潜在的不效率。在这种情况下，由于检索检查需要上下文查询，我们可以将它们合并为一个提示，以进行更少的请求。
第 2 部分：分析助手提示
似乎助手在填充 JSON 字段时发生了许多不同的步骤，这可能表明并行化的机会。但是，让我们假装我们已经进行了一些测试，并发现将 JSON 中的推理步骤拆分会导致更差的响应。
我们可以使用经过微调的 GPT-3.5 代替 GPT-4 进行助手，但是助手的开放式回答最好留给 GPT-4，因此它可以更好地处理更广泛的情况。但是，推理步骤的良好定义和有限范围的性质使其成为经过微调的潜在候选者。
第 3 部分：优化结构化输出
仔细查看推理 JSON，我们注意到字段名本身是相当长的。通过使它们更短并将解释移动到注释中，我们可以生成更少的令牌。
示例总结
我们已经为客户服务机器人示例实施了以下优化：
- 将查询上下文化和检索检查步骤合并，以进行更少的请求。
- 为新提示切换到更小的经过微调的 GPT-3.5，以更快地处理令牌。
- 将助手提示拆分为两个，为推理切换到更小的经过微调的 GPT-3.5，再次以更快地处理令牌。
- 并行化了检索检查和推理步骤。
- 缩短了推理字段名并将注释移动到提示中，以生成更少的令牌。
结论
您现在应该熟悉了可以应用于改善 LLM 应用程序延迟的核心原则。当您探索这些技术时，请始终记住测量延迟来自何处并测试试用每个解决方案的影响。现在，去让您的应用程序飞一般吧！