SageMaker Inference now supports Multi-Instance GPU to maximize GPU utilization for model endpoints

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker Inference가 NVIDIA Multi-Instance GPU(MIG)를 지원해, inference components 기반 엔드포인트에서 GPU를 하드웨어로 격리된 파티션으로 나누고 모델에 필요한 용량을 배정할 수 있게 됐다.

📌 핵심 요약

• 기존에는 모델 배포 시 GPU 전체가 최소 할당 단위여서, A100 8개를 갖춘 ml.p4d.24xlarge도 모델별 메모리 요구량이 40 GB든 14 GB든 8개 모델만 수용했다. MIG 지원으로 GPU 수보다 많은 모델을 배치하고 최신 GPU의 일부 용량을 선택할 수 있다.
• MIG 파티션은 연산 자원, 캐시, 메모리와 메모리 대역폭을 독립적으로 제공한다. 원문은 이를 통해 예측 가능한 지연시간, 장애·테넌트 격리, 모델 상주에 따른 콜드 스타트 방지, 모델·팀·테넌트별 비용 배분이 가능하다고 설명한다.
• GPU 파티셔닝은 inference components를 사용하는 엔드포인트에 적용되며, 단일 모델 엔드포인트·서버리스 엔드포인트·이기종 인스턴스 풀에는 적용되지 않는다. 파티션 수는 GPU별로 최대 7개이고 레이아웃은 엔드포인트 생성 시 선택하며, GPU 여러 개가 필요한 모델은 여전히 전체 GPU를 사용해야 한다.
• 기존 API에 AcceleratorPartitionLayouts와 AcceleratorPartitionType을 추가해 레이아웃과 모델별 파티션을 지정한다. ml.p4d.24xlarge의 A100마다 mig-4g.20gb·mig-2g.10gb·mig-1g.5gb를 배치하면 총 24개 파티션이 생기며, 테스트에서 GPU 분할은 프로비저닝에 약 17초를 추가했다.
• P4d·P5·G7·G7e는 지원 프로파일과 연산·메모리 분할 단위가 달라 GPU별 검증이 필요하다. P4d의 mig-1g.10gb는 R525 이상 드라이버가 필요하며 기본 이미지의 470.256.02에서는 실패한다. 제공된 원문은 prefill의 연산 자원 요구를 설명한 뒤 메모리 역할 설명 도중 끊겨, 구체적인 비용 비교 결과는 포함하지 않는다.

🧩 주요 포인트

1. GPU 전체 할당에서 파티션 할당으로 선택지가 세분화된다 → 모델 밀도를 높이고 모델 요구량에 맞는 용량을 선택할 수 있지만, 실제 비용 절감 규모는 제공된 원문만으로 확인할 수 없다.
2. 하드웨어 격리와 SageMaker의 구성·배치·확장 관리가 결합된다 → 공유 GPU의 성능 간섭과 자체 Kubernetes 운영 부담을 줄일 수 있으나, inference components 적용 조건과 생성 시 레이아웃 선택이라는 제약을 고려해야 한다.
3. 프로파일은 연산과 메모리를 정해진 비율로 묶는다 → GPU별 지원 여부·자원 합계·드라이버 조건을 충족하는 것과 prefill 등 워크로드에 적합한 용량을 고르는 것은 별도의 판단이다.

🧠 상세 정리

1. GPU 전체 할당이 만드는 모델 수와 용량 선택의 제약

기존 GPU 엔드포인트에서 요청할 수 있는 최소 단위는 가속기 한 개 전체이므로, 모델이 GPU 자원을 일부만 필요로 해도 전체 장치를 배정해야 했다. 예를 들어 ml.p4d.24xlarge는 A100 8개를 제공하지만, 각 모델이 40 GB를 쓰든 14 GB를 쓰든 원문이 설명하는 기존 방식에서는 모델 8개만 수용한다. 또 동시 요청 수와 프롬프트 길이가 늘어나면 이전 세대 GPU 전체로는 부족하지만 최신 GPU 전체는 과도한 상황이 생겨, 처리 용량 부족과 사용하지 못하는 용량에 대한 지출 사이에서 선택해야 한다. Amazon SageMaker Inference의 GPU 파티셔닝은 물리 GPU를 독립된 여러 조각으로 나누어 각 파티션에 서로 다른 모델을 배치하고, 최신 가속기의 일부만 선택하는 방식으로 이 두 제약을 완화한다.

2. 기존 세 가지 운영 방식과 각각의 한계

가속기보다 모델 수가 많을 때 사용하던 첫 번째 방법은 더 적고 큰 엔드포인트에 작업을 모으고 배치를 강화하는 것으로, 모델들이 서로 대체 가능할 때는 활용률을 높일 수 있다. 그러나 미세 조정된 여러 변형 모델이나 테넌트별 모델처럼 모델을 서로 바꿔 쓸 수 없는 구성에는 이 접근이 맞지 않는다. 두 번째인 다중 모델 엔드포인트는 공유 GPU에 모델을 필요할 때 올리고 내리므로 드물고 순간적으로 몰리는 트래픽에 적합하지만, 무거운 요청이 다른 모델에 영향을 주고 미적재 모델의 첫 요청에는 로딩 지연이 발생한다. 세 번째인 자체 관리 Kubernetes에서는 MIG를 사용할 수 있지만, 드라이버 버전·파티션 구성·디바이스 플러그인·스케줄링을 관리하고 여러 인스턴스에서 일관성을 유지하는 운영 부담을 사용자가 맡는다.

3. MIG가 제공하는 자원 전용성과 하드웨어 격리

NVIDIA Multi-Instance GPU는 GPU 종류에 따라 물리 GPU 하나를 최대 7개 인스턴스로 나누며, 각 인스턴스에 독립된 연산 자원·캐시·메모리·메모리 대역폭을 제공한다. 원문은 전용 메모리 대역폭 덕분에 한 모델의 트래픽 급증이 다른 모델의 p99 지연시간에 나타나지 않고, 충돌이나 메모리 오류도 해당 파티션 안에 격리된다고 설명한다. 각 모델이 자신의 파티션에 계속 적재되므로 모델 로딩이나 축출에 따른 지연이 없고, 작은 모델과 중간 크기 모델에는 필요한 크기의 파티션을 배정하면서 한 장치 안에 서로 다른 크기를 섞을 수도 있다. 하드웨어가 파티션 사이의 메모리 보호를 강제한다는 점은 테넌트 격리와 보안·규정 준수 검토에 도움이 되며, 이웃 모델과 무관한 성능 특성은 부하 테스트를 통한 운영 예측과 모델·팀·테넌트별 비용 배분을 뒷받침한다.

4. 관리형 지원의 범위와 Salesforce의 검증 단계

SageMaker AI에서는 사용자가 모델의 파티션 프로파일을 선택하면 서비스가 GPU 구성·배치·확장을 처리하므로, MIG를 쓰기 위해 Kubernetes 기반 플랫폼을 직접 운영할 필요가 줄어든다. 다만 이 기능은 여러 모델의 배포와 자원 배정을 정의하는 inference components를 사용하는 엔드포인트에 적용되며, 단일 모델 엔드포인트·서버리스 엔드포인트·이기종 인스턴스 풀은 지원 대상이 아니다. MIG 레이아웃은 파티션이 유휴 상태일 때만 변경할 수 있고 SageMaker AI에서는 엔드포인트 생성 시 선택해야 하며, GPU 여러 개가 필요한 모델에는 여전히 전체 장치가 필요하다. Salesforce는 요구사항 정의와 초기 구현 검증에 참여했으며, 인용문에서는 대표적인 프로덕션 워크로드를 이용한 검증을 준비 중이라고 밝혀 활용률·비용·성능 개선에 대한 기대와 실제 운영 검증의 진행 단계를 구분한다.

5. 기존 API에 추가된 레이아웃 지정 방식

GPU 파티셔닝은 새로운 API 작업이나 리소스 유형, AWS Identity and Access Management(IAM) 작업을 만들지 않고 기존 호출에 선택 필드 두 개를 추가하는 방식이며, 두 필드를 모두 생략한 엔드포인트는 기존과 동일하게 동작한다. 첫 번째 필드인 AcceleratorPartitionLayouts는 CreateEndpointConfig의 프로덕션 변형에 들어가 각 가속기를 어떻게 나눌지 선언한다. 예시에서는 ml.p4d.24xlarge의 A100마다 mig-4g.20gb·mig-2g.10gb·mig-1g.5gb를 하나씩 배치해 7개 연산 슬라이스를 모두 사용하고, A100 8개 전체에서 유형별 8개씩 총 24개 파티션을 만든다. 이 레이아웃은 해당 변형의 모든 인스턴스에 있는 모든 가속기에 동일하게 적용되며, 레이아웃 목록의 항목 순서가 특정 GPU를 지정하는 방식은 아니다.

6. 컴포넌트 배치·복제와 프로비저닝 동작

두 번째 필드인 AcceleratorPartitionType은 inference component의 ComputeResourceRequirements에 들어가 모델이 사용할 파티션 유형을 선택하며, 컴포넌트 복사본 하나가 요청한 유형의 파티션 하나를 차지한다. CopyCount를 늘리면 빈 파티션에 복사본이 추가되는데, 원문은 단일 프로세스가 GPU를 충분히 활용하지 못하면서 높은 동시 요청을 처리해야 하는 작은 모델에 이 방식이 유용하다고 설명한다. 파티션 유형을 지정할 때 NumberOfAcceleratorDevicesRequired는 항상 1이며 전체 가속기가 아닌 파티션 하나를 뜻하고, NumberOfCpuCoresRequired와 MinMemoryRequiredInMb는 계속 호스트 CPU와 호스트 메모리를 가리킨다. InvokeEndpoint는 기존처럼 inference component 이름으로 모델을 호출하고 파티션 정보는 요청에 포함하지 않으며, 엔드포인트가 InService에 도달하면 GPU 분할은 끝나 있지만 컴포넌트가 배치되기 전까지 파티션은 비어 있을 수 있다. 원문의 테스트에서 분할 작업은 프로비저닝에 약 17초를 추가했고, 나머지 시간은 일반적인 인스턴스 시작과 컨테이너 이미지 가져오기에 해당했다.

7. GPU별 프로파일과 서로 다른 분할 단위

지원 프로파일은 GPU에 따라 달라지며, P4d의 NVIDIA A100은 40 GB, P5의 NVIDIA H100은 80 GB 메모리를 제공하고 둘 다 연산은 7단위·메모리는 8단위로 나뉘어 GPU당 최대 7개 파티션을 지원한다. G7의 NVIDIA RTX PRO 4500 Blackwell은 32 GB를 연산·메모리 각각 2단위로 나누어 mig-1g.16gb 또는 mig-2g.32gb를 제공하며, 최대 파티션 수는 2개다. G7e의 NVIDIA RTX PRO 6000 Blackwell Server Edition은 96 GB를 각각 4단위로 나누고 mig-1g.24gb·mig-2g.48gb·mig-4g.96gb를 제공하므로 최대 4개 파티션을 구성할 수 있다. 프로파일 이름은 연산 단위와 GPU 메모리를 함께 나타내므로 mig-3g.40gb는 연산 3단위와 메모리 40 GB를 뜻하지만, 같은 슬라이스 수라도 GPU별 이름과 용량이 다르므로 다른 인스턴스 계열의 레이아웃을 그대로 옮겨서는 안 된다. 원문은 전체 프로파일과 한 장치에서 허용되는 조합을 확인할 때 NVIDIA의 지원 MIG 프로파일 문서를 기준으로 삼도록 안내한다.

8. 레이아웃 자원 계산과 P4d 드라이버 주의점

레이아웃은 해당 GPU가 제공하는 프로파일만 사용해야 하며, 포함된 프로파일의 연산 단위 합계와 메모리 단위 합계가 각각 장치 용량을 넘지 않아야 한다. A100과 H100의 3g 프로파일은 연산 7단위 중 3단위와 메모리 8단위 중 4단위를 사용하므로, 두 개를 배치하면 메모리가 가득 차 남은 연산 단위가 있어도 다른 파티션을 추가할 수 없다. 지원 여부와 자원 합계는 엔드포인트 구성 생성 시 검사되며, 조건을 어기면 전체 GPU 할당으로 대체되는 것이 아니라 구성이 거부된다. 별도로 P4d의 mig-1g.10gb는 R525 이상 NVIDIA 드라이버가 필요하지만 기본 이미지는 470.256.02를 사용하므로, 해당 프로파일을 요청하면 프로파일 이름을 명시하는 오류 없이 분할이 실패한다. 원문은 프로덕션 변형의 InferenceAmiVersion을 al2023-ami-sagemaker-inference-gpu-4-1로 설정하면 이 프로파일을 제공하는 580 계열 드라이버 이미지를 사용할 수 있다고 설명한다.

9. 허용되는 레이아웃과 워크로드에 적합한 레이아웃의 차이

원문은 시스템이 받아들이는 유효한 레이아웃을 고르는 일과 실제 워크로드에 적합한 레이아웃을 고르는 일을 별개의 문제로 구분한다. 파티션은 연산과 메모리를 고정된 비율로 제공하고 두 자원이 추론에서 수행하는 역할이 다르기 때문에, 프로파일의 유효성 검사만으로 모델에 맞는 용량 선택이 끝나는 것은 아니라는 설명이다. 제공된 내용에서 prefill은 프롬프트를 읽고 표현을 구성하는 연산 중심 단계이며, 파티션에 배정된 스트리밍 멀티프로세서와 이에 따른 TFLOPs에 비례해 처리 능력이 달라진다. 입력이 길고 동시에 도착하는 프롬프트가 많을수록 이 단계가 첫 토큰 반환 속도를 더 크게 좌우하지만, 원문은 이어지는 메모리 역할 설명 도중 끊겨 그 이후의 분석과 앞부분에서 예고한 구체적인 비용 측정 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 파티셔닝의 가치는 한 GPU에 모델을 더 많이 올리는 데 더해, 이전 세대 GPU 전체와 최신 GPU 전체 사이에 있던 용량 선택의 간극을 줄이는 데 있다.
• MIG의 자원 전용성과 하드웨어 격리는 공유 환경에서도 모델별 성능 예측과 비용 배분을 가능하게 하는 근거지만, 실제 워크로드의 비용 절감 폭은 별도 검증이 필요하다.
• 연산과 메모리의 분할 비율이 다르므로 남는 연산 자원이 곧 추가 모델을 배치할 여유를 뜻하지 않으며, 유효한 프로파일 조합도 워크로드 적합성을 자동으로 보장하지 않는다.

✅ 액션 아이템

• 대상 엔드포인트의 inference components 사용 여부와 단일 모델 엔드포인트·서버리스 엔드포인트·이기종 인스턴스 풀 제외 조건을 확인한다.
• 모델 요구량과 prefill 특성을 기준으로 P4d·P5·G7·G7e의 지원 프로파일, 연산·메모리 자원 합계와 생성 시 레이아웃 제약을 검토한다.
• P4d에서 mig-1g.10gb를 사용할 경우 R525 이상 드라이버 충족 여부를 확인하고, 실제 비용 절감 규모는 별도로 검증한다.

❓ 열린 질문

• inference components 기반 엔드포인트에 MIG를 적용했을 때 실제 워크로드의 GPU 활용률과 비용은 얼마나 개선되는가?
• 동시 요청 수와 프롬프트 길이가 달라질 때 prefill에 적합한 파티션 용량은 어떻게 달라지는가?
• 엔드포인트 생성 시 선택한 레이아웃이 이후 모델 요구량과 맞지 않게 되면 어떤 방식으로 대응해야 하는가?