一、部署概述

本文要完成的核心部署任务是：将一个大语言模型（LLM）推理服务部署到生产环境，并为其建立完整的监控指标体系与持续优化闭环。部署完成后应达到三个效果：一是推理服务可被业务系统稳定调用，接口响应正常、流式输出顺畅；二是性能、资源、服务健康、输出质量四类指标可采集、可告警、可回溯；三是当性能或质量出现劣化时，团队有明确的排查路径与优化手段。

本文适合负责模型上线的开发者、SRE与运维工程师、平台架构师以及技术负责人阅读。

在开始部署前，需要理解LLM推理服务与传统无状态Web服务的三点差异。第一，计算密集，严重依赖GPU算力与显存，资源规划方式与普通应用完全不同；第二，请求耗时长且输出为逐Token生成的流式过程，首Token延迟与后续生成速度需要分开度量、分开优化；第三，输出质量高度依赖输入侧的prompt定义——同样的模型、同样的算力，prompt语义不完整就会导致业务结果偏差。这三点决定了部署时的资源估算、监控设计与排查思路。

二、部署场景

LLM推理服务部署通常适用于以下场景，不同场景对指标的侧重不同：

• 在线对话与助手类应用：如智能客服、领域助手。用户直接交互，首Token延迟和输出语义准确性是核心指标。
• 检索增强生成（RAG）类业务：模型基于检索结果作答，除推理指标外还需关注检索链路延迟与答案与原文的一致性。
• 后端批量文本处理：如摘要、分类、结构化抽取。对吞吐量敏感，对单请求延迟相对宽容。
• 内部平台集成：为多个业务线提供统一推理入口，需要按业务维度做指标隔离与配额管理。

三、架构与组件

一个生产级LLM推理服务的典型组件拆解如下：

层级	组件	作用
接入层	负载均衡、API网关、认证鉴权、限流	流量分发、访问控制、过载保护
推理层	GPU计算节点、推理服务进程	模型加载、批处理调度、KV Cache管理、流式输出
配置层	prompt模板与业务参数版本管理	将prompt作为部署资产统一管理、可回滚
监控层	指标采集、日志采集、链路追踪、告警通知	支撑四类指标的观测与异常发现
存储层	模型文件仓库、日志存储、评测数据存储	模型分发、日志回溯、质量回归基准

若选择在百度智能云等云平台上部署，可直接组合使用GPU云服务器、容器服务、负载均衡、对象存储、云监控、日志服务等通用云产品能力，减少自建基础设施的工作量；自建环境则需自行准备同等能力的组件。

四、关键监控指标体系

这是部署后能否”看得见、管得住”的关键，建议按四个维度建立指标体系。

4.1 性能指标

• 首Token延迟（TTFT）：从请求发出到首个Token返回的时间，直接决定用户感知的”响应快不快”。它受排队时间、输入预填充计算量、批处理策略共同影响。长输入请求的TTFT天然更高，应分位数（P50/P95/P99）统计并按输入长度分桶观察。
• 每输出Token延迟（TPOT）：流式输出过程中相邻Token的平均间隔，反映生成阶段的平稳程度。TPOT波动大会造成用户端”打字卡顿”的观感。
• 端到端延迟：完整返回全部内容的总耗时，由TTFT、输出Token数与TPOT共同决定。
• 吞吐量：每秒输出Token数与每秒处理请求数。需区分单请求吞吐与系统整体吞吐——整体吞吐可以靠批处理提升，但单请求延迟可能随之上升，二者需要按业务SLA权衡。

4.2 资源指标

• GPU利用率与显存占用：显存消耗 = 模型权重 + 激活值 + KV Cache。其中KV Cache随并发数与上下文长度增长，是显存溢出的主要来源，必须重点监控其水位与增长趋势。
• CPU、内存、网络带宽：输入输出处理、分词、调度逻辑运行在CPU侧，网络带宽影响流式输出体验，均需纳入采集。

4.3 服务健康指标

• QPS、当前并发数、排队长度：排队长度持续增长是容量不足的最早信号，比错误率先出现。
• 错误率、超时率、成功率：建议按模型版本、业务线、接口类型打标签分维度统计，便于快速定位劣化范围。

4.4 输出质量指标

性能指标全绿，不代表业务效果达标。技术资料中有一个典型案例：某房产助手应用中，用户输入”找附近的住宅房源”，模型返回了公寓、联排别墅和独栋住宅的混合结果，而该业务的用户实际只想看独栋住宅。排查后发现，问题既不在模型能力也不在算力，而在prompt中没有定义”住宅房源”这个词的业务含义；在prompt中补充一句”当用户说住宅房源时，默认指独栋住宅”，问题即修复。

这个案例对部署与监控的启示有三点：

1. 质量监控必须纳入指标体系：可采用线上抽样人工评估、业务规则校验（如输出类别是否符合预期枚举）、用户负反馈率统计、badcase归因等方式，将”答得对不对”量化。
2. prompt是部署资产的一部分：应纳入版本管理，与模型版本、服务配置一起可追溯、可回滚。质量问题的修复往往落在prompt层而非模型层。
3. 形成优化闭环：监控发现异常 → 归因（模型能力/算力瓶颈/prompt定义/检索质量）→ 修复 → 用固定评测集回归 → 灰度发布。缺少评测集回归环节，prompt修改容易引入新问题。

五、前置准备

部署前应完成以下清单：

1. 资源规格估算：显存 ≈ 模型权重（参数量 × 每参数字节数，16bit精度约为2字节/参数）+ KV Cache预留（并发数 × 上下文长度 × 每Token KV开销）+ 激活与系统开销。建议在估算值基础上预留20%～30%余量，避免上线后被迫降并发。
2. 模型文件准备：提前上传至对象存储或本地高速盘，校验文件完整性，避免启动阶段才发现文件损坏。
3. 运行时与依赖：制作统一基础镜像，锁定依赖版本，保证开发、测试、生产三套环境一致，杜绝”测试环境正常、生产异常”的版本漂移问题。
4. 网络与安全：规划内网隔离、访问凭证签发、传输加密、限流阈值；密钥不写入代码与镜像。
5. 配置文件：明确模型路径、最大上下文长度、最大并发、批处理参数、请求超时时间等关键项。
6. 监控组件：确定指标采集间隔、日志级别、告警规则与通知渠道，并准备一套覆盖典型业务场景（含歧义表述用例）的评测集。

六、部署流程

按”准备环境 → 加载模型 → 配置参数 → 启动服务 → 开放访问 → 验证结果”的顺序推进：

步骤1：环境初始化。 创建GPU计算节点或容器实例，挂载模型存储，配置网络策略与安全组。此步骤决定后续所有环节的运行基础，网络策略过严会导致监控上报失败，过松则带来安全风险。

步骤2：构建或拉取推理镜像。 镜像内包含运行时、依赖库与推理服务框架。生产环境禁止现场临时安装依赖，一切以镜像为准，保证可重复部署。

步骤3：配置推理参数。 以下为通用示意配置（字段名为示例，实际以所用推理框架文档为准）：

service:
  model_path: /models/llm-base
  dtype: bf16
  max_context_length: 8192
  max_batch_size: 32
  max_concurrency: 64
  request_timeout_ms: 30000
  enable_stream: true
monitor:
  metrics_interval_s: 15
  log_level: info
  alert_rules:
    - metric: ttft_p99_ms
      threshold: 3000
    - metric: error_rate
      threshold: 0.01

配置要点：max_concurrency与显存容量必须匹配，并发乘以上下文长度超过KV Cache预算时会触发显存溢出或大量排队；超时时间需结合业务可接受时长与输出长度上限设定。

步骤4：启动服务与健康检查。 配置就绪探针（模型加载完成、健康接口可用后才接入流量）与存活探针（进程假死时自动重启）。模型加载可能耗时数分钟，就绪探针的超时阈值要相应放宽。

步骤5：接入层配置。 配置负载均衡、内网访问地址、认证方式与限流规则。限流阈值应低于推理服务实际承载能力，起过载保护作用。

步骤6：监控告警接入。 确认四类指标已成功上报、看板数据可见、告警通知链路畅通（可制造一次测试告警验证）。

步骤7：灰度放量。 先小流量观察，确认延迟、错误率、质量指标稳定后再逐步全量。

七、上线验证

• 功能验证：健康检查接口返回正常；分别发起一次非流式与流式请求，输出内容完整、流式过程无中断。
• 性能验证：压测确认TTFT、端到端延迟、吞吐达到预设目标；观察高并发下排队长度与错误率是否可控。
• 质量验证：用固定评测集回归，特别要覆盖含歧义表述的用例（类似”住宅房源”这类口语化、多义词场景），确认prompt中的业务定义生效、输出分类符合预期。
• 资源验证：稳态运行下GPU利用率与显存水位平稳，无持续增长趋势（排除显存泄漏）。
• 日志验证：无异常堆栈与频繁重试记录，告警规则已生效。

八、常见问题与排查

现象	常见原因	解决思路
首Token延迟高	并发超限导致排队；长输入预填充慢	观察排队长度，降低单请求输入长度，调整并发与批大小，必要时扩容
整体吞吐不达标	批处理过小、CPU侧前后处理瓶颈	启用连续批处理，优化分词与输入拼接逻辑
显存溢出、进程重启	并发×上下文长度超出KV Cache预算	降低max_concurrency或max_context_length，或升级显存规格
输出与业务预期不符	prompt语义定义不完整	参照房产助手案例，在prompt中明确业务词表定义，修改后跑评测集回归再发布
监控数据缺失	采集器未部署、上报网络不通	检查采集组件状态与网络策略，验证上报链路
流式输出卡顿	TPOT波动、网络缓冲	查看TPOT分位数曲线与网络带宽，排查批处理抖动

九、运维与优化

• 性能优化：启用连续批处理提升整体吞吐；在质量可接受前提下通过量化降低显存占用、提升吞吐；对相同系统prompt启用前缀缓存复用KV计算；对高频相同请求引入结果缓存。
• 质量优化：建立prompt版本管理与固定评测集，每次修改prompt（如补充”住宅房源默认指独栋住宅”这类业务定义）先回归后发布；对badcase做周期性归因，区分模型问题与定义问题。
• 容量与成本：按高峰QPS规划容量，低峰弹性缩容；定期治理闲置实例；评估量化与批处理策略对单Token成本的影响，在体验与成本间取得平衡。
• 稳定性保障：配置限流、超时、重试与降级策略；多实例部署避免单点；模型文件与配置定期备份，支持快速回滚。
• 安全运维：密钥集中管理、定期轮换；日志中对用户输入脱敏；保留操作审计记录。

十、总结

部署一个LLM推理服务，本质是交付一套”算得快、答得对、看得见、稳得住”的在线系统。关键步骤包括：按显存预算完成资源规划，以镜像化方式保证环境一致，按”环境初始化—模型加载—参数配置—健康检查—接入开放—灰度验证”的顺序完成上线，并建立性能、资源、服务健康、输出质量四类指标的监控告警体系。上线不是终点：性能优化围绕延迟与吞吐持续调优，质量优化依托prompt版本管理与评测回归形成闭环，容量与成本按流量规律动态治理。只有把监控指标与优化动作串成闭环，推理服务才能在业务增长中长期稳定运行。