AI模型部署学习：用Docker跑通第一个本地推理服务

AI模型部署学习的第一步不是研究大参数模型，而是先在一台能控制的机器上跑通一次可验证的推理服务。
本文用Docker部署一个轻量文本生成模型，适合刚接触模型部署、想先理解“模型文件怎么变成接口”的读者。

开始前需要确认的三件事

模型部署和普通Web服务不同，主要卡在运行环境上。
动手前先确认以下条件：

• 一台Linux服务器，建议Ubuntu 22.04或相近版本，内存至少8GB。
• 已安装Docker和Docker Compose，执行 docker --version 能返回版本号。
• 如果使用GPU推理，先确认显卡驱动和容器运行时可用；纯CPU推理可以跳过GPU检查，但生成速度会明显变慢。

检查Docker是否正常：

docker run --rm hello-world

看到“Hello from Docker!
”说明容器运行环境正常。
如果这条命令报权限错误，把当前用户加入docker组后重新登录：

sudo usermod -aG docker $USER

用容器启动一个推理服务

这里选择支持OpenAI兼容接口的轻量推理镜像，好处是启动后可以直接用HTTP请求验证，不需要先写客户端代码。
以下命令以CPU模式为例，实际镜像名和模型名请按你选用的推理框架文档替换：

docker run -d \
  --name ai-infer \
  -p 8000:8000 \
  -v /data/models:/models \
  your-inference-image:latest \
  --model /models/your-model

参数含义：

• -p 8000:8000 把容器内服务端口映射到宿主机，后续通过 http://服务器IP:8000 访问。
• -v /data/models:/models 把宿主机模型目录挂载进容器，避免每次重建容器都重新下载模型。
• --model 指定模型路径，必须和挂载路径一致。

启动后查看日志，确认服务是否真正就绪：

docker logs -f ai-infer

日志中出现监听端口或“server started”一类信息，才说明容器内进程正常。
如果容器状态是 Exited，先看日志最后二十行，常见原因是模型路径写错或内存不足。

验证接口是否可用

服务启动不等于能回答请求。
用一条最简单的请求验证：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-model",
    "messages": [{"role": "user", "content": "用一句话解释什么是模型推理"}]
  }'

返回JSON中包含回复内容，说明部署链路已经跑通。
如果返回连接拒绝，检查容器是否在运行；
如果返回模型不存在，核对请求里的 model 字段和启动参数是否一致。

容易踩坑的地方

端口映射后仍访问不了。 先确认服务监听的是 0.0.0.0 而不是 127.0.0.1，再检查服务器防火墙或安全组是否放行8000端口。

显存不足导致容器反复重启。 GPU部署时先用 nvidia-smi 看显存占用，模型加载失败通常会直接在日志里提示OOM。
可以换更小参数量的模型，或减少并发请求数。

模型文件放在容器内层。 不挂载目录而把模型下载进容器，容器删除后模型就没了。
模型目录一定要用 -v 挂到宿主机。

直接暴露公网端口。 推理接口默认没有鉴权，验证阶段建议只绑定 127.0.0.1，确认可用后再通过Nginx反向代理并加访问控制。

部署完成后检查什么

一次合格的部署至少满足三个条件：容器状态为 Up、日志无持续报错、接口能返回结构化结果。
建议把启动命令和模型版本记录到笔记里，后续换机器或升级时可以直接复用。

如果请求偶发超时，先看 docker stats 里CPU和内存是否打满，再判断是模型太大还是并发过高。
部署学习阶段不必追求高并发，先把单次请求稳定跑通，再考虑加缓存、限流或换用推理加速方案。

后续可以继续了解模型量化、批处理推理和反向代理配置，这些都是在跑通第一个服务之后自然要面对的问题。