Amazon SageMaker 인스턴스 선호 목록, 수동 GPU 재시도는 대체하지만 용량 계획까지 대체하지는 않아

Amazon은 Amazon SageMaker 인스턴스 선호 목록을 도입했다. 이제 하나의 훈련 요청에 고정된 인스턴스 유형 하나 대신, 우선순위가 정해진 최대 5개의 컴퓨팅 옵션을 포함할 수 있다. SageMaker AI는 이 옵션들을 우선순위 순으로 확인하고, 용량이 उपलब्ध한 첫 번째 구성을 실행한다.

이번 변경은 지속적인 운영 문제를 겨냥한다. GPU 기반 SageMaker 훈련 작업은 요청한 하드웨어를 사용할 수 없을 때 대기 상태에 머무를 수 있다. 이에 따라 팀들은 용량을 모니터링하거나 작업을 다시 제출하고, 대체 구성을 시도하는 스크립트를 유지해 왔다.

AWS는 이제 이 재시도 결정을 관리형 스케줄러로 옮긴다. 다만 이 기능이 GPU 용량을 새로 만들거나, 서로 다른 가속기가 워크로드를 올바르게 실행할 수 있음을 보장하는 것은 아니다. 그 가치는 팀이 훈련 코드, 성능 목표, 비용 제어를 실제로 하드웨어 유연하게 만들 수 있는지에 달려 있다.

이러한 구분은 친숙한 클라우드 관행에 압박을 가한다. 즉, 인스턴스 유형을 모든 작업의 고정 속성으로 간주하는 방식이다. Google Cloud는 이미 Dynamic Workload Scheduler를 통해 유연한 가속기 요청을 대기열에 넣고 있다. Azure Machine Learning 사용자 역시 리전 및 제품군별 컴퓨팅 할당량을 기준으로 계획을 수립한다. AWS는 이제 선언된 하드웨어 유연성을 개별 SageMaker 작업의 핵심 요소로 만들고 있다.

Amazon SageMaker 인스턴스 선호 목록으로 AWS가 바꾼 점

이제 하나의 SageMaker 요청에서 외부 재시도 컨트롤러 없이 여러 개의 허용 가능한 컴퓨팅 구성을 표현할 수 있다.

AWS는 2026년 9월 15일 훈련 및 처리 작업 모두에 이 기능을 발표했다. 회사의 리전별 제공 현황 공지에 따르면, SageMaker AI를 사용할 수 있는 모든 AWS 리전에서 SageMaker API, SDK, 명령줄 도구, 콘솔을 통해 이용할 수 있다.

선호 목록에는 우선순위 순서대로 2개에서 5개의 인스턴스 유형을 포함할 수 있다. SageMaker는 목록을 검증하고, 메모리 내 스위프를 수행한 뒤, 사용 가능한 용량을 보유한 첫 번째 구성을 선택한다. 목록에 포함된 구성 중 하나만 작업을 실행한다.

즉시 사용할 수 있는 옵션이 없다면 작업은 이벤트 기반 대기열에 들어간다. SageMaker는 클라이언트 프로세스가 서비스를 폴링하고 요청을 재제출할 필요 없이, 용량 변화에 따라 재시도한다. 총 대기 시간은 MaxPendingTimeInSeconds로 제한할 수 있다.

이 시간 제한은 각 옵션에 개별적으로 적용되는 것이 아니라 전체 선호 목록에 적용된다. AWS는 또한 ml.p, ml.g, ml.trn과 같은 제품군의 가속 컴퓨팅을 목록의 구성 중 하나 이상이 사용할 때에만 이 설정이 적용된다고 설명한다.

이 동작이 중요한 이유는 선호 항목이 단순한 대체 인스턴스 이름 이상이기 때문이다. 팀은 각 옵션에 서로 다른 인스턴스 수를 할당할 수 있다. 예를 들어 작업은 두 개의 ml.g6.48xlarge 노드를 선호하되, 두 번째 구성이 충분한 총 처리량을 제공한다면 네 개의 ml.g5.48xlarge 노드를 수용할 수 있다.

AWS는 두 가지 개수 모델을 허용한다. 공통 ResourceConfig.InstanceCount를 모든 선호 항목에 적용하거나, 각 선호 항목이 자체 인스턴스 수를 정의할 수 있다. API 참조 문서에서 설명하듯, 이 두 방식을 혼용하는 것은 유효하지 않다.

이 기능은 지정된 기간 동안 지원되는 GPU 용량을 예약하는 SageMaker Flexible Training Plans와도 연동된다. 훈련 작업은 일치하는 플랜 기반 구성을 첫 번째에 두고, 그 뒤에 온디맨드 대안을 나열할 수 있다. 예약된 옵션을 프로비저닝할 수 없으면 SageMaker는 남은 선호 항목을 순서대로 진행한다.

이 통합은 훈련에만 적용된다. 처리 작업도 동일한 순서 기반 폴백 메커니즘을 제공받지만, 선호 항목을 Flexible Training Plans와 연결할 수는 없다.

그럼에도 처리 사용 사례는 중요하다. SageMaker Processing은 데이터 준비, 특성 엔지니어링, 평가 및 관련 작업을 위한 관리형 인프라를 실행한다. 이러한 작업은 정교하게 최적화된 분산 훈련 작업보다 더 넓은 하드웨어 범위를 허용하는 경우가 많다.

AWS는 출시 게시물에서 이 변경을 수동 재시도 루프와 용량 모니터링 스크립트의 대안으로 제시한다. 이것이 가장 분명한 즉각적 이점이다. 파이프라인은 하나의 작업을 제출하고, SageMaker는 선언된 경계 내에서 용량 탐색을 담당한다.

스케줄러가 동등하다고 판단한 임의의 머신을 선택하는 것은 아니다. 고객이 지정한 순서를 따른다. 이는 유용한 책임 분담을 유지한다. 운영자는 어떤 구성이 유효한지 결정하고, SageMaker는 유효한 옵션 중 어느 것이 먼저 시작할 수 있는지 결정한다.

이는 작은 API 변경이지만 더 큰 운영상의 함의를 지닌다. 이제 인프라 유연성은 주변 오케스트레이션 코드에 머무르지 않고 작업 정의와 함께 이동할 수 있다.

SageMaker GPU 용량이 스케줄러 문제가 된 이유

희소한 자원은 더 이상 단순한 GPU가 아니라, 적절한 리전에서 적절한 시점에 확보할 수 있는 올바른 클러스터 구성이다.

AI 훈련 팀은 흔히 가속기를 상호 교환 가능한 단위로 논의하지만, 클라우드 용량은 인스턴스 제품군, 크기, 리전, 가용성 풀, 할당량, 예약 모델 전반에 걸쳐 나뉜다. 고객은 특정 머신을 요청할 권한이 있어도, 해당 머신이 즉시 할당 가능한 상태는 아닐 수 있다.

이러한 분절은 불편한 실패 처리를 만든다. 파이프라인은 기술적으로 올바르더라도 선택한 구성을 시작할 수 없어 몇 시간을 잃을 수 있다. 그러면 엔지니어는 기다릴지, 하드웨어를 바꿀지, 노드 수를 변경할지, 워크로드를 옮길지를 결정해야 한다.

선호 목록 도입 전에는 SageMaker 훈련 작업이 제출 시 하나의 인스턴스 유형만 지정했다. 대안을 수용한 팀들은 그 유연성을 다른 위치에 코드로 구현해야 했다. 일부는 API 실패를 중심으로 재시도 함수를 구축했고, 다른 일부는 여러 변형을 제출한 뒤 하나가 시작되면 나머지를 취소했다.

두 패턴 모두 조정 작업을 추가한다. 여러 개의 활성 요청은 관측성과 취소를 복잡하게 만들 수 있다. 순차 재시도 스크립트에는 상태 관리, 백오프 규칙, 시간 제한 처리, 권한, 중복 실행 방지 기능이 필요하다.

용량 모니터링 역시 또 하나의 프로덕션 시스템이 된다. 팀은 SDK 동작이 바뀔 때 이를 유지보수하고, 장애를 노출하며, 재시작된 컨트롤러가 같은 고비용 작업을 두 번 실행하지 않도록 보장해야 한다.

Amazon SageMaker 인스턴스 선호 목록은 이 제어 플레인의 일부를 흡수한다. 작업 요청에는 허용 가능한 결과의 제한된 집합이 담기고, 관리형 서비스는 용량이 확보되면 선택을 수행한다.

이 모델은 실제 워크로드가 작동하는 방식과 맞닿아 있다. 파인튜닝, 평가, 전처리, 모델 실험은 수학적으로 반드시 필요한 구성 하나가 아니라 선호 구성을 갖는 경우가 많다. 팀은 속도를 위해 최신 GPU를 선호하되, 시작 시간이 더 중요할 때는 구형 GPU를 수용할 수 있다.

같은 원칙은 노드 수에도 적용된다. 더 빠른 두 개의 노드와 더 느린 네 개의 노드는 때로 비슷한 완료 목표를 충족할 수 있다. 이들이 본질적으로 동등한 것은 아니지만, 개발자는 이를 테스트하고 둘 다 허용 가능하다고 선언할 수 있다.

AWS만이 희소성을 스케줄링 인터페이스로 전환하는 것은 아니다. Google Cloud의 Flex-start 모드는 필요한 모든 리소스를 사용할 수 있을 때까지 가속기 요청을 대기열에 넣는다. Google은 이를 유연한 시작 시간을 허용할 수 있는 훈련 작업용으로 제시한다.

메커니즘은 다르다. Google의 모델은 요청된 가속기 할당과 기간의 충족을 강조한다. AWS는 하나의 SageMaker 작업이 정렬된 유형 및 개수 집합을 순차적으로 이동하도록 한다. 두 접근법 모두 고객이 용량을 반복적으로 탐색하는 대신 유연성을 표현하도록 요구한다.

Azure Machine Learning은 제약의 또 다른 측면을 드러낸다. 컴퓨팅 할당량은 리전 및 VM 제품군별로 관리되며, 워크스페이스와 구독 사용에 별도 한도가 적용된다. 구독에 따라 GPU 제품군은 기본 전용 코어 할당량 없이 시작할 수 있다.

이러한 시스템은 가속기 가용성을 카탈로그 페이지로 축소할 수 없는 이유를 보여 준다. 나열된 인스턴스는 지원될 수 있지만, 특정 계정, 위치, 작업 규모 또는 시간대에는 사용할 수 없을 수 있다.

AWS 고객에게는 맞춤형 프로비저닝 로직을 유지하는 팀에 즉각적인 압박이 가해진다. 재시도 서비스가 SageMaker 인스턴스 유형만 순환한다면, 이제 그 핵심 기능은 플랫폼과 겹친다.

이 기능은 모델별로 정확히 하나의 인스턴스 유형만 승인하는 경직된 내부 표준에도 압박을 가한다. 이러한 표준은 벤치마킹과 거버넌스를 단순화했지만, 모든 용량 부족을 차단 요인으로 만들었다. 이제 팀은 각 워크로드에 여러 구성을 인증할 이유가 생겼다.

이것이 오케스트레이션을 없애는 것은 아니다. 파이프라인에는 여전히 종속성, 아티팩트 추적, 실패 정책, 실행 후 검증이 필요하다. 이번 변경은 반복되는 한 가지 결정, 즉 허용 가능한 구성 중 어느 것이 시작할 수 있는지를 SageMaker 자체로 옮겨 오케스트레이션의 역할을 좁힌다.

유연성은 재시도 로직을 대체할 뿐, 용량 제약을 대체하지는 않는다

이 메커니즘은 사용 가능한 인프라 탐색을 개선하지만, 존재하지 않는 인프라를 제공할 수는 없다.

작업이 도착하면 SageMaker는 지원되는 리소스와 제한 사항을 기준으로 구성 및 선호 목록을 검증한다. 이후 스케줄러는 선언된 순서에 따라 옵션을 한 번 확인한다. 사용 가능한 첫 번째 옵션이 선택되고 프로비저닝을 시작한다.

모든 옵션을 사용할 수 없다면 이벤트 기반 대기열은 관련 용량 변경을 기다린다. 이는 지속적인 고객 폴링보다 효율적이지만, 여전히 대기열이다. 작업은 시간 제한이 만료될 때까지 대기 상태로 남을 수 있다.

이 경계는 이 기능이 작업의 더 빠른 시작을 돕는다는 AWS의 주장을 평가할 때 중요하다. 비교 대상은 사용할 수 없는 단일 구성에 고정된 작업이나, 더 느린 고객 관리형 재시도 시스템이다. AWS는 리전, 인스턴스 제품군 또는 클러스터 규모 전반의 중앙값 시작 시간 개선을 보여 주는 독립 벤치마크를 공개하지 않았다.

목록은 여러 항목에서 부분 용량을 결합하지도 않는다. 선호 항목이 8개 노드를 요청한다면 SageMaker는 선택된 구성을 프로비저닝할 수 있어야 한다. 시스템은 사용 가능한 조각으로 이기종 클러스터를 조립하는 대신, 하나의 완전한 선호 항목을 선택한다.

이는 인스턴스 선호 항목과 SageMaker 이기종 클러스터를 구분한다. 이기종 클러스터는 하나의 훈련 작업 안에서 여러 인스턴스 그룹을 의도적으로 실행한다. 선호 목록은 상호 배타적인 대안을 나타내며, 그중 하나만 작업의 컴퓨팅 환경이 된다.

이 구분은 실행 일관성을 보호한다. 분산 훈련 프레임워크는 보통 작업이 시작된 뒤 알려진 토폴로지를 기대한다. 하나의 사전 정의된 구성을 선택하는 편이 하드웨어 아키텍처, 네트워크 특성, 메모리 프로필을 동적으로 혼합하는 것보다 단순하다.

Training Plan 통합은 또 하나의 의사결정 계층을 추가한다. 선호 항목은 일치하는 예약 플랜을 가리킬 수 있고, 이후 항목은 온디맨드 용량을 사용할 수 있다. 운영자가 예약 옵션을 첫 번째에 배치하면 AWS는 해당 옵션을 먼저 평가한다.

그 순서는 조직이 선불 용량을 우선 활용하되, 그것만이 작업의 유일한 경로가 되지는 않도록 하는 직접적인 방법을 제공한다. 다만 대체 경로는 경제적 결과를 바꿀 수 있다. 온디맨드 대안은 실질 비용이 다를 수 있으며, 노드 수가 많아지면 그 차이가 커질 수 있다.

이 기능은 Managed Spot Training을 대체하려는 것으로도 보이지 않는다. Managed Spot Training은 중단 가능한 EC2 Spot 용량을 사용해 다른 절충점을 다룬다. AWS는 이 방식이 컴퓨팅 비용을 줄일 수 있지만, 중단으로 인해 완료 시간이 길어지고 체크포인팅이 필요할 수 있다고 설명한다.

인스턴스 선호도는 주로 허용 가능한 구성 전반에서 초기 용량을 선택하는 문제를 다룬다. Spot Training은 워크로드가 컴퓨팅 자원을 확보한 뒤의 구매 모델과 중단 위험을 다룬다. 팀은 이 두 차원을 별도로 평가해야 한다.

따라서 가장 적합한 대상은 재시작에는 민감하지만 하드웨어에는 유연한 작업이다. 여러 GPU 세대에서 실행할 수 있는 야간 평가 파이프라인을 생각해 보자. 아침 보고 시간대를 놓치는 일은 중요하지만, 반드시 가장 빠른 가속기를 사용해야 하는 것은 아니다.

팀은 여러 구성을 검증하고, 완료 시간과 예상 비용의 선호 균형에 따라 순서를 정한 뒤, 최대 대기 시간을 설정할 수 있다. SageMaker는 검증된 이 범위 내에서 선택한다.

대규모 사전 학습 실행은 더 어려운 경우다. 통신 패턴, 메모리 요구 사항, 체크포인트 동작, 토폴로지가 특정 가속기와 인터커넥트에 맞춰 조정되어 있을 수 있다. 명목상 지원되는 대체 구성도 작업을 더 느리게 만들거나, 비용을 높이거나, 불안정하게 만들 수 있다.

새 스케줄러는 그 대체 구성이 과학적으로나 경제적으로 계속 유효한지 판단할 수 없다. 그 판단은 워크로드 소유자에게 남는다.

따라서 Amazon SageMaker 인스턴스 선호도 목록은 넓은 의미에서 적응형이 아니라 선언형이다. SageMaker는 용량 신호에 반응하지만, 모델을 벤치마크하거나 분산 설정을 다시 작성하거나 마감 시한에 맞춰 목록을 최적화하지는 않는다.

그럼에도 이는 의미가 있다. 관리형 서비스는 모든 고객이 반복적으로 수행하는, 범위가 명확한 책임을 가져와 한 번 구현할 때 가치를 만든다. 고객이 정직한 호환성 경계를 제공한다면 용량 대체는 이 패턴에 부합한다.

호환성과 비용은 여전히 운영자의 책임이다

가장 중요한 위험은 SageMaker가 잘못된 선호도를 선택하는 것이 아니라, 팀이 안전하지 않은 선호도를 허용 가능한 것으로 선언하는 데 있다.

AWS는 SageMaker가 인스턴스 유형 간 호환성을 검증하지 않는다고 명시적으로 경고한다. 이 서비스는 컨테이너가 모든 GPU 아키텍처를 지원하는지, 드라이버가 일치하는지, 또는 분산 구성이 Elastic Fabric Adapter 네트워킹을 필요로 하는지를 판단하지 않는다.

따라서 작업은 요청 검증을 통과하더라도 프로비저닝 후 실패할 수 있다. 이 경우 시작 시간이 소모되고 자동 대체가 제공할 것으로 기대한 이점도 약화될 수 있다.

프레임워크 동작에는 특히 주의가 필요하다. CUDA 기능, 집단 통신 라이브러리, 혼합 정밀도 형식, 컴파일러 출력, 디바이스별 커널은 가속기 세대에 따라 달라질 수 있다. H100 하드웨어에서 테스트한 컨테이너가 A100 또는 L40S 하드웨어에서도 동일하게 동작한다고 가정해서는 안 된다.

메모리 역시 또 다른 경계다. 한 가속기에 맞는 워크로드가 이론적 총 처리량이 비슷해 보여도 다른 가속기에서는 디바이스 메모리를 초과할 수 있다. 노드 수를 늘린다고 해서 디바이스별 메모리 제약이 자동으로 해결되지는 않는다.

분산 토폴로지도 성능에 영향을 미친다. 고대역폭 노드 2개를 더 느린 노드 4개로 교체하면 통신량, 동기화 오버헤드, 실패 노출도가 달라진다. GPU 수가 같거나 컴퓨팅 성능 추정치가 비슷하다고 해서 완료 시간까지 같다는 보장은 없다.

AWS의 예시는 보편적인 등가 공식이 아니라 의도를 보여준다. 한 예시에서는 ml.g6.48xlarge 인스턴스 2개를 ml.g5.48xlarge 인스턴스 4개보다 앞에 나열한다. 이 관계가 해당 모델, 배치 크기, 네트워킹 패턴, 소프트웨어 스택에도 성립하는지는 고객이 판단해야 한다.

팀은 프로덕션에서 사용하는 동일한 컨테이너 이미지, 데이터 경로, 분산 실행 프로그램으로 목록에 포함된 모든 구성을 벤치마크해야 한다. 그 결과 승인 기록에는 실행 시간, 수렴 확인, 활용률, 실패율, 출력 검증이 포함되어야 한다.

비용 정책에도 같은 수준의 규율이 필요하다. 선호도 순서는 우선순위를 표현할 뿐 예산 상한을 뜻하지는 않는다. 더 많은 인스턴스를 사용하는 대체 구성은 더 빨리 시작할 수 있지만, 선호 옵션보다 총 청구액이 커질 수 있다.

반대로 오래된 하드웨어는 실행 시간이 길어져 인스턴스당 절감 효과가 사라질 수 있다. 관련 측정 기준은 시작 지연, 실행 시간, 재시도, 스토리지, 이후 마감 시한에 미치는 영향을 포함한 전체 작업 결과다.

이번 출시는 관측 가능성 요건도 만든다. 팀은 어떤 선호도가 선택되었는지, 작업이 얼마나 기다렸는지, 대안이 왜 해당 순서로 배치되었는지, 실제 성능이 벤치마크와 일치했는지를 기록해야 한다.

이런 기록이 없다면 자동 선택은 불투명해진다. 엔지니어는 실행 간 인스턴스 패밀리가 바뀌었다는 사실을 모른 채 실행 시간이나 비용의 변동성이 커졌다고만 볼 수 있다.

거버넌스 규칙도 업데이트가 필요할 수 있다. AWS는 SageMaker 인스턴스 유형을 제한하는 ID 정책을 지원한다. 조직의 승인된 선호도 목록은 이러한 통제, 계정 할당량, 리전별 가용성 범위 안에 있어야 한다.

예약 용량도 오해를 낳을 수 있다. Flexible Training Plan 선호도는 더 강한 용량 약정을 제공할 수 있지만, 대체 경로가 사용할 수 없는 예약을 더 많은 예약 공급으로 바꾸지는 않는다. 대신 작업을 별도로 허용 가능한 온디맨드 경로로 이동시킨다.

처리 작업은 별도의 검토가 필요하다. 일부 변환 작업에는 CPU 대체 구성이 적절할 수 있지만, 완료 시간을 크게 바꿀 수도 있다. API가 허용한다는 이유만으로 CPU 옵션을 목록에 추가해서는 안 된다.

현재 가장 큰 불확실성은 공개된 현장 데이터가 없다는 점이다. AWS는 스케줄링 흐름과 구성 규칙을 설명했지만, 고객은 서로 다른 부족 조건에서 시작 시간 개선 효과에 관한 폭넓은 근거를 아직 갖고 있지 않다.

유용한 측정은 이 기능을 각 팀의 기존 기준선과 비교해야 한다. 여기에는 제출부터 실행까지 걸리는 시간, 대체 구성을 사용하는 작업의 비율, 타임아웃 비율, 총 컴퓨팅 소비량, 구성 변경으로 발생한 운영 사고가 포함된다.

이 측정값은 SageMaker GPU 용량 유연성이 실제 운영 부담을 줄이는지, 아니면 변동성을 덜 보이는 계층으로 옮길 뿐인지를 보여줄 것이다.

기능이 실제로 작동하는지 보여줄 세 가지 신호

도입 성과는 구성에 두 번째 인스턴스 유형을 추가한 팀의 수가 아니라 작업 결과로 판단해야 한다.

첫 번째 신호는 시작 시간과 함께 보는 대체 선택 빈도다. 팀은 SageMaker가 첫 번째 선호도보다 낮은 옵션을 얼마나 자주 선택하는지, 그리고 그것이 제출부터 시작까지의 지연 시간을 어떻게 바꾸는지 측정해야 한다.

대기 시간이 짧아지면서 대체 선택 비율이 높다면 AWS의 핵심 주장을 뒷받침한다. 선호 유형이 제약을 받을 때에도 더 넓은 풀에는 용량이 존재한다는 점을 보여줄 것이다.

대기 시간이 줄지 않은 채 대체 선택 비율만 높다면 이 주장은 약화된다. 나열된 대안이 같은 리전 병목을 공유하거나, 요청한 클러스터가 너무 크거나, 이벤트 기반 큐가 해당 워크로드의 처리 충족도를 실질적으로 개선하지 못한다는 의미일 수 있다.

두 번째 신호는 선택된 구성별 성능과 비용의 변동성이다. 모든 대체 선택은 실행 시간, 활용률, 완료 상태, 총 리소스 소비량과 연결되어야 한다.

결과가 안정적이라면 인프라를 선호도 집합으로 다루자는 주장이 강화될 것이다. 큰 편차가 나타난다면 각 구성이 기술적으로 컨테이너를 실행할 수 있었더라도, 그 대안들이 실제로 동등하지 않았음을 보여준다.

이는 반복 파이프라인에서 특히 중요하다. 팀은 긴급 실험에서 한 번의 느린 실행은 받아들일 수 있지만, 일일 프로덕션 일정에서 지속적인 예측 불가능성은 받아들이지 않을 수 있다.

세 번째 신호는 AWS가 이 기능과 주변 텔레메트리를 어떻게 확장하는지다. 고객은 더 풍부한 선택 이벤트, 더 명확한 대기 상태 설명, 비용을 고려한 순서 지정 도구, 파이프라인 제어 기능과의 더 폭넓은 통합을 주시해야 한다.

더 세밀한 정책 지원도 중요할 것이다. 운영자는 궁극적으로 마감 시한, 지출 한도, 또는 대체 구성 처리량이 검증된 범위 안에 있어야 한다는 요구 사항 같은 제약을 원할 수 있다. 현재의 순서형 목록은 이러한 판단을 수동으로 인코딩한다.

경쟁사의 대응은 보조적인 맥락을 제공하지만, 결정적인 근거는 고객 운영에서 나올 것이다. Google은 이미 Dynamic Workload Scheduler를 통해 가속기 부족을 스케줄링 문제로 다룬다. Azure는 관리형 작업 실행 가능 여부를 좌우하는 할당량 경계를 노출한다.

AWS의 차별점은 여러 허용 가능한 구성을 SageMaker 학습 또는 처리 요청 안에 직접 넣는다는 데 있다. 고객이 허용할 수 없는 변동성 없이 더 빠른 시작을 달성한다면, 이 모델은 관리형 ML 플랫폼이 무시하기 어려워질 것이다.

단기적인 검증 방법은 간단하다. 하드웨어에 유연한 워크로드 하나를 선택하고, 모든 후보 구성을 벤치마크한 뒤, 자동 대체를 활성화하기 전에 최대 대기 시간을 정의하라. 이후 기존 재시도 프로세스와 최소 여러 차례의 실행을 비교하라.

선택된 인스턴스 유형, 큐 대기 시간, 실행 시간, 완료 상태, 총 리소스 사용량을 기록하라. 성공적으로 시작되었다는 사실만으로 전체 결과를 판단해서는 안 된다.

Amazon SageMaker 인스턴스 선호도 목록은 용량 관리를 덜 수동적으로 만들지만, 준비된 팀에 더 큰 가치를 준다. 대안을 검증한 팀은 취약한 인프라 코드를 제거할 수 있다. 추측에 기반한 대체 구성을 입력한 팀은 비호환성 발견만 자동화하게 될 수 있다.

유용한 질문은 다섯 가지 옵션이 하나보다 나은지 여부가 아니다. 조직이 진정으로 허용 가능한 다섯 가지 결과를 정의하고, 의도적으로 순위를 매기며, SageMaker가 그중에서 선택할 때 무엇이 일어나는지 측정할 수 있는지다.