Accelerate documentation

Sorun Giderme

You are viewing main version, which requires installation from source. If you'd like regular pip install, checkout the latest stable version (v1.15.0).
Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Sorun Giderme

This guide provides solutions to some issues you might encounter when using Accelerate. Not all errors are covered because Accelerate is an active library that is continuously evolving and there are many different use cases and distributed training setups. If the solutions described here don’t help with your specific error, please take a look at the Ask for help section to learn where and how to get help.

Kayıt Tutma

Günlükleme, bir hatanın nereden kaynaklandığını belirlemenize yardımcı olabilir. Birden fazla sürecin yer aldığı dağıtık bir kurulumda günlük tutmak zorlayıcı olabilir, ancak Accelerate, günlüklerin senkronize edilmesini sağlamak için logging() yardımcısını sunar.

Bir sorunu gidermek için standart Python logging modülü yerine logging() kullanın. Ayrıntı düzeyini (INFO, DEBUG, WARNING, ERROR, CRITICAL) log_level parametresiyle ayarlayın ve ardından şunlardan birini yapabilirsiniz:

  1. log_level değerini ACCELERATE_LOG_LEVEL ortam değişkeni olarak dışa aktarın.
  2. log_level değerini doğrudan get_logger fonksiyonuna iletin.

Örneğin, log_level="INFO" değerini ayarlamak için:

from accelerate.logging import get_logger

logger = get_logger(__name__, log_level="DEBUG")

Varsayılan olarak, log yalnızca ana süreçlerde çağrılır. Tüm süreçlerde çağırmak için main_process_only=False parametresini iletin. Bir logun tüm süreçlerde ve sırayla çağrılması gerekiyorsa, ayrıca in_order=True parametresini de iletin.

from accelerate.logging import get_logger

logger = get_logger(__name__, log_level="DEBUG")
# log all processes
logger.debug("thing_to_log", main_process_only=False)
# log all processes in order
logger.debug("thing_to_log", main_process_only=False, in_order=True)

Asılı kalan kod ve zaman aşımı hataları

Kodunuzun takılmasının birçok nedeni olabilir. Kodunuzu takılmasına yol açabilen en yaygın sorunlardan bazılarını nasıl çözeceğimize bir bakalım.

Eşleşmeyen tensör şekilleri

Eşleşmeyen tensör şekilleri, dağıtık bir kurulumda kodunuzun önemli ölçüde uzun süre takılmasına neden olabilecek yaygın bir sorundur.

Dağıtık bir kurulumda betikler çalıştırılırken, Accelerator.gather() ve Accelerator.reduce() gibi işlevler, tensörleri cihazlar arasında toplayarak bunlar üzerinde ortak işlemler gerçekleştirmek için gereklidir. Bu (ve diğer) işlevler, gather işlemini gerçekleştirmek için torch.distributed üzerine kuruludur ve bu işlem, tensörlerin tüm süreçlerde aynı şekle sahip olmasını gerektirir. Tensör şekilleri eşleşmediğinde kodunuz takılır ve sonunda bir zaman aşımı istisnasıyla karşılaşırsınız.

Bu sorunu anında yakalamak için Accelerate’in operasyonel hata ayıklama modunu kullanabilirsiniz. Bu modun accelerate config kurulumu sırasında etkinleştirilmesini öneriyoruz ancak CLI üzerinden, bir ortam değişkeni olarak veya config.yaml dosyasını manuel olarak düzenleyerek de etkinleştirebilirsiniz.

CLI
ortam değişkeni
config.yaml
accelerate launch --debug {my_script.py} --arg1 --arg2

Hata ayıklama modunu etkinleştirdikten sonra, tensör şekli uyumsuzluğu sorununa işaret eden bir izleme (traceback) almanız gerekir.

Traceback (most recent call last):
  File "/home/zach_mueller_huggingface_co/test.py", line 18, in <module>
    main()
  File "/home/zach_mueller_huggingface_co/test.py", line 15, in main
    broadcast_tensor = broadcast(tensor)
  File "/home/zach_mueller_huggingface_co/accelerate/src/accelerate/utils/operations.py", line 303, in wrapper
accelerate.utils.operations.DistributedOperationException:

Cannot apply desired operation due to shape mismatches. All shapes across devices must be valid.

Operation: `accelerate.utils.operations.broadcast`
Input shapes:
  - Process 0: [1, 5]
  - Process 1: [1, 2, 5]

Erken durdurma

Dağıtık eğitimde erken durdurma için, her sürecin kendine özgü bir durdurma koşulu varsa (ör. doğrulama kaybı), bu koşul tüm süreçler arasında senkronize olmayabilir. Sonuç olarak, 0 numaralı süreçte bir break gerçekleşirken 1 numaralı süreçte gerçekleşmeyebilir; bu da kodunuzun bir zaman aşımı oluşana kadar sonsuza kadar beklemesine neden olur.

Erken durdurma koşullarınız varsa, tüm süreçlerin doğru şekilde sonlandırıldığından emin olmak için set_trigger ve check_trigger yöntemlerini kullanın.

# Assume `should_do_breakpoint` is a custom-defined function that returns a conditional, 
# and that conditional might be true only on process 1
if should_do_breakpoint(loss):
    accelerator.set_trigger()

# Later in the training script when we need to check for the breakpoint
if accelerator.check_trigger():
    break

Linux'ta düşük çekirdek sürümleri

Çekirdek sürümü < 5.5 olan Linux sistemlerde, takılan süreçler raporlanmıştır. Bu sorundan kaçınmak için sisteminizi daha yeni bir çekirdek sürümüne yükseltin.

MPI

MPI kullanan dağıtık CPU eğitim işiniz takılıyorsa, düğümler arasında şifresiz SSH kurulumunun (anahtarlar kullanılarak) yapıldığından emin olun. Bu, hostfile'daki tüm düğümler için, bir düğümden diğerine şifre sorulmadan SSH bağlantısı kurulabileceği anlamına gelir.

Ardından, bir sağlamlık kontrolü olarak mpirun komutunu çalıştırmayı deneyin. Örneğin, aşağıdaki komut her bir düğümün ana bilgisayar adlarını yazdırmalıdır.

mpirun -f hostfile -n {number of nodes} -ppn 1 hostname

Bellek Dışı

Eğitim betiklerini çalıştırırken karşılaşılan en sinir bozucu hatalardan biri, CUDA, XPU veya CPU gibi cihazlarda “Out-of-Memory” (Bellek Yetersizliği) hatasıyla karşılaşmaktır. Betiğin tamamının yeniden başlatılması gerekir ve mevcut ilerleme kaybedilir.

Bu sorunu çözmek için Accelerate, büyük ölçüde toma üzerine kurulu find_executable_batch_size() yardımcı aracını sunar. Bu yardımcı araç, bellek dışı (out-of-memory) koşullar nedeniyle başarısız olan kodu yeniden dener ve batch boyutlarını otomatik olarak düşürür. Her bellek dışı koşulunda algoritma, batch boyutunu yarıya indirir ve kod başarılı olana kadar yeniden dener.

find_executable_batch_size() kullanmak için eğitim işlevinizi yeniden yapılandırın ve içinde find_executable_batch_size içeren bir iç işlev ekleyin; veri yükleyicilerinizi de bu iç işlevin içinde oluşturun. En azından bu, yalnızca 4 yeni kod satırı gerektirir.

İç fonksiyon mutlaka parti boyutunu ilk parametre olarak almalıdır, ancak çağrıldığında ona bir değer geçirmezsiniz. Sarmalayıcı bunu sizin için halleder. Cihaz belleği tüketen ve Accelerator nesnesine geçirilen herhangi bir nesne (modeller, optimizatörler) da mutlaka iç fonksiyonun içinde tanımlanmalıdır.

def training_function(args):
    accelerator = Accelerator()

+   @find_executable_batch_size(starting_batch_size=args.batch_size)
+   def inner_training_loop(batch_size):
+       nonlocal accelerator # Ensure they can be used in our context
+       accelerator.free_memory() # Free all lingering references
        model = get_model()
        model.to(accelerator.device)
        optimizer = get_optimizer()
        train_dataloader, eval_dataloader = get_dataloaders(accelerator, batch_size)
        lr_scheduler = get_scheduler(
            optimizer, 
            num_training_steps=len(train_dataloader)*num_epochs
        )
        model, optimizer, train_dataloader, eval_dataloader, lr_scheduler = accelerator.prepare(
            model, optimizer, train_dataloader, eval_dataloader, lr_scheduler
        )
        train(model, optimizer, train_dataloader, lr_scheduler)
        validate(model, eval_dataloader)
+   inner_training_loop()

Cihaz kurulumları arasında tekrarlanamayan sonuçlar

Cihaz kurulumunu değiştirdiyseniz ve farklı model performansları gözlemliyorsanız, bir kurulumdan diğerine geçerken betiğinizi güncellemediğiniz için bu durum büyük olasılıkla gerçekleşmiştir. Aynı betiği aynı batch boyutuyla kullanıyor olsanız bile, sonuçlar TPU, çoklu GPU ve tek GPU üzerinde yine de farklı olacaktır.

Örneğin, 16'lık bir batch size ile tek bir GPU üzerinde eğitim yapıyorsanız ve çift GPU kurulumuna geçiyorsanız, aynı etkili batch size'ı elde etmek için batch size'ı 8 olarak değiştirmeniz gerekir. Bunun nedeni, Accelerate ile eğitim sırasında dataloader'a geçirilen batch size'ın GPU başına batch size olmasıdır.

Kurulumlar arasında sonuçları yeniden üretebileceğinizden emin olmak için aynı tohumu kullanın, parti boyutunu buna göre ayarlayın ve öğrenme oranını ölçeklendirmeyi göz önünde bulundurun.

Toplu işlem boyutları için daha fazla ayrıntı ve hızlı bir referans için Farklı cihaz kurulumları arasında performans karşılaştırması kılavuzuna göz atın.

Farklı GPU'larda performans sorunları

Çoklu GPU kurulumunuz farklı GPU'lardan oluşuyorsa, bazı performans sorunlarıyla karşılaşabilirsiniz:

  • GPU'lar arasında GPU belleğinde bir dengesizlik olabilir. Bu durumda, daha küçük belleğe sahip GPU, GPU'lara yüklenebilecek parti boyutunu veya model boyutunu sınırlayacaktır.
  • Farklı performans profillerine sahip GPU'lar kullanıyorsanız, diğer GPU'ların iş yükünü tamamlamasını beklemek zorunda kalacağı için performans, kullandığınız en yavaş GPU tarafından belirlenecektir.

Aynı kurulum içinde birbirinden çok farklı GPU'lar performans darboğazlarına yol açabilir.

Yardım isteyin

Buradaki çözümler ve öneriler sorununuzun çözülmesine yardımcı olmadıysa, her zaman topluluğa ve Accelerate ekibine ulaşarak yardım isteyebilirsiniz.

  • Sorunuzu Accelerate kategorisinde paylaşarak Hugging Face forumlarında yardım isteyin. Sorununuzun çözülme olasılığını en üst düzeye çıkarmak için, kurulumunuzla ilgili ilgili bağlamı ve yeniden üretilebilir kodu içeren açıklayıcı bir gönderi yazdığınızdan emin olun!

  • Discord’da bir soru paylaşın ve ekibin ve topluluğun size yardım etmesine izin verin.

  • Kütüphaneyle ilgili bir hata bulduğunuzu düşünüyorsanız, Accelerate GitHub deposunda bir Issue oluşturun. Hatanın bağlamını ve dağıtık kurulumunuza dair ayrıntıları dahil edin; böylece sorunun ne olduğunu daha iyi anlayabilir ve nasıl düzeltebileceğimizi belirleyebiliriz.

Update on GitHub