멀티카메라 로봇의 처리량은 카메라 커넥터 수보다 데이터 경로에 더 크게 종속된다. 센서가 프레임을 보내도 수신, 색 변환, 리사이즈, 인코딩, 추론 사이에서 버퍼가 복사되거나 큐가 밀리면 제어기가 받는 영상은 이미 늦다. 따라서 Jetson AGX Thor를 고르는 일과 카메라 대역폭을 설계하는 일은 분리해서 보아야 한다.
출발점은 NVIDIA가 공개한 최대 사양이 아니라 우리 파이프라인의 바이트 장부다. Jetson Thor 공식 제품 페이지에는 128GB LPDDR5X와 273GB/s 메모리 대역폭이 표시돼 있지만, 이 값이 카메라가 지속해서 독점할 수 있는 처리량을 뜻하지는 않는다. GPU 추론과 CPU, 후처리도 같은 메모리 계층을 사용한다.
먼저 확인된 사양과 아직 측정하지 않은 값을 나눈다
Thor에서 확인된 사실은 메모리 용량과 표시 대역폭, 전력 범위, HSB 카메라 입력 같은 제품 수준의 조건이다. NVIDIA의 Camera Development 문서는 Thor 세대의 기본 카메라 경로로 SIPL을 설명하고 Argus도 지원한다고 밝힌다. 어느 경로를 선택하느냐에 따라 드라이버, 버퍼 형식과 디버깅 도구가 달라진다.
반면 실제 센서가 내는 프레임 간격, CSI 또는 이더넷 구간의 오버헤드, 변환 횟수, 추론 모델의 메모리 트래픽은 제품표에 없다. 이 값들은 카메라 데이터시트, 파이프라인 설정과 실행 로그에서 채워야 한다. ‘최대 몇 대’라는 답을 먼저 정하고 나중에 근거를 맞추면 야간 노출이나 장면 복잡도가 바뀔 때 설계가 쉽게 깨진다.
계산표에는 평균과 피크를 따로 둔다. 카메라가 서로 다른 시각에 도착한다는 가정만 쓰지 말고, 동기 트리거로 여러 프레임이 한꺼번에 도착하는 구간도 기록한다. 지연 예산은 한 프레임의 평균 처리시간보다 가장 늦은 프레임과 큐 깊이가 더 잘 설명한다.
원시 프레임부터 바이트 단위로 예산을 세운다
원시 대역폭의 기본식은 가로 픽셀 × 세로 픽셀 × 초당 프레임 × 픽셀당 바이트 × 카메라 수다. 예를 들어 1920×1080, 30fps, 16비트로 들어오는 카메라 8대라는 가정을 넣으면 초당 995,328,000바이트, 약 0.995GB/s다. 이는 설명을 위한 산술값이며 패킷 오버헤드와 정렬, 메타데이터, 재전송은 포함하지 않는다.
픽셀당 바이트는 이름만 보고 정하지 않는다. Bayer RAW10은 센서가 10비트를 내더라도 저장·정렬 방식에 따라 메모리 점유가 달라질 수 있고, RGB 변환 뒤에는 채널 수만큼 커진다. NV12도 휘도와 색차 평면을 합친 크기를 써야 한다. 수신 형식, 중간 형식, 모델 입력 형식을 각각 한 행으로 두면 어느 변환에서 트래픽이 늘었는지 보인다.
인코딩 비트레이트는 원시 프레임 대역폭을 대신하지 못한다. 카메라가 원시로 들어와 하드웨어 인코더에서 압축된다면 수신과 전처리 구간에는 여전히 원시 버퍼가 존재한다. 압축률도 움직임과 노이즈, 화질 설정에 따라 흔들리므로 네트워크 저장 예산과 메모리 처리 예산을 다른 열에 적어야 한다.
카메라 수보다 실제 작업 부하로 병목을 재현한다
실험은 빈 연구실의 고정 영상이 아니라 로봇이 겪을 장면으로 구성한다. 주행 중 흔들림, 세밀한 텍스처, 조도 전환, 여러 카메라의 동기 프레임은 인코딩량과 전처리 시간을 바꾼다. 녹화만 켠 상태, 추론만 켠 상태, 녹화와 추론을 동시에 켠 상태를 나누면 자원 경쟁의 위치를 찾기 쉽다.
측정 지표도 FPS 하나로 끝내지 않는다. 센서 타임스탬프에서 모델 입력까지의 지연, 추론 완료까지의 지연, 프레임 드롭, 큐 깊이, 메모리 사용량과 GPU·CPU 부하를 같은 시간축에 놓는다. 평균 FPS가 유지돼도 오래된 프레임이 처리된다면 폐루프 제어에는 부적합할 수 있다.
카메라가 위치 추정에도 쓰인다면 처리량을 줄이는 방식이 알고리즘의 관측성을 해치지 않는지 따로 본다. 해상도나 FPS를 낮추기 전에 VIO와 SLAM의 차이를 기준으로 빠른 회전, 저텍스처 구간과 동기 오차에 필요한 입력을 확인하는 편이 안전하다.
공식 수치가 말하는 것과 말하지 않는 것을 구분한다
공식 문서는 설계의 상한과 지원 경로를 알려 주지만 우리 센서 조합의 지속 성능을 보증하지 않는다. 특히 메모리 표시 대역폭, 인터페이스 지원, 샘플 파이프라인의 FPS를 같은 종류의 증거처럼 더하면 안 된다. 아래 표처럼 주장과 검증 과제를 한 줄씩 대응시킨다.
| 공식 자료에서 확인되는 항목 | 설계에 쓸 수 있는 의미 | 현장에서 추가로 재야 할 값 |
|---|---|---|
| 128GB LPDDR5X·273GB/s 표시 대역폭 | 메모리 용량과 이론적 상한 | 카메라·추론 동시 부하의 지속 처리량과 지연 |
| HSB 카메라 입력과 QSFP 지원 | 연결 가능한 물리 경로 | 센서별 프로토콜·드라이버·스위치 구간의 실효 처리량 |
| Thor에서 SIPL 중심의 카메라 개발 경로 | 지원 API와 버퍼 경로를 고르는 기준 | 선택한 드라이버의 형식 변환·복사·큐 동작 |
| nvsiplsrc의 센서별 NVMM 풀·큐·스레드 | 스트림을 분리해 구성할 수 있는 구조 | 여러 스트림 동시 실행 시 드롭·대기·메모리 압력 |
Accelerated GStreamer 문서는 `nvsiplsrc`가 센서별 source pad와 NVMM 풀, 큐, 스레드를 두는 구조를 설명한다. 이 구조는 불필요한 CPU 왕복을 줄일 설계 단서이지, 어떤 그래프에서도 복사가 전혀 없거나 모든 센서가 목표 FPS를 유지한다는 보증은 아니다.
증설 전에 실패 비용이 큰 지점부터 닫는다
대역폭 여유를 한 숫자로 표현하면 변경 영향이 가려진다. 센서 교체, 모델 입력 크기 증가, 녹화 품질 상향은 서로 다른 구간을 압박한다. 그래서 카메라 한 대를 더 붙일 수 있는가보다 어느 조건까지 지연 상한을 지킬 수 있는가를 승인 기준으로 삼는다. Thor와 Orin의 구매 차이는 Jetson AGX Thor·Orin 비교에서 보고, 여기서는 선택한 장치의 검증에 집중한다.
- 센서마다 수신 형식·해상도·FPS·동기 방식을 고정하고 원시 바이트 예산을 계산한다.
- 수신→변환→추론→인코딩→저장 각 경계의 버퍼 형식과 복사 여부를 기록한다.
- 동기 프레임이 몰리는 최악 구간에서 지연 백분위, 드롭 수와 큐 깊이를 함께 잰다.
- 카메라만, 추론만, 동시 실행을 비교해 메모리·연산·입출력 병목을 분리한다.
- 센서나 모델이 바뀔 때 같은 시나리오를 재실행할 수 있도록 설정과 로그를 보존한다.
예산표에는 ‘예상’, ‘관측’, ‘승인’ 세 열을 둔다. 예상 열은 픽셀 형식과 프레임 수로 계산한 값, 관측 열은 실제 실행에서 읽은 처리량·지연·드롭, 승인 열은 작업 요구와 비교한 판정이다. 계산보다 관측값이 커지면 정렬이나 숨은 변환, 중복 버퍼부터 찾는다. 관측값이 작더라도 프레임이 버려졌다면 효율이 좋아진 것이 아니다. 이 구분이 있어야 센서 공급사, 파이프라인 개발자와 모델 담당자가 같은 숫자를 서로 다르게 해석하지 않는다.
복구 시험도 용량 시험의 일부다. 카메라 한 대를 잠시 끊었다가 다시 연결하고, 인코더나 저장 프로세스를 재시작했을 때 나머지 스트림의 타임스탬프와 큐가 정상으로 돌아오는지 본다. 정상 상태의 최대 FPS만 통과한 시스템은 현장에서 한 번의 링크 흔들림 뒤 오래된 프레임을 계속 처리할 수 있다. 재연결 이후 버퍼가 비워지는지, 프레임 순서가 보존되는지와 목표 지연으로 복귀하는 시간을 기록한다.
마지막 판단은 표시 대역폭 대비 사용률이 아니라 작업 지연과 데이터 손실로 내린다. 목표 처리량을 지켰더라도 온도 상승 뒤 프레임이 밀리거나 복구 과정에서 시간 순서가 뒤집히면 운영 여유가 부족하다. 반대로 모든 카메라를 최댓값으로 가정해 장치를 과도하게 키우는 것도 비용만 늘린다. 측정한 최악 조건과 변경 여유를 따로 남기는 이유다.
Jetson AGX Thor 카메라 대역폭 설계 실무 질문
273GB/s라는 수치를 카메라 대역폭으로 그대로 써도 되나요?
아니다. 제품에 표시된 메모리 대역폭은 메모리 계층의 상한 성격이며 카메라 전용 지속 처리량이 아니다. 카메라, GPU 추론, CPU와 후처리가 공유하므로 실제 그래프에서 지연·드롭·큐 깊이를 함께 측정해야 한다.
더 큰 Thor 모듈을 선택하면 메모리 복사 병목도 사라지나요?
장치 여유가 늘 수는 있지만 형식 변환이나 프로세스 경계에서 생기는 복사는 그대로 남을 수 있다. 업그레이드 전에 버퍼 형식과 이동 경로를 추적해야 하며, 같은 카메라·모델·동시 부하 조건으로 전후를 비교해야 한다.
자료 마지막 확인: 2026년 8월 26일