Hata kodu: E1000

Kategori: Derleme Zamanı: HBM OOM

Bu hata, programın TPU cihazda fiziksel olarak mevcut olandan daha fazla yüksek bant genişlikli bellek (HBM) gerektirdiğini gösterir.

Örnek hata mesajları:

RESOURCE_EXHAUSTED: TPU TensorCore Hbm usage: 34.82G, SparseCore Hbm usage 174.10G, exceeding available bytes: 95.74G

RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space hbm. Used 49.34G of 32.00G hbm. Exceeded hbm capacity by 17.34G.

XLA arka uçları: TPU

Genel Bakış

XLA, gerekli tüm statik ayırmaların toplam boyutunun cihazın HBM'sine sığdığından emin olmak için kontroller gerçekleştirir.

Derleyici, TPU'nun sabit HBM kapasitesini çeşitli tahsis türleri için yönetir:

  • Program girişleri ve çıkışları: Eğitim grupları, optimize edici durumları vb.
  • TPU geçicileri: Ara hesaplamalar (ör.etkinleştirmeler, gradyanlar vb.) için gereken dinamik bellek.
  • Derlenmiş ikili program: Hem TensorCore (TC) hem de SparseCore (SC) için makine dili.
  • Sistem ek yükü: XLA çalışma zamanı için ayrılmış alan (ör. eski TPU nesillerinde feed içi arabellekler).
  • Sabitler: HLO IR'ye yerleştirilmiş sabit değerler, HBM'ye ayrılır.
  • Derleyici iç işleyişi: Program düzeyi ve HLO başına ayırmalar (ör. ağdaki düğümler için yönlendirme bilgileri).

Bu hata, XLA derleyicisi yukarıdaki tüm tahsisleri cihaz HBM'sine sığdıramadığında oluşur.

Hata ayıklama

Aşağıdaki HBM OOM kategorilerinden hangisinin hatanızı en iyi şekilde tanımladığını belirlemek için hata mesajını ve günlükleri dikkatlice analiz edin:

1. senaryo TC ve SC HBM kullanımını dengeleme

Hata, kullanımı açıkça ayrıntılandırıyorsa (ör. "TC Hbm kullanımı: X, SC Hbm kullanımı Y"), bu, toplam TensorCore (TC) + SparseCore (SC) kullanımının HBM sınırını aştığı anlamına gelir. Performans sorununu belirlemek için iki değeri karşılaştırın:

  • Yüksek SparseCore kullanımı
    • HBM yığını kullanımını optimize etme: HBM yığını bellek tüketimi feature_width, max_unique_nz_per_row ve logical_replica_count ile ölçeklenir. Tabloların işlenmesini serileştiren --xla_sc_num_serialized_tables_to_optimize_hbm işaretini ayarlayarak en yüksek yığın kullanımını azaltabilirsiniz. Bu durum, paralelliğin azalması pahasına gerçekleşir.
    • Doldurma ek yükünü kontrol edin: SparseCore, yerleştirme tablolarını 32 B'ye (8 kayan nokta) göre hizalar. Küçük özellik genişliklerine (ör. < 8 kayan nokta) sahip tablolar önemli dolgu ek yüküne neden olarak HBM'yi boşa harcar.
    • Yığın kullanımını azaltma: maximum_parallel_iterations için yüksek değerler, HBM yığınına önceden getirilen giriş verilerinin miktarını artırır. Bu değeri düşürmek önemli ölçüde bellek alanı açabilir.
    • Parçalama işlemini doğrulayın: Yerleştirme tablolarının tüm çiplerde düzgün şekilde mod-parçalandığından emin olun. Sınırlar tablolara nasıl yansıtılır? başlıklı makaleyi inceleyin.
    • Daha fazla fikir için SC: Performance and memory bottlenecks (SC: Performans ve bellek darboğazları) başlıklı makaleyi inceleyin.
  • Yüksek Tensor Çekirdeği kullanımı
  • Dengeli
    • İkisi de ayrı ayrı aşırı olmamasına rağmen toplam çok yüksekse çipin kapasitesindesinizdir. Her iki bileşenin de kullanımını azaltmayı denemeniz gerekir. Üç bölümdeki önerileri de uygulayın.

2. Senaryo. Beklenmedik şekilde büyük yer ayırmalar nedeniyle bellek yetersiz

"HBM bellek alanında bellek tükendi" hata mesajını görüyorsanız ve günlüklerde bir veya daha fazla beklenmedik şekilde büyük tahsisler varsa (HBM sınırının% 50'sinden fazla), bu neredeyse hiçbir zaman donanım kapasitesi sorunu değildir. Bu hata genellikle yapılandırma hatasıdır. Büyük ayırmaların JAX kaynak koduyla ilgili ipuçları için XLA etiketini (varsa) kontrol edin.

  • Hata ayıklama yapılarını kaldırma
    • Büyük ölçekli çalıştırmalarda jax.debug.print() kullanmak, derleyiciyi tensörün tamamını HBM'de oluşturmaya zorlayarak CPU'ya aktarmasına, birleştirmeyi bozmasına ve en yüksek bellek kullanımını artırmasına neden olabilir. Kalan jax.debug.print() karakterlerini kaldırın.
  • Verimsiz örgü şekillerini veya parçalama işlemlerini düzeltme
    • Yanlış ağ şekilleri veya eksik parçalama ek açıklamaları, derleyicinin varsayılan olarak replikasyon kullanmasına neden olabilir. Bu durumda derleyici, çok büyük tensörleri tek bir çipe sığdırmaya çalışır.
    • Büyük ayırmaların şekillerini kontrol edin ve parçalama işleminin XLA tarafından doğru şekilde belirtilip yayıldığını doğrulayın.

3. Senaryo. Toplam ayırmalar nedeniyle bellek yetersiz

"HBM bellek alanında bellek tükendi" hata mesajını görüyorsanız ve günlüklerde beklenmedik şekilde büyük tensörler yoksa program, tahsislerin toplamı HBM sınırını aştığı için kapasiteyi aşmıştır. Bu durumda, en yüksek kullanıma katkıda bulunan belirli arabellekleri belirlemek için bellek profilini görselleştirmek genellikle yararlıdır. En yüksek bellek kullanımına neden olan öğeleri belirleme hakkında adım adım talimatlar için XProf ile OOM hatalarını ayıklama başlıklı makaleyi inceleyin.

En çok katkıda bulunanlardan bazılarını belirledikten sonra, bellekte kaplanan yeri optimize etmek için aşağıdaki adımları uygulayın.

Senaryo 3.A Yapılandırmayı ayarlama

Aşağıdaki yapılandırma düzenlemeleriyle genellikle OOM'leri çözebilirsiniz:

  • Grup boyutunu küçültün: Ara etkinleştirmeler ve gradyanlar için gereken bellek, grup boyutuyla doğru orantılıdır. Toplu iş boyutunu azaltmak genellikle bellek kullanımını azaltmaya yardımcı olabilir.
  • Giriş arabelleklerine bağış yapma: jax.jit kullanırken model parametreleriniz için donate_argnums değerini belirtin. Bu, XLA'nın giriş belleğinin üzerine çıkışla yazmasına olanak tanır.
  • Karma duyarlılığı (bfloat16) etkinleştirme: Model mimarisi ve kalite koşulları izin veriyorsa programdaki en büyük tensörler için bfloat16 veya nicemleme (int8 vb.) kullanın. Bu değişikliğin model davranışını etkileyebileceğini ve dikkatli bir şekilde değerlendirilmesi gerektiğini unutmayın.

Senaryo 3.B: Mimarinin ve parçalamanın optimize edilmesi

Yapılandırma değişiklikleri yetersizse model topolojisi, mevcut donanım kurulumu için çok büyük olabilir.

  • Daha yeni TPU nesillerini kullanın: Daha yeni TPU'lar genellikle çip başına daha fazla HBM sunar. Mümkünse daha yeni TPU nesillerine geçin.
  • Daha büyük bir çip topolojisinde çalıştırma: Model ağırlıkları mevcut topoloji için çok büyükse bunları daha fazla çipte parçalamayı deneyebilirsiniz.
  • Gelişmiş parçalama tekniklerini uygulayın:
    • Daha gelişmiş veri, tensör veya ardışık düzen paralelliği yaklaşımlarını keşfedin.
    • Ara değerler ve çıkışlar için parçalama ipuçları belirtin.
  • JAX ana makine yükünü boşaltma özelliğini kullanma: Ana makine yükünü boşaltma teknikleri, kullanıcının büyük Tensörleri ana makine CPU belleğine boşaltmasına olanak tanır (ör. etkinleştirme yükünü boşaltma ve optimizasyon aracı durumunu boşaltma).

Senaryo 3.C: Tensör dolgusunu ve hizalamasını kontrol etme

Verimsiz tensör şekilleri, TPU'larda OOM'lerin yaygın ve sessiz bir nedenidir. TPU'larda en iyi performansı elde etmek için XLA, tensör boyutlarını doldurur. Bu işlem genellikle en küçük boyut için 128'in, ikinci en küçük boyut için ise 8'in katları olacak şekilde yapılır. Bu dolgu, hem giriş dizilerini hem de ara tensörleri (HLO geçicileri) etkiler ve özellikle küçük boyutlarda bellek kullanımını önemli ölçüde artırabilir. Dizi Düzenleri'ne bakın.

  • Büyük arabelleklerin şekillerini denetleme: (Varsayılan düzenlere sahip TPU v5'te)
    • Xprof Memory Viewer'da bir arabelleğin üzerine gelindiğinde, dolgu bilgileri de dahil olmak üzere arabellek ayrıntılarını içeren arabellek ayrıntıları kartı gösterilir.
    • Örnek: (129, 1024) şekli (256, 1024) ile doldurulabilir ve bu da yaklaşık% 50 bellek israfına neden olur.
    • Düzeltme: (128, 1024) şekli için dolgu gerekmez ve %0 bellek israfına neden olur.
  • Boyutları hizalama: Tüm büyük tensör boyutlarının (grup boyutu, yerleştirme boyutu, gizli boyut) 128'in katları olduğundan emin olun. Bu değişikliğin model davranışını etkileyebileceğini ve dikkatli bir şekilde değerlendirilmesi gerektiğini unutmayın.

Senaryo 3.D: XLA'yı etkileyen önemli bellek işaretlerini ayarlama

Temel bellek işaretleri, bellek kullanımını azaltmak için performansla dengeleyecek şekilde ayarlanabilir. Ancak bu strateji, performansı olumsuz etkileyebileceğinden son çare olarak kullanılmalıdır.

Senaryo 3.E Tune XLA rematerialization pass/manual checkpointing

Model belleğe sığmaya yakınsa jax.grad ile jax.checkpoint dekoratörünü kullanarak hangi ara değerlerin ileri geçişte kaydedileceğini, hangilerinin geri geçişte yeniden hesaplanacağını manuel olarak kontrol edebilir, HBM için işlem döngülerini değiştirebilirsiniz.

Alternatif olarak, XLA::Rematerialization geçişini, derlemelerin yavaşlaması pahasına da olsa bellek tasarrufuna öncelik verecek şekilde zorlayabilirsiniz:

İşaret Açıklama Etki / Değişim
--xla_tpu_max_hbm_size_mib Yeniden materyalleştirme kartı tarafından kullanılan HBM boyutu için sınırı manuel olarak ayarlar. Derleyiciyi, programı gerçek fiziksel HBM'den daha küçük bir sınıra sığdırmak için daha fazla çalışmaya zorlar.
--xla_tpu_rematerialization_algo=PEAK_PRIORITY Çabaları, en yüksek bellek kullanımının olduğu noktalara odaklar. Varsayılan algoritmadan daha agresif bir bellek azaltma için daha verimli olabilir.
--xla_tpu_rematerialization_max_block_size_limit=32 Bir blokta aynı anda yeniden oluşturulabilecek maksimum talimat sayısını kontrol eder. Bu değeri artırmak, derleme süresini önemli ölçüde artırma pahasına bellek tasarrufu sağlar.
--xla_tpu_rematerialization_block_effort_factor=10.0 Yeniden oluşturulacak blokları aramak için harcanan çaba miktarını (derleme süresi) tanımlar. Daha yüksek değerler, derleme sürelerinin artması pahasına bellek tasarrufu için daha kapsamlı bir arama yapılmasına olanak tanır.
--xla_tpu_pre_fusion_remat=true Birleştirme kartından önce ek bir yeniden materyalleştirme kartı oluşturulmasını sağlar. Daha fazla bellek tasarrufu sağlayabilir ancak derleme sürelerini artırır ve sayısal kararlılığı etkileyebilir.

XLA işaretlerinde değişiklik yapmanın performansı olumsuz etkileyebileceğinden, bu işlemin son çare olarak kullanılması gerektiğini unutmayın.

Senaryo 3.F: Gelişmiş profilleme araçlarını kullanma

XProf ile OOM hatalarını ayıklama, derleyicinin HBM kullanımı görünümünü görselleştirmek için XProf Memory Viewer'ı kullanmayla ilgili bir eğitim sunar.

Bu araç, en yüksek bellek ayırma ve arabellek ömrünü görmenize olanak tanır. Bu, en yüksek kullanım noktasında HBM'yi tam olarak neyin tükettiğini anlamak için çok önemlidir. Genel profil oluşturma kurulumu için Xprof'u kullanmaya başlama ve TensorBoard Profiling başlıklı makaleleri inceleyin.