Inferencia remota

Las políticas grandes requieren una GPU, y con un despliegue síncrono el robot deja de moverse cada vez que la política calcula su siguiente bloque de acciones. La inferencia remota divide la tarea en dos: un servidor de política ejecuta el punto de control en una GPU, y el ordenador del robot mantiene el control de las cámaras, los motores, la teleoperación y la grabación. El robot sigue ejecutando las acciones que ya tiene mientras el servidor calcula las siguientes, por lo que el movimiento ya no se detiene para la inferencia.

Úsalo cuando:

• la computadora conectada al robot no tiene GPU o tiene una demasiado pequeña para la política: una laptop o una computadora de placa única junto al brazo y una estación de trabajo con GPU al otro lado del laboratorio;
• la inferencia consume una parte notable de cada trozo de acción y se desea un movimiento continuo;
• desea decidir con qué frecuencia el robot vuelve a planificar sin tocar el punto de control.

El único compromiso que se ajusta es la frescura frente a la continuidad. Solicitar un nuevo plan con mayor antelación permite que el robot reaccione a lo que observa; seguir más del plan actual preserva el progreso de la tarea.

Cómo funciona

La computadora del robot mantiene un búfer de acciones próximas. Cuando el búfer se agota, envía una observación nueva, continúa moviéndose desde el búfer mientras el servidor calcula y une el nuevo fragmento en la parte del plan que aún no se ha ejecutado.

Tres ajustes del cliente definen este comportamiento. refill_seconds determina con cuánta antelación solicitar el siguiente plan, chunk_merge decide cómo se integra el nuevo plan en el anterior, y el blending suaviza la transición entre ambos. El servidor solo necesita el checkpoint y una descripción del robot para el que fue entrenado. Las secciones siguientes parten de una configuración funcional y luego desarrollan la intuición para cada ajuste.

RTC local (--inference.type=rtc) es la otra opción asíncrona: la inferencia se ejecuta en un hilo en segundo plano del proceso de rollout, en la misma máquina, sin un servidor. La inferencia remota en el mismo host sigue utilizando dos procesos y --inference.type=remote, y ofrece alineación y mezcla para políticas sin RTC. Consulte cómo se relaciona RTC con la inferencia remota.

Políticas y robots admitidos

Un checkpoint puede servirse cuando sus procesadores guardados predicen un trozo de acciones a partir de una única observación actual; ACT necesita tener desactivado el ensamblado temporal. Los checkpoints de ACT, SmolVLA, XVLA, EVO1 y LaWAM se han ejecutado en robots reales a través de esta ruta. Varios otros policies están soportados a nivel de contrato pero no han sido validados en hardware, y los policies dependientes del historial requieren una integración adicional. La tabla de soporte de policies enumera el estado y las restricciones de cada policy.

El controlador del robot debe declarar el soporte para mantener la posición, ya que el cliente actualiza el último objetivo aplicado mientras espera las acciones. SO, OMX, Koch, HopeJr, Rebot y los seguidores YAM lo declaran; OpenArm, Reachy2 y los envoltorios bimanuales dependen de su configuración; el Unitree G1 lo declara solo con el controlador SONIC, cuyo objetivo retenido es el último token de movimiento; las bases móviles no lo hacen. Consulte la tabla de hardware. Los contratos de robot o de política no compatibles se rechazan en la admisión, antes de cualquier movimiento.

Comience con un despliegue funcional

Mantenga un comando lerobot-rollout síncrono exitoso como referencia y conserve sus ajustes de robot, cámaras, tarea, FPS, teleoperador e interpolación. El punto de control y el dispositivo del modelo se trasladan al servidor; el cliente remoto no carga los pesos.

Los ejemplos a continuación describen un SO-101 genérico de seis actuadores con una cámara frontal. Adapta el checkpoint, las vistas de la cámara, el orden de los componentes y las unidades de forma coherente.

1. Instalar en ambas computadoras

Ambos lados necesitan el extra remote. Mantén los extras de hardware en el cliente y el extra de la política seleccionada en el servidor:

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

El rango de Zenoh compatible es >=1.9.0,<1.11.0; uv sync --locked instala la versión del lockfile, actualmente 1.10.1.

2. Configure y inicie el servidor

Copia la configuración genérica y, a continuación, edítala:

cp examples/remote_inference/server.yaml server.yaml

Establezca model.repo_or_path y model.device. Para un punto de control del Hub, fije model.revision al commit que desea validar. Ajuste features, action_feature, semantics, robot_type y execution.action_fps a su configuración de trabajo; consulte los ejemplos de esquema y renombrado de cámaras a continuación.

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

El servidor carga el checkpoint, valida sus declaraciones, ejecuta el warmup y luego registra Policy server ready: deployment=<name> instance=<id>; awaiting one client. Cada campo YAML acepta una superposición anidada de CLI:

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

3. Iniciar el cliente del robot

En otra terminal, adapta los argumentos de hardware a la misma configuración:

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

Tras la admisión, escribe /start. /stop finaliza la ejecución; consulta lo que hace el robot mientras espera o se detiene. Mantén las opciones de teleoperación y grabación de tu despliegue de trabajo. No pases --policy.path, sobrescrituras locales de modelo-dispositivo ni banderas de compilación al cliente remoto.

deployment selecciona el servidor y semantics nombra las unidades de acción validadas y su orden; ambos deben coincidir con la configuración del servidor. El ejemplo utiliza los grados de las articulaciones del cuerpo y un rango calibrado de pinza de 0 a 100.

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

Elija cómo continuar el movimiento

Para cuando llega un nuevo fragmento, la observación a partir de la cual se calculó ya es un poco antigua y el robot ya ha avanzado. El modo de fusión decide qué hacer al respecto: reproducir el nuevo fragmento después del antiguo, descartar los pasos que el robot ya ha superado, o suavizar la unión.

Los ajustes de esta tabla usan el prefijo --inference.. Los fragmentos simples usan alineación con el mezclado deshabilitado por defecto. Un objetivo que ya está siendo interpolado se confirma y no puede reemplazarse.

Alignment descarta los pasos entrantes ya comprometidos. Blending promedia los objetivos futuros superpuestos. Interpolation añade comandos motores intermedios entre los extremos. RTC modifica cómo se genera la predicción. Ninguno de ellos garantiza un movimiento fluido o un agarre exitoso.

--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

Parámetros que importan

Las opciones de cliente a continuación usan el prefijo --inference. salvo que se indique lo contrario. Los valores predeterminados son valores iniciales, no garantías para un robot en particular.

El relleno efectivo es max(refill_seconds, recent maximum turnaround + 1 / fps). El tiempo de rotación incluye codificación, red, encolamiento, inferencia y decodificación. La primera solicitud aceptada proporciona una estimación inicial; las estimaciones posteriores utilizan hasta 100 muestras en estado estacionario.

Por lo tanto, Refill no es un período de solicitud fijo ni un número garantizado de acciones ejecutadas. Inspecciona el refill configurado y efectivo en los registros. Un umbral que cubra todo el horizonte de ejecución provoca una sustitución muy frecuente.

Lo que hace el robot mientras espera o se detiene

Durante una espera admitida, el cliente actualiza el último objetivo aplicado realmente por el controlador, incluyendo la interpolación, el recorte y el actuador de agarre. Antes del primer comando, una pose medida lo inicializa. Esto detiene el avance de la trayectoria; el robot aún puede estabilizarse hacia ese objetivo. No desactiva el par ni garantiza inmovilidad. RTC local utiliza la misma espera acotada en robots admitidos y falla de inmediato en caso de agotamiento en otros.

La recuperación por inanición descarta una predicción antigua en curso y obtiene una predicción nueva a partir de una captura tomada después de que comenzó la espera. Los resultados antiguos no pueden reiniciar el movimiento. Los paquetes y los resultados inutilizables no renuevan la gracia. Las esperas frecuentes indican una cobertura insuficiente de reproducción o latencia.

La pérdida del servidor o de la conexión no se recupera automáticamente. Las acciones en búfer válidas pueden agotarse, seguido de una espera hasta que expire el plazo de gracia u otro plazo límite. Una vez que se observa que la presencia del servidor se ha perdido, esa sesión no puede reanudarse cuando la conectividad se restablece; reinicie el despliegue para una nueva sesión. Durante el trabajo con texto, la pérdida observada del servidor provoca un error en la consulta.

Con la adquisición de observaciones y el control de actuadores en buen estado, el apagado final respeta --return_to_initial_position=true (el valor predeterminado) y luego se desconecta. Al regresar, se lee una observación completa, por lo que un fallo persistente de la cámara puede impedirlo. Una acción fallida o la aplicación de un mantenimiento (hold) suprime cualquier movimiento posterior. Establecer la opción en false omite el regreso, pero no la desconexión. Al desconectarse, es posible que se libere el par según la configuración del robot. Los fallos terminales finalizan con un estado no cero tras la limpieza; un proceso finalizado de forma forzada no puede garantizar la limpieza.

Ajustar una tarea funcional

Comience cerca de la referencia síncrona: ejecute una parte sustancial de cada predicción, pero solicite con suficiente antelación para ocultar la latencia de inferencia. Luego, evalúe si un replanificado más frecuente ayuda.

1. Use alignment without blending first. Mantén fijos los FPS, la interpolación y la configuración. Inspecciona el horizonte de ejecución, el tiempo total de respuesta y las solicitudes lentas.
2. Elige una cobertura de reabastecimiento con margen. Deja suficiente reproducción para otra solicitud y la variación de latencia, sin reemplazar continuamente el plan.
3. Añade una mezcla breve a ese ritmo. Compara por separado la finalización de la tarea, el agarre/soltado y los golpes. Un promedio suave de planes incompatibles puede pasar por alto el objeto.
4. Solicitar antes solo por un beneficio. Aumentar la recarga puede mejorar la capacidad de respuesta, pero interrumpe el progreso útil. Vuelve al ritmo estable si el rendimiento de la tarea empeora.
5. Cambie una configuración a la vez. Aumentar los tiempos de espera o la tolerancia no proporciona las acciones que faltan. Reducir el reabastecimiento no es una solución universal para el agotamiento.

Para un horizonte de ejecución de 0.8 s y alineación exitosa estable, la separación entre solicitudes es aproximadamente 0.8 - effective_refill:

Esto excluye los efectos de inicio, retenciones, saturación y ticks de control. Una solicitud que comienza con 0.2 s restantes y tarda 0.1 s deja solo 0.1 s para la mezcla, tres pasos a 30 Hz. Por lo tanto, una cadencia casi síncrona puede requerir solo una mezcla breve.

Para la alineación y el RTC, compruebe la reproducción disponible tras el recorte, no la longitud nominal del fragmento. Si la inferencia tarda 1 segundo de una predicción de 1,67 segundos, solo quedan aproximadamente 0,67 segundos. Una solicitud adicional de 1 segundo no cabe; ningún valor de relleno lo soluciona. Reduzca el tiempo de respuesta, use un horizonte de soporte más largo o valide una frecuencia de acción diferente.

La edad de la fuente incluye la ejecución. Para el modo de agregación, permita aproximadamente execution horizon + effective refill más un margen de captura/inferencia. Un fragmento de 100 pasos a 30 Hz ya abarca 3,33 segundos. La alineación suele reducir la edad, pero el mezclado repetido puede conservar contribuyentes más antiguos.

Lee los registros y diagnostica una ejecución

Los registros de nivel INFO muestran la configuración de admisión y efectiva, los resultados de las solicitudes de texto, las transiciones de espera/apagado y un resumen de actividad aproximadamente cada cinco segundos. Lea el tiempo de respuesta y la reproducción en cola juntos. Para más detalles, use el servidor con --log_level=DEBUG y el cliente con --inference.log_level=DEBUG. Las sesiones interactivas silencian los registros del cliente por debajo de ERROR; use una ejecución no interactiva al recopilar registros de temporización en vivo.

Al guardar los registros, usa 2>&1 | tee -i server.log (o client.log). La opción -i mantiene tee activo cuando Ctrl+C alcanza todo el pipeline, de modo que también captura los mensajes de cierre correcto.

DEBUG incluye la reproducción de cada solicitud en el momento del envío, la edad de la observación y el progreso del cursor, además de los pasos recortados/útiles y la superposición por resultado. Estos describen el progreso comandado, no la ejecución física medida.

Configuración y redes

Mantenga un solo YAML de despliegue para el punto de control, el esquema del robot y la configuración del servidor; use anulaciones anidadas de la CLI para los experimentos. Asigne nombres de despliegue diferentes a los experimentos independientes. Ambos procesos registran sus versiones de paquete y de protocolo; la admisión verifica el protocolo y los contratos de ejecución/datos, sin requerir versiones de paquete idénticas.

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

Idioma y grabación

Use /vqa, /subtask y /autosteer a través de interactive rollout. Habilite el servidor language.enabled=true solo en un checkpoint que implemente la generación de texto; el autosteering requiere además un checkpoint entrenado para la generación de subtareas con un prompting de objetivo/subtarea compatible. El servidor expone estos comandos cuando el checkpoint declara la capacidad; si las respuestas y las subtareas son útiles depende del checkpoint.

El trabajo de texto pausa el movimiento y descarta la continuación en búfer. VQA conserva tu instrucción y reanuda con una predicción nueva, por lo que el robot puede perder el progreso de la tarea al volver a planificar, incluso después de una respuesta exitosa. Mantener el movimiento en búfer en ejecución durante una consulta informativa de VQA está previsto; consulta trabajo futuro.

La grabación utiliza el formato de conjunto de datos local normal. Las etiquetas de la tarea siguen la acción enviada. Los diagnósticos permanecen en los registros de la aplicación; no se escriben en el conjunto de datos ni se suben. Con un conjunto de datos, use --dataset.single_task para la instrucción inicial; de lo contrario, use --task. Prefiera uno para evitar configuraciones en conflicto.

Úsalo desde Python

Los motores y la configuración compartidos se encuentran en lerobot.inference; el cliente remoto, el motor y el servidor se encuentran en lerobot.remote_inference. Un bucle de control externo a lerobot-rollout conecta y admite un cliente, lo envuelve en un motor, publica las capturas y despacha cada tick del motor a través de dispatch_tick, que aplica el mismo contrato de permiso, retención y confirmación que la 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

Las observaciones se indexan por los nombres de características orientados al checkpoint y deben coincidir con el esquema del servidor: vectores float32 en el orden de componentes declarado, imágenes RGB uint8 del tamaño declarado. tests/remote_inference/test_library_client.py ejecuta esta ruta contra un servidor loopback y es la referencia para la secuencia de llamadas. lerobot-rollout añade sobre esto la conversión del driver, las comprobaciones de posición fija, los comandos interactivos y la grabación; lerobot-policy-server es el punto de entrada de servicio y se configura únicamente a través de sus superposiciones YAML y CLI.

Para la arquitectura, los contratos de ejecución y las extensiones planificadas, consulte la referencia de diseño de ingeniería.