ai-serving

让 PMML 和 ONNX 模型轻松上线的推理服务引擎

你有没有遇到过这样的困境：训练了几天几夜的机器学习模型，效果非常好，结果上线时发现不知道怎么部署——用 Flask 包装太慢，用 TensorFlow Serving 配置又太复杂，偏偏模型还不是 TensorFlow 训练的？

AI-Serving 就是来解决这个问题的。它是一个专门为 PMML 和 ONNX 这两种开放标准模型格式打造的推理服务引擎，一行命令就能把你的模型变成 HTTP 接口或 gRPC 接口，直接对接生产系统，不需要写一行胶水代码。

项目背景：模型部署的「最后一公里」

2019 年，AutoDeployAI 团队在为企业搭建机器学习平台时发现：模型训练工具越来越多，训练完的模型却很难低成本、高效率地部署到生产环境。当时市面上的推理服务器要么只支持特定框架（如 TensorFlow Serving），要么需要大量定制开发。

团队决定做一个「通用」的方案——不绑定任何训练框架，而是支持业界公认的两种开放标准：

• PMML（Predictive Model Markup Language）：DMG 組織维护的 XML 标准，被 SPSS、SAS、R、Python sklearn 等几乎所有主流 ML 工具支持，是传统机器学习的「通用语言」
• ONNX（Open Neural Network Exchange）：微软和 Facebook 联合发起的开放标准，目标是让任意框架训练的神经网络模型可以自由流转，已成为深度学习模型互操作的事实标准

这样无论你用 XGBoost、LightGBM 训练的传统模型，还是用 PyTorch、TensorFlow 训练的神经网络，都能通过同一套接口部署上线。AI-Serving 应运而生，GitHub 仓库于 2019 年创建并持续维护至今。

核心技术：双引擎推理架构

AI-Serving 的推理能力来自两大底层引擎的深度集成。

PMML 引擎：即插即用的传统 ML

项目通过集成 PMML4S 库（同样是 AutoDeployAI 团队开发的开源库）来支持 PMML 模型。PMML4S 纯 Scala 实现，运行在 JVM 上，无需任何原生依赖，直接解析 PMML XML 文件即可执行推理。

这意味着 PMML 模型在 AI-Serving 中的部署几乎没有额外开销——上传模型文件，服务器自动识别并加载，没有任何编译或环境配置步骤。

ONNX 引擎：高性能神经网络推理

对于 ONNX 模型，AI-Serving 集成的是 Microsoft ONNX Runtime（当前版本 1.22.0），这是目前业界最快的 ONNX 模型推理引擎之一。ONNX Runtime 由微软维护，支持 CPU/GPU 多后端，包括 CUDA、TensorRT、DNNL、DirectML 等。

关键的是，ONNX Runtime 的 x64 架构 CPU 和 GPU 版本都已经发布到 Maven Central，AI-Serving 通过 Maven 依赖直接引用，无需手动编译原生库。默认使用 CPU 加速（OpenMP），加上 -Dgpu=true 参数即可切换到 CUDA GPU 模式。

动态批处理：GPU 利用率的黑科技

AI-Serving 对 ONNX 模型还支持动态批处理（Dynamic Batching），这是提升生产吞吐量的关键特性。在 model.conf 中可以配置：

• max-batch-size：单批最大样本数（对支持动态输入形状的模型生效）
• max-batch-delay-ms：等待凑批的超时时间

也就是说，即使单个请求只有一张图片，服务器也会在不超过延迟阈值的前提下，等待更多请求到来后合并成一批发推理，从而显著提高 GPU 并行效率。

API 设计：REST + gRPC 双协议

AI-Serving 同时暴露 REST API 和 gRPC API 两套接口，这在工业级推理系统中是标准做法——REST 用于调试和简单集成，gRPC 用于高性能、低延迟的生产流量。

v1 API：经典推理协议

v1 REST API 遵循经典的 KFServing v1 推理协议：

• PUT /v1/validate — 上传并验证模型，返回模型输入输出元数据
• PUT /v1/models/{name} — 部署模型
• DELETE /v1/models/{name} — 下线模型
• GET /v1/models — 查询所有已部署模型及版本
• POST /v1/models/{name}[/versions/{ver}]/infer — 推理预测

推理请求支持 JSON 和 Protobuf 两种格式，通过 Content-Type 头区分。gRPC 端同样定义了完整的 protobuf 接口规范（见 ai-serving.proto），支持单次推理和流式推理。

v2 API：全面兼容 KServe

v2 REST API 则完全兼容 KServe Open Inference Protocol，这是云原生推理领域的权威标准。v2 API 的 Predict 接口与 KServe 完全对齐，使得 AI-Serving 可以无缝替换 KServe 的推理节点，享受到 KServe 生态的一切工具链（模型网关、版本管理、A/B 测试等）。

这种双版本兼容策略非常聪明：老系统可以继续用 v1，新建设的云原生系统可以直接用 v2，两不耽误。

架构解析：Actor 模型驱动的并发设计

AI-Serving 的 HTTP 服务层基于 Akka HTTP（10.5.3）构建，这是akka生态的旗舰级 HTTP 框架。Akka 基于 Actor 模型，天然适合高并发、低延迟的网络服务——每个请求不会阻塞线程，服务器可以轻松应对上万并发连接。

gRPC 服务层则基于 ScalaPB（Scala Protocol Buffers），自动从 .proto 文件生成类型安全的 Scala gRPC 客户端和服务端代码。

整个系统的并发模型：

• Akka Actor System 作为 HTTP 层的并发基础，ai-dispatcher 配置了线程池（默认使用所有 CPU 核心）
• 每个模型的推理在独立的 Actor 中执行，天然支持多模型并发推理
• ONNX Runtime 的执行模式可选顺序执行（sequential）或并行执行（parallel）

应用配置通过 application.conf 管理，HTTP/gRPC 端口、ONNX Runtime 后端、线程数、日志级别等均可通过 Java 系统属性或独立配置文件覆盖。

部署体验：Docker 一键启动

AI-Serving 提供官方多阶段 Dockerfile，内存占用约 2GB，构建后的镜像包含完整的 JVM 环境、ONNX Runtime（CPU 或 GPU）和模型推理服务。

部署流程：

1. 拉取镜像：docker pull autodeployai/ai-serving
2. 启动容器：docker run -p 9090:9090 -p 9091:9091 autodeployai/ai-serving
3. 等待约 30 秒（模型预热），服务即就绪

服务器默认监听 0.0.0.0:9090（HTTP）和 0.0.0.0:9091（gRPC），模型存储目录为 /opt/ai-serving/models。也可以直接用 JAR 包运行，只需 JDK 17 以上即可。

不过需要注意：源码构建需要安装 SBT（Scala Build Tool），构建时间较长（首次约 10-20 分钟），生产环境推荐直接使用官方预构建镜像。

实战演示：MNIST 手写数字识别

以 ONNX 格式的 MNIST 模型为例，整个部署推理流程非常简洁。

首先启动 AI-Serving，然后将 mnist.onnx 模型文件放入指定目录，AI-Serving 会自动扫描并加载模型。通过 REST API 发送推理请求：

curl -X PUT http://localhost:9090/v1/models/mnist   -H "Content-Type: application/octet-stream"   --data-binary @mnist.onnx

curl -X POST http://localhost:9090/v1/models/mnist/infer   -H "Content-Type: application/json"   -d '{"X": {"columns": ["input"],"data": [[0.1, 0.4, ...]]}}'

模型元数据（输入输出 shape、类型）通过 v2 API 也可以直接查询，支持 Open Inference Protocol 规范的对接工具直接集成。

图1：ONNX MNIST 模型推理示意（上：输入手写数字；下：推理结果）

对于传统机器学习模型，AI-Serving 还支持 PMML 格式的 XGBoost 模型（如经典的 Iris 分类任务），工作流程完全一致，只需更换模型文件格式即可。

图2：Iris 数据集 PMML XGBoost 模型推理示意

局限与注意事项

1. 无 Web UI：AI-Serving 定位是后端推理引擎，没有提供可视化界面，所有交互通过 API 完成。对于需要快速调试的可视化场景，需要配合其他工具使用。

2. 模型热更新有限：虽然支持 API 部署/下线模型，但不支持在线切换模型版本（需要通过手动替换文件目录实现），在需要灰度发布的场景下需要额外的负载均衡策略。

3. 源码构建门槛：Scala + SBT 的构建链路对习惯 Python/Go 的开发者来说有一定学习成本，但 Docker 用户可以完全绕过这个问题。

4. 生态绑定：项目由 AutoDeployAI 维护（非 Apache 基金会官方项目），长期活跃度取决于公司战略，建议关注 release 频率和社区活跃度再决定是否用于核心生产系统。

行业意义：连接训练与生产的桥梁

AI-Serving 解决了一个很实在的问题：模型训练框架百花齐放，但推理服务却没有统一标准。TF Serving、Triton、TorchServe 各有各的接口，换一个框架就得重新适配一遍推理服务。

AI-Serving 的思路是「不绑定训练框架，而是拥抱开放标准」——PMML 和 ONNX 都是业界认可的开放标准，得到了几乎所有主流 ML 工具链的原生支持。这意味着无论数据科学团队用什么工具训练模型，DevOps 团队只需要维护一套推理服务。

特别值得一提的是 v2 API 对 KServe Open Inference Protocol 的完整兼容，这让它成为了一个可以在 Kubernetes 原生环境中即插即用的推理服务组件，配合 KServe 的模型网关、版本管理、A/B 测试能力，可以构建完整的 MLOps 推理平台。

总体来看，AI-Serving 是一个专注于 PMML/ONNX 模型推理的专业工具，代码质量高、文档完善、特性丰富，适合需要跨框架统一推理服务的团队。不过对于纯 TensorFlow/PyTorch 用户，TF Serving 或 Triton 可能是更成熟的选择。