DAN24 2일차 비전 AI & 모델 서빙 위주 참여 후기

참여 계기

최근 개발하면서 여러가지 기술적 어려움과 GPU 모델 서빙에 대해 많은 고민을 하고 있었는데, DAN24에서 비전 AI 관련 세션 및 모델 서빙에 대해 유익할 것 같은 세션이 열리는 것 같아 참여 신청을 했습니다.

부스 투어

그냥 세션만 진행하는 줄 알았는데 다양한 부스와 이벤트가 진행되어서 좋았습니다.

흥미가 간 곳 중 하나는 네이버 지도의 로드뷰 서비스 였습니다. 기존에는 일정 간격으로 차량에서 찍은 사진을 볼 수 있어서 불편한 점이 많다고 생각했습니다. 그런데 새로운 기술은 카메라 및 라이다 데이터 등을 사용하여 3D Mesh로 공간을 복원한다고 합니다. 이렇게 하면 마치 자동차로 주행하듯이 주변 건물을 살필 수 있어서 특정 장소를 파악하기 매우 용이할 것 같았습니다.

NeRF, 3DGS를 이용하면 렌더링 비용이 너무 많이 필요하다는 문제가 있는데, 이렇게 3D Mesh로 3D scene을 렌더링한다면 모바일에서도 충분히 가능할 것 같아 매우 유용할 것 같습니다.

그리고 ZUMP라는 메타버스 서비스도 흥미로웠습니다. 웹 기반이라 게더타운처럼 누구나 접속할 수 있을 것 같고, 영상에서는 수십명의 동시접속도 감당할 수 있는 것 같았습니다.

스튜디오에서는 개발된 기능은 물론 naver에서 제공하는 API로 직접 javascript 코드 개발이 가능하다고 합니다. (babylon.js와 유사한 문법)

화면 공유기능 각종 이모션도 있는 것으로 보아 3D 게더타운의 역할을 할 수 있지 않을까 싶네요. 기대됩니다.

세션

당신의 Python 모델이 이븐하게 추론하지 못하는 이유 [CPU 추론/모델서빙 Python 딥다이브]

세션 정보 및 자료 링크

저는 무거운 생성 모델 위주로 다루다보니, ms 단위 지연시간이 중요한 모델에 대해서는 잘 알지 못합니다.

네이버에서 사용하는 추천 시스템은 100ms 이내로 응답해야하며, 또한 비용 문제로 CPU 환경에서 추론해야한다고 하는데요. 이 때 모델의 추론 시간을 최대한 줄이기 위해 Python 딥다이브가 필요하다고 합니다.

요약하자면 Python의 최적화를 위해서는 다음의 것들을 고려해야 한다고 합니다.

저수준 연산

• 요약
  • pandas 대신 numpy를 사용
  • numpy 중에서도 저수준 API 사용

python에서 사용하는 데이터는 저수준에 저장되어 있지만, 일반적으로 python에서는 PyObject 객체를 통해 데이터 주소만 참조하면서 데이터 처리 및 연산을 수행합니다. 하지만 PyObject는 원시 데이터에 비해 매우 무겁고, 고수준에서 데이터를 참조할 경우 GIL(Global Interpreter Lock)에 의해 연산이 느릴 수 밖에 없습니다.

numpy, pytorch와 같은 라이브러리는 저수준 데이터에 직접 접근하여 연산하는 CPython API를 지원하기 때문에 이를 적극 이용하면 C, C++ 등으로 포팅하지 않아도 충분한 성능 개선을 이룰 수 있다고 합니다.

반면 pandas는 사용자의 편의성을 위하여 PyObject로 객체를 다루기 때문에 연산 속도가 느릴 수 밖에 없습니다. 때문에 pandas 연산을 numpy로 바꾸는 것 만으로도 90% 이상 상당한 성능 최적화를 이룰 수 있습니다.

또한 같은 numpy여도 내부적으로 저수준 API를 호출하는 고수준 API를 사용하면 결국 PyObject를 다루기 때문에 연산 효율이 감소합니다. 때문에 각 API가 어떻게 동작하는지 명확히 이해하고 사용해야 할 것 같습니다.

Compiled Python

mypy[mypyc]와 같은 라이브러리는 파이썬 문법에 타입 힌트를 강제하여, 아예 C처럼 바이너리로 컴파일을 한 뒤 실행할 수 있게 합니다.

이 경우 Interpreter를 거치지 않고 실행하기 때문에 성능 향상을 기대할 수 있습니다. 그러나 강사분에 말에 의하면 numpy 등의 저수준 연산으로 충분히 최적화 될 경우 컴파일로 인한 성능 향상은 미미하다고 합니다.

즉 컴파일에 의존하는 것 보다는 Python에 딥다이브하여 코드를 최적화하는 것이 더 중요한 것 같습니다. intel-extension-for-pytorch)

Optimized ML Framework

pytorch와 같은 ML Framework를 최적화하는 익스텐션 개념의 라이브러리를 활용하여 최적화를 할 수 있습니다.

대표적으로 intel의 IPEX(intel-extension-for-pytorch)는 operation fusion을 통해 pytorch의 CPU 연산을 최적화하는 라이브러리입니다.

operation fusion이란, 행렬을 더한 뒤 곱하는 연산이 있다고 했을 때

기존

배열 접근 및 순회 -> 덧셈 연산 수행 -> 결과 반환 -> 결과 접근 및 순회 -> 곱셈 연산 수행 -> 결과 반환

operation fusion

배열 접근 및 순회 -> 덧셈과 곱셈 연산을 동시에 수행 -> 결과 반환

이렇게 여러번에 걸쳐 이루어지는 최소 연산자 연산을 한번의 연산으로 수행할 수 있도록 최적화하는 기법입니다.

pytorch 1.X 버전까지는 직접 적용해야 했지만, pytorch 2.X 버전부터는 CPU 연산에 자동 적용되어 pytorch 버전 업그레이드 만으로 CPU 추론에서는 큰 개선이 된다고 합니다.

그리고 강연에서 다루지 못했지만, 이렇게 ML framework를 최적화하는 다양한 라이브러리가 존재하니 task에 맞게 찾아보는 것이 좋을 것 같습니다.

어? GPU 그거 어떻게 쓰는건가요? : AI 서빙 헤딩팟 실전 노하우 (feat. AI 이어북)

세션 정보 및 자료 링크

SNOW에서 무거운 이미지 생성 모델을 서빙하면서 겪은 내용들을 공유한 세션입니다.

사실 글로 적는 것 보다는 직접 자료를 보는게 훨씬 유용할 것 같은 세션이어서 자세히 적지는 않으려고 합니다. 위 링크에서 자료를 받으실 수 있습니다.

로드 밸런싱 문제

일반적인 웹 API와 달리 SNOW에서 사용하는 모델은 수 초 ~ 수십 분까지 모델 크기에 따라 API 응답시간 차이가 크기 때문에 로드 밸런싱이 특히 어렵다고 합니다.

게다가 GPU는 OOM이 발생하면 곧바로 뻗기 때문에 한 두번의 잘못된 요청이 들어오는 것 만으로도 치명적인 오류를 일으킬 수 있습니다.

초기 해결책 : queue 방식

각 GPU마다 moon-worker라는 worker를 두어 해당 worker가 queue를 관리하도록 하는 방식을 사용했다고 합니다.

GPU를 통째로 사용해야하는 모델의 경우에는 1GPU 1worker를, 비교적 가벼운 모델에는 1GPU에 여러개의 worker를 할당하여 GPU 로드율을 최대한 효율적으로 사용할 수 있는 방법인 것 같습니다. 자세한 설명은 없었지만 아마 모델 별로 VRAM 사용량을 계산해서 worker 개수를 정하지 않았을까 생각합니다.

그러나 여전히 GPU 사용률을 효율적으로 쓰지 못하는 문제가 있었다고 합니다.

MPS (Multi-Process Service)

Nvidia가 제공하는 단일 GPU를 여러 프로세스에서 쓸 수 있게 하는 기능입니다. 적용하는 것도 어렵지 않다고 합니다.

MPS를 적용하면 GPU를 90% 넘게 사용하는 모델을 동시에 사용하더라도 큰 오버헤드 없이 병렬 처리가 가능합니다. 이렇게하면 개별 응답 시간은 느려지지만, 동시성이 보장되기 떄문에 훨씬 더 높은 효율로 GPU를 사용할 수 있다고 합니다.

지금 생각해보니 queue와 함께 적용했을 때 기존 queue 처리도 다소 변경되어야 할 것 같은데, 어떻게 MPS를 통합했는지를 미처 여쭤보지 못했네요.

소감

종합적으로 많은 것을 얻어갈 수 있는 컨퍼런스 였습니다. 특히 모델 서빙에 대해 저는 FastAPI로 단순 API를 뚫는 것 외에 경험이 없었는데, 정말로 모델 서빙이 필요할 때 이러이러한 것을 고려해야하구나~ 라는 것을 많이 배울 수 있었습니다.

또 필요하게 된다면 모델 성능 최적화도 공부해서 성능 n% 향상을 당당히 이력서에 적을 수 있게 되면 좋을 것 같습니다.