MLOps & Triển khai (MLOps & Deployment)

#exam-tip

Mục lục

1. Tổng quan

ML Operations (MLOps) - các thực tiễn tốt nhất (practices) để triển khai, giám sát, và bảo trì các mô hình ML trên môi trường production.

2. Các Chiến lược Triển khai (Deployment Strategies) #exam-tip

2.1 Luồng So sánh Chiến lược Triển khai 

graph TB
    A[Cần Triển khai Mô hình] --> B{Đặc thù<br/>Lưu lượng?}

    B -->|Liên tục<br/>Dễ dự đoán| C[Real-time Endpoint]
    B -->|Ngắt quãng<br/>Khó dự đoán| D[Serverless Inference]
    B -->|Xử lý Hàng loạt<br/>Theo lịch| E[Batch Transform]

    C --> F{Chiến lược<br/>Triển khai?}

    F -->|Triển khai Toàn bộ| G[Thay thế Mô hình cũ<br/>⚠️ Rủi ro Downtime]
    F -->|Blue/Green| H[Triển khai Mới<br/>Đổi Lưu lượng<br/>✅ Sẵn sàng Rollback]
    F -->|Canary| I[5% → 25% → 50% → 100%<br/>✅ Giảm Rủi ro]
    F -->|A/B Testing| J[Chia 50/50<br/>So sánh Hiệu suất]

    D --> K{Giới hạn?}
    K -->|Payload < 4MB<br/>Thời gian < 60s| L[✅ Dùng Serverless<br/>$0 phí chờ]
    K -->|Payload > 4MB<br/>HOẶC Thời gian > 60s| M[❌ Dùng Endpoint<br/>hoặc Batch]

    E --> N[S3 In → Xử lý → S3 Out<br/>Không có Endpoint cố định<br/>$ Chỉ tính tiền khi chạy]

    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#e1ffe1
    style I fill:#d4f4dd
    style L fill:#d4f4dd
    style M fill:#ffcccc
    style G fill:#ffe1e1

2.2 Luồng Canary vs A/B Testing 

graph LR
    subgraph "Triển khai Canary - Giảm thiểu Rủi ro"
        A1[Mô hình cũ v1.0<br/>95% traffic] --> B1[Theo dõi Metrics]
        A2[Mô hình mới v2.0<br/>5% traffic] --> B1
        B1 --> C1{An toàn?}
        C1 -->|Có| D1[Tăng lên 25%]
        C1 -->|Không| E1[Quay về v1.0]
        D1 --> F1{Vẫn An toàn?}
        F1 -->|Có| G1[50% → 100%]
        F1 -->|Không| E1
    end

    subgraph "A/B Testing - So sánh"
        A3[Mô hình A<br/>50% traffic] --> B3[Thu thập Metrics]
        A4[Mô hình B<br/>50% traffic] --> B3
        B3 --> C3[So sánh:<br/>Độ chính xác, Độ trễ<br/>Các KPI Kinh doanh]
        C3 --> D3{Ai thắng?}
        D3 -->|A Tốt hơn| E3[Triển khai A 100%]
        D3 -->|B Tốt hơn| F3[Triển khai B 100%]
    end

    style A2 fill:#fff4e1
    style A4 fill:#e1f5ff
    style E1 fill:#ffcccc
    style G1 fill:#d4f4dd

2.3 Suy luận Thời gian thực (Real-time Inference - SageMaker Endpoints)

Mục đích: Cung cấp các dự đoán với độ trễ siêu thấp (low-latency) cho từng request riêng lẻ.

Đặc điểm:

  • Endpoint cố định (lúc nào cũng chạy).
  • Độ trễ tính bằng mili-giây (ms).
  • Hỗ trợ Auto-scaling (tự động thay đổi quy mô).
  • Tốt nhất cho: Các ứng dụng trực tiếp phục vụ người dùng (User-facing apps), APIs.

Các Loại Endpoint:

  • Single model endpoint - Một mô hình, một endpoint.
  • Multi-model endpoint - Nhiều mô hình dùng chung một endpoint (giúp tiết kiệm chi phí).
  • Serial inference pipeline - Chuỗi nối tiếp (preprocessing + prediction) (có thể ghép 2-15 containers).

Các Lựa chọn Triển khai (Deployment Options):

  • All-at-once (Triển khai toàn bộ) - Thay thế mô hình cũ ngay lập tức (mang rủi ro sập hệ thống - downtime).
  • Blue/green - Triển khai bản mới song song, sau đó chuyển toàn bộ traffic sang bản mới, dễ dàng rollback (quay đầu) nếu có biến.
  • Canary - Cơ chế an toàn (Safety mechanism): Điều hướng một lượng % nhỏ traffic sang mô hình mới, nếu thấy êm thì từ từ tăng dần.
    • Mục đích: Giảm thiểu rủi ro (Risk mitigation) - Thử nghiệm mô hình mới trên traffic thật trước khi bung xõa.
    • Quy trình: 5% → theo dõi → 25% → theo dõi → 50% → theo dõi → 100%.
    • Mục tiêu: Chắc chắn rằng mô hình mới không làm sập production.
  • A/B testing - Cơ chế so sánh (Comparison mechanism): Chia đều traffic để so tài hiệu suất giữa 2 mô hình.
    • Mục đích: Quyết định xem ai giỏi hơn - So sánh mặt thống kê giữa các biến thể.
    • Quy trình: Chia 50/50 → thu thập metrics → chọn ra người chiến thắng.
    • Mục tiêu: Xem mô hình nào mang lại hiệu quả cao hơn (về accuracy, latency, business metrics).

Khi nào nên dùng: #exam-tip

  • Yêu cầu xử lý các requests thời gian thực từ người dùng (web, mobile apps).
  • Cần độ trễ thấp (low latency < 100ms).
  • Lưu lượng requests khó đoán nên cần chức năng auto-scaling.
  • Các ứng dụng mang tính tương tác (Interactive applications).

2.4 Batch Transform (Offline Inference)

Mục đích: Xử lý các tập dữ liệu khổng lồ theo phương thức offline.

Đặc điểm:

  • KHÔNG CÓ endpoint cố định.
  • Xử lý toàn bộ dữ liệu chỉ trong một mẻ (at once).
  • Kết quả được lưu thẳng lên S3.
  • Tốt nhất cho: Các dự đoán chạy theo định kỳ, chấm điểm (scoring) quy mô lớn.

Khi nào nên dùng: #exam-tip

  • Dữ liệu cực lớn (hàng triệu records).
  • Các dự đoán KHÔNG CẦN NGAY LẬP TỨC.
  • Chạy theo lịch trình định sẵn (hàng ngày, hàng tuần).
  • Nhạy cảm về chi phí (không tốn tiền nuôi endpoint 24/7).
  • Ví dụ: Chấm điểm rời bỏ của khách hàng (churn scores) vào mỗi tối, đánh giá rủi ro tín dụng hàng tháng.

2.5 SageMaker Serverless Inference #exam-tip

Mục đích: Suy luận tự động thay đổi quy mô (Auto-scaling inference) mà không cần phải quản lý máy móc (instances).

⚠️ CÁC GIỚI HẠN CHÍ PHÀO (CRITICAL LIMITATIONS): #exam-tip

  • Kích thước payload TỐI ĐA: 4MB - Bất kỳ request nào > 4MB sẽ fail sấp mặt.
  • Timeout TỐI ĐA: 60 giây - Bất kỳ lần suy luận nào mất > 60s sẽ bị timeout.
  • Độ trễ khởi động lạnh (Cold start latency): Request đầu tiên sau một thời gian dài nghỉ ngơi sẽ bị chậm (độ trễ có thể lên đến vài giây).

Đặc điểm:

  • Tự động scale về 0 khi không có ai dùng (không tốn phí ngâm máy - idle cost).
  • Chỉ trả tiền cho thời gian máy tính (compute time) thực sự dùng để xử lý.
  • Tự động scale lên tùy theo lượng traffic.

Khi nào nên dùng: #exam-tip

  • Lưu lượng ngắt quãng (Intermittent traffic) (cách nhau nhiều giờ/ngày mới có 1 request).
  • Mức độ sử dụng khó đoán xen kẽ với những khoảng thời gian nghỉ dài.
  • Payload nhỏ (< 4MB) và thời gian suy luận nhanh (< 60s).
  • Môi trường Dev/Test.
  • Tối ưu chi phí cho các khối lượng công việc cường độ thấp (low-volume workloads).

Khi nào KHÔNG NÊN dùng: #exam-tip

  • Cường độ cao (High-throughput), traffic đổ về liên tục (lúc này hãy dùng Endpoint).
  • Payload lớn > 4MB (hãy dùng Endpoint hoặc Batch Transform).
  • Thời gian suy luận dài > 60s (hãy dùng Endpoint hoặc Batch Transform).
  • Các ứng dụng nhạy cảm về độ trễ, không thể chấp nhận việc dính “cold starts”.

Giá cả: Bạn chỉ phải trả tiền cho THỜI GIAN suy luận + bộ nhớ (memory) được cấp phát (tuyệt đối không tốn phí idle).

2.6 Bảng So sánh Các phương án Triển khai #exam-tip

Yếu tố Endpoint Batch Transform Serverless
Độ trễ (Latency) Thấp (ms) Rất cao (phút/giờ) Vừa (Cold start sẽ cộng thêm vài giây)
Chi phí $$$ Chạy 24/7 $ Chỉ tốn khi chạy job $ Chỉ tốn khi có request
Use case Real-time API Dữ liệu khổng lồ Traffic ngắt quãng
Scaling Thủ công/Auto Không áp dụng Tự động (scale về 0)
Phí chờ (Idle cost) $$$ (full giá) $0 $0
Đặc thù Traffic Liên tục/dễ đoán Batch theo lịch trình Ngắt quãng/khó đoán
Max payload 25MB Vô hạn (dùng S3) 4MB (Giới hạn cứng)
Max timeout Không giới hạn Không giới hạn 60s (Giới hạn cứng)
Tốt nhất cho Production APIs Offline scoring Dev/test, low-volume

Khung ra quyết định (Decision Framework): #exam-tip

Chọn Endpoint khi:

  • Cần trả lời ngay lập tức (độ trễ < 100ms).
  • Traffic dội về liên tục hoặc theo pattern dễ đoán.
  • Cân đối được chi phí nuôi máy 24/7.
  • Cần tính năng auto-scaling cho lượng tải biến động.

Chọn Batch Transform khi:

  • Cần xử lý hàng triệu records.
  • Kết quả dự đoán không cần vội.
  • Có thể cho chạy theo lịch (daily, weekly).
  • Đây là giải pháp rẻ nhất cho các batch lớn.

Chọn Serverless khi:

  • Traffic ngắt quãng (nhiều giờ/ngày mới có 1 request).
  • Có thể chấp nhận bị chậm vài giây vì “cold start”.
  • Payload < 4MB VÀ thời gian suy luận < 60s.
  • Quyết tâm không trả một cắc nào cho lúc rảnh rỗi (idle time).
  • Làm môi trường Dev/Test.

3. Tối ưu hóa Inference (Inference Optimization) #exam-tip

3.1 Các Kỹ thuật Tối ưu hóa Mô hình

SageMaker Neo

Mục đích: Tối ưu hóa mô hình chuyên để chạy trên thiết bị vùng biên (edge devices) và suy luận trên cloud.

Tính năng:

  • Biên dịch (Compile) các mô hình để nó khớp hoàn hảo với phần cứng mục tiêu.
  • Chạy nhanh gấp 2 lần, ngốn RAM chỉ bằng 1/10.
  • Hỗ trợ các framework: TensorFlow, PyTorch, MXNet, XGBoost.
  • Triển khai lên: Cloud, edge (Greengrass), các thiết bị IoT.

Use case: Triển khai mô hình xuống các thiết bị edge, muốn cắt giảm chi phí suy luận.

Elastic Inference

Mục đích: Gắn thêm “sức mạnh GPU” vào các máy chủ CPU.

Tính năng:

  • Cung cấp GPU phân mảnh (Fractional GPU) (từ 1-8 GB GPU memory).
  • Giá rẻ hơn nhiều so với việc thuê nguyên một con máy GPU bự.
  • Rất hợp cho: Các mô hình TensorFlow, PyTorch, MXNet.

Use case: Chỉ cần một chút sức mạnh của GPU chứ không cần nguyên con.

Multi-Model Endpoints #exam-tip

Mục đích: Lưu trữ chung (Host) nhiều mô hình vào cùng MỘT endpoint duy nhất.

Lợi ích:

  • Tiết kiệm bộn tiền (vì xài chung hạ tầng).
  • Tốt cho: Nơi chứa hàng tá mô hình nhỏ có nhu cầu tài nguyên na ná nhau.
  • Các mô hình được load lên bộ nhớ một cách tự động khi có nhu cầu (on-demand).
  • Tối đa có thể chứa hàng ngàn mô hình trên một endpoint.

Use case: Tạo mô hình cá nhân hóa cho từng khách hàng riêng biệt, chạy A/B testing vô số biến thể.

Sự đánh đổi (Trade-off): Mất thời gian để load mô hình lên bộ nhớ (chỉ bị chậm ở request đầu tiên trúng vào mô hình đó).

3.2 Auto-Scaling #exam-tip

Target Tracking Scaling:

  • Tự động thay đổi quy mô (Scale) dựa trên một chỉ số (metric) (ví dụ: số invocations trên mỗi instance).
  • Định nghĩa một giá trị mục tiêu (target value) (ví dụ: muốn giữ ở mức 1000 requests/instance).
  • SageMaker sẽ tự động thêm/bớt số lượng instances để bám sát mục tiêu này.

Best Practices:

  • Thiết lập số instances min/max sao cho hợp lý.
  • Đừng quên trừ hao thời gian làm nóng (warm-up time) cho các máy mới được tạo ra.
  • Theo dõi các chỉ số scaling (scaling metrics) trong CloudWatch.

4. Chiến lược Huấn luyện lại (Model Retraining Strategies) #exam-tip

4.1 Khi nào cần Huấn luyện lại (Retrain)

Các yếu tố kích hoạt (Triggers):

  • Theo lịch trình (Scheduled) - Hàng tuần, hàng tháng (dựa trên lịch).
  • Dựa trên hiệu suất (Performance-based) - Độ chính xác rớt thê thảm xuống dưới ngưỡng cho phép.
  • Trôi dạt dữ liệu (Data drift) - Phân phối của dữ liệu đầu vào đã bị lệch đi quá nhiều.
  • Có dữ liệu mới - Các đợt cập nhật dữ liệu định kỳ.

4.2 Các Phương pháp Retraining

1. Huấn luyện lại Toàn bộ (Full Retraining)

  • Đập đi xây lại từ đầu bằng toàn bộ dữ liệu.
  • Ưu điểm: Khởi đầu tươi mới, không sợ bị concept drift.
  • Nhược điểm: Vừa đắt vừa tốn thời gian.

2. Huấn luyện Tăng cường (Incremental Training)

  • Lấy mô hình cũ ra train tiếp.
  • Ưu điểm: Vừa nhanh vừa rẻ.
  • Nhược điểm: Có thể không thích ứng được nếu dữ liệu bị thay đổi quá đột ngột.
  • SageMaker: Chỉ cần truyền (pass) mô hình cũ vào làm input.

3. Học Trực tuyến (Online Learning)

  • Cập nhật mô hình liên tục không ngừng nghỉ bằng luồng dữ liệu mới.
  • Ưu điểm: Lúc nào cũng bắt trend (current).
  • Nhược điểm: Hạ tầng cực kỳ phức tạp, rủi ro dính drift rất cao.

Mẹo làm bài: Đa số các kịch bản trong bài thi sẽ chọn giải pháp Full retraining theo lịch trình (hàng tuần/hàng tháng).

5. Cơ sở Hạ tầng dưới dạng Mã (Infrastructure as Code) #exam-tip

5.1 AWS CloudFormation

  • Định nghĩa hạ tầng ML dưới dạng code.
  • Cung cấp các Templates cho: Endpoints, pipelines, giám sát (monitoring).
  • Quản lý phiên bản, triển khai có thể tái lập nhiều lần.

5.2 AWS CDK (Cloud Development Kit)

  • Định nghĩa hạ tầng bằng các ngôn ngữ lập trình thực thụ.
  • Có tính trừu tượng cao hơn CloudFormation.
  • Cực kỳ tốt cho các workflow ML siêu phức tạp.

5.3 SageMaker Projects

  • Là các CloudFormation templates được tạo sẵn.
  • Được tích hợp luôn CI/CD pipelines.
  • Hỗ trợ triển khai đa tài khoản (Multi-account deployment).

6. Bảo mật & Tuân thủ (Security & Compliance) #important

Những yếu tố bảo mật cốt lõi khi triển khai:

  • Chế độ VPC (VPC mode) - Triển khai các endpoints vào trong private subnets (xem Bảo mật Mạng).
  • Mã hóa (Encryption) - Bật KMS encryption để mã hóa các artifacts của mô hình và dữ liệu (xem Mã hóa).
  • IAM roles - Dùng các vai trò (roles) tách biệt cho việc training và inference, luôn tuân thủ nguyên tắc quyền tối thiểu (least privilege) (xem Bảo mật).
  • Tuân thủ (Compliance) - Đáp ứng các yêu cầu khắt khe của HIPAA, PCI DSS, GDPR thông qua sự kết hợp của VPC + Mã hóa + Audit logging.

📖 Để hiểu sâu sát ván về Bảo mật:

  • Security - IAM, nguyên tắc cơ bản, Macie, WAF, Shield, compliance
  • Encryption - KMS, Secrets Manager, mã hóa lúc nghỉ (at rest) & lúc vận chuyển (in transit)
  • Network Security - VPC, security groups, endpoints, cấu hình SageMaker VPC

7. Tổng hợp Kịch bản Bài thi (Exam Scenarios Summary) #exam-tip

Kịch bản Giải pháp
Real-time API kết hợp với auto-scaling SageMaker Endpoint + Auto-scaling
Xử lý 10 Triệu records mỗi tháng Batch Transform (chạy theo lịch)
Lượng truy cập lèo tèo: 10 requests/ngày Serverless Inference
Cần host 1000 mô hình khách hàng Multi-model Endpoint
Tối ưu mô hình để nhét vào edge device SageMaker Neo
Cần train mà rẻ như cho Managed Spot Training
Train dữ liệu nhạy cảm cực kỳ bảo mật VPC mode + Encryption (Mã hóa)