一、按部署架构分类

(1) 实时推理（Web API / Online Inference）

  • 定义：将训练好的模型封装成一个可通过网络（通常是 HTTP/REST 或 gRPC）实时调用的服务。客户端发送单个或少量请求，服务端立即返回预测结果。
  • 特点：
    • 低延迟：响应时间通常在毫秒到秒级。
    • 交互性强：适用于需要即时反馈的应用场景。
    • 资源消耗按需：每个请求都会触发一次推理计算。
  • 适用情况：推荐系统、欺诈检测、聊天机器人、图像/语音实时识别、个性化内容生成等需要快速响应的在线应用。
  • 相关常用工具/架构：
    • Web 框架：Flask, FastAPI, Django (用于构建轻量级API)。
    • 专用模型服务器：TensorFlow Serving, TorchServe, NVIDIA Triton Inference Server。
    • 云服务：AWS SageMaker Endpoints, Google Cloud AI Platform Prediction, Azure ML Online Endpoints。
    • 编排平台：KServe (基于 Kubernetes)，Seldon Core，BentoML

(2) 批处理推理（Batch Inference）

  • 定义：将大量待预测的数据集一次性或周期性地提交给模型进行离线处理。模型对整个数据集进行推理，并将结果批量输出到存储系统（如数据库、数据湖）。
  • 特点：
    • 高吞吐量：可以高效处理海量数据。
    • 非实时性：从数据提交到获得结果有显著延迟（分钟、小时甚至天）。
    • 成本效益高：可以利用计算资源空闲时段（如夜间）运行，优化资源利用率。
  • 适用情况：用户画像更新、风险评估报告生成、营销活动效果预测、大规模数据标注、日志分析等对实时性要求不高但数据量巨大的场景。
  • 相关常用工具/架构：
    • 工作流调度器：Apache Airflow, Prefect, Kubeflow Pipelines。
    • 大数据处理框架：Apache Spark (MLlib), Dask。
    • 容器化任务：通过 Docker 封装推理脚本，在 Kubernetes 或云函数（如 AWS Lambda, GCP Cloud Functions）上作为批处理任务运行。

(3) 边缘/端侧部署（Edge/On-Device Deployment）

  • 定义：将模型直接部署并运行在数据产生的源头设备上，如智能手机、IoT传感器、嵌入式设备、车载计算机等，而非在云端或数据中心。
  • 特点：
    • 超低延迟：省去了网络传输时间，响应速度极快。
    • 隐私与安全：敏感数据无需离开设备，增强了用户隐私保护。
    • 离线可用：不依赖网络连接，可在无网环境下工作。
    • 资源受限：设备的计算能力、内存和功耗通常有限，对模型有严格要求。
  • 适用情况：手机上的实时滤镜/人脸解锁、自动驾驶汽车的感知系统、工业设备的本地故障预测、智能家居设备的语音助手等。
  • 相关常用工具/架构：
    • 移动端框架：TensorFlow Lite, PyTorch Mobile, Apple Core ML, ONNX Runtime for Mobile。
    • 模型优化技术：量化（Quantization）、剪枝（Pruning）、知识蒸馏（Knowledge Distillation）是部署前的必备步骤，以减小模型体积和计算量 。
    • 嵌入式推理引擎：NVIDIA Jetson (搭配 TensorRT), OpenVINO (Intel)。

二、主流部署工具与框架详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
┌─────────────────────────────────────────────────────┐
│ 高层 MLOps 编排框架 (Orchestrators)                   │
│  • KServe, Seldon Core, BentoML (K8s Operator)      │
│  • SageMaker, Vertex AI (云托管)                     │
└───────────────────────┬─────────────────────────────┘
                        │ （调用/集成）
┌───────────────────────▼─────────────────────────────┐
│ 模型服务/API 层 (Model Serving Layer)                 │
│  • TorchServe, TensorFlow Serving                   │
│  • NVIDIA Triton Inference Server (多框架, GPU 优化)  │
│  • Flask/FastAPI + 自定义推理逻辑                     │
└───────────────────────┬─────────────────────────────┘
                        │ （运行在）          
┌───────────────────────▼───────────────┐
│  容器平台 (Container Platform)         │		 
│  • Docker                             │
│  • Docker Compose                     │
│  • Kubernetes (K8s)                   │
└─────────────────┬─────────────────────┘
（模型服务可选集成：）
┌─────────────────▼─────────────────────┐
│   高性能推理后端 (Execution Backend)  │
│  • TensorRT                           │ ←── **加速引擎**
│  • ONNX Runtime (with CUDA EP)        │
│  • cuDNN / cuBLAS                     │
└───────────────────────────────────────┘

2.1 Orchestrators

(1) KServe (原 KFServing)

  • 定位：一个基于 Kubernetes 的标准模型服务框架，旨在为机器学习模型提供无服务器（Serverless）的推理体验。
  • 核心优势：
    • Kubernetes 原生：深度集成 K8s 生态，天然支持自动扩缩容（包括缩容至零）、滚动更新、流量管理等。
    • 多框架支持：通过“推理运行时”（Inference Runtimes）的概念，可以轻松集成 TensorFlow Serving, TorchServe, Triton 等后端。
    • 高级功能：支持金丝雀发布、解释性（Explainability）、GPU 资源管理等 MLOps 关键能力。
  • 使用方式：用户只需定义一个简单的 YAML 文件（KServe CRD），即可在 K8s 集群上一键部署和管理模型服务。

2.2 云平台托管服务

  • AWS SageMaker、Google Vertex AI、Azure ML：提供端到端的模型训练、部署、监控能力
  • 优势：免运维、自动扩缩容、内置监控告警

2.3 通用模型服务器 (Inference Server)

(1) TensorFlow Serving

  • 定位：专为 TensorFlow 模型设计的高性能、灵活的生产级模型服务系统。
  • 核心优势：
    • 高性能：针对 TensorFlow 模型进行了深度优化，支持批量处理（batching）以提升吞吐量。
    • 模型生命周期管理：原生支持模型版本控制和热更新（A/B测试、无缝切换），无需重启服务。
    • 多模型支持：可以在同一个服务实例中同时托管多个模型或同一模型的不同版本。
  • 使用方式：通常通过 Docker 容器部署，提供 gRPC 和 RESTful API 接口供客户端调用。

(2) TorchServe

  • 定位：由 AWS 和 Facebook（PyTorch）共同开发的，用于在生产环境中高效部署 PyTorch 模型的开源工具。
  • 核心优势：
    • 开箱即用：简化了 PyTorch 模型的部署流程，无需编写复杂的自定义服务代码。
    • 灵活性：支持自定义预处理/后处理逻辑（通过 handler 脚本），可轻松集成到现有工作流。
    • 生产就绪：内置指标监控、多模型管理、版本控制等功能。
  • 使用方式：同样提供官方 Docker 镜像，支持 REST 和 gRPC 接口，易于在各种环境中部署。

(3) NVIDIA Triton Inference Server

  • 定位：一个跨框架、跨平台的高性能推理服务软件，尤其擅长在 NVIDIA GPU 上进行加速。
  • 核心优势：
    • 框架无关性：支持 TensorFlow, PyTorch, ONNX, TensorRT, OpenVINO 等多种模型格式。
    • 极致性能：利用动态批处理（Dynamic Batching）、并发模型执行等技术最大化 GPU 利用率。
    • 部署灵活性：可在云、数据中心、边缘（Jetson）甚至 Kubernetes 上运行。
  • 使用方式：通过标准化的 HTTP/gRPC 接口提供服务，是构建大规模、高并发AI服务的理想选择。

2.4 容器/编排平台

1. Docker Compose

  • 定义：Docker Compose 是一个用于定义和运行多容器 Docker 应用程序的工具。
  • 用途：通过一个 YAML 文件（docker-compose.yml）配置多个服务（如数据库、Web 服务器等），实现一键启动、停止和管理容器化应用。
  • 适用场景：主要用于单机环境（如本地开发、测试服务器或小型单节点部署）

2. Kubernetes（K8s）

  • 定义：Kubernetes 是一个开源的容器（支持多种容器，多为containerd容器）编排平台，用于自动化部署、扩展和管理容器化应用。
  • 核心功能：
    • 自动扩缩容：根据负载动态调整容器数量。
    • 服务发现与负载均衡：自动分配流量到健康容器。
    • 自我修复：容器故障时自动重启或替换。
  • 适用场景：为多服务器集群设计，适用于生产级分布式系统

2.5 跨框架推理引擎

  • ONNX Runtime：支持跨平台（Windows/Linux/macOS/iOS/Android/Web）的高性能推理引擎，可加速多种框架导出的 ONNX 模型
  • TensorRT：NVIDIA 推出的 GPU 推理优化器，针对 NVIDIA 硬件提供极致性能

三、大语言模型（LLM）特殊部署方式

针对大模型资源消耗大的特点，常用方案包括：

  • vLLM：基于 PagedAttention 的高效推理引擎，显著提升吞吐量
  • TGI（Text Generation Inference）：Hugging Face 官方推理服务器，支持张量并行
  • Llama.cpp：纯 C/C++ 实现，支持 CPU/GPU 混合推理，适合资源受限环境
  • Ollama：本地运行大模型的简易工具，适合开发测试

四、部署策略（降低风险）

  • 蓝绿部署（Blue/Green）：同时维护两套环境，切换时零停机
  • 金丝雀发布（Canary）：先向小部分用户发布新模型，验证稳定后再全量
  • 影子部署（Shadow Deployment）：新模型与旧模型并行运行，仅用于数据收集不参与决策

五、部署示例

Docker+Flask

✅ 1. 开发机上的流程（1.1–1.4）

步骤 基本操作 建议增强（生产级）
1.1 开发 ✔️已有：可部署格式的模型（ONNX/ PMML/ SavedModel/ .pt/ .joblib)
✔️编写 Flask 应用（app.py）：创建一个 Flask 应用，定义 API 端点（如 /predict），在其中加载模型并处理预测请求。
✔️准备依赖文件（requirements.txt）：列出项目运行所需的所有 Python 包。		 - 添加输入校验（如 Pydantic）
- 加入日志记录（logging）
- 考虑异常处理（try-except）
1.2 封装（Dockerfile） ✔️ 编写 Dockerfile：这是一个文本文件，包含一系列指令，告诉 Docker 如何构建镜像。
- FROM python:3.8-slim：指定基础镜像。
- COPY requirements.txt . 和 RUN pip install …：复制依赖文件并安装库。
- COPY app.py model.pkl ./：将应用代码和模型文件复制到镜像中。
- EXPOSE 5000：声明容器运行时监听的端口。
- CMD [“python”, “app.py”]：指定容器启动后要运行的命令（启动 Flask 应用）		 - 使用 .dockerignore 避免无关文件被复制
- 将应用放在非 root 用户下运行（安全）
- 多阶段构建（Multi-stage build）减小镜像体积（对大依赖项目有用）
1.3 构建镜像 ✔️ docker build -t my-model-app .
Docker 会根据 Dockerfile 的指令，一步步构建出一个包含你的 Flask 应用和所有环境依赖的、可移植的镜像，并命名为 my-model-app		 - 建议打语义化标签（如 v1.0.0、git-commit-id）便于追踪
1.4 推送镜像 ✔️ 登录仓库：docker login your-registry.com（如未指定，默认为 Docker Hub）
✔️ 推送镜像：docker push your-username/my-model-app:v1.0
将本地构建好的镜像上传到一个中央镜像仓库，这样任何有权访问的服务器都能获取它		 - 私有项目务必使用私有镜像仓库（如阿里云 ACR、Harbor）
- 镜像应进行漏洞扫描（如 Trivy）

✅ 2. 服务器上的流程（2.1–2.3）

服务器上必须已安装 Docker，安装命令： sudo apt-get install docker.io

步骤 评价 建议增强（生产级）
2.1 拉取镜像 ✔️ docker pull your-username/my-model-app:v1.0
从中央仓库将镜像下载到目标服务器		 - 可通过 CI/CD 自动触发（如 GitLab CI、GitHub Actions）
2.2 运行容器 ⚠️docker run -d -p 80:5000 my-model-app
Docker 会从镜像启动一个容器实例，并将容器内的 Flask 端口 (5000) 映射到服务器的 80 端口（HTTP 默认）。此时，你的 Flask 应用就在容器内运行起来了。		 - 必须加 --restart=unless-stopped：防止容器意外退出后服务中断
- 挂载日志卷：-v /logs:/app/logs 便于排查问题
- 限制资源：--memory=512m --cpus=1 防止单个服务耗尽服务器资源
- 使用 .env 文件管理配置（而非硬编码）
2.3 测试 ✔️ 使用工具如 curl 或 Postman 向 http://localhost:80/predict 发送 POST 请求，测试 API 是否正常工作并返回预测结果。
✔️ 本地电脑测试服务器上的 API，地址应为 http://<服务器公网IP>/predict		 - 应加入健康检查端点（如 /health）
- 生产环境需配合监控（Prometheus + Grafana）和告警