智驾模型推理服务部署与容量规划实操指南

一、场景选型与架构

本文讨论的服务是智驾场景中的模型推理服务。输入可能是多帧感知数据、时序特征或结构化序列，输出为检测结果、规划建议或特征向量。部署前先确定服务属于哪一类场景，因为不同场景的时延目标、资源规格和网络暴露方式差别很大。

维度	在线推理	离线批量推理	训练后验证
典型调用方	车端或路侧设备经网关调用	数据平台按任务批量提交	算法工程师手动或脚本触发
核心指标	P99 时延、可用性	总吞吐、单位样本成本	结果可复现、启动速度
实例形态	常驻，至少 2 个副本分布在不同可用区	按任务弹性拉起，可用抢占式实例	单实例即可
弹性策略	按 QPS 或队列长度自动扩缩容	按任务队列长度扩容，任务结束后释放	无需弹性
网络暴露	优先内网，公网入口需加认证和白名单	仅内网访问存储与调度系统	仅开发网段访问

可用性目标需要量化。例如，在线服务可以先设定 99.9% 作为示例值，但该数字必须由业务方确认后才能写入 SLA。

选型建议：有明确时延上限的服务按在线场景设计，优先保证副本冗余。以吞吐为目标的回放和评测按离线场景设计，允许排队，成本优先。

1.1 架构分层

模型权重与服务镜像分开管理。镜像只包含运行时、推理框架和服务代码。权重存放在对象存储中，按版本号组织目录，例如 s3://<bucket>/models/<model>/v1.4.2/。每个版本目录包含模型文件和一份 manifest.json，manifest 记录每个文件的 SHA256 值。

启动时，初始化容器把权重同步到本地盘或挂载卷，并逐个比对 SHA256。模型更新时只替换权重目录和版本环境变量，不需要重新构建镜像。

权限按最小化原则配置。服务账号只有模型前缀的读取权限，只有发布流水线拥有写入权限。本地盘设定清理策略，只保留最近两个版本，磁盘使用率超过 80% 时删除最旧的版本。

1.2 版本校验落地

版本校验分四步执行。

1. 目录检查：初始化容器确认 manifest.json 存在，并且目录中的文件与清单一致，多出或缺失的文件都视为失败。
2. 哈希校验：对每个文件计算 SHA256 并与清单比对。任何一个文件不一致，初始化容器以非零退出码结束。
3. 启动失败退出：主容器依赖初始化容器成功。校验失败时 Pod 停留在 Init 错误状态，不会接收流量，同时触发校验失败告警。
4. 兼容性确认：服务启动后，读取本地版本文件，与 MODEL_VERSION 比对。两者不一致时拒绝进入就绪状态。

镜像与权重需要维护兼容矩阵。下表是模板，具体版本号需要按实际发布记录填写。

镜像版本	支持的模型版本	运行时最低要求	状态
infer-runtime 2.3.x	v1.4.x	CUDA 版本按发布说明	当前生产
infer-runtime 2.2.x	v1.3.x	CUDA 版本按发布说明	可回滚

发布前先查矩阵。不在矩阵中的组合不得上线。

二、资源估算与容量规划

资源评估分三步：先估单实例显存，再压测得到单副本稳定吞吐，最后用峰值流量推算副本数。

2.1 显存估算

权重显存可按下式估算：

权重显存（GB）≈ 参数量（十亿）× 每参数字节数

每参数字节数取决于精度：

精度	每参数字节数
FP16 或 BF16	2
INT8	1
INT4	0.5

例如，参数量为 7 十亿、采用 FP16 时，权重显存约为 14 GB。这只是计算示例，不代表任何实测结果。

总显存还包括 KV cache、中间激活和框架开销：

总显存（GB）≈ （权重显存 + KV cache 显存 + 激活与中间张量显存 + 框架开销）×（1 + 预留系数）

KV cache 显存仅适用于含注意力机制的序列模型，计算公式为：

KV cache 显存（GB）≈ 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 每元素字节数 ÷ 10⁹

其中系数 2 对应 K 和 V 两份缓存。非序列模型该项记为 0。框架开销和激活显存无法精确推算，需要在目标 GPU 上实际加载模型后读取峰值显存。预留系数可以先取 0.1 到 0.2，之后按压测结果调整。

量化会改变权重显存，但精度可能下降。INT8 或 INT4 上线前，必须在固定评测集上比对精度指标，并设定可接受的下降阈值。

2.2 压测得到单副本稳定吞吐

压测结果只有在条件固定时才可复现。压测需要记录以下口径：

• 输入形状与模型版本保持一致，不混用不同分辨率或序列长度。
• 请求分布取自生产流量的采样数据，而不是随机生成的数据。
• 预热时长需覆盖模型加载和首次编译耗时，预热期间的数据不计入统计。
• 每个并发档位持续运行固定时长，统计窗口内取稳定段的 P99 和吞吐。
• 压测工具可选用 wrk、locust 或内部压测平台，工具与版本需要记录在报告中。

稳定 QPS 的定义是：在连续统计窗口内，P99 不超过 SLA 目标，错误率接近零时的最大 QPS。测试方法是逐步提高并发，每档记录 P99、吞吐和错误率，取满足条件的最大值。

批处理和并发会影响结果。增大批大小通常提高吞吐，但每个请求的排队和计算时间变长，P99 随之上升。并发增加时，超过 GPU 处理能力的请求进入队列，P99 会突然变大。因此 SLA 目标决定了可用的批大小上限。

2.3 副本数计算

副本数 = ceil(峰值 QPS ÷ (单副本稳定 QPS × 冗余系数))

冗余系数用于留出余量。若希望平时副本利用率不超过 70%，冗余系数可取 1 ÷ 0.7，约等于 1.43。在线服务无论计算结果多少，副本数都不少于 2，并分布在不同可用区。

假设峰值 QPS 为 200，单副本稳定 QPS 为 30，冗余系数为 1.43，则副本数为 ceil(200 ÷ (30 × 1.43)) = ceil(4.66)，结果为 5。上述数字仅用于演示公式，实际值必须来自压测和业务流量统计。

三、部署配置示例

下面是在线服务的 Kubernetes 配置示例。执行前需要替换镜像地址、存储路径和资源规格，并确认 GPU 节点标签与调度策略。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: drive-infer
namespace: drive-infer
spec:
replicas: 2
selector:
matchLabels:
app: drive-infer
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: