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