Hai bài trước, chúng ta đã tìm hiểu về LLM Engine & Engine Core trong hệ thống suy luận LLM thông lượng cao  và Các tính năng nâng cao – mở rộng logic lõi của engine. 

Trong bài viết này, chúng ta sẽ cùng khám phá phần 3: Scaling up: từ một GPU đến nhiều GPU.

Khi các kỹ thuật cốt lõi đã được thiết lập, giờ chúng ta có thể nói về việc mở rộng quy mô.

Giả sử trọng số mô hình của bạn không còn vừa trong VRAM của một GPU đơn lẻ nữa.

Lựa chọn đầu tiên là phân mảnh mô hình trên nhiều GPU trong cùng một node bằng tensor parallelism (ví dụ: TP=8). Nếu mô hình vẫn không vừa, bước tiếp theo là pipeline parallelism giữa các node.

Lưu ý: Băng thông trong cùng một node cao hơn đáng kể so với giữa các node, đó là lý do tensor parallelism (TP) thường được ưu tiên hơn pipeline parallelism (PP). (Cũng đúng là PP truyền ít dữ liệu hơn TP.)

Ở giai đoạn này, chúng ta cần nhiều tiến trình GPU (worker) và một lớp điều phối để phối hợp chúng. Đó chính xác là những gì MultiProcExecutor cung cấp.

Cách điều này hoạt động trong vLLM:

1. MultiProcExecutor khởi tạo một hàng đợi thông điệp rpc_broadcast_mq (được triển khai bằng shared memory ở bên dưới).
2. Hàm khởi tạo lặp qua world_size (ví dụ: TP=8 ⇒ world_size=8) và tạo một tiến trình daemon cho mỗi rank thông qua WorkerProc.make_worker_process.
3. Đối với mỗi worker, tiến trình cha trước tiên tạo một pipe đọc và một pipe ghi.
4. Tiến trình mới chạy WorkerProc.worker_main, tiến trình này khởi tạo một worker (đi qua cùng các bước “init device”, “load model”, v.v. như trong UniprocExecutor).
5. Mỗi worker xác định liệu nó có phải là driver (rank 0 trong nhóm TP) hay là một worker thông thường. Mỗi worker thiết lập hai hàng đợi:
   • rpc_broadcast_mq (được chia sẻ với tiến trình cha) để nhận công việc.
   • worker_response_mq để gửi phản hồi trở lại.
6. Trong quá trình khởi tạo, mỗi tiến trình con gửi handle của worker_response_mq của nó cho tiến trình cha thông qua pipe. Khi tất cả đều được nhận, tiến trình cha được bỏ chặn — điều này hoàn tất việc điều phối.
7. Sau đó các worker đi vào một vòng lặp bận, chặn trên rpc_broadcast_mq.dequeue. Khi một mục công việc đến, chúng thực thi nó (giống như trong UniprocExecutor, nhưng giờ với phần công việc được phân chia theo TP/PP). Kết quả được gửi trở lại thông qua worker_response_mq.enqueue.
8. Khi chạy thực tế, khi một yêu cầu đến, MultiProcExecutor đưa nó vào rpc_broadcast_mq (không chặn) cho tất cả các worker con. Sau đó nó chờ trên worker_response_mq.dequeue của rank đầu ra được chỉ định để thu thập kết quả cuối cùng.

Từ góc nhìn của engine, không có gì thay đổi, toàn bộ độ phức tạp của multiprocessing này được trừu tượng hóa thông qua lời gọi execute_model của model executor.

• Trong trường hợp UniProcExecutor: execute_model dẫn trực tiếp đến việc gọi execute_model trên worker.
• Trong trường hợp MultiProcExecutor: execute_model dẫn gián tiếp đến việc gọi execute_model trên từng worker thông qua rpc_broadcast_mq.

Tại thời điểm này, chúng ta có thể chạy các mô hình lớn đến mức tài nguyên cho phép bằng cùng một giao diện engine.

Bước tiếp theo là mở rộng theo chiều ngang: bật data parallelism (DP > 1) để sao chép mô hình trên nhiều node, thêm một lớp điều phối DP nhẹ, đưa vào cân bằng tải giữa các bản sao, và đặt một hoặc nhiều API server phía trước để xử lý lưu lượng truy cập đến.

Phần tiếp theo, chúng ta sẽ đến với Phần 4: Hệ thống phân tán phục vụ vLLM

Phần 1: LLM Engine & Engine Core

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

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

Phần 5: Benchmark và tự động tinh chỉnh – độ trễ và thông lượng