Ở các bài trước, chúng ta đã đi qua bốn phần:

• Phần 1: LLM engine & engine core: nền tảng của vLLM
• Phần 2: Các tính năng nâng cao
• Phần 3: Scaling up: từ một GPU đến nhiều GPU
• Phần 4: Serving layer: hệ thống phân tán

Lần này, đến với phần 5, cũng là phần cuối: Benchmark và tự động tinh chỉnh – độ trễ và thông lượng

Cho đến nay chúng ta đã phân tích các “hạt khí”, tức các chi tiết bên trong về cách các yêu cầu đi qua engine/hệ thống. Vậy làm thế nào để đo hiệu năng của một hệ thống suy luận?

Ở mức cao nhất có hai chỉ số cạnh tranh nhau:

1. Độ trễ (Latency): thời gian từ khi một yêu cầu được gửi cho đến khi các token được trả về.
2. Thông lượng (Throughput): số token/yêu cầu mỗi giây mà hệ thống có thể sinh ra/xử lý.

Độ trễ quan trọng nhất đối với các ứng dụng tương tác, nơi người dùng đang chờ phản hồi.

Thông lượng quan trọng đối với các tác vụ ngoại tuyến như tạo dữ liệu tổng hợp cho các lần chạy tiền huấn luyện/hậu huấn luyện, làm sạch/xử lý dữ liệu, và nói chung là mọi loại công việc suy luận theo lô ngoại tuyến.

Trước khi giải thích vì sao độ trễ và thông lượng cạnh tranh với nhau, hãy định nghĩa một vài chỉ số suy luận phổ biến:

• TTFT (time to first token): Thời gian từ khi gửi yêu cầu đến khi nhận được token đầu ra đầu tiên
• ITL (inter-token latency): Thời gian giữa hai token liên tiếp (ví dụ: từ token i-1 đến token i)
• TPOT (time per output token): Giá trị ITL trung bình trên tất cả các token đầu ra trong một yêu cầu
• Latency / E2E (end-to-end latency): Tổng thời gian để xử lý một yêu cầu, tức TTFT + tổng tất cả các ITL, hay tương đương thời gian từ lúc gửi yêu cầu đến lúc nhận token đầu ra cuối cùng
• Throughput: Tổng số token được xử lý mỗi giây (đầu vào, đầu ra hoặc cả hai), hoặc số yêu cầu mỗi giây.
• TTFT (time to first token): Thời gian từ khi gửi yêu cầu đến khi nhận được token đầu ra đầu tiên
• Goodput: Thông lượng đáp ứng các mục tiêu mức dịch vụ (SLO) như TTFT tối đa, TPOT hoặc độ trễ e2e. Ví dụ, chỉ các token từ những yêu cầu đáp ứng các SLO đó mới được tính.

Đây là một mô hình đơn giản giải thích bản chất cạnh tranh của hai chỉ số này.

Lưu ý: Giả định: I/O trọng số (weight I/O), chứ không phải I/O của KV cache, chiếm ưu thế; tức là chúng ta đang xử lý các chuỗi ngắn.

Sự đánh đổi trở nên rõ ràng khi nhìn vào cách kích thước batch B ảnh hưởng đến một bước decode đơn lẻ. Khi B ↓ tiến về 1, ITL giảm: có ít công việc hơn trong mỗi bước và token không phải “cạnh tranh” với các token khác. Khi B ↑ tiến về vô cực, ITL tăng vì chúng ta thực hiện nhiều FLOP hơn trong mỗi bước, nhưng thông lượng được cải thiện (cho đến khi đạt hiệu năng đỉnh) vì chi phí I/O của trọng số được phân bổ cho nhiều token hơn.

Một mô hình roofline giúp hiểu điều này: dưới một kích thước batch bão hòa B_sat, thời gian của mỗi bước bị chi phối bởi băng thông HBM (streaming trọng số từng lớp vào bộ nhớ trên chip), nên độ trễ của bước gần như phẳng – tính 1 token hay 10 token có thể mất thời gian tương tự. Vượt quá B_sat, các kernel trở nên bị giới hạn bởi năng lực tính toán và thời gian của bước tăng xấp xỉ theo B; mỗi token bổ sung làm tăng ITL.

Cách benchmark trong vLLM

vLLM cung cấp CLI vllm bench {serve,latency,throughput} bao bọc các script vllm/benchmarks/{server,latency,throughput}.py.

Các script này thực hiện như sau:

• latency:  dùng đầu vào ngắn (mặc định 32 token) và lấy mẫu 128 token đầu ra với batch nhỏ (mặc định 8). Nó chạy nhiều vòng và báo cáo độ trễ e2e của batch.
• throughput: gửi một tập prompt cố định (mặc định: 1000 mẫu ShareGPT) cùng lúc (còn gọi là chế độ QPS=Inf), và báo cáo số token đầu vào/đầu ra/tổng cùng số yêu cầu mỗi giây trong toàn bộ lần chạy.
• serve: khởi chạy một server vLLM và mô phỏng tải thực tế bằng cách lấy mẫu thời gian đến của các yêu cầu từ phân phối Poisson (hoặc tổng quát hơn là Gamma). Nó gửi các yêu cầu trong một khoảng thời gian, đo tất cả các chỉ số đã thảo luận, và có thể tùy chọn áp đặt giới hạn đồng thời phía server (qua semaphore, ví dụ giới hạn server ở 64 yêu cầu đồng thời).

Ví dụ chạy script đo độ trễ:

vllm bench latency 

–model <model-name> 

–input-tokens 32 

–output-tokens 128 

–batch-size 8

Lưu ý: Các cấu hình benchmark được sử dụng trong CI nằm tại đường dẫn `.buildkite/nightly-benchmarks/tests`.

Ngoài ra còn có một tập lệnh tự động tinh chỉnh (auto-tune script) giúp điều phối quy trình đo hiệu năng phục vụ (serve benchmark) nhằm tìm ra các thiết lập tham số đáp ứng các mục tiêu SLO (ví dụ: “tối đa hóa thông lượng trong khi vẫn giữ độ trễ đầu-cuối p99 dưới 500 ms”), từ đó trả về cấu hình được đề xuất.

Lời kết

Chúng ta bắt đầu từ lõi engine cơ bản (UniprocExecutor), bổ sung các tính năng nâng cao như speculative decoding và prefix caching, mở rộng lên MultiProcExecutor (với TP/PP > 1), và cuối cùng mở rộng theo chiều ngang, bọc toàn bộ trong engine bất đồng bộ và stack phục vụ phân tán, kết thúc bằng cách đo lường hiệu năng hệ thống.

Bài viết dừng lại ở kiến trúc và cơ chế vận hành của vLLM, nhưng hành trình triển khai thực tế còn cần một nền tảng GPU đủ mạnh để kiểm chứng các tối ưu này. iRender mang đến GPU Cloud hiệu năng chuyên sâu cho AI & Deep Learning, sẵn sàng cho các tác vụ từ nghiên cứu, fine-tuning đến serving LLM quy mô lớn.

Phần 1: LLM engine & engine core: nền tảng của vLLM

Phần 2: Các tính năng nâng cao

Phần 3: Scaling up: từ một GPU đến nhiều GPU

Phần 4: Hệ thống phân tán phục vụ vLLM