다음은 TTS/트랜스포머 계열 모델의 CPU 추론에서 ONNX Runtime(ORT) CPU EP vs OpenVINO EP를 고르는 빠른 기준과, 바로 돌려볼 “첫 번째 튜닝 노브” 요약이다.

언제 ORT를 고를까

• 이식성/패키징: 단일 바이너리·심플한 의존성, 컨테이너·서버리스(특히 AWS Lambda)에서 유리하다.

• Arm/Graviton/라즈베리: 비‑x86 환경 지원이 깔끔하다.

• ONNX 워크플로우 단순화: 모델 변환→로드까지 일관되며, EP 전환이 쉽다.

• 콜드 스타트 민감: 초기 컴파일 비용이 작아 첫 요청 지연을 줄이기 좋다.

언제 OpenVINO를 고를까 (x86_64 Intel 기준)

• 지속 고부하(steady‑state) 처리량: 그래프/커널 최적화, 스트림·스레드 핀닝으로 TPS 극대화가 쉽다.

• CPU 캐시·NUMA 활용: 배치가 작아도 장시간 워커가 도는 환경에서 성능이 잘 나온다.

• 모델 캐싱: 최초 컴파일 후 IR/캐시 재사용으로 장기 서비스에 유리하다.

핵심 트레이드오프 한눈에

• 첫 요청 대기(compile/create): CPU EP유리 ↔ OpenVINO는 캐시 전제 시 유리

• 지속 처리량: OpenVINO(핀닝/스트림 튜닝) > CPU EP(간편)

• 메모리 풋프린트: CPU EP가 작게 나오는 편 ↔ OpenVINO는 캐시·옵티 artifact로 커질 수 있다

• 패키징/서버리스 제약: CPU EP유리 ↔ OpenVINO는 런타임 구성 요소가 더 큼

• 아키텍처 지원: CPU EP광범위 ↔ OpenVINO는 Intel x86에서 베스트

먼저 돌려볼 “노브(설정)” — CPU EP

1. 스레드: intra_op_num_threads = <물리코어> → 그다음 inter_op_num_threads = 1 또는 2

2. 스케줄러: OpenMP vs default 스레딩 비교, OMP_NUM_THREADS, OMP_WAIT_POLICY=PASSIVE 시험

3. 메모리/그래프: enable_mem_pattern=1, graph_optimization_level=ORT_ENABLE_ALL

4. 동시성: 다수 세션 대신 단일 세션 + 다중 런 요청으로 잠금 경합 확인

5. 양자화/레이아웃: Q8/INT8 모델이면 EP 기본 연산 커버리지 확인(Unsupported op fallback 체크)

먼저 돌려볼 “노브(설정)” — OpenVINO (CPU)

1. 스레드 핀닝: CPU_BIND_THREAD=YES, AFFINITY=CORE, CPU_THREADS=<물리코어>

2. 스트림 수: CPU_THROUGHPUT_STREAMS=1~코어수/2 범위 스윕(짧은 발화는 적게, 긴 발화는 더)

3. 메모리 캐시: 모델 컴파일 캐시 활성화(디스크 캐시 경로 지정)로 재기동/배포 시 재사용

4. 정밀도: FP32 → BF16 전환 가능 시 시도(품질 영향 없는지 샘플 청취)

5. 입출력 레이아웃: NCHW/NHWC 고정 및 리샘플 비용 제거

TTS/트랜스포머 워크로드 팁

• 짧고 잦은 호출(대화형/스트리밍 초저지연): CPU EP로 시작 → 콜드스타트·패키징 이점 극대화.

• 길고 무거운 배치 처리(오디오 대량 생성/오프라인 파이프라인): OpenVINO로 전환해 스테디 처리량 최적화.

• Lambda/서버리스: 코드/레이어 사이즈·SnapStart 호환성 고려하면 CPU EP가 관리가 쉽다.

• EC2/온프렘 Intel x86: 장기 워커 + 코어 핀닝 + 스트림 튜닝으로 OpenVINO가 보통 더 빠르다.

미니 체크리스트

• 배포 타깃이 Intel x86 장기 서버인가? → OpenVINO부터.

• Arm/Graviton/서버리스인가? → CPU EP부터.

• 첫 응답 지연이 KPI인가? → CPU EP.

• 최대 TPS/코스트 절감이 KPI인가? → OpenVINO(+핀닝/스트림/캐시).