AI hay gặpLLM serving có bộ chỉ số riêng; đo như web API thường sẽ không thấy nút thắt nằm ở đâu.
Độ trễ — nhìn theo hai pha, đừng nhìn con số tổng:
- TTFT (Time To First Token) — từ lúc nhận request đến token đầu tiên. Đây là chỉ số quyết định cảm giác "nhanh" của người dùng, dưới 1s là ngưỡng dễ chịu. Nó phản ánh pha prefill nên phụ thuộc độ dài prompt và độ sâu hàng đợi.
- ITL / TPOT (Inter-Token Latency) — khoảng cách giữa các token sau đó. Phản ánh pha decode, phụ thuộc băng thông bộ nhớ và mức tranh chấp trong batch.
- Tổng độ trễ ≈ TTFT + số token sinh × ITL. Luôn đọc p95/p99 thay vì trung bình — phần đuôi mới là phần người dùng phàn nàn.
Tách được hai chỉ số này thì mới biết sửa gì: TTFT cao là nghẽn prefill hoặc xếp hàng, ITL cao là nghẽn băng thông bộ nhớ.
Thông lượng: dùng output tokens/giây của cả hệ cho capacity planning, không dùng RPS — vì độ dài mỗi request chênh nhau rất xa.
GPU và batch — phải nhìn cùng nhau:
- GPU utilization nên trên 80% khi có tải; thấp hơn nghĩa là nút thắt nằm ngoài GPU, hoặc batch đang quá nhỏ.
- Bộ nhớ GPU giữ khoảng 85–95% (tham số gpu_memory_utilization của vLLM): thấp là phí VRAM, cao quá là rủi ro OOM.
- Batch occupancy — trung bình bao nhiêu request trong một batch. Đây là chỉ số hay thiếu nhất: GPU nhàn có thể do tải nhẹ, cũng có thể do batch nhỏ, và hai nguyên nhân đó xử lý hoàn toàn khác nhau.
- Preemption rate cao nghĩa là scheduler phải hoãn request vì thiếu bộ nhớ — dấu hiệu cần scale.
Mức ứng dụng: chi phí theo request và theo tính năng, tỉ lệ trúng cache (prompt cache lẫn semantic cache), lượng token theo từng tính năng để biết prompt nào đang đắt.
Công cụ: DCGM Exporter + Prometheus cho tầng GPU; vLLM/TGI tự expose sẵn /metrics; Langfuse hoặc Phoenix cho trace ở tầng ứng dụng.
Lỗi hay gặp: chỉ log tổng độ trễ nên không biết prefill hay decode chậm; theo dõi GPU utilization mà không có batch occupancy; không gắn một request id xuyên suốt app → gateway → serving nên khi cần debug thì không lần được đường đi.