Verwendung von modularem Code mit dem @remote Decorator - Amazon SageMaker AI

Verwendung von modularem Code mit dem @remote Decorator

Sie können Ihren Code in Modulen organisieren, um die Workspace-Verwaltung während der Entwicklung zu vereinfachen, und trotzdem die @remote-Funktion verwenden, um eine Funktion aufzurufen. Sie können die lokalen Module auch aus Ihrer Entwicklungsumgebung in die Remote-Auftragsumgebung replizieren. Setzen Sie dafür den Parameter include_local_workdir auf True, wie im folgenden Beispielcode gezeigt.

@remote( include_local_workdir=True, )
Anmerkung

Der @remote Decorator und der Parameter müssen in der Hauptdatei und nicht in einer der abhängigen Dateien vorkommen.

Wenn include_local_workdir auf True gesetzt ist, packt SageMaker AI alle Python-Skripte und behält dabei die Verzeichnisstruktur im aktuellen Verzeichnis des Prozesses bei. Außerdem werden die Abhängigkeiten im Arbeitsverzeichnis des Jobs verfügbar gemacht.

Nehmen wir beispielsweise an, Ihr Python-Skript, das den MNIST-Datensatz verarbeitet, ist in ein main.py-Skript und ein abhängiges pytorch_mnist.py-Skript unterteilt. main.py ruft das abhängige Skript auf. Das main.py-Skript enthält außerdem Code zum Importieren der Abhängigkeit, wie dargestellt.

from mnist_impl.pytorch_mnist import ...

Die main.py-Datei muss außerdem den @remote-Decorator enthalten und muss den include_local_workdir-Parameter auf True setzen.

Der include_local_workdir-Parameter umfasst standardmäßig alle Python-Skripte im Verzeichnis. Sie können anpassen, welche Dateien in den Job hochgeladen werden sollen, indem Sie diesen Parameter in Verbindung mit dem custom_file_filter-Parameter verwenden. Sie können entweder eine Funktion übergeben, die Auftragsabhängigkeiten filtert, die auf S3 hochgeladen werden sollen, oder ein CustomFileFilter-Objekt, das die lokalen Verzeichnisse und Dateien angibt, die in der Remote-Funktion ignoriert werden sollen. Sie können custom_file_filter nur dann verwenden, wenn include_local_workdir auf True gesetzt ist. Andernfalls wird der Parameter ignoriert.

Im folgenden Beispiel wird CustomFileFilter verwendet, um beim Hochladen von Dateien auf S3 alle Notebook-Dateien und Ordner oder Dateien mit dem Namen data zu ignorieren.

@remote( include_local_workdir=True, custom_file_filter=CustomFileFilter( ignore_pattern_names=[ # files or directories to ignore "*.ipynb", # all notebook files "data", # folter or file named data ] ) )

Das folgende Beispiel zeigt, wie Sie einen gesamten Workspace verpacken können.

@remote( include_local_workdir=True, custom_file_filter=CustomFileFilter( ignore_pattern_names=[] # package whole workspace ) )

Das folgende Beispiel zeigt, wie Sie eine Funktion zum Filtern von Dateien verwenden können.

import os def my_filter(path: str, files: List[str]) -> List[str]: to_ignore = [] for file in files: if file.endswith(".txt") or file.endswith(".ipynb"): to_ignore.append(file) return to_ignore @remote( include_local_workdir=True, custom_file_filter=my_filter )

Bewährte Methoden zur Strukturierung Ihres Arbeitsverzeichnisses

Die folgenden Best Practices zeigen, wie Sie Ihre Verzeichnisstruktur organisieren und gleichzeitig den @remote-Decorator in Ihrem modularen Code verwenden können.

  • Legen Sie den @remote Decorator in einer Datei ab, die sich im Stammverzeichnis des Workspace befindet.

  • Lokale Module auf der Stammebene strukturieren.

Das folgende Beispielbild zeigt die empfohlene Verzeichnisstruktur. In dieser Beispielstruktur befindet sich das main.py Skript im Stammverzeichnis.

. ├── config.yaml ├── data/ ├── main.py <----------------- @remote used here ├── mnist_impl │ ├── __pycache__/ │ │ └── pytorch_mnist.cpython-310.pyc │ ├── pytorch_mnist.py <-------- dependency of main.py ├── requirements.txt

Das folgende Beispielbild zeigt eine Verzeichnisstruktur, die zu inkonsistentem Verhalten führt, wenn sie dazu verwendet wird, Ihren Code mit einem @remote Decorator zu kommentieren.

In dieser Beispielstruktur befindet sich das main.py Skript, das den @remote Decorator enthält, nicht im Stammverzeichnis. Die folgende Struktur wird NICHT empfohlen.

. ├── config.yaml ├── entrypoint │ ├── data │ └── main.py <----------------- @remote used here ├── mnist_impl │ ├── __pycache__ │ │ └── pytorch_mnist.cpython-310.pyc │ └── pytorch_mnist.py <-------- dependency of main.py ├── requirements.txt