Ghép tất cả lại: một case study end-to-end
Bài này áp dụng mọi thứ đã học vào một tình huống thật. Bạn là AI Infra PM tại một startup SaaS. Sản phẩm là trợ lý viết nội dung dùng LLM. Vấn đề đang nóng: hóa đơn GPU tháng vừa rồi 48.000 USD, tăng 60% so với tháng trước, trong khi doanh thu chỉ tăng 12%. CEO yêu cầu bạn xử lý trong 30 ngày mà không làm hỏng trải nghiệm.
Bước 1: Đo trước khi sửa (baseline)
Bạn không đoán. Bạn thu thập dữ liệu:
- GPU utilization trung bình chỉ 28% — dấu hiệu lãng phí khổng lồ.
- Có 8 replica chạy 24/7, kể cả 2–6h sáng gần như không tải.
- Latency p95 hiện là 620ms; SLO cam kết là p95 < 900ms → còn dư địa đổi độ trễ lấy chi phí.
- Mô hình chạy FP16, mỗi GPU chỉ tải 1 bản.
- Không có batching động; mỗi request xử lý gần như riêng lẻ.
Bước 2: Lập danh sách đòn bẩy theo tác động/rủi ro
| Đòn bẩy | Tác động chi phí | Rủi ro | Ưu tiên |
|---|---|---|---|
| Continuous batching | Cao (utilization 28%→65%) | Latency tăng nhẹ, vẫn trong SLO | 1 |
| Autoscaling ban đêm | Trung bình | Cold start giờ thấp điểm | 2 |
| Quantization INT8 | Cao (nhồi 2 bản/GPU) | Chất lượng có thể giảm | 3 (cần eval) |
| Đổi sang GPU rẻ hơn | Trung bình | Throughput thay đổi | 4 |
Bước 3: Triển khai theo thứ tự an toàn
- Continuous batching trước — ít rủi ro chất lượng, tận dụng dư địa latency (p95 620→780ms, vẫn < 900ms). Utilization lên ~65%, throughput ×2.
- Autoscaling — giảm 8 replica ban ngày, min 2 replica ban đêm, pre-warm 7h sáng trước giờ cao điểm. Cắt GPU chạy không tải.
- Quantization INT8 có eval — chạy bộ eval chất lượng nội dung trước/sau. Chất lượng chênh <1% → chấp nhận, nhồi 2 bản mô hình/GPU.
Bước 4: Kết quả và trình bày
Kết quả điển hình: hóa đơn từ 48.000 xuống ~19.000 USD/tháng (giảm ~60%), p95 vẫn 780ms < SLO 900ms, chất lượng giữ nguyên, tiêu thụ điện giảm theo. Bạn trình bày với ba con số CEO cần: chi phí giảm, SLO vẫn đạt, năng lượng giảm.
Bước 5: Chống tái phát
Tối ưu một lần rồi để trôi là sai lầm. Bạn thiết lập:
- Dashboard theo dõi utilization, cost/1K token, p95/p99, error budget.
- Alert khi cost/request vượt ngưỡng.
- Rà soát unit economics hàng tháng.
- Chính sách error budget để cân bằng tốc độ và ổn định.
Khung tư duy 5 bước (mang đi dùng lại)
- Đo baseline — không sửa khi chưa có số.
- Liệt kê đòn bẩy theo tác động và rủi ro.
- Triển khai từ an toàn tới rủi ro, đo lại sau mỗi bước.
- Bảo vệ SLO & chất lượng bằng eval và error budget.
- Thể chế hóa bằng dashboard, alert, rà soát định kỳ.
Checklist tối ưu nền tảng inference
- [ ] Có baseline utilization, latency percentile, cost/request.
- [ ] Xác định dư địa latency so với SLO trước khi đánh đổi.
- [ ] Ưu tiên đòn bẩy ít rủi ro chất lượng trước.
- [ ] Luôn eval chất lượng quanh quantization/đổi mô hình.
- [ ] Đo lại sau mỗi thay đổi; theo dõi error budget.
- [ ] Thiết lập giám sát chống tái phát.
Sai lầm thường gặp
- Nhảy vào tối ưu mà không đo. Không biết đâu là nút thắt thật.
- Làm mọi thứ cùng lúc. Khi có sự cố không biết đòn bẩy nào gây ra.
- Đánh đổi hết dư địa latency. Không chừa biên an toàn cho đỉnh tải.
- Tối ưu một lần rồi quên. Chi phí sẽ bò trở lại nếu không giám sát.