Szybki start z CLI AI Runtime

Important

Interfejs wiersza polecenia środowiska uruchomieniowego sztucznej inteligencji jest w wersji beta.

Uruchom swoje pierwsze zadanie treningowe za pomocą interfejsu wiersza polecenia AI Runtime w trzech krokach: utwórz konfigurację train.yaml, uruchom ją za pomocą air run, a następnie sprawdź przebieg. Przed rozpoczęciem zainstaluj interfejs wiersza polecenia i skonfiguruj uwierzytelnianie.

Krok 1. Pisanie konfiguracji YAML

Utwórz opis train.yaml opisujący obciążenie. Minimalna konfiguracja wymaga nazwy eksperymentu, specyfikacji obliczeniowej i polecenia. Poniższe polecenie uruchamia się bez żadnego lokalnego kodu, więc możesz od razu przesłać swoje pierwsze uruchomienie:

experiment_name: my-first-air-run
compute:
  num_accelerators: 1
  accelerator_type: GPU_1xA10
command: echo "hello AIR!"

Uruchamianie własnego kodu

Aby uruchomić lokalny skrypt trenowania, dodaj environment blok zawierający listę zależności Python i code_source blok, który przekazuje kod lokalny. Umieść skrypt obok elementu train.yaml:

my-project/
├── train.yaml
└── train.py

experiment_name: my-first-air-run
environment:
  version: '4'
  dependencies:
    - torch
    - transformers
compute:
  num_accelerators: 1
  accelerator_type: GPU_1xA10
code_source:
  type: snapshot
  snapshot:
    root_path: .
command: python $CODE_SOURCE_PATH/train.py

Ta konfiguracja instaluje wymienione zależności, przesyła bieżący katalog (root_path: .) i uruchamia train.py na pojedynczym GPU A10. $CODE_SOURCE_PATH wskazuje na lokalizację przesłanego kodu na zdalnym węźle. Databricks zaleca użycie tego rozwiązania zamiast wpisywania ścieżki na stałe. environment.version wybiera wersję bezserwerowego środowiska GPU i jest opcjonalny (domyślnie '4'). Aby zapoznać się ze wszystkimi dostępnymi wersjami, zobacz Wersje środowiska bezserwerowego.

Pełne informacje o polu znajdziesz w dokumencie Dokumentacja YAML obciążenia.

Krok 2: Prześlij uruchomienie

Prześlij obciążenie:

air run --file train.yaml

CLI przesyła Twój kod lokalny (jeśli skonfigurowano element code_source), przesyła zadanie i wyświetla identyfikator uruchomienia. Użyj tego identyfikatora, aby sprawdzać, monitorować i anulować uruchomienie w kolejnych poleceniach.

Przesłanie tworzy uruchomienie w eksperymencie MLflow o nazwie podanej w experiment_name (eksperyment może zawierać wiele uruchomień). To uruchomienie rejestruje metryki, parametry, artefakty i dzienniki związane z obciążeniem, a wszystkie te elementy można wyświetlić w interfejsie MLflow w obszarze roboczym. Dzienniki są również dostępne poza platformą MLflow: przesyłaj je strumieniowo do terminalu lub pliku albo pobieraj je później air logs (zobacz Krok 3).

Aby obserwować dzienniki do momentu ukończenia, dodaj polecenie --watch:

air run --file train.yaml --watch

Krok 3. Sprawdzanie przebiegu

Sprawdź stan:

air get run <run-id>

Wynik zawiera klikalne linki do eksperymentu MLflow danego uruchomienia oraz do uruchomienia MLflow w interfejsie użytkownika obszaru roboczego.

Przesyłanie strumieniowe lub pobieranie dzienników:

air logs <run-id>
air logs <run-id> --node 2
air logs <run-id> --download-to ./logs/

Rozproszone obciążenia robocze działają na wielu węzłach. Domyślnie air logs streamuje z węzła 0. Aby wyświetlić dzienniki z określonego węzła, przekaż polecenie --node. Użyj --download-to, aby zapisywać logi w lokalnym katalogu zamiast przesyłać je strumieniowo.

Wyświetl listę ostatnich uruchomień:

air list runs --limit 10
air list runs --active

Anuluj uruchomienie:

air cancel <run-id>

Często używane wzorce

Zastąpij pola YAML z wiersza polecenia:

air run --file train.yaml --override compute.num_accelerators=32 timeout_minutes=120

Zweryfikuj konfigurację bez przesyłania:

air run --file train.yaml --dry-run

Umożliw bezpieczne ponawianie zgłoszenia:

air run --file train.yaml --idempotency-key my-unique-key

Jeśli wcześniej użyto tego samego klucza, istniejące uruchomienie zostanie zwrócone zamiast utworzyć nowy.

Dodatkowe zasoby

  • Last updated on