上周朋友公司的 AI 模型又出问题了 —— 电商大促期间，预测接口突然崩溃，眼睁睁看着订单流失。老板气得拍桌子：“花了几十万训练的模型，连个大促都扛不住？”

这其实是很多企业的通病：模型在实验室跑得好好的，一到线上就掉链子。要么是突然来一波流量就扛不住，要么是服务器一挂整个服务就瘫了。

今天就给大家分享一套经过实战验证的方案：用 Docker+Kubernetes（简称 K8s）部署模型，既能自动应对流量波动，又能保证服务器崩了也不影响服务。全程大白话，跟着做就能学会。

先说说为啥模型总掉链子？

朋友公司的模型部署方式，可能也是你正在用的：把模型打包成 Python 脚本，直接扔在一台服务器上运行。这种方式有三个致命问题：

1. 环境坑：本地测试好好的，换台服务器就报错，一堆依赖包冲突

2. 扛不住：突然来了 10 倍流量，服务器 CPU 瞬间跑满，接口直接超时

3. 不抗揍：就一台服务器，万一崩了，整个模型服务就停了

上个月他们做奶粉促销，就因为模型接口崩了 2 小时，损失了近百万订单 —— 这就是没做好弹性伸缩和高可用的代价。

[插入图片 1：服务器监控截图，显示 CPU 突然飙升到 100%，接口响应时间变长]

Docker：给模型装个 “移动房子”

解决这些问题的第一步，是用 Docker 给模型 “打包”。你可以把 Docker 理解成一个 “移动房子”，模型和它需要的所有环境（Python 版本、依赖包等）都装在里面，不管搬到哪台服务器，都能原样运行。

给模型建 “房子” 的 3 个步骤：

1. 写个简单的模型服务

用 Flask 给模型套个 API 接口，再加上健康检查（就像给房子装个烟雾报警器）：

# 保存为model_service.py

from flask import Flask, request, jsonify

import joblib

# 加载模型

model = joblib.load('sales_model.pkl')

app = Flask(__name__)

# 预测接口

@app.route('/predict', methods=['POST'])

def predict():

data = request.json

# 调用模型预测（这里简化处理）

result = model.predict([data['features']])

return jsonify({'prediction': float(result[0])})

# 健康检查接口（重要！）

@app.route('/health', methods=['GET'])

def health():

return jsonify({'status': 'ok'}), 200

if __name__ == '__main__':

app.run(host='0.0.0.0', port=5000)

2. 写 Dockerfile（建房图纸）

告诉 Docker 这房子要怎么建，用什么材料：

# 用轻量版Python做基础

FROM python:3.9-slim

# 装依赖

RUN pip install flask scikit-learn joblib

# 把模型和代码放进房子里

COPY model_service.py /app/

COPY sales_model.pkl /app/

# 打开大门（端口）

EXPOSE 5000

# 启动服务

CMD ["python", "/app/model_service.py"]

3. 盖房子（构建镜像）

执行这条命令，Docker 就会按图纸盖好房子：

docker build -t sales-model:v1 .

这样，你的模型就变成了一个可移动的 “集装箱”，随便在哪台装了 Docker 的服务器上，输入这条命令就能运行：

docker run -d -p 5000:5000 sales-model:v1

[插入图片 2：Docker 镜像构建和运行的命令截图，突出成功提示]

K8s：给模型请个 “智能管家”

光有房子还不够，还得有个管家帮忙管房子 ——K8s 就是这个管家。它能帮你做三件大事：

• 多雇人：流量大了自动多开几个模型实例（弹性伸缩）

• 换班制：一个实例崩了，马上启动新的顶上（高可用）

• 分任务：把用户请求均匀分到不同实例上（负载均衡）

让管家干活的 3 个关键指令：

1. 告诉管家要雇几个人（Deployment 配置）

创建一个model-deploy.yaml文件：

apiVersion: apps/v1

kind: Deployment

metadata:

name: sales-model

spec:

replicas: 3 # 一开始先雇3个人

selector:

matchLabels:

app: model

template:

metadata:

labels:

app: model

spec:

containers:

- name: model-container

image: sales-model:v1 # 用上面建好的镜像

ports:

- containerPort: 5000

resources:

requests:

cpu: "1核"

memory: "1G"

执行kubectl apply -f model-deploy.yaml，管家就会启动 3 个模型实例。

2. 让管家自动调人（弹性伸缩配置）

创建model-hpa.yaml：

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

name: model-scaler

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: sales-model

minReplicas: 3 # 最少3个人

maxReplicas: 10 # 最多10个人

metrics:

- type: Resource

resource:

name: cpu

target:

averageUtilization: 70 # CPU超70%就加人

执行kubectl apply -f model-hpa.yaml，当用户变多，模型 CPU 超过 70%，管家就会自动多开实例；用户少了，又会自动减人。

3. 给用户指路（Service 配置）

创建model-service.yaml，让用户能找到模型：

apiVersion: v1

kind: Service

metadata:

name: model-service

spec:

selector:

app: model

ports:

- port: 80

targetPort: 5000

type: LoadBalancer

执行kubectl apply -f model-service.yaml，管家就会分配一个访问地址，用户通过这个地址就能调用模型，请求会自动分到不同实例上。

[插入图片 3：K8s 控制台截图，显示多个模型实例正常运行，突出弹性伸缩的数字变化]

实战效果：大促流量涨 10 倍也不怕

朋友公司用这套方案后，最近一次促销活动效果明显：

• 流量从平时的 100QPS 涨到 1000QPS，K8s 自动把实例从 3 个加到 8 个，响应时间始终稳定在 200ms 以内

• 中途有台服务器突然断电，K8s 在 10 秒内就把上面的实例转移到其他服务器，用户完全没感觉到

• 活动结束后，实例自动减回 3 个，省了不少服务器费用

[插入图片 4：流量和实例数变化的曲线图，显示流量上涨时实例数同步增加]

新手入门注意这 3 点

1. 先在本地练手：用 Minikube 在自己电脑上装个迷你版 K8s，随便折腾不怕出事

2. 镜像别太大：模型文件别直接塞镜像里，大文件可以放云存储，启动时再下载

3. 监控要做好：装个 Prometheus+Grafana，实时看着 CPU、内存和接口响应时间

其实 Docker+K8s 没那么神秘，就像先把模型装进标准化的快递盒，再请个智能快递员负责分发和调配。中小公司不用追求一步到位，先把 Docker 用起来，再慢慢过渡到 K8s，一样能解决大部分问题。

你在部署模型时遇到过哪些崩溃瞬间？评论区聊聊，点赞最高的送一份《Docker+K8s 部署速查表》，里面有所有关键命令和配置模板。

（关注我，下期分享怎么用 100 块钱的服务器跑起这套系统，小公司也能轻松上手）