NVIDIA AIPerf ile LLM Performansındaki Ölümcül Kör Noktalar Nasıl Ortaya Çıkarılır?

Geliştiriciler, yapay zekâ tabanlı uygulamaları test ederken genellikle tek kullanıcı odaklı basit benchmark’larla yetinirler. Ancak gerçek kullanıcı trafiği altında sistemin ne kadar kırılgan olduğunu gösteren tek bir araç var: NVIDIA AIPerf. Bu performans ölçüm aracı, özellikle büyük dil modelleri (LLM) için tasarlanmış olup, standart testlerin gözden kaçırdığı performans tuzaklarını ortaya çıkarabilir.

Bu makalede, yerel bir model üzerinde yapılan üç farklı test senaryosu üzerinden, LLM dağıtımlarında neleri yanlış ölçtüğümüz ve bu hataların nasıl telafisi mümkün olduğunu inceleyeceğiz. Hazırsanız, performans mühendislerinin mutlaka görmesi gereken bu hikayeye dalalım.

Test Ortamının Temelleri: Basit Gözlemlerin Tehlikesi

Deneyim için seçilen model, granite4:350m olarak adlandırılan hafif bir LLM olup, yerel makinelerde veya MacBook’larda kolayca çalıştırılabiliyor. Bu modeli, yerel bir sunucu üzerinde ` adresinden erişilebilir hale getirdik. Performans ölçümlerinde ise NVIDIA’nın resmi olarak desteklediği AIPerf aracını kullandık.

AIPerf’in kurulumu son derece basit:

pip install aiperf

Bu araç, sadece bir komutla çalıştırılabiliyor ve hem tek kullanıcı hem de çoklu kullanıcı senaryolarını destekliyor. Özellikle, yerel testlerde bile gerçekçi trafik koşullarını simüle etmek için ideal bir çözüm sunuyor.

Birinci Test: Yanlış Güven Veren Tek Kullanıcı Ölçümü

İlk test, çoğu geliştiricinin yaptığı yaygın hatayı simüle ediyordu: tek kullanıcı senaryosu. Bu yaklaşımda, sadece bir kullanıcıdan gelen tek bir istek üzerinden performans ölçümü yapılıyor. Komut aşağıdaki gibiydi:

aiperf profile \
  --model "granite4:350m" \
  --streaming \
  --endpoint-type chat \
  --url  \
  --tokenizer builtin \
  --request-count 50 \
  --concurrency 1

Bu testin sonuçları oldukça umut verici görünüyordu:

• Ortalama TTFT (Time to First Token): 223.11 ms
• Ortalama ITL (Inter-Token Latency): 10.67 ms
• Ortalama istek gecikmesi: 1,309.30 ms
• İstek işleme hızı: 0.76 istek/saniye

Bu veriler ışığında, sistemin üretime hazır olduğunu düşünmek oldukça doğal. Ancak gerçek şu ki, bu ölçümler sadece yalnızca bir kullanıcının sistemle etkileşime girdiği durumda geçerli. Peki ya yüzlerce kullanıcı aynı anda sisteme erişmeye çalışırsa?

İkinci Test: Gerçekçi Yük Altında Patlayan Performans Sorunları

İkinci test, sistemi gerçekçi bir yük altında incelemek için tasarlandı. Bu kez 50 kullanıcıdan oluşan bir senaryo simüle edildi. Ayrıca, soğuk başlangıç etkilerini ortadan kaldırmak için 10 istek ısınma amaçlı gönderildi ve ölçümler 60 saniye boyunca devam etti. Komut şu şekildeydi:

aiperf profile \
  --model "granite4:350m" \
  --url  \
  --endpoint-type chat \
  --concurrency 50 \
  --tokenizer builtin \
  --warmup-request-count 10 \
  --benchmark-duration 60 \
  --streaming

Sonuçlar ise tam bir şok etkisi yarattı:

• Ortalama TTFT: 41,660.92 ms (önceki 223 ms’den 186 kat artış!)
• Ortalama ITL: 10.38 ms (neredeyse hiç değişmedi)
• Kullanıcı başına çıktı token hızı: 4.86 token/saniye
• İstek işleme hızı: 0.88 istek/saniye

En çarpıcı olanı, p99 seviyesinde kullanıcıların ilk token’ı görmek için 64 saniyeden fazla beklemek zorunda kalmalarıydı. Bu durumda, sisteminizin performans paneli yeşil gözükse bile, gerçek kullanıcılar boş bir ekranla karşı karşıya kalıyor olabilir.

Üçüncü Test: İyi Hisseden Performansın Gerçek Yüzü: Goodput

AIPerf’in en güçlü yanı, goodput adı verilen bir metriği ölçebilmesidir. Goodput, belirlenen bir Hizmet Seviyesi Anlaşması (SLA) çerçevesinde başarılı olan isteklerin oranını gösterir. Üçüncü testte, TTFT için 500 ms’lik bir SLA belirleyerek ölçüm yaptık:

aiperf profile \
  --model "granite4:350m" \
  --url  \
  --endpoint-type chat \
  --concurrency 50 \
  --tokenizer builtin \
  --benchmark-duration 60 \
  --goodput 'time_to_first_token:500' \
  --streaming

Sonuçlar, sistemin gerçek performansını ortaya çıkardı:

• Toplam istek işleme hızı: 0.91 istek/saniye (normalde iyi görünüyor)
• Goodput (SLA’ya uygun istekler): 0.01 istek/saniye

Bu, yaklaşık %99 oranında isteklerin 500 ms’lik SLA’yı karşılayamadığı anlamına geliyor. Sistem istekleri işliyor olabilir, ancak kullanıcılara hizmet veremiyor.

Gizlenen Gerçek: Model İyi, Sıra Sistemi Zayıf

Bu testlerin en önemli bulgularından biri, ITL (Inter-Token Latency) metriğinin neredeyse hiç değişmemiş olmasıdır. Tüm testlerde ITL yaklaşık 10 ms civarında kaldı. Bu durum, modelin token üretme hızının son derece tutarlı olduğunu gösteriyor. Ancak TTFT (Time to First Token), kullanıcı sayısı arttıkça felaket boyutlarına ulaştı.

Bu da bize önemli bir ipucu veriyor: Sorun modelde değil, sistemdeki kuyruk yönetiminde. Model token üretmeye başladıktan sonra oldukça hızlı çalışıyor, ancak istekler, modelin işleme sürecine girmeden önce uzun süre kuyrukta beklemek zorunda kalıyor. Bu durum, kapasite planlaması yaparken yanıltıcı sonuçlara yol açıyor.

Eğer ITL de kötüleşmiş olsaydı, daha hızlı bir modele veya daha güçlü donanıma ihtiyaç duyulacaktı. Ancak yalnızca TTFT’nin patlaması, sorunun mimaride olduğunu gösteriyor. Bu durumda yapılabilecekler arasında kuyruk yönetimini iyileştirmek, istek yönlendirmesini optimize etmek veya yatay ölçeklendirme yapmak bulunuyor.

Alınacak Dersler: Ölçümünüzü Gözden Geçirin

Üç farklı test senaryosu, sadece birkaç dakika içinde sistem hakkında tamamen farklı bir bakış açısı sundu. İşte bu testlerden çıkarılan ana dersler:

• Tek kullanıcı testi: Yanlış güven verir. Sistem gerçek yük altında nasıl performans gösterir hiçbir fikir vermez.
• 50 kullanıcı testi: Gerçek TTFT davranışını ortaya çıkarır. Kullanıcıların ne kadar beklediğini gösterir.
• Goodput ölçümü: SLA’ya uyan isteklerin oranını ortaya koyar. Sistem ne kadar kullanıcıya gerçekten hizmet verebiliyor?

Bu deneyimden çıkarılan en önemli sonuç, her zaman gerçekçi kullanıcı yükü altında test yapmak ve mutlaka bir SLA belirleyerek goodput’u ölçmek gerektiğidir. Ayrıca, TTFT ve ITL’yi ayrı ayrı takip etmek, sistem performansının farklı yönlerini anlamak için kritik önem taşıyor.

Sonuç olarak, sisteminizin iyi ITL değerlerine sahip olması ancak yüksek TTFT’ye sahip olması, kuyruk yönetiminde bir problem olduğunu gösterir. Bu farkı bilmek, sorunu çözmek için atılacak adımları tamamen değiştirecektir. İyi testler!