生产环境中部署大语言模型：分步指南
从成功的演示到可靠、可扩展且经济高效的大语言模型（LLM）应用，这一过程中充满了演示阶段从未暴露的挑战：意外的用户输入、性能瓶颈、级联系统故障以及不断攀升的成本。本指南提供了一个全面的分步框架，帮助您应对这些复杂性，构建一个生产级的大语言模型系统。
您将学到什么
通过本指南，您将了解部署大语言模型的端到端生命周期，从选择合适的模型和基础设施，到实施稳健的测试、监控和安全实践。您将获得一份清晰、可操作的行动计划，将您的 LLM 项目从原型转变为可靠、高性能的生产服务，特别关注基于 Kubernetes 部署的关键步骤。
第一步：基础——模型选择与基础设施规划
在编写任何代码之前，您必须就模型及其运行的基础设施做出关键决策。这一初始规划阶段对于避免日后代价高昂的重构至关重要。
选择模型和硬件
开源模型世界广阔无垠，选择合适的模型是第一个重大障碍。不要猜测；使用精选模型中心。 像 Google Cloud 的 Vertex AI Model Garden 这样的云服务提供商提供了一个集中式仓库，包含 200 多个经过验证的模型（包括 Gemma、Qwen 和 Llama），并附有关键信息，例如实现最佳性能的推荐硬件（GPU 类型和大小）。这消除了仅为运行单个测试而设置环境的耗时过程。您通常可以找到使用优化服务容器（例如利用 vLLM 或 SGLang 的容器）的“一键部署”选项。
对于硬件，模型的规模直接决定了您的 GPU 需求。以下是基于 DigitalOcean 等提供商常见 GPU 选项的通用指南：
| GPU 类型 | 典型用例 | 适用模型大小 |
|---|---|---|
| RTX 4000 Ada | 经济高效的推理 | 较小模型（7B-13B 参数） |
| RTX 6000 Ada | 均衡性能 | 中等模型（13B-34B 参数） |
| L40S | 大规模工作负载的最大性能 | 大型模型（70B+ 参数） |
⚠️ 模型访问警告： 许多流行模型，例如 Meta 的 Llama，要求您拥有 HuggingFace 帐户、请求访问权限并接受许可协议，然后才能下载。请务必将此审批时间纳入您的项目时间表。
Google AdInline article slot
选择基础设施：Kubernetes 标准
对于生产级 LLM 部署，Kubernetes 已成为事实上的标准。它提供了管理复杂、资源密集型工作负载所必需的可扩展性、弹性和云原生工具。无论您使用的是托管 Kubernetes 服务（如 Google Kubernetes Engine (GKE)、Amazon EKS 或 DigitalOcean Kubernetes (DOKS)），其原则都是相同的：
- GPU 支持： 您的 Kubernetes 集群必须具有 GPU 节点。这涉及安装 NVIDIA 设备插件，以使 GPU 可用于您的 Pod。
- 调度： 对于多节点部署，可以使用像 Volcano 这样的高级调度器进行“组调度”，确保分布式训练或推理作业的所有 Pod 同时启动。
第二步：核心部署——服务您的模型
下载权重并纠结于 requirements.txt 的“老方法”在生产环境中是不可行的。您需要一个稳健、高性能的服务框架。
vLLM 生产栈
vLLM 已成为领先的开源 LLM 推理引擎。其生产栈源自伯克利-芝加哥大学的合作，封装了上游 vLLM，提供了一个针对生产优化的代码库，旨在易于使用和高性能。关键特性包括多模型支持、模型感知路由和 KV 缓存卸载。
要在您的 Kubernetes 集群上部署 vLLM 生产栈：
- 确保您已在 GPU 服务器上安装 Helm。Helm 是 Kubernetes 的包管理器。
- 添加 vLLM Helm 仓库：
sudo helm repo add vllm https://vllm-project.github.io/production-stack - 安装 Chart：
sudo helm install vllm vllm/vllm-stack -f tutorials/assets/values-01-minimal-example.yamlfacebook/opt-125m）作为概念验证。
部署的核心配置通过一个 YAML 文件进行管理，您可以在其中指定模型 URL、副本数量以及 CPU、内存和 GPU 的资源请求。
验证部署
安装后，监控状态：
sudo kubectl get pods等待直到所有 Pod 显示 Running 状态。这可能需要一些时间，因为 Docker 镜像和模型权重正在下载。
查询服务
运行后，您可以转发本地端口并查询兼容 OpenAI 的 API 端点：
sudo kubectl port-forward svc/vllm-router-service 30080:80
curl -o- http://localhost:30080/v1/models这将验证您的模型服务栈是否正常运行。
第三步：高级架构与优化
对于真正可扩展、生产就绪的系统，您需要超越单个模型实例。现代框架将推理过程分解，以获得更好的性能和资源利用率。
使用 llm-d 进行分解推理
llm-d 是一个分布式推理框架，它将 LLM 推理管道分为两个不同的阶段：预填充（上下文处理）和解码（令牌生成）。这使得每个阶段可以独立优化和扩展，从而实现更高的吞吐量和更好的 GPU 利用率。
要在 Kubernetes 上部署分解系统，可以使用像 Kthena 这样的专用操作器来管理这些复杂分布式工作负载的生命周期和调度。Kthena 提供了一个 ModelServing 自定义资源定义（CRD），用于声明式地部署多节点 vLLM 服务，并利用 Volcano 进行组调度。该过程包括：
- 在您的集群中安装 Volcano 和 Kthena。
- 应用一个
ModelServing清单，该清单定义了用于预填充和解码角色的入口（领导者）和工作 Pod。 - 操作器编排这些 Pod，然后它们使用 Ray 形成一个分布式集群。
这种方法非常适合大规模、高吞吐量、低延迟的应用，但它也引入了显著的运营复杂性。
第四步：生产思维——可靠性、可观测性与安全性
一旦您的 LLM 开始服务，真正的工作就开始了。进入生产环境需要思维方式的重大转变，从“让它工作”转变为“保持它工作”。
为现实进行测试
演示的顺利路径并非生产现实。您必须采用系统化的测试策略：
- 鲁棒性测试： LLM 出奇地脆弱。输入的微小变化可能导致输出的重大转变。系统化评估模型在各种扰动下行为的自动化测试框架至关重要。
- 黄金数据集： 创建一个包含代表性用户查询和预期输出的“黄金数据集”。这是自动化评估的基础。在部署之前，应针对此数据集对新模型版本或提示更改进行基准测试。没有它就不要发布。
- RAG 评估： 如果您使用检索增强生成（RAG），不仅要评估最终答案，还要使用上下文精确度和召回率等指标评估检索质量。
实施生产清单
生产清单是保持纪律的重要工具。关键项目包括：
- 客户端规范： 设置超时、使用抖动实现重试，并为重试操作使用幂等键。
- 服务器设置： 对每个用户实施严格的令牌感知速率限制。根据实际业务需求（而非模型的最大值）设置上下文和输出上限。
- 可靠性模式： 使用健康检查探针、熔断器和优雅关闭。进行故障演练（例如，模拟内存不足错误），以确保您的系统按预期恢复。
衡量用户感知
可观测性是不可协商的。跟踪直接影响用户体验的指标：
- 首令牌时间（TTFT） 和 每秒令牌数（TPS）：感知速度的关键指标。目标是将 TTFT 的第 95 百分位值控制在 ≤800 毫秒。
- 队列长度和 GPU 内存余量： 监控这些指标以防止过载并优化资源使用。
- 按类型划分的错误率： 区分 OOM 错误、超时和客户端错误。
安全与成本
- 安全： 在所有地方强制执行 TLS，使用每服务 API 密钥，并且默认情况下不要记录原始提示。
- 成本： 将令牌视为有限资源。监控每个功能和每个租户的令牌消耗，并积极缓存响应。对于更简单的任务，使用更小、更高效的模型以降低成本。
来源
- vLLM 生产栈文档： 关于使用 Helm Charts 在 Kubernetes 上部署 vLLM 以及理解其配置的来源。
- Etiq AI – 生产 LLM 系统： 关于鲁棒性测试、RAG 评估和“生产现实”原则的来源。
- DigitalOcean – 在 Kubernetes 上部署 llm-d： 关于在 Kubernetes 上部署分布式 LLM 推理和 GPU 选择的实际步骤的来源。
- Google Cloud 博客 – Vertex AI 开源模型指南： 关于在托管平台上进行模型发现、微调和优化服务的来源。
- vLLM Kthena 文档： 关于使用 Kthena 和 Volcano 部署多节点 vLLM 服务的来源。
- Hivenet – LLM API 生产清单： 关于涵盖客户端规范、服务器设置、可靠性和监控的实用清单的来源。
- Deepchecks – 团队如何实施 LLMOps？： 关于 LLMOps 参考架构、实施阶段和运营最佳实践来源。
— Editorial Team
暂无评论。