⚠️ Cạm bẫy chi phí và checklist vận hành

By Ngọc Vương Trương

Vì sao hóa đơn vẫn tăng dù bạn đã chọn hạ tầng rẻ

Bài trước bạn đã dựng được monitoring rẻ: chỉ lưu summary statistics và tính PSI thay vì ghi toàn bộ request. Bạn đã có số liệu về model. Nhưng phần lớn tiền trong một pipeline MLOps tự host không chảy vào model, nó chảy vào những thói quen vận hành: một VPS thử nghiệm quên tắt, một bucket MinIO không bao giờ xóa, một job spot chạy lại ba lần. Bài này chỉ ra các cạm bẫy đó và đưa bạn checklist tuần để chặn chúng trước khi chúng kịp vào hóa đơn.

Sau bài này bạn cần:

  • Nhận diện được 6 nhóm cạm bẫy chi phí phổ biến trong pipeline tự host.
  • Biết dấu hiệu sớm của từng cạm bẫy để phát hiện trong vòng một tuần.
  • Áp dụng được checklist vận hành hằng tuần cho chính capstone của mình.
  • Đặt được ngưỡng cảnh báo và ngưỡng hành động cho chi phí.

Sáu nhóm cạm bẫy âm thầm ăn vào hóa đơn

Nhóm cạm bẫy Dấu hiệu sớm Cách chặn
Tài nguyên mồ côi (VPS, volume, snapshot của lần thử trước) Instance có CPU gần 0 suốt 7 ngày, không có nhãn project Gắn nhãn ngay khi tạo, đặt TTL, lịch xóa
Artifact và log phình vô hạn Dung lượng MinIO tăng đều dù số model không tăng Retention policy, dọn artifact cũ hơn N ngày
Job spot bị thu hồi giữa chừng Job chạy lại nhiều lần, thời gian train tăng bất thường Checkpoint mỗi epoch, retry có giới hạn
Serving quá tay Số replica cao hơn lưu lượng cần, GPU chạy cho model nhỏ min replicas = 1, autoscale theo RPS, batch cho job định kỳ
Băng thông và egress Kéo image lớn mỗi lần deploy, đọc ghi dữ liệu ra ngoài nhiều Image nhỏ nhiều tầng, cache registry, xử lý gần dữ liệu
Dịch vụ trả tiền còn sót Hóa đơn cố định hằng tháng không thuộc stack OSS Rà danh sách subscription, dùng thẻ ảo cho thử nghiệm

Cạm bẫy nguy hiểm nhất là loại không gây lỗi. Pipeline vẫn xanh, metric vẫn đẹp, chỉ có hóa đơn là khác. Vì vậy chi phí phải được đối xử như một chỉ số của hệ thống, đứng cạnh latency và PSI, chứ không phải thứ chỉ xem cuối tháng.

Bài tập 1. Job train capstone chạy trên spot bị thu hồi hai lần, mỗi lần mất 40 phút. Bạn thấy gì và sửa gì?

Xem gợi ý

Thiếu checkpoint nên mỗi lần bị thu hồi là trả tiền lại từ đầu. Sửa: ghi checkpoint mỗi epoch lên MinIO kèm resume, đặt số lần retry tối đa, và đo tỷ lệ thu hồi của loại instance trước khi chọn. Nếu tỷ lệ thu hồi cao, chuyển sang loại spot ổn định hơn hoặc chạy giờ thấp điểm.

Checklist vận hành hằng tuần

Nguyên tắc: 30 phút, cùng một ngày mỗi tuần, cùng một thứ tự, và ghi lại kết quả. Checklist không có bản ghi thì tuần sau bạn sẽ tranh luận lại từ đầu.

  1. Đối chiếu hóa đơn: xuất chi phí theo dịch vụ, so với baseline tuần trước, đánh dấu chênh lệch trên 20%.
  2. Dọn tài nguyên mồ côi: liệt kê instance, volume, snapshot có CPU dưới 5% hoặc thiếu nhãn, tắt hoặc xóa.
  3. Siết lưu trữ: xem dung lượng MinIO và MLflow, chạy retention cho artifact cũ hơn N ngày.
  4. Rà log: kiểm tra log level, khối lượng log mỗi ngày, tắt DEBUG ở production.
  5. Xem drift và quyết định retrain: chỉ train khi PSI vượt ngưỡng, không train theo lịch cố định.
  6. Kiểm tra serving: replica trung bình so với RPS, có GPU nào nhàn rỗi không.
  7. Test cảnh báo ngân sách: cố tình vượt ngưỡng 80%, xác nhận có email hoặc tin nhắn thật.
  8. Ghi báo cáo chi phí: một dòng chi phí tuần, một dòng hành động đã làm.

Ba ngưỡng nên đặt: 80% ngân sách tháng là cảnh báo, 100% là hành động (tắt bớt tài nguyên), và tuần này vượt 120% trung bình 4 tuần là điều tra nguyên nhân. Ngưỡng tiền không bắt được mọi thứ, vì một VPS vài đô vẫn có thể chạy ba tuần mà không ai để ý, nên bước 2 phải dựa trên hành vi sử dụng chứ không chỉ dựa trên số tiền.

Bài tập 2. Một VPS 4GB được dựng để thử serving ba tuần trước, không còn ai dùng. Checklist nào bắt được nó, và vì sao cảnh báo ngân sách không bắt?

Xem gợi ý

Bước 1 và bước 2 bắt được. Cảnh báo ngân sách không bắt vì khoản này quá nhỏ so với ngưỡng, hoặc vì ngưỡng đang tính trên tổng nên bị các khoản khác che lấp. Bài học: luôn có một lớp kiểm tra theo hành vi (CPU thấp, không có nhãn, không có người dùng) song song với lớp kiểm tra theo tiền.

Kinh nghiệm thực chiến: chặn chi phí trước khi nó phát sinh

  • Gắn nhãn mọi tài nguyên ngay khi tạo. Tài nguyên không nhãn là tài nguyên không ai chịu trách nhiệm.
  • Đặt TTL cho mọi thứ mang tính thử nghiệm, kể cả bucket và snapshot.
  • Đừng bao giờ tiết kiệm bằng cách tắt monitoring. Chi phí monitoring rẻ hơn rất nhiều so với một model hỏng chạy ba tuần mà không ai biết.
  • Nếu một tài nguyên không có người dùng cụ thể và không có ngày hết hạn, nó sẽ sống mãi.
  • Ghi lại từng lần tăng chi phí bất thường kèm nguyên nhân. Báo cáo chi phí của capstone sẽ cần đúng những dòng này.

Ôn nhanh trước khi làm capstone

Cạm bẫy chi phí nguy hiểm nhất là loại không gây _____ cho pipeline, nên không có alert nào kêu. Mọi tài nguyên thử nghiệm nên có _____ hoặc lịch xóa tự động ngay khi tạo. Job train trên spot cần ghi _____ để chạy tiếp thay vì làm lại từ đầu. Ở production nên đặt log level _____ thay vì DEBUG để giảm khối lượng log. Cảnh báo ngân sách nên đặt ở mức _____% để còn thời gian xử lý trước khi vượt 100%. Checklist vận hành nên chạy mỗi _____ và ghi lại kết quả.

Front: Phần lớn chi phí trong pipeline MLOps tự host đến từ đâu? Back: Từ thói quen vận hành: tài nguyên mồ côi, lưu trữ không giới hạn, job chạy lại.

Front: Tài nguyên mồ côi là gì? Back: Instance, volume hoặc snapshot vẫn tồn tại và bị tính tiền nhưng không còn workload nào dùng.

Front: Dấu hiệu sớm để phát hiện tài nguyên mồ côi trong một tuần? Back: CPU dưới 5% liên tục 7 ngày hoặc tài nguyên thiếu nhãn project.

Front: Cách chặn lưu trữ artifact phình vô hạn? Back: Đặt retention policy cho MinIO và MLflow, dọn artifact cũ hơn N ngày.

Front: Vì sao job spot bị thu hồi lại làm chi phí tăng? Back: Không có checkpoint nên phải chạy lại từ đầu, trả tiền hai lần cho cùng một công việc.

Front: Log level nào nên dùng ở production? Back: WARN hoặc INFO có chọn lọc, không để DEBUG.

Front: Hai cấu hình serving dễ gây lãng phí nhất? Back: min replicas đặt quá cao và dùng GPU cho model không cần GPU.

Front: Vì sao retrain theo lịch cố định lại tốn kém? Back: Vì train cả khi không có drift; nên train theo tín hiệu PSI hoặc drift.

Front: Chi phí băng thông và egress tăng do đâu? Back: Kéo image lớn mỗi lần deploy và đọc ghi dữ liệu ra ngoài thường xuyên.

Front: Ba ngưỡng cảnh báo chi phí nên đặt là gì? Back: 80% ngân sách là cảnh báo, 100% là hành động, tăng trên 120% so với trung bình 4 tuần là điều tra.

Front: Bước nào trong checklist tuần hay bị bỏ qua nhất? Back: Test cảnh báo ngân sách; alert không hoạt động thì không ai biết khi vượt ngưỡng.

Front: Vì sao không nên cắt monitoring để tiết kiệm? Back: Chi phí monitoring nhỏ hơn nhiều so với model hỏng chạy ba tuần mà không ai phát hiện.

Front: Nguyên tắc một dòng về vòng đời tài nguyên? Back: Không có người dùng cụ thể và không có ngày hết hạn thì tài nguyên sẽ sống mãi.

Chốt lại và bước sang capstone

  • Cạm bẫy chi phí thường không gây lỗi, nên phải chủ động tìm thay vì chờ alert.
  • Sáu nhóm cần rà: tài nguyên mồ côi, lưu trữ phình, spot bị thu hồi, serving quá tay, băng thông, dịch vụ trả tiền còn sót.
  • Checklist tuần 8 bước, chạy cùng ngày, có ghi chép, kèm ba ngưỡng cảnh báo.
  • Kiểm tra theo hành vi sử dụng song song với kiểm tra theo số tiền.

Bài tiếp theo bạn sẽ ghép tất cả lại: pipeline end-to-end hoàn chỉnh và báo cáo chi phí, nơi checklist này trở thành một phần của báo cáo chứ không chỉ là việc làm thêm.