Baseten để AI tự viết engine suy luận, nhanh hơn vLLM 90%

Nhà cung cấp dịch vụ suy luận Baseten vừa đăng một bài blog kỹ thuật vào ngày 2 tháng 10: họ dùng Claude Code để điều khiển Fable 5, giao cho agent tự viết từ đầu một engine suy luận chỉ phục vụ một mô hình duy nhất, và kết quả là engine này vượt qua vLLM ở toàn bộ các mô hình lưu lượng truy cập được kiểm thử.

Engine này có tên VibeQwen, được thiết kế riêng để phục vụ mô hình Qwen-3.6-35B-A3B của Alibaba. Tác giả Shawn Rushefsky viết trong bài:

"the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases"

(Engine được tạo ra, gọi là VibeQwen, vượt qua vLLM ở tất cả các mô hình lưu lượng truy cập được kiểm thử, và trong một số trường hợp khoảng cách rất lớn.)

Số liệu đến từ đâu

Phần cứng kiểm thử là Nvidia B200, nhóm đối chiếu là vLLM 0.25.1, công cụ đo tải là AIPerf. Một vài kết quả:

  • Giải mã đơn luồng đạt 1792 TPS, vLLM chỉ đạt 943 TPS, nhanh hơn khoảng 90%;
  • Độ trễ token đầu tiên giảm từ 28 ms xuống 12 ms, tương đương khoảng 2,3 lần;
  • Ở mức 32 luồng đồng thời, thông lượng cao hơn 71%.

Về chi phí, VibeQwen mất khoảng một tuần, tiêu tốn khoảng 1,7 tỷ token (phần lớn trúng cache), khoảng 200 giờ B200, tổng chi phí ở mức vài nghìn đô la.

Baseten cũng thử cùng phương pháp này trên bài toán phân đoạn ảnh. Sản phẩm thứ hai có tên Sammie, phục vụ mô hình SAM 3.1 của Meta, chạy trên H100, hoàn thành trong vài ngày với chi phí vài trăm đô la và khoảng 200 triệu token. Ở mức 32 luồng đồng thời, thông lượng cao hơn 50% so với server tham chiếu chính thức của Meta, đạt 91 ảnh mỗi giây.

Agent đã làm gì trong quá trình này

Baseten mở rộng framework nội bộ có tên MetaInfer thành một stack phục vụ hoàn chỉnh, rồi giao cho agent tự điền vào. Agent có thể tham khảo các giải pháp mã nguồn mở hiện có, sau mỗi lần sửa đổi sẽ dùng AIPerf để đo tải lại, và quyết định bước tiếp theo dựa trên số liệu.

Có một ràng buộc được viết rất cụ thể: bất kỳ thay đổi nào có thể ảnh hưởng đến độ chính xác đầu ra, agent đều phải dừng lại để xin con người phê duyệt. Độ trôi số học nhỏ là thứ khó phát hiện nhất trong một engine suy luận; nếu tốc độ tăng lên nhưng phải đánh đổi bằng độ chính xác, bảng xếp hạng benchmark sẽ không cho thấy điều đó — ràng buộc này chính là để chặn trường hợp đó.

Bài blog cũng tự vạch rõ giới hạn. Cả VibeQwen và Sammie đều vẫn là sản phẩm thử nghiệm, chưa phục vụ lưu lượng sản xuất thực tế. Phần so sánh của Sammie còn thô hơn, tác giả tự nhận những số liệu đó chỉ là "bằng chứng gợi ý": hai bên kiến trúc khác nhau, bộ gia tốc khác nhau, cũng không có nhóm đối chiếu được kiểm soát.

Nhìn từ góc độ các nhóm tại Trung Quốc

Đối tượng của VibeQwen là mô hình mã nguồn mở Qwen, và rất nhiều dịch vụ trực tuyến tại Trung Quốc vừa đúng lúc cũng chạy trên tổ hợp Qwen cộng với vLLM hoặc SGLang, nên những số liệu này liên quan trực tiếp đến công việc hằng ngày của không ít nhóm kỹ thuật.

Có thể so sánh bài toán kinh tế giữa hai cách làm. Engine đa năng phải chăm sóc hàng trăm kiến trúc mô hình khác nhau, nên nhiều tối ưu hóa mạnh tay cho riêng một kiến trúc không thể đưa vào; engine chuyên dụng chỉ nhắm vào một mô hình, có thể điều chỉnh toàn bộ kernel attention, cơ chế định tuyến MoE, chiến lược lập lịch theo đúng hình dạng của 35B-A3B. Trước đây viết một engine chuyên dụng cần một nhóm làm việc trong vài tháng, lần này Baseten rút ngắn xuống một tuần, chi phí vài nghìn đô la — tính sơ còn rẻ hơn một tháng công của một kỹ sư suy luận.

Hạn chế cũng rõ ràng:

  1. Engine gắn chặt với mô hình. Khi Qwen nâng cấp và thay đổi kiến trúc, engine nhiều khả năng phải được tạo lại từ đầu.
  2. Kiểm thử chỉ phủ trên B200. Các loại GPU có sẵn tại Trung Quốc rất đa dạng, liệu cùng quy trình này có lặp lại được trên các bộ gia tốc khác hay không, bài blog không có số liệu.
  3. Độ ổn định đuôi dài, phân mảnh bộ nhớ, xử lý request bất thường mà môi trường sản xuất cần — benchmark chưa chắc đã phủ hết.

Dù vậy, hướng đi "mỗi mô hình chủ lực đi kèm một engine chuyên dụng được tạo tự động" đã có một mẫu thử có thể kiểm chứng lại được. Việc vai trò của vLLM có chuyển từ "trụ cột sản xuất" xuống "đường cơ sở và phương án dự phòng" hay không, còn tùy có nhóm nào đưa loại engine này vào sản xuất thật và công khai dữ liệu chạy trong vài tháng hay không.

Nguồn tham khảo: blog kỹ thuật Baseten, CocoLoop; TPS, độ trễ token đầu tiên, thông lượng đồng thời, token tiêu thụ và số giờ GPU được xác nhận qua blog Baseten.