转型这事最难的不是某一门技术学不会而是前期学的东西都是散的。Python基础会了、机器学习概念也懂了、模型训练流程也跑通过但真要独立做出一个能给别人用的应用总感觉中间隔着一层东西。Week 7 这个阶段就是来解决这个问题的——把前几周散落的知识点收敛成一个可以上线的应用。这一周做的事情本质上是一次系统性收束。不是再学新算法也不是继续刷模型精度而是把之前积累的训练脚本、特征工程经验、模型调优技巧全部整合到一条完整的工程链路上从数据处理到模型推理从接口封装到容器部署。作为长期写 Java 的开发者这个阶段最大的感受是AI 工程化的难点根本不在“AI”而在“工程”二字。好在 Java 生态里那些成熟的东西——Maven、Spring Boot、Docker、监控体系——全都是现成的武器关键是知道怎么把它们和 AI 模型这条线接起来。我这次选择的主线项目是一个商品评论情感分析服务。目标很明确输入一段中文评论文本返回情感极性正向/负向和置信度用 HTTP 接口对外提供服务整个链路能跑在 Docker 容器里。这个项目虽然小但五脏俱全——有数据清洗、有模型推理、有服务封装、有性能优化正好把 Week 1 到 Week 6 学到的东西全部串起来。下面把这周的思路和实操细节完整拆开讲。1. 内容整体设计与思路拆解1.1 为什么选“评论情感分析”作为收束项目选择这个项目主要基于三点考量。第一模型本身不复杂。情感分析是一个典型的文本二分类任务用预训练的中文模型或简单微调就能达到可用水平不会把精力耗在训练过程本身。第二工程链路完整。从用户请求进来到模型推理出去中间要经过文本预处理、特征转换、推理计算、结果后处理每个环节都有实际工程问题要解决。第三便于验证效果。评论文本随手就能找到测试用例好构造结果肉眼可判非常适合用来做集成测试和效果验证。和很多转型者一开始的想法不同我并没有选择做一个图片分类或者智能问答这种看起来更“AI”的项目。核心原因是对于 Week 7 来说训练一个惊艳的模型不是目标跑通一条可复现、可维护、可部署的推理服务才是目标。评论情感分析这种“模型简单但链路完整”的项目恰恰能把工程能力练到位。练好了这条链以后换什么模型都是往这条流水线上插一个新的模块而已。1.2 从“知识点”到“应用”的整合框架前几周学习是纵向的这周需要横向串联。我的思路是把整个应用拆成四层数据层负责中文文本清洗、去重、切分以及模型输入格式的转换推理层加载训练好的模型完成文本到预测结果的转换服务层用 Spring Boot 封装 HTTP 接口处理请求参数、超时控制和异常返回部署层用 Docker 打包模型文件和 Java 服务实现一键启动。对应到 Java 开发者的优势来说服务层和部署层本来就是强项数据层和推理层是转型时补出来的短板。这周工作的核心就是把“短板补上、长板接上”——推理层怎么在 JVM 里跑起来数据层怎么和 Java 对象互相转换服务层怎么调用推理层的 API部署层怎么把整个系统装进镜像。这一整套设计和一个传统 Java Web 系统的分层架构非常像。所以转型者完全不用恐惧“AI 工程化”这个词它本质上就是把一个模型当成一个计算组件嵌进你熟悉的业务系统里。2. 工具选型解析JVM 世界里跑模型的几种路线2.1 三种模型集成方案的对比Java 生态里接入模型推理主要有三条路。我实际调研和对比后发现它们各有明确的适用场景适配不同的团队规模和部署条件。方案实现方式性能表现工程复杂度适用场景REST 调用独立推理服务用 Python 起一个 Flask/FastAPI 服务Java 侧通过 HTTP 调用中等受网络开销影响低模型迭代频繁、需要 GPU 训练环境ONNX Runtime Java API模型导出为 ONNX 格式JVM 进程内直接加载推理高无网络开销中使用 CPU 推理、需要低延迟的线上服务DJLDeep Java Library亚马逊开源的 Java 深度学习框架支持多种模型格式高中高团队纯 Java、希望避免多语言维护对于这个情感分析项目我最终选择了 ONNX Runtime Java API。原因很简单项目规模不大但要求部署简单、启动快、不依赖外部 Python 环境。抽取出的模型导出成 ONNX 后用一个onnxruntime的 JAR 包就能在 JVM 里完成所有推理工作。整个服务变成一个可执行 JAR 加一个模型文件部署成本非常低。2.2 选型背后的三个判断依据展开讲一下选型逻辑因为很多转型者会在这一步卡住。第一看团队维护能力。如果团队里 Python 和 Java 都有人REST 方案没问题如果只有 Java 团队DJL 或 ONNX Runtime 明显更合适不用额外承担一套 Python 服务的监控和运维。第二看部署环境。在 GPU 服务器上做大规模模型推理Python 生态仍然最成熟但 CPU 推理、小流量场景ONNX Runtime 在 JVM 内的表现已经非常稳定。第三看模型迭代频率。算法团队经常升级模型独立推理服务更灵活模型基本固定后打进 JVM 反而省心。顺带提一句很多人纠结性能问题时直觉上会认为 Python 的深度学习框架更高效。我实测下来在自己公司的 8 核 CPU 服务器上ONNX Runtime 处理单条短文本的推理耗时稳定在 30 到 60 毫秒足以支撑每秒几十次的请求量。对一个中小型业务系统来说这个性能完全够用。真正影响性能的反而是序列化、网络传输这些环节优化空间比模型推理本身大得多。2.3 为什么最终放弃了其他两条路线REST 调用路线我不是没用过Week 5 自学时就是用 Flask 包了一个文本分类模型再用 Spring Boot 去调用。当时最大的困扰在于Python 服务和 Java 服务要分别部署、分别监控测试环境里还要处理跨域、端口映射、服务发现的一堆问题。做 Demo 可以但一想到要“上线”这种多语言部署的运维负担立刻变得不可忽视。DJL 我也花时间评估过它能直接在 Java 里加载 PyTorch 模型设计理念非常对 Java 开发者的胃口。但当时中文预训练模型的导出链路还没有现在这么顺畅部分模型转换时容易出现算子兼容问题。相比之下ONNX 格式的兼容性更成熟我手上的模型一次性导出成功后续迭代也基本没有踩坑。所以这次实战我投了 ONNX Runtime 一票。3. 核心细节解析与实操要点3.1 数据预处理链路最容易翻车的地方文本模型的输入不是字符串而是向量化后的 token IDs。评论“这个手机电池耐用但屏幕容易花”先要做清洗再经过分词器和词表映射变成[101, 100, 120, ...]这样的整数序列还要加上 attention mask 表示哪些位置是有效内容。这一步如果处理不一致线上效果会和测试时天差地别。我踩过最亏的一个坑是训练时用 Python 的处理逻辑做了随机裁剪和丢弃但上线时 Java 端的推理代码忘了做对应处理导致线上结果比测试集低了两三个百分点。这种问题不报错、不崩溃就是效果不对排查起来极其耗费时间。所以这一周我强制自己做了一个处理逻辑对照表训练端和推理端一个字段一个字段核对确保预处理逻辑完全一致。注意训练时代码里所有“随机”的部分推理时必须全部关闭。随机裁剪、随机丢弃、随机 mask 这类操作在推理链路里要替换成确定性的逻辑否则每次请求的结果都可能不一样。另外中文文本的编码问题也要重视。HTTP 请求传过来的是带 UTF-8 编码的字符串清洗时常见的坑是半角全角符号混用、特殊空白字符隐藏其中。我建议在服务入口统一做一次归一化把所有标点符号转成半角去掉不可见控制字符。这套清洗逻辑直接复用训练数据集里写的 Python 清洗脚本的规则逐条翻译成 Java 实现。3.2 模型导出与算子兼容性检查训练用的模型是 Hugging Face 上的一个中文 BERT 轻量版本微调后导出 ONNX。导出这一步最怕碰到算子兼容性问题——模型里某些层用的算子在 ONNX Runtime 里不受支持导出过程不报错但加载时直接抛异常。我的操作顺序是先在 Python 里用torch.onnx.export导出然后用 ONNX Runtime 的 Python 接口做一次推理验证确保导出的模型结果和原始模型一致。这个验证不能省因为即使算子都支持模型里的动态轴设置错误也会导致推理时输入形状对不上。导出时有一个参数必须注意——dynamic_axes。如果不设置导出的模型会把输入序列长度固定成训练时的最大长度比如 128意味着所有新输入都会被填充或截断到这个长度很浪费算力。设置了动态轴之后输入长度可以由请求方决定短句子可以很快跑完长句子才会用满最大长度。这个优化在后续性能测试中体现得很明显。导出完成后模型文件大概在 100 到 400 MB 之间。这个体积放容器里完全没问题但要注意 Docker 构建时将模型 COPY 进镜像的路径不能写错否则启动加载模型时直接FileNotFoundException。3.3 Java 侧推理封装核心代码结构ONNX Runtime 的 Java API 用起来不复杂核心就三步加载模型、构造输入、运行推理。下面给出实际项目里的关键代码骨架照着这个结构改就可以复用到其他模型上。// 加载模型全局只加载一次 public class SentimentInferenceEngine implements Closeable { private final OrtSession session; private final OrtEnvironment env; public SentimentInferenceEngine(String modelPath) throws OrtException { this.env OrtEnvironment.getEnvironment(); // 配置 CPU 线程数不宜盲目调大 OrtSession.SessionOptions options new OrtSession.SessionOptions(); options.setIntraOpNumThreads(4); this.session env.createSession(modelPath, options); } // 核心推理方法 public SentimentResult predict(String text) throws OrtException { // 1. 文本预处理清洗 分词 转 ID ListInteger tokenIds tokenizer.encode(text); // 2. 构造定长输入BERT 类模型需要固定最大长度 int maxLen 128; long[] inputIds new long[maxLen]; long[] attentionMask new long[maxLen]; for (int i 0; i maxLen; i) { if (i tokenIds.size()) { inputIds[i] tokenIds.get(i); attentionMask[i] 1L; } else { inputIds[i] 0L; // padding } } // 3. 转换为 ONNX Runtime 的 OnnxTensor long[] shape new long[]{1, maxLen}; OnnxTensor inputTensor OnnxTensor.createTensor(env, LongBuffer.wrap(inputIds), shape); OnnxTensor maskTensor OnnxTensor.createTensor(env, LongBuffer.wrap(attentionMask), shape); // 4. 运行推理 MapString, OnnxTensor inputs new HashMap(); inputs.put(input_ids, inputTensor); inputs.put(attention_mask, maskTensor); OrtSession.Result results session.run(inputs); // 5. 解析输出情感二分类取 softmax 后概率较大的一方 OnnxTensor output (OnnxTensor) results.get(0); float[][] probs output.getFloatMatrix(); float positiveProb probs[0][1]; float negativeProb probs[0][0]; // 6. 释放资源 inputTensor.close(); maskTensor.close(); results.close(); return new SentimentResult( positiveProb negativeProb ? POSITIVE : NEGATIVE, Math.max(positiveProb, negativeProb)); } }这段代码里有几个细节值得展开。OrtEnvironment.getEnvironment()是全局单例一个 JVM 进程里只要创建一个。OrtSession也是线程安全的可以多个请求并发调用同一个 session 实例不需要每次请求都重新加载模型。setIntraOpNumThreads(4)配置的是单个算子内部并行线程数我测试了 2、4、8 三种取值4 线程在 8 核服务上综合表现最好。资源释放这块必须养成习惯。每次推理创建的OnnxTensor和OrtSession.Result都持有 native memory不 close 的话最终会导致堆外内存泄漏。这一点和 Java 里的文件流处理一个道理——用完必须关。我在服务里统一用 try-with-resources 包装推理调用确保异常路径下也能释放资源。3.4 分词器移植Python 到 Java 的无缝迁移模型用的是 BERT 类结构分词器是 WordPiece 算法。比较省事的方案是在 Java 里引入一个分词库比如 Hugging Face 官方的 Java 版本 Tokenizers它能直接加载训练时保存的 tokenizer.json 文件实现和 Python 端完全一致的分词结果。我第一次图省事想用简单的按字切分代替 WordPiece结果发现效果差了接近三个点。原因很直接预训练模型学习到的词表是按 WordPiece 子词单元建立的按字切分等于把模型的输入分布整个破坏了。所以分词这件事上没有捷径必须用和训练时相同的分词器。引入官方库后一次分词的耗时约 1 到 2 毫秒在推理耗时里占比很小。实际代码中我把分词器也设计成单例初始化时加载一次tokenizer.json后面直接复用。注意这个文件要打进 Docker 镜像最好是和模型文件放在同一个目录下路径写死成相对路径避免部署时因为路径不一致而找不到文件。4. 实操过程与核心环节实现4.1 服务层设计Spring Boot 接口封装推理引擎准备好了接下来就是把它暴露成 HTTP 接口。我用了 Spring Boot 的 WebFlux 做异步接口核心考虑是ONNX 推理是 CPU 密集操作如果走传统的 Tomcat 线程池同步阻塞模型线程数很容易被推理耗时拖住。WebFlux 异步模型能让有限的线程处理更多请求配合subscribeOn把推理任务调度到独立线程池响应表现更稳定。接口设计上很简单但很多细节是在实践中磨出来的。请求参数如果为空、超过最大长度、或包含非法字符都在入口统一校验返回统一的错误码结构。这种做法和传统 Java 接口开发完全一致但一定要记得为推理单独设置超时时间——模型推理偶尔会出现长尾延迟超过 3 秒的请求直接返回超时错误避免拖垮整体响应。PostMapping(/api/v1/sentiment) public MonoResponseEntityResultSentimentResponse analyze( RequestBody SentimentRequest request) { return Mono.fromCallable(() - { // 校验逻辑省略text 非空、长度限制等 SentimentResult result inferenceEngine.predict(request.getText()); return new SentimentResponse(result.getLabel(), result.getScore()); }) .subscribeOn(Schedulers.boundedElastic()) .timeout(Duration.ofSeconds(3)) .map(resp - ResponseEntity.ok(Result.success(resp))) .onErrorResume(ex - { log.error(inference failed, ex); return Mono.just(ResponseEntity.status(500) .body(Result.error(internal_error))); }); }项目里用到的线程池配置也值得记一笔。我给推理分配了一个独立线程池核心线程数设为 CPU 核数一半左右最大线程数设为 CPU 核数。原因是推理操作是计算密集型的线程数超过 CPU 核数不仅不会加快速度反而会引入上下文切换开销。IO 密集型业务接口的线程池策略在这里不适用这个认知是转型过程中比较容易忽略的。4.2 单测与集成测试模型效果的验证方法很多人写完服务直接上线这是转型期最容易犯的错。模型不是普通代码它的表现具有概率性——输入变化一点点输出可能完全不同。所以必须建立一套针对模型服务的测试体系。我的做法分三层。第一层是离线 Golden Test提前准备 50 条覆盖典型场景的测试评论把每条评论的预期情感结果固化成测试用例。每次更新模型或预处理逻辑都跑一遍这 50 条确保没有回归。第二层是模糊测试随机生成一些乱码、表情符号、超长文本验证服务不会崩溃、异常输入能返回合理错误。第三层是压测用并发请求验证系统的吞吐量和延迟找出瓶颈点。这里特别强调一下 Golden Test 的价值。传统 Java 开发中单元测试验证的是逻辑正确性而模型服务的“正确性”很难定义。Golden Test 本质上把模型行为固化成已知输入/输出对以后任何代码改动导致这些用例输出变化都能立刻暴露。我实际经历过一次分词器版本升级后10 条用例的预测结果发生翻转正是靠这套测试才及时发现。4.3 容器化部署Docker 镜像构建实战部署阶段我选择 Docker 作为最终交付方式。核心原因是模型文件和依赖打包成镜像后部署环境完全可控不用再担心目标机器缺什么动态库。写 Dockerfile 时有一个重要的分层策略基础镜像用带 JRE 的精简镜像但模型文件单独一层 COPY。因为模型文件通常有几百 MB如果 Dockerfile 里把模型 ADD 和代码 ADD 写在同一层每次代码改动都会触发模型文件层的重建镜像构建速度会非常慢。正确的做法是分两个 COPY 指令模型文件先 COPY代码后 COPY。这样代码改动时Docker 构建系统能复用模型文件层构建时间从几分钟降到几秒。FROM eclipse-temurin:17-jre-alpine WORKDIR /app # 先复制模型文件层利用 Docker 层缓存加速构建 COPY model/onnx/ ./model/onnx/ COPY model/tokenizer.json ./model/ # 再复制业务代码 COPY target/sentiment-service.jar ./app.jar EXPOSE 8080 ENTRYPOINT [java, -Xms512m, -Xmx1g, -jar, app.jar]这里 JVM 参数我设置了初始堆 512MB最大堆 1GB。模型推理使用的内存大头在堆外ONNX Runtime 的 native memoryJVM 堆主要承载分词结果和请求对象。上线初期我试过给 2GB 堆反而在压测时因为 GC 时间过长导致响应变慢。降到 1GB 后频繁的 Young GC 反而让内存使用更平稳。这个参数需要结合自己的模型大小和服务流量去调整不要照抄任何人的配置。4.4 启动验证全流程一条命令跑通整个服务部署完成后验证从开发到生产运行流程是否顺畅是整个实战收尾的关键动作。我的运行验证清单如下本地启动 Spring Boot 应用确认模型加载无异常日志中出现模型加载耗时调用curl -X POST http://localhost:8080/api/v1/sentiment -H Content-Type: application/json -d {text:这个耳机降噪效果非常好}确认返回POSITIVEDocker 构建镜像启动容器映射端口重复步骤 2 的调用检查容器日志确认无堆外内存持续增长、无线程数异常积累。这个流程看似简单但往往能暴露不少“开发环境正常、生产环境跑不起来”的问题。比如模型文件路径是绝对路径还是相对路径Linux 容器里用户权限设置是否影响文件读取镜像内时区、字符集是否匹配。每一步验证通过后这套服务才真正具备了可交付的质量。5. 常见问题与排查技巧实录5.1 模型加载慢接口首请求超时第一次启动后调用接口直接超时。排查发现是模型加载发生在 Spring 容器启动之后、第一个请求到达时才执行模型加载耗时 10 多秒远超接口超时限制。解决方案是在应用启动阶段预加载模型。实现ApplicationRunner接口在run方法里主动调用一次推理引擎的初始化确保所有 Bean 准备好之前模型已经加载完毕。后续所有请求都能直接使用内存中的 session。这个问题暴露出一个工程习惯所有重的资源初始化都应该放在启动期完成而不是懒加载到运行时。5.2 并发一上来CPU 飙升到 100%压测时发现并发 20 个请求就能把 8 核 CPU 打满单请求耗时不降反升。用jstack看线程栈发现所有请求线程都卡在 ONNX Runtime 的推理方法里大量线程在竞争同一个 session。查资料确认ONNX Runtime 的OrtSession是线程安全的但内部存在锁竞争。解决方案有两个方向。一是创建多个 session 实例每个线程绑定自己的 session规避锁竞争。二是调整setIntraOpNumThreads让每个请求占用的线程数降低整体并发能力反而上升。我采用了方案二配合线程池限制并发线程数压测单机 QPS 从 20 提升到 70效果非常显著。5.3 中文乱码线上和本地结果不一样同样的测试文本本地返回POSITIVE容器里返回NEGATIVE。排查发现不是模型问题是容器环境的默认字符集不是 UTF-8导致 Spring 接收 HTTP 请求时参数解码错误模型拿到的是乱码文本。解决方案是在 Dockerfile 里显式声明环境变量确保 JVM 使用 UTF-8。这个坑在本地很难复现因为开发机的默认编码通常已经是 UTF-8但基础镜像的默认编码可能不同。建议所有 Java 服务容器都显式设置不要依赖环境默认值。5.4 内存缓慢增长最后一夜之间 OOM服务上线后运行稳定但内存监控曲线在缓慢爬升运行两天后在凌晨被 OOM Killer 杀掉。初步怀疑是 ONNX Tensor 资源未释放的路由泄漏检查代码后发现推理主路径确实用了 try-with-resources但异常分支里有个return语句跳过了资源释放。后来通过审查代码把所有返回值前没有关闭 tensor 的逻辑全部扫描修正并对推理方法做了资源释放的单元测试。这类问题不压测很难发现所以要养成一个习惯所有涉及 native resource 的代码无论正常路径还是异常路径都要严格保证释放。可以借助内存分析工具做上线前后的快照对比确认堆外内存曲线平稳。5.5 常见问题速查表问题现象可能原因排查手段解决方案接口超时模型懒加载看启动日志启动期预加载首请求特别慢JIT 未预热压测观察规律启动后做一次预热请求推理结果全为同一类别预处理输入异常打印 token IDs核对分词器与训练一致堆外内存不断增长推理资源未关闭堆外内存监控严格 try-with-resources并发高时耗时不降锁竞争/线程争抢jstack 分析调整算子线程数容器内中文乱码字符集不一致打印编码信息显式设置 UTF-86. 复盘沉淀与下一步扩展路径这一周的项目虽然小但把 Java 开发者转型 AI 工程化的关键能力完整走了一遍。其中最重要的收获不是模型训练技能而是建立了一条可以复用的工程链路。以后再接任何模型服务流程都是清晰的模型导出成 ONNX、写推理引擎封装、包进 Spring Boot、打成 Docker 镜像、配上监控指标。这套方法论比具体某个算法重要得多。回顾整体过程有三件事是转型者会容易忽视的。第一预处理一致性是线上效果的生死线训练端和推理端必须逐条核对第二模型服务的性能瓶颈往往不在模型本身而在资源管理和并发策略第三Docker 镜像分层和 JVM 参数调优这类“传统 Java 技能”在实际部署时反而是 AI 工程化中最值钱的能力。按照我的个人经验下一步有两个可以继续扩展的方向。一个是给服务加上模型版本的灰度发布能力——将新旧模型同时部署按比例切流量观察线上效果后再全量切换。另一个是把推理结果缓存起来对相同或相似文本命中缓存直接返回能显著降低计算开销。具体到实现前者可以引入配置中心做动态开关后者可以用 Redis 加一层结果缓存过期时间按业务容忍度设定。如果在实际操作中遇到任何问题建议按这个顺序排查先看输入文本的预处理结果是否符合预期再确认模型加载是否成功然后看推理耗时和内存曲线最后才怀疑模型本身的准确率。绝大多数“模型效果差”的问题追到根因后会发现都是工程链路某个环节的偏差而不是模型能力不够。转型到第七周最大的感受是从“会跑通”到“能上线”之间的距离确实靠一个完整项目才能跨过去。把它做好、做实后面无论是学习更复杂的模型架构还是转向其他 AI 方向这条已经踩实的工程链路都能成为你继续往前走的底座。