شیرجه عمیق به SparseCore برای مدل‌های جاسازی بزرگ (LEM)

SparseCore یک پردازنده کاشی‌شده تخصصی است که برای شتاب‌دهی با کارایی بالا در بارهای کاری که شامل دسترسی و محاسبات نامنظم و پراکنده به حافظه است، به ویژه در مجموعه داده‌های بزرگ ذخیره‌شده در حافظه با پهنای باند بالا (HBM) مهندسی شده است. در حالی که در کارهایی مانند جاسازی جستجوها برتر است، قابلیت‌های آن به سرعت بخشیدن به انواع بارهای کاری پویا و پراکنده دیگر گسترش می‌یابد.

1. مقدمه ای بر SparseCore

ویژگی های کلیدی معماری:

• معماری کاشی : شامل چندین کاشی محاسباتی است (هر کاشی یک واحد جریان داده کامل با حافظه محلی و واحد پردازش خود است) که امکان پردازش موازی را فراهم می کند.
• اجرای پویا : به طور طبیعی از جریان کنترل وابسته به داده و دسترسی به حافظه پشتیبانی می کند که برای داده های پراکنده بسیار مهم است.
• پردازش برداری : از وظایف برداری کوچک (8 عنصری یا 16 عنصری، بسته به نسخه سخت افزاری) برای محاسبه کارآمد استفاده می کند.
• کنترل متمرکز : یک ترتیب سنج SparseCore وظایف را در تمام کاشی ها هماهنگ می کند و از عملیات هماهنگ اطمینان می دهد.
• پشتیبانی از خلاصه‌سازی داده‌ها : شامل عملیات تخصصی بین خطوط مفید برای کارهایی مانند مرتب‌سازی، فیلتر کردن، و جمع‌های پیشوندی است.
• سلسله مراتب حافظه : به طور استراتژیک از HBM برای ذخیره مجموعه داده های بزرگ و حافظه محلی اسکرچ پد (SPMEM) برای مرحله بندی داده هایی که به طور مکرر دسترسی دارند، استفاده می کند و تأخیر HBM را به طور قابل توجهی کاهش می دهد.

مشخصات در یک نگاه:

2. پیش پردازش میزبان SparseCore

آماده سازی موثر داده ها برای عملکرد SparseCore بسیار مهم است، و اینجاست که پیش پردازش میزبان نقش حیاتی ایفا می کند. این شامل چندین عملکرد کلیدی است:

• تبدیل داده ها :
  • تغییرات لازم را در داده های ورودی خام اعمال کنید.
  • تبدیل‌های شناسه را مدیریت کنید، که مخصوصاً هنگام برخورد با ویژگی یا جدول انباشته مهم است.
  • داده های ورودی را به فرمت مختصر (COO) تبدیل کنید که در بخش زیر به تفصیل شرح داده شده است.
  • داده ها را برای توزیع کارآمد در میان هسته های Sparse مختلف موجود در تراشه تقسیم کنید.
• اعتبار سنجی حد :
  • اطمینان حاصل کنید که ویژگی های داده های ورودی (به عنوان مثال، تعداد شناسه ها) با محدودیت های عملیاتی از پیش تعریف شده SparseCore، مانند max_ids_per_partition و max_unique_ids_per_partition مطابقت دارند.
  • اگر داده‌های ورودی از این محدودیت‌ها فراتر رود، لایه پیش‌پردازش میزبان شما می‌تواند سعی کند داده‌ها را به دسته‌های کوچک‌تر تقسیم کند که در محدوده محدودیت‌ها قرار می‌گیرند.
• انتقال داده :
  • داده های پردازش شده و تایید شده را به طور موثر در حافظه با پهنای باند بالا (HBM) TPU کپی کنید و آن را برای اجرای SparseCore آماده کنید.

آشنایی با چیدمان جدول:

انباشته کردن جدول یک تکنیک بهینه سازی قابل توجه است که در آن چندین جدول جاسازی به طور منطقی ترکیب می شوند تا کارایی جستجوی جاسازی را افزایش دهند. این فرآیند معمولاً به طور خودکار توسط چارچوب ML زیربنایی انجام می شود.

• انباشتن ویژگی : این زمانی اتفاق می‌افتد که چندین ویژگی متمایز از یک جدول جاسازی زیرین مشترک استفاده می‌کنند. یک مثال رایج استفاده از یک فرهنگ لغت جاسازی شده برای ویژگی‌های دسته‌بندی مختلف مانند کدهای پستی از زمینه‌های مختلف است.
• انباشته شدن جدول : در این سناریو، چندین جدول تعبیه شده مجزا در کنار هم چیده می شوند. جداولی که ابعاد جاسازی و پیکربندی بهینه ساز یکسانی دارند اغلب گروه بندی می شوند.

مزیت اصلی انباشتن میز، ایجاد یک اندازه دسته ای موثرتر برای عملیات روی این میزهای انباشته است. این امر سربار محاسباتی را کاهش می دهد و می تواند در پنهان کردن تأخیرهای ارتباط بین تراشه (ICI) مؤثر باشد. برای عملکرد بهینه، تعداد متوسطی از میزهای روی هم (به طور کلی در محدوده 5 تا 100) توصیه می شود.

3. تبدیل به تانسور COO

قبل از اینکه داده‌ها توسط SparseCore پردازش شوند، معمولاً به یک فرمت تانسور پراکنده Coordinate (COO) تبدیل می‌شوند. فرمت COO راهی برای نمایش ماتریس های پراکنده به طور کارآمد معمولاً با استفاده از سه آرایه است:

• row_ids : آرایه ای حاوی شاخص های ردیف برای هر عنصر غیر صفر. در زمینه پردازش دسته ای، این اغلب با بعد دسته ای مطابقت دارد.
• col_ids : آرایه ای حاوی شاخص های ستون برای هر عنصر غیر صفر. برای جاسازی ها، اینها اغلب مقادیر ویژگی یا شناسه هستند.
• values (اختیاری): آرایه ای که مقادیر واقعی عناصر غیر صفر را در مختصات مربوطه ( row ، col ) نگه می دارد. برای محاسبات حد (که بعداً بحث خواهد شد) مربوط به شمارش شناسه، این مقادیر (سود) اغلب در نظر گرفته نمی شوند.

مثال گویا:

یک ماتریس پراکنده ورودی را در نظر بگیرید که دسته ای از شناسه ها را نشان می دهد:

[
    [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 (و احتمالاً پس از حذف شناسه ها در همان نمونه):

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

این تبدیل برای نحوه پردازش و توزیع SparseCore اساسی است. به طور خاص، col_ids برای تعیین اینکه یک ID متعلق به کدام پارتیشن SparseCore خاص است، بسیار مهم است و امکان اشتراک گذاری و جستجوی کارآمد را فراهم می کند.

4. SparsecoreConfig: API سطح بالا

APIهای تعبیه شده خاص چارچوب:

• 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 یا مکانیسم‌های معادل آن مانند پرچم‌های XLA، به عنوان یک رابط سطح بالا برای کنترل طیف گسترده‌ای از رفتارهای SparseCore عمل می‌کند. درک کامل این پارامترها برای تنظیم عملکرد موثر و اطمینان از عملکرد صحیح مدل‌های شما حیاتی است.

• disable_table_stacking: bool = False
  • توضیح : این پرچم کنترل می‌کند که آیا انباشته شدن جداول به صورت خودکار مانع از انباشتن جداول در چارچوب می‌شود، که به طور بالقوه منجر به کاهش عملکرد به دلیل افزایش هزینه‌های سربار و کاهش توانایی پنهان کردن تأخیر بین تراشه (ICI) می‌شود.
  • پیش‌فرض : False (به این معناست که چیدمان جدول معمولاً به‌طور پیش‌فرض در جایی که چارچوب آن را پشتیبانی می‌کند فعال می‌شود).
• max_ids_per_chip_per_sample: int = 64
  • توضیح : این پارامتر یک حد بالایی جهانی را بر تعداد کل شناسه‌های تعبیه‌شده که یک تراشه می‌تواند از یک نمونه در دسته ورودی پردازش کند، ایجاد می‌کند، که در همه جداول جمع‌آوری شده است. این مکانیزمی است برای مدیریت منابع در سطح تراشه، قبل از اینکه محدودیت های گرانول بیشتر در هر جدول یا هر پارتیشن در نظر گرفته شوند. تنظیم دقیق این مقدار معمولاً به ویژگی های مدل خاص و ظرفیت کلی سیستم بستگی دارد.
  • پیش فرض : 64 .
• max_ids_per_table: Optional[Dict[str, int]] = None
  • توضیح : این پارامتر حداکثر تعداد شناسه‌های تعبیه‌شده (که می‌تواند شامل موارد تکراری باشد) را مشخص می‌کند که می‌تواند برای هر جدول منطقی با در نظر گرفتن تمام پارتیشن‌های آن در همه SparseCores پردازش شود. این یک محدودیت گسترده‌تر از max_ids_per_partition است. اگر جدول T به پارتیشن‌های P تقسیم شود، این محدودیت برای مجموع شناسه‌های هدایت‌شده به تمام پارتیشن‌های P اعمال می‌شود. اغلب مربوط به max_ids_per_partition_per_sample و اندازه کلی دسته است.
  • تنظیمات : معمولاً با استفاده از یک فایل limits پیکربندی می‌شود (به عنوان مثال، با استفاده از پرچم xla_sparse_core_max_ids_file )، که در آن max_ids_per_partition تعریف شده است. این مفهوم سطح جدول روشی برای تعیین محدودیت های سطح پارتیشن ( max_ids و max_uniques ) است.
  • پیش‌فرض : None (مقدار ممکن است از محدودیت‌های هر پارتیشن یا تنظیمات دیگر استنتاج شود، اگر صریحاً ارائه نشده باشد).
• max_unique_ids_per_table: Optional[Dict[str, int]] = None
  • توضیح : مشابه max_ids_per_table است، اما این پارامتر حداکثر تعداد شناسه های منحصر به فرد را برای هر جدول منطقی مشخص می کند. این یک تنظیم حیاتی برای اندازه‌گیری مناسب بافرهای روی دستگاه است که در پردازش شناسه منحصربه‌فرد و عملیات بردار بعدی استفاده می‌شود.
  • تنظیمات : همچنین معمولاً در یک فایل limits تعریف می‌شود یا از max_unique_ids_per_partition_per_sample مشتق می‌شود.
  • پیش فرض : None .
• allow_id_dropping: bool = False
  • توضیح : این پرچم بولین حذف شناسه را هنگامی که تعداد شناسه‌هایی که در داده‌های ورودی با آن مواجه می‌شوند (محدودیت‌های مشاهده‌شده) از محدودیت‌های تعیین‌شده در طول کامپایل فراتر می‌رود (مثلاً max_ids_per_partition ) کنترل می‌کند.
    • اگر True : شناسه‌هایی که باعث تجاوز از محدودیت‌ها می‌شوند بی‌صدا حذف می‌شوند. به طور معمول، شناسه‌های درون یک پارتیشن به ترتیب مرتب‌سازی شده پردازش می‌شوند و هر شناسه‌ای که تعداد در حال اجرا را از حد مجاز برای دسته کوچک تعیین‌شده‌اش بیشتر کند، کنار گذاشته می‌شود. این به برنامه اجازه می دهد تا اجرا را ادامه دهد اما ممکن است تأثیر نامطلوبی بر دقت مدل داشته باشد.
    • اگر False : خطایی راه اندازی می شود و اگر محدودیت های مشاهده شده فراتر از محدودیت های کامپایل شده بروند، روند احتمالاً خاتمه می یابد. این رویکرد تضمین می‌کند که تمام داده‌ها پردازش می‌شوند، اما نیاز به محدودیت‌هایی برای پیکربندی محافظه‌کارانه‌تر دارد.
  • پیش‌فرض : False (باعث ایجاد خطا در سرریز به جای ریزش اطلاعات بی‌صدا).

• initialize_tables_on_host: bool = True

  • توضیح : این پرچم تعیین می کند که آیا جداول جاسازی قبل از اینکه متعاقباً به حافظه باند پهنای باند بالا (HBM) TPU منتقل شوند، روی CPU میزبان مقداردهی اولیه شوند یا خیر. روش استاندارد این است که جداول روی هاست مقداردهی اولیه شوند. تنظیم این روی True از این قرارداد پیروی می کند. اگر روی False تنظیم می شد، به یک مکانیسم اولیه سازی روی دستگاه اشاره می کرد که می تواند پیامدهای عملکرد متفاوت یا پیش نیازهای اولیه سازی خاصی داشته باشد.

• enable_fast_table_initialization: bool = False

  • توضیح : جداول را مستقیماً روی TPU راه‌اندازی می‌کند. این می تواند به کاهش زمان راه اندازی مدل کمک کند.

5. لوله کشی برای عملکرد

Pipelining یک تکنیک بهینه‌سازی عملکرد است که امکان اجرای همزمان عملیات روی TensorCore (TC) و SparseCore (SC) را فراهم می‌کند. با همپوشانی این محاسبات، توان عملیاتی کلی را می توان به طور قابل توجهی بهبود بخشید.

• مکانیسم : در یک مرحله آموزشی استاندارد که شامل جستجوهای تعبیه شده پراکنده (که توسط SC انجام می شود) و محاسبات لایه متراکم (که توسط TC انجام می شود)، خط لوله به SC اجازه می دهد تا در قسمت خود از مرحله i (مثلاً عبور به جلو یا عقب) کار کند در حالی که TC به طور همزمان در حال پردازش بخش متفاوتی از همان مرحله i یا حتی i i-1 i+1 است.
• تاثیر بر شیب ها : SparseCore ممکن است بر روی گرادیان های "بیات" کار کند. برای مثال، گرادیان‌های محاسبه‌شده در مرحله پس انتشار مرحله i ممکن است تا مرحله i+2 به‌طور کامل به‌روزرسانی و برای SC قابل مشاهده نباشند.
• مبادله عملکرد در مقابل اعداد : این اجرای همپوشانی می تواند منجر به افزایش سرعت قابل توجهی شود که احتمالاً تا 2 برابر بهبود در زمان گام دستگاه را افزایش می دهد. با این حال، تغییرات ظریف در اعداد (embedding_weights) ناشی از استفاده از گرادیان های قدیمی ممکن است بر رفتار همگرایی مدل یا دقت نهایی به دست آمده تأثیر بگذارد. قابل قبول بودن این مبادله به شدت وابسته به مدل است و اغلب نیاز به اعتبار سنجی تجربی دارد.
• پرچم کنترل : لوله گذاری را می توان با tf_xla_disable_full_embedding_pipelining کنترل کرد. تنظیم این پرچم روی true ، خط لوله کامل (همپوشانی با محاسبات TensorCore و SparseCore) را غیرفعال می کند، در حالی که تنظیم آن بر روی false (یا اگر معنایی پرچم به معنای فعال کردن زمانی که false باشد) آن را فعال می کند.

جریان مفهومی خط لوله:

• بدون خط لوله (جریان متوالی ساده شده) :

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

• با خط لوله (جریان همپوشانی ساده شده) :

  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
  

  توجه : مراحل لوله‌گذاری واقعی که در سخت‌افزار و کامپایلر پیاده‌سازی می‌شوند، می‌توانند پیچیده‌تر باشند، که اغلب شامل حلقه‌های پیش، حلقه‌های اجرای اصلی، و حلقه‌های پس از آن برای مدیریت وابستگی‌های داده‌ها و اطمینان از صحت است.

6. نقش XLA

XLA (جبر خطی تسریع شده) کامپایلر مخصوص دامنه است که نمودارهای محاسباتی سطح بالا را معمولاً از چارچوب هایی مانند TensorFlow به کد ماشین بسیار بهینه شده متناسب با TPU ها ترجمه می کند. این شامل تولید دستورالعمل‌های عملیاتی است که برای SparseCore مقصد هستند.

توابع کلیدی در زمینه SparseCore:

• کامپایل عملیات پراکنده : XLA مسئول کامپایل کردن عملیات جستجوی جاسازی (مانند SparseDenseMatmulOp ) و سایر محاسبات پراکنده در برنامه های SparseCore سطح پایین و قابل اجرا است.
• یکپارچه‌سازی محدودیت‌ها : از محدودیت‌های عملیاتی پیکربندی‌شده (به عنوان مثال، max_ids_per_partition ، max_unique_ids_per_partition ، که اغلب از طریق یک فایل limits مشخص‌شده توسط پرچم‌هایی مانند xla_sparse_core_max_ids_file ارائه می‌شود) استفاده می‌کند تا به‌طور ایستا اندازه‌های حافظه S-PMde و همه چیز را تعیین کند.
• بهینه سازی های هدفمند : XLA مجموعه ای از بهینه سازی ها را انجام می دهد که به طور خاص برای معماری SparseCore طراحی شده اند. اینها می توانند شامل برنامه ریزی دستورالعمل، تغییر شکل حافظه و ادغام عملیات برای به حداکثر رساندن کارایی باشند.
• کنترل با استفاده از پرچم‌ها : بسیاری از جنبه‌های رفتار SparseCore، پارامترهای تنظیم، و استراتژی‌های بهینه‌سازی از طریق پرچم‌های XLA در معرض دید و کنترل قرار می‌گیرند (به عنوان مثال، xla_sparse_core_estimate_max_ids برای تخمین حد، یا xla_sc_detect_nan برای اشکال‌زدایی).

وضعیت منبع باز:

در حال حاضر Sparsecore Implementation داخلی است و با استفاده از libtpu.so ارائه می شود.

گزارش خطا و تشخیص:

خرابی های کامپایل مربوط به پیکربندی های SparseCore یا محدودیت های منابع اغلب به صورت خطاهای زمان کامپایل XLA:TPU ظاهر می شوند. این پیام‌های خطا می‌توانند بینش‌های ارزشمندی را در مورد مسائلی مانند تنظیم بیش از حد محدودیت‌ها برای SPMEM موجود یا استفاده از پیکربندی‌های پشتیبانی‌نشده ارائه دهند.

7. چگونه محدودیت ها به جداول در SparseCore ترجمه می شوند

در SparseCore، "Limits" پارامترهای پیکربندی اساسی هستند که در درجه اول به دو تنظیمات در هر پارتیشن برای هر جدولی که در SparseCores های موجود تقسیم شده (توزیع شده) اشاره دارد:

• max_ids_per_partition : این حداکثر تعداد کل شناسه‌ها (شامل موارد تکراری) را که انتظار می‌رود هر SparseCore منفرد برای یک پارتیشن خاص از یک جدول معین در یک مرحله محاسباتی ارسال یا پردازش کند را مشخص می‌کند.
• max_unique_ids_per_partition : حداکثر تعداد شناسه‌های منحصربه‌فردی را که انتظار می‌رود هر SparseCore منفرد به آن ارسال یا پردازش کند را مشخص می‌کند.

ترجمه به چیدمان و پردازش جدول فیزیکی:

• استراتژی تقسیم جدول : جداول جاسازی شده معمولاً در تمام هسته های Sparse در سیستم "mod-sharded" می شوند. این بدان معناست که هر SparseCore مسئول یک زیر مجموعه مجزا از واژگان (ردیف‌ها) هر جدول می‌شود. شناسه j به طور کلی بر اساس فرمولی مانند k = j % num_total_sparse_cores به SparseCore_k اختصاص داده می شود.
• تعریف "پارتیشن" : در این زمینه، "پارتیشن" به بخش خاصی از جدول تعبیه شده اشاره دارد که یک SparseCore منفرد جستجوها را انجام می دهد.
• تخصیص بافر SPMEM : این محدودیت ها توسط کامپایلر XLA برای اندازه استاتیک و تخصیص بافرها در حافظه اسکرچ پد روی دستگاه (SPMEM) استفاده می شود. ابعاد بافرها به گونه ای است که تمام داده های لازم مربوط به شناسه های یک پارتیشن معین (تا حد تعیین شده max_ids و max_unique_ids ) را می توان برای پردازش در SPMEM بارگذاری کرد. این به ویژه برای محاسبات غیر عنصری، مانند کاهش شناسه های تکراری در یک پارتیشن (به عنوان مثال، هنگام ایجاد یک نمایش ردیف پراکنده فشرده (CSR))، که در آن کل مجموعه داده مربوطه برای شناسه های آن پارتیشن باید به راحتی در حافظه سریع در دسترس باشد، بسیار مهم است.

• محدودیت های تدوین شده در مقابل محدودیت های مشاهده شده :

  • محدودیت های مشاهده شده : این تعداد واقعی شناسه هایی است که برای هر پارتیشن در طول زمان اجرا بر اساس داده های ورودی در حال پردازش مواجه می شوند.
  • اگر محدودیت‌های مشاهده‌شده از محدودیت‌های کامپایل شده بیشتر شود، می‌تواند منجر به حذف شناسه (در صورت فعال بودن allow_id_dropping ) یا خطا شود.

• محاسبه محدودیت ها : فرآیند تعیین حدود مناسب شامل تجزیه و تحلیل دقیق توزیع داده های ورودی است. برای هر جدول داده شده (بیایید آن را T1 بنامیم، که ممکن است خود بخشی از یک جدول انباشته بزرگتر T باشد):

  1. دسته ورودی (به عنوان مثال، یک SparseTensor دو بعدی به شکل [BatchSize, MaxSequenceLength] ) ابتدا در هسته های Sparse موجود تقسیم می شود. به عنوان مثال، اگر یک TensorCore با 2 هسته Sparse جفت شود، هر SparseCore ممکن است یک دسته فرعی از شکل [BatchSize/2, MaxSequenceLength] دریافت کند.
  2. این دسته فرعی سپس به فرمت COO تبدیل می شود و row_ids و col_ids به دست می دهد.
  3. شناسه‌های تکراری در یک نمونه (یعنی ورودی‌هایی با همان row_id و col_id ) حذف می‌شوند.
  4. برای هر col_id منحصر به فرد باقی مانده (در یک نمونه)، SparseCore هدف مسئول این شناسه با استفاده از قانون mod-sharding تعیین می شود: target_sc_id = col_id % num_total_sparse_cores .
  5. شمارش تعداد کل شناسه‌ها ( ids_per_sparse_core[target_sc_id]++ ) و تعداد شناسه‌های منحصربه‌فرد ( unique_ids_per_sparse_core[target_sc_id]++ ، پس از اطمینان از منحصربه‌فرد بودن برای آن target_sc_id خاص) که برای هر target_sc_id شده‌اند، حفظ می‌شود.
  6. سپس max_ids_per_partition برای جدول T1 روی max(ids_per_sparse_core_array) تنظیم می‌شود.
  7. به طور مشابه، max_unique_ids_per_partition برای جدول T1 روی max(unique_ids_per_sparse_core_array) تنظیم شده است.
  8. اگر جدول T1 جزء یک جدول انباشته است، تبدیل‌های اضافی مانند چرخش‌ها یا جابه‌جایی‌ها ممکن است در توزیع‌های ID قبل از جمع‌آوری آمار از همه جداول تشکیل‌دهنده اعمال شود. این به متعادل کردن بار روی تراشه ها کمک می کند.

تنظیم صحیح این محدودیت ها یک عمل متعادل کننده است: محدودیت های پایین تر به طور بالقوه می تواند منجر به عملکرد بالاتر شود (زیرا داده های کمتری باید در هر مرحله پردازش شود و فشار SPMEM کاهش می یابد)، اما اگر خیلی پایین تنظیم شود، می تواند منجر به مینی بچینگ بیش از حد یا افت ID نامطلوب شود.

8. هر SparseCore چگونه ارتباط برقرار می کند

ارتباطات SparseCore، به ویژه در زمینه پردازش فهرستی از شناسه‌ها برای جاسازی جستجوها، بر چندین مکانیسم هماهنگ متکی است:

• به اشتراک گذاری مود و مسیریابی ضمنی :
  • جداول جاسازی در تمام هسته های Sparse در سیستم به صورت mod-sharded هستند.
  • هنگامی که میزبان دسته ای از داده های ورودی را ارائه می دهد (که متعاقباً در قالب COO از قبل پردازش می شود، از جمله col_ids )، از مقدار col_id برای تعیین اینکه کدام SparseCore مسئول آن شناسه خاص است استفاده می شود: target_sc_id = col_id % num_total_sparse_cores .
  • هر SparseCore به طور موثر فقط زیرمجموعه شناسه هایی را دریافت و پردازش می کند که به پارتیشن های واژگان اختصاص داده شده خود نگاشت می شوند. مرحله پیش پردازش میزبان برای آماده سازی داده ها به گونه ای حیاتی است که هر SparseCore بتواند به راحتی شناسه های مربوطه خود را شناسایی کرده و بر روی آنها کار کند.
• توزیع داده ها بر اساس میزبان :
  • منطق پیش‌پردازش میزبان، دسته ورودی کلی را پارتیشن بندی می‌کند و بخش‌های مربوط به row_ids و col_ids (به همراه هر ویژگی یا وزن مرتبط در صورت وجود) یا در حافظه (HBM) که مستقیماً توسط هر SparseCore قابل دسترسی است یا در یک HBM مشترک که SparseCores داده‌های مورد نیاز خود را از آن دریافت می‌کند، توزیع می‌کند.
• پردازش درون SparseCore :
  • هنگامی که یک SparseCore مجموعه ای از شناسه های تعیین شده خود را برای یک پارتیشن جدول معین دریافت کرد، عملیاتی مانند کپی برداری از این شناسه ها و جمع آوری بردارهای تعبیه شده مربوطه را انجام می دهد. اینها عمدتاً محاسبات محلی هستند که در کاشی های خود SparseCore و با استفاده از SPMEM محلی آن اجرا می شوند.
• ارتباط بین SparseCore (همه به همه) :
  • پس از مرحله پردازش اولیه (مانند جستجوهای جاسازی)، یک الگوی ارتباطی "همه به همه" ممکن است برای ترکیب یا توزیع مجدد نتایج در SparseCores استفاده شود (به عنوان مثال، قبل از تغذیه فعال‌سازی‌ها در لایه TensorCore که انتظار ورودی مربوط به تمام موقعیت‌های نمونه اصلی را دارد). اگر دسته ورودی اصلی برای پردازش موازی توزیع شده باشد، این برای بازسازی مجموعه کامل فعال‌سازی‌ها حیاتی است.
• ارتباط با TensorCores :
  • SparseCores با TensorCores برای ارسال فعال‌سازی‌های تعبیه‌شده (در حین عبور به جلو) و برای دریافت گرادیان (در حین عبور به عقب) ارتباط برقرار می‌کنند. این تعامل توسط برنامه XLA کامپایل شده است و اغلب HBM را به عنوان یک بافر واسطه درگیر می کند. استراتژی خط لوله (که قبلاً مورد بحث قرار گرفت) به شدت بر زمان بندی و همگام سازی این ارتباط SC-TC تأثیر می گذارد.

در اصل، "توزیع" اولیه شناسه ها به SparseCores مناسب تا حد زیادی توسط طرح تقسیم و مراحل پیش پردازش میزبان انجام می شود. ارتباطات بعدی شامل SparseCores می‌شود که بر روی داده‌های محلی خود کار می‌کنند، به طور بالقوه عملیات‌های ارتباطی جمعی مانند all-to-all اگر داده‌ها باید در سراسر SparseCores مبادله یا مرتب شوند قبل از پردازش بیشتر توسط TensorCores.

9. مدیریت حافظه SparseCore

هر SparseCore به طور موثر چندین نوع حافظه متمایز را برای انجام محاسبات خود مدیریت می کند:

• حافظه Scratchpad (SPMEM) :
  • Nature : یک SRAM محلی نسبتا کوچک، اما بسیار سریع که منحصراً برای هر SparseCore در دسترس است. توجه به این نکته مهم است که SPMEM یک کش نیست. استفاده از آن به صراحت توسط کامپایلر XLA مدیریت و تنظیم می شود.
  • هدف : از SPMEM برای "ارسال بندی فرصت طلبانه داده ها" استفاده می شود. این شامل ورودی ها، خروجی ها و نتایج میانی است که برای محاسبات SC در حال انجام مورد نیاز است. مرحله بندی داده ها در SPMEM به طور قابل توجهی تأخیر بالا که معمولاً با دسترسی به HBM مرتبط است را کاهش می دهد.
  • اندازه : همانطور که در بخش "محدودیت ها" بحث شد، بافرهای SPMEM در زمان کامپایل به صورت ایستا اندازه می شوند. این اندازه بر اساس پارامترهایی مانند max_ids_per_partition و max_unique_ids_per_partition است. این تخصیص استاتیک تضمین می کند که برای هر عملیات معین روی یک پارتیشن جدول (مانند کاهش CSR)، تمام داده های لازم برای شناسه های آن پارتیشن (تا حد تعیین شده) می توانند در SPMEM قرار بگیرند.
  • بهینه‌سازی کامپایلر : کامپایلر XLA از بهینه‌سازی‌های پیچیده استفاده می‌کند تا دقیقاً تعیین کند چه مقدار داده و کدام عناصر داده خاص باید در SPMEM مرحله‌بندی شوند تا تأخیر HBM را به طور مؤثر پنهان کرده و کارایی را به حداکثر برسانند.
  • محدودیت تخصیص پویا : کامپایلر SparseCore در حال حاضر از تخصیص پویا scratchpad پشتیبانی نمی کند. این امر اهمیت حیاتی اندازه استاتیک را از طریق پیکربندی دقیق محدودیت ها برجسته می کند.
• حافظه با پهنای باند بالا (HBM) :
  • Nature : یک منبع حافظه مشترک بزرگ و قابل دسترسی برای همه SparseCores، TensorCores و سیستم میزبان. جداول تعبیه اولیه در HBM ذخیره می شوند.
  • استفاده از پشته : عملیات SparseCore اغلب به ذخیره سازی موقت در HBM برای نتایج میانی نیاز دارند که یا در SPMEM محدود نمی گنجند یا باید بین مراحل بزرگتر خط لوله پردازش منتقل شوند. استفاده از پشته HBM در طول پاس های رو به جلو و عقب را می توان به صورت زیر تخمین زد:
    • Forward Pass پشته HBM (تک جدول) ≈ (2 * feature_width + 1) * max_unique_nz_per_row * logical_replica_count * 4 byte
    • پشته HBM Pass Backward (تک جدول) ≈ 3 * feature_width * max_unique_nz_per_row * logical_replica_count * 4 byte
  • استفاده از Heap : HBM همچنین هیپ را که توسط میزبان مدیریت می شود، در خود جای می دهد. Heap داده هایی مانند وزن لایه متراکم، ثابت های استفاده شده توسط مدل و داده های ورودی از پیش واکشی شده را ذخیره می کند. استفاده از Heap با تعداد مراحلی که میزبان داده‌ها را از قبل واکشی می‌کند (که توسط پرچم maximum_parallel_iterations کنترل می‌شود) افزایش می‌یابد. در حالی که پیش واکشی بیشتر می‌تواند عملکرد را با تداخل انتقال‌های میزبان به دستگاه با محاسبات دستگاه بهبود بخشد، HBM بیشتری مصرف می‌کند.
  • سریال‌سازی برای بهینه‌سازی HBM : پرچم xla_sc_num_serialized_tables_to_optimize_hbm مکانیزمی را برای کنترل تعداد داده‌های جداول در حافظه پشته HBM به صورت زنده در هر زمان ارائه می‌کند. افزایش این عدد به طور موثر پردازش را برای جداول بیشتر سریال می کند، که می تواند اوج استفاده از پشته HBM را کاهش دهد، اما ممکن است به دلیل کاهش موازی بودن، به قیمت کارایی تمام شود.
• حافظه برداری (VMEM) :
  • VMEM یک حافظه اسکراچ‌پد محلی است که منحصراً توسط TC (TensorCore) استفاده می‌شود. در حالی که VMEM مستقیماً توسط SparseCore مدیریت نمی شود، بخش جدایی ناپذیری از اکوسیستم حافظه است که SC با آن تعامل دارد، در درجه اول از طریق TensorCore.

استراتژی کلی مدیریت حافظه:

استراتژی مدیریت حافظه اصلی برای SparseCore حول محور استفاده از SPMEM کوچک و سریع برای داده‌های "گرم" است که به طور فعال توسط یک کاشی SparseCore پردازش می‌شود، در نتیجه دسترسی به HBM کندتر را به حداقل می‌رساند. محدودیت های پیکربندی شده مکانیسم اصلی برای اطمینان از سرریز نشدن SPMEM هستند. HBM برای ذخیره جداول تعبیه‌شده بزرگ و داده‌های موقتی که یا از ظرفیت SPMEM فراتر می‌رود یا نیاز به اشتراک‌گذاری در واحدهای پردازش یا مراحل مختلف خط لوله دارند، استفاده می‌شود. کامپایلر XLA مسئول هماهنگی تمام حرکت داده ها و تخصیص بافر بر اساس این اصول معماری و محدودیت های پیکربندی شده توسط کاربر است.

10. تنگناهای عملکرد و حافظه

دستیابی به عملکرد بهینه با SparseCore نیاز به درک روشنی از تنگناهای بالقوه و نحوه رسیدگی به آنها دارد. اینها می توانند در میزبان، درون خود SparseCore یا در تعامل آن با TensorCores ایجاد شوند.

گلوگاه های رایج عملکرد:

• گلوگاه میزبان :
  • مشکل : ممکن است CPU میزبان نتواند داده‌ها را از قبل پردازش کند و آن‌ها را با سرعت کافی به TPU تغذیه کند، که منجر به استفاده ناکافی از SparseCores و TensorCores می‌شود. این یک محدودکننده عملکرد مکرر است.
  • کاهش : استفاده از CPU میزبان و معیارهای خط لوله ورودی را نظارت کنید. بارگذاری و پیش پردازش داده های سمت میزبان را بهینه کنید (به نکات تبدیل COO مراجعه کنید). برای تنظیم دقیق واکشی اولیه داده، پرچم maximum_parallel_iterations را تنظیم کنید.
• همگام سازی TC/SC کمتر از حد مطلوب (عدم خط لوله) :
  • مشکل : اگر خط لوله بین TensorCore و SparseCore غیرفعال باشد یا به طور موثر کار نکند، ممکن است یک واحد زمان قابل توجهی را در انتظار دیگری صرف کند و در نتیجه توان عملیاتی کلی سیستم را کاهش دهد.
  • کاهش : اطمینان حاصل کنید که خط لوله فعال است (به عنوان مثال، tf_xla_disable_full_embedding_pipelining = false یا معادل آن).
• تنگناهای ناشی از محدودیت :
  • مسئله :
    • محدودیت‌ها خیلی کم : می‌تواند باعث مینی بچینگ بیش از حد شود (تقسیم دسته‌های ورودی به تعداد زیادی زیرمجموعه کوچکتر برای رعایت محدودیت‌های محدود). در حالی که این صحت را حفظ می کند، هر دسته کوچک مقداری سربار پردازش را معرفی می کند که به طور بالقوه اجرای کلی را کند می کند. اگر allow_id_dropping درست باشد، محدودیت‌های بسیار کم نیز می‌تواند منجر به حذف ID شود که بر دقت مدل تأثیر می‌گذارد.
    • محدودیت‌های خیلی زیاد (اما همچنان مناسب) : در حالی که محدودیت‌های بسیار بالا ممکن است از مینی بچینگ جلوگیری کند، اگر ویژگی‌های داده واقعی به ندرت به این مقادیر اوج نزدیک شوند، می‌توانند فشار SPMEM را بی‌رویه افزایش دهند. آنها همچنین می توانند به استفاده از پشته HBM بزرگتر از آنچه به شدت مورد نیاز است منجر شوند.
    • خرابی های کامپایل : اگر محدودیت های پیکربندی شده به پشته SPMEM یا HBM بیشتری نسبت به حافظه فیزیکی موجود نیاز داشته باشند، کامپایل با شکست مواجه می شود.
  • کاهش : اطمینان حاصل کنید که محدودیت ها به درستی تنظیم شده اند.
• انحراف توزیع داده ها :
  • مسئله : اگر پارتیشن‌های SparseCore به طور مداوم تعداد نامتناسبی بیشتری از شناسه‌ها را در مقایسه با سایرین دریافت کنند (که نشان دهنده توزیع ضعیف ID است)، آن SparseCore‌های بارگذاری شده به گلوگاه عملکرد تبدیل می‌شوند.
  • کاهش : به هم زدن شناسه در طول فرآیند مینی بچینگ می تواند به کاهش این مشکل برای جداول انباشته شده، به ویژه آنهایی که میزهای کاربر «گرم» دارند، کمک کند. توزیع ID را به دقت تجزیه و تحلیل کنید تا محدودیت های مناسب و متعادل در هر جدول تنظیم کنید.
• مشکلات چیدمان میز :
  • مسئله :
    • تعداد بسیار کمی جدول انباشته شده : ممکن است برای پنهان کردن تأخیر ICI یا کاهش کافی هزینه های پردازش کافی نباشد.
    • تعداد زیادی جدول روی هم انباشته شده است : می تواند منجر به ایجاد جداول منطقی بسیار بزرگی شود که مدیریت آنها سخت می شود یا ممکن است از محدودیت های منابع موجود فراتر رود.
  • کاهش :
    • از تعداد بهینه میزها برای چیدمان اطمینان حاصل کنید. یک دستورالعمل کلی یک "نقطه شیرین" از 5 تا 100 میز را برای چیدمان پیشنهاد می کند.
• اعداد/کوانتیزه ناکارآمد :
  • مشکل : استفاده از دقت کامل FP32 زمانی که فرمت‌های با دقت پایین‌تر مانند BF16 یا اعداد صحیح کوانتیزه‌شده کافی هستند (و محاسبات سریع‌تری ارائه می‌دهند) می‌تواند یک گلوگاه عملکرد باشد.
  • کاهش : گزینه های با دقت کمتر را کاوش کنید. با این حال، توجه داشته باشید که کوانتیزاسیون به خودی خود مقداری سربار دارد و ممکن است به تنظیم دقیق پارامترهای کوانتیزاسیون برای حفظ دقت مدل نیاز داشته باشد.
• اشباع پهنای باند HBM :
  • مشکل : جابجایی بیش از حد داده به و از HBM، که به طور بالقوه ناشی از عرض ویژگی های بسیار کوچک (که منجر به سربار بالشتک بالا می شود)، الگوهای دسترسی ناکارآمد به حافظه، یا تعداد بسیار زیاد جستجوها، می تواند پهنای باند HBM موجود را اشباع کند.
  • کاهش : مقیاس بندی تعداد TPU ها می تواند به اشباع پهنای باند HBM کمک کند.

تنگناهای رایج حافظه:

• سرریز SPMEM (شکست در کامپایل) :
  • مشکل : اگر max_ids_per_partition و max_unique_ids_per_partition خیلی بالا تنظیم شده باشند، کامپایلر XLA ممکن است نتواند SPMEM کافی را اختصاص دهد و در نتیجه خطاهای کامپایل مانند: "Fixed size allocations (...) do not fit in TileSpmem (...)" علاوه بر این، اگر عبارت (sample_count * feature_width) / kNumTiles (که در آن kNumTiles تعداد کاشی‌ها در هر SC است) برای مرحله‌بندی جمع‌آوری عملوندها در کاشی SPMEM بسیار زیاد باشد، خطاهایی مانند "Gather operand too large..." ممکن است رخ دهد.
  • کاهش : اندازه دسته را کاهش دهید یا تعداد تراشه های مورد استفاده برای پردازش را افزایش دهید.
• سرریز پشته HBM (زمان اجرا یا کامپایل) :
  • مشکل : اگر ترکیب feature_width ، max_unique_nz_per_row ، و logical_replica_count منجر به نیازهای حافظه پشته HBM شود که بیش از HBM موجود باشد، این می تواند باعث خطاهای Out-Of-Memory (OOM) در زمان اجرا یا در طول کامپایل شود.
  • کاهش : پرچم xla_sc_num_serialized_tables_to_optimize_hbm را تنظیم کنید تا استفاده از پشته HBM را با سریال کردن پردازش جداول کاهش دهید (این معمولاً هزینه عملکرد دارد).
• HBM Heap Exhausting :
  • مشکل : عمدتاً ناشی از وزن‌های لایه متراکم بسیار زیاد، ثابت‌های متعدد ذخیره‌شده در حافظه، یا واکشی اولیه ورودی بیش از حد تهاجمی ( maximum_parallel_iterations بالا) است.
  • کاهش : استفاده از هیپ را با استفاده از ابزارهایی مانند XProf Memory Viewer نظارت کنید.
• سربار بالشتک :
  • مشکل : جداول جاسازی به گونه‌ای که 32B تراز شده باشند (معادل 8 شناور) در بعد ویژگی قرار گرفته‌اند. در نتیجه، پهنای ویژگی‌های کوچک (مثلاً 1 شناور) باعث بالارفتن بار قابل‌توجهی می‌شود (به عنوان مثال، 7/8 از فضای بافر اختصاص‌یافته، بالشتک است)، که منجر به هدر رفتن HBM می‌شود. بعد واژگان جداول نیز به صورت مضربی از تعداد هسته های Sparse در سیستم اضافه شده است. با این حال، این تأثیر معمولاً برای جداول با اندازه واژگان به اندازه کافی بالا ناچیز است.

عوامل کلی موثر بر عملکرد و حافظه:

• توپولوژی : تعداد تراشه های موجود و معماری اتصال آنها.
• اندازه دسته ای : به طور مستقیم بر sample_count در هر SparseCore تأثیر می گذارد، که به نوبه خود بر مصرف حافظه و بار محاسبه تأثیر می گذارد.
• قالب بندی داده ها : اطمینان از یک چیدمان کارآمد داده روی دستگاه برای عملکرد بهینه بسیار مهم است.

11. تجزیه و تحلیل پروفایل SparseCore

تجزیه و تحلیل یک نمایه عملکرد یک گام کلیدی در شناسایی تنگناها و کشف فرصت‌هایی برای بهینه‌سازی در بارهای کاری SparseCore است.

1. به دست آوردن ردیابی :
   • از ابزارهای پروفایل، مانند XProf ، برای ثبت یک رد اجرای دقیق در حالی که مدل شما در حال آموزش یا اجرای استنتاج است، استفاده کنید. این ردیابی یک جدول زمانی از عملیات انجام شده در میزبان، TensorCores و SparseCores ارائه می دهد.
2. Trace Viewer (مثلاً در XProf یا TensorBoard) را بررسی کنید :
   • فعالیت میزبان : فعالیت میزبان را بررسی کنید. آیا شکاف های قابل توجهی در فعالیت TPU وجود دارد؟ چنین شکاف‌هایی ممکن است نشان‌دهنده این باشد که میزبان یک گلوگاه است و نمی‌تواند داده‌ها را با سرعت کافی تغذیه کند. عملکرد خط لوله ورودی خود را تجزیه و تحلیل کنید.
   • فعالیت TensorCore (TC) و SparseCore (SC) :
     • به جدول زمانی اجرا برای TC و SC نگاه کنید. آیا آنها به صورت موازی عمل می کنند که نشان دهنده خط لوله موثر است؟ یا دوره های طولانی وجود دارد که یک واحد بیکار است و منتظر دیگری است؟
     • عملیاتی را که بیشترین زمان را صرف می کنند (طولانی ترین عملیات) در هر دو SC و TC شناسایی کنید.
     • خروجی‌های ردیابی بصری (اغلب بلوک‌های رنگی را نشان می‌دهند که عملیات‌های مختلف را در طول زمان نشان می‌دهند، مانند TPU:0 SparseCore 1 (pid 1005) ) برای شناسایی بصری عملیات غالب و دوره‌های بیکار بسیار ارزشمند هستند.
   • تجزیه و تحلیل زمان مرحله : زمان کلی مرحله را مشاهده کنید و درک کنید که چگونه بین پردازش میزبان، محاسبات SC و محاسبه TC توزیع یا تجزیه می شود.
3. تجزیه و تحلیل حافظه (XProf Memory Viewer) :
   • استفاده از Heap : از ابزارهایی مانند برگه "Memory Viewer" XProf برای بررسی استفاده از هیپ HBM استفاده کنید. این می تواند به تعیین اینکه آیا وزن مدل بزرگ ، ثابت ها یا پیش تنظیم ورودی بیش از حد پرخاشگرانه مقدار بیش از حد HBM را مصرف می کند ، کمک کند. فعال کردن پرچم هایی مانند --vmodule=best_fit_allocator=1 ممکن است سیاهههای مربوط به استفاده از اوج پشته را فراهم کند.
   • استفاده از پشته (غیرمستقیم) : در حالی که پروفایل مستقیم پشته HBM می تواند پیچیده باشد ، اگر با خطاهای خارج از حافظه روبرو شوید و استفاده از پشته معقول به نظر می رسد ، فرسودگی پشته HBM (اغلب به دلیل محدودیت های بیش از حد زیاد یا عرض های دارای ویژگی) یک مظنون قوی است. فرمول های ارائه شده برای استفاده از پشته HBM می تواند در تخمین این امر کمک کند.
4. به دنبال الگوهای خاص باشید :
   • MINI BATCHING : اگر اغلب از محدودیت ها فراتر رود ، ممکن است شواهدی از مینی دسته بندی در ردیابی مشاهده کنید (به عنوان مثال ، تعداد بیشتری از عملیات SC کوچکتر از حد انتظار برای اندازه دسته جهانی). این اغلب می تواند از سیاههها یا با مشاهده تعداد فراخوانی از عملیات خاص استنباط شود.
   • رها کردن شناسه : اگر افت شناسه فعال و در حال وقوع باشد ، سیاهههای مربوط به سیستم ممکن است نشانه هایی از این امر را ارائه دهند. این همچنین می تواند یک نشانه واضح باشد که محدودیت های پیکربندی شده برای داده های ورودی بسیار محدود کننده هستند.
   • زمان تدوین : زمان بازخوانی طولانی ، به ویژه اگر بهینه سازی بازخورد (FDO) فعال باشد و محدودیت های مرتباً تنظیم شود ، می تواند سربار قابل توجهی را به زمان کلی آموزش اضافه کند.
5. با پرچم ها و پیکربندی ارتباط برقرار کنید :
   • رفتار مشاهده شده را در نمایه به تنظیمات پراکنده خود (تنظیمات در پرونده های محدود ، پرچم های XLA) مرتبط کنید. به عنوان مثال ، اگر xla_sc_num_serialized_tables_to_optimize_hbm روی یک مقدار بالا تنظیم شده باشد ، ممکن است انتظار داشته باشید عملکرد SC کندتر اما مصرف پشته HBM پایین تر باشد.
6. روند تکراری :
   • پروفایل اغلب یک فرآیند پالایش مکرر است. یک تغییر خاص ایجاد کنید (یک حد مجاز را تنظیم کنید ، یک ویژگی را فعال یا غیرفعال کنید) ، یک پروفایل جدید را ضبط کنید و سپس آن را در برابر پروفایل قبلی مقایسه کنید تا تأثیر اصلاح خود را ببینید.

12. پرچم های اشکال زدایی عمومی

چندین پرچم را می توان برای کمک به اشکال زدایی موضوعات مربوط به اجرای پراکنده فعال کرد. توجه به این نکته حائز اهمیت است که فعال کردن این چک ها اغلب مجازات عملکرد را متحمل می شود و بنابراین ، آنها به طور معمول باید برای اجرای تولید غیرفعال شوند.

• چک های شناسه (خارج از محدوده) :
  • پرچم : xla_sparse_core_enable_id_bound_check = true
  • هدف : بررسی های مربوط به سیستم میزبان را قادر می سازد تا تشخیص دهد که آیا شناسه های تعبیه شده در داده های ورودی در خارج از محدوده واژگان معتبر تعریف شده برای یک جدول تعبیه شده مشخص قرار دارند. این به گرفتن مشکلات مربوط به داده های ورودی نادرست یا فاسد کمک می کند.
• NAN Checker :
  • پرچم : xla_sc_detect_nan = true
  • هدف : تشخیص مقادیر NAN (نه یک عدد) را در داده های نقطه شناور پردازش شده بر روی پراکنده امکان پذیر می کند. اگر یک NAN در ورودی ها یا خروجی های مختلف کامپایلر تشخیص داده شود ، این پرچم باعث ایجاد خطایی می شود. چنین خطاهایی به طور معمول اطلاعاتی در مورد محل برخورد NAN ارائه می دهد.
• Checker Bounds (دسترسی به حافظه) :
  • پرچم : xla_sc_assert_level=bounds
  • هدف : این پرچم یک ابزار ASAN (AdressSanitizer) را قادر می سازد که دستورالعمل های دسترسی به حافظه (مانند بارهای VMEM/فروشگاه ها و عملیات DMA) را بازنویسی کند. این چک ها تأیید می کنند که آیا دسترسی حافظه در محدوده اختصاص یافته منطقه حافظه هدف است یا خیر.
  • رفتار : اگر دسترسی به حافظه خارج از مرز تشخیص داده شود ، اعدام با شکست روبرو می شود.
  • احتیاط : به عنوان مثال ، به دلیل الگوهای دسترسی پیچیده و پیچیده که توسط چکر کاملاً درک نشده است ، می تواند این چکر مثبت تولید کند. این تحول در یک مرحله اواخر در فرآیند تدوین پس زمینه اعمال می شود.
• بافر چک (فساد حافظه) :
  • پرچم ها :
    • 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
  • هدف : این پرچم ها به اطمینان حاصل می کنند که بافرهای حافظه ناخواسته توسط عملیات نامربوط خراب یا رونویسی نمی شوند. ضد عفونی کننده بافر محتوای بافر را بررسی می کند تا تأیید کند که آنها به طور غیر منتظره تغییر نمی کنند.

13. پشتیبانی کمیت

Sparsecore's SparseDenseMatmulOp برای پشتیبانی از عملیات در جداول تعبیه شده با استفاده از هر دو نقطه شناور 32 بیتی (FP32) و انواع داده عدد صحیح طراحی شده است. در حالی که آموزش مدل به طور معمول با استفاده از دقت FP32 برای جداول تعبیه انجام می شود ، می توان کمیت پس از آموزش (PTQ) استفاده کرد. PTQ امکان استفاده از داده های با دقت پایین (مانند عدد صحیح 8 بیتی) را برای استنتاج فراهم می کند ، که به طور بالقوه می تواند منجر به بهبود عملکرد و کاهش حافظه شود.

کمیت شبیه سازی شده:

SparseDenseMatmulOp می توان برای انجام "کمیت شبیه سازی شده" پیکربندی کرد. در این حالت عملیاتی ، بردارهای تعبیه شده ابتدا با دقت کمتری تعیین می شوند و سپس قبل از استفاده در محاسبات بعدی ، به دقت بالاتر (برای مثال FP32) می پردازند. این روش اجازه می دهد تا در حین حساب کردن اثرات سر و صدای کمیت ، مدل ها آموزش ببینند. آموزش با کمیت شبیه سازی شده می تواند دقت مدل نهایی را هنگامی که کاملاً برای استنباط کمیت می شود ، بهبود بخشد.

ویژگی های پیکربندی برای SparseDenseMatmulOp (برای کمیت):

• quantization_config_num_buckets = 256
  • این ویژگی تعداد سطل های گسسته یا سطحی را که در آن تعداد 32 بیتی شناور نقطه تعیین می شود ، مشخص می کند. به عنوان مثال ، هنگام کمیت به عدد صحیح 8 بیتی ، معمولاً 2^8 = 256 سطل را مشخص می کند.
• quantization_config_low = -XX
  • این ویژگی حداقل مقدار نقطه شناور را در محدوده کمیت تعریف می کند. هر مقادیر ورودی زیر این حداقل مشخص شده در طول کمیت به این حداقل مقدار بریده می شود.
• quantization_config_high = YY
  • این ویژگی حداکثر مقدار نقطه شناور را در محدوده کمیت مشخص می کند. هر مقادیر ورودی بالاتر از این حداکثر مشخص شده در طول کمیت به این حداکثر مقدار بریده می شود.

تعداد و تعامل لوله کشی:

رفتار عددی مدل بسته به اینکه آیا لوله کشی بین Tensorcore و پراکنده فعال است ، می تواند تغییر کند. اگر لوله کشی فعال باشد ، شیب های پردازش شده توسط پراکنده ممکن است "بی رنگ" باشند (از تکرار قبلی). این می تواند با فرایند کمیت تعامل داشته باشد و به طور بالقوه بر پویایی آموزش مدل یا دقت نهایی تأثیر بگذارد.

14. ویژگی های آینده و پیشرفت های اخیر

اکوسیستم پراکنده منوط به توسعه و پیشرفت مداوم است.

نقشه راه:

• نمونه مینی باکتری نمونه :
  • این به عنوان یک ویژگی مکمل برای قابلیت های مینی باچال واژگان موجود برنامه ریزی شده است.
  • این امکان را برای پارتیشن بندی بیشتر ورودی های تعبیه شده در بعد نمونه فراهم می کند. این امر با معرفی حلقه های روی دستگاه که می توانند به طور همزمان از زیر مجموعه ای از نمونه ها را فیلتر و پردازش کنند ، حاصل می شود. چنین ویژگی می تواند برای مدیریت تعداد شناسه های بسیار بزرگ در هر نمونه یا برای بهبود تعادل بار در واحدهای پردازش مفید باشد.
• پشتیبانی بهبود یافته برای تعبیه با کمتر از 8 عدد صحیح در هر سطر (عرض ویژگی های کوچک) :
  • طراحی فعلی اغلب از بالشتک قابل توجهی برای تعبیه عرض ویژگی استفاده می کند که کمتر از 8 شناور هستند (که مربوط به 32 بایت است). این بالشتک می تواند منجر به هدر رفتن HBM و منابع محاسباتی بالقوه مورد استفاده شود. پیشرفت های آینده با هدف کاهش این ناکارآمدی برای جداول با ابعاد ویژگی کوچک انجام می شود.

پیشرفت های اخیر:

• مرحله بندی عملیات جمع آوری در HBM :
  • این بهینه سازی به کاهش فشار بر روی حافظه Scratchpad مشترک (SPMEM) کمک می کند تا برخی از ورودی ها یا خروجی های جمع آوری جمع آوری در HBM بزرگتر انجام شود.
• کاهش در استفاده از حافظه پشته :
  • پیشرفت هایی برای کاهش مصرف حافظه پشته HBM در طی عملیات پراکنده انجام شده است ، در حالت ایده آل بدون تأثیر منفی بر عملکرد کلی یا توان.

این پیشرفت ها بر بهبود عملکرد ، بهره وری حافظه و انعطاف پذیری عملیاتی برای طیف وسیع تری از بار کاری پراکنده متمرکز شده است.