← Trang chủ
Dùng AI ngay

Ảnh SOCI rút thời gian khởi động job SageMaker, trừ khi code đọc hết ảnh ngay

AWS nói ảnh SOCI đưa thời gian tải từ phút xuống giây cho job SageMaker, trừ khi code đọc hết ảnh. Cách đo trên job của bạn.

Xong bài này bạn làm được Người đọc biết job của mình có hưởng lợi từ ảnh SOCI hay không bằng hai lần chạy, thay vì tin con số của hãng.

Job huấn luyện của bạn trên Amazon SageMaker AI (dịch vụ của AWS để huấn luyện và chạy mô hình) chưa chạy dòng code nào mà đã tốn vài phút tải ảnh container (gói phần mềm đóng sẵn, chứa thư viện và môi trường để job chạy). Trên bản tin AWS, hãng nói với ảnh học sâu hơn 10 GB, bước tải này thêm vài phút vào mỗi job và bạn trả tiền cho khoảng thời gian đó. Cách AWS vừa giới thiệu là lập chỉ mục SOCI (Seekable OCI, kỹ thuật tải ảnh theo nhu cầu: chỉ lấy tệp cần để khởi động, phần còn lại tải ngầm khi code chạy). Chỉ mục này chỉ có lợi nếu lúc khởi động code của bạn không đọc gần hết ảnh, và bạn kiểm được điều đó bằng hai lần chạy cùng một job.

AWS nói gì và đo trên cái gì

Theo AWS, một chỉ mục SOCI là siêu dữ liệu (mô tả vị trí từng tệp trong ảnh), lưu trong Amazon ECR (kho chứa ảnh container của AWS) như một tệp đi kèm ảnh gốc, nên mã định danh ảnh (digest) và chữ ký hiện có vẫn đúng. Nếu ảnh không có chỉ mục, hoặc chỉ mục không đọc được, job quay về cách tải đầy đủ và vẫn chạy.

Số liệu dưới đây là kết quả AWS tự đo, trên ảnh nén từ 1,8 đến 35,4 GB, lấy trung vị của nhiều lần chạy; các bước ở phần sau chuyển từ hướng dẫn của AWS và bài chưa chạy lại chúng:

  • Ảnh 1,8 GB: tải thường 48 giây, tải theo nhu cầu 3–11 giây.
  • Ảnh 13,2 GB: 3 phút 42 giây so với khoảng 6 giây.
  • Ảnh 35,4 GB: 7 phút 17 giây so với 3–11 giây.
  • Trên mỗi job huấn luyện thử (phân loại ảnh ResNet-50 và tinh chỉnh một mô hình ngôn ngữ nhỏ), lượt chạy đầu (epoch, một vòng qua toàn bộ dữ liệu huấn luyện) chậm thêm 3–16 giây. Tính ròng, AWS báo mỗi job xong sớm hơn 1–6 phút.

AWS cũng nói mức cải thiện tăng theo kích thước ảnh và ảnh nhỏ hơn khoảng 4 GB chỉ thấy cải thiện tương đối nhỏ. Điều AWS tự nêu và là cốt của bài này: nếu điểm vào (entry point, lệnh đầu tiên job chạy) đọc gần hết ảnh trước khi huấn luyện, ví dụ quét, tính checksum (mã kiểm tra tính toàn vẹn của tệp) hay nạp sẵn nội dung, lượt chạy đầu phải chờ gần đúng lượng byte mà tải đầy đủ đã lấy, và mức cải thiện ròng nhỏ.

Thử trên một job của bạn

Hãy thử trên một job không quan trọng trước.

Đầu vào: một job SageMaker đang dùng ảnh từ khoảng 4 GB trở lên, chạy lặp lại (quét siêu tham số hay thử nghiệm ngắn là chỗ AWS nói tải ảnh chiếm tỉ trọng lớn nhất). Ảnh phải nằm trong kho riêng (private repository) của Amazon ECR. AWS nói ảnh ở kho khác, hoặc job kéo ảnh qua kho Docker riêng với TrainingRepositoryAccessMode đặt là Vpc, không đủ điều kiện tải theo nhu cầu.

  1. Chạy job như hiện tại và ghi hai con số: thời gian từ lúc kéo ảnh đến lúc container sẵn sàng, và tổng thời gian job. Đây là mốc so sánh.
  2. Chọn một trong hai đường. Nếu bạn dùng ảnh Deep Learning Container (ảnh dựng sẵn của AWS cho PyTorch, TensorFlow, vLLM, SGLang), đổi thẻ ảnh (tag, phần sau dấu hai chấm trong tên ảnh, chỉ ra phiên bản cần kéo) sang biến thể có đuôi -soci, ví dụ pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci. Nếu dùng ảnh riêng, tạo chỉ mục trên một máy Linux có containerd (phần mềm chạy container), SOCI snapshotter (thành phần của containerd để tải ảnh theo nhu cầu) và nerdctl (công cụ dòng lệnh cho containerd): nerdctl pull, rồi nerdctl image convert --soci sang thẻ mới, rồi nerdctl push. Nếu ảnh của bạn dựng từ ảnh nền DLC, bạn phải tạo chỉ mục cho ảnh cuối, vì chỉ mục của ảnh nền không truyền xuống.
  3. Kiểm thẻ mới có chỉ mục thật. AWS đưa lệnh này; kết quả mong đợi là một danh sách các manifest (tệp mô tả các thành phần của ảnh) có artifactType của chỉ mục SOCI:
aws ecr batch-get-image --repository-name "$REPOSITORY_NAME" \
  --image-ids imageTag="$SOCI_IMAGE_TAG" \
  --accepted-media-types "application/vnd.oci.image.index.v1+json" \
  --query 'images[0].imageManifest' --output text \
  | jq '.manifests[] | {mediaType, artifactType}'
  1. Mở điểm vào và các script cài đặt của job, tìm đoạn gọi lệnh Docker, đọc /var/run/docker.sock, hoặc suy ra mã định danh từ đường dẫn cgroup. AWS cảnh báo ảnh SOCI chạy trên môi trường dựa trên containerd, nên đoạn nào dựa vào Docker có thể hỏng. Sửa trước khi chạy.
  2. Chạy lại đúng job cũ, chỉ đổi thẻ ảnh, rồi ghi lại cùng hai con số và thêm thời gian lượt chạy đầu.

Đọc kết quả và xử lý khi hỏng

Dấu hiệu làm xong: thời gian chờ container sẵn sàng giảm từ phút xuống giây, và tổng thời gian job thấp hơn mốc, dù lượt chạy đầu chậm vài giây. Nếu lượt chạy đầu chậm hơn nhiều so với con số 3–16 giây của AWS, xem điểm vào của bạn có đọc cả thư mục thư viện hay nạp sẵn dữ liệu từ ảnh không; đó đúng là trường hợp AWS cảnh báo lợi ích ròng nhỏ, nên giữ cách tải cũ hoặc bỏ bước nạp sẵn.

Nếu thời gian tải không đổi, kiểm theo thứ tự này. Trước hết, nếu ảnh không nằm trong kho riêng của Amazon ECR, hoặc job đặt TrainingRepositoryAccessMode là Vpc, thì ảnh không đủ điều kiện và đổi thẻ sẽ không giúp gì. Kế đến, ảnh có nhỏ hơn khoảng 4 GB không, vì khi đó AWS nói mức cải thiện nhỏ. Cuối cùng mới quay lại bước 3, vì thẻ có thể trỏ vào ảnh chưa có chỉ mục. Trong trường hợp ảnh không có chỉ mục hoặc chỉ mục không đọc được, job tải đầy đủ như thường, nên bạn không hỏng gì mà cũng không được lợi. Nếu bạn chỉ cần thử cục bộ trước khi gửi job, AWS có hướng dẫn thử tải theo nhu cầu bằng Finch (công cụ container mã nguồn mở của AWS) trong phần tài nguyên của bài gốc.

Nguồn tham khảo

  1. AWS Machine Learning Blog, “Announcing SOCI-indexed images for faster SageMaker AI jobs” — nguồn của số liệu, lệnh và cảnh báo trên.

Tiếp trên bàn Việc hôm nay: Chấm OCR bằng tên và ngày tháng trước khi tin tỉ lệ lỗi ký tự