로봇 개발에서 온보드 컴퓨터는 한 번 정하면 바꾸기 어려운 부품입니다. 캐리어 보드, 전원, 냉각, 카메라 배선이 모두 그 모듈에 맞춰 설계되기 때문입니다. 그런데 모듈 비교는 흔히 가장 큰 숫자 하나, 즉 TOPS나 TFLOPS로만 이루어집니다. 이 글은 NVIDIA Jetson Orin, Jetson Thor, IGX Thor의 공식 사양을 놓고, 성능 숫자 외에 확인해야 할 일곱 가지 기준과 그중 계산으로 확인할 수 있는 항목을 정리합니다.
모델이 메모리에 들어가는지와 대역폭에 따른 추론 속도 상한은 온디바이스 VLA 메모리·대역폭 산정에서 따로 다뤘으므로, 여기서는 그 계산을 끝낸 뒤 모듈을 고르는 단계에 집중합니다.
비교 대상 모듈의 공식 사양
| 항목 | Orin NX 16GB | AGX Orin 64GB | Jetson T4000 | Jetson T5000 |
|---|---|---|---|---|
| AI 성능 표기 | 157 TOPS (희소 INT8) | 275 TOPS (희소 INT8) | 1,200 TFLOPS (희소 FP4) | 2,070 TFLOPS (희소 FP4) |
| GPU | Ampere 1,024코어 | Ampere 2,048코어 | Blackwell 1,536코어 | Blackwell 2,560코어 |
| CPU | Cortex-A78AE 8코어 | Cortex-A78AE 12코어 | Neoverse-V3AE 12코어 | Neoverse-V3AE 14코어 |
| 메모리 | 16GB LPDDR5 | 64GB LPDDR5 | 64GB LPDDR5X | 128GB LPDDR5X |
| 메모리 대역폭 | 102.4GB/s | 204.8GB/s | 273GB/s | 273GB/s |
| 전력 범위 | 10~40W | 15~60W | 40~70W | 40~130W |
| 고속 네트워크 | — | — | 25GbE 3개 | 25GbE 4개 |
출처: NVIDIA Jetson Orin, NVIDIA Jetson Thor. Jetson Orin 페이지의 표는 열 정렬이 일부 어긋나 있으므로 설계 확정 전에는 각 모듈의 데이터시트로 다시 확인하는 것이 좋습니다. Jetson Thor 페이지는 최고 성능 값이 130W에서 측정됐다고 주석을 답니다.
산업용 버전인 IGX Thor는 별도 표 대신 아래 기능 안전 기준에서 다룹니다.
기준 1: 성능 표기의 정밀도를 맞춘다
표에서 가장 먼저 눈에 띄는 숫자는 성능이지만, Orin은 희소 INT8 TOPS, Thor는 희소 FP4 TFLOPS로 표기됩니다. 정밀도가 다르면 같은 연산 장치에서도 숫자가 크게 달라지므로, 두 값을 나눠 “몇 배 빠르다"고 계산하는 것은 의미가 없습니다.
실제로 확인할 것은 배포할 모델을 어떤 정밀도로 돌릴 것인가입니다. FP4로 양자화할 계획이 없다면 FP4 성능 값은 참고만 하고, 사용할 정밀도에서의 벤치마크나 직접 측정값으로 비교해야 합니다.
기준 2: 메모리 용량과 대역폭은 따로 본다
Jetson Thor 사양에서 T4000과 T5000은 대역폭이 273GB/s로 같고 용량만 64GB와 128GB로 다릅니다. 즉 모델이 64GB 안에 들어간다면 T5000으로 바꿔도 대역폭에 묶인 추론 속도는 크게 달라지지 않을 수 있습니다. 반대로 Orin NX 16GB에서 AGX Orin 64GB로 가면 Jetson Orin 사양 기준 대역폭이 102.4GB/s에서 204.8GB/s로 두 배가 되어, 용량과 속도가 함께 바뀝니다.
기준 3: 전력과 열은 배터리 계산으로 바꾼다
모듈의 전력 범위는 배터리 구동 로봇에서 곧 구동 시간입니다. 모듈 소비 전력을 , 교대 시간을 라 하면 연산에만 쓰이는 에너지는 다음과 같습니다.
Jetson Thor 사양의 T5000 최대 130W로 4시간을 돌리면 520Wh, T4000 최대 70W라면 280Wh입니다. AGX Orin 최대 60W라면 240Wh입니다. 이 값을 로봇 배터리 용량과 나란히 놓으면 연산이 구동 시간을 얼마나 줄이는지 바로 보입니다. 실제 소비 전력은 전력 모드와 부하에 따라 최대값보다 낮을 수 있으므로, 운용 모드에서 측정한 값으로 바꿔 넣는 것이 정확합니다.
소비한 전력은 거의 모두 열이 되므로 같은 값이 냉각 설계의 기준이 됩니다. 밀폐된 몸체 안에 들어가는 휴머노이드라면 최대 전력 모드를 계속 유지할 수 있는지 열 시험으로 확인해야 합니다.
기준 4: 제어 주기에서 지연 예산을 거꾸로 구한다
모듈이 감당해야 할 지연은 로봇의 제어 주기에서 나옵니다. 주기 로 명령을 내야 한다면 한 주기에 쓸 수 있는 시간은 입니다. 200Hz 제어라면 5ms, 30Hz 카메라라면 약 33ms입니다.
Figure Helix 구조 정리에서 본 것처럼 큰 모델은 느린 주기로, 작은 정책은 빠른 주기로 나눠 돌리는 경우가 많습니다. 이 경우 모듈 선택은 “가장 빠른 계층이 지연 예산 안에 들어가는가"와 “느린 계층과 빠른 계층을 한 칩에서 동시에 돌릴 수 있는가"를 함께 따지는 문제가 됩니다. Jetson Thor는 GPU를 여러 인스턴스로 나누는 MIG(T5000 10 TPC, T4000 6 TPC)를 지원한다고 공식 페이지에 적혀 있어, 계층별로 GPU 자원을 나누는 설계를 검토할 수 있습니다.
기준 5: 센서와 네트워크 입출력을 먼저 센다
휴머노이드는 머리·손목·손바닥 카메라에 라이다, IMU, 촉각 센서까지 붙는 경우가 많아 입력 포트가 먼저 부족해질 수 있습니다. Jetson Thor 페이지는 25GbE 포트 수(T5000 4개, T4000 3개)와 함께 MIPI CSI-2, Holoscan Sensor Bridge를 통한 다중 카메라 연결을 소개합니다. 카메라 수와 인터페이스 종류(MIPI, GMSL, 이더넷)를 먼저 정리하고, 모듈이 아니라 캐리어 보드에서 실제로 몇 개가 나오는지 확인해야 합니다.
기준 6: 기능 안전이 필요한지 먼저 정한다
사람 곁에서 일하는 로봇을 제품으로 인증하려면 기능 안전이 문제가 됩니다. NVIDIA 기술 블로그는 IGX Thor를 다음과 같이 설명합니다.
- ISO 26262와 IEC 61508을 따르며 ASIL D/SC3와 ASIL/SIL 2를 목표로 한다고 표현합니다. 인증을 받았다는 표현은 아닙니다.
- 안전 영역과 비안전 영역을 하드웨어로 분리하는 독립 안전 프로세서(Functional Safety Island)를 둡니다.
- IGX T5000은 DRAM ECC를 모두 켠 상태에서도 Jetson T5000과 같은 성능을 낸다고 밝힙니다.
따라서 기능 안전이 필요한 제품이라면, 모듈이 지원하는 범위와 시스템 전체가 받아야 할 인증 범위를 구분해 인증 기관과 먼저 협의해야 합니다.
기준 7: 소프트웨어 스택과 공급 기간
같은 블로그에 따르면 IGX 플랫폼은 하드웨어를 최대 10년 지원하고, 버전을 고정한 프레임워크를 10년간 유지하는 LTS 브랜치를 제공합니다. 양산 로봇은 수년간 같은 보드를 생산해야 하므로, 개발 키트 단계에서 이 기간을 확인해 두면 나중에 다시 설계하는 일을 줄일 수 있습니다. 로봇 소프트웨어 스택(Isaac, GR00T, Holoscan)과 학습·시뮬레이션 쪽 컴퓨터의 관계는 NVIDIA 3-컴퓨터 구조에서 정리했습니다.
후보 모듈을 같은 조건으로 계산해 보기
기준 3과 4는 몇 줄짜리 스크립트로 후보 모듈을 한꺼번에 비교할 수 있습니다. 아래 예시의 전력 값은 Jetson Thor·Jetson Orin 페이지의 최대값이고, 배터리 용량·교대 시간·추론 시간은 설명을 위한 가정이므로 자신의 측정값으로 바꿔 넣어야 합니다.
# 후보 모듈별 연산 에너지와 제어 주기 여유를 비교한다.
modules = { # 최대 전력(W): 공식 페이지 값
"Orin NX 16GB": 40,
"AGX Orin 64GB": 60,
"Jetson T4000": 70,
"Jetson T5000": 130,
}
battery_wh = 2000 # 가정: 로봇 배터리 용량
shift_h = 4 # 가정: 교대 시간
control_hz = 200 # 가장 빠른 제어 계층의 주기
infer_ms = {"Orin NX 16GB": 6.0, "AGX Orin 64GB": 3.5, # 가정: 측정한 정책 추론 시간
"Jetson T4000": 2.0, "Jetson T5000": 1.5}
budget_ms = 1000 / control_hz
for name, watt in modules.items():
e = watt * shift_h
share = e / battery_wh
slack = budget_ms - infer_ms[name]
print(f"{name:14s} 연산 {e:5.0f}Wh (배터리의 {share:4.0%}) | 주기 {budget_ms:.1f}ms, 여유 {slack:+.1f}ms")
여유가 음수로 나오는 모듈은 그 정책을 해당 주기로 돌릴 수 없다는 뜻입니다. 이때는 모듈을 바꾸거나, 정책을 더 작게 만들거나, 제어 주기를 낮추는 세 가지 선택지를 비교하면 됩니다.
일곱 가지 기준을 한 표로
| 기준 | 확인 방법 | 계산 가능 여부 |
|---|---|---|
| 1. 성능 정밀도 | 배포 정밀도에서의 벤치마크 | 정밀도가 같을 때만 비교 |
| 2. 메모리 용량·대역폭 | 가중치·캐시·여유분 합산 | 가능 (VLA 산정 글 참고) |
| 3. 전력·열 | 와 배터리 용량 비교 | 가능 |
| 4. 지연 예산 | 과 계층별 추론 시간 비교 | 가능 (측정값 필요) |
| 5. 센서·네트워크 | 카메라·포트 목록과 캐리어 보드 대조 | 목록 대조 |
| 6. 기능 안전 | 목표 등급과 인증 범위 구분 | 인증 기관 협의 |
| 7. 소프트웨어·공급 기간 | 지원 연수와 제품 수명 비교 | 목록 대조 |
어떤 모델을 올릴지 아직 정하지 못했다면 오픈소스 로봇 정책 모델 비교에서 모델별 필요 VRAM을 먼저 확인한 뒤 이 표로 돌아오면 됩니다.