Cursor's MoK, NVIDIA GB300 NVL72 üzerinde %237 performans artışı sağlıyor

Cursor, MoK'ı açık kaynak hale getirerek token yönetimi, çapraz GPU iletişimini ve uzman hesaplamalarını aynı GPU çekirdeğine entegre ediyor. Bu çözüm, GB300 NVL72 üzerinde MXFP8 ileri yönlü hesaplamada en fazla 2,37 kat, geri yönlü hesaplamada 1,78 kat performans artışı sağlıyor ve 512 adet GB300 GPU ile eğitim verimliliği %41 artarak 1070,2 tokens/s seviyesine ulaşıyor. Sinyalizasyon gecikmesi 103 μs'den 18 μs'e düşüyor. Analizler, NVLink bant genişliğinin bugün 130 TB/s'ye ulaştığı dönemde, GPU'da veri bekleme süresinin yeni performans engeli olduğunu gösteriyor. Bu atılım, AI rekabetinin "tam yığın egemenliği" aşamasına girdiğini işaret ediyor; kod, GPU belleği ve kayıtlara ne kadar yakınsa, şirket o kadar fazla fiyat belirleme gücüne sahip olacak.

Yazan: LeiFeng.com

21 Temmuz'da NVIDIA, GB300 NVL72'nin DeepSeek-V3'ü eğitme sonucunu açıkladı: 256 GPU ile tek bir GPU performansı 1.648 TFLOPS'e ulaştı.

İki haftadan az bir süre sonra Cursor, MoK olarak bilinen Mixture-of-Kittens’i açık kaynak hale getirdi. Daha hızlı matris çarpımı üzerinde çalışmaya devam etmek yerine, MoE yürütme katmanını tamamen yeniden yazdı ve token yönlendirme, GPU arası iletişim ve uzman hesaplamalarını aynı GPU çekirdeğine yerleştirdi.

Bu biraz karşıt görünüyor, çünkü GB300 NVL72, 72 adet GPU'yu aynı NVLink alanına yerleştirmiş ve toplam NVLink bant genişliğini 130 TB/s'ye çıkarmıştır. Bu spesifikasyona göre, GPU'lar arasında veri transferi yeterince hızlı olmalıdır.

Büyük ölçekli MoE eğitimi sırasında iletişim hâlâ uzman hesaplamalarını yavaşlatacaktır.

Sorun MoE veri akışındadır. Router, her adımda token'ın hangi uzmana gideceğini yeniden belirler ve uzmanlar farklı GPU'larda dağıtılmıştır. Token önce kartlar arası gönderilmeli, hesaplandıktan sonra geri gönderilmelidir; göndermeden önce konum düzenlenmeli, ulaştıktan sonra verinin tamamlanmasını beklemelidir. MXFP8 ve Blackwell Tensor Core'un uzman hesaplamalarını giderek daha da kısaltmasıyla, önce hesaplama arkasında gizlenebilen bu bekleme süreleri artık giderek daha belirgin hale gelmektedir.

Cursor, MoK için buradan başlıyor. Sadece bir Dispatch'in ne kadar hızlı iletilebileceğini hedeflemiyor, token'ların uzmanlara nasıl ulaşacağını, hesaplamanın ne zaman başlayacağını ve iletişim ile hesaplamanın GPU'yu nasıl aynı anda kullanacağını yeniden düzenliyor.

Günümüzde hesaplama kaynakları Blackwell ve NVLink ile en üst seviyeye çıkarılmışken, geliştiriciler: donanım ne kadar hızlı çalışırsa çalışsın, verimsiz yazılım düzenlemesini kurtaramaz.

MoK'nin açık kaynak olması, bir çekirdek zaferi değil, "uygulama katmanının işlemciyi tanımlaması" çağının başlangıcını işaret ediyor: Son %30 hesaplama gücünü çıkarmak için AI girişimcileri temel egemenlik için bir mücadele başlatıyor.

Ancak Cursor'un bu tasarımının neden etkili olduğunu anlamak için önce MoE'nin nerede "iletişim vergisi" ödediğini net bir şekilde görmelisiniz.

01

MoE'nin "İletişim Vergisi"

Normal yoğun FFN'de, token'ların geçtiği ağırlıklar genellikle sabittir. MoE'ye Router eklendikten sonra, her token geçici olarak birkaç uzmana seçilir. Expert Parallel kullanıldığında, uzmanlar birçok GPU'ya bölünür ve böylece bir ileri yayılım en az iki kez cihazlar arası iletişim gerektirir.

İlk tur Dispatch olarak adlandırılır, token uzmanların bulunduğu GPU'ya gönderilir; uzmanlar hesaplamayı tamamladıktan sonra, sonuçlar Combine aracılığıyla tokenın orijinal konumuna geri gönderilir. Eğitim, geriye doğru iki tur iletişim gerçekleştiren geri yayılımı da içerir.

Sadece büyük bir sürekli veri bloğunu A'dan B'ye taşımak gerekiyorsa, NVLink yeterince hızlıdır. MoE'nin zorluğu, Router'ın her adımda farklı bir veri dağılımı vermesidir.

Bir uzmanın bu adımda birçok token alırken bir sonraki adımda çok az alması mümkündür. Sistem, her uzmanın kaç tokena sahip olduğunu önceden saymalı ve bu tokenların hedef GPU’da nereye yerleştirileceğini belirlemelidir. Aynı uzmanın verileri mümkün olduğunca bir arada olmalıdır. Grouped GEMM, düzenli bir giriş almak ve Tensor Core’a verimli bir şekilde veri sağlayabilmek için gereklidir.

İletişim bittikten hemen sonra hesaplama başlatılamaz. Hedef GPU, uzaktan yazmanın tamamlandığını ve verilerin gerçekten görünür olduğunu doğrulamalıdır. Uzman yükü tamamen eşit olmadığından, bazı GPU’lar erken bitse bile, en yoğun uzmana kadar beklenmelidir.

Böylece bir “iletişim” aşamasında, veri taşıma, düzen oluşturma, senkronizasyon ve yük dengesizliği gibi birkaç şey karışık halde bulunur. 130 TB/s, tüm rafın sağlayabileceği tepe bant genişliğini ifade eder, ancak her dinamik ve parçalı MoE iletişiminde bu bağlantıların hepsinin aynı anda tamamen dolu olduğunu göstermez.

DeepEP, veri taşımayı çok hızlı bir şekilde gerçekleştirmiştir. Kendisi, özel Dispatch ve Combine çekirdekleri sunan, FP8'i destekleyen ve iletişim için kullanılan SM sayısını kontrol etmeye izin veren Expert Parallel için tasarlanmış yüksek performanslı bir iletişim kütüphanesidir. En son sürüm, çok daha az SM kullanarak bile yüksek iletişim verimliliğini koruyabilmektedir.

Bir katman MoE, Dispatch, Grouped GEMM ve Combine arasında sürekli olarak elden ele geçmelidir.

Bu durumda oldukça pratik bir çelişkiyle karşılaşırsınız: Yeterli sayıda token birikmesini bekleyip hesaplamayı yaparsanız, matris büyük olur ve Tensor Core'lar verimli çalışır, ancak hesaplama geç başlar; token'lar geldikçe hemen hesaplama yaparsanız, iletişim ve hesaplama daha erken örtüşür, ancak matris çok küçük olur ve GPU'nun birçok SM'si yeterli işe sahip olmaz.

Birden fazla CUDA akışı, iletişim ve hesaplamayı paralel hale getirebilir, ancak her iki tarafın da tam olarak uygun GPU kaynaklarına sahip olmasının garantisi zordur.

MoK'nın ardından gelen tasarım, temel olarak bu "ritim" sorunuyla ilgileniyor.

02

MoK'un en ilginç değişikliklerinden biri, ön yönlendirme işlemini Push'tan Pull'a değiştirmektir.

Geleneksel Push oldukça doğrudur: Kaynak GPU'nun elinde token varsa, bunu hedef GPU'ya aktif olarak yazar. Sorun, hedef adresinde ortaya çıkar. Bir GPU, aynı anda birçok diğer GPU'dan gelen tokenları alır.

Her gönderici, hangi bölüme yazması gerektiğini önceden bilmelidir; birbirini覆盖 etmemelidir. Aynı uzmanın token'ları ayrıca ardışık şekilde sıralanmalıdır, aksi takdirde sonraki GEMM yeniden düzenlenmek zorunda kalacaktır.

Katılım eden GPU sayısı arttıkça bu işlem planlama süreci giderek daha ağırlaşır. Pull, farklı bir yöntem kullanır: uzmanların hedef GPU'su, ihtiyaç duyulan tokenları kendi kendine okur. Sadece tokenın hangi kaynak GPU'da ve kaynak veride nerede olduğunu bilmesi yeterlidir; yerel depolama konumunu kendi belirler.

Bu, hedef adres için birden fazla gönderen arasında koordinasyon yapmayı ortadan kaldırıyor. Alınan veriler doğrudan yerel uzmanlar tarafından sıralanabilir.

İlginç olan, Pull'un veri göndermeden azalmadığıdır. Cursor'un mikro-benchmark'ında, aynı 256×256 BF16 veri bloğu için Push, NVLink üzerinde yaklaşık 159,6 KB hareket ettirirken, Pull 172,0 KB'a ulaşır, çünkü okuma için ek istekler gönderilmelidir.

Pull, başka bir noktada avantajlıdır: MoE iletişimleri parçalı ve yük dengesizdir. NVLink'in iki yönü ayrı kanallara sahiptir ve Pull, istek ve veri geri dönüşü yönlerini aynı anda kullanabilir. Uzman yük dengesizliği testlerinde, Cursor en yüksek %29'luk bir NVLink kullanım artışı tespit etti.

Senkronizasyon farkı daha belirgin hale geliyor. Push tamamlandıktan sonra, hedef GPU diğer GPU'ların tamamlama sinyallerini beklemek zorunda kalır; Expert Parallel ölçeği büyük olduğunda, bir rank en fazla 71 başka peer ile ilişkili olabilir. Pull, yerel GPU'nun kendi kendine okuma başlatmasıdır; veriler geldikten sonra hemen kullanılabilir.

Cursor'un çok düğümlü mikro-benchmark'inde, bu sinyalleştirme gecikmesi, Push'taki yaklaşık 103 mikrosaniyeden Pull'daki 18 mikrosaniyeye düştü.

MoK, tüm yerlerde Pull kullanmaz. İleri yönde Pull Dispatch ve Push Combine kullanılır; geri yönde ise Pull Reverse-Combine ve Push Reverse-Dispatch kullanılır. Dispatch aşamasında birçok kaynaktan gelen token’lar uzman girdilerine yeniden düzenlenmelidir; Pull, koordinasyonu daha az gerektirir. Combine aşamasında her sonuç hangi token’a geri dönecek açıkça bellidir, bu nedenle doğrudan Push yapmak daha basittir.

İletişim yönü değiştirildikten sonra, MoK hala iletişimi ve uzman hesaplamalarını aynı Megakernel'de birleştirdi.

GPU'nun SM'sini iki parçaya ayırır. Bir kısmı Dispatch, Combine ve durum yönetimi için sorumludur, diğer kısmı ise Expert FFN'yi özel olarak yürütür. İletişim tarafı, tam bir token grubunu aldıktan sonra GPU yerel sayaçları aracılığıyla hesaplama tarafını bilgilendirir; hesaplama tamamlandığında, sonuçların geri iletilmesi için iletişim tarafını tekrar bilgilendirir.

Bu sayede iletişim için kaç SM kullanılacağı ve hesaplama için kaç SM kullanılacağı doğrudan belirlenebilir; birden fazla CUDA akışının kendi aralarında rekabet etmesine gerek kalmaz. Buradaki en kritik parametre, minibatch'tir, yani her seferinde uzmana kaç token verileceği.

Çok büyük olmamalı. Çok büyük olmak, ilk hesaplamaların uzun süre beklemesi anlamına gelir. Çok küçük de olmamalı. Uzman GEMM, nihayetinde birçok hesaplama görevini SM'lere dağıtmak için parçalanır; eğer token sayısı çok azsa, görev sayısı yeterli olmaz ve birçok SM boş kalır.

Cursor, bu sınırı bir dalgayla belirler. Tam bir dalga, tüm SM'lerin iş aldığını basitçe anlamına gelir. MoK, bir minibatch'in en az iki tam dalga oluşturmasını ister ki Tensor Core yeterli sayıda görevle sürekli çalışabilsin.

Gerçek sonuçlar çok açıklayıcıdır. Kimi 2.5 yapısında gizli boyut 7168 ve uzman orta boyut 2048 olduğunda, Cursor, minibatch için en az yaklaşık 2368 token gerektiğini tahmin eder. 512 token ile MoK ileri geçiş süresi 5,981 ms; 2560 tokene çıkarıldığında 3,425 ms'ye düşer. Daha da artırıldığında hızda belirgin bir iyileşme gözlenmez.

Yani, iletişimi daha küçük parçalara bölmek her zaman daha hızlı yapmaz. Gerçekten verimli bir üst üste binme, iletişimin verileri erken teslim etmesini ancak GEMM’i çok küçük kesmemesini gerektirir.

Ancak MoE'nin bir başka sorunu da: Router tamamlanana kadar, her GPU'nun sonunda kaç token alacağı bilinmiyor.

En kötü senaryo için buffer hazırlamak, çok fazla GPU belleği harcayacaktır. GPU'nun önce token'ları sayıp ardından CPU'ya karşılık gelen alanı tahsis etmesini sağlamak, GPU'nun CPU'yu beklemesi gerektiği anlamına gelir.

MoK, sabit boyutlu bir Ring Token Buffer kullanır. Bir alan, önce gelen tokenları alır; uzmanlar işlemi tamamladıktan ve Combine sonuçları gönderdikten sonra, bu alan hemen bir sonraki token grubu için yeniden kullanılır. Bir önceki macrobatch'in Combine işlemi, bir sonraki macrobatch'in Dispatch işlemiyle aynı anda gerçekleştirilebilir.

Ring Buffer burada bir tampon katmanı gibi davranır: iletişim geçici olarak daha hızlı ilerlerse, veri orada birikir; hesaplama daha hızlı tüketirse, bir sonraki token'ın gelmesini bekler. Tüm süreç, GPU üzerindeki durumla ilerler ve CPU'nun her adımda bir sonraki adımı belirlemesine gerek yoktur.

Cursor, MXFP8 etkinleştirmesini Dispatch, Gruplanmış GEMM ve SwiGLU veri yollarına da dahil etti, bağımsız quantize çekirdeğini kaldırdı ve HBM'de ara sonuçların tekrar tekrar okunup yazılmasını azalttı.

Pull, minibatch, SM bölgeleri ve Ring Buffer bir araya getirildiğinde, MoK gerçekten sürekli bir MoE akış hattına dönüşür.

03

Cursor'un benchmark'u, Schedule, Dispatch, Expert FFN, Combine ve son ağırlıklı birleştirme dahil olmak üzere tam MoE katmanını ölçer; karşılaştırma nesneleri NCCL + PyTorch, DeepEP, TransformerEngine ve HybridEP + Megatron'dur.

GB300 NVL72 üzerinde, MoK, MXFP8 ile her senaryoda en hızlı açık temel karşılaştırıldığında ileri yönde maksimum 2,37 kat, geri yönde maksimum 1,78 kat artış sağlıyor; BF16 ile ileri ve geri yönde maksimum sırasıyla 1,92 kat ve 1,58 kat artış sağlıyor.

Daha önemlisi, uçtan uca eğitim. Cursor'un orijinal üretim çözümü zaten DeepEP'yi kullanıyordu. 512 adet GB300 GPU üzerinde MoK'e geçildiğinde, tek bir GPU'nun işlem kapasitesi saniyede 760,9 token'den 1070,2 token'a yükseldi ve yaklaşık %41 artış sağlandı.

Bu sonuçlar da sınırları dikkatle gözlemlemelidir. Cursor, ayrıntılı ablasyonları açıkça paylaşmadığından, 2,37 katlık artışın ne kadarının Pull, ne kadarının Megakernel ve ne kadarının Ring Buffer'dan kaynaklandığını kesin olarak belirleyemeyiz.

Pull'un NVLink kullanımını ve sinyal gecikmesini iyileştirdiği tekil olarak doğrulanabilir; diğer kazanımlar ise tam yürütme yöntemi kombinasyonundan kaynaklanmaktadır.

MoK, donanıma da büyük ölçüde bağımlıdır. Blackwell ve NVL72 gibi yüksek hızda NVLink alanlarına yöneliktir. Uzak okumalar, iletişim ve hesaplama arasındaki ince düzeydeki karışım, GPU’lar arasında düşük gecikmeli bellek erişimi olabilmesi üzerine kuruludur. Modelin gizli boyutu, Top-k ve uzman ölçeği değiştiğinde, uygun minibatch ve iletişim SM sayısı da değişir.

Bu, MoK'nin en dikkat çekici yönüdür. Geçmişte MoE optimizasyonu tartışılırken, kolayca iki sayıya odaklanılırdı: GEMM'nin TFLOPS'ı, All-to-All'ın GB/s'ı. GB300 neslinde, bu iki sayıyı yalnızca artırmak, tüm performansı açıklayamaz.

Token ne zaman ulaşacak, uzmanların gerektirdiği düzenlemeye nasıl yerleştirilecek, ne kadar biriktiğinde hesaplama başlayacak, iletişimde kaç SM alınacak, buffer ne zaman serbest bırakılacak — bu yürütme detayları doğrudan eğitim hızını belirlemeye başlıyor.

130 TB/s NVLink bant genişliğine sahip bir raf, nihayetinde MoE için GPU çekirdeklerini yeniden yazmak zorunda kalır; çünkü bağlantılar zaten çok hızlı, şimdi tasarruf edilmesi gereken, GPU'nun verileri beklemesi zamanıdır.

Cursor, GPU çekirdeklerini yeniden yazarak AI 2.0 çağının rekabetini "tam yığın egemenliği" yeni aşamasına taşıyor.

Daha önce, "her meslek kendi alanında uzmanlaşır" inancına inanıyorduk; uygulama yapmak uygulamaydı (Cursor), temel katman yapmak temel katmandı (NVIDIA). Ancak günümüzdeki AI rekabeti, "aracıları ortadan kaldırma" aşamasına ulaşmıştır; Cursor, "yapmak istemeden" değil, "yapmak zorunda kalınca" çekirdeği yapmıştır.

DeepSeek, mühendislik verimliliğinin yeni bir çağını başlattı ve Cursor bu ateşi uygulama katmanına taşıdı. Bu “araacı kaldırma” eğilimi, AI'nın fiyat belirleme gücünü yeniden şekillendiriyor: Gelecekte, AI şirketlerinin değerlemesini belirleyen, ne kadar Token'e sahip oldukları değil, kodlarının bellek ve kaydedicilere ne kadar yakın olduğu olacak.

Alt katmanın kara kutusunu geçemeyen AI şirketleri, "ortalama vergi" çamurunda kalacaktır.