Spring Boot 3 + GraalVM AOT在ARM工控机上跑YOLO的实践

去年年中，项目组要把一批边缘目标检测任务从云端算力盒子迁到现场工控机上。设备用的是飞腾系ARM处理器，系统是Linux，原来每台设备都要按月租GPU推理服务，量一多成本就压不住。迁移时我们没有走最常见的Python推理栈，而是用Spring Boot 3 + GraalVM AOT编译出的Java单文件服务来跑YOLO检测。最终产物一个可执行文件约50MB，冷启动稳定在200ms左右，5台设备实测跑了半年，综合TCO算下来省了大约4.5万元。

这篇文章把这次迁移的关键点都记录下来：为什么在边缘端选Java、Spring Boot 3怎么和GraalVM配合、native-image编译遇到的那几个坑、飞腾ARM工控机上的实测调优，以及那笔4.5万元到底是怎么算出来的。如果你也在做类似的边缘AI落地，尤其是硬件平台不是x86、又要长期稳定运行的场景，这份实操记录应该能帮你省不少时间。

1. 为什么在边缘选Java跑YOLO：两笔账算完就不纠结了

1.1 现场设备约束

先交代一下实际环境。项目有5个独立工位，每个工位需要实时检测视频流里的目标，比如安全帽、人员闯入、吸烟行为这类。现场放的是飞腾ARM工控机，内存4GB，本地磁盘64GB，CPU是8核心ARMv8架构。这类设备的特点是功耗低、体积小、没有风扇，但算力比同价位x86弱不少，尤其是浮点性能。

原来的方案是每台设备连一个云端GPU推理实例，图片传上去、结果返回来。链路一长就有两个问题：一是网络抖动导致检测结果回传延迟不稳定，二是每月的算力租赁费是固定支出，跟业务量没关系。后来决定把推理全部搬到工控机本地。第一个想到的方案自然是Python + PyTorch + YOLO，但实测下来很尴尬：冷启动要5到10秒，内存占用轻松超过2GB，ONNX Runtime或PyTorch的依赖包加起来几百MB，现场设备只有4GB内存和64GB磁盘，虽然能跑，但长期运行容易被日志和临时文件撑爆。

这时候才开始认真比较Java方案。Java在服务端有天然优势：成熟的开发框架、稳定的内存管理、完善的守护进程生态。但Java跑YOLO有个短板，常见推理库对Java的支持不如Python好，而且传统JVM模式启动慢、内存占用高。直到看到Spring Boot 3对GraalVM Native Image的原生支持，才觉得这条路能走通。AOT编译后不用JVM和JIT预热，启动时间从秒级降到毫秒级，内存占用也大幅度降低，正好卡在工控机的资源边界内。

1.2 方案对比

做个简单对比表格，把三种路线放在一起看：

从表里能看出来，GraalVM AOT路线最大的代价是构建过程的复杂性，但换来的是部署、启动、内存三项指标全面改善。对边缘设备来说，这三项决定了能不能稳定长期运行。后面几节会详细说构建时踩的坑，但总体结论是：在5台设备上跑半年之后，构建期多花的时间早已通过部署和运维省回来。

2. Spring Boot 3 + GraalVM AOT：构建可执行文件的完整链路

2.1 工程结构与依赖

先搭工程。Spring Boot 3要求Java 17以上，GraalVM Native Image要求使用GraalVM对应版本的JDK。我在构建机上装的是GraalVM for JDK 21的Linux AArch64版本，注意AArch64版本非常关键，因为最终要部署到飞腾ARM平台，而native-image的产物和宿主架构绑定，最好在目标架构的构建机上编译。

Maven工程的核心依赖如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.microsoft.onnxruntime</groupId> <artifactId>onnxruntime</artifactId> <version>1.17.3</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

这里要说明一下，我用的推理引擎不是PyTorch，而是ONNX Runtime。YOLO模型导出成ONNX格式之后，用ONNX Runtime的Java API加载推理。理由有三个：ONNX Runtime官方提供了Java接口；发布包自带各平台预编译native库；推理延迟在ARM CPU上比PyTorch更可控。YOLOv8s这类轻量模型经过ONNX导出后，模型文件本身只有6MB左右，非常适合塞进单文件。

2.2 编写YOLO推理接口

工程里我写了一个极简的检测服务，Controller接收上传图片，返回检测框坐标、类别和置信度。核心逻辑分三步：图片预处理、模型推理、后处理NMS。

@RestController public class DetectController { private final OrtEnvironment env; private final OrtSession session; public DetectController() { this.env = OrtEnvironment.getEnvironment(); OrtSession.SessionOptions options = new OrtSession.SessionOptions(); // 限定4线程，避免工控机CPU被占满 options.setIntraOpNumThreads(4); this.session = env.createSession("yolov8s.onnx", options); } @PostMapping(value = "/detect", consumes = MediaType.MULTIPART_FORM_DATA_VALUE) public DetectionResult detect(@RequestParam("image") MultipartFile file) throws Exception { float[][][] input = preprocess(file.getBytes()); OnnxTensor tensor = OnnxTensor.createTensor(env, input); OrtSession.Result output = session.run(java.util.Map.of("images", tensor)); float[][] rawOutput = (float[][]) output.get(0).getValue(); DetectionResult result = postprocess(rawOutput); tensor.close(); return result; } }

预处理主要是把图片缩放填充到640x640，转换RGB顺序，做归一化。后处理则是把模型的1x84x8400输出解析成检测框，过滤低置信度，再用NMS合并重叠框。这段代码本身不复杂，难点全在编译成native-image之后的运行环境适配，也就是第三节的内容。

2.3 从Jar到Native单文件

Spring Boot 3开始，原生镜像构建直接使用GraalVM提供的native-maven-plugin，不需要再引入单独的Spring Native项目。在pom.xml的build节点加上这个插件即可：

<build> <plugins> <plugin> <groupId>org.graalvm.buildtools</groupId> <artifactId>native-maven-plugin</artifactId> <configuration> <mainClass>com.example.yolo.YoloApplication</mainClass> </configuration> </plugin> </plugins> </build>

构建命令很简单：

./mvnw -Pnative native:compile

第一次编译相当慢，在32核ARM构建机上跑了8分钟。产物生成在target目录下，名字是项目名，没有后缀。这个文件就是最终的部署单元，包含Spring Boot应用、YOLO模型和ONNX Runtime的native库，约50MB。部署时只需把这个单一文件拷贝到工控机，直接执行即可，系统里不用安装JDK或Python环境。

3. native-image编译踩下的三个坑

3.1 坑一：Spring AOT处理不了的Jackson反射

第一个问题出现在序列化阶段。Controller返回的DetectionResult对象包含List、Float等字段，Jackson在native-image下不能像JVM模式那样通过运行时反射自动发现类和字段。第一次编译成功后启动没问题，但访问接口直接抛错，报找不到Jackson序列化器。

根因是GraalVM的Native Image为了减少体积和提升启动速度，会静态分析代码，反射调用默认需要显式声明。Spring Boot 3的AOT引擎能处理大部分Spring自身配置，但对自定义业务对象的反射无能为力。

解决方式是实现Spring的RuntimeHintsRegistrar接口，在启动时注册反射信息：

public class DetectionRuntimeHints implements RuntimeHintsRegistrar { @Override public void registerHints(RuntimeHints hints, ClassLoader classLoader) { hints.reflection() .registerType(DetectionResult.class, MemberCategory.values()); hints.resources() .registerResource(new ClassPathResource("yolov8s.onnx")); } } @SpringBootApplication @ImportRuntimeHints(DetectionRuntimeHints.class) public class YoloApplication { public static void main(String[] args) { SpringApplication.run(YoloApplication.class, args); } }

排查过程其实比解决更花时间。先看native-image构建日志里的reflect-config配置，再对照接口调用栈逐层找反射入口。后来我在构建参数里临时加了-H:+ReportExceptionStackTraces，才能定位到Jackson的反射链。这个问题一旦解决，其他自定义POJO的反射都能按同样方式注册。

3.2 坑二：ONNX Runtime的native库打不进镜像

第二个坑是ONNX Runtime的Java包结构问题。onnxruntime的jar包里有/linux-aarch64/libonnxruntime.so，运行时会自动解压到临时目录加载。但在native-image下，jar里的资源默认不会全部包含进可执行文件，导致运行时找不到so库。

现象是启动不报错，第一次调用session.run时抛UnsatisfiedLinkError。排查时先用native-image --dry-run确认资源包含情况，再用-H:Log=registerResource输出注册日志，发现jar里的so文件确实没有被纳入。

解决方式是在native-maven-plugin的buildArgs里加资源包含规则：

-H:IncludeResources=.*libonnxruntime.so -H:IncludeResources=.*yolov8s.onnx

这样构建时会把ONNX Runtime的native库和模型文件都作为资源写入可执行文件。运行时ONNX Runtime的LibraryLoader会从资源里解压so到临时目录再加载。这里有个细节，如果通过System.loadLibrary直接加载全局so，可能会与Spring Boot的资源提取逻辑冲突，建议保持官方LibraryLoader的默认解压行为，只负责把资源包含进镜像。

3.3 坑三：JNI依赖配置与libonnxruntime.so加载顺序

第三个坑是关于JNI配置的。ONNX Runtime Java接口底层通过JNI调用C++库，而native-image默认不开放JNI，需要显式开启并注册JNI相关的类。如果没配，启动阶段偶发性崩溃，报错信息五花八门，有时是NoClassDefFoundError，有时是SIGSEGV。

为了彻底定位，我做了两步。第一步，确认构建参数里有--enable-jni；第二步，手动补充jni-config.json，把ONNX Runtime涉及的类加载入口注册进去。在native-maven-plugin的配置里指向这个文件：

[ { "name": "com.microsoft.onnxruntime.OrtSession" }, { "name": "com.microsoft.onnxruntime.OrtEnvironment" } ]

同时把so文件的加载时机提前，不要让它在第一次请求时才触发。可以在主启动类里写一段静态加载逻辑，确保进程一开始就完成native库初始化：

static { try { // 触发标椎的LibraryLoader加载流程 Class.forName("com.microsoft.onnxruntime.OrtEnvironment"); } catch (ClassNotFoundException e) { throw new RuntimeException(e); } }

这一步解决后，运行进程稳定了，不再出现随机崩溃。整体来看，这三个坑都是native-image的典型问题：反射、资源、JNI。花时间最多的是JNI，因为崩溃发生在运行时，留给排查的信息量很少。

4. 飞腾ARM工控机上的实测数据

4.1 构建与基础参数实测

先看一组构建阶段的关键参数。构建机是ARM架构Linux，32核，内存64GB。使用GraalVM for JDK 21的AArch64版本，编译命令加了-O3优化。同一个工程在JVM模式下打包成jar是95MB，加上运行需要的JRE，部署包至少150MB；而GraalVM native-image编译出单文件约50MB。这个体积包含了约6MB的YOLO模型和约14MB的ONNX Runtime native库。

编译时间第一次8分15秒，后续开启增量缓存后缩短到5分半左右。如果模型或代码频繁变动，这个编译时间会比较痛苦，所以建议尽量把模型文件作为资源常量对待，不要在开发期频繁换模型。

4.2 冷启动和推理延迟

部署到飞腾8核ARM工控机上之后，我记录了JVM模式和native模式的实际表现。测试方法是从进程启动命令执行开始计时，到HTTP端口能响应健康检查结束，统计十次取中位数：

冷启动从3.9秒降到198毫秒，改善接近20倍。这个提升直接解决了现场设备断电重启后需要尽快恢复服务的问题，之前每次断电恢复要等半分钟，现在基本是一瞬间。

推理延迟方面，native模式比JVM模式还略微好一点，消除了JIT预热波动。前50帧JVM模式下的延迟会在150ms到250ms之间跳，native模式则稳定在115到130ms。对于工业现场的视频流检测来说，稳定比峰值更重要。

4.3 调优细节

在飞腾平台上做了一些针对性调优。首先是线程数控制，ONNX Runtime默认使用所有CPU核心，但工控机还有其他业务服务，我在创建Session时把线程数限定为4，保证检测延迟和系统负载的平衡。如果工控机是4核，建议线程数设为2或3。

其次是内存参数调整。native-image产物没有JVM的堆参数配置一说，但ONNX Runtime的堆外内存需要关注。当并发请求量大时，OnnxTensor创建频繁，容易出现堆外内存增长。我在代码里用try-with-resources确保每个tensor都及时释放：

try (OnnxTensor tensor = OnnxTensor.createTensor(env, input); OrtSession.Result output = session.run(Map.of("images", tensor))) { return postprocess((float[][]) output.get(0).getValue()); }

这比手动close更可靠，也能避免异常路径上的资源泄漏。

最后是编译参数。为了在目标ARM平台上稳定运行，我用了--march=compatibility。不要为了性能随便开--march=native，因为构建机和现场工控机的ARM处理器微架构可能不完全一样，一旦启用native指令集优化，程序可能在构建机上跑得好好的，换到现场就非法指令崩溃。

5. 半年省4.5万的TCO拆解

5.1 对比对象和统计口径

说完技术，回到标题里的那笔经济账。4.5万不是单纯的电费节省，而是从项目整体拥有成本角度做的对比。对比对象是原来的方案：每台工控机配一块独立GPU并租用云端推理服务，加上edge设备现场的部署调试，以及后续每个月依赖升级和现场修复的人工成本。

统计口径是半年。原来的GPU硬件按3年折旧，新方案购买的飞腾ARM工控机也按3年折旧。电费按照工业电价1.2元/度估算。人力成本只计算与推理服务部署、重启、排障相关的差旅和工时。

5.2 明细表

按这个表算，新方案半年成本约0.56万，原方案约5.05万，差额4.49万，再加上首次部署时新方案节省的那次GPU环境调试差旅，基本就是4.5万。这里面的核心变量很清晰：不再租云GPU、硬件采购成本大幅降低、电费少了一个数量级、运维从每月出差变成远程替换。

5.3 真正影响省钱的关键因素

拆开看，最大头是云GPU推理服务，占了2.4万。这也是边缘AI项目最常见的成本陷阱：算力租赁是持续支出，业务运转越久，租赁越贵。其次才是硬件折旧差和电费差。很多人只盯着电费，实际上电费才省了0.45万左右，真正的大头是算力和运维。

另一个容易被忽略的是单文件部署带来的隐性成本节省。原来部署一个Python推理服务，要在工控机上配Python版本、装依赖、处理ONNX Runtime底层库的兼容性，稍微有点问题就得现场调试。现在一个可执行文件拷过去、给执行权限、运行，三步搞定。半年内只出差过一次，还不是因为故障，而是现场要增加一个摄像头点位。

6. 这套方案的边界与后续扩展建议

6.1 什么场景别硬上

GraalVM AOT虽然好，但并不是所有边缘AI场景都适合。如果你的模型是PyTorch动态图且没有导出ONNX，或者经常在部署现场调试模型参数，那不建议用这套方案。每次改模型、改代码都要重新走native-image编译，构建时间5分钟起步，迭代体验远不如Python即时运行。

另外，如果业务逻辑大量依赖反射、动态代理、自定义类加载器，native-image的兼容性会非常难受。Spring框架本身已经被AOT处理得很好，但第三方Jar不一定。我遇到过几个通用的Apache组件在native-image下需要额外配置，无形中增加了维护成本。

还要关注模型大小。YOLOv8s的ONNX模型约6MB，打进去完全没问题；如果换成YOLOv8x，模型文件将近60MB，最终产物可能超过120MB，内存占用也会涨到接近1GB，4GB内存的工控机就开始紧张了。这时候需要先做模型量化或剪枝，把模型压到轻量级再上AOT。

6.2 后续硬件加速的扩展思路

这套方案后续还有明显升级空间。现在ONNX Runtime只跑CPU，飞腾ARM平台如果集成NPU或者配合独立的推理加速卡，可以通过ONNX Runtime的Execution Provider把部分算子卸载到NPU。代码层面只需要在SessionOptions里添加对应的EP配置，业务接口可以保持不变。

如果下一步检测延迟要求更高，我可能会在飞腾平台上试验半精度推理或INT8量化。INT8量化后的YOLOv8s模型体积可以压缩到2MB左右，推理延迟预计能再降低40%。前提是现场的检测精度能接受，需要在数据集上重新验证mAP。

另外一个实际操作层面的建议：如果未来要扩展到几十台设备，建议把构建好的单文件和版本号一起放到内部仓库，每台设备用远程脚本拉取后替换执行。这样所有设备同时更新，避免现场一台台改。

就我个人这次的实际体验而言，Spring Boot 3 + GraalVM AOT让Java在边缘AI这个被Python主导的领域里真正站稳了脚跟。它不是银弹，但它把部署、启动、内存三个运维痛点一次性解决了。如果你手头也有一批ARM工控机要做类似的事，先把模型固定下来，再把native-image的三个坑提前绕开，剩下的收益会随着设备数量和运行时间慢慢放大。