Profiling ONNX Runtime Inference: Techniques and Practical Setup

ONNX Runtime 프로파일러와 CloudWatch 연동

모델 추론 프로파일링 가이드

1) ORT 프로파일러 활성화 (Operator-Level Timeline)

ONNX Runtime은 실행 중 발생하는 연산자(Operator)별 시작/종료 시점, 스레드, 메모리 사용 정보를 JSON trace로 기록할 수 있다.

이 파일은 Chrome Tracing 또는 Perfetto에서 바로 시각화할 수 있다.

코드 예시 (C/C++)

환경변수 기반 활성화 (대안)

• ORT_PROFILING_START_TIME=0

• ORT_PROFILE_FILE_PREFIX=profile_

출력

• profile_<pid>_<timestamp>.json

• Chrome → chrome://tracing → Load 로 시각화 가능

2) 요청 단위 상관관계를 위한 추가 메타데이터(주석/태그 활용)

여러 요청이 하나의 세션을 공유하는 환경에서는 trace가 뒤섞일 수 있으므로, 요청 단위 식별용 ID를 trace에 포함시키는 것이 유용하다.

예시 전략

• 요청마다 request_id(UUID 등)를 생성 후 thread-local에 저장

• Session 옵션에 태그 추가
• 예: AddSessionConfigEntry("session.run_tag", request_id)

• 후처리 시 trace 이벤트(ph":"B"/"E")에 주석 삽입

추천 메타데이터 구조

3) CloudWatch EMF 기반 저비용 성능 모니터링

원시 trace 파일(JSON)은 심층 디버깅에 적합하지만 운영 환경에서는 비용이 크다.

운영 지표는 CloudWatch Embedded Metrics Format(EMF) 로 기록하면 로그 요금만으로 시계열 지표를 운영할 수 있다.

EMF 예시 레코드

Logs Insights 쿼리 예시

상위 느린 연산자(top N)

특정 요청의 operator 성능 보기

4) CPU-only 환경에서의 주요 튜닝 포인트

CPU 기반 추론에서는 커널 선택, 스레드 구성, 메모리 풀 등이 성능에 큰 영향을 준다.

스레드 풀

• intra_op: 단일 연산자 내부 병렬화

• inter_op: 연산자 간 병렬화

• 환경 변수:
• ORT_NUM_THREADS
• OMP_NUM_THREADS

• *코어 수가 적은 환경(1~2코어)**에서는 과도한 스레드가 오히려 컨텍스트 스위칭 오버헤드를 유발할 수 있다.

Arena Allocator

• 환경 변수 ORT_DISABLE_ARENA=1 로 비활성화 후 비교

• 짧은 요청 기반 workload는 Arena가 오히려 불리할 수도 있음

I/O Binding

• 입력/출력 텐서를 미리 바인딩해 메모리 복사 감소

• 반복 추론 환경에서 효과적

세션 재사용

• Session 초기화 비용은 크므로 재사용 권장

• 워밍업(warm-up) 1~2회 수행

동적 축 최소화

• 가능한 고정 입력 길이(패딩 등)로 모델 구성 시 커널 최적화가 더 잘 적용됨

5) 운영을 위한 전략적 조언

샘플링 기반 trace 수집

• 전체 요청에서 trace를 수집하면 I/O 부담이 매우 커짐

• 1~5%만 활성화하거나 지연 SLO 초과 시 동적 활성화

보존 주기

• 원시 trace(JSON): S3 + Intelligent-Tiering

• EMF 로그: 30~90일 보존으로 시작

초기 대시보드 구성

• 연산자별 p95 지연

• 메모리 피크 히스토그램

• 요청당 operator 개수

• 모델별 추론 시간 추이

6) 체크리스트