惚兮模型训练好，只是万里长征第一步。真正让模型产生价值的，是把它跑进业务系统里，让用户在点击、下单、审核这些真实动作中获得预测结果。这篇博文就聊这个：怎么把一个训练好的机器学习模型，稳稳地接进业务系统。
这个问题看着简单，实际操作时坑不少。训练环境里跑个离线推理 demo 是一回事，放到线上应对真实流量是另一回事，模型推理延迟、服务可用性、版本更新、回滚机制、监控告警，每一项都要单独设计。我从自己的实践经历出发，把整个链路拆开讲清楚，包括方案选型、格式转换、服务封装、系统集成和问题排查，希望对正在做类似事情的朋友有帮助。
1. 部署形态选择：先想清楚模型要住在哪
1.1 三种主流部署形态对比
把模型嵌进业务系统，第一件事不是写代码，而是决定模型以什么形态存在。我见过不少团队一上来就选 TensorFlow Serving，结果业务量根本用不到这么重的组件，白白增加运维成本。反过来也有团队图省事直接把模型打进业务进程，结果每次模型更新都要全量发版，卡得苦不堪言。
目前主流的部署形态大概有三种。
第一种是内嵌进程式，直接在业务服务里加载模型文件，调用时用模型框架的 API 做推理。这种方案实现最简单，不用额外起服务，适合模型较小、调用频率不高的场景。举个例子，一个后台管理系统的垃圾评论识别模块，模型文件几十兆，调用量每秒几次，直接把 pickle 或 joblib 文件加载进 Python 服务里，完全够用。缺点也很明显：模型推理占用的 CPU 和内存和业务代码共享，一旦出现资源争抢，互相拖累；模型更新必须重新发布整个服务，发布窗口被卡死。
第二种是独立模型服务，把模型封装成一个独立的微服务，业务系统通过 HTTP 或 gRPC 调用。这是目前最通用的做法，也是大厂的主流选择。模型服务独立部署、独立扩缩容，模型更新只需滚动发布推理服务，不碰业务代码。比如电商场景的推荐服务、风控场景的评分服务，都适合拆出来单独跑。缺点是多了一次网络调用，延迟会比内嵌高一些，同时需要一套服务治理机制保证稳定性。
第三种是边缘端集成，把模型部署到手机端、嵌入式计算设备等离用户最近的位置。这多见于移动端 App 的离线识别、智能设备的本地语音指令识别。模型需要做深度量化压缩，还要适应目标设备的算力水平，部署形态以 Core ML、TFLite、ONNX Runtime Mobile 为代表。嵌入式场景下网络成本大，但模型更新难，必须设计好热更新机制。
三种方案的取舍核心就一句话：在延迟、资源、运维复杂度之间找到业务可接受的平衡点。内嵌式最省事但不省心，独立服务看着多一跳网络但换来了解耦，边缘端是特殊赛道，常规业务系统一般不用一上来就碰。
1.2 按业务场景选型的决策逻辑
实践中我一般按三个维度来决策：模型的体积和推理耗时为第一维度，业务的调用量级为第二维度，团队的运维能力为第三维度。
模型体积在 100MB 以内、单次推理耗时在 20ms 以内、调用量 QPS 低于 50，我倾向于先考虑内嵌式。这里有个前提——业务服务本身的技术栈要能兼容模型的运行环境。比如模型是 PyTorch 训练的，业务服务是 Java 写的，那要把模型嵌进 Java 进程就比较折腾，通常需要用 DJL 或者其他框架桥接。这种情况下，即使业务量不大，拆一个独立的 Python 推理服务反而更划算。
调用量一旦上到 QPS 几百甚至上千，独立模型服务就是一个必然选择了。因为只有独立部署，才能单独做水平扩展。假设模型单次推理耗时为 15ms，单实例满负荷大约是 66 QPS，业务需要 500 QPS，那就需要 8 个左右实例，加上一部分冗余带流量波动，可能实际要上到 10 个实例。这种扩缩容如果在内嵌模式下，就意味着业务服务所有的实例都要跟着扩，成本完全不可控。
运维能力也是一个重要考量。独立模型服务意味着多一个服务要监控、要告警、要保证可用性。如果团队连基本的 Docker 部署和日志采集都没理顺，我建议先不要急着拆微服务，老老实实内嵌跑一段时间，把模型上线流程跑通，再逐步演进。这里顺便分享一个经验：第一版上线，最稳的方案往往是"内嵌起步 + 预留接口抽象"，把推理调用封装成一个接口，底层用内嵌实现，将来迁移独立服务时只需要替换实现类，业务代码不用动。这个设计成本极低，收益却非常大，我现在做任何模型集成项目都会先做这层隔离。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。