MLPerf tarafından ölçülen saniye başına token sayısı nedir ve bunlar LLM'de nasıl kullanılır?

Donanım Kılavuzu » Deneyler » MLPerf tarafından ölçülen saniye başına token sayısı nedir ve bunlar LLM'de nasıl kullanılır?

Dil modelleriyle çalışıyorsanız, "saniye başına token sayısı" terimini binlerce kez duymuşsunuzdur, ancak gerçek dünya ortamlarında ne anlama geldiği ve her şeyden önce MLPerf'in bunu nasıl ölçtüğü nadiren ayrıntılı olarak açıklanır. Bu makalede, tokenların ne olduğunu, saniye başına token sayısı metriğinin çıkarımda neden bu kadar önemli olduğunu ve Databricks ve MLPerf kıyaslaması gibi platformların bunu boyutlandırma, karşılaştırma ve ölçeklendirme için nasıl kullandığını açıklıyoruz. Ayrıca üreticilerden ve bulutlardan yer performans beklentilerine kadar belirli rakamları da dahil ediyoruz..

Sorun küçük değil: Sektör, veri merkezlerinde ve uçta LLM performansını değerlendirmek için saniye başına düşen belirteçleri standartlaştırdı. Hakemli MLCommons paketi olan MLPerf, donanım ve yazılımları karşılaştırmak için kıstas haline geldi.Buna paralel olarak, Databricks gibi operatörler, model uç noktalarını halihazırda doğrudan saniyedeki belirli bir token aralığına göre sağlıyor. Şimdi, elimizdeki sayılar ve kullanım örnekleriyle tüm bunları ayrıntılı olarak inceleyelim.

Token nedir ve LLM'de neden önemlidir?

Dil modelleri, harfleri veya kelimeleri olduğu gibi işlemez; token adı verilen birimlerle çalışır. Bir token genellikle yaklaşık 4 karakter uzunluğundadır veya ortalama 0,75 kelimedir.Bu oran, dile ve modelin belirteçleyicisine bağlı olarak değişir, ancak hızlı bir referans olarak kullanılabilir: 10 kelimelik bir metin 13-14 belirteç arasında hareket eder.

Kesin segmentasyon modele bağlıdır: Her LLM kendi belirteç ayırıcısını kullanır ve kelimeleri tam belirteçlere veya alt kelimelere bölerÇevrimiçi araçlar, örneğin Llama'nın belirli bir ifadeyi nasıl simgeleştirdiğini görmenizi sağlar. Küçük bir ayrıntı gibi görünen bu değişkenlik, gecikmeyi ve işlem maliyetlerini etkiler.

Üretim hızından bahsederken, genellikle saniye başına kelime sayısı yerine saniye başına düşen token sayısı cinsinden ifade edilir. Bu, metriği diller, bağlam uzunlukları ve çıktı stilleri arasında homojenleştirir.ve çıkarım maliyetinin ve gerekli kapasitenin doğru bir şekilde hesaplanmasına olanak tanır.

Performansı neden saniye başına düşen token sayısıyla ölçüyoruz da RPS ile ölçmüyoruz?

Geleneksel API hizmetleri RPS'ye (saniye başına istek sayısı) odaklanır. LLM'de ise bu yaklaşım yetersiz kalır: Giriş belirteçlerine ve çıkış belirteçlerine bağlı olarak iki istek çok farklı zamanlarda gerçekleşebilirYani gerçek yük "çağrı sayısı" olarak değil, tokenlar olarak geliyor.

Değişkenliğin iki temel kaynağı vardır. Birincisi, girdi bağlamının uzunluğudur. Kısa bir istemde yalnızca birkaç simge bulunabilir, ancak özet bir belgede yüzlerce veya binlerce simge bulunabilir.Öte yandan, çıktının uzunluğu: özetlemek genellikle daha az belirteç üretir; uzun bir makale veya açıklama oluşturmak zamanı artırır, çünkü çıktı çözümleme en pahalı kısımdır.

Bu nedenle, bir çıkarım son noktasını gerçekçi bir şekilde ölçeklendirmek için, belirteçler açısından düşünmek faydalıdır. Örneğin Databricks, Serving uç noktalarını saniye başına belirli bir token aralığıyla sağlar ve ölçeklemeye göre saatlik olarak faturalandırır.Bu şekilde, tüm hikayeyi anlatmayan bir RPS'ye aldanmadan kapasiteyi gerçek yük ile uyumlu hale getirebilirsiniz.

Databricks ve MLPerf saniye başına token sayısını nasıl ölçer?

Databricks, referans olarak temsili bir RAG yükünü alır ve özetler: 2048 giriş jetonu ve 256 çıkış jetonuHer iki aşamayı (önceden doldurma ve kod çözme) birleştirir ve varsayılan olarak, istek başına 1'lik toplu boyutlar için verim ve gecikme arasındaki dengeyi optimize ederek birden fazla eşzamanlı isteği simüle eder.

Bu kurala göre sayılar şu şekilde okunur: Eğer saniyede 2304 token (2048 + 256) bir uç nokta yapılandırırsanız, Bu boyutlardaki bir istek yaklaşık bir saniye sürerBunu saniyede 5600 token olarak ayarlarsanız, aynı isteğin süresi yaklaşık 0,5 saniyeye düşer ve saniyede iki benzer isteği işleyebilirsiniz.

İş yükünüz değiştiğinde gecikme de değişecektir. Daha fazla çıktı jetonu üretmek, girdi jetonlarını artırmaktan daha fazla ceza gerektirir.Toplu çıkarım yapıyorsanız, veri kümeniz için ortalama giriş ve çıkış belirteç sayısını hesaplayın ve süreleri tahmin etmek için bunu önceki kıyaslama ile karşılaştırın.

Pratik örnekler: 1000 satır, ortalama 3000 giriş ve 500 çıkış belirteci ve saniyede 3500 belirteçlik sağlanan bir verim ile, 1000 saniyeden fazla sürecek Çünkü ortalamalarınız referansı aşıyor. Bunun yerine, saniyede 1500 token ile 100 giriş ve 1600 çıkışın ortalamasını alırsanız, 1000 saniyenin altına düşeceksin toplamda bu 1000 satır için.

İsteğe bağlı otomatik ölçekleme ve gerçek ölçekleme hesaplaması

Databricks Model Serving, hızlı otomatik ölçeklemeyi içerir Saniye başına token talebine göre kaynakları artırın veya azaltınSistem, kapasite blokları halinde ölçeklenir ve ek kapasite yalnızca kullanıldığında faturalandırılır. Daha fazla paralel istek içeren testlerde, sağlanan verim, kaynaklar doygunluğa ulaştığında saniyede yaklaşık 8000 token'a ulaşana kadar artar ve bu da kuyruk gecikmesini artırır.

Saniyede işaretlediğinizden daha az token görüyorsanız iki şeyi kontrol edin: Uç nokta ölçümlerini ve minimum bant genişliği boyutunu yansıtan sağlanan eşzamanlılık yapılandırılmıştır. Bu verilerle, gerçek ölçekleme şu formül kullanılarak tahmin edilir: sağlanan eşzamanlılık × minimum bant genişliği boyutu / 4.

Somut bir örnek: saniyede maksimum 8 eşzamanlılık ve minimum 850 token şerit boyutu ile, Etkin sınır saniyede 1700 token olacaktır (8 × 850 / 4). Bu hesaplamayı anlamak, sürprizleri önler ve ayarlarınızı gecikme SLO'larınıza göre hassas bir şekilde ayarlamanıza yardımcı olur.

MLPerf Çıkarımı: Nedir ve bugün neyi ölçer?

MLCommons tarafından geliştirilen MLPerf, veri merkezi ve uçta yapay zeka performansının, vizyondan LLM'ye kadar ölçülmesi için açık ve standartlaştırılmış bir pakettir. Amacı, ekosistem verimliliğini artırmak için platformları adil ve tekrarlanabilir bir şekilde karşılaştırmaktır.Son yıllarda odak noktasının GenAI ve büyük LLM'lere doğru kaydığı açıkça görülüyor.

Beşinci baskıda, Llama 2 70B, ResNet50'nin yerini alarak yıldız ölçütü olarak konsolide edildi ve Saniye başına token metrikleri en iyi ihtimalle bir yılda 3,3 kata kadar iyileştiDonanım ve yazılım optimizasyonları sayesinde 5 kat daha yüksek bir ortalama performansa sahip. Intel Xeon 6 gibi CPU'ların resmi sonuçlarda yer alması da bunu kanıtlıyor. Belirli senaryolarda verimli genel çözümlere yer vardır.

MLPerf Inference'ın 5.1 sürümü bir adım daha ileri gitti: üç yeni temel ölçütü bünyesinde barındırıyor: DeepSeek-R1 ile muhakeme, Whisper Large v3 ile konuşma-metne dönüştürme ve Llama 3.1 8B tabanlı küçük bir LLMKonsorsiyum genel olarak 27 katılımcı bildirdi, 90.000 sonuç hedefine ulaştı ve etkileşimli senaryolarda gecikme metriklerini daralttı.

Yeni ölçütlerdeki metrikler ve hedefler

1B parametreli bir MoE olan DeepSeek‑R671 ile yapılan akıl yürütme kıyaslaması şunu göstermektedir: Bu modeller, cevaptan önce uzun akıl yürütme zincirleri üretirVeri setinde çıktı başına ortalama 20.000 token ile 3880 tokena kadar çıktıları destekler; bu, çıkarım alanında bugüne kadarki en büyük değerdir.

Kurallar çevrimdışı modda ve sunucu modunda verimi sıkı sınırlamalarla ölçer: p2'da ilk jetona ulaşma süresi 80 saniye ve jeton başına gecikme 99 msBu, "düşünen" bütçeyi, onu uygulamaya koymak için gereken duyarlılıkla dengelemeyi amaçlar.

Llama 3.1‑8B'li küçük LLM kıyaslaması, ağ geçidi olarak GPT‑J 6B'nin yerini alıyor. 128.000'e kadar jetonun bağlamlarını destekler ve CNN‑DailyMail'de 778 girdi ve 73 çıktı belirteci ile özetlemeyi değerlendirir. Doğruluk, ROUGE ile doğrulanır ve kapalı bölmede, yüksek doğruluklu bir kıyaslamanın %99'una uyması gerekir.

Gecikme metriklerinde iki gösterge kullanılır: TTFT (ilk tokene kadar geçen süre) ve TPOT (token başına düşen süre). Sunucuda 2 sn TTFT ve 100 ms TPOT görülmektedir. (yaklaşık 480 ppm) ve yeni etkileşimli senaryoda sohbet, kodlama veya yaratıcı araçlar gibi durumlar için sırasıyla 0,5 sn ve 30 ms'ye (yaklaşık 1600 ppm) sıkıştırılıyor.

Üretici ve operatöre göre performans vurguları

• NVIDIA, bu kez GB300 NVL72 sisteminde Blackwell Ultra ile liderliği ele geçirdi ve puan aldı GB45 NVL1'den yüzde 200 daha fazla verim sağlayan DeepSeek‑R72 ile muhakemede rekorGPU başına saniyede 5842 token'a çevrimdışı ve sunucuda 2907 token'a ulaşarak, doğrulanmamış Hopper'a kıyasla 5 kata yakın iyileştirmeler sağladı.
• NVIDIA, yeni etkileşimli Llama 3.1 405B kıyaslamasında şunları uyguladı: Dynamo ile parçalanmış servis, farklı GPU'larda bağlamı ve üretimi ayırarak ve KV Önbelleğini NVLink üzerinden aktararak, Blackwell'deki geleneksel sunucuya göre GPU başına 1,5 kat daha fazla verim ve Hopper'lı sistemlere göre 5 kattan fazla verim elde ediyor.
• NVIDIA, daha küçük modeller için şunları bildirdi: Llama 18.000 3.1B çevrimdışında GPU başına saniyede 8'den fazla token ve Whisper'da GPU başına saniyede 5667 token üreterek tüm senaryolarda (çevrimdışı, sunucu ve etkileşimli) GPU liderliğini koruyor.
• AMD, şu anda 355‑2B aralığında olan Instinct MI70X GPU'nun ilk sevkiyatıyla varlığını genişletti. FP2,7'de çoklu düğüm ölçeklemesi ve MI325X'e kıyasla saniyede 8 kat daha fazla token artışı görüldüAçık bölmede, Llama 3.1‑405B (FP4)'ye yapılandırılmış budama uygulandı. %82 derinlik budaması yapılmış bir modelle verimi %21, %90 daha ince ayarlı bir modelle ise %33 oranında artırdı, hassasiyeti koruyarak.
• Ayrıca Llama 2‑70B Interactive, Mixtral‑8×7B ve Stable Diffusion XL'de de sevkiyatlar başladı ve karışık MI300X/MI325X sonuçları sundu: 4 düğüme ölçeklendiğinde MI355X, MI3,4X'ten 300 kat daha fazla verim elde etti8 düğüme kadar genişleyen, iyi ölçeklenebilirliğe sahip.
• HPE, ProLiant ve Cray'i bir araya getirerek 14 adet 1 numara sonuç bildirdi. DL380a Gen12, 3.1 GPU'lu PCIe sistemleri arasında DLRM ve Llama 8‑8B (Sunucu) kategorilerinde öne çıktı; DL385 Gen11 ise Whisper'da belirgin şekilde daha iyi GPU performansı görüldü H200 NVL ile; ve Cray XD670 (8× H200) RetinaNet, Llama 3.1‑8B, Mixtral ve Whisper'da altı birincilik elde etti, ayrıca DLRM'de RTX Pro 6000 Blackwell SE ve GH200 NVL2 sonuçlarında birincilik elde etti.
• CoreWeave, GB300 ile sonuçlarını bildiren ilk bulut oldu ve şunları sağladı: DeepSeek‑R6005'de GPU başına saniyede 1 token çevrimdışı ve Kubernetes üzerinde Slurm ile orkestrasyon ve ölçeklemeyi ve NVLink'ten en iyi şekilde yararlanmak için topolojiye duyarlı planlamayı gösteriyor.
• Dell, AMD ve NVIDIA hızlandırıcıları ile 12 sistem gönderdi ve PowerEdge XE2L ve B70 ile LLaMA 9680 200B Interactive'de parladı. XE3.1L+B8'de LLaMA 9685‑200B Sunucusu, XE9685L üzerinde SDXL ve XE9680L üzerinde Whisper, LLM aracılığıyla görüntüden sese çok yönlülüğü gösteriyor.
• Intel, bunun devam ettiğini vurguladı sonuçları sunucu CPU'larıyla gönderen tek kişi ve P çekirdekli Xeon 6'nın beş kıyaslamada 1,9. Nesil Xeon'a göre 5 kat daha iyi performans gösterdiğini göstererek genel amaçlı çıkarımdaki rolünü pekiştirdi. Ayrıca, Llama8‑60B'yi birden fazla kullanıcıya sunmak için 192 GB VRAM'e sahip 2 Arc Pro B70 GPU'lu iş istasyonları tanıttı ve çoklu GPU dağıtımını basitleştirmek için sürücüler ve çerçeveler ekledi.
• Entegratörler ve ortaklar arasında ASUSTeK Niceleme, çekirdekler ve yığın ile optimize edilmiş gecikme ve verim; Broadcom, birden fazla iş yükünde (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet) çıplak metale kıyasla minimum ek yük ile VCF sanallaştırmayı gösterdi; Cisco, One G885 ağları tarafından desteklenen UCS C8A M8 (200× H845 SXM) ve UCS C8A M8 (200× H40 NVL veya L200S) ile neredeyse doğrusal olarak ölçeklendi.
• OpenAI API'sini ve gerçekçi genel giderleri kullanan KRAI, SGLang ve vLLM'yi Llama3.1‑70B ile karşılaştırdı: SGLang 31.391 ile saniyede 0.4.9 token çevrimdışı ve vLLM 26.319 ile tek bir sunucuda 0.9.2x H8 ile 200'a ulaştı; dinamik niceleme ile SGLang ile 27.697'ye ve vLLM ile 30.893'e ulaştı ve çoklu düğümde üç sunucuda saniyede 87.334 jetona kadar ölçeklendi.
• 8x B200 180 GB SXM'li Lambda, verimlilikte iyileştirmeler gösterdi SDXL'de %7'ye kadar ve Llama 15‑3.1B'de %405'e kadar Önceki tura kıyasla, yönetilen Kubernetes veya Slurm ile 16 ila 1536 GPU'lu kümeler sunuyor.
• MiTAC, G8825Z5 serisiyle LLaMA 2 70B Interactive'de parladı Saniyede 18.846,1 jeton ve Server ve Mixtral'da iyi sonuçlar; Nebius, sanallaştırılmış performansının GB200 NVL72, HGX B200 ve HGX H200'de çıplak metal ile neredeyse aynı seviyede olduğunu onayladı. Sunucuda saniyede 596,11 belirteç ve Llama 855,82‑3.1B'de çevrimdışı 405 belirteç 4 GB200 GPU'lu.
• Red Hat, vLLM'yi AI Inference Server'ında desteklenen bir çalışma zamanı olarak gösterdi. FP8 ve FlashAttention‑3 için CUTLASS çekirdekleri Ayrıca geliştirilmiş vLLM v1 motoru, H3.1 ve L8S'deki Llama‑100‑40B'yi harika bir maliyet-performans oranıyla güçlendiriyor.
• Supermicro, hem Intel hem de AMD CPU'larla HGX‑B200 8‑GPU (hava ve sıvı) ile önde gelen sonuçlar yayınladı ve şunları vurguladı: Sunucu/çevrimdışı/etkileşimli ve Whisper'da Llama 3.1‑8B ve Llama 2‑70B; işbirliklerinde 32× H100‑SXM ve MI325X alternatifleriyle mükemmel ölçekleme gösterdi.
• Vultr, Supermicro AS‑8126GS‑TNMR ve 8x MI325X ile piyasaya sürülerek Bulut GPU'su olarak rekabetçi performansını belgelendirdi; GATEOverflow MLCFlow ile geliştirilmiş tekrarlanabilirlik RTX 4090 ve AMD/Intel CPU'lar üzerinde; Giga Computing 8U hava soğutmalı EPYC+MI325X ve Xeon+HGX B200 sistemleri gönderdi; QCT, 6× MI200X sistemlerine ek olarak, H4 NVL (8 GPU) ve NVLink ve GPUDirect Depolama özellikli 200× H5 SXM8 platformlu Xeon 325 yapılandırmalarını kapsadı.

Akademi dünyasının da bir şansı vardı. Florida Üniversitesi, HiPerGator ile entegre DGX B200 SuperPOD'u ile çıkarım sonuçlarını sunan ilk kurum oldu Kapalı bölümlendirme altında sunucu gecikmelerini karşılama, Docker/Sudo olmadan Apptainer kullanma ve çok kullanıcılı SLURM'a uyum sağlama. Tam tersi durumda, M1 MacBook Pro'da tek bir gönderim, GPU ve Neural Engine üzerinde ONNX Runtime ve CoreML ile, uç kategorisinde hedef doğruluğu aştı ve tüketici donanımlarında kalite çıkarımının değerlendirilebileceğini gösterdi.

Kullanıcıların algıladığı hız ve pratik sınırlar

Kullanıcı deneyimi yalnızca kıyaslamalarda ölçülmez; günlük yaşamda da, Akışkanlık hissi, saniyede belirli bir token eşiğini aştığınızda ortaya çıkarBir kullanıcı, sohbet için limitinin saniyede 4 token, hikaye yazma için ise saniyede 10 token civarında olduğunu, bunun altında etkileşimin yavaş olduğunu belirtti.

Yerel olarak bir LLM programı yürütmeyi denerseniz, üç durumla karşı karşıya kalırsınız. Bir masaüstü işlemcisinde, Saniyede 1-2 jetonun hareket etmesi normaldir, uzun cevaplar için uygun değil. Üst düzey bir oyun GPU'suyla saniyede yaklaşık 5 token alabilirsiniz. NVIDIA H100 ile, evet, zaten saniyede 60 token'dan bahsediyoruz. ama bu masaüstü donanımı değil, veri merkezi donanımı.

Bulutta neler oluyor? En güçlü sağlayıcılar, özel donanım ve optimize edilmiş çıkarım yığınları sayesinde bu rakamları aşıyor. ChatGPT‑119'te saniyede ortalama 4, Gemini'de ise 168 token raporlandı.DeepSeek gibi popüler açık kaynaklı modeller ise saniyede 21 token civarında seyrediyor. Bunu kelimelere çevirirsek, saniyede 119 token, saniyede yaklaşık 90 kelimeye denk geliyor.

Operasyonel sonuç: Çoğu kullanıcı için, Bilgisayarda yapay zeka çalıştırmak mümkün, ancak yavaşlığı nedeniyle pratik değilRahat hızlarda ve kısa gecikmelerle çalışmak için yönetilen hizmetler hala mantıklı bir seçenek olmaya devam ediyor.

Uç noktanızı TPS'ye göre nasıl boyutlandırırsınız ve gecikmeden ne beklersiniz?

Boyutlandırma için pratik adımlar. İlk olarak, kullanım durumunuzu özetleyin: Giriş ve çıkış belirteçlerinin ortalama sayısı, uzunluk dağılımı ve beklenen eşzamanlılıkİkinci olarak, istek başına sürdürülen saniye başına TTFT ve belirteçleri içeren temsili bir veri kümesiyle bir yük testi çalıştırın.

Ardından, yapılandırmayı deseninizle uyumlu hale getirin. İş yükünüz Databricks referansına benziyorsa (2048 giriş, 256 çıkış), İsteğin istenen gecikme bütçesi içinde kalmasını sağlayacak şekilde saniye başına düşen belirteç aralığını seçinÇıktıyı çoğaltmanın genellikle girdiyi çoğaltmaktan daha pahalıya mal olduğunu ve etkili eşzamanlılığın gerçek otomatik ölçeklemeye bağlı olduğunu unutmayın.

İzleyin ve ayarlayın. Metrikleri takip edin sağlanan eşzamanlılık, kuyruklar, TTFT ve TPOTve SLO'larınızla karşılaştırın. Kapasiteniz yetersizse, aralığı genişletin; fazla kaynaklarınız varsa, aralığı azaltın ve tasarruf etmek için blokları ayarlayın. Gerçek ölçekleme formülü, yeterli sayıda kopya oluşturmadığı takdirde uç noktanın neden yapılandırıldığı gibi performans göstermediğini anlamanıza yardımcı olacaktır.

Son olarak, senaryonun farkında olun. Etkileşimli sohbet robotu tarzında, token başına 0,5 saniye ve 30 ms TTFT hedefleyin Bu, size birinci sınıf bir kullanıcı deneyimi sunacaktır. Sunucu modunda, belirteç başına 2 saniye ve 100 ms makul değerlerdir ve çevrimdışı modda, kıyaslama ölçütünün gerektirdiği doğruluğu korurken maksimum verim elde etmeyi hedefler.

MLPerf trendlerine baktığımızda vektör açıkça görülüyor: Daha fazla bağlam, daha fazla belirteç ve daha iyi verimlilik teknikleri —Ayrıştırılmış hizmet, FP4/FP8, yapılandırılmış budama, özel çekirdekler, KV önbellek zamanlaması— hem çip başına hem de sistem başına token tavanını yıldan yıla iki kat yukarı itiyor.

Databricks ve MLPerf'in çizdiği genel tablo tutarlıdır: LLM'de maliyet, gecikme ve ölçeklenebilirlik hakkında akıl yürütmenin doğru yolu, saniye başına düşen token sayısı cinsinden düşünmektir.İyi bir temsili kıyaslama, TTFT/TPOT ölçümleri ve iyi kalibre edilmiş otomatik ölçekleme ile altyapıyı aşırı boyutlandırmadan hızlı ve istikrarlı yanıtlar sunmak mümkündür.