결론부터 말하면, 로봇 엣지 컴퓨터의 합격 기준은 최고 TOPS가 아니라 실제 임무를 열 포화 상태까지 실행한 뒤의 지속 성능입니다. 센서 입력부터 전처리·추론·후처리·제어 메시지까지 전 구간을 돌리고, 온도·전력·CPU/GPU/메모리 클록·메모리 사용량과 P50·P95·P99 지연을 같은 타임라인에 기록해야 합니다.
Jetson에서는 NVIDIA Platform Power and Performance 문서를 기준으로 전력 모드와 열 관리 항목을 고정할 수 있습니다. 하드웨어 구조 선택은 CPU·GPU·NPU 비교, 배치 설계는 로봇 엣지 AI, 지연 용어는 로봇 추론 지연, 관절 열 문제는 로봇 관절 열 관리에서 분리해 볼 수 있습니다.
TOPS는 연산 상한이고 로봇 임무의 지속 처리량은 아니다
TOPS는 특정 정밀도와 연산 형식에서 가속기의 이론 또는 지정 조건 처리 능력을 나타냅니다. 카메라 디코딩, 이미지 복사, CPU 전처리, 메모리 대역폭, 모델 실행, 후처리와 ROS 2 통신이 합쳐진 지연을 자동으로 설명하지 않습니다.
또한 최고 모드의 짧은 벤치마크는 팬·히트싱크·하우징이 열을 머금은 뒤의 클록을 보여주지 않습니다. 로봇이 60분 순찰 후에도 제어 마감시간을 지키는지가 구매 사양의 핵심입니다.
| 지표 | 보여주는 것 | 단독으로 증명하지 못하는 것 |
|---|---|---|
| TOPS | 지정 연산의 계산 상한 | 전체 파이프라인 지연 |
| 초기 평균 지연 | 차가운 장치의 중심 성능 | 열 포화 뒤 꼬리 지연 |
| P95·P99 지연 | 느린 프레임의 마감 위험 | 안전한 행동 자체 |
| 클록·온도·전력 | 스로틀링 원인과 시점 | 센서·제어 통합의 정확성 |
보드·JetPack·전력 모드·냉각 구성을 먼저 고정한다
시험 보고서 첫 줄에는 모듈 SKU, 캐리어 보드, Jetson Linux·JetPack, CUDA·TensorRT, 커널, 모델 해시, 정밀도, 전력 모드, 팬 프로파일과 하우징을 적습니다. Jetson Thor r39.2 기능표처럼 제품군과 릴리스가 달라지면 지원 기능과 인터페이스도 달라지므로 명령과 기대값을 버전 없이 복사하면 안 됩니다.
Jetson Orin 계열의 한 예로 `sudo nvpmodel -q`에서 현재 모드를 확인하고, 지원 모드 ID와 최대 CPU·GPU·EMC 주파수를 해당 버전의 `/etc/nvpmodel.conf`와 공식 표에 맞춥니다. `jetson_clocks`로 잠깐 높인 결과와 현장 전력 모드의 결과는 별도 시험으로 남깁니다.
합성 추론 대신 실제 센서부터 행동 출력까지 부하를 재현한다
카메라 수와 해상도·프레임률, LiDAR 파싱, 타임스탬프 동기화, 전처리, 검출·VLA 추론, 후처리, 맵 업데이트, 로그 기록과 제어 메시지 발행을 모두 켭니다. 모델 엔진만 반복하면 CPU·메모리·I/O 경합과 프레임 드롭이 사라져 실제보다 좋은 결과가 나옵니다.
NVIDIA Jetson Test Plan은 전력 모드별 CPU·GPU·EMC 주파수를 부하 중 확인하고 `tegrastats`로 주파수·온도·전력·메모리를 관찰하는 절차를 제공합니다. 이를 로봇의 실제 프로세스별 타임스탬프와 합쳐야 병목이 어느 계층에서 시작됐는지 찾을 수 있습니다.
| 구간 | 반드시 켤 부하 | 기록할 값 |
|---|---|---|
| 센서 입력 | 실제 카메라·LiDAR·IMU | 프레임률·드롭·타임스탬프 |
| 전처리 | 리사이즈·정규화·복사 | CPU/GPU 시간·메모리 이동 |
| 추론 | 배포 엔진·실제 정밀도 | P50·P95·P99·처리량 |
| 후처리·제어 | 필터·계획·메시지 발행 | 끝단 지연·마감 초과 |
| 시스템 | 로그·네트워크·저장장치 | 온도·전력·클록·메모리 |
_-_top_view.jpg){kind=link}
열 포화 시험은 최악의 외기와 밀폐 조건에서 충분히 길게 돌린다
시험 시간은 임의의 10분이 아니라 온도와 클록이 평형에 도달하는 시점 또는 실제 임무 주기 중 더 긴 값으로 정합니다. 최악의 외기온, 직사광선, 먼지 필터, 막힌 흡기, 배터리 전압 범위와 다른 발열 부품을 포함해야 합니다.
NVIDIA 검증 계획의 열 알림 시험은 장시간 다중 부하로 온도를 올리고 trip point와 throttle alert를 확인합니다. 제품 검증에서는 경고 발생만 볼 것이 아니라, 경고 전후의 클록 하락·P99 상승·프레임 드롭·복구 시간을 초 단위로 기록합니다.
TensorRT 숫자는 워밍업·동시성·데이터 이동 조건과 함께 남긴다
TensorRT 11.2.1 벤치마킹 가이드를 사용할 때는 엔진, 입력 shape, 배치, 스트림 수, 정밀도, 워밍업과 측정 구간을 고정합니다. 호스트-디바이스 전송을 제외한 엔진 지연과 실제 애플리케이션 끝단 지연을 같은 값처럼 보고하면 안 됩니다.
처리량이 높아도 P99가 제어 주기를 넘으면 로봇은 간헐적으로 늦습니다. 시간대별 지연 분포를 온도·클록과 겹쳐 보고, 최초 5분과 마지막 안정 구간의 차이를 지속 성능 저하율로 계산합니다.
합격은 열 스로틀링 없음보다 임무 SLA 유지로 판정한다
열 스로틀링은 장치가 열 한계를 지키기 위해 하드웨어 클록을 낮추는 현상이고, 애플리케이션 rate limiting은 소프트웨어가 의도적으로 호출 빈도를 줄이는 정책입니다. 둘을 로그에서 구분해야 냉각 보강과 소프트웨어 최적화 중 무엇이 필요한지 결정할 수 있습니다.
합격표에는 열 포화 구간 P95·P99, 마감 초과율, 센서 드롭률, 최소 클록, 최대 온도, 평균·피크 전력, 메모리 여유와 재부팅·복구 여부를 넣습니다. NVIDIA 문서는 Jetson 방법의 예이며, 다른 보드도 동등한 전력·온도·클록·메모리 텔레메트리를 제공해야 같은 기준으로 비교할 수 있습니다.
자주 묻는 질문
로봇 컴퓨터는 TOPS가 높으면 무조건 빠른가요?
아닙니다. 모델 정밀도, 메모리 대역폭, 전처리·후처리, 센서 I/O, 전력 모드와 열 스로틀링에 따라 끝단 지연이 달라집니다. 실제 파이프라인의 지속 P95·P99를 측정해야 합니다.
열 지속 성능 시험은 몇 분 돌려야 하나요?
고정된 보편 시간은 없습니다. 온도와 클록이 평형에 도달하거나 실제 임무 주기를 모두 재현할 때까지, 둘 중 더 긴 조건으로 돌려야 합니다.
tegrastats만 기록하면 검증이 끝나나요?
아닙니다. tegrastats는 시스템 온도·전력·클록·메모리 텔레메트리를 제공하지만 센서부터 행동 출력까지의 지연, 드롭과 마감 초과는 애플리케이션 타임스탬프로 별도 측정해야 합니다.
확인한 공식 자료
- NVIDIA Jetson Thor Series 기능표 r39.2
- NVIDIA Jetson Platform Power and Performance r36.4.3
- NVIDIA Jetson Test Plan and Validation r36.4
- NVIDIA TensorRT 11.2.1 Benchmarking Guide
2026-08-07