MI355X Üzerinde Kimi K3 Çalıştırmak: B300'e Kıyasla Dolar Başına Daha Yüksek Performans
İçindekiler
Açık kaynaklı yapay zeka modelleri hızlı bir gelişim göstermekte ve performans açısından kapalı kaynaklı rakipleriyle yarışmaktadır. Ancak DeepSeek V4-Pro ve Kimi K3 gibi devasa parametreli modeller, yazılım mimarları için ciddi bellek ve altyapı maliyetleri yaratmaktadır. Kimi K3'ün 2.8 trilyon parametresi, 1 milyon tokenlik KV belleği ayrılmadan önce bile 1.5 TB üstünde VRAM talep eder. Bu miktar tek bir Nvidia B200 düğümünün (8 GPU) kapasitesini aşar ve geliştiricileri iki düğümlü B200 kümesi (TP16) veya maliyetli B300 sistemleri kullanmaya zorlar.
AMD MI355X ise GPU başına sunduğu 288 GB HBM bellek ve saatlik 2.50 dolar maliyetiyle dikkat çeker. Nvidia B300'e kıyasla yaklaşık 2.4 kat, B200'e kıyasla 1.7 kat daha ucuz olan MI355X, doğru optimizasyonlarla dolar başına performansta rakiplerini geride bırakmaktadır. 1.024 token girdi ve 400 token çıktı testlerinde MI355X düğüm başına 952 tok/s saniyeye ulaşarak B300 karşısında dolar başına 48 tok/s/$ verimlilik yakalamıştır.
Edumints platformu kapsamında, bu projeden çıkarılabilecek teknik optimizasyonlar ve yazılım mühendisliği dersleri üç ana başlıkta toplanabilir:
Nasıl Başardık? (Speculative Decode Optimizasyonu)
- Framework Hatalarını Python Seviyesinde Çözmek: Sglang sunucu mimarisinde Kimi-K3-DSpark spekülatif dekodlama modeli çalıştırılırken ROCm ortamında
top_k_renorm_probçekirdeğinin bulunmaması nedeniyleNameErrorhatası alındı. Sıfırdan özel bir C++/HIP GPU çekirdeği yazmak yerine, PyTorch'un yerelsort,masked_fillve bölme işlemlerini içeren basit bir Python fonksiyonu yazılarak framework seviyesindeki eksiklik giderildi. - Performans Kazanımları: Yapılan bu müdahale ile tekil yayın akışında (single stream) 2.2 kat, orta ölçekli yük altında akış başına 1.7 kat ve zirve toplam üretim hızında %18 performans artışı elde edildi.
Prefill (Ön Yükleme) Optimizasyonları
- İlk Token Süresinin (TTFT) Önemi: Büyük dil modellerinde kullanıcıların hissettiği gecikme büyük oranda ilk tokenın üretilme süresine bağlıdır. Uzun bağlamlı (1M token) senaryolarda prefill aşamasının yavaş kalması sistem kaynaklarının verimsiz kullanılmasına yol açar.
- Boyut Uyumsuzluklarını Dolgu (Padding) İle Geçmek: ROCm üzerinde AITER MLA prefill optimizasyonu 12 attention kafası içeren modelleri desteklemediği için sistem yavaş Triton kütüphanesine düşmekteydi. Attention kafa sayısı zero-padding tekniği ile 12'den 16'ya çıkarılıp hızlı çekirdek çalıştırıldı ve çıktıdan ilk 12 kafa dilimlenerek alındı. Bu mühendislik hamlesi cold prefill sürecini 2 ila 3 kat hızlandırarak saniyede 13 bin token seviyesine çıkardı.
Çıkarımlar ve Mühendislik Dersleri
- Bellek Kapasitesi En Kritik Unsurdur: Kimi K3 gibi devasa modellerde GPU bellek miktarı, sunucular arası iletişim ve maliyet darboğazını belirleyen temel faktördür.
- Derinlemesine Kod Analizi ve Pragmatik Çözümler: Karşılaşılan hatalarda hemen karmaşık özel GPU çekirdekleri (custom kernels) yazmak yerine, mevcut kütüphanelerin eksiklerini Python/PyTorch seviyesinde tamamlamak veya boyut uydurma yöntemlerine başvurmak zamandan kazandırır.
- AMD ve ROCm Ekosisteminin Olgunlaşması: AMD donanımlarında yaşanan yazılım sürücüsü engelleri, yazılım geliştiricilerin pragmatik optimizasyonlarıyla aşılabilmekte ve dolar başına performansta Nvidia Blackwell serisine güçlü bir alternatif oluşturmaktadır.
Orijinal makaleye buradan ulaşabilirsiniz.
Bu konuyu daha derinlemesine öğrenmek ister misin?
Edumints'teki ücretsiz kursları incele ve bugün başla.
Kurslara Göz At →