NVIDIA H100 ile Llama 2 70B'yi Turbo Şarj Edin

Perplexity’nin yanıt motorunda performans arayışı, bizi NVIDIA ve AWS'nin sunduğu en son teknolojiyi benimsemeye yöneltiyor. Bu blog yazısında, en son deneylerimizin sonuçlarını paylaşmaktan heyecan duyuyoruz: Çeşitli donanım ve yazılım ayarlarında Llama 2 70B çıkarımının bir karşılaştırması.

LLM çıkarım platformumuz pplx-api, açık kaynaklı kütüphaneler tarafından desteklenen son teknoloji bir yığın üzerine kurulmuştur. pplx-api'nin halka açık betasının Ekim ayında başlamasından bu yana, ölçeklendirme zorluklarıyla mücadele ediyor ve devasa ölçekte ulaşmak için yapılandırmamızı en iyi nasıl optimize edeceğimizi öğreniyoruz. Bu bizi aşağıdaki rehber sorularla deneyler yapmaya yöneltti:

GPU'larımızı NVIDIA A100'den NVIDIA H100'e geçirdiğimizde, diğer tüm ayarlar aynı kalırken ham performans kazancı nedir?

H100'ün yerel destek eklediği 8 bitlik kayan nokta (fp8) nicemlemesinin verimlilik kazancı nedir? Bu nicemlemenin doğruluk maliyeti nedir?

Tensör paralelliği ve yığın boyutu, gecikmeyi ve token aktarım hızını nasıl etkiler?

Yukarıdakiler göz önüne alındığında, hangi yapılandırma performans ve maliyet verimliliğinin en ölçeklenebilir dengesini sağlar?

Ağ gecikmesinden kaçınmak için aşağıdaki deneyi bir dizi yerel kıyaslama olarak yürüttük.

Gecikme: Çıkarım sunucusunun tam yanıtını oluşturmasının toplam süresi.

Aktarım Hızı: Çıkarım sunucusunun tüm kullanıcılar ve istekler genelinde saniye başına, GPU başına üretebileceği çıktı token sayısı.

Aşağıdaki faktörler temel metrikleri etkileyecektir, bu nedenle bunları deneyin farklı denemeleri boyunca tutarlı tuttuk.

Performans, LLM'in boyutuyla ölçeklenir. Daha fazla parametre, daha yavaş çıkarımla sonuçlanan daha fazla hesaplama gerektirir. Örneğin, diğer ayarlar eşit olduğunda Llama 2 13B, Llama 2 70B'den daha hızlıdır. Bu deneyde Llama 2 70B'ye bağlı kalıyoruz çünkü en yetenekli açık kaynaklı modellere hizmet vermeyi optimize etmek istiyoruz.

Her örnek istek/yanıt çiftindeki girdi ve çıktı token miktarı performans ölçümlerini etkileyebilir. Genel olarak, çıktı token üretimi genel yanıt süresine hakimdir. Veri örneklemesi yalnızca LLM'den "evet/hayır" yanıtları aldığında, yanıt, LLM'den deneme yazmasını isteyen örneklere kıyasla daha hızlıdır. Veri kümemiz, 512 çıktı token'ı üreten 1024 girdi token'ı içeren sentetik isteklerden oluşur. Bu dağılım, Llama2 70B'nin halka açık dağıtımımızda gözlemlenen trafik dağılımıyla eşleşmesi için seçilmiştir.

NVIDIA TensorRT-LLM (v0.5.0 sürümü), LLM çıkarımını optimize etmek için açık kaynaklı bir kütüphanedir. 2023'ün sonlarında piyasaya sürüldü, NVIDIA'nın birçok çıkarım optimizasyonunu sentezler ve bu deneyin ana parametreleri için esnek bir özelleştirme katmanı sağlar: yığın boyutu, nicemleme ve tensör paralelliği.

4 yapılandırma ekseni üzerinde deney yaptık: tensör paralelliği, GPU mimarisi, nicemleme ve maksimum yığın boyutu. Bu eksenler birbirine bağlıdır çünkü her biri GPU belleğinin kritik darboğaz kaynağı açısından bir ödünleşimi temsil eder.

Dokuzuncu nesil Hopper (H100-HBM3-80GB / p5.48xlarge) GPU mimarisi, selefi Ampere'e (A100-SXM4-80GB / p4de.24xlarge) kıyasla 2 kat - 6 kat hesaplama oranları ve neredeyse 2 kat GPU bellek bant genişliği dahil olmak üzere devasa bir özellik listesi barındırır. GPU bellek bant genişliği, çıkarım için kritik bir ölçüttür çünkü çıkarımın matris çarpımlarının birincil gecikme darboğazı, model verilerinin gigabaytlarını GPU belleğinden hesaplama yazmaçlarına yüklemekten kaynaklanır. Bu istatistiklere dayanarak, NVIDIA H100 ve A100'ün birebir karşılaştırmasının hem gecikmede hem de aktarım hızında 2 kat iyileşme göstereceğini varsaydık.

NVIDIA H100 ve A100 arasındaki bir diğer önemli fark, H100 tensör çekirdeğinin yerel olarak 8 bitlik kayan nokta (fp8) talimatları için desteği eklemesi ve bu da aşağıda detaylandırılan daha fazla optimizasyonun kapısını açmasıdır. Bu yüzden fp8 ve fp16'yı özellikle H100 için kullanıyoruz.

Bu deneyde GPU başına belleği tutarlı tutmak için hem NVIDIA A100'lerimiz hem de H100'lerimiz için 8x80GB GPU belleğine sahip düğümlere bağlı kaldık. Daha yüksek yığın boyutlarını etkinleştirmenin yanı sıra, GPU belleği önemlidir çünkü modelin parametreleri hızlı erişim için sunucu başlangıcında GPU belleğine yüklenir. Örneğin, modelimizdeki 70 milyar parametrenin her biri 16 bitlik kayan nokta sayısı ise, model yaklaşık 140 GB boyutundadır ve bu tek bir GPU'ya sığmaz. Bu nedenle, aşağıda açıkladığımız tensör paralelliğine ihtiyaç duyulmaktadır.

Tensör paralelliği, çıkarım sunucusunu çalıştırmak için tüketilen GPU cihazlarının sayısını ifade eder. Bir dizi GPU ayırdığımızda, TensorRT-LLM, Llama2 70B'yi çalıştırmak için gereken minimum bellek bütçesine ulaşmamıza yardımcı olmak için kaynaklarını bir araya getirir. Hipotezimiz, daha düşük tensör paralelliğinin, daha yüksek tensör paralelliğiyle karşılaştırıldığında daha yüksek gecikmeyle (her bir yığını karşılamak için daha az kaynak tüketildiğinden) ancak GPU başına daha yüksek aktarım hızıyla (daha iyi kullanım nedeniyle) sonuçlanacağıdır.

Nicemleme, sinir ağları tarafından kullanılan ağırlıklar ve aktivasyonlardaki hassasiyetin azalmasıdır. Bu tekniği, fp16'dan fp8'e geçtiğimizde GPU bellek tüketimini yarıya indirmek için kullanıyoruz. Bu, aynı modeli daha düşük toplam GPU bellek kullanımıyla çalıştırmayı mümkün kılar ve bu da aktarım hızını artıran daha düşük tensör paralelliğini etkinleştirir.

Nicemleme uygulamaları doğruluğu düşürme potansiyeline sahiptir. Bu nedenle, WikiText derleminde LLM'in bir cümledeki sonraki her token'ı ne kadar iyi tahmin ettiğinin bir ölçüsü olan şaşkınlık istatistiklerini karşılaştırarak farklı hassasiyetler için doğruluğu değerlendirdik. 8 bitlik kayan nokta ve 8 bitlik ağırlık için 8 bitlik aktivasyon ve SmoothQuant (w8a8 SQ) ile WikiText üzerindeki fp16'ya kıyasla şaşkınlıkta önemli bir değişiklik olmadı (< %1), bu yüzden devam etmekten kendimizden emindik. Bununla birlikte, w4a16, muhtemelen daha da düşük hassasiyet ve int4 ile fp16 arasındaki gerekli dinamik dönüştürmeler nedeniyle şaşkınlıkta önemli bir %7 değişiklik sergiledi.

Yığunlama yoluyla paralellik, kaynak kısıtlı bir sistemden performans elde etmek için klasik bir stratejidir. Sinir ağından her ileri geçişte birden fazla isteği işleyerek, yığınlamanın biraz gecikme pahasına aktarım hızını arttırdığı bilinmektedir. Yığınlama ayrıca daha yüksek GPU bellek tüketimine neden olur çünkü dikkat mekanizmasını yöneten KV önbelleğinin boyutu yığın boyutuyla doğrusal olarak büyür.

Llama 2 70B (80 katmanı olan) durumunda, 4096 bağlam boyutu için 32 yığın boyutuna sahip fp16, KV önbelleğinin boyutu önemli bir 40 GB olarak ortaya çıkmaktadır. Bu durum, yalnızca ağırlıkları 140 GB tutan Llama 2 70B fp16'nın, tensör paralelliği 2'de (TP-2) mevcut olan 160 GB GPU belleğine rahatça sığmasını engellemektedir.

Deneyin 4 değişkeninin uyumlu kombinasyonlarını taradık ve aşağıda en bilgilendirici trendleri sunuyoruz.

Şekil 1 - Hepsi 8 mevcut GPU ile en iyi gecikmeyi sağlayan 8 tensör paralelliğine sahip beş farklı yapılandırma genelinde değişen yığın boyutuna sahip isteklerin gecikmesi. Her yapılandırma içinde, yığın boyutu 1'den 32'ye çıkarıldığında gecikme genellikle iki katına çıkar ve 32'den 128'e tekrar iki katına çıkar. Yeterince büyük yığın boyutlarında, H100 A100'e kıyasla gecikmeyi yaklaşık olarak yarıya indirir. A100 karma hassasiyet kullanır çünkü mimari fp8 için yerel desteğe sahip değildir. SmoothQuant (SQ) içeren w8a8, fp8'e benzemek üzere tasarlanmıştır.

Nicemlemenin gecikme iyileştirmesi, H100 fp16 → fp8 ve A100 fp16 → SmoothQuant ile w8a8 karşılaştırıldığında %10 civarındadır. Bununla birlikte, karma hassasiyetli w4a16 aslında düşük yığın boyutlarında daha iyi ve fp16'ya kıyasla daha yüksek yığın boyutlarında daha kötü performans gösterir. Bu, daha az optimize edilmiş hesaplama çekirdekleri, int4 ve fp16 arasındaki atım süresi ve w4a16'nın aktivasyonlar için hala 16 bitlik kayan noktalar kullanması ve KV önbelleğinin boyutlarında tasarruf sağlanamaması dahil olmak üzere bir dizi faktörden kaynaklanabilir. w4a16 ayrıca daha düşük doğruluk gösterdiğinden, A100'ler için w8a8 SQ'ya ve H100'ler için fp8'e bağlı kalmamız gerektiği sonucuna varıyoruz.

Şekil 2 - Farklı mimari, nicemleme ve yığın boyutu ile TP-8 yapılandırmaları genelinde aktarım hızı. Her mimari ve nicemleme için, benzer gecikmeye sahip yapılandırmaları karşılaştırmamız için 25600ms (512 token için saniyede 20 token) gecikme gereksinimini karşılayan en büyük yığın boyutu seçilmiştir. Bu gereksinim altında, BS-128'li H100, aynı nicemlemeyi (fp16) kullanan A100 BS-64'e kıyasla %228 aktarım hızına ulaşır ve iki katına çıkan yığın boyutuna rağmen daha düşük yanıt gecikmesine bile sahiptir. fp8 ile nicemleme bu faktörü %251'e çıkarır.

İlk iki şeklimizde, yalnızca TP-8 yapılandırmalarını sunuyoruz. H100, her ikisi de fp16 / BS-128 / TP-8 kullandığında A100'e kıyasla %54 gecikme ve %184 aktarım hızı elde eder; bu oran H100 üzerinde fp8 kullanıldığında %49 gecikmeye ve %202 aktarım hızına yükselir. Performanstaki bu iyileştirme, H100 ve A100 arasındaki hesaplama gücü ve bellek bant genişliğindeki artışlara bağlanabilir. Özellikle, fark, kullanımın daha düşük olabileceği daha düşük yığın boyutlarında daha az belirgindir.

Platformumuzu oluştururken, aktarım hızını en üst düzeye çıkarırken kullanıcılarımız için belirli gecikme gereksinimlerini karşılamak istiyoruz. Bu nedenle, A100 ile H100'ü aynı yığın boyutunda karşılaştırmak yerine, aktarım hızlarını yalnızca bir gecikme gereksinimini karşıladıkları yapılandırmalar altında karşılaştırmamız aslında daha mantıklıdır. 512 çıktı token'ının tamamlanması için 25600ms gecikmede bir sınır belirledik ve H100 / TP-8 / fp8 / BS-128'in, A100 / TP-8 / fp16 / BS-64'e kıyasla %251 aktarım hızı sağladığını bulduk, çünkü daha düşük bir gecikmede iki katı yığın boyutunu işleyebilmektedir. Nicemlemenin GPU belleği tasarrufu sağladığı göz önüne alındığında, artık tensör paralelliğinin bir sonraki optimizasyon katmanını nasıl ekleyebileceğini değerlendirmemiz gerekiyor.

Şekil 3 - H100 fp8 için değişen yığın boyutları ve tensör paralelliği genelinde gecikme. Yığın boyutu 1'den 32'ye çıkarıldığında gecikme genellikle iki katına çıkar ve 32'den 128'e tekrar iki katına çıkar. Yığın boyutları eşit olduğunda TP-2, sürekli olarak TP-8'den yaklaşık iki kat daha yavaştır. Yığın boyutunu iki katına çıkarırken tensör paralelliğini iki katına çıkarmak, GPU'lar başına işlenen yığın sayısı eşit kaldığı için gecikmeyi nispeten kararlı tutar.

Nicemleme ve mimari söz konusu olduğunda, net kazananlar vardır: H100, A100'e üstünlük sağlar ve azaltılmış hassasiyetli nicemleme bellek kullanımını, gecikmeyi ve aktarım hızını iyileştirir. Bununla birlikte, yığın boyutu ve tensör paralelliği temel metriklerimizde bir ödünleşim sunar. Daha büyük bir yığın boyutu, artan gecikme ve bellek tüketimi pahasına aktarım hızını optimize eder. Öte yandan, daha yüksek tensör paralelliği mevcut belleğin toplam havuzunu artırır ve gecikme için optimize eder, ancak dağıtılmış matris çarpımının senkronizasyon maliyetleri nedeniyle ve daha fazla GPU kaynağını kilitlemesi erdemiyle aktarım hızıyla ödünleşir.

Şekil 4 - H100 fp8 için değişen yığın boyutları ve tensör paralelliği genelinde aktarım hızı. En yüksek aktarım hızı, A100/TP-8/fp16/BS-64 taban çizgisine kıyasla %460 ile TP-2 BS-128'den gelir. Bununla birlikte, TP-2 BS-128 aynı zamanda Şekil 3'teki en yavaş sonuçtur.

Deneyimizin aktarım hızını en üst düzeye çıkaran yapılandırması, GPU başına saniyede 767 çıktı token'ı ile H100 / fp8 / TP-2 / BS-128'dir. Bu, A100 / fp16 / TP-8 / BS-64'e kıyasla %460 bir iyileştirmedir. Bununla birlikte, iki katına çıkan gecikme (512 çıktı token'ı için 42000ms'ye daha yakın) pahasına gelir, bu nedenle bir üretim yapılandırması olarak uygun olmayabilir. TP-4 BS-128 (26188ms yanıt süresinde 626 tok/sn/gpu) ve TP-2 BS-32 (18821ms yanıt süresinde 435 tok/sn/gpu) sonuçları, temel metriklerimizde daha iyi ödünleşimleri temsil edebilir.

Sonuçlarımız şunları göstermektedir:

Aynı yapılandırma göz önüne alındığında A100'e kıyasla H100 kullanarak %54 gecikme ve %184 aktarım hızı elde ediyoruz; bu oran H100 fp8 için yerel desteğinden yararlandığında sırasıyla %49 ve %202'ye yükselir.

Bir gecikme kısıtlamasına tabi olarak aktarım hızı en üst düzeye çıkarıldığında, H100 / fp8 / TP-8 / BS-128, daha hızlı bir hızda iki katı yığını işleyebileceğinden, A100 / fp16 / TP-8 / BS-64'e kıyasla %251 aktarım hızı sağlar.

fp8 ile TP-2'ye sahip H100'den yararlanarak, gecikmede %10'dan az bir artışla A100 / fp16 / TP-8 / BS-128'in %373 aktarım hızına ulaşabiliriz.

Yığın boyutu ve tensör paralelliği, bir LLM çıkarım sisteminin operatörüne aktarım hızı ve gecikme arasında bir ödünleşim sunar.

Bu sonuçlar, daha önce A100 tarafından desteklenen donanım yığınımızda H100 GPU'larına tam bir geçiş konusunda kendimizden emin olmamızı sağlıyor. NVIDIA tarafından duyurulan performans kazançlarını teyit edebilmekten heyecan duyuyoruz ve hızlandırılmış donanımdaki sonraki atılımlarını dört gözle bekliyoruz.

Optimizasyon için bir sonraki sınırımız, Llama 2 70B'nin GPU bellek ayak izini önemli ölçüde azaltabilecek ve gecikmede 2 kata varan iyileştirmeler sağlayabilecek yapılandırılmış seyrelikliğin ve int4 hassasiyetinin doğruluk ve performans etkisini incelemektir. İnanılmaz derecede hızlı çıkarım yolculuğuna devam etmekten heyecan duyuyoruz ve kullanıcılarımızın platformumuzun üzerine güçlü uygulamalar oluşturmalarını sağlamayı umuyoruz.

Yakın vadede pplx-api, oran limitlerini kaldıracak ve gerçekler için zemin oluşturan internet destekli bir LLM dahil olmak üzere daha özel Perplexity LLM'leri sunacak.

perplexity.ai/pro adresinden Perplexity Pro'ya kaydolun. En son teknolojimiz olan pplx-api'ye erişin ve projelerinizde bu gelişmiş yeteneklerden yararlanın. Blogumuzda pplx-api hakkında daha fazla bilgi edinin.

Yapay zekanın geleceğini şekillendirmekle ilgileniyor musunuz? İşe alım yapıyoruz! Devasa ölçekli, üretken LLM altyapısını yönlendiren bir ekibin parçası olun. Perplexity Careers adresindeki fırsatları keşfedin.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Deneysel kurulum

Temel Metrikler:

Sabitler:

Y 模型

Girdi/Çıktı Token Veri Kümesi

Yazılım Sürümü

Değişkenler

GPU mimarisi

Tensör Paralelliği

Nicemleme

Yığın Boyutu

Sonuçlar

Sonuç

Sırada Ne Var

Yazarlar: