Gemini Robotics On-Device 2의 지연 예산은 ‘모델 추론 몇 ms’로 끝나지 않는다. 카메라가 장면을 노출한 시점부터 프레임 읽기와 전처리, VLA 추론, 행동 후처리, 미들웨어 전송, 저수준 제어와 실제 관절 응답까지 같은 시계로 이어 재야 한다. 로컬 실행은 클라우드 왕복을 없애지만 센서·컴퓨팅·큐·제어기에서 생기는 지연과 흔들림까지 없애지는 않는다.
Google DeepMind는 On-Device 2를 네트워크가 제한된 환경에서 로컬로 실행하는 VLA로 설명하지만, 공개 자료에는 camera-to-actuator 지연, 대상 보드, 전력, quantization과 cloud fallback 기준이 없다. 그러므로 이 글은 존재하지 않는 밀리초 수치를 채우지 않는다. 대신 각 구간의 timestamp, p50·p95·p99, 최대값, deadline miss, frame age와 표본 수를 기록해 해당 로봇에서 허용 가능한 경계를 찾는 방법을 제시한다.
먼저 어떤 작업과 입력을 한 번의 지연으로 묶을 것인가
지연 측정의 시작점은 작업 위험과 제어 주기다. 테이블 위 물체를 천천히 옮기는 작업과 걷는 로봇이 사람을 피해 방향을 바꾸는 작업은 늦은 명령의 비용이 다르다. 카메라 영상만 VLA에 들어가는지, 관절 상태·힘·언어 지시가 함께 들어가는지 적고, 최종 출력이 목표 자세·속도·gripper 상태·행동 묶음 중 무엇인지 명시한다.
- 카메라 exposure 시작·종료와 sensor readout 완료 시간을 분리한다.
- decode, resize, crop, normalization과 여러 카메라 동기화 시간을 기록한다.
- VLA 입력 큐 진입·추론 시작·종료와 모델 버전을 같은 event ID에 묶는다.
- 행동 decoding, 좌표 변환, 제한값 적용과 middleware queue 시간을 잰다.
- motion controller 수신·적용 시점과 safety layer의 수정·거부를 남긴다.
- encoder·force sensor에서 실제 반응이 확인된 시점까지 폐루프 지연으로 센다.
- 각 구간의 p50·p95·p99·최대값, deadline miss와 전체 sample count를 함께 보관한다.
하나의 end-to-end 값은 사용자가 체감하는 결과를 보여 주지만 원인을 알려 주지 않는다. 구간별 값은 병목을 찾지만 timestamp가 다른 clock이면 합칠 수 없다. PTP 같은 동기 방식의 이름보다 실제 clock offset과 drift를 측정하고, 로그 쓰기 때문에 지연이 달라지는지도 확인한다. 테스트 장면에는 정상 부하뿐 아니라 카메라 여러 대, 열 제한, 저장 장치 쓰기와 네트워크 단절을 포함한다.
프레임과 행동을 어떤 표현으로 연결해야 늦은 명령을 찾을 수 있나
영상에는 캡처 시각과 처리 완료 시각을 모두 붙인다. 추론이 빨라도 오래된 프레임이 큐에 머물렀다면 로봇은 과거 장면에 반응한다. 그래서 frame age를 ‘행동이 적용되는 순간－노출 시점’으로 별도 기록한다. 여러 카메라를 쓰면 묶인 프레임들의 시간 차이도 남겨야 한다. 서로 다른 순간의 손과 물체를 한 입력으로 합치면 공간 판단이 맞아도 접촉 시점이 어긋날 수 있다.
행동 표현에는 기준 좌표계, 단위, 유효 시각과 지속 시간을 넣는다. 관절 목표인지 end-effector delta인지, 한 스텝인지 여러 스텝의 chunk인지에 따라 늦은 출력의 처리법이 달라진다. 새 관측이 도착했는데 이전 행동 묶음이 큐에 남아 있으면 폐기·혼합·완료 중 어떤 규칙을 쓰는지 기록한다. 명령 sequence number와 실제 controller 적용 번호를 맞추면 누락과 재정렬을 찾을 수 있다.
On-Device 2의 역할과 일반 설명은 인터넷 없이 실행하는 VLA 안내에서 볼 수 있다. 여기서는 ‘오프라인’이라는 제품 특징을 측정 가능한 데이터 계약으로 바꾼다. 로컬 모델이 수치형 로봇 행동을 출력해도 하위 제어기가 그 행동을 어떤 rate와 제한으로 소비하는지 공개되지 않으면 실제 제어 지연은 정해지지 않는다.
모델 추론 시간만 재면 왜 의사결정 지연을 놓치는가
추론기는 입력 준비 완료부터 출력 tensor 생성까지 따로 잰다. cold start와 warm run, batch 크기, precision, thermal state, 동시 프로세스와 메모리 압박을 함께 기록한다. 평균 하나는 간헐적 멈춤을 숨기므로 분포와 최댓값, deadline을 넘긴 횟수를 본다. 모델이 기권하거나 행동을 생성하지 못한 경우를 빠른 추론 표본에서 빼지 않고 별도 결과로 남긴다.
Google의 공식 On-Device 2 모델 페이지는 새 embodiment에 수시간의 훈련과 200개 미만 예시로 적응할 수 있다고 설명한다. 이는 2026년 8월 26일 조회한 개발사 사례이며 대상 로봇·과제 수와 반복 횟수, 실제 학습 기간의 분모가 공개되지 않았고 독립 검증도 없다. 모든 작업의 데이터 상한이나 현장 학습 SLA로 사용해서는 안 된다.
모델 선택은 속도와 성공률을 따로 보지 않는다. 낮은 precision이나 작은 입력으로 추론이 빨라졌다면 같은 trial 집합에서 작업 성공, 접촉 오류, 기권과 안전 제어기의 거부가 어떻게 변했는지 비교한다. 모델 카드의 SO101·Dexmate 수치는 Google의 특정 post-training 평가이며 task·trial 분모와 독립 검증이 없다. 독자 하드웨어의 예상 성공률이나 지연 수치로 옮기지 않는다.
로컬 VLA와 저수준 제어의 명령권은 어디에서 갈라져야 하나
VLA는 작업 의미와 다음 행동 후보를 다루고, 빠른 균형·힘 제어·관절 제한과 충돌 회피는 해당 로봇의 저수준 계층이 맡아야 한다. 모델 프로세스가 멈추거나 deadline을 넘겼을 때도 안전한 감속·정지와 자세 유지가 작동하도록 권한을 분리한다. 로컬에서 돌아간다는 이유만으로 모델을 functional safety controller나 인증된 보호 기능의 대체재로 두지 않는다.
클라우드가 연결될 때 맡길 기능도 명확히 한다. 장기 계획, 로그 업로드, 원격 분석이나 모델 갱신은 지연 허용도가 높은 경로에 둘 수 있다. 반면 현재 관절 제한, 접촉 감시, 비상정지와 안전 구역 보호는 네트워크 상태에 의존하지 않아야 한다. 연결이 끊기면 로컬 VLA를 계속 쓸지, 제한 작업으로 낮출지, 안전정지할지는 작업별 위험과 로컬에 남아 있는 모델·지도·권한으로 결정한다.
Google의 On-Device 2 모델 카드는 주 평가 범위를 standing bi-arm manipulation으로 두고 OOD 과제와 high-DoF 제어를 한계로 적는다. 따라서 mobile·whole-body 로봇의 균형과 이동 제어까지 입증됐다고 해석하지 않는다. 안전 구조와 허용 deadline은 embodiment별 위험성 평가와 실제 controller 시험에서 정한다.
한 시계로 측정한 피드백 루프는 무엇을 보여 줘야 하나
폐루프 기록은 관측－결정－명령－반응을 한 사건으로 묶는다. 목표 물체가 움직였을 때 새 프레임이 언제 잡혔고, 어느 추론이 어떤 행동을 냈으며, controller가 무엇을 적용했고, encoder·힘 센서에서 언제 반응이 확인됐는지 이어 본다. 지연이 길어졌을 때 작업 결과만 실패로 표시하지 말고 어느 구간이 deadline을 넘었는지 남겨야 수정 위치를 찾을 수 있다.
| 측정 구간 | 같이 남길 값 | 선택·중단 판단 |
|---|---|---|
| 노출·readout | 노출 시각, readout 종료, frame age, 조명·설정 | 낡은 프레임 비율이 작업 위험에 허용되는지 |
| 전처리·동기화 | decode 시간, 카메라 간 skew, queue depth | 프레임 묶음의 시간 불일치가 접촉 판단을 흐리는지 |
| VLA 추론 | p50·p95·p99·최대, cold start, deadline miss, sample count | 최악 지연과 기권을 포함해 작업 주기를 지키는지 |
| 행동 전달·제어 | 명령 번호, 좌표 변환, safety 수정·거부, 적용 시각 | 늦거나 오래된 행동이 실행 버스에 남는지 |
| 기계 반응 | encoder·force 변화, overshoot, 정지·복구 시각 | 전체 폐루프가 안전·품질 기준 안에서 끝나는지 |
NIST의 event camera pixel latency 원 연구는 센서 지연이 광량, 설정, 활성 픽셀과 측정 절차에 의존함을 보여 주는 측정 자료다. On-Device 2를 시험한 논문은 아니므로 제품 지연의 근거로 쓰지 않는다. 여기서는 ‘카메라 지연’조차 하나의 고정 상수가 아니며 조건과 측정점을 공개해야 한다는 원칙만 가져온다.
공개되지 않은 수치 앞에서 시스템 한계를 어떻게 표시할까
2026년 8월 26일 기준 공개 모델 페이지와 모델 카드에는 end-to-end ms, FPS, 메모리, 전력, 대상 보드, quantization과 cloud fallback 임계값이 없다. 그러므로 ‘저지연’이라는 표현을 임의 숫자로 바꾸거나 특정 엣지 장치가 충분하다고 추천할 수 없다. trusted testers 상태 역시 누구나 같은 하드웨어 조합으로 배포할 수 있다는 뜻이 아니다.
로컬 실행의 실제 이점은 네트워크 왕복과 외부 연결 의존을 제거할 수 있다는 데 있다. 그러나 CPU·GPU 경쟁, 열 제한, 카메라 드라이버, 미들웨어 큐와 controller 주기가 남아 있으므로 결정론은 실측해야 한다. 클라우드 ER 계열의 제공 방식과 비교할 때는 Gemini Robotics ER 2 API·스트리밍 안내를 참고하되, 서로 다른 모델 역할의 지연을 같은 수치처럼 합치지 않는다.
합격 기준은 현장 baseline에서 만든다. 동일 작업을 기존 정책과 새 모델로 반복하고, 전체 지연 분포와 성공·개입·안전 거부·품질을 함께 비교한다. 평균이 개선돼도 p99나 최대 지연이 커져 위험 장면에서 늦는다면 배포를 보류한다. 반대로 모델 추론이 느려 보여도 행동 chunk와 controller가 안전하게 흡수한다면 전체 결과로 판단한다. 숫자는 해당 하드웨어·작업·부하·버전에만 귀속한다.
독자가 이어서 묻는 질문
카메라와 VLA, 로봇 제어기 사이에 최소 어떤 인터페이스 계약이 필요한가요?
관측에는 capture timestamp·frame ID·좌표계·유효성, 행동에는 기준 좌표·단위·sequence number·생성 시각·유효 기간을 넣어야 한다. controller는 실제 적용 시각과 수정·거부 이유를 돌려주고, encoder·힘 센서 반응을 같은 clock domain 또는 측정된 offset으로 연결해야 한다. 모델 출력과 안전 명령권도 분리한다.
전체 지연이 갑자기 늘었을 때 어디부터 확인해야 하나요?
먼저 clock offset과 로그 누락을 확인한 뒤 frame age·queue depth를 본다. 이어 전처리, cold start·thermal throttling을 포함한 추론 분포, 행동 큐와 middleware, controller 적용 시각, 실제 기계 응답 순서로 좁힌다. 평균값만 비교하지 말고 같은 사건의 p99·최대값과 deadline miss, 작업 결과를 함께 대조한다.
자료 마지막 확인: 2026년 8월 26일