AMD MI300X Üzerinde VLLM_ROCM_USE_AITER=1 Neden Gemma 4'ü Yavaşlatıyor? Bayrağın Değiştirdikleri ve Nedenleri

Bu rehber, tek bir AMD Instinct MI300X hızlandırıcısı üzerinde vLLM için AMD'nin AITER çekirdeklerini (kernels) etkinleştirerek fp8 formatındaki Gemma 4 12B modelini sunmayı ve sunucu başlatma logları üzerinden yapılan değişiklikleri adım adım incelemeyi ele almaktadır. Süreçteki tüm loglar, raporlar ve betikler açıkça kayıt altına alınmıştır.

Ölçülen her test senaryosunda VLLM_ROCM_USE_AITER=1 bayrağı; aynı gün, aynı droplet ve aynı imajda çalıştırılan standart yapıya kıyasla Gemma 4 12B çıkarımını %0,6 ile %2,6 arasında yavaşlatmıştır. Sunucunun açılış logları (boot log) bu durumun nedenini açıkça ortaya koymaktadır:

Attention Katmanı: AITER kütüphanesinin normalde en yüksek hız artışını sağladığı attention katmanları Triton'dan ayrılmamıştır; çünkü Gemma 4'ün tam dikkat katmanları 512 genişliğinde başlıklar (512-wide heads) kullanmaktadır.
Matris Çarpımları: fp8 matris çarpımları AITER'a devredilmiştir; ancak AITER modelin altı tensör ağırlık şekli için optimize edilmiş ayarlara sahip olmadığından varsayılan (default) ayarlarla çalışmıştır.

AITER Nedir?#

AITER, AMD'nin Instinct kartları için geliştirdiği optimize edilmiş GPU çekirdeği kütüphanesidir. ROCm üzerinde vLLM başlatılırken VLLM_ROCM_USE_AITER=1 ortam değişkeni tanımlandığında devreye girer; attention, matris çarpımları ve normalizasyon katmanlarını kapsar. Matris çarpımı konfigürasyonlarını matris şekline göre özel olarak ayarlanmış tablolardan seçer.

Bu Aşamada Sahip Olmanız Gerekenler#

MI300X droplet'ına (gpu-mi300x1-192gb) ve SSH anahtarına sahip bir AMD Developer Cloud hesabı,
Proje deposunun klonu: git clone https://github.com/xbill9/gemma4-dev,
Docker'ı kuran, GPU izin gruplarını ekleyen ve vLLM imajını çeken amd-gputools içerisindeki make scaffold komutuyla hazırlanmış bir droplet.

Adım 1 — Bayrağı Sunucu Konteynerine Aktarma#

AITER, vLLM konteyneri içindeki bir ortam değişkeniyle tetiklenir. Sunucu altyapısı VLLM_DOCKER_ENV değişkenini alıp docker run -e parametrelerine dönüştürür; sweep sürücüsü ise bunu --engine-env olarak iletir:

python3 -u dtype_sweep.py --droplet $DROPLET --image $IMG --run-id 2026-10-09-aiter-mi300x \
  --size 12b --only fp8 --engine-env VLLM_ROCM_USE_AITER=1

Adım 2 — AITER ve Standart Sürümleri Art Arda Çalıştırma#

Her iki testte de xbill9/gemma-4-12B-it-qat-q4_0-fp8-text modeli; --max-model-len 32768, --gpu-memory-utilization 0.90 ve prefix caching aktif halde art arda çalıştırılmıştır. 128, 1.024 ve 8.192 token'lık promptlar ile 512 çıktı token'ı için 1, 8 ve 64 istek eşzamanlılığı test edilmiştir. Prefix cache'den veri okunmasını engellemek için her yinelemede yeni tohumlar (seed) kullanılmıştır.

Adım 3 — Bayrağın Neyi Değiştirdiğini İnceleme#

Açılış logları donanım işlemlerindeki dönüşümü gösterir:

Attention: Standart ve AITER sürümlerinin her ikisinde de TRITON_ATTN korunmuştur.
fp8 Lineer Katmanlar: Standart sürümdeki RowWiseTorchFP8ScaledMMLinearKernel, AITER etkinleştirildiğinde varsayılan ayarlardaki AITER fp8 GEMM çağrısına geçmiştir.
RMSNorm: native yerine aiter kernel'i seçilmiştir.
Ağırlıklar: Her iki yapılandırmada da 12.65 GiB bellek ayrılmıştır.

Ne Kadar Hızlı ve Pratik Çıkarımlar#

Ölçülen saniye başına token hızlarında AITER, beklenenin aksine tüm istek yüklerinde hafif bir performans gerilemesine neden olmuştur.

Geliştirici Notu ve Çıkarım: Üretim seviyesinde LLM optimizasyonu yaparken ortam bayrakları otomatik bir hızlanma garantisi sunmaz. Donanım çekirdeği mimariyle (512 başlık boyutu gibi) uyuşmadığında veya tensör şekilleri kütüphane tablolarında önceden optimize edilmediğinde (untuned GEMM), sistem varsayılan ayarlara dönerek standart uygulamadan daha yavaş çalışabilir. Bu nedenle sistem logları ve profil analizleri her zaman ampirik olarak doğrulanmalıdır.

Bu konuyu derinlemesine öğrenmek isterseniz: Ölçeklendirme ve Optimizasyon modülüne göz atın.