3. 环境与工具准备

在进入金融Serving API、批量推理与版本编排的实战之前，必须先搭建一条稳定、可复现的工具链。金融场景对推理结果的确定性、可追溯性和版本一致性要求极高，因此环境准备不是“装几个包”那么简单，而是要建立从模型训练产物到线上服务的完整通路。本节将围绕Python、FastAPI、Docker、Kubernetes、MLflow与ONNX Runtime六个核心组件，讲清它们各自的职责、安装要点与协同配置方式。

一、核心原理：六件工具在推理链路中的定位

这六个组件并非并列关系，而是分层协作。Python是模型加载与业务逻辑的宿主语言；FastAPI负责将推理能力暴露为HTTP接口；ONNX Runtime承担高性能推理执行；MLflow管理模型版本、参数与制品；Docker将运行环境固化为镜像；Kubernetes负责多副本调度、扩缩容与滚动更新。理解这条链路，才能避免“装了却不知道怎么串起来”的常见困境。

金融推理工具链分层协作关系 MLflow 模型版本 / 参数 / 制品 ONNX Runtime 高性能推理执行 FastAPI HTTP Serving 接口 Docker 环境固化镜像 Kubernetes 调度 / 扩缩容 / 滚动更新

二、方法流程：分步安装与配置

建议按“语言运行时→推理引擎→服务框架→容器化→编排→版本管理”的顺序推进，每一步都验证通过后再进入下一步，避免问题叠加。

  1. Python环境：推荐使用3.10或3.11，金融推理库对版本较敏感。用conda或venv隔离项目环境。
  2. ONNX Runtime：CPU版直接pip安装；GPU版需匹配CUDA与cuDNN版本。
  3. FastAPI与Uvicorn：安装fastapi、uvicorn[standard]、pydantic，用于构建异步推理接口。
  4. MLflow：安装mlflow并启动tracking server，配置后端存储与制品存储路径。
  5. Docker：安装Docker Engine，编写Dockerfile固化推理环境。
  6. Kubernetes：本地可用minikube或kind，生产用托管集群，配置kubectl与镜像仓库凭证。
# 1. 创建并激活Python环境
conda create -n fin-serving python=3.11 -y
conda activate fin-serving

# 2. 安装核心依赖
pip install fastapi "uvicorn[standard]" pydantic
pip install onnxruntime          # CPU版
# pip install onnxruntime-gpu    # GPU版，需匹配CUDA

# 3. 安装MLflow
pip install mlflow
mlflow server --host 0.0.0.0 --port 5000 \
  --backend-store-uri sqlite:///mlflow.db \
  --default-artifact-root ./artifacts

# 4. 验证ONNX Runtime
python -c "import onnxruntime as ort; print(ort.get_available_providers())"
金融场景建议固定所有依赖版本，使用pip freeze > requirements.txt锁定，确保训练与推理环境一致，避免因numpy或onnx版本差异导致数值偏差。

三、案例场景：一个最小可用的推理服务配置

假设我们已有一个信用评分ONNX模型，需要将其封装为FastAPI服务并容器化。下面是一个精简但完整的配置示例，展示工具链如何串联。

# app.py
import onnxruntime as ort
from fastapi import FastAPI
from pydantic import BaseModel
import numpy as np

app = FastAPI(title="Credit Scoring API")
session = ort.InferenceSession("model/credit_score.onnx")

class Features(BaseModel):
    income: float
    debt_ratio: float
    age: int

@app.post("/predict")
def predict(f: Features):
    x = np.array([[f.income, f.debt_ratio, f.age]], dtype=np.float32)
    out = session.run(None, {"input": x})[0]
    return {"score": float(out[0][0])}

# Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py model/ ./
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

# 构建并本地验证
docker build -t credit-api:v1 .
docker run -p 8000:8000 credit-api:v1
curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"income":50000,"debt_ratio":0.3,"age":35}'

验证通过后，将镜像推送到仓库，再通过Kubernetes Deployment部署多副本，并配置Service与HPA实现弹性伸缩。MLflow则记录该模型对应的版本号与训练参数，使线上服务可追溯到具体制品。

四、误区与复盘：环境准备中的高频问题

误区表现正确做法
依赖版本不锁定本地正常，容器内推理结果漂移使用requirements.txt固定版本并纳入镜像构建
ONNX与CUDA不匹配GPU版加载失败或回退CPU先查onnxruntime-gpu对应CUDA版本再安装
MLflow制品路径用本地相对路径容器内找不到模型文件使用对象存储或挂载卷作为artifact root
K8s未配置资源限制推理Pod被OOM Kill设置requests/limits并配置就绪探针
镜像过大拉取慢、扩缩容延迟使用slim基础镜像、多阶段构建
金融合规要求推理服务具备可审计性。务必确保MLflow中记录的模型版本与线上运行的ONNX文件哈希一致，并在Kubernetes中通过镜像tag而非latest进行部署，避免版本漂移导致审计失败。

完成本节工具链搭建后，你应当能够：在隔离环境中安装并验证六个组件；将ONNX模型封装为FastAPI服务；通过Docker固化环境；在Kubernetes中部署并验证服务可用性；通过MLflow追溯模型版本。这套环境是后续Serving API开发、批量推理任务编排与版本灰度发布的基础，建议在进入下一环节前，先用一个真实的小模型完整跑通一次端到端流程，确认每个环节的日志与输出都符合预期。

← 上一章 📖 返回目录 下一章 →