AI Briefing

성능을 유지하며 ML GPU model server를 CPU server로 전환한 경험

·2023.07.13 16:19

torchserve thread 설정과 ipex pinning으로 CPU serving 성능을 4배 끌어올렸다.

GPU 자원이 한정된 상황에서 기존에 운영하던 비교적 작은 ML model server를 CPU serving으로 옮기면서도 서비스 품질을 유지한 사례다. 목표는 단순한 비용 절감이 아니라, 성능 하락 없이 GPU 서버를 CPU 서버로 전환해 연간 약 4억원의 비용 절감 효과를 내는 것이었다.

초기 비교에서는 CPU로 배포한 이미지 점수 측정 모델이 GPU 대비 rps는 10배 낮고 response time은 10배 느린 결과를 보였다. 추가 scale out은 고려하지 않았기 때문에, 대략 10~20배 수준의 성능 개선이 필요했다.

처음에는 TorchServe worker 수 증가로 처리량을 높이려 했지만, 오히려 성능이 떨어지는 현상이 나타났다. 원인은 torch thread 기본값이 physical core 수로 잡혀 있어, worker를 늘릴수록 logical thread 경쟁이 발생하고 GEMM 연산에서 front end bound가 생기기 때문이었다.

해결책은 두 단계였다.

  • worker 수를 늘리되, 각 worker의 torch thread를 pod의 CPU limit과 physical core 수에 맞게 조정했다.
  • 여기에 ipex_enable=true, cpu_launcher_enable=true를 적용해 thread를 socket 단위로 pinning했다.

그 결과 rps는 초기 대비 **4배 수준(약 7.9~8 rps)**까지 올라갔다. 다만 ipex는 nn inference에 특히 효과적이라, inference 뒤에 svr이 붙는 이미지 점수 측정기보다 순수 nn 모델인 음식 인식기에서 더 큰 개선(2.5 rps → 17.5 rps, 약 7배)을 확인했다.

latency 문제는 별도의 모델 경량화로 접근했다. 정확도가 중요한 서비스라 pruning은 제외했고, Knowledge Distillation(KD) 같은 방식으로 model 자체를 가볍게 만들어 CPU inference time을 줄이려 했다. 또한 torchserve 0.6.1 이상에서만 ipex 기반 multi-worker pinning이 제대로 동작한다는 버전 이슈도 확인해, 오래된 버전에서는 직접 코드를 뜯어봐야 했다.

이 요약은 원문 이해를 돕기 위한 큐레이션입니다. 저작권은 원저작자에게 있으며, 정확한 내용과 맥락은 원문을 확인하세요.

요약 오류, 출처 표기 문제, 삭제 요청은 문의 · 건의로 알려주세요.