大模型推理服务部署指南：从资源规划到回滚运维

作者：菠萝爱吃肉2026.11.13 03:28浏览量：0

简介：本文按实际操作顺序讲解大模型推理服务的部署：先估算显存与并发，再准备环境与配置参数，随后完成单实例验证、多副本上线、监控告警和回滚。读完可得到参数表、验证步骤和一份上线检查清单，减少上线时的反复试错。

一、资源规划

部署前先回答三个问题：模型有多大，需要支撑多少并发，单次请求平均有多长。

显存由两部分构成。

  1. 模型权重：约等于参数量乘以每个参数占用的字节数。FP16或BF16每个参数占2字节，INT8约占1字节，INT4约占0.5字节。例如70亿参数（7B）的模型，FP16权重约需14 GB显存。
  2. KV缓存：约等于 2 × 层数 × KV头数 × 每个头的维度 × 上下文词元数 × 并发数 × 每个元素的字节数。它随并发和上下文长度增长，常常是显存紧张的主要原因。层数、KV头数和头维度应从模型的配置文件中读取，不同模型之间差异很大，不宜凭经验估计。

除此之外，激活值、推理框架的运行时开销和显存碎片也会占用空间。建议预留一部分余量，具体比例以实际测量为准。

并发数增加会提高吞吐，但增长到显存或计算能力饱和后，请求排队变长，首词元延迟会快速上升。量化可以降低权重占用，但输出质量可能下降，需要用业务评测集对比量化前后的结果。

容量数据必须通过压测获得。压测时应统一以下口径：输入长度分布、输出长度分布、并发数、是否流式返回。口径不统一，测得的数字无法比较。

二、环境准备与版本依赖

部署环境中的各个组件版本需要互相匹配。下表列出需要锁定的版本及核对方式。

组件 要求 核对方式
GPU驱动 满足所选GPU型号与CUDA运行时的最低版本 执行 nvidia-smi
CUDA与cuDNN运行时 与推理框架的预编译版本一致 查阅框架的发行说明
容器运行时 能够把GPU设备透传进容器 运行官方提供的测试镜像
推理框架 固定到具体版本号，不使用 latest 标签 镜像标签或依赖锁文件
模型文件 权重、配置和分词器来自同一次发布 核对文件的 sha256 值

准备步骤如下。

  1. 把模型下载到只读的存储挂载点，并校验每个文件的 sha256。
  2. 确认分词器文件与模型权重属于同一版本。分词器不匹配会导致输出乱码或结果异常，而且这类错误往往不会报错。
  3. 把访问密钥写入环境变量或密钥管理服务，不写入镜像、代码或配置仓库。
  4. 服务端口只开放给内网或网关，不直接暴露到公网。

三、关键参数配置

参数名称因推理框架而异，下表列出的是通用含义。

参数 作用 设置原则
模型路径 指向权重目录 使用带版本号的目录，例如 /models/名称/版本号
分词器路径 指向分词器文件 与模型来自同一次发布
最大上下文长度 输入加输出的词元总上限 按业务最长请求设定，设置过大会占用更多KV缓存
单次最大输出词元数 限制单次生成的长度 由接口默认值和业务上限共同决定
最大并发序列数 同时处理的请求上限 由压测结果确定，且要落在显存余量之内
张量并行度 模型切分到的GPU数量 等于模型所需的卡数，且不超过节点可用卡数
显存使用上限比例 框架可占用的显存比例 先取保守值，压测后再调整
请求超时时间 单个请求的最长等待时间 大于P99生成时长，并留出余量
健康检查路径 存活与就绪探测地址 就绪前不接入业务流量
预热请求数 启动后发送的预热请求次数 覆盖常见的输入长度

四、架构与组件

一个完整的推理服务通常包含以下组件。

  • 负载均衡与API网关：统一入口，负责鉴权、限流、路由、超时与重试策略。它部署在推理副本前面，不直接占用GPU。
  • 推理服务运行时：加载模型、执行推理并对外提供HTTP接口。它部署在GPU节点上，每个副本占用固定的显卡。
  • 调度与批处理：在运行时内部合并请求，并根据显存余量决定是否接纳新请求。它随运行时一起部署，行为由配置参数控制。
  • 模型存储与缓存：保存模型权重。网络存储保证各节点版本一致，节点本地缓存可以加快启动速度。
  • 监控与告警：采集延迟、吞吐、显存和错误率等指标并触发告警。监控应与推理服务分开部署，避免服务故障时监控也随之失效。

依赖关系是：客户端经网关访问运行时副本，副本在启动时从存储读取模型，监控从网关和副本拉取指标。

五、单实例启动与接口验证

在扩展到多个副本之前，先把单个实例验证通过。

  1. 启动一个副本，只绑定内网地址。
  2. 观察日志，等待模型加载完成，并记录加载耗时。
  3. 调用健康检查接口，确认返回就绪状态后再继续。
  4. 发送一条短请求和一条接近最大长度的长请求，检查返回格式、停止条件和词元计数是否正常。
  5. 用一组固定提示词做回归测试，把关键字段与旧版本的输出对比。
  6. 记录显存峰值占用、首词元延迟和整体延迟。

接口调用示例如下，具体路径以所用框架的接口文档为准。

  1. curl -N http://127.0.0.1:8000/v1/chat/completions \
  2.   -H "Authorization: Bearer $API_KEY" \
  3.   -H "Content-Type: application/json" \
  4.   -d '{"model": "your-model", "messages": [{"role": "user", "content": "你好"}], "stream": true}'

六、多副本上线与监控告警

副本数由压测结果推算：副本数不少于目标峰值请求量除以单副本稳定承载的请求量，再额外增加一个冗余副本。

上线时先接入一个副本，观察指标稳定后再逐步增加。

监控应覆盖以下指标。

指标 含义 告警设置
P95首词元延迟 第95百分位的首个输出词元返回时间 以压测基线为依据设定
每秒输出词元数 实际吞吐 低于基线的一定比例时告警
GPU显存利用率 显存占用比例 长时间接近上限时告警
5xx错误率 服务端错误请求占比 持续超过阈值时告警
排队等待时长 请求在队列中的等待时间 持续增长时告警

告警阈值应由自己的压测数据决定，不要套用其他团队公布的数字。

七、回滚运维

只有在旧版本保持运行的前提下，回滚才可能在几分钟内完成。因此上线时需要做到以下几点。

  • 保留上一版本的镜像标签、模型版本和配置文件。
  • 新旧版本可以同时运行，并能通过网关的权重或后端分组切换流量。
  • 旧版本副本在新版本稳定之前保持运行，不提前下线。

灰度上线的流程如下。

  1. 把新版本的流量比例设为较小的值，例如5%。
  2. 在每个比例上观察指标，指标稳定后再提高比例，依次推进到20%、50%和100%。每个阶段的观察时长由业务流量决定。
  3. 出现以下任一情况时触发回滚：5xx错误率超过阈值；P95首词元延迟超过阈值并持续；回归测试的关键输出与旧版本不一致。
  4. 回滚时把新版本的流量权重降为0。新版本副本先保留，用于排查问题，确认后再下线。
  5. 回滚后验证健康检查通过，错误率回落，延迟回到基线，抽样请求的输出与旧版本一致。
  6. 记录回滚的原因、时间和影响范围。

回滚耗时取决于网关切换速度和旧副本的响应情况。应在预发环境演练一次，记录实际耗时，再确定对外承诺的时间。

八、上线检查清单

  • 显存估算已完成，余量已规划
  • 模型与分词器的版本号和 sha256 一致
  • 驱动、CUDA、容器运行时和推理框架版本已锁定
  • 关键参数表已评审
  • 单实例回归测试通过
  • 压测结果已记录，作为告警基线
  • 监控与告警已接通，告警接收人已确认
  • 访问密钥通过环境变量或密钥服务注入
  • 服务端口未直接暴露到公网，对外访问经过网关鉴权
  • 旧版本保持可用，回滚步骤已演练并记录耗时
  • 日志不记录用户输入全文和任何密钥

最热文章