部署LLM应用需要决定它将在哪里以及如何运行,这一步骤通常在应用打包(通常在容器中)之后进行。选择正确的部署策略对于确保您的应用可用、可伸缩、可靠且具有成本效益十分重要。没有一个唯一的“最佳”方式;最合适的选择很大程度上取决于您的应用需求、团队能力以及运维要求。
我们来看一下您在Python LLM应用中可能考虑的常见部署模式。
虚拟机 (VMs)
虚拟机提供一个完整的操作系统环境,运行在共享或专用的物理硬件上。例如Amazon EC2、Google Compute Engine或Azure Virtual Machines等服务。
- 优点:
- 完全控制权: 您拥有根权限,可以完全控制操作系统、依赖项和配置。
- 灵活性: 适用于几乎所有工作负载,包括有状态应用、长时间运行的进程(如模型微调或批处理),以及需要特定硬件(如高性能GPU)的应用。
- 成熟技术: 被广泛理解,拥有丰富的文档和工具。
- 缺点:
- 手动管理: 您需要负责操作系统补丁、安全更新、软件安装和配置。
- 伸缩性: 伸缩通常需要手动干预或配置自动伸缩组,这增加了复杂性。
- 资源利用率: 只要VM在运行,即使您的应用没有主动处理请求,您也需要付费,这对于偶发性工作负载来说效率不高。
VMs通常是一个不错的起点,特别是对于开发、测试,或具有可预测负载或需要其他平台不易满足的特定硬件的应用。
容器编排平台
如果您已使用Docker(如前所述)将应用容器化,那么Kubernetes (K8s) 或Docker Swarm等平台可以大规模管理这些容器。它们负责处理跨机器集群(节点)的容器化应用的部署、伸缩、负载均衡和健康监测。
- 优点:
- 伸缩性与弹性: 具有出色的能力,可根据负载进行自动伸缩和自我修复(替换失败的容器)。
- 可移植性: Kubernetes可在所有主要云提供商上使用,并可本地部署,在不同环境间提供一致性。
- 资源使用效率: 与每个VM运行一个应用相比,能更好地将资源封装到节点上。
- 缺点:
- 复杂性: 尤其是Kubernetes,学习曲线陡峭,运维开销较大。管理集群需要专业知识。
- 资源开销: 控制平面和代理程序会占用集群节点上的资源。
容器编排非常适合需要高可用性和动态伸缩的生产应用,特别是如果您的团队拥有相关专业知识,或使用托管的Kubernetes服务(如EKS、GKE、AKS)来抽象部分底层复杂性。
平台即服务 (PaaS)
PaaS提供商提供一个环境,您只需部署代码,平台就负责处理底层基础设施、操作系统、补丁以及通常的伸缩。例子包括Heroku、Google App Engine、Azure App Service和AWS Elastic Beanstalk。
- 优点:
- 简化部署: 通常只需推送代码仓库;平台负责构建和部署应用。
- 托管基础设施: 显著减少运维负担。
- 集成服务: 易于与其他平台服务(如数据库和缓存)集成。
- 缺点:
- 控制较少: 您对底层操作系统拥有有限或没有访问权限。
- 潜在锁定: 从特定PaaS提供商迁移可能更具挑战性。
- 平台限制: 可能对后台进程、硬件选择(有限的GPU选项)或特定语言/框架版本有限制。
PaaS是Web应用和API(包括许多LLM驱动的后端)的不错选择,尤其是在开发速度和减少运维开销是优先事项时。请检查特定PaaS提供商关于可能长时间运行的LLM推理的执行时间和资源可用性方面的限制。
无服务器函数 (函数即服务 - FaaS)
无服务器平台允许您以函数形式部署代码,这些函数响应事件(如HTTP请求)而执行。您无需管理任何服务器。例子包括AWS Lambda、Google Cloud Functions和Azure Functions。
- 优点:
- 按使用付费: 您只需为函数运行时消耗的执行时间和资源付费。对于流量可变或较低的应用来说,成本效益很高。
- 自动伸缩: 平台根据传入请求自动处理伸缩。
- 事件驱动: 天生适合事件驱动的架构。
- 缺点:
- 无状态: 函数通常是无状态的,意味着它们在调用之间不保留信息。状态必须在外部管理(例如,在数据库或缓存中)。
- 执行限制: 平台对执行持续时间、内存和部署包大小施加限制。这对于大型模型或非常长的推理时间可能是一个挑战。
- 冷启动: 当函数最近未被调用时(即“冷启动”),可能会增加延迟。这对于对延迟敏感的LLM应用来说可能无法接受。
- GPU访问: GPU支持通常有限或不可用。
FaaS非常适合LLM工作流中的特定任务:执行快速推理的简单API端点、处理由事件触发的异步任务(例如,处理上传文档以供RAG),或充当不同服务之间的连接器。复杂、有状态的RAG管道或需要大型模型的应用可能难以应对FaaS的限制。
托管模型服务平台
云提供商和专业公司提供专门用于部署和提供机器学习模型(包括LLM)的平台。例子包括AWS SageMaker Endpoints、Google Vertex AI Endpoints、Azure Machine Learning Endpoints,以及Hugging Face Inference Endpoints或Anyscale Endpoints等第三方服务。
- 优点:
- 为推理优化: 旨在处理模型加载、高效推理以及ML工作负载的伸缩。通常支持GPU。
- 简化部署: 提供专为部署ML模型量身定制的工具和SDK。
- 托管伸缩与监测: 包含自动伸缩和模型性能监测功能。
- 缺点:
- 成本: 可能比通用计算更昂贵,特别是如果利用率不高。
- 平台特定: 通常与特定的云提供商或供应商生态系统绑定。
- 抽象程度: 可能会抽象掉复杂、定制化且涉及多个步骤的LLM工作流所需的细节。
当主要目标是通过API端点提供LLM进行推理时,这些平台是很好的选择,特别是如果您需要优化性能、GPU加速和托管伸缩,而无需自行构建基础设施。
影响选择的因素
在这些选项之间做出选择涉及平衡多个因素:
- 伸缩需求:
- 低/可变流量: FaaS成本效益很高。PaaS也可能运行良好。
- 高/持续流量: Kubernetes、托管端点或配置良好的VMs/PaaS更适合。
- 性能要求:
- 低延迟: VMs、Kubernetes或托管端点通常提供最可预测的性能,避免FaaS冷启动。
- GPU加速: 通常需要VMs、Kubernetes(带GPU节点)或专业的托管端点。仔细检查PaaS/FaaS的GPU可用性。
- 工作流复杂性:
- 简单推理API: FaaS、PaaS或托管端点可能就足够了。
- 复杂链/代理/RAG: VMs或Kubernetes为多步骤流程、自定义依赖项和状态管理(例如,与应用一起运行向量数据库)提供更大的灵活性。
- 成本预算:
- 最大程度降低闲置成本: FaaS是理想选择。
- 可预测成本: 预留VMs或PaaS/Kubernetes/托管端点上的承诺使用可以提供可预测的定价。密切监测使用情况。
- 团队专业知识与运维承受能力:
- 高专业知识/承受能力: VMs或自管理Kubernetes提供最大的控制权。
- 较低专业知识/承受能力: PaaS、FaaS或托管服务(Kubernetes、端点)显著降低运维负担。
- 状态管理:
- 无状态: FaaS天然契合。
- 有状态: VMs、Kubernetes Pods(带持久卷)或PaaS实例通常更容易在其中管理状态。
一个基于应用需求选择部署策略的决策指南。根据您对问题的回答跟随箭头。
最终,选择往往涉及权衡。在开发和早期阶段,您可以从PaaS或VMs等更简单的方法开始,随着应用伸缩和成熟,可能会迁移到Kubernetes或托管端点。仔细评估这些因素与您的应用特点和团队情况,以做出明智的决定。