Долгосрочная цель — сделать Shardy полностью автономным компонентом, способным работать с любым диалектом MLIR. В настоящее время Shardy напрямую зависит от StableHLO, но мы добиваемся прогресса в устранении этой зависимости с помощью различных абстракций и интерфейсов, чтобы сделать Shardy более гибким.
Правила шардинга
Правило сегментирования кодирует способ распространения операции. Поскольку Shardy теперь зависит от 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;
// ...
}
См. также раздел «Операции потока данных» , чтобы получить общий обзор того, как мы обрабатываем операции потока данных.
Интерфейсы еще не реализованы
В будущем будет добавлено больше интерфейсов и функций, чтобы сделать Shardy более гибким и независимым от диалектов. Мы перечислим их ниже.
Постоянное расщепление
Большинство тензорных программ в MLIR имеют один экземпляр константы, который повторно используется любой операцией, которой требуется это значение. Это имеет смысл, когда необходимая константа одинакова. Однако для оптимального сегментирования программы мы хотели бы разрешить каждому использованию константы иметь собственное сегментирование и не зависеть от того, как другие операции используют эту константу.
Например, на рисунке ниже, если add сегментировано, это не должно влиять на то, как сегментируются операции divide и subtract (в разных частях вычислений).
Мы называем это ложной зависимостью : поскольку константы дешевы, между операциями, использующими одну и ту же константу, нет реальной зависимости. Таким образом, пользователи могут принять решение о сегментировании своих постоянных (и подобных константам) операций. Каждое использование этой константы может затем иметь различное сегментирование, которое может распространяться изолированно на свою собственную копию подвычисления константы.
Для этого пользователям Shardy необходимо определить: — проход your_dialect.constant -> sdy.constant ; - Черта sdy::ConstantLike , например iota ; — Черта mlir::Elementwise для поэлементных операций, таких как add и multiply ; — sdy::ConstantFoldable для таких операций, как срез / трансляция . Эти операции технически могут быть рассчитаны во время компиляции, если все их операнды/результаты являются константами.
Операционные приоритеты
В GSPMD сначала распространяются поэлементные операции, а затем такие операции, как matmul . В Shardy мы хотим позволить пользователям устанавливать свои собственные приоритеты операций, поскольку мы априори не знаем об их диалектах. Таким образом, мы попросим их передать список операций в том порядке, в котором они хотят, чтобы Шарди их распространял.
На рисунке ниже показано, как приоритеты используются в GSPMD для распространения операций в правильном порядке.
См. документ GSPMD , где обсуждается, почему важны операционные приоритеты.
Будучи диалекто-агностиком
Пока вы реализуете предыдущие интерфейсы, черты и проходы, Шарди сможет работать на вашем диалекте. Мы работаем над тем, чтобы сделать Shardy более гибким и независимым от диалектов, поэтому следите за обновлениями.
,Долгосрочная цель — сделать Shardy полностью автономным компонентом, способным работать с любым диалектом MLIR. В настоящее время Shardy напрямую зависит от StableHLO, но мы добиваемся прогресса в устранении этой зависимости с помощью различных абстракций и интерфейсов, чтобы сделать Shardy более гибким.
Правила шардинга
Правило сегментирования кодирует способ распространения операции. Поскольку Shardy теперь зависит от 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;
// ...
}
См. также раздел «Операции потока данных» , чтобы получить общий обзор того, как мы обрабатываем операции потока данных.
Интерфейсы еще не реализованы
В будущем будет добавлено больше интерфейсов и функций, чтобы сделать Shardy более гибким и независимым от диалектов. Мы перечислим их ниже.
Постоянное расщепление
Большинство тензорных программ в MLIR имеют один экземпляр константы, который повторно используется любой операцией, которой требуется это значение. Это имеет смысл, когда необходимая константа одинакова. Однако для оптимального сегментирования программы мы хотели бы разрешить каждому использованию константы иметь собственное сегментирование и не зависеть от того, как другие операции используют эту константу.
Например, на рисунке ниже, если add сегментировано, это не должно влиять на то, как сегментируются операции divide и subtract (в разных частях вычислений).
Мы называем это ложной зависимостью : поскольку константы дешевы, между операциями, использующими одну и ту же константу, нет реальной зависимости. Таким образом, пользователи могут принять решение о сегментировании своих постоянных (и подобных константам) операций. Каждое использование этой константы может затем иметь различное сегментирование, которое может распространяться изолированно на свою собственную копию подвычисления константы.
Для этого пользователям Shardy необходимо определить: — проход your_dialect.constant -> sdy.constant ; - Черта sdy::ConstantLike , например iota ; — Черта mlir::Elementwise для поэлементных операций, таких как add и multiply ; — sdy::ConstantFoldable для таких операций, как срез / трансляция . Эти операции технически могут быть рассчитаны во время компиляции, если все их операнды/результаты являются константами.
Операционные приоритеты
В GSPMD сначала распространяются поэлементные операции, а затем такие операции, как matmul . В Shardy мы хотим позволить пользователям устанавливать свои собственные приоритеты операций, поскольку мы априори не знаем об их диалектах. Таким образом, мы попросим их передать список операций в том порядке, в котором они хотят, чтобы Шарди их распространял.
На рисунке ниже показано, как приоритеты используются в GSPMD для распространения операций в правильном порядке.
См. документ GSPMD , где обсуждается, почему важны операционные приоритеты.
Будучи диалекто-агностиком
Пока вы реализуете предыдущие интерфейсы, черты и проходы, Шарди сможет работать на вашем диалекте. Мы работаем над тем, чтобы сделать Shardy более гибким и независимым от диалектов, поэтому следите за обновлениями.
,Долгосрочная цель — сделать Shardy полностью автономным компонентом, способным работать с любым диалектом MLIR. В настоящее время Shardy напрямую зависит от StableHLO, но мы добиваемся прогресса в устранении этой зависимости с помощью различных абстракций и интерфейсов, чтобы сделать Shardy более гибким.
Правила шардинга
Правило сегментирования кодирует способ распространения операции. Поскольку Shardy теперь зависит от 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;
// ...
}
См. также раздел «Операции потока данных» , чтобы получить общий обзор того, как мы обрабатываем операции потока данных.
Интерфейсы еще не реализованы
В будущем будет добавлено больше интерфейсов и функций, чтобы сделать Shardy более гибким и независимым от диалектов. Мы перечислим их ниже.
Постоянное расщепление
Большинство тензорных программ в MLIR имеют один экземпляр константы, который повторно используется любой операцией, которой требуется это значение. Это имеет смысл, когда необходимая константа одинакова. Однако для оптимального сегментирования программы мы хотели бы разрешить каждому использованию константы иметь собственное сегментирование и не зависеть от того, как другие операции используют эту константу.
Например, на рисунке ниже, если add сегментировано, это не должно влиять на то, как сегментируются операции divide и subtract (в разных частях вычислений).
Мы называем это ложной зависимостью : поскольку константы дешевы, между операциями, использующими одну и ту же константу, нет реальной зависимости. Таким образом, пользователи могут принять решение о сегментировании своих постоянных (и подобных константам) операций. Каждое использование этой константы может затем иметь различное сегментирование, которое может распространяться изолированно на свою собственную копию подвычисления константы.
Для этого пользователям Shardy необходимо определить: — проход your_dialect.constant -> sdy.constant ; - Черта sdy::ConstantLike , например iota ; — Черта mlir::Elementwise для поэлементных операций, таких как add и multiply ; — sdy::ConstantFoldable для таких операций, как срез / трансляция . Эти операции технически могут быть рассчитаны во время компиляции, если все их операнды/результаты являются константами.
Операционные приоритеты
В GSPMD сначала распространяются поэлементные операции, а затем такие операции, как matmul . В Shardy мы хотим позволить пользователям устанавливать свои собственные приоритеты операций, поскольку мы априори не знаем об их диалектах. Таким образом, мы попросим их передать список операций в том порядке, в котором они хотят, чтобы Шарди их распространял.
На рисунке ниже показано, как приоритеты используются в GSPMD для распространения операций в правильном порядке.
См. документ GSPMD , где обсуждается, почему важны операционные приоритеты.
Будучи диалекто-агностиком
Пока вы реализуете предыдущие интерфейсы, черты и проходы, Шарди сможет работать на вашем диалекте. Мы работаем над тем, чтобы сделать Shardy более гибким и независимым от диалектов, поэтому следите за обновлениями.