AKS에서 Ray를 사용하여 일괄 처리 유추 실행

이 문서에서는 LLM 학습 예제에서 생성된 LoRA 어댑터를 사용하여 vLLM 오프라인 일괄 처리 유추를 실행하는 RayJob을 제출합니다. 작업은 Azure Blob Storage viggo 테스트 분할 및 LoRA 어댑터를 읽고, 단일 GPU에 대한 예측을 생성하고, 결과를 업로드합니다.

중요

오픈 소스 소프트웨어는 AKS 설명서와 샘플 전반에서 언급되어 있습니다. 배포하는 소프트웨어는 AKS 서비스 수준 계약, 제한된 보증 및 Azure 지원 제외됩니다. AKS와 함께 오픈 소스 기술을 사용하는 경우 각 커뮤니티 및 프로젝트 유지 관리자에서 사용할 수 있는 지원 옵션을 참조하여 계획을 개발합니다.

Microsoft는 AKS에 배포하는 오픈 소스 패키지를 빌드하는 역할을 담당합니다. 해당 책임에는 컨테이너 이미지의 이진 파일에 대한 제어와 함께 빌드, 스캔, 서명, 유효성 검사 및 핫픽스 프로세스의 완전한 소유권이 포함됩니다. 자세한 내용은 AKS의 취약성 관리 및 AKS 지원 범위를 참조하세요.

필수 조건

환경 변수 설정

복제된 리포지토리에서 일괄 처리 유추 예제로 이동하고 필요한 환경 변수를 구성합니다.

cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/3-workloads/batch-inference
export AZURE_STORAGE_ACCOUNT_NAME=$(terraform -chdir=../../1-infrastructure/terraform output -raw storage_account_name)
source env.example

참고

팀 큐(옵션 B)를 구성한 경우, source env.example를 실행하기 전에 export QUEUE_NAME=team-a 또는 export QUEUE_NAME=team-b을 설정합니다. 기본값 QUEUE_NAME=default 은 단일 큐 구성(옵션 A)에서만 작동합니다.

워크로드 제출

일괄 처리 유추 RayJob을 제출합니다.

./submit.sh

스크립트는 유추 스크립트에서 ConfigMap을 만들고, 매니페스트 템플릿을 통해 envsubst렌더링하고, 적용합니다. Kueue는 구성된 큐에서 1개의 GPU를 사용할 수 있는 경우 작업을 인정합니다.

Tip

실행 ./submit.sh --dry-run 하여 클러스터에 적용하지 않고 렌더링된 매니페스트의 유효성을 검사합니다.

진행 상황 모니터링

새 셸을 사용 중인 경우 작업 이름을 찾아 export합니다:

export JOB_NAME=$(kubectl -n ray get rayjob --no-headers -o custom-columns=":metadata.name" | grep batch-inference)

RayJob 상태와 Kueue 승인 여부를 확인합니다:

kubectl -n ray get rayjob ${JOB_NAME} -w
kubectl -n ray get workload -w

작업이 완료될 때 예상되는 출력:

NAME                         JOB STATUS   DEPLOYMENT STATUS   START TIME             END TIME               AGE
batch-inference-xxxxxxxxxx   SUCCEEDED    Complete            2026-01-01T00:00:00Z   2026-01-01T00:09:00Z   9m
NAME                                      QUEUE     RESERVED IN     ADMITTED   FINISHED   AGE
rayjob-batch-inference-xxxxxxxxxx-xxxxx   default   cluster-queue   True       True       9m

작업자 로그를 실시간으로 확인합니다.

kubectl -n ray logs -l ray.io/cluster=$(kubectl -n ray get rayjob ${JOB_NAME} -o jsonpath='{.status.rayClusterName}') -f --tail=100

결과 확인

Blob Storage에 예측 파일을 나열합니다.

az storage blob list -c llm-pipeline --prefix "inference/${JOB_NAME}/" \
  --account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table

예상 출력:

Name                                                 Blob Type    Blob Tier    Length    Content Type
---------------------------------------------------  -----------  -----------  --------  ------------------------
inference/<job-name>/metrics.json                    BlockBlob    Hot          128       application/octet-stream
inference/<job-name>/predictions.jsonl               BlockBlob    Hot          411777    application/octet-stream

예측을 다운로드하고 검사합니다.

az storage blob download -c llm-pipeline \
  -n "inference/${JOB_NAME}/predictions.jsonl" \
  --account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login \
  --file /tmp/predictions.jsonl
head -1 /tmp/predictions.jsonl | python3 -m json.tool

예상 출력:

{
    "input": "I'm wondering, have you played any games you found genuinely shocking?",
    "expected": "request(specifier[shocking])",
    "generated": "request_explanation"
}

구성 참조

변수 Default Description
AZURE_STORAGE_ACCOUNT_NAME (필수) 모듈 1의 스토리지 계정
JOB_NAME batch-inference-<timestamp> 고유 RayJob 이름
QUEUE_NAME default Kueue LocalQueue 이름
LLM_DATA_CONTAINER llm-pipeline viggo 테스트 데이터가 있는 Blob 컨테이너
LLM_LORA_CONTAINER llm-pipeline LoRA 어댑터가 있는 Blob 컨테이너
CONFIGMAP_NAME batch-inference-scripts 유추 스크립트를 포함하는 ConfigMap의 이름

자원을 정리하세요

RayJob 및 해당 ConfigMap을 삭제합니다.

kubectl -n ray delete rayjob ${JOB_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}

모든 인프라를 중단하려면 인프라 배포 - 리소스 정리를 참조하세요.

다음 단계