企业官网建设流程全解析

278ms。

这个时长对于人类对时间的认知来说，几乎是一瞬间。同时，它也是Pi0.5 使用 OpenPI 基线在端侧完成一次推理的等待时间。

然而对于机器人来说，这个时间还是太长了。

从指令进入系统，到机器人开始动作，中间的每一段等待都有代价。

模型算出来的是正确答案，但物理世界已经变了。

杯子可能移动，人的手可能伸过来，机器人的动作不再合时宜。

换一台更强的服务器，可以解决部分计算问题。

但对需要移动、进入家庭或在网络条件不稳定的场所工作的机器人，通信时延、连接可靠性、部署成本和功耗都会成为约束。算力设备还要装进机身，消耗电量，并满足散热要求。

端侧推理优化要解决的，就是在这些约束下，把有限芯片的性能充分发挥出来：让模型及时完成计算，同时为其他任务和整机续航留出空间。

原文链接：机器人不接受迟到的答案！Thor 芯片上，Pi0.5推理被干到了26ms，10.7倍加速。

VLA的实时推理被什么卡住了？

谈这个问题之前，先思考一下：机器人收到一组观察之后，还要做哪些事？

多路图像需要处理，语言和状态需要转换成模型输入。

之后，输出的动作还要后处理，才能进入控制系统。

数据复制、处理、算子启动、显存分配和模块间之间的等待，都可能出现在这条链路里。

从input到output，涉及很多前置和后置处理。

模型在仿真环境中效果不错，甚至可以说是完美；但到了机器人本体上，可能响应速度都不够。

其中一个重要原因，就是VLA这类模型没有专属的推理引擎。

到了端侧，VLA 要与相机、定位、规划和控制等模块共享有限的算力、带宽与功耗。

这是一个很复杂的系统工程。

云端服务追求多请求下的整体吞吐，机器人端侧更关心小batch时的一次响应能有多快、多稳定。

性能之外，适配同样耗人。

模型换一块芯片或一个驱动版本，算子、精度路径和内存布局可能都要重新适配。

换一个机器人本体，相机输入、状态维度、动作定义和控制接口又要重新接入。

每增加一种部署组合，团队往往都要从零开始重新适配，完整的排查、优化和验证流程需重新走一遍。

研发投入极大。

但跑通一次也只是开始。

时延抖动、资源泄漏、异常中断，以及多台设备和多个软件版本能否保持一致，直接决定了机器人能否在真实场景中持续、稳定地工作。

VLA 从 Demo 走向本体，急需一套专为真实硬件约束设计的推理引擎。

单次响应要快，连续运行要稳，模型和硬件能低成本的快速接入

让VLA的计算和物理世界的变化同步。

APXInf 就是在这些约束下出现的。

它由无问芯穹主导，联合清华大学与上海交通大学推出，定位是面向机器人本体的 VLA 高性能推理引擎，重点服务小 batch、多视角、强实时的推理场景。

• GitHub： https://github.com/RLinf/APXinf-robo

• Quick 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.5+FP8+Thor下的实测结果。

相比于之前的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/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