Wdróż obciążenia treningowe do środowiska produkcyjnego

Ważna

Ta funkcja jest dostępna w publicznej wersji testowej.

Użyj DABs do definiowania zadania treningowego AI Runtime w postaci kodu. Trzymaj go w kontroli wersji źródłowej, wdrażaj w różnych środowiskach, planuj i komponuj razem z innymi zadaniami. Ta strona opisuje ścieżkę korzystania z własnego treningu, w ramach której ai_runtime_task uruchamia własne polecenie dla katalogu z kodem na bezserwerowych zasobach GPU.

To jest inne zadanie niż uruchomienie notatnika na bezserwerowym GPU za pomocą pakietu. Przykład podstawowego pakietu notebook-on-GPU można znaleźć w Jobs API i Declarative Automation Bundles.

Requirements

  • Przestrzeń robocza z włączonym AI Runtime. Zobacz Wymagania.
  • Databricks CLI (interfejs wiersza poleceń) zainstalowany i skonfigurowany do wdrażania pakietów.

Zdefiniuj zadanie AI Runtime w pakiecie

Element ai_runtime_task nadaje nazwę eksperymentowi, wskazuje kod treningowy za pomocą code_source_path i deklaruje jedno wdrożenie: polecenie do uruchomienia oraz procesor GPU, na którym ma ono zostać uruchomione. Dodaj to do zadania w swoim zestawie:

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 wskazuje na Twój spakowany kod treningowy, a command_path to skrypt uruchamiany przez zadanie. Ponowienia, limity czasu i uprawnienia ustawia się w zadaniu i jobie w taki sam sposób jak w przypadku każdego joba Azure Databricks, więc możesz nadal stosować dotychczasowe praktyki związane z bundlami. Aby dowiedzieć się, jak zapakować i odnieść się do kodu, zobacz Wyślij swój kod treningowy.

ai_runtime_task Pola

Pole Typ Description
experiment String Required. Nazwa eksperymentu MLflow dla tego biegu. Zobacz Śledzenie eksperymentów i obserwowalność.
code_source_path String Kod szkoleniowy, który ma zostać uruchomiony: plik wyjściowy spakowanego artefaktu tgz lub ścieżka /Workspace albo /Volumes do kodu, który został już przesłany. Zobacz Wyślij swój kod treningowy.
deployments Sequence Required. Pojedyncze wdrożenie opisujące polecenie i obliczenia do jego uruchomienia. Każdy wpis zawiera command_path, compute, oraz opcjonalny name.
deployments[].command_path String Required. Skrypt uruchamia zadanie na każdym węźle.
deployments[].compute.accelerator_type String Required. Typ GPU, na przykład GPU_1xA10, GPU_1xH100, lub GPU_8xH100.
deployments[].compute.accelerator_count Integer Required. Całkowita liczba procesorów GPU we wszystkich węzłach — wielokrotność liczby GPU na węzeł zakodowanej w accelerator_type.
deployments[].name String Opcjonalna nazwa wdrożenia, używana w logach i interfejsie użytkownika.
docker_image_url String Opcjonalny niestandardowy obraz Dockera do uruchomienia polecenia zamiast środowiska zarządzanego. Zobacz Używanie niestandardowych obrazów platformy Docker.
mlflow_run String Opcjonalna nazwa wyświetlania dla uruchomienia MLflow.
mlflow_experiment_directory String Opcjonalny katalog przestrzeni roboczej, w którym tworzony jest eksperyment. Musi zaczynać się od /Workspace. Ustaw tę opcję w przypadku uruchamiania jako jednostka usługi, która nie ma domyślnego katalogu użytkownika.
mlflow_artifact_location String Opcjonalna lokalizacja korzeniowa dla artefaktów MLflow, na przykład ścieżka /Volumes/<catalog>/<schema>/<volume>/… . Musi odpowiadać lokalizacji artefaktu istniejącego eksperymentu lub zostać pominięta.

Ustaw próby, timeouty, uprawnienia i środowisko (environment_key) na zadaniu i zadaniu — nie wewnątrz ai_runtime_task. Pełne informacje o zadaniu można znaleźć w artykule AI Runtime task.

Konfiguruj akcelerator sprzętowy

Ustaw accelerator_type na procesor GPU, którego wymaga Twoje obciążenie robocze, a accelerator_count na całkowitą liczbę procesorów GPU. Liczba jest wielokrotnością liczby GPU w jednym węźle: 1 dla GPU_1xA10 i GPU_1xH100, oraz 8 dla GPU_8xH100. Liczba większa niż rozmiar na węzeł powoduje uruchomienie zadania na wielu węzłach — na przykład konfiguracja GPU_8xH100 z accelerator_count: 16 jest uruchamiana na dwóch węzłach. Aby uzyskać wskazówki dotyczące wyboru akceleratora, zobacz Opcje sprzętowe.

Note

W przypadku uruchomień wielowęzłowych AI Runtime uruchamia Twoje polecenie na każdym węźle i ustawia w środowisku zadania standardowe zmienne środowiskowe trenowania rozproszonego — NUM_NODES, WORLD_SIZE, LOCAL_WORLD_SIZE, MASTER_ADDR i MASTER_PORT. Są odczytywane z polecenia (na przykład podczas torchrun uruchamiania); nie ustawia się ich w pakiecie.

Ustaw środowisko i zależności

Zadeklaruj blok environments w zadaniu i odwołaj się do niego w zadaniu podrzędnym za pomocą environment_key. AI Runtime instaluje wymienione zależności przed uruchomieniem polecenia:

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: '5'
            dependencies:
              - numpy

Dostępne środowiska znajdziesz w artykule Ustaw swoje środowisko.

Wyślij swój kod treningowy

code_source_path informuje zadanie o tym, gdzie znajduje się Twój kod szkoleniowy. Przybiera jedną z dwóch form:

  • Artefakt zapakowany tgz — zadeklaruj artefakt i wskaż code_source_path jego plik wyjściowy. Azure Databricks buduje tarball i przesyła go na .databricks bundle deploy Tak właśnie wysyła się kod z lokalnego katalogu projektów lub z dedykowanej rewizji Gita.
  • Przestrzeń robocza lub ścieżka woluminów — kod już przesłany, używany as-is.

Opakowany artefakt

Zadeklaruj artefakt i wskaż tgzcode_source_path jego plik wyjściowy. W databricks bundle deploy CLI tworzy archiwum tar, przesyła je, a zadanie je rozpakowuje i uruchamia na nim Twoje polecenie:

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

Użyj do include pakowania plików z drzewa roboczego lub git do snapshotu zadeklarowanej gałęzi lub commitu.

Przestrzeń robocza lub ścieżka woluminu

Aby użyć kodu, który został już przesłany, ustaw code_source_path na ścieżkę /Volumes/… lub /Workspace/…. Azure Databricks używa ścieżki as-is i nie pakuje nic.

Pola artefaktów tgz :

Pole Description
type tgz tworzy archiwum tar.gz z plików źródłowych, zamiast uruchamiać polecenie build.
path Bazowy katalog do pakowania. include ścieżki i nazwy elementów archiwum są do niego względne.
include Lista podścieżek pakietu path. Pomiń pakowanie całego path. Uwzględnia .gitignore; sync.include i sync.exclude obowiązujące dla całego pakietu nie mają zastosowania. Alternatywa dla komendy build .
git Utwórz migawkę zatwierdzonego odwołania Git zamiast drzewa roboczego. Ustaw git.branch lub git.commit (commit wygrywa, gdy oba są ustawione). Alternatywa dla komendy build .
files[].source Ścieżka zbudowanej tarballi. Wskaż code_source_path na to.

Note

AI Runtime wyodrębnia Twój kod do katalogu i udostępnia go jako CODE_SOURCE_PATH zmienną środowiskową. Odwołaj się do niego w poleceniu, aby ścieżki względne były poprawnie rozpoznawane, na przykład cd "$CODE_SOURCE_PATH", przed uruchomieniem skryptu.

Kompletny przykład

Ten przykład trenuje na jednym GPU A10 z lokalnego projektu, bez wcześniejszego ustawienia CLI poza instalacją i konfiguracją Azure Databricks CLI. Projekt składa się z trzech plików:

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

command.sh jest punktem wejścia nazwanym przez command_path. Zmienia się do katalogu wyodrębnionego kodu i uruchamia skrypt treningowy:

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

databricks.yml nadaje nazwę pakietowi, pakuje src/ jako artefakt tgz, uruchamia go jako ai_runtime_task, instaluje numpy w środowisku zadania oraz definiuje cele programistyczne i produkcyjne:

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: '5'
            dependencies:
              - numpy

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

Wdroż pakiet i uruchom zadanie. databricks bundle deploy buduje i przesyła tgz artefakt oraz tworzy zadanie; databricks bundle run rozpoczyna go:

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

Buduj wielozadaniowe workflowy

ai_runtime_task to zadanie w usłudze Azure Databricks, więc współdziała z pozostałymi elementami zadania. Możesz wykonać etap przygotowawczy przed treningiem, połączyć zadania GPU i CPU w jednym zadaniu i używać różnych akceleratorów dla każdego zadania.

Uporządkuj zadania za pomocą depends_on

Użyj depends_on, aby uruchamiać zadania kolejno. Poniższy potok uruchamia notatnik przygotowawczy, a następnie zadanie trenowania na GPU, które rozpoczyna się dopiero po pomyślnym zakończeniu zadania przygotowawczego:

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

Połączenie zadań GPU i CPU

W powyższym pipeline tylko etap treningowy wymaga GPU. Utrzymywanie zadań niezwiązanych z GPU, takich jak przygotowanie danych, w osobnych zadaniach sprawia, że czas pracy GPU jest przeznaczony na trenowanie.

Note

ai_runtime_task nie obsługuje wartości zadań w usłudze Azure Databricks ({{tasks.<task_key>.values.<name>}} lub dbutils.jobs.taskValues). Aby przekazywać dane między etapami, zapisz je we współdzielonej lokalizacji, do której oba zadania mają dostęp, na przykład w woluminie usługi Unity Catalog lub w pliku obszaru roboczego, i odwołuj się do tej ścieżki w każdym zadaniu.

Zaplanuj pracę

Dodaj do zadania element schedule, aby uruchamiać je cyklicznie. Wdróż pakiet z wstrzymanym harmonogramem, aby wdrożenie pakietu nie uruchamiało automatycznie przebiegów, a następnie wznów harmonogram, gdy wszystko będzie gotowe:

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

Awans od rozwoju do produkcji

Awans z rozwoju do produkcji to standardowa funkcja pakietu, którą zadanie AI Runtime dziedziczy bez zmian.

Cele i tryby wiązek

Zdefiniuj cel produkcyjny mode: production obok celu rozwojowego. Element docelowy określa, gdzie pakiet jest wdrażany i jak są nazywane jego zasoby:

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

Wdrożenie i uruchomienie

Rozmieszczenie i uruchomienie pakietu przeciwko celowi za pomocą standardowych poleceń pakietu:

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

Następne kroki

  • Last updated on