Meituan Visual GPU 추론 서비스 배포 아키텍처 최적화 실습

온라인 추론 서비스에 사용되는 GPU 리소스 증가와 일반적으로 낮은 GPU 활용 문제에 직면한 Meituan Vision R&D 팀은 모델 구조와 마이크로 서비스를 분할하여 최적화하기로 결정하고 일반적이고 효율적인 배포 아키텍처를 제안했습니다. 성능 병목 문제.

'이미지 감지 + 분류' 서비스를 예로 들면 최적화 서비스 압력 테스트 성능 지표의 GPU 활용률이 40%에서 100%로 증가했으며 QPS도 3배 이상 증가했습니다. 이 기사에서는 유추 서비스 배포 아키텍처 최적화의 엔지니어링 방식에 초점을 맞춰 도움을 주거나 영감을 주기를 바랍니다.

0. 소개
1. 배경
2. 비주얼 모델 서비스의 특징과 과제
- 2.1 모델 최적화 도구 및 배포 프레임워크
- 2.2 비주얼 모델 기능
- 2.3 시각적 추론 서비스가 직면한 문제와 과제
3. GPU 서비스 최적화 실습
- 3.1 이미지 분류 모델 서비스 최적화
- 3.2 이미지 "검출 + 분류" 모델 서비스 최적화
4. 일반적이고 효율적인 추론 서비스 배포 아키텍처
5. 요약 및 전망

0. 소개

Meituan Vision은 지역 생활 서비스를 지향하며 텍스트 인식, 이미지 품질 평가, 비디오 이해와 같은 시각 AI 기술을 다양한 시나리오에 적용했습니다. 이전에는 온라인 추론 서비스에서 사용하는 GPU 리소스가 계속 증가했지만 일반적으로 서비스 GPU의 활용률이 낮아 많은 컴퓨팅 리소스를 낭비하고 시각적 AI 애플리케이션 비용을 증가시키는 것은 Meituan과 많은 기업이 필요로 하는 시급한 문제입니다. 해결하다.

실험 분석을 통해 Meituan의 시각 지능 부서는 시각 추론 서비스의 GPU 활용률이 낮은 중요한 이유가 모델 구조 문제라는 것을 발견했습니다. 모델의 전처리 또는 후처리 부분의 CPU 작동 속도는 느려서 추론 백본 네트워크가 GPU 컴퓨팅 성능을 완전히 활용할 수 없습니다. 이를 기반으로 Visual R&D 팀은 모델 구조 분할 및 마이크로 서비스를 통해 이러한 일반적인 성능 병목 문제를 해결하기 위해 일반적이고 효율적인 배포 아키텍처를 제안합니다.

현재 이 솔루션은 여러 핵심 서비스에 성공적으로 적용되었습니다. "이미지 감지 + 분류" 서비스를 예로 들면 최적화 서비스 압력 테스트 성능 지수의 GPU 활용률이 40%에서 100%로 증가했으며 QPS는 3배 이상 증가했습니다. 이 기사는 관련 작업에 참여하는 학생들에게 도움이 되거나 영감을 주기를 바라며 추론 서비스 배포 아키텍처 최적화의 엔지니어링 사례에 중점을 둘 것입니다.

1. 배경

점점 더 많은 AI 애플리케이션이 프로덕션 애플리케이션 단계에 진입함에 따라 추론 서비스에 필요한 GPU 리소스도 빠르게 증가하고 있습니다. 조사 자료에 따르면 국내 AI 관련 산업에서 추론 서비스의 자원 사용량은 55% 이상을 차지하고 있으며, 앞으로도 그 비율은 계속 증가할 것으로 보인다. 그러나 많은 기업이 직면한 실제 문제는 온라인 추론 서비스의 GPU 활용률이 일반적으로 낮고 여전히 개선의 여지가 많다는 것입니다.

서비스의 GPU 활용도가 낮은 중요한 이유 중 하나는 추론 서비스 자체에 성능 병목 현상이 있고, 극심한 압박에도 GPU 리소스를 충분히 활용할 수 없기 때문입니다. 이러한 맥락에서 "추론 서비스 성능 최적화, GPU 리소스 사용 효율성 향상 및 리소스 사용 비용 절감"은 큰 의미가 있습니다. 이 글은 아키텍처 배치 최적화를 통한 정확성, 추론 지연 등 지표 확보를 전제로 추론 서비스의 성능과 GPU 활용도를 높이는 방법을 주로 소개한다.

2. 비주얼 모델 서비스의 특징과 과제

최근 몇 년 동안 딥 러닝 방법은 컴퓨터 비전 작업에서 눈부신 발전을 이루었고 주류 방법이 되었습니다. 비전 모델은 그 구조상 몇 가지 특수성이 있으며, 기존 추론 프레임워크와 함께 배포할 경우 성능 및 GPU 활용 측면에서 서비스가 요구 사항을 충족하지 못할 수 있습니다.

2.1 모델 최적화 도구 및 배포 프레임워크

딥 러닝 모델은 일반적으로 배포 전에 최적화 도구를 사용하여 최적화되며 일반적인 최적화 도구에는 TensorRT, TF-TRT, TVM 및 OpenVINO가 포함됩니다. 이러한 도구는 연산자 융합, 동적 메모리 할당 및 정확도 보정과 같은 방법을 통해 모델 실행 속도를 향상시킵니다. 모델 배포는 프로덕션 애플리케이션의 마지막 링크로 딥러닝 모델 추론 프로세스를 서비스로 캡슐화하고 내부적으로는 모델 로딩, 모델 버전 관리, 일괄 처리, 서비스 인터페이스 캡슐화 등의 기능을 구현하고 외부적으로는 RPC/HTTP 인터페이스를 제공합니다. 업계의 주류 배포 프레임워크는 다음과 같습니다.

TensorFlow Serving : TensorFlow Serving (줄여서 TF-Serving)은 기계 학습 모델 배포를 위해 Google에서 출시한 고성능 오픈 소스 프레임워크입니다. 형식.
Torch Serve : TorchServe는 AWS와 Facebook이 공동으로 출시한 Pytorch 모델 배포 추론 프레임워크로, 간단한 배포, 고성능, 경량이라는 장점이 있습니다.
Triton : Triton은 Nvidia에서 출시한 고성능 추론 서비스 프레임워크로 TensorFlow, TensorRT, PyTorch, ONNX 등 여러 프레임워크 모델을 지원하며 다중 모델 공동 추론 시나리오에 적합합니다.

실제 배포에서는 어떤 프레임워크를 선택하든 모델 형식, 최적화 도구 및 프레임워크 기능과 같은 여러 요소를 고려해야 합니다.

2.2 비주얼 모델 기능

딥러닝은 기존 방식과 달리 특징 추출, 분류기 등 별도의 모듈 설계가 필요하지 않고 기존 방식의 다중 모듈 작업을 단일 모델로 대체하는 end-to-end 방식이다. 딥 러닝 모델은 분류, 감지, 분할, 인식과 같은 시각적 작업에서 큰 이점을 보여주었고 기존 방법으로는 달성할 수 없는 정밀도를 달성했습니다. 일반적으로 사용되는 시각적 분류 모델(예: ResNet, GoogleNet 등)과 탐지 모델(예: YOLO, R-FCN 등)은 다음과 같은 특징이 있습니다.

다수의 네트워크 계층(GPU 컴퓨팅에 적합) : ResNet-50을 예로 들면 네트워크에는 49개의 컨볼루션 계층과 1개의 완전 연결 계층이 포함되어 있으며 최대 2,500만 개의 매개변수와 38억 개의 FLOP(부동 소수점 피연산자)가 있습니다. 모델 추론에는 GPU 병렬 가속에 적합한 많은 행렬 계산이 포함됩니다.
입력 이미지 크기는 고정되어 있습니다(전처리 필요) : ResNet-50도 예로 들어 네트워크의 입력은 이미지 부동 소수점 유형 행렬이고 크기는 224x224로 고정되어 있습니다. 따라서 이진 부호화된 그림을 네트워크로 보내기 전에 디코딩, 스케일링, 자르기와 같은 전처리 작업이 필요합니다.

2.3 시각적 추론 서비스가 직면한 문제와 과제

위의 시각적 모델의 특성으로 인해 모델의 배포 및 최적화에 두 가지 문제가 있습니다.

불완전한 모델 최적화 : TensorRT, TF-TRT 및 기타 도구는 주로 백본 네트워크 최적화를 목표로 하지만 전처리 부분을 무시하므로 전체 모델 최적화가 충분하지 않거나 최적화할 수 없습니다. 예를 들어 분류 모델에서 ResNet-50의 모든 네트워크 계층을 최적화할 수 있지만 전처리에서 이미지 디코딩(일반적으로 CPU 작업) 작업 "tf.image.decode"는 무시되고 TF-TRT에서 건너뜁니다.
여러 모델 배포의 어려움 : 시각적 서비스는 기능을 구현하기 위해 여러 모델을 직렬로 결합하는 경우가 많습니다. 예를 들어, 문자 인식 서비스에서 먼저 감지 모델에 의해 문자의 위치를 찾은 다음 문자 위치의 부분 이미지를 잘라낸 다음 최종적으로 인식 모델로 전송하여 문자 인식 결과를 얻습니다. 서비스의 여러 모델은 서로 다른 교육 프레임워크를 사용할 수 있습니다.TF-Serving 또는 Troch Serve 추론 프레임워크는 배포 요구 사항을 충족할 수 없는 단일 모델 형식만 지원합니다. Triton은 다양한 모델 포맷을 지원하며, 커스텀 모듈(Backend)과 통합 스케줄링(Ensemble)을 통해 모델 간의 결합 로직을 구축할 수 있으나 구현이 비교적 복잡하고 전체적인 성능에 문제가 있을 수 있습니다.

이 두 가지 일반적인 모델 배포 문제는 시각적 추론 서비스의 성능 병목 현상과 낮은 GPU 사용률로 이어지며 고성능 배포 프레임워크인 Triton으로도 해결하기 어렵습니다.

일반적인 배포 프레임워크는 "통신 방식, 일괄 처리, 다중 인스턴스"와 같은 서비스 호스팅의 성능 문제에 중점을 둡니다. 최적화 도구는 그것을 최적화할 수 없습니다. , "배럴 효과"가 발생하여 전체 추론 프로세스의 성능이 저하됩니다. 따라서 추론 서비스에서 모델 성능 병목 현상을 최적화하는 방법은 여전히 중요하고 어려운 작업입니다.

3. GPU 서비스 최적화 실습

분류 및 감지는 이미지 검토, 이미지 레이블 분류 및 얼굴 감지와 같은 시나리오에서 자주 사용되는 두 가지 가장 기본적인 비전 모델입니다. 다음은 두 가지 일반적인 서비스를 사례로 사용하여 단일 분류 모델과 "분류 + 탐지" 다중 모델 조합을 사용하여 특정 성능 최적화 프로세스를 소개합니다.

3.1 이미지 분류 모델 서비스 최적화

Meituan은 위험한 콘텐츠를 필터링하기 위해 매일 수천만 장의 사진을 검토하고 필터링해야 합니다.수동 검토 비용이 너무 높고 자동 기계 검토를 실현하려면 이미지 분류 기술이 필요합니다. 일반적으로 사용되는 분류 모델 구조는 그림 1과 같습니다. 전처리 부분은 주로 "디코딩, 스케일링 및 자르기"와 같은 작업을 포함하며 백본 네트워크는 ResNet-50입니다. 전처리부는 이미지 바이너리 스트림을 수신하여 백본 네트워크(각각 사진의 수, 채널 수, 이미지의 높이, 이미지의 너비를 나타냄)와 백본 네트워크에서 요구하는 매트릭스 데이터 Nx3x224x224를 생성하고, 출력 이미지 분류 결과를 예측합니다.

그림 1 이미지 분류 모델 구조의 개략도

TF-TRT 최적화 후 모델의 실제 구조는 아래 그림 2와 같다 백본 네트워크 ResNet은 Engine으로 최적화되어 있지만 전처리 부분의 연산자는 최적화를 지원하지 않아 전체 전처리 부분은 원래 상태를 유지한다. .

그림 2 이미지 분류 모델 TF-TRT 최적화 구조 다이어그램

3.1.1 성능 병목 현상

모델이 TF-TRT에 의해 최적화된 후 TF-Serving 프레임워크를 사용하여 배포됩니다.서비스 압력 테스트의 GPU 활용률은 42%에 불과하며 QPS와 Nvidia의 공식 데이터 사이에는 큰 격차가 있습니다. TF-TRT 및 Tensorflow 프레임워크와 같은 가능한 영향 요인을 배제하고 마지막으로 전처리 부분에 집중합니다. Nvidia의 성능 테스트를 위한 모델은 전처리되지 않고 Nx3x224x224 매트릭스 데이터가 직접 입력됩니다. 그러나 여기에서 온라인 서비스는 전처리 부분이 포함되어 있으며 스트레스 테스트 지표의 CPU 사용률이 상대적으로 높습니다. 모델에서 각 오퍼레이터의 운영 장비를 확인하고 대부분의 모델 전처리가 CPU 컴퓨팅이고 백본 네트워크는 GPU 컴퓨팅임을 확인합니다(자세한 내용은 그림 1 참조).

아래 그림 3과 같이 NVIDIA Nsight System(nsys) 도구를 통해 모델이 실행될 때 CPU/GPU 실행 상태를 확인하면 GPU 작업 사이에 분명한 간격이 있음을 알 수 있습니다.CPU 데이터를 기다려야 합니다. 백본 네트워크 추론을 수행하기 전에 GPU에 준비 및 복사 계산, CPU의 느린 처리 속도로 인해 GPU가 기아 상태에 있게 됩니다. 서비스 스트레스 테스트의 CPU/GPU 활용도 데이터와 종합하면 높은 CPU 소모와 전처리 부분의 느린 처리 속도가 추론 서비스의 성능 병목 현상임을 알 수 있다.

그림 3 분류 모델 nsys 성능 진단 다이어그램

3.1.2 최적화 방법

아래 그림 4와 같이 전처리의 높은 CPU 사용량이 추론 서비스의 성능에 영향을 미치는 문제를 해결하기 위해 몇 가지 최적화 방법을 제안합니다.

그림 4 최적화 방법 비교

CPU 늘리기 : 머신의 CPU 수를 늘리는 가장 쉬운 방법이지만 서버 하드웨어 구성에 따라 제한되며 일반적으로 1 GPU는 8개의 CPU로만 구성됩니다. 따라서 CPU를 높이는 방법은 성능 테스트 데이터 비교에만 사용할 수 있으며 실제 응용 프로그램에 배포할 수 없습니다.
전처리 : 큰 크기의 그림의 디코딩 및 스케일링 작업은 많은 CPU를 소비하지만 작은 크기의 그림의 처리 속도가 훨씬 빠릅니다. 따라서 미리 입력된 이미지를 전처리하는 것을 고려한 다음 전처리된 작은 이미지를 서비스로 보냅니다. Tensorflow의 크기 조정 및 자르기 작업에는 중첩 불변성이 있음이 확인되었습니다. 즉, 여러 작업과 단일 작업이 최종 결과에 영향을 미치지 않습니다. 사전 처리된 작은 이미지는 원시 분류 서비스로 전송되기 전에 인코딩됩니다. 이미지 인코딩을 위해 무손실 인코딩(예: PNG)을 선택해야 합니다. 그렇지 않으면 디코딩된 데이터가 일관성이 없고 예측 오류가 발생합니다. 전처리 방식의 장점은 원본 모델 서비스를 수정할 필요가 없고, 높은 운용성과 예측 결과에 오류가 없다는 것입니다. 단점은 반복적인 전처리가 필요하여 전체 프로세스 지연이 증가하고 CPU 리소스가 낭비된다는 것입니다.
별도의 전처리 : 또 다른 아이디어는 모델 전처리 부분을 백본 네트워크에서 분리하고 전처리 부분을 CPU 머신에 별도로 배치하고 백본 네트워크를 GPU 머신에 배치하는 것입니다. 이 접근 방식을 통해 CPU 전처리 서비스는 GPU 처리를 위한 데이터 공급을 충족하고 GPU 성능을 최대한 활용할 수 있도록 수평으로 무한히 확장할 수 있습니다. 더 중요한 것은 CPU와 GPU 작업의 분리가 CPU-GPU 데이터 교환을 위한 대기 시간을 줄여 이론적으로 CPU 수를 늘리는 것보다 더 효율적이라는 것입니다. 고려해야 할 사항은 서비스 간 통신 효율성과 시간 뿐이며 크롭된 이미지 크기는 224x224x3, 무부호 정수 데이터 크기는 143KB이며 전송 시간과 대역폭은 10,000 QPS 이하로 문제가 없습니다.

3.1.3 최적화 결과

아래 그림 5와 같이 NVIDIA Nsight System을 사용하여 위의 방법으로 최적화된 모델의 동작을 비교합니다. CPU를 늘리고 전처리하는 방법은 CPU 전처리 시간을 단축하고 GPU 데이터 대기 시간을 줄이며 GPU 활용도를 높일 수 있습니다. 하지만 그에 비해 전처리를 분리하는 방법이 더 철저하게 최적화되어 있고, CPU에서 GPU로 데이터를 복사하는 시간이 가장 짧으며, GPU를 최대한 활용합니다.

그림 5 최적화 방식 nsys 성능진단 비교표

다양한 방법으로 최적화된 온라인 서비스 압력 테스트 성능 결과는 아래의 그림 6과 같다(전처리 및 분리 전처리에서 CPU 전처리 서비스는 추가로 16개의 CPU를 사용함), 머신에 구성된 CPU 모델은 Intel(R) Xeon(R) Gold 5218 [email protected], GPU 모델은 Tesla T4입니다. 압력 테스트 결과에서 다음을 확인할 수 있습니다.

그림 6 최적화 결과의 성능 비교

1. 서비스 CPU가 32코어로 증가하고, QPS 및 GPU 활용도( nvidia-smi커맨드를 통해 얻은 GPU-Util 지표)가 1배 이상 증가했으며, GPU 활용도는 88%로 증가했습니다.

2. 전처리 방식을 최적화한 후 서비스 QPS가 2배 이상으로 CPU를 늘리는 방식보다 약간 나아지지만 GPU 활용 측면에서는 아직 최적화의 여지가 많다.

3. 분리 전처리 방법을 최적화한 후 QPS가 2.7배 증가하고 GPU 활용률이 98%에 도달하여 풀로드 상태에 가깝습니다.

CPU를 늘려도 서비스 성능 병목 문제를 완전히 해결할 수는 없으며, GPU 활용률이 88%에 달하지만 CPU-GPU 데이터 전송 시간이 차지하는 비중이 커서 QPS 개선에 한계가 있다. 전처리 방법은 전처리 성능 병목 문제를 완전히 해결하지 못하고 최적화가 철저하지 않습니다. 이에 비해 별도의 전처리 방법은 GPU의 컴퓨팅 성능을 최대한 발휘하고 QPS 및 GPU 활용 지표에서 더 나은 최적화 결과를 달성합니다.

3.2 이미지 "검출 + 분류" 모델 서비스 최적화

일부 복잡한 작업 시나리오(예: 얼굴 감지 및 인식, 이미지 텍스트 인식 등)에서는 일반적으로 기능을 달성하기 위해 감지, 세분화 및 분류와 같은 여러 모델의 조합입니다. 본 장에서 소개하는 모델은 "탐지 + 분류"가 연속적으로 구성되어 있으며 모델 구조는 아래의 그림 7과 같으며 주로 다음과 같은 부분으로 구성된다.

그림 7 원래 모델 구조의 개략도

전처리 : 주로 이미지 디코딩, 스케일링, 채우기 등의 작업을 포함하며 Nx3x512x512 이미지 매트릭스를 출력합니다.대부분의 연산자는 CPU 장치에서 실행됩니다.
탐지 모델 : 탐지 네트워크 구조는 YOLOv5이며, 운영자 실행 장치는 GPU입니다.
사후 감지 처리 : NMS(비최대값 억제) 알고리즘을 사용하여 중복되거나 잘못 감지된 대상 프레임을 제거하여 유효한 감지 프레임을 얻은 다음 대상 영역 하위 이미지를 자르고 크기를 조정하고 Nx3x224x224 이미지 매트릭스를 출력하고 대부분의 CPU 장치에서 감지 후 연산자.
분류 모델 : 분류 네트워크 구조는 ResNet-50이며, 운영자 구동 장치는 GPU입니다.

탐지 및 분류의 두 하위 모델은 개별적으로 훈련되고 추론 중에 단일 모델로 병합됩니다.배포 프레임워크는 TF-Serving을 사용하고 최적화 도구는 TF-TRT를 사용합니다.

3.2.1 성능 병목 현상

모델에서 대부분의 전처리 및 사후 감지 처리는 CPU 작업이며 감지 및 분류 모델의 백본 네트워크는 GPU 작업입니다 단일 추론 프로세스에서 여러 CPU-GPU 데이터 교환이 필요합니다. 마찬가지로 CPU 작업 속도가 느리면 GPU 사용률이 낮아지고 추론 서비스에 성능 병목 현상이 발생합니다.

실제 온라인 서비스 압박 테스트 결과 GPU 활용률은 68%로 QPS도 최적화 여지가 크다. 서비스 구성은 1GPU+8CPU(기기의 CPU 모델은 Intel(R) Xeon(R) Gold 5218 [email protected], GPU 모델은 Tesla T4)입니다.

3.2.2 최적화 방법

모델 분할 아이디어는 여전히 채택되고 있으며 마이크로 서비스는 CPU 및 GPU 컴퓨팅 부분에 대해 별도로 배포됩니다. 아래 그림 8과 같이 원본 모델을 4개 부분으로 분할하여 전처리 및 사후 감지 처리를 CPU 마이크로서비스(트래픽 볼륨에 따라 동적으로 확장 가능)로 배치하고 감지 모델 및 분류 모델을 배치합니다. GPU 마이크로서비스(동일한 GPU 카드)로 호출 방법을 단순하게 유지하기 위해 상위 계층은 스케줄링 서비스를 사용하여 다양한 마이크로 서비스를 직렬로 연결하고 통합 호출 인터페이스를 제공하며 상위 계층과의 호출 차이를 보호합니다. 분할 감지 모델과 분류 모델은 TensorRT에 의해 최적화된 후 Triton과 함께 배포됩니다.

그림 8 모델 최적화 배포 구조의 개략도

3.2.3 최적화 결과

아래 그림 9와 같이 기존 서비스와 마이크로서비스 분할 외에 CPU와 Triton Ensemble을 추가한 성능 테스트 결과도 비교한다. Triton Ensmeble 방법은 다중 모델 파이프라인 스케줄링을 실현하기 위해 하나의 머신에 모든 하위 모델(전처리 및 후처리 포함)을 배포합니다. 비교에서 알 수 있습니다.

그림 9 최적화 결과의 성능 비교

원래 서비스의 CPU는 32코어로 증가하고 GPU 활용률은 90%로 증가하지만 QPS 증가는 36%에 불과합니다.
원래 TF-Serving 서비스와 비교할 때 Triton Ensemble 방법은 성능 차이가 거의 없습니다.
모델 분할 마이크로서비스 방식의 최적화 후 QPS가 3.6배 증가하고 GPU 활용률이 100% 풀로드에 도달합니다.

CPU를 늘리는 방법은 서비스 GPU 활용도를 크게 향상시키지만 QPS 향상이 뚜렷하지 않은 이유는 CPU 전처리 및 후처리 시간은 단축되지만 CPU-GPU 데이터 전송 시간은 여전히 차지하기 때문입니다. 전체 추론 프로세스에서 많은 비율을 차지하며 GPU 컴퓨팅 시간은 비교적 큽니다.

분할 모델은 다중 모델 스케줄링 파이프라인을 구현하기 위해 Triton Ensmeble을 사용하여 배포되며 효율성은 모델 분할 전보다 높지 않습니다. 다중 모델 파이프라인이 동일한 시스템에 있기 때문에 CPU와 GPU 간의 상호 영향 문제가 해결되지 않았으며 GPU의 처리 효율성은 CPU에 의해 제한됩니다. 모델 분할 마이크로서비스 배포 방법은 서비스 수준에서 호출 파이프라인을 실현하고 CPU 전처리 및 후처리 마이크로서비스는 트래픽에 따라 리소스를 동적으로 증가시켜 GPU 모델 마이크로서비스의 처리량 요구 사항을 충족하고 GPU/CPU 처리 분리를 실현하며 방지합니다. CPU 처리가 병목 현상이 됩니다.

대체로 마이크로 서비스를 분할하는 방법은 GPU의 컴퓨팅 성능을 최대한 활용하고 QPS 및 GPU 활용 지표 측면에서 더 나은 결과를 얻습니다.

4. 일반적이고 효율적인 추론 서비스 배포 아키텍처

위의 두 가지 대표적인 추론 서비스 최적화 사례 외에도 많은 다른 시각적 서비스도 이 최적화 방법을 채택합니다. 이 최적화 방법에는 핵심 아이디어가 있습니다. CPU 컴퓨팅이 병목 현상이 되는 추론 서비스에서 모델의 CPU 및 GPU 컴퓨팅 부분을 분할하고 CPU/GPU 마이크로 서비스로 별도로 배포합니다 .

이러한 아이디어를 바탕으로 일반적이고 효율적인 추론 서비스 배포 아키텍처를 제안합니다. 아래 그림 10과 같이 하단 레이어는 공통 배포 프레임워크(TF-Serving/Triton 등)를 사용하고, 전처리 및 후처리와 같은 모델의 CPU 컴퓨팅 부분은 분할되어 CPU 마이크로 서비스에 별도로 배포되며, 백본 네트워크 모델은 GPU 서비스로 배포됩니다.상위 수준 스케줄링 서비스는 모델 마이크로 서비스를 연결하여 전체 기능 논리를 실현합니다.

그림 10 일반 서비스 배포 아키텍처의 개략도

여기에서 중요한 질문을 설명해야 합니다. 이 배포 아키텍처가 효율적인 이유는 무엇입니까?

먼저 매크로 수준에서 모델을 분할하여 마이크로 서비스로 배포하고 스케줄링 서비스를 통해 하위 모델 파이프라인 처리를 구현합니다. 분할된 하위 모델 CPU 마이크로서비스는 트래픽 및 처리 기능에 따라 동적으로 확장될 수 있으며, 성능 병목 현상으로 모델 전처리 또는 후처리를 위한 CPU 컴퓨팅 성능 부족을 방지하고 GPU 모델 마이크로서비스의 처리량 요구 사항을 충족합니다.

둘째, 미시적 수준에서 모델에 여러 CPU/GPU 컴퓨팅 부품이 포함되어 있으면 GPU 컴퓨팅 사이에 간격이 생깁니다. 아래 그림 11과 같이 단일 추론 프로세스에서는 두 개의 GPU 작업 사이에 CPU 후처리 부분이 완료될 때까지 기다려야 하며 CPU 전처리도 GPU 작업에 영향을 미칩니다. 모델이 분할된 후 전처리 및 후처리 부분이 CPU 서비스로 독립적으로 배치됩니다 GPU 서비스의 추론 프로세스는 두 개의 하위 모델 연산 부분만 포함하고 하위 모델 간의 연산은 각각 독립적 다른 데이터 연결없이 CPU-GPU 데이터 전송 부분은 GPU와 연결될 수 있습니다. 계산 프로세스는 병렬이며 이론적으로 GPU는 100% 작동 효율을 달성할 수 있습니다.

그림 11 추론 프로세스 비교의 개략도

또한 지연 측면에서 마이크로서비스를 분할하여 배포하는 방식은 RPC 통신 및 데이터 복사의 시간 오버헤드를 증가시키지만 실제로는 이 부분의 시간이 차지하는 비중이 적고 end-to-to-end에 큰 영향을 미치지 않습니다. 지연 종료. 예를 들어 위 3.1절의 분류 모델의 경우 최적화 전 평균 서비스 시간은 42ms이고 최적화 후 마이크로 서비스 형태(RPC 통신 프로토콜은 Thrift)의 평균 서비스 시간은 45ms입니다. 이 수준의 대기 시간 증가는 일반적으로 대부분의 비전 제공 사용 사례에 둔감합니다.

5. 요약 및 전망

이 글은 대표적인 두 가지 시각적 추론 서비스를 예로 들어 모델 성능 병목 현상과 낮은 GPU 활용 문제에 대한 최적화 사례를 소개합니다. 100%. 본 논문은 최적화 실행에 따라 일반적이고 효율적인 추론 서비스 전개 구조를 제안하며, 이 구조는 시각적 모델 서비스에 국한되지 않고 다른 분야의 GPU 서비스도 참고할 수 있다.

물론 이 최적화 방식에도 몇 가지 단점이 있습니다.예를 들어 최적화 프로세스에서 모델을 분할하는 방법은 수동 경험 또는 실험 테스트에 따라 다르며 최적화 프로세스의 자동화 및 표준화를 실현하지 못합니다. 향후에는 모델 병목 현상을 자동으로 진단하고 전체 프로세스의 자동 분할 및 최적화를 지원하는 모델 성능 분석 도구를 구축할 계획입니다.