Trainingsarbeitslasten produktivisieren

Important

Dieses Feature befindet sich in der Public Preview.

Verwenden Sie DABs, um einen AI-Runtime-Trainings-Workload als Code zu definieren. Behalten Sie es in der Versionskontrolle, deployen Sie es in verschiedenen Umgebungen, planen Sie es und setzen Sie es mit anderen Aufgaben zusammen. Diese Seite beschreibt den Pfad für eigenes Training (Bring your own Training), bei dem eine ai_runtime_task Ihren eigenen Befehl für ein Codeverzeichnis mit serverlosen GPU-Computeressourcen ausführt.

Tip

  • Verwenden Sie Declarative Automation Bundles, um Trainings-Workloads als Code zu definieren, sie umgebungsübergreifend bereitzustellen und zu planen.
  • ai_runtime_task führt Ihren eigenen Befehl für ein Codeverzeichnis aus (bring-your-own-training).
  • Kombinieren Sie GPU- und CPU-Aufgaben in Multitask-Jobs.

Das ist eine andere Aufgabe als ein Notebook auf serverloser GPU über ein Bundle zu betreiben. Für das grundlegende Beispiel eines Notebook-on-GPU-Bundles siehe Schedule with the Jobs API und Declarative Automation Bundles.

Anforderungen

  • Ein Arbeitsbereich mit aktivierter AI Runtime. Siehe Anforderungen.
  • Die Databricks CLI (Kommandozeilenschnittstelle) wurde installiert und konfiguriert, um Bundles bereitzustellen.

Definiere eine KI-Laufzeitaufgabe in einem Bundle

Ein ai_runtime_task benennt ein Experiment, verweist mit code_source_path auf Ihren Trainingscode und deklariert ein Deployment: den auszuführenden Befehl und die GPU, auf der er ausgeführt wird. Füge es einem Auftrag in deinem Bündel hinzu:

resources:
  jobs:
    train:
      tasks:
        - task_key: train
          ai_runtime_task:
            experiment: my-experiment
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1

code_source_path zeigt auf deinen verpackten Trainingscode und command_path ist das Skript, das die Aufgabe ausführt. Wiederholungen, Zeitüberschreitungen und Berechtigungen werden für die Aufgabe und den Job genauso festgelegt wie für jeden Azure Databricks-Job, sodass Sie Ihre bestehenden Bundle-Verfahren weiterverwenden können. Wie Sie Ihren Code verpacken und referenzieren, siehe Ship your training code.

ai_runtime_task Felder

Feld Typ Description
experiment Schnur Required. Der Name des MLflow-Experiments für den Durchlauf. Siehe Experiment-Tracking und Beobachtbarkeit.
code_source_path Schnur Der Trainingscode, der ausgeführt werden soll: die Ausgabedatei eines verpackten tgz-Artefakts oder ein /Workspace- oder /Volumes-Pfad zu bereits hochgeladenem Code. Siehe Trainingscode bereitstellen.
deployments Sequenz Required. Eine einzelne Bereitstellung, die den Befehl und die Rechenressourcen definiert, auf denen er ausgeführt wird. Jeder Eintrag enthält command_path, compute, und ein optionales name.
deployments[].command_path Schnur Required. Das Skript der Aufgabe läuft auf jedem Knoten.
deployments[].compute.accelerator_type Schnur Required. Der GPU-Typ, zum Beispiel GPU_1xA10, GPU_1xH100, oder GPU_8xH100.
deployments[].compute.accelerator_count Integer Required. Die Gesamtzahl der GPUs über alle Knoten – ein Vielfaches der pro Knoten angegebenen Anzahl, die in accelerator_type kodiert ist.
deployments[].name Schnur Ein optionaler Name für die Bereitstellung, verwendet in Logs und der Benutzeroberfläche.
docker_image_url Schnur Ein optionales benutzerdefiniertes Docker-Image zum Ausführen des Befehls statt der verwalteten Umgebung. Siehe Verwenden von benutzerdefinierten Docker-Images.
mlflow_run Schnur Ein optionaler Anzeigename für den MLflow-Lauf.
mlflow_experiment_directory Schnur Ein optionales Workspace-Verzeichnis, unter dem das Experiment erstellt wird. Muss mit /Workspace beginnen. Stellen Sie dies ein, wenn Sie als Service Principal ohne Standard-Benutzerverzeichnis laufen.
mlflow_artifact_location Schnur Eine optionale Wurzelposition für MLflow-Artefakte, zum Beispiel einen /Volumes/<catalog>/<schema>/<volume>/… Pfad. Muss mit dem Artefaktspeicherort eines bestehenden Experiments übereinstimmen oder muss weggelassen werden.

Lege Wiederholungen, Time-outs, Berechtigungen und die Umgebung (environment_key) für die Aufgabe und den Job fest – nicht in ai_runtime_task. Für die vollständige Aufgabereferenz siehe AI Runtime Task.

Konfigurieren Sie den Hardware-Beschleuniger

Setzen Sie accelerator_type auf die GPU, die Ihre Arbeitslast benötigt, und accelerator_count auf die Gesamtzahl der GPUs. Die Anzahl ist ein Vielfaches der Anzahl der GPUs pro Knoten: 1 für GPU_1xA10 und GPU_1xH100, und 8 für GPU_8xH100. Eine Anzahl, die die Größe pro Knoten überschreitet, führt die Aufgabe auf mehreren Knoten aus – zum Beispiel wird GPU_8xH100 mit accelerator_count: 16 auf zwei Knoten ausgeführt. Für Hinweise zur Wahl eines Beschleunigers siehe Hardware-Optionen.

Note

Für Multi-Knoten-Runs führt AI Runtime Ihren Befehl auf jedem Knoten aus und füllt die Standardvariablen der verteilten Trainingsumgebung in der Aufgabenumgebung aus—NUM_NODES, WORLD_SIZE, LOCAL_WORLD_SIZE, MASTER_ADDR, und MASTER_PORT. Lesen Sie sie aus Ihrem Befehl (zum Beispiel einen torchrun-Start); Sie legen sie nicht im Bundle fest.

Richte die Umgebung und Abhängigkeiten ein.

Definiere einen Block environments im Job und verweise in der Aufgabe mit environment_key darauf. AI Runtime installiert die aufgeführten Abhängigkeiten, bevor dein Befehl ausgeführt wird:

resources:
  jobs:
    train:
      tasks:
        - task_key: train
          environment_key: default
          ai_runtime_task:
            # experiment, code_source_path, and deployments as above
      environments:
        - environment_key: default
          spec:
            environment_version: '6'
            dependencies:
              - numpy

Für die verfügbaren Umgebungen siehe Einrichten Ihrer Umgebung.

Schick deinen Trainingscode

code_source_path teilt der Aufgabe mit, wo sich Ihr Trainingscode befindet. Sie nimmt eine von zwei Formen an:

  • Ein verpacktes tgz Artefakt — definieren Sie ein Artefakt und verweisen Sie mit code_source_path auf dessen Ausgabedatei. Azure Databricks baut den Tarball und lädt ihn auf databricks bundle deploy. So sendet man Code aus einem lokalen Projektverzeichnis oder einer festgelegten Git-Revision.
  • Ein Arbeitsbereich oder Volumenpfad – Code, der bereits hochgeladen und as-isverwendet wird.

Verpacktes Artefakt

Deklariere ein tgz Artefakt und zeige code_source_path auf seine Ausgabedatei. Auf databricks bundle deploy erstellt die CLI das Tar-Archiv, lädt es hoch, und die Aufgabe extrahiert es und führt Ihren Befehl damit aus:

artifacts:
  code:
    type: tgz
    path: .
    include: [src]
    files:
      - source: ./dist/code.tgz
resources:
  jobs:
    train:
      tasks:
        - task_key: train
          ai_runtime_task:
            code_source_path: ./dist/code.tgz

Verwende include, um Dateien aus deinem Arbeitsbaum zu verpacken, oder git, um eine Momentaufnahme eines festgeschriebenen Branches oder Commits zu erstellen.

Arbeitsbereich oder Volumenpfad

Um bereits hochgeladenen Code zu verwenden, legen Sie code_source_path auf einen Pfad vom Typ /Workspace/… oder /Volumes/… fest. Azure Databricks verwendet den Pfad as-is und paketiert nichts.

Die Felder des tgz Artefakts:

Feld Description
type tgz erstellt aus Quelldateien ein gzip-komprimiertes Tar-Archiv, anstatt einen build-Befehl auszuführen.
path Das Basisverzeichnis, das gepackt werden soll. include Pfade und die Namen der Archiveinträge sind relativ dazu.
include Eine Liste von Unterpfaden zum path Paket. Verzichte darauf, das gesamte Paket pathzu verpacken. Honors .gitignore; das Bundle-weite sync.include und sync.exclude gilt nicht. Alternative zu einem build Befehl.
git Erstellen Sie eine Momentaufnahme einer committeten Git-Referenz anstelle der Arbeitsstruktur. Satz git.branch oder git.commit (commit gewinnt, wenn beide gesetzt sind). Alternative zu einem build Befehl.
files[].source Der Pfad des erstellten Tarballs. Zeigen Sie code_source_path auf das hier.

Note

AI Runtime extrahiert deinen Code in ein Verzeichnis und stellt ihn als Umgebungsvariable CODE_SOURCE_PATH bereit. Referenziere es aus deinem Befehl, damit relative Pfade aufgelöst werden, zum Beispiel cd "$CODE_SOURCE_PATH" bevor du dein Skript ausführst.

Vollständiges Beispiel

Dieses Beispiel trainiert auf einer einzelnen A10-GPU aus einem lokalen Projekt, ohne vorherige CLI-Einrichtung außer der Installation und Konfiguration der Azure Databricks CLI. Das Projekt besteht aus drei Dateien:

my-training/
├── databricks.yml
├── command.sh
└── src/
    └── train.py

command.sh ist der Einstiegspunkt, benannt durch command_path. Es wechselt in das extrahierte Codeverzeichnis und führt das Trainingsskript aus:

#!/usr/bin/env bash
set -euo pipefail
cd "$CODE_SOURCE_PATH"
python train.py

databricks.yml benennt das Bundle, packt src/ als tgz-Artefakt, führt es als ein ai_runtime_task aus, installiert numpy in der Task-Umgebung und definiert Entwicklungs- und Produktionsziele:

bundle:
  name: my-training

artifacts:
  code:
    type: tgz
    path: .
    include: [src]
    files:
      - source: ./dist/code.tgz

resources:
  jobs:
    train:
      name: my-training
      tasks:
        - task_key: train
          environment_key: default
          ai_runtime_task:
            experiment: /Users/me@example.com/my-training
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1
      environments:
        - environment_key: default
          spec:
            environment_version: '6'
            dependencies:
              - numpy

targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production

Deploye das Bundle und führe den Job aus. databricks bundle deploy baut und lädt das tgz Artefakt hoch und erstellt den Auftrag; databricks bundle run startet ihn:

databricks bundle deploy --target dev
databricks bundle run train --target dev

Aufbau von Multitask-Workflows

Eine ai_runtime_task ist eine Aufgabe eines Azure Databricks-Auftrags und lässt sich mit dem Rest eines Auftrags kombinieren. Du kannst vor dem Training einen Vorbereitungsschritt durchführen, GPU- und CPU-Aufgaben in einem Job kombinieren und pro Aufgabe verschiedene Beschleuniger verwenden.

Ordne Aufgaben mit depends_on

Nutze es, depends_on um Aufgaben nacheinander auszuführen. Die folgende Pipeline führt ein Vorbereitungsnotizbuch aus, dann eine GPU-Trainingsaufgabe, die erst nach erfolgreicher Vorbereitungsaufgabe beginnt:

resources:
  jobs:
    train_pipeline:
      tasks:
        - task_key: prep
          notebook_task:
            notebook_path: ./prep.py
        - task_key: train
          depends_on:
            - task_key: prep
          ai_runtime_task:
            experiment: my-experiment
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1

GPU- und CPU-Aufgaben kombinieren

In der oben genannten Pipeline benötigt nur der Trainingsschritt eine GPU. Wenn Arbeiten wie die Datenvorbereitung, die nicht auf der GPU ausgeführt werden, in separate Aufgaben ausgelagert werden, bleibt die GPU-Zeit auf das Training konzentriert.

Note

Eine ai_runtime_task unterstützt keine Werte für Azure Databricks-Auftragsaufgaben ({{tasks.<task_key>.values.<name>}} oder dbutils.jobs.taskValues). Um Daten zwischen den Schritten zu übertragen, schreiben Sie sie an einen gemeinsamen Speicherort, den beide Tasks lesen können, wie zum Beispiel ein Unity-Catalog-Volume oder eine Arbeitsbereichsdatei, und referenzieren Sie diesen Pfad jeder Aufgabe.

Planen Sie die Arbeitsbelastung

Fügen Sie dem Auftrag ein schedule hinzu, um ihn in einem bestimmten Intervall auszuführen. Stellen Sie den Zeitplan im pausierten Zustand bereit, damit durch die Bereitstellung des Bundles nicht automatisch Ausführungen gestartet werden, und aktivieren Sie ihn dann wieder, wenn Sie bereit sind:

resources:
  jobs:
    train_pipeline:
      schedule:
        quartz_cron_expression: '0 0 9 * * ?'
        timezone_id: UTC
        pause_status: PAUSED

Von der Entwicklung in die Produktion überführen

Die Höherstufung von der Entwicklung zur Produktion ist eine Standardpaketfunktion, die die KI-Laufzeitaufgabe unverändert übernimmt.

Bündelziele und -modi

Definieren Sie neben Ihrem Entwicklungsziel auch ein Produktionsziel mit mode: production. Das Ziel steuert, wo das Bundle eingesetzt wird und wie seine Ressourcen benannt werden:

targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production

Implementieren und Ausführen

Deploye und führe das Bundle mit den Standard-Bundle-Befehlen gegen ein Ziel aus:

databricks bundle deploy --target dev
databricks bundle run train_pipeline --target dev

Nächste Schritte

  • Last updated on