Giải mã kiến trúc Granite 4.2: Cách IBM xây dựng các mô hình ngôn ngữ lớn thế hệ mới

Hướng dẫn kỹ thuật về cách chúng tôi xây dựng dòng mô hình lập luận Granite 4.2.

Tác giả: Đội ngũ Granite, IBM

Tóm tắt: Granite 4.2 là dòng mô hình ngôn ngữ lớn (LLM) lập luận dạng dense, decoder-only đầu tiên của chúng tôi, được phát hành với ba kích thước: 3B, 8B và 30B. Mỗi mô hình được huấn luyện trước (pre-trained) từ đầu trên khoảng 15 nghìn tỷ token với chiến lược năm giai đoạn, mở rộng cửa sổ ngữ cảnh lên 512K token, được tinh chỉnh có giám sát (SFT) trên dữ liệu chuỗi suy nghĩ (chain-of-thought), lập luận và quỹ đạo tác tử (agentic-trajectory), sau đó được hậu huấn luyện (post-trained) bằng quy trình học tăng cường đa giai đoạn. Quy trình đó bao gồm học tăng cường tác tử (agentic RL), nơi các mô hình 8B và 30B học cách hành động với các công cụ bên trong môi trường sandbox thực tế. Mỗi mô hình đều có công tắc tư duy / không tư duy, chế độ tư duy nỗ lực thấp dành một ngân sách lập luận ngắn cho các câu hỏi dễ và khả năng gọi công cụ (tool calling) nguyên bản. Tất cả các mô hình Granite 4.2 đều được phát hành theo giấy phép Apache 2.0.

Liên kết:

Tổng quan

Granite 4.2 là phiên bản tập trung vào lập luận của dòng mô hình ngôn ngữ Granite. Các phiên bản Granite trước đây là những trợ lý tuân thủ chỉ dẫn mạnh mẽ; Granite 4.2 bổ sung khả năng lập luận rõ ràng. Mỗi mô hình có thể tạo ra một chuỗi suy nghĩ trước khi đưa ra câu trả lời và có thể chạy ở chế độ tư duy hoặc không tư duy tùy thuộc vào mức độ cân nhắc mà tác vụ yêu cầu. Chế độ nỗ lực thấp nằm giữa hai chế độ này, dành một ngân sách lập luận ngắn cho các câu hỏi dễ.

Ba kích thước (3B, 8B và 30B) chia sẻ cùng một thiết kế kiến trúc và tuân theo cùng một quy trình huấn luyện (huấn luyện trước từ đầu, SFT, sau đó là RL đa giai đoạn), mỗi kích thước ở quy mô riêng. Cả ba đều là những mô hình lập luận và tuân thủ chỉ dẫn mạnh mẽ. Sự khác biệt rõ ràng nhất về năng lực xuất hiện ở giai đoạn hậu huấn luyện. Các mô hình 8B và 30B được bổ sung thêm khối RL tác tử giúp chúng vận hành như các tác tử: gọi công cụ, chỉnh sửa và chạy mã, điều khiển terminal và tìm kiếm trên web trong môi trường thực tế. Mỗi mô hình đều hỗ trợ gọi công cụ nguyên bản. Được phục vụ thông qua endpoint tương thích với OpenAI (ví dụ: với vLLM), mô hình phát ra các lệnh gọi công cụ theo định dạng function-calling của OpenAI và kết nối vào các khung tác tử (agentic harnesses) mà không cần thêm mã trung gian. Granite 4.2 cũng được hỗ trợ trong SGLang, hãy xem cookbook của SGLang để biết công thức triển khai sẵn sàng.

Phần còn lại của bài viết này sẽ đi sâu vào quá trình xây dựng: kiến trúc, huấn luyện trước, tinh chỉnh có giám sát, quy trình RL đa giai đoạn và kết quả.

Kiến trúc mô hình

Các mô hình Granite 4.2 được xây dựng trên kiến trúc transformer dense decoder-only với các thành phần cốt lõi sau:

Huấn luyện trước (Pre-Training)

Granite 4.2 được huấn luyện từ đầu trên khoảng 15 nghìn tỷ token bằng chiến lược huấn luyện năm giai đoạn. Các giai đoạn 1–2 tập trung vào huấn luyện trước nền tảng, các giai đoạn 3–4 thực hiện huấn luyện trung gian với việc tinh chỉnh dữ liệu (data annealing) có chất lượng cao dần, và giai đoạn 5 giới thiệu huấn luyện ngữ cảnh dài, mở rộng cửa sổ ngữ cảnh lên 512K token. Mỗi giai đoạn sử dụng một hỗn hợp dữ liệu và lịch trình tốc độ học (learning-rate schedule) riêng biệt, chuyển dần từ dữ liệu quy mô web rộng lớn sang các nguồn chất lượng cao, được chọn lọc kỹ lưỡng hơn.

Công thức huấn luyện trước tuân theo sát thế hệ trước; để biết chi tiết về hỗn hợp dữ liệu, lịch trình giai đoạn và mở rộng ngữ cảnh dài, hãy xem blog về Granite 4.1.

SFT: Chuẩn bị dữ liệu & Kiểm soát chất lượng

Tinh chỉnh có giám sát (SFT) biến mô hình cơ sở thành một trợ lý đáng tin cậy trong việc tuân thủ chỉ dẫn, lập luận và sử dụng công cụ. Hỗn hợp dữ liệu SFT kết hợp dữ liệu tác tử (31,6%) và phi tác tử (68,4%), tổng cộng khoảng 7,2 triệu mẫu, tương đương khoảng 100 tỷ token, trong đó khoảng 65 tỷ token có thể huấn luyện được.

Tập dữ liệu tác tử bao gồm nhiều lĩnh vực, bao gồm kỹ thuật phần mềm (SWE, 69%), gọi công cụ (12,1%), sử dụng terminal (8,0%), toán học (3,5%), tìm kiếm (0,8%) và hành động (0,2%). Các mẫu và quỹ đạo này được tạo ra bằng cách sử dụng nhiều khung tác tử và bộ công cụ hỗ trợ đa dạng, bao gồm OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex và Goose. Dữ liệu tác tử kết hợp các mẫu từ cả tập dữ liệu mã nguồn mở và các môi trường RL được tạo tổng hợp của riêng chúng tôi, bao gồm nhiều sự kết hợp giữa tác tử và khung hỗ trợ.

Tập dữ liệu phi tác tử bao gồm một số danh mục chính: tuân thủ chỉ dẫn (18,8%), lập trình (18,8%), toán học (14,6%), đa ngôn ngữ (7,0%), khoa học (5,4%), lập luận (3,0%) và an toàn (0,8%).

Kiểm soát chất lượng dữ liệu

Chúng tôi áp dụng nhiều giai đoạn kiểm soát chất lượng trước khi một mẫu được đưa vào hỗn hợp SFT cuối cùng. Đầu tiên, dữ liệu từ các nguồn khác nhau được chuẩn hóa và định dạng lại thành định dạng OpenAI Chat nhất quán, giúp cấu trúc hội thoại và tương tác công cụ đồng nhất trên các tập dữ liệu và khung hỗ trợ.

Sau đó, chúng tôi sử dụng GPT-OSS-120B và Gemma 4 làm các giám khảo dựa trên LLM để đánh giá chất lượng mẫu. Các mẫu có điểm thấp sẽ bị loại bỏ, cũng như các mẫu chứa thông tin bịa đặt hoặc ảo tưởng, tương tác công cụ không hợp lệ hoặc các lệnh gọi công cụ đến các hàm không được định nghĩa trong danh sách công cụ tương ứng. Một số quy tắc heuristic nhắm mục tiêu, cụ thể cho từng tập dữ liệu cũng được áp dụng khi cần thiết để cải thiện chất lượng và loại bỏ các nguồn nhiễu đã biết.

Cuối cùng, chúng tôi thực hiện khử trùng lặp (deduplication) cả cục bộ và toàn cục. Việc khử trùng lặp dựa trên các mã băm SHA-256 được tính toán trên sự kết hợp của các trường công cụ và tin nhắn, loại bỏ các mẫu trùng lặp cả trong từng nguồn dữ liệu riêng lẻ và trên toàn bộ hỗn hợp SFT.

Chi tiết huấn luyện SFT

Toàn bộ tập dữ liệu được xáo trộn toàn cục trước để giảm hiệu ứng thứ tự và đảm bảo các mẫu từ các lĩnh vực khác nhau được trộn đều trong quá trình huấn luyện. Tập dữ liệu sau khi xáo trộn được phân chia thành các shard.parquet có kích thước bằng nhau, được token hóa bằng tokenizer và chat template của mô hình, sau đó chuẩn bị cho quá trình huấn luyện phân tán quy mô lớn.

Trước khi khởi chạy các đợt huấn luyện quy mô lớn cuối cùng, chúng tôi điều chỉnh các siêu tham số trên các cấu hình đại diện, quét qua các lịch trình tốc độ học, tốc độ học ban đầu và tỷ lệ warm-up để tìm các cài đặt giúp huấn luyện ổn định trên các kích thước mô hình. Cấu hình huấn luyện cuối cùng được tóm tắt dưới đây:

SFT giai đoạn 2 cho mô hình 30B

Đối với mô hình 30B, chúng tôi thực hiện thêm giai đoạn SFT thứ hai tập trung cụ thể vào lập trình tác tử. Trong giai đoạn này, dữ liệu tác tử, SWE và lập trình được lấy mẫu lại (upsampled) để tăng đóng góp hiệu quả của chúng vào phân phối huấn luyện, trong khi khoảng 16% hỗn hợp được giữ lại làm dữ liệu phát lại (replay data) từ tập dữ liệu SFT gốc.

Sau đó, mô hình 30B được tinh chỉnh thêm khoảng một epoch với tốc độ học thấp hơn là 3.0e-6. Giai đoạn thứ hai có mục tiêu này giúp tăng khả năng tiếp xúc của mô hình với các quỹ đạo lập trình tác tử mà không làm mất đi các năng lực đã đạt được trong giai đoạn SFT ban đầu.

Học tăng cường: Quy trình đa giai đoạn, đa môi trường

Sau SFT, chúng tôi áp dụng quy trình học tăng cường đa giai đoạn, đa môi trường. Thay vì một lượt RL duy nhất, chúng tôi chạy một chuỗi các giai đoạn tập trung bao gồm nhiều môi trường: toán học, mã nguồn, khoa học, tuân thủ chỉ dẫn, sử dụng công cụ và đầu ra có cấu trúc, sau đó là kỹ thuật phần mềm, sử dụng terminal và tìm kiếm web. Mỗi giai đoạn là một lượt chạy RL độc lập nhắm vào một năng lực và khởi động từ checkpoint của giai đoạn trước.

Hình 1. Chương trình giảng dạy RL theo giai đoạn. RL nền tảng (phần thưởng có thể kiểm chứng + tăng cường kỹ năng) chạy cho tất cả các kích thước; khối RL tác tử (SWE → Terminal → Search) chỉ chạy cho 8B và 30B. Mọi mô hình đều kết thúc bằng RLHF. Mỗi giai đoạn là một lượt chạy GRPO riêng biệt khởi động từ checkpoint trước đó.

Phương pháp huấn luyện

Mỗi giai đoạn huấn luyện với GRPO (Group Relative Policy Optimization) không đồng bộ, vì vậy các nửa generator và trainer của vòng lặp không bao giờ chặn lẫn nhau. Một nhóm các worker tạo phản hồi liên tục lấy mẫu và thả các quỹ đạo đã hoàn thành vào một bộ đệm dùng chung; khi bộ đệm chứa đủ một bước, trainer sẽ lấy batch đó, thực hiện một bước tối ưu hóa và truyền các tham số đã cập nhật trở lại các worker tạo mà không tạm dừng chúng. Việc làm mới có thể diễn ra giữa chừng trong quá trình rollout, để lại một quỹ đạo duy nhất được ghép từ hai phiên bản chính sách liền kề. Chúng tôi cho phép điều này thay vì trả chi phí để ngăn chặn nó: các worker tái sử dụng bộ nhớ đệm KV hiện có thay vì xây dựng lại sau mỗi lần làm mới, và rào cản duy nhất là giới hạn ngăn chúng trôi xa hơn một bản cập nhật so với trainer, điều này giới hạn mức độ off-policy của bất kỳ mẫu nào. Bất kỳ sự sai lệch nào vượt qua giới hạn đó đều được xử lý trong mục tiêu bằng cách lấy mẫu quan trọng bị cắt cụt (truncated importance sampling), giúp cố định tỷ lệ log-xác suất giữa huấn luyện và tạo ở một mức trần, để một vài token cũ không thể chi phối một bản cập nhật.

Các lợi thế mang tính tương đối theo nhóm với đường cơ sở "loại trừ một" (leave-one-out): mỗi phản hồi được đánh giá dựa trên phần thưởng trung bình của các mẫu khác được rút ra cho cùng một prompt, giúp loại bỏ nhu cầu về một mạng giá trị riêng biệt. Để cụ thể hóa điều này, hãy lấy RLVR, giai đoạn đầu tiên và chạy lâu nhất: mỗi bước ghép 256 prompt với 16 phản hồi được lấy mẫu cho mỗi prompt để tạo thành một batch 4.096 ví dụ, mà trainer tiêu thụ trong một bước tối ưu hóa duy nhất trước khi lượt rollout tiếp theo bắt đầu. Các giai đoạn sau giữ nguyên cơ chế này và chỉ điều chỉnh hình dạng mỗi giai đoạn, được hiển thị tiếp theo.

Cấu hình huấn luyện RL

Quy trình này duy trì một khung siêu tham số chung qua mọi giai đoạn, giúp chương trình giảng dạy dễ chạy và so sánh hơn. Một số nút điều chỉnh được cố định ở mọi nơi:

Điều thay đổi giữa các giai đoạn là hình dạng của mỗi lượt chạy: bao nhiêu prompt và thế hệ phản hồi mỗi bước, ngữ cảnh dài bao nhiêu, vòng lặp tác tử có chạy hay không và mức độ chúng tôi kéo ngược về chính sách tham chiếu. Bảng dưới đây đưa ra các cài đặt chính xác cho chuỗi 30B, theo từng giai đoạn:

Các tham số hiển thị cho mô hình 30B. Batch size toàn cục = prompt/bước × thế hệ phản hồi/prompt (ví dụ: 256 × 16 = 4096 cho RLVR). Các mô hình 3B và 8B sử dụng cùng công thức và siêu tham số với ít giai đoạn hơn (xem Cách ba kích thước khác nhau như thế nào); danh sách giai đoạn là thứ thay đổi, không phải các nút điều chỉnh.

Lịch trình KL tuân theo loại phần thưởng: khám phá tự do nơi phần thưởng là khách quan và có thể kiểm chứng (RLVR và SWE 2 chạy ở KL 0), và giữ gần với tham chiếu nơi mục tiêu là sở thích, an toàn hoặc ghép kỹ năng hẹp (RLHF và bộ tăng cường mã sử dụng KL 0.05). Cột rollout-turns đếm các tương tác môi trường mà chính GRPO thấy trên mỗi lượt rollout. Trong mọi trường hợp, mô hình đều được huấn luyện trên các quỹ đạo môi trường thực tế, hoàn chỉnh.