企业官网建设流程全解析

在频繁重规划的任务里，模型算出一整块动作，客户端往往只执行其中一小段，就开始下一轮。FASTER顺着这个“用不完”的现象分配计算：近期位置先完成，完成后逐步发送，够本轮执行就结束剩余采样。

我把阅读重点放在三个时刻：第一条新增动作何时到达，下一轮观测何时发生，整个任务何时结束。论文里的加速数字分别对应不同环节，不能互相替代。沿着这些时间读方法和实验，也更容易看出启元 Q1 适配时该先测哪一段。

1. 论文速览 研究对象是等待新动作的时间

作者在 Piper 平台开展实验。FASTER 可以帮助检查策略服务器和客户端的等待，本篇也据此分析 Q1 适配；论文没有给出 Q1 的任务表现。

图1 论文的 arXiv 题录页。本文锁定 v3，避免把不同修订版的表格或方法条件混在一起；访问日期为2026年10月20日。

若已部署通过多次采样生成动作的策略，正准备排查动态目标跟踪中的等待，这篇值得细读。它提供的是采样与发送机制；感知是否看准、指令是否理解正确，仍取决于原有模型。

2. 方法拆解 让近期动作先完成

论文选了 π₀.₅ 和 X-VLA 两个模型，它们都属于 VLA（Vision-Language-Action，视觉—语言—动作）。输入里有相机画面、语言指令和机器人当前状态，输出是一串后续动作。以本文讨论的流匹配式结构来看，视觉语言骨干先处理观测与指令，动作专家接着通过多轮计算修正动作表示。

这就有了两套计数。采样步数的是动作专家做了几轮更新；控制步数的是序列里要执行的动作时间点。例如30 Hz序列里的相邻动作相隔约33.3 ms，模型为生成它们做了几次采样，是另外一件事。读到“十步变一步”时，应对应到前一种计数。论文第3.1节

2.1 问题 动作连续以后仍有等待

读论文里的动作块，可以先在纸上画一排格子。H 个格子是本轮预测长度，其中实际用到 s 个，就开始下一次决策。H 描述“预测了多远”，s 决定“多久重新看一次”。TTFA（Time to First Action）则从发起推理请求开始计时，到首个可执行动作返回为止。

例如，一次得到50步预测，不代表50步全部执行。只用前几步就重新观测，是为了让后续决策看到更新后的状态。同步流程会等动作执行结束再计算；异步流程把两件事重叠起来。提前计算能省去停顿，事件若发生在观测之后，仍要等下一次请求才能被看见。

这一点可以用时刻表检查。设两次请求相隔 P 秒，事件恰在前一次请求之后发生，等待接近 P；若发生在下一次请求之前，等待接近0。再加上固定有效时延 L，在事件相位均匀的假设下，平均值就是 L+P/2。将 P=s/f 代入，得到论文异步时序分析中的关系：

平均反应时间 = L + s / (2f)。

其中 f 是控制频率，L 表示从客户端发送观测到收到可用动作的固定有效时延，包含推理、通信、数据处理等开销。在这个模型中，事件对应的反应时间介于 L 与 L+P 之间；均值不能当作每一次事件的响应时间。真实系统还要检查观测是否准时、L 是否稳定，以及动作到达后是否留在旧队列里等待。论文表1、第2节及附录G

图2 X-VLA / RTX 4060的系统时间线。参数取自论文表2；事件处于刚错过观测的最坏相位极限，首动作到达后立即采用。右侧单列均匀事件相位下的平均反应时间。

2.2 为什么近期动作也被拖到最后

FASTER 面向流匹配一类动作模型。它从噪声形式的动作表示出发，经过多次更新得到预测，模型内部常把这个过程称为“去噪”。原有常数调度让所有动作位置一起推进，第一步即使容易估计，也要和整串动作一起等到最后。

作者为此先做了一组检查：去噪路径偏离直线多少？中间一步估计出的干净动作，与最后输出差多少？这里的路径位于动作表示空间，不能理解成机械臂末端走直线。微调后的 π₀.₅ 在近期位置上，这两项量更小；已有动作前缀又为近期预测增加了约束。因此作者尝试减少这些位置的计算轮次。先导实验给了设计依据，是否真的生成可靠动作，还要看后面的任务评估。论文第3.2节

2.3 HAS把动作完成时间错开

Horizon-Aware Schedule（HAS）给每个动作位置分配自己的采样进度。靠近当前时刻的位置先完成，远处的位置继续更新。α 控制远近位置完成时刻的分布，u₀ 决定首个新增动作何时完成；当采样步数 N=10、u₀=0.9时，首个新增动作经过一次更新即可完成。

训练为什么也要调整？预训练模型熟悉的是所有位置共用相同进度。直接让全部微调样本改用 HAS，一方面改变了原有的时间分布，另一方面会让近期位置频繁处于无噪声的真值状态，减少学习生成这些动作的机会。作者采用混合调度：以 p 的概率使用 HAS，以 1−p 的概率保留常数调度。默认 p=0.5，每个样本有一半概率使用 HAS；“不改架构”没有免去相应微调。论文第3.3节

HAS 先解决“什么时候算完”，流式接口再解决“什么时候送到”。服务端把完成的动作立即发出，客户端边执行、边补充缓冲；若仍等整块打包，近期动作提前完成的好处就无法及时兑现。本轮实际要执行的那一段全部完成后，早停会结束剩余采样，让服务器更早腾出时间处理下一次观测。因此，在后续动作供应跟得上控制节拍的前提下，可行的执行长度 s 也能减小，请求周期 s/f 随之缩短。TTFA 更低与重看环境更频繁，是两项相互配合的收益。s 的选择还要检查后续动作到达和本轮计算结束的时刻，不能只按第一条动作的时延来定。论文第3.3节及附录D.2、算法2

公开代码中的compute_HAS对应调度计算，mix_prob对应混合比例。代码默认 α=0.6、p=0.5、u₀=0.9与10次采样，图3沿用其中的调度与采样设置；论文的 X-VLA 在 LIBERO、CALVIN 上另取 α=0.7，后面的消融也要按该条件阅读。官方实现固定提交，训练设置，PDF第26页

图3 常数调度与 HAS 的完成顺序。H=50、前缀长度d=3、N=10、α=0.6；每个格子表示一个动作位置在相应采样步结束后的完成状态。

把这项工作放回领域中看，RTC 主要处理相邻动作块怎样衔接；FASTER 继续追问，新观测对应的第一条动作能否更早到达。它与提高视觉编码效率、缩小网络等方法有不同着力点，可以互补。双方的实验条件不同，不宜据此判断某种方法在所有场景都更好。RTC原论文

3. 检验证据 提速是否转化为任务收益

3.1 表2里的两个模型为何受益不同

论文在 RTX 4090、RTX 4060 上比较 π₀.₅ 与 X-VLA，控制频率设为30 Hz，并为反应时间分析选用最小可行执行长度。下面只摘出同一张 RTX 4060 的异步基线与 FASTER，避免跨硬件比较。

数据来源：v3表2，PDF第7页。TTFA 是作者报告的时间测量；最右列依据时序模型计算，不能当作逐个突发事件的实测机械反应时间。附录表4对接收时间注明为20次试验的均值与标准差。

X-VLA 的 TTFA 约加速3.09倍，π₀.₅ 约1.27倍，都不是十倍。原因并不神秘：把动作专家的采样从十步压到一步，并没有同时去掉视觉语言编码、数据搬运与通信开销。若本来的主要耗时就在这些环节，仅减少采样次数，收益自然有限。

图4 论文表2、表10的结果对照。左侧为 RTX 4060 的 TTFA，越低越好；右侧为 CALVIN ABC→D的平均完成链长，越高越好。左右分别使用各自单位和图例。

3.2 乒乓球表格里的0.467怎样读

作者用 AgileX Cobot Magic 做乒乓球回击、饮料取放和毛巾折叠。乒乓球更依赖及时响应，另外两项则帮助检查加速后是否损害一般操作能力。每个条件的评估回合分别为15、35、10次；乒乓球示范有335段，约14分钟。附录E.1，PDF第23—24页

需要特别留意评分方式。乒乓球采用0、0.5、1的分级评分，包含是否击中与回击力度。π₀.₅ 在 RTX 4060 上，Training-time RTC 的平均分为0.300，FASTER 为0.467；对应96% bootstrap置信区间分别为[0.133, 0.500]与[0.333, 0.567]。表8，PDF第27页

这个评分还有一个容易漏看的细节：弱回击记0.5分。平均分里既含命中情况，也含回击效果，没法由0.467直接还原“成功了几次”。原表没有把它叫成功率，引用时也应保留平均分的名字。

两组置信区间较宽，反映了这15回合的估计仍有不确定性。区间重叠本身不能判定差异是否显著；作者没有报告两方法得分差值的区间或相应检验，本篇也没有原始回合数据。来球速度在附录中只有尽量控制的描述，换到不同球速时会怎样，还需要新的实验。

3.3 长任务和消融里还藏着代价

CALVIN 的输出是一条任务链的完成长度。例如五件事只完成前三件，链长就是3。这个测试没有乒乓球那种强烈的反应时间压力，更适合检查改动后的策略是否仍能把后续动作做对。表10记录 π₀.₅ 为4.313，加 FASTER 后为4.292；X-VLA 则是4.151与4.093。表10，PDF第28页

两组平均链长的点估计都略有下降，但原表没有报告跨训练重复的波动范围，尚不能据此确定是否存在稳定的精度代价。它提醒开发者在测速度时继续测任务能力。再看取饮料实验：Training-time RTC 的用时11.9 s，FASTER 为12.0 s；对应平均得分分别为0.950和0.957。这里的耗时没有继续缩短。表9，PDF第28页

接着看表13的 p。这个参数决定训练样本使用 HAS 的比例；该消融使用 X-VLA / CALVIN，并固定 α=0.7。X-VLA 在 p=0.5 时得到4.093，全部使用 HAS 的 p=1.0只得到3.112。若准备照着做，值得把这一行和采样公式放在一起：只有推理步骤、没有合适的调度训练，未必能保住策略能力。表13，PDF第30页

表2测动作何时到达，表8评回球质量，表9记录任务用时。引用时把平台、指标和比较对象一起写下，就不容易把“首动作更早返回”转写成“每项任务都更快结束”。

4. 转化价值 启元开发先检查时间链路

4.1 从官方接口确定适配边界

Q1 的接口与上肢例程，可查启元官方 SDK 仓库。本文使用开源标签 v1.0.0，链接已锁定提交。官方资料下载页中的 Q1 SDK 则标为 v1.0.0.0；代码核对采用前者，页面截图记录后者。

图5 官方页面中的 Q1 SDK 下载条目，标记为 v1.0.0.0、13 MB，下载按钮位于该行右端。

上肢例程 upper_body_control.py里，PUBLISH_RATE_HZ = 100.0控制发布节拍。程序预先建立10个关节的消息，publish_pose逐帧更新位置、时间戳和序号后发送。这个100 Hz属于客户端发布线程，不能拿来代替策略模型的生成频率。

接口说明中“自定义上肢关节控制”一节给出了具体约束。Topic 是/aima/mc/custom/joint/command，这10个关节由双臂8个和腰部2个组成。文档建议连续发送完整目标，遗漏目标按0处理；进入BIPED_CUSTOM_UPPER并确认RUNNING后才开始，header.stamp保持单调递增。

Q1这里还有一个时间细节。100 Hz发布线程每10 ms工作一次，论文30 Hz动作序列的间隔却是约33.3 ms。每个预测点若都固定发三次，就只覆盖30 ms，次数越多，和原定时间偏得越远。适配时可以让发布线程按动作时间戳查找当前目标，再依动作含义选择保持或插值，每次都填全10个目标。官方例程用半余弦函数平滑两个姿态，提供了一种参考，并未规定策略输出只能这样处理。输出若为关节增量，要结合当前状态恢复目标；若为末端位姿，还需做运动学适配。

图6 面向 Q1 的适配架构。虚线框为动作适配层；T₀—T₃依次记录观测采集、请求发出、首动作返回和首次采用。模型推理、动作缓冲与100Hz发布分别运行。

若下一步在 Q1 上做适配，我会先为一条观测保留序号，沿着采集、发起请求、收到首动作、首次采用四个位置打时间记录。跨机器的记录还要注明时钟关系。这样可以查出新动作究竟在网络里、缓冲区里，还是执行端等待。

4.2 先在电脑上复核调度 再决定是否做完整复现

本文提供一个可直接运行的教学项目，代码版本1.0.0，实测 CPython 3.12.14。主脚本只用标准库，不需要机器人或服务器。它按论文公式计算 HAS，并枚举事件在周期内的发生相位，核对平均等待时间；不会加载 VLA 权重、生成关节命令或连接硬件。

从本文 AtomGit 配套仓库 v1.0.0取得项目后，在终端依次执行：

gitclone--depth1--branchv1.0.0 https://atomgit.com/xiongwenhao888/faster-q1-reading-lab.gitcdfaster-q1-reading-lab python3 has_demo.py--outresult

运行后得到调度 CSV 和结果 JSON。本次输出中，第一个新增动作 i=3 在第1步归零，i=49 在第10步归零；常数调度里的两者都等到第10步。把表2的 X-VLA/RTX 4060 参数代入时序公式，程序算出599.5 ms与229.2 ms，与原表一致。输入时延来自论文，本地只重新计算这个关系。

图7 配套项目 v1.0.0 的运行结果：首尾动作完成步数与两组反应时间公式核验均通过。参考函数核对工具的使用方法与依赖版本见仓库 README。

若要进一步复现完整 FASTER，应先按作者仓库准备数据、归一化统计、微调权重和硬件环境。该版本使用 JAX/CUDA，官方说明给出推理显存大于8 GB、LoRA微调大于22.5 GB、全量微调大于70 GB的估算，并报告在 Ubuntu 22.04 验证过全量微调。仓库示例对接 Piper 平台，README给出用户自行训练的检查点路径；本次未找到论文实机微调权重的下载入口。论文没有 Q1 实验，迁移还需 Q1 的数据与动作映射。本文的本地验证覆盖调度公式与参考函数，完整模型和本体迁移按上述流程另行验证。

引用与复核入口：论文 v3、FASTER固定提交、Q1 SDK固定提交。四张原创解释图的 SVG 与生成工具见配套项目 article-v1.2.0。

4.3 总结 从首动作时延到任务收益

FASTER把动作块内部的计算安排，与动作实际使用的先后顺序联系起来。HAS 让近期动作先完成，流式接口把完成的动作及时送到客户端，早停再为下一轮观测腾出计算时间。三者共同缩短等待，混合调度训练则帮助模型适应新的生成方式。

实验给出了收益，也划定了适用范围。同一张 RTX 4060 上，X-VLA 与 π₀.₅ 的 TTFA 分别加速约3.09倍、1.27倍；取饮料任务的用时却没有随之缩短。CALVIN 的点估计变化还需要结合重复评估判断。首动作时延、动态任务得分与整项任务耗时，应分别记录和解释。

对启元 Q1 开发，能够先用起来的是这套测量方法：沿着观测采集、请求发出、首动作返回和首次采用记录时间，定位计算、通信及缓冲中的等待，再选择对应的优化。模型的动作空间与 Q1 的关节接口对齐后，策略生成和100 Hz目标发布仍需按各自节拍运行。

回到开头的三个时刻：第一条新增动作何时到达，决定动作供给有多及时；下一轮观测何时发生，决定多久重新了解环境；整个任务何时结束，检验这些改进是否带来了实际收益。这也是阅读 FASTER 后评估机器人响应性能时，应一起保留的三项指标。

启元机器人模型、SDK与后续开发资料，可到启元机器人开源组织和启元机器人开发者社区 https://dev.primebot.com/查阅。