Mở Khóa Huấn Luyện RL Agentic Cho GPT-OSS: Đánh Giá Thực Tế

RL Agentic (Học tăng cường dựa trên tác nhân) mở rộng huấn luyện LLM truyền thống bằng cách tối ưu hóa không chỉ một phản hồi duy nhất, mà là toàn bộ quy trình ra quyết định được học thông qua tương tác trực tiếp với môi trường trong quá trình huấn luyện. Khác với các phương pháp học tăng cường một lượt hoặc dựa trên sở thích ngoại tuyến dựa vào các tập dữ liệu tĩnh, RL Agentic huấn luyện các chính sách bằng cách thu thập dữ liệu theo chính sách một cách chủ động khi tác nhân lập kế hoạch hành động, gọi các công cụ, quan sát kết quả và thích ứng hành vi của nó qua các quỹ đạo nhiều bước trong môi trường mô phỏng hoặc thực tế. Sự tối ưu hóa dựa trên tương tác này phân bổ tín dụng trên các quyết định có phạm vi dài, nơi các lựa chọn trung gian như định dạng lại truy vấn, lựa chọn công cụ và thứ tự thực thi ảnh hưởng trực tiếp đến sự thành công ở các bước tiếp theo. Quá trình huấn luyện tuân theo một vòng lặp khép kín lặp đi lặp lại, trong đó tác nhân tương tác với môi trường để thu thập các quỹ đạo triển khai, tính toán phần thưởng trên các quỹ đạo này, cập nhật chính sách dựa trên các kết quả quan sát được, sau đó sử dụng chính sách đã cập nhật để điều khiển vòng tương tác và thu thập dữ liệu tiếp theo, ví dụ như các thuật toán GRPO hoặc PPO.

LinkedIn là một công ty ưu tiên AI, đã xây dựng các tác nhân để giúp các chuyên gia thành công hơn. Trong bối cảnh này, các mô hình phải lý luận dựa trên thông tin không đầy đủ, tương tác với các dịch vụ có cấu trúc và thích ứng với ý định của người dùng đang phát triển qua nhiều bước thay vì đưa ra một phản hồi tĩnh duy nhất. Những khả năng này đặc biệt quan trọng đối với các tác nhân hỗ trợ mục tiêu của nhà tuyển dụng, người tìm kiếm việc làm và kiến thức, cũng như người học, chẳng hạn như truy xuất thông tin, tinh chỉnh truy vấn, phối hợp công cụ và thực thi quy trình làm việc nhiều bước. Bằng cách học các chính sách ra quyết định mạnh mẽ thông qua tương tác, RL Agentic cung cấp một nền tảng có nguyên tắc để xây dựng các hệ thống AI có thể mở rộng, đáng tin cậy và thích ứng thông qua tối ưu hóa đầu cuối.

Mô hình GPT-OSS đã cho thấy hiệu suất tương đương với OpenAI o3-mini và o4-mini [tham khảo], nhưng sự phù hợp của nó với huấn luyện RL Agentic vẫn chưa được xác thực. Hầu hết các công việc gần đây tập trung vào tinh chỉnh mà không có khả năng gọi công cụ, ví dụ: Tinh chỉnh với gpt-oss và Hugging Face Transformers và hướng dẫn unsloth: cách tinh chỉnh gpt-oss. Bài đăng blog này khám phá hành trình mở khóa RL Agentic cho GPT-OSS như một mô hình nền tiềm năng cho các ứng dụng agentic.

Trong các thử nghiệm của chúng tôi, chúng tôi sử dụng verl làm khung huấn luyện vì đây là một trong những khung phổ biến nhất được áp dụng trong cộng đồng mã nguồn mở. Chúng tôi sử dụng gsm8k, nhiệm vụ Retool, nhiệm vụ tuân thủ hướng dẫn có thể xác minh, các nhiệm vụ này thường được sử dụng trong huấn luyện RL. Chúng tôi tập trung vào việc trình bày kết quả thực nghiệm cho mô hình GPT-OSS-20B, và việc sửa lỗi attention-sink của chúng tôi cũng hoạt động trên GPT-OSS-120B. Mô hình Qwen-2.5-32B được sử dụng bổ sung để đánh giá xu hướng chỉ số tiêu chuẩn trong quá trình huấn luyện RL.

Thách thức của Huấn Luyện RL Agentic GPT-OSS

verl đã là một khung OSS được nhóm sử dụng, và nhóm trước đây đã cộng tác và đóng góp vào nó để giúp dân chủ hóa huấn luyện RL Agentic. Với việc giới thiệu mẫu chat Harmony mới trong GPT-OSS, bước đầu tiên là đảm bảo rằng khung huấn luyện hỗ trợ đầy đủ định dạng tin nhắn đã cập nhật và ngữ nghĩa hội thoại cần thiết bởi Harmony. Bước này giúp việc tạo quỹ đạo, xây dựng quỹ đạo và phân tích công cụ vẫn nhất quán và chính xác dưới mẫu mới.

Nhóm sử dụng ReTool làm một ví dụ đại diện để xác minh tính đúng đắn của mã. ReTool là một nhiệm vụ mã hóa agentic, trong đó mô hình được yêu cầu giải một bài toán toán học với sự hỗ trợ của công cụ biên dịch mã. Thiết lập này cho phép mô hình tập trung vào logic cốt lõi về lý luận và thuật toán, đồng thời ủy quyền các phép tính số học và thực thi thực tế cho công cụ. Trong một tập, mô hình tương tác với công cụ mã nhiều lần, sử dụng kết quả thực thi làm phản hồi để tinh chỉnh giải pháp của nó. Cuối quỹ đạo, mô hình đưa ra câu trả lời cuối cùng, trên đó phần thưởng được tính toán.

Trong các lần chạy huấn luyện ban đầu, chúng tôi quan sát thấy KL divergence và entropy bùng nổ, cùng với phần thưởng không tăng, cho thấy các vấn đề tiềm ẩn trong thiết lập huấn luyện GPT-OSS, như thể hiện trong Hình 1.

Norm Gradient Trung bình	Phần thưởng Trung bình

Hình 1. Trái: Qwen32b có phần thưởng cao hơn đáng kể so với GPT-OSS 20B; Phải: Norm gradient bùng nổ khi huấn luyện tiến triển.

Hành trình Gỡ Lỗi Thực Tế trong verl: Khôi Phục Tính Toàn Vẹn Theo Chính Sách PPO

Khôi phục tính toàn vẹn theo chính sách: Sửa lỗi không khớp xác suất log MoE

Chúng tôi tập trung vào các phương pháp theo chính sách vì chúng mang lại sự ổn định lớn hơn và hội tụ đáng tin cậy hơn. Nền tảng của Proximal Policy Optimization (PPO) theo chính sách thuần túy yêu cầu tỷ lệ lấy mẫu quan trọng phải bằng chính xác 1. Định nghĩa toán học của tỷ lệ quan trọng là:

$$ \text{ratio} = \frac{\pi(a \mid s)}{\pi_{\text{old}}(a \mid s)} $$

Yêu cầu này đảm bảo rằng việc cập nhật chính sách chỉ được thực hiện trên dữ liệu được tạo bởi chính sách hiện tại π(a | s) = πold(a | s), ngăn chặn việc cắt bỏ không mong muốn.

Chúng tôi đã quan sát thấy tỷ lệ cắt bỏ không bằng không trong quá trình huấn luyện ReTool của chúng tôi, như thể hiện trong Hình 2, bắt nguồn từ sự không khớp giữa hai xác suất log:

• Xác suất log hiện tại log_prob: log(π(a | s))
• Xác suất log cũ old_log_prob: log(πold(a | s))

Nguyên nhân gốc rễ: Lượt chuyển tiếp kép và Kiến trúc MoE

Trước verl 0.3.0, việc triển khai dựa vào hai lượt chuyển tiếp riêng biệt (một để tính toán log_prob hiện tại và một để truy xuất old_log_prob đã lưu trữ) cho cùng một cặp trạng thái-hành động.

Trong kiến trúc Mixture of Experts (MoE) như GPT-OSS, mạng cổng sẽ định tuyến đầu vào đến các chuyên gia khác nhau. Do các yếu tố triển khai (ví dụ: sự khác biệt nhỏ về dấu chấm động hoặc tính ngẫu nhiên rõ ràng), việc định tuyến chuyên gia có thể khác nhau một chút giữa hai lượt chuyển tiếp. Những người đọc quan tâm có thể đọc thêm Ổn định hóa MoE Reinforcement Learning bằng cách Căn chỉnh Bộ định tuyến Huấn luyện và Suy luận.

Sự khác biệt trong định tuyến này dẫn đến:

$$ \log(\pi(a \mid s)) \neq \log(\pi_{\text{old}}(a \mid s)) $$

Kết quả là tỷ lệ sai khác với 1, kích hoạt sai clipping PPO và vi phạm giả định cốt lõi theo chính sách.

Giải pháp: Ép buộc Tỷ lệ = 1 thông qua Thay thế Xác suất Log

Việc sửa chữa giải quyết vấn đề bằng cách ghi đè logic tính toán sai khi môi trường được biết là theo chính sách (tức là khi kích thước minibatch bằng kích thước batch toàn cục):

python if on_policy: old_log_prob = log_prob.detach() else: old_log_prob = model_inputs[“old_log_probs”]

Bằng cách đặt old_log_prob bằng với log_prob mới được tính toán (đã tách rời để ngăn chặn luồng gradient qua giá trị tham chiếu), tỷ lệ lấy mẫu quan trọng về mặt toán học bị buộc trở lại 1. Chiến lược này bỏ qua sự bất ổn gây ra bởi việc định tuyến không xác định của MoE và đảm bảo hành vi theo chính sách nghiêm ngặt trong quá trình huấn luyện PPO.

Sửa lỗi Không khớp Huấn luyện-Suy luận

Mặc dù việc sửa lỗi không khớp xác suất log đã giảm tỷ lệ cắt bỏ tỷ lệ lấy mẫu quan trọng về 0, các chuẩn gradient tiếp tục bùng nổ và phần thưởng không cải thiện. Để cô lập vấn đề, chúng tôi đã đơn giản hóa việc huấn luyện cho GSM8K, một nhiệm vụ một bước mà không cần sử dụng công cụ agentic. Sự bất ổn tương tự vẫn tồn tại, như thể hiện trong các đường màu xanh lá cây trong Hình 3, cho thấy một vấn đề cơ bản trong huấn luyện RL cơ bản với GPT-OSS trong verl.

Chúng tôi giả định rằng sự không khớp huấn luyện-suy luận có thể là một nguyên nhân tiềm ẩn: sự khác biệt giữa việc thực thi tại thời điểm suy luận—nơi các công cụ như vLLM và SGLang tối ưu hóa mạnh mẽ cho thông lượng—và việc thực thi tại thời điểm huấn luyện dưới FSDP, ưu tiên độ chính xác và ổn định số học, có thể biến tối ưu hóa RL theo chính sách thành tối ưu hóa ngoại tuyến.

Bài đăng blog này chi tiết lý do tại sao sự không khớp như vậy dẫn đến gradient không ổn định và phần thưởng không cải thiện. Hình 3 so sánh các lần chạy huấn luyện có và không có sửa lỗi quỹ đạo (xem blog verl này để biết chi tiết). Sau khi áp dụng sửa lỗi quỹ đạo, động lực học huấn luyện cải thiện đáng kể, với các chuẩn gradient ổn định thay vì bùng nổ.

Tuy nhiên, như thể hiện trong biểu đồ bên trái của Hình 4, phần thưởng chỉ tăng lên một cách khiêm tốn, và việc hội tụ trên nhiệm vụ GSM8K đơn giản vẫn chậm hơn đáng kể so với các biến thể mô hình dày đặc nhỏ hơn.

Entropy Trung bình	Norm Gradient Trung bình	Tổn thất KL Trung bình

Hình 3. Norm gradient trong các cấu hình huấn luyện khác nhau. Màu xanh lá cây: Huấn luyện không có sửa lỗi quỹ đạo, thể hiện gradient không ổn định. Màu đỏ: Huấn luyện với lớp attention bị đóng băng để cô lập vấn đề với cơ chế attention, dẫn đến ổn định hóa một phần. Màu xanh lam: Huấn luyện với sửa lỗi quỹ đạo được bật (lấy mẫu quan trọng cấp độ quỹ đạo), mang lại chuẩn gradient ổn định.

Phần thưởng Trung bình	Sự khác biệt log-perplexity tối đa

Hình 4. Trái: Sự cải thiện phần thưởng trên GSM8K vẫn chậm ngay cả sau khi áp dụng sửa lỗi quỹ đạo, với hiệu suất tương đương với các lần chạy mà lớp attention bị đóng băng trong quá trình huấn luyện. Phải: Sự không khớp log-ppl đáng kể được quan sát giữa công cụ suy luận (SGLang với các kernel Triton hỗ trợ lượt chuyển tiếp attention-sink) và ngăn xếp huấn luyện (FSDP với FlashAttention-v2), cho thấy sự không nhất quán lớn giữa huấn luyện và suy luận.

Để cô lập thêm nguyên nhân gốc rễ, chúng tôi đóng băng các lớp attention trong quá trình huấn luyện và quan sát động lực học phần thưởng tương tự như các lần chạy không đóng băng (đường màu xanh lam so với đường màu vàng trong Hình 4). Điều này cho thấy rằng việc học chủ yếu được thúc đẩy bởi các lớp MoE, trong khi cơ chế attention đóng góp kém hiệu quả hơn mong đợi. Ngoài ra, chúng tôi quan sát thấy sự không khớp xác suất cấp token đáng kể giữa công cụ suy luận và ngăn xếp huấn luyện phân tán sử dụng các kernel attention khác nhau. Kết hợp lại, những quan sát này thúc đẩy một cuộc điều tra sâu hơn về cơ chế attention.

Hỗ Trợ Attention Sink trong FlashAttentionV3

Attention sinks được sử dụng trong GPT-OSS là các tham số vô hướng có thể học được (một cho mỗi đầu attention) hoạt động như các “token ảo” trong phép tính softmax. Chúng cho phép mô hình phân bổ khối lượng attention cho một sink đã học thay vì buộc tất cả attention vào các token nội dung, điều này đã được chứng minh là cải thiện sự ổn định của attention trong suy luận streaming và huấn luyện với attention cửa sổ trượt.

Sau khi điều tra sâu hơn, chúng tôi đã xác định được một số vấn đề lớn:

• verl mã hóa cứng FlashAttention v2 trong fsdp_worker, không hỗ trợ attention sinks.
• Lượt chuyển tiếp ngược của attention sink không được hỗ trợ trong FlashAttention v2 và v3, vì vậy nó không hoạt động như mong đợi ngay cả khi FlashAttention v3 được bật.
• Vì lượt chuyển tiếp chưa được hợp nhất vào kho lưu trữ FlashAttention v3 gốc, chúng tôi đã tận dụng lượt chuyển tiếp từ nhánh FlashAttention của vLLM (PR #75) và triển khai lượt chuyển tiếp ngược để tính toán gradient của sink.

Attention Tiêu Chuẩn

python scores = QK^T / sqrt(d) # [B, H, N_q, N_k] probs = softmax(scores, dim=-1) # Σ_j P_ij = 1 output = probs @ V # [B, H, N_q, d_v]

Attention với Sinks (GPT-OSS)

python scores = QK^T / sqrt(d) # [B, H, N_q, N_k] combined = concat([scores, sink_param], dim=-1) # [B, H, N_q, N_k+1] probs = softmax(combined, dim=-1) # Σ_j P_ij + P_sink = 1 probs_content = probs[…, :-1] # Loại bỏ thành phần sink output = probs_content @ V # [B, H, N_q, d_v]

Điểm khác biệt chính: Sink tham gia vào việc chuẩn hóa softmax nhưng không đóng góp vào đầu ra.

Công Thức Toán Học

Trọng số attention cho token nội dung j trong hàng i được định nghĩa là:

$$ P_{ij}

\frac{\exp(S_{ij})} {\sum_{j’=1}^{N_k} \exp(S_{ij’}) + \exp(S_h)} $$

Trong đó:

• Sij = Qi Kj⊤ / √d là điểm attention
• Pij là trọng số attention cho các token nội dung
• Sh là tham số sink có thể học được cho đầu h

Xác suất Sink:

Xác suất sink được tính toán nhưng không được sử dụng trong đầu ra:

$$ P_{i,h}

\frac{\exp(S_h)} {\sum_{j’=1}^{N_k} \exp(S_{ij’}) + \exp(S_h)} $$

Lượt chuyển tiếp Ngược

Đạo hàm của tổn thất L đối với tham số sink Sh là:

$$ \frac{\partial L}{\partial S_h}

- \sum_i P_{i,h} \left( \frac{\partial L}{\partial S_{i,h}}

\sum_{j \in {1,\ldots,N_k}} P_{ij} \frac{\partial L}{\partial S_{ij}} \right) $$

Trong đó:

• Pi,h là xác suất attention của sink cho hàng i
• ∂L/∂Sij là đạo hàm đối với điểm attention, bao gồm cả sink

Đạo hàm Đơn giản hóa:

Vì lượt chuyển tiếp được tính toán nhưng không được sử dụng trong đầu ra, đạo hàm của nó ∂L/∂Si,h = 0.

Do đó, phương trình ngược lại đơn giản hóa thành:

$$ \frac{\partial L}{\partial S_h}

- \sum_i P_{i,h} \left( \sum_{j \in {1,\ldots,N_k}} P_{ij} \frac{\partial L}{\partial S_{ij}} \right) $$

Lượt chuyển tiếp xuôi đã được điều chỉnh từ nhánh FlashAttention của vLLM và chúng tôi đã triển khai lượt chuyển tiếp ngược để tính toán gradient cho các tham số sink. Việc triển khai sẽ được phát hành sau quy trình đánh giá nội bộ.

Kết quả

Sau khi áp dụng sửa lỗi trong FlashAttention v3, chúng tôi quan sát thấy sự hội tụ nhanh hơn đáng kể cho GPT-OSS-20B trên nhiều loại nhiệm vụ học tăng cường. Bao gồm học tăng cường một lượt trên lý luận toán học (GSM8K — đường màu đỏ trong Hình 5), tuân thủ hướng dẫn (VerifyIf, được đánh giá trên một điểm chuẩn đa điều kiện ngoài phạm vi — Hình 6) và học tăng cường agentic nhiều lượt với việc sử dụng công cụ (ReTool — Hình 7).

Trong tất cả các cài đặt, việc huấn luyện trở nên ổn định và cho thấy sự cải thiện phần thưởng ổn định.

Hình 5. GSM8K một lượt, đường màu đỏ hội tụ nhanh hơn đáng kể so với các đường còn lại mà không có sửa lỗi.

Entropy Trung bình	Norm Gradient Trung bình	Phần thưởng Trung bình

Hình 6 Trên nhiệm vụ tuân thủ hướng dẫn có thể xác minh, lần chạy không có sửa lỗi đã sụp đổ (màu xanh lam), và lần chạy có sửa lỗi cho thấy sự cải thiện phần thưởng ổn định.

Norm Gradient Trung bình	Phần thưởng Trung bình	Độ chính xác Xác minh

Hình 7. Trên nhiệm vụ Retool, lần chạy có sửa lỗi cho thấy sự cải thiện phần thưởng ổn định và không có gradient bùng nổ (fa2 là flash attention 2 không có sửa lỗi trong khi fa3 là flash attention 3 có sửa lỗi). Sau khi sửa lỗi, điểm độ chính xác xác minh đã tăng lên.

Huấn Luyện Hiệu Quả Bộ Nhớ

Giảm thiểu Sự Bùng Nổ Bộ Nhớ FSDP Do Vật Liệu Hóa Chuyên Gia MoE Lặp Lại

Một vấn đề chúng tôi liên tục gặp phải là việc cấp phát bộ nhớ quá mức trong lượt chuyển tiếp xuôi FSDP, dẫn đến lỗi hết bộ nhớ (OOM) lặp đi lặp lại khi huấn luyện các mô hình GPT-OSS-20B bf16 trên 16 nút H200 (chiều dài phản hồi tối đa: 16k, chiều dài prompt: 8k). Hành vi này rất bất ngờ đối với một mô hình MoE 20 tỷ tham số.

text 2025-11-27T11:15:27.927Z [36m(TaskRunner pid=32081)[0m File “/home/jobuser/.local/lib/python3.10/site-packages/transformers/models/gpt_oss/modeling_gpt_oss.py”, line 123, in forward 2025-11-27T11:15:27.927Z [36m(TaskRunner pid=32081)[0m hidden_states = hidden_states.repeat(num_experts, 1) 2025-11-27T11:15:27.927Z [36m(TaskRunner pid=32081)[0m torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 180.00 GiB. GPU 0 has a total capacity of 139.72 GiB of which 110.94 GiB is free. Process 685851 has 24.88 GiB memory in use. Process 692458 has 3.87 GiB memory in use. Of the allocated memory 23.28 GiB is allocated by PyTorch, and 84.43 MiB is reserved by PyTorch but unallocated.

Chúng tôi đã xác định vấn đề bắt nguồn từ hai triển khai khác nhau của đường chuyển tiếp xuôi MoE trong Hugging Face Transformers. Vấn đề này cũng đã được người dùng khác báo cáo: https://github.com/huggingface/transformers/issues/40073; Khi verl tính toán xác suất log dưới FSDP, đường chuyển tiếp xuôi suy luận được kích hoạt. Trong triển khai Hugging Face hiện tại, đường này nhân đôi các trạng thái ẩn cho tất cả các chuyên gia và thực hiện nhân ma trận theo lô, tạo ra các tensor cực lớn trong bộ nhớ GPU. Ngược lại, đường chuyển tiếp xuôi huấn luyện sử dụng một vòng lặp để xử lý từng chuyên gia một cách tuần tự và sau đó kết hợp các kết quả. Mặc dù chậm hơn, cách tiếp cận này hiệu quả bộ nhớ hơn đáng kể.

python @GPUMemoryLogger(role=“dp actor”, logger=logger) def compute_log_prob(self, data: DataProto, calculate_entropy=False) -> torch.Tensor: """ …. """ # set to eval, this essentially prioritizes parallelism at the cost of memory efficiency self.actor_module.eval() …

Chúng tôi đã vá triển khai Hugging Face để sử dụng đường thực thi hiệu quả bộ nhớ hơn, tránh vật liệu hóa chuyên gia lặp lại.

Song song Hóa Chuỗi với Flash Attention V3

RL Agentic yêu cầu tác nhân phải tương tác với môi trường qua nhiều bước trong khi duy trì ngữ cảnh ngày càng mở rộng. Các quan sát và phản hồi môi trường từ mỗi bước được nối vào ngữ cảnh và được sử dụng làm đầu vào cho việc ra quyết định tiếp theo, điều này đặt ra những thách thức đáng kể về hiệu quả bộ nhớ và khả năng mở rộng trong quá trình huấn luyện.

Dưới hình thức song song hóa dữ liệu được chia sẻ hoàn toàn (FSDP), các tham số mô hình, trạng thái trình tối ưu hóa và đạo hàm được chia sẻ trên toàn bộ kích thước thế giới (tức là tất cả các GPU trong cụm huấn luyện). Mỗi GPU chỉ lưu trữ và cập nhật các phần tham số được gán của nó, trong khi dữ liệu quỹ đạo được nhân bản trên tất cả các GPU—nghĩa là mỗi GPU xử lý lịch sử tương tác tác nhân đầy đủ cho mỗi quỹ đạo.

Trong quá trình chuyển tiếp xuôi, khi tính toán đến một lớp có các tham số không có sẵn cục bộ, một thao tác all_gather sẽ được kích hoạt để vật liệu hóa toàn bộ các tham số trên các GPU. Trong quá trình chuyển tiếp ngược, một thao tác reduce_scatter tương ứng sẽ tổng hợp các đạo hàm và đảm bảo rằng mỗi GPU chỉ giữ lại phần chia sẻ cục bộ của nó. Điều này mang lại một mức độ mở rộng: khi số lượng GPU tăng lên, dấu chân bộ nhớ trên mỗi GPU giảm đi.

FSDP cung cấp khả năng mở rộng cấp độ mô hình bằng cách chia sẻ các tham số mô hình, đạo hàm và trạng thái trình tối ưu hóa trên các GPU. Song song hóa chuỗi (hoặc song song hóa ngữ cảnh) tiếp tục giảm mức tiêu thụ bộ nhớ trên mỗi GPU bằng cách phân chia chuỗi đầu vào trên các thiết bị, do đó giảm bộ nhớ kích hoạt đỉnh trên mỗi GPU.

Khi số lượng chiều song song chuỗi tăng lên, bộ nhớ kích hoạt tối đa trên mỗi GPU tương ứng giảm xuống. Chúng tôi đã triển khai song song hóa chuỗi để nhận biết attention-sink và tương thích với FlashAttention v3 (Hình 8, bên phải).

Hình 8. Trái: Suy luận không có song song hóa chuỗi. Phải: Suy luận có song song hóa chuỗi, nơi thao tác all-to-all bổ sung được thực hiện trước và sau lớp attention. Điều này phân chia chuỗi trên các tác nhân song song và giảm dấu chân bộ nhớ đỉnh của tính toán attention theo một yếu tố tỷ lệ với bậc của song song hóa chuỗi.

Song song hóa chuỗi mở rộng theo chiều của chuỗi để giảm dấu chân kích hoạt trên mỗi GPU. Các token đầu vào từ tất cả các chuỗi được đóng gói thành một danh sách liên tục duy nhất bằng cách loại bỏ các token đệm, trong khi các ID vị trí được sử dụng để phân biệt các token thuộc về các chuỗi khác nhau. Thiết kế này có lợi tự nhiên từ khả năng hỗ trợ độ dài thay đổi của FlashAttention. Đối với song song hóa chuỗi, các lớp khác ngoài lớp attention không có sự phụ thuộc giữa các vị trí; do đó, chúng không yêu cầu mỗi GPU giữ một phần chuỗi hoàn chỉnh, và không cần giao tiếp bổ sung cho các lớp này.

Tuy nhiên, lớp attention yêu cầu tất cả các token thuộc cùng một chuỗi phải có mặt trên cùng một GPU để tính toán trọng số attention một cách chính xác. Để đáp ứng ràng buộc này, một thao tác all-to-all được thực hiện để thu thập các phần tử chuỗi, với việc chia được thực hiện ở cấp độ đầu attention. Thiết kế này tránh giao tiếp trong chính phép tính attention, nếu không sẽ rất tốn kém. Sau lớp attention, một thao tác all-to-all duy nhất phân phối lại các đầu ra trở lại bố cục song song chuỗi ban đầu của chúng, sau đó các lớp phi-attention còn lại có thể tiếp tục mà không cần đồng bộ hóa thêm.

Kết Luận

Hành trình của chúng tôi để kích hoạt huấn luyện RL agentic cho mô hình nền GPT-OSS là một đánh giá thực tế, làm nổi bật rằng việc mở khóa các khả năng nâng cao trong LLM mã nguồn mở đòi hỏi kỹ thuật tỉ mỉ, chuyên sâu.

Chúng tôi đã thực hiện các đóng góp đã biến đổi khả năng của GPT-OSS cho các ứng dụng agentic, đặc biệt bằng cách:

• Ổn định hóa PPO: Chúng tôi đã đóng góp một sửa lỗi để khôi phục tính toàn vẹn theo chính sách, ghi đè sự không khớp xác suất log do tính không xác định của kiến trúc MoE gây ra (Hình 2).
• Kích hoạt Hỗ trợ Attention Sink: Chúng tôi đã triển khai và tích hợp thành công lượt chuyển tiếp ngược của attention sink vào FlashAttention v3, sửa lỗi sự không khớp huấn luyện-suy luận thảm khốc trước đó đã gây ra sự bất ổn và hội tụ chậm (Hình 5, 6 và 7).
• Mở rộng Hiệu quả Bộ nhớ: Chúng tôi đã giới thiệu các tối ưu hóa bộ nhớ quan trọng, bao gồm vá quy trình vật liệu hóa MoE và tích hợp song song hóa chuỗi với hỗ trợ attention sink mới, cho phép huấn luyện với các cửa sổ ngữ cảnh dài cần thiết cho các tác nhân đa bước (Hình 8).

Những nỗ lực kỹ thuật này xác nhận GPT-OSS là một nền tảng có thể mở rộng và hiệu suất cao để xây dựng thế hệ tiếp theo của các tác nhân ra quyết định thông minh, đa bước.

Lời Cảm Ơn

Cảm ơn Deepak Agarwal, Bee-Chung Chen, Animesh Singh, Gungor Polatkan, Balaji Krishnapuram và Jitendra Agarwal vì sự hỗ trợ lãnh đạo của họ.

Tài Liệu Tham Khảo

1. Feng, Jiazhan, et al. Retool: Reinforcement Learning for Strategic Tool Use in LLMs. arXiv preprint arXiv:2504.11536 (2025).
2. Xiao, Guangxuan, et al. Efficient Streaming Language Models with Attention Sinks. arXiv preprint arXiv:2309.17453 (2023).
3. When Speed Kills Stability: Demystifying RL Collapse from the Training–Inference Mismatch. https://yingru.notion.site/When-Speed-Kills-Stability-Demystifying-RL-Collapse-from-the-Training-Inference-Mismatch-271211a558b7808d8b12d403fd15edda

Link bài viết gốc

• Tags:
• Ai
• 27 January 2026
• Huggingface.co