模型服务上线最头疼的问题往往不是模型精度，而是运行环境。当算法工程师在本地用特定版本的深度学习框架训好模型，交付给运维部署到生产服务器时，常常因为底层库不一致、驱动版本不匹配而导致推理失败。容器化部署把模型文件、推理代码以及所有依赖全部打进一个不可变的镜像里，从根源上消除了环境差异。它也让弹性扩缩容变得简单，流量高峰时多起几个容器即可，不用重新配置机器。
如何构建稳定可复用的模型服务镜像
构建模型服务镜像的第一步是选择合适的基础镜像。不要直接使用过大的通用系统镜像，而应该优先选用官方提供的带推理引擎的精简镜像，例如 PyTorch 或 TensorFlow 的 CPU、GPU 特定版本镜像。这样既能保证框架兼容性，也能减少层数。在编写 Dockerfile 时，先拷贝依赖清单安装第三方库，再拷贝代码，利用分层缓存加快后续构建速度。
模型文件通常体积较大，不建议直接写进镜像，可以通过启动脚本从对象存储或挂载卷读取，保持镜像轻量。如果必须打包，也要注意使用 .dockerignore 排除训练数据和日志。下面给出一个简化的 Dockerfile 示例，展示如何封装一个 Flask 推理服务。
FROM python:3.9-slim # 设置工作目录 WORKDIR /app # 先拷贝依赖文件以利用缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 拷贝推理代码 COPY app.py . COPY model/ ./model/ # 暴露端口 EXPOSE 8080 # 启动命令 CMD ["python", "app.py"]
上面的方式虽然简单，但在真实场景中要加上健康检查与降级逻辑。比如容器启动后先加载模型到内存，如果模型下载失败应当退出并返回非0状态，让编排系统知道该实例不可用。镜像构建完成后，推送到私有仓库并打上语义化版本标签，禁止用 latest 覆盖，否则回滚时会找不到确切版本。
容器资源隔离与 GPU 调度要点
模型推理服务对计算资源的需求差异很大。文本分类可能只需零点几个 CPU 核，而视觉大模型则需要整张 GPU。容器通过 cgroups 实现资源限制，在部署时必须显式声明 resources 字段，防止某个服务把节点资源吃满。对于 CPU 服务，限制内存尤为重要，因为 Python 进程在加载大模型时容易出现内存陡增。
当使用 GPU 推理时，需要节点安装对应驱动并启用 nvidia-container-toolkit，容器里才能看到显卡。Kubernetes 中通过 nvidia.com/gpu 资源声明来调度，但注意一块卡默认不能被多个容器强行共享，除非使用 MIG 切分或时间片方案。下面的代码片段展示 docker run 命令如何指定 GPU 设备。
# 使用所有可用 GPU 启动推理容器 docker run -d --gpus all -p 8080:8080 --memory=4g --cpus=2 my-registry/model-serve:1.2.0
资源隔离不只是限制上限，也要配置合理的请求值。若请求值过高，调度器会无法装箱，造成节点闲置；若过低，则节点超卖后引发争抢，导致推理延迟飙升。建议对线上模型做一轮压测，记录 P99 时延下的实际消耗，再反推容器配额。同时开启 OOM 监控，一旦容器被系统杀掉要有告警和自动重启。
基于编排系统的弹性扩容与灰度策略
单机容器只能解决环境封装，真正应对业务波动要靠编排系统。以 Kubernetes 为例，将模型服务部署为 Deployment，配合 HPA 基于 QPS 或自定义指标自动增减副本。这样白天流量高时自动扩到十几个实例，凌晨缩到一个，既保体验又省成本。注意 HPA 的冷却窗口要调好，避免频繁伸缩引起抖动。
灰度发布在模型服务里尤为关键，因为新模型可能准确率下降或耗时变长。可以通过 Service 与不同版本 Deployment 的权重切流，先放百分之五的流量观察监控。下面的 YAML 片段说明如何用副本数做简单灰度：旧版保持十副本，新版起两副本，前端通过统一 Service 轮询。
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-serve-v1
spec:
replicas: 10
selector:
matchLabels:
app: model-serve
version: v1
template:
metadata:
labels:
app: model-serve
version: v1
spec:
containers:
- name: serve
image: my-registry/model-serve:1.2.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-serve-v2
spec:
replicas: 2
selector:
matchLabels:
app: model-serve
version: v2
template:
metadata:
labels:
app: model-serve
version: v2
spec:
containers:
- name: serve
image: my-registry/model-serve:1.3.0
除了副本灰度，还要在网关层做超时与熔断。模型服务偶尔会因输入异常而卡死，若没有超时控制，请求堆积会拖垮整个容器组。建议在客户端和 Sidecar 都设上限，并结合日志追踪每次推理的耗时分布。当新版本指标平稳一段时间后，再逐步调大副本比例，最终下掉旧版，完成安全迭代。