Giải mã vLLM: Kiến trúc hệ thống suy luận LLM hiệu năng cao

Trong bài viết này, tôi sẽ dần dần giới thiệu tất cả các thành phần cốt lõi của hệ thống và các tính năng nâng cao tạo nên một hệ thống suy luận LLM hiện đại có lưu lượng cao. Cụ thể, tôi sẽ phân tích cách thức hoạt động của vLLM [1].

Đây là bài viết đầu tiên trong một loạt bài. Nội dung bắt đầu từ tổng quan rồi đi sâu dần vào chi tiết (theo phương pháp hình tháp ngược) để bạn có thể hình thành một mô hình tư duy cấp cao chính xác về toàn bộ hệ thống mà không bị choáng ngợp bởi các chi tiết vụn vặt.

Các bài viết sau sẽ đi sâu vào từng hệ thống con cụ thể.

Bài viết này được cấu trúc thành năm phần:

📝Ghi chú

LLM Engine & Engine Core

LLM engine là khối xây dựng cơ bản của vLLM. Bản thân nó đã cho phép thực hiện suy luận lưu lượng cao - nhưng chỉ trong môi trường ngoại tuyến (offline). Bạn chưa thể phục vụ người dùng qua web với nó.

Chúng ta sẽ sử dụng đoạn mã suy luận ngoại tuyến sau đây làm ví dụ xuyên suốt (được điều chỉnh từ basic.py).

📝Các biến môi trường:

Cấu hình này là:

Từ đây, chúng ta sẽ dần xây dựng lên một hệ thống suy luận trực tuyến, bất đồng bộ, đa GPU, đa node - nhưng vẫn phục vụ một mô hình transformer tiêu chuẩn.

Trong ví dụ này, chúng ta thực hiện hai việc:

Hãy bắt đầu phân tích hàm khởi tạo (constructor).

Hàm khởi tạo LLM Engine

Các thành phần chính của engine bao gồm:

📝Lưu ý:

Với việc engine V0 bị loại bỏ dần, tên lớp và các chi tiết có thể thay đổi. Tôi sẽ nhấn mạnh vào các ý tưởng cốt lõi thay vì các chữ ký (signatures) chính xác. Tôi sẽ trừu tượng hóa một số chi tiết nhưng không phải tất cả.

Bản thân Engine core được tạo thành từ một vài thành phần con:

Trình quản lý KV-cache duy trì một free_block_queue - một nhóm các khối KV-cache khả dụng (thường ở quy mô hàng trăm nghìn, tùy thuộc vào dung lượng VRAM và kích thước khối). Trong quá trình paged attention, các khối này đóng vai trò là cấu trúc lập chỉ mục để ánh xạ các token tới các khối KV cache đã tính toán của chúng.

Các thành phần cốt lõi được mô tả trong phần này và mối quan hệ giữa chúng

Kích thước khối cho một lớp transformer tiêu chuẩn (không phải MLA [4]) được tính như sau: 2 (key/value) * block_size (mặc định=16) * num_kv_heads * head_size * dtype_num_bytes (ví dụ: 2 cho bf16)

Trong quá trình xây dựng model executor, một đối tượng Worker được tạo ra và ba quy trình chính được thực thi. (Sau này, với MultiProcExecutor, các quy trình tương tự này chạy độc lập trên mỗi tiến trình worker trên các GPU khác nhau.)

Tôi đã trừu tượng hóa nhiều chi tiết cấp thấp ở đây — nhưng đây là những phần cốt lõi mà tôi sẽ giới thiệu ngay bây giờ, vì tôi sẽ nhắc lại chúng nhiều lần trong các phần tiếp theo.

Bây giờ khi đã khởi tạo xong engine, hãy chuyển sang hàm generate.

Hàm generate

Bước đầu tiên là xác thực và đưa các yêu cầu vào engine. Với mỗi prompt, chúng ta:

Tại thời điểm này, engine đã được nạp dữ liệu và quá trình thực thi có thể bắt đầu. Trong ví dụ về engine đồng bộ, các prompt ban đầu này là những prompt duy nhất chúng ta xử lý — không có cơ chế nào để đưa thêm yêu cầu mới vào giữa chừng. Ngược lại, engine bất đồng bộ hỗ trợ điều này (còn gọi là continuous batching [6]): sau mỗi bước, cả yêu cầu mới và cũ đều được xem xét.

Vì quá trình forward pass làm phẳng batch thành một chuỗi duy nhất và các kernel tùy chỉnh xử lý nó một cách hiệu quả, continuous batching về cơ bản được hỗ trợ ngay cả trong engine đồng bộ.

Tiếp theo, chừng nào còn yêu cầu cần xử lý, engine sẽ liên tục gọi hàm step của nó. Mỗi bước có ba giai đoạn:

📝Các điều kiện dừng là:

Vòng lặp Engine

Ở chế độ streaming, chúng ta sẽ gửi các token trung gian ngay khi chúng được tạo ra, nhưng hiện tại chúng ta sẽ bỏ qua điều đó.

Tiếp theo, chúng ta sẽ xem xét kỹ hơn về lập lịch (scheduling).

Scheduler

Có hai loại khối lượng công việc chính mà một engine suy luận xử lý:

Trong phần đánh giá hiệu năng (benchmarking), chúng ta sẽ phân tích cái gọi là mô hình roofline của hiệu năng GPU. Phần đó sẽ đi sâu hơn vào các cấu hình hiệu năng prefill/decode.

Scheduler V1 có thể kết hợp cả hai loại yêu cầu trong cùng một bước nhờ các lựa chọn thiết kế thông minh hơn. Ngược lại, engine V0 chỉ có thể xử lý prefill hoặc decode tại một thời điểm.

Scheduler ưu tiên các yêu cầu decode — tức là những yêu cầu đã nằm trong hàng đợi đang chạy. Với mỗi yêu cầu như vậy, nó:

Sau đó, nó xử lý các yêu cầu prefill từ hàng đợi chờ, nó: