GPU Maliyetlerini Boşa Harcamayı Durdurun! 3 Adımlı Trafo Optimizasyon Kılavuzu

GPU faturaları, Transformer iş akışındaki küçük seçimlerden artabilir. Büyük bir model kullanabilir, dolgulu girdiler gönderebilir, tam hassasiyetli matematik çalıştırabilir ve istekler arasında GPU'yu bekletebilirim. Her seçim, çıktıyı her zaman iyileştirmeden maliyeti artırır. Model kalitesini gözden geçirirken israfı azaltmak için üç pratik adım kullanıyorum. ## Adım 1: Dolguyu azaltın ve dizi uzunluğunu kontrol edin Transformatörler, giriş şeklindeki her jetonu işler. Bir isteğin 80 jetonu ve diğerinin 900 jetonu varsa, her ikisini de 900 jetona doldurmak, daha kısa olan isteğin gerekenden daha fazla GPU belleği kullanmasına neden olur. Benzer uzunluktaki istekleri gruplandırıyorum ve kullanışlı bir belirteç limiti belirliyorum. python from transformatörler import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased") toplu = tokenizer( texts, padding=True, truncation=True, max_length=512, return_tensors="pt" ) Dinamik dolgu genellikle her numuneyi sabit bir uzunluğa doldurmaktan daha iyi bir seçimdir. Metin sınıflandırması için 128, 256 ve 512 token gibi limitleri test edebilirim. En iyi ayar verilere bağlıdır. Kısa müşteri mesajlarını işleyen bir destek ekibinin 512 jeton sınırına ihtiyacı olmayabilir. Yasal bir belge modeli daha uzun girdilere ihtiyaç duyabilir ancak yine de uzunluğa dayalı toplu işlem yoluyla kullanılmayan alanı kaldırabilir. Test sırasında üç sayıyı takip ediyorum: - Ortalama giriş uzunluğu - GPU bellek kullanımı - Sabit bir doğrulama kümesinde model kalitesi Daha düşük bir belirteç sınırı maliyeti azaltabilir, ancak yararlı bağlamı ortadan kaldırabilir. Limiti bir tahminden ziyade ölçülmüş bir seçim olarak ele alıyorum. ## Adım 2: Model çıktısını kontrol ettikten sonra karma hassasiyet kullanın Birçok modern GPU, seçilen Transformer işlemlerini FP16 veya BF16 ile çalıştırabilir. Bu formatlar FP32'ye göre daha az bellek kullanır ve verimi artırabilir. PyTorch ile çıkarım yapmak için otomatik yayını şu şekilde test edebilirim: python import torch model.eval() with torch.no_grad(): with torch.autocast( Device_type='cuda", dtype=torch.float16 ): Output = model(**batch) BF16, FP16'dan daha geniş bir sayısal aralığa sahip olduğundan, desteklenen donanımlarda iyi bir seçenek olabilir. python with torch.no_grad(): with torch.autocast( devices_type='cuda", dtype=torch.bfloat16 ): çıktı = model(**batch) Sonuçları kontrol etmeden hassasiyeti değiştirmem. Doğruluğu, F1 puanını, yanıt kalitesini, hata oranlarını ve gecikmeyi FP32 temel çizgisiyle karşılaştırıyorum. Bir metin sınıflandırıcı, FP16'ya geçtikten sonra neredeyse hiç kalite değişikliği göstermeyebilir. Hassas sayısal işlemlere sahip bir modelin daha fazla teste ihtiyacı olabilir. Donanım da önemli, bu yüzden her test sırasında GPU türünü ve yazılım sürümlerini kaydediyorum. Bu adım, model, CUDA kurulumu ve PyTorch sürümü seçilen veri türünü desteklediğinde en iyi sonucu verir. ## Adım 3: GPU'yu toplu işlem yapma ve yeniden kullanmayla meşgul edin Bir GPU, tek tek gönderilen birçok küçük istekten daha verimli bir şekilde birden fazla isteği birlikte işleyebilir. Küçük gruplar cihazın bir kısmını boşta bırakabilirken, çok büyük gruplar bellekte baskıya neden olabilir. 4, 8, 16 ve 32 gibi toplu iş boyutlarını test ediyorum. Her boyut için şunları ölçüyorum: - Saniyede işlenen istekler - Ortalama yanıt süresi - En yüksek GPU belleği - Zaman aşımı veya hata oranı Pratik bir hizmet, kısa bir toplu işlem penceresi kullanabilir. Bu pencere içinde gelen istekler tek bir grupta gruplandırılır. Pencere, beklenen yanıt süresine yetecek kadar küçük kalmalıdır. Tekrarlanan metinler için, sonucun önbelleğe alınmasının güvenli olduğu çalışmaları da yeniden kullanıyorum. Bir ürün arama hizmeti aynı kategori etiketlerini veya kısa sorguları birçok kez alabilir. Bu sonuçların önbelleğe alınması tekrarlanan model çağrılarını azaltabilir. Yalnızca kod çözücüye yönelik dil modelleri için KV önbelleği, belirteç oluşturma sırasında tekrarlanan dikkat çalışmalarını azaltabilir. vLLM ve Hugging Face Metin Oluşturma Çıkarımı gibi hizmet araçları, oluşturma iş yüklerinin yönetilmesine yardımcı olan özellikleri destekler. Sonuçlar modele ve istek uzunluğuna göre değiştiği için bellek kullanımını ve yanıt süresini hala kendi trafiğimde test ediyorum. Basit bir izleme tablosu, yalnızca GPU kullanımına dayalı kararlardan kaçınmama yardımcı oluyor: | Testi | Parti boyutu | Hassasiyet | Jetonlar/talep | Gecikme | GPU belleği | Kalite | |---|---:|---|---:|---:|---:|---:| | bir | 1 | FP32 | 256 | Kayıt | Kayıt | Temel | | B | 8 | FP16 | 256 | Kayıt | Kayıt | Karşılaştır | | C | 16 | FP16 | 128 | Kayıt | Kayıt | Karşılaştır | Hizmet hedefini kabul edilebilir kalitede karşılayan kurulumu seçerim. Yavaş yanıtlara veya daha fazla başarısız isteklere neden oluyorsa, en düşük bellek okuması her zaman en iyi seçenek değildir. Ana ders basittir: Kullanılmayan belirteçleri azaltın, düşük hassasiyetli matematiği test edin ve çalışmayı uygun gruplar halinde GPU'ya gönderin. Her seferinde bir değişiklik yapıyorum, aynı test setini saklıyorum ve hem maliyet hem de model kalitesini karşılaştırıyorum. Yararlı bir başlangıç ​​planı şuna benzer: 1. Mevcut token uzunluğunu, gecikmeyi, bellek kullanımını ve GPU saatlerini ölçün. 2. Dinamik dolgu ekleyin ve daha küçük bir jeton limitini test edin. 3. FP16 veya BF16'yı mevcut hassasiyetle test edin. 4. Toplu iş boyutlarını üretim benzeri trafikle test edin. 5. Hizmet hedefine zarar vermeden GPU kullanımını düşüren ayarları koruyun. Bu adımlar test ihtiyacını ortadan kaldırmaz. Daha büyük bir GPU'ya geçmeden veya modeli değiştirmeden önce boşa harcanan hesaplamayı bulmam için bana net bir yol sunuyorlar.

GPU faturaları model kalitesinden daha hızlı büyüyebilir. Asıl sorun kullanılmayan bellek, doldurulmuş jetonlar veya iş yüküyle eşleşmeyen toplu iş boyutu olduğunda ekiplerin daha büyük kartlar eklediğini gördüm. Bir Transformer'ın varsayılan olarak en pahalı GPU'ya ihtiyacı yoktur. Üç kontrolle başlıyorum: iş yükünü ölçün, boşa harcanan hesaplamayı azaltın ve daha düşük maliyetli bir yürütme yolu seçin. ## Adım 1: Modelin gerçekte ne kullandığını ölçün Temel verileri toplamadan önce GPU'yu değiştirmiyorum. Takip: - GPU bellek kullanımı - GPU kullanımı - Saniye başına işlenen jeton sayısı - Talep gecikmesi - Toplu iş boyutu - Giriş sırası uzunluğu - Veri yükleme ve ön işlemede harcanan süre %35 kullanımda kalan bir GPU'nun daha fazla belleğe veya daha yeni bir karta ihtiyacı olmayabilir. Model CPU'yu bekliyor, istekleri tek tek alıyor veya yoğun şekilde doldurulmuş girişleri işliyor olabilir. BERT tabanlı bir sınıflandırıcı için, iki grubu karşılaştırın: - 512 belirteçle doldurulmuş 16 metin - o kümedeki en uzun metinle doldurulmuş 16 metin İkinci grup çok daha az doldurma belirteci içerebilir. Kesin kazanç veriye, modele ve donanıma bağlıdır, bu yüzden bunu aynı test seti ve istek modeliyle ölçüyorum. Yararlı araçlar şunları içerir: bash nvidia-smi PyTorch iş yükleri için, belleği ve yürütme süresini de kaydederim: python start = torch.cuda.Event(enable_timing=True) end = torch.cuda.Event(enable_timing=True) start.record() with torch.inference_mode(): çıktı = model(**inputs) end.record() torch.cuda.synchronize() print(f"{start.elapsed_time(end):.2f} ms") print(torch.cuda.memory_allocated() / 1024**2, "MB") Tek bir hızlı çalışma beni yanıltabilir. Isınma isteklerini kullanıyorum ve birkaç çalıştırmada ortalama gecikmeyi bildiriyorum. ## Adım 2: Boşa harcanan jetonları ve gereksiz işleri ortadan kaldırın Sıra uzunluğunun Transformer maliyeti üzerinde doğrudan etkisi vardır. Uzun girişler, tokenlerin çoğu çok az değer katsa bile hafızayı tüketebilir. Dinamik dolgu kullanıyorum: python tokenizer( texts, padding=True, truncation=True, max_length=256, return_tensors="pt" ) max_length değeri görevden gelmelidir. Bir destek bileti sınıflandırıcısı 128 veya 256 jetonla iyi çalışabilirken, bir belge modeli daha fazla bağlama ihtiyaç duyabilir. Daha kısa bir girdinin güvenli olduğunu varsaymak yerine her değişiklikten sonra kaliteyi test ediyorum. Çıkarım için değerlendirme modunu da etkinleştiriyorum: python model.eval() torch.inference_mode() ile: çıktı = model(**inputs) Bu, eğitimle ilgili çalışmaların tahmin sırasında saklanmasını önler. Toplulaştırmanın pratik bir sınıra ihtiyacı vardır. Daha büyük bir toplu işlem verimi artırabilir ancak gecikmeyi ve bellek kullanımını artırabilir. 1, 8, 16 ve 32 gibi çeşitli boyutları test ediyorum ve ardından hizmet hedefine uygun bir nokta seçiyorum. ## Adım 3: Kalite kontrolleriyle daha düşük hassasiyetli çıkarımı kullanın Birçok Transformer çıkarım işi, desteklenen GPU'larda FP16 veya BF16'yı kullanabilir. python with torch.inference_mode(), torch.autocast("cuda", dtype=torch.float16): çıktı = model(**girişler) BF16, özellikle FP16 sayısal sorunlar oluşturduğunda onu destekleyen donanıma daha uygun olabilir. Şunları karşılaştırırım: - Doğruluk veya F1 puanı - Medyan ve yüksek yüzdelik gecikme - Saniyedeki jeton sayısı - En yüksek GPU belleği - Hata durumları Niceleme, çıkarım için başka bir seçenektir. Sonuç kitaplığa, model mimarisine, GPU'ya ve iş yüküne bağlı olsa da, 8 bitlik veya 4 bitlik bir model bellek gereksinimlerini azaltabilir. Nicelenmiş modeli bir hizmete taşımadan önce temsili veriler üzerinde doğrularım. Pratik bir yol şuna benzer: 1. Mevcut modelin ve trafiğin profilini çıkarın. 2. Dolguyu azaltın ve test edilmiş bir sıra sınırı ayarlayın. 3. Çıkarım modunu etkinleştirin ve toplu iş boyutunu ayarlayın. 4. FP16 veya BF16'yı test edin. 5. Kuantizasyonu ancak daha önceki değişiklikler anlaşıldıktan sonra ölçün. Ana dersim basit: GPU maliyeti genellikle yalnızca model boyutundan ziyade verimsiz uygulamayı yansıtır. Daha küçük bir girdi, daha iyi bir parti ve ölçülmüş bir hassasiyet ayarı, Transformer'ın mevcut donanımını daha etkili bir şekilde kullanmasına yardımcı olabilir. Bu kontroller sonrasında iş yükü hala hedefi aşıyorsa GPU'nun yükseltilmesi bir tahminden ziyade daha net bir teknik karar haline geliyor.

Bir ürünün çok sayıda kullanıcısı olmadan transformatör çıkarımı pahalı hale gelebilir. Bir model testte iyi yanıt verebilir, ancak birkaç istek bir araya geldiğinde yavaşlayabilir. GPU belleği doluyor, uzun istemler gecikmeyi artırıyor ve oluşturulan her jeton faturaya ekleniyor. Daha hızlı ve daha ucuz transformatör çıkarımının genellikle üç pratik değişiklikten kaynaklandığını keşfettim: 1. Göreve uygun bir model ve hassasiyet kullanın. 2. Kontrol istemleri, sıra uzunluğu ve istek toplu işlemi. 3. Modeli, donanımı iyi kullanan bir çıkarım motoruyla çalıştırın. Doğru sıra sisteme bağlıdır ancak ölçüm süreci aynı kalır. Herhangi bir şeyi değiştirmeden önce gecikmeyi, saniye başına belirteçleri, bellek kullanımını ve istek başına maliyeti kaydedin. 1. Her isteğin ihtiyaç duyduğu işi azaltın Büyük bir model, odaklanılan bir görev için her zaman en uygun seçenek olmayabilir. Bir destek botu yalnızca biletleri sınıflandırıyor veya ürün adlarını çıkarıyorsa, daha küçük bir model aynı iş sonucunu daha az bellek ve daha düşük gecikmeyle sağlayabilir. Genellikle üç soruyu işaretliyorum: - Görevin açık uçlu oluşturulması gerekiyor mu? - Modelin uzun bir bağlam penceresine ihtiyacı var mı? - Daha büyük bir modelin sağladığı ekstra doğruluk kullanıcıya fayda sağlar mı? Birçok metin sınıflandırma görevi için kompakt bir kodlayıcı modeli yeterli olabilir. Üretim için, komut açık olduğunda ve çıktı formatı sınırlı olduğunda talimat ayarlı daha küçük bir model işe yarayabilir. Niceleme, model ağırlıkları için kullanılan bit sayısını azaltabilir. FP16'dan INT8'e veya desteklenen bir 4 bit formata geçiş, bellek kullanımını azaltabilir ve bir GPU'da daha fazla isteğe izin verebilir. Etki modele, donanıma, kitaplığa ve iş yüküne bağlıdır. Bazı modeller çok az kalite kaybı yaşarken diğerleri uzun biçimli yazma veya araç çağrılarında gözle görülür değişiklikler gösterir. Kuantizasyona serbest hız artışı olarak bakmıyorum. Tam duyarlıklı model için kullanılan değerlendirme setinin aynısıyla test ediyorum. Şunları karşılaştırıyorum: - Görev doğruluğu - Çıktı kalitesi - İlk jetona kadar geçen süre - Saniyede oluşturulan jetonlar - GPU bellek kullanımı - 1.000 istek başına maliyet Pratik bir örnek, kısa yanıtlar için 7B veya 8B dil modelini kullanan bir müşteri destek sistemidir. Ekip aynı GPU üzerinde FP16, INT8 ve 4 bitlik sürümleri test edebilir. 4 bitlik model gerekli yanıt kalitesini korursa ve daha az bellek kullanırsa, sistem başka bir makine eklemeden daha fazla eşzamanlı isteği işleyebilir. Bu sonuç ölçülmeli, varsayılmamalıdır. 2. İstemleri ve grupları kontrol altında tutun Uzun istemler transformatör çıkarımını iki şekilde etkiler. Sistem girişi okumak için daha fazla zaman harcar ve model daha fazla jeton işledikçe anahtar/değer önbelleği büyür. Kullanıcı arayüzünde küçük görünen bir sohbet geçmişi, birçok değişiklikten sonra büyüyebilir. Gereksiz bağlamı şu şekilde azaltırım: - Tekrarlanan sistem talimatlarını kaldırarak - Eski sohbet mesajlarını kırparak - Eski konuşma bölümlerini özetleyerek - Yalnızca mevcut soru için gereken belgeleri göndererek - Pratik bir çıktı belirteci sınırı belirleyerek - Kısa formatlı bir rehber çalışırken büyük örneklerden kaçınarak Daha kısa bir istem, modeli değiştirmeden gecikmeyi artırabilir. Ayrıca servis sağlayıcının jetonlarla faturalandırması durumunda giriş jetonu ücretlerini de azaltabilir. Harmanlama başka bir kullanışlı kaldıraçtır. Bir toplu iş, birden fazla isteği tek bir GPU işleminde birleştirir. Bu, özellikle belge etiketleme veya yerleştirme oluşturma gibi çevrimdışı işler için verimi artırabilir. Çevrimiçi başvuruların daha fazla bakıma ihtiyacı vardır çünkü toplu işlemin tamamını beklemek yanıt süresini uzatabilir. Canlı bir sohbet robotu için şunları ölçüyorum: - İlk jetona kadar geçen süre - Toplam yanıt süresi - Saniyede tamamlanan istekler - Sırada bekleme süresi - Farklı toplu iş boyutlarında performans Sekizlik bir toplu iş boyutu, bir iş yükü için verimi artırabilir ve diğer iş yükü için çok fazla beklemeye neden olabilir. En iyi ayar genellikle sabit bir kuralla değil, küçük bir yük testiyle bulunur. Dinamik toplu işlem, birbirine yakın gelen istekleri gruplandırabilir. vLLM ve NVIDIA TensorRT-LLM gibi araçlar, desteklenen modeller için GPU kullanımını iyileştirebilecek yöntemleri destekler. Yapılandırma hala önemlidir. Bir hizmetin bir kuyruk sınırı, maksimum bekleme süresi ve yanıt süresi hedefi olmalıdır. 3. Modele uyan bir çıkarım çalışma zamanı kullanın Ham Python modeli çağrısı, erken testler için faydalı olabilir. Üretim çıkarımı genellikle bellek, zamanlama ve GPU çekirdekleri üzerinde daha fazla kontrole ihtiyaç duyar. Ortak seçenekler şunları içerir: - Birçok dil modeli isteğini karşılamak için vLLM - NVIDIA GPU dağıtımları için TensorRT-LLM - Desteklenen transformatör modelleri için ONNX Çalışma Zamanı - Model dışa aktarma ve donanıma özel yürütme için Hugging Face Optimum Bu araçlar her model için birbirinin yerine kullanılamaz. Çalışma zamanını değiştirmeden önce model desteğini, niceleme desteğini, akış davranışını, toplu işlem özelliklerini ve dağıtım gereksinimlerini kontrol ediyorum. Otoregresif oluşturmada anahtar/değer önbelleği dikkati hak eder. Model, ara dikkat verilerini saklar, böylece her yeni belirteç için konuşmanın tamamını yeniden hesaplamaz. Bu önbellek, üretimi hızlandırır ancak belleği kullanır. Uzun girişler, uzun çıkışlar ve çok sayıda eş zamanlı kullanıcı, önbelleği ana sınır haline getirebilir. Sayfalandırılmış dikkat ve sürekli toplu işlem, bazı hizmet veren iş yüklerinin önbelleği daha verimli kullanmasına yardımcı olabilir. Sınır koyma ihtiyacını ortadan kaldırmazlar. Hala maksimum giriş jetonlarını, maksimum çıkış jetonlarını ve donanımın işleyebileceği bir eşzamanlılık aralığını tanımlıyorum. Basit bir kıyaslama, üretim benzeri verileri kullanmalıdır: Metin Model: uygulama tarafından kullanılan aynı kontrol noktası Giriş: kısa, orta ve uzun istemler Çıkış: normal jeton limiti Eşzamanlılık: gerektiğinde 1, 4, 8, 16 ve daha fazlası Metrikler: gecikme, verim, bellek, hatalar ve maliyet Her testi birden fazla kez çalıştırırım. İlk istek, model yüklemeyi veya bellek kurulumunu içerebilir, dolayısıyla kararlı durum sonuçlarıyla karıştırılmamalıdır. Bir ekip, çalışma zamanı değişikliğinin ortalama yanıt süresini kısalttığını keşfedebilirken, bir diğeri çok az fayda görebilir çünkü asıl sorun istemlerin büyük boyutlu olmasıdır. Bu nedenle profil oluşturma, bir kurulumu başka bir projeden kopyalamaktan daha önemlidir. En kullanışlı optimizasyon genellikle en az dramatik olanıdır: istemi 12.000 jetondan 3.000'e düşürün, net bir çıktı limiti belirleyin ve oluşturulması gerekmeyen isteklerin gönderilmesini durdurun. Bundan sonra niceleme, gruplandırma ve daha iyi bir çıkarım motoru daha fazla alan sağlayabilir. Transformatör çıkarımını bir ölçüm problemi olarak ele alıyorum. Görev gereksinimlerini karşılayan en küçük modelle başlayın. İstemleri yararlı bir aralıkta tutun. Kesinlik değişikliklerini gerçek değerlendirme verileriyle test edin. Toplu işlemi yalnızca maksimum verim için değil, yanıt hedefi için de ayarlayın. Model ve donanımla eşleşen bir sunum çalışma zamanı seçin. Bu yaklaşım her dağıtımda aynı sonucu vaat etmez. Bu bana gerçek darboğazları bulmam, kaçınılabilir bilgi işlem kullanımını azaltmam ve kullanıcıların gerçekte ihtiyaç duyduğu kaliteden ödün vermeden çıkarım hızını artırmam için net bir yol sağlıyor.

Transformatör modelleri güçlü sonuçlar verebilir, ancak her istek tam hassasiyet, uzun girişler ve büyük boyutlu bir model kullandığında GPU faturaları hızla artabilir. Ekiplerin aktif iş yüklerinden ziyade boş GPU kapasitesine daha fazla para harcadığını gördüm. İyi haber şu ki, tasarrufların çoğu, tam modelin yeniden inşasından ziyade küçük mühendislik değişikliklerinden geliyor. Model kalitesini kontrol altında tutarken GPU kullanımını azaltmanın üç pratik yolunu burada bulabilirsiniz. 1. Modelin desteklediği durumlarda karma hassasiyet kullanın Çoğu transformatör iş yükünün, 32 bit kayan noktalı sayıları kullanmak için her hesaplamaya ihtiyacı yoktur. Karma hassasiyet, hassas hesaplamaları daha güvenli bir hassasiyette tutarken seçilen işlemlerin FP16 veya BF16 ile çalıştırılmasına olanak tanır. Bu, bellek kullanımını azaltabilir ve bu formatları destekleyen GPU'lardaki verimi artırabilir. Daha düşük bellek kullanımı, daha büyük toplu iş boyutuna da olanak tanıyabilir; bu da GPU'nun her çalıştırma sırasında daha fazla isteği işlemesine yardımcı olur. Temel bir PyTorch örneği şuna benzer: python with torch.autocast(device_type='cuda", dtype=torch.float16): Outputs = model(**inputs) Daha yeni veri merkezi GPU'ları için BF16 yararlı bir seçenek olabilir: python with torch.autocast(device_type="cuda", dtype=torch.bfloat16): çıktılar = model(**inputs) Karışık hassasiyeti üretime taşımadan önce modeli küçük bir doğrulama setinde test ederdim. Doğruluğu, yanıt kalitesini, kayıp değerlerini ve hata oranlarını kontrol edin. Bazı modeller çok az değişiklikle FP16 veya BF16 ile çalışır. Diğer modeller, özellikle eğitim sırasında kararsız çıktılar gösterebilir. Yararlı bir test süreci basittir: - Sabit bir dizi değerlendirme örneğini tam hassasiyetle çalıştırın. - Aynı numuneleri karışık hassasiyetle çalıştırın. - Kaliteyi ve gecikmeyi karşılaştırın. - Taşma, 'NaN' değerleri veya oluşturulan metindeki değişiklikleri izleyin. - Ürün hedefinizi karşılayan formatı koruyun. Karma kesinlik genellikle düşük riskli bir başlangıç ​​noktasıdır çünkü model mimarisini değiştirmeden hesaplamaların çalışma şeklini değiştirir. 2. Boşa harcanan jetonları azaltın ve toplu işlemleri iyileştirin Bir dönüştürücü, jetonlar üzerinde bilgi işlem harcar. Uzun istemler, tekrarlanan talimatlar, doldurma ve kullanılmayan çıktı alanı iş yükünü artırır. Genellikle dört değeri ölçerek başlarım: - Ortalama giriş uzunluğu - Ortalama çıkış uzunluğu - Doldurulmuş belirteçlerin yüzdesi - Toplu iş başına işlenen istekler Bu veriler basit bir sorunu ortaya çıkarabilir. Örneğin, bir destek sohbet robotu, çoğu konuşmada 900'den az jeton kullanılmasına rağmen 4.096 jetonluk bir limiti kabul edebilir. Kullanılmayan kapasite bellek planlamasını hâlâ etkiler ve GPU'nun birlikte işlediği istek sayısını sınırlayabilir. Birkaç değişiklik yardımcı olabilir: Tekrarlanan bilgi istemi içeriğini kırpın. Sistem talimatlarına odaklanın. Uygulama yalnızca ilgili bölümleri alabildiğinde, kararlı referans malzemesini istemin dışında saklayın. İstekleri uzunluğa göre gruplandırın. 2.000 jetonluk bir istek ve birkaç 200 jetonluk istek içeren bir grup, büyük miktarda dolgu oluşturabilir. İsteklerin benzer uzunlukta gruplandırılması GPU kullanımını iyileştirebilir. Göreve göre çıktı sınırlarını ayarlayın. Kısa bir sınıflandırma yanıtı, rapor yazma aracıyla aynı oluşturma sınırına ihtiyaç duymaz. Çıkarım için dinamik toplu işlemi kullanın. Bir istek kuyruğu yakındaki istekleri toplayabilir ve bunları modele tek bir toplu iş olarak gönderebilir. Toplu iş penceresi gecikme hedefiniz dahilinde kalmalıdır. Örneğin, metin sınıflandırma hizmeti sunan bir ekip, isteklerin eşit olmayan aralıklarla geldiğini keşfedebilir. Her isteğin tek başına çalıştırılması GPU'nun bir kısmını kullanılmadan bırakır. Küçük bir dinamik parti, modeli değiştirmeden verimi artırabilir. Doğru ayar trafiğe bağlıdır. Daha büyük gruplar verimi artırabilir ancak bekleme süresini ve bellek kullanımını artırabilir. Tek bir sayıyı optimize etmek yerine hem istek başına maliyeti hem de yanıt gecikmesini ölçerdim. 3. Doğru görev için niceleme uygulayın veya daha küçük bir model kullanın Niceleme, model ağırlıklarını daha az bitle saklar. 16 bit ağırlık kullanan bir model, donanıma, yazılım yığınına ve kalite hedefine bağlı olarak çıkarım için 8 bit veya 4 bit formatlara dönüştürülebilir. Ortak seçenekler şunları içerir: - Bellek kullanımı ile kalite arasında bir denge sağlamak için 8 bitlik ağırlık nicelemesi - Bellek basıncı yüksek olduğunda 4 bitlik niceleme - Seçilen çıkarım iş yükleri için yalnızca ağırlık nicelemesi - Daha büyük bir modelden daha küçük bir modeli eğitmek için bilgi damıtma Niceleme, bellek gereksinimlerini azaltabilir ve bir modelin daha küçük bir GPU üzerinde çalışmasına izin verebilir. Her kurulumda aynı hızı veya çıktı kalitesini garanti etmez; bu nedenle test yapmak önemlidir. Orijinal ve nicelenmiş modelleri, gerçek kullanıcı isteklerini yansıtan veriler üzerinde karşılaştırırdım. Bir müşteri destek modeli için test seti, kısa soruları, uzun konuşmaları, ürün adlarını, yazım hatalarını ve dikkatli bir şekilde reddedilmesi veya yükseltilmesi gereken talepleri içermelidir. Takip: - Görev doğruluğu - İnsan inceleme puanları - Yanıt gecikmesi - GPU bellek kullanımı - Hata ve geri dönüş oranları - 1.000 istek başına maliyet Daha küçük bir model, amaç tespiti, duyarlılık analizi veya belge yönlendirme gibi basit görevler için daha iyi bir seçim olabilir. Karmaşık durumlar için büyük bir model mevcut kalabilir. Bu model yönlendirme yaklaşımı, her isteğin en pahalı seçeneği kullanmasını engeller. Bir modeli yalnızca bellek alanı büyük göründüğü için sıkıştırmam. Kalite düşerse ekstra destek çalışmaları ve başarısız talepler beklenen tasarrufu ortadan kaldırabilir. GPU maliyet kontrolü en iyi ölçüm süreci olarak çalışır. Karma hassasiyetle başlayın, gereksiz belirteçleri kaldırın, toplu işlemi iyileştirin, ardından nicelemeyi veya model yönlendirmeyi test edin. Her aşamada kalite kontrolü yapın. Daha düşük bir fatura yalnızca hizmetin hâlâ kullanıcılarının ihtiyaçlarını karşılaması durumunda faydalıdır. Küçük bir kıyaslama karara rehberlik edebilir: ``metin Model formatı: FP32 GPU belleği: 18 GB Gecikme: 210 ms Kalite puanı: 92 Model formatı: BF16 GPU belleği: 11 GB Gecikme: 145 ms Kalite puanı: 91 Model formatı: 8-bit GPU belleği: 8 GB Gecikme: 132 ms Kalite puanı: 90 ``` Bu rakamlar örnektir, her biri için bir söz değildir modeli. Sonucu kendi trafiğiniz, donanımınız, istem uzunluğu ve kalite gereksinimleriniz belirleyecektir.

Transformatör modelleri, GPU tam hesaplama sınırına ulaşmadan çok önce pahalı hale gelebilir. Bellek trafiği, uzun giriş dizileri, tekrarlanan model yükleme ve zayıf toplu işlem çoğu zaman gerçek darboğazı oluşturur. Daha küçük bir değişiklik aynı baskıyı azaltabilecekken ekiplerin donanım eklediğini gördüm: daha kısa girişler, daha düşük hassasiyet, daha iyi önbellekleme veya daha temiz bir sunum düzeni. Amaç her katmanı kaldırmak veya her ayarı en düşük değerine itmek değildir. Amaç, modelin nerede zaman ve bellek harcadığını bulmak, ardından kullanıcılarınızın ihtiyaç duyduğu çıktı kalitesine zarar vermeden bu maliyeti azaltmaktır. Mevcut iş yükünü ölçün Gerçek kullanımı yansıtan küçük bir test seti ile başlıyorum. Kısa ve uzun istekleri, ortak istemleri, en yüksek istek oranlarını ve modelin normal çıktı uzunluğunu içermelidir. Şunları kaydederim: - Ortalama ve p95 gecikme süresi - Saniyede işlenen jeton sayısı - GPU bellek kullanımı - Giriş ve çıkış jetonu sayıları - Toplu iş boyutu - Hata oranı - Sabit bir değerlendirme kümesinde çıktı kalitesi Bu adım tahminde bulunmayı önler. Bir model, bellek erişimini beklerken düşük işlem kullanımı gösterebilir. Başka bir model, dizi uzunluğu çok büyük olduğundan GPU'nun çoğunu kullanabilir. Düzeltme farklı olacaktır. Basit bir profil, ana maliyetin aşağıdakilerden kaynaklanıp kaynaklanmadığını ortaya çıkarabilir: - Matris çarpımı - Uzun dizilere dikkat - Anahtar-değer önbellek büyümesi - CPU ve GPU arasında veri aktarımı - Tokenizasyon - Model yükleme - Küçük gruplar Her seferinde bir ayarı değiştirirken test koşullarını sabit tutuyorum. Bu sonuca güvenmeyi kolaylaştırır. Jeton israfını azaltın Her giriş jetonu hafızayı ve işlem süresini tüketir. Birçok uygulama tekrarlanan talimatlar, uzun sohbet geçmişi, kullanılmayan belge bölümleri veya yinelenen meta veriler gönderir. İsteğin tamamını modele ulaşmadan önce kontrol ederim: - Hizmet tasarımının izin verdiği ölçüde tekrarlanan sistem metnini kaldırın - Eski konuşma dönüşlerini kısaltın - Uzun belgeleri bilgi istemi dışında saklayın ve yalnızca yararlı bölümleri alın - Boş alanları ve tekrarlanan biçimlendirmeyi kaldırın - Pratik bir çıktı sınırı belirleyin - Daha küçük bir bilgi istemi şablonu kullanın Bir destek asistanı, 800 jeton gerektiren bir soruyu yanıtlamak için 12.000 jetonluk bir bilgi tabanı sayfası alabilir. Geri alma, ilgili pasajları korurken girişi azaltabilir. Bu değişiklik genellikle model cerrahiden daha az maliyetlidir. Ayrıca agresif sıkıştırmanın neden olduğu kalite kaybını da önler. Daha düşük hassasiyet kullanın Birçok transformatör modeli 16 bit ağırlıklarla eğitilir veya sunulur. Düşük hassasiyetli formatlar bellek kullanımını azaltabilir ve bunları destekleyen donanımın verimini artırabilir. Yaygın seçenekler şunları içerir: - Geniş destek için FP16 veya BF16 - Ağırlık veya aktivasyon nicelemesi için INT8 - Daha düşük bellek kullanımı için INT4 - Bazı büyük dil modelleri için GPTQ veya AWQ Niceleme, model değerlerinin depolanma şeklini değiştirir. Daha küçük bir gösterim bellek trafiğini azaltabilir ancak etki modele, donanıma, çalışma zamanına ve iş yüküne bağlıdır. Nicelenmiş versiyonları aynı değerlendirme setine göre test ediyorum. Bu özellikler ürün için önemli olduğunda gerçek yanıtları, sınıflandırma doğruluğunu, kod çıktısını, reddetme davranışını ve yanıt stilini kontrol ederim. Yararlı bir model, diğer katmanları nicelerken hassas katmanları daha yüksek hassasiyette tutmaktır. Katıştırma katmanları, çıktı kafaları ve dikkat blokları farklı tepki verebilir. En iyi ayar genellikle mevcut en düşük bit genişliğinden ziyade ölçülen bir uzlaşmadır. bitsandbytes, llama.cpp, TensorRT-LLM ve ONNX Runtime gibi kitaplıklar farklı niceleme yolları sağlar. Sonuçları birbirinin yerine kullanılamaz, bu nedenle üretimde kullanılan tam çalışma süresini karşılaştırırım. Sonucu etkilemeyen işleri kaldırın Budama, ağdaki seçilen ağırlıkları veya yapıları azaltır. Yapılandırılmamış budama birçok sıfır değeri oluşturabilir ancak donanım bunları verimli bir şekilde kullanamayabilir. Yapılandırılmış budama, tüm kanalları, kafaları veya blokları kaldırır ve çalışma zamanının yürütülmesini kolaylaştırabilir. Süreç şuna benzer: 1. Bir kalite temel çizgisi oluşturun. 2. Düşük etkiye sahip katmanları veya kafaları belirleyin. 3. Küçük bir budama seviyesi uygulayın. 4. Gerektiğinde ince ayar yapın. 5. Kaliteyi, gecikmeyi ve belleği tekrar ölçün. 6. Para üstünü yalnızca servis yığını kullanabileceği zaman saklayın. Budama otomatik olarak hız artışı anlamına gelmez. Çekirdek, matrisi yoğun olarak ele alırsa, çok sayıda sıfır ağırlığa sahip bir model aynı hızda çalışabilir. Yapılandırılmış değişikliklerin bilgi işlem miktarını düşürmeye yönelik daha net bir yolu vardır ancak daha fazla kalite kaybına neden olabilirler. Modelin rutin görevler için ayrıştırılması Bilginin ayrıştırılması, daha küçük bir öğrenci modelini daha büyük bir öğretmenle eşleşecek şekilde eğitir. Bu, görevin duyarlılık sınıflandırması, amaç tespiti, belge etiketleme veya kısa yanıt desteği gibi net bir kapsamı olduğunda işe yarar. Örneğin DistilBERT, damıtma ve ilgili eğitim yöntemleri yoluyla BERT'in daha küçük bir versiyonu olarak oluşturuldu. Yalnızca bilet sınıflandırmasına ihtiyaç duyan bir ekibin, her istek için geniş bir genel dil modeline ihtiyacı olmayabilir. Öğrenciyi asıl görev etrafında tanımlarım: - Hangi girdileri alıyor? - Hangi etiketleri veya çıktıları üretiyor? - Hangi hatalar maliyetlidir? - Ne kadar bağlama ihtiyacı var? - Açık uçlu nesile ihtiyacı var mı? Daha küçük bir model aynı GPU'da daha hızlı ve daha ucuz olabilir. Kapsamlı muhakeme veya olağandışı talepler konusunda öğretmenle eşleşmeyebilir, bu nedenle ona yalnızca uygun görevleri yönlendiririm. Pratik bir tasarım, ortak, dar istekler için küçük bir model kullanır ve belirsiz durumları daha büyük bir modele gönderir. Yönlendirme kuralı, yalnızca model boyutuna dayanmak yerine gerçek trafik örnekleriyle test edilmelidir. Toplamayı iyileştirin Aynı anda tek bir isteğin sunulması, istekler birbirine yakın geldiğinde donanımın boşta kalmasına neden olur. Toplu işleme, işi tek bir yürütme adımında birleştirir. Statik toplu işlem sabit bir grubu bekler. Dinamik toplu işlem, istekleri kısa bir süre için toplar. Sürekli toplu işlem, diziler tamamlandıktan sonra grubu günceller ve bu, metin oluşturma açısından iyi sonuç verebilir. Takasın gözden kaçırılması kolaydır. Daha uzun bir bekleme penceresi, yanıt gecikmesini artırırken verimi artırabilir. Maksimum bekleme süresini ayarlıyorum ve her iki değeri de ölçüyorum. Şekilleri farklılık gösterdiğinde iş yüklerini de ayırıyorum. Çok uzun bir bilgi istemi ve çok sayıda kısa bilgi istemi içeren bir grup, belleği boşa harcayabilir ve kısa istekleri geciktirebilir. İstekleri yaklaşık giriş uzunluğuna göre gruplamak daha istikrarlı bir performans sağlayabilir. vLLM, TensorRT-LLM ve Hugging Face TGI gibi hizmet araçları farklı toplu işlem ve önbellek stratejilerini destekler. Doğru seçim model mimarisine ve GPU üretimine bağlıdır. Anahtar/değer önbelleğini yönetin Otoregresif oluşturma, önceki belirteçlerdeki anahtar ve değer durumlarını depolar. Bu önbellek, bağlam uzunluğu, katman sayısı ve toplu iş boyutu arttıkça büyüse de modelin her yeni belirteç için tam geçmişi yeniden hesaplamasını engeller. Önbellek büyümesini şu şekilde kontrol ederim: - Ürün ihtiyaçlarına uygun bir bağlam sınırı belirleyerek - Maksimum çıktı belirteçlerini sınırlayarak - Çalışma zamanı desteklediğinde paylaşılan bir öneki yeniden kullanarak - Eski sohbet geçmişini çıkararak - Sayfalanmış dikkat veya benzer bellek yönetimini kullanarak - Desteklendiğinde önbellek hassasiyetini test ederek Uzun konuşmalar, model ağırlıklarından daha fazla bellek tüketebilir. Kısa bir test sırasında uyan bir model, birden fazla kullanıcının aynı anda uzun geçmişler göndermesi durumunda başarısız olabilir. Önek önbelleğe alma, birçok isteğin aynı sistem istemini veya belge önekini paylaştığı durumlarda yardımcı olabilir. Faydası, bu önekin ne sıklıkla tekrarlandığına ve çalışma zamanının bunu nasıl sakladığına bağlıdır. Optimize edilmiş dikkat ve çekirdekleri kullanın Dikkat performansı, dizi uzunluğuna ve uygulama ayrıntılarına bağlıdır. FlashAttention gibi çekirdekler, dikkatin hesaplanma ve saklanma şeklini değiştirerek gereksiz hafıza hareketini azaltır. Model çıktısı standart ilgiye yakın kalacak şekilde tasarlanmıştır, ancak tam destek mimariye ve yazılım yığınına göre değişir. Derleyici araçları birden fazla işlemi tek bir çekirdekte birleştirebilir. ONNX Runtime, TensorRT ve PyTorch derleme özellikleri, kararlı iş yükleri için başlatma yükünü azaltabilir. Her optimizasyonu aynı anda etkinleştirmekten kaçınıyorum. Bir çekirdek değişikliği, bir girdi şeklini iyileştirebilir ve diğerinde kötü performans gösterebilir. Kısa istemleri, uzun istemleri, küçük grupları ve uygulama tarafından kullanılan eşzamanlılık düzeyini test ediyorum. Mümkün olduğunda modeli cihazda tutun Tensörlerin CPU ile GPU arasında taşınması gecikmeye neden olur. Sık transferler daha küçük bir modelin değerini ortadan kaldırabilir. Şunları kontrol ediyorum: - Model ağırlıklarının nerede yüklendiğini - Simgeleştirmenin nerede çalıştığını - Girişlerin nerede kopyalandığını - Ara tensörlerin cihazlar arasında hareket edip etmediğini - Çerçevenin belleği yeniden yükleyip yüklemediğini veya yeniden tahsis edip etmediğini - Birden fazla işlemin aynı GPU CPU boşaltması için rekabet edip etmediğini bir modelin belleğe sığmasına yardımcı olabilir, ancak yanıt hızını azaltabilir. Garantili bir performans düzeltmesi olarak değil, bir kapasite seçeneği olarak ele alınmalıdır. Model yükleme de önemlidir. Her istek için ağırlık yükleyen bir hizmet, üretim başlamadan önce büyük bir maliyet öder. Bir çalışanı sıcak tutmak, tekrarlanan işlerden kaçınabilir; ancak hafıza sınırlarının hâlâ izlenmesi gerekir. Hedefi karşılayan en küçük modeli seçin Model boyutu kararın yalnızca bir parçasıdır. Niceleme ve iyi gruplama özelliğine sahip daha büyük bir model, zayıf girdi kontrolüne sahip daha küçük bir modele göre iş yüküne daha sorunsuz hizmet edebilir. Küçük bir model çok sık başarısız olabilir ve fazladan inceleme çalışması gerektirebilir. Aday modelleri aynısını kullanarak karşılaştırıyorum: - Değerlendirme istemleri - Giriş uzunluğu aralığı - Çıkış uzunluğu sınırı - Donanım - Çalışma zamanı - Toplu politika - Kalite eşiği Bir müşteri destek sınıflandırıcısı için doğruluk ve hata kategorileri, açık uçlu akıcılıktan daha önemli olabilir. Bir kodlama asistanı için söz dizimi geçerliliği ve test sonuçları, kısa bir ortalama yanıt süresinden daha önemli olabilir. Pratik bir kullanıma sunma yolu Çoğu proje için bu sırayı kullanıyorum: 1. Mevcut sistemin profilini çıkarın. 2. Tekrarlanan ve gereksiz jetonları kesin. 3. Mantıklı giriş ve çıkış sınırlarını ayarlayın. 4. Uygun gruplamayı etkinleştirin. 5. FP16, BF16, INT8 veya INT4 seçeneklerini test edin. 6. Optimize edilmiş dikkat veya derlenmiş çekirdekler ekleyin. 7. Önbellek kullanımını ve cihaz aktarımlarını inceleyin. 8. Daha küçük veya damıtılmış bir modeli test edin. 9. Budamayı yalnızca çalışma zamanı kullanabildiğinde ekleyin. 10. Dağıtımdan sonra kaliteyi ve gecikmeyi izleyin. Bu sıra geri dönüşü kolay değişikliklerle başlar. Ayrıca yazılım atıklarının model boyutundan ayrılmasına da yardımcı olur. Bir takımın bir transformatör modeline iyi hizmet verebilmesi için her zaman başka bir GPU'ya ihtiyacı yoktur. Daha iyi yol, daha kısa bir istem, nicelenmiş bir kontrol noktası, daha küçük bir öğrenci modeli veya GPU'yu meşgul eden bir hizmet katmanı olabilir. Her değişikliği ölçülmüş bir deney olarak ele alıyorum: Kullanıcının karşılaştığı kalite hedefini sabit tutun, bir maliyet etkenini değiştirin ve sonucu aynı iş yüküyle karşılaştırın. Bu makalenin içeriğiyle ilgili sorularınız için lütfen Amy Wu ile iletişime geçin: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

Vaswani, Ashish ve diğerleri. 2017, İhtiyacınız Olan Tek Şey Dikkat Micikevicius, Paulius, et al. 2018, Karma Hassas Eğitim Sanh, Victor, vd. 2019, DistilBERT: BERT'in Damıtılmış Bir Versiyonu Frantar, Elias, et al. 2022, GPTQ: Üretken Önceden Eğitimli Transformatörler için Eğitim Sonrası Doğru Niceleme Dao, Tri, vd. 2022, FlashAttention: IO Farkındalığıyla Hızlı ve Bellek Açısından Verimli Tam Dikkat Kwon, Woosuk, et al. 2023, PagedAttention ile Hizmet Veren Büyük Dil Modeli için Etkin Bellek Yönetimi