智驾Transformer服务部署实战：估算到回滚

一、先确认服务形态与前置条件

部署前先回答四个问题。答案决定后面每一步的参数选择，不能跳过。

检查项	判断标准	需要准备的材料	不满足时的处理
服务形态	是在线逐请求推理，还是离线批处理	业务的延迟要求（如P99目标）和吞吐要求	在线推理优先看延迟，批处理优先看吞吐，两者的batch策略不同，需分别配置
运行时依赖	推理框架、CUDA版本、驱动版本、加速库是否互相兼容	框架和加速库的版本矩阵	按厂商兼容表选定一组版本，不要混用未验证的组合
模型与配置文件布局	权重、配置、分词或预处理文件是否有固定目录和版本号	模型目录结构、文件sha256校验值	统一为 models/<版本号>/ 结构，每个版本附带校验文件
网络与数据依赖	上游输入来源、下游调用方、是否需要访问外部存储	网络拓扑图、端口列表、鉴权方式	为每个依赖列出超时时间和失败后的降级方案

在线推理的服务通常还要确认三件事。第一，单次请求的输入形状是否可变，可变时需要设定最大序列长度。第二，是否允许排队，允许排队时需要设定最大队列长度，超出即拒绝。第三，是否有多模型串联，串联时每个模型的显存需要分别估算后再相加。

二、显存与带宽估算

2.1 显存估算公式

显存总量 ≈ 权重显存 + KV缓存 + 激活与工作区 + 框架开销 + 预留余量

各项的计算口径如下。

• 权重显存 = 参数量 × 每参数字节数。参数量单位为个，FP32为4字节，FP16或BF16为2字节，INT8为1字节。
• KV缓存 = 2 × 层数 × KV头数 × 头维度 × 序列长度 × batch × 每元素字节数。系数2表示K和V各存一份。注意KV头数可能小于注意力头数，多查询或分组查询注意力结构需按KV头数计算。
• 激活与工作区：没有实测数据前，可以先按权重显存的10%至30%作为初值。实测后用峰值显存减去权重和KV缓存，得到真实值。
• 框架开销：由推理框架的上下文、内核缓存和内存池决定，以实测为准。首次部署时单独记录这一项，后续版本升级后需重新测量。
• 预留余量：建议至少保留可用显存的15%，用于应对输入长度突增和显存碎片。

适用边界：公式只给出静态估算。实际峰值会随算子实现、并行策略和动态形状变化，所以公式的结果必须经过第三节的实测校验。

2.2 带宽估算公式

自回归解码阶段，每生成一步，都要从显存读取全部权重和当前的KV缓存。这一阶段通常受访存限制，因此带宽是吞吐的主要约束。

单步访存量 ≈ 权重字节 + KV缓存字节
单步耗时 ≈ 单步访存量 ÷ 有效带宽
吞吐上限（token/s）≈ batch ÷ 单步耗时

有效带宽 = 峰值带宽 × 实测效率系数。峰值带宽从显卡规格书获取，效率系数用带宽测试工具或profiler中的DRAM吞吐数据得到。效率系数一般明显低于1，直接用峰值带宽计算会高估吞吐。

这组公式只适用于解码阶段。输入预填充阶段的计算量更接近算力瓶颈，需要单独估算。卷积层和其他结构的访存模式也不同，不能直接套用。

2.3 算例

以下数值为演示用假设，不代表任何硬件或模型的实测结果。

假设条件：参数量10亿，BF16精度，层数24，KV头数8，头维度64，序列长度2048，batch为4。

1. 权重显存 = 10⁹ × 2 字节 = 2 GB。
2. 每个序列的KV缓存 = 2 × 24 × 8 × 64 × 2048 × 2 字节 ≈ 0.10 GB。batch为4时，KV缓存约为0.40 GB。
3. 假设激活与工作区为0.5 GB，框架开销为1 GB。合计 = 2 + 0.40 + 0.5 + 1 = 3.9 GB。
4. 加上15%余量，建议至少预留约4.5 GB显存。
5. 假设有效带宽为400 GB/s，单步访存量约为2.4 GB，单步耗时约6 ms，吞吐上限约为 4 ÷ 0.006 ≈ 667 token/s。

这个算例说明，在该假设下，权重读取和KV读取各占一部分流量。若序列长度翻倍，KV部分随之翻倍，吞吐上限会明显下降。调参时应先确认哪一项占主导。

2.4 profiler实测流程

估算结果必须用实测验证。推荐按以下步骤执行。

1. 固定变量。记录模型版本、精度、框架版本、驱动版本、输入序列长度、batch和硬件型号。任何一项变化都视为新的测试条件。
2. 预热。先跑至少10轮推理，排除首次加载和内核编译带来的波动。
3. 记录显存。以下代码可用于记录PyTorch的峰值显存：

import torch
torch.cuda.reset_peak_memory_stats()
# 执行一次完整推理，包括预处理和后处理
output = model(inputs)
peak_gib = torch.cuda.max_memory_allocated() / 1024 ** 3
print(f"peak allocated: {peak_gib:.2f} GiB")

1. 记录带宽。使用Nsight Systems、厂商性能工具或框架自带的profiler，采集DRAM读写吞吐和每个内核的耗时。
2. 对比。把实测峰值显存和估算值对比，把实测吞吐和带宽公式的结果对比。

验证标准如下。

• 峰值显存不超过可用显存的85%。
• 估算与实测的偏差在±20%以内。偏差超出时，先检查口径是否一致，例如是否把框架开销算进了权重显存。
• 在目标序列长度和batch下，延迟和吞吐达到业务要求。

如果偏差持续存在，把偏差较大的项单独拆出来测量，然后更新估算模型。这样就形成了“估算、实测、调参”的闭环。

三、环境准备与容器化部署

3.1 运行时准备

宿主机需要完成以下准备。

• 安装与CUDA版本匹配的显卡驱动。驱动版本需要满足容器内CUDA运行时的最低要求，具体以厂商兼容表为准。
• 安装容器GPU运行时插件，使容器能访问宿主机显卡。安装后执行 docker run --rm --gpus all <基础镜像> nvidia-smi 确认显卡可见。
• 为模型文件准备独立目录，例如 /data/models。模型文件较大，要预留至少为所有保留版本总和1.5倍的空间，给下载和校验留出余量。

3.2 镜像构建

建议把模型权重放在宿主机，用只读卷挂载进容器，不要打进镜像。这样回滚时只需切换模型路径，不必重新构建镜像。

示例Dockerfile：

# 基础镜像选择与推理框架、CUDA版本匹配的官方镜像，并固定版本标签
FROM <推理框架官方基础镜像:固定版本标签>
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY serve/ ./serve/
COPY config/ ./config/
# 非root用户运行，降低容器内被提权后的影响范围
RUN useradd -u 10001 -m appuser
USER 10001
ENV MODEL_PATH=/models/current
EXPOSE 8080
CMD ["python", "-m", "serve.main", "--config", "config/service.yaml"]

镜像构建完成后，用镜像扫描工具检查高危漏洞。发现问题时先修复基础镜像，不要直接忽略。

3.3 启动参数

启动容器的示例命令如下。路径、版本号和资源限制需要替换为实际值。

docker run -d \
  --name trans-svc \
  --gpus all \
  -p 8080:8080 \
  -v /data/models:/models:ro \
  -e MODEL_PATH=/models/v1.2.0 \
  --memory 16g \
  --restart unless-stopped \
  <镜像名:版本标签>

启动参数的含义如下。

• -v ... :ro：模型目录只读挂载，服务进程无法修改权重。
• MODEL_PATH：指向具体版本目录，版本切换和回滚都通过修改这一项完成。
• --memory：限制容器内存，防止主机内存被耗尽。
• --restart unless-stopped：容器异常退出后自动重启。这会掩盖故障，因此上线期间要同时监控重启次数。

3.4 配置字段与安全检查

服务配置文件 config/service.yaml 中，建议显式写出以下字段。

字段	含义	设置原则
max_seq_len	允许的最大序列长度	按第二节的KV公式反推，保证峰值显存不超标
max_batch_size	最大批次	与吞吐测试结果一致，超出时排队或拒绝
max_queue_len	最大排队长度	设定上限，避免延迟无限增长
request_timeout_ms	单次请求超时	略高于P99延迟目标，超时返回明确错误码
dtype	推理精度	与估算和实测使用的精度一致

安全方面，上线前逐项确认以下内容。

• 服务以非root用户运行，且容器没有多余的系统权限。
• 鉴权令牌、证书和密钥从密钥管理服务或环境变量注入，不写入镜像、代码或日志。
• 对外入口启用TLS，内部调用链路也需要认证。
• 日志中不打印原始请求体，避免输入数据中的敏感信息落盘。

四、上线验证与灰度发布

4.1 上线前验证

上线前按顺序完成以下检查。

1. 离线一致性：用固定的输入样本集，对比新版本和基线版本的输出。数值容差由业务定义，超出容差的样本需要人