部署
在快节奏的技术环境中，大型语言模型（LLM）的使用正在迅速扩展。因此，开发人员了解如何在生产环境中有效部署这些模型至关重要。LLM 接口通常分为以下两类：
情况 1：利用外部 LLM 提供商（OpenAI，Anthropic 等） 在这种情况下，LLM 提供商处理大部分计算负担，而 LangChain 简化了围绕这些服务实现业务逻辑的过程。此方法包括提示模板化、聊天消息生成、缓存、向量嵌入数据库创建、预处理等功能。
情况 2：自助托管开源模型 或者，开发人员可以选择使用更小但功能相当的自助托管开源 LLM 模型。这种方法可以显著降低与将数据传输到外部 LLM 提供商相关的成本、延迟和隐私问题。
无论构建您的产品的框架如何，部署 LLM 应用程序都具有自己的挑战。在评估服务框架时，了解权衡和关键考虑因素非常重要。
大纲
本指南旨在全面介绍在生产环境中部署 LLM 的要求，重点关注以下内容：
- 设计强大的 LLM 应用程序服务
- 维持成本效益
- 确保快速迭代
在评估服务系统时，理解这些组件非常重要。LangChain 与几个旨在解决这些问题的开源项目集成在一起，为您的 LLM 应用程序提供了一个强大的框架。一些值得注意的框架包括：
这些链接将提供有关每个生态系统的更多信息，帮助您找到最适合您的 LLM 部署需求的解决方案。
设计强大的 LLM 应用程序服务
在生产环境中部署 LLM 服务时，提供无故障的无缝用户体验至关重要。实现全天候的服务可用性涉及创建和维护围绕应用程序的多个子系统。
监控
监控是在在生产环境中运行的任何系统的重要组成部分。在 LLM 的上下文中，监控性能和质量指标都至关重要。
性能指标： 这些指标提供有关模型效率和容量的见解。以下是一些关键示例：
- 每秒查询数（QPS）：这是衡量模型每秒处理的查询数，提供有关其利用率的见解。
- 延迟：此指标量化客户端发送请求到接收响应之间的延迟。
- 每秒标记数（TPS）：表示模型每秒可以生成的标记数。
质量指标： 这些指标通常根据业务用例进行定制。例如，您的系统输出与基线（例如先前版本）相比如何？尽管这些指标可以离线计算，但您需要记录必要的数据以后续使用它们。
容错
您的应用程序可能会遇到错误，例如模型推断或业务逻辑代码中的异常，导致失败并中断流量。其他潜在问题可能来自运行应用程序的机器，例如意外的硬件故障或高需求时的实例丢失。通过增加副本扩展和为失败的副本实施恢复机制，可以减轻这些风险。然而，模型副本并非唯一可能的故障点。构建针对堆栈中任何时刻可能出现的各种故障的弹性非常重要。
零停机升级
系统升级通常是必要的，但如果处理不当可能会导致服务中断。防止升级期间的停机的一种方法是实施从旧版本到新版本的平滑过渡过程。理想情况下，您的 LLM 服务的新版本部署，并且流量逐渐从旧版本转移到新版本，在整个过程中保持恒定的 QPS。
负载均衡
负载均衡简单来说是一种技术，用于将工作均匀分配到多台计算机，服务器或其他资源上，以优化系统的利用率，最大化吞吐量，最小化响应时间，并避免任何单一资源的过载。可以将其视为交通警察将汽车（请求）引导到不同的道路（服务器），以使任何一条道路不会过于拥挤。
有几种负载均衡策略。例如，一种常见的方法是 轮询 策略，其中每个请求都发送到下一个服务器，当所有服务器都收到请求时，循环回到第一个服务器。当所有服务器的能力相等时，这种方法效果良好。但是，如果某些服务器比其他服务器更强大，则可以使用 加权轮询 或 最小连接 策略，将更多请求发送到更强大的服务器，或发送到当前处理最少活动请求的服务器。假设您正在运行一个 LLM 链。如果您的应用程序变得流行起来，可能会有数百甚至数千个用户同时提问。如果一个服务器过于繁忙（负载高），负载均衡器将将新请求引导到另一个负载较轻的服务器。这样，所有用户都能够及时获得响应，系统保持稳定。
维持成本效益和可扩展性
部署 LLM 服务可能成本高昂，特别是当您处理大量用户交互时。LLM 提供商的收费通常基于使用的标记数，使得在这些模型上进行聊天系统推理可能很昂贵。然而，有几种策略可以帮助管理这些成本而不影响服务的质量。
自助托管模型
出现了几个较小和开源的 LLM 模型来解决对 LLM 提供商依赖的问题。自助托管允许您在管理成本的同时保持与 LLM 提供商模型类似的质量。挑战在于在您自己的机器上构建一个可靠的高性能 LLM 服务系统。
资源管理和自动伸缩
应用程序内的计算逻辑需要精确的资源分配。例如，如果部分流量由 OpenAI 端点提供，另一部分由自助托管模型提供，为每个部分分配合适的资源至关重要。自动伸缩 - 根据流量调整资源分配 - 可显著影响运行应用程序的成本。这种策略需要在成本和响应能力之间保持平衡，确保既不过度提供资源，也不会影响应用程序的响应能力。
利用抢占式实例
在 AWS 等平台上，抢占式实例提供了大量的成本节省，通常价格约为按需实例的三分之一。这种权衡是更高的崩溃率，因此需要建立一个强大的容错机制以实现有效的使用。
独立扩展
自主托管模型时，您应该考虑独立缩放。例如，如果您有两个翻译模型，一个针对法语进行了微调，另一个针对西班牙语进行了微调，那么传入的请求可能需要对每个模型进行不同的缩放要求。
批处理请求
在大型语言模型的背景下，批处理请求可以通过更好地利用 GPU 资源来提高效率。GPU 是并行处理器，设计用于同时处理多个任务。如果将单独的请求发送到模型，GPU 可能无法充分利用，因为它只能一次处理一个任务。另一方面，通过将请求批处理在一起，您可以允许 GPU 同时处理多个任务，最大限度地利用它并提高推理速度。这不仅可以节省成本，还可以提高 LLM 服务的整体延迟。
总之，在扩展 LLM 服务的同时管理成本需要采用战略方法。使用自主托管模型、有效管理资源、使用自动扩缩、使用竞价实例、独立缩放模型以及批处理请求是需要考虑的关键策略。Ray Serve 和 BentoML 等开源库可以用于处理这些复杂性。
确保快速迭代
LLM 领域正以前所未有的速度发展，不断引入新的库和模型架构。因此，避免将自己局限于特定框架的解决方案至关重要。这在服务端尤其相关，因为对基础架构的更改可能耗时、昂贵且具有风险。应追求不锁定在任何特定机器学习库或框架上的基础架构，而是提供通用、可扩展的服务层。以下是柔性发挥关键作用的一些方面：
模型组合
部署像 LangChain 这样的系统需要能够将不同的模型拼接在一起，并通过逻辑连接它们。以构建自然语言输入 SQL 查询引擎为例。查询 LLM 并获取 SQL 命令只是系统的一部分。您需要从连接的数据库中提取元数据，为 LLM 构建提示，使用引擎运行 SQL 查询，随着查询运行收集和反馈响应，并向用户呈现结果。这说明了将 Python 中构建的各种复杂组件无缝集成到动态逻辑块链中的需求，这些块链可以一起提供服务。
云服务提供商
许多托管解决方案仅限于单个云提供商，这可能会限制您在当今多云世界中的选择。根据您的其他基础架构组件建立的位置，您可能更喜欢坚持使用您选择的云提供商。
基础架构即代码（IaC）
快速迭代还涉及能够快速可靠地重新创建基础架构。这就是基础架构即代码（IaC）工具（如 Terraform、CloudFormation 或 Kubernetes YAML 文件）的作用。它们允许您在代码文件中定义基础架构，这些文件可以进行版本控制并快速部署，从而实现更快、更可靠的迭代。
CI/CD
在快节奏的环境中，实施 CI/CD 流水线可以显著加快迭代过程。它们有助于自动化 LLM 应用程序的测试和部署，减少错误风险，并实现更快的反馈和迭代。