Android 机器学习模型平台开发实战：Chaquopy + Compose + ZeroMQ 全栈解决方案

做了几年 Android 端机器学习应用，有一个问题始终绕不开：Python 生态里现成的模型、预训练权重和数据处理库，和 Android 原生世界的 Java/Kotlin 代码之间，始终隔着一道墙。你要么用 TF Lite 把模型转换一遍再重新适配输入输出，要么自己用 JNI 封装推理逻辑，折腾一圈下来，模型迭代的爽快感全没了。我最后落地的方案，是用 Chaquopy 在 App 进程内直接跑 Python 推理代码，用 Jetpack Compose 做整套 UI 和状态管理，再用 ZeroMQ 把 Python 推理逻辑和界面进程解耦。这套组合解决了我项目中"模型更新慢、推理卡 UI、代码耦合重"三个最痛的问题。如果你也在做 Android 端机器学习平台，或者正在纠结怎么把 Python 模型塞进手机应用里，这篇文章会把完整的技术选型思路、集成步骤、通信方案和踩坑记录都摊开来讲。

1. 移动端机器学习平台的架构困境：三个绕不开的问题

1.1 模型迭代速度与原生集成的冲突

机器学习项目有一个天然节奏：数据处理脚本在 Notebook 里跑，模型训练完导出权重，接下来才是痛苦的开始。在传统 Android 集成方式下，每换一版模型，你都要经历"把 Python 模型转成 TensorFlow Lite → 处理算子兼容性问题 → 重新实现输入预处理 → 修改 native 层调用代码"这一步，少则半天，多则两三天。我做过的项目里，有一个图像分类模型因为 TensorFlow 版本升级导致算子不兼容，光修转换链路就花了一周。

Chaquopy 的思路完全不同。它把 CPython 运行时直接打包进 Android 应用里，你在 Python 侧训练好的模型、写好的推理脚本，几乎不需要改动就能在 App 内运行。这意味着模型迭代周期从"改完模型还要改 App 代码"变成了"只更新模型文件和 Python 脚本"。

1.2 UI 线程与推理任务的边界模糊

另一个常见问题是 UI 卡顿。Android 的 UI 操作必须在主线程执行，而机器学习推理通常是个吃 CPU 的重活。如果推理代码直接在 Activity 或 Fragment 里同步调用，主线程被阻塞，界面直接 ANR。很多早期项目采用"AsyncTask 包一下推理"的做法，但协程出现后这种方式就显得粗糙了——如果推理过程中用户退出页面，AsyncTask 照样在跑，回调回来时还可能碰上一个已经销毁的 View，内存泄漏和崩溃都少不了。

我用 Compose 之后，这个问题的处理方式有了质的提升。Compose 的状态模型让你天然地把"推理结果"当成界面状态来管，配合 Kotlin 协程和 Flow，从"触发推理"到"拿到结果"之间的所有调度逻辑都可以写得非常干净，而且生命周期感知是内置的。

1.3 Python 与 Kotlin 之间的数据交换效率

技术上最容易被轻视的一环，是 Python 和 Kotlin 之间的数据传递。如果你在 Kotlin 里调一个 Python 函数，传进去一张图片或者一个矩阵，底层发生的是数据从一个运行时拷贝到另一个运行时。Chaquopy 的PyObject桥接机制已经把这个过程封装得比较友好了，但如果你在代码里频繁地反复传递大数据对象，性能开销还是很可观的。

所以我把整套平台设计成了"Python 推理进程"与"Android 界面进程"两个逻辑单元。界面进程负责 Compose 渲染和用户交互，推理进程负责加载模型和跑预测，中间用 ZeroMQ 的消息通道来传指令和数据。这样的解耦让每个进程的职责单一，性能瓶颈也好定位——模型跑得慢就优化 Python 侧，界面卡了就查 Compose 的状态重组，两边互不干扰。

2. Chaquopy 深度集成实操：让 Python 运行时在 Android 里安家

2.1 Gradle 配置最容易被忽略的几个细节

Chaquopy 的接入方式不复杂，在项目级build.gradle里声明 Maven 仓库，然后在模块级配置 Python 版本和依赖。但有几个细节，文档里写得不显眼，实际坑过不少人。

// 项目级 build.gradle buildscript { repositories { maven { url "https://chaquo.com/maven" } google() mavenCentral() } dependencies { classpath "com.chaquo.python:gradle:15.0.1" } } // 模块级 build.gradle plugins { id 'com.android.application' id 'com.chaquo.python' } android { compileSdk 33 defaultConfig { applicationId "com.example.mlplatform" minSdk 24 targetSdk 33 versionCode 1 versionName "1.0" python { buildPython "python3" pip { install "numpy" install "torch" install "msgpack" } pyc { src true } } } }

第一个坑是buildPython的路径。如果你电脑上装了多个 Python 版本，Gradle 可能找到错误的那个。我建议用绝对路径，比如/usr/local/bin/python3.8，少给自己找麻烦。

第二个坑是pip依赖的版本锁定。Chaquopy 对 Python 版本有固定的支持范围，某些新版本 Python 的 C 扩展模块可能无法直接打包。我在项目初期遇到过 torch 装进真机后运行闪退的问题，最后查下来是 Python 3.9 和某个 torch 版本之间的兼容性问题。解决办法是把 Python 版本固定为 Chaquopy 官方文档推荐的版本，并且不要盲目追新。

第三个坑是包体积。Python 运行时加 numpy 加 torch，APK 体积轻松突破 100MB。如果你面向国内市场分发，这个体积是个很现实的问题。后面我会专门讲体积优化方案。

2.2 Python 依赖管理：少碰 conda，多用 pip 冻结

很多从数据科学转过来的开发者习惯用 conda 管理环境，但在 Chaquopy 的世界里，你只能通过pip来安装依赖，conda 是不支持的。这意味着你的 Python 依赖树必须能够用 pip 完整复现。

我的做法是在开发机上用一个干净的 Python 虚拟环境做依赖测试：

python -m venv ml_env source ml_env/bin/activate pip install numpy torch msgpack pip freeze > requirements.txt

然后把requirements.txt里的版本号填到 Gradle 的pip配置里。这样能保证本地调试环境和手机上的运行时环境高度一致。

另外要注意一个细节：pip的依赖如果包含 C 扩展，Chaquopy 在构建时会尝试从 PyPI 下载对应 Android 平台的 wheel 包。如果你的网络环境访问 PyPI 不稳定，构建过程会卡住。我在 CI 上专门配置了 PyPI 镜像缓存，国内团队应该都会有类似的体会。

2.3 Kotlin 调用 Python：PyObject 与数据转换的底层逻辑

Chaquopy 的核心交互方式是Python.getInstance()获取运行时实例，然后通过getModule()加载 Python 模块，最后调用模块里的函数。说起来简单，但当你开始传复杂数据时，就要深入理解PyObject的转换规则了。

// 获取 Python 实例 val py = Python.getInstance() // 加载 Python 模块 val mlModule = py.getModule("ml_engine") // 调用 Python 函数，传入图片路径和参数 val result = mlModule.callAttr("predict", imagePath, 224, 224) // 解析返回值 val label = result.toString()

这段代码能跑通，但我强烈建议不要在真实项目里这样直接调用。原因很简单：callAttr是同步阻塞的，而且跨运行时调用的开销不可忽略。如果推理耗时两三秒，主线程就卡死了。

我的做法是定义一个薄封装层，把 Python 函数调用封装成一个挂起函数：

suspend fun predictWithModel(imagePath: String, width: Int, height: Int): String = withContext(Dispatchers.Default) { val py = Python.getInstance() val mlModule = py.getModule("ml_engine") val result = mlModule.callAttr("predict", imagePath, width, height) result.toString() }

这个封装虽然简单，但它解决了一个关键问题：把 Python 调用推到了后台线程。协程的withContext保证了线程切换，Dispatchers.Default适合 CPU 密集型任务。

不过我要提醒你，如果只是这么用 Chaquopy，你很快就会遇到问题。因为所有 Python 模块共享同一个解释器实例，如果你的代码里同时有多个协程在跑推理，它们会互相阻塞。Chaquopy 的 Python 解释器有全局锁（GIL），多个线程同时调用 Python 代码时实际上还是串行执行。所以我在这个平台里做了一个重要决定：Python 推理跑在独立进程里，也就是接下来要讲的 ZeroMQ 方案。

3. ZeroMQ 通信中间层：为什么要把 Python 隔离到独立进程里跑

3.1 Chaquopy 默认运行模式的瓶颈

先说说为什么我不满足于"Kotlin 直接调 Python"这种模式。

Chaquopy 默认情况下把 Python 运行时嵌入到 App 的主进程里。这意味着 Python 代码里任何崩溃都可能直接带崩整个应用。Python 的异常机制和 native 崩溃不完全一样，虽然 Chaquopy 做了不少防护，但如果你在一个大型 PyTorch 模型推理过程中发生段错误，整个 App 没有任何缓冲余地。

另一个问题前面提到了：GIL 导致并发推理无法实现。在我的场景里，用户可能一边在上传新的测试图片，一边在查看历史推理结果，后台还可能跑着批量数据处理任务。这些任务如果共享同一个 Python 解释器，要么互相等待，要么频繁切换，体验很差。

3.2 ZeroMQ 的消息模式选型：REQ/REP 还是 PUSH/PULL

ZeroMQ 提供了多种消息模式，我在这个项目里实际用到了两种：REQ/REP 用于同步请求-响应，PUSH/PULL 用于任务分发。

// Kotlin 侧（Android 主进程） +-------------------+ REQ +-------------------+ | Compose UI 层 | --------------------> | Python 推理进程 | | ZMQ REQ Socket | <-------------------- | ZMQ REP Socket | +-------------------+ REP response +-------------------+

职责分配很清晰：Android 端是请求方，Python 端是处理方。请求发出后，Android 端挂起等待应答；Python 端收到任务执行推理，完成后返回结果。

# Python 进程侧的核心循环（伪代码） import zmq import msgpack context = zmq.Context() socket = context.socket(zmq.REP) socket.bind("tcp://127.0.0.1:5555") while True: message = socket.recv() request = msgpack.unpackb(message, raw=False) if request["type"] == "predict": result = model.predict(request["data"]) response = {"status": "ok", "result": result} else: response = {"status": "error", "message": "unknown request type"} socket.send(msgpack.packb(response))

这里有个非常重要的设计决策：把 Python 进程作为服务器，Android 端作为客户端。如果反过来，Android 主进程会需要维护一个常驻的接收线程来等待 Python 端的推送，这在生命周期管理上非常痛苦。请求-响应模式天然契合"用户触发操作，界面等待结果"的交互场景。

PUSH/PULL 模式我用于批量数据处理场景。比如用户选择一批图片做批量识别，界面不需要等待每一张的结果，而是把任务全部推过去，Python 进程按顺序处理，结果通过另一个通道回传。这在 Web 项目里常见的异步任务队列，在 Android 本地同样成立。

3.3 通信协议设计：用 msgpack 而不是纯字符串

跨进程通信的协议选择，看起来是个小决定，实际影响很大。最简单的方式是传 JSON 字符串，但有两个问题：一是序列化和反序列化开销大，尤其在图片数据量大的时候；二是没有类型安全，Kotlin 侧拿到 JSON 还得手动解析到数据类。

我最终选了 msgpack。它是二进制序列化格式，比 JSON 体积小、解析快，而且 Python 和 Kotlin 侧都有成熟库支持。

# Python 侧编码 import msgpack data = msgpack.packb({"type": "predict", "image_path": path, "params": [224, 224]}, use_bin_type=True)

// Kotlin 侧解析 import org.msgpack.core.MessagePack import org.msgpack.value.Value val packer = MessagePack.newDefaultBufferPacker() packer.packString("predict") packer.packString(imagePath) packer.packInt(224) packer.packInt(224) val bytes = packer.toByteArray()

当然，如果你对性能极致敏感，也可以考虑 protobuf，但那需要在两个语言里都生成代码，维护成本高了不少。msgpack 的优势是描述简单、依赖轻、性能和 JSON 完全不在一个量级，对移动端来说足够了。

3.4 Python 进程的启动方式与生命周期挂钩

Android 里启动一个独立进程的常规操作是android:process=":ml"属性。我在 Manifest 里给一个专用 Service 配置了独立进程，然后在onCreate里启动 Python 脚本。

<service android:name=".MLService" android:process=":ml" android:exported="false" />

关键点是：Python 进程的启动必须在 Service 里做，而且onCreate只能调用一次。如果你在 Activity 里直接碰AndroidProcess的上下文，很容易出问题。

我在 Service 的onStartCommand里做的事包括：

1. 初始化 Chaquopy 的 Python 运行时。
2. 加载消息循环模块，启动 ZeroMQ REP 服务。
3. 绑定本地端口，把实际使用的端口号通知主进程。
4. 通过 WorkManager 或者 LocalBroadcast 把"服务已就绪"的信号发回主进程。

这里有一个很现实的坑：Android 对多进程应用有自己的回收机制。进程可能被系统在内存紧张时杀死，Service 也会随之重启。如果 Python 进程被杀时你还没来得及清理 ZeroMQ 的 socket，重启后重新绑定端口可能会失败。我的解决方案是每次启动时先关闭旧的 context，再重新绑定。ZeroMQ 的context.term()方法可以强制清理，注意在循环外调用，别在某个具体请求里做。

def start_zmq_server(port=5555): ctx = zmq.Context() socket = ctx.socket(zmq.REP) socket.setsockopt(zmq.LINGER, 0) socket.bind(f"tcp://127.0.0.1:{port}") return ctx, socket

加上LINGER为 0 的设置，进程退出时不会等待未发送的消息，避免了 socket 资源泄漏。

4. Compose 界面层的推理状态编排：从回调地狱到响应式更新

4.1 用 sealed class 建模推理状态

Compose 最核心的思维方式是用不可变状态描述 UI。在机器学习场景里，一次推理操作会经历多个阶段：空闲、请求中、推理中、成功、失败。这些阶段用传统的when分支加上一堆 boolean 标志位来管理，代码会越来越乱。我更推荐用 sealed class 一次性定义清楚。

sealed class InferenceState { object Idle : InferenceState() data class Running(val progress: Float, val message: String) : InferenceState() data class Success(val label: String, val confidence: Float, val elapsedMs: Long) : InferenceState() data class Error(val code: Int, val message: String) : InferenceState() }

这个建模方式的好处是，你在 Compose 里可以非常直接地根据状态去渲染不同的 UI 分支，不存在"某种状态该显示什么"的模糊地带。而且编译器会强制你处理所有分支，新增状态类型时不会漏掉 UI 层。

4.2 用 Flow 做推理请求的通道

Compose 项目里我习惯用MutableStateFlow做事件通道，它和 Compose 的状态系统天然融合。每次用户点击"开始推理"，我往MutableStateFlow里发一个事件，ViewModel 或业务层收集这个事件，触发 ZeroMQ 请求，再把结果映射为InferenceState更新 UI。

class MLViewModel(private val mlClient: MLClient) : ViewModel() { private val inferenceRequests = MutableStateFlow<InferenceRequest?>(null) val uiState: StateFlow<InferenceState> = inferenceRequests .filterNotNull() .flatMapLatest { request -> flow { emit(InferenceState.Running(0f, "正在上传数据")) val result = mlClient.predict(request.imagePath) emit(InferenceState.Success(result.label, result.confidence, result.elapsedMs)) } } .catch { e -> emit(InferenceState.Error(-1, e.message ?: "推理失败")) } .stateIn(viewModelScope, SharingStarted.Eagerly, InferenceState.Idle) }

为什么要用flatMapLatest而不是map？因为推理是一个异步操作，中间会有多个状态的发射。flatMapLatest保证如果用户连续触发多次请求，只有最后一次会真正执行，之前的请求会被自动取消。这个细节在高频操作场景下非常关键。

4.3 推理进度条实现：长任务必须给用户反馈

机器学习推理经常要处理图片加载、预处理、模型前向传播、后处理多个阶段。如果在界面上只显示一个"正在推理"的文字，用户感受很含糊。我曾经遇到过用户反馈："点了按钮之后以为 App 卡死了"。于是我把进度条做成了分阶段上报。

Python 进程在执行推理的不同阶段，通过 ZeroMQ 的额外通道把进度信息推送回来。

# Python 侧推送进度 progress_socket = context.socket(zmq.PUSH) progress_socket.connect("tcp://127.0.0.1:5560") progress_socket.send(msgpack.packb({ "stage": "preprocess", "progress": 0.3, "message": "正在加载图片" })) # ... 模型推理 progress_socket.send(msgpack.packb({ "stage": "inference", "progress": 0.7, "message": "模型推理中" }))

Android 端我单独用一个MutableStateFlow<Float>去收集进度。Compose 里渲染LinearProgressIndicator，它支持分段显示，每个阶段的值不同。

@Composable fun InferenceProgressBar(progress: Float, message: String) { Column { LinearProgressIndicator( progress = { progress }, modifier = Modifier.fillMaxWidth() ) Text(message, style = MaterialTheme.typography.bodySmall) } }

这里有个小坑：LinearProgressIndicator的进度值必须在 0 到 1 之间，如果你的 Python 端上报的进度偶尔超过 1，要么截断，要么在 Kotlin 侧做 clamp。我后来直接在状态类里加了规范化逻辑，保证 UI 层拿到的永远是合法的数字。

4.4 生命周期管理与页面退出时的清理

多进程通信最怕的情况就是：用户已经退出页面，但 ZeroMQ 的客户端连接还挂在那边，Python 进程还在傻乎乎地推理。我的做法是让MLClient实现AutoCloseable，并在 ViewModel 的onCleared()或者 DisposableEffect 里做清理。

@Composable fun MLScreen(viewModel: MLViewModel) { DisposableEffect(Unit) { onDispose { viewModel.closeClient() } } }

单靠onCleared()不够保险，因为在 Compose 里如果 Activity 还在但某个组合项被移除了，ViewModel 可能还没销毁。所以在组合项销毁时主动关闭客户端连接，能避免"僵尸连接"浪费资源。

5. 全链路踩坑实录：从联调到上线，那些文档里没有的内容

5.1 端口冲突与多进程重启的坑

ZeroMQ 默认用tcp://127.0.0.1:5555，但如果你的 Python 进程被系统杀死再重启，端口可能还被旧进程占用。这个问题我排查了很久，最终定位到崩溃日志里总有Address already in use。

解决方案有两个：

1. 在 Python 端启动时先尝试连接，如果失败说明端口被占用，就换下一个端口。
2. Android 端启动 Service 时先探测可用端口，然后通过 Intent extra 把端口号传给 Service，再启动 Python。

我最后用的是方案二，因为更可控。具体做法是在MLService.onStartCommand里先找一个空闲端口，然后把它作为环境变量传给 Python 进程。Python 端读环境变量，动态绑定端口。这样彻底避免了端口冲突。

5.2 Python 进程崩溃后的自动恢复策略

真机测试中，Python 进程由于模型加载失败或内存不足而退出是经常发生的事。如果不做恢复处理，用户下次点击"推理"时，Android 端发出去的 ZeroMQ 请求永远没有响应，界面卡在"请求中"。

我的兜底策略是：Android 端维护一个服务连接状态，每次发出请求前先检查 Python 进程是否存活。如果发现连接断开，自动重启MLService，等待就绪信号后再重发请求。

suspend fun MLClient.connectWithRetry(retries: Int = 3): Boolean { repeat(retries) { attempt -> try { connect() return true } catch (e: Exception) { Log.w("MLClient", "连接失败第 ${attempt + 1} 次", e) restartMLService() delay(1000) } } return false }

重试的次数不能太多，三次足够，再多用户体验反而更差。

5.3 内存占用与 APK 体积的平衡

我记得第一次打出 APK 的时候，一个简单的图像分类应用就有 158MB。对于移动端项目来说这是灾难。

体积拆解大概是：CPython 运行时约 15-20MB，PyTorch Android 版本约 50-60MB，numpy 约 20MB，加上自己的模型文件，全堆在一起就爆了。

砍体积的实操顺序：

1. 优先考虑 ONNX Runtime 替代 PyTorch。如果你的模型可以转成 ONNX，那么 PyTorch 这个大头可以完全去掉。ONNX Runtime 的 Android so 文件大概 20MB，比 PyTorch 小一半以上。
2. 模型文件用量化版本。我常用的一个图像分类模型，fp32 版本 40MB，int8 量化之后只剩 10MB。推理速度提升 2-3 倍，准确率损失在 1% 以内，完全可接受。
3. 用abiFilters只保留 arm64-v8a。如果你的应用明确放弃 32 位设备，这个配置能让 Python 运行时的体积砍掉三分之一以上。

defaultConfig { ndk { abiFilters "arm64-v8a" } }

5.4 数据预处理放哪一侧更合理

这是我在设计过程中反复权衡的问题。模型推理前的图片缩放、归一化、张量变换，到底是放在 Python 侧还是 Kotlin 侧？

如果放在 Kotlin 侧，你可以用 Android 的 Bitmap API 和各种图像处理库，性能很高，而且不需要把原始图片的字节数据传给 Python 进程。但问题是这些预处理逻辑和模型强相关——模型换了，输入规格变了，Kotlin 侧代码也得同步改，这违背了我们"模型迭代不应该改 App"的初衷。

如果放在 Python 侧，你可以在 Python 脚本里直接写图像处理逻辑，模型怎么更新，预处理就怎么调，完全不需要动 Kotlin。代价是 Python 端的图像处理性能不如 Android 原生，而且图片数据要传递过去。

最终我的选择是：简单预处理放 Python，重活放 Android。图片的缩放和格式转换属于重活，在 Kotlin 侧做，只把预处理后的 float 数组传给 Python。而归一化、通道变换、排序这些针对模型输入的轻量处理放 Python。这样两边分工明确，模型更换时最多改一个预处理参数配置，Kotlin 不用动。

5.5 日志系统：跨进程问题排查的救命稻草

多进程应用有一个非常让人头疼的问题：logcat 里所有进程的日志混在一起，你无法区分哪条日志来自主进程，哪条来自 Python 进程。如果排查的问题是"Python 端模型加载异常"，在混在一起的日志里很难定位。

我的习惯是给每个进程的日志加固定的 TAG 前缀。主进程用[ML-APP]，Python 进程用[ML-PY]。这样在 logcat 里用 tag 过滤时，一眼就能分辨日志来源。

import logging logger = logging.getLogger("ML-PY") logger.setLevel(logging.DEBUG) def log_info(msg): logger.info(msg)

我的 Chaquopy Python 侧日志输出到了 Android 的 logcat，在调试阶段下载了一个 logcat 分析工具，直接按[ML-PY]过滤，很多问题解决速度能翻倍。

6. 性能实测与优化方向：这套平台到底能跑多快

6.1 基准测试：不同通信模式下的耗时分布

我在一个中端机型（骁龙 778G）上跑了几个基准测试，这里列一下我观察到的数据，供大家参考。

可以看到瓶颈并不是网络通信，而是模型推理本身。ZeroMQ 的本地 socket 传输在局域网级延迟上是几百微秒，在 Android 本机 loopback 上也就在 1ms 级别，完全不是问题。

6.2 分阶段推理的并发优化

前面讲到 GIL 问题限制了多个 Python 协程并行执行。但在实际场景里，我可以用 Python 的多进程模式来绕过。Chaquopy 的文档明确支持在 Android 上启动 Python 子进程，不过新增子进程会引入额外的 5-8 秒启动时间，只有在处理批量任务时才值得。

更实用的做法是：在 Python 进程内部维护一个任务队列，多个 Android 请求排队进入，顺序执行。由于推理任务通常不会频繁触发，排队带来的体验损失微乎其微，但代码稳定性提升了一个档次。

6.3 模型热更新的实现思路

开发这套平台的另一个动机是实现模型热更新。传统 TFLite 集成模式下，模型更新往往要发版。而我们的架构里，模型文件只是一个独立的资源，可以通过下载策略来更新。

我在 Python 进程中实现了这样的逻辑：

1. 启动时检查本地模型文件的版本号。
2. 如果服务器上有新的模型版本，下载到应用的 files 目录。
3. 替换 Python 脚本中指向的模型路径。
4. 下次推理时自动加载新模型。

这就意味着，模型迭代后不需要发版，你只需要把新模型文件上传到服务器就行了。既然 Python 逻辑也在 Apk 里，只要你愿意，也可以把 Python 脚本文件作为 update 资源动态加载。这一层能力对我们的运营场景非常实用。

7. 从个人实践出发的一套建议组合

这套方案走到现在，我最大的体会是：Android 端跑机器学习，最难的不是模型本身，而是怎么把模型、运行时、界面和通信好好地组织在一起。Chaquopy 大大降低了 Python 模型集成到 App 的成本，Compose 让界面状态管理变得清晰，ZeroMQ 则给整个系统提供了解耦的骨架。如果你准备动手做类似的平台，我建议你们按照以下顺序推进：先把一个简单的 Python 模型在 Chaquopy 里跑通，再独立出 Python 进程，加上 ZeroMQ 通道，最后用 Compose 串起完整界面。每一步都有独立的验收标准，出了问题也容易定位。

最后再分享一个我在真机联调时的小技巧：给开发用的测试包单独留一个调试入口，可以在界面上随时查看 Python 进程的运行日志和当前推理耗时。表面上看这功能没什么技术含量，但排查问题的时候，它真的能省下好几个小时。这个思路你们可以顺着做下去，比如把每个推理请求的完整链路耗时也显示出来，扩展成一个小型监控页，对后续优化很有帮助。