APXInf开源推理引擎 破解机器人具身部署难题

把视觉语言大模型部署到机器人本体上，是很多具身智能开发团队都绕不开的工程难题。不少团队好不容易在云端或仿真环境里跑通了模型，到了实体机器人端侧，却要面对算力、内存、功耗的多重限制，还要满足实时响应的严苛要求。算子适配、张量布局调整、内存分配优化、数值精度对齐，每一项都需要逐一攻克。对于缺乏推理系统专业人才的团队来说，这些繁琐的工作往往会拖慢自研模型从Demo走向实际落地的进度。只有缩短这个部署周期，模型的技术进步才能更快转化为机器人在真实场景中的执行能力。

为了解决这些部署难题，无问芯穹联合清华大学、上海交通大学推出了APXInf。这是一款专门面向具身模型、为机器人量产部署打造的开源高性能具身端侧推理引擎，目前已经适配了两款主流具身模型和三款芯片，在Jetson AGX Thor平台上达成了行业领先的性能表现。

这款引擎在底层针对具体模型和硬件定制优化执行路径，同时将AI编程助手（Agent）参与模型适配和性能优化的流程纳入了项目的整体设计中。那些在模型适配、性能优化与部署验证过程中积累的专家经验，被整理成了可供Coding Agent执行的工作流与操作技能。我们更愿意将其定位为一款原生支持Agent参与的具身端侧推理引擎。

我们曾在官方已适配的RTX 4090上测试了π0.5模型的实际运行表现，后续还意外发现APXInf可以在DGX Spark上运行——尽管当时官方尚未适配这款硬件。我们便按照APXInf自带的开发工作流指南，将Qwen3-VL模型迁移到了DGX Spark平台上，完成了完整的迁移开发和使用测试。

机器人端侧的小批量推理，核心关注点在于单次观测输入后，模型能否在规定时限内返回控制动作。多视角图像处理、模型前向计算和动作生成需要共享有限的计算与内存资源，因此除了整体吞吐量，还要重点关注响应时延及其波动幅度。

APXInf针对每个具体模型，将内存分配和算子执行安排在明确的静态执行路径中。计算流程通过CUDA Graph捕获后，可以复用预先分配的缓冲区重复执行；经过自动调优选出的kernel也会保留在设备中，减少每次推理的重复开销。

开发者可以通过熟悉的Python接口调用模型，性能敏感的计算部分交由底层的高性能算子库处理，而Rust语言则负责内存和资源管理，确保运行的安全性与稳定性。这样一来，使用模型的团队既可以保留原有的开发习惯，又能获得性能提升和运行稳定性的保障。

随着模型结构和硬件环境的不断变化，静态执行路径往往需要进行调整。APXInf从框架设计之初就顺应行业趋势，将自身定位为原生支持Agent的具身端侧引擎，将Coding Agent的开发适配流程纳入了模型接入、前后处理、本体适配和部署验证的完整开发链路中，充分适配Agent时代的开发需求。

具体的开发适配入口位于skills/model-port-workflow/目录，其中关联了模型移植、模型层架构、执行路径集成和新增算子的工程文档。其中有三个核心环节尤为关键：

1. 先跑通原模型，建立对照基准

在开始移植前，需要先确定模型与参考代码的版本，固定所用的权重文件。在此基础上，明确目标设备、推理精度和测试输入，约定允许的误差范围。随后在隔离环境中运行参考实现，保存输入、输出和必要的中间张量，用于后续的对照验证。中间张量可以帮助定位偏差最早出现的位置，避免仅凭最终输出通顺就认定实现正确。不同的实现方式必须保证计算结果一致，因此改写前后需要使用完全相同的输入、权重和随机条件，再按照事先约定的误差范围逐项比对。仅仅通过编译测试、看着输出正常，还不能算完成移植工作。

2. 优先复用现有算子，再补充缺失能力

仓库中存在某个算子，并不意味着模型可以直接调用它。要启用高性能路径，还需要目标架构的编译支持、匹配的数据类型与内存布局，以及正确的调用条件。流程要求先检查已有实现，优先复用现有能力；如果遇到数据布局不匹配的问题，可以在接入时做适配转换。如果确实缺少高性能实现，可以先用正确但速度较慢的版本验证功能，确认能力确实缺失后再开发新的算子。代码的修改范围也有明确的边界：模型层负责处理模型结构、权重映射和执行顺序，通过统一的安全接口调用底层算子，不直接操作CUDA或跨语言接口。这样Agent修改模型时有清晰的边界，工程师也更容易判断哪些部分需要重新测试。

3. 验证结果正确性，检查性能表现

验证工作从改动过的算子开始，逐步扩大到完整模型，并通过实际使用的API检查调用结果。需要覆盖约定的设备和精度组合，启用CUDA Graph后也需要重新核对输出结果。性能测试则需要记录时延和内存占用，结合数据搬运开销查找性能瓶颈。必须先保证结果正确，再追求性能提升。如果功能跑通但性能未达到目标，需要如实记录瓶颈位置和后续优化方向，不能将“能够运行”等同于“已经做好”。临时脚本、张量文件和日志可以放入Git忽略的devlocal/目录，提交的代码、测试和文档则需要保留可维护的版本，便于后续审阅和回归测试。

对于具身开发者来说，判断一个推理引擎是否好用，既要参考已支持模型的运行表现，也要看接入新模型和硬件的便捷程度。我们先看官方公布的π0.5测试结果，再结合Qwen3-VL的适配实践，看看APXInf在这两方面的表现。

官方测试表现

以机器人领域主流的π0.5模型为例，APXInf仓库中直接提供了Python Policy封装（build_robot_policy），并自带兼容OpenPI的服务接口。开发者无需手动处理底层显存预分配或CUDA Graph捕获，只需要传入多视角相机的原始画面，即可获取机器人的控制动作。根据官方在APXInf-robo仓库公布的基准测试，π0.5在RTX 4090上的单步推理延迟为31.38ms（BF16精度，对应31.9Hz帧率）和25.99ms（INT8精度，对应38.5Hz帧率）；在车载边缘平台Jetson AGX Thor上，FP8精度的延迟为41.16ms（对应24.3Hz帧率）。同时在官方公布的LIBERO-10评测中，Thor平台上的任务成功率为92.2%（FP8）和92.8%（BF16），与参考实现的92.4%基本持平，说明在提速过程中没有损失原有的任务完成表现。我们在RTX 4090上复测了π0.5的表现，结果与官方公布的数据基本一致。

扩展适配实践

除了官方已适配的模型，更换其他模型或硬件的适配过程又是怎样的？我们从RTX 4090上的Qwen3-VL适配排查开始，随后将工作扩展到搭载GB10芯片的DGX Spark平台，以APXInf的移植流程为指导，让Coding Agent参与到排查和优化工作中。本次适配工作基于APXInf仓库的commit 7126992展开，后续验证对齐至26a4c9c，主要经历了四轮关键改动：

首先解决模型尺寸兼容问题：原有实现中存在维度硬编码和因果Softmax网格限制的问题，导致4B、8B尺寸的模型运行异常。通过对照参考实现，按照实际配置推导维度并修复网格限制后，多尺寸模型的运行路径得以跑通，对应PR#57。

其次补齐新硬件支持：当时的架构匹配规则尚未覆盖GB10芯片，补齐识别逻辑后，仓库中已有的CUTLASS等实现可以为该设备编译并运行，对应PR#60。

接着优化视觉编码速度：排查发现，视觉编码和语言预填充阶段尚未使用已有的FlashAttention-2优化。接入该优化后，在GB10、Qwen3-VL-2B、BF16精度和指定高清图输入的配置下，首token延迟从150.7秒降至2.51秒。这是该适配路径优化前后的单次测试结果，详细内容见PR#64。

最后处理视觉模块的LayerNorm瓶颈：将LayerNorm的调用从串行归约改为已有的块并行实现后，GPU kernel的总耗时降低约六成，端到端首token延迟进一步下降约10%。两者的降幅不同，是因为主机侧的数据搬运仍占用了较多时间，详细内容见PR#66。

四轮改动均已整理为PR提交至官方仓库，具体配置和验证结果可以查看对应记录。完成这次适配后，我们最深的体会是：工程师负责把控整体方向、确定测试边界和最终的代码审查，而Agent则可以在规范约束下完成查找算子、提取张量、进行分层对齐等具体工作。很多时候我们不需要从头开发新的工具，仓库中本来就有现成的优质算子，工作流规范让Agent可以沿着清晰的路径找到这些能力并完成对接。这种分工模式，比单纯依靠工程师死磕底层细节要轻松高效得多。

完成适配后，我们进一步在DGX Spark上对比了APXInf与主流框架的性能。

这里展示的是APXInf在原先未正式支持的硬件上，经过我们完成模型适配与优化后的性能表现。测试模型为Qwen3-VL-2B-Instruct，各框架均使用官方BF16权重，输入同一张1344×1792的图像，包含9408个图像patch，图文输入合计2379个token，以贪心解码方式生成256个token。

测试结果显示，APXInf的解码速率超过了vLLM和SGLang，也明显高于Transformers框架，但首token延迟仍然相对更长。结合之前的性能分析，主机侧的数据搬运是后续需要继续排查和优化的重点。需要注意的是，本次测试得到的TPS是VLM文本生成的速度，48.2 tok/s不能直接换算为机器人的控制频率。完整的机器人控制链路还包括感知输入、动作生成、数据传输和硬件执行等环节。总的来说，这次测试的结果有些超出预期，APXInf的解码速度竟然比vLLM更快，足以证明其性能表现相当出色。

经过这次完整的实测，我们认为APXInf值得关注的亮点，除了优秀的推理速度之外，还有它让Agent参与底层开发的设计模式。模型技术会持续更新，适配工作也不会只做一次。如果每次适配新模型都需要等待少数专家从头排查，那么新模型落地的速度就无法提升。APXInf将专家经验固化到工作流中，让Agent可以承接具体的适配工作，让开发团队减少重复摸索的成本。

虽然仍然需要工程师把控整体方向，但有Agent协助排查和修改代码，工程师可以腾出更多精力投入到模型本身的改进中。这也解释了它为什么会在RLinf生态中首发：RLinf支持模型训练与评测，APXInf负责端侧推理与部署，两者结合起来，让模型从训练到落地的完整链路更加顺畅。

我们期待这次实测中用到的适配与优化流程，能够帮助更多具身智能团队快速将自己的模型部署到机器人上，让模型的技术进步早点惠及真实的机器人应用。

目前相关项目已经正式开源，如果你也在为机器人本体的端侧推理部署寻找高性能解决方案，可以前往APXInf官方仓库体验：https://github.com/RLinf/APXInf-robo。

本项目设有官方交流群，可扫码加入。