4. 模型序列化与格式选型：ONNX、PMML、TensorFlow SavedModel、PyTorch TorchScript 的对比与选择
在实时风险拦截场景中，模型从训练环境迁移到生产 Serving 环境，必须经过序列化与格式转换。选型不当会导致推理延迟飙升、算子不兼容、部署架构锁定等问题。本节从实时拦截的工程约束出发，对比四种主流格式的核心差异。
4.1 四种格式的定位与适用场景
| 格式 | 维护方 | 核心定位 | 实时拦截适用性 |
|---|---|---|---|
| ONNX | Linux Foundation / 微软 | 跨框架中间表示，算子级互操作 | ★★★★★ 首选，多框架混合、硬件加速友好 |
| PMML | Data Mining Group | 数据挖掘流程标准化，含预处理与后处理 | ★★☆☆☆ 适合传统 ML，不适用深度学习与复杂图模型 |
| TensorFlow SavedModel | TF 原生完整模型包，含签名与资源 | ★★★★☆ TF 技术栈内高效，跨框架需额外转换 | |
| PyTorch TorchScript | Meta | PyTorch 模型静态图导出，支持 JIT 优化 | ★★★★☆ PyTorch 生态首选，C++ 部署友好 |
实时拦截关键指标： ONNX 在延迟 P99、算子覆盖率、硬件适配（GPU/CPU/FPGA）三个维度上综合表现最优，是当前风险拦截模型 Serving 的事实标准中间格式。
4.2 格式选型决策树
以下决策流程帮助团队根据自身技术栈与模型类型快速锁定推荐格式：
- 模型类型判断： 是否为深度学习模型（DNN/CNN/Transformer）？是 → 进入 ONNX 或 TorchScript/SavedModel；否（XGBoost/LR/RF）→ 考虑 PMML 或 ONNX。
- 框架锁定： 团队是否统一使用 PyTorch 或 TensorFlow？是 → 优先原生格式（TorchScript / SavedModel）；否 → ONNX 作为通用桥接。
- 预处理复杂度： 特征工程是否包含大量自定义逻辑（如时间窗口聚合、黑名单查表）？是 → PMML 可完整封装流程，但需确认算子支持；ONNX 需额外部署预处理服务。
- 硬件加速需求： 是否计划使用 NVIDIA Triton / TensorRT / OpenVINO？是 → ONNX 是唯一原生支持的通用格式。
- 长期维护成本： 团队是否频繁切换框架或模型版本？是 → ONNX 降低框架锁定风险。
4.3 格式对比：实时拦截关键维度
| 对比维度 | ONNX | PMML | SavedModel | TorchScript |
|---|---|---|---|---|
| 推理延迟（P99） | 低（经优化器融合） | 中（XML 解析开销） | 低（TF Runtime 优化） | 低（JIT 融合） |
| 算子覆盖率 | 高（社区贡献，持续扩展） | 低（仅传统 ML） | 高（TF 生态） | 高（PyTorch 生态） |
| 跨框架兼容 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ | ★★☆☆☆ |
| 硬件加速适配 | NVIDIA Triton / TensorRT / OpenVINO / CoreML | 有限 | TF Serving / TF-TRT | TorchServe / LibTorch |
| 预处理封装 | 需外部服务 | 内置 | 需 TF Transform | 需自定义 |
| 模型版本管理 | 文件级 | 文件级 | 内置版本目录 | 文件级 |
| 动态图支持 | 静态图（需 trace） | 静态流程 | 静态图（GraphDef） | 静态图（ScriptModule） |
4.4 实时风险拦截场景的推荐策略
推荐组合： ONNX 作为核心推理格式 + 独立预处理服务（如 Feast / 自研特征引擎） + NVIDIA Triton Inference Server 作为统一 Serving 网关。该组合在延迟、可维护性、硬件弹性上取得最佳平衡。
4.5 格式转换实战要点
- ONNX 导出常见陷阱： 动态轴（batch size、序列长度）需显式标记为动态维度；自定义算子需注册 ONNX Runtime 扩展；控制流（if/loop）需使用 ONNX 原生算子或子图。
- TorchScript 导出： 使用
torch.jit.trace时需提供代表性输入，避免动态控制流被固化；torch.jit.script支持更灵活的控制流但需代码兼容。 - SavedModel 签名定义： 必须明确指定
serving_default签名的输入输出 tensor 名称与 dtype，否则 Triton 等 Serving 框架无法自动解析。 - PMML 适用边界： 仅推荐用于纯表格模型（XGBoost、LightGBM、LR）且预处理逻辑固定不变的场景；深度学习模型禁止使用 PMML。
# ONNX 导出示例（PyTorch → ONNX）
import torch
import torch.onnx
model = torch.load("risk_model.pth")
model.eval()
dummy_input = torch.randn(1, 128) # batch=1, feature_dim=128
input_names = ["features"]
output_names = ["risk_score"]
torch.onnx.export(
model,
dummy_input,
"risk_model.onnx",
input_names=input_names,
output_names=output_names,
dynamic_axes={"features": {0: "batch_size"}, "risk_score": {0: "batch_size"}},
opset_version=17,
do_constant_folding=True,
)
避坑提醒： 切勿在生产环境直接使用训练框架（PyTorch / TF Eager）进行实时推理。未序列化的动态图模式会导致每次推理都触发图编译，延迟飙升 10~50 倍，且无法享受硬件加速优化。
4.6 格式选型总结
| 场景 | 推荐格式 | 理由 |
|---|---|---|
| 多框架混合、硬件加速、长期维护 | ONNX | 跨框架、跨硬件、社区活跃 |
| 纯 PyTorch 技术栈、C++ 部署 | TorchScript | 原生支持、调试方便、延迟低 |
| 纯 TensorFlow 技术栈、TFX 流水线 | SavedModel | 生态完整、版本管理内置 |
| 传统 ML 模型、预处理流程固定 | PMML | 端到端封装、无需额外预处理服务 |
在实时风险拦截系统中，ONNX 是当前综合最优的序列化格式，尤其适合需要跨框架协作、多硬件适配、长期迭代的团队。建议将 ONNX 作为 Serving 层的标准中间格式，同时保留原生格式用于训练与调试，形成“训练原生 → 导出 ONNX → 统一 Serving”的标准化流水线。