AEGLOSLAB 엔비디아 기술 스택

제9부 로보틱스

9.4 Jetson 전력·성능 운영

9.4.1 이 장에서 배우는 것 / 선수 지식

9.1~9.3에서 Jetson 모듈·소프트웨어·배포를 봤다. 그런데 엣지의 천장은 전력과 열이다(8.1·9.1) — 로봇은 배터리·발열 한계 안에서 동작해야 한다. 이 장은 그 전력·성능 운영 — nvpmodel로 전력 모드 설정, jetson_clocks로 클럭 고정, 발열·throttling 관리, 통합 메모리(CPU-GPU 공유), 전력 vs 성능 트레이드오프 — 를 본다. 데이터센터의 DCGM(7.3)이 클러스터를 모니터하듯, 엣지에선 tegrastats/jtop으로.

핵심 통찰: Jetson 운영의 본질은 "전력·열 예산 안에서 성능을 극대화하는 것" 이다 — 무한정 성능을 못 낸다. nvpmodel이 전력 예산(어느 코어·최대 클럭)을 정하고, jetson_clocks가 그 천장에 클럭을 고정하며, 발열이 한계를 넘으면 throttling으로 성능이 떨어진다. 그리고 Jetson은 CPU·GPU가 메모리를 공유(통합 메모리)해 zero-copy 이점이 있으되 메모리 풀을 두고 경합한다.

배우는 것:

  • nvpmodel — 전력 모드(전력 예산·코어·클럭), 로봇 예산에 맞춰 선택.
  • jetson_clocks — 클럭을 최대로 고정(DVFS 끔), 지속·결정적 성능 vs 전력·열.
  • 발열·throttling — 온도 한계 초과 시 클럭 저하, 냉각(수동·능동)·환경·모니터.
  • 전력 vs 성능 — 핵심 트레이드오프, 드론(제약 큼) vs 전원 로봇.
  • 통합 메모리 — CPU-GPU 공유(zero-copy 이점·메모리 경합), 데이터센터 별도 HBM과 차이.
  • 모니터링 — tegrastats·jtop(GPU·CPU·DLA·전력·온도·메모리).

선수 지식: 8.1(전력·열 천장·TOPS/W·결정성)·9.1(모듈·전력 예산)·8.4(DLA 효율)·2.5(메모리 전송·zero-copy)·4.8(Grace 일관 메모리 — 유사)·7.3(DCGM 모니터 — 데이터센터판). DeepStream은 9.5. 환경은 Jetson.

정직: nvpmodel 모드·전력 수치·발열 특성은 모듈·세대·캐리어 의존이다 — 이 장은 전력 운영의 개념·도구·트레이드오프를 가르치고 구체 모드·수치는 "그 모듈 문서로 확인". 냉각 설계는 캐리어·환경 의존이고 안전·신뢰성에 직결.

9.4.2 nvpmodel — 전력 모드

nvpmodel은 Jetson의 전력 모드(전력 예산) 를 설정한다 — 어느 코어를 켜고 최대 클럭을 얼마로:

   nvpmodel: 미리 정의된 전력 모드(전력 예산) 중 선택
     각 모드: 활성 CPU 코어 수·CPU/GPU/DLA 최대 클럭·전력 상한
     예(개념, 모드명·수치 세대 의존):
       MAXN(또는 최대 모드): 모든 코어·최대 클럭 → 최고 성능·최대 전력/열
       저전력 모드(예 N W 캡): 코어·클럭 제한 → 낮은 전력·낮은 성능
   사용:
     sudo nvpmodel -m <모드번호>    # 모드 설정
     sudo nvpmodel -q              # 현재 모드 조회
   → 로봇의 전력·열 예산에 맞는 모드를 선택
  • 전력 예산 = 모드: 드론(엄격한 배터리·무게 제약)은 저전력 모드, 전원 있는 로봇은 고성능 모드. 모드가 천장을 정함(8.1).
  • 코어·클럭 제어: 모드가 활성 CPU 코어 수·CPU/GPU/DLA 최대 주파수를 정해 전력을 제한.
  • 재부팅 유지: 설정한 모드가 유지(확인). 앱 시작 시 의도한 모드 보장.

핵심: nvpmodel은 "이 로봇의 전력·열 예산에서 얼마나 쓸까" 를 정하는 다이얼이다 — 높은 모드는 성능↑·전력/열↑, 낮은 모드는 반대. 8.1의 "전력이 천장"을 운영으로 — 로봇 형상(드론 vs 전원 로봇)에 맞는 모드를 골라 전력 예산 안에서 동작.

9.4.3 jetson_clocks — 클럭 고정

기본적으로 Jetson은 DVFS(동적 전압·주파수 스케일링) 로 부하에 따라 클럭을 오르내린다(전력 절약). jetson_clocks는 클럭을 현재 nvpmodel의 최대로 고정한다:

   DVFS(기본): 부하에 따라 클럭 변동(저부하=저클럭 절전, 고부하=고클럭)
     → 전력 절약하나, 클럭 변동으로 지연이 변동(jitter)·peak 도달 지연
   jetson_clocks: 클럭을 'nvpmodel 천장의 최대'에 고정(DVFS 끔)
     sudo jetson_clocks            # 최대 고정
     sudo jetson_clocks --show     # 현재 클럭
   효과:
     · 지속·결정적 최대 성능(클럭 변동 없음 → 지연 일정, 8.1 결정성)
     · 대가: 최대 전력·열(절전 안 함)
   용도: 벤치마크·지속 고부하·결정적 지연이 필요한 안전 critical 작업
  • nvpmodel(천장) + jetson_clocks(고정): nvpmodel이 전력 예산·최대 클럭을 정하고, jetson_clocks가 그 안에서 클럭을 최대로 고정. 둘은 다른 역할 — 예산 vs 고정.
  • 결정성: 클럭이 고정되면 지연이 일정(jitter↓) — 실시간·결정적 작업(8.1·8.6)에 유리. DVFS의 클럭 변동은 지연 변동을 만든다.
  • 대가: 절전 안 함 → 최대 전력·열. 전력·열 여유가 있고 지속 성능·결정성이 필요할 때.

핵심: nvpmodel = 전력 예산(천장), jetson_clocks = 그 천장에 클럭 고정. DVFS는 절전하되 클럭 변동(jitter)이 있고, jetson_clocks는 결정적 최대 성능을 주되 전력·열을 다 쓴다. 결정적 지연·지속 부하면 jetson_clocks, 전력 절약이 우선이면 DVFS. 전력·열 예산을 보고 선택.

9.4.4 발열·throttling — 지속 성능의 적

전력을 쓰면 열이 난다 — 온도가 한계를 넘으면 throttling(클럭 저하)으로 SoC가 자기를 보호한다:

thermal throttling 온도 한계 초과 → SoC가 클럭을 자동으로 낮춤(자기 보호) → 성능↓ → '지속(sustained) 성능'이 떨어짐 — 짧게는 빠르나 오래 실행하면 throttle 원인·관리 냉각 부족: 수동(히트싱크)· 능동(팬) 냉각이 발열을 못 빼면 throttle 높은 환경 온도: 실외·밀폐· 고온 환경이면 더 빨리 throttle 높은 전력 모드 + 지속 부하: 열 발생↑ 대응 냉각 설계(히트싱크·팬·환기) — 캐리어·로봇 설계의 핵심 전력 모드 조정(throttle보다 낮은 모드로 안정적 지속 성능) 온도 모니터(tegrastats·jtop) → throttle 전에 대응
  • throttling이 지속 성능의 적: 벤치마크(짧은)는 빠른데 실제 로봇(지속 운영)에선 throttle로 느려질 수 있다 — 지속 성능을 봐야(피크 아님).
  • 냉각 설계: 수동(팬 없음, 조용·신뢰)·능동(팬, 발열 큼) — 로봇 환경·전력 모드에 맞춰. 캐리어 보드(9.1) 설계의 핵심.
  • 환경: 실외·밀폐·고온이면 더 빨리 throttle — 환경 온도를 고려한 설계.

핵심: 발열·throttling이 지속 성능을 정한다 — 전력을 쓰면 열이 나고, 못 빼면 throttle로 성능이 떨어진다. 피크가 아니라 지속 성능을 보고, 냉각 설계·전력 모드·온도 모니터로 throttle를 막거나 throttle보다 낮은 안정적 모드로. 8.1(전력·열 천장)의 운영 현실.

9.4.5 통합 메모리 — CPU·GPU 공유

Jetson은 데이터센터 GPU(별도 HBM, 1.9)와 달리 CPU·GPU가 물리 메모리를 공유한다(통합 메모리, Grace의 일관 메모리 4.8와 유사한 정신):

이점 주의 데이터센터: CPU 메모리(DRAM) + GPU 메모리(HBM) 분리 → PCIe 전송 (2.5) Jetson: CPU·GPU· DLA가 '같은 물리 메모리'를 공유(통합 메모리) zero-copy: CPU↔GPU 데이터를 복사 없이(PCIe 전송 불필요, 2.5) → 센서 데이터· 이미지를 CPU·GPU· DLA가 공유 → 지연· 대역 절약 메모리 풀이 '공유' → CPU + GPU + DLA + 시스템이 같은 풀을 경합 총 메모리가 한정 → OOM 주의(GPU 큰 모델 + CPU 앱이 합쳐 초과) 메모리 관리: 통합 메모리 API (zero-copy)로 효율적 공유
  • zero-copy 이점: CPU와 GPU가 같은 메모리라 데이터를 복사할 필요 없음(데이터센터의 H2D/D2H, 2.5가 없음) — 센서→GPU 추론이 효율적. 2.5의 전송 최적화 고민이 줄어든다.
  • 메모리 경합·OOM: 같은 풀을 공유하니 CPU 앱 + GPU 모델 + DLA + 시스템이 합쳐 총 메모리를 넘으면 OOM. 데이터센터처럼 GPU 메모리만 보면 안 되고 전체 풀을 봐야.
  • 메모리 관리: 통합 메모리 API로 zero-copy 버퍼를 써 복사를 피하되, 총 사용을 모니터.

핵심: 통합 메모리는 "CPU·GPU 복사를 없애는 이점"(zero-copy, 2.5 부담↓)이되 "메모리 풀을 공유해 경합·OOM" 이 주의점이다. 큰 모델 + CPU 앱이 합쳐 총 메모리를 넘지 않게, 전체 풀을 모니터(tegrastats). 데이터센터의 별도 HBM·PCIe 전송과 다른 엣지 메모리 모델 — Grace(4.8)의 일관 메모리와 정신이 닮았다.

9.4.6 워크스루 — 전력·성능 튜닝

   1) 전력 모드 설정(로봇 예산에 맞춰):
      sudo nvpmodel -q             # 현재 모드
      sudo nvpmodel -m <모드>      # 전력 예산 선택(드론=저, 전원로봇=고)
   2) 결정적 최대 성능(필요시):
      sudo jetson_clocks           # 클럭 고정(전력·열 여유 있을 때)
   3) 모니터(tegrastats/jtop):
      sudo tegrastats              # GPU·CPU·DLA·메모리·전력·온도 실시간
      jtop                         # 종합 GUI(커뮤니티, GPU/DLA/전력/온도/메모리/클럭)
   4) 발열 확인:
      jtop/tegrastats 온도 → throttle 여부, 지속 부하 시 온도 추이
      throttle면: 냉각 보강·전력 모드↓·환경 개선
   5) 메모리:
      tegrastats RAM → CPU+GPU+DLA 합산 사용, OOM 여유 확인
      zero-copy로 복사 절약(통합 메모리)
   6) 전력 측정:
      tegrastats/jtop 전력 → 배터리 예산 안인지(드론 비행 시간 등)
성능 부족 전력 모드↑·jetson_ clocks (단 전력·열 여유 확인) 전력·열 초과 전력 모드↓, DLA 오프로드(8.4, 효율), 냉각 지연 변동(jitter) jetson_clocks(클럭 고정, 결정성) OOM 통합 메모리 총 사용↓·모델 경량 (양자화 5.4) 지속 throttle 냉각·throttle보다 낮은 안정 모드

견해: 전력 모드(nvpmodel)로 예산을 정하고, 필요하면 jetson_clocks로 결정적 고정, tegrastats/jtop으로 전력·온도·메모리를 모니터하며 튜닝한다. 지속 성능(throttle)·배터리(전력)·결정성(jitter)·메모리(OOM)를 함께 보고, DLA 오프로드(8.4)로 효율을 극대화한다. 피크가 아니라 지속·실제 운영을 본다.

9.4.7 중간 점검 (체크포인트)

  • [ ] nvpmodel이 전력 모드(전력 예산·코어·클럭)를 정하고, 로봇 예산에 맞춰 선택함을 안다.
  • [ ] jetson_clocks가 클럭을 최대로 고정(결정적 성능 vs 전력·열)함과 nvpmodel과의 역할 차이를 안다.
  • [ ] 발열·throttling이 지속 성능을 정하고, 냉각·환경·모니터로 관리함을 안다.
  • [ ] 통합 메모리(CPU·GPU 공유)의 zero-copy 이점·메모리 경합/OOM 주의를 안다(2.5·4.8).
  • [ ] tegrastats/jtop으로 전력·온도·메모리·활용을 모니터함을 안다(7.3 엣지판).
  • [ ] 전력 vs 성능 트레이드오프를 로봇 형상(드론 vs 전원)으로 판단한다.

증상→의심: 벤치는 빠른데 지속 운영서 느림 → thermal throttling → 냉각·전력 모드·온도 모니터. 전력·열 초과(드론) → 높은 모드 → 낮은 모드·DLA 오프로드(8.4). 지연이 변동(jitter) → DVFS → jetson_clocks. OOM → 통합 메모리 총 사용 초과 → 경량(양자화)·총 풀 모니터. 성능 부족 → 낮은 전력 모드 → 높은 모드(전력·열 여유 시). 모니터 못 함 → tegrastats/jtop. 재부팅 후 모드 리셋 → 모드 유지 설정.

9.4.8 트레이드오프·대안

결정트레이드오프
높은 vs 낮은 전력 모드성능 vs 전력·열·배터리
jetson_clocks(고정) vs DVFS결정적·지속 성능 vs 절전·jitter
수동 vs 능동 냉각조용·신뢰·throttle 위험 vs 발열 제거·팬·소음
GPU vs DLA(추론)유연·전력↑ vs 효율(TOPS/W, 8.4)
통합 메모리 zero-copy vs 복사효율·경합 vs 단순

견해: 로봇 형상으로 전력 모드를 정한다 — 드론(제약 큼)은 저전력·효율(DLA 오프로드 8.4·양자화 5.4), 전원 로봇은 높은 모드. 결정적 지연이 필요하면 jetson_clocks, 절전이 우선이면 DVFS. 지속 부하는 냉각 설계가 핵심(throttle 방지). 통합 메모리 zero-copy로 복사를 줄이되 총 풀을 모니터(OOM). 모든 결정은 tegrastats/jtop 측정으로 — 피크가 아니라 지속·전력·열·메모리.

비엔비디아 정직: 전력·열·DVFS·throttling은 모든 엣지 SoC의 공통 제약(다른 임베디드도 전력 모드·throttle). Jetson의 강점은 nvpmodel·jetson_clocks·tegrastats·통합 메모리·DLA 효율의 통합 도구. 냉각·전력 설계는 임베디드 일반 공학. 구체 모드·수치는 모듈·세대 의존 — 그 모듈 데이터시트·열 설계 가이드로.

9.4.9 흔한 함정

  • 피크 성능만 본다. 벤치(짧은)는 빠른데 지속 운영서 throttle로 느려짐 → 지속 성능·냉각·온도 모니터.
  • 냉각 설계 경시. throttle로 지속 성능 붕괴 → 히트싱크·팬·환기를 전력 모드·환경에 맞춰.
  • 전력 모드 안 맞음. 드론에 높은 모드 → 전력·열 초과, 전원 로봇에 낮은 모드 → 성능 낭비.
  • DVFS jitter 무시. 결정적 지연이 필요한데 DVFS면 클럭 변동 jitter → jetson_clocks.
  • GPU 메모리만 본다. 통합 메모리라 CPU+GPU+DLA 합산 → 전체 풀로 OOM 판단.
  • 복사 낭비. 통합 메모리인데 복사하면 이점 못 누림 → zero-copy.
  • 모니터 안 함. 전력·온도·메모리를 안 보면 throttle·OOM·배터리 초과를 놓침 → tegrastats/jtop.
  • 모드·수치 단정. 모듈·세대 의존 — 데이터시트·열 가이드로.

9.4.10 연습문제

연습 1 (nvpmodel·jetson_clocks). nvpmodel과 jetson_clocks의 역할 차이를 설명하고, 결정적 지연이 필요한 안전 작업에 무엇을 쓰는지 답하라.

정답

역할 차이: nvpmodel = 전력 모드(전력 예산·천장) 를 정함 — 어느 CPU 코어를 켜고, CPU/GPU/DLA의 최대 클럭·전력 상한을 얼마로(미리 정의된 모드 중 선택). 로봇의 전력·열 예산에 맞춰 "얼마나 쓸까"를 정하는 다이얼. jetson_clocks = 클럭을 현재 nvpmodel 천장의 최대로 고정(DVFS 끔) — nvpmodel이 정한 예산 안에서 클럭을 변동 없이 최대로. 둘은 다른 역할: nvpmodel은 예산(천장), jetson_clocks는 그 천장에 고정. 기본 DVFS는 부하에 따라 클럭을 오르내려(절전) 클럭이 변동한다. 결정적 지연이 필요한 안전 작업: jetson_clocks(클럭 고정) — DVFS의 클럭 변동은 지연 변동(jitter) 을 만들어, 매 사이클 데드라인 보장(8.1·8.6 결정성)이 어렵다. jetson_clocks로 클럭을 고정하면 지연이 일정해 결정적·지속 최대 성능. 단 대가는 최대 전력·열(절전 안 함)이라 전력·열 여유가 있어야. 안전 critical·실시간(인지~제어 루프)은 결정성이 중요하므로 jetson_clocks + 적절한 nvpmodel(예산) + 냉각(throttle 방지). 절전이 우선인 비실시간 작업은 DVFS. 즉 nvpmodel로 예산 정하고, 결정적 작업은 jetson_clocks로 고정, 전력·열은 냉각으로 받침. throttle가 일어나면 고정도 무의미하므로 냉각이 전제.

연습 2 (throttling). 로봇이 벤치마크에선 빠른데 실제 운영 몇 분 후 느려진다. 원인과 진단·대응을 설명하라.

정답

원인: thermal throttling — 전력을 쓰면 열이 나는데, 지속 부하로 온도가 한계를 넘으면 SoC가 자기 보호를 위해 클럭을 자동으로 낮춘다 → 성능 저하. 벤치마크(짧은)는 온도가 오르기 전이라 빠르지만, 실제 운영(지속 부하) 은 몇 분 후 온도가 한계에 도달해 throttle → 느려짐. 즉 피크 성능 ≠ 지속 성능. 진단: tegrastats/jtop으로 온도·클럭 추이 모니터 — 시간이 지나며 온도가 한계에 닿고 클럭이 떨어지는지(throttle 신호), GPU/CPU 클럭이 nvpmodel 최대 밑으로 떨어지는지. 대응: ① 냉각 보강 — 히트싱크 추가·팬(능동)·환기 개선으로 발열을 빼서 온도를 한계 밑으로(캐리어·로봇 설계, 9.4.4). 수동 냉각이 부족하면 능동. ② 전력 모드↓(nvpmodel) — throttle가 일어나는 높은 모드보다 낮은 안정 모드로 — throttle로 변동하는 것보다 일관된 낮은 클럭이 지속 성능·결정성에 나을 수 있음. ③ 환경 — 실외·밀폐·고온이면 더 빨리 throttle → 환경 온도 고려, 환기. ④ DLA 오프로드(8.4) — 추론을 GPU 대신 DLA로 효율(전력·열↓). ⑤ 워크로드 경량(양자화 5.4). 핵심: 지속 성능을 봐야지 피크가 아니다 — throttle가 지속 성능을 정하므로, 냉각·전력 모드·온도 모니터로 throttle를 막거나 안정 모드로. 로봇 설계 시 지속 부하·환경 온도에서의 열을 설계(throttle 없이 목표 성능 유지). 8.1(전력·열 천장)의 운영 현실 — 피크 TOPS는 의미 적고 지속·열이 핵심.

연습 3 (통합 메모리). Jetson의 통합 메모리가 데이터센터 GPU와 어떻게 다르고, zero-copy 이점과 OOM 주의를 설명하라.

정답

차이: 데이터센터 GPU(1.9)는 CPU 메모리(DRAM)와 GPU 메모리(HBM)가 물리적으로 분리 — CPU↔GPU 데이터를 PCIe로 전송(H2D/D2H, 2.5)해야 함. Jetson은 CPU·GPU·DLA가 같은 물리 메모리를 공유(통합 메모리, Grace 4.8의 일관 메모리와 정신 유사). zero-copy 이점: CPU와 GPU가 같은 메모리라 데이터를 복사할 필요가 없다(PCIe 전송 불필요) — 센서 데이터·이미지를 CPU가 받아 GPU가 추론할 때 복사 없이 공유, 지연·대역 절약. 데이터센터의 2.5(전송 최적화·pinned·async) 고민이 크게 줄어듦 — 통합 메모리 API로 zero-copy 버퍼를 쓰면 됨. OOM 주의: 같은 메모리 풀을 CPU 앱 + GPU 모델 + DLA + 시스템이 공유·경합 — 데이터센터처럼 "GPU 메모리만" 보면 안 되고, 전체가 합쳐 총 메모리를 넘으면 OOM. 예: 큰 추론 모델(GPU) + 고부하 CPU 앱이 합쳐 총 RAM 초과 → OOM. 그래서 ① 전체 풀을 모니터(tegrastats RAM, CPU+GPU+DLA 합산), ② 모델 경량(양자화 5.4)·메모리 관리, ③ zero-copy로 복사 버퍼 중복 회피(복사하면 두 벌). 정리: 통합 메모리는 복사 없는 효율(zero-copy) 이되 공유 풀 경합·OOM이 대가 — 이점을 누리되(zero-copy) 총 사용을 관리(OOM). 엣지의 메모리 모델이 데이터센터(별도 HBM·PCIe)와 다름을 이해하고 운영. Grace(4.8)의 일관 메모리가 데이터센터로 이 정신을 가져온 것과 대비.

연습 4 (드론 vs 전원 로봇). 소형 드론과 전원 연결 산업 로봇의 Jetson 전력·성능 운영이 어떻게 달라야 하는지 설명하라.

정답

소형 드론(엄격한 전력·무게·열 제약): ① 저전력 nvpmodel — 배터리·비행 시간·페이로드 제약이 엄격해 전력 예산이 작음, 낮은 전력 모드로 전력·열 제한. ② 효율 우선 — DLA 오프로드(8.4, TOPS/W)·양자화(5.4)로 같은 인지를 적은 전력에. ③ 냉각 제약 — 무게·공간 때문에 큰 히트싱크·팬이 어려움 → 수동·소형 냉각, 전력 모드를 throttle 안 나게 보수적으로. ④ DVFS 활용 — 부하 낮을 때 절전(비행 시간↑). 단 결정적 제어는 그 부분만 jetson_clocks. ⑤ 무게 — 모듈·냉각이 경량이어야(9.1 모듈 선택도). 핵심: 전력·무게·열이 1순위, 효율·절전. 전원 연결 산업 로봇(전력 여유, 고정·전원): ① 높은 nvpmodel — 전원이 있어 전력 예산이 크고, 고성능 모드로 복잡 인지·다센서. ② jetson_clocks·결정성 — 전력·열 여유로 클럭 고정해 지속 최대 성능·결정적 지연(실시간 제어). ③ 능동 냉각 — 팬·큰 히트싱크 가능(무게·소음 덜 제약), throttle 방지로 지속 고성능. ④ 더 큰 모델·다센서. 핵심: 성능·결정성 우선, 전력·냉각 여유 활용. 차이 요약: 드론 = 저전력·효율·수동냉각·절전(전력/무게/열 천장), 전원 로봇 = 고성능·결정성·능동냉각·지속(성능 우선). 같은 Jetson·도구(nvpmodel·jetson_clocks·tegrastats)이되 로봇 형상의 제약(전력·무게·열·연속성)이 운영을 정한다 — 8.1(전력 천장)·9.1(모듈 선택)의 운영판. 둘 다 tegrastats/jtop으로 전력·온도·지속 성능 측정해 튜닝.

연습 5 (모니터·튜닝). Jetson 로봇의 전력·성능을 튜닝하는 모니터링·의사결정 워크플로를 설계하라.

정답

워크플로: ① 모니터(tegrastats/jtop) — GPU·CPU·DLA 활용률, 전력(배터리 예산), 온도(throttle), 메모리(통합 풀 OOM), 클럭을 실시간·지속 관찰(7.3 DCGM의 엣지판). 지속 부하에서의 추이를 봄(피크 아님). ② 목표 확인 — 필요 성능(인지 처리량·지연), 전력 예산(배터리·비행 시간), 열 한계(환경 온도·냉각). ③ 전력 모드(nvpmodel) — 목표 성능을 내는 최소 모드 선택(전력·열 절약), 또는 예산이 천장이면 그 안 최대 모드. ④ 결정성 필요시 jetson_clocks — 실시간·안전 작업의 지연 jitter를 없애려 클럭 고정(전력·열 여유 확인). ⑤ throttle 진단 — 지속 부하서 온도가 한계·클럭 저하면 throttle → 냉각 보강·전력 모드↓·환경 개선. ⑥ 효율 — 전력 초과면 DLA 오프로드(8.4)·양자화(5.4)·이기종 분업(8.5)으로 같은 작업을 적은 전력에. ⑦ 메모리 — 통합 풀 총 사용 모니터, OOM이면 경량·zero-copy. ⑧ 검증 — 지속 운영(실제 시간·환경)에서 성능·전력·온도가 목표 안인지(벤치 아닌 실운영). ⑨ 반복 — 한 가지 바꿔 재측정(전력 모드·냉각·모델). 의사결정: 성능 부족 → 모드↑/jetson_clocks(전력·열 여유 시); 전력·열 초과 → 모드↓·DLA·냉각; jitter → jetson_clocks; OOM → 경량. 핵심: tegrastats/jtop으로 전력·온도·메모리·지속 성능을 측정하고, 전력 모드(예산)·jetson_clocks(결정성)·냉각(throttle)·효율(DLA)을 튜닝 — 피크가 아니라 실 운영의 지속·전력·열·메모리를 목표 안에. 로봇 형상(드론 vs 전원)에 맞춰. 데이터센터의 측정 기반 튜닝(5.12·7.3)을 엣지 전력·열에 적용.

9.4.11 요약 · 다음 장

  • Jetson 운영의 본질은 전력·열 예산 안에서 성능을 극대화하는 것(8.1). nvpmodel이 전력 모드(예산·코어·클럭)를 정하고, jetson_clocks가 그 천장에 클럭을 고정(결정적 성능 vs 전력·열). 둘은 예산 vs 고정의 다른 역할.
  • 발열·throttling이 지속 성능을 정한다 — 온도 한계 초과 시 클럭 저하. 피크가 아니라 지속 성능을 보고, 냉각 설계·전력 모드·온도 모니터로 throttle를 관리.
  • 통합 메모리(CPU·GPU·DLA 공유)는 zero-copy 이점(복사 없음, 2.5 부담↓)이되 메모리 풀 경합·OOM 주의 — 전체 풀을 모니터(데이터센터 별도 HBM과 다름, Grace 4.8 유사).
  • tegrastats/jtop으로 전력·온도·메모리·활용을 모니터(7.3 엣지판)하며, 로봇 형상(드론 저전력·효율 vs 전원 로봇 고성능·결정성)으로 튜닝. DLA 오프로드(8.4)로 효율.
  • 정직: 모드·수치·발열은 모듈·세대·캐리어 의존(데이터시트·열 가이드), 전력·열·throttle는 엣지 공통 제약.

다음 장: 9.5 DeepStream — 비디오 분석 파이프라인. 전력·운영을 봤으니, Jetson의 대표 응용 — DeepStream으로 다중 카메라 비디오 분석(디코딩→추론→추적→출력)을 GPU 가속 파이프라인으로 구축하는 법을 본다. 스마트시티·산업 비전·로봇 인지의 비디오 AI.