Gestire un modello con Ray Serve in AKS

In questo articolo si distribuisce il modello meteo Aurora ottimizzato come endpoint HTTP persistente usando Ray Serve in Servizio Azure Kubernetes (AKS). Questo metodo usa una risorsa RayService per il serving di lunga durata e non è soggetta al controllo di ammissione di Kueue.

Importante

Il software open source è citato nella documentazione e negli esempi di AKS. Il software che distribuisci è escluso dagli accordi sul livello di servizio di AKS, dalla garanzia limitata e dal supporto Azure. Quando si utilizza una tecnologia open source insieme ad AKS, consulta le opzioni di supporto offerte dalle rispettive community e dai responsabili dei progetti per definire un piano.

Microsoft si assume la responsabilità di creare i pacchetti open source che distribuiamo su AKS. Tale responsabilità comprende la piena responsabilità del processo di compilazione, scansione, firma, convalida e applicazione degli hotfix, oltre al controllo dei file binari nelle immagini container. Per altre informazioni, vedere Gestione delle vulnerabilità per il servizio Azure Kubernetes (AKS) e Copertura del supporto del servizio Azure Kubernetes (AKS).

Prerequisiti

Impostare le variabili di ambiente

Passare all'esempio di servizio online nel repository clonato e configurare le variabili di ambiente necessarie:

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

Nota

AURORA_RUN_ID è il JOB_NAME dell'esecuzione di fine-tuning Aurora completata. È possibile trovarlo con:

az storage blob list -c aurora --prefix checkpoints/ \
  --account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table

Distribuisci il servizio

Distribuire RayService:

./submit-service.sh

Lo script crea un oggetto ConfigMap dal codice dell'applicazione che gestisce, esegue il rendering del manifesto RayService tramite envsubste lo applica. L'operatore KubeRay crea il cluster Ray e distribuisce l'applicazione Serve.

Tip

Eseguire ./submit-service.sh --dry-run per convalidare il manifesto di cui è stato eseguito il rendering senza applicarlo al cluster.

Nota

RayService non è soggetto al controllo di ammissione da parte di Kueue. La gestione dei carichi di lavoro è di lunga durata e richiede risorse dedicate anziché semantica della coda batch.

Verificare la distribuzione

Attendere finché RayService non segnala lo stato In esecuzione:

kubectl -n ray get rayservice ${SERVICE_NAME} -w

Output previsto:

NAME           SERVICE STATUS   NUM SERVE ENDPOINTS
aurora-serve   Running          1

Testare l'endpoint

Eseguire il port forwarding del servizio serve e inviare richieste di test:

kubectl -n ray port-forward svc/${SERVICE_NAME}-serve-svc 8000:8000

Controllo stato:

curl http://localhost:8000${ROUTE_PREFIX}

Output previsto:

{"status":"ok","gpu_name":"NVIDIA A100-SXM4-80GB","run_id":"<your-run-id>","adapter":"checkpoints/<your-run-id>/last.safetensors"}

Richiesta di previsione:

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}'

Output previsto:

{
  "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",
  ...
}

La risposta include statistiche di riepilogo per variabile (forma, media, min, max) per ogni variabile di superficie nella previsione.

Informazioni di riferimento sulla configurazione

Variabile Predefinito Description
AZURE_STORAGE_ACCOUNT_NAME (obbligatorio) Account di archiviazione dal modulo 1
AURORA_RUN_ID (obbligatorio) JOB_NAME da un'esecuzione aurora-finetune completata
AURORA_INPUT_CONTAINER aurora Contenitore con dati di inizializzazione
AURORA_ADAPTER_CONTAINER aurora Contenitore con il checkpoint LoRA
AURORA_INIT_FILE init-2021-01-01-00z.npz File init predefinito per le richieste
AURORA_LEAD_HOURS 6 Tempo di anticipo predefinito della previsione (deve essere un multiplo di 6 ore)
AURORA_LORA_RANK 8 Rango LoRA (deve corrispondere all'addestramento)
AURORA_REQUIRE_GPU_NAME A100 Verificare il nome della GPU (lasciare vuoto per ignorarlo)
SERVICE_NAME aurora-serve Nome della risorsa RayService
ROUTE_PREFIX /aurora Prefisso di route HTTP per l'endpoint di servizio
CONFIGMAP_NAME aurora-serve-scripts Nome della ConfigMap che contiene lo script di servizio

Pulire le risorse

Eliminare RayService e il relativo ConfigMap:

kubectl -n ray delete rayservice ${SERVICE_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}

Passaggi successivi

  • Last updated on