로봇의 '뇌'를 클라우드에 두려고 한다면, 신청 양식을 내기 전에 읽어보길 바란다.
Hugging Face의 로보틱스 부문에는 현재 36,917개의 모델이 배열되어 있다(필자가 10월 20일에 확인). 당장 구동할 수 있는 로봇용 AI는 이미 이만큼이나 나와 있다.
- 이름에 'smolvla'를 포함하는 모델:
6,102개 - 이름에 'pi05'(Physical Intelligence의 $\pi$0.5)을 포함하는 모델:
3,520개 - 두 개를 합치면
26.1%. 4개 중 1개를 넘는다.
그런데 그 $\pi$0.5를 만든 Physical Intelligence(이하 PI)는 10월 13일에 반대 방향을 택했다. 최신 모델을 클라우드 API로 공개한 것이다. 발표의 시작은 이렇다.
We are making our latest models available for training and inference through the Pi API beta.
자신의 로봇 데이터를 올리고, PI가 관리하는 계산 자원으로 미세 조정하며, 호스트형 게이트웨이를 통해 추론한다. 이전에 사용한 회사는 일본, 스위스, 미국 각지에 퍼져 있으며, 유타주에서는 운전석에 아무도 없는 휠로더가 자재를 집어 더미에 쌓고 있다. 발표에 따르면 공개된 사례의 대부분이 클라우드에서 추론하고 있었다. 그리고 일부에서는 통신 문제가 발생한 것도 PI 스스로 인정했다.
그 API 신청 양식에는 이런 질문이 있다.
Where do you need to run inference?
Cloud / Local (on your own hardware) / Both / Not sure yet
로봇의 뇌를 어디에 둘 것인가. 이 한 질문에 숫자로 답할 수 있을까?
1. 'Cloud'를 선택하기 전에, 자신의 로봇에서 GPU까지의 지연 시간을 측정하고, 행동의 몇 스텝 분량에 해당하는지 계산하는 것.
계산은 $d = ext{⌊지연 시간} ext{ ÷ 制御周期⌋}$ 이다. PI 논문의 설정(50Hz, 1회 추론으로 50스텝 = 1초분)이라면, 지연 시간 200ms로 10스텝이 된다.
2. PI의 논문 값으로 추산하면, 일미 왕복을 더한 지연 시간은 약 208ms. PI가 새로운 학습 방식으로 상정한 상한선 200ms의 바로 경계에 걸친다.
원격의 H100에서 측정한 108ms에, Azure의 동일본에서 미국 서부로 왕복하는 100ms(중앙값)을 더한 필자의 계산이다. 한편, 오래된 방식은 +200ms 지연 시간을 더한 실험에서도 성능 저하가 없었다.
3. 하지만 무서운 것은 평균적인 느림보다 끊기는 것이다. 1회 추론으로 얻는 행동은 1초분밖에 없다.
게다가 API의 가격, GPU의 위치, 어느 방식을 사용하는지는 모두 공표되지 않았다.
[그림: PI 학습 시 RTC 논문의 실측 108ms에 일미 왕복 100ms를 더한 추산. GPU 위치별 지연 시간과 함께 필자가 작성]
숫자는 2026년 10월 20일 기준이다. API 내용은 PI의 발표(10월 13일)와 신청 양식에 따른 것이다. 지연 실측값은 PI의 두 논문(2025년 6월 추론 시 RTC, 2025년 12월 학습 시 RTC)에서, 왕복 시간은 Microsoft가 공표한 Azure 리전 간 중앙값(2026년 7월 30일까지 30일간)을 빌렸다. API에서 사용되는 모델 이름, 행동 청크의 길이, 어느 RTC를 사용할지, GPU 위치, 가격 모두 공표되지 않았으며, 추산은 모두 필자의 단순한 덧셈이다. 필자는 PI의 API도 로봇도 구동하지 않았다.
| 항목 | 값 |
|---|
| Pi API β | |
| 2026년 10월 13일 공개. 소수의 회사부터 순차적으로 수용 | |
| 사용법 | 데이터를 올림 $\rightarrow$ PI의 계산 자원으로 미세 조정 $\rightarrow$ 호스트형 게이트웨이에서 추론 |
| 공개 사례의 추론 | |
| 대부분 클라우드 (일본, 스위스, 미국 각지) | |
| 모델명・가격・GPU 위치 | 비공개 |
| 제어 주기와 행동 청크 | 50Hz (1스텝 20ms), 1회 추론으로 50스텝 = 1초분 ($\pi$0.5 논문 설정) |
| LAN을 통한 총 지연 시간 ($\pi$0.5, RTX 4090) | 이동 로봇 139ms, 고정형 109ms |
| ... | 최대 200ms (0~10스텝) |
| 동일본 $\rightarrow$ 미국 서부 2 왕복 (Azure) | |
| 100ms (중앙값) | |
| Hugging Face의 로보틱스 부문 | |
| 36,917 모델 (smolvla 6,102, pi05 3,520) | |
같은 건물 안의 GPU에 연결하더라도, 이동 로봇은 추론 1회당 139ms가 소요된다. 50Hz라면 139÷20＝6.95로, 버림하여 6스텝이다. 새로운 명령이 도착할 때까지, 로봇은 이전 계획대로 6보만큼 움직인다.
여기까지는 '로봇의 AI도 API로 빌릴 수 있게 되었다'는 이야기다. 흥미로운 것은 그 다음이다.
VLA(Vision-Language-Action)는 카메라 이미지를 받아 지시문과 함께 관절 움직임을 출력하는 모델이다. PI의 π0.5는 1회 추론으로 50스텝 분량의 행동을 한꺼번에 출력한다. 이를 행동 청크(action chunk)라고 부른다.
이유는 간단하다. π0.5 실험에서 사용된 제어 주기는 50Hz, 즉 20ms마다 다음 명령이 필요하다. 그런데 RTC 논문에 따르면, RTX 4090으로 추론할 경우 모델 자체만으로도 76ms가 걸린다. 스텝별로 추론한다면 시간 안에 맞출 수 없다.
그래서 1초 분량을 한 번에 출력하고, 그 사이에 다음 1초 분량을 생각하는 것이다. 문제는 연결 부위다.
| 연결 방식 | 발생하는 일 |
|---|
| 동기(사용 후 다음 추론) | 추론할 때마다 로봇이 멈춘다. 지연 시간이 길어질수록 작업이 느려진다 |
| 중첩 평균화(temporal ensembling) | +100ms의 지연으로 진동하여, 로봇 보호 정지 기능이 작동해 움직일 수 없었다 |
| 그대로 전환 | 신구 청크가 어긋나 급격한 가속이나 끊김 현상이 발생한다 |
평균 방식으로 연결하는 것에 대해 논문은 이렇게 적고 있다.
both TE variants do not run at all due to causing such high oscillations that the robot’s protective stop is triggered
PI가 2025년 6월에 발표한 RTC(Real-Time Chunking)는 이 연결 부위의 문제를 '빈틈 채우기' 문제로 해결했다.
추론에 걸리는 시간을 $\delta$, 제어 주기를 $\Delta t$라고 하면, 논문은 지연을 스텝 수로 정의한다.
d = ⌊$\delta / \Delta t\rfloor$ (다음 청크가 도착할 때까지, 이전 청크대로 실행되는 스텝 수)
맨 앞의 $d$ 스텝은 새로운 청크가 도착하기 전에 반드시 실행되므로 바꿀 수 없다. RTC는 이곳을 이전 청크 값으로 고정하고, 나머지를 새로운 관측에 맞춰 다시 그린다. 가중치는 고정된 부분에서 1이고, 그 이후부터 1에서 0으로 지수적으로 줄이며, 청크의 뒷부분은 0(자유롭게 다시 그림)으로 처리한다.
또 하나의 중요한 제약이 있다. 한 번의 청크로 실행하는 스텝 수를 $s$, 청크 길이를 $H$라고 할 때, 비동기적으로 작동하려면 $d \le s \le H - d$가 필요하다. 여기서 $d \le H/2$가 도출된다. $H=50$이라면 $d \le 25$이며, 지연 시간으로 환산하면 520ms 미만이 이론적 상한선이 된다(논문 제약 조건으로부터 필자의 계산).
# 추론 시 RTC 흐름 (논문 설명을 필자가 간략화한 의사 코드/미실행)
H, DT = 50, 0.020 # 1청크 50스텝, 제어 주기 20ms(50Hz)
chunk = policy.sample(robot.observe())
...
실기 결과는 이렇다. 6가지 종류의 작업에서, 작업과 방식 조합별로 10번씩 시도하여 총 480 에피소드(약 28시간)를 비교했다. +100ms($d \approx 11$), +200ms($d \approx 16$)의 지연을 추가해도, RTC의 작업 효율은 떨어지지 않았다.
RTC is completely robust to injected delay, showing no degradation
동기 방식은 지연 시간에 비례하여 효율이 떨어졌다. PI 설명 페이지에는 매치(match)를 문지르거나 이더넷 케이블을 꽂는 것 같은 정밀 작업을 300ms가 넘는 지연으로 완료했다고도 쓰여 있다.
이 실험의 지연 시간 내역도 공개되어 있다. 모델은 다른 RTX 4090 머신에서 구동하고, 로봇과는 LAN으로 연결했다.
| 항목 | 이동 로봇 | 고정형 |
|---|---|
| 모델 (RTC 포함) | 96.89ms | 97.43ms |
| 통신 (LAN) | 21.20ms | 6.89ms |
| 이미지 축소 (로봇 측 CPU) | 11.22ms | 1.44ms |
| 기타 | 9.67ms | 3.00ms |
| 합계 | 138.98ms | 108.76ms |
이동 로봇 측 계산기는 Intel NUC, 고정형 측은 Ryzen 9 7950X 워크스테이션이다. 같은 건물 안에서도, 로봇 측 통신과 계산기 차이만으로 약 30ms (138.98 − 108.76 = 30.22ms)의 차이가 난다.
2025년 12월, PI는 학습 시 RTC(Training-time RTC)를 발표했다. 추론할 때마다 빈칸 채우기 계산(역전파 포함)을 하는 대신, 학습 중에 지연을 모사하고 첫 번째 행동을 조건으로 제공한다. 이로써 추론 시 추가적인 계산이 사라진다.
다만, 모사하는 지연의 폭은 학습 시점에 결정된다. 논문의 실제 실험 설정은 다음과 같다.
We sample delays uniformly between 0 and 10 during training, which supports a maximum latency of 200ms on a 50Hz robot.
논문은 이 방식의 약점도 명확하게 서술하고 있다.
However, training-time RTC is fundamentally less flexible than inference-time RTC
| 항목 | 추론 시 RTC (Inference-time RTC) (2025년 6월) | 학습 시 RTC (Training-time RTC) (2025년 12월) |
|---|
| 원리 | 추론 중에 첫 d 스텝을 고정하고, 나머지를 다시 그린다 | 학습 중에 지연을 모사하고, 첫 행동을 조건으로 제공한다 |
| ... | | |
π0.6 실험에서는 추론 시 RTC도 135ms (d≈7)로 구동하여, 두 방식의 작업 성적은 비슷했다. 차이가 난다면, 지연이 예상치를 초과했을 때이다.
새로운 방식일수록, 지연의 상한선을 처음에 확정한다. 클라우드에 뇌를 둘 계획이라면, 이 부분이 중요하게 작용한다.
PI는 API의 GPU가 어디에 있는지 공개하지 않았다. 여기부터는 가상의 계산이다.
자료는 두 가지다. 학습 시 RTC 논문에서 원격 H100을 사용했을 때의 실측 108ms와, Azure의 공표값에 있는 리전 간 왕복 시간(2026년 7월 30일까지 30일간의 중앙값)이다. 108ms 중 통신이 몇 ms인지는 논문에 나와 있지 않으므로, GPU가 논문과 같은 정도로 가까운 상태에서 멀어진 만큼의 왕복 시간을 그대로 더한다.
| GPU 위치 (가정) | 추가할 왕복 시간 | 합계 | d (50Hz) | 학습 시 RTC 예상치 (0〜10) | 추론 시 RTC 실험 (+200ms까지 성능 저하 없음) |
|---|
| 논문과 같은 근접성 | 0ms | 108ms | 5 | 내부 | 내부 |
| ... | 10 | | | | |
| 경계점 | | | | | |
| 내부 | | | | | |
| 미국 동부 (동일본 → 미국 동부) | 162ms | 270ms | 13 | 외부 | 내부 |
미국과 일본의 왕복 시간을 더하면 208ms가 된다. 논문이 제시하는 '최대 200ms'를 8ms 초과하지만, 스텝에 직수로 계산하면 208÷20＝10.4로, 버림하여 d=10이다. 이는 학습에서 모사한 0〜10의 정확히 끝 지점에 걸린다.
이동 로봇이라면 더욱 까다롭다. 앞 표에서 이동 로봇은 고정된 상태보다 약 30ms 느렸다. 같은 차이가 더해지면 238ms가 되어 d=11로, 학습 범위 밖으로 나가는 계산이다.
반면, 추론 시 RTC 실험은 +200ms까지 성능 저하가 없었으므로, 미국 동부 왕복 시간 162ms여도 그 범위 안에 들어온다. 같은 왕복 시간이라도, 방식에 따라 '여유'와 '예상 범위를 벗어남'으로 나뉜다. API에서 어느 것이 사용되는지는 공개되지 않았다.
로봇 내부에 배치하는 쪽의 수치도 있다. NVIDIA의 모델 카드를 보면, GR00T N1.7의 추론은 데이터센터용 H100에서 27.9ms, 로봇용 Jetson AGX Thor에서 93.8ms이다 (둘 다 TensorRT, 노이즈 제거 4 스텝, 카메라 1대). 차이는 65.9ms다. 이 모델이라면, 왕복 시간이 약 66ms보다 길어지는 클라우드의 H100보다 로봇에 탑재된 Thor가 더 빨리 답을 반환한다 (이미지 전송 시간 등은 제외한 필자의 계산). 일본-미국 왕복 100ms는 이 차이를 초과한다.
솔직히 말하자면, 이 추산치는 PI의 연구용 구성 값과 Azure 리전 간 중앙값을 더했을 뿐이며, API 모델, 청크 길이, RTC 방식, GPU 위치 등 어떤 것도 공개되지 않았기 때문에, 실제 값은 API 위에서 측정할 수밖에 없다.
당신의 로봇에서 GPU까지 왕복 시간은 몇 ms였나요? 구성(유선인지 무선인지, 어느 클라우드인지)과 함께 댓글로 알려주세요.
API는 대기열이다. 하지만 지연을 측정하는 방법과 RTC의 효과는 오늘, 직접 확인할 수 있다.
LeRobot에는 RTC가 내장되어 있어 데이터셋만으로 효과를 그래프화할 수 있다. 문서에 있는 명령어는 다음과 같다 (CUDA GPU 필요).
# LeRobot 리포지토리를 가져온 디렉토리에서
pip install -e
일반적인 생성(generation)과 RTC 생성이 좌우로 나란히 배치되어 있고, 새로운 청크의 시작 부분이 이전 청크의 끝 부분에 이어지는 모습이 보인다. `execution_horizon`
은 이전 청크와 맞추는 스텝 수이며, 문서상 기준으로 8~12가 적절하다.
openpi는 모델을 다른 서버에서 구동하고 WebSocket으로 행동(action)을 전송하는 구조를 처음부터 갖추고 있다. 원격 추론 설명과 simple_client를 사용하면 로봇이 없어도 왕복 시간을 측정할 수 있다.
GPU 머신 (openpi는 Ubuntu 22.04에서 검증. 추론에는 VRAM 8GB 초과)
git clone --recurse-submodules [email protected]:Physical-Intelligence/openpi.git
cd openpi
...
simple_client는 클라이언트 측에서 측정된 1회당 시간(`client_infer_ms`)을 평균, P50, P95, P99로 표시한다. **봐야 할 것은 평균이 아니라 P99이다.** 그것을 20ms로 나누어 버린 값이 당신 구성의 d가 된다.
지연 예산 계산 (저자 작성/미실행. 값은 본문 시뮬레이션과 동일)
from math import floor
def delay_steps(latency_ms: float, hz: int = 50) -> int:
...
수동 계산으로는 d가 순차적으로 5, 5, 10, 13이 되며, 학습 시 RTC 범위를 벗어나는 것은 미국 동부 지역뿐이다 (미국 서부는 양 끝의 d=10).
LeRobot의 비동기 추론은 추론 서버(PolicyServer)와 로봇 측 클라이언트(RobotClient)를 분리한다. 로봇은 가지고 있는 행동을 실행하는 동시에, 나머지가 임계값을 넘으면 다음 관측(observation)을 전송한다. 문서의 명령어를 LAN 내 GPU 머신에 연결하는 형태로 수정하면 다음과 같다 (주소, 포트, 로봇과 카메라 설정은 예시. 저자는 실행하지 않았다).
GPU 머신 측
python -m lerobot.async_inference.policy_server
--host=192.168.0.10
...
효과적인 파라미터는 두 가지다.
- `actions_per_chunk`: 한 번에 출력하는 행동의 수. 기본값은 50이며, 문서의 일반적인 값은 10~50이다.
- `chunk_size_threshold`: 가지고 있는 행동이 이 비율을 넘으면 다음 관측을 전송한다. 0에 가까우면 동기식(synchronous)과 같아지고, 1에 가까우면 매 스텝마다 전송한다. 문서에서는 0.5~0.6이 성공적이었다고 한다.
`--debug_visualize_queue_size=True`를 추가하면 가지고 있는 행동 잔량의 변화를 그릴 수 있다. **잔량이 0에 붙어 있다면, 추론 속도에 비해 제어가 너무 빠르다는 의미다.** 문서 역시 행동을 다 사용한다면 프레임 속도(fps)를 낮추도록 권장하고 있다. 추론 시 메모리는 $ ext{π}0$의 14GB에 비해 SmolVLA는 약 2GB로 충분하다.
PI 측정에서도 통신과 이미지 축소는 편차가 있었다 (50회 추론의 평균 ± 표준편차).
Network 21.20 ± 3.12ms (mobile)
Image resize 11.22 ± 5.00ms (mobile)
Azure의 왕복 시간도 중앙값 기준으로, 절반의 시간은 그보다 느리다. d는 평균이 아니라 느린 쪽의 꼬리(tail)에서 결정된다. 학습 시 RTC라면, d가 10을 순간이라도 초과하는 순간 모델은 학습에서 보지 못한 상황에 놓인다.
**대책: simple_client의 P99 (최소한 P95)로 d를 계산할 것.**
비동기 추론은 추론 사이에 로봇이 멈추는 문제를 없애준다. 하지만 신구 청크 간의 불일치는 또 다른 문제다. LeRobot의 RTC 문서는 비동기 추론을 '대기 시간(waiting time)'으로, RTC를 '청크의 불연속성(chunk discontinuity)'을 해결하는 것으로 정리하고 있다. 그리고 겹침을 평균만 내는 방식은 PI 실험에서 +100ms 지연일 때 보호 정지(protective stop)를 일으켰다.
**대책: 지연이 큰 구성에서는 비동기 추론에 RTC를 중첩할 것. LeRobot의 경우 실제 기기 실행 시 `--inference.type=rtc`를 추가한다. 문서 역시 두 가지를 함께 사용하도록 권장하고 있다.**
하나의 청크는 50 스텝, 즉 1초 분량밖에 없다. 통신이 끊어지면 로봇은 가지고 있는 행동을 다 소진하는 시점에 명령을 잃는다. PI 발표에서도 조기 전개 과정에서 이런 문제가 있었다고 언급하고 있다.
including network connectivity challenges for some
Google은 7월에 출시한 Gemini Robotics On-Device 2를 로봇 측에서 구동하는 이유로 바로 이것을 들고 있다.
많은 로봇 애플리케이션은 네트워크 지연(latency)이나 인터넷 연결 없이 작동해야 한다.
**대책: 자체 행동이 다했을 때 안전하게 멈추는 처리는 반드시 로봇 측에 배치할 것. 멈출 수 없는 작업이라면, 로봇 내부에서 구동되는 대체 모델을 준비할 것.**
PI는 발표에서 API의 기반이 되는 모델을 신속하게 업데이트하여 최신 모델을 지속적으로 제공한다고 적고 있다.
Pi can update the models underpinning the API rapidly
버전을 고정할 수 있는지, 아니면 업데이트를 알려주는지에 대해서는 언급되어 있지 않다. 로봇에게 있어 모델의 업데이트는 동작 자체가 변하는 것을 의미한다. 어제 잡았던 부품을 오늘 잡지 못하게 될 수도 있다.
**대책: 대표적인 작업을 정하고 매일 같은 조건에서 성공률을 측정할 것. 결과는 날짜와 함께 보관해 둘 것.**
신청 양식에서는 원격 조작 데이터와 모의 데이터의 시간 수만 묻고, 데이터 취급에 대해서는 언급하지 않는다. 반면, PI가 지난 2월에 공개한 파트너 기사에는 파트너 데이터를 사전 학습(pre-training)에 포함했을 경우와 포함하지 않았을 경우를 비교한 그래프가 있다.
UPT = Ultra data included in pre-training (+UPT = 포함, -UPT = 미포함).
파트너 데이터가 PI의 사전 학습에 들어간 사례는 이미 존재하는 것이다. API로 올린 데이터가 어떻게 처리될지는 공개된 정보만으로는 알 수 없다.
**대책: 규정으로 데이터 사용처를 확인할 수 있을 때까지, 사람의 얼굴이나 회사 기밀 공정이 담긴 영상은 올리지 말 것.**
| 배치 위치 | 추가되는 통신 | 추론 속도 예시 (공개 값) | 강점 | 약점 | 현재 사용 가능한 예시 |
|---|---|---|---|
| 클라우드 | WAN 왕복 (동일본→미국 서부 2로 100ms) | 비공개 | 최신 모델. GPU와 미세 조정(fine-tuning)을 맡길 수 있음 | 단절 및 흔들림. 가격과 데이터 취급이 비공개 |
| ... | | | | |
| 모델 | 제공처 | 파라미터 | 라이선스 | 최근 30일 DL | 이름 포함 모델 수 | 추론 기준 |
| SmolVLA (lerobot/smolvla_base) | Hugging Face | 0.45B | Apache-2.0 | 150,095 | 6,102 |
추론 시 메모리 약 2GB |
| GR00T N1.7 (nvidia/GR00T-N1.7-3B) | NVIDIA | 3.1B | NVIDIA Open Model License | 108,706 | 443 | AGX Thor에서 93.8ms |
| π0.5 (lerobot/pi05_base) | PI (LeRobot 이식) | 3.6B | Gemma |
18,027 | 3,520 |
VRAM 8GB 초과 (openpi) |
| MolmoAct2 (allenai/MolmoAct2) | Ai2 | 5.4B | Apache-2.0 (연구·교육용으로 명시) | 14,951 | 308 | 설정에 따라 bf16으로 16GB 미만 |
| OpenVLA (openvla/openvla-7b) | OpenVLA 연구팀 | 7.5B | MIT | 152,456 | 80 | 1회 추론으로 1단계 분 |
파라미터는 Hugging Face의 API가 반환하는 safetensors의 합계이며, 최근 30일 DL은 모델 페이지의 'Downloads last month' 값이다. 이름 포함 모델 수는 로보틱스 부문에서 smolvla, groot, pi05, molmoact, openvla를 검색한 건수이며, 파생 모델의 대략적인 기준에 불과하다. MolmoAct2의 라이선스는 Hugging Face 카드가 아닌 GitHub 기재에 따른 것이다.
**표에서 읽을 수 있는 것:**
-
**최근 30일 다운로드 수 1위는 2024년 6월에 논문이 발표된 OpenVLA(152,456)입니다.** 다만 한 번의 추론으로 1 스텝 분량만 출력하기 때문에 원격 추론과는 궁합이 좋지 않습니다 (필자의 견해).
-
**파생 모델이 가장 많은 것은 SmolVLA(6,102)입니다.** 0.45B 크기에 추론 시 메모리는 약 2GB를 차지합니다. 로봇 내부에 탑재하기에는 단연 최고입니다.
-
**$ ext{π}0.5$의 가중치는 Apache가 아닌 Gemma 조건으로 배포되고 있습니다.** openpi 코드 자체는 Apache-2.0입니다. 상업적으로 사용하기 전에 조건을 반드시 확인해야 합니다.
-
**PI의 최신 모델은 이 표 어디에도 없습니다.** openpi에서 공개한 가중치는 $ ext{π}0$, $ ext{π}0 ext{-FAST}$, $ ext{π}0.5$까지이며, Hugging Face의 PI 조직 페이지에 있는 모델은 FAST 토크나이저 하나뿐이었습니다. 최신 세대를 사용할 방법은 현재로서는 API밖에 없습니다.
구내 GPU나 로봇에서 미세 조정된 $ ext{π}0.5$나 SmolVLA를 RTC(Real-Time Chunking)와 함께 구동한다면, LeRobot 문서에 있는 실행 명령이 그대로 기반이 됩니다 (로봇, 포트, 카메라, 태스크는 예시입니다. 필자는 실제로 실행하지 않았습니다).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
lerobot-rollout
--strategy.type=base
--policy.path=${HF_USERNAME}/policy_repo_id
...
✗ "클라우드 GPU가 더 빠르다" → GR00T N1.7은 H100에서 27.9ms, Thor에서는 93.8ms입니다. 그 차이인 66ms는 일미 왕복 100ms로 사라집니다.
✗ "같은 건물 LAN이라면 지연 시간은 거의 제로다" → $ ext{π}0.5$의 LAN을 통한 추론에서도 이동 로봇으로 139ms가 걸립니다.
✗ "지연 시간은 평균만 보면 된다" → 학습 시 RTC가 가정했던 것은 최대 200ms였습니다. 이 범위를 초과하는 순간은 예상 범위 밖에 있습니다.
...
PI의 API는 로봇 세계에 LLM(대규모 언어 모델)이 가진 '두뇌를 API로 빌리는' 형태를 도입했습니다. 샌프란시스코의 Almond는 자사 양팔 로봇이 자체 조립에 사용하는 스페이서의 버(burr) 제거 작업을, API를 통해 4일 동안 시도하고 오류를 수정하는 모델에게 맡기고 있습니다. 자체 GPU 없이 최신 모델을 시험해 볼 수 있다는 것은 큰 진전입니다.
다만, 채팅과 달리 로봇은 기다려주지 않습니다. 50Hz 제어에서는 20ms가 1 스텝이므로, 추론 지연 시간은 그대로 '이전 계획으로 움직이는 시간'이 됩니다. **오늘, 본인의 로봇에서 GPU까지의 왕복 시간을 P99 기준으로 측정하여 20ms로 나누어 보세요. 그 숫자가 신청서 양식에 들어갈 답입니다.**
Frontier Models for Every Robot: Announcing our API beta - Physical Intelligence
Pi API beta waitlist - Physical Intelligence
Real-Time Action Chunking with Large Models - Physical Intelligence
Real-Time Execution of Action Chunking Flow Policies - arXiv:2506.07339
Training-Time Action Conditioning for Efficient Real-Time Chunking - arXiv:2512.05964
The Physical Intelligence Layer - Physical Intelligence
openpi - GitHub
Running openpi models remotely - openpi
simple_client - openpi
Real-Time Chunking (RTC) - LeRobot Docs
Asynchronous Inference - LeRobot Docs
Azure network round-trip latency statistics - Microsoft Learn
GR00T-N1.7-3B - Hugging Face
Gemini Robotics 2 brings whole body intelligence to robots - Google DeepMind
Gemini Robotics On-Device 2 - Model Card - Google DeepMind
lerobot/smolvla_base - Hugging Face
lerobot/pi05_base - Hugging Face
MolmoAct2 - GitHub
openvla/openvla-7b - Hugging Face
Models: robotics - Hugging Face
Physical Intelligence - Hugging Face
**이 글이 도움이 되었다면, 좋아요와 저장 부탁드립니다! PI API에 가입하려는 로봇 회사 동료들에게도, 폼을 제출하기 전에 공유해 주세요.**
댓글로 알려주세요.
**당신의 로봇 추론은 클라우드? 로컬? 둘 다?****로봇에서 GPU까지의 왕복 시간(P99)은 몇 ms였나요?****최신 모델을 클라우드에서 빌릴 건가요? 아니면 SmolVLA나 π0.5를 직접 구동할 건가요?**
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
