Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule wdrożysz dostosowany model pogody Aurora jako trwały punkt końcowy HTTP przy użyciu funkcji Ray Serve w Azure Kubernetes Service (AKS). Ta metoda korzysta z zasobu RayService do długotrwałego udostępniania i nie podlega kontroli dopuszczenia przez Kueue.
Important
Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Oprogramowanie, które wdrażasz, jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji i wsparcia technicznego platformy Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.
Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje posiadanie pełnej kontroli nad procesem kompilacji, skanowania, podpisywania, weryfikacji i szybkich poprawek, a także nad plikami binarnymi w obrazach kontenerów. Aby uzyskać więcej informacji, zobacz zarządzanie podatnościami dla AKS i zakres wsparcia dla AKS.
Prerequisites
- Infrastruktura wdrożona zgodnie z instrukcją Wdróż infrastrukturę dla Ray i Kueue na platformie AKS.
- Przestrzeń nazw i konto usługi utworzone zgodnie z instrukcjami w dokumencie Konfigurowanie kolejek Kueue dla obciążeń Ray w usłudze AKS.
- Dostrajanie Aurora zostało ukończone zgodnie z instrukcją Dostrajanie modelu pogodowego Aurora przy użyciu Ray na AKS — punkt kontrolny LoRA musi znajdować się pod adresem
aurora/checkpoints/<run-id>/last.safetensorsw magazynie obiektów blob. -
envsubstzainstalowano (gettextpakiet w systemie Linux,brew install gettextw systemie macOS).
Ustawianie zmiennych środowiskowych
Przejdź do przykładu usługi online w sklonowanym repozytorium i skonfiguruj wymagane zmienne środowiskowe:
cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/3-workloads/online-serving
export AZURE_STORAGE_ACCOUNT_NAME=$(terraform -chdir=../../1-infrastructure/terraform output -raw storage_account_name)
export AURORA_RUN_ID=<your-aurora-finetune-job-name>
source env.example
Note
AURORA_RUN_ID to JOB_NAME z ukończonego uruchomienia dostrajania Aurora. Możesz go znaleźć za pomocą:
az storage blob list -c aurora --prefix checkpoints/ \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table
Wdrażanie usługi
Wdróż usługę RayService:
./submit-service.sh
Skrypt tworzy obiekt ConfigMap z kodu aplikacji obsługującej, renderuje manifest RayService za pośrednictwem envsubstmetody i stosuje go. Operator KubeRay tworzy klaster Ray i wdraża aplikację Serve.
Wskazówka
Uruchom polecenie ./submit-service.sh --dry-run , aby zweryfikować renderowany manifest bez stosowania go do klastra.
Note
RayService nie podlega kontroli dopuszczenia przez Kueue. Obsługa obciążeń jest długotrwała i wymaga dedykowanych zasobów, a nie semantyki kolejek wsadowych.
Weryfikowanie wdrożenia
Poczekaj, aż RayService zgłosi stan Running:
kubectl -n ray get rayservice ${SERVICE_NAME} -w
Oczekiwane dane wyjściowe:
NAME SERVICE STATUS NUM SERVE ENDPOINTS
aurora-serve Running 1
Testowanie punktu końcowego
Skonfiguruj przekierowanie portów dla usługi serve i wyślij żądania testowe:
kubectl -n ray port-forward svc/${SERVICE_NAME}-serve-svc 8000:8000
Kontrola kondycji:
curl http://localhost:8000${ROUTE_PREFIX}
Oczekiwane dane wyjściowe:
{"status":"ok","gpu_name":"NVIDIA A100-SXM4-80GB","run_id":"<your-run-id>","adapter":"checkpoints/<your-run-id>/last.safetensors"}
Żądanie prognozy:
curl -X POST http://localhost:8000${ROUTE_PREFIX} \
-H 'Content-Type: application/json' \
-d '{"init_file": "init-2021-01-01-00z.npz", "lead_hours": 6}'
Oczekiwane dane wyjściowe:
{
"init_file": "init-2021-01-01-00z.npz",
"lead_hours": 6,
"surface_variables": {
"2t": {"shape": [1,1,52,100], "mean": 298.76, "min": 272.0, "max": 302.0},
"10u": {"shape": [1,1,52,100], "mean": -2.21, "min": -18.0, "max": 15.38},
"10v": {"shape": [1,1,52,100], "mean": 0.92, "min": -13.88,"max": 18.88},
"msl": {"shape": [1,1,52,100], "mean": 101320.07, "min": 100352.0, "max": 101888.0}
},
"gpu_name": "NVIDIA A100-SXM4-80GB",
...
}
Odpowiedź zawiera statystyki podsumowania poszczególnych zmiennych (kształt, średni, min, max) dla każdej zmiennej powierzchni w prognozie.
Dokumentacja konfiguracji
| Zmienna | Default | Description |
|---|---|---|
AZURE_STORAGE_ACCOUNT_NAME |
(wymagane) | Konto magazynowe z modułu 1 |
AURORA_RUN_ID |
(wymagane) | JOB_NAME z ukończonego biegu aurora-finetune |
AURORA_INPUT_CONTAINER |
aurora |
Kontener z danymi inicjalizacyjnymi |
AURORA_ADAPTER_CONTAINER |
aurora |
Kontener z punktem kontrolnym LoRA |
AURORA_INIT_FILE |
init-2021-01-01-00z.npz |
Domyślny plik inicjalizacyjny dla żądań |
AURORA_LEAD_HOURS |
6 |
Domyślny czas realizacji prognozy (musi być wielokrotny 6 godzin) |
AURORA_LORA_RANK |
8 |
Ranga LoRA (musi odpowiadać treningowi) |
AURORA_REQUIRE_GPU_NAME |
A100 |
Sprawdzenie nazwy GPU (pozostaw puste, aby pominąć) |
SERVICE_NAME |
aurora-serve |
Nazwa zasobu RayService |
ROUTE_PREFIX |
/aurora |
Prefiks trasy HTTP dla punktu końcowego usługi |
CONFIGMAP_NAME |
aurora-serve-scripts |
Nazwa obiektu ConfigMap zawierającego skrypt obsługujący |
Uprzątnij zasoby
Usuń usługę RayService i jej ConfigMap:
kubectl -n ray delete rayservice ${SERVICE_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}