9 月的第二周，具身圈很热闹。

8 日，松延动力发布 HERON-World Model；9 日，智元一口气放出 AGILE 2.0 与 GE-Act 2.0；10 日，宇树开源 UnifoLM-WLA-1.0，6B 参数，约 2500 小时真机数据，一个模型统筹 64 项任务；到 15 日，松延又补上了 HERON-CRA。八天，三家本体厂商，五个模型。

与此同时，机器人正在加速迈入物理世界。9 月 20 日，启元机器人举办新品发布会，两款个人机器人正式发售，Q1 定价 19999 元起；此前 9 月 10 日，优必选宣布斩获超 5000 万元海外订单，涉及 Walker C1、优世界 U1 等产品。资本市场的评价标准也随之变化，开始用脱水复购率、经营性净现金流，以及真实履约成本（即交付之后的部署、调试与维护投入）来重新审视具身企业。

两条线索交汇，一个核心痛点浮现：如何将复杂强大的具身大模型，高效、稳定地部署到算力极其有限的机器人本体硬件上？这正是端侧推理引擎的核心价值所在。

9 月 15 日，清华大学联合无问芯穹与上海交通大学开源了APXInf，一款面向具身模型的端侧推理引擎。它同时回答了两个问题：

在算力、内存和功耗受限的端侧环境中，如何让具身模型在机器人本体上达到可用的推理速度？

当模型不断迭代进化，如何构建持续适配、永不掉队的端侧优化能力？

第一个问题，APXInf 交出的答案是一组数字：无需改变 π0.5 模型本身，通过端到端的全栈优化，在 Thor 芯片 FP8 配置下把推理延迟从 278ms 降至 26ms，端到端提速约 10.7 倍，38.46Hz 的频率让机器人控制进入实时区间。

[图片: https://n.sinaimg.cn/spider20260929/786/w1080h506/20260929/0a0b-b8e4d2a40a32b31bc457bf663b8422b0.png]

第二个问题的答案则写在 APXInf 仓库的构建方式中。它把原本依赖少数专家的模型适配、优化与验证，沉淀成了一套可被持续复用并且可被 Agent 使用的工作流程。

[图片: https://n.sinaimg.cn/spider20260929/140/w1080h660/20260929/5668-676275bf6765c038fb895c726e50a7b8.png]

项目地址：https://github.com/RLinf/APXinf-robo

为什么具身需要专门的端侧推理优化？

要回答这个问题，先要看清推理引擎在一台机器人中的位置。

一台具身本体大致由主控、算力盒子和外设构成。一次控制循环是：主控采集观测，算力盒子推理出动作 chunk，推送给手臂或底盘执行，然后进入下一帧。推理引擎就嵌在这个循环的中间，它决定一次推理花多少毫秒、控制频率能到多少赫兹，以及那个算力盒子要多大、多热、多贵。

[图片: https://n.sinaimg.cn/spider20260929/786/w1080h506/20260929/f07e-860ef4d594f784ad85d1ae90f70ffa8a.png]

这个位置对引擎提出了一组相当具体的要求：小 batch、实时、延迟抖动小，并且能被主控通过 websocket 或 ROS 稳定调用。这几条恰好是云端推理框架不擅长的。

通用推理框架的做法是用统一的中间表示把模型逐层 lower，再交给后端生成可执行代码，一套编译栈覆盖尽可能多的模型与硬件；vLLM、SGLang 这类方案则围绕云端吞吐设计。它们各自都很成功，但收益都建立在模型种类多、批量大、调度空间足的前提上，而具身端侧这三条恰好都不满足。

于是具身模型的端侧部署形成了三类现实瓶颈。

端侧性能。在端侧，算力、带宽、功耗和散热同时受限，而一次推理却要完成多视角感知、模型前向和动作生成，并以稳定的节奏回应主控。端侧模组与独立显卡之间，内存带宽相差 4 到 8 倍，功耗相差 5 到 10 倍。也因此，在云端跑得顺的模型，换到 Thor 或 Orin 上，效果可能大打折扣。

人力与时间。将模型部署到端侧硬件，并非简单的拷贝运行，而是一项浩大的系统工程。它需要经历从底层架构适配、核心算子编译、精度量化，到软硬件性能调优与仿真验证的全链路流程。这套流程通常要几周，依赖既懂推理系统又懂算子优化的跨领域专家，而这类人在任何一家具身公司都十分稀缺。更关键的是，硬件的微小变动就会导致前功尽弃：一旦更换芯片，所有的算子选择、内存布局与流水线排布都必须推倒重来。

[图片: https://n.sinaimg.cn/spider20260929/615/w1080h335/20260929/34ee-d0548ee1dca78ad9ada82e0f32f214bc.png]

稳定性。Demo 跑得通和长期稳定运行是两件事。后者要面对连续感知控制、资源受限与多模块协同，最怕的还不是慢一点，而是跑着跑着出现抖动、卡死或状态失控。

这三条叠在一起，会呈现出一个乘积特征：

把模型部署到本体上的总工作量≈（一次接入 + 一次调优）× 本体型号数 × 芯片平台数 × 模型迭代次数。

右边每一项变量都在急剧变大：本体型号在增加，芯片多样化，而模型的迭代周期还在极速缩短。事实上，文章开头八天五个模型就是这一现状的直接呈现。靠扩充团队并不现实，它需要的是一层可以被持续复用的基础设施：既能把单次推理压到硬件的极限，还能让下一个模型、下一块芯片的接入不必从头再来。

APXInf 要做的正是这一层。

APXInf 做对了什么？

先看第一项挑战：如何在有限硬件上把推理效率做到位。

APXInf 不以统一通用 IR 为首要目标，而是优先建设面向模型族的特化执行路径。模型结构、权重布局、内存空间、算子融合方案和执行顺序都直接体现在代码中；只有经过多个模型验证的共性能力，才会进一步沉淀为共享模块。这种设计让优化能够深入模型结构和硬件特性，在算子选择、内存布局与执行流程上进行针对性调整，减少为了兼容通用场景而引入的额外开销。

在运行时，只保留端侧实时推理真正需要的控制能力：

算子执行用 CUDA Graph 完成整图捕获与稳态回放，Kernel 选择由 Autotune 生成并持久化；

内存由模型层持有固定 Workspace，固定形状、预分配、地址稳定，减少热路径上的数据搬运；

调度以小 batch 实时推理为核心，不引入面向大 batch 吞吐的 Continuous Batching 与 Paged Attention。

运行时不做复杂启发式，换来的是执行路径可预测、可复现、可审计。

这种特化一直贯彻到构建环节：编译时会查询本机 GPU 的计算能力，只为这一个架构编译 kernel；CUDA kernel、CUTLASS 与 FlashAttention 的源码随仓库内置，部署时不需要 Docker 和外部框架依赖，省掉动辄数 GB 的镜像。