5G用户面暴露AI推理：IoD让网络原生支持拆分推理

移动网络能传输张量，却读不懂张量背后的推理意图——这是边缘AI服务化面临的根本矛盾。一篇来自rss来源的研究提出了 Inference on Demand（IoD），试图把拆分推理（split inference）从应用层的私有实现，变成5G用户面上可被网络识别和调度的服务。

问题：网络只搬数据，不理解推理

当前移动系统在传输AI张量时，本质上把它们当作普通字节流。网络可以看到包的大小、时延和吞吐，但看不到“这批张量属于哪个模型的哪一层、下一跳应该去哪里、是否还能继续拆分”。

这种“上下文缺失”导致此前的研究路线各有局限。动态分区、协同推理、拆分流水线虽然解决了算力分配问题，但大多停留在应用层：要么绑定特定App，要么对网络状态无感知，要么干脆丢掉了拆分语义。结果就是，网络无法把推理当作一种可编排的服务来对待。

IoD的核心判断是：拆分推理要真正成为网络服务，服务意图、运行时分区和張量运输三者必须同时对移动数据面可见。

拆分推理（Split Inference） 是边缘AI领域的一类关键范式：将一个完整的神经网络模型按层切分成多个子模型，分别部署在终端设备、边缘服务器甚至云端，中间层产生的张量（tensor）通过网络在前后段之间传输。它的初衷是解决端侧算力/内存受限的问题——让终端只跑前几层，把计算密集的后几层交给边缘或云。然而，拆分的粒度与边界如何选择，直接影响时延、带宽占用与整体吞吐。传统做法通常在应用层静态配置（如按层数固定切分），缺乏对网络实时状态的感知，这也是文中指出的核心局限。将拆分从应用层上移到网络层，意味着网络需要理解张量的语义归属，而不仅是字节流搬运。

IoD做了什么：CAMARA式API + 带内张量上下文

IoD提出了一种按需推理抽象，包含两个关键设计。

第一，它用一个类似CAMARA的API来暴露拆分推理能力。CAMARA是电信领域推动网络能力开放的项目，IoD借用这种思路，让应用可以用标准接口请求推理服务，而不是自己硬编码分区逻辑。

第二，它把拆分感知的张量上下文带内（in-band）携带在5G用户面路径上。这意味着张量在传输时，附带的分区信息和推理状态会随数据一起流动，网络节点能够据此做出转发或计算决策，而不需要额外的控制面查询。

CAMARA 是由 GSMA 与 Linux 基金会联合推动的开源项目，目标是为电信网络能力（如位置、QoS、切片、号码验证等）定义一套标准化、对开发者友好的 RESTful API，使应用无需了解底层 3GPP 细节即可调用网络功能。CAMARA 的价值在于把运营商网络能力抽象成类似云服务的接口，降低集成门槛。IoD 借用 CAMARA 的思路，意味着把“拆分推理”本身作为一种可以被请求、配置和计费的网络能力开放出来——应用只需调用 API 声明推理需求，网络侧的编排器负责决定在哪个 UPF、按何种分区执行。这为运营商将 AI 推理作为增值服务变现提供了标准化路径，也便于跨厂商互操作。

5G 用户面（User Plane）与 UPF：在 5G 核心网架构中，控制面（CP）负责会话管理、策略与移动性，用户面（UP）负责实际的数据包转发。UPF（User Plane Function）是用户面的核心网元，承担 PDR/FAR/QER 等规则匹配、隧道封装、QoS 执行与流量统计。可编程 UPF 允许在数据面插入自定义处理逻辑（如基于 P4 或 eBPF），这正是 IoD 实现“带内张量上下文”的落点——张量包经过 UPF 时，节点可以读取随包携带的分区元数据，决定是转发、缓存还是就地执行推理子任务。相比旁路控制面查询，带内携带上下文减少了信令往返，但也会增加包载荷开销，需在真实拥塞下权衡。

测试台与自适应拆分

研究团队在一个基于可编程用户面功能（UPF）的测试台上评估了IoD，使用的是一个可分区的视觉AI工作负载。

实验的关键发现是：自适应拆分选择可以作为面向网络的服务来运行，同时避免静态配置那种僵化的成本曲线。换句话说，网络不必为所有推理请求固定一套分区方案，而是可以根据运行时条件动态调整。

这一点对运营商有实际意义。静态拆分意味着要么过度预留资源，要么在负载变化时性能塌陷；自适应拆分把这种权衡交给了可编程基础设施来动态处理。

意义：从卸载到网络原生AI服务

当服务意图、运行时分区和張量运输对移动数据面可见时，拆分推理就不再只是“把计算卸载到边缘”这么简单。它变成了网络可以参与协调的一件事。

这指向一条通往网络原生AI服务的路径：可编程的电信基础设施同时协调计算、上下文和连接，为面向用户的应用提供支撑。对于正在寻找5G能力变现方向的运营商来说，这种把推理暴露为网络API的思路，可能比单纯卖带宽更具差异化价值。

当然，从测试台到现网还有距离。可编程UPF的部署密度、跨厂商API的标准化进度、以及推理上下文在真实拥塞场景下的开销，都是IoD需要继续回答的问题。