大模型推理服务上云部署全流程实践

一、部署概述：这次要交付的到底是什么

很多团队做大模型时，训练脚本跑得通、离线评测分数也不错，但一到”上线”就卡住：模型权重放在哪、用多大显存的机器、并发上来为什么会排队、超时了怎么重试、版本更新怎么不影响线上。这类问题的本质是——模型本身不是服务，推理服务才是。本文讨论的部署对象，就是把 Transformer 结构的大模型（无论其主体是仅含自注意力的理解型编码器结构，还是带交叉注意力、带因果掩码的自回归解码结构）封装为一个具备健康检查、并发处理、限流保护、日志与监控的标准后端服务，并部署到云上通用运行环境（云服务器、容器平台或托管运行环境）中。

部署完成后应达到的效果是：外部业务通过统一的接口地址即可发起推理请求，服务在多副本下稳定运行，具备可观测性和灰度回滚能力，单请求延迟与吞吐满足业务约定，资源利用率可控。

适用读者：负责模型服务化的算法工程师、负责承载与运维的平台/运维工程师、负责容量与成本决策的技术负责人。

部署前需要理解的基本背景（这几点直接决定后面的资源规划）：

• 模型属于哪一类结构。理解型模型（只做一次前向、输出向量或分类结果）与生成型模型（自回归逐 token 输出）在显存占用、批处理策略、延迟特征上差异很大；
• 生成型模型的服务分为两个阶段：对输入提示做并行计算的预填充阶段（计算密集，决定首字延迟）与逐词生成的解码阶段（访存密集，决定吐字速度）。因果掩码保证解码时每个位置只能看到自身及之前的位置，这使得历史 Key/Value 可以缓存复用，形成 KV 缓存——它是显存规划中最大的变量；
• 输入输出长度分布。上下文窗口是配置上限，真实业务的平均长度才决定实际并发能力；
• 网络访问方式（公网/内网/专有网络）、是否有数据合规要求、是否需要私有化环境。

二、部署场景：先确认你的部署形态

不同场景对应完全不同的部署设计，动手前先对号入座：

场景	服务形态	部署要点
内部效果评测、算法调试	单实例长驻 + 内网访问	优先环境一致性与快速换版，不做高可用
业务在线问答、智能助手	多副本无状态服务 + 负载均衡	关注首字延迟、并发上限、限流降级
离线批处理（文档抽取、批量打标）	任务型/队列驱动	关注吞吐与成本，允许高延迟，可用抢占式资源
对外提供 API 能力	网关 + 鉴权 + 计量	关注多租户隔离、配额、审计
私有化/专有环境交付	容器化打包整体交付	关注镜像体积、离线依赖、无外网时的可运行性

三、架构与组件拆解

一套完整的推理服务部署通常包含以下层次，每一层都对应独立的部署动作：

1. 接入层：负载均衡与反向代理，负责南北向流量入口、TLS 终止、连接复用、超时与重试策略；
2. 网关与治理层：身份认证、租户与配额、限流熔断、请求路由与灰度分流；
3. 推理运行时层：模型加载、权重解析、算子执行、批处理调度、KV 缓存管理、显存回收。这是唯一有”重状态”的层，也是容量规划的核心；
4. 模型资产层：权重与配置文件、分词器、模板文件、版本号与校验值，通常存放在对象存储上，由容器启动时拉取或挂载；
5. 依赖数据层：向量库或关系型数据库（检索增强场景）、缓存组件（热点结果与前缀复用）、消息队列（异步与削峰）；
6. 可观测层：日志服务、指标监控与告警、链路追踪；
7. 安全层：密钥管理、访问白名单、传输加密、审计日志。

结构差异如何影响部署设计：仅有自注意力的编码器型模型，输入长度固定或可截断，可放心做静态批处理，显存占用可预测；带交叉注意力的编码器-解码器型模型需要同时持有两套子网络权重，镜像与显存开销更大；自回归解码型模型必须处理变长序列与 KV 缓存增长，因此需要连续批处理能力和显存上限保护，否则单个超长请求会拖垮整个实例。部署前把这三点想清楚，后面的参数配置就不会靠猜。

四、前置准备清单

账号与权限：云上账号、资源创建权限、对象存储读写权限、镜像仓库推送权限、密钥管理读取权限。遵循最小权限原则，部署账号与运行账号分离。

资源准备：目标机型（是否含加速卡、加速卡型号与显存容量）、系统盘与数据盘容量、带宽或负载均衡规格、对象存储空间、数据库与缓存实例规格。

运行环境与依赖：统一的运行时版本、框架版本、加速库版本、系统基础库版本。强烈建议把这些固化进容器镜像并打版本标签，避免”我机器上能跑”。

模型资产与校验：权重文件、结构定义文件、分词器、对话模板、许可与合规确认。上传后必须记录版本号与文件校验值，作为回滚与排障依据。

配置与密钥：服务端口、监听地址、上下文长度上限、最大并发、批处理窗口、模型路径、依赖连接串。所有敏感信息通过环境变量或密钥管理注入，禁止写入镜像或代码仓库。

网络与证书：域名解析、证书签发、安全组/访问控制策略、上下游服务的调用白名单。

五、资源规划：先算显存，再谈并发

大模型推理的资源瓶颈通常先出现在显存，而不是 CPU 或带宽。通用估算思路如下（具体数值必须以实测为准）：

显存需求 ≈ 权重占用 + KV 缓存占用 + 运行时与算子临时开销
权重占用   ≈ 参数量 × 每参数字节数（FP16/BF16 为 2，INT8 为 1）
KV 缓存    ≈ 2 × 层数 × 隐藏维度 × 上下文长度 × 并发数 × 每元素字节数（按结构参数换算）
运行时开销 ≈ 框架预留 + 激活值 + 通信缓冲区

由此可得到三条规划原则：

• 上下文上限 × 最大并发是显存配置的主变量，而不是平均输入长度。把上限设得过高会导致大量显存被预留而无法被真正使用；
• 量化（FP16/BF16/INT8）是显存与吞吐之间最直接的调节手段，但需在效果回归评测通过后再上线；
• 单实例容量确定后，用水平扩展承接并发，而不是无限调大批处理窗口——批越大吞吐越高，但延迟也随之上升。

资源项	规划依据	常见风险
计算规格	模型规模、并行策略、目标吞吐	规格不足导致排队
加速卡显存	权重 + KV 缓存上限	OOM 导致实例反复重启
存储	镜像体积 + 权重体积 + 日志量	拉取慢、磁盘写满
网络	请求体大小 × QPS、下游调用量	带宽或连接数打满
弹性策略	峰值倍数、扩容冷启动时间	扩容不及时，峰值雪崩

六、部署流程（八步）

第一步：环境与资源初始化。 创建网络与安全组、对象存储桶、镜像仓库、日志与监控空间。此步产出的是”地基”，权限和网络策略错了，后面每一步都会以奇怪的方式失败。

第二步：构建并推送镜像。 将运行时、依赖、推理框架、服务代码打成一个不可变镜像，打上版本标签（含模型版本）。镜像要区分”基础镜像”和”应用镜像”，基础镜像复用可减少后续构建与拉取时间。不要把权重打进镜像，权重放对象存储、启动时拉取或挂载，否则镜像动辄数十 GB，扩容速度无法接受。

第三步：准备模型资产与启动配置。 上传权重并记录版本与校验值；编写配置文件（模型路径、精度、上下文长度、并行度、端口、批处理策略、依赖地址）。

第四步：本地/单实例连通性验证。 在单台云服务器上先跑通：加载权重成功、单次请求返回正确、健康检查返回就绪。跳过这一步直接多副本发布，是把不确定性放大 N 倍。

第五步：编写服务编排描述。 声明副本数、资源请求与上限、环境变量与密钥引用、健康检查与就绪检查、优雅退出时间、存储挂载、日志采集。

第六步：配置访问入口。 负载均衡后端组挂载实例、域名解析、证书绑定、超时与重试策略。注意：对生成式接口，网关读超时必须大于单请求最长生成时间，否则会出现”后端正常出结果、网关已返回 504”的经典问题。

第七步：灰度发布。 先 1 个新版本实例接入少量流量，与旧版本并行观察，再逐步扩大比例。

第八步：验证与放量。 按下一节的验证清单逐项确认后再全量。

通用编排描述示意（仅表达结构，非任何具体平台语法）：

service:
  name: llm-inference
  replicas: 3
  container:
    image: registry.internal/llm-inference:${VERSION}
    env:
      MODEL_PATH: /models/${MODEL_VERSION}
      MAX_CONTEXT_LEN: "8192"
      MAX_CONCURRENCY: "32"
      DB_CONN: "@secret://inference/db"
    resources:
      requests: { cpu: "8", memory: "32Gi", accelerator: "1" }
      limits:   { cpu: "16", memory: "64Gi", accelerator: "1" }
    health:
      readiness: { path: /ready, interval: 10s, timeout: 3s, failureThreshold: 3 }
      liveness:  { path: /healthz, interval: 15s, timeout: 3s, failureThreshold: 4 }
    lifecycle:
      preStop: { sleep: 20s }      # 先从后端摘流，再退出
      terminationGracePeriod: 60s   # 覆盖最长单次生成时间
  storage:
    model: { from: object-storage, mount: /models, readonly: true }

推理服务启动参数示意（伪代码，表达配置项语义）：

runtime = InferenceRuntime(
    model_dir="/models/<version>",
    dtype="bfloat16",              # 精度：显存与效果的权衡点
    max_context_len=8192,          # 单请求上下文上限
    max_batch_tokens=16384,        # 批处理 token 预算，控制延迟
    kv_cache_mem_ratio=0.85,       # 允许用于 KV 缓存的显存比例，留出余量防 OOM
    tensor_parallel=1,             # 单卡可容纳则为1，超出则按卡数切分
    enable_continuous_batching=True,
)
app = InferenceService(
    runtime=runtime,
    max_concurrency=32,            # 排队上限，超出快速失败优于无限堆积
    request_timeout_s=120,         # 覆盖最长生成时间
    stream=True,                   # 流式返回可显著改善首字体验
)

七、关键配置说明与风险点

• 上下文长度上限：直接决定 KV 缓存峰值。设过大导致实际并发被显存挤死；设过小则长文档请求被拒。应按业务 P99 输入长度设定，而非取模型理论上限。
• 最大并发与队列长度：必须有上限并快速失败。无上限队列会让延迟无限增长，最终以超时形式批量爆发。
• 超时分层：网关读超时 > 服务处理超时 > 单次生成预估时长。三层超时关系错乱是线上”假故障”的高频原因。
• 重试策略：生成类请求默认不自动重试（重复扣费且放大负载），仅对明确的连接类错误幂等重试；流式响应中断后不可重试。
• 优雅退出：preStop 先摘流、等存量请求结束再退出，否则每次发布都会丢请求。
• 健康检查与就绪检查分离：存活检查失败重启实例，就绪检查失败只摘流量。模型加载慢时二者混用会造成滚动发布时的雪崩式重启。
• 限流与降级：按租户/接口维度限流，超限时返回明确错误码；可保留一条更小模型或缓存兜底路径。

八、上线验证清单

按层次逐级确认，任何一层不通过都不要放量：

1. 实例层：副本全部就绪，无重启计数增长，无 OOM 记录；
2. 健康检查：就绪/存活探针稳定通过，摘流后能从后端组正确摘除；
3. 接口正确性：正常请求、空输入、超长输入、非法参数、鉴权失败分别返回预期结果；
4. 生成质量：用固定的回归评测集比对，确认量化、并行切分、模板变更未造成效果回退；
5. 性能基线：记录首字延迟、单请求总延迟、每秒输出 token 数、最大稳定并发，并做小步压测找出拐点；
6. 长稳测试：持续数小时的恒定压力，观察显存与内存是否缓慢增长（KV 缓存或缓存组件泄漏的典型表现）；
7. 可观测性：日志能检索到请求标识，指标能在监控面板看到，告警能触达值班人；
8. 故障演练：手动杀实例、断开依赖、打满显存，确认服务降级符合预期而非整体不可用。

九、常见问题与排查

现象	常见原因	排查与处理思路
实例反复重启，日志无异常	显存/内存超限被强制回收	查资源事件与显存峰值，下调并发或上下文上限，或改用更低精度
首个请求超时、后续正常	模型加载与预热未完成就接流量	就绪检查加入”模型已加载”判定，增加预热请求
网关 504 但后端有结果	网关读超时小于生成时长	拉长网关超时，启用流式返回
吞吐高但延迟不可接受	批处理窗口过大	降低单批 token 预算，改用连续批处理
长文档请求导致整实例卡顿	单请求占满 KV 缓存	限制单请求上下文，隔离长请求队列
发布过程丢请求	无优雅退出与摘流	增加 preStop 等待与足够长的终止宽限期
扩容后仍不够快	冷启动拉取镜像/权重耗时过长	精简镜像、权重与镜像分离、预热节点池
成本超预期	按峰值长期预留、闲置副本未回收	定时缩容、区分在线与离线资源池、存储生命周期策略

十、运维与优化

监控告警：分三类指标。资源类看加速卡显存与利用率、CPU、内存、网络；服务类看 QPS、错误率、P95/P99 延迟、队列长度、排队时长；业务类看请求量、输入输出长度分布、拒答率、限流触发次数。告警要绑定处置动作，而不只是”发个通知”。

日志与追踪：为每个请求生成标识并贯穿网关、服务、依赖调用，便于定位慢在哪一段。同时注意日志中可能包含用户输入，需按合规要求脱敏或缩短保留期。

稳定性保障：多可用区部署副本，避免单点；对依赖（数据库、缓存、向量库）设置连接池上限与超时；关键路径加熔断，防止下游变慢把线程与连接耗尽。

版本与回滚：模型版本与服务版本都要独立可追溯。灰度期间保留旧版本实例与旧权重，回滚动作应是”切流量 + 恢复配置”，而不是重新构建。发布前把回滚命令与判定条件写清楚。

成本与容量：在线与离线任务用不同资源池，离线任务可用低优先级/可中断资源；缓存热点结果与相同前缀的重复计算；按真实峰值分布设定弹性策略，避免为极端峰值长期买单；定期复盘资源利用率并回收闲置实例。

安全：接口必须鉴权，密钥定期轮换，传输全程加密，内网服务不暴露公网，开启访问审计，对模型资产做完整性校验以防被替换。

十一、总结

大模型服务的部署难点不在于”把进程跑起来”，而在于把模型结构特性翻译成工程约束：编码器的定长批处理、解码器的因果掩码与 KV 缓存、变长序列的显存上限，分别对应批处理策略、显存规划和并发保护三类配置。完整链路可归纳为：明确对象与环境 → 规划资源与显存 → 固化镜像与权重资产 → 单实例连通性验证 → 编排与入口配置 → 灰度发布 → 分层验证 → 长期运维。

上手时最容易忽略的三件事是：就绪检查必须包含模型加载完成、网关超时与优雅退出必须与最长生成时间对齐、模型资产必须与镜像分离。把这三点做对，再配合完整的指标监控与可执行的回滚方案，一套大模型推理服务才算真正具备上线的条件。若团队希望减少自建推理运行时的门槛，也可以基于百度智能云提供的容器平台、对象存储、日志监控等通用云产品能力搭建同等架构，部署逻辑与本文一致。