Không để GPU nào bị bỏ lại phía sau- Mở khóa hiệu quả với vLLM đồng vị trí trong TRL

June 3, 2025
19 min read

KHÔNG GPU nào bị bỏ lại phía sau: Mở khóa hiệu quả với vLLM đồng vị trí trong TRL

TRL hỗ trợ huấn luyện LLM bằng GRPO, một thuật toán học trực tuyến được giới thiệu gần đây trong bài báo DeepSeekMath. Trong GRPO, mô hình học hỏi từ chính các đầu ra của nó: nó tạo ra các phản hồi trong quá trình huấn luyện, nhận được phản hồi và sử dụng phản hồi đó để cải thiện bản thân theo thời gian.

Điều này làm cho quá trình tạo trở thành một bước quan trọng trong vòng lặp huấn luyện — và cũng là một nút thắt lớn. Để tăng tốc quá trình tạo, TRL tích hợp với vLLM. Sự kết hợp này cho phép bạn huấn luyện các mô hình mạnh mẽ hiệu quả hơn trong thiết lập GRPO. Tuy nhiên, có một nhược điểm.

🧨 Vấn đề

Trước TRL v0.18.0, vLLM chỉ được hỗ trợ ở chế độ máy chủ, chạy như một quy trình riêng biệt trên các GPU khác với công việc huấn luyện. Nó giao tiếp với tập lệnh huấn luyện qua HTTP, điều này làm cho thiết lập trở nên mô-đun và dễ sử dụng — nhưng cũng gây ra sự kém hiệu quả của GPU.

Đây là những gì xảy ra:

Trong quá trình huấn luyện, mô hình cần tạo ra các phần hoàn thành thường xuyên.
Trình huấn luyện gửi yêu cầu đến máy chủ vLLM, chạy trên các GPU riêng của nó.
Trong khi vLLM tạo, các GPU huấn luyện ở trạng thái chờ và đợi.
Sau khi quá trình tạo xong, GPU vLLM trở nên nhàn rỗi, và quá trình huấn luyện tiếp tục.

Quá trình “ping-pong” giữa huấn luyện và tạo ra:

Lãng phí thời gian GPU ở cả hai phía
Tăng nhu cầu về GPU bổ sung chỉ để chạy suy luận
Giảm thông lượng tổng thể và chi phí cao hơn

Trong các phương pháp học trực tuyến như GRPO — nơi quá trình tạo diễn ra liên tục — sự kém hiệu quả này thậm chí còn trở nên khó chịu hơn. Bạn chi nhiều hơn cho phần cứng, nhưng không nhận được hiệu suất như mong đợi.

Vì vậy, câu hỏi quan trọng trở thành: Liệu chúng ta có thể chia sẻ cùng một GPU cho cả huấn luyện và tạo, thay vì tách chúng ra?

💡 Cơ hội

Vấn đề chính là huấn luyện và suy luận chạy trên các GPU riêng biệt, dẫn đến thời gian nhàn rỗi và sử dụng không hết công suất. Giải pháp tự nhiên? Chạy cả hai trên cùng một GPU. Thay vì để vLLM hoạt động như một máy chủ độc lập trong quy trình và thiết bị riêng, điều gì sẽ xảy ra nếu vLLM có thể chạy cùng với mã huấn luyện, trong cùng một nhóm quy trình phân tán? Điều này sẽ cho phép chúng ta khởi chạy một công việc phân tán duy nhất, nơi huấn luyện và suy luận chia sẻ cùng một thiết bị, chuyển đổi giữa các tác vụ một cách hiệu quả mà không lãng phí tài nguyên.

Phương pháp này là những gì chúng ta gọi là đồng vị trí. Huấn luyện và suy luận được đồng vị trí trên cùng một GPU và được điều phối thông qua cùng một nhóm quy trình, cho phép chúng thay phiên nhau một cách trơn tru — không cần thêm phần cứng.

Trước đây, điều này là không thể trong TRL, dựa vào vLLM như một máy chủ HTTP bên ngoài. Điều đó đã thay đổi với PR #3394 của chúng tôi, đã thêm hỗ trợ cho trình khởi chạy bên ngoài của vLLM và tích hợp thực sự vào quy trình huấn luyện.

Những gì nó cho phép

Thực thi thống nhất: Bằng cách nhúng vLLM vào cùng một nhóm quy trình, cả tác vụ huấn luyện và suy luận có thể chia sẻ cùng một GPU, thay phiên nhau thay vì chờ đợi lẫn nhau. Điều này làm giảm thời gian nhàn rỗi và tăng hiệu quả tổng thể.
Bỏ qua giao tiếp HTTP: Không cần gọi API REST hoặc kết nối mạng — vLLM chạy nội tuyến với vòng lặp huấn luyện, tránh được chi phí và độ trễ.
Khả năng tương thích Torchrun: Hoạt động liền mạch với torchrun, vì vậy rất dễ dàng mở rộng quy mô trên các nút với những thay đổi cấu hình tối thiểu.
Hỗ trợ TP và DP: Tương thích với tính song song tensor và tính song song dữ liệu, làm cho nó phù hợp với các lần chạy huấn luyện quy mô lớn.
Mô hình thực thi SPMD: Sử dụng mô hình Single Program, Multiple Data (SPMD), trong đó mỗi GPU chạy phiên bản công cụ của riêng mình đồng bộ. Lý tưởng cho thiết lập đa GPU, đa nút phân tán.
Triển khai đơn giản hóa: Bạn không còn cần duy trì tập lệnh máy chủ riêng — vLLM được khởi chạy và kiểm soát trực tiếp bên trong công việc huấn luyện của bạn.
Thông lượng nâng cao: Bằng cách tránh GPU nhàn rỗi và loại bỏ giao tiếp giữa các quy trình, hệ thống cung cấp quá trình huấn luyện và tạo nhanh hơn, đặc biệt quan trọng trong thiết lập học trực tuyến như GRPO.
Giao tiếp giữa các quy trình mạnh mẽ: Điều này mạnh mẽ hơn vì nó tránh được sự phức tạp của việc thiết lập các nhóm quy trình phân tán giữa các quy trình độc lập, như yêu cầu trong chế độ máy chủ.

Nhờ tính năng này, huấn luyện và suy luận đồng vị trí không còn là một bản hack — giờ đây nó là ưu tiên hàng đầu, có thể mở rộng và sẵn sàng cho sản xuất.

🧩 Thiết kế: Từ các máy chủ riêng biệt đến GPU được chia sẻ

Sự thay đổi từ TRL máy chủ sang TRL đồng vị trí là tất cả về việc sử dụng GPU thông minh hơn. Sơ đồ bên dưới cho thấy sự khác biệt:

gpus-design

Thiết lập TRL máy chủ (Hàng trên cùng)

Trong thiết lập TRL máy chủ, huấn luyện và suy luận chạy trên các GPU riêng biệt. Ví dụ:

GPU 0 đến 2 được sử dụng để huấn luyện.
GPU 3 được dành riêng hoàn toàn để chạy vLLM như một máy chủ riêng biệt.

Trong các bước huấn luyện, GPU 3 ở trạng thái chờ. Trong các bước tạo (suy luận), GPU 0–2 ở trạng thái chờ trong khi GPU 3 tạo ra đầu ra.

Điều này dẫn đến:

Sử dụng GPU không hiệu quả, với các thiết bị thường xuyên chờ đợi lẫn nhau
GPU bổ sung được cung cấp chỉ dành cho suy luận
Tăng chi phí và sự phức tạp

Thiết lập TRL đồng vị trí (Hàng dưới cùng)

Ngược lại, thiết lập TRL đồng vị trí chạy cả huấn luyện và vLLM trên cùng một GPU. Mỗi GPU:

Chạy vòng lặp huấn luyện
Khởi chạy một công cụ vLLM trong cùng một quy trình

Huấn luyện và suy luận thay phiên nhau sử dụng tài nguyên của GPU — không cần thiết bị chuyên dụng hoặc quy trình riêng biệt.

Thiết kế này:

Giảm thời gian nhàn rỗi
Giảm thiểu giao tiếp giữa các quy trình và HTTP
Sử dụng hết bộ nhớ và tính toán GPU có sẵn
Cung cấp thông lượng nhanh hơn mà không tăng yêu cầu về phần cứng

🛠️ Ghi chú triển khai

Thay vì khởi chạy vLLM như một máy chủ, quá trình huấn luyện bây giờ khởi chạy vLLM trong quy trình bằng cách sử dụng trình khởi chạy bên ngoài, như được hiển thị bên dưới:

self.llm = LLM(
    model=model.name_or_path,
    tensor_parallel_size=args.vllm_tensor_parallel_size,
    gpu_memory_utilization=self.vllm_gpu_memory_utilization,
    max_num_seqs=self.args.per_device_train_batch_size
        * self.vllm_tensor_parallel_size
        * self.args.gradient_accumulation_steps,
    max_model_len=self.max_prompt_length + self.max_completion_length,
    distributed_executor_backend="external_launcher",
    # Feed identical seed for tp groups to ensure sampling results are the same across workers
    seed=self.accelerator.process_index // self.vllm_tensor_parallel_size,
)

vLLM đồng vị trí tôn trọng nhóm quy trình và cấu trúc thứ hạng torch.distributed. Điều này cho phép vLLM được khởi tạo cùng với quá trình huấn luyện mà không xung đột và làm cho thiết lập TP/DP hoạt động liền mạch:

if self.vllm_tensor_parallel_size > 1:
    # Create subgroups of ranks for TP, each group with `vllm_tensor_parallel_size` ranks.
    self.tp_group, _ = torch.distributed.new_subgroups_by_enumeration(
        [
            list(range(i * self.vllm_tensor_parallel_size, (i + 1) * self.vllm_tensor_parallel_size))
            for i in range(self.accelerator.num_processes // self.vllm_tensor_parallel_size)
        ]
    )

vLLM đồng vị trí không còn dựa vào API REST — nó chạy trực tiếp trong bộ nhớ và giao tiếp thông qua các lệnh gọi Python gốc:

if self.vllm_tensor_parallel_size > 1:
    orig_size = len(prompts_text)
    gathered_prompts = [None for _ in range(self.vllm_tensor_parallel_size)]
    torch.distributed.all_gather_object(gathered_prompts, prompts_text, group=self.tp_group)
    all_prompts_text = [p for sublist in gathered_prompts for p in sublist]
else:
    all_prompts_text = prompts_text

with profiling_context(self, "vLLM.generate"):
    all_outputs = self.llm.generate(all_prompts_text, sampling_params=sampling_params, use_tqdm=False)

completion_ids = [output.token_ids for outputs in all_outputs for output in outputs.outputs]

if self.vllm_tensor_parallel_size > 1:
    local_rank_in_group = torch.distributed.get_rank(group=self.tp_group)
    tp_slice = slice(local_rank_in_group * orig_size, (local_rank_in_group + 1) * orig_size)
    completion_ids = completion_ids[tp_slice]

Để sử dụng thiết lập này, chỉ cần đặt vllm_mode=“colocate” trong cấu hình GRPO của bạn:

training_args = GRPOConfig(
    ...,
    use_vllm=True,
    vllm_mode="colocate",
)

Lưu ý: Tùy thuộc vào kích thước mô hình và yêu cầu bộ nhớ GPU tổng thể cho quá trình huấn luyện, bạn có thể cần điều chỉnh tham số vllm_gpu_memory_utilization trong GRPOConfig để tránh lỗi sử dụng không hết hoặc hết bộ nhớ.

📊 Trình bày: Hiệu suất TRL đồng vị trí so với TRL thông thường

Để đo lường tác động của việc đồng vị trí, chúng tôi đã chạy một loạt các thí nghiệm so sánh chế độ máy chủ truyền thống (trong đó vLLM chạy trên một GPU riêng biệt như một máy chủ độc lập) với chế độ đồng vị trí mới (trong đó huấn luyện và suy luận chia sẻ cùng một GPU).

Ở chế độ máy chủ, chỉ có 7 GPU được sử dụng để huấn luyện vì 1 GPU được dành riêng hoàn toàn cho máy chủ suy luận vLLM.

Ở chế độ đồng vị trí, tất cả 8 GPU được sử dụng để huấn luyện — tăng kích thước lô hiệu quả theo mặc định.

Để đảm bảo so sánh công bằng, chúng tôi đã chuẩn hóa thông lượng ở chế độ máy chủ theo hệ số 8/7. Điều chỉnh này tính đến khả năng huấn luyện lớn hơn ở chế độ đồng vị trí và cho phép chúng tôi so sánh hai thiết lập trong điều kiện huấn luyện tương đương.

Thí nghiệm 1: Mô hình 1.5B — Thay đổi kích thước lô

Khi kích thước lô tăng lên, thông lượng được cải thiện trong cả hai thiết lập.
Thiết lập đồng vị trí đạt tốc độ nhanh hơn tới 1,43 lần ở kích thước lô lớn nhất.
Các lô lớn hơn tận dụng tốt hơn bộ nhớ GPU được chia sẻ ở chế độ đồng vị trí.

Thí nghiệm 2: Mô hình 1.5B — Thay đổi tính song song Tensor (TP)

Trong thiết lập đồng vị trí, tăng TP làm giảm hiệu suất.
Phân mảnh nhiều hơn giới thiệu nhiều chi phí giao tiếp hơn — điều này không lý tưởng cho các mô hình nhỏ hơn.
Kết luận: Đối với các mô hình nhỏ, hãy tránh phân mảnh quá mức ở chế độ đồng vị trí.

Thí nghiệm 3: Mô hình 7B — Thay đổi kích thước lô

Một lần nữa, chế độ đồng vị trí mở rộng quy mô tốt hơn với kích thước lô.
Mức tăng đạt được tốc độ nhanh hơn 1,35 lần ở lô lớn nhất được kiểm tra.

Thí nghiệm 4: Mô hình 7B — Thay đổi tính song song Tensor (TP)

Xu hướng ngược lại từ mô hình 1.5B.
Với 7B, nhiều TP cải thiện thông lượng hơn, đạt được tốc độ nhanh hơn tới 1,73 lần.
Các mô hình lớn hơn được hưởng lợi từ việc phân mảnh trong thiết lập đồng vị trí.

📊 Mở rộng quy mô lên mô hình 72B

Khi huấn luyện các mô hình lớn như Qwen2.5-Math-72B, điều quan trọng là sử dụng đúng chiến lược để làm cho quá trình huấn luyện hiệu quả, có thể mở rộng và ổn định trên nhiều GPU và nút. Trong thiết lập của mình, chúng tôi đã kết hợp vLLM đồng vị trí với một số tối ưu hóa chính để làm cho việc này hoạt động hiệu quả.

Chế độ ngủ trong vLLM

Khi sử dụng huấn luyện đồng vị trí, việc quản lý bộ nhớ GPU là rất quan trọng để cả huấn luyện và suy luận có thể chạy trơn tru trên cùng một thiết bị. Để hỗ trợ điều này, chúng tôi đã thêm API sleep() của vLLM vào vòng lặp huấn luyện GRPO.

Hàm sleep() tạm thời tạm dừng công cụ vLLM và giải phóng bộ nhớ GPU. Nó hỗ trợ hai cấp độ:

Cấp 1: Dỡ trọng số mô hình từ GPU (giữ chúng trong bộ nhớ CPU) và xóa bộ đệm KV. Hữu ích khi cùng một mô hình sẽ được sử dụng lại sớm.
Cấp 2: Dỡ cả trọng số mô hình và bộ đệm KV hoàn toàn. Tốt nhất cho các trường hợp mà mô hình sẽ thay đổi hoặc sẽ không được sử dụng lại ngay lập tức.

Trong GRPO, mô hình được cập nhật sau mỗi bước — vì vậy chúng tôi sử dụng chế độ ngủ Cấp 2.

Lợi ích của chế độ ngủ Cấp 2:

Tối đa hóa bộ nhớ GPU miễn phí để huấn luyện
Tránh tranh chấp bộ nhớ giữa huấn luyện và tạo
Giữ cho đồng vị trí hiệu quả, ngay cả đối với các mô hình lớn như Qwen2.5-72B

Sự bổ sung nhỏ này tạo ra một sự khác biệt lớn trong việc cho phép huấn luyện đồng vị trí trơn tru và có thể mở rộng.

Tối ưu hóa DeepSpeed

Để huấn luyện các mô hình lớn như Qwen2.5-72B, chúng tôi dựa vào DeepSpeed ZeRO Stage 3, cùng một thiết lập được sử dụng trong TRL thông thường.

ZeRO giúp mở rộng các mô hình lớn bằng cách phân phối bộ nhớ trên các GPU. Stage 3 đi xa hơn bằng cách phân vùng:

Trọng số mô hình
Độ dốc
Trạng thái trình tối ưu hóa

Điều này rất cần thiết cho các mô hình không thể phù hợp với một GPU duy nhất. Với ZeRO Stage 3, mỗi GPU chỉ xử lý một phần của mô hình.

Các tùy chọn bổ sung mà chúng tôi kích hoạt:

"offload_optimizer": {"device": "cpu"} Chuyển trạng thái trình tối ưu hóa sang CPU để giải phóng bộ nhớ GPU — rất quan trọng trong thiết lập đồng vị trí.
"overlap_comm": true Cho phép giao tiếp chồng lên tính toán, tăng tốc quá trình huấn luyện.
"contiguous_gradients": true Phân bổ độ dốc trong một khối bộ nhớ duy nhất, cải thiện khả năng truy cập bộ nhớ và giảm phân mảnh.

Các tối ưu hóa này giúp huấn luyện hiệu quả các mô hình 72B và đảm bảo đồng vị trí vẫn ổn định trong điều kiện hạn chế bộ nhớ.

Tích hợp tăng tốc

Như được khuyến nghị trong TRL, chúng tôi sử dụng Accelerate, một thư viện nhẹ giúp đơn giản hóa quá trình huấn luyện phân tán. Nó xử lý:

Khởi chạy công việc đa GPU và đa nút
Tính song song dữ liệu
Tích lũy độ dốc
Tải dữ liệu phân tán

Điều này làm cho thiết lập sạch sẽ, có thể mở rộng và dễ bảo trì.

Thí nghiệm 5: Qwen2.5-Math-72B — Thông lượng, độ chính xác và kết quả điểm chuẩn

Thông lượng

Ngay cả với ít hơn 4 GPU, thiết lập đồng vị trí nhanh hơn ~1,26 lần so với TRL thông thường. Điều này làm nổi bật hiệu quả của việc chia sẻ GPU thông minh hơn và làm sạch bộ nhớ bằng cách sử dụng sleep(). 72b-tput

Đường cong phần thưởng

Các đồ thị phần thưởng huấn luyện cho thiết lập đồng vị trí và thông thường gần như giống hệt nhau, chứng minh rằng:

Huấn luyện đồng vị trí bảo toàn độ chính xác
Không có hồi quy trong hiệu suất học tập của mô hình

Điểm chuẩn Math500

Chúng tôi đã đánh giá ba mô hình: Mô hình cơ sở, Mô hình được huấn luyện đồng vị trí, Mô hình được huấn luyện thông thường trên điểm chuẩn Math500. Cả hai mô hình được huấn luyện đều vượt trội hơn so với cơ sở, và mô hình đồng vị trí hoạt động ngang bằng với mô hình được huấn luyện thông thường — xác nhận rằng đồng vị trí không ảnh hưởng đến hiệu suất hạ nguồn. blogpost_72b_math500

🎓 Thách thức & Bài học kinh nghiệm & Các bước tiếp theo

Thông qua công việc của chúng tôi về việc mở rộng quy mô huấn luyện GRPO với vLLM đồng vị trí, chúng tôi đã đối mặt với một số thách thức quan trọng và học được những bài học quan trọng về hiệu quả, tính linh hoạt và thiết kế hệ thống khi huấn luyện các mô hình lớn.

Thách thức

Lỗi song song Tensor trong vLLM ≥ 0.8.0. Tính song song Tensor (TP) với external_launcher đã ngừng hoạt động trong vLLM phiên bản 0.8.0 trở lên. Điều này đã được theo dõi theo Vấn đề #15895. Để xác định điểm phá vỡ, chúng tôi đã tuân theo phương pháp được mô tả trong nhà phát triển vLLM này bài đăng trên blog, cung cấp các bánh xe cho mọi cam kết. Sau khi chia đôi, chúng tôi đã xác định cam kết phá vỡ là cc10281. Nguyên nhân gốc rễ là tính xác định — các phiên bản mới hơn yêu cầu thiết lập rõ ràng hạt giống ngẫu nhiên. Sau khi hạt giống được thiết lập, vấn đề đã biến mất.
Lỗi bộ đệm ngủ Cấp 2. Ban đầu, chế độ ngủ cấp 2 không hoạt động chính xác khi chúng tôi cố gắng tải lại trọng số bằng load_weights. Vấn đề này đã được theo dõi trong Vấn đề #16564. Vấn đề là bộ đệm mô hình (như chạy trung bình/phương sai trong BatchNorm) không được khôi phục sau khi thức dậy từ chế độ ngủ. Bản sửa lỗi đi kèm với PR #16889, đã thêm logic để khôi phục rõ ràng các bộ đệm khi thức dậy từ chế độ ngủ cấp 2. Bây giờ chúng tôi giữ một bản sao của các bộ đệm gốc và áp dụng lại chúng theo cách thủ công sau khi tải trọng số mới.
Lỗi phân đoạn khi thoát. Vẫn còn một vấn đề mở với chế độ ngủ vLLM gây ra lỗi phân đoạn khi kết thúc quá trình huấn luyện khi đóng các quy trình. Điều này đã được báo cáo trong Vấn đề #16993. Sự cố này xảy ra trong quá trình tắt máy nhưng không làm hỏng quá trình huấn luyện, vì vậy chúng tôi đã có thể hoàn thành tất cả các bản trình diễn và thử nghiệm được chia sẻ trong blog này. Tuy nhiên, chúng tôi đang chờ bản sửa lỗi chính thức trước khi tích hợp sleep() hoàn toàn vào TRL ngược dòng.

Những thách thức này không phải là những yếu tố cản trở, nhưng chúng đòi hỏi gỡ lỗi cẩn thận, kiểm soát phiên bản và hiểu sâu hơn về cách vLLM quản lý bộ nhớ và tính song song dưới vỏ bọc.

Bài học kinh nghiệm

Suy luận đồng vị trí cải thiện đáng kể việc sử dụng GPU. Bằng cách cho phép huấn luyện và tạo chia sẻ cùng một GPU, chúng ta loại bỏ thời gian nhàn rỗi và giảm yêu cầu về phần cứng — đạt được thông lượng cao hơn ngay cả với ít GPU hơn.
Tính năng sleep() của vLLM rất cần thiết cho đồng vị trí quy mô lớn. Nó cho phép kiểm soát chi tiết việc sử dụng bộ nhớ, cho phép huấn luyện hoàn toàn thu hồi bộ nhớ GPU giữa các bước tạo — một yếu tố quan trọng cho các mô hình như Qwen2.5-72B.
DeepSpeed ZeRO Stage 3 rất cần thiết cho việc huấn luyện các mô hình lớn. Nó cho phép các mạng cực kỳ lớn phù hợp với bộ nhớ bằng cách phân phối trọng số mô hình, độ dốc và trạng thái trình tối ưu hóa trên nhiều GPU. Theo kinh nghiệm của chúng tôi, việc kích hoạt contiguous_gradients đã giúp giảm phân mảnh bộ nhớ, trong khi việc dỡ trình tối ưu hóa sang CPU đã giải phóng bộ nhớ GPU quan trọng — cả hai đều đặc biệt hữu ích trong thiết lập đồng vị trí.
Đồng vị trí rất mạnh mẽ nhưng đi kèm với sự đánh đổi. Nó hoạt động tốt nhất khi bộ nhớ GPU được quản lý cẩn thận, thường yêu cầu điều chỉnh thủ công các tham số sử dụng bộ nhớ như vllm_gpu_memory_utilization. Mặc dù nó mang lại lợi ích thông lượng rõ ràng và giảm thời gian GPU nhàn rỗi, đồng vị trí có thể không lý tưởng cho các mô hình có ngân sách bộ nhớ eo hẹp hoặc khi phân mảnh bộ nhớ không được kiểm soát tốt. Tuy nhiên, khi được thực hiện đúng cách, nó sẽ mở ra những lợi ích hiệu quả đáng kể.
Khả năng tương thích TP/DP, Accelerate và hỗ trợ torchrun giúp triển khai liền mạch. Mặc dù kiến trúc cơ bản phức tạp, toàn bộ hệ thống có thể được khởi chạy và mở rộng quy mô với các công cụ phân tán tiêu chuẩn.
Huấn luyện đồng vị trí duy trì chất lượng mô hình. Trên nhiều điểm chuẩn (Math500, AIME24), thiết lập đồng vị trí và thông thường đã tạo ra kết quả so sánh được, xác nhận rằng hiệu suất không bị hy sinh cho hiệu quả.

✅ Kết luận

Bài đăng trên blog này đã khám phá cách đồng vị trí vLLM với huấn luyện GRPO mở ra những lợi ích hiệu quả đáng kể khi huấn luyện các mô hình ngôn ngữ lớn — bao gồm cả các mô hình lớn như Qwen2.5-72B.

Theo truyền thống, TRL chỉ hỗ trợ vLLM ở chế độ máy chủ, yêu cầu các quy trình và GPU riêng biệt cho suy luận, dẫn đến lãng phí tính toán và thời gian nhàn rỗi. Với việc giới thiệu trình khởi chạy bên ngoài của vLLM và PR đồng vị trí trong TRL PR #3394, giờ đây chúng ta có thể chạy huấn luyện và suy luận trong cùng một nhóm quy trình phân tán, trên cùng một GPU, với hỗ trợ đầy đủ cho TP, DP và Accelerate.

Mặc dù vẫn còn những thách thức — chẳng hạn như lỗi vLLM dành riêng cho phiên bản và các trường hợp cạnh như với sleep() — kết quả tổng thể cho thấy rằng GRPO đồng vị trí là một giải pháp thiết thực, có thể mở rộng để huấn luyện hiệu quả các mô hình lớn. Chúng tôi rất vui được tiếp tục tinh chỉnh thiết lập này, tích hợp các tính năng như FSDP và thúc đẩy giới hạn của quá trình huấn luyện mô hình lớn — làm cho nó nhanh hơn, rẻ hơn và dễ tiếp cận hơn cho mọi người xây dựng thế hệ LLM tiếp theo.

✅ Hãy dùng thử!

Dưới đây là một ví dụ để thử huấn luyện GRPO với vLLM đồng vị trí.

📄 `train_grpo_colocate.py`

from datasets import load_dataset
from trl import GRPOConfig, GRPOTrainer

# Load dataset
dataset = load_dataset("trl-lib/tldr", split="train")

# Define the reward function
def reward_len(completions, **kwargs):
    return [-abs(20 - len(completion)) for completion in completions]

# Define training arguments
training_args = GRPOConfig(
    output_dir="Qwen2-0.5B-GRPO",
    logging_steps=1,
    use_vllm=True,
    vllm_mode="colocate",
    vllm_tensor_parallel_size=1,
    vllm_gpu_memory_utilization=0.3,
    max_prompt_length=512,
    max_completion_length=1024,
    max_steps=2,
    num_generations=4,
    num_train_epochs=1,
    per_device_train_batch_size=4,
    push_to_hub=False,
    report_to=None
)

# Create and run the trainer
trainer = GRPOTrainer(
    model="Qwen/Qwen2-0.5B-Instruct",
    reward_funcs=reward_len,
    args=training_args,
    train_dataset=dataset,
)

trainer.train()

AI Today - SkyAI

Không để GPU nào bị bỏ lại phía sau- Mở khóa hiệu quả với vLLM đồng vị trí trong TRL

KHÔNG GPU nào bị bỏ lại phía sau: Mở khóa hiệu quả với vLLM đồng vị trí trong TRL

🧨 Vấn đề

💡 Cơ hội

Những gì nó cho phép

🧩 Thiết kế: Từ các máy chủ riêng biệt đến GPU được chia sẻ

Thiết lập TRL máy chủ (Hàng trên cùng)

Thiết lập TRL đồng vị trí (Hàng dưới cùng)

🛠️ Ghi chú triển khai

📊 Trình bày: Hiệu suất TRL đồng vị trí so với TRL thông thường

Thí nghiệm 1: Mô hình 1.5B — Thay đổi kích thước lô

Thí nghiệm 2: Mô hình 1.5B — Thay đổi tính song song Tensor (TP)

Thí nghiệm 3: Mô hình 7B — Thay đổi kích thước lô

Thí nghiệm 4: Mô hình 7B — Thay đổi tính song song Tensor (TP)

📊 Mở rộng quy mô lên mô hình 72B

Chế độ ngủ trong vLLM

Tối ưu hóa DeepSpeed

Tích hợp tăng tốc

Thí nghiệm 5: Qwen2.5-Math-72B — Thông lượng, độ chính xác và kết quả điểm chuẩn

Thông lượng

Đường cong phần thưởng

Điểm chuẩn Math500

🎓 Thách thức & Bài học kinh nghiệm & Các bước tiếp theo

Thách thức

Bài học kinh nghiệm

✅ Kết luận

✅ Hãy dùng thử!

📄 `train_grpo_colocate.py`

Link bài viết gốc

KHÔNG GPU nào bị bỏ lại phía sau: Mở khóa hiệu quả với vLLM đồng vị trí trong TRL

🧨 Vấn đề

💡 Cơ hội

Những gì nó cho phép

🧩 Thiết kế: Từ các máy chủ riêng biệt đến GPU được chia sẻ

Thiết lập TRL máy chủ (Hàng trên cùng)

Thiết lập TRL đồng vị trí (Hàng dưới cùng)

🛠️ Ghi chú triển khai

📊 Trình bày: Hiệu suất TRL đồng vị trí so với TRL thông thường

Thí nghiệm 1: Mô hình 1.5B — Thay đổi kích thước lô

Thí nghiệm 2: Mô hình 1.5B — Thay đổi tính song song Tensor (TP)

Thí nghiệm 3: Mô hình 7B — Thay đổi kích thước lô

Thí nghiệm 4: Mô hình 7B — Thay đổi tính song song Tensor (TP)

📊 Mở rộng quy mô lên mô hình 72B

Chế độ ngủ trong vLLM

Tối ưu hóa DeepSpeed

Tích hợp tăng tốc

Thí nghiệm 5: Qwen2.5-Math-72B — Thông lượng, độ chính xác và kết quả điểm chuẩn

Thông lượng

Đường cong phần thưởng

Điểm chuẩn Math500

🎓 Thách thức & Bài học kinh nghiệm & Các bước tiếp theo

Thách thức

Bài học kinh nghiệm

✅ Kết luận

✅ Hãy dùng thử!

📄 train_grpo_colocate.py

Link bài viết gốc

📄 `train_grpo_colocate.py`