소속: 4by4 Inc. · Pixell Lab 역할: ML Engineer 기간: 2023.06 – 2023.10 산업 도메인: 미디어 AI SaaS (Video Enhancement)


Situation

4by4는 AI 리서처만으로 구성된 조직에서 2년간 연구를 진행한 끝에 상용화 가능성을 가진 Video Enhancement 모델 “SharpClear”(Denoising + Sharpening)를 도출했다.

당시 이 모델은 PyTorch 기반으로 3090×8 서버에서 3~4 fps 수준의 추론 속도를 가지고 있었으며, 고객이 FTP로 비디오를 보내면 리서처가 수동으로 PyTorch 추론을 돌려 결과물을 생성하고 다시 FTP로 전달하는 방식으로 운영되고 있었다.

목표 고객은 교육 사업자였다. 인터넷 강의의 화질을 개선하는 서비스를 제공하는 것이 목표였으며, 교육 사업자들은 기존에 사용하는 인코더와 비슷한 속도를 기대했다. 따라서 FHD 30fps 실시간 처리 속도가 타겟 성능으로 설정되었다. 자동화된 인프라는 아무것도 준비되어 있지 않은 상태에서, 사람 없이 자동으로 동작하는 추론 파이프라인을 처음부터 구축해야 했다.


Task

  • 팀 구성
    • Sales & PM ×1: BM 기획, 프로젝트 관리
    • DL Researcher ×1: Model 개발
    • SW Engineer ×1: Frontend, Backend, Inference Pipeline(Main)
    • ML Engineer(본인) ×1: Inference Engine, Docker
  • 담당 영역
    • Inference Engine 개발
    • Docker 기반 배포 환경 구성
  • 협업
    • AI 리서처 → (모델/Weight 전달) → 본인(최적화 및 엔진 개발) → SW Engineer(서비스 통합)
  • 목표
    • SharpClear 모델 기준 FHD 30fps 실시간 처리 달성.

Action

기술 스택 & 시스템 구성

분류기술
LanguagePython
InferenceTensorRT (via ONNX Runtime)
DeploymentDocker, GHCR
InfraOn-Premise, Kakao Cloud

아키텍처

메인 프로세스(작업 관리)와 서브 프로세스 8개(추론)로 구성된 Multi GPU 구조. 서브 프로세스가 ONNX Runtime의 TensorRT Execution Provider를 통해 추론을 수행하는 형태였다.

핵심 구현 사례

1. Inference Processor Interface 및 GPU/NPU 구현

문제 Nvidia GPU와 Furiosa NPU 두 가지 디바이스에서 모두 추론을 지원해야 했다.

구현 Inference Processor Interface를 정의하고, 이를 상속하여 Nvidia GPU(TensorRT)와 Furiosa NPU(Furiosa SDK) 각각에 대한 구현체를 개발했다. 이 Interface 위에 Inference Engine을 구현하여, 디바이스에 관계없이 동일한 인터페이스로 추론을 수행할 수 있도록 설계했다.

2. TensorRT 적용을 통한 추론 속도 최적화

문제 PyTorch 기반 SharpClear 모델의 추론 속도가 3090×8 서버에서 3~4 fps 수준으로, FHD 30fps 목표에 크게 미달했다.

구현 PyTorch → ONNX → TensorRT 변환을 적용하여 추론 속도를 최적화했다. ONNX Runtime의 TensorRT Execution Provider를 사용하여 FP16 추론을 활성화하고, IO Binding을 통해 GPU 메모리에서 직접 입출력을 수행하는 엔진을 구현했다. 모델 자체의 변환 이슈는 없었으나, ONNX Runtime · TensorRT · CUDA 간 버전 호환성을 맞추는 것이 까다로웠다. 이를 해결하기 위해 Docker를 도입하여 런타임 환경을 고정했으며, 이 Docker 이미지가 이후 On-Premise 및 Kakao Cloud 배포의 기반이 되었다. SharpClear(DPIR 기반) 모델 기준 PyTorch 대비 770% 추론 속도 향상을 달성했다.

3. Memory Pooling을 통한 전/후처리 최적화

문제 추론 전후의 전/후처리 단계에서 transpose 연산 시 새로운 메모리가 반복적으로 할당되어 latency가 발생했다.

구현 transpose 시 생성되는 임시 메모리 할당을 제거하고, 고정 크기 버퍼 풀을 사전 할당한 뒤 해당 버퍼에 직접 복사하는 방식으로 전환했다. 입력 데이터와 출력 데이터, 그리고 ORT IO 바인딩용 버퍼를 엔진 초기화 시점에 한 번만 할당하고 재사용하는 구조로 설계했다. 이를 통해 전/후처리 시간을 **56ms → 21ms (64% 개선)로 단축했다.

4. 추론 파이프라인 구조 분석 및 개선 제안

구현 추론 파이프라인을 분석했고, Disk I/O 병목 이슈를 발견했다. 이 이슈를 회피할수 있는 설계를 하면, 얼마나 효과가 있을지 확인하기 위해서 gRPC 기반 Multi-Processing Inference Pipeline 구조를 구현하고 성능을 분석했다. 분석 결과를 기반으로 Inference Pipeline에 Multi-Processing 구조 도입을 제안했으며, .


Result

기술 성과

  • GPU/NPU 모두 사용 가능한 Inference Processor Interface 구현
  • TensorRT 적용으로 PyTorch 대비 추론 속도 770% 향상
  • Memory Pooling으로 전/후처리 latency 64% 개선 (56ms → 21ms)
  • GPU Throughput 30fps 달성 (On-Premise)
  • Disk I/O 병목 이슈 분석 및 구조적 개선 방향 도출

비즈니스 임팩트

  • CES 2024 혁신상 수상

회고

잘한 점

비즈니스 목표였던 FHD 30fps 실시간 처리를 달성했다. PyTorch 3~4 fps에서 출발하여 TensorRT 변환과 Memory Pooling이라는 두 가지 최적화만으로 목표 성능에 도달한 것은 핵심 병목을 정확히 식별하고 집중 투자한 결과였다.

아쉬운 점 / 다시 한다면

Disk I/O 병목을 확인했지만 alpha 단계에서는 해결하지 못했으며, 이는 v1.0에서 본격적으로 해결하게 되었다.

배운 점

프로토타입에서 프로덕션으로 가는 과정에서, 모델 추론 속도만 높이는 것이 아니라 전체 파이프라인의 병목을 식별하고 해결하는 것이 핵심이라는 것을 배웠다. TensorRT로 실제 추론 속도가 매우 빨라지니, 그 이후에는 별로 중요하게 생각하지 않았던 전/후처리의 메모리 할당이 또 다른 병목으로 자리잡고 있었다. 성능 최적화는 모든 구간을 고려해야 하는 일이라는 교훈을 얻었다.