远程推理

大型策略需要 GPU，而在同步 rollout 中，每当策略计算下一段动作时，机器人就会停止运动。远程推理将任务拆分为两部分：策略服务器在 GPU 上运行检查点，而机器人计算机则负责控制摄像头、电机、遥操作和录制。机器人在服务器计算下一批动作期间继续执行已有的动作，因此运动不再因推理而暂停。

使用时机：

• 连接到机器人的计算机没有 GPU，或者 GPU 太小，无法满足策略的需求：例如，机械臂旁边是一台笔记本电脑或单板计算机，而实验室的另一端则是一台 GPU 工作站；
• 推理过程占据了每个动作片段中相当可观的时间，而你希望实现连续的运动；
• 您希望在不触及检查点的情况下，决定机器人重新规划的频率。

你所调节的唯一权衡是新鲜度与连续性。更早地请求新计划能让机器人对所见做出反应；而更多地遵循当前计划则能保持任务进度。

工作原理

机器人计算机维护一个即将执行动作的缓冲区。当缓冲区中的动作数量不足时，它会发送一条新的观测数据，在服务器进行计算的同时继续从缓冲区中执行动作，并将新计算出的动作片段拼接进计划中尚未执行的部分。

三个客户端设置决定了这一行为。refill_seconds 决定提前多久请求下一个计划，chunk_merge 决定如何将新计划拼接进旧计划，而混合（blending）则平滑两者之间的接缝。服务器只需要检查点以及机器人训练目标的描述。以下各节将从一个可用的配置出发，然后逐步建立对每个设置的直观理解。

本地 RTC（--inference.type=rtc）是另一种异步选项：推理在 rollout 进程的后台线程中运行，位于同一台机器上，无需服务器。在同一主机上进行的远程推理仍使用两个进程和 --inference.type=remote，并为没有 RTC 的策略提供对齐和混合功能。请参阅 RTC 与远程推理的关系。

支持的政策和机器人

当检查点保存的处理器能够根据单个当前观测预测动作块时，该检查点即可提供服务；ACT 需要禁用时间集成。ACT、SmolVLA、XVLA、EVO1 和 LaWAM 检查点已通过此路径在真实机器人上运行。其他几种策略在契约层面受到支持，但尚未在硬件上验证，且依赖历史的策略需要额外的集成。策略支持表列出了每种策略的状态和限制。

机器人驱动器必须声明支持位置保持，因为客户端在等待动作时会刷新最后应用的目标。因此，SO、OMX、Koch、HopeJr、Rebot 和 YAM 跟随器均声明了该支持；OpenArm、Reachy2 和双手操作封装器则取决于其配置；Unitree G1 仅在配备 SONIC 控制器时声明该支持，其保留的目标是最后一个运动令牌；移动底盘则不支持。请参阅硬件表格。不支持的机器人或策略契约会在准入阶段被拒绝，早于任何运动发生之前。

从一个可用的 rollout 开始

保留一条成功的同步 lerobot-rollout 命令作为参考，并保留其机器人、相机、任务、FPS、遥操作器和插值设置。检查点和模型设备移至服务器；远程客户端不加载权重。

以下示例描述的是一个配备一个前置摄像头的通用六执行器 SO-101。请一并调整检查点、摄像头视角、组件顺序和单位。

1. 在两台计算机上安装

双方都需要 remote 附加组件。在客户端保留硬件附加组件，在服务器上保留所选策略的附加组件：

uv sync --locked --extra remote --extra core_scripts --extra feetech
# Add the policy extra on the server when required, for example --extra pi.

支持的 Zenoh 版本范围为 >=1.9.0,<1.11.0；uv sync --locked 会安装锁文件中的版本，当前为 1.10.1。

2. 配置并启动服务器

复制通用配置，然后对其进行编辑：

cp examples/remote_inference/server.yaml server.yaml

设置 model.repo_or_path 和 model.device。对于 Hub 检查点，请将 model.revision 固定为您打算验证的提交。使 features、action_feature、semantics、robot_type 和 execution.action_fps 与您的工作配置相匹配；请参阅下方的 架构和相机重命名示例。

uv run --no-sync lerobot-policy-server --config_path=server.yaml

服务器会加载检查点，验证其声明，执行预热，然后记录日志 Policy server ready: deployment=<name> instance=<id>; awaiting one client。每个 YAML 字段都支持嵌套的 CLI 覆盖：

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --model.device=cuda \
  --execution.idle_timeout_s=10

3. 启动机器人客户端

在另一个终端中，将硬件参数调整为相同的配置：

uv run --no-sync lerobot-rollout \
  --inference.type=remote \
  --inference.endpoint=tcp/127.0.0.1:7447 \
  --inference.deployment=manipulation \
  --inference.mode=chunk \
  --inference.chunk_merge=aligned \
  --inference.semantics=so101-degrees-gripper-percent-v1 \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.use_degrees=true \
  --robot.cameras='{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
  --fps=30 \
  --task="pick up the cube" \
  --interactive=true

入院后，输入 /start。/stop 会结束运行；请参阅 机器人在等待或停止时执行的操作。请保留您工作 rollout 中的遥操作和录制选项。不要向远程客户端传递 --policy.path、本地模型-设备覆盖项或编译标志。

deployment 用于选择服务器，semantics 用于指定经过验证的动作单元及其顺序；两者都必须与服务器配置相匹配。该示例使用身体关节自由度以及经过校准的 0–100 夹爪范围。

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.listen_endpoints='[tcp/172.18.133.214:7447]'

选择如何继续运动

当新的数据块到达时，用于计算它的观测数据已经略显陈旧，机器人也已向前移动。合并模式决定了如何处理这种情况：在旧数据块之后播放新数据块、丢弃机器人已经走过的步骤，或者平滑衔接处。

此表中的设置使用 --inference. 前缀。普通块默认启用对齐并禁用混合。正在插值的目标会被提交，无法被替换。

Alignment 会丢弃已提交的传入步骤。Blending 会对重叠的未来目标取平均值。Interpolation 会在端点之间添加中间电机指令。RTC 会改变预测的生成方式。它们中的任何一个都不保证平滑的运动或成功的抓取。

--inference.chunk_merge=aligned \
--inference.blend_steps=5 \
--inference.blend_weight=0.5 \
--inference.blend_components='[shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos]'

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --execution.supported_modes='[rtc_guided]' \
  --execution.rtc.enabled=true \
  --execution.rtc.mode=guided \
  --execution.rtc.execution_horizon=15

重要的参数

以下客户端选项默认使用 --inference. 前缀，除非另有说明。默认值是起始值，并非针对特定机器人的保证。

有效补充时间为 max(refill_seconds, recent maximum turnaround + 1 / fps)。周转时间包括编码、网络、排队、推理和解码。首个被接受的请求提供初始估计值；后续的估计值最多使用 100 个稳态样本。

因此，Refill 既不是固定的请求周期，也不是保证执行的动作数量。请在日志中检查已配置的 和实际生效的 refill。如果阈值覆盖了整个执行周期，会导致非常频繁的替换。

机器人在等待或停止时的行为

在支持的等待期间，客户端会刷新驱动程序实际应用的最后一个目标，包括插值、裁剪和夹爪。在第一条命令之前，会通过测量的位姿对其进行初始化。这会停止轨迹的推进；机器人可能仍会向该目标收敛。它不会关闭力矩，也不保证机器人保持静止。本地 RTC 在支持的机器人上使用相同的有界等待，在其他情况下耗尽时立即触发故障。

饥饿恢复会丢弃一个旧的在途预测，并获取一个在等待开始之后捕获的新鲜预测。旧结果无法重启运动。数据包和不可用的结果不会更新宽限期。频繁的等待表明播放或延迟覆盖不足。

服务器或连接丢失不会自动恢复。有效的缓冲操作可能会被耗尽，随后会等待宽限期或其他截止时间到期。一旦观察到服务器存在性丢失，即使连接恢复，该会话也无法恢复；请重新启动 rollout 以创建新会话。在文本处理期间，观察到服务器丢失会导致查询故障。

在观测采集正常且执行器控制良好的情况下，终端关闭会遵循 --return_to_initial_position=true（默认值），然后断开连接。返回过程会读取完整的观测数据，因此持续的相机故障可能会阻止返回。动作失败或保持应用失败会抑制后续移动。将该选项设置为 false 会跳过返回，但不会跳过断开连接。断开连接时，可能会根据机器人配置释放扭矩。终端故障会在清理后以非零状态退出；被强制终止的进程无法保证完成清理。

调优一个可运行的任务

从同步参考点附近开始：执行每次预测的相当大部分，但请求要足够早，以隐藏推理延迟。然后评估更频繁的重新规划是否有帮助。

1. 先使用对齐功能，不要混合。 保持 FPS、插值和设置固定。检查执行范围、完整周转时间和慢速请求。
2. 选择带有裕量的补充覆盖范围。 为下一个请求和延迟波动预留足够的播放时间，而无需持续替换计划。
3. 在该节奏下添加一个短暂的混合。 分别比较任务完成度、抓取/释放以及碰撞。不兼容计划的平滑平均值可能会错过目标物体。
4. 仅在有益时才提前请求。 增加补充频率可以提高响应速度，但会打断有用的进展。如果任务性能下降，请恢复到稳定的节奏。
5. 一次只更改一个设置。增加超时时间或宽限期并不能提供缺失的操作。减少补充量也不是资源耗尽的通用解决方案。

对于 0.8 s 的执行周期和稳定的成功对齐，请求间隔约为 0.8 - effective_refill：

这排除了启动、保持、饱和和控制节拍效应。一个剩余 0.2 s 且耗时 0.1 s 的请求，仅剩下 0.1 s 用于混合，即 30 Hz 下的三个步长。因此，近同步节拍可能只需要很短的混合时间。

对于对齐和 RTC，请检查裁剪后可用的播放时长，而非标称的块长度。如果推理耗时 1 秒，而预测时长为 1.67 秒，则仅剩余约 0.67 秒。另一个 1 秒的请求将无法容纳，任何 refill 值都无法解决此问题。请缩短周转时间、使用更长的支持时域，或验证不同的动作频率。

源年龄包含执行时间。对于追加操作，允许的时间大致为 execution horizon + effective refill，再加上捕获/推理的余量。一个 100 步的块在 30 Hz 下已经跨越了 3.33 秒。对齐通常会降低年龄，但反复混合可能会保留较旧的贡献者。

读取日志并诊断运行

INFO 日志会显示准入和生效的设置、文本请求结果、等待/关闭状态转换，以及大约每五秒一次的活动摘要。请结合读取延迟和排队播放情况来查看。如需详细信息，请使用服务器 --log_level=DEBUG 和客户端 --inference.log_level=DEBUG。交互式会话会屏蔽客户端中低于 ERROR 级别的日志；在收集实时计时日志时，请使用非交互式运行。

保存日志时，请使用 2>&1 | tee -i server.log（或 client.log）。-i 参数可确保在 Ctrl+C 作用于整个管道时 tee 保持运行，从而也能捕获优雅关闭的消息。

DEBUG 包含每个请求在提交时、观察年龄以及光标进度时的回放，以及每个结果的裁剪/可用步骤和重叠。这些描述的是指令进度，而非实际测量的物理执行。

配置与网络

为检查点、机器人架构和服务器设置保留一份部署 YAML；使用嵌套的 CLI 覆盖项进行实验。为独立的实验指定不同的部署名称。两个进程都会记录其包和协议版本；准入检查会验证协议以及执行/数据契约，但不要求包版本完全一致。

features:
  - name: observation.state
    shape: [6]
    dtype: float32
    names:
      [
        shoulder_pan.pos,
        shoulder_lift.pos,
        elbow_flex.pos,
        wrist_flex.pos,
        wrist_roll.pos,
        gripper.pos,
      ]
    semantics: so101-degrees-gripper-percent-v1
  - name: observation.images.front
    shape: [480, 640, 3]
    dtype: uint8
    kind: rgb
    semantics: rgb-front-table-v1

zenohd --config examples/remote_inference/zenoh/router.json5

uv run --no-sync lerobot-policy-server --config_path=server.yaml \
  --zenoh.mode=client \
  --zenoh.listen_endpoints='[]' \
  --zenoh.connect_endpoints='[tls/localhost:7447]' \
  --zenoh.config_file=examples/remote_inference/zenoh/server.json5

--inference.endpoint=tls/localhost:7447 \
--inference.zenoh_mode=client \
--inference.zenoh_config_path=examples/remote_inference/zenoh/robot.json5

LEROBOT_ZENOHD=/absolute/path/to/zenohd \
  uv run --no-sync pytest tests/remote_inference/test_zenoh.py -q -rs

语言和录音

通过交互式 rollout使用/vqa、/subtask和/autosteer。仅在实现了文本生成的 checkpoint 上启用服务器language.enabled=true；autosteering 还需要一个针对 subtask 生成进行训练且具备兼容的 goal/subtask 提示的 checkpoint。当 checkpoint 声明了该能力时，服务器会暴露这些命令；答案和 subtask 是否有用取决于 checkpoint。

文本工作会暂停运动并丢弃已缓冲的后续动作。VQA 会保留您的指令并基于新的预测继续执行，因此机器人在重新规划时可能会丢失任务进度，即使它已经给出了正确的回答。在信息性 VQA 查询期间保持已缓冲的运动继续运行是计划中的功能；请参阅 未来工作。

录制使用标准的本地数据集格式。任务标签遵循已分发的操作。诊断信息保留在应用日志中，不会写入数据集或上传。若使用数据集，请通过 --dataset.single_task 指定初始指令；否则请使用 --task。建议仅使用其中一种方式，以避免配置冲突。

在 Python 中使用

共享引擎和配置位于 lerobot.inference 中；远程客户端、引擎和服务器位于 lerobot.remote_inference 中。lerobot-rollout 外部的控制循环负责连接并接纳客户端，将其封装为引擎，发布捕获数据，并通过 dispatch_tick 分发每个电机节拍，该函数应用与 CLI 相同的权限、保持和确认契约：

import time

import numpy as np

from lerobot.inference import RemoteInferenceConfig, dispatch_tick
from lerobot.remote_inference import RemoteClient, RemoteInferenceEngine
from lerobot.utils.action_interpolator import ActionInterpolator

config = RemoteInferenceConfig(
    endpoint="tcp/127.0.0.1:7447",
    deployment="manipulation",
    semantics="so101-degrees-gripper-percent-v1",
)
client = RemoteClient.connect(config)
caps = client.capabilities
client.admit(
    features=caps.features,
    action_feature=caps.action_feature,
    semantics=config.semantics,
    action_interval=caps.action_interval,
    mode=config.mode,
)
engine = RemoteInferenceEngine(client, config, task="pick up the cube")
interpolator = ActionInterpolator(multiplier=1)

engine.start()
engine.resume()
try:
    while running():
        captured = time.monotonic()
        engine.submit_observation(
            {"observation.state": state_vector(), "observation.images.front": front_rgb()},
            capture_time=captured,
        )
        # send() receives a torch tensor in the deployment's action order; hold() refreshes
        # the last applied target. Returns None when the tick was held or starved.
        dispatch_tick(engine, interpolator, send=robot_send, hold=robot_hold)
finally:
    engine.stop()  # revokes motion and closes the client

Observations 以面向 checkpoint 的特征名称作为键，且必须与服务器模式匹配：float32 向量需按声明的组件顺序排列，RGB uint8 图像需为声明的尺寸。tests/remote_inference/test_library_client.py 针对回环服务器运行此路径，并作为调用序列的参考。lerobot-rollout 在其基础上增加了驱动转换、位置保持检查、交互式命令和录制功能；lerobot-policy-server 是服务入口点，仅通过其 YAML 和 CLI 覆盖项进行配置。

有关架构、执行契约和计划中的扩展，请参阅工程设计参考。