djl-serving
deepjavalibrary/djl-serving加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：DJL Serving 系统架构图，展示前后端分离设计与多引擎调度机制
深夜，AI 工程师小张完成了一个效果惊艳的 Transformer 模型训练，准备上线给用户使用。他满心欢喜地把 PyTorch 模型文件和 Python 推理代码打包——然后问题来了：
Python 环境怎么管理？生产环境跑不起来怎么办？并发请求如何优雅处理？GPU 显存不够怎么动态扩容？多个模型要同时服务怎么统一管理？
这些问题，几乎每个 AI 开发者都遇到过。模型训练是技术活，模型部署更是。小张不想在每一个项目里都重复造轮子，他需要一把"万能钥匙"——既能跑 PyTorch，又能跑 TensorFlow，还能跑 ONNX，一个框架搞定所有主流深度学习引擎的推理部署。
这把"钥匙"，就是 DJL Serving。
DJL Serving 由亚马逊 AWS 旗下的 Deep Java Library (DJL) 团队开发和维护，是 DJL 生态系统的模型服务组件。DJL 本身是一个用 Java 编写的深度学习框架，核心目标是"让 Java 开发者也能轻松玩转深度学习"。
作为一个 Java 项目，DJL Serving 天然具备企业级特性：强类型语言保障、多线程并发友好、与 Spring Boot 等 Java 生态无缝集成。这使得它成为在企业 Java 环境中部署 AI 模型的理想选择。
项目托管于 deepjavalibrary 组织，GitHub 仓库 djl-serving 现有约 253 颗星、92 个 Fork，围绕 DJL 生态有超过 40 个相关项目，形成了完整的技术矩阵。
可以把 DJL Serving 理解为一个高级酒店的智能门卫系统。这位"门卫"具备以下能力：
DJL Serving 的系统架构分为四个核心层次：
图2：Netty 多 Handler 架构处理不同类型 HTTP 请求
前端基于 Netty 网络库构建，这是 Java 生态中最成熟的高性能网络框架。Netty 使用非阻塞 I/O，能够轻松处理上万并发连接，而不会像传统多线程服务器那样耗尽线程资源。
前端通过多个 HttpRequestHandler 组件分别处理：
这种 Handler 链式设计非常优雅：新增一种协议支持，只需实现一个新的 Handler 并注册到 pipeline 中，无需改动核心逻辑。
Workflow 是 DJL Serving 的编排层，允许将多个模型和预处理/后处理代码组合成一个执行计划。例如，一个典型的图文生成工作流可能是：文本编码模型 → 图片生成模型 → 图片增强模型，DJL Serving 自动管理模型间的数据流转和依赖关系。
每个 Workflow 对应一个端点（Endpoint），一个 Endpoint 下可以注册多个 Workflow 版本，实现蓝绿部署和灰度发布。
WLM 是 DJL Serving 的后端核心，负责：
模型文件存放在配置目录中，启动时自动扫描加载，也支持运行时通过 Management API 动态注册/卸载模型。模型可以是本地文件，也可以是远程 URL（自动下载）。
DJL Serving 开箱即用支持的模型格式：
| 模型格式 | 适用场景 | 支持引擎 |
|---|---|---|
| PyTorch TorchScript | 通用深度学习 | DJL PyTorch Engine |
| TensorFlow SavedModel | TensorFlow 模型 | DJL TensorFlow Engine |
| ONNX | 跨框架部署 | DJL ONNX Runtime Engine |
| Python Script | 快速实验 | DJL Python Engine |
通过插件扩展还可以支持：XGBoost、LightGBM、Sentencepiece、fastText/BlazingText 等。
最简单的方式，一行命令即可启动 DJL Serving 完整服务：
docker run -itd -p 8080:8080 deepjavalibrary/djl-serving
Dockerfile 使用 Ubuntu 22.04 + Java 17 基础镜像，多阶段构建分离了基础镜像和 CPU 全量镜像，CPU 全量镜像内置了 PyTorch、scikit-learn、XGBoost、ONNX Runtime 等主流依赖。
brew install djl-serving
brew services start djl-serving
curl -O https://publish.djl.ai/djl-serving/djl-serving_0.30.0-1_all.deb
sudo dpkg -i djl-serving_0.30.0-1_all.deb
安装 management-console 插件后，可通过 Web 界面直观查看模型状态、管理端点、监控推理指标，适合不熟悉命令行的用户。
DJL Serving 提供标准的 RESTful API：
POST /predictions/{model_name}：推理请求GET /models：查询所有已加载模型POST /models：动态注册新模型DELETE /models/{model_name}：卸载模型GET /pings：健康检查兼容 AWS SageMaker 推理 API 规范，可无缝迁移在 SageMaker 上运行的推理代码。
项目使用 Gradle Kotlin DSL 管理多模块构建：
engines/python：Python 引擎模块，通过子进程方式运行 Python 代码（隔离 JVM 与 Python 运行时）wlm：WorkLoadManager 模块，封装了线程池、批处理、扩缩容逻辑plugins：插件系统，支持 gRPC、KServe、静态文件服务等扩展serving：核心服务模块，包含 Netty 前端和 ModelManagerNetty 的 Epoll（Linux）/Kqueue（macOS）原生传输器使用操作系统级 I/O 多路复用，相比 Java NIO 有更高的吞吐量和更低的延迟。代码中对 Netty 版本有精确控制（通过 BOM 统一管理），避免了依赖冲突。
项目维护了超过 15 个 GitHub Actions workflow，覆盖单元测试、集成测试、SageMaker 基准测试、Docker 镜像发布、夜间构建等场景，体现了企业级的工程成熟度。
尽管 DJL Serving 功能强大，也存在一些局限：
Java 生态绑定：对于非 Java 技术栈的团队，学习和运维成本较高。Java 17 的依赖管理在容器化场景下可能带来额外的镜像体积。
Python 引擎的进程隔离开销：Python 引擎通过子进程方式运行（通过 djl_python_engine.py），每次推理都有序列化/反序列化的 IPC 开销，不如原生 JVM 引擎高效。
大模型支持有限：官方文档中 LMI（Large Model Inference）部分指向较新的功能（如 TensorRT-LLM 集成），但在大模型（LLM）场景下，竞争项目如 vLLM、TGI（TGI）、Text Generation Inference 更加成熟。
文档更新节奏：README 中示例版本为 0.30.0，但仓库中可见更多最新功能，需要查阅 docs 目录和 nightly 构建版本才能获取最新能力。
DJL Serving 代表了"企业级 AI 推理平台"的发展方向：
作为 AWS 官方支持的推理引擎，DJL Serving 与 AWS SageMaker 深度集成，在云端部署场景下有完整的 SRE 支持和 SLA 保障。对于已有 Java 技术栈的企业，它是将 AI 能力引入生产环境的低门槛选择。
本报告基于 GitHub 仓库 deepjavalibrary/djl-serving (master分支) 自动生成。