Announcing SOCI-indexed images for faster SageMaker AI jobs

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 Amazon SageMaker AI 학습·처리 작업에 SOCI 인덱싱을 도입해 컨테이너를 지연 로딩하며, 벤치마크에서 이미지 준비 시간을 수분에서 3~11초로 줄이고 첫 에포크의 추가 시간을 반영해도 작업을 1~6분 빨리 완료했다고 밝혔다.

📌 핵심 요약

• SOCI는 컨테이너 시작에 필요한 파일만 먼저 가져오고 나머지는 실행 중 백그라운드로 가져온다. SageMaker AI는 인덱스를 자동으로 확인하며, 인덱스가 없거나 읽기·지연 로딩에 실패하면 표준 다운로드로 진행한다.
• AWS는 압축 크기 1.8~35.4 GB인 이미지 8개를 시험했다. 이미지 준비 시간은 지연 로딩에서 3~11초로 유지돼 표준 다운로드보다 8~46배 빨랐으며, 이미지 다운로드 중 GPU 유휴 시간은 최대 90% 감소했다.
• ResNet-50 이미지 분류와 Qwen2.5-0.5B 미세 조정 시험에서 첫 에포크는 3~16초 길어졌지만, 두 번째 에포크부터는 실행 간 변동 범위 안에서 성능이 같았다. 전체 작업은 1~6분 빨리 끝났으며, 시작 시 이미지 대부분을 읽는 워크로드에서는 순이익이 작을 수 있다.
• 도입 방법은 사전 인덱싱된 AWS Deep Learning Container의 -soci 태그를 사용하거나 사용자 정의 이미지에 SOCI 인덱스를 생성하는 것이다. DLC 기반으로 파생한 이미지도 최종 이미지용 인덱스가 필요하며, 작업 API·진입점·데이터 채널 변경은 필요하지 않다.
• 지연 로딩은 Amazon ECR 비공개 저장소의 이미지에만 적용된다. 다른 레지스트리의 이미지와 TrainingRepositoryAccessMode가 Vpc인 비공개 Docker 레지스트리 경유 이미지는 지원 대상이 아니다.

🧩 주요 포인트

1. 이미지 전체 다운로드가 컨테이너 시작의 선행 조건에서 빠짐 → 대규모 이미지와 짧은 반복 작업에서 모델 계산 없이 발생하는 대기 시간과 과금 시간을 줄일 여지가 커진다.
2. 첫 에포크의 추가 비용과 이후 에포크의 동일한 성능 → 효과는 지속적인 학습 처리량 향상보다 작업별 고정 시작 비용 절감에 있으며, 실제 이익은 시작 시 접근하는 이미지 파일의 양에 좌우된다.
3. soci 태그 또는 최종 이미지용 SOCI 인덱스로 도입하고 실패 시 표준 다운로드로 복귀 → 기존 실행 방식에 대한 변경 부담은 작지만, Amazon ECR 비공개 저장소와 이미지별 인덱스 조건을 확인해야 한다.

🧠 상세 정리

1. 이미지 다운로드가 만드는 반복 비용

SageMaker AI 학습·처리 작업은 Amazon ECR에 저장된 컨테이너 이미지 안에서 실행되며, 기존 방식에서는 사용자 코드 실행 전에 이미지 전체를 다운로드하고 모든 계층의 압축을 풀어 디스크에 기록한다. 작은 이미지는 이 과정이 수초에 끝나지만, 딥러닝 이미지는 흔히 10 GB 이상이어서 작업마다 수분의 준비 시간이 추가되고 이 시간도 작업 시간으로 과금된다. 특히 수백 개 작업을 실행하는 하이퍼파라미터 튜닝, 빠른 실험, 짧은 처리 작업에서는 이미지 다운로드가 전체 실행 시간에서 큰 비중을 차지할 수 있다. AWS가 발표한 Seekable OCI(SOCI) 인덱싱은 전체 다운로드를 작업 시작의 필수 선행 단계에서 제외해, 모델 학습이 진행되지 않는 대기 시간을 줄이는 데 초점을 둔다.

2. SOCI의 작동 방식과 자동 대체 동작

SOCI는 컨테이너 이미지를 지연 로딩하는 오픈 소스 기술로, 런타임이 인덱스를 이용해 컨테이너 시작에 필요한 파일만 먼저 가져오도록 한다. 나머지 파일은 코드 실행 중 접근에 맞춰 백그라운드에서 가져오며, 인덱스는 이미지 안의 모든 파일을 매핑하는 메타데이터다. 이 인덱스는 원본 이미지에 연결된 별도의 OCI 호환 아티팩트로 Amazon ECR에 저장되므로 원본 이미지의 다이제스트와 기존 서명은 유효하게 유지된다. SageMaker AI는 학습·처리 작업 생성 시 인덱스를 자동으로 확인하고, 인덱스가 있으면 전체 다운로드가 끝나기 전에 컨테이너를 시작한다. 인덱스가 없거나 읽을 수 없거나 지연 로딩이 성공하지 못하면 표준 다운로드로 전환해 작업을 계속하므로, AWS는 인덱스 추가 때문에 기존 작업 실행이 막히지 않는다고 설명한다.

3. 이미지 크기와 인스턴스에 따른 준비 시간 측정

AWS는 압축 크기 1.8~35.4 GB인 이미지 8개를 실제 SageMaker AI 학습 작업에서 비교했으며, 미국 서부 오리건과 미국 동부 버지니아 북부 리전의 GPU·CPU 인스턴스를 사용했다. 측정 구간은 이미지 가져오기 시작부터 컨테이너 실행 준비 완료까지이고, 제시한 값은 반복 실행의 중앙값이다. 표준 다운로드는 1.8 GB에서 48초, 13.2 GB에서 3분 42초, 35.4 GB에서 7분 17초였지만 지연 로딩은 전체 이미지 크기 범위에서 3~11초에 머물렀고, 원문은 개선 폭을 8~46배로 보고한다. 13.2 GB 이미지를 인스턴스 유형·크기 조합 13개에서 시험했을 때도 표준 방식은 3분 16초~4분 20초, 지연 로딩은 6~8초였으며 AWS는 약 34배의 개선으로 설명한다. 이 결과는 시험 범위에서 인스턴스 유형이나 크기를 바꾸지 않고도 시작 시간을 줄일 수 있음을 보여주며, 이미지 다운로드 중 GPU 유휴 시간은 최대 90% 감소했다.

4. 전체 학습 결과와 첫 에포크의 추가 비용

AWS는 다운로드 시간 외에 전체 학습 성능도 비교하기 위해 ResNet-50 이미지 분류와 대규모 언어 모델 미세 조정이라는 두 워크로드를 실행했다. 이미지 분류에는 이미지 9,469개인 Imagenette와 13.2 GB PyTorch DLC 및 9.9 GB TensorFlow DLC를 사용했고, 언어 모델 시험에는 예제 51,760개인 alpaca-cleaned에서 Hugging Face Trainer로 Qwen2.5-0.5B의 전체 파라미터 지도 미세 조정을 수행하는 9.4 GB Hugging Face PyTorch DLC를 사용했다. 두 워크로드 모두 시험한 모든 인스턴스에서 두 번째 에포크부터 에포크당 시간이 실행 간 변동 범위 안에서 같았다. 다만 지연 로딩 이미지는 프레임워크가 처음 접근하는 파일을 가져오는 동안 첫 에포크가 3~16초 길어졌고, 이 추가 비용은 인스턴스 크기에 관계없이 같았다고 보고됐다. 다운로드 절감분에서 이 일회성 비용을 차감한 결과 전체 작업은 각각 1~6분 빨리 완료됐으므로, 측정된 이익은 작업마다 발생하는 고정 시간 절감으로 해석할 수 있다.

5. 시작 시 파일 접근량에 따라 달라지는 순이익

원문은 제시한 성능 수치가 앞서 설명한 두 워크로드에서 나온 결과이며, 첫 에포크의 추가 비용은 이미지 구성과 코드가 시작 시 접근하는 파일에 따라 달라진다고 명시한다. 첫 학습 단계가 이미지 일부만 필요로 하면 나머지를 학습과 병행해 가져올 수 있어 지연 로딩이 유리하다. 반대로 진입점이 학습 전에 이미지 대부분을 스캔하거나 체크섬을 계산하거나 미리 로드한다면, 전체 다운로드와 비슷한 양의 데이터를 기다리게 돼 순개선이 작을 수 있다. 시작 단계의 작업이 많은 시험에서도 torch.compile과 JIT 방식 CUDA 확장은 첫 에포크에 7~15초를 더했지만 전체적으로 3분 25초~3분 56초를 절약했다. 이미지에 포함된 6 GB 모델의 가중치를 로딩 시 가져오는 경우에는 2~3.5분이 추가됐지만 전체 작업은 여전히 2~2.5분 빨리 끝났으며, 이는 자체 워크로드의 전체 완료 시간을 직접 비교해야 한다는 근거다.

6. 사전 인덱싱된 DLC를 이용한 도입

가장 간단한 도입 경로는 AWS가 제공하는 사전 인덱싱된 Deep Learning Container를 사용하는 것으로, 해당 변형은 이미지 태그 끝의 -soci로 식별한다. 원문은 PyTorch Training, TensorFlow Training, vLLM, SGLang용 변형을 제공하며 일부 프레임워크에는 arm64 변형도 있다고 설명하고, 전체 목록은 AWS Deep Learning Containers Gallery에서 확인하도록 안내한다. 기존 작업에서 해당 변형을 사용하려면 작업 정의의 이미지 태그를 -soci 버전으로 바꾸면 되고, 작업 API나 진입점, 데이터 채널을 수정할 필요는 없다. 다만 DLC를 기반 이미지로 삼아 자체 이미지를 빌드했다면 기반 이미지의 인덱스가 파생 이미지로 이어지지 않으므로 최종 이미지에 대한 SOCI 인덱스를 별도로 생성해야 한다. 따라서 사전 인덱싱된 DLC를 그대로 사용하는 경우와 이를 기반으로 사용자 정의 이미지를 만드는 경우는 필요한 인덱스 생성 작업이 다르다.

7. 사용자 정의 이미지 인덱싱과 자동화

사용자 정의 이미지를 인덱싱하려면 containerd, SOCI snapshotter, Finch 또는 nerdctl이 설치된 Linux 호스트가 필요하며, 원문은 Amazon Linux 2023을 실행하는 Amazon EC2 인스턴스를 예로 든다. 안내된 절차는 계정·리전·저장소·원본 및 SOCI 태그를 설정하고 도구와 서비스를 준비한 뒤, Amazon ECR 인증과 원본 이미지 가져오기를 수행하는 순서다. 이후 nerdctl image convert --soci로 SOCI 인덱싱된 이미지를 만들고 푸시하며, 예시 명령은 linux/amd64 플랫폼을 지정한다. 이 과정은 저장소에 SOCI 인덱스와 이미지·인덱스를 연결하는 OCI 호환 이미지 인덱스 매니페스트를 생성하고, 원본 이미지와 다이제스트는 변경하지 않는다. 매번 푸시할 때 인덱스를 자동 생성하려면 CFN ECR SOCI Index Builder를 배포할 수 있으며, 이는 Amazon EventBridge 규칙으로 Amazon ECR 이미지 푸시 이벤트를 감지하므로 기존 빌드 파이프라인 변경은 필요하지 않다고 설명한다.

8. 작업 적용, 인덱스 확인과 지원 범위

생성한 SOCI 인덱싱 이미지는 다른 컨테이너 이미지와 같은 방식으로 SageMaker AI 작업에서 참조하며, 원문의 SageMaker Python SDK 예시는 ModelTrainer의 training_image에 v1.0-soci 태그를 지정한다. 실행 전에는 Amazon ECR의 batch-get-image로 해당 태그의 OCI 이미지 인덱스 매니페스트를 조회해 실제로 인덱스가 연결됐는지 확인하도록 안내한다. 플랫폼 매니페스트와 함께 artifactType이 application/vnd.amazon.soci.index.로 시작하는 하위 매니페스트가 있어야 하며, 없다면 그 태그는 인덱싱된 이미지를 가리키지 않는다. 지원 범위는 Amazon ECR 비공개 저장소로 한정되고, 다른 레지스트리의 이미지나 TrainingRepositoryAccessMode를 Vpc로 설정한 비공개 Docker 레지스트리를 통해 가져오는 이미지는 지연 로딩 대상이 아니다. 따라서 태그를 바꾸는 절차와 함께 인덱스 연결 여부 및 이미지 저장·접근 방식도 적용 가능성을 판단하는 조건이다.

🧾 핵심 주장 / 시사점

• 지연 로딩의 이점은 이미지 크기 자체보다 전체 이미지 중 시작 전에 반드시 읽어야 하는 비중과 연결된다. 큰 이미지라도 초기 접근량이 적으면 다운로드를 실행과 겹쳐 처리할 여지가 크다.
• 절감 효과가 작업별 고정 시간으로 나타나므로, 동일한 절감 시간도 짧은 실험이나 다수의 반복 작업에서는 전체 실행 시간에서 더 큰 비중을 차지할 수 있다.
• 표준 다운로드로의 자동 복귀는 실행 지속성을 뒷받침하지만, 작업이 성공했다는 사실만으로 지연 로딩이 적용됐다고 판단할 수는 없다. 인덱스 연결 확인과 실제 시간 비교가 효과 판단에 필요하다.

✅ 액션 아이템

• 사용 중인 AWS Deep Learning Container의 -soci 태그 적용 가능 여부를 확인하고, 사용자 정의 이미지는 최종 이미지용 SOCI 인덱스 생성 검토.
• 자체 워크로드에서 첫 에포크의 추가 시간과 전체 완료 시간을 비교해, 보고된 1~6분 단축 효과의 재현 여부 확인.
• 이미지 저장소가 Amazon ECR 비공개 저장소인지와 TrainingRepositoryAccessMode가 Vpc인 경로를 사용하는지 확인해 지연 로딩 적용 가능 여부 판단.

❓ 열린 질문

• 현재 워크로드는 시작 시 이미지 일부만 읽는가, 아니면 이미지 대부분을 읽어 SOCI 지연 로딩의 순이익이 작아지는가?
• 사용 중인 AWS Deep Learning Container에 -soci 태그가 제공되는가, 아니면 최종 이미지용 SOCI 인덱스를 직접 생성해야 하는가?
• 현재 이미지의 저장·접근 방식은 Amazon ECR 비공개 저장소 조건을 충족하며 TrainingRepositoryAccessMode가 Vpc인 제외 경로에 해당하지 않는가?