이 페이지에서는 대규모 언어 모델(LLM)에 중점을 두고 AI 추론용 GPU와 함께 Cloud Run 서비스를 사용할 때 성능을 최적화하기 위한 권장사항을 제공합니다.
확장 이벤트에 실시간으로 응답할 수 있는 Cloud Run 서비스를 빌드하고 배포해야 합니다. 즉, 다음을 수행해야 합니다.
- 빠르게 로드되고 GPU 지원 구조로 최소한의 변환이 필요한 모델을 사용하고 로드 방법을 최적화합니다.
- 최대의 효율적인 동시 실행을 허용하는 구성을 사용하면 비용을 낮추면서 초당 목표 요청을 처리하는 데 필요한 GPU 수를 줄일 수 있습니다.
Cloud Run에서 대규모 ML 모델을 로드하는 데 권장되는 방법
Google은 ML 모델을 컨테이너 이미지 내에 저장하거나 Cloud Storage에서 로드를 최적화하는 것이 좋습니다.
ML 모델 저장과 로드의 장단점
다음은 옵션을 비교한 내용입니다.
| 모델 위치 | 배포 시간 | 개발 환경 | 컨테이너 시작 시간 | 저장소 비용 |
| 컨테이너 이미지 | 느립니다. 대형 모델이 포함된 이미지를 Cloud Run으로 가져오는 데 시간이 더 오래 걸립니다. | 컨테이너 이미지를 변경하려면 재배포가 필요하며, 대형 이미지의 경우 느려질 수 있습니다. | 모델의 크기에 따라 다릅니다. 초대형 모델의 경우 예측 가능성은 높지만 성능은 저하되는 Cloud Storage를 사용합니다. | Artifact Registry에 여러 개의 사본이 있을 수 있습니다. |
| Cloud Storage FUSE 볼륨 마운트를 사용하여 로드된 Cloud Storage | 빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | 설정이 어렵지 않으며 Docker 이미지를 변경할 필요가 없습니다. | 네트워크 최적화 시 속도가 빠릅니다. 다운로드를 동시에 처리하지 않습니다. | 사본 1개가 Cloud Storage에 있습니다. |
Cloud Storage는 Google Cloud CLI 명령어 gcloud storage cp 또는 Cloud Storage API를 사용하여 Transfer Manager 동시 다운로드 코드 샘플에 표시된 대로 동시에 다운로드됩니다.
|
빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | Cloud Storage API를 사용하려면 이미지에 Google Cloud CLI를 설치하거나 코드를 업데이트해야 하므로 설정이 약간 더 어렵습니다. | 네트워크 최적화 시 속도가 빠릅니다. Google Cloud CLI는 모델 파일을 동시에 다운로드하므로 FUSE 마운트보다 빠릅니다. | 사본 1개가 Cloud Storage에 있습니다. |
| 인터넷 | 빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | 일반적으로 더 간단합니다(많은 프레임워크가 중앙 저장소에서 모델을 다운로드합니다). | 일반적으로 품질이 낮고 예측할 수 없습니다.
|
모델 호스팅 제공업체에 따라 다릅니다. |
컨테이너 이미지에 모델 저장
Cloud Run에 배포된 컨테이너 이미지에 ML 모델을 저장하면 추가 네트워크 최적화 없이 파일 로드 시간을 극대화하는 Cloud Run의 내장 컨테이너 이미지 스트리밍 최적화의 이점을 누릴 수 있습니다.
ML 모델이 포함된 컨테이너를 빌드하는 데 시간이 다소 걸릴 수 있습니다. Cloud Build를 사용하는 경우 더 빠른 빌드를 위해 더 큰 머신을 사용하도록 Cloud Build를 구성할 수 있습니다. 이렇게 하려면 다음 단계의 빌드 구성 파일을 사용하여 이미지를 빌드합니다.
steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'IMAGE', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'IMAGE'] images: - IMAGE options: machineType: 'E2_HIGHCPU_32' diskSizeGb: '500'
모델을 포함하는 레이어가 이미지 간에 고유한 경우(다른 해시) 이미지당 하나의 모델 복사본을 만들 수 있습니다. 모델 레이어가 각 이미지마다 고유한 경우 이미지당 모델 사본이 하나씩 있을 수 있으므로 Artifact Registry 비용이 추가로 발생할 수 있습니다.
Cloud Storage에 모델 저장
Cloud Storage 볼륨 마운트를 사용하거나 Cloud Storage API 또는 명령줄을 직접 사용하여 Cloud Storage에서 ML 모델을 로드할 때 ML 모델 로드를 최적화하려면 Private Service Connect와 함께 이그레스 설정 값을 all-traffic으로 설정한 직접 VPC를 사용해야 합니다.
빌드, 배포, 런타임, 시스템 디자인 고려사항
다음 섹션에서는 빌드, 배포, 런타임, 시스템 설계 고려사항을 설명합니다.
빌드 시간
다음 목록은 빌드를 계획할 때 고려해야 할 사항을 보여줍니다.
- 적절한 기본 이미지를 선택합니다. 사용 중인 ML 프레임워크에 대해 Deep Learning Containers 또는 NVIDIA Container Registry의 이미지로 시작해야 합니다. 이러한 이미지에는 최신 성능 관련 패키지가 설치되어 있습니다. 커스텀 이미지 만들기는 권장하지 않습니다.
- 결과 품질에 영향을 미친다고 입증할 수 없는 한 동시 실행을 최대화하기 위해 4비트 양자화 모델을 선택합니다. 양자화는 더 작고 빠른 모델을 생성합니다. 따라서 모델을 제공하는 데 필요한 GPU 메모리의 양을 줄이고 런타임에 병렬성을 높일 수 있습니다. 모델은 타겟 비트 심도로 양자화하는 것보다는 타겟 비트 심도로 학습하는 것이 이상적입니다.
- GGUF와 같이 로드 시간이 짧아 컨테이너 시작 시간을 최소화하는 모델 형식을 선택합니다. 이러한 형식은 타겟 양자화 유형을 더 정확하게 반영하며 GPU에 로드할 때 변환이 적게 필요합니다. 보안을 강화하려면 피클 형식 체크포인트를 사용하지 마세요.
- 빌드 시 LLM 캐시를 만들고 웜합니다. Docker 이미지를 빌드하는 동안 빌드 머신에서 LLM을 시작합니다. 프롬프트 캐싱을 사용 설정하고 일반 또는 예시 프롬프트를 피드하여 실제 사용을 위해 캐시를 웜합니다. 생성된 출력을 저장하여 런타임에 로드합니다.
- 빌드 시간 중 생성하는 자체 추론 모델을 저장합니다. 이렇게 하면 저장된 모델의 효율성이 낮은 모델을 로드하고 컨테이너 시작 시 양자화와 같은 변환을 적용하는 것보다 훨씬 시간을 절약할 수 있습니다.
배포 시
- Cloud Run에서 서비스 동시 실행을 정확하게 설정해야 합니다.
- 구성에 따라 시작 프로브를 조정합니다.
시작 프로브는 컨테이너가 시작되었고 트래픽을 수락할 준비가 되었는지 확인합니다. 시작 프로브를 구성할 때는 다음 주요 사항을 고려하세요.
- 적절한 시작 시간: 모델을 포함한 컨테이너가 완전히 초기화되고 로드되는 데 충분한 시간을 허용합니다.
- 모델 준비 확인: 애플리케이션이 요청을 처리할 준비가 되었을 때만 통과하도록 프로브를 구성합니다. 대부분의 제공 엔진은 모델이 GPU 메모리에 로드될 때 이를 자동으로 실행하여 조기 요청을 방지합니다.
Ollama는 모델이 로드되기 전에 TCP 포트를 열 수 있다는 점에 유의하세요. 이 문제를 해결하려면 다음 안내를 따르세요.
- 모델 미리 로드: 시작 중에 모델을 미리 로드하는 방법에 관한 안내는 Ollama 문서를 참고하세요.
런타임
- 지원되는 컨텍스트 길이를 적극적으로 관리합니다. 지원하는 컨텍스트 창이 작을수록 더 많은 쿼리를 동시에 실행할 수 있습니다. 자세한 방법은 프레임워크에 따라 다릅니다.
- 빌드 시간에 생성한 LLM 캐시를 사용합니다. 프롬프트 및 프리픽스 캐시를 생성할 때 빌드 시간 중에 사용한 것과 동일한 플래그를 제공합니다.
- 방금 작성한 저장된 모델에서 로드합니다. 모델 로드 방법에 대한 비교는 모델 저장과 모델 로드의 장단점을 참조하세요.
- 프레임워크에서 지원하는 경우 양자화된 키-값 캐시를 사용하는 것이 좋습니다. 이렇게 하면 쿼리당 메모리 요구사항이 줄어들고 동시 로드를 더 많이 구성할 수 있습니다. 하지만 품질에 영향을 미칠 수도 있습니다.
- 모델 가중치, 활성화, 키-값 캐시를 위해 예약할 GPU 메모리 양을 조정합니다. 메모리 부족 오류가 발생하지 않도록 최대한 높게 설정합니다.
- 서비스 코드 내에서 동시 실행을 올바르게 구성합니다. 서비스 코드가 Cloud Run 서비스 동시 실행 설정과 호환되도록 구성되어 있는지 확인합니다.
- 프레임워크에 컨테이너 시작 성능을 개선할 수 있는 옵션이 있는지 확인합니다(예: 모델 로드 동시 로드 사용).
시스템 디자인 수준:
- 적절한 위치에 시맨틱 캐시를 추가합니다. 경우에 따라서는 전체 쿼리와 응답을 캐싱하여 일반적인 쿼리의 비용을 효과적으로 제한할 수 있습니다.
- 프리앰블의 분산을 제어합니다. 프롬프트 캐시는 프롬프트가 순차적으로 포함된 경우에만 유용합니다. 캐시는 사실상 프리픽스 캐시로 처리됩니다. 시퀀스에 삽입 또는 수정이 있으면 캐시되지 않았거나 일부만 표시된다는 의미입니다.
자동 확장 및 GPU
Cloud Run은 CPU 사용률 및 요청 동시 실행과 같은 요소를 기준으로 각 버전의 인스턴스 수를 자동으로 확장합니다. 하지만 Cloud Run은 GPU 사용률을 기준으로 인스턴스 수를 자동으로 확장하지 않습니다.
GPU가 포함된 버전의 경우 버전에 상당한 CPU 사용량이 없으면 요청 동시 실행을 위해 Cloud Run이 수평 확장됩니다. 요청 동시 실행을 최적화하려면 다음 섹션에 설명된 대로 최적의 인스턴스당 최대 동시 요청 수를 설정해야 합니다.
인스턴스당 최대 동시 요청 수
인스턴스당 최대 동시 요청 수 설정은 Cloud Run이 단일 인스턴스에 한 번에 전송하는 최대 요청 수를 제어합니다. 각 인스턴스 내부의 코드가 우수한 성능으로 처리할 수 있는 최대 동시 실행과 일치하도록 동시 실행을 조정해야 합니다.
최대 동시 실행 및 AI 워크로드
각 인스턴스의 GPU에서 AI 추론 워크로드를 실행할 때 코드가 우수한 성능으로 처리할 수 있는 최대 동시 실행은 특정 프레임워크 및 구현 세부정보에 따라 다릅니다. 다음은 최적의 최대 동시 요청 설정을 설정하는 방법에 영향을 미칩니다.
- GPU에 로드된 모델 인스턴스 수
- 모델당 병렬 쿼리 수
- 일괄 처리 사용
- 특정 배치 구성 매개변수
- 비 GPU 작업의 양
최대 동시 요청 수가 너무 높게 설정되면 요청이 GPU에 액세스하기 위해 인스턴스 내에서 대기하게 되어 지연 시간이 늘어날 수 있습니다. 최대 동시 요청 수가 너무 낮게 설정되면 GPU가 사용되지 않아 Cloud Run에서 필요 이상으로 인스턴스를 수평 확장할 수 있습니다.
AI 워크로드의 최대 동시 요청을 구성하기 위한 대략적인 규칙은 다음과 같습니다.
(Number of model instances * parallel queries per model) + (number of model instances * ideal batch size)
예를 들어 인스턴스가 GPU에 3 모델 인스턴스를 로드하고 각 모델 인스턴스가 4 병렬 쿼리를 처리할 수 있다고 가정해 보겠습니다. 또한 이상적인 배치 크기는 각 모델 인스턴스가 처리할 수 있는 병렬 쿼리 수인 4입니다. 대략적인 가이드라인에 따라 최대 동시 요청 24: (3 * 4) + (3 * 4)를 설정합니다.
이 수식은 경험에 기반한 규칙일 뿐이라는 점에 유의하십시오. 이상적인 최대 동시 요청 설정은 구현의 세부사항에 따라 다릅니다. 실제 최적의 성능을 얻으려면 다양한 최대 동시 요청 설정으로 서비스를 부하 테스트하여 가장 실적이 좋은 옵션을 평가하는 것이 좋습니다.
처리량, 지연 시간, 비용 절충
최대 동시 요청이 처리량, 지연 시간, 비용에 미치는 영향은 처리량, 지연 시간, 비용 절충을 참고하세요. GPU를 사용하는 모든 Cloud Run 서비스에는 항상 CPU가 할당됩니다.