📚 课程目录第4章模型部署架构

4. 模型部署架构：离线训练 vs 在线推理、模型序列化（Pickle/ONNX）、API服务架构设计

信用评分模型从开发环境走向生产环境，核心在于构建一套稳定、高效、可扩展的部署架构。本章围绕“离线训练”与“在线推理”的职责划分、模型序列化标准以及API服务架构设计展开，帮助学员掌握从模型文件到线上服务的完整链路。

4.1 离线训练 vs 在线推理：职责分离与协同

信用评分模型的生命周期天然分为两个阶段：离线训练（Offline Training） 和 在线推理（Online Inference）。两者在计算资源、时效性、数据范围上存在显著差异，生产环境中必须采用分离架构。

对比维度	离线训练	在线推理
触发方式	定时调度（每日/每周）或事件触发	实时API请求（毫秒级响应）
数据范围	全量历史样本（百万级+）	单条或小批量实时特征
计算资源	GPU集群/大数据Spark作业	CPU容器/轻量级推理引擎
产出物	模型文件（Pickle/ONNX）+ 特征工程元数据	评分结果 + 决策建议
延迟要求	分钟级~小时级	P99 < 200ms
版本管理	模型注册中心（MLflow/ModelDB）	灰度发布 + 回滚机制

  架构原则：离线训练负责“生产模型”，在线推理负责“消费模型”。两者通过统一的模型仓库和版本号解耦，训练完成后推送模型文件至推理服务，推理服务不参与任何训练逻辑。

4.2 模型序列化：Pickle vs ONNX

模型训练完成后，必须序列化为标准文件格式才能被推理服务加载。序列化方案直接影响推理性能、跨平台兼容性和部署灵活性。信用评分场景下，Pickle 和 ONNX 是两种主流选择。

4.2.1 Pickle（Python原生序列化）

优点： 使用简单，一行代码即可保存/加载；支持任意Python对象（包括sklearn pipeline、自定义Transformer）。
缺点： 仅限Python环境；文件可能包含恶意代码（安全风险）；版本依赖强（sklearn版本不一致可能导致加载失败）。
适用场景： 内部实验、小规模部署、全Python技术栈团队。

# 保存模型
import pickle
with open('credit_model.pkl', 'wb') as f:
    pickle.dump(model_pipeline, f)

# 加载模型
with open('credit_model.pkl', 'rb') as f:
    model = pickle.load(f)
score = model.predict_proba(features)[:, 1]

4.2.2 ONNX（开放神经网络交换格式）

优点： 跨语言/跨框架（Python/Java/C#均可加载）；推理引擎优化（ONNX Runtime）带来2~5倍加速；支持硬件加速（GPU/FPGA）。
缺点： 转换过程可能丢失部分自定义算子；调试相对复杂。
适用场景： 生产级高并发API、多语言异构系统、边缘端部署。

# 将XGBoost模型转换为ONNX
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType

initial_type = [('float_input', FloatTensorType([None, n_features]))]
onnx_model = convert_sklearn(model, initial_types=initial_type)
with open('credit_model.onnx', 'wb') as f:
    f.write(onnx_model.SerializeToString())

# ONNX Runtime推理
import onnxruntime as ort
session = ort.InferenceSession('credit_model.onnx')
input_name = session.get_inputs()[0].name
score = session.run(None, {input_name: features})[0]

对比维度	Pickle	ONNX
跨语言支持	仅Python	Python/Java/C#/C++/Rust
推理性能	基线	提升2~5倍（图优化+算子融合）
版本兼容性	脆弱（依赖sklearn版本）	稳定（ONNX opset版本管理）
安全风险	存在反序列化漏洞	无代码执行风险
模型大小	较大（含Python对象元数据）	较小（仅计算图+权重）
推荐场景	开发调试、快速原型	生产部署、高并发API

生产建议： 信用评分API推荐使用ONNX格式。即使原始模型是sklearn pipeline，也可以通过 skl2onnx 或 hummingbird 库完成转换，获得显著的性能收益和跨平台能力。

4.3 API服务架构设计

信用评分API服务需要同时满足低延迟、高可用、可观测和灰度发布等要求。以下是一个经过生产验证的微服务架构设计。

4.3.1 核心组件

API网关（Gateway）： 统一入口，负责鉴权、限流、路由、请求日志。推荐Kong/APISIX或云原生ALB。
评分服务（Scoring Service）： 无状态容器，加载ONNX模型，执行推理。每个Pod可加载多个模型版本。
特征服务（Feature Store）： 实时特征计算与缓存，避免重复计算。可使用Redis或Flink实时特征。
模型仓库（Model Registry）： 存储模型文件+元数据，支持版本回滚。MLflow或S3+MySQL。
监控与告警（Monitoring）： Prometheus + Grafana，采集延迟、QPS、模型分数分布、PSI漂移。

4.3.2 请求处理流程

Step 1： 客户端发送POST请求，携带用户ID和基础字段。
Step 2： API网关校验Token，检查QPS配额，转发至评分服务。
Step 3： 评分服务从特征服务获取实时特征（如征信查询次数、近30天逾期次数）。
Step 4： 加载ONNX模型，执行推理，输出违约概率和信用评分。
Step 5： 返回JSON响应，同时异步发送评分事件至Kafka用于离线分析。

4.3.3 部署关键配置

配置项	推荐值	说明
容器资源（CPU/内存）	2C / 4GB	ONNX推理单次约5~15ms，2C可支撑50+ QPS
模型预热	启动时加载ONNX session	避免首次请求冷启动延迟
超时设置	上游超时 500ms，服务超时 300ms	防止慢请求堆积
健康检查	/health 返回模型加载状态	K8s liveness/readiness probe
限流策略	令牌桶：100 QPS / 实例	保护下游特征服务

避坑提醒： 不要在评分服务中直接使用Pickle加载模型。生产环境曾出现因sklearn版本升级导致Pickle反序列化失败，引发线上大面积5xx。始终使用ONNX或至少将Pickle模型封装为独立微服务，隔离版本依赖。

4.4 本章小结

离线训练与在线推理必须分离，通过模型仓库实现版本解耦。
模型序列化优先选择ONNX格式，兼顾性能、跨平台与安全。
API服务架构采用网关+无状态评分服务+特征服务+监控的四层模型，支持高并发与灰度发布。
部署时关注模型预热、超时控制、健康检查和限流策略，确保服务SLA。