中心学习、端侧决策：西电团队为开源鸿蒙多终端协同推理构建智能调度框架——开源鸿蒙技术课题成果展播

课题名称：基于OpenHarmony的多终端推理任务调度框架研究

挑战方向：以用户为中心、场景感知的应用软件新形态

揭榜年份：2025年

揭榜单位：西安电子科技大学开源鸿蒙技术俱乐部

课题负责人：张宁，西安电子科技大学开源鸿蒙技术俱乐部指导老师

1

当端侧AI推理从“单兵作战”走向“协同会战”

智慧家居、工业物联网、自动驾驶等场景对低时延和隐私保护提出更高要求，推动AI推理能力从云中心向终端与边缘节点下沉。但单一端侧设备受处理器、内存、电池和散热条件限制，在大批量或多模态任务并发时，容易出现排队积压、局部过载和完成时间增长。

将多台终端的计算、存储与通信能力组织成可协同的边缘资源池，并按设备状态、任务类型和网络条件动态分配推理任务，成为边缘智能的重要方向。开源鸿蒙面向全场景提供分布式软总线、分布式数据管理和“一次开发，多端部署”能力，与多终端协同推理天然契合。

西安电子科技大学开源鸿蒙技术俱乐部团队申报并揭榜的“基于OpenHarmony的多终端推理任务调度框架研究”，正是面向这一场景展开。团队构建了从资源感知、任务决策、通信传输、推理执行到结果反馈、参数优化的闭环系统，让多台开源鸿蒙设备能够协同完成推理任务。目前课题已完成原型系统并开源。

·

2

这事儿为什么难？六重挑战横亘在前

课题组调研发现，真实终端环境下的多终端协同推理并不只是把任务从一台设备发到另一台设备，难点主要集中在六个方面：

第一，异构资源难以统一表征。不同终端在CPU、内存、电量、存储和网络延迟上的量纲与波动频率不同，单一指标无法反映真实执行能力。

第二，实时响应与全局优化存在矛盾。中心化调度会引入网络往返和中心排队，纯端侧固定规则又难以利用历史经验和全局资源分布。

第三，多目标之间天然冲突。低时延、负载均衡和能耗控制难以同时最优，固定经验权重也无法适应动态负载。

第四，控制消息与数据传输需求不同。状态同步、任务通知等高频小消息，与图像、音频、模型文件等大对象传输，对协议能力的要求完全不同。

第五，跨设备执行缺乏可观测性。设备离线、远端超时、传输异常和模型失败若只记录“成功/失败”，故障将无法定位。

第六，调度框架容易与单一模型绑定。若调度逻辑直接理解模型输入、预处理和结果结构，新增语音、文本或多模态任务时就要反复改造链路。

·

3

西电团队为此提出系统化方案

针对上述挑战，团队将系统概括为“一个中心、两个平面、四类模块、一个闭环”：服务端作为参数优化中心，持续汇聚运行样本并更新调度权重；控制平面与数据平面分离，兼顾组网治理与大文件传输；通信、资源感知、智能调度、推理执行四类模块协同工作；运行数据再反哺参数优化，形成持续演化的闭环。

资源感知：让系统“看清”每台设备的真实状态

调度决策的前提是准确理解设备状态。终端周期性采集CPU、内存、电量、存储和网络延迟等指标，并通过MQTT上报；对上层接口覆盖不足的指标，团队结合NDK读取底层系统文件，补齐端侧资源画像。

服务端维护在线节点集合并向终端广播，各终端将本机状态与远端状态合并为本地设备视图。调度器每次决策都基于实时视图，而不是静态配置表；服务端同步记录候选节点、选中节点和实际耗时，为后续优化沉淀样本。

中心学习、端侧决策：兼顾全局优化与实时响应

核心问题是：如何既不牺牲任务响应速度，又能让调度策略从全局经验中持续获益？

团队将调度拆分为两个时间尺度：慢时间尺度上，服务端汇聚历史样本，构建耗时代理评估模型，并通过NSGA-II搜索更优权重；快时间尺度上，终端基于本地设备视图和最新权重进行轻量评分，任务提交瞬间即可完成节点选择。

端侧评分综合CPU、内存、电量、存储和网络延迟五类指标，权重由服务端优化后下发。若本机得分最高，任务进入本地串行队列；若远端更优，则通过任务分发链路交给目标设备执行。服务端不阻塞实时路径，但通过参数下发持续影响后续调度。

多目标权重自优化：让调度策略持续进化

多终端调度不是单目标优化。只压低时延可能造成热点节点，只追求均衡又可能牺牲交互体验，过度强调能耗还会影响效率。

为此，服务端监听任务分发与结果回传，记录候选节点状态、选中节点和真实耗时，形成结构化样本；样本累积后先建立耗时代理模型，再将低时延、负载均衡和能耗控制作为共同目标，通过NSGA-II搜索帕累托最优权重并广播至终端。

测试采用200个构造的资源受限样本：负载均衡敏感、电量敏感、延迟敏感和存储敏感场景各50个；基准策略为静态固定等权。在同一评价函数下，NSGA-II优化权重相对该基准使延迟目标降低21.55%、负载均衡目标改善61.63%、能耗目标降低35.21%，综合评分为36.31%。这证明优化模块能够依据样本中的资源受限模式调整权重，调度策略从人工经验调参转向由真实运行样本驱动的持续优化。

通信分层：MQTT管控制、TCP传数据

高频小消息与大数据对象对协议的要求不同。团队通过多协议通信测试横向比较后，明确了MQTT与TCP的职责边界。

MQTT作为唯一控制协议，统一承载设备状态同步、在线列表广播、任务分发、结果通知、参数下发和传输协商；其Topic路由、发布/订阅、QoS和Broker集中治理能力，适合多设备组网场景下的控制编排。

当输入数据较大时，发送端先通过MQTT发送传输协商消息，声明任务ID、目标设备、数据大小、校验信息、协议类型和连接参数；接收端据此建立独立数据通道完成传输，再进入推理执行流程。

由此，MQTT只负责“协商和编排”，大容量数据由独立通道承担。TCP是当前默认实现，后续接入WebSocket、UDP、Wi-Fi P2P或蓝牙SPP时，只需按统一传输抽象扩展协议实现。

状态可追踪：让分布式调用“有据可查”

跨设备链路环节多，失败若只剩“成功/失败”两个结果，工程定位将无从下手。

团队在端侧设计完整任务状态机，覆盖待调度、调度中、已分发、本地执行、远端执行、已完成、失败和重试中等状态；任务记录包含目标节点、执行结果、错误信息、重试次数、超时配置和流转历史，可将失败定位到调度、传输、执行或结果等待环节。

容错策略将重试与超时分层处理：默认最多重试3次，基础延迟1000ms、最大延迟10000ms并启用指数退避；连接、传输和远端结果等待分别设置超时阈值，在弱网环境下兼顾响应速度与恢复能力。

统一推理接口：让新增模型“即插即用”

若框架只服务单一模型，后续新增语音、文本或多模态任务时就必须修改调度链路，复用价值会明显下降。

团队将推理执行层抽象为模型无关接口：调度模块只面向统一任务对象、统一执行入口和统一结果封装，不直接依赖具体推理引擎；图像、音频等不同模态通过输入类型和参数字段描述，模型加载、预处理、推理调用和后处理都封装在执行层内部。

新增模型只需实现初始化、推理执行、状态检查和资源释放等接口，即可复用调度、通信、状态追踪和结果回传链路。MobileNetV2图像识别与SenseVoice语音识别已在同一调度链路中完成验证，说明框架具备承载多类型端侧AI任务的基础。

·

4

成果验证：真实设备上的端到端测试

课题组以Purple Pi OH开发板（OpenHarmony 6.0、RK3566芯片）为主要测试设备，围绕设备接入、任务执行、异常恢复、负载运行、模型扩展和参数优化等方面开展系统验证。

测试结果显示，两台终端可通过MQTT快速接入系统并及时刷新资源状态；MobileNetV2图像识别任务能够完成从创建到执行、再到结果回传的全流程；在远程超时和传输异常场景下，系统可记录失败原因、显示重试次数并保留状态历史；在同一页面下，系统还可一键切换至SenseVoice语音识别任务，模型初始化、任务提交和识别结果返回链路均可顺利完成。

在负载测试中，研究以10、25、50个并发任务为测试条件，对比单机执行、随机策略与最终资源感知方案。全部实验组合成功率均为100%。在50并发下，最终方案平均完成时间较单机执行降低52.9%，较随机策略降低43.1%。

协同调度开销实验进一步验证了框架调度操作的高效性。若将任务分发、数据传输和结果回传纳入统计，热启动场景下调度相关耗时约为174.133 ms，仅占端到端总耗时的5.263%。这表明框架自身的调度开销较低，跨端传输带来的协同成本处于可控范围。

5

开源贡献

目前，课题已开源代码、架构设计文档、系统使用说明和测试验证记录。系统已打通设备接入、状态同步、端侧调度、推理执行、结果回传、样本沉淀、权重优化与参数下发全链路，支持图像识别与语音识别两类异构推理任务。

课题组寄语

很荣幸参与开源鸿蒙技术课题揭榜攻关。从单机受限到多设备“协同会战”，我们始终相信，端侧AI的未来不在于孤立的算力堆砌，而在于异构设备间的高效协同。

从开发板上的第一行代码，到MQTT与TCP双平面通信的打通；从多目标权重自优化的持续迭代，到不同模型在同一调度链路中的稳定运行，我们用一次次实验和一行行代码，将“多终端协同推理”从概念落地为可运行、可观测、可演化的开源系统。

感谢开源鸿蒙技术社区提供的宝贵平台，点燃了同学们投身基础软件创新的热情。

未来，我们将继续深耕开源鸿蒙生态，期待更多志同道合的伙伴加入，共同推动端侧智能在更多场景中落地生根。

—— 西安电子科技大学开源鸿蒙技术俱乐部

全体课题组师生

2026年8月

写在最后

本课题为开源鸿蒙生态补充了面向边缘智能和多终端AI协同的实践样例，其通信协议设计、设备状态建模、调度接口规范和推理Worker接入流程可沉淀为社区工程模板。后续团队将继续完善多设备、多模型、多网络环境下的长期稳定性测试，探索更细粒度的任务划分与资源分配，并推动代码、接口文档和测试样例规范化，降低开发者在开源鸿蒙上构建AI协同应用的门槛。

附录：

开源项目地址：https://atomgit.com/huozj/OH

本文经AI辅助，人工审校后发布。

审核编辑 黄宇