Büyük gömme modelleri (LEM) için SparseCore'un ayrıntılı incelemesi

SparseCore, özellikle Yüksek Bant Genişlikli Bellek'te (HBM) depolanan büyük veri kümelerinde olmak üzere düzensiz, seyrek bellek erişimi ve bilgi işlem içeren iş yüklerinin yüksek performanslı hızlandırılması için tasarlanmış özel bir döşemeli işlemcidir. Yerleştirme aramaları gibi görevlerde mükemmel performans gösterse de çeşitli diğer dinamik ve seyrek iş yüklerini hızlandırma konusunda da yeteneklidir.

1. SparseCore'a Giriş

Başlıca mimari özellikler:

• Döşeme mimarisi: Paralel işleme olanağı sağlayan birden fazla işlem döşemesinden (her döşeme, kendi yerel belleği ve işleme birimi olan eksiksiz bir veri akışı birimidir) oluşur.
• Dinamik yürütme: Verilere bağlı kontrol akışını ve bellek erişimlerini doğal olarak destekler. Bu, seyrek veriler için çok önemlidir.
• Vektör işleme: Verimli hesaplama için küçük vektör görevlerinden (donanım sürümüne bağlı olarak 8 veya 16 öğeli) yararlanır.
• Merkezi kontrol: Tek bir SparseCore sıralayıcı, tüm döşemelerdeki görevleri düzenleyerek senkronize işlemler sağlar.
• Veri özetleme desteği: Sıralama, filtreleme ve önek toplamları gibi görevler için faydalı olan özel şeritler arası işlemler içerir.
• Bellek hiyerarşisi: Büyük veri kümelerini depolamak için stratejik olarak HBM'den, sıklıkla erişilen verileri hazırlamak için ise yerel geçici bellekten (SPMEM) yararlanarak HBM gecikmesini önemli ölçüde azaltır.

Teknik özelliklere kısa bir bakış:

2. SparseCore ana makine ön işleme

SparseCore performansında etkili veri hazırlama çok önemlidir ve bu noktada ana makine ön işleme önemli bir rol oynar. Bu özellik, çeşitli temel işlevleri kapsar:

• Veri dönüşümü:
  • Ham giriş verilerine gerekli dönüşümleri uygulayın.
  • Özellikle özellik veya tablo yığınlamasıyla uğraşırken önemli olan kimlik dönüşümlerini yönetin.
  • Giriş verilerini, aşağıdaki bölümde ayrıntılı olarak açıklanan Koordinat (COO) seyrek biçimine dönüştürün.
  • Verileri, çip üzerinde bulunan farklı SparseCore'lara verimli bir şekilde dağıtmak için bölümlere ayırın.
• Sınır doğrulama:
  • Giriş verilerinin özelliklerinin (ör. kimlik sayısı), SparseCore'un önceden tanımlanmış operasyonel sınırlarına (ör. max_ids_per_partition ve max_unique_ids_per_partition) uygun olduğundan emin olun.
  • Giriş verileri bu sınırları aşarsa ana makine ön işleme katmanınız, verileri kısıtlamalara uyan daha küçük mini gruplara ayırmaya çalışabilir.
• Veri aktarımı:
  • İşlenen ve doğrulanan verileri TPU'nun yüksek bant genişliğine sahip belleğine (HBM) verimli bir şekilde kopyalayarak SparseCore yürütmeye hazır hale getirin.

Tablo yığınlamayı anlama:

Tablo yığınlama, yerleştirme arama verimliliğini artırmak için birden fazla yerleştirme tablosunun mantıksal olarak birleştirildiği önemli bir optimizasyon tekniğidir. Bu işlem genellikle temel makine öğrenimi çerçevesi tarafından otomatik olarak gerçekleştirilir.

• Özellik yığılması: Bu durum, birden fazla farklı özelliğin aynı temel yerleştirme tablosunu paylaşmasıyla ortaya çıkar. Yaygın bir örnek, farklı bağlamlardaki posta kodları gibi çeşitli kategorik özellikler için tek bir yerleştirme sözlüğü kullanmaktır.
• Tablo yığınlama: Bu senaryoda, birden fazla farklı yerleştirme tablosu birlikte yığınlanır. Aynı yerleştirme boyutunu ve optimize edici yapılandırmasını paylaşan tablolar genellikle gruplandırılır.

Tablo yığınlamanın temel avantajı, bu yığınlanmış tablolardaki işlemler için daha büyük bir etkili toplu iş boyutu oluşturulmasıdır. Bu, hesaplama ek yükünü azaltır ve çip içi iletişim (ICI) gecikmelerini gizlemede etkili olabilir. Optimum performans için orta düzeyde yığılmış tablo (genellikle 5 ila 100 arasında) kullanılması önerilir.

3. COO tensörlerine dönüştürme

Verilerin SparseCore tarafından işlenebilmesi için genellikle Koordinat (COO) seyrek tensör biçimine dönüştürülmesi gerekir. COO biçimi, genellikle üç dizi kullanarak seyrek matrisleri verimli bir şekilde temsil etmenin bir yoludur:

• row_ids: Sıfır olmayan her öğenin satır dizinlerini içeren bir dizi. Toplu işleme bağlamında bu genellikle toplu iş boyutuyla eşleşir.
• col_ids: Sıfır olmayan her öğenin sütun dizinlerini içeren bir dizi. Yerleştirmelerde bunlar genellikle özellik veya kimlik değerleridir.
• values (isteğe bağlı): Sıfır olmayan öğelerin ilgili (row, col) koordinatlardaki gerçek değerlerini içeren bir dizi. Kimlik sayılarıyla ilgili sınır hesaplamalarında (daha sonra ele alınacaktır) bu değerler (kazançlar) genellikle dikkate alınmaz.

Açıklayıcı örnek:

Kimlik gruplarını temsil eden bir giriş seyrek matrisini ele alalım:

[
    [id_A],                 // Sample 0
    [id_A, id_B, id_C],     // Sample 1
    [id_B, id_B, id_D],     // Sample 2 (note duplicate id_B)
]

COO biçimine dönüştürüldükten sonra (ve aynı örnekteki kimliklerin tekilleştirilmesinden sonra):

row_ids = [0, 1, 1, 1, 2, 2]
col_ids = [id_A, id_A, id_B, id_C, id_B, id_D]

Bu dönüştürme, SparseCore'un işleri nasıl işleyip dağıttığı açısından temel öneme sahiptir. Özellikle col_ids, bir kimliğin hangi SparseCore bölümüne ait olduğunu belirlemek için çok önemlidir. Bu sayede verimli parçalama ve arama yapılabilir.

4. SparsecoreConfig: Üst düzey API

Framework'e özel yerleştirme API'leri:

• JAX: https://github.com/jax-ml/jax-tpu-embedding
• TensorFlow: https://www.tensorflow.org/recommenders/api_docs/python/tfrs/layers/embedding/TPUEmbedding
• Keras: https://keras.io/keras_rs/api/embedding_layers/distributed_embedding

SparsecoreConfig veya XLA işaretleri gibi eşdeğer mekanizmalar, çeşitli SparseCore davranışlarını kontrol etmek için üst düzey bir arayüz görevi görür. Bu parametrelerin ayrıntılı bir şekilde anlaşılması, etkili performans ayarlaması ve modellerinizin doğru şekilde çalışmasını sağlamak için hayati önem taşır.

• disable_table_stacking: bool = False
  • Açıklama: Bu işaret, otomatik tablo yığınlamanın etkinleştirilip etkinleştirilmeyeceğini kontrol eder. Bu özellik, çerçeve tablolarda yığınlama yapılmasını önleyerek ek yüklerin artması ve çip arası bağlantı (ICI) gecikmesinin gizlenememesi nedeniyle performansın düşmesine neden olabilir.
  • Varsayılan: False (tablo yığınlamanın, çerçeve tarafından desteklendiği yerlerde varsayılan olarak etkinleştirildiği anlamına gelir).
• max_ids_per_chip_per_sample: int = 64
  • Açıklama: Bu parametre, giriş grubundaki bir örnekten tek bir çipin işleyebileceği toplam yerleştirme kimliği sayısına ilişkin genel bir üst sınır belirler. Bu sınır, tüm tablolarda toplanır. Bu, daha ayrıntılı tablo başına veya bölüm başına sınırlar dikkate alınmadan önce kaynakları çip düzeyinde yönetmek için kullanılan bir mekanizmadır. Bu değerin ince ayarı genellikle belirli model özelliklerine ve genel sistem kapasitesine bağlıdır.
  • Varsayılan: 64.
• max_ids_per_table: Optional[Dict[str, int]] = None
  • Açıklama: Bu parametre, tüm SparseCore'lardaki tüm bölümleri dikkate alınarak her mantıksal tablo için işlenebilecek maksimum yerleştirme kimliği sayısını (yinelenenler dahil olabilir) belirtir. Bu, max_ids_per_partition'dan daha geniş bir sınırdır. Bir T tablosu P bölüme ayrılırsa bu sınır, tüm P bölümlerine yönlendirilen kimliklerin toplamı için geçerlidir. Bu genellikle max_ids_per_partition_per_sample ve genel toplu iş boyutuyla ilgilidir.
  • Ayar: Genellikle bir sınır dosyası (örneğin, max_ids_per_partition tanımlanmışken xla_sparse_core_max_ids_file işareti kullanılarak) kullanılarak yapılandırılır. Bu tablo düzeyindeki kavram, bölüm düzeyindeki sınırları (max_ids ve max_uniques) ayarlamak için kullanılan bir yöntemdir.
  • Varsayılan: None (değer açıkça sağlanmamışsa bölüm başına sınırlardan veya diğer yapılandırmalardan çıkarılabilir).
• max_unique_ids_per_table: Optional[Dict[str, int]] = None
  • Açıklama: max_ids_per_table ile benzerdir ancak bu parametre, her mantıksal tablo için maksimum benzersiz kimlik sayısını belirtir. Bu, benzersiz kimlik işleme ve sonraki vektör işlemlerinde kullanılan cihaz üzerindeki arabelleklerin uygun şekilde boyutlandırılması için kritik bir ayardır.
  • Ayar: Genellikle bir sınır dosyasında da tanımlanır veya max_unique_ids_per_partition_per_sample öğesinden türetilir.
  • Varsayılan: None.
• allow_id_dropping: bool = False
  • Açıklama: Bu boole işareti, giriş verilerinde karşılaşılan kimlik sayısı (gözlemlenen sınırlar) derleme sırasında belirlenen sınırları (örneğin, max_ids_per_partition) aştığında kimlik bırakma işlemini kontrol eder.
    • Şu durumlarda True: Sınırların aşılmasına neden olacak kimlikler sessizce bırakılır. Genellikle bir bölümdeki kimlikler sıralı bir şekilde işlenir ve çalışan sayıyı belirlenen mini toplu iş sınırının üzerine çıkaracak tüm kimlikler atılır. Bu, programın yürütülmeye devam etmesini sağlar ancak model doğruluğu üzerinde olumsuz bir etki yaratabilir.
    • If False: Bir hata tetiklenir ve derlenen sınırlar aşılırsa süreç büyük olasılıkla sonlandırılır. Bu yaklaşım, tüm verilerin işlenmesini sağlar ancak sınırların daha muhafazakar bir şekilde yapılandırılmasını gerektirir.
  • Varsayılan: False (sessiz veri bırakma yerine taşmada hataya neden olur).

• initialize_tables_on_host: bool = True

  • Açıklama: Bu işaret, yerleştirme tablolarının, TPU'nun yüksek bant genişliğine sahip belleğine (HBM) aktarılmadan önce ana makine CPU'sunda başlatılıp başlatılmayacağını belirler. Tabloların ana makinede başlatılması standart bir uygulamadır. Bu ayarı True olarak ayarladığınızda bu kurala uyulur. False olarak ayarlanırsa cihaz üzerinde bir başlatma mekanizması olduğu anlaşılır. Bu durum, farklı performans etkilerine veya belirli başlatma ön koşullarına yol açabilir.

• enable_fast_table_initialization: bool = False

  • Açıklama: Tabloları doğrudan TPU'da başlatır. Bu, modelin başlatma sürelerini azaltmaya yardımcı olabilir.

5. Performans için ardışık düzen

Pipelining, TensorCore (TC) ve SparseCore (SC) üzerinde işlemlerin eşzamanlı olarak yürütülmesini sağlayan bir performans optimizasyonu tekniğidir. Bu hesaplamaları çakıştırarak genel işleme hızı önemli ölçüde artırılabilir.

• Mekanizma: Seyrek yerleştirme aramalarını (SC tarafından işlenir) ve yoğun katman hesaplamalarını (TC tarafından işlenir) içeren standart bir eğitim adımında, işlem hattı SC'nin adım i'nin kendi bölümü (örneğin, ileri veya geri geçiş) üzerinde çalışmasına olanak tanırken TC aynı anda aynı adım i'nin farklı bir bölümünü, hatta i-1 veya i+1 gibi bitişik adımların bölümlerini işler.
• Gradyanlar üzerindeki etkisi: SparseCore, "eski" gradyanlar üzerinde çalışabilir. Örneğin, adım i'nın geri yayılım aşamasında hesaplanan gradyanlar, adım i+2'e kadar tam olarak güncellenmeyebilir ve SC tarafından görünmeyebilir.
• Performans ve sayısal değerler arasındaki denge: Bu çakışan yürütme, önemli ölçüde hızlanmaya ve cihaz adım süresinde 2 kat iyileşmeye yol açabilir. Ancak, eski gradyanların kullanılmasından kaynaklanan sayılardaki (embedding_weights) küçük değişiklikler, model yakınsama davranışını veya elde edilen nihai doğruluğu etkileyebilir. Bu dengeyi kabul edip etmemek büyük ölçüde modele bağlıdır ve genellikle deneysel doğrulama gerektirir.
• Kontrol işareti: Pipelining, tf_xla_disable_full_embedding_pipelining ile kontrol edilebilir. Bu işareti true olarak ayarlamak tam işlem hattı oluşturmayı (TensorCore ve SparseCore hesaplamasının çakışması) devre dışı bırakır. false olarak ayarlamak (veya işaretin semantiği yanlış olduğunda etkinleştirmeyi ima ediyorsa) ise etkinleştirir.

Kavramsal ardışık düzen akışı:

• Ardışık düzen olmadan (basitleştirilmiş sıralı akış):

  Loop: SC/F_i -> TC/F_i -> TC/B_i -> SC/B_i

• Pipelining ile (basitleştirilmiş çakışan akış):

  Time ->
  Step i:   SC/F_i | TC/F_i | TC/B_i | SC/B_i
  Step i+1:          SC/F_i+1| TC/F_i+1| TC/B_i+1| SC/B_i+1
  

  Not: Donanımda ve derleyicide uygulanan gerçek işlem hattı aşamaları daha karmaşık olabilir. Genellikle veri bağımlılıklarını yönetmek ve doğruluğu sağlamak için ön döngüler, ana yürütme döngüleri ve son döngüler içerir.

6. XLA'nın rolü

XLA (Hızlandırılmış Doğrusal Cebir), genellikle TensorFlow gibi çerçevelerden gelen üst düzey hesaplama grafiklerini TPU'lar için özel olarak tasarlanmış, yüksek düzeyde optimize edilmiş makine koduna çeviren alana özel derleyicidir. Bu kapsamda, SparseCore'a yönelik işlemler için talimatlar oluşturulur.

SparseCore bağlamındaki temel işlevler:

• Seyrek işlemlerin derlenmesi: XLA, yerleştirme arama işlemlerini (ör. SparseDenseMatmulOp) ve diğer seyrek hesaplamaları düşük seviyeli, yürütülebilir SparseCore programlarına derlemekten sorumludur.
• Sınırların entegrasyonu: Yapılandırılmış operasyonel sınırları (ör. max_ids_per_partition, max_unique_ids_per_partition, genellikle xla_sparse_core_max_ids_file gibi işaretlerle belirtilen bir sınır dosyası aracılığıyla sağlanır) kullanarak özellikle SPMEM'de cihaz üzerindeki bellek arabelleklerinin boyutlarını statik olarak belirler ve bu arabellekleri ayırır.
• Hedeflenen optimizasyonlar: XLA, SparseCore mimarisi için özel olarak tasarlanmış bir dizi optimizasyon gerçekleştirir. Bunlar arasında talimat planlama, bellek düzeni dönüşümleri ve verimliliği en üst düzeye çıkarmak için işlemlerin birleştirilmesi yer alabilir.
• İşaretleri kullanarak kontrol etme: SparseCore davranışının, ayarlama parametrelerinin ve optimizasyon stratejilerinin birçok yönü XLA işaretleri (örneğin, xla_sparse_core_estimate_max_ids ile sınır tahmini veya xla_sc_detect_nan ile hata ayıklama) aracılığıyla gösterilir ve kontrol edilir.

Açık kaynak durumu:

Şu anda Sparsecore Implementation dahili olarak kullanılmaktadır ve libtpu.so kullanılarak sunulmaktadır.

Hata raporlama ve teşhis:

SparseCore yapılandırmaları veya kaynak kısıtlamalarıyla ilgili derleme hataları genellikle XLA:TPU derleme zamanı hataları olarak ortaya çıkar. Bu hata mesajları, kullanılabilir SPMEM için sınırların çok yüksek ayarlanması veya desteklenmeyen yapılandırmaların kullanılması gibi sorunlar hakkında değerli bilgiler sağlayabilir.

7. Sınırlamaların SparseCore'daki tablolara yansıması

SparseCore'da "sınırlar", öncelikle kullanılabilir SparseCore'lar arasında parçalanmış (dağıtılmış) her tablo için iki bölüm başına ayarı ifade eden temel yapılandırma parametreleridir:

• max_ids_per_partition: Bu, tek bir SparseCore'un tek bir hesaplama adımında belirli bir tablonun belirli bir bölümü için göndermesi veya işlemesi beklenen toplam kimliklerin (yinelenenler dahil) maksimum sayısını tanımlar.
• max_unique_ids_per_partition: Bu, herhangi bir tek SparseCore'un bir

Fiziksel tablo düzenine çeviri ve işleme:

• Tablo parçalama stratejisi: Yerleştirme tabloları genellikle sistemdeki tüm SparseCore'lar arasında "mod-parçalanır". Bu durumda, her SparseCore, her tablonun kelime dağarcığının (satırlar) farklı bir alt kümesinden sorumlu olur. Bir j kimliği genellikle SparseCore_k öğesine k = j % num_total_sparse_cores gibi bir formüle göre atanır.
• "Bölüm" tanımı: Bu bağlamda "bölüm", tek bir SparseCore'un aramaları işlediği yerleştirme tablosunun belirli segmentini ifade eder.
• SPMEM arabellek ayırma: Bu sınırlar, XLA derleyicisi tarafından cihaz üzerindeki geçici bellek (SPMEM) içindeki arabellekleri statik olarak boyutlandırmak ve ayırmak için kullanılır. Arabellekler, belirli bir bölümdeki kimliklerle ilgili gerekli tüm veriler (belirtilen max_ids ve max_unique_ids sınırlarına kadar) işlenmek üzere SPMEM'e yüklenebilecek şekilde boyutlandırılır. Bu durum, özellikle bir bölümdeki yinelenen kimlikleri azaltma (örneğin, Compressed Sparse Row (CSR) gösterimi oluştururken) gibi öğe bazında olmayan hesaplamalar için çok önemlidir. Bu hesaplamalarda, bölümün kimlikleriyle ilgili tüm veri kümesinin hızlı bellekte kolayca kullanılabilir olması gerekir.

• Derlenen sınırlar ve gözlemlenen sınırlar:

  • Gözlemlenen sınırlar: Bunlar, işlenen giriş verilerine göre çalışma zamanı sırasında her bölüm için karşılaşılan kimliklerin gerçek sayısıdır.
  • Gözlemlenen sınırlar derlenen sınırları aşarsa kimlik bırakmaya (allow_id_dropping etkinse) veya hatalara yol açabilir.

• Sınırları hesaplama: Uygun sınırları belirleme süreci, giriş verilerinin dağılımının dikkatli bir şekilde analiz edilmesini içerir. Belirli bir tablo için (T1 olarak adlandıralım, bu tablo T adlı daha büyük bir yığılmış tablonun parçası olabilir):

  1. Giriş grubu (ör. [BatchSize, MaxSequenceLength] şeklindeki bir 2D SparseTensor), başlangıçta mevcut SparseCore'lara bölünür. Örneğin, bir TensorCore 2 SparseCore ile eşleştirilirse her SparseCore, [BatchSize/2, MaxSequenceLength] şeklindeki bir alt grubu alabilir.
  2. Bu alt grup daha sonra COO biçimine dönüştürülerek row_ids ve col_ids elde edilir.
  3. Aynı örnekteki yinelenen kimlikler (ör. aynı row_id ve col_id değerlerine sahip girişler) kaldırılır.
  4. Kalan her benzersiz col_id (örnek içinde) için bu kimlikten sorumlu hedef SparseCore, mod-sharding kuralı kullanılarak belirlenir: target_sc_id = col_id % num_total_sparse_cores.
  5. Her target_sc_id için hedeflenen toplam kimlik sayısı (ids_per_sparse_core[target_sc_id]++) ve benzersiz kimlik sayısı (unique_ids_per_sparse_core[target_sc_id]++, söz konusu target_sc_id için benzersizlik sağlandıktan sonra) sayılır.
  6. Ardından, T1 tablosu için max_ids_per_partition değeri max(ids_per_sparse_core_array) olarak ayarlanır.
  7. Benzer şekilde, T1 tablosu için max_unique_ids_per_partition değeri max(unique_ids_per_sparse_core_array) olarak ayarlanır.
  8. T1 tablosu yığılmış bir tablonun bileşeniyse tüm bileşen tablolardaki istatistikler toplanmadan önce kimlik dağıtımlarına döndürme veya kaydırma gibi ek dönüşümler uygulanabilir. Bu, yükün çipler arasında dengelenmesine yardımcı olur.

Bu sınırları doğru şekilde ayarlamak denge gerektirir: Daha düşük sınırlar, adım başına işlenmesi gereken veri miktarı azaldığı ve SPMEM baskısı düşürüldüğü için performansı artırabilir. Ancak çok düşük ayarlanırsa aşırı mini toplu işleme veya istenmeyen kimlik bırakma durumlarına yol açabilir.

8. Her SparseCore'un nasıl iletişim kurduğu

SparseCore iletişimi, özellikle yerleştirme aramaları için bir kimlik listesinin işlenmesi bağlamında, birkaç koordineli mekanizmaya dayanır:

• Mod sharding ve örtülü yönlendirme:
  • Yerleştirme tabloları, sistemdeki tüm SparseCore'lar arasında mod-parçalanır.
  • Ana makine bir grup giriş verisi sağladığında (bu veriler daha sonra col_ids dahil olmak üzere COO biçiminde önceden işlenir), col_id değeri, hangi SparseCore'un söz konusu kimlikten sorumlu olduğunu belirlemek için kullanılır: target_sc_id = col_id % num_total_sparse_cores.
  • Her SparseCore, yalnızca kendisine atanan sözlük bölümleriyle eşleşen kimliklerin alt kümesini alır ve işler. Ana makine ön işleme aşaması, verileri her bir SparseCore'un ilgili kimliklerini kolayca tanımlayabileceği ve üzerinde işlem yapabileceği şekilde hazırlamak için çok önemlidir.
• Ana makineye göre veri dağıtımı:
  • Ana makine ön işleme mantığı, genel giriş toplu işini bölümlere ayırır ve row_ids ile col_ids'nin ilgili kısımlarını (varsa ilişkili özellikler veya ağırlıklarla birlikte) her bir SparseCore tarafından doğrudan erişilebilen belleğe (HBM) ya da SparseCore'ların gerekli verilerini getireceği paylaşılan bir HBM'ye dağıtır.
• Intra-SparseCore işleme:
  • Bir SparseCore, belirli bir tablo bölümü için belirlenen kimlik grubunu aldıktan sonra bu kimliklerin tekilleştirilmesi ve karşılık gelen yerleştirme vektörlerinin toplanması gibi işlemleri gerçekleştirir. Bunlar, öncelikle SparseCore'un kendi kutucuklarında yürütülen ve yerel SPMEM'ini kullanan yerel hesaplamalardır.
• Inter-SparseCore iletişimi (All-to-All):
  • İlk işleme aşamasından (ör. yerleştirme aramaları) sonra, sonuçları SparseCore'lar arasında birleştirmek veya yeniden dağıtmak için "herkesten herkese" iletişim kalıbı kullanılabilir (ör. etkinleştirmeleri, tüm orijinal örnek konumlarına karşılık gelen giriş bekleyen bir TensorCore katmanına aktarmadan önce). Bu, orijinal giriş grubu paralel işleme için dağıtıldıysa etkinleştirmelerin tamamını yeniden oluşturmak için çok önemlidir.
• Tensor çekirdekleriyle iletişim:
  • SparseCore'lar, TensorCore'larla iletişim kurarak yerleştirme etkinleştirmelerini (ileri geçiş sırasında) gönderir ve gradyanları (geri geçiş sırasında) alır. Bu etkileşim, XLA ile derlenmiş program tarafından düzenlenir ve genellikle HBM'yi aracı arabellek olarak kullanır. Daha önce bahsedilen işlem hattı stratejisi, bu SC-TC iletişiminin zamanlamasını ve senkronizasyonunu büyük ölçüde etkiler.

Temel olarak, kimliklerin uygun SparseCore'lara ilk "dağıtımı" büyük ölçüde parçalama şeması ve ana makine ön işleme adımlarıyla gerçekleştirilir. Sonraki iletişimde, SparseCore'lar yerel verileri üzerinde çalışır. Verilerin TensorCore'lar tarafından daha fazla işlenmeden önce SparseCore'lar arasında genel olarak değiştirilmesi veya yeniden sıralanması gerekiyorsa bu işlem, tümden tümüne iletişim gibi toplu iletişim işlemleriyle devam edebilir.

9. SparseCore bellek yönetimi

Her SparseCore, hesaplamalarını gerçekleştirmek için çeşitli farklı bellek türlerini verimli bir şekilde yönetir:

• Scratchpad bellek (SPMEM):
  • Doğa: Nispeten küçük ancak çok hızlı olan ve yalnızca her SparseCore'a özel olarak sunulan yerel SRAM. SPMEM'in bir önbellek olmadığını, kullanımının XLA derleyicisi tarafından açıkça yönetildiğini ve düzenlendiğini unutmamak önemlidir.
  • Amaç: SPMEM, "verileri fırsatçı bir şekilde aşamalandırmak" için kullanılır. Bu, devam eden SC hesaplamaları için gereken girişleri, çıkışları ve ara sonuçları içerir. SPMEM'de verileri hazırlamak, genellikle HBM'ye erişimle ilişkili olan yüksek gecikmeyi önemli ölçüde azaltır.
  • Boyutlandırma: "Sınırlar" bölümünde belirtildiği gibi, SPMEM arabellekleri derleme zamanında statik olarak boyutlandırılır. Bu boyutlandırma, max_ids_per_partition ve max_unique_ids_per_partition gibi parametrelere dayanır. Bu statik ayırma, bir tablo bölümünde yapılan herhangi bir işlem (ör. CSR azaltma) için bölüm kimlikleriyle ilgili gerekli tüm verilerin (tanımlanan sınırlara kadar) SPMEM'e sığmasını sağlar.
  • Derleyici optimizasyonları: XLA derleyicisi, HBM gecikmesini etkili bir şekilde gizlemek ve performansı en üst düzeye çıkarmak için SPMEM'de ne kadar verinin ve hangi belirli veri öğelerinin aşamalandırılması gerektiğini tam olarak belirlemek üzere gelişmiş optimizasyonlar içerir.
  • Dinamik ayırma kısıtlaması: SparseCore derleyicisi şu anda dinamik geçici alan ayırmayı desteklemiyor. Bu, sınırların dikkatli bir şekilde yapılandırılmasıyla statik boyutlandırmanın kritik önemini vurgular.
• Yüksek bant genişliğine sahip bellek (HBM):
  • Doğa: Tüm SparseCore'lar, TensorCore'lar ve ana sistem tarafından erişilebilen büyük bir paylaşılan bellek kaynağıdır. Birincil yerleştirme tabloları HBM'de depolanır.
  • Yığın kullanımı: SparseCore işlemleri, sınırlı SPMEM'e sığmayan veya işleme hattının daha büyük aşamaları arasında aktarılması gereken ara sonuçlar için genellikle HBM'de geçici depolama alanı gerektirir. Hem ileri hem de geri geçişler sırasında HBM yığını kullanımı aşağıdaki gibi tahmin edilebilir:
    • İleri Geçiş HBM Yığını (tek tablo) ≈ (2 * feature_width + 1) * max_unique_nz_per_row * logical_replica_count * 4 bayt
    • Geriye Doğru Geçiş HBM Yığını (tek tablo) ≈ 3 * feature_width * max_unique_nz_per_row * logical_replica_count * 4 bayt
  • Yığın kullanımı: HBM, ana makine tarafından yönetilen yığını da barındırır. Yığın, yoğun katman ağırlıkları, model tarafından kullanılan sabitler ve önceden getirilmiş giriş verileri gibi verileri depolar. Ana makinenin verileri önceden getirdiği adım sayısı arttıkça yığın kullanımı da artar (maximum_parallel_iterations işaretiyle kontrol edilir). Daha fazla önceden getirme, ana makineden cihaza aktarımları cihaz hesaplamasıyla çakıştırarak performansı artırabilir ancak daha fazla HBM de tüketir.
  • HBM optimizasyonu için serileştirme: xla_sc_num_serialized_tables_to_optimize_hbm işareti, herhangi bir zamanda HBM yığın belleğinde kaç tablonun verilerinin "canlı" tutulacağını kontrol etme mekanizması sağlar. Bu sayının artırılması, daha fazla tablo için işlemeyi etkili bir şekilde serileştirir. Bu da HBM yığını kullanımının zirve noktasını azaltabilir ancak paralelliğin azalması nedeniyle performans düşebilir.
• Vektör belleği (VMEM):
  • VMEM, yalnızca TC (TensorCore) tarafından kullanılan yerel bir geçici bellek alanıdır. VMEM doğrudan SparseCore tarafından yönetilmese de SC'nin etkileşimde bulunduğu bellek ekosisteminin ayrılmaz bir parçasıdır. Bu etkileşim, öncelikle TensorCore aracılığıyla gerçekleşir.

Genel bellek yönetimi stratejisi:

SparseCore'un temel bellek yönetimi stratejisi, SparseCore birimi tarafından etkin olarak işlenen "sık kullanılan" veriler için küçük ve hızlı SPMEM'in kullanılmasını temel alır. Böylece, daha yavaş olan HBM'ye erişimler en aza indirilir. Yapılandırılan sınırlar, SPMEM'in taşmamasını sağlamak için kullanılan birincil mekanizmadır. HBM, büyük yerleştirme tablolarını ve SPMEM kapasitesini aşan veya farklı işleme birimleri ya da işlem hattı aşamaları arasında paylaşılması gereken geçici verileri depolamak için kullanılır. XLA derleyicisi, bu mimari ilkeler ve kullanıcı tarafından yapılandırılan sınırlara göre tüm veri hareketini ve arabellek ayırmayı düzenlemekten sorumludur.

10. Performans ve bellek sorunları

SparseCore ile optimum performansa ulaşmak için olası darboğazların ve bunların nasıl giderileceğinin net bir şekilde anlaşılması gerekir. Bunlar ana makinede, SparseCore'un kendisinde veya TensorCore'larla etkileşiminde ortaya çıkabilir.

Sık karşılaşılan performans sorunları:

• Ana makine darboğazı:
  • Sorun: Ana makine CPU'su, verileri önceden işleyip TPU'ya yeterince hızlı bir şekilde aktaramayabilir. Bu durum, SparseCore'ların ve TensorCore'ların yeterince kullanılmamasına neden olur. Bu, sık karşılaşılan bir performans sınırlayıcıdır.
  • Azaltma: Ana makine CPU kullanımını ve giriş işlem hattı metriklerini izleyin. Ana makine tarafındaki veri yükleme ve ön işleme rutinlerini optimize edin (COO dönüşüm ipuçlarına bakın). Veri önceden getirme özelliğine ince ayar yapmak için maximum_parallel_iterations işaretini ayarlayın.
• En iyi olmayan TC/SC senkronizasyonu (ardışık işlem hattı eksikliği):
  • Sorun: TensorCore ve SparseCore arasındaki işlem hattı oluşturma devre dışı bırakılırsa veya verimli bir şekilde çalışmazsa birimlerden biri diğerini beklerken önemli ölçüde zaman harcayabilir. Bu durum, genel sistem işleme hızını düşürür.
  • Azaltma: Pipelining'in etkinleştirildiğinden emin olun (örneğin, tf_xla_disable_full_embedding_pipelining = false veya eşdeğeri).
• Sınırlamadan kaynaklanan darboğazlar:
  • Sorun:
    • Sınırlar çok düşük: Sıkı sınırlara uymak için giriş toplu işlemlerini çok sayıda daha küçük alt toplu işe bölme (aşırı mini toplu işleme) tetiklenebilir. Bu işlem doğruluğu korurken her mini toplu işlem, bir miktar işlem ek yükü getirir ve genel yürütmeyi yavaşlatabilir. allow_id_dropping doğruysa çok düşük sınırlar, model doğruluğunu etkileyen kimlik bırakmaya da yol açabilir.
    • Sınırlar çok yüksek (ancak yine de uygun): Çok yüksek sınırlar mini toplu işlemeyi engelleyebilir ancak gerçek veri özellikleri nadiren bu tepe değerlerine yaklaşıyorsa SPMEM baskısını gereksiz yere artırabilir. Ayrıca, kesinlikle gerekenden daha fazla HBM yığını kullanımına da yol açabilirler.
    • Derleme hataları: Yapılandırılan sınırlar, mevcut fiziksel bellekten daha fazla SPMEM veya HBM yığını gerektiriyorsa derleme başarısız olur.
  • Azaltma: Sınırların doğru şekilde ayarlandığından emin olun.
• Veri dağılımı çarpıklığı:
  • Sorun: Belirli SparseCore bölümleri, diğerlerine kıyasla sürekli olarak orantısız bir şekilde daha fazla sayıda kimlik alıyorsa (bu da kimlik dağıtımının kötü olduğunu gösterir) aşırı yüklenen bu SparseCore'lar performans darboğazı haline gelir.
  • Azaltma: Mini toplu işleme sırasında kimlik karıştırma, özellikle "popüler" kullanıcı tabloları içeren yığılmış tablolarda bu sorunu hafifletmeye yardımcı olabilir. Tablo başına uygun ve dengeli sınırlar belirlemek için kimlik dağıtımlarını dikkatlice analiz edin.
• Tablo üst üste yerleştirme sorunları:
  • Sorun:
    • Çok az tablo yığılmış: ICI gecikmesini etkili bir şekilde gizlemek veya işlem yükünü yeterince azaltmak için yeterli olmayabilir.
    • Çok fazla tablo yığılmış: Yönetilmesi zorlaşan veya kullanılabilir kaynak sınırlarını aşan çok büyük mantıksal tabloların oluşturulmasına neden olabilir.
  • Azaltma:
    • İstifleme için optimum sayıda tablo olduğundan emin olun. Genel bir kural, üst üste yerleştirme için 5-100 tablo arasında bir "ideal nokta" olduğunu belirtir.
• Verimsiz sayısal değerler/nicelendirme:
  • Sorun: BF16 veya nicelenmiş tam sayılar gibi daha düşük hassasiyetli biçimler yeterli olacağı (ve daha hızlı hesaplama sunacağı) halde tam FP32 hassasiyetinin kullanılması performans açısından darboğaz oluşturabilir.
  • Azaltma: Daha düşük hassasiyetli seçenekleri keşfedin. Ancak nicemlemenin kendisinin bir miktar ek yükü olduğunu ve model doğruluğunu korumak için nicemleme parametrelerinin dikkatli bir şekilde ayarlanması gerekebileceğini unutmayın.
• HBM bant genişliği doygunluğu:
  • Sorun: HBM'ye ve HBM'den aşırı veri hareketi (çok küçük özellik genişliklerinden kaynaklanabilir ve bu da yüksek dolgu ek yüküne, verimsiz bellek erişim kalıplarına veya son derece fazla sayıda aramaya yol açar), kullanılabilir HBM bant genişliğini doyurabilir.
  • Azaltma: TPU sayısını ölçeklendirmek, HBM bant genişliği doygunluğuna yardımcı olabilir.

Sık karşılaşılan bellek darboğazları:

• SPMEM taşması (derleme hatası):
  • Sorun: max_ids_per_partition ve max_unique_ids_per_partition çok yüksek ayarlanırsa XLA derleyicisi yeterli SPMEM'i ayıramayabilir ve bu da "Fixed size allocations (...) do not fit in TileSpmem (...)" gibi derleme hatalarına neden olur. Ayrıca, (sample_count * feature_width) / kNumTiles (burada kNumTiles, SC başına döşeme sayısıdır) terimi, döşeme SPMEM'inde işlenenleri toplama için çok büyükse "Gather operand too large..." gibi hatalar oluşabilir.
  • Azaltma: Toplu iş boyutunu küçültün veya işleme için kullanılan çip sayısını artırın.
• HBM yığın taşması (çalışma zamanı veya derleme):
  • Sorun: feature_width, max_unique_nz_per_row ve logical_replica_count kombinasyonu, kullanılabilir HBM'yi aşan HBM yığın bellek gereksinimlerine yol açarsa bu durum, çalışma zamanında veya derleme sırasında bellek yetersiz (OOM) hatalarına neden olabilir.
  • Azaltma: Tabloların işlenmesini seri hale getirerek HBM yığını kullanımını azaltmak için xla_sc_num_serialized_tables_to_optimize_hbm işaretini ayarlayın (bu genellikle performans maliyetine yol açar).
• HBM yığını tükenmesi:
  • Sorun: Temelde çok büyük yoğun katman ağırlıkları, bellekte depolanan çok sayıda sabit veya aşırı agresif giriş önceden getirme (yüksek maximum_parallel_iterations) nedeniyle oluşur.
  • Azaltma: Yığın kullanımını XProf Memory Viewer gibi araçlarla izleyin.
• Doldurma ek yükü:
  • Sorun: Yerleştirme tabloları, özellik boyutunda 32B ile hizalanacak şekilde (8 kayan sayıya eşdeğer) doldurulur. Sonuç olarak, küçük özellik genişlikleri (örneğin, 1 kayan nokta) önemli bir doldurma ek yüküne (örneğin, ayrılan arabellek alanının 7/8'i doldurmadır) neden olarak HBM'nin boşa harcanmasına yol açar. Tabloların kelime hazinesi boyutu da sistemdeki SparseCore sayısının katı olacak şekilde doldurulur. Ancak bu etki, yeterince yüksek kelime hazinesi boyutuna sahip tablolarda genellikle ihmal edilebilir.

Performansı ve belleği etkileyen genel faktörler:

• Topoloji: Kullanılabilir çip sayısı ve bunların birbirine bağlanma mimarisi.
• Toplu iş boyutu: SparseCore başına sample_count değerini doğrudan etkiler. Bu da bellek tüketimini ve işlem yükünü etkiler.
• Veri biçimlendirme: Cihaz üzerinde verilerin düzeninin verimli olmasını sağlamak, optimum performans için çok önemlidir.

11. SparseCore profilini analiz etme

Performans profilini analiz etmek, SparseCore iş yüklerinizdeki darboğazları belirlemek ve optimizasyon fırsatlarını ortaya çıkarmak için önemli bir adımdır.

1. İzleme bilgisi alma:
   • Modeliniz eğitilirken veya çıkarım çalıştırılırken ayrıntılı bir yürütme izi yakalamak için XProf gibi profilleme araçlarını kullanın. Bu izleme, ana makinede, Tensor çekirdeklerinde ve Sparse çekirdeklerinde gerçekleşen işlemlerin zaman çizelgesini sağlar.
2. İzleyiciyi inceleyin (örneğin, XProf veya TensorBoard'da):
   • Düzenleyenin etkinliği: Düzenleyenin etkinliğini inceleyin. TPU etkinliğinde önemli boşluklar var mı? Bu tür boşluklar, ana makinenin bir darboğaz olduğunu ve verileri yeterince hızlı besleyemediğini gösterebilir. Giriş ardışık düzeninizin performansını analiz edin.
   • TensorCore (TC) ve SparseCore (SC) etkinliği:
     • Hem TC hem de SC için yürütme zaman çizelgelerine bakın. Bunlar paralel olarak mı çalışıyor? Bu, etkili bir işlem hattı olduğunu mu gösteriyor? Yoksa bir birimin diğerini beklediği uzun süreler var mı?
     • Hem SC hem de TC'de en çok zaman alan işlemleri (en uzun süren işlemler) belirleyin.
     • Görsel izleme çıktıları (genellikle zaman içinde farklı işlemleri temsil eden renkli bloklar gösterir, örneğin TPU:0 SparseCore 1 (pid 1005)), baskın işlemleri ve boşta kalma sürelerini görsel olarak belirlemek için çok değerlidir.
   • Adım süresi analizi: Genel adım süresini gözlemleyin ve bunun ana makine işleme, SC hesaplama ve TC hesaplama arasında nasıl dağıtıldığını veya bölündüğünü anlayın.
3. Bellek analizi (XProf Memory Viewer):
   • Yığın kullanımı: HBM yığın kullanımını incelemek için XProf'un "Bellek Görüntüleyici" sekmesi gibi araçları kullanın. Bu, büyük model ağırlıklarının, sabitlerin veya aşırı agresif giriş önceden getirme işlemlerinin aşırı miktarda HBM kullanıp kullanmadığını belirlemeye yardımcı olabilir. --vmodule=best_fit_allocator=1 gibi işaretleri etkinleştirmek, en yüksek yığın kullanımının günlüklerini sağlayabilir.
   • Yığın kullanımı (dolaylı): Doğrudan HBM yığın profil oluşturma karmaşık olsa da bellek yetersiz hatasıyla karşılaşırsanız ve yığın kullanımı makul görünüyorsa HBM yığınının tükenmesi (genellikle aşırı büyük sınırlar veya özellik genişliklerinden kaynaklanır) güçlü bir şüphelidir. HBM yığını kullanımı için sağlanan formüller, bu tahmini yapmanıza yardımcı olabilir.
4. Belirli kalıplar olup olmadığına bakın:
   • Mini gruplama: Sınırlar sık sık aşılıyorsa izlemede mini gruplama kanıtları (örneğin, genel grup boyutu için beklenenden daha fazla sayıda küçük SC işlemi) görebilirsiniz. Bu genellikle günlüklerden veya belirli işlemlerin çağrı sayılarını gözlemleyerek anlaşılabilir.
   • Kimlik bırakma: Kimlik bırakma etkinse ve gerçekleşiyorsa sistem günlükleri bu konuda bilgi verebilir. Bu durum, yapılandırılan sınırların giriş verileri için çok kısıtlayıcı olduğunun da net bir göstergesi olur.
   • Derleme süreleri: Özellikle geri bildirim odaklı optimizasyon (FDO) etkinleştirilmişse ve sınırlar sık sık ayarlanıyorsa yeniden derleme sürelerinin uzaması, genel eğitim süresine önemli bir ek yük getirebilir.
5. İşaretler ve yapılandırmayla ilişkilendirme:
   • Profilde gözlemlenen davranışı SparseCore yapılandırmalarınızla (sınır dosyalarındaki ayarlar, XLA işaretleri) ilişkilendirin. Örneğin, xla_sc_num_serialized_tables_to_optimize_hbm yüksek bir değere ayarlanırsa SC performansının daha yavaş olmasını ancak HBM yığını tüketiminin daha düşük olmasını bekleyebilirsiniz.
6. Tekrarlanan süreç:
   • Profillendirme genellikle yinelemeli bir iyileştirme sürecidir. Belirli bir değişiklik yapın (sınırı ayarlayın, özelliği etkinleştirin veya devre dışı bırakın), yeni bir profil oluşturun ve ardından değişikliğinizin etkisini görmek için önceki profille karşılaştırın.

12. Genel hata ayıklama işaretleri

SparseCore yürütmeyle ilgili sorunların hata ayıklamasına yardımcı olmak için çeşitli işaretler etkinleştirilebilir. Bu kontrollerin etkinleştirilmesinin genellikle performans cezasına yol açtığını ve bu nedenle üretim çalıştırmaları için devre dışı bırakılması gerektiğini unutmayın.

• Kimlik kontrolleri (aralık dışında):
  • İşaretle: xla_sparse_core_enable_id_bound_check = true
  • Amaç: Giriş verilerindeki yerleştirme kimliklerinin, belirli bir yerleştirme tablosu için tanımlanan geçerli sözcük aralığının dışında olup olmadığını tespit etmek amacıyla ana makine sisteminde kontroller yapılmasını sağlar. Bu sayede, yanlış veya bozuk giriş verileriyle ilgili sorunları yakalayabilirsiniz.
• NaN denetleyicisi:
  • İşaretle: xla_sc_detect_nan = true
  • Amaç: SparseCore'da işlenen kayan nokta verilerindeki NaN (Sayı Değil) değerlerinin algılanmasını sağlar. Çeşitli derleyici geçişlerinin giriş veya çıkışlarında NaN algılanırsa bu işaret hata oluşmasına neden olur. Bu tür hatalar genellikle NaN'nin nerede karşılaşıldığı hakkında bilgi verir.
• Sınır kontrolü (bellek erişimi):
  • İşaretle: xla_sc_assert_level=bounds
  • Amaç: Bu işaret, bellek erişim talimatlarını (ör. VMEM yüklemeleri/depolamaları ve DMA işlemleri) dinamik kontroller içerecek şekilde yeniden yazan ASAN (AddressSanitizer) tarzı bir aracı etkinleştirir. Bu kontroller, bellek erişiminin hedef bellek bölgesinin ayrılmış sınırları içinde olup olmadığını doğrular.
  • Davranış: Sınırların dışında bir bellek erişimi algılanırsa yürütme başarısız olur.
  • Dikkat: Bu kontrol aracının, örneğin kontrol aracı tarafından tam olarak anlaşılamayan karmaşık adımlı erişim kalıpları nedeniyle yanlış pozitif sonuçlar üretmesi mümkündür. Bu dönüşüm, arka uç derleme sürecinin son aşamasında uygulanır.
• Arabellek denetleyicisi (bellek bozulması):
  • İşaretler:
    • xla_tpu_buffer_contents_sanitizer_config='cores_to_sanitize: [TC, SC_SCS, SC_TILE], sanitizer_mode: LOCAL_ONLY'
    • xla_tpu_verify_launch_id_across_cores=true
  • Amaç: Bu işaretler, bellek arabelleklerinin yanlışlıkla bozulmamasını veya alakasız işlemlerle üzerine yazılmamasını sağlar. Buffer Sanitizer, arabelleklerin içeriğini kontrol ederek beklenmedik şekilde değişmediğini doğrular.

13. Kuantizasyon desteği

SparseCore'un SparseDenseMatmulOp özelliği, hem 32 bit kayan nokta (FP32) hem de tam sayı veri türlerini kullanarak yerleştirme tablolarında işlemleri desteklemek için tasarlanmıştır. Model eğitimi genellikle yerleştirme tabloları için FP32 duyarlılığı kullanılarak gerçekleştirilirken eğitim sonrası nicemleme (PTQ) uygulanabilir. PTQ, çıkarım için daha düşük hassasiyetli veri türlerinin (ör. 8 bitlik tam sayılar) kullanılmasına olanak tanır. Bu da performansı artırabilir ve bellek ayak izini azaltabilir.

Simüle Edilmiş Kuantizasyon:

SparseDenseMatmulOp, "simüle edilmiş nicemleme" yapacak şekilde yapılandırılabilir. Bu çalışma modunda, yerleştirme vektörleri önce daha düşük bir hassasiyete kuantize edilir ve ardından sonraki hesaplamalarda kullanılmadan önce tekrar daha yüksek bir hassasiyete (ör. FP32) dekuantize edilir. Bu teknik, modellerin nicemleme gürültüsünün etkileri dikkate alınarak eğitilmesine olanak tanır. Simüle edilmiş nicemleme ile eğitim, çıkarım için tamamen nicemlenmiş nihai modelin doğruluğunu artırabilir.

SparseDenseMatmulOp için yapılandırma özellikleri (nicelendirme için):

• quantization_config_num_buckets = 256
  • Bu özellik, 32 bitlik bir kayan nokta sayısının nicelleştirileceği ayrı paketlerin veya seviyelerin sayısını belirtir. Örneğin, 8 bitlik tam sayılara nicelendirirken genellikle 2^8 =256 paket belirtilir.
• quantization_config_low = -X.X
  • Bu özellik, nicemleme aralığındaki minimum kayan nokta değerini tanımlar. Belirtilen bu minimum değerin altındaki giriş değerleri, nicelendirme sırasında bu minimum değere kırpılır.
• quantization_config_high = Y.Y
  • Bu özellik, nicemleme aralığındaki maksimum kayan nokta değerini tanımlar. Belirtilen bu maksimum değerin üzerindeki giriş değerleri, nicemleme sırasında bu maksimum değere kırpılır.

Sayısal değerler ve işlem hattı etkileşimi:

Modelin sayısal davranışı, TensorCore ve SparseCore arasında işlem hattı oluşturmanın etkin olup olmamasına bağlı olarak değişebilir. Pipelining etkinse SparseCore tarafından işlenen gradyanlar "eski" (önceki bir yinelemeden) olabilir. Bu durum, nicemleme süreciyle etkileşime girebilir ve model eğitimi dinamiklerini veya nihai doğruluğu etkileyebilir.

14. Yakında kullanıma sunulacak özellikler ve son iyileştirmeler

SparseCore ekosistemi sürekli olarak geliştirilmekte ve iyileştirilmektedir.

Yol haritası:

• Örnek boyutlu mini toplu işleme:
  • Bu özellik, mevcut sözcük boyutu mini toplu işleme özelliklerini tamamlayıcı bir özellik olarak planlanmıştır.
  • Bu, örnek boyutu boyunca yerleştirme girişlerinin daha fazla bölümlenmesine olanak tanır. Bu, aramaları bir seferde örneklerin bir alt kümesinden filtreleyip işleyebilen cihaz üzerinde döngüler oluşturularak sağlanır. Bu tür bir özellik, örnek başına çok yüksek kimlik sayılarını yönetmek veya işlem birimleri arasında yük dengelemesini iyileştirmek için faydalı olabilir.
• Satır başına 8'den az tam sayı içeren yerleştirmeler (küçük özellik genişlikleri) için daha iyi destek:
  • Mevcut tasarım, 8 kayan noktadan (32 bayta karşılık gelir) daha az olan özellik genişliklerini yerleştirmek için genellikle önemli bir dolgu kullanır. Bu dolgu, HBM'nin boşa harcanmasına ve bilgi işlem kaynaklarının yeterince kullanılmamasına neden olabilir. Gelecekteki iyileştirmeler, küçük özellik boyutlarına sahip tablolarda bu verimsizliği azaltmayı amaçlamaktadır.

Son iyileştirmeler:

• HBM'de toplama operandlarının aşamalandırılması:
  • Bu optimizasyon, bazı toplama işlemi girişlerinin veya çıkışlarının daha büyük HBM'de aşamalandırılmasına izin vererek paylaşılan geçici bellek (SPMEM) üzerindeki baskıyı azaltmaya yardımcı olur.
• Yığın belleği kullanımında azalma:
  • SparseCore işlemleri sırasında HBM yığını bellek tüketimini azaltmak için geliştirmeler yapıldı. Bu geliştirmeler, genel performansı veya işleme hızını olumsuz etkilemeden yapıldı.

Bu geliştirmeler, SparseCore'un performansını, bellek verimliliğini ve operasyonel esnekliğini daha da geniş bir aralıkta seyrek iş yükleri için iyileştirmeye odaklanmıştır.