Asynchronous Robot Inference: Decoupling Action Prediction and Execution

📝 요약

현재 로봇 정책은 미래 액션 덩어리를 예측하면서 복잡성이 증가하고 있으며, 이는 실행 시 지연과 반응성 저하를 초래합니다. 본문에서는 액션 예측과 실행을 분리하는 비동기 추론 기법을 소개하며, 이를 통해 런타임 지연을 제거하고 더 적응적인 제어를 가능하게 합니다. 비동기 추론은 `PolicyServer`와 `RobotClient`로 구성된 2단계 시스템을 사용하여, 로봇이 추론을 기다리는 시간을 없애고 작업 완료 시간을 약 2배 단축하면서도 작업 성공률은 비슷하게 유지합니다. 이 기법은 로봇 정책의 성능을 향상시키는 간단하지만 효과적인 방법으로, 실제 로봇 응용 분야에서 중요한 이점을 제공합니다.

---

TL;DR 로봇 정책은 점점 더 복잡해지고 있으며, 단일 다음 액션을 예측하는 대신 미래 액션 덩어리를 예측합니다. 이는 로봇이 새로운 액션을 기다리는 동안 유휴 상태가 되어 실행 시 눈에 띄는 지연이 발생하고 반응성이 떨어지는 결과를 초래합니다. 비동기 추론은 제어 루프를 조이고, 액션 예측과 액션 실행을 분리하여 런타임 지연을 제거하고 더 적응적인 제어를 가능하게 합니다. 이 블로그 게시물에서는 비동기 추론의 기본 사항과 실제 로봇 정책의 성능을 개선하는 데 어떻게 사용될 수 있는지 다룹니다.

시작하기

가이드를 따라 비동기 추론을 시작하십시오.

순차 추론(왼쪽) 대 비동기 추론(오른쪽). 재계획 및 더 빡빡한 제어 루프를 허용하는 비동기 추론은 (1) 복구 시도를 하고, (2) 작업 완료 시간을 약 2배 단축합니다. 순차 추론은 물체를 잡는 데 실패한 후에도 현재 액션 덩어리를 계속 실행하는 반면, 비동기 추론은 재계획하고 새 액션 덩어리를 실행할 수 있습니다. 두 설정 모두 동일한 정책을 사용합니다!

비동기 추론: 심층 분석

비동기 추론을 사용하면 액션 실행과 액션 예측을 분리합니다. 이는 [ACT], [OpenVLA], [PI0], [SmolVLA]와 같이 현재 인기 있는 모델들이 관찰 \(ot\)가 주어졌을 때 단일 액션 \(at\) 대신 액션 덩어리 \(a_{t:t+H}\)를 출력하는 경향을 고려할 때 특히 관련성이 있습니다. LeRobot을 사용하여 이러한 모든 모델을 실행하여 이를 직접 확인하십시오.

덩어리를 순차적으로 사용하면 (1) 런타임 지연이 발생하여 작업 실행 시간에 영향을 미치고 (2) 개방 루프로 넓게 작동하기 때문에 반응성이 떨어집니다. 비동기 추론은 액션 예측과 액션 실행을 분리하여 이러한 두 가지 제한 사항을 완화합니다. SmolVLA에서 비동기 추론을 도입했으며, 작업 완료 시간을 약 2배 단축하고 작업 성공률은 비슷하게 나왔습니다.

특히, 정책 추론과 액션 실행을 두 개의 다른 프로세스에서, 가능하다면 네트워크를 통해 연결된 두 개의 다른 기계에서 수행하는 2가지 구성 요소 시스템을 설계했습니다.

• PolicyServer: 가속 하드웨어에서 호스팅되며 실제 로봇에 할당된 것보다 더 많은 계산 리소스를 사용하여 추론을 실행할 수 있습니다.
• RobotClient: 수신된 액션을 큐에 넣고 다음 덩어리가 계산되는 동안 실행합니다.

PolicyServer와 RobotClient 간의 통신은 gRPC에 의존하며, 이는 비교 가능한 REST API보다 약 5배 빠른 성능을 보장합니다. 이 모든 결과로 로봇은 추론을 기다리지 않습니다.

비동기 추론은 다음을 강조합니다. (1) 클라이언트가 첫 번째 관찰을 추론용으로 보내고, 잠시 후 첫 번째 덩어리를 받습니다. (2) 클라이언트가 현재 덩어리를 소진하지 않은 동안 다른 관찰을 처리용으로 보냅니다. (3) 클라이언트가 업데이트된 액션 덩어리를 수신하고, 이를 이전에 실행 중이던 덩어리의 나머지 부분과 통합합니다.

---

1. 순차 추론이 부족한 이유

정책 \( \pi \)가 현재 관찰 \( ot \)를 \( H \)개의 미래 액션 시퀀스로 매핑한다고 가정합니다. 형식적으로, \(\pi : \mathcal{O} \;\mapsto\; \mathcal{A}, \mathbf{A}t = \begin{pmatrix} a{t}, & a{t+1}, & \dots & a{t+H} \end{pmatrix} = \pi(ot)\).

따라서 전통적인 제어 루프는 다음과 같은 단계로 구성됩니다.

1. \( o_t \)를 캡처합니다.
2. \( \pi(ot) \)를 실행하여 \( \mathbf{A}t = \pi(o_t) \)를 얻습니다.
3. \(\mathbf{A_t} \)를 큐에 넣고 큐에서 액션을 가져와 실행하기 시작합니다.
4. 큐가 비어 있으면 \( \mathbf{A}_{t+H} \)를 기다리고, 그렇지 않으면 3단계를 반복합니다.

2단계 동안 로봇은 유휴 상태입니다. 지연 시간은 모델 크기가 커짐에 따라 증가하며(모델은 시간이 지남에 따라 점점 더 커지는 경향이 있습니다), 상호 작용 시간(일반적으로 1/fps 정도)을 빠르게 지배할 수 있습니다. 아래 동영상(당사 Discord 커뮤니티 🤗에서 제공)에서 볼 수 있습니다.

이는 (1) 작업 완료 시간 측면에서 성능 저하(로봇은 다음 액션 덩어리가 계산될 때까지 기다려야 함)와 (2) (2.1) 액션이 사용 가능한 동안 개방 루프로 넓게 작동하고 (2.2) 다음 액션 덩어리를 기다리는 동안 완전히 유휴 상태로 인해 반응성 저하로 직접 이어집니다.

(왼쪽) 강조 표시된 유휴 기간이 있는 순차 추론. (오른쪽) 로컬 큐 소진으로 인해 추론이 트리거될 때 스파이크를 보여주는 액션 선택 시간 (추론 지연 시간은 약 100ms ~ 30fps에서 ~3 프레임으로, 2021 MacBook Pro에서 ACT 모델 사용).

---

2. 비동기 추론, 요약

당사의 시스템은 계산과 실행을 겹쳐서 유휴 기간을 제거합니다.

1. RobotClient는 최신 관찰을 PolicyServer로 스트리밍합니다.
2. 서버가 추론을 수행하는 동안 클라이언트는 현재 큐의 액션을 실행합니다.
3. 새 액션이 도착하여 큐에 병합되고 루프가 계속됩니다.

핵심 아이디어는 로봇이 이미 몇 번의 시간 단계 동안 무엇을 해야 하는지 알고 있으므로, 서버에서 신선한 액션이 계산되는 동안 계속 움직일 수 있다는 것입니다.

비동기 추론은 두 프로세스를 분리하여, 가능하다면 네트워크로 연결된 완전히 별개의 기계에서 실행함으로써 현재 액션 덩어리의 실행과 다음 액션 덩어리의 계산을 시간적으로 겹칩니다.

이는 더 빡빡한 제어 루프와 추론을 기다리지 않는 로봇으로 이어집니다. 결과적으로 작업 완료 시간이 약 2배 단축되고 작업 성공률은 비슷하며, 더 빡빡한 루프에서 나오는 더 적응적인 제어가 가능해집니다(아래 동영상 참조).

---

3. 시스템 아키텍처

| 구성 요소 | 역할 | 기술 | |-----------|------|-------------| | RobotClient | 온보드에서 실행, 관찰 스트리밍, 액션 큐 유지, 액션 실행 | Python, gRPC | | PolicyServer | 정책 호스팅, 배치 추론 수행, 액션 덩어리 반환 | Python, gRPC, 가속 하드웨어(GPU/TPU) 가능 |

gRPC는 HTTP/2 기반이며 프로토콜 버퍼를 사용하므로 기본적으로 저지연 바이너리 메시징 및 양방향 스트림을 달성하여 더 빡빡한 제어 루프와 100ms 미만의 왕복 지연 시간(로컬 네트워크에서 SmolVLA를 NVIDIA RTX 4090에서 호스팅하는 경우)을 유지하는 데 도움이 됩니다.

RobotClient는 온보드에서 실행되며 gRPC를 통해 PolicyServer로 관찰을 스트리밍합니다. PolicyServer는 수신된 관찰을 추론에 적합하게 준비하고 액션 덩어리를 RobotClient로 다시 보냅니다.

Robot Client

클라이언트 관점에서, 관찰은 로컬 큐 상태에 따라 서버로 스트리밍됩니다. 수신된 덩어리는 현재 사용 가능한 액션 큐와 겹치는 부분에서 통합됩니다.

RobotClient는 로컬 액션 큐를 유지하고 간단하지만 효과적인 전략을 따릅니다: 큐 길이가 구성 가능한 임계값(g in SmolVLA paper, chunk_size_threshold in the code) 미만으로 떨어지면 새 관찰을 보내기를 트리거합니다. 최대 덩어리 크기의 비율로 표현되는 이 임계값은 계산 부하와 반응성을 균형 맞추는 트리거 조건 역할을 합니다.

클라이언트는 로컬 큐 상태에 따라 서버로 관찰을 스트리밍합니다.

클라이언트 관점에서 프로세스는 다음과 같이 진행됩니다.

1. 큐 모니터링: 클라이언트는 액션 큐 길이를 덩어리 크기 임계값 매개변수와 지속적으로 비교합니다. 큐가 이 임계값 미만으로 떨어지면 새 관찰을 처리용으로 보내야 한다는 신호가 됩니다.

2. 관찰 스트리밍: 임계값 조건이 충족되면 클라이언트는 현재 관찰을 캡처하여 gRPC를 통해 PolicyServer로 스트리밍합니다. 중요하게도, 관찰은 단일 RPC를 통해 전송되는 것이 아니라 스트리밍됩니다. 왜냐하면 일반적으로 4MB의 최대 메시지 크기(고해상도에서 여러 카메라 캡처 결과)를 초과하기 때문입니다.

3. 액션 덩어리 통합: 서버에서 새 액션 덩어리가 도착하면 클라이언트는 이를 현재 큐의 나머지 액션과 겹치는 부분에서 병합합니다. 이때 사용자 정의 집계기가 사용되며, 각 겹치는 타임스텝에 대해 aggregate_fn(chunk1: torch.Tensor, chunk2: torch.Tensor) -> torch.Tensor 함수를 호출하여 겹치는 부분을 다르게 처리합니다. 이 함수는 사용자가 제공할 수 있습니다. 겹치는 부분(다이어그램에서 하늘색으로 표시)은 신중한 처리가 필요합니다. 다양한 집계 전략을 설계할 수 있습니다.

• 교체: 겹치는 액션을 새 예측으로 단순히 교체합니다.
• 가중치 블렌딩: 시간 가중치를 사용하여 겹치는 액션을 결합합니다(가까운 액션에 더 높은 가중치 부여).

이 시스템은 덩어리 크기 임계값을 네트워크 지연 시간, 모델 추론 시간 및 원하는 반응성을 기반으로 조정할 수 있으므로 매우 구성 가능합니다. 낮은 임계값은 더 빈번한 업데이트(및 더 높은 계산 비용)를 의미하는 반면, 높은 임계값은 잠재적인 큐 부족을 대가로 통신 오버헤드를 줄입니다. 마지막으로, 일반적으로 별도의 스레드에서 PolicyServer로부터 액션을 수신하고 다른 스레드에서 실행합니다. 이를 통해 클라이언트는 실행을 차단하지 않고 새 덩어리가 완전히 사용 가능해질 때까지 항상 현재 덩어리를 소비하면서 별도의 스레드에서 수신 덩어리를 계속 수신합니다.

Policy Server

RobotClient로부터 관찰을 수신하면 PolicyServer는 수신된 관찰을 정리하여 추론에 적합하게 만듭니다. 이 프로세스는 아래 이미지에 설명되어 있습니다.

서버에서 실행되는 관찰 정리 파이프라인은 (1) 키 일치 (2) 사전 처리 및 (3) 추론 준비와 관련된 세 가지 주요 단계를 강조합니다.

관찰이 준비되면 추론에 사용된 마지막 관찰과 비교됩니다. 이렇게 하면 매우 유사한 관찰이 처리되어 불필요한 추론과 유사한 액션 실행이 트리거되는 루프로 이어지는 것을 방지합니다(이는 다시 매우 유사한 관찰이 다시 처리되는 결과를 낳습니다). 로봇의 변화를 근사하고 빠르게 측정하는 방법으로 관절 공간 유사성을 기반으로 관찰을 비교합니다. 명확하게, 이 메트릭은 환경의 동적 변화(객체 위치 변경 또는 교란 적용)에 적응하지 않지만, 대부분의 경우 좋은 절충안으로 판명되었으며 불필요한 추론과 상태 붕괴를 방지하는 데 매우 효과적이었습니다. 중요하게도, RobotClient는 교착 상태를 피하기 위해 특정 관찰을 처리해야 하는지 여부에 대한 제어를 유지합니다. must_go=True 태그가 지정된 클라이언트에서 보낸 관찰은 유사성 메트릭에 관계없이 처리됩니다.

정책 워크플로우에서는 수신된 관찰을 추론에 사용된 마지막 관찰과 비교하고, 충분히 다른 경우 또는 `must_go`인 경우에만 처리됩니다.

마지막으로, PolicyServer가 항상 최신 사용 가능한 관찰을 처리하도록 보장하기 위해 이전 관찰이 성공적으로 처리될 때까지 수신 관찰을 차단합니다. 이를 위해 PolicyServer의 큐를 활용하여 수신 관찰이 서버가 처리할 준비가 될 때까지 큐에 넣지 않도록 합니다(아래 참조).

클라이언트는 1/fps 초마다 서버에 핑하지만, 이전 관찰이 성공적으로 처리될 때까지 관찰은 처리용으로 큐에 넣지 않습니다.

---

4. 비동기 추론 분석

모든 실질적인 목적을 위해 비동기 추론에는 두 가지 중요한 시간 척도가 있습니다.

• 환경 단계 \(\texttt{environment_dt} = 1/\texttt{fps}\): 로봇이 얼마나 빨리 액션을 수행할 수 있는지를 나타냅니다.
• 추론 지연 시간 \(\texttt{inference_time}\): 순방향 패스 + 네트워크 왕복. 네트워크 왕복은 정책 추론 시간에 비해 무시할 수 있다고 가정할 수 있지만, 모든 설정에서 그렇지는 않을 수 있습니다.

중요하게도, 비율 \( c = \frac{\texttt{environment_dt}}{\texttt{inference_time}} \) 은 다른 동작으로 이어집니다.

• \(c \ll 1\): 환경이 추론보다 빠르게 발전합니다. 이 시나리오에서는 큐가 빠르게 비어 순차 제어로 퇴화합니다.
• \(c \ge 1\): 서버가 따라잡습니다. 큐는 항상 (거의) 채워져 있습니다.

중요하게도, \(c\)는 각 시간 동안 큐에 있는 사용 가능한 액션 수에 영향을 미칩니다. 위에서 언급한 순차 제한 제어를 피하려면 다음을 수행할 수 있습니다.

1. 정책 서버에 더 많은 컴퓨팅을 사용하여 GPU에 서버를 호스팅하고, 더 많은 계산 리소스를 할당한 결과로 \(\texttt{inference_time}\)을 줄입니다.
2. 서버에 관찰을 더 자주 보내기: 큐 길이 \(k\)가 최대 크기의 분수 \(g = k/H\) 미만으로 떨어지면 새 관찰을 보냅니다.

• \(g=0\)은 순차 추론(큐 비움, 대기)을 재현합니다.
• \(g=1\)은 각 타임스텝마다 관찰을 보냅니다(최대 컴퓨팅, 최소 지연).

실험(아래 플롯 참조)에 따르면 \(g\approx0.7\)은 관찰이 필터링되지 않을 때(모두 must-go) 좋은 절충안을 제공합니다. \(g=0.5\)로 설정하고 문서를 따라 필요에 맞게 이 매개변수를 조정하는 것이 좋습니다.

각 시간 동안 큐에 있는 사용 가능한 액션 수, g의 함수. g 값이 클수록 업데이트가 더 빈번해지고 계산 비용이 더 많이 듭니다. g 값이 0에 가까울수록 순차 추론(큐 비움, 대기)이 재현됩니다. 실험에서 g~0.7이 좋은 절충안임을 발견했습니다.

---

5. 설정에서 비동기 사용하기

비동기 추론은 로봇 정책의 성능을 개선하는 간단하지만 효과적인 방법입니다. SmolVLA를 사용한 실험에서 비동기 추론은 작업 완료 시간을 약 2배 단축하고 작업 성공률은 비슷하며, 더 빡빡한 루프에서 나오는 더 적응적인 제어가 가능해집니다.

비동기 추론을 사용하여 정책을 실행하려면 사용자 정의 매개변수(예: 정책 경로 또는 덩어리 크기 임계값)와 함께 튜토리얼을 따르면 됩니다. 비동기 추론은 액션 덩어리를 지원하는 정책을 지원합니다!

---

결론

간단하지만 효과적인 로봇 정책 성능 개선 방법인 비동기 추론을 소개했습니다. SmolVLA를 사용한 실험에서 비동기 추론은 작업 완료 시간을 약 2배 단축하고 작업 성공률은 비슷하며, 더 빡빡한 루프에서 나오는 더 적응적인 제어가 가능해집니다.

이 작업을 커뮤니티와 공유하게 되어 기쁘게 생각하며, 로봇 정책의 성능을 개선하는 데 어떻게 사용될 수 있는지 보기를 기대합니다. huggingface/lerobot에서 비동기 추론 프레임워크를 개선하고 확장하기 위한 PR을 환영하며, Discord 커뮤니티 🤗에서 이에 대해 더 자세히 논의할 수 있습니다.

---

원문 출처: https://huggingface.co/blog/async-robot-inference