Bài 55 — Cloud cho AI/ML — Training, Inference

Mở đầu — vì sao bài này quan trọng

Trong hai năm trở lại đây, gần như mọi công ty công nghệ ở Việt Nam đều có ít nhất một dự án dính đến AI/ML: từ chatbot chăm sóc khách hàng, hệ thống chấm điểm tín dụng, cho tới nhận diện khuôn mặt trong ứng dụng ngân hàng số (eKYC). Điều làm nhiều bạn DevOps bất ngờ là: phần lớn công sức không nằm ở việc "viết model" — đó là việc của data scientist — mà nằm ở hạ tầng chạy model. Chọn sai loại GPU, cấu hình sai instance, hay để một endpoint inference luôn bật 24/7 có thể đốt hàng chục triệu đồng mỗi tháng mà không ai để ý.

AI/ML có một đặc điểm khiến nó khác hẳn workload web truyền thống: nó ngốn compute cực đắt tiền (GPU/TPU), và chia làm hai giai đoạn với yêu cầu hạ tầng gần như trái ngược nhau — training (huấn luyện) và inference (suy luận, tức phục vụ dự đoán). Nếu bạn không hiểu rõ sự khác biệt này, bạn sẽ dùng cùng một loại máy cho cả hai và lãng phí nghiêm trọng.

Bài này giúp bạn — với vai trò DevOps/Cloud Engineer — hiểu được: nên chọn compute nào cho từng loại workload, cách kiến trúc một pipeline training, cách deploy và tối ưu chi phí inference, và những cạm bẫy tiền bạc mà rất nhiều team ở Việt Nam đã vấp phải. Đây là kiến thức nền để bạn tự tin ngồi cùng bàn với data team mà không bị "ngợp".

Khái niệm cốt lõi

Hai giai đoạn: Training vs Inference

Hãy tưởng tượng training giống như luyện thi: bạn cần một khoảng thời gian tập trung cường độ cao, dùng nhiều tài nguyên (nhiều GPU chạy song song), nhưng chỉ diễn ra theo đợt. Còn inference giống như đi làm hằng ngày: chạy liên tục, đều đặn, mỗi request nhẹ hơn nhiều nhưng phải phản hồi nhanh và ổn định.

• Training: đọc lượng lớn dữ liệu, tính toán ma trận khổng lồ để điều chỉnh trọng số (weights) của model. Cần GPU/TPU mạnh, băng thông bộ nhớ lớn, thường chạy trong vài giờ đến vài tuần rồi kết thúc. Chấp nhận gián đoạn được (checkpoint để chạy tiếp).
• Inference: nạp model đã huấn luyện, nhận input và trả về kết quả (ví dụ: ảnh này là mèo hay chó, câu hỏi này trả lời thế nào). Cần độ trễ thấp (low latency) và tính sẵn sàng cao (high availability), chạy 24/7.

Compute options — chọn "máy" nào cho việc gì

Đây là bảng định hướng bạn nên thuộc nằm lòng:

GPU (Graphics Processing Unit) là "ngựa thồ" của AI vì nó xử lý song song hàng nghìn phép tính. Các dòng bạn sẽ nghe thường xuyên: T4/L4 (rẻ, cho inference nhẹ), A10G/A100/H100 (mạnh dần, cho training). TPU (Tensor Processing Unit) là chip riêng của Google, chỉ có trên GCP, cực mạnh cho một số framework như JAX/TensorFlow.

Managed ML services — không phải lúc nào cũng "tự dựng"

Ba nhà cloud lớn đều có nền tảng ML được quản lý sẵn, giúp bạn không phải tự cài đặt driver GPU, tự quản lý cluster:

• AWS SageMaker: từ notebook, training job, tới endpoint inference, đều có sẵn. Có SageMaker Serverless Inference (tự scale về 0).
• GCP Vertex AI: mạnh về TPU, tích hợp BigQuery, có AutoML cho người ít kinh nghiệm.
• Azure Machine Learning: tích hợp tốt với hệ sinh thái Microsoft, mạnh mảng doanh nghiệp.

Với đội nhỏ ở Việt Nam, dùng managed service thường tiết kiệm thời gian hơn tự dựng GPU trên VM trần — trừ khi bạn cần tối ưu chi phí ở quy mô rất lớn.

Ba đòn bẩy tối ưu chi phí inference

Vì inference chạy 24/7 nên nó thường tốn tiền hơn training về lâu dài. Ba kỹ thuật cốt lõi:

• Quantization: nén trọng số model từ 32-bit (FP32) xuống 16-bit hoặc 8-bit (INT8), giảm dung lượng và tăng tốc, đổi lại độ chính xác giảm nhẹ. Một LLM 13 tỷ tham số sau quantization có thể vừa một GPU thay vì hai.
• Batching: gom nhiều request lại xử lý cùng lúc trên GPU để tận dụng tối đa. GPU rảnh mà chỉ phục vụ 1 request là lãng phí.
• Auto-scale to zero: khi không có traffic thì tắt hẳn (dùng serverless inference), chỉ trả tiền khi có request. Rất hợp với demo, ứng dụng nội bộ traffic thấp.

Storage cho ML — đừng để dữ liệu thành nút thắt cổ chai

Training đọc terabyte dữ liệu, nếu storage chậm thì GPU đắt tiền phải "ngồi chờ". Nguyên tắc: để dữ liệu gần compute, dùng object storage (S3/GCS) cho dataset gốc, và dùng file storage tốc độ cao (FSx for Lustre, Filestore) làm lớp đệm khi training cần đọc nhanh liên tục.

Tình huống thực tế

Ví dụ 1 — Startup fintech Việt Nam huấn luyện model chấm điểm tín dụng

Một startup fintech ở TP.HCM (khoảng 25 người) cần huấn luyện model dự đoán rủi ro vỡ nợ dựa trên hành vi giao dịch. Ban đầu, team data thuê một instance p3.8xlarge (4 GPU V100) trên AWS chạy 24/7 để "tiện thử nghiệm", tốn khoảng 9.000 USD/tháng — hơn 220 triệu đồng, trong khi thực tế mỗi tuần họ chỉ train khoảng 10 giờ.

Sau khi DevOps vào cuộc, họ chuyển sang mô hình: dùng SageMaker Training Job — chỉ khởi tạo GPU khi có job train, xong thì tắt. Đồng thời chuyển các lần chạy thử nghiệm (experiment) sang Spot Instance (rẻ hơn 60–70%), có bật checkpoint để nếu bị AWS thu hồi máy giữa chừng thì train tiếp từ điểm lưu. Kết quả: chi phí compute training giảm từ 9.000 xuống còn khoảng 1.100 USD/tháng.

Bài học: Training là workload theo đợt. Đừng bao giờ để GPU training chạy thường trực. Tách bạch giai đoạn thử nghiệm (dùng Spot cho rẻ) và giai đoạn train chính thức (dùng On-Demand để ổn định).

Ví dụ 2 — Sàn thương mại điện tử Đông Nam Á và bài toán inference gợi ý sản phẩm

Một sàn TMĐT hoạt động tại Việt Nam và Indonesia cần chạy model gợi ý sản phẩm (recommendation) phục vụ hàng triệu người dùng. Traffic có đặc điểm rất "gợn sóng": ban ngày cao, ban đêm thấp, và bùng nổ vào các đợt sale 11.11, 12.12.

Ban đầu họ deploy inference trên một số lượng cố định GPU T4 — đủ để chịu tải giờ cao điểm, nhưng ban đêm thì 80% GPU nằm không mà vẫn tính tiền. Team tối ưu theo ba bước: (1) áp dụng quantization INT8 cho model, giúp mỗi GPU phục vụ được gấp đôi request; (2) bật request batching để gom yêu cầu; (3) cấu hình auto-scaling theo lượng request thực tế, ban đêm co lại còn số GPU tối thiểu, khi vào đợt sale thì tự bung ra.

Với riêng đợt sale 12.12, hệ thống tự scale từ 6 lên 40 GPU trong vài phút mà không cần ai can thiệp thủ công, và ban đêm tự co về 4 GPU. Hóa đơn inference trung bình giảm khoảng 45%, trong khi độ trễ p99 vẫn giữ dưới 80ms.

Bài học: Inference cần scale theo traffic thật, không phải theo lo lắng "sợ sập". Quantization + batching + auto-scaling là bộ ba kinh điển để vừa nhanh vừa rẻ.

Ví dụ 3 — Agency dùng LLM và bẫy "gọi API bên ngoài vs tự host"

Một agency marketing ở Hà Nội xây tính năng viết nội dung tự động cho khách hàng. Họ đứng trước hai lựa chọn: gọi API của một nhà cung cấp LLM bên ngoài (trả tiền theo token), hay tự host một model mã nguồn mở trên GPU cloud.

Ở giai đoạn đầu, lượng người dùng ít, họ gọi API bên ngoài — không tốn chi phí hạ tầng cố định, chỉ trả theo lượng dùng, triển khai trong một ngày. Khi lượng request tăng vọt (hàng trăm nghìn lượt/ngày), hóa đơn API trở nên đắt hơn cả việc tự host, họ mới chuyển sang self-host model open-source trên một GPU L4 với quantization, tối ưu bằng batching. Điểm hòa vốn (break-even) rơi vào khoảng khi họ vượt ngưỡng traffic cố định mỗi ngày.

Bài học: Không có câu trả lời đúng tuyệt đối cho "tự host hay gọi API". Ở quy mô nhỏ, API bên ngoài rẻ và nhanh. Khi traffic lớn và ổn định, tự host mới đáng. Hãy tính điểm hòa vốn dựa trên chi phí thật, đừng quyết định theo cảm tính.

Hướng dẫn từng bước

Dưới đây là quy trình khung để đưa một dự án ML lên cloud, từ góc nhìn DevOps:

• Phân loại workload trước tiên. Hỏi rõ data team: đây là training từ đầu, fine-tuning, hay chỉ inference? Model bao nhiêu tham số? Cần latency bao nhiêu? Câu trả lời quyết định toàn bộ lựa chọn hạ tầng phía sau.

• Chọn compute theo bảng định hướng. Training lớn → GPU cluster A100/H100 hoặc TPU. Fine-tuning → 1–8 GPU. Inference nhỏ → T4/L4 hoặc CPU. Đừng dùng máy training để chạy inference thường trực.

• Chuẩn bị pipeline training. Đặt dataset gốc trên object storage (S3/GCS). Với training cần đọc nhanh liên tục, gắn thêm file storage tốc độ cao làm lớp đệm. Luôn bật checkpoint để có thể chạy tiếp khi gián đoạn.

• Dùng Spot/Preemptible cho thử nghiệm. Giai đoạn experiment chấp nhận gián đoạn được — dùng Spot để tiết kiệm 60–70%. Giai đoạn train chính thức, cân nhắc On-Demand cho ổn định.

• Đóng gói model để inference. Sau khi train xong, lưu model (artifact) vào object storage. Áp dụng quantization nếu cần giảm chi phí phục vụ. Đóng gói thành container hoặc dùng managed endpoint (SageMaker/Vertex/Azure ML).

• Deploy endpoint inference với auto-scaling. Cấu hình scale theo số request hoặc mức sử dụng GPU. Với traffic thất thường hoặc thấp, cân nhắc serverless inference (scale về 0). Bật batching để tăng throughput.

• Giám sát và gắn cost tag. Theo dõi GPU utilization, latency p99, và chi phí. Gắn tag rõ ràng cho từng dự án ML để biết tiền đi đâu — đây là bước hay bị bỏ qua nhất.

Lỗi thường gặp & mẹo

• Để GPU training chạy 24/7. Sai lầm đắt đỏ nhất. Training theo đợt — tắt máy ngay khi xong job. Đặt cảnh báo ngân sách (budget alert) cho các instance GPU.

• Dùng GPU quá mạnh cho inference nhẹ. Chạy inference một model nhỏ trên A100 giống như dùng xe tải chở một túi rau. Hãy thử T4/L4, thậm chí CPU trước, rồi mới nâng cấp nếu latency không đạt.

• Quên bật checkpoint khi dùng Spot. Spot rẻ nhưng có thể bị thu hồi bất cứ lúc nào. Không checkpoint = mất trắng nhiều giờ train. Luôn lưu tiến độ định kỳ.

• Bỏ quên chi phí lưu trữ và truyền dữ liệu. Dataset ML thường rất lớn. Chi phí egress (truyền dữ liệu ra) và lưu trữ lâu dài có thể âm thầm phình to. Dọn dẹp checkpoint cũ, dữ liệu tạm sau khi train xong.

• GPU "ngồi chờ" vì storage chậm. Nếu GPU utilization thấp mà latency đọc dữ liệu cao, nút thắt là storage chứ không phải compute. Đưa dữ liệu lại gần compute, dùng lớp đệm tốc độ cao.

• Mẹo — bắt đầu bằng managed service. Với đội nhỏ, đừng vội tự dựng cluster GPU. SageMaker/Vertex/Azure ML lo phần cực khổ (driver, scale, monitoring) giúp bạn. Tự dựng chỉ đáng khi bạn ở quy mô lớn và cần tối ưu sâu.

• Mẹo — tính điểm hòa vốn giữa API và self-host. Khi phân vân giữa gọi API LLM bên ngoài và tự host, hãy làm phép tính chi phí theo lượng token/request thực tế. Quy mô nhỏ ưu tiên API, quy mô lớn ưu tiên self-host.

Bài tập thực hành

• Phân loại workload. Cho ba tình huống: (a) huấn luyện model nhận diện biển số xe từ đầu với 2 triệu ảnh, (b) phục vụ chatbot LLM cho 500 người dùng nội bộ, (c) chạy dự đoán rủi ro tín dụng theo lô mỗi đêm. Với mỗi tình huống, hãy chọn loại compute (GPU nào, On-Demand/Spot/Serverless) và giải thích lý do.

• Tính chi phí. Một instance 4 GPU giá 2,5 USD/giờ. Team train 12 giờ/tuần. So sánh chi phí giữa: (a) để máy chạy 24/7, và (b) chỉ bật khi train. Sau đó tính lại nếu dùng Spot với giá giảm 65% cho phương án (b).

• Thiết kế endpoint inference. Phác thảo kiến trúc phục vụ một model gợi ý sản phẩm cho sàn TMĐT có traffic gợn sóng (cao điểm tối, thấp ban đêm, bùng nổ ngày sale). Nêu rõ bạn sẽ dùng loại GPU nào, chính sách auto-scaling ra sao, và áp dụng quantization/batching thế nào.

• Ra quyết định API vs self-host. Giả sử gọi API bên ngoài tốn 0,002 USD/request, còn tự host tốn cố định 500 USD/tháng cộng chi phí gần như bằng 0 mỗi request. Ở mức bao nhiêu request/tháng thì tự host bắt đầu rẻ hơn? Đây là điểm hòa vốn của bạn.

Tóm tắt

• AI/ML trên cloud chia làm hai giai đoạn với yêu cầu trái ngược: training (theo đợt, ngốn GPU mạnh, chấp nhận gián đoạn) và inference (chạy 24/7, cần latency thấp và độ sẵn sàng cao).
• Chọn compute theo workload: training lớn dùng GPU cluster A100/H100 hoặc TPU, fine-tuning dùng vài GPU, inference nhẹ dùng T4/L4 hoặc CPU. Đừng dùng máy training để chạy inference thường trực.
• Ba đòn bẩy tối ưu inference: quantization (nén model), batching (gom request), auto-scale to zero (tắt khi rảnh).
• Với training, luôn dùng Spot/Preemptible + checkpoint cho thử nghiệm để tiết kiệm, và tuyệt đối không để GPU chạy không tải 24/7.
• Managed service (SageMaker, Vertex AI, Azure ML) là điểm khởi đầu tốt cho đội nhỏ; tự dựng cluster chỉ đáng khi ở quy mô lớn.
• Luôn gắn cost tag, đặt budget alert, và theo dõi GPU utilization — vì GPU là tài nguyên đắt nhất trong toàn bộ hạ tầng cloud của bạn.