-sdy-close-shardings
Schließt Tensor-Shards und entfernt replizierte Achsen.
-sdy-constant-or-scalar-merger
Identische Konstanten und skalare Erweiterungen mit übereinstimmenden Shardings zusammenführen:
Führt eine einfache CSE für Konstanten mit identischen Shardings durch.
In der Importpipeline werden die Konstanten und skalaren Erweiterungen aufgeteilt und dupliziert, sodass Sharding nicht zwischen verschiedenen Verwendungen einer konstanten Unterberechnung weitergegeben wird. Wenn die Konstanten nach der Weitergabe dieselben Shardings haben, werden sie in diesem Durchlauf zusammengeführt, um die Kompilierungszeit zu verkürzen. Weitere Informationen finden Sie unter -sdy-constant-or-scalar-splitter.
-sdy-convert-global-to-local
Konvertiert ein SDY-Programm von globalen in lokale Formen.
Konvertiert ein SDY-Programm von globalen in lokale Formen, indem logische Dimensionen basierend auf Sharding-Attributen partitioniert werden.
Bei diesem Durchlauf wird ein Typkonverter verwendet, um RankedTensorType von globalen logischen Formen zu gerätespezifischen physischen Formen zuzuordnen.
-sdy-drop-sharding-rules
Drops OpShardingRuleAttr aus allen registrierten Vorgängen.
-sdy-insert-explicit-reshards
Fügt explizite Reshards ein, damit alle Vorgänge kompatible Shardings haben.
Eine kompatible Fragmentierung bedeutet im Wesentlichen, dass für den Vorgang die sharded Operanden akzeptiert und ein sharded Ergebnis erzeugt werden kann, ohne dass eine Reshard-Kommunikation erforderlich ist. Der Vorgang kann jedoch weiterhin Kommunikation wie All-Reduce oder Halo-Swaps erfordern.
Nach der Weitergabe können einige Vorgänge immer noch inkompatible Shardings haben.
Beachten Sie, dass, wenn eine Achse (oder Unterachse) verwendet wird, um nicht übereinstimmende Dimensionen (z.B. nicht kontrahierende Dimensionen in matmul) über mehrere Tensoren hinweg zu fragmentieren, oder wenn eine Achse eine Dimension in einem Tensor, aber nicht die entsprechende Dimension im anderen Tensor fragmentiert, von einem Sharding-Konflikt gesprochen wird. Nach diesem Durchlauf sind die Vorgänge daher konfliktfrei.
In diesem Durchlauf werden Reshard-Vorgänge explizit eingefügt, sodass für jeden Vorgang entsprechende Dimensionen auf allen Operanden und Ergebnissen auf dieselbe Weise aufgeteilt werden und jede Achse (oder Unterachse) nur zum Aufteilen eines einzelnen Dimensionstyps verwendet werden kann.
Beispiel:
Eingabe:
mesh = <"x"=4, "y"=2>
%lhs : tensor<8x32xf32> {sdy.sharding=<@mesh, \[{"x"}, {"y"}\]>}
%rhs : tensor<32x16xf32> {sdy.sharding=<@mesh, \[{"y"}, {"x"}\]>}
stablehlo.dot %lhs, %rhs {sdy.sharding_per_value=<[<@mesh, \[{"x"}, {}\]>]>}
: (tensor<8x32xf32>, tensor<32x16xf32>) -> tensor<8x16xf32>
Ausgabe:
sdy.mesh = <"x"=4, "y"=2>
%lhs : tensor<8x32xf32> {sdy.sharding=<@mesh, \[{"x"}, {"y"}\]>}
%rhs : tensor<32x16xf32> {sdy.sharding=<@mesh, \[{"y"}, {"x"}\]>}
%0 = sdy.reshard %rhs <@mesh, \[{"y"}, {}\]> : tensor<32x16xf32>
stablehlo.dot %lhs, %0 {sdy.sharding_per_value=<[<@mesh, \[{"x"}, {}\]>]>}
: (tensor<8x32xf32>, tensor<32x16xf32>) -> tensor<8x16xf32>
Im obigen Beispiel werden lhs und rhs beide auf der Achse „x“ auf ihren nicht kontrahierenden Dimensionen aufgeteilt, was nicht kompatibel ist. Der Pass fügt vor dem Punktvorgang eine explizite Resharding-Operation für rhs ein, damit der Punktvorgang kompatible Shardings hat.
Optionen
-enable-full-version : Enable full version.
-avoid-reshards-on-named-computations : Avoid explicit reshards/collectives on named computations.
-sdy-remove-all-gather-reduce-scatter-for-cmv1
_Entfernt sdy.all_gather und sdy.reducescatter für CMV1.
Entfernt „all-gather“ im Muster „all-gather + dot“. Entfernt „reduce-scatter“ im Muster „Punkt + reduce-scatter“. Dieser Durchgang dient der Kompatibilität mit Collective Matmul V1 (CMV1). Dies ist eine vorübergehende Lösung für b/432019089.
-sdy-remove-propagation-debug-info
Entfernt beim Export Debugging-Informationen zur Weitergabe (Weitergabe-Kanten und Ursprungs-Shards).
-sdy-remove-sharding-groups
Entfernt ShardingGroupOps nach der Weitergabe.
-sdy-remove-sub-axes-in-input-output-shardings
Entfernt untergeordnete Achsen in Eingabe-/Ausgabe-Shards.
Einige Nutzer von Shardy erwarten, dass die Ein- und Ausgaben von Funktionen Shardings ohne untergeordnete Achsen haben. Mit diesem Durchlauf werden untergeordnete Achsen und ihre nachfolgenden Achsen aus den Ein-/Ausgabe-Shards entfernt. Dieser Durchlauf erfolgt in der Regel nach sdy-update-non-divisible-input-output-shardings, um sicherzustellen, dass durch das Entfernen von untergeordneten Achsen keine nicht teilbaren Shardings entstehen.
-sdy-reshard-to-collectives
Konvertiert ReshardOp in verschiedene Shardy-Collective-Operationen.
Gleicht Reshard-Vorgänge ab und schreibt sie in verschiedene Shardy-Collective-Vorgänge um. Danach sind keine Reshard-Vorgänge mehr im Modul vorhanden.
Optional: Wenn keepRedundantReshards „true“ ist, sind die einzigen verbleibenden Resharding-Vorgänge die redundanten. Standardmäßig wird davon ausgegangen, dass explizite Reshards bereits eingefügt wurden (sdy-insert-explicit-reshards). Redundante Reshards werden nicht beibehalten. Es sollten redundante Reshards beibehalten werden, wenn explizite Reshards noch nicht eingefügt wurden.
Beispiel:
Eingabe:
mesh = <"x"=2, "y"=2, "z"=2>
%0 : tensor<16x2xf32> {sdy.sharding<@mesh, \[{"x", "y", "z"}, {}\]>
%1 = sdy.reshard %arg0 <@mesh, \[{"x"}, {}\]> : tensor<16x2xf32>
Ausgabe:
mesh = <"x"=2, "y"=2, "z"=2>
%0 : tensor<16x2xf32> {sdy.sharding<@mesh, \[{"x", "y", "z"}, {}\]>
%1 = sdy.all_gather \[{"y", "z"}, {}\] %arg0 out_sharding=<@mesh, \[{"x"}, {}\]> : tensor<16x2xf32>
Im obigen Beispiel wird der Tensor %0 : tensor<16x2xf32> als \[{"x", "y", "z"}, {}\] aufgeteilt. Anschließend wird es mit reshard als \[{"x"}, {}\] neu aufgeteilt. Da das Suffix {"y", "z"} nach dem Resharding von den ersten Achsen entfernt wird, schließen wir daraus, dass wir alle {"y", "z"}-Daten erfasst haben. Die zweite Dimension wird nicht geändert.
Optionen
-keep-redundant-reshards : Whether it keeps redundant reshards or removes.
-sdy-sharding-constraint-to-reshard
Konvertiert ShardingConstraintOp in ReshardOp.
-sdy-sink-data-flow-edges
Führt alle DataFlowEdgeOp in die Eingabe ein.
Verschiebt das Sharding jedes DataFlowEdgeOp in seine Eingabe (das Stammziel des Rands) und ersetzt den Vorgang durch seine Eingabe.
Optionen
-sink-debug-sharding-origins : Whether to sink the debug sharding origins info. See `debug-sharding-origins` option in propagation for more info.
-sink-debug-propagation-edge-sharding : Whether to sink the debug propagation edge sharding info. See `debug-propagation-edge-sharding` option in propagation for more info.
-sdy-update-non-divisible-input-output-shardings
Die Ein- und Ausgaben von FuncOp werden gleichmäßig aufgeteilt, sodass keine Auffüllung aufgrund von nicht teilbaren Shardings erforderlich ist.
Nutzer von Shardy erwarten, dass die Funktions-Ein-/Ausgaben gleichmäßig teilbar/shardbar sind, damit ihre Tensoren nicht aufgefüllt werden müssen. Durch die Weitergabe können Ein-/Ausgaben nicht teilbare Shardings haben. Daher werden sie in diesem Durchgang auf das größte Dimensions-Sharding-Präfix des ursprünglichen Shardings aktualisiert, das gleichmäßig aufgeteilt ist.