- Hơn 100 AI agents hợp tác trong 1 tuần, tăng tốc inference Gemma 4 trên vLLM lên gần 5 lần.
- Nguyên nhân khởi đầu chậm: kiến trúc hybrid attention đặc biệt khiến vLLM phải dùng đường vòng Triton thay vì FlashAttention.
- Stack tối ưu gồm kernel fix, quantization FP8/NVFP4 và MTP speculative decoding với acceptance rate 96.5%.
- Đội nhóm 3-5 agents tốt hơn nhóm 20+ agents trong mọi benchmark.
TL;DR
Thomas Wolf, đồng sáng lập Hugging Face, vừa chia sẻ kết quả của Fast Gemma Challenge - thí nghiệm do Google và Hugging Face tổ chức: hơn 100 AI agents hợp tác trong 1 tuần và tăng tốc inference Gemma 4 trên vLLM lên gần 5 lần. Điều đáng chú ý không chỉ là con số 5x, mà là cách các agents tự xây dựng quy tắc, tự phân công công việc và kiểm tra lẫn nhau - không cần con người điều phối từng bước.
Tại sao Gemma 4 khởi đầu chậm đến vậy?
Để hiểu tại sao kết quả 5x lại đáng kể, cần biết vLLM xử lý Gemma 4 kém hiệu quả đến mức nào ngay từ đầu.
Gemma 4 sử dụng kiến trúc hybrid attention 5:1 - cứ 5 lớp local attention thì có 1 lớp global attention - với head dimension không chuẩn là 256 và 512. Đây là thiết kế cố ý của Google để cân bằng giữa hiệu năng và tốc độ, nhưng nó lại gây ra một vấn đề nghiêm trọng với vLLM.
vLLM tích hợp FlashAttention để tăng tốc, nhưng FlashAttention trong phiên bản đó chỉ hỗ trợ các head dimension phổ biến. Khi gặp Gemma 4, vLLM không kích hoạt được FlashAttention và buộc phải reroute sang Triton kernel - vốn là đường dự phòng chậm hơn nhiều. Kết quả: điểm xuất phát khoảng 9 tok/s trên RTX 4090, chậm hơn khoảng 14 lần so với các model có thông số tương đương chạy đúng kernel.
Nói cách khác, phần lớn con số 5x đến từ việc khắc phục một lỗi cấu hình, không phải từ kỳ tích kỹ thuật nào hoàn toàn mới. Nhưng cách hơn 100 AI agents phối hợp để tìm ra và vá lỗi đó mới là câu chuyện đáng kể.
Hơn 100 AI Agents Phối Hợp Như Thế Nào?
Không có một tổng chỉ huy nào. Các agents tương tác qua một bảng tin chung công khai - tương tự một GitHub issue thread mở hoặc một kênh Discord có lịch sử minh bạch. Ai cũng đọc được mọi thứ đã xảy ra trước đó.
Việc phân công diễn ra tự nhiên theo tài nguyên:
- Agents có GPU mạnh tập trung chạy benchmark và thử nghiệm các kernel mới
- Agents hết quota GPU chuyển sang viết tài liệu kỹ thuật, phân tích kết quả và tính toán lý thuyết
- Một số agents chia sẻ tài nguyên Modal để hỗ trợ các agents khác đang bị giới hạn số lần benchmark mỗi ngày
Điều quan trọng là cộng đồng tự xây dựng knowledge base chung: playbook mô tả các hướng tối ưu đã biết, lever maps liệt kê các lever kỹ thuật và mức tác động ước tính, triage tools giúp agents mới nhanh chóng xác định nên thử gì và không cần lặp lại những hướng đã thất bại.
Có một chuỗi 4 agents cùng xử lý một nhiệm vụ nói lên rõ cơ chế này: agent đầu tiên tạo checkpoint int4-lm_head nhưng hết quota. Agent thứ hai chạy thử nhưng gặp lỗi. Agent thứ ba phân tích và phát hiện nguyên nhân do cấu hình tie_word_embeddings và ignore-list. Cuối cùng, agent thứ tư chạy thành công và đạt 118 tok/s, tương đương tăng 2.68 lần. Không agent nào biết trước mình sẽ là người hoàn thành.
Những Khoảnh Khắc Bất Ngờ Trong Quá Trình Hợp Tác
Kết quả kỹ thuật là điều có thể dự đoán - nhưng các hành vi emergent của agents mới là phần khó đoán nhất.
Từ chối chuyển kênh riêng: Khi một participant đề xuất chuyển cuộc thảo luận kỹ thuật sang Telegram để trao đổi nhanh hơn, một agent đã phản đối thẳng thắn: việc thảo luận ở kênh riêng tư khó phân biệt với hành vi phối hợp gian lận, và toàn bộ quá trình nên được công khai để bất kỳ ai cũng có thể theo dõi và kiểm chứng.
Tự phát hiện và báo cáo lỗ hổng: Một agent tìm ra cách tối ưu giúp tăng điểm TPS đáng kể, nhưng sau khi phân tích kỹ hơn, agent đó nhận ra cách tối ưu này khai thác một điểm yếu trong hệ thống đánh giá - không phản ánh tốc độ thật của model. Thay vì giữ lại kết quả, agent chủ động đăng báo cáo lên cộng đồng và đề nghị bỏ phiếu. Người tổ chức sau đó xác nhận kết quả là không hợp lệ.
Cảnh báo nguy cơ overfitting: Một agent nhận ra một số tối ưu chỉ hoạt động tốt trên tập dữ liệu đánh giá công khai, không phản ánh hiệu năng thực tế. Sau cảnh báo, agent khác xây dựng bộ dữ liệu kiểm tra riêng để đánh giá công bằng hơn.
Tự chuẩn hóa ngưỡng đánh giá: Sau nhiều lần benchmark, cộng đồng đo được độ dao động tự nhiên khoảng σ ≈ 1.16 TPS. Họ tự đặt quy tắc: chênh lệch dưới ~4 TPS được coi là tương đương. Quy tắc này sau đó được dùng nhất quán trên toàn cộng đồng.
Stack Tối Ưu Đạt 5x - Những Gì Thực Sự Hoạt Động
Kết quả 5x không đến từ một cải tiến đột phá duy nhất, mà là từ nhiều layer xếp chồng lên nhau:
- Kernel normalization - tác động lớn nhất: mở rộng FlashAttention để hỗ trợ head dimension 256/512 của Gemma 4, loại bỏ Triton fallback. Đây là nguyên nhân chính khiến baseline thấp bất thường.
- FP8/NVFP4 quantization: giảm precision để tăng throughput, đạt 1.7-2.66x speedup thêm với đánh đổi nhỏ về chất lượng (FP8 block quantization gây một số logit-saturation bugs ở cấu hình không phù hợp).
- MTP Speculative Decoding: ghép drafter nhỏ với target model để dự đoán nhiều token cùng lúc, rồi verify song song. Acceptance rate đạt 96.5% - gần như tất cả token đề xuất đều được chấp nhận.
- torch.compile: giảm overhead từ graph compilation.
Một phát hiện đáng chú ý: drafter lớn hơn không nhất thiết tốt hơn. Mô hình 2B drafter tiêu tốn nhiều băng thông bộ nhớ hơn, trong khi drafter nhỏ hơn cho hiệu quả tốt hơn ở batch size = 1. Nhiều giả thuyết tưởng đúng ngay từ đầu đã bị chính cộng đồng bác bỏ sau khi có thêm thực nghiệm.
Điều Này Có Ý Nghĩa Gì Với Tương Lai Nghiên Cứu AI?
Thí nghiệm Fast Gemma Challenge không chứng minh AI agents có thể thay thế con người trong nghiên cứu. Con người vẫn đóng vai trò giám sát quan trọng ở những điểm quan trọng - xác nhận lỗ hổng benchmark, loại bỏ kết quả không hợp lệ, thiết kế quy tắc ban đầu cho cộng đồng.
Nhưng thí nghiệm này cho thấy điều gì đó quan trọng hơn: multi-agent systems đang tiếp cận mô hình hoạt động của một nhóm nghiên cứu thực sự - không phải chỉ là một AI chạy nhanh hơn AI kia.
Các agents phân công theo năng lực sẵn có, không phải theo chỉ thị cứng. Họ kiểm tra chéo nhau và bác bỏ kết quả của nhau khi cần. Họ xây dựng knowledge base tập thể thay vì mỗi agent tự tìm lại từ đầu. Và họ tự đặt ra chuẩn mực về tính minh bạch - không phải vì được lập trình để làm vậy, mà vì một agent đã lập luận rằng đó là điều đúng đắn trong bối cảnh cạnh tranh công khai này.
Một điểm đáng chú ý về quy mô: nhóm 3-5 agents cho kết quả tốt nhất trên mỗi task cụ thể. Nhóm 20+ agents thực sự cho kết quả kém hơn - không phải vì agents không đủ giỏi, mà vì coordination overhead vượt quá lợi ích của parallelism. Đây là bài học không chỉ áp dụng cho AI, mà cho bất kỳ đội nhóm nào.
Kết
5x là con số ấn tượng, nhưng bối cảnh thực sự là: đây là 5x từ một baseline bất thường thấp do một vấn đề kiến trúc cụ thể. Điều đó không làm giảm giá trị của thí nghiệm - nó chỉ làm rõ hơn câu hỏi thực sự đang được trả lời.
Câu hỏi không phải là "AI có thể tối ưu model nhanh không?" - đó là "nhiều AI agents có thể tự tổ chức thành một nhóm nghiên cứu có hiệu quả không, và cái gì thực sự tạo ra hiệu quả đó?" Kết quả từ Fast Gemma Challenge gợi ý câu trả lời là có - với điều kiện quy mô đúng, cơ sở hạ tầng đánh giá vững chắc, và một môi trường mở đủ minh bạch để agents tự kiểm tra lẫn nhau.
Đạo hữu là phàm nhân, tu tiên giả
... hay AI cào nội dung?
Tất cả nội dung tại đạo quán đều miễn phí. Đạo hữu chỉ cần nhập email của mình để đọc tiếp. Nói KHÔNG với Spam. Huỷ subcribe lúc nào đạo hữu thích.
nếu không muốn nhận newsletter thì có thể nhập mail phụ
