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配置下,将推理延迟从278毫秒降低至26毫秒,实现了约10.7倍的端到端提速,38.46Hz的频率使机器人控制进入了实时区间。
针对第二个问题,其答案体现在APXInf代码库的构建方式中。它将原本依赖少数专家的模型适配、优化和验证过程,沉淀为一套可被持续复用、并能被智能体使用的工作流程。
项目地址:https://github.com/RLinf/APXinf-robo
为何具身智能需要专门的端侧推理优化?
要回答这个问题,首先需要了解推理引擎在机器人中的位置。
一台具身机器人大致由主控、算力模块和外设组成。一次控制循环的过程是:主控收集观测数据,算力模块推理出动作序列,将其发送给机械臂或底盘执行,然后进入下一帧。推理引擎就嵌入在这个循环的中间,它决定了单次推理所需毫秒数、控制频率能达到多少赫兹,以及算力模块的体积、散热和成本。
这个位置对引擎提出了一系列具体要求:小批量、实时、低延迟抖动,并能被主控通过WebSocket或ROS稳定调用。 这些正是云端推理框架所不擅长的。
通用推理框架的做法是,使用统一的中间表示将模型逐层转换,然后交给后端生成可执行代码,用一套编译栈覆盖尽可能多的模型和硬件;而vLLM、SGLang等方案则围绕云端吞吐量进行设计。它们各自都很成功,但其优势都建立在模型种类多、批量大、调度空间充足的前提下,而具身端侧恰好都不满足这些条件。
因此,具身模型的端侧部署形成了三类现实瓶颈。
端侧性能。在端侧,算力、带宽、功耗和散热同时受限,而一次推理却需要完成多视角感知、模型前向计算和动作生成,并以稳定的节奏响应主控。端侧模块与独立显卡之间,内存带宽相差4到8倍,功耗相差5到10倍。因此,在云端运行流畅的模型,换到Thor或Orin上,效果可能大打折扣。
人力与时间。将模型部署到端侧硬件,并非简单的复制运行,而是一项复杂的系统工程。它需要经历从底层架构适配、核心算子编译、精度量化,到软硬件性能调优和仿真验证的全链路流程。这套流程通常需要数周时间,且依赖于既懂推理系统又懂算子优化的跨领域专家,而这类人才在任何具身公司中都极为稀缺。更关键的是,硬件的微小变动就会导致前功尽弃:一旦更换芯片,所有的算子选择、内存布局和流水线排布都必须重新开始。
稳定性。演示运行成功与长期稳定运行是两回事。后者需要应对连续的感知控制、资源受限和多模块协同,最怕的并非速度稍慢,而是运行过程中出现抖动、卡死或状态失控。
这三者叠加,会呈现出一个乘积特征:
将模型部署到本体上的总工作量≈(一次接入 + 一次调优)× 本体型号数 × 芯片平台数 × 模型迭代次数。
右边每一项变量都在急剧增长:本体型号在增加,芯片种类在多样化,而模型的迭代周期还在不断缩短。事实上,文章开头提到的八天五个模型正是这一现状的直接体现。单纯扩充团队并不现实,它需要的是一层可被持续复用的基础设施:既能将单次推理性能压榨到硬件极限,又能让下一个模型、下一块芯片的接入不必从头开始。
APXInf的目标正是构建这一层。
将推理压入实时区间,APXInf做对了什么?
首先看第一项挑战:如何在有限硬件上实现高效的推理。
APXInf并不以统一通用的中间表示为首要目标,而是优先构建面向模型族的特化执行路径。 模型结构、权重布局、内存空间、算子融合方案和执行顺序都直接体现在代码中;只有经过多个模型验证的共性能力,才会进一步沉淀为共享模块。这种设计使得优化能够深入模型结构和硬件特性,在算子选择、内存布局和执行流程上进行针对性调整,减少为兼容通用场景而引入的额外开销。
在运行时,只保留端侧实时推理真正需要的控制能力:
算子执行使用CUDA Graph完成整图捕获和稳态回放,Kernel选择由Autotune生成并持久化;
内存由模型层持有固定工作空间,固定形状、预分配、地址稳定,减少热路径上的数据搬运;
调度以小批量实时推理为核心,不引入面向大批量吞吐的Continuous Batching和Paged Attention。
运行时不做复杂启发式,换来的是执行路径的可预测、可复现、可审计。
这种特化一直贯彻到构建环节:编译时会查询本机GPU的计算能力,只为这一个架构编译kernel;CUDA kernel、CUTLASS和FlashAttention的源码随代码库内置,部署时不需要Docker和外部框架依赖,省去动辄数GB的镜像。
最终,这种全栈优化可带来效率的巨大提升。Orin上的优化阶梯可以说明这一点:基线为1300毫秒,经过torch.compile、Pipeline、Graph、Kernel、Pruning逐级下探,最终降至119毫秒,整体提升超过10.9倍。Thor上也是如此。
效果上,官方评测协议是LIBERO-10全部10个任务各50个episode,种子固定为7,重规划步长为5,共500次rollout。Thor FP8成功率为92.2%,Thor BF16为92.8%,Orin BF16为92.0%,作为参照的π0.5参考实现为92.4%。
除了跑得快,还要跑得稳。 APXInf底层聚焦高性能算子,实现性能的极致压榨;推理框架的主体部分则选择使用Rust语言开发,作为一种系统语言,Rust能够提供低成本、细粒度的系统运行时控制,实现更优的调度与并发管理。同时,Rust的强制RAII特性和所有权系统,极大地收窄了内存问题的风险范围,支持更安全鲁棒的资源生命周期管理,unsafe代码被严格限制在固定的FFI边界。中间这一层的系统级价值,是让野指针、数据竞争这类隐蔽故障尽量在上线前就被消除;对一台需要连续工作的机器人来说,这不只需要能「跑到38Hz」,更是能「连续跑八小时之后还是38Hz」。
模型不断更迭,推理优化如何跟上?
特化路径带来了性能,也带来了新问题:为每个模型族手写一条路径,意味着模型一更新、硬件一换代,这条路径就要重做一次。如果这部分工作仍然依赖少数专家手工完成,那永远也跟不上具身模型的迭代。
APXInf的解法是将这套工程能力本身产品化:把原本散落在少数专家经验里的模型接入、前后处理、本体适配、性能调优与部署验证,沉淀为代码智能体可以理解、调用和持续迭代的工程流程。
在这种全新的工作流中,人机分工呈现出一种颠覆性的模式:
智能体负责跑流程:读取PyTorch参考实现,生成执行记录,实现模型的静态路径,逐算子对拍与回归,最后完成Autotune、文档与迭代。
人负责定标准:架构边界与模块职责、Kernel契约与安全规范,精度、性能与任务的验收线,以及决定何时将共性抽取为共享抽象。
交给智能体的不再是简单的辅助工作,而是最消耗专家时间的实现部分,人则进化为把控全局的「判据」与「决策者」。
也正因为实现可以交给智能体,验证体系的严谨性成为了新的核心护城河。APXInf建立了三重保障:
全链路分层验证:从单算子、Layer到完整模型,配合Eager与Graph路径的交叉对拍,确保每一步都精准可控。
故障封闭原则:不支持的参数或硬件直接报错,绝不静默输出错误结果。
模型族隔离:共享能力仅在Kernel层下沉,任何变更必须经过严格的分层回归,从而锁死风险。
这对用户意味着什么?
对具身企业而言,它将推理优化从一次性项目变成了可持续的工程能力。自研模型改一版,不必重新排队等专家;换一款芯片,不必把上一轮的调优经验推倒重来;团队规模不再是接入速度的硬约束。更重要的是,专家经验从个人手感变成了团队可复用的资产。
对于行业,它提供了一种新的基础设施建设方式。过去衡量一个推理框架,看的是支持多少模型、适配多少硬件、算子库有多全,这些指标背后的假设是接入成本固定,所以覆盖面越广越好。而当接入成本本身开始下降,真正值得看的就变成了:接入一个新模型、上一款新本体需要多少时间。这衡量的是一家具身公司把新模型变成实际产能的速度。
从Mizar到APXInf,端侧推理技术栈向物理世界延伸
APXInf并非一个从零开始的实验性项目,而是无问芯穹在端侧推理领域长期积累的必然结果。
APXInf的技术基因直接承袭自面向智能终端的推理加速引擎Mizar。早在Mizar阶段,无问芯穹围绕AI PC、AI盒子和一体机等终端,已逐步形成异构硬件适配、本地模型部署、推理加速、内存优化与低功耗运行等核心能力。这套技术栈不仅支撑本地模型规模数倍提升、推理性能翻倍,还在相同算力资源下带来了18%的智能水平提升。
更重要的是,这一技术路线已走过实验阶段,并通过了严苛的量产检验。2025年2月,无问芯穹与联想达成深度合作,将Mizar引擎植入联想新一代AI PC,并于同年11月达成超千万台AI PC的预装合作。APXInf正是在此基础上的再次进化。
AI PC与具身端侧的负载并不相同,但两者面对的约束是一致的:在有限的算力、内存和功耗条件下,达到可用的推理速度。
针对具身场景提出的全新挑战,APXInf进行了技术延展:无论是面对更复杂的VLA模型多模态执行链路,还是应对机器人毫秒级的实时控制需求,APXInf都能通过底层的极致优化,充分释放硬件性能。同时,面对模型的高速迭代,它又引入了面向智能体开发的工程流程。这不仅实现了原有端侧能力的「无缝平移」,更完成了针对具身行业的「深度适配」。
生态布局的另一重考量,是「工程闭环」的无缝衔接。APXInf选择在RLinf开源生态中首发,是因为模型训练与本体推理本就是同一条工程链路上的两个环节。
RLinf覆盖强化学习训练、评测与真实机器人工作流,而训练完成的具身模型要真正进入本体,还需要一套针对小批量、低时延和有限功耗设计的推理引擎。APXInf接的正是这一棒,把RLinf的能力从训练与评测延伸到端侧推理与部署,让开发者能在同一套生态里走完从训练、验证到本体运行的全程。
下一步,开源共建
就在今天,APXInf已同步完成π0-fast、GR00T与Qwen Drive的适配,模型支持进一步覆盖机器人操作、移动智能体等不同具身场景。
硬件侧,AMD与国产芯片后端也已进入路线规划。未来将支持更多具身模型在不同端侧设备上高效、稳定运行。
具身智能要真正走进物理世界,模型、本体和中间这层基础设施缺一不可。面对庞大的接入和验证工程,这也是APXInf选择开源共建的初衷。
如果你正在把π0.5这类具身模型部署到机器人上,手上有RTX 4090、Jetson Thor或Orin,或者希望为APXInf接入新的模型、芯片乃至参与模型接入技能与智能体部署流程本身的建设,都欢迎上手体验、提交Issue或贡献PR。
GitHub:https://github.com/RLinf/APXinf-robo
Quick Start:https://github.com/RLinf/APXinf-robo#build-apxinf-robo
致谢
APXInf的开发深受以下优秀开源项目的启发。无问芯穹向这些项目的社区致以诚挚的感谢,感谢他们的开源精神与技术贡献。
FasterTransformer:
https://github.com/NVIDIA/FasterTransformer
Tensor-LLM:
https://github.com/NVIDIA/TensorRT-LLM
llama.cpp:
https://github.com/ggml-org/llama.cpp
vLLM:
https://github.com/vllm-project/vllm
sgLang:
https://github.com/sgl-project/sglang
FlashRT:
https://github.com/flashrt-project/FlashRT
本文来自微信公众号“机器之心”(ID:almosthuman2014),作者:机器之心,36氪经授权发布。

