شاردینگ دیالکتی-اگنوستیک,شارینگ-آگنوستیک-گویش-گویش-آگنوستیک شاردینگ

هدف بلند مدت این است که Shardy را به یک جزء کاملاً مستقل تبدیل کنیم که بتواند با هر گویش MLIR کار کند. در حال حاضر، Shardy به طور مستقیم به StableHLO وابسته است، اما ما در حال پیشرفت به سمت بالا بردن آن از طریق انتزاعات و رابط های مختلف هستیم تا Shardy را انعطاف پذیرتر کنیم.

قوانین شاردینگ

یک قانون اشتراک گذاری نحوه انتشار ما از طریق یک عملیات را رمزگذاری می کند. از آنجایی که Shardy اکنون به StableHLO وابسته است، قوانین اشتراک گذاری را برای هر عملیات stablehlo تعریف می کند. علاوه بر این، Shardy یک ShardingRuleOpInterface ارائه می دهد که می تواند توسط صاحبان گویش در عملیات خود برای تعریف قوانین اشتراک گذاری برای عملیات خود استفاده شود. تا زمانی که یک عملیات این رابط را پیاده سازی کند، Shardy می تواند از طریق آن انتشار یابد.

def ShardingRuleOpInterface : OpInterface<"ShardingRuleOpInterface"> {
  let methods = [
    InterfaceMethod<
      /*desc=*/[{
        Returns the sharding rule of the op.
      }],
      /*retType=*/"mlir::sdy::OpShardingRuleAttr",
      /*methodName=*/"getShardingRule"
    >,
  ];
}

عملیات جریان داده

برخی از عملیات‌ها، به‌عنوان مثال، عملیات‌های مبتنی بر منطقه، به رویکرد متفاوتی نیاز دارند که در آن قوانین تقسیم‌بندی، که فقط مطابقت بین ابعاد در همه عملوندها و نتایج را توصیف می‌کنند، کافی نیستند. در این موارد، Shardy یک ShardableDataFlowOpInterface را تعریف می‌کند تا صاحبان گویش بتوانند از طریق عملیات خود، انتشار به اشتراک گذاری را توصیف کنند. این رابط روش هایی را برای دریافت منابع و اهداف هر لبه جریان داده از طریق صاحب آنها، و همچنین دریافت و تنظیم تقسیم بندی صاحبان لبه ارائه می دهد.

def ShardableDataFlowOpInterface :
    OpInterface<"ShardableDataFlowOpInterface"> {
  (get|set)BlockArgumentEdgeOwnerShardings;
  (get|set)OpResultEdgeOwnerShardings;
  getBlockArgumentEdgeOwners;
  getOpResultEdgeOwners;
  getEdgeSources;
  // ...
}

همچنین برای یک نمای کلی در سطح بالا از نحوه مدیریت عملیات جریان داده، به عملیات جریان داده مراجعه کنید.

اینترفیس ها هنوز پیاده سازی نشده اند

در آینده، رابط‌ها و ویژگی‌های بیشتری اضافه خواهند شد تا شاردی انعطاف‌پذیرتر و گویش‌گراتر شود. ما آنها را در زیر فهرست می کنیم.

تقسیم مداوم

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

به عنوان مثال در شکل زیر، اگر add تقسیم شده باشد، نباید بر نحوه divide و subtract (در قسمت‌های مختلف محاسبات) تأثیر بگذارد.

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

برای رسیدن به این هدف، کاربران Shardy باید تعریف کنند: - یک your_dialect.constant -> sdy.constant pass; - یک ویژگی sdy::ConstantLike ، مانند iota ; - یک mlir::Elementwise برای عملیات عنصری مانند add و multiply . - یک sdy::ConstantFoldable برای عملیاتی مانند برش / پخش . اگر همه عملوندها/نتایج آنها ثابت باشند، این عملیات ها از نظر فنی می توانند در زمان کامپایل محاسبه شوند.

اولویت های عملیاتی

در GSPMD ابتدا عملیات های عنصری منتشر می شوند و سپس عملیات هایی مانند matmul منتشر می شوند. در Shardy، می‌خواهیم به کاربران اجازه دهیم اولویت‌های عملیاتی خود را تعیین کنند، زیرا ما از پیشینی لهجه‌های آنها را نمی‌دانیم. به این ترتیب، ما از آنها می خواهیم که لیستی از عملیات ها را به ترتیبی که می خواهند Shardy آنها را منتشر کند، ارسال کنند.

شکل زیر نشان می دهد که چگونه از اولویت ها در GSPMD برای انتشار عملیات به ترتیب درست استفاده می شود.

مقاله GSPMD را برای بحث در مورد اینکه چرا اولویت‌های عملیات مهم هستند، ببینید.

گویش گرا بودن

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

هدف بلند مدت این است که Shardy را به یک جزء کاملاً مستقل تبدیل کنیم که بتواند با هر گویش MLIR کار کند. در حال حاضر، Shardy به طور مستقیم به StableHLO وابسته است، اما ما در حال پیشرفت به سمت بالا بردن آن از طریق انتزاعات و رابط های مختلف هستیم تا Shardy را انعطاف پذیرتر کنیم.

قوانین شاردینگ

یک قانون اشتراک گذاری نحوه انتشار ما از طریق یک عملیات را رمزگذاری می کند. از آنجایی که Shardy اکنون به StableHLO وابسته است، قوانین اشتراک گذاری را برای هر عملیات stablehlo تعریف می کند. علاوه بر این، Shardy یک ShardingRuleOpInterface ارائه می دهد که می تواند توسط صاحبان گویش در عملیات خود برای تعریف قوانین اشتراک گذاری برای عملیات خود استفاده شود. تا زمانی که یک عملیات این رابط را پیاده سازی کند، Shardy می تواند از طریق آن انتشار یابد.

def ShardingRuleOpInterface : OpInterface<"ShardingRuleOpInterface"> {
  let methods = [
    InterfaceMethod<
      /*desc=*/[{
        Returns the sharding rule of the op.
      }],
      /*retType=*/"mlir::sdy::OpShardingRuleAttr",
      /*methodName=*/"getShardingRule"
    >,
  ];
}

عملیات جریان داده

برخی از عملیات‌ها، به‌عنوان مثال، عملیات‌های مبتنی بر منطقه، به رویکرد متفاوتی نیاز دارند که در آن قوانین تقسیم‌بندی، که فقط مطابقت بین ابعاد در همه عملوندها و نتایج را توصیف می‌کنند، کافی نیستند. در این موارد، Shardy یک ShardableDataFlowOpInterface را تعریف می‌کند تا صاحبان گویش بتوانند از طریق عملیات خود، انتشار به اشتراک گذاری را توصیف کنند. این رابط روش هایی را برای دریافت منابع و اهداف هر لبه جریان داده از طریق صاحب آنها، و همچنین دریافت و تنظیم تقسیم بندی صاحبان لبه ارائه می دهد.

def ShardableDataFlowOpInterface :
    OpInterface<"ShardableDataFlowOpInterface"> {
  (get|set)BlockArgumentEdgeOwnerShardings;
  (get|set)OpResultEdgeOwnerShardings;
  getBlockArgumentEdgeOwners;
  getOpResultEdgeOwners;
  getEdgeSources;
  // ...
}

همچنین برای یک نمای کلی در سطح بالا از نحوه مدیریت عملیات جریان داده، به عملیات جریان داده مراجعه کنید.

اینترفیس ها هنوز پیاده سازی نشده اند

در آینده، رابط‌ها و ویژگی‌های بیشتری اضافه خواهند شد تا شاردی انعطاف‌پذیرتر و گویش‌گراتر شود. ما آنها را در زیر فهرست می کنیم.

تقسیم مداوم

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

به عنوان مثال در شکل زیر، اگر add تقسیم شده باشد، نباید بر نحوه divide و subtract (در قسمت‌های مختلف محاسبات) تأثیر بگذارد.

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

برای رسیدن به این هدف، کاربران Shardy باید تعریف کنند: - یک your_dialect.constant -> sdy.constant pass; - یک ویژگی sdy::ConstantLike ، مانند iota ; - یک mlir::Elementwise برای عملیات عنصری مانند add و multiply . - یک sdy::ConstantFoldable برای عملیاتی مانند برش / پخش . اگر همه عملوندها/نتایج آنها ثابت باشند، این عملیات ها از نظر فنی می توانند در زمان کامپایل محاسبه شوند.

اولویت های عملیاتی

در GSPMD ابتدا عملیات های عنصری منتشر می شوند و سپس عملیات هایی مانند matmul منتشر می شوند. در Shardy، می‌خواهیم به کاربران اجازه دهیم اولویت‌های عملیاتی خود را تعیین کنند، زیرا ما از پیشینی لهجه‌های آنها را نمی‌دانیم. به این ترتیب، ما از آنها می خواهیم که لیستی از عملیات ها را به ترتیبی که می خواهند Shardy آنها را منتشر کند، ارسال کنند.

شکل زیر نشان می دهد که چگونه از اولویت ها در GSPMD برای انتشار عملیات به ترتیب درست استفاده می شود.

مقاله GSPMD را برای بحث در مورد اینکه چرا اولویت‌های عملیات مهم هستند، ببینید.

گویش گرا بودن

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

هدف بلند مدت این است که Shardy را به یک جزء کاملاً مستقل تبدیل کنیم که بتواند با هر گویش MLIR کار کند. در حال حاضر، Shardy به طور مستقیم به StableHLO وابسته است، اما ما در حال پیشرفت به سمت بالا بردن آن از طریق انتزاعات و رابط های مختلف هستیم تا Shardy را انعطاف پذیرتر کنیم.

قوانین شاردینگ

یک قانون اشتراک گذاری نحوه انتشار ما از طریق یک عملیات را رمزگذاری می کند. از آنجایی که Shardy اکنون به StableHLO وابسته است، قوانین اشتراک گذاری را برای هر عملیات stablehlo تعریف می کند. علاوه بر این، Shardy یک ShardingRuleOpInterface ارائه می دهد که می تواند توسط صاحبان گویش در عملیات خود برای تعریف قوانین اشتراک گذاری برای عملیات خود استفاده شود. تا زمانی که یک عملیات این رابط را پیاده سازی کند، Shardy می تواند از طریق آن انتشار یابد.

def ShardingRuleOpInterface : OpInterface<"ShardingRuleOpInterface"> {
  let methods = [
    InterfaceMethod<
      /*desc=*/[{
        Returns the sharding rule of the op.
      }],
      /*retType=*/"mlir::sdy::OpShardingRuleAttr",
      /*methodName=*/"getShardingRule"
    >,
  ];
}

عملیات جریان داده

برخی از عملیات‌ها، به‌عنوان مثال، عملیات‌های مبتنی بر منطقه، به رویکرد متفاوتی نیاز دارند که در آن قوانین تقسیم‌بندی، که فقط مطابقت بین ابعاد در همه عملوندها و نتایج را توصیف می‌کنند، کافی نیستند. در این موارد، Shardy یک ShardableDataFlowOpInterface را تعریف می‌کند تا صاحبان گویش بتوانند از طریق عملیات خود، انتشار به اشتراک گذاری را توصیف کنند. این رابط روش هایی را برای دریافت منابع و اهداف هر لبه جریان داده از طریق صاحب آنها، و همچنین دریافت و تنظیم تقسیم بندی صاحبان لبه ارائه می دهد.

def ShardableDataFlowOpInterface :
    OpInterface<"ShardableDataFlowOpInterface"> {
  (get|set)BlockArgumentEdgeOwnerShardings;
  (get|set)OpResultEdgeOwnerShardings;
  getBlockArgumentEdgeOwners;
  getOpResultEdgeOwners;
  getEdgeSources;
  // ...
}

همچنین برای یک نمای کلی در سطح بالا از نحوه مدیریت عملیات جریان داده، به عملیات جریان داده مراجعه کنید.

اینترفیس ها هنوز پیاده سازی نشده اند

در آینده، رابط‌ها و ویژگی‌های بیشتری اضافه خواهند شد تا شاردی انعطاف‌پذیرتر و گویش‌گراتر شود. ما آنها را در زیر فهرست می کنیم.

تقسیم مداوم

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

به عنوان مثال در شکل زیر، اگر add تقسیم شده باشد، نباید بر نحوه divide و subtract (در قسمت‌های مختلف محاسبات) تأثیر بگذارد.

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

برای رسیدن به این هدف، کاربران Shardy باید تعریف کنند: - یک your_dialect.constant -> sdy.constant pass; - یک ویژگی sdy::ConstantLike ، مانند iota ; - یک mlir::Elementwise برای عملیات عنصری مانند add و multiply . - یک sdy::ConstantFoldable برای عملیاتی مانند برش / پخش . اگر همه عملوندها/نتایج آنها ثابت باشند، این عملیات ها از نظر فنی می توانند در زمان کامپایل محاسبه شوند.

اولویت های عملیاتی

در GSPMD ابتدا عملیات های عنصری منتشر می شوند و سپس عملیات هایی مانند matmul منتشر می شوند. در Shardy، می‌خواهیم به کاربران اجازه دهیم اولویت‌های عملیاتی خود را تعیین کنند، زیرا ما از پیشینی لهجه‌های آنها را نمی‌دانیم. به این ترتیب، ما از آنها می خواهیم که لیستی از عملیات ها را به ترتیبی که می خواهند Shardy آنها را منتشر کند، ارسال کنند.

شکل زیر نشان می دهد که چگونه از اولویت ها در GSPMD برای انتشار عملیات به ترتیب درست استفاده می شود.

مقاله GSPMD را برای بحث در مورد اینکه چرا اولویت‌های عملیات مهم هستند، ببینید.

گویش گرا بودن

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