SageMaker AI, SOCI 인덱스 이미지 지원: 학습 컨테이너 지연 로딩, 이미지 받는 동안 GPU 유휴 시간 최대 90% 감소(AWS)

AWS는 2026년 10월 29일 Amazon SageMaker AI의 학습 및 처리 작업이 SOCI(Seekable OCI) 인덱스가 붙은 컨테이너 이미지를 지원한다고 발표했다. AWS에 따르면 학습 컨테이너가 몇 초 만에 시작되고 이미지를 받는 동안의 GPU 유휴 시간을 최대 90% 줄이며 학습 성능에는 첫 에폭의 일회성 비용을 빼면 영향이 없다. 90%는 AWS 자체 벤치마크에서 나온 ‘최대’ 값이지 모든 작업에 대한 보장이 아니다.

문제는 작업이 시작되기 전에 있다. SageMaker AI는 먼저 컨테이너 이미지 전체를 인스턴스에 내려받고 압축을 풀어 모든 레이어를 기록한다. 딥러닝 이미지는 흔히 10GB를 넘어 작업마다 몇 분이 더해지고 그 시간에도 요금이 붙는다. 수백 개 작업의 하이퍼파라미터 탐색, 짧은 실험, 짧은 처리 작업에서 영향이 크며 내려받기가 전체 실행 시간의 대부분일 수 있다.

SOCI는 오픈 소스 지연 로딩 기술이다. SOCI 인덱스는 이미지 안의 모든 파일을 대응시킨 메타데이터로, OCI 규격 아티팩트로 Amazon ECR에 저장되어 원본 이미지에 연결되므로 이미지 다이제스트와 기존 서명은 그대로 유효하다. 작업의 이미지에 인덱스가 있으면 SageMaker AI는 컨테이너 시작에 필요한 파일만 가져오고 나머지는 코드가 실행되는 동안 백그라운드로 흘려 보낸다. 서비스가 인덱스 유무를 자동으로 확인해 있으면 지연 로딩, 없으면 예전처럼 내려받고, 인덱스를 읽을 수 없거나 지연 로딩이 실패하면 표준 다운로드로 돌아가 작업을 계속한다. 그러니 인덱스를 붙여도 작업이 시작되지 못하는 일은 없다.

도입 방법은 두 가지다. 하나는 AWS가 이미 인덱싱한 Deep Learning Container를 쓰고 이미지 태그를 -soci가 붙은 변형으로 바꾸는 것이다. AWS 출시 블로그는 PyTorch Training, TensorFlow Training, vLLM, SGLang을 들며 일부 프레임워크에는 arm64 변형도 있다. 다른 하나는 자기 이미지에 인덱스를 추가하는 것으로, containerd와 SOCI snapshotter, Finch 또는 nerdctl이 있는 Linux 호스트가 필요하고 이미지를 다시 빌드할 필요는 없다. 작업 정의, 진입점, 데이터 채널은 바꾸지 않는다. 조건이 두 가지 있다. Deep Learning Container를 FROM으로 만든 이미지는 기본 이미지의 인덱스가 이어지지 않으므로 최종 이미지에 따로 인덱스가 필요하고, 이미지는 비공개 ECR 리포지토리에 있어야 한다. 기능은 SageMaker AI를 쓸 수 있는 모든 리전에서 API, CLI, SDK, 콘솔로 이용할 수 있다.

출시 블로그에는 AWS의 자체 측정이 실려 있다. 테스트는 압축 후 1.8~35.4GB의 이미지 8개를 사용했고 ml.g4dn부터 ml.p5까지의 인스턴스에서 미국 서부(오리건)와 미국 동부(버지니아 북부) 리전으로 실행했으며, 수치는 반복 실행의 중앙값이다. 1.8GB 이미지는 48초에서 3~11초로, 13.2GB는 3분 42초에서 약 6초로, 35.4GB는 7분 17초에서 3~11초로 줄었다. 같은 13.2GB 이미지를 13가지 인스턴스 유형과 크기에서 시험하니 표준 다운로드는 3분 16초~4분 20초, 지연 로딩은 6~8초였다. 블로그의 개요는 배율 표기가 일관되지 않아 약 10배, 8배, 8~46배가 섞여 나오고 표에서는 약 8배에서 약 38배이므로 초 단위 수치를 기준으로 삼는 편이 낫다.

학습 자체에는 한 번만 드는 비용이 있다. AWS는 Imagenette(9,469장)의 ResNet-50과 51,760개 예제에 대한 Qwen2.5-0.5B 전체 파라미터 미세조정을 비교했다. 두 번째 에폭부터는 에폭당 시간이 같았고 첫 에폭은 처음 접근하는 파일을 가져오느라 3~16초 더 걸렸으며, 작업 전체로는 약 1~6분 먼저 끝났다. 진입점이 학습 전에 이미지의 대부분을 읽는다면, 예컨대 스캔, 체크섬, 사전 로딩을 한다면 이득이 줄어든다. AWS 테스트에서 torch.compile과 JIT로 빌드한 CUDA 확장은 첫 에폭을 7~15초 늘렸고, 6GB 모델을 이미지에 넣어 로딩 시 가중치를 스트리밍한 경우 2~3.5분이 늘었지만 작업은 그래도 2~2.5분 먼저 끝났다.

AWS의 테스트 세부 사항도 볼 만하다. 이미지 분류는 Imagenette 9,469장으로 ResNet-50을 학습했고 13.2GB PyTorch DLC와 9.9GB TensorFlow DLC를 썼으며 ml.p5.48xlarge, ml.p4d.24xlarge, ml.g7e.48xlarge, ml.g7.48xlarge와 ml.g6e 몇 가지 크기의 인스턴스를 사용했다. 대규모 언어 모델 미세조정은 9.4GB Hugging Face PyTorch DLC로 ml.p5.48xlarge, ml.p4d.24xlarge, ml.g6.48xlarge에서 실행했다. 입구 프로그램이 학습 전에 일을 많이 해도 AWS 테스트에서는 순이익이 남았다. torch.compile과 JIT로 빌드한 CUDA 확장은 첫 에폭을 7~15초 늘렸지만 작업의 순절감은 3분 25초~3분 56초였고, 6GB 모델 가중치를 이미지에 넣어 로딩 때 스트리밍하면 첫 에폭이 2~3.5분 늘었어도 작업은 2~2.5분 먼저 끝났다. AWS는 지연 로딩이 첫 학습 단계에 이미지의 일부만 필요할 때 가장 이득이라고 하며, 그래서 수백 개 작업의 하이퍼파라미터 탐색과 짧은 작업에서 가치가 크다. AWS 페이지는 훈련 작업과 처리 작업을 모두 지원하며 API, CLI, SDK, 콘솔에서 인덱스가 있는 이미지를 참조하면 된다고 밝힌다. 작업 정의, 진입점, 데이터 채널은 바꿀 필요가 없어 이전 비용이 낮고, 인덱스가 별도 아티팩트라서 이미지 다이제스트와 서명이 유지되는 점도 운영 부담을 줄인다.

이는 AWS가 두 종류의 워크로드에서 잰 값이다. 첫 에폭의 비용은 이미지와 시작 시 코드가 접근하는 파일에 따라 달라지므로 자기 작업에서 직접 측정해야 한다.