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