模型蒸馏技术把大模型的知识迁移到参数量更小的学生模型中，训练完成后如何把模型稳定地跑在线上，就成了新的问题。蒸馏模型的推理环境往往涉及特定版本的Python、PyTorch、CUDA以及一批三方库，稍微有版本偏差就可能出现算子不兼容或精度异常。Docker通过镜像把整个运行环境固化下来，让蒸馏模型在训练机和线上机器上表现出完全一致的行为，是当前最主流的推理服务部署方案之一。本文从环境隔离、镜像构建、部署实践三个层面，完整讲解Docker在蒸馏模型服务中的使用方法。
为什么蒸馏模型服务特别适合用Docker部署
蒸馏模型本身并不特殊，特殊的是它所处的依赖链路。学生模型通常继承自教师模型的结构裁剪版本，例如把BERT-base蒸馏成6层甚至4层的小模型，推理代码里可能同时依赖Transformers、ONNXRuntime、Tokenizer等组件。这些组件对底层CUDA版本、cuDNN版本有严格要求，一旦服务器环境和训练环境不一致，很容易出现“本地能跑、线上报错”的尴尬局面。
Docker的价值在于把操作系统层之上的所有内容打包成镜像。镜像里包含Python解释器、依赖库、推理代码和模型权重，任何一台装了Docker的机器拉取镜像后运行的结果都完全一致。对于需要横向扩容的推理服务来说，这一点尤其重要：新增节点时不需要手工装驱动、配环境变量，直接启动容器即可，扩容时间从小时级缩短到分钟级。
另外，蒸馏模型经常需要和原始大模型共存提供服务。比如线上同时跑一个教师模型用于离线评估、若干个学生模型用于在线推理，通过Docker可以给不同模型分配独立的容器和端口，互不干扰，也方便针对每个模型单独做资源限制和版本管理。
推理镜像的构建要点与Dockerfile编写
构建镜像的第一步是选择合适的基础镜像。如果模型跑在GPU上，推荐使用NVIDIA官方的nvcr.io/nvidia/pytorch系列镜像或PyTorch官方的pytorch/pytorch镜像，它们已经内置了匹配的CUDA运行时。如果蒸馏后的模型足够小，可以走CPU推理路线，此时python:3.10-slim配合CPU版PyTorch能把镜像从十几GB压缩到两GB以内，部署成本大幅下降。
依赖安装建议分层处理，先把变化频率低的系统库和Python基础依赖放在前面的层，把经常变动的业务代码放在后面的层，这样反复构建时可以利用缓存加速。模型权重文件比较大，不建议直接打包进镜像，更好的做法是构建时拷入或运行时挂载。下面是一个典型的CPU推理镜像Dockerfile示例：
FROM python:3.10-slim
# 设置工作目录
WORKDIR /app
# 先安装依赖，利用缓存加速后续构建
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt \
&& pip install --no-cache-dir torch --index-url https://download.pytorch.org/whl/cpu
# 拷贝推理代码与蒸馏后的模型文件
COPY ./src ./src
COPY ./models/distilled_model ./models/distilled_model
# 暴露推理服务端口
EXPOSE 8000
# 启动命令
CMD ["python", "src/server.py", "--model_dir", "models/distilled_model"]
这个例子中有几个细节值得注意。--no-cache-dir可以避免pip缓存占用额外空间；torch使用CPU专用源安装，体积只有GPU版本的五分之一左右；模型目录单独一层拷贝，代码改动时不必重新传输模型文件。如果坚持把大模型文件打进镜像，建议先确认镜像仓库的分层存储上限，否则推送和拉取都会非常缓慢。
对于GPU场景，还需要确认宿主机安装了NVIDIA驱动并部署了nvidia-container-toolkit。镜像内的CUDA版本只需要和PyTorch编译版本匹配，驱动版本向下兼容，这一点让镜像的CUDA选择比直接在物理机上装CUDA灵活得多。此外可以使用多阶段构建，在一个完整的编译阶段安装依赖并导出虚拟环境，再复制到精简的运行镜像中，进一步削减体积。
容器启动、健康检查与服务编排实践
镜像构建完成后，用docker run启动容器即可提供推理服务。CPU场景直接映射端口运行；GPU场景通过--gpus参数把显卡透传进容器。启动命令示例如下：
# CPU推理服务
docker run -d --name distilled-server -p 8000:8000 distilled-inference:latest
# GPU推理服务，指定使用0号显卡
docker run -d --name distilled-server \
--gpus '"device=0"' \
-p 8000:8000 \
distilled-inference:latest
模型文件采用挂载方式时，把宿主机上的模型目录挂到容器内对应路径，这样更新模型只需要替换文件并重启容器，不用重新构建镜像。这种“代码进镜像、权重走挂载”的模式在团队协作中非常实用，模型迭代和代码迭代可以解耦推进。
健康检查是保障服务稳定的关键环节。在启动命令或编排配置里配置健康探测，定时请求推理服务的健康接口，失败次数超过阈值后自动重启容器，可以避免模型加载异常导致的服务假死。下面给出一个结合健康检查与自动重启的docker-compose配置：
services:
distilled-server:
image: distilled-inference:latest
container_name: distilled-server
ports:
- "8000:8000"
volumes:
- ./models/distilled_model:/app/models/distilled_model:ro
deploy:
resources:
limits:
cpus: "2"
memory: 4G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
interval: 30s
timeout: 5s
retries: 3
restart: unless-stopped
这份配置里做了几件事：模型目录以只读方式挂载，防止容器内误改权重；对CPU和内存做了上限限制，避免单个推理容器抢占宿主机资源；健康检查每三十秒探测一次/health接口，三次失败即判定不健康。如果服务规模扩大，可以把同样的容器定义迁移到Kubernetes，利用HPA根据请求量自动伸缩蒸馏模型的推理副本。
最后补充两个实践建议。一是推理服务建议在容器内以非root用户运行，降低安全风险；二是给镜像打上包含模型版本号的标签，例如distilled-inference:student-v1.2，回滚时直接切换到历史标签即可，配合镜像仓库可以做到秒级版本切换。把这些细节落实到位，蒸馏模型的线上服务就能长期保持轻量、稳定和可追溯。