Goal
设计目标
边缘侧 AI 服务通常由多个异构业务节点组成，例如 LLM、ASR、TTS 或设备控制节点。外部请求、内部调度、跨节点通信、任务隔离和流式结果返回交织在一起，如果缺少统一抽象，业务节点就需要直接处理 socket、端口、通信协议和连接生命周期，导致新节点接入成本高、系统扩展困难。
Edge Flow infra
分布式边缘 AI 任务调度与混合通信框架
面向边缘设备提供一套通用的业务节点接入与调度机制，让新的模型节点或设备控制节点能够以插件化方式快速接入，并通过统一 API 对外提供服务。
- 类型
- 边缘 AI 基础设施
- 周期
- 2026.04 - 2026.07
- 核心模块
- 通信框架 / 任务调度 / API Gateway
- 技术栈
- C++ / ZMQ / eventpp / FastAPI / Vue 3
Overview
项目概览
Edge-Flow-Infra 是一个可扩展的边缘 AI 服务基础设施，用于统一接入、调度和开放本地设备上的多类业务节点。系统通过 unit-manager、Channel 抽象和 ZeroMQ 混合通信框架，封装节点注册、任务路由、通信管理和生命周期调度能力，使开发者可以像接入插件一样扩展新的 LLM、ASR、TTS、视觉检测或设备控制节点。 对外，项目提供 OpenAI-compatible API，让 Web 控制台和第三方应用能够用标准接口调用本地 AI 能力；对内，框架负责将请求分发到对应业务节点并管理任务隔离与结果返回。它的目标是把分散的边缘模型和设备能力组织成统一、可扩展、可调用的本地 AI 服务平台。
6通信策略统一封装
5OpenAI 兼容接口
3AI 推理节点
Approach
架构思路
以 unit-manager 作为中心注册与调度模块，结合 Channel 抽象、work_id 路由、连接池和 TCP/ZMQ 协议网关，将节点注册、通信连接、任务分发和生命周期管理统一收敛到基础设施层。业务节点只需实现标准化的 setup / exit / inference 接口，即可像插件一样接入系统并对外提供服务。
Architecture
项目架构
Web / Client
→OpenAI Gateway
→Network
→Unit-manager
→Stackflow
→LLM / ASR / TTS Units
Capabilities
核心能力
统一 API 服务入口
通过 OpenAI-compatible API 对外开放本地 AI 能力，让外部应用可以用标准接口调用 LLM、ASR、TTS 等服务。
插件化业务节点接入
将模型和设备能力抽象为统一业务节点，使新的 AI 节点或设备控制节点可以按照标准接口快速接入系统。
任务调度与生命周期管理
通过 unit-manager 管理节点注册、work_id 分配、请求路由和资源释放，实现多业务节点的统一调度。
通信管理与任务隔离
基于 ZMQ、Channel 和 work_id 路由封装底层通信，为每个任务实例维护独立上下文，保证请求分发和结果回传的准确性。
Implementation
技术实现
底层通信组件
设计并实现基于 ZeroMQ 的 pzmq 通信封装，统一支持 PUB/SUB、PUSH/PULL、RPC Server/Client 等多种通信模式，并实现 RPC action 动态注册、方法发现、超时控制和重连机制。
Channel 通信抽象
实现 Channel 层对 work_id、ZMQ URL、连接池、输入订阅、结果发布和用户回传通道的统一管理，使业务节点无需直接处理 socket、端口和底层消息路由。
任务调度框架
基于 eventpp 构建异步事件驱动的任务调度框架，将远程 RPC 控制指令转换为本地事件队列任务，并通过 setup、exit、pause、taskinfo 等标准接口管理业务节点生命周期。
unit-manager 注册调度中心
实现 unit-manager 模块，负责业务节点注册、work_id 分配、通信 URL 维护、资源释放和轻量级 KV 元信息管理，并通过 TCP/ZMQ 协议网关完成外部请求到内部节点的动态转发。
业务节点接入
基于统一节点接口接入 RKLLM、ASR、TTS 等业务节点，完成模型加载、任务实例管理、推理调用、流式输出回调和节点资源释放流程，验证框架对不同类型节点的扩展能力。
OpenAI-compatible Gateway
实现 FastAPI 网关层，对外提供 /v1/chat/completions、/v1/audio/speech、/v1/audio/transcriptions 等 OpenAI-compatible API，将外部标准请求转换为内部 unit-manager 调度请求。
Difficulties
项目难点
1
异构业务节点如何统一接入
难点：LLM、ASR、TTS 和设备控制等节点的输入输出形式不同，执行耗时和通信模式也不同。如果每类节点都单独设计通信和调度逻辑，系统会很快变得难以维护。
解决方式：抽象统一的业务节点生命周期接口，将节点启动、任务创建、推理执行和资源释放收敛为 setup / inference / exit 等标准流程，使新节点只需关注自身业务逻辑，底层通信、路由和连接管理由框架统一处理。
2
多任务实例如何实现通信隔离
难点：同一个业务节点可能同时服务多个任务实例，不同任务之间需要独立的输入通道、输出通道和状态上下文，否则容易出现消息串扰、结果错发或资源释放不完整的问题。
解决方式：设计 work_id 路由机制和 Channel 连接池，为每个任务实例维护独立的通信上下文，将请求、回调、输出结果和节点生命周期绑定到对应 work_id，实现任务级别的通信隔离。
3
外部标准 API 与内部复杂通信如何解耦
难点：外部调用方希望通过统一 API 调用本地 AI 能力，但系统内部需要处理 TCP、ZMQ、RPC、PUB/SUB、PUSH/PULL 等多种通信方式。如果直接暴露内部通信细节，会增加调用方和业务节点的复杂度。
解决方式：对外提供 OpenAI-compatible API 作为统一服务入口，对内通过 unit-manager 和 ZMQ 混合通信框架完成请求分发、节点调用和结果返回，使外部应用无需理解内部节点拓扑和通信协议。