Tinh chỉnh mô hình 235B trên bốn GPU: Bài học từ một dự án triển khai thất bại

Các kỹ sư tại Vertexcover đã thành công trong việc tinh chỉnh mô hình Qwen3 với 235 tỷ tham số trên một máy chủ duy nhất trang bị bốn GPU H100, đạt được mức tăng đáng kể về độ chính xác so với các mô hình API trả phí. Bất chấp thành công kỹ thuật và chi phí giảm xuống cho mỗi token, nhóm quyết định không triển khai giải pháp này sau khi các mô hình mã nguồn mở mới ra mắt khiến hạ tầng phức tạp trở nên không cần thiết.

Chuyện gì đã xảy ra

Nhóm đặt mục tiêu thay thế các mô hình OpenAI và Gemini đã qua tinh chỉnh đắt đỏ, vốn được dùng để phân loại thực thể trong tài liệu khách hàng. Họ chọn Qwen3-235B-A22B-Thinking, một mô hình Hỗn hợp Chuyên gia (Mixture of Experts - MoE), vì nó vượt trội hơn các mô hình mã nguồn mở khác trong các bài kiểm tra ban đầu. Mục tiêu là duy trì hoặc cải thiện độ chính xác đồng thời kiểm soát chi phí thông qua phần cứng tự lưu trữ.

Sau một epoch huấn luyện trên khoảng 3.600 ví dụ, mô hình đã tinh chỉnh cải thiện điểm F1 trung bình thêm 7,6 điểm trên tất cả các khách thuê bao. Nó cũng giảm chi phí cho mỗi token xuống còn khoảng một phần ba so với các giải pháp dựa trên API trước đó. Quá trình huấn luyện mất 26 giờ trên bốn GPU NVIDIA H100, mỗi card có bộ nhớ 80 GB.

Bất chấp các chỉ số tích cực này, dự án đã bị gác lại. Nhóm nhận thấy rằng việc phục vụ mô hình thinking 235B với độ trễ thấp và chi phí vận hành hợp lý là một thách thức kỹ thuật lớn hơn nhiều so với bản thân quá trình tinh chỉnh. Đồng thời, các mô hình mã nguồn mở mới xuất hiện có khả năng xử lý nhiều tác vụ phân loại mà không cần bất kỳ sự tinh chỉnh nào, loại bỏ nhu cầu về hạ tầng tùy chỉnh của họ.

Cách hoạt động

Qwen3-235B là một mô hình MoE, trong đó chỉ khoảng 22 tỷ trong số 235 tỷ tham số của nó được kích hoạt cho bất kỳ token cụ thể nào. Mỗi lớp chứa 128 mạng chuyên gia nhỏ, và một bộ định tuyến hướng dẫn các token đến những chuyên gia liên quan nhất. Kiến trúc này giúp việc suy luận ít tốn kém tính toán hơn so với các mô hình đặc (dense models) cùng kích thước, nhưng làm phức tạp việc quản lý bộ nhớ trong quá trình nạp và huấn luyện.

Nhóm sử dụng QLoRA (Quantized Low-Rank Adaptation) để tinh chỉnh mô hình. Phương pháp này nén mô hình cơ sở xuống độ chính xác 4-bit, giảm dung lượng bộ nhớ từ 470 GB xuống còn khoảng 120 GB. Các lớp adapter nhỏ sau đó được huấn luyện trên nền tảng trọng số gốc đã đóng băng. Thách thức nằm ở việc phối hợp các thư viện nén và phân mảnh (sharding), vốn có các yêu cầu mâu thuẫn nhau về cách lưu trữ và truy cập trọng số mô hình trong bộ nhớ.

Huấn luyện thành công đòi hỏi DeepSpeed ZeRO-3 kèm theo offload sang CPU. Cấu hình này giữ các bản sao đầy đủ của mô hình nén 120 GB trong RAM hệ thống thay vì bộ nhớ GPU. Trong quá trình huấn luyện, các lớp được di chuyển từ RAM sang GPU khi cần thiết, cho phép bốn card H100 xử lý khối lượng công việc mặc dù giới hạn bộ nhớ riêng lẻ của từng card. Cách tiếp cận này đánh đổi tốc độ lấy tính khả thi, dẫn đến thời gian huấn luyện kéo dài 26 giờ.

Chi tiết chính

• Mô hình cải thiện điểm F1 cho mọi khách thuê bao, với mức tăng dao động từ +4,81 đến +11,96 điểm.
• Huấn luyện sử dụng 3.600 ví dụ bao gồm cả dấu vết suy luận (reasoning traces), vì Qwen3 là một mô hình "thinking".
• Yêu cầu bốn GPU H100 với bộ nhớ 80 GB mỗi card và 960 GB RAM hệ thống.
• Các triển khai Axolotl, Unsloth và FSDP+QLoRA của Answer.AI đều thất bại do vấn đề bộ nhớ hoặc tương thích.
• LlamaFactory với FSDP tiêu chuẩn thất bại vì Transformers âm thầm tắt các cài đặt tiết kiệm bộ nhớ trong quá trình lượng tử hóa.
• Cấu hình cuối cùng hoạt động tốt sử dụng LlamaFactory với DeepSpeed ZeRO-3 và offload CPU để quản lý bộ nhớ.

Tại sao điều này quan trọng

Trường hợp này làm nổi bật sự phức tạp ẩn giấu của việc tinh chỉnh các mô hình MoE khổng lồ trên phần cứng hạn chế. Các kỹ sư thường giả định rằng lượng tử hóa và phân mảnh sẽ dễ dàng đưa các mô hình lớn vào bộ nhớ GPU khả dụng, nhưng sự không tương thích của thư viện và các vấn đề về thứ tự bộ nhớ có thể ngăn cản quá trình huấn luyện bắt đầu. Hiểu rõ các ràng buộc cấp thấp này là rất quan trọng để lập kế hoạch hạ tầng cho các mô hình vượt quá 100 tỷ tham số.

Nó cũng là lời nhắc nhở rằng khả năng kỹ thuật không phải lúc nào cũng biện minh cho việc triển khai. Nỗ lực tối ưu hóa suy luận cho một mô hình 235B có thể vượt quá lợi ích của việc tinh chỉnh, đặc biệt khi mô hình cơ sở đã mạnh mẽ. Các đội ngũ phải đánh giá tổng chi phí sở hữu, bao gồm độ trễ phục vụ và yêu cầu phần cứng, chứ không chỉ độ chính xác và chi phí huấn luyện.

Cuối cùng, nhịp độ phát triển nhanh chóng của mã nguồn mở có nghĩa là vấn đề kỹ thuật khó khăn hôm nay có thể được giải quyết bởi một bản phát hành mô hình vào ngày mai. Đầu tư vài tuần vào các pipeline tinh chỉnh tùy chỉnh mang rủi ro chi phí chìm nếu một mô hình đa năng cải thiện đủ để xử lý tác vụ ngay từ đầu. Sự kiên nhẫn chiến lược đôi khi mang lại kết quả tốt hơn so với việc tùy chỉnh ngay lập tức.

Bạn có thể làm gì

• Kiểm tra hiệu suất (benchmark) nhiều mô hình mã nguồn mở trước khi cam kết tinh chỉnh, vì hiệu suất cơ bản biến động đáng kể.
• Xác minh tính tương thích của thư viện cho các mô hình MoE, đặc biệt liên quan đến thứ tự lượng tử hóa và phân mảnh.
• Đảm bảo đủ RAM hệ thống cho việc offload CPU khi bộ nhớ GPU không đủ cho toàn bộ mô hình đã nén.
• Giám sát các cài đặt của Transformers để phát hiện những thay đổi âm thầm đối với quản lý bộ nhớ trong quá trình lượng tử hóa.
• Đánh giá chi phí suy luận và yêu cầu độ trễ sớm, không chỉ tập trung vào độ chính xác và chi phí huấn luyện.
• Đánh giá lại nhu cầu tinh chỉnh thường xuyên, vì các mô hình cơ sở mới có thể thu hẹp khoảng cách hiệu suất mà không cần tùy chỉnh.