- 빠르게 로드되고 GPU 지원 구조로 최소한의 변환이 필요한 모델을 사용하고 로드 방법을 최적화합니다.
- 최대의 효율적인 동시 실행을 허용하는 구성을 사용하면 비용을 낮추면서 초당 목표 요청을 처리하는 데 필요한 GPU 수를 줄일 수 있습니다.
Cloud Run에서 대규모 ML 모델을 로드하는 데 권장되는 방법
Google은 ML 모델을 컨테이너 이미지 내에 저장하거나 Cloud Storage에서 로드를 최적화하는 것이 좋습니다.
ML 모델 저장과 로드의 장단점
다음은 옵션을 비교한 내용입니다.
| 모델 위치 | 배포 시간 | 개발 환경 | 컨테이너 시작 시간 | 저장소 비용 |
| 컨테이너 이미지 | 느립니다. 대형 모델이 포함된 이미지를 Cloud Run으로 가져오는 데 시간이 더 오래 걸립니다. | 컨테이너 이미지를 변경하려면 재배포가 필요하며, 대형 이미지의 경우 느려질 수 있습니다. | 모델의 크기에 따라 다릅니다. 초대형 모델의 경우 예측 가능성은 높지만 성능은 저하되는 Cloud Storage를 사용합니다. | Artifact Registry에 여러 개의 사본이 있을 수 있습니다. |
| Cloud Storage, Cloud Storage FUSE 볼륨 마운트를 사용하여 로드됨 | 빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | 설정이 어렵지 않으며 Docker 이미지를 변경할 필요가 없습니다. | 네트워크 최적화를 사용하면 속도가 빠릅니다. 다운로드를 병렬화하지 않습니다. | 사본 1개가 Cloud Storage에 있습니다. |
Transfer Manager 동시 다운로드 코드 샘플에 표시된 대로 Google Cloud CLI 명령어 gcloud storage cp 또는 Cloud Storage API를 사용하여 동시에 다운로드된 Cloud Storage. |
빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | Cloud Storage API를 사용하려면 이미지에 Google Cloud CLI를 설치하거나 코드를 업데이트해야 하므로 설정이 약간 더 어렵습니다. | 네트워크 최적화를 사용하면 속도가 빠릅니다. Google Cloud CLI는 모델 파일을 동시에 다운로드하므로 FUSE 마운트보다 빠릅니다. | 사본 1개가 Cloud Storage에 있습니다. |
| 인터넷 | 빠릅니다. 모델이 컨테이너 시작 중에 다운로드됩니다. | 일반적으로 더 간단합니다(많은 프레임워크가 중앙 저장소에서 모델을 다운로드합니다). | 일반적으로 품질이 낮고 예측할 수 없습니다.
|
모델 호스팅 업체에 따라 다릅니다. |
컨테이너 이미지에 모델 저장
컨테이너 이미지에 ML 모델을 저장하면 모델 로드가 Cloud Run의 최적화된 컨테이너 스트리밍 인프라의 이점을 누릴 수 있습니다. 하지만 ML 모델이 포함된 컨테이너 이미지를 빌드하는 것은 특히 대규모 모델로 작업할 때 리소스 집약적인 프로세스입니다. 특히 빌드 프로세스가 네트워크 처리량에서 병목 현상이 발생할 수 있습니다. 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 모델 로드를 최적화하려면 비공개 Google 액세스와 함께 이그레스 설정 값을 all-traffic으로 설정한 직접 VPC를 사용해야 합니다.
인터넷에서 모델 로드
인터넷에서 ML 모델 로드를 최적화하려면 이그레스 설정 값을 all-traffic으로 설정하여 모든 트래픽을 VPC 네트워크를 통해 라우팅하고 Cloud NAT를 설정하여 높은 대역폭으로 공개 인터넷에 연결합니다.
빌드, 배포, 런타임, 시스템 디자인 고려사항
다음 섹션에서는 빌드, 배포, 런타임, 시스템 설계에 대한 고려사항을 설명합니다.
빌드 시
다음 목록은 빌드를 계획할 때 고려해야 할 사항을 보여줍니다.
- 적절한 기본 이미지를 선택합니다. 사용 중인 ML 프레임워크에 대해 Deep Learning Containers 또는 NVIDIA Container Registry의 이미지로 시작해야 합니다. 이러한 이미지에는 최신 성능 관련 패키지가 설치되어 있습니다. 커스텀 이미지 만들기는 권장하지 않습니다.
- 결과 품질에 영향을 미친다고 입증할 수 없는 한 동시 실행을 최대화하기 위해 4비트 양자화 모델을 선택합니다. 양자화는 더 작고 빠른 모델을 생성합니다. 따라서 모델을 제공하는 데 필요한 GPU 메모리의 양을 줄이고 런타임에 병렬성을 높일 수 있습니다. 모델은 타겟 비트 심도로 양자화하는 것보다는 타겟 비트 심도로 학습하는 것이 이상적입니다.
- GGUF와 같이 로드 시간이 짧아 컨테이너 시작 시간을 최소화하는 모델 형식을 선택합니다. 이러한 형식은 타겟 양자화 유형을 더 정확하게 반영하며 GPU에 로드할 때 변환이 적게 필요합니다. 보안을 강화하려면 피클 형식 체크포인트를 사용하지 마세요.
- 빌드 시 LLM 캐시를 만들고 웜합니다. Docker 이미지를 빌드하는 동안 빌드 머신에서 LLM을 시작합니다. 프롬프트 캐싱을 사용 설정하고 일반 또는 예시 프롬프트를 피드하여 실제 사용을 위해 캐시를 웜합니다. 생성된 출력을 저장하여 런타임에 로드합니다.
- 빌드 시간 중 생성하는 자체 추론 모델을 저장합니다. 이렇게 하면 저장된 모델의 효율성이 낮은 모델을 로드하고 컨테이너 시작 시 양자화와 같은 변환을 적용하는 것보다 훨씬 시간을 절약할 수 있습니다.
배포 시
다음 목록은 배포를 계획할 때 고려해야 할 사항을 보여줍니다.
- GPU 작업자 풀은 자동 확장할 수 없습니다. GPU가 프로세스를 실행하지 않아도 GPU 요금이 청구됩니다.
- 작업자 풀의 CPU 및 메모리는 서비스 및 작업과 가격이 다릅니다. 하지만 GPU SKU의 가격은 서비스 및 작업과 동일합니다.
런타임
- 지원되는 컨텍스트 길이를 적극적으로 관리합니다. 지원하는 컨텍스트 창이 작을수록 더 많은 쿼리를 동시에 실행할 수 있습니다. 자세한 방법은 프레임워크에 따라 다릅니다.
- 빌드 시간에 생성한 LLM 캐시를 사용합니다. 프롬프트 및 프리픽스 캐시를 생성할 때 빌드 시간 중에 사용한 것과 동일한 플래그를 제공합니다.
- 방금 작성한 저장된 모델에서 로드합니다. 모델 로드 방법에 대한 비교는 모델 저장과 모델 로드의 장단점을 참조하세요.
- 프레임워크에서 지원하는 경우 양자화된 키-값 캐시를 사용하는 것이 좋습니다. 이렇게 하면 쿼리당 메모리 요구사항이 줄어들고 동시 로드를 더 많이 구성할 수 있습니다. 하지만 품질에 영향을 미칠 수도 있습니다.
- 모델 가중치, 활성화, 키-값 캐시를 위해 예약할 GPU 메모리 양을 조정합니다. 메모리 부족 오류가 발생하지 않도록 최대한 높게 설정합니다.
- 프레임워크에 컨테이너 시작 성능을 개선할 수 있는 옵션이 있는지 확인합니다(예: 모델 로드 동시 로드 사용).
시스템 디자인 수준:
- 적절한 위치에 시맨틱 캐시를 추가합니다. 경우에 따라서는 전체 쿼리와 응답을 캐싱하여 일반적인 쿼리의 비용을 효과적으로 제한할 수 있습니다.
- 프리앰블의 분산을 제어합니다. 프롬프트 캐시는 프롬프트가 순차적으로 포함된 경우에만 유용합니다. 캐시는 사실상 프리픽스 캐시로 처리됩니다. 시퀀스에 삽입 또는 수정이 있으면 캐시되지 않았거나 일부만 표시된다는 의미입니다.