Bu yazı, büyük dil modellerinin (LLM) gecikme ve verimlilik benchmarking serisinin üçüncü bölümüdür. Amaç, geliştiricilere LLM çıkarımının maliyetini belirlemeleri için toplam sahiplik maliyetini (TCO) tahmin etme yöntemlerini öğretmektir.
LLM Inference Benchmarking: Temel Kavramlar‘da, benchmarking ve parametrelerle ilgili temel bilgileri bulabilirsiniz. Ayrıca, LLM Inference Benchmarking Rehberi: NVIDIA GenAI-Perf ve NIM‘de, kendi uygulamalarınız için GenAI-Perf ve NVIDIA NIM’i nasıl kullanabileceğinize dair ipuçları bulunmaktadır.
Giriş
Büyük dil modelleri (LLM’ler), modern yazılım endüstrisinin ayrılmaz bir parçası haline geldi ve birçok uygulamanın inşa edildiği bir “işletim sistemi” temel katmanı gibi işlev görüyor. Bu uygulamalar, AI asistanları, müşteri destek ajansları, kodlama yardımcıları ve “derin araştırma” asistanlarını içermektedir.
Son zamanlarda algoritmaların ve model verimliliğinin geliştirilmesi, eğitim ve çıkarım maliyetlerini azaltmıştır. Bu, DeepSeek R1 model ailesi ile gösterilmiştir. Gelişmiş verimlilik ile LLM uygulamalarının daha uygun maliyetli ve yaygın olması beklenmektedir, bu da daha fazla hesaplama kaynağı tüketmelerine neden olacaktır (buna Jevonsparadoksu denir).
Bu çıkarım uygulamaları için gereken altyapıyı tahmin etmek ve toplam sahiplik maliyeti (TCO) hesaplaması yapmak, işletmelerin üretken AI sistemlerini ölçeklendirme hazırlığı kapsamında karşılaştıkları bir problemdir. Bu yazıda, bu problemin detaylı rehberliğini ve adım adım analizini sunacağız.
Bu blog yazısının geri kalanında, şu adımları takip edeceğiz:
- Performans benchmarking tamamlamak. Bu, altyapı boyutlandırması için gereken verilerin üretilmesini sağlar.
- Benchmark verilerini analiz etmek. Performans verileri, model örneklerinin ve sunucuların sayısını tahmin etmek için kullanılabilir.
- Bir TCO hesaplayıcı oluşturmak. Bu, farklı dağıtım senaryolarını, trade-off’ları ve maliyet etkilerini keşfetmeyi kolaylaştırır.
Performans Benchmarking
Boyutlandırma ve TCO tahmini için ön koşul, her dağıtım biriminin, örneğin bir çıkarım sunucusunun, performansının benchmark edilmesidir. Bu adımın amacı, bir sistemin yük altında ne kadar verim üretebileceğini ve hangi gecikme süresiyle çalıştığını ölçmektir. Bu throughput ve latency metrikleri, kaliteli hizmet seviyelerinin yanı sıra (örneğin, maksimum gecikme) ve beklenen yüksek talep (örneğin, maksimum eşzamanlı kullanıcı veya her saniye başına istek sayısı) ile birlikte, gerekli donanımın tahmin edilmesine yardımcı olacaktır; böylece dağıtım boyutlandırması yapılabilir. Bu bilgilere sahip olmak ise verilen çözümün toplam maliyetinin (TCO) tahmin edilmesi için gereklidir.
NVIDIA GenAI-Perf, bir istemci tarafı LLM odaklı benchmarking aracıdır ve ilk token süresi (TTFT), token arasındaki gecikme (ITL), saniye başına token sayısı (TPS), saniye başına istek sayısı (RPS) gibi önemli metrikleri sağlar. Bu metriklerin nasıl ölçüldüğüne dair temek bir açıklama için önceki yazımıza göz atabilirsiniz.
LLM’ler, NVIDIA NIM mikro hizmetleri ile dağıtıldığında, performansın kolayca ölçülmesini sağlamak için adım adım rehberimiz bulunmaktadır. Ancak, GenAI-Perf, vLLM veya SGLang gibi diğer OpenAI uyumlu API’leri destekleyen çok yönlü bir araçtır. GenAI-Perf, aynı zamanda NVIDIA Dynamo, NVIDIA Triton çıkarım sunucusu ve NVIDIA TensorRT-LLM arka ucu ile dağıtılan LLM’leri de destekler.
Benchmark Verilerini Analiz Etme
Ham benchmark verileri toplandıktan sonra, bunlar sistemin çeşitli performans özellikleri hakkında içgörü sağlamak için analiz edilir. NIM performans verilerini GenAI-Perf ile toplayarak ve basit bir Python betiği kullanarak verileri analiz etme yöntemini içeren LLM çıkarım benchmarking rehberimizi okuyabilirsiniz.
Örneğin, GenAI-Perf tarafından sağlanan performans verileri, gecikme-verimlilik tablosunu oluşturmak için kullanılabilir.
Grafikteki her nokta, benchmarking süreci boyunca sisteme aynı anda yerleştirilen eşzamanlı istek sayısını temsil eder. X ekseni, millisecond (ms) cinsinden TTFT gecikmesini gösterirken; Y ekseni, her saniye başına istek sayısı (req/s) cinsinden verimliliği temsil eder. GenAI-Perf verileriyle benzer grafikler, TTFT, ITL veya toplam isteğe yanıt süresi gibi gecikme metrikleri ile RPS veya TPS gibi verimlilik metrikleri ile de oluşturulabilir.
Genellikle aşağıdaki trade-off görünmektedir:
- Düşük eşzamanlılıkta, sistem yalnızca az sayıda eşzamanlı isteği işler. Gecikme düşük ama verimlilik de düşüktür (grafiğin sol köşesi).
- Yüksek eşzamanlılıkta, sistem, daha fazla isteği etkili bir şekilde işlemeyi sağlayan toplama etkisini kullanabilir; ancak bunun gecikme artışı gibi bir maliyeti vardır (grafiğin üst sağ köşesi).
FP4, FP8 ve BF16 gibi dağıtım formatlarını değerlendirirken, çıkarım hızı, bellek kullanımı ve doğruluk arasındaki trade-off’lar Pareto öncü üzerinde görselleştirilebilir. Bu eğri, hiçbir metrik iyileştirilmeden geliştirilemeyecek en iyi yapılandırmaları vurgulamakta ve geliştiricilerin iş yükleri için en verimli hassasiyeti seçmelerine yardımcı olmaktadır.
Pareto öncüsü, belirli bir gecikme seviyesinde (örn. ilk token süresi) en yüksek verimliliği (örn. saniye başına istek) sağlayan dağıtım yapılandırmalarını içerir. Bir dağıtım seçeneği, aynı veya daha düşük gecikme süresinde, daha yüksek verimliliği sağlayan başka bir seçenek yoksa Pareto-optimal kabul edilir. Görsel olarak, Pareto öncü, verimliliğin maksimum tutulurken gecikmenin en düşük olduğu grafik üzerindeki en üst sola en yakın noktalardan oluşur.
Altyapı Sağlama
Bir LLM uygulaması için gerekli altyapıyı hesaplayabilmek için aşağıdaki kısıtların belirlenmesi gerekmektedir:
- Gecikme türü ve maksimum değer. Bu genellikle uygulamanın doğasına bağlıdır. Örneğin, canlı interaktif yanıtlar veren sohbet uygulamaları için ortalama ilk token süresinin 250 ms veya altında tutulması gerekir.
- Planlı pik talep/saniye. Sistemin hizmet vermesi beklenen eşzamanlı istek sayısını hesaplayın. Bunun, eşzamanlı kullanıcı sayısıyla aynı olmadığını unutmayın, çünkü herkes aynı anda aktif bir talebe sahip olmayabilir.
Bu bilgileri kullanarak, performans grafiğinin yetersiz kalan kısmını ortadan kaldırabilirsiniz (bu örnekte, 250 ms çizgisinin sağındaki herhangi bir veri noktası). gecikme kısıtını sağlayan geri kalan veri noktalarından, en yüksek verimliliğe sahip olanı seçmek isteyeceğiz, bu da en ekonomik seçenek olacaktır (Şekil 3’te gösterilmektedir).
Not: Bu grafik, tüm dağıtım seçeneklerinin aynı sayıda GPU kullandığını varsaymaktadır. Aksi takdirde, saniye başına istek metriği, karşılaştırma için ortak bir zemin sağlamak üzere, GPU başına saniye başına istek olarak normalize edilmelidir.
Grafikten, ulaşılabilir istek sayısını okuyarak bu sayıyı kaydedin. Her örneğin kullandığı GPU sayısını da not edin.
Sonrasında, gereken model örneği sayısını aşağıdaki gibi hesaplarız:
- Asgari model örneği sayısı: Bu, planlı pik talep/saniye, erişilebilir istek sayısı örneği başına bölünerek hesaplanır.
Bir TCO Hesaplayıcı Oluşturma
Gerekli donanım ve yazılım lisanslarının miktarını ve ilgili maliyetleri tahmin etmek için bu adımları ve bir örnek hesaplamayı izleyebilirsiniz.
Öncelikle, donanım ve yazılım ile ilgili maliyet bilgilerini toplayın ve tanımlayın.
| Donanım maliyeti | Örnek değer |
| 1x sunucu maliyeti (initialServerCost) | $320,000 |
| Sunucu başına GPU sayısı (GPUsPerServer) | 8 |
| Sunucu amortisman süresi (amortismanPeriyodu) | 4 yıl |
| Yıllık sunucu barındırma maliyeti (yearlyHostingCost) | $3,000 |
| Yazılım maliyeti | Örnek değer |
| Yıllık yazılım lisans maliyeti (yearlySoftwareCost) | $4,500 |
Sonrasında, toplam maliyeti şu şekilde hesaplayın:
- Sunucu sayısı, istek sayısını, model örnekleri ile GPU sayısını bölerek hesaplanır.
- Yıllık sunucu maliyeti, başlangıç maliyetini amortisman süresine (yılda) bölerek, yıllık yazılım lisans ve barındırma maliyetlerini ekleyerek hesaplanır.
- Toplam maliyet, gerekli sunucu sayısı ile yıllık sunucu maliyetinin çarpımı ile hesaplanır.
Toplam maliyet, bir sunucunun yılda sağlayabileceği toplam isteğin sayısı gibi hizmet başına maliyet, yani 1000 istek başına maliyet ya da 1 milyon token başına maliyet gibi daha da ayrıştırılabilir ve sektör genelinde popüler maliyet metrikleri olarak kullanılabilir.
- 1000 istek başına maliyet, yıllık sunucu maliyetinin, sunucunun %100 çalışma süresinde yıllık olarak sunabileceği toplam istek sayısına bölünmesiyle hesaplanır. Bu oran, gerçek çalışma süresi ile ayarlanabilir.
- 1 milyon token başına maliyet, hem girdi hem de çıktı tokenlerini kapsar. Zaten, bu isteklerin ilgili kullanımıyla bağlantılı olarak, gerekli giriş ve çıkış dizisi uzunluğu (ISL ve OSL) bilindiğinden, 1M birleşik token maliyetini hesaplayabiliriz:
- 1M girdi/çıktı token maliyeti, girdi ve çıktı tokenleri arasındaki maliyet oranını kullanarak hesaplanır. Çünkü genellikle çıktı tokenleri üretilmesi için daha fazla zaman alır ve çoğu ticari LLM hizmet sağlayıcısı, girdi ve çıktı tokenleri için ayrı maliyetler belirlemektedir.
| Token türü | Referans maliyet |
| 1M girdi tokeni (1MinputPrice) | $1 |
| 1M çıktı tokeni (1MoutputPrice) | $3 |
1000 istek başına referans maliyet:
Son olarak:
Sonuç
Bu blog serisinde, bir LLM uygulamaları için TCO hesaplayıcı oluşturma sürecini ele aldık. Çıkarım sunucusu kurulumunu, performans özelliklerini ölçmeyi, gerektiğinde donanım altyapısını tahmin etmeyi ve toplam sahiplik maliyeti hesaplamasında dikkate alınacak maliyet unsurlarını belirlemeyi içerir. Bu metodolojik yaklaşım, kullanıcılara LLM uygulamalarını oluşturma ve onları ölçekli bir şekilde dağıtma konusunda hazırlık yapmalarında yardımcı olacaktır.
Aşağıdaki kaynaklara göz atmayı unutmayın:
- Daha fazla bilgi edinmek ve pratik yapabilmek için, kendi hızınızda “LLM Çıkarım Sistemlerini Boyutlandırma” çevrimiçi kursa katılabilirsiniz.
- FLOPS ötesinde platform mimarisinin TCO’yu nasıl etkileyebileceğini öğrenmek için, NVIDIA DGX Cloud‘un AI platform performansını benchmarklamak için kullanıma hazır şablonlar tanıttığı blog yazısını ve performans benchmark reçetelerini inceleyebilirsiniz.
- Token başına maliyetinizi azaltmak ve AI modellerinizi maksimum verimle kullanmaya yönelik Yöneticiye Yönelik AI Çıkarım ve Performans Rehberi‘ni okuyabilirsiniz.