모델을 멀리 두면 통신과 장애의 경계가 추가된다
로컬 추론은 로봇 가까운 컴퓨터에서, 원격 추론은 네트워크 너머 서버에서 모델을 실행하는 구성이다. 로컬도 센서/구동기·다른 프로세스와 통신할 수 있고 원격도 상위 지각/계획만 맡기는 등 분담이 다양하다. 어느 쪽이 항상 빠르거나 적합한지 장치 이름만으로 결정하지 않는다. 지연/메모리·전력, 연결 단절과 데이터 취급·접근 권한을 과업 조건에 맞춰 비교한다.
합성 로컬 경로가 전처리 10 ms·모델 55 ms·후처리 5 ms·제어기 적용까지 10 ms라면 총 80 ms다. 원격 경로는 직렬로 인코딩 8 ms·상행 12 ms·서버 대기 15 ms·모델 20 ms·하행 10 ms·복원 5 ms·적용 10 ms라 80 ms다. 모델은 55→20 ms로 빨라졌지만 전체 지연은 같다. 모든 항목이 겹치지 않고 같은 관측의 경로라는 교육용 가정이다.
네트워크 지연이 추가로 40 ms 늘면 원격 전체는 120 ms다. 기한 100 ms에서 평소 20 ms 여유가 20 ms 초과로 바뀐다. 평균 대역폭이 높다는 것만으로 이 변동/timeout을 없애지 못한다. 다른 호스트 시각을 직접 빼지 말고 정합/오차를 기록하거나 클라이언트의 같은 경과 시계로 왕복 경계를 잰다. 이 표는 실제 네트워크/모델 성능이 아니다.
응답 봉투에는 숫자 외에 근거 ID와 버전이 필요하다
요청에는 요청 ID·관측 ID/취득 시각, task/장면·모델 묶음 버전과 입력 계약을 연결한다. 응답도 어떤 요청/관측/버전에서 나온 결과인지 밝혀야 한다. 인증/권한은 신뢰된 연결/감독이 검사하며 모델이 적은 '승인' 문자열로 대체하지 않는다. 전송 암호화만으로 좌표/시간·행동 의미의 호환이 증명되는 것도 아니다.
관측 취득이 같은 시계의 1000 ms이고 응답/적용이 1080 ms라면 근거 관측의 적용 나이는 80 ms다. 허용 나이를 100 ms 이하로 정한 과제에서는 통과한다. 늦은 1120 ms 응답은 120 ms로 초과다. 응답을 새 명령 봉투에 넣어 발행 나이를 0으로 만들더라도 근거 관측이 새로워지지는 않는다. model response 수신과 실제 동작 완료도 다른 사건이다.
timeout은 정해진 시간 안에 필요한 응답/결과를 못 받은 상태다. 서버 계산이 끝나지 않았는지, 계산은 끝났으나 통신만 늦었는지 알 수 없을 수 있다. 순수 추론을 재요청하는 것과 이미 부작용이 있는 skill을 다시 실행하는 것을 구분한다. 중복 요청/늦은 응답 정책과 현재 실행 상태를 확인하지 않고 원격 실패를 로컬 동작으로 즉시 덮어쓰지 않는다.
체크포인트와 해석 코드를 하나의 묶음으로 검증한다
모델 묶음은 가중치뿐 아니라 입력 feature 이름/shape·카메라 채널/해상도·정규화 통계, 출력 관절 순서/단위·absolute/delta·프레임/기준 시각, 모델/런타임과 schema 버전을 함께 고정한 계약이다. 해시는 파일 동일성을 확인할 수 있지만 잘못된 행동 의미를 자동으로 찾아 주는 것은 아니다. 같은 shape/숫자 범위로도 의미가 다를 수 있다.
가상 A 묶음은 출력 z를 정규화된 절대 관절 목표로 해석하고 평균 μ=0.3 rad/표준편차 σ=0.1 rad로 복원한다. q=μ+σz이므로 z=1이면 q=0.4 rad다. 가상 B 묶음은 정규화하지 않은 순차 증분 rad를 출력하며 현재 q=0.7 rad에서 +0.1이면 목표는 0.8 rad다. 두 예의 행동 표현을 실제 제품의 기본값이라고 가정하지 않는다.
B의 숫자 0.1을 A의 복원/절대 해석으로 잘못 처리하면 0.3+0.1×0.1=0.31 rad가 된다. 의도한 0.8 rad와 0.49 rad 차이다. 둘 다 유한한 한 개 실수여서 dtype/shape 검사만으로는 이 혼용을 찾지 못한다. 관절/그리퍼·양팔 순서나 RGB/BGR 순서, 카메라 이름을 바꾸는 경우도 계약과 기준 입력의 기대 출력을 함께 검증한다.
교체 후보를 먼저 비실행 경로에서 기준 입력·변형/오류 입력으로 확인하고 지연/메모리·출력/작업 지표를 비교한다. 이전 통계를 쓰며 새 가중치만 넣거나 단위가 다른 출력을 기존 제한기로 넘기지 않는다. 같은 검증 묶음으로 모델/전처리·복원/제한 계약이 선택되도록 관리한다. 이 문맥의 원자적 선택은 요청 하나가 신구 구성 일부를 섞지 않도록 하는 논리적 조건이며 하드웨어 전체가 한 순간에 바뀐다는 뜻은 아니다.
서버의 모델 교체와 로봇의 전환은 다른 계약이다
Triton 공식 repository는 모델별 버전 디렉터리와 설정을 설명하고, control 문서는 변경 적용이 제어 모드에 따라 다름을 설명한다. 폴더를 복사하면 모든 서버가 즉시 새 모델을 쓰거나 모든 응답이 한꺼번에 바뀐다고 가정하지 않는다. 아래 절차는 특정 서버 기능을 실행한 결과가 아닌 로봇 측의 설계 과제다.
전환 시 새 요청을 보류하고 이전 goal/물리 상태를 확인한다. 남은 action chunk/큐·시간창·재귀 상태와 EMA/ensemble의 상태는 어떻게 비울지/재초기화할지 명시한다. 값을 지운 뒤 출력이 튀지 않는지도 확인한다. 검증된 후보 묶음을 선택한 뒤 새 관측에서 새 실행 세대를 시작하고, 실제 전제/권한·출력 제한을 다시 검사한다. 정지 요청 수락만으로 실제 정지를 선언하지 않는다.
실행 세대 epoch는 이 설계에서 전환/재시작마다 바꾸는 식별자다. 이전 epoch e7 요청이 늦게 돌아왔는데 현재가 e8이면 같은 숫자 shape여도 새 실행에 섞지 않는다. request/model ID·나이도 함께 검사한다. epoch를 바꾸었다고 실행 중인 이전 명령이 물리적으로 취소되는 것은 아니다. 이미 전달된 명령의 결과/중단은 별도 추적한다.
롤백(rollback)은 검증된 이전 구성 묶음으로 되돌리는 관리 작업이다. 로봇 위치/물체 파지·배터리나 세계 상태가 과거로 되돌아가는 것은 아니다. 이전 묶음의 호환/가용성과 현재 장면·관측/권한을 재검증하고 감독 상태를 거쳐 재개한다. 복구 조건을 만족하지 못하면 보류/미상을 유지한다. 기존 6.5 End-to-End 배포와 연결해 버전, 판단 근거·중단/결과와 rollback 이유를 기록하자.