OpenXLA Project

Diese Seite wurde von der Cloud Translation API übersetzt.

`-sdy-close-shardings`

Schließt Tensor-Shardings und verwirft replizierte Achsen.

`-sdy-constant-merger`

Identische Konstanten mit übereinstimmenden Shardings zusammenführen

Führt eine einfache clientseitige Verschlüsselung auf Konstanten mit identischen Shardings durch.

Die Importpipeline teilt und dupliziert die Konstanten so, dass das Sharding nicht zwischen verschiedenen Verwendungen einer konstanten Teilberechnung weitergegeben wird. Wenn die Konstanten nach der Weiterleitung dieselbe Sharding haben, werden sie mit diesem Pass zusammengeführt, um die Kompilierungszeit zu verkürzen.

`-sdy-drop-sharding-rules`

Löst OpShardingRuleAttr bei allen registrierten Geschäftsaktivitäten aus.

`-sdy-insert-explicit-reshards`

Fügt explizite Reshards ein, damit alle Vorgänge kompatible Shardings haben.

Eine kompatible Sharding-Technologie bedeutet im Wesentlichen, dass der Vorgang die geShardeten Operanden akzeptieren und ein geShardetes Ergebnis ohne Reshard-Kommunikation liefern kann. Beachten Sie, dass der Vorgang möglicherweise noch Kommunikation wie All-Reduce oder Halo-Swaps erfordert.

Nach der Replikation haben einige Vorgänge möglicherweise weiterhin inkompatible Shardings.

Wenn eine Achse (oder eine untergeordnete Achse) verwendet wird, um nicht übereinstimmende Dimensionen (z.B. nicht schrumpfende Dimensionen in matmul) über mehrere Tensoren zu teilen, oder wenn eine Achse eine Dimension in einem Tensor, aber nicht die entsprechende Dimension im anderen Tensor teilt, liegt ein Sharding-Konflikt vor. Nach diesem Pass werden die Vorgänge also konfliktfrei.

Mit diesem Pass werden Resharding-Vorgänge explizit eingefügt, sodass für jeden Vorgang entsprechende Dimensionen für alle Operanden und Ergebnisse auf dieselbe Weise gesplittet werden. Außerdem kann jede Achse (oder untergeordnete Achse) nur zum Sharding eines einzelnen Dimensionstyps verwendet werden.

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 entlang der Achse „x“ nach ihren nicht schrumpfenden Dimensionen geSharded. Das ist nicht zulässig. Der Pass fügt vor dem Punktvorgang eine explizite Reshardierung auf rhs ein, damit der Punktvorgang kompatible Shardings hat.

`-sdy-remove-sharding-groups`

Entfernt ShardingGroupOps nach der Replikation.

`-sdy-reshard-to-collectives`

Konvertiert ReshardOp in verschiedene Shardy-Kollektiv-Vorgänge.

Übereinstimmung von Reshard-Vorgängen und Umschreiben in verschiedene Shardy-Kollektivvorgänge. Danach sind im Modul keine Reshard-Vorgänge mehr vorhanden. Bei diesem Ausweis wird davon ausgegangen, dass bereits explizite Reshards eingefügt wurden (sdy-insert-explicit-reshards).

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"}, {}\] geSharded. Dann gibt es eine reshard-Operation, die das Volume neu als \[{"x"}, {}\] partitioniert. Da das Suffix {"y", "z"} auf den ersten Achsen nach der Reshardierung entfernt wird, schließen wir daraus, dass wir {"y", "z"} mit All-Gather erhalten haben. Die zweite Dimension bleibt unverändert.

`-sdy-sharding-constraint-to-reshard`

Konvertiert ShardingConstraintOp in ReshardOp.

`-sdy-sink-data-flow-edges`

Leitet alle DataFlowEdgeOp in die Eingabe weiter.

Verschiebt das Sharding jeder DataFlowEdgeOp an ihre Eingabe (das Stammziel des Edge) und ersetzt die Operation durch ihre 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-temp-explicit-reshards-for-optimizations`

Fügt explizite Reshards für bestimmte Optimierungen ein.

Diese Karte/dieser Ticket ist eine vorübergehende Lösung, bis wir die Karte/das Ticket sdy-insert-explicit-reshards standardmäßig aktivieren können.

So können wir für bestimmte Vorgänge explizite Reshards einfügen, um sie zu optimieren.

`-sdy-update-non-divisible-input-output-shardings`

Die Eingaben/Ausgaben von FuncOp werden gleichmäßig auf Shards verteilt, sodass kein Padding aufgrund nicht teilbarer Shards erforderlich ist.

Nutzer von Shardy erwarten, dass die Funktionseingaben/-ausgaben gleichmäßig teilbar/shardbar sind, damit keine Tensoren aufgefüllt werden müssen. Durch die Replikation können Eingaben/Ausgaben nicht teilbare Shardings haben. Daher werden sie in diesem Pass auf das größte Dimensions-Sharding-Präfix des ursprünglichen Shardings aktualisiert, das gleichmäßig geSharded ist.