Công cụ suy luận mã nguồn mở vLLM đã thu hút sự chú ý đáng kể nhờ khả năng phục vụ các mô hình ngôn ngữ lớn một cách hiệu quả ở quy mô lớn. Một phân tích kỹ thuật chi tiết cho thấy hệ thống đạt được thông lượng cao thông qua các chiến lược batching sáng tạo và kỹ thuật quản lý bộ nhớ giúp tối đa hóa việc sử dụng GPU mà không ảnh hưởng đến chất lượng phản hồi.
Các thành phần kiến trúc vLLM V1:
- AsyncLLM: Wrapper bất đồng bộ xử lý tokenization và giao tiếp IPC
- EngineCore: Engine suy luận cốt lõi với logic lập lịch và thực thi
- Scheduler: Quản lý việc gộp batch các yêu cầu và phân bổ token
- ModelExecutor: Điều phối việc tải model trên các GPU worker sử dụng Ray
- ModelRunner: Thực hiện forward pass trên từng GPU riêng lẻ
- KVCacheManager: Quản lý bộ nhớ GPU như hệ thống phân trang với các block có kích thước cố định
 |
|---|
| Khám phá vLLM: Cách các mô hình ngôn ngữ lớn được triển khai hiệu quả ở quy mô lớn |
Continuous Batching Duy trì Chất lượng Đồng thời Tăng Hiệu quả
Một trong những mối quan tâm chính của các nhà phát triển về việc batching nhiều yêu cầu là liệu nó có ảnh hưởng đến hiệu suất mô hình hay không. Thảo luận cộng đồng cho thấy cách tiếp cận của vLLM giải quyết mối quan tâm này một cách hiệu quả. Khác với các phương pháp batching truyền thống có thể kết hợp các prompt khác nhau vào cùng một ngữ cảnh, vLLM xử lý các yêu cầu riêng biệt song song trong khi chia sẻ tài nguyên tính toán. Điều này có nghĩa là không có sự đánh đổi về độ phức tạp hoặc chất lượng phản hồi - người dùng nhận được hiệu suất mô hình tương tự như họ mong đợi từ các yêu cầu riêng lẻ, nhưng với hiệu quả được cải thiện đáng kể.
Thuật toán continuous batching hoạt động bằng cách duy trì một ngân sách token linh hoạt trên nhiều yêu cầu. Ví dụ, nếu ba yêu cầu có lần lượt 3, 5 và 12 prompt token với ngân sách 10 token, bộ lập lịch có thể xử lý 3 token từ yêu cầu đầu tiên, 5 từ yêu cầu thứ hai và 2 từ yêu cầu thứ ba trong một lần forward pass duy nhất. Việc phân bổ động này đảm bảo tài nguyên GPU được sử dụng hết công suất trong khi duy trì tính công bằng giữa các yêu cầu.
Ngân sách token: Số lượng token tối đa có thể được xử lý trong một lần forward pass duy nhất qua mô hình
Ví dụ về Continuous Batching:
- 3 yêu cầu với lần lượt 3, 5, và 12 prompt token
- Ngân sách token là 10 token cho mỗi lần forward pass
- Bước 0: Xử lý 3 token (R1) + 5 token (R2) + 2 token (R3)
- Bước 1: Xử lý 8 token còn lại (R3) + 1 decode token cho mỗi yêu cầu (R1, R2)
 |
|---|
| Quá trình phân bổ token trong continuous batching cải thiện hiệu quả cho nhiều yêu cầu |
Giới hạn Băng thông Bộ nhớ Cho phép Xử lý Song song
Hiệu quả của cách tiếp cận batching của vLLM xuất phát từ một đặc điểm cơ bản của các kiến trúc LLM hiện tại. Các mô hình ngôn ngữ hiện đại bị giới hạn nghiêm trọng bởi băng thông bộ nhớ thay vì khả năng tính toán. Tắc nghẽn này xảy ra vì hệ thống dành thời gian đáng kể để chờ các trọng số mô hình chuyển từ bộ nhớ video (VRAM) sang bộ nhớ băng thông cao (HBM). Trong những khoảng thời gian chờ này, việc xử lý nhiều yêu cầu đồng thời trở nên gần như miễn phí từ góc độ tính toán.
Hiểu biết này giải thích tại sao vLLM có thể đạt được những cải thiện hiệu suất đáng kể như vậy. Hệ thống về cơ bản lấp đầy những khoảng trống tính toán mà nếu không sẽ bị lãng phí khi chờ truyền tải bộ nhớ. Các lõi GPU vốn sẽ nhàn rỗi trong các hoạt động bộ nhớ thay vào đó có thể làm việc trên các yêu cầu bổ sung mà không ảnh hưởng đến tốc độ xử lý của các yêu cầu riêng lẻ.
Đặc điểm hiệu suất theo từng giai đoạn:
- Giai đoạn Prefill: Sử dụng tính toán cao, I/O bộ nhớ thấp, xử lý tất cả token prompt song song
- Giai đoạn Decode: Yêu cầu tính toán nhẹ, I/O bộ nhớ nặng để truy cập KV cache, tạo token tuần tự
- Nút thắt bộ nhớ: Các kiến trúc LLM hiện tại bị giới hạn bởi băng thông bộ nhớ thay vì khả năng tính toán
Paged Attention và Quản lý KV Cache
Ngoài continuous batching, hệ thống quản lý bộ nhớ của vLLM đóng vai trò quan trọng trong các lợi thế hiệu suất của nó. Hệ thống sử dụng một kỹ thuật gọi là Paged Attention, ban đầu được phát triển bởi nhóm vLLM và sau đó được các công cụ suy luận khác áp dụng. Cách tiếp cận này xử lý bộ nhớ GPU như một hệ thống phân trang, lưu trữ dữ liệu key-value (KV) cache trong các khối có kích thước cố định thay vì yêu cầu phân bổ bộ nhớ liền kề lớn.
KV cache lưu trữ các khóa và giá trị attention của transformer cho mỗi token, điều này rất cần thiết để tạo ra các token tiếp theo một cách hiệu quả. Bằng cách phân đoạn cache này thành các khối có thể quản lý được, vLLM có thể phân bổ bộ nhớ động theo nhu cầu và tránh các vấn đề phân mảnh bộ nhớ gây khó khăn cho các hệ thống phục vụ khác. Cách tiếp cận dựa trên khối này cũng cho phép sử dụng bộ nhớ tốt hơn trên nhiều yêu cầu đồng thời.
KV cache: Bộ nhớ GPU lưu trữ các khóa và giá trị attention từ các token trước đó, cho phép tạo ra các token mới một cách hiệu quả mà không cần tính toán lại các trạng thái quá khứ
Đặc điểm Hiệu suất Prefill so với Decode
Hệ thống xử lý hai giai đoạn suy luận khác biệt một cách khác nhau, mỗi giai đoạn có các đặc điểm hiệu suất riêng. Trong giai đoạn prefill, tất cả các prompt token có thể được xử lý đồng thời vì các tensor truy vấn cho mỗi vị trí đều có sẵn ngay lập tức. Việc xử lý song song này làm cho các hoạt động prefill tương đối nhanh và tính toán chuyên sâu với yêu cầu I/O bộ nhớ tối thiểu.
Giai đoạn decode hoạt động khác biệt, tạo ra các token từng cái một theo trình tự. Mỗi token mới phụ thuộc vào đầu ra của token trước đó, ngăn cản việc tạo ra song song trong một yêu cầu duy nhất. Tuy nhiên, giai đoạn này yêu cầu I/O bộ nhớ rộng rãi để truy cập các khóa và giá trị được lưu trữ từ giai đoạn prefill. Sự tương phản giữa các giai đoạn này làm nổi bật tại sao việc batching nhiều yêu cầu trở nên có giá trị hơn nữa - trong khi một yêu cầu chờ các hoạt động bộ nhớ, những yêu cầu khác có thể sử dụng các tài nguyên tính toán có sẵn.
Câu hỏi về Hiệu suất và Tối ưu hóa Tương lai
Mặc dù có giải thích kỹ thuật chi tiết, một số thành viên cộng đồng đã lưu ý về việc thiếu các benchmark hiệu suất cụ thể và thông số kỹ thuật phần cứng. Việc thiếu các con số thông lượng cụ thể khiến việc đánh giá hiệu suất của vLLM so với các lựa chọn thay thế hoặc ước tính hiệu suất dự kiến trên các cấu hình phần cứng cụ thể trở nên khó khăn.
Có thêm hiệu suất bạn có thể vắt ra từ vLLM
Các cơ hội tối ưu hóa bổ sung tồn tại ngoài các khả năng cốt lõi của vLLM. Một số tổ chức đang xây dựng dựa trên nền tảng của vLLM bằng cách thêm các hệ thống xếp hàng tập trung và hỗ trợ batching rõ ràng phía client để đạt được tỷ lệ thông lượng cao hơn nữa.
Thảo luận cũng làm nổi bật các cân nhắc triển khai thực tế, chẳng hạn như quản lý các cuộc hội thoại có trạng thái trên nhiều phiên bản mô hình. Trong khi bản thân các mô hình không có trạng thái, ngữ cảnh hội thoại yêu cầu các chiến lược định tuyến cẩn thận ở cấp độ load balancer để duy trì lợi ích hiệu suất từ prompt caching và tái sử dụng KV cache.
Sự kết hợp giữa continuous batching, paged attention và quản lý bộ nhớ hiệu quả của vLLM đại diện cho một bước tiến đáng kể trong công nghệ phục vụ LLM. Bằng cách giải quyết các tắc nghẽn cơ bản trong kiến trúc transformer, hệ thống đạt được những cải thiện hiệu suất đáng kể trong khi duy trì chất lượng phản hồi, khiến nó trở thành một lựa chọn hấp dẫn cho các tổ chức triển khai mô hình ngôn ngữ lớn ở quy mô lớn.
Tham khảo: Life of an inference request (vLLM V1): How LLMs are served efficiently at scale