278ms。这个时长对于人类对时间的认知来说几乎是一瞬间。同时它也是Pi0.5 使用 OpenPI 基线在端侧完成一次推理的等待时间。然而对于机器人来说这个时间还是太长了。从指令进入系统到机器人开始动作中间的每一段等待都有代价。模型算出来的是正确答案但物理世界已经变了。杯子可能移动人的手可能伸过来机器人的动作不再合时宜。换一台更强的服务器可以解决部分计算问题。但对需要移动、进入家庭或在网络条件不稳定的场所工作的机器人通信时延、连接可靠性、部署成本和功耗都会成为约束。算力设备还要装进机身消耗电量并满足散热要求。端侧推理优化要解决的就是在这些约束下把有限芯片的性能充分发挥出来让模型及时完成计算同时为其他任务和整机续航留出空间。原文链接机器人不接受迟到的答案Thor 芯片上Pi0.5推理被干到了26ms10.7倍加速。VLA的实时推理被什么卡住了谈这个问题之前先思考一下机器人收到一组观察之后还要做哪些事多路图像需要处理语言和状态需要转换成模型输入。之后输出的动作还要后处理才能进入控制系统。数据复制、处理、算子启动、显存分配和模块间之间的等待都可能出现在这条链路里。从input到output涉及很多前置和后置处理。模型在仿真环境中效果不错甚至可以说是完美但到了机器人本体上可能响应速度都不够。其中一个重要原因就是VLA这类模型没有专属的推理引擎。到了端侧VLA 要与相机、定位、规划和控制等模块共享有限的算力、带宽与功耗。这是一个很复杂的系统工程。云端服务追求多请求下的整体吞吐机器人端侧更关心小batch时的一次响应能有多快、多稳定。性能之外适配同样耗人。模型换一块芯片或一个驱动版本算子、精度路径和内存布局可能都要重新适配。换一个机器人本体相机输入、状态维度、动作定义和控制接口又要重新接入。每增加一种部署组合团队往往都要从零开始重新适配完整的排查、优化和验证流程需重新走一遍。研发投入极大。但跑通一次也只是开始。时延抖动、资源泄漏、异常中断以及多台设备和多个软件版本能否保持一致直接决定了机器人能否在真实场景中持续、稳定地工作。VLA 从 Demo 走向本体急需一套专为真实硬件约束设计的推理引擎。单次响应要快连续运行要稳模型和硬件能低成本的快速接入让VLA的计算和物理世界的变化同步。APXInf 就是在这些约束下出现的。它由无问芯穹主导联合清华大学与上海交通大学推出定位是面向机器人本体的 VLA 高性能推理引擎重点服务小 batch、多视角、强实时的推理场景。GitHub https://github.com/RLinf/APXinf-roboQuick Start https://github.com/RLinf/APXinf-robo#quick-start其中RLinf 提供具身与 Agentic AI 相关训练、评测基础设施APXInf 则进一步衔接训练完成之后的本体推理与部署。APXInf 希望通过 Agent 协助开发者把已经验证过的模型部署到端侧并结合推理引擎的优化能力降低模型的落地门槛拓展性极高。之前的部署推理逻辑不一定适合具身推理通用大模型推理框架主要服务云端高并发通过 Continuous Batching、Paged Attention 和动态调度提升整体吞吐。机器人本体面对的却是小Batch 的实时控制一次推理要在有限功耗和内存带宽下完成多视角感知、VLA 前向和动作生成并以稳定的低时延响应主控系统。两类场景的优化目标出现很大不同。云端关注单位时间能处理多少请求机器人关注单次响应及其抖动。为大 Batch 和动态负载设计的调度、缓存与内存管理机制到了端侧可能成为额外开销。VLA真的走向部署需要一套专属的推理引擎。让pi0.5在Thor上26ms跑起来从278ms到26ms。APXInf 最直观的优势体现在推理速度上。这是双视角输入条件下Pi0.5FP8Thor下的实测结果。相比于之前的278ms未用APXInf加速了约10.7倍。支撑 APXInf 性能的一项关键设计是针对 Jetson、RTX 平台和具身模型定制优化的高性能算子库。这套算子库支持融合算子、CUTLASS、cuBLASLt 等多种实现与计算后端兼顾不同计算需求的覆盖以及具体场景的定向优化。它与计算图、量化、内存管理和推理流水线的优化配合减少计算之外的等待。举个例子。如果相邻的几个计算操作每一步都需要单独启动并把中间结果写回显存、再由下一步读出时间就会花在计算之外。适合的算子融合可以减少其中一部分启动和读写开销。量化则从数据表示入手从FP32到INT8 or FP8做过部署的同学应该都清楚“数值误差可接受的前提下用更低精度执行部分计算可以减轻带宽和算力压力”。这些优化相互配合最后体现为一次推理的总耗时变化。但这并不代表拿提升速度来牺牲精度。官方也给出了实验对比在 LIBERO-10 的 10 项任务、每项 50 次评测中任务成功率达到92.2%baseline 92.4%。性能优化没有以明显损失任务效果为代价。一次跑得快还要持续跑得稳26ms让单次推理可以进入实时区间但面向机器人本体部署不能只看一次测试中的最快成绩。机器人需要持续调用模型。时延是否稳定、资源占用是否可预测、长期运行会不会出现内存和并发问题都会直接影响动作控制。APXInf 在这里采用的是高性能算子库负责计算效率Rust 原生运行时加强内存与并发管理上层通过 Python 接口降低使用门槛。开发者可以通过熟悉的 Python 完成模型接入底层由原生运行时控制计算和资源使用。固定执行路径、提前分配运行所需内存等设计不只为了缩短时延也能减少运行过程中的等待和波动。真正面向本体的高性能不是偶尔跑到26ms而是在连续调用中仍能保持稳定响应。Agent参与构建开发让历史收益和积累延续为每个模型建立专用路径性能优化会更好这是每次部署工程都会想到的。但适配工作会不会随之增加会。这正是模型特化路线需要面对的扩展成本。**APXinf从设计之初的理念就是“让Agent从推理引擎的使用者进入到推理引擎的构建过程。**让已有实现和接入经验有机会被后续开发继续利用”。过去很多调整工作高度依赖推理和系统专家。现阶段APXInf 通过Agent已经可以帮助开发者快速部署已支持的模型。后续团队计划将更多模型接入、前后处理和本体适配经验沉淀为 Agent 可理解、可调用的 Workflow 与 Skills并逐步探索由 Agent 参与性能调优和结果验证。随着已有算子、接口约定和部署流程逐步沉淀后续模型就有机会复用这些工程成果把适配工作更多集中在新增差异上。对团队来说这意味着更少的重复开发、更短的接入周期也让之前投入的人力和时间继续产生价值。接上从训练到本体部署的下一环之前于超老师团队的Rlinf解决了强化学习后训练的问题。APXInf 则是另一条工程链路是在将 RLinf 的能力从训练与评测进一步延伸到端侧推理与本体部署。这也是为什么 APXInf 选择在 RLinf 生态中首发的原因。让开发者可以沿着同一套具身智能技术生态完成从模型训练、效果验证到机器人运行的完整流程。具身模型训练结束后工程其实才刚开始VLA 进入真实机器人后推理引擎就不能只负责“把模型跑起来”。它需要在有限的功耗和带宽下接住多视角输入、完成动作生成并以稳定、可预测的时延持续响应控制系统。计算如何组织、数据如何流动、资源如何分配最终都会影响机器人等待动作的时间。任何一环跟不上Demo 都很难继续走向真实的本体部署。更值得关注的是APXInf 对部署门槛的降低。通过 Agent 协助部署开发者可以更容易地使用已支持的模型。后续团队还计划把更多模型接入、适配与验证经验整理成可复用的工具和流程让新模型、新硬件的接入从已有积累出发逐步减少对重复手工工作的依赖。一次优化留下的代码、路径与验证经验也有机会继续服务后续模型和硬件。根据APXInf团队的后续规划他们还将逐步适配更多具身模型与国产硬件并针对不同模型和平台持续优化向更高的推理性能推进。对具身团队来说这种扩展的价值在于接入门槛有机会持续降低已有实现和部署经验能够被更多项目复用。换一个模型、换一套硬件时团队可以少做一些从头适配的工作减少时间与人力投入。让一次适配留下的积累成为下一次部署的起点。致谢APXInf 的开发深受以下优秀开源项目的启发。我们向这些项目的社区致以诚挚的感谢感谢他们的开源精神与技术贡献。FasterTransformer: https://github.com/NVIDIA/FasterTransformerTensor-LLM: https://github.com/NVIDIA/TensorRT-LLMllama.cpp: https://github.com/ggml-org/llama.cppvLLM: https://github.com/vllm-project/vllmsgLang: https://github.com/sgl-project/sglangFlashRT: https://github.com/flashrt-project/FlashRT