Ngân hàng đề — AWS Certified Machine Learning Engineer Associate

Đáp án

A — Bật AWS CloudTrail ghi mọi lời gọi API liên quan tới SageMaker, bao gồm CreateTrainingJob và UpdateEndpoint, và cấu hình CloudWatch Alarms thông báo cho đội bảo mật khi phát hiện lời gọi API trái phép.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là chức năng của CloudTrail: | Yêu cầu | Cơ chế | |---|---| | Ghi lại mọi hoạt động huấn luyện lại | CloudTrail ghi API call | | Truy vết cho tuân thủ | CloudTrail là nguồn kiểm toán chuẩn | | Thông báo khi có nỗ lực trái phép | CloudWatch Alarm trên metric filter |

CloudTrail là dịch vụ kiểm toán API của AWS — nó ghi lại ai đã gọi API nào, khi nào, từ đâu, và kết quả ra sao:

{
  "eventName": "CreateTrainingJob",
  "eventTime": "2026-08-29T14:23:11Z",
  "userIdentity": {"arn": "arn:aws:sts::123456789012:assumed-role/DataScientist/nguyen.van.a"},
  "sourceIPAddress": "203.0.113.45",
  "errorCode": "AccessDenied",           ← nỗ lực TRÁI PHÉP
  "requestParameters": {"trainingJobName": "phat-hien-gian-lan-v7"}
}

Trường errorCode là chìa khoá cho vế cảnh báo: một lời gọi bị từ chối vì thiếu quyền chính là "unauthorized attempt", và bạn bắt nó bằng metric filter:

{ ($.eventSource = "sagemaker.amazonaws.com") &&
  (($.errorCode = "AccessDenied") || ($.errorCode = "UnauthorizedOperation")) }

Rồi đặt alarm trên metric đó → SNS → đội bảo mật.

Hai API mà đáp án nêu đúng là hai điểm nhạy cảm nhất: | API | Ý nghĩa | |---|---| | CreateTrainingJob | ai đó khởi động huấn luyện lại | | UpdateEndpoint | ai đó thay model đang phục vụ production |

Vì sao các phương án khác sai

• C. Bật AWS CloudWatch ghi mọi lời gọi API liên quan tới SageMaker, gồm CreateTrainingJob và UpdateEndpoint, và đặt alarm thông báo khi có lời gọi trái phép — đây là phương án gần nhất và giống hệt A trừ một từ: CloudWatch KHÔNG ghi lời gọi API. CloudWatch thu thập metric và log ứng dụng; CloudTrail mới là dịch vụ ghi API. Đây là bẫy chỉ khác tên dịch vụ.
• B. Bật detailed monitoring trong CloudWatch theo dõi mọi hoạt động SageMaker, dùng CloudWatch Logs lưu và phân tích log tìm hoạt động đáng ngờ — cùng nhầm lẫn: detailed monitoring cho metric ở tần suất cao hơn, nó không ghi ai gọi API nào.
• D. Cấu hình CloudTrail chỉ ghi data access event kích hoạt huấn luyện lại, và kích hoạt huấn luyện lại THỦ CÔNG khi phát hiện thay đổi dữ liệu qua log — thiếu vế quan trọng: chỉ ghi data event mà bỏ management event nghĩa là không ghi được CreateTrainingJob và UpdateEndpoint — đúng hai thứ đề yêu cầu. Và "manually trigger" không liên quan tới yêu cầu kiểm toán.

Ghi nhớ

Ba dịch vụ giám sát của AWS — nhớ đúng vai: | Dịch vụ | Ghi gì | |---|---| | CloudTrail | AI đã gọi API nào — KIỂM TOÁN | | CloudWatch | METRIC số học và log ứng dụng — HIỆU NĂNG | | AWS Config | cấu hình tài nguyên thay đổi thế nào theo thời gian |

Câu hỏi phân biệt:

"Ai đã làm gì?" → CloudTrail "Hệ thống chạy thế nào?" → CloudWatch "Cấu hình có tuân thủ không?" → Config

Hai loại sự kiện của CloudTrail: | Loại | Ghi gì | Mặc định | |---|---|---| | Management event | thao tác trên tài nguyên: tạo, sửa, xoá | BẬT | | Data event | thao tác trên DỮ LIỆU: GetObject của S3, Invoke của Lambda | TẮT (tốn phí) |

Với SageMaker, CreateTrainingJob và UpdateEndpoint là management event — nên chúng được ghi mặc định. Còn InvokeEndpoint là data event — phải bật riêng nếu muốn ghi từng lời gọi suy luận.

Ba thực hành cho CloudTrail trong môi trường chịu quản lý: | Thực hành | Vì sao | |---|---| | Organization trail | ghi mọi tài khoản vào một chỗ | | Log file validation | phát hiện nếu log bị sửa đổi | | S3 Object Lock trên bucket log | log không xoá được — bằng chứng bất biến |

Ba thứ nên đặt alarm cho hệ thống ML chịu quản lý: | Sự kiện | Ý nghĩa | |---|---| | errorCode = AccessDenied trên SageMaker | nỗ lực truy cập trái phép | | UpdateEndpoint ngoài giờ hoặc từ IP lạ | thay model đáng ngờ | | DeleteModel, DeleteEndpoint | thao tác phá huỷ |

Và một mẫu tự động hoá đáng dùng: EventBridge rule bắt sự kiện CloudTrail theo mẫu và kích hoạt Lambda ngay — nhanh hơn metric filter (vốn có độ trễ vài phút):

{"source": ["aws.sagemaker"],
 "detail": {"eventName": ["UpdateEndpoint", "DeleteEndpoint"]}}

Đáp án

C và E.

• C — Chia dữ liệu thành ba tập: training để học, validation để tinh chỉnh siêu tham số, test để đánh giá cuối trên dữ liệu chưa thấy
• E — Dùng stratified split (chia phân tầng) để mỗi tập chứa phân bố đại diện của giao dịch gian lận và không gian lận

Vì sao đúng

Đề nêu hai điều kiện, và mỗi đáp án xử lý một cái: | Điều kiện | Đáp án | |---|---| | Cần đo hiệu năng chính xác, tránh overfitting | C — ba tập riêng biệt | | Dữ liệu MẤT CÂN BẰNG nặng | E — chia phân tầng |

C — vì sao cần ba tập, không phải hai: | Tập | Việc | Vì sao riêng biệt | |---|---|---| | Training | model học tham số | | | Validation | tinh chỉnh siêu tham số, chọn model | nếu dùng test set cho việc này, nó không còn "chưa thấy" | | Test | đánh giá cuối, dùng ĐÚNG MỘT LẦN | ước lượng không thiên lệch về hiệu năng thật |

Điểm mấu chốt: mỗi lần bạn nhìn vào một tập để ra quyết định, tập đó bị "nhiễm". Chọn model tốt nhất trên test set nghĩa là bạn đã tối ưu theo test set — và con số cuối cùng sẽ lạc quan hơn thực tế.

E — vì sao chia ngẫu nhiên không đủ với dữ liệu mất cân bằng:

Giả sử 0,2% giao dịch là gian lận (2.000 trong 1 triệu)

Chia NGẪU NHIÊN 80/10/10:
  Test set 100.000 mẫu → kỳ vọng 200 ca gian lận
  → nhưng biến động ngẫu nhiên có thể cho 150 hoặc 250
  → chỉ số đánh giá dao động mạnh

Chia PHÂN TẦNG:
  Mỗi tập giữ ĐÚNG tỷ lệ 0,2%
  → so sánh giữa các tập có ý nghĩa

Với lớp thiểu số rất hiếm, chia ngẫu nhiên còn có rủi ro cực đoan: một tập có thể gần như không có ca dương nào — và mọi chỉ số tính trên nó đều vô nghĩa.

from sklearn.model_selection import train_test_split
X_temp, X_test, y_temp, y_test = train_test_split(
    X, y, test_size=0.1, stratify=y, random_state=42)   # ← stratify

Vì sao các phương án khác sai

• A. Xáo trộn ngẫu nhiên và chia mà không xét phân bố lớp để tránh thiên lệch — đây là phương án gần nhất về mặt "nghe hợp lý", nhưng nó hiểu ngược về thiên lệch: chia phân tầng không tạo ra thiên lệch, nó loại bỏ biến động ngẫu nhiên trong tỷ lệ lớp. Với dữ liệu mất cân bằng, chia ngẫu nhiên mới là thứ gây vấn đề.
• B. Dùng TOÀN BỘ dữ liệu để huấn luyện và đánh giá bằng cross-validation — không có tập kiểm thử độc lập: cross-validation ước lượng tốt hơn một lần chia đơn, nhưng nếu bạn dùng nó để chọn model và siêu tham số thì kết quả vẫn lạc quan. Cần một tập test chưa bao giờ được nhìn tới.
• D. Gộp validation và test thành một tập để đơn giản hoá — mất đúng sự phân biệt quan trọng nhất: nếu tinh chỉnh siêu tham số trên chính tập dùng để đánh giá cuối, con số cuối cùng không còn là ước lượng khách quan.

Ghi nhớ

Vai trò của ba tập — bảng nền tảng: | Tập | Dùng để | Nhìn bao nhiêu lần | |---|---|---| | Training | học tham số | mọi epoch | | Validation | chọn siêu tham số, early stopping, chọn model | nhiều lần | | Test | báo cáo hiệu năng cuối | ĐÚNG MỘT LẦN |

Tỷ lệ chia thường dùng: | Kích thước dữ liệu | Tỷ lệ | |---|---| | Nhỏ (< 10 nghìn) | 60/20/20, hoặc cross-validation | | Vừa | 70/15/15 hoặc 80/10/10 | | Rất lớn (hàng triệu) | 98/1/1 — 1% của 1 triệu vẫn là 10 nghìn mẫu |

Ba nguyên tắc chia dữ liệu, theo mức quan trọng: | Nguyên tắc | Chi tiết | |---|---| | Chia phân tầng khi mất cân bằng | giữ tỷ lệ lớp ở mọi tập | | Chia THEO THỜI GIAN với dữ liệu chuỗi thời gian | không bao giờ chia ngẫu nhiên | | Chia theo nhóm khi có dữ liệu liên quan | mọi giao dịch của cùng một khách hàng phải cùng một tập |

Hai nguyên tắc cuối đặc biệt quan trọng cho phát hiện gian lận và cả hai đều không nằm trong năm phương án:

Chia theo thời gian: gian lận có tính thời gian mạnh — mẫu tấn công thay đổi theo tháng. Chia ngẫu nhiên cho model nhìn thấy tương lai, và điểm số sẽ cao hơn thực tế production đáng kể.

Chia theo nhóm: nếu một khách hàng có giao dịch ở cả tập train lẫn tập test, model có thể học "khách hàng này hay gian lận" thay vì học đặc điểm của giao dịch gian lận — một dạng rò rỉ tinh vi.

Và một quy tắc bắt buộc khi kết hợp với cân bằng lớp:

Chia tập TRƯỚC, cân bằng SAU — và chỉ cân bằng tập TRAINING.

Oversample trước khi chia sẽ khiến bản sao của cùng một mẫu nằm ở cả train lẫn test. Cân bằng cả tập test cho ra điểm số đẹp không phản ánh thực tế production.

Đáp án

C — Dùng Amazon SageMaker Debugger với các rule dựng sẵn để phát hiện vanishing gradient, GPU chưa được dùng hết và overfitting; cấu hình Debugger tự động phản ứng dựa trên ngưỡng định trước.

Vì sao đúng

Đề nêu ba yêu cầu và một ràng buộc, và Debugger đáp ứng cả bốn: | Yêu cầu | Debugger | |---|---| | Phát hiện vấn đề THỜI GIAN THỰC | rule chạy song song với training job | | Tự động phản ứng: dừng huấn luyện hoặc thông báo | tích hợp với EventBridge và SNS | | Metric toàn diện | thu thập tensor, gradient, mức dùng tài nguyên | | Ít công sức vận hành nhất | rule DỰNG SẴN, không viết mã |

Ba vấn đề đề nêu đều có rule dựng sẵn tương ứng:

rules = [
    Rule.sagemaker(rule_configs.vanishing_gradient()),      # ① gradient tiêu biến
    Rule.sagemaker(rule_configs.low_gpu_utilization()),     # ② GPU chưa dùng hết
    Rule.sagemaker(rule_configs.overfit()),                 # ③ overfitting
    Rule.sagemaker(rule_configs.overtraining()),
    Rule.sagemaker(rule_configs.saturated_activation())]

estimator = PyTorch(..., rules=rules,
                    debugger_hook_config=DebuggerHookConfig(
                        s3_output_path='s3://kho/debug/'))

Và vế "automatically react" là điểm quan trọng nhất về mặt kinh tế:

Rule phát hiện vanishing gradient ở phút thứ 20
    ↓ EventBridge event
    ↓ Lambda gọi StopTrainingJob
Job dừng — tiết kiệm 10 giờ GPU còn lại

Với huấn luyện deep learning trên GPU đắt tiền, dừng sớm một job hỏng tiết kiệm rất đáng kể — và đó là "wasted resources" mà đề nói tới.

Rule low_gpu_utilization đáng nhắc riêng vì nó bắt một loại lãng phí âm thầm: job chạy "thành công" nhưng GPU chỉ dùng 20% — thường do nút thắt ở khâu đọc dữ liệu, không phải ở tính toán.

Vì sao các phương án khác sai

• B. Dùng SageMaker Experiments ghi metric huấn luyện và ĐÁNH GIÁ THỦ CÔNG để tìm dấu hiệu vanishing gradient, GPU kém hiệu quả và overfitting — đây là phương án gần nhất và Experiments ghi metric thật, nhưng nó không có rule tự động và không phản ứng được. "Manually evaluate" trái yêu cầu real-time và tự động. Và Experiments không thu thập gradient ở mức tensor — thứ cần để phát hiện vanishing gradient.
• A. Dùng CloudWatch Logs giám sát mức dùng GPU và PHÂN TÍCH LOG THỦ CÔNG tìm vanishing gradient và overfitting — CloudWatch không thấy được gradient: nó đo metric hệ thống (GPU, bộ nhớ), không nhìn vào bên trong quá trình huấn luyện. Vanishing gradient là hiện tượng ở tầng tensor.
• D. Viết script Python tuỳ chỉnh theo dõi metric và tự cài logic giám sát thời gian thực — tự dựng lại Debugger: trái thẳng ràng buộc "LEAST operational overhead", và bạn phải tự cài đặt cả việc thu thập tensor lẫn logic phát hiện.

Ghi nhớ

SageMaker Debugger — ba khả năng: | Khả năng | Chi tiết | |---|---| | Thu thập tensor | gradient, trọng số, activation trong lúc huấn luyện | | Rule dựng sẵn | hơn 20 rule cho các vấn đề phổ biến | | Profiling | mức dùng CPU, GPU, bộ nhớ, thời gian đọc dữ liệu |

Các rule dựng sẵn quan trọng: | Rule | Phát hiện | |---|---| | vanishing_gradient | gradient tiến về 0 — model ngừng học | | exploding_tensor | giá trị bùng nổ thành NaN hoặc Inf | | overfit | validation loss tăng trong khi training loss giảm | | overtraining | không còn cải thiện | | saturated_activation | kích hoạt kẹt ở biên — gradient không truyền được | | low_gpu_utilization | GPU nhàn rỗi — thường do nút thắt I/O | | loss_not_decreasing | loss đứng yên | | poor_weight_initialization | khởi tạo trọng số kém |

Ba mức phản ứng khi rule kích hoạt: | Mức | Hành động | |---|---| | Ghi nhận | rule status trong console | | Thông báo | EventBridge → SNS → email hoặc Slack | | Dừng job | EventBridge → Lambda → StopTrainingJob |

Mức thứ ba là nơi tiết kiệm chi phí thật: với job huấn luyện nhiều giờ trên GPU, dừng ngay khi phát hiện vanishing gradient tiết kiệm phần lớn chi phí của một lần chạy hỏng.

Và Debugger profiling đáng bật mặc định cho mọi job huấn luyện lớn: nó thường lộ ra rằng GPU chỉ được dùng 30–50% vì nút thắt nằm ở khâu đọc dữ liệu. Ba cách chữa thường dùng: | Cách | Chi tiết | |---|---| | Đổi sang FastFile mode hoặc FSx for Lustre | giảm thời gian chờ dữ liệu | | Gộp tệp nhỏ | RecordIO, TFRecord | | Tăng số worker tải dữ liệu | num_workers trong DataLoader |

Ba cách này thường tăng tốc huấn luyện nhiều hơn cả việc đổi sang GPU mạnh hơn — vì GPU mạnh hơn cũng chỉ nằm chờ dữ liệu.

Đáp án

B — Factorization Machines để mô hình hoá tương tác giữa người dùng và sản phẩm cho collaborative filtering.

Vì sao đúng

Đề nêu ba đặc điểm, và Factorization Machines khớp cả ba: | Đặc điểm | Factorization Machines | |---|---| | Dữ liệu tương tác: nhấp, mua, đánh giá | thiết kế riêng cho ma trận người dùng × sản phẩm | | Mở rộng tới hàng triệu người dùng | xử lý hiệu quả dữ liệu THƯA quy mô lớn | | Gợi ý thời gian thực | dự đoán nhanh sau khi huấn luyện |

Vấn đề cốt lõi của hệ gợi ý là DỮ LIỆU THƯA:

Ma trận người dùng × sản phẩm:
  1 triệu người dùng × 100 nghìn sản phẩm = 100 tỷ ô
  Nhưng mỗi người chỉ tương tác với vài chục sản phẩm
  → hơn 99,99% ô là TRỐNG

Factorization Machines giải quyết bằng cách phân rã thành vector tiềm ẩn:

Thay vì học 100 tỷ tham số:
  Học một vector k chiều cho MỖI người dùng và MỖI sản phẩm
  → (1 triệu + 100 nghìn) × k tham số
  → dự đoán = tích vô hướng của hai vector

Đây là cách nó học được tương tác giữa các cặp chưa từng xuất hiện — nền tảng của collaborative filtering.

Và FM có một ưu điểm so với matrix factorization cổ điển: nó nhận thêm đặc trưng phụ (tuổi người dùng, danh mục sản phẩm, thời điểm), nên xử lý được cold start tốt hơn.

Vì sao các phương án khác sai

• D. XGBoost xếp hạng sản phẩm dựa trên hành vi người dùng và đặc trưng nhân khẩu — đây là phương án gần nhất và XGBoost dùng được cho bài toán xếp hạng, nhưng nó không xử lý tốt dữ liệu thưa quy mô lớn: bạn phải mã hoá hàng trăm nghìn sản phẩm thành đặc trưng, và one-hot encoding của chúng tạo ra không gian khổng lồ mà cây quyết định xử lý rất kém.
• A. K-Means phân cụm người dùng thành phân khúc rồi gợi ý theo phân khúc — quá thô: mọi người trong cùng một cụm nhận cùng một danh sách gợi ý, mất hết tính cá nhân hoá. Nó là kỹ thuật bổ trợ hợp lý (phân khúc để phân tích), không phải hệ gợi ý.
• C. BlazingText phân tích văn bản đánh giá và tìm sản phẩm tương tự — chỉ dùng một phần dữ liệu: đề nói có nhấp chuột, mua hàng và đánh giá, nhưng BlazingText chỉ xử lý văn bản. Nó bỏ qua tín hiệu hành vi mạnh nhất (mua hàng).

Ghi nhớ

Thuật toán dựng sẵn của SageMaker cho hệ gợi ý: | Thuật toán | Đặc điểm | |---|---| | Factorization Machines | dữ liệu thưa, tương tác người dùng–sản phẩm | | k-NN | tìm người dùng hoặc sản phẩm tương tự | | Neural Topic Model | gợi ý theo chủ đề nội dung | | Object2Vec | embedding cho cặp thực thể bất kỳ — linh hoạt hơn FM |

Dòng cuối đáng biết: Object2Vec là phiên bản tổng quát hơn, học embedding cho các cặp (người dùng, sản phẩm) và nhận được cả đặc trưng dạng chuỗi — mạnh hơn FM nhưng cần nhiều dữ liệu hơn.

Ba loại hệ gợi ý: | Loại | Dựa trên | Điểm yếu | |---|---|---| | Collaborative filtering | hành vi người dùng tương tự | cold start với người và sản phẩm mới | | Content-based | thuộc tính sản phẩm | ít đa dạng | | Hybrid | kết hợp | khắc phục cả hai |

Factorization Machines thuộc nhóm đầu — nên trong thực tế nên ghép thêm content-based cho khách hàng mới.

Amazon Personalize đáng nhắc như lựa chọn thay thế: nó là dịch vụ được quản lý cho hệ gợi ý, xử lý sẵn cold start, cập nhật thời gian thực, và nhiều loại công thức (recipe). Với đội không muốn tự vận hành model, nó thường nhanh hơn nhiều.

Ba tín hiệu tương tác và độ mạnh: | Tín hiệu | Độ mạnh | |---|---| | Mua hàng | mạnh nhất — thể hiện ý định thật | | Thêm vào giỏ | mạnh | | Nhấp chuột | yếu — có thể chỉ là tò mò | | Xem lâu | vừa |

Khi huấn luyện FM, gán trọng số khác nhau cho các loại tín hiệu thường cải thiện đáng kể so với coi chúng như nhau — một lượt mua đáng giá hơn nhiều lượt nhấp.

Đáp án

A và B.

• A — Amazon Augmented AI (A2I) — đưa quy trình xem xét của con người vào hệ thống ML
• B — Amazon SageMaker Model Monitor — giám sát model đã triển khai

Vì sao đúng

Câu hỏi yêu cầu hai thứ, và hai đáp án chia nhau đúng hai vế: | Yêu cầu trong câu hỏi | Dịch vụ | |---|---| | "monitoring machine learning models" | Model Monitor | | "incorporating human review processes" | Amazon A2I |

A2I — human-in-the-loop được quản lý:

Model dự đoán → điểm tin cậy
    ├─ tin cậy CAO  → dùng kết quả ngay
    └─ tin cậy THẤP → gửi tới A2I
                        ↓
                   Con người xem xét
                        ↓
                   Kết quả cuối + dữ liệu để cải thiện model

A2I lo toàn bộ phần khó: hàng đợi công việc, giao diện xem xét, quản lý lực lượng, thu thập kết quả có cấu trúc.

Model Monitor — giám sát tự động sau khi triển khai: | Loại giám sát | Phát hiện | |---|---| | Data quality | phân bố đầu vào lệch | | Model quality | độ chính xác giảm | | Bias drift | chênh lệch giữa các nhóm | | Feature attribution drift | đặc trưng chi phối đổi |

Hai dịch vụ này bổ sung nhau trong một vòng lặp:

Model Monitor phát hiện chất lượng giảm
    ↓
Tăng tỷ lệ gửi sang A2I để con người xem xét
    ↓
Kết quả con người xem xét → dữ liệu huấn luyện lại

Vì sao các phương án khác sai

• **E. Amazon SageMaker Ground Truth — đây là phương án gần nhất và cũng liên quan tới con người, nhưng nó gán nhãn dữ liệu HUẤN LUYỆN, không phải xem xét dự đoán của model đang chạy. Khác biệt về giai đoạn: | | Ground Truth | A2I | |---|---|---| | Giai đoạn | TRƯỚC huấn luyện | SAU khi triển khai | | Đối tượng | dữ liệu thô cần nhãn | dự đoán của model | | Mục đích | tạo tập huấn luyện | xác minh và sửa kết quả |
• C. SageMaker Data Wrangler — chuẩn bị dữ liệu: làm sạch, biến đổi, trực quan hoá. Không giám sát model, không có con người xem xét.
• D. SageMaker Feature Store — lưu trữ và phục vụ đặc trưng. Cũng không liên quan tới hai yêu cầu.

Ghi nhớ

Ba dịch vụ có yếu tố con người — phân biệt theo giai đoạn: | Dịch vụ | Giai đoạn | Việc | |---|---|---| | Ground Truth | trước huấn luyện | gán nhãn dữ liệu | | A2I | sau khi triển khai | xem xét dự đoán | | Model Evaluation (Bedrock) | đánh giá | người chấm chất lượng đầu ra |

Ba loại workflow của A2I: | Loại | Dùng khi | |---|---| | Tích hợp sẵn (Textract, Rekognition) | dịch vụ AWS có ngưỡng tin cậy thấp | | Tuỳ chỉnh | bất kỳ model nào, kể cả SageMaker và Bedrock | | Lấy mẫu ngẫu nhiên | kiểm tra chất lượng định kỳ |

Ba lực lượng xem xét: | Lực lượng | Dùng khi | |---|---| | Private workforce | nhân viên nội bộ — bắt buộc với dữ liệu bảo mật | | Vendor workforce | nhà cung cấp đã kiểm định | | Mechanical Turk | dữ liệu công khai, khối lượng lớn |

Ba tình huống nên đưa con người vào vòng lặp: | Tình huống | Chi tiết | |---|---| | Điểm tin cậy thấp | model không chắc — người quyết định | | Quyết định có hậu quả cao | y tế, tài chính, pháp lý | | Lấy mẫu kiểm tra chất lượng | phát hiện drift mà chỉ số không bắt được |

Và một lợi ích kép của A2I hay bị bỏ qua: kết quả con người xem xét chính là dữ liệu gán nhãn chất lượng cao cho lần huấn luyện lại. Nên vòng lặp human-in-the-loop vừa đảm bảo chất lượng hiện tại vừa tự sinh dữ liệu cải thiện model — hai giá trị từ cùng một công sức.

Đáp án

B và E.

• E — Tối ưu siêu tham số bằng automatic model tuning để cải thiện hiệu năng, đồng thời dùng spot instance để giảm chi phí
• B — Triển khai huấn luyện phân tán trên nhiều instance NHỎ hơn để cân bằng thời gian và chi phí trong khi vẫn giữ hiệu năng

Vì sao đúng

Đề yêu cầu cân bằng ba yếu tố: hiệu năng model, thời gian huấn luyện, và chi phí. Hai đáp án tấn công cả ba theo hai cách khác nhau: | Đáp án | Hiệu năng | Thời gian | Chi phí | |---|---|---|---| | E — HPO + Spot | ↑ (tinh chỉnh) | — | ↓↓ (Spot giảm tới 90%) | | B — phân tán trên instance nhỏ | giữ nguyên | ↓ (song song) | ↓ (nhiều instance nhỏ thường rẻ hơn một instance rất lớn) |

E — kết hợp hai kỹ thuật bổ sung nhau:

tuner = HyperparameterTuner(
    estimator=Estimator(..., use_spot_instances=True,     # ← Spot
                        max_run=7200, max_wait=14400,
                        checkpoint_s3_uri='s3://kho/checkpoint/'),
    strategy='Bayesian',                                   # ← HPO hiệu quả
    max_jobs=30, max_parallel_jobs=3)

Tinh chỉnh siêu tham số vốn là workload lý tưởng cho Spot: mỗi lần thử độc lập, nên mất một lần thử không ảnh hưởng các lần khác — và với 30 lần thử, tiết kiệm 90% là khoản rất lớn.

B — vì sao nhiều instance nhỏ thường tốt hơn một instance rất lớn:

Một ml.p3.16xlarge:        8 GPU trong một máy
Bốn ml.p3.2xlarge:          8 GPU trong bốn máy

Chi phí thường tương đương hoặc thấp hơn
Nhưng: linh hoạt hơn khi co giãn, và dễ tìm capacity Spot hơn

Dòng cuối đáng chú ý: instance nhỏ dễ có sẵn trên thị trường Spot hơn instance rất lớn — nên B và E kết hợp với nhau tốt.

Vì sao các phương án khác sai

• D. Dùng instance NHỎ HƠN để tiết kiệm và chấp nhận thời gian huấn luyện lâu hơn, vì độ chính xác không phải ưu tiên cao nhất — đây là phương án gần nhất và sai ở tiền đề: đề nói rõ "requires the model to be highly accurate to optimize inventory levels". Phương án này hy sinh đúng thứ đề nói là quan trọng.
• C. Dùng instance LỚN NHẤT để tối thiểu thời gian huấn luyện, bất kể chi phí — vi phạm thẳng ràng buộc ngân sách mà đề nêu.
• A. Triển khai nhiều model với các loại instance khác nhau ĐỒNG THỜI, chọn cái hoàn thành huấn luyện trước, bất kể hiệu năng hay chi phí — tiêu chí chọn vô nghĩa: "hoàn thành trước" không liên quan gì tới chất lượng model. Và chạy nhiều cấu hình song song rồi vứt bỏ hầu hết là lãng phí.

Ghi nhớ

Ba trục cân bằng khi huấn luyện model:

        Hiệu năng
           /\
          /  \
         /    \
   Thời gian — Chi phí

Không tối ưu được cả ba cùng lúc — nhưng có những kỹ thuật cải thiện hai trục mà không hại trục thứ ba: | Kỹ thuật | Cải thiện | Không hại | |---|---|---| | Managed Spot Training | chi phí (−90%) | hiệu năng | | Early stopping | thời gian + chi phí | hiệu năng (thậm chí tốt hơn) | | Mixed precision (FP16) | thời gian (2–3×) | hiệu năng (gần như không đổi) | | Hyperband | chi phí tinh chỉnh | hiệu năng | | Huấn luyện phân tán | thời gian | chi phí (gần như tuyến tính) |

Năm kỹ thuật này nên là mặc định cho mọi dự án có ràng buộc ngân sách.

Điều kiện dùng Spot — cả hai đều bắt buộc: | Điều kiện | Chi tiết | |---|---| | Workload chịu được gián đoạn | huấn luyện, HPO ✅ | | Có checkpoint | nếu không, mất tiến độ khi bị thu hồi |

Hai tham số của Managed Spot Training: | Tham số | Việc | |---|---| | max_run | thời gian huấn luyện tối đa | | max_wait | tổng gồm cả chờ Spot — phải ≥ max_run |

Bốn chiến lược tinh chỉnh siêu tham số: | Chiến lược | Tiết kiệm | |---|---| | Bayesian | ít lần thử nhất | | Hyperband | ít tài nguyên nhất — dừng sớm nhánh kém | | Random | song song tốt | | Grid | tệ nhất |

Với model dự báo nhu cầu huấn luyện lâu, Hyperband thường tiết kiệm hơn Bayesian — nó dừng các cấu hình kém sau vài epoch thay vì chạy hết.

Và một chỉ số nên xem sau mỗi job dùng Spot: Managed Spot Training savings trong log — nó cho biết thực tế tiết kiệm bao nhiêu phần trăm, hữu ích để quyết định có tiếp tục dùng Spot cho loại instance đó không.

Đáp án

D — Dùng IAM policy với điều kiện dựa trên tài nguyên để cấp cho mỗi nhà khoa học dữ liệu quyền truy cập các prefix S3 cụ thể tương ứng với danh mục sản phẩm được giao; gắn policy này vào IAM role mà SageMaker notebook instance dùng.

Vì sao đúng

Đề nêu bốn yêu cầu: | Yêu cầu | Cơ chế | |---|---| | Dữ liệu trong MỘT tài khoản AWS | không tách tài khoản | | Mỗi người chỉ truy cập danh mục của mình | IAM policy theo prefix | | Kiểm soát chi tiết | điều kiện trên s3:prefix và ARN | | Quản lý tập trung | policy ở một chỗ, không phải nhiều bucket |

Kiểm soát theo prefix cho phép chia nhỏ trong CÙNG một bucket:

s3://kho-du-lieu-huan-luyen/
    ├── dien-tu/          ← nhà khoa học A
    ├── thoi-trang/       ← nhà khoa học B
    └── gia-dung/         ← nhà khoa học C

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::kho-du-lieu-huan-luyen/dien-tu/*"
},
{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::kho-du-lieu-huan-luyen",
  "Condition": {"StringLike": {"s3:prefix": ["dien-tu/*"]}}
}

Hai statement là cần thiết và hay bị làm thiếu: statement đầu cho phép đọc object, statement thứ hai cho phép liệt kê — và điều kiện s3:prefix giới hạn việc liệt kê chỉ trong thư mục được phép. Không có statement thứ hai, người dùng đọc được file nếu biết tên nhưng không duyệt được thư mục.

Và điểm kỹ thuật quan trọng nhất: policy phải gắn vào execution role của notebook instance, không phải vào IAM user:

SageMaker notebook chạy bằng EXECUTION ROLE, không phải bằng danh tính của người đang mở nó.

Vì sao các phương án khác sai

• C. Tạo bucket RIÊNG cho từng danh mục và dùng bucket policy cấp quyền theo IAM role của từng người — đây là phương án gần nhất và hoạt động được, nhưng nó kém linh hoạt hơn: thêm một danh mục sản phẩm là tạo một bucket mới, và với hàng chục danh mục thì số bucket phình ra. Đề cũng nhấn mạnh "centralized management" — một bucket với nhiều prefix dễ quản lý hơn nhiều bucket.
• A. Dùng Glue tách dữ liệu ra các bucket riêng rồi dùng bucket policy — thêm một bước xử lý không cần thiết: dữ liệu đã có sẵn, việc sao chép nó ra nhiều bucket tạo bản trùng lặp phải đồng bộ và tăng chi phí lưu trữ.
• B. Tạo tài khoản AWS riêng cho từng danh mục trong AWS Organizations, hạn chế mỗi người vào tài khoản của họ — quá nặng nề: đề nói rõ dữ liệu nằm trong một tài khoản và cần quản lý tập trung. Tách tài khoản cho mỗi danh mục sản phẩm là mức cách ly không tương xứng với nhu cầu.

Ghi nhớ

Ba mức kiểm soát truy cập S3: | Mức | Cơ chế | |---|---| | Bucket | bucket policy hoặc IAM policy trên ARN bucket | | Prefix (thư mục) | IAM policy với ARN có prefix + điều kiện s3:prefix | | Object | ARN cụ thể, hoặc object tag với ABAC |

Hai loại policy và khi nào dùng: | Loại | Gắn vào | Dùng khi | |---|---|---| | Identity-based (IAM policy) | role, user, group | kiểm soát từ phía người truy cập | | Resource-based (bucket policy) | bucket | chia sẻ chéo tài khoản, chính sách chung cho bucket |

Với nhiều người truy cập cùng một bucket theo các phạm vi khác nhau, identity-based policy linh hoạt hơn — mỗi role có policy riêng, không phải nhồi mọi quy tắc vào một bucket policy khổng lồ.

ABAC với tag là cách mở rộng đáng biết khi số lượng danh mục lớn:

{"Condition": {"StringEquals":
  {"s3:ExistingObjectTag/danhMuc": "${aws:PrincipalTag/danhMuc}"}}}

Cách này cho MỘT policy phục vụ mọi danh mục — thêm danh mục mới chỉ cần gắn tag, không sửa policy. Với hàng chục danh mục, khác biệt là giữa một policy và hàng chục policy.

Ba lưu ý khi phân quyền cho SageMaker notebook: | Lưu ý | Chi tiết | |---|---| | Policy gắn vào EXECUTION ROLE | không phải IAM user của người dùng | | Một role cho một vai trò công việc | không phải một role cho mỗi tài nguyên | | Cần cả GetObject lẫn ListBucket | thiếu cái sau thì không duyệt thư mục được |

Và một kiểm thử nên có: test tự động thử truy cập dữ liệu của danh mục khác và phải THẤT BẠI. Nếu test đó thành công, phân quyền có lỗ hổng — và đó là loại lỗi im lặng không tự lộ ra trong quá trình sử dụng bình thường.

Đáp án

A và B.

• B — Dùng AWS Inferentia ở môi trường production để đạt thông lượng cao và độ trễ thấp
• A — Dùng instance CPU ở môi trường test để tiết kiệm chi phí trong lúc thử nghiệm

Vì sao đúng

Đề mô tả hai môi trường với hai yêu cầu khác nhau, và điểm mấu chốt là không nên cấp phát giống nhau cho cả hai: | Môi trường | Yêu cầu | Lựa chọn | |---|---|---| | Production | độ trễ thấp, thông lượng cao | Inferentia | | Test | thử nghiệm, kiểm chứng, tiết kiệm | CPU |

B — AWS Inferentia là chip do AWS thiết kế riêng cho SUY LUẬN: | Đặc điểm | Chi tiết | |---|---| | Chuyên cho suy luận | không dùng cho huấn luyện (đó là Trainium) | | Chi phí mỗi suy luận thấp hơn GPU | thường rẻ hơn đáng kể | | Độ trễ thấp | tối ưu cho throughput cao | | Cần biên dịch | qua AWS Neuron SDK |

Với phát hiện gian lận thời gian thực — nơi mỗi giao dịch cần quyết định trong vài chục mili giây và khối lượng rất lớn — đây là lựa chọn tối ưu cả về hiệu năng lẫn chi phí.

A — CPU cho môi trường test vì mục đích của test là kiểm chứng tính đúng đắn, không phải đo hiệu năng đỉnh:

Test: chạy được không? logic đúng không? đầu ra đúng định dạng không?
      → CPU chậm hơn nhưng RẺ HƠN NHIỀU và đủ dùng

Vì sao các phương án khác sai

• E. Cấp phát instance GIỐNG HỆT NHAU ở cả hai môi trường để đảm bảo hiệu năng nhất quán, loại bỏ rủi ro sai lệch khi triển khai — đây là phương án gần nhất và lập luận nghe rất hợp lý, nhưng nó lãng phí: môi trường test không cần năng lực của production. (Có một hạt nhân đúng trong lập luận này: nên có một lần kiểm thử hiệu năng trên phần cứng giống production trước khi phát hành — nhưng đó là một bước riêng, không phải lý do để chạy toàn bộ môi trường test trên Inferentia suốt ngày.)
• C. Cấp phát CPU ở CẢ hai môi trường để giảm chi phí — hy sinh yêu cầu production: đề nói rõ cần "low-latency inference to ensure fraudulent transactions are flagged immediately". CPU thường không đạt được với model phức tạp và khối lượng lớn.
• D. Dùng GPU ở CẢ hai môi trường để đảm bảo tốc độ tối đa, bất kể chi phí — vi phạm ràng buộc chi phí, và với suy luận thì Inferentia thường rẻ hơn và hiệu quả hơn GPU.

Ghi nhớ

Các chip chuyên dụng của AWS cho ML: | Chip | Việc | Instance | |---|---|---| | AWS Inferentia | SUY LUẬN | inf1, inf2 | | AWS Trainium | HUẤN LUYỆN | trn1, trn2 | | GPU (NVIDIA) | cả hai | p3, p4, p5, g4, g5 | | CPU | model nhẹ, tiền xử lý | c5, m5, r5 |

Phân biệt Inferentia và Trainium là một câu hỏi hay gặp:

Inferentia → Inference (suy luận) Trainium → Training (huấn luyện)

Điều kiện dùng Inferentia: | Điều kiện | Chi tiết | |---|---| | Model phải biên dịch qua AWS Neuron SDK | thêm một bước trong pipeline | | Framework được hỗ trợ | PyTorch, TensorFlow, và các model phổ biến | | Không phải model nào cũng biên dịch được | kiểm tra trước khi cam kết |

Dòng đầu là chi phí thật cần tính: biên dịch Neuron là một bước thêm, và khi đổi model phải biên dịch lại.

Nguyên tắc phân bổ tài nguyên theo môi trường: | Môi trường | Nguyên tắc | |---|---| | Development | rẻ nhất có thể — CPU, instance nhỏ, tắt khi không dùng | | Test/Staging | đủ để kiểm chứng tính đúng đắn | | Kiểm thử hiệu năng | giống production — chạy một lần trước phát hành | | Production | tối ưu cho yêu cầu thật |

Dòng thứ ba là điều mà phương án E nắm được một phần: bạn cần một môi trường giống production, nhưng chỉ khi kiểm thử hiệu năng, không phải suốt ngày.

Bốn cách giảm chi phí môi trường test: | Cách | Chi tiết | |---|---| | Instance CPU thay GPU | rẻ hơn nhiều | | Serverless Inference | co về 0 khi không dùng | | Tắt endpoint ngoài giờ làm việc | tự động bằng EventBridge schedule | | Spot cho job huấn luyện thử | giảm tới 90% |

Và SageMaker Inference Recommender đáng dùng trước khi chọn phần cứng production: nó chạy load test thật trên nhiều loại instance (gồm cả Inferentia) và cho biết chi phí mỗi suy luận của từng cái — thay vì đoán từ thông số kỹ thuật.

Đáp án

C — Tạo FSx for Lustre liên kết với thư mục S3 chứa các tệp ảnh nhỏ, và áp Fast File mode cho thư mục S3 chứa tệp video lớn — kết hợp điểm mạnh của cả hai cách.

Vì sao đúng

Đề mô tả hai loại dữ liệu có đặc tính I/O hoàn toàn khác nhau, và đó là chìa khoá: | Loại dữ liệu | Đặc tính | Nút thắt | |---|---|---| | Hàng chục triệu tệp ảnh NHỎ | rất nhiều lời gọi, mỗi cái nhỏ | độ trễ mỗi lời gọi (latency-bound) | | Vài terabyte video LỚN | ít tệp, mỗi tệp rất lớn | băng thông (throughput-bound) |

Và mỗi cách truy cập tối ưu cho một loại:

FSx for Lustre với TỆP NHỎ:
  Hệ thống tệp POSIX hiệu năng cao, độ trễ dưới mili giây
  → hàng chục triệu lời gọi nhỏ được phục vụ rất nhanh

Fast File mode với TỆP LỚN:
  Stream tuần tự từ S3, không tải hết xuống trước
  → không tốn đĩa cục bộ cho vài terabyte video

Vì sao S3 kém với hàng chục triệu tệp nhỏ: mỗi GetObject có overhead cố định (thiết lập kết nối, xác thực, HTTP). Với tệp 50 KB, overhead đó chiếm phần lớn thời gian:

10 triệu tệp × overhead ~20 ms = hơn 55 giờ chỉ riêng overhead

FSx for Lustre tải trước dữ liệu từ S3 vào hệ thống tệp song song, nên overhead đó biến mất.

Và vì sao FSx không phải lựa chọn tốt cho vài terabyte video: bạn phải trả tiền cho dung lượng FSx đủ chứa chúng, trong khi video được đọc tuần tự một lần — đúng kịch bản mà streaming làm tốt.

Vì sao các phương án khác sai

• A. Dùng FSx for Lustre mount TOÀN BỘ dataset, cho độ trễ thấp nhất quán với cả tệp nhỏ lẫn tệp lớn — đây là phương án gần nhất và hoạt động được, nhưng nó tốn kém không cần thiết: bạn trả tiền cho dung lượng FSx đủ chứa vài terabyte video, trong khi Fast File mode phục vụ chúng tốt tương đương với chi phí gần bằng không.
• B. Dùng Fast File mode cho các tệp ảnh nhỏ, giảm thời gian bắt đầu huấn luyện — sai loại dữ liệu: Fast File vẫn gọi S3 cho từng tệp, nên với hàng chục triệu tệp nhỏ thì overhead vẫn là nút thắt.
• D. Fast File mode cho video lớn (đúng), và lưu tệp ảnh nhỏ CỤC BỘ trên instance huấn luyện — không khả thi: hàng chục triệu ảnh có thể vượt dung lượng đĩa của instance, và bạn phải tải chúng xuống trước — đúng vấn đề đang muốn tránh.

Ghi nhớ

Bốn chế độ đưa dữ liệu vào SageMaker training job: | Chế độ | Cách hoạt động | Hợp với | |---|---|---| | File | tải hết xuống đĩa trước | dataset nhỏ (< vài chục GB) | | Pipe | stream tuần tự | dataset lớn, đọc tuần tự | | FastFile | POSIX, tải lazy theo nhu cầu từ S3 | dataset lớn, ít tệp | | FSx for Lustre | hệ thống tệp hiệu năng cao liên kết S3 | RẤT NHIỀU tệp nhỏ, đọc lặp qua nhiều job |

Bảng chọn theo đặc tính dữ liệu: | Đặc tính | Chọn | |---|---| | Nhiều tệp NHỎ (triệu tệp) | FSx for Lustre | | Ít tệp LỚN | FastFile mode | | Đọc LẶP cùng dữ liệu qua nhiều job | FSx for Lustre | | Dataset nhỏ, một job | File mode |

Dòng thứ ba đáng nhớ riêng: FSx tải dữ liệu từ S3 một lần rồi phục vụ nhiều job — nên với chu trình thử nghiệm chạy nhiều job liên tiếp trên cùng dataset, nó tiết kiệm rất nhiều thời gian.

Ba cách khác giảm nút thắt I/O với nhiều tệp nhỏ: | Cách | Chi tiết | |---|---| | Gộp tệp thành định dạng lô | RecordIO, TFRecord, WebDataset — giảm số lời gọi | | Tăng số worker đọc dữ liệu | num_workers trong DataLoader | | Giảm kích thước ảnh trước | không cần độ phân giải gốc nếu model không dùng |

Cách đầu thường hiệu quả nhất và rẻ nhất: gộp 10 triệu ảnh thành vài nghìn tệp RecordIO biến bài toán latency-bound thành throughput-bound — và khi đó cả Fast File mode cũng hoạt động tốt.

Ba cấu hình FSx for Lustre cần biết: | Cấu hình | Chi tiết | |---|---| | Liên kết với S3 bucket | dữ liệu tự đồng bộ từ S3 | | Deployment type | SCRATCH (tạm, rẻ) hoặc PERSISTENT (bền, đắt hơn) | | Throughput per TiB | 50 / 100 / 200 MB/s — chọn theo nhu cầu |

Với training job, SCRATCH_2 thường đủ — dữ liệu gốc vẫn ở S3, nên mất FSx không mất gì.

Và một điểm về profiling đáng nhớ: SageMaker Debugger profiling thường lộ ra rằng GPU chỉ dùng 30–50% vì đang chờ dữ liệu. Nếu thấy vậy, tối ưu I/O cho lợi ích lớn hơn nhiều so với đổi sang GPU mạnh hơn.

Đáp án

A — Triển khai model phát hiện gian lận bằng SageMaker endpoint cho dự đoán thời gian thực độ trễ thấp, model chấm điểm tín dụng trên Amazon ECS cho xử lý theo lô, và model marketing cá nhân hoá bằng AWS Lambda cho thực thi hướng sự kiện.

Vì sao đúng

Đề mô tả ba model với ba yêu cầu hoàn toàn khác nhau, và đáp án A ghép đúng từng cái: | Model | Yêu cầu trong đề | Lựa chọn | Vì sao | |---|---|---|---| | Phát hiện gian lận | thời gian thực, độ trễ thấp, co giãn nhanh | SageMaker endpoint | model đã nạp sẵn, mili giây, auto scaling | | Chấm điểm tín dụng | nặng tính toán, chịu được độ trễ cao hơn | ECS | kiểm soát tài nguyên, hợp xử lý theo lô | | Marketing cá nhân hoá | hướng sự kiện, không cần luôn sẵn sàng | Lambda | co về 0, kích hoạt bởi sự kiện |

Nguyên tắc chung: hình dạng workload quyết định nền tảng.

Vì sao Lambda đúng cho model marketing:

"triggered by events and doesn't require constant availability"
    ↓
Lambda: 0 sự kiện = 0 chi phí
        có sự kiện → chạy ngay

Đây là kịch bản lý tưởng của serverless: workload rời rạc, không đều, không cần luôn sẵn sàng.

Và vì sao SageMaker endpoint đúng cho phát hiện gian lận: giao dịch đang chờ quyết định, nên cần model đã nạp sẵn trong bộ nhớ — không chịu được cold start của Lambda hay thời gian khởi động của ECS task.

Vì sao các phương án khác sai

• C. Gian lận trên ECS để auto-scale theo nhu cầu, tín dụng trên SageMaker endpoint cho chấm điểm thời gian thực, marketing trên EKS cho xử lý hướng sự kiện — đây là phương án gần nhất và hoán vị sai cả ba: gian lận cần độ trễ thấp nhất nhưng lại đặt trên ECS (có thời gian khởi động), tín dụng chịu được độ trễ cao lại đặt trên endpoint đắt tiền chạy 24/7, và EKS là lựa chọn nặng nề nhất cho một workload hướng sự kiện.
• B. Gian lận trên Lambda cho thực thi serverless, tín dụng trên EKS, marketing trên SageMaker endpoint — ba lựa chọn đều lệch: Lambda có cold start (rủi ro cho phát hiện gian lận), và SageMaker endpoint chạy 24/7 cho một workload chỉ chạy khi có sự kiện là lãng phí rõ ràng.
• D. Triển khai cả ba model trên MỘT cụm EKS để tận dụng Kubernetes, đảm bảo quản lý và co giãn nhất quán — "nhất quán" nghe hợp lý nhưng bỏ qua chính vấn đề: đề mô tả ba yêu cầu khác nhau một cách có chủ đích. Và EKS cho một model chỉ chạy khi có sự kiện là trả tiền cho cụm chạy liên tục.

Ghi nhớ

Bảng chọn nền tảng triển khai theo hình dạng workload: | Hình dạng | Nền tảng | Vì sao | |---|---|---| | Thời gian thực, độ trễ thấp, tải liên tục | SageMaker endpoint | model nạp sẵn, auto scaling | | Hướng sự kiện, rời rạc, model NHỎ | Lambda | co về 0 | | Theo lô, nặng tính toán | Batch transform, ECS, hoặc SageMaker Processing | không cần endpoint thường trực | | Cần môi trường runtime tuỳ chỉnh | ECS/EKS | kiểm soát container | | Tải rất thưa, model vừa | SageMaker Serverless | co về 0 + tính năng ML |

Ba giới hạn của Lambda cần kiểm tra trước khi chọn: | Giới hạn | Giá trị | |---|---| | Gói ZIP giải nén | 250 MB | | Container image | 10 GB | | Thời gian chạy | 15 phút | | GPU | không có |

Với model marketing cá nhân hoá — thường là model gợi ý nhẹ — bốn giới hạn này không phải vấn đề.

Ba cách xử lý workload theo lô như chấm điểm tín dụng: | Cách | Đặc điểm | |---|---| | SageMaker Batch Transform | không cần endpoint, tính tiền theo job — thường rẻ nhất | | ECS/Fargate task | kiểm soát môi trường, chạy theo lịch | | SageMaker Processing job | tích hợp với pipeline ML |

(Đáng nói: với "computationally intensive but can tolerate batch processing", SageMaker Batch Transform thường là lựa chọn tối ưu hơn ECS — nó không đòi quản lý cụm. Nhưng trong bốn phương án đã cho, A vẫn là ghép đúng nhất.)

Và nguyên tắc tổng quát rút ra từ câu này:

Đừng chuẩn hoá nền tảng khi các workload có yêu cầu thật sự khác nhau.

Sự nhất quán về công cụ có giá trị vận hành, nhưng ép ba workload khác nhau vào một nền tảng thường tốn hơn — cả về tiền lẫn về việc phải bù đắp cho những chỗ nền tảng đó không phù hợp.