Ray w środowisku wykonawczym AI

Uwaga / Notatka

Jeśli używasz Ray w klasycznym środowisku obliczeniowym Databricks z Databricks Runtime ML, zobacz Ray on Databricks.

Ray to open source framework do skalowania obciążeń Python. Możesz uruchomić Ray na AI Runtime bez konfigurowania czy zarządzania bazową infrastrukturą GPU.

Dlaczego używać Ray w AI Runtime

Ray jest powszechnie używany do dystrybucji obciążeń Python, takich jak trenowanie modeli, wnioskowanie wsadowe, przetwarzanie danych oraz strojenie hiperparametrów. W środowisku AI Runtime Ray może uzyskiwać dostęp do danych w woluminach Unity Catalog, śledzić eksperymenty za pomocą MLflow i działać jako część produkcyjnych przepływów pracy.

Możesz używać popularnych bibliotek Ray, takich jak Ray Core, Ray Data, Ray Train i Ray Tune w AI Runtime. Istniejące obciążenia Ray mogą nadal korzystać ze standardowych API bibliotek.

Jak Ray współpracuje z AI Runtime

Każda aplikacja Ray działa na klastrze Ray, który może zawierać jeden lub więcej węzłów. AI Runtime udostępnia i konfiguruje węzły, a Ray przydziela zadania i aktory do dostępnych zasobów CPU i GPU. Sposób uruchamiania Raya zależy od interfejsu wykonawczego:

Interfejs	Nodes	Uruchamianie promienia
Notebook	Pojedynczy węzeł podłączony do notatnika	Wywołaj ray_init() z AI Runtime SDK (databricks.air)
Databricks CLI	Stały zbiór jednego lub więcej węzłów	Uruchom węzeł główny na węźle 0, a następnie dołącz pozostałe węzły jako węzły robocze za pomocą skryptu bootstrap wielokrotnego użytku

Używaj Raya w zeszytach

Gdy Twój notebook jest podłączony do obliczeń GPU środowiska AI Runtime, użyj ray_init() z pakietu SDK Databricks AI Runtime, aby uruchomić Ray na podłączonym węźle:

from databricks.air import ray_init

ray_init()

ray_init() wywołuje standardowy interfejs API ray.init(), konfiguruje pulpit nawigacyjny Ray na potrzeby dostępu przez serwer proxy sterownika Databricks i wyświetla adres URL pulpitu nawigacyjnego w danych wyjściowych notatnika. Używaj dashboardu, aby przeglądać zadania, zadania, aktory, logi i zużycie zasobów Ray, podczas gdy kod działa.

Uwaga / Notatka

ray_init() Wymaga środowiska w wersji 5 i nowej. W wersji 5 importuj go z serverless_gpu, a nie z databricks.air. Databricks AI v6 zawiera Ray. Jeśli używasz Standard v6, zainstaluj Ray przed połączeniem ray_init(). Zobacz Konfigurowanie środowiska.

Przykłady notebooków

Example	Opis
Ray Core, witaj świat	Wysyłaj asynchroniczne zadania GPU na podłączonym komputerze, przeglądaj harmonogramowanie w panelu Ray i pobieraj wyniki.
Strojenie hiperparametrów CIFAR-10 z Ray Tune	Uruchom równoczesne próby z użyciem ułamkowych zasobów GPU dla klasyfikatora obrazów w PyTorch i użyj asynchronicznego algorytmu successive halving (ASHA), aby wcześnie zatrzymywać słabiej działające konfiguracje.
Wnioskowanie wsadowe Qwen2.5-32B z użyciem Ray Data i vLLM	Uruchom wielojęzyczne wnioskowanie wsadowe z ośmioma utrzymywanymi replikami vLLM na 8 układach GPU H100 i zapisz wyniki w formacie Parquet w woluminie Unity Catalog.

Użyj Ray z Databricks CLI

Polecenia interfejsu Databricks CLI dla środowiska AI Runtime obsługują obciążenia Ray jednowęzłowe i wielowęzłowe. W konfiguracji obciążenia określ stałą wartość accelerator_type i wartość całkowitą num_accelerators. Przewodnik Pierwsze kroki z Ray Core zawiera wielokrotnego użytku skrypt bootstrap. W polu command obciążenia ustaw RAY_ENTRYPOINT na ścieżkę do pliku Python i uruchom skrypt inicjalizacyjny. Skrypt bootstrap wykonuje następujące czynności:

• Na węźle 0 uruchamia głowicę Ray i uruchamia skonfigurowany punkt wejścia.
• Na każdym innym węźle uruchamia się pracownik Raya i utrzymuje go podłączonego, podczas gdy punkt wejścia działa.
• Po zakończeniu działania punktu wejścia zatrzymywane są procesy Ray.

W aplikacji połącz się z klastrem za pomocą ray.init(address="auto").

W środowisku standardowym dodaj ray lub wymagane dodatki, takie jak ray[data], ray[train], lub ray[tune], do zależności obciążenia. Databricks AI v6 zawiera Ray.

Zacznij od Raya

Poniższe minimalne przykłady wprowadzają główne biblioteki Ray i korzystają z tego samego wzorca bootstrap klastra.

Example	Opis
Ray Core	Rozpocznij klaster Ray na dwóch GPU A10 i zaplanuj jedno zadanie Ray Core na każdą kartę.
Pociąg Ray	Trenuj mały wielowarstwowy perceptron na danych syntetycznych, z jednym pracownikiem Ray Train na każdą kartę graficzną.
Ray Data	Uruchom syntetyczny pipeline przetwarzania danych przez klaster Ray.
Ray Tune	Dostrajaj mały wielowarstwowy perceptron na danych syntetycznych, z jedną próbą na każdą kartę graficzną.

Dodatkowe przykłady CLI

Example	Opis
Dostrajanie ResNet-50 z Ray Train	Dostrój ResNet-50 z jednym rozproszonym procesem roboczym równoległym na każdy procesor GPU A10 na dwóch węzłach.
Precyzyjne dostrajanie Qwen2.5-3B z Ray Train	Dopracuj Qwen2.5-3B z jednym procesem równoległego przetwarzania danych na każdy GPU na 8x węźle H100.
Wnioskowanie wsadowe z użyciem Ray Data i vLLM	Generuj odpowiedzi za pomocą Qwen2.5-7B-Instruct i zapisuj wyniki w woluminie katalogu Unity jako Parquet.
Wyszukiwanie hiperparametrów LoRA za pomocą Ray Tune	Przeszukaj konfiguracje LoRA dla Qwen2.5-0.5B na czterech GPU A10 i zatrzymuj słabo rokujące próby za pomocą harmonogramu ASHA.
Wyszukiwanie hiperparametrów XGBoost za pomocą Ray Tune	Przeszukaj hiperparametry XGBoost na czterech GPU A10, zapisz najlepszą konfigurację do MLflow i zarejestruj model w Unity Catalog.

Praca z danymi i funkcjami Databricks

Obciążenia robocze Ray mogą mieć dostęp do danych w woluminach Unity Catalog, rejestrować przebiegi w MLflow oraz być uruchamiane jako zadania w Lakeflow Jobs zdefiniowane za pomocą Declarative Automation Bundles.

Dostęp do danych w Unity Catalog

Dla danych tabelarnych w tabeli katalogu Unity użyj ray.data.read_databricks_tables() do odczytania tabeli lub uruchomienia zapytania SQL przez magazyn SQL Databricks. Określ ID magazynu, katalog i schemat, ponieważ AI Runtime nie zapewnia lokalnej sesji Spark. Możesz użyć SQL do wykonywania dołączeń, agregacji i filtrów przed przetworzeniem wyników przez Ray.

Dla danych opartych na plikach i niestrukturalnych użyj woluminu katalogu Unity. Pracownicy Raya mogą uzyskać dostęp do plików za pomocą swoich /Volumes/<catalog>/<schema>/<volume>/... ścieżek. Na przykład Ray Data może odczytywać pliki Parquet za pomocą ray.data.read_parquet() i zapisywać wyniki za pomocą Dataset.write_parquet().

Monitoruj i organizuj obciążenia robocze

Użyj MLflow do rejestrowania parametrów, metryk i artefaktów z obciążenia roboczego Ray. Zobacz Śledzenie eksperymentów i obserwowalność.

Aby zaplanować obciążenie lub komponować je z zadaniami przygotowania danych CPU, użyj Lakeflow Jobs i Declarative Automation Bundles. Zobacz Planowanie obciążeń GPU i tworzenie zadań.

Migracja istniejącego obciążenia Ray

Migracja samodzielnie zarządzanego obciążenia Ray wymaga zastąpienia konfiguracji infrastruktury i integracji usług modelem wykonawczym AI Runtime.

Ocena obciążenia

Przed migracją przejrzyj ograniczenia. Potwierdź, że obciążenie może działać na klastrze o stałej wielkości z jednym typem akceleratora.

Migrowanie obciążenia

Aby przeprowadzić migrację obciążenia Ray zarządzanego samodzielnie:

1. Wybierz notatnik do interaktywnego rozwoju jednowęzłowego lub Databricks CLI do zadań jednowęzłowych lub wielowęzłowych.
2. Przypisuj istniejące zasoby klastra do typu akceleratora AI Runtime oraz liczby akceleratorów. Zobacz Opcje sprzętowe.
3. Zastąp istniejące uruchamianie klastra elementem ray_init() w notesie lub udokumentowanym uruchamianiem węzła nadrzędnego i roboczego w obciążeniu roboczym Databricks CLI.
4. Zadeklaruj zależności Python obciążenia i zaktualizuj jego dane, punkty kontrolne, model oraz ścieżki wyjściowe.
5. Zweryfikowaj obciążenie na najmniejszej możliwej konfiguracji. Potwierdź jego dostęp do danych, żądania dotyczące zasobów i dane wyjściowe przed przetestowaniem docelowej stałej topologii.

Ograniczenia

Ray na AI Runtime ma następujące ograniczenia:

• Klaster Ray ma stałą liczbę węzłów na czas trwania obciążenia. Automatyczne skalowanie klastrów promieni nie jest obsługiwane.
• Wszystkie węzły w obciążeniu roboczym korzystają z tego samego accelerator_type. Klaster Ray nie może zawierać oddzielnych grup roboczych tylko CPU i GPU ani skalować pojemności CPU i GPU niezależnie.
• Notatnik uruchamia Ray na przypisanym do niego pojedynczym węźle. Użyj Databricks CLI dla wielowęzłowego klastra Ray.
• Dostęp do panelu Ray za pośrednictwem serwera proxy sterownika Databricks jest obecnie dostępny tylko dla obciążeń uruchamianych w notebookach.

Tip

Jeśli przygotowanie na CPU i przetwarzanie na GPU mogą działać jako oddzielne etapy, użyj zadania Lakeflow z wieloma zadaniami i przekazuj dane między zadaniami za pośrednictwem woluminu Unity Catalog.