“LLM Benchmarking: Temel Kavramlar ve Önemi”

Son birkaç yılda, yaratıcı yapay zeka ve büyük dil modelleri (LLM’ler) popülaritesinde kayda değer bir artış yaşandı. LLM tabanlı uygulamalar işletmelerde kullanılmaya başlarken, çeşitli yapay zeka sunum çözümlerinin maliyet etkinliğini değerlendirme ihtiyacı doğdu. Bir LLM uygulamasının dağıtım maliyeti, işlevselliğiyle birlikte saniyede işleyebileceği sorgu sayısına ve yanıtların kabul edilebilir doğruluğuna bağlıdır. Bu yazı, LLM uygulama maliyetlerini değerlendirmenin bir parçası olarak LLM’nin throughput (verimlilik) ve latency (gecikme) ölçümüne odaklanmaktadır.

NVIDIA, geliştiricilere çipler, sistemler ve yazılımlar gibi bir dizi inovasyon sunarak destek vermektedir. NVIDIA’nın inferans yazılımı, NVIDIA TensorRT-LLM ve NVIDIA NIM mikro hizmetlerini içeren bir yazılım yelpazesine sahiptir. Geliştiricilere inferans performansını benchmark etmekte yardımcı olmak için NVIDIA, GenAI-Perf adlı açık kaynaklı bir benchmark aracını sunmaktadır. GenAI-Perf ile benchmark yapmayı öğrenin.

LLM performansını değerlendirmek için çeşitli araçlar kullanılabilir. Bu araçlar, LLM tabanlı uygulamalar için belirli metrikler sağlar; ancak bu metriklerin tanımı, ölçümü ve hesaplaması bakımında farklılık gösterir. Bu durum kafa karıştırıcı olabilecek ve bir araçtan alınan sonuçların diğerinin sonuçlarıyla karşılaştırılmasını zorlaştırabilir.

Yük Testi ve Performans Benchmarking

Yük testi ve performans benchmarking, bir LLM dağıtımını değerlendirmek için iki ayrı yaklaşımdır. Yük testi, bir modele çok sayıda eşzamanlı isteği simüle ederek, gerçek dünya trafiğini ölçekli bir şekilde işleme kapasitesini değerlendirmeye yöneliktir. Bu tür testler, sunucu kapasitesi, otomatik ölçeklendirme taktikleri, ağ gecikmesi ve kaynak kullanımı gibi sorunları tanımlamakta yardımcı olur.

Buna karşın, NVIDIA GenAI-Perf aracıyla gösterildiği gibi performans benchmarking, modelin kendisinin gerçek performansını, belirli metrikler (throughput, latency ve token düzeyinde metrikler gibi) ile ölçmeyi amaçlar. Bu tür testler, model verimliliği, optimizasyonu ve yapılandırmasına ilişkin sorunları tanımlamaya yardımcı olur.

Yük testi, modelin büyük bir istek hacmini yönetebilmesini sağlamak için önemlidir; bunun yanı sıra performans benchmarking, modelin istekleri etkin bir şekilde işleme yeteneğini anlamak için kritik öneme sahiptir. Her iki yaklaşımın birleşimi, geliştiricilere LLM dağıtım yeteneklerini kapsamlı bir şekilde anlamalarına ve geliştirilmesi gereken alanları tanımlamalarına olanak tanır.

LLM İnfereansının Çalışma Şekli

Benchmark metriklerini incelemeden önce, LLM infereansının nasıl çalıştığını anlamak ve ilgili terimlerle tanışmak önemlidir. Bir LLM uygulaması, infereans aşamaları aracılığıyla sonuç üretir. Belirli bir LLM uygulaması için bu aşamalar şunlardır:

Prompt: Kullanıcı bir sorgu sağlar.
Queueing: Sorgu işlem için kuyruğa katılır.
Prefill: LLM modeli prompt’u işler.
Generation: LLM modeli, her seferinde bir token olmak üzere bir yanıt üretir.

Bir token, LLM’lerin doğal dili işlemek için kullandığı en küçük dilsel birimdir. Tüm tokenlerin birleşimine ise vokabüler denir. Her LLM, verilerden öğrenilen ve giriş metinlerini etkili bir şekilde temsil eden kendi tokenizer’ına sahiptir. Popüler LLM’lerin çoğu için bir tokenın yaklaşık 0.75 İngilizce kelimeye denk geldiği söylenebilir.

Girdi Dizi Uzunluğu (Input Sequence Length – ISL), LLM’nin aldığı token sayısını belirtir. Bu, kullanıcı sorgusunu, model için sistem prompt’unu (örneğin, talimatlar) ve önceki sohbet geçmişini de kapsar. Çıktı Dizi Uzunluğu (Output Sequence Length – OSL) ise LLM’nin ürettiği token sayısını ifade eder. Bağlam uzunluğu (Context Length), LLM’nin her üretim adımında kullandığı token sayısını ifade eder; bu hem giriş hem de o zamana kadar üretilen çıktı tokenlerini içermektedir. Her LLM’nin maksimum bağlam uzunluğu, giriş ve çıktı tokenleri için tahsis edilebilir.

Streaming, kısmi LLM çıktılarını, kullanıcıya artımlı olarak üretilen tokenlar şeklinde akıtarak geri gönderme seçeneğidir. Bu, kullanıcıların ilk yanıtı hızla almasının istendiği chatbot uygulamaları için önemlidir. Kullanıcı, kısmi içeriği sindirirken, yanıtın bir sonraki parçası arka planda gelir. Buna karşılık, non-streaming modda tam yanıt bir kerede döner.

LLM İnferans Metrikleri

Bu bölüm, sektörde yaygın olarak kullanılan bazı metrikleri, örneğin ilk token için geçen süre (TTFT) ve tokenlar arası gecikmeyi (ITL) açıklamaktadır. Her ne kadar basit gibi görünseler de, bu metrikler çeşitli benchmark araçları tarafından toplanırken bazı karmaşık farklılıklar içermektedir.

Diagram showing LLM metrics including time to first token and inter-token latency. — *Şekil 1. LLM inferans performans metrikleri*

İlk Token İçin Geçen Süre (TTFT)

İlk token için geçen süre (TTFT), prompt’un işlenmesi ve ilk tokenın üretilmesi için geçen süreyi belirtir. Yani, bir kullanıcının modelin çıktısını görmeden önce beklemesi gereken süreyi ölçer.

TTFT ölçümünde, hem GenAI-Perf hem de LLMPerf benchmarking araçları, içeriği olmayan ya da boş bir dize içeren ilk yanıtları dikkate almaz. Çünkü ilk yanıtın hiç token içermesi durumunda TTFT ölçümü anlam taşımamaktadır.

Figure showing the process leading to generating the first token: tokenization, prompt processing, and detokenization. These comprise the time to the first token metric. — *Şekil 2. İlk tokenın üretilmesine giden süreç*

TTFT genel olarak, sorgu kuyruğu süresini, ön işlem süresini ve ağ gecikmesini içerir. Prompt’un uzunluğu, TTFT’yi uzatır çünkü dikkat mekanizması, KV önbelleğini oluşturmak için tüm girdi dizisini kullanır. Üretim uygulaması birden fazla isteğe sahip olabilir, bu nedenle bir isteğin ön işleme aşaması, başka bir isteğin üretim aşamasıyla örtüşebilir.

Uçtan Uca İstek Gecikmesi

Uçtan uca istek gecikmesi (e2e_latency), bir sorgu gönderiminden tamamlanmış yanıtı alana kadarki süreyi belirtir. Bu süre, kuyruklama, toplama ve ağ gecikmelerini de içerir. (Şekil 3). Streaming modda, kısmi sonuçların kullanıcıya döndürülmesi sırasında detokenizasyon adımı birden fazla kez yapılabilir.

Figure showing end-to-end request latency, comprising network latency, queueing time, tokenization, prompt processing, and the generation/detokenization loop. — *Şekil 3. Uçtan uca istek gecikmesi*

Bireysel bir istekte, uçtan uca istek gecikmesi, isteğin gönderildiği ve son tokenin alındığı zaman arasındaki farktır:

$mathit{e2e_latency} = TTFT + mathit{generation_time}$

Unutulmamalıdır ki, generation_time, ilk tokenin alındığı andan son tokenin alındığı ana kadar geçen süredir (Şekil 1). Ayrıca, GenAI-Perf, son (tamamlandı) sinyalini veya boş yanıtı dikkate almaz, bu nedenle bunlar e2e_latency’ya dahil edilmez.

Tokenlar Arası Gecikme

Tokenlar arası gecikme (ITL), bir dizide ardışık tokenlerin üretilmesi arasındaki ortalama zamanı belirtmektedir. Aynı zamanda, çıktı token başına süre (TPOT) olarak da bilinir.

Figure demonstrating the latency between consecutive tokens. — *Şekil 4. Tokenlar arası gecikme, ardışık token üretimleri arasındaki ortalama zamanı gösterir*

Bu tanım basit görünse de, farklı benchmark araçları arasında metriklerin toplanma şekli bakımından bazı karmaşık farklılıklar vardır. Örneğin, GenAI-Perf, ortalama hesaplama sırasında TTFT’yi dahil etmezken, LLMPerf bunu dahil etmektedir.

GenAI-Perf, ITL’yi şu denklemle tanımlar:

$mathit{ITL} = frac{mathit{e2e_latency} - TTFT}{mathit{Total_output_tokens} - 1}$

Bu denklemde, ilk tokenın çıkarılması nedeniyle paydada 1 çıkartılmaktadır. Bu, ITL’nin yalnızca isteğin işlenmesi sırasında oluşturulan tokenlerin karakteristiği olarak tanımlanmasını sağlar.

Uzun çıktı dizileriyle birlikte KV önbellek büyür; dolayısıyla bellek maliyeti de artar. Dikkat hesaplamalarının maliyeti de artar: her yeni token için bu maliyet, o ana kadar üretilen giriş ve çıktı dizelerinin uzunluğu ile lineerdir. Ancak, bu hesaplama genelde hesaplama ile sınırlı değildir. Tutarlı ITL’ler, etkili bellek yönetimi, daha iyi bellek bant genişliği ve etkili dikkat hesaplaması belirtir.

Token Başına Düşen Süre

Token başına düşen süre (TPS) sistemi başına yazılımın çıktıları tokenlerinin toplam sayısını ifade ederken, her bir sistemin toplam çıktı tokenlerinden saniyede elde edilen throughput’u temsil eder. İstek sayısı arttıkça, toplam TPS değeri artar; fakat belirli bir noktada tüm mevcut GPU hesaplama kaynaklarının sınırına ulaşır ve sonraki aşamada düşüş gösterebilir.

Şekil 5’te belirtilen benchmarking örneğinde, tüm benchmark süresinin zaman çizelgesi şu şekilde tanımlanmıştır:

Li: i. isteğin uçtan uca gecikmesi
T_start: Benchmarkın başlangıcı
Tx: İlk isteğin zaman damgası
Ty: Son isteğin yanıtının zaman damgası
T_end: Benchmarkın bitişi

Figure demonstrating the timeline of events in a benchmarking run, from the start of the benchmark, the start of the request sent to the end of the last request, to the end of the entire benchmark. — *Şekil 5. Benchmarking sürecindeki olayların zaman çizelgesi*

GenAI-Perf, TPS’yi toplam çıktı tokenlerini, ilk isteğin zaman damgası ile son isteğin yanıtının zaman damgası arasındaki uçtan uca gecikmeye bölerek tanımlar:

$TPS = frac{mathit{Total_output_tokens}}{T_y - T_x}$

LLMPerf ise TPS’yi toplam çıktı tokenlerini toplam benchmark süresine bölerek tanımlar:

$frac{mathit{Total_output_tokens}}{T_{text{end}} - T_{text{start}}}$

Bu sayede, LLMPerf aşağıdakileri de TPS metrik hesaplamasına dahil eder:

Girdi prompt’unun üretilmesi
İstek hazırlama süresi
Yanıtların saklanması.

Tek bir eş zamanlılık senaryosunda bu ek yüklerin, toplam benchmark süresinin %33’üne kadar çıkabileceğini gözlemledik.

Unutulmaması gereken bir diğer nokta, TPS hesaplamasının toplu bir biçimde yapıldığı ve canlı bir ölçüm olmadığıdır. GenAI-Perf ise stabil ölçümler bulmak için kayan pencere tekniği kullanır. Yani verilen ölçümler, tamamen tamamlanmış isteklerin bir temsilci alt kümesinden alınır; bu nedenle “ısıtma” ve “soğutma” istekleri bu ölçümlere dahil edilmez.

Kullanıcı başına token sayısı (TPS per user), tek bir kullanıcının perspektifinden throughput’u temsil eder ve şöyle tanımlanır:

$TPS_{text{per user}} = frac{mathit{Output sequence length}}{mathit{e2e_latency}}$

Bu tanım, her kullanıcının isteği için geçerlidir ve çıktı dizisi uzunluğu arttıkça 1/ITL’ye yaklaşmaktadır. Not etmek gerekir ki, sistemde eş zamanlı isteğin sayısı arttıkça, toplam sistem TPS değeri yükselecek, ancak kullanıcı başına TPS değeri gecikme artışıyla düşecektir.

Saniyedeki İstek Sayısı

Saniyedeki istek sayısı (RPS) sistemin başarılı bir şekilde tamamlayabildiği istek sayısını göstermektedir. Bu, aşağıdaki şekilde hesaplanır:

$RPS = frac{mathit{total_completed_requests}}{T_y - T_x}$

Benchmarking Parametreleri ve En İyi Uygulamalar

Bu bölüm, anlamlı bir benchmarking ve kalite güvence sağlamak için bazı önemli test parametrelerini ve bunların aralığını sunmaktadır.

Uygulama Kullanım Senaryoları ve LLM Performansı Üzerindeki Etkisi

Bir uygulamanın belirli kullanım senaryoları, dizilerin uzunluklarını (ISL ve OSL) etkiler ve bu da sistemin giriş verilerini KV-cache’i oluşturmak ve çıktı tokenlerini üretmekteki hızını belirler. Uzun bir ISL, ön işlem aşamasında bellek gereksinimlerini artırır ve dolayısıyla TTFT’yi uzatır. Uzun bir OSL ise, üretim aşamasında bellek gereksinimlerini artırarak ITL’yi uzatır. LLM dağıtımınızda giriş ve çıkışların dağılımını anlamak, donanım kullanımınızı en iyi şekilde optimize etmek için önemlidir.

Yaygın kullanım senaryoları ve olası ISL/OSL çiftleri şunlardır:

Çeviri: Diller arası ve kod çevirisi ile ilgilidir ve yaklaşık 500~2000 token uzunluğu olan benzer ISL ve OSL ile karakterize edilmektedir.
Üretim: Kod, hikâye ve e-posta içeriği gibi içerik üretimi ile ilgilidir. Bu, O(1,000) token boyutunda bir OSL ve O(100) token boyutunda bir ISL ile karakterize edilir.
Özetleme: Alım, düşünce zinciri tanımlama ve çok dönüşlü konuşmaları içerir. Bu, O(1000) token boyutunda bir ISL ve O(100) token boyutunda bir OSL ile karakteriz edilir.
Akıl yürütme: Güncel akıl yürütme modelleri, karmaşık sorunları çözmek için açık bir düşünce zinciri yayımlanan genelleme yöntemleri kullanarak geniş sayıda çıktı token üreterek tanımlanır. Kısa ISL’ler (O(100) token) ve büyük OSL’ler (O(1000-10000) token) ile karakterize edilir.

Yük Kontrol Parametreleri

Bu bölümde tanımlanan yük kontrol parametreleri, LLM sistemlerinin yüklenmesine neden olmak için kullanılmaktadır.

Eş Zamanlılık N, her biri bir aktif isteğe sahip olan eş zamanlı kullanıcı sayısını belirtir; veya aynı şekilde, LLM hizmeti tarafından eşzamanlı olarak işlenen istek sayısını belirtir. Her kullanıcı isteği tamamlanır tamamlanmaz, başka bir istek gönderilir; böylece sistemin her zaman tam N sayıda isteği olur. Eş zamanlılık, genellikle infereans sistemine uygulanan yükü tanımlamak ve kontrol etmek için kullanılır.

LLMPerf, isteği partiler halinde N sayıda istekte bulunur; fakat bir boşaltma süresi bekler ve tüm isteklerin tamamlanmasını bekleyerek bir sonraki parti isteği gönderir. Bu nedenle, partinin sonunda eşzamanlı istek sayısı, 0’a doğru yavaş yavaş düşer. Bu, ve her zaman N aktif isteği koruyan GenAI-Perf’ten farklıdır.

Maksimum parti boyutu parametresi, infereans motorunun aynı anda işleyebileceği maksimum istek sayısını tanımlar; burada parti, infereans motoru tarafından işlenen eş zamanlı isteklerin grubudur. Bu, eşzamanlı isteklerin bir alt kümesi olabilir.

Eğer eşzamanlılığı maksimum parti boyutunu aşarsa, bazılarının daha sonraki işlemler için kuyruğa alınması gerekecektir. Bu durumda, TTFT değerinde artış gözlemlenebilir; çünkü bir yer açılmasını beklemekte olan tüm istekler kuyrukta kalacaktır.

İstek oranı, yeni isteklerin gönderilme oranını belirlemek için bir diğer parametre olarak kullanılabilir. Sabit bir (yani statik) istek oranı r kullanarak, her bir saniyede 1 istek gönderilir; Poisson (ya da üstel) istek oranı ise ortalama aralığı belirler.

GenAI-Perf, hem eşzamanlılığı hem de istek oranını destekler. Ancak, eşzamanlılık kullanılmasını öneriyoruz. İstek oranı kullanıldığında, istek başına yanıt süresi sistem throughput’unu aştığında, bekleyen istekler sayısı sınırsız ölçüde yükselebilir.

Test edilecek eşzamanlılıkların belirtilmesi sırasında, 1 olan minimum değerden başlayarak maksimum değere kadar bir değer aralığını süzmek faydalıdır; bu değer, maksimum parti boyutunun çok üzerinde olmamalıdır. Zira, eşzamanlılık, motorun maksimum parti boyutundan fazla olduğunda, bazı isteklerin kuyrukta beklemesi gerekecektir. Bu nedenle, sistemin throughput’u, genellikle maksimum parti boyutunun etrafında doygunluk seviyesine ulaşır; dolayısıyla latency ise sürekli olarak artacaktır.

Diğer Parametreler

Ayrıca, infereans performansını etkileyen ve ölçüm hassasiyetini etkileyen bazı LLM sunum parametreleri mevcuttur.

Pek çok LLM, üretimin sonunu belirten özel bir son dizi (EOS) token içerir. Bu, LLM’nin tam bir yanıt ürettiğini ve durması gerektiğini gösterir. Genel kullanımda, LLM infereansı bu sinyale saygı duymalı ve daha fazla token üretmemelidir. ignore_eos parametresi, genellikle bir LLM infereans çerçevesinin EOS tokenini göz ardı edip etmeyeceğini belirtir ve bu durumda gerçek çıktı uzunluğunu elde etmek ve tutarlı ölçüm yapmak için, bu parametre doğru ayarlanmalıdır.

Farklı örnekleme parametrelerinin (greedy, top_p, top_k ve sıcaklık gibi) LLM üretim hızını etkileyebileceği göz önünde bulundurulmalıdır. Örneğin, greedy, en yüksek logiti seçerek uygulanabilir. Bu durumda, tokenlerin olasılık dağılımını normalleştirmeye ve sıralamaya gerek olmadığından, hesaplama süresi de kısalmaktadır. Hangi örnekleme yöntemi seçilirse seçilsin, aynı benchmark ayarları içinde tutarlı kalmak iyi bir uygulamadır; farklı örnekleme yöntemleri hakkında derinlemesine bilgi için Farklı Metodlarla Metin Üretimi: Dönüşümlü ve Dili Anlama Yöntemleri‘ne göz atabilirsiniz.

Başlayın

LLM performans benchmarking, yüksek performans ve maliyet etkin LLM sunumu sağlamak için kritik bir adımdır. Bu yazıda LLM infereansını benchmark ederken dikkate alınması gereken en önemli metrikler ve parametreler ele alınmıştır. Daha fazlasını öğrenmek için şu kaynaklara göz atabilirsiniz:

Yapay Zeka İfadesi: Maliyet, Gecikme ve Performansı Dengelemek
NVIDIA NIM’i 5 Dakikada Nasıl Yükleyebilirsiniz?
Generative AI’yi NVIDIA NIM ile Yüklemenin Basit Kılavuzu

NVIDIA AI Inferans platformunu keşfedin ve en son yapay zeka inferans performans verilerini görün. TensorRT, TensorRT-LLM ve TensorRT Model Optimizer kütüphanelerinden optimizasyonlar, NVIDIA NIM mikro hizmetleri kullanarak üretime hazır dağıtımlar aracılığıyla bir araya getirilmiştir.