你让机器人看见桌上的杯子，再按指令伸手去拿。真正决定它是否“反应及时”的，不是某一道计算题做得多快，而是从摄像头画面进入系统，到动作指令出来，一共等了多久。中间哪怕每个计算模块都很快，若模块启动、交接数据和重复计算耗时太多，机器人仍会显得迟钝。
这正是 FLASHRT-PAI 想解决的问题。它面向 Physical AI，也就是让模型参与现实世界感知和行动的系统。作者把优化对象从单个推理内核，扩大到完整的感知—决策—动作管线。这里的“内核”（kernel）是 GPU 上执行的一小段底层计算；“端到端延迟”则是从传感器输入到动作输出的总等待时间。
本文数字与发布情况均来自 Liang Su 等人的论文及其作者记录，尚无材料中的第三方复现或独立核验。
快内核为什么拼不出快管线？
论文关注三类机器人策略模型。VLA（视觉—语言—动作模型）同时读取画面和文字指令，再生成动作；VA 会一起生成视频与动作；WAM 则进一步预测未来画面和动作。它们有一个共同特点：实时推理通常采用单批次，也就是一次只处理当前这一份输入。此时，大规模计算未必是唯一主角，许多细碎开销反而更显眼。
作者在 Jetson AGX Thor 上分析一条官方 PyTorch eager——按程序顺序即时执行的默认路径。一次决策耗时 222.64 毫秒，其中内核之间估算出的空档为 50.14 毫秒，占 22.52%；夹在矩阵乘法之间的其他内核又占 70.10 毫秒。它们负责归一化、残差相加、布局转换和精度转换等工作。每拆成一个独立内核，系统就要多启动一次，还可能把中间结果写入显存，紧接着再读出来。
连续决策还会制造另一种浪费。机器人的文字指令可能很久不变，相邻两次决策也常共享部分条件，但普通调用路径可能每次都重新计算。说白了，厨房已经备好了同一份配料，系统却在每次出菜前重新切一遍。
它优化的是“接力方式”
FLASHRT-PAI 采用模型—硬件管线协同设计，核心有三部分。
第一是深度内核融合。它把可以连续完成的小操作合并，减少启动次数和中间数据往返。但作者强调，合并得多不等于一定更快。某次初始设计虽然减少了内核，却让下一个矩阵乘法读取了更多数据，整条链反而变慢。最终版本改用更紧凑的输出布局。关键不是消灭一道边界，而是让上一步交出的结果正好适合下一步接手。
在论文给出的一个动作解码层里，torch.compile + FP8 路径需要 20 个内核，FLASHRT-PAI 的 FP8 路径降到 12 个；NVFP4 路径为 11 个。完整管线相较官方 eager 路径减少了 59%至93%的 GPU 内核。不过，这个降幅同时包含融合和取消重复计算，不能只归功于融合。
第二是启动重叠。若后一个内核暂时只需加载权重，不必立刻读取前一个内核的结果，它就可以提前开始准备，到真正需要数据时再等待。FLASHRT-PAI 借助 CUDA 的 Programmatic Dependent Launch（允许有依赖关系的 GPU 工作部分重叠执行），为具体模型标出安全的触发点和等待点。在一组保持内核与精度不变的配对实验中，这项机制把整次调用从 21.960 毫秒降至 21.044 毫秒，改善约 4.2%。这也说明，局部重叠有效，却不会自动加速管线里的其他阶段。
第三是 execution contract，可理解为一份“执行约定”。它记录各阶段的先后关系、输入多久更新一次，以及哪些具名缓冲区可以保留。指令没变，就复用依赖指令的结果；新画面来了，只刷新与画面有关的部分。论文在 Thor 上让相同路径保留可复用状态后，平均决策延迟从 37.05 毫秒降到 21.61 毫秒，输出动作逐比特一致。
在这份约定之上，系统还能制作 execution-state capsule——执行状态胶囊。它像一份正在进行中的工作现场快照，可供恢复或分叉会话。另一会话覆盖工作区后，恢复 pi0.5 的 14.40 MB 状态并生成下一动作需 9.73 毫秒；重新构建上下文则需 21.48 毫秒。胶囊并非通用存档：它只能在进程内使用，并绑定具体执行方案和设备地址。
数字要放回基线里看
论文在 RTX 5090 上评测六种策略，在 Jetson AGX Thor 上评测四种。最值得注意的是两组不能混为一谈的结果。
在同为 16-bit 精度时，FLASHRT-PAI 相比官方编译路径快 1.3至3.7 倍。这组比较更能说明管线设计、专用内核、图回放与状态复用的综合价值。另一组 3.38至12.66 倍的加速，则以官方 eager 实现为基线，同时采用了更低精度。它既换了执行管线，也换了数字精度，因此不能把全部收益归因于管线优化，更不能与前一组数字直接拼接。
低精度是否会让机器人“动作走样”，论文用 LIBERO-10 仿真任务做了检查。四比特 pi0.5 在 Thor 上成功率为 94.04%，在 RTX 5090 上为 93.32%；作者实测的官方 FP16 参考为 92.4%。这说明该测试中低精度版本没有表现出成功率下降，但三者精度、硬件和执行路径不同，92.4%也是作者测得的参考值，不能解读成四比特天然优于 FP16。
为什么值得关注？
这项工作的意义不只是又写了一批快内核。它提醒机器人系统的开发者：实时性是一项管线属性。模型内部不同部分的更新频率不同，数据格式是否顺手、阶段能否重叠、旧结果何时失效，都会进入最终延迟。
FLASHRT-PAI 还提供替换式接入：现有 PyTorch 模型不必整体改写。候选内核只有在结果与参考路径一致、且完整调用确实更快时才启用，否则保留原路径。论文称项目已开源，经 Hugging Face Kernel Hub 分发，pi0.5 的可选内核也已被 LeRobot 采用；但这些发布与采用情况在所给材料中没有独立来源印证。
局限与未知
- 论文测的是预热后的离线推理，不包含网络传输、模型加载、校准、图捕获和真实机械动作。实际控制循环还取决于应用如何安排重新规划。
- 材料未给出完整功耗、统计方差及所有复现条件。不同模型的速度数字也使用不同基线和精度，不能简单横向排名。
- 新的模型—硬件组合仍需人工设计阶段边界、数据布局、精度和等待点。论文关于通用图编译器局限的概括较强，现有证据不足以断言所有通用编译器都无法实现跨调用状态复用。