Udostępnij za pośrednictwem

Śledzenie i obserwowanie eksperymentów

Ważna

Środowisko uruchomieniowe sztucznej inteligencji dla zadań z jednym węzłem jest w publicznej wersji zapoznawczej. Rozproszony interfejs API trenowania dla obciążeń z wieloma procesorami GPU pozostaje w wersji beta.

W tym artykule opisano, jak używać platformy MLflow, monitorować kondycję procesora GPU, wyświetlać dzienniki i zarządzać punktami kontrolnymi modelu w środowisku uruchomieniowym sztucznej inteligencji.

Integracja platformy MLflow

Środowisko AI Runtime integruje się natywnie z rozwiązaniem MLflow na potrzeby śledzenia eksperymentów, rejestrowania modeli i wizualizacji metryk.

Zalecenia dotyczące konfiguracji:

  • Uaktualnij bibliotekę MLflow do wersji 3.7 lub nowszej i postępuj zgodnie z wzorcami przepływu pracy uczenia głębokiego.

  • Włącz automatyczne rejestrowanie dla rozwiązania PyTorch Lightning:

    import mlflow
mlflow.pytorch.autolog()

  • Dostosuj nazwę przebiegu MLflow, zamykając kod treningowy modelu w obszarze interfejsu API mlflow.start_run(). Daje to kontrolę nad nazwą uruchomienia i pozwala na restart z poprzedniego uruchomienia. Nazwę uruchomienia można dostosować przy użyciu parametru run_name w mlflow.start_run(run_name="your-custom-name") lub w bibliotekach innych firm, które obsługują MLflow (na przykład Hugging Face Transformers). W przeciwnym razie domyślna nazwa przebiegu to jobTaskRun-xxxxx.

    from transformers import TrainingArguments
args = TrainingArguments(
    report_to="mlflow",
    run_name="llama7b-sft-lr3e5",  # <-- MLflow run name
    logging_steps=50,
)

  • Bezserwerowy interfejs API procesora GPU automatycznie uruchamia eksperyment MLflow z domyślną nazwą /Users/{WORKSPACE_USER}/{get_notebook_name()}. Użytkownicy mogą zastąpić ją zmienną środowiskową MLFLOW_EXPERIMENT_NAME. Zawsze używaj ścieżek bezwzględnych dla zmiennej środowiskowej MLFLOW_EXPERIMENT_NAME :

    import os
os.environ["MLFLOW_EXPERIMENT_NAME"] = "/Users/<username>/my-experiment"

  • Wznów poprzedni trening, ustawiając parametr MLFLOW_RUN_ID z wcześniejszego uruchomienia:

    mlflow.start_run(run_id="<previous-run-id>")

  • Ustaw parametr step w MLFlowLogger na odpowiednie numery partii. Narzędzie MLflow ma limit 10 milionów etapów metrycznych — rejestrowanie każdej partii w dużych operacjach treningowych może spowodować przekroczenie tego limitu. Zobacz Limity zasobów.

Wyświetlanie dzienników

  • Dane wyjściowe notesu — standardowe dane wyjściowe i błędy z kodu szkoleniowego są wyświetlane w danych wyjściowych komórki notesu.
  • Dzienniki sterowników — dostępne za pośrednictwem panelu obliczeniowego na potrzeby debugowania problemów z uruchamianiem, problemów z konfiguracją środowiska i błędów środowiska uruchomieniowego.
  • Dzienniki platformy MLflow — metryki trenowania, parametry i artefakty są widoczne w interfejsie użytkownika eksperymentu MLflow.

Modelowanie punktów kontrolnych

Zapisz punkty kontrolne modelu w woluminach Unity Catalog, które zapewniają takie samo zarządzanie, jak inne obiekty Unity Catalog. Użyj następującego formatu ścieżki, aby odwoływać się do plików w woluminach w notesie Databricks.

/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>

Zapisuj punkty kontrolne na dyskach w taki sam sposób, jak zapisujesz je w pamięci lokalnej.

W poniższym przykładzie pokazano, jak zapisać punkt kontrolny PyTorch do woluminów katalogu Unity.

import torch

checkpoint = {
    "epoch": epoch,  # last finished epoch
    "model_state_dict": model.state_dict(),  # weights & buffers
    "optimizer_state_dict": optimizer.state_dict(),  # optimizer state
    "loss": loss,  # optional current loss
    "metrics": {"val_acc": val_acc},  # optional metrics
    # Add scheduler state, RNG state, and other metadata as needed.
}
checkpoint_path = "/Volumes/my_catalog/my_schema/model/checkpoints/ckpt-0001.pt"
torch.save(checkpoint, checkpoint_path)

Takie podejście działa również w przypadku rozproszonych punktów kontrolnych. W poniższym przykładzie przedstawiono rozproszone punkty kontrolne modelu za pomocą interfejsu API rozproszonego punktu kontrolnego torch:

import torch.distributed.checkpoint as dcp

def save_checkpoint(self, checkpoint_path):
    state_dict = self.get_state_dict(model, optimizer)
    dcp.save(state_dict, checkpoint_id=checkpoint_path)

trainer.save_checkpoint("/Volumes/my_catalog/my_schema/model/checkpoints")

Współpraca między użytkownikami

  • Aby zapewnić wszystkim użytkownikom dostęp do kodu udostępnionego (na przykład modułów pomocnika lub plików YAML środowiska), zapisz je w /Workspace/Shared zamiast w folderach specyficznych dla użytkownika, takich jak /Workspace/Users/<your_email>/.
  • W przypadku kodu, który jest aktywnie rozwijany, użyj folderów Git w folderach specyficznych dla użytkowników /Workspace/Users/<your_email>/ i prześlij do zdalnych repozytoriów Git. Dzięki temu wielu użytkowników może mieć klony i gałęzie specyficzne dla użytkownika, jednocześnie używając zdalnego repozytorium Git do kontroli wersji. Zobacz najlepsze rozwiązania dotyczące korzystania z usługi Git w usłudze Databricks.
  • Współpracownicy mogą udostępniać notesy i komentować je.

Limity globalne w usłudze Databricks

Zobacz Limity zasobów.

  • Last updated on