Bu, AMD'nin uzun süredir beklediği an olabilir.
Son zamanlarda Wafer AI, AMD MI355X üzerinde dağıtıldı Kimi K3. Sonuç olarak, orijinal olarak 16 adet NVIDIA B200 ile iki sunucuda çalıştırılması gereken model, 8 adet MI355X ile donatılmış bir AMD sunucusunda dağıtılabilir hale geldi.
Daha da önemlisi, sadece modeli yerleştirmekle kalmadı.
1024 Token girdi ve 400 Token çıktı testinde, MI355X toplam verimlilik olarak 952 Token/s ve tek kullanıcı başına 118 Token/s üretme hızı elde etti.
Tek bir düğüm üzerinden hesaplandığında, veri işlem kapasitesi yaklaşık olarak 16 adet B200 çözümünün 3,8 katıdır ve maliyet-verimlilik oranı B200 ve B300'ü aşar.
Ancak en şaşırtıcı olan, ROCm'nin bu sefer özellikle karıştırmaması.
Model çok büyük, video belleği artık hesaplama gücünden daha önemli hale geldi
Kimi K3, 2,8 trilyon parametreye sahiptir ve model ağırlıkları yalnızca 1,5 TB'dan fazla GPU belleği gerektirir; bu, milyonlarca Token bağlamı için gerekli KV Cache'i içermez.
Her biri 192 GB GPU belleğine sahip 8 kartlı bir B200 sunucusu, toplam yaklaşık 1,5 TB bellek kapasitesine sahiptir. Yani, model ağırlıkları bile tamamen yerleştirilemez, KV Cache için yer bırakmak ise daha da zordur. Bu nedenle B200, iki sunucu ve 16 GPU kullanmak zorundadır.
B300, her bir kartta 288 GB GPU belleğe sahip olup, modeli tek bir düğümde barındırabilir. İlginç bir şekilde, AMD MI355X de aynı 288 GB GPU belleğe sahiptir; 8 adet MI355X toplamda yaklaşık 2,3 TB bellek sağlar ve bunun için sadece bir sunucu yeterlidir.
Bu sadece bir makinenin az kullanılması değil. Model düğümler arasında çalıştırıldığında, her bir Token üretimi için ağ üzerinden veri senkronizasyonu gerekebilir. Yaklaşık 195 Gb/s RoCE v2 ağı kullanılsa bile, düğümler arası iletişim hala dekodlamayı yavaşlatır.
MI355X, daha büyük bir bellek sayesinde tüm modeli tek bir düğümde tutuyor.
Sonuçlara göre, 8 adet MI355X'in peak toplam verimliliği 952 Token/s, tek yoldaki üretimi 118 Token/s oldu.
Karşılaştırmada, 16 adet B200'un çift düğüm dağılımının toplam verimliliği 498 Token/s'tir ve tek düğüme çevrildiğinde yaklaşık 249 Token/s olur.
Yani, MI355X'in tek düğüm verimliliği, B200'un çift düğüm dağıtımının ortalama tek düğüm verimliliğinin yaklaşık 3,8 katıdır. Tek kullanıcı üretimi hızı açısından, MI355X'in 118 Token/s hızı, B200'un 90 Token/s hızından yüksektir.
B300, hâlâ en yüksek performansa sahip çözüm. 8 adet B300 içeren bir düğümün toplam veri throughput'u 1568 Token/s'ye ulaşır, tek yol üretimi 172 Token/s hızındadır ve toplam veri throughput'u MI355X'in yaklaşık 1,65 katıdır.
Ancak fiyat değiştiğinde sonuç değişir. Wafer, MI355X için saat başına 2,5 dolar, B200 için 4,25 dolar ve B300 için 6 dolar olarak hesaplanır.
Bu fiyat varsayımına göre, MI355X yaklaşık 48 Token/s peak verimlilik sağlıyor; B200 yaklaşık 7 Token/s; B300 yaklaşık 33 Token/s.
B300 daha hızlıdır, ancak MI355X'in birim maliyet verimliliği daha yüksektir. Büyük ölçekli açık modelleri çalıştırmayı gerektiren veri merkezleri için bu, yalnızca performans şampiyonluğunu kazanmaktan daha önemli olabilir.
Daha da şaşırtıcı olan, ROCm'nin neredeyse doğrudan kullanılabilmesi.
Uzun zamandır AMD'nin veri merkezi GPU'larının en büyük sorunu genellikle donanım değil, yazılımdı.
Aynı model CUDA üzerinde doğrudan çalışabilir, ancak ROCm üzerinde çerçeve değiştirilmeli, işlemci eklenmeli veya hatta alt seviye çekirdekler yeniden yazılmalıdır.
ama Kimi K3 durumu farklıdır.
AMD, başlangıçla senkronize destek sağlamıştır. Wafer, modelin temel olarak doğrudan MI355X üzerinde çalışabileceğini belirtti ve sonraki çalışmalar, az sayıda uyumluluk sorunu ve performans optimizasyonuna odaklanacaktır.
Tahmini çözme aşamasında bir sorun ortaya çıktı. Kimi K3, MTP veya EAGLE için gerekli taslak model parametrelerini sağlamadığından, Wafer bir dış blok yayılma taslak modeli kullandı.
Bu senaryo CUDA üzerinde doğrudan çalışır, ancak ROCm ortamında ilk gerçek istek, scheduler'da hata yapar. Nedeni, ROCm dalında top_k_renorm_prob adlı bir fonksiyonun eksik tanımlanmasıdır.
Bu işlevin yaptığı şey karmaşık değil: Olasılık dağılımından en yüksek k değeri seçilir, diğer olasılıklar sıfırlanır ve korunan olasılıklar yeniden normalleştirilir.
Wafer, bu mantığı tamamlamak için sıradan bir PyTorch işlevini kullandı, GPU çekirdeği yazmaya veya tahmini dekodlama sistemini yeniden tasarlamaya gerek kalmadı.
Düzeltildikten sonra, tahmini çözümlenme tek yol performansını yaklaşık 2,2 kat, orta düzeyde paralellik altında tek akış performansını yaklaşık 1,7 kat artırırken, tepe toplam verimlilik yaklaşık %18 arttı.
Daha önemlisi, sistem daha yüksek eşzamanlılık altında zirve verimliliğine ulaşabiliyor.
İlk harf çok yavaş, sonunda sadece dört sıfır eklendi
Elbette, verimlilik sadece çıkarım hizmetlerinin tamamını değil. Gerçek kullanıcılar için deneyimi doğrudan etkileyen başka bir göstergede, istek gönderildiğinden ilk Token'in görülmeye başlanmasına kadar geçen süredir, yani TTFT.
Bu işlemde MI355X başlangıçta iyi performans göstermedi. Yaklaşık 172.000 Token'lık bir başlangıç ön-doldurma göreviyle MI355X yaklaşık 51 saniye, B300 ise yalnızca yaklaşık 23 saniye aldı.
Milyonlarca token bağlamını destekleyen modellerde, ön doldurma görevleri çok büyük olabilir. Uzun bağlam işlenirken kullanıcı her seferinde onlarca saniye veya daha uzun bir süre beklemek zorunda kalırsa, ne kadar yüksek bir dekodlama hızı olsun, deneyimdeki sorunları telafi etmek zor olur.
Wafer, performans farkının neredeyse tamamının bir dikkat çekirdeğinden kaynaklandığını keşfetti. Kimi K3, 8 yollu tensör paralel yapılandırmada her GPU'ya 12 dikkat kafası düşer. AMD AITER'deki daha hızlı MLA ön doldurma çekirdekleri ise yalnızca 4, 8 veya 16'nın katları şeklindeki boyutları destekler.
12 baş eşleşmediğinden sistem, daha yavaş genel Triton uygulamasına geri döndü.
Çözüm oldukça basittir: 12 dikkat başlığını sıfırlarla 16'ya tamamlayın, mevcut hızlı çekirdeği çağırın, hesaplama tamamlandığında gerçek olarak ihtiyaç duyulan 12 başlığı geri alın. Model yapısı değiştirilmedi, yeni bir derleme çekirdeği yazılmadı, sadece dört sıfır eklendi.
Optimize edildikten sonra AITER MLA çekirdeğinin kararlı ön doldurma hızı yaklaşık 13.000 token/s seviyesine ulaştı, eski Triton geri dönüş yolu ise yaklaşık 4.000–7.000 token/s idi; bu nedenle soğuk ön doldurma süresi yaklaşık iki ila üç kat kısaltıldı.
Bu optimizasyon, nihai çözme verimliliğini değiştirmeyecek, ancak kullanıcıların ilk karakteri görmesi için beklemelerini önemli ölçüde azaltacaktır.
Bu, AMD ile NVIDIA arasında görünen büyük yazılım farkının bazen temel kapasite eksikliği değil, mevcut yüksek hızlı çekirdeklerin bazı yeni model şekillerini henüz kapsamaması anlamına gelir.
CUDA'nın koruma duvarı hâlâ var, ancak boşluklar ortaya çıkmıştır.
Bir test, AMD'nin NVIDIA'ya tamamen yetiştiğini kanıtlamaz.
B200, bellek yetersizliği nedeniyle düğüm arası çalıştırılmak zorunda bırakıldı; B300'ün mutlak performansı hâlâ önde; ROCm'nin araç zinciri, çerçeveler desteği ve geliştirici ekosistemi hâlâ CUDA'dan geride.
Ancak açık modeller hızla trilyon parametre dönemine giriyor. Bir sunucuda yerleştirilemeyecek kadar büyük hale gelen modellerde, GPU belleği kapasitesi sadece bir parametre tablosundaki bir sayı değil, iletişim maliyetini, dağıtım karmaşıklığını ve nihai verimliliği doğrudan etkileyecektir.
AMD'nin tek bir karta daha fazla HBM sağlamaya yönelik stratejisi, gerçek bir sistem avantajı haline gelmektedir.
AMD, ROCm'nin kararlılığını artırmaya, yüksek hızlı çekirdekler için daha geniş bir şekil desteği sağlamaya ve yeni modeller için daha hızlı ilk gün uyum sağlamaya devam ederse, veri merkezleri bu GPU'ları ciddi şekilde değerlendirmelidir. Daha düşük fiyat, daha büyük bellek, yeterli performans ve aylarca uğraşmaya gerek olmayan yazılım.
Buna ne dersiniz?
Referans bağlantısı:
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
Bu yazı, WeChat hesabından "Makine Kalbi" (ID: almosthuman2014) tarafından paylaşılmıştır, yazar: LLM'ye dikkat eden