Cursor's MoK đạt hiệu suất tăng 2,37 lần trên NVIDIA GB300 NVL72

Cursor mở nguồn MoK, tích hợp việc điều phối token, giao tiếp xuyên GPU và tính toán chuyên gia vào cùng một nhân GPU. Giải pháp này đạt hiệu suất tăng tối đa 2,37 lần cho tiến trình MXFP8 và 1,78 lần cho lùi tiến trình trên GB300 NVL72, đồng thời tăng thông lượng đào tạo với 512 GPU GB300 lên 41% đến 1070,2 tokens/s. Độ trễ tín hiệu giảm từ 103μs xuống còn 18μs. Phân tích chỉ ra rằng, khi băng thông NVLink đã đạt 130 TB/s ngày nay, thời gian chờ dữ liệu trên GPU trở thành điểm nghẽn hiệu suất mới; bước đột phá này đánh dấu sự chuyển sang giai đoạn “chủ quyền toàn bộ hệ thống” trong cuộc cạnh tranh AI, những công ty có mã nguồn gần bộ nhớ hiển thị và thanh ghi hơn sẽ sở hữu quyền định giá lớn hơn.

Tác giả bài viết, nguồn: LeFengwang

Ngày 21 tháng 7, NVIDIA công bố kết quả mới nhất về việc GB300 NVL72 huấn luyện DeepSeek-V3: trên 256 GPU, hiệu năng mỗi card đạt 1.648 TFLOPS.

Chưa đầy hai tuần sau, Cursor đã mở nguồn Mixture-of-Kittens, viết tắt là MoK. Thay vì tiếp tục tối ưu phép nhân ma trận nhanh hơn, họ đã viết lại hoàn toàn một lớp thực thi MoE, gộp việc điều phối token, giao tiếp giữa các GPU và tính toán chuyên gia vào cùng một nhân GPU.

Điều này hơi phản trực giác. Vì GB300 NVL72 đã đặt 72 GPU vào cùng một NVLink Domain, tổng băng thông NVLink của toàn bộ kệ đạt 130 TB/s. Theo thông số này, việc truyền dữ liệu giữa các GPU nên đã đủ nhanh.

Trong quá trình huấn luyện MoE quy mô lớn, giao tiếp vẫn sẽ làm chậm tính toán của các chuyên gia.

Vấn đề nằm ở luồng dữ liệu của MoE. Mỗi bước, Router đều quyết định lại token nào sẽ gửi đến chuyên gia nào, trong khi các chuyên gia được phân tán trên các GPU khác nhau. Token phải được gửi qua các card trước, tính toán xong rồi mới truyền lại; trước khi gửi, cần sắp xếp vị trí, và sau khi đến nơi, phải chờ dữ liệu đầy đủ. Khi MXFP8 và Blackwell Tensor Core làm giảm thời gian tính toán của chuyên gia ngày càng ngắn, những khoảng chờ vốn từng bị che giấu sau tính toán giờ đây trở nên ngày càng rõ rệt.

Cursor làm MoK, chính là bắt đầu từ đây. Nó không chỉ tập trung vào việc một lần Dispatch có thể truyền nhanh đến đâu, mà còn sắp xếp lại cách token đến chuyên gia, thời điểm bắt đầu tính toán, cũng như cách thức giao tiếp và tính toán cùng lúc sử dụng GPU.

Trong bối cảnh tài nguyên tính toán đã được đẩy đến giới hạn bởi Blackwell và NVLink, các nhà phát triển nhận ra: phần cứng chạy nhanh đến đâu cũng không thể cứu vãn phần mềm sắp xếp kém hiệu quả.

Việc MoK mở nguồn không chỉ là chiến thắng của một lõi, mà còn đánh dấu sự khởi đầu của thời đại “ứng dụng层 định nghĩa toán tử”: để khai thác 30% năng lực tính toán cuối cùng, các công ty khởi nghiệp AI đang phát động một cuộc chiến giành lại chủ quyền hạ tầng.

Tuy nhiên, để hiểu tại sao thiết kế của Cursor lại hiệu quả, trước tiên phải xác định rõ MoE đã phải trả “thuế giao tiếp” ở đâu.

01

Thuế liên lạc của MoE

Trong FFN dày đặc thông thường, các token đi qua các trọng số cơ bản là cố định. Sau khi thêm Router vào MoE, mỗi token sẽ tạm thời chọn một số chuyên gia. Khi sử dụng Expert Parallel, các chuyên gia được chia thành nhiều GPU, do đó một lần lan truyền thuận ít nhất phải trải qua hai vòng truyền thông giữa các card.

Vòng đầu tiên gọi là Dispatch, gửi token đến GPU nơi chuyên gia đang hoạt động; sau khi chuyên gia tính toán xong, kết quả sẽ được gửi trở lại vị trí ban đầu của token thông qua Combine. Quá trình huấn luyện còn bao gồm lan truyền ngược, tương ứng với hai vòng truyền thông theo hướng ngược lại.

Nếu chỉ đơn thuần di chuyển một khối dữ liệu liên tục lớn từ A sang B, NVLink đã đủ nhanh. Vấn đề của MoE nằm ở chỗ, phân phối dữ liệu do Router đưa ra ở mỗi bước đều khác nhau.

Một chuyên gia ở bước này có thể nhận được rất nhiều token, nhưng bước tiếp theo lại rất ít. Hệ thống cần đếm chính xác mỗi chuyên gia có bao nhiêu token, sau đó quyết định đặt các token này ở vị trí nào trên GPU mục tiêu, đồng thời cố gắng sắp xếp dữ liệu của cùng một chuyên gia gần nhau. Grouped GEMM mới có thể nhận đầu vào được tổ chức gọn gàng và cung cấp hiệu quả cho Tensor Core.

Sau khi kết thúc giao tiếp, vẫn không thể bắt đầu tính toán ngay lập tức. GPU mục tiêu phải xác nhận rằng việc ghi từ xa đã hoàn tất hoàn toàn và dữ liệu thực sự có thể truy cập được. Tải của các chuyên gia cũng không hoàn toàn đồng đều, một số GPU có thể kết thúc sớm nhưng vẫn phải chờ chuyên gia bận nhất hoàn thành.

Vì vậy, trong một giai đoạn “giao tiếp”, thực tế đang diễn ra đồng thời nhiều việc như di chuyển dữ liệu, tạo bố cục, đồng bộ hóa và mất cân bằng tải. Mức 130 TB/s mô tả băng thông đỉnh mà toàn bộ kệ máy có thể cung cấp, nhưng không có nghĩa là mỗi lần giao tiếp MoE động và rời rạc đều có thể đồng thời sử dụng hết toàn bộ các liên kết này.

DeepEP đã tối ưu hóa việc di chuyển dữ liệu rất nhanh. Đây là thư viện giao tiếp hiệu năng cao được thiết kế dành riêng cho Expert Parallel, cung cấp các nhân Dispatch và Combine chuyên dụng, hỗ trợ FP8 và cho phép kiểm soát số SM được sử dụng cho giao tiếp. Phiên bản mới nhất thậm chí còn có thể duy trì thông lượng giao tiếp cao với số SM ít hơn đáng kể.

Một lớp MoE vẫn phải liên tục chuyển giao giữa Dispatch, Grouped GEMM và Combine.

Lúc này sẽ gặp phải một mâu thuẫn thực tế: nếu đợi đủ nhiều token tập hợp mới tính toán, ma trận sẽ rất lớn, Tensor Core hoạt động hiệu quả, nhưng việc tính toán bắt đầu chậm; nếu tính toán ngay khi có một chút token, giao tiếp và tính toán có thể chồng chéo sớm hơn, nhưng ma trận lại quá nhỏ, khiến nhiều SM của GPU không có đủ công việc.

Nhiều CUDA Stream có thể cho phép giao tiếp và tính toán chạy song song, nhưng rất khó để luôn đảm bảo cả hai bên nhận được tài nguyên GPU vừa đủ.

Thiết kế sau MoK chủ yếu xử lý vấn đề “nhịp điệu” này.

02

Một trong những thay đổi thú vị nhất của MoK là chuyển Dispatch phía trước từ Push sang Pull.

Push truyền thống rất trực quan: khi GPU nguồn có token, nó chủ động ghi token đó vào GPU đích. Vấn đề phát sinh ở địa chỉ đích. Một GPU sẽ đồng thời nhận nhiều token từ các GPU khác nhau.

Mỗi người gửi cần phải biết trước mình nên ghi vào đoạn nào, không được ghi đè lên nhau; các token của cùng một chuyên gia tốt nhất nên được sắp xếp liên tiếp, nếu không, GEMM phía sau lại phải sắp xếp lại.

Khi ngày càng có nhiều GPU tham gia, quá trình lập lịch này sẽ ngày càng nặng nề hơn. Pull đã thay đổi cách thức: lưu trữ GPU mục tiêu của chuyên gia để tự đọc các token cần thiết. Nó chỉ cần biết token nằm trên GPU nguồn nào và ở vị trí nào trong dữ liệu nguồn, còn việc lưu trữ cục bộ thì tự nó sắp xếp.

Điều này đã loại bỏ sự phối hợp giữa nhiều bên gửi đến địa chỉ mục tiêu. Dữ liệu nhận được cũng có thể được sắp xếp trực tiếp theo chuyên gia địa phương.

Điều thú vị là Pull không truyền ít dữ liệu hơn. Trong bài kiểm tra vi mô của Cursor, cùng một khối dữ liệu BF16 256×256, Push di chuyển khoảng 159,6 KB trên NVLink, trong khi Pull lại đạt đến 172,0 KB do việc đọc còn cần gửi thêm yêu cầu.

Pull的优势在于另一点：MoE的通信碎片化且负载不均衡。NVLink的两个方向拥有独立通道，Pull可同时利用请求和数据返回两个方向。在专家负载不均衡的测试中，Cursor测得NVLink利用率最高提升29%。

Sự chênh lệch đồng bộ trở nên rõ ràng hơn. Sau khi Push hoàn thành, GPU mục tiêu cần chờ tín hiệu hoàn thành từ các GPU khác; khi quy mô Expert Parallel lớn, một rank có thể liên quan đến tối đa 71 peer khác. Pull do GPU cục bộ tự khởi tạo việc đọc, ngay khi dữ liệu về là có thể sử dụng trực tiếp.

Trong các micro-benchmark đa nút của Cursor, độ trễ signaling đã giảm từ khoảng 103 microgiây của Push xuống còn 18 microgiây của Pull.

MoK cũng không sử dụng Pull ở mọi nơi. Ở chiều thuận, sử dụng Pull Dispatch và Push Combine; ở chiều ngược, sử dụng Pull Reverse-Combine và Push Reverse-Dispatch. Giai đoạn Dispatch cần tái tổ chức nhiều nguồn token thành đầu vào cho chuyên gia, Pull tiết kiệm hơn về mặt điều phối; khi Combine, đã rõ ràng kết quả nào nên trả về token nào, nên Push trực tiếp trở lại đơn giản hơn.

Sau khi thay đổi hướng truyền thông, MoK vẫn giữ truyền thông và tính toán chuyên gia trong cùng một Megakernel.

Nó chia SM của GPU thành hai phần. Một phần phụ trách phân phối, kết hợp và quản lý trạng thái, phần còn lại chuyên thực thi Expert FFN. Sau khi bên truyền thông nhận được một lô token hoàn chỉnh, nó sẽ thông báo cho bên tính toán thông qua bộ đếm cục bộ trên GPU; sau khi tính toán xong, nó sẽ thông báo lại cho bên truyền thông để gửi kết quả trở lại.

Điều này cho phép bạn trực tiếp xác định bao nhiêu SM dùng cho giao tiếp và bao nhiêu SM dùng cho tính toán, thay vì hoàn toàn để nhiều CUDA Stream tự cạnh tranh. Tham số quan trọng nhất ở đây gọi là minibatch, tức là số token được giao cho các chuyên gia tính toán trong một lần.

Nó không thể quá lớn. Quá lớn có nghĩa là các phép tính đầu tiên sẽ phải chờ rất lâu. Cũng không thể quá nhỏ. GEMM chuyên gia cuối cùng sẽ được chia thành rất nhiều nhiệm vụ tính toán để phân phối cho các SM; nếu token quá ít, số lượng nhiệm vụ sẽ không đủ, khiến nhiều SM sẽ bị lãng phí.

Cursor sử dụng wave để xác định ranh giới này. Một wave hoàn chỉnh có thể được hiểu đơn giản là tất cả các SM đều được phân công công việc. MoK mong muốn mỗi minibatch ít nhất tạo thành hai wave hoàn chỉnh để Tensor Core có đủ nhiệm vụ thực thi liên tục.

Kết quả thực tế rất rõ ràng. Trên kiến trúc Kimi 2.5 với Hidden Size là 7168 và chiều trung gian chuyên gia là 2048, Cursor ước tính minibatch cần ít nhất khoảng 2368 token. Khi là 512 token, thời gian tiến của MoK là 5,981 ms; khi tăng lên 2560 token, thời gian giảm xuống còn 3,425 ms. Khi tiếp tục tăng thêm, tốc độ không còn cải thiện đáng kể.

Nói cách khác, việc chia nhỏ giao tiếp không nhất thiết làm tăng tốc độ liên tục. Sự chồng chéo hiệu quả thực sự đòi hỏi phải truyền dữ liệu sớm, đồng thời không chia nhỏ GEMM quá mức.

Tuy nhiên, MoE còn một vấn đề khác: Trước khi Router hoàn thành, hoàn toàn không thể biết mỗi GPU cuối cùng sẽ nhận được bao nhiêu token.

Nếu chuẩn bị buffer theo trường hợp xấu nhất, sẽ lãng phí rất nhiều bộ nhớ GPU. Nếu để GPU đếm token xong mới thông báo cho CPU cấp phát không gian tương ứng, GPU lại phải dừng lại chờ CPU.

MoK sử dụng bộ đệm Ring Token có kích thước cố định. Một vùng không gian đầu tiên chứa các token được phân phối đến, sau khi chuyên gia tính toán xong và Combine truyền kết quả đi, vùng không gian này ngay lập tức được tái sử dụng cho lô token tiếp theo. Quá trình Combine của macrobatch trước có thể đồng thời diễn ra với quá trình Dispatch của macrobatch tiếp theo.

Ring Buffer ở đây giống như một lớp đệm: khi giao tiếp chạy nhanh hơn, dữ liệu sẽ tích tụ bên trong; khi tính toán tiêu thụ nhanh hơn, thì chờ đến loạt token tiếp theo. Toàn bộ quá trình được thúc đẩy bởi trạng thái trên GPU, không cần CPU tham gia vào mỗi vòng để quyết định bước tiếp theo.

Cursor còn tích hợp lượng tử hóa MXFP8 vào các đường dẫn dữ liệu của Dispatch, Grouped GEMM và SwiGLU, loại bỏ kernel lượng tử hóa độc lập và giảm một lần đọc ghi trung gian qua HBM.

Sau khi kết hợp Pull, minibatch, SM partition và Ring Buffer, MoK mới thực sự trở thành một đường ống MoE liên tục.

03

Benchmarks của Cursor đo toàn bộ lớp MoE, bao gồm Schedule, Dispatch, Expert FFN, Combine và phép hợp nhất có trọng số cuối cùng, với các đối tượng so sánh gồm NCCL + PyTorch, DeepEP, TransformerEngine và HybridEP + Megatron.

Trên GB300 NVL72, so với các cơ sở tham chiếu công khai nhanh nhất trong từng kịch bản, MoK đạt mức tăng tối đa 2,37 lần cho tiến trình MXFP8 và 1,78 lần cho lùi lại; đối với BF16, mức tăng tối đa lần lượt là 1,92 lần cho tiến trình và 1,58 lần cho lùi lại.

Quan trọng hơn là việc huấn luyện end-to-end. Giải pháp sản xuất ban đầu của Cursor đã sử dụng DeepEP. Sau khi chuyển sang MoK trên 512 GPU GB300, thông lượng trên mỗi card tăng từ 760,9 token/giây lên 1.070,2 token/giây, tăng khoảng 41%.

Cũng cần xem rõ ranh giới của kết quả này. Cursor không công bố đầy đủ các kết quả loại trừ từng phần, nên không thể xác định chính xác trong mức tăng 2,37 lần có bao nhiêu phần đến từ Pull, bao nhiêu đến từ Megakernel và bao nhiêu đến từ Ring Buffer.

Chỉ có thể xác nhận riêng biệt rằng Pull đã cải thiện việc sử dụng NVLink và độ trễ tín hiệu, các lợi ích còn lại chủ yếu đến từ kết quả tổng thể của toàn bộ phương pháp thực thi.

MoK cũng rất phụ thuộc vào phần cứng. Nó hướng đến các miền NVLink tốc độ cao như Blackwell và NVL72. Việc đọc từ xa, giao tiếp và xen kẽ tính toán tinh tế đều dựa trên khả năng truy cập bộ nhớ GPU của nhau với độ trễ thấp. Khi kích thước ẩn của mô hình, Top-k và quy mô chuyên gia thay đổi, kích thước minibatch phù hợp và số lượng SM giao tiếp cũng sẽ thay đổi theo.

Đây cũng là điểm đáng chú ý nhất của MoK. Trong quá khứ, khi thảo luận về tối ưu MoE, người ta thường chỉ tập trung vào hai con số: GEMM có bao nhiêu TFLOPS, All-to-All có bao nhiêu GB/s. Đến thế hệ GB300, việc chỉ đơn giản đẩy hai con số này lên cao hơn nữa đã không còn giải thích được toàn bộ hiệu năng.

Khi nào token đến, cách sắp xếp thành bố cục mà chuyên gia yêu cầu, bao nhiêu token tích lũy mới bắt đầu tính toán, bao nhiêu SM được sử dụng cho giao tiếp, và khi nào buffer được giải phóng—những chi tiết thực thi này trực tiếp quyết định tốc độ huấn luyện.

Một kệ có băng thông NVLink 130 TB/s, cuối cùng vẫn cần phải viết lại nhân GPU cho MoE, và lý do chính là: liên kết đã nhanh rồi, giờ cần tiết kiệm thời gian GPU chờ dữ liệu.

Hành vi ghi lại lại kernel GPU của Cursor đánh dấu sự cạnh tranh trong thời đại AI 2.0 bước vào giai đoạn mới của “chủ quyền toàn bộ hệ thống”.

Trước đây, chúng ta tin tưởng vào “chuyên môn hóa”, làm ứng dụng thì chỉ nên làm ứng dụng (Cursor), làm nền tảng thì chỉ nên làm nền tảng (NVIDIA). Nhưng cuộc cạnh tranh AI hiện nay đã bước vào giai đoạn mới “loại bỏ trung gian”, Cursor không làm kernel vì “muốn làm”, mà vì “bắt buộc phải làm”.

DeepSeek đã mở ra một kỷ nguyên mới của việc khai thác kỹ thuật, trong khi Cursor đã kéo ngọn lửa này đến tầng ứng dụng. Xu hướng “loại bỏ trung gian” này đang tái định hình quyền định giá của AI: trong tương lai, điều quyết định định giá của các công ty AI sẽ không còn là họ sở hữu bao nhiêu token, mà là mã nguồn của họ gần đến bộ nhớ hiển thị và thanh ghi đến mức nào.

Những công ty AI không thể xuyên thấu được hộp đen nền tảng sẽ cuối cùng bị kẹt trong vũng bùn của "mức thuế trung bình".