9 月的第二周，具身智能赛道密集出现新模型。8 日，松延动力发布 HERON-World Model；9 日，智元连续推出 AGILE 2.0 与 GE-Act 2.0；10 日，宇树开源 UnifoLM-WLA-1.0，参数规模 6B，使用约 2500 小时真机数据，一个模型覆盖 64 项任务；到 15 日，松延动力又发布 HERON-CRA。8 天时间里，3 家本体厂商共推出 5 个模型。
另一边，机器人产品也在加快进入真实市场。9 月 20 日，启元机器人举行新品发布会，两款个人机器人正式发售，Q1 起售价为 19999 元。更早的 9 月 10 日，优必选宣布拿下超过 5000 万元海外订单，涉及 Walker C1、优世界 U1 等产品。随着交付走向现实，资本市场对具身企业的衡量口径也在变化，开始关注脱水复购率、经营性净现金流，以及真实履约成本，也就是交付后的部署、调试和维护投入。
模型快速迭代与商业化落地同时推进后，一个问题变得更突出：复杂的具身大模型，怎样高效、稳定地部署到算力极其有限的机器人本体硬件上。9 月 15 日，清华大学联合无问芯穹与上海交通大学开源 APXInf，试图解决的正是这一层问题。
APXInf 试图回答两个核心问题
APXInf 是一款面向具身模型的端侧推理引擎。项目给出的目标很直接：一是在算力、内存和功耗都受限的端侧环境里，让具身模型在机器人本体上达到可用的推理速度；二是在模型持续迭代的情况下，建立一套能够持续适配的端侧优化能力。
围绕第一个问题，APXInf 给出了一组明确数据。在不改变 π0.5 模型本身的前提下，项目通过端到端全栈优化，把 Thor 芯片 FP8 配置下的推理延迟从 278ms 压缩到 26ms，端到端提速约 10.7 倍，运行频率达到 38.46Hz，进入机器人控制所需的实时区间。
第二个问题的答案，则体现在 APXInf 的构建方式上。项目把原本依赖少数专家完成的模型适配、优化和验证流程，沉淀成一套可以持续复用、也可以被 Agent 调用的工作流。
项目地址为：https://github.com/RLinf/APXinf-robo
为什么具身模型需要专门的端侧推理优化
要理解 APXInf 的定位，先要看推理引擎在机器人控制链路中的位置。一台具身机器人通常由主控、算力盒子和外设组成。一次控制循环大致是：主控采集观测，算力盒子完成推理并生成动作 chunk，再把结果发送给机械臂或底盘执行，随后进入下一帧。推理引擎就处在这条链路中间，它直接决定一次推理需要多少毫秒、控制频率能达到多少赫兹，也影响算力盒子的体积、发热和成本。
这意味着端侧推理引擎面对的是一组很具体的要求：小 batch、实时、低延迟抖动，并且能够被主控通过 websocket 或 ROS 稳定调用。云端推理框架通常并不擅长处理这类场景。
通用推理框架通常会先用统一的中间表示把模型逐层 lower，再交给后端生成可执行代码，希望一套编译栈覆盖尽可能多的模型和硬件。vLLM、SGLang 这类方案则主要围绕云端吞吐设计。它们的优势建立在模型种类多、批量大、调度空间充足的前提上，而具身端侧恰恰不具备这些条件。
端侧部署面临三类现实瓶颈
第一类是端侧性能限制。端侧设备同时受到算力、带宽、功耗和散热约束，但一次推理仍要完成多视角感知、模型前向和动作生成，并以稳定节奏响应主控。文中提到，端侧模组与独立显卡相比，内存带宽相差 4 到 8 倍，功耗相差 5 到 10 倍。因此，在云端运行顺畅的模型，迁移到 Thor 或 Orin 上后，效果可能明显下降。
第二类是人力与时间成本。把模型部署到端侧硬件并不是简单复制运行，而是一项系统工程，涉及底层架构适配、核心算子编译、精度量化、软硬件性能调优和仿真验证等完整流程。这套流程通常需要数周时间，而且依赖既懂推理系统又懂算子优化的跨领域专家。更麻烦的是，硬件上的微小变化都可能让之前的工作失效。一旦更换芯片，算子选择、内存布局和流水线排布都要重新来过。
第三类是稳定性。Demo 能跑通，不等于系统能长期稳定运行。真正落地时，系统要面对连续感知控制、资源受限和多模块协同，风险不只是速度变慢，还包括抖动、卡死和状态失控。
原文将这类问题概括为一个乘积关系：
把模型部署到本体上的总工作量≈（一次接入 + 一次调优）× 本体型号数 × 芯片平台数 × 模型迭代次数。
而这几个变量都在扩大。本体型号在增加，芯片平台在变多，模型迭代周期也在缩短。文章开头提到的 8 天 5 个模型，就是这种变化的直接体现。按这一逻辑，仅靠扩充团队并不能解决问题，更需要一层可持续复用的基础设施，让单次推理尽量逼近硬件极限，也让下一个模型、下一块芯片的接入不必从头开始。
APXInf 如何把推理压进实时区间
在性能设计上，APXInf 没有把统一通用 IR 作为首要目标，而是优先构建面向模型族的特化执行路径。模型结构、权重布局、内存空间、算子融合方案和执行顺序，都直接体现在代码中。只有经过多个模型验证的共性能力，才会进一步沉淀为共享模块。
这种设计让优化可以更深入地贴合模型结构和硬件特性，在算子选择、内存布局和执行流程上做针对性调整，减少为了兼容通用场景而引入的额外开销。
在运行时，APXInf 只保留端侧实时推理真正需要的控制能力：
- 算子执行通过 CUDA Graph 完成整图捕获和稳态回放，Kernel 选择由 Autotune 生成并持久化；
- 内存由模型层持有固定 Workspace，采用固定形状、预分配和稳定地址，减少热路径上的数据搬运；
- 调度围绕小 batch 实时推理展开，不引入面向大 batch 吞吐的 Continuous Batching 与 Paged Attention。
项目在运行时不采用复杂启发式，换来的是执行路径可预测、可复现、可审计。
这种特化思路也延伸到构建环节。编译时，系统会查询本机 GPU 的计算能力，只为当前架构编译 kernel。CUDA kernel、CUTLASS 和 FlashAttention 的源码随仓库内置，部署时不需要 Docker 和外部框架依赖，也省去了动辄数 GB 的镜像。
从结果看，这套全栈优化带来了明显提升。以 Orin 为例，baseline 为 1300ms，经过 torch.compile、Pipeline、Graph、Kernel、Pruning 逐级优化后，最终降到 119ms，整体提升超过 10.9 倍。Thor 平台也呈现出类似趋势。
速度之外，项目还强调成功率和长期稳定性
官方评测协议采用 LIBERO-10 的全部 10 个任务，每个任务 50 个 episode，seed 固定为 7，replan 步长为 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，还要在连续运行 8 小时后仍保持 38Hz。
模型持续更新后，优化流程如何跟上
特化路径带来性能优势，也带来新的维护压力。若每个模型族都要手写一条执行路径，那么模型更新、硬件换代后，这条路径就需要重做。如果这部分工作仍然依赖少数专家手工完成，就很难跟上具身模型的迭代速度。
APXInf 的做法，是把这套工程能力本身产品化。项目把原本分散在少数专家经验中的模型接入、前后处理、本体适配、性能调优和部署验证，沉淀为代码 Agent 可以理解、调用并持续迭代的工程流程。
在这套工作流里，人机分工被重新定义：
- Agent 负责执行流程，包括读取 PyTorch Reference、生成执行 Ledger、实现模型静态路径、逐算子对拍与回归，最后完成 Autotune、文档和迭代；
- 人负责设定标准，包括架构边界与模块职责、Kernel 契约与安全规范、精度性能和任务验收线，以及决定何时把共性能力抽取为共享抽象。
按原文表述，交给 Agent 的不再只是辅助工作，而是最消耗专家时间的实现部分；人则转向把控全局的判据和决策。
也因为实现过程可以交给 Agent，验证体系本身变得更关键。APXInf 建立了三重保障：
- 全链路分层验证：从单算子、Layer 到完整模型，并结合 Eager 与 Graph 路径交叉对拍；
- Fail-closed 原则：不支持的参数或硬件直接报错，不静默输出错误结果；
- 模型族隔离：共享能力只在 Kernel 层下沉，任何变更都必须经过严格的分层回归。
对企业和行业意味着什么
对具身企业来说，APXInf 试图把推理优化从一次性项目变成可持续的工程能力。自研模型更新后，不必重新排队等待专家；更换芯片后，也不必把上一轮调优经验全部推翻；团队规模不再直接限制接入速度。原本依赖个人经验的优化过程，也可以转化为团队可复用的资产。
对行业来说，项目给出了一种新的基础设施建设思路。过去衡量推理框架，常看支持多少模型、适配多少硬件、算子库是否完整，这背后的前提是接入成本固定，因此覆盖面越广越有价值。原文认为，当接入成本本身开始下降后，更值得关注的指标会变成：接入一个新模型、上一款新本体需要多少时间。这决定了一家具身公司把新模型转化为实际产能的速度。
从 Mizar 到 APXInf，技术栈向物理世界延伸
文章指出，APXInf 并不是一个从零开始的实验项目，而是无问芯穹在端侧推理领域长期积累后的延伸。其技术基因直接来自面向智能终端的推理加速引擎 Mizar。
在 Mizar 阶段，无问芯穹围绕 AI PC、AI 盒子和一体机等终端，已经形成异构硬件适配、本地模型部署、推理加速、内存优化和低功耗运行等能力。原文称，这套技术栈不仅支撑本地模型规模数倍提升、推理性能翻倍，还在相同算力资源下带来了 18% 的智能水平提升。
文章还提到，这一路线已经经过量产检验。2025 年 2 月，无问芯穹与联想达成深度合作，将 Mizar 引擎植入联想新一代 AI PC；同年 11 月，双方达成超千万台 AI PC 的预装合作。APXInf 被描述为建立在这一基础上的再次进化。
AI PC 与具身端侧的负载并不相同，但两者面对的约束一致，都是在有限算力、内存和功耗条件下实现可用的推理速度。针对具身场景更复杂的 VLA 模型多模态执行链路，以及机器人毫秒级实时控制需求，APXInf 在底层优化之外，又加入了面向 Agent 开发的工程流程。原文将其概括为，不只是原有端侧能力的延续，也完成了针对具身行业的深度适配。
为何选择在 RLinf 开源生态中首发
生态层面的考虑之一，是工程闭环。APXInf 选择在 RLinf 开源生态中首发，原因是模型训练与本体推理本来就处在同一条工程链路上。
RLinf 覆盖强化学习训练、评测和真实机器人工作流，而训练完成后的具身模型要真正进入本体，还需要一套针对小 batch、低时延和有限功耗设计的推理引擎。APXInf 补上的正是这一环，把 RLinf 的能力从训练和评测延伸到端侧推理与部署，让开发者可以在同一套生态中完成从训练、验证到本体运行的完整流程。
后续计划与开源协作
按照原文披露，APXInf 目前已经同步完成 π0-fast、GR00T 与 Qwen Drive 的适配，模型支持进一步覆盖机器人操作、移动智能体等不同具身场景。
硬件侧方面，AMD 与国产芯片后端已经进入路线规划，后续将支持更多具身模型在不同端侧设备上高效、稳定运行。
文章最后表示，具身智能要真正进入物理世界，模型、本体和中间基础设施缺一不可。面对庞大的接入和验证工程，APXInf 选择开源共建。对于正在把 π0.5 等具身模型部署到机器人上的开发者，或手头拥有 RTX 4090、Jetson Thor、Orin 等硬件的用户，也包括希望为 APXInf 接入新模型、新芯片，或参与模型接入 Skill 与 Agentic 部署流程建设的开发者，项目欢迎体验、提交 Issue 或贡献 PR。
GitHub：https://github.com/RLinf/APXinf-robo
Quick Start：https://github.com/RLinf/APXinf-robo#build-apxinf-robo
致谢与参考项目
原文还列出了 APXInf 开发过程中受到启发的开源项目，并向相关社区致谢，包括 FasterTransformer、Tensor-LLM、llama.cpp、vLLM、sgLang 和 FlashRT。
- 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），作者为机器之心。