你让机器人看见杯子后伸手去拿，它不能想上半秒再行动。具身模型——接收摄像头等传感信息、输出动作指令的 AI——必须不断完成“感知、决策、行动”的闭环。模型再聪明，若在机器人本机跑得太慢，动作仍会迟钝。APXInf 想解决的就是这层问题：让训练好的具身模型在端侧硬件上更快运行。
无问芯穹联合清华大学、上海交通大学开源了 APXInf。它是一款端侧推理引擎，也就是夹在模型和芯片之间的软件层，负责模型加载、计算与内存调度。项目支持 RTX 4090、Jetson Orin 和 Jetson Thor，代码已发布在 GitHub 的 RLinf/APXinf-robo 仓库。
需要先说明，现有性能信息全部来自量子位转载的项目方材料，没有论文、测试报告或第三方复现交叉验证。下文数字应视为项目方披露的结果。
快的不只是一个算子
端侧推理，是让模型直接在机器人本机运行，而不是把数据传到云端再等结果。它减少了网络依赖和往返时间，但机器人机身里的算力、内存、功耗和散热空间都有限。推理引擎要做的，像是在一间狭小厨房里重新安排备菜、烹饪和上菜：只把某一步做快还不够，整条流程都不能堵。
据项目方材料，APXInf 从多个层次压缩端到端延迟。Pipeline 是把不同计算阶段衔接起来；Graph 是重新组织模型的计算流程；Kernel 是芯片实际执行的底层计算单元；量化则用更低精度的数字表示模型，以减少计算和存储负担。项目还使用 Agent4Kernel 优化融合算子，即把原本分开的底层操作合并执行，减少中间开销。
在 Jetson Thor 上，项目方称 APXInf 将 PI 0.5 的 FP8 推理延迟从 278ms 降到 26ms 以内。FP8 是一种用 8 位浮点数进行计算的低精度格式。按这组数字计算，延迟约缩短至原来的十分之一，改善约 10.7 倍。材料同时给出 38.46Hz 的频率，也就是每秒约完成 38.46 次推理；它与约 26ms 一次推理在算术上对应，不能当作两项独立证据。
为什么端侧引擎值得看
APXInf 所处的不是“让模型学会新技能”的训练层，而是把模型能力真正交给机器人执行的基础设施层。具身智能要走出 Demo，既要模型能作出正确决策，也要决策及时抵达电机和机械结构。延迟因此不只是等待体验，还可能影响动作能否连续完成。
工程接入同样重要。APXInf 用 Rust 构建极简运行时，并提供 Python 接口：前者承担底层执行，后者保留开发者较熟悉的调用方式。项目首发支持 PI 0.5 和 WALL-OSS 两款具身模型，并提出继续适配 VLA、VLM、世界模型及更多芯片平台的路线图。VLA 是把视觉、语言和动作连接起来的模型；VLM 则是处理视觉与语言信息的模型。不过，路线图代表计划，不等于已经交付。
这项工作的规模化价值也正在这里：若同一套引擎能覆盖开发验证和机器人本体部署，团队就可能少做一些针对不同模型、硬件的重复适配。但现有材料尚不足以判断这种通用性已经达到什么程度。
局限与未知
- 项目方称 PI 0.5 性能达到 SOTA，即特定条件下的“当前最佳水平”。但材料没有给出对比方案、测试协议、输入配置和完整模型版本，暂时无法核实这一结论。
- 材料未披露 FP8 量化对模型精度或任务成功率的影响，也没有功耗、预热方式、重复次数和长期稳定性数据。Rust 的内存安全属性本身不能证明整个系统持续运行稳定。
- “完全满足机器人多场景实时控制要求”仍是项目方判断。不同机器人和任务对响应速度的要求不同，26ms 以内的结果能否转化为真实任务收益，还需实机测试与独立复现。