AKS で Ray Serve を使用してモデルを提供する

この記事では、ray Serve on Azure Kubernetes Service (AKS)を使用して、微調整された Aurora 気象モデルを永続的な HTTP エンドポイントとしてデプロイします。 このメソッドは、有効期間の長いサービスに RayService リソースを使用します。Kueue による入場管理は行われません。

重要

オープンソース ソフトウェアは、AKS のドキュメントとサンプル全体で説明されています。 デプロイするソフトウェアは、AKS サービス レベル アグリーメント、限定保証、Azure サポートから除外されます。 AKS と共にオープンソース テクノロジを使用する場合は、それぞれのコミュニティとプロジェクト保守担当者から受けられるサポート オプションを調べ、計画を策定してください。

Microsoft は、AKS 上に展開するオープンソース パッケージを構築する責任を負います。 その責任には、ビルド、スキャン、署名、検証、修正プログラム プロセスの完全な所有権と、コンテナー イメージ内のバイナリの制御権が伴います。 詳細については、「AKS の脆弱性の管理」と「AKS のサポート範囲」を参照してください。

前提条件

環境変数の設定

複製されたリポジトリのオンライン サービスの例に移動し、必要な環境変数を構成します。

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

注

AURORA_RUN_ID は、完了した Aurora のファインチューニング実行で得られた JOB_NAME です。 次の方法で見つけることができます。

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

サービスをデプロイする

RayService をデプロイします。

./submit-service.sh

このスクリプトは、サービス側のアプリケーション コードから ConfigMap を作成し、 envsubstを介して RayService マニフェストをレンダリングして適用します。 KubeRay オペレーターが Ray クラスターを作成し、Serve アプリケーションをデプロイします。

Tip

./submit-service.sh --dry-runを実行して、レンダリングされたマニフェストをクラスターに適用せずに検証します。

注

RayService は、Kueue によって受付管理されていません。 ワークロードの提供は有効期間が長く、バッチ キュー セマンティクスではなく専用のリソースが必要です。

デプロイメントを確認する

RayService が Running と表示されるまで待ちます:

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

予想される出力:

NAME           SERVICE STATUS   NUM SERVE ENDPOINTS
aurora-serve   Running          1

エンドポイントをテストする

serve サービスをポートフォワードし、テストリクエストを送信します。

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

ヘルスチェック:

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

予想される出力:

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

予測要求:

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

予想される出力:

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

応答には、予測の各サーフェス変数の変数ごとのサマリー統計 (図形、平均、最小値、最大値) が含まれます。

構成のリファレンス

Variable Default Description
AZURE_STORAGE_ACCOUNT_NAME (必須) モジュール 1 のストレージ アカウント
AURORA_RUN_ID (必須) aurora-finetune の実行完了後の JOB_NAME
AURORA_INPUT_CONTAINER aurora init データを含むコンテナー
AURORA_ADAPTER_CONTAINER aurora LoRA チェックポイントを持つコンテナー
AURORA_INIT_FILE init-2021-01-01-00z.npz リクエスト用の既定の初期化ファイル
AURORA_LEAD_HOURS 6 既定の予測リード タイム (6 時間の倍数にする必要があります)
AURORA_LORA_RANK 8 LoRAのランク（学習時の設定と一致している必要があります）
AURORA_REQUIRE_GPU_NAME A100 GPU名の確認（空欄でスキップ）
SERVICE_NAME aurora-serve RayService リソースの名前
ROUTE_PREFIX /aurora サービス エンドポイントの HTTP ルート プレフィックス
CONFIGMAP_NAME aurora-serve-scripts サービス スクリプトを保持している ConfigMap の名前

リソースをクリーンアップする

RayService とその ConfigMap を削除します。

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

次のステップ

  • Last updated on