Bài 3 — Batching, autoscaling và quantization

Ba đòn bẩy kỹ thuật PM cần hiểu

Bài này giới thiệu ba kỹ thuật bạn không cần tự code nhưng bắt buộc hiểu để ra quyết định và trao đổi với kỹ sư: batching, autoscaling, và quantization. Mỗi cái là một cần gạt trên bàn điều khiển chi phí/độ trễ.

1. Batching — nhồi nhiều request vào một lần chạy

GPU thích làm việc song song. Xử lý 1 request lãng phí như chở 1 người bằng xe buýt. Batching gom nhiều request lại chạy cùng lúc, đẩy throughput lên nhiều lần.

• Static batching: chờ đủ N request rồi chạy. Đơn giản nhưng request đến sớm phải chờ, độ trễ tăng.
• Dynamic / continuous batching: kỹ thuật hiện đại (dùng trong vLLM, TGI) cho phép request mới nhảy vào batch đang chạy khi có slot trống. Đây là bước nhảy lớn về hiệu quả cho LLM, vì các request có độ dài khác nhau.

Đánh đổi PM cần nắm: batch càng lớn → throughput càng cao, chi phí/request càng thấp, nhưng độ trễ p99 càng xấu. Bạn chọn max batch size theo SLO độ trễ.

2. Autoscaling — co giãn theo tải

Tải AI hiếm khi phẳng. Ban ngày cao, ban đêm thấp; có đỉnh khi chạy chiến dịch. Autoscaling tự động tăng/giảm số bản sao (replica) hoặc GPU theo tải.

Hai điểm đau đặc thù của GPU mà PM phải biết:

• Cold start chậm. Nạp một mô hình lớn vào GPU có thể mất từ vài chục giây tới vài phút. Khác hẳn web server bật trong mili-giây. Nghĩa là autoscaling phản ứng trễ — nếu chờ tới khi quá tải mới scale, người dùng đã kịp gặp lỗi.
• Scale không mượt. Bạn thêm nguyên một GPU chứ không thêm từng chút, nên chi phí nhảy bậc thang.

Giải pháp thực tế: giữ min replica đủ để hứng tải nền + đặt ngưỡng scale sớm (scale khi utilization đạt ~60% chứ không đợi 95%) + cân nhắc pre-warming trước giờ cao điểm đã biết trước.

3. Quantization — nén mô hình

Quantization giảm độ chính xác số học của trọng số mô hình, ví dụ từ FP16 (16 bit) xuống INT8 (8 bit) hoặc INT4 (4 bit). Kết quả:

• Mô hình nhỏ hơn → tốn ít bộ nhớ GPU → chạy được trên chip rẻ hơn hoặc nhồi được nhiều bản hơn.
• Chạy nhanh hơn → throughput cao, chi phí thấp.
• Đánh đổi: chất lượng có thể giảm nhẹ. INT8 thường gần như không mất chất lượng; INT4 có thể ảnh hưởng rõ hơn với tác vụ khó.

Quy tắc PM: quantization là bữa trưa gần-như-miễn-phí, nhưng phải đo chất lượng trước và sau bằng eval thật của use case, đừng tin lời hứa suông.

Ví dụ phối hợp cả ba

Một dịch vụ tóm tắt tài liệu: bật continuous batching (throughput ×3), quantize xuống INT8 (nhồi 2 bản mô hình/GPU, chất lượng gần như nguyên vẹn), và autoscaling giữ min 2 replica ban ngày, giảm về 1 ban đêm. Kết quả điển hình: chi phí giảm 50–70% mà SLO độ trễ vẫn đạt.

Khung quyết định nhanh

• Chi phí cao vì throughput thấp? → Batching trước tiên.
• Trả tiền GPU chạy không tải ngoài giờ? → Autoscaling.
• Hết bộ nhớ GPU / cần chip rẻ hơn? → Quantization (kèm eval).

Checklist

• [ ] Xác định max batch size tương thích với SLO p99.
• [ ] Dùng continuous batching cho workload LLM nếu engine hỗ trợ.
• [ ] Đặt min replica + ngưỡng scale sớm để né cold start.
• [ ] Pre-warm trước đỉnh tải đã biết.
• [ ] Đo chất lượng trước/sau quantization bằng eval của chính use case.

Sai lầm thường gặp

• Batch quá lớn cho real-time. Giết chết độ trễ để tiết kiệm vài đồng.
• Autoscaling như web thường. Quên cold start GPU → scale trễ, lỗi tràn.
• Quantize mù quáng. INT4 cho tác vụ khó mà không eval → tụt chất lượng âm thầm.
• Chỉ dùng một đòn bẩy. Ba kỹ thuật cộng hưởng mạnh nhất khi phối hợp.