Launch

• 1: Tutorial: W&B Launch basics
• 2: Launch terms and concepts
• 3: Set up Launch
• 3.1: Configure launch queue
• 3.2: Set up launch agent
• 3.3: Tutorial: Set up W&B Launch on Kubernetes
• 3.4: Tutorial: Set up W&B Launch on SageMaker
• 3.5: Tutorial: Set up W&B Launch on Vertex AI
• 3.6: Tutorial: Set up W&B Launch with Docker
• 4: Create and deploy jobs
• 4.1: Add job to queue
• 4.2: Create a launch job
• 4.3: Manage job inputs
• 4.4: Monitor launch queue
• 4.5: View launch jobs
• 5: Create sweeps with W&B Launch
• 6: Launch FAQ
• 6.1: Are there best practices for using Launch effectively?
• 6.2: Can I specify a Dockerfile and let W&B build a Docker image for me?
• 6.3: Can Launch automatically provision (and spin down) compute resources for me in the target environment?
• 6.4: Can you specify secrets for jobs/automations? For instance, an API key which you do not wish to be directly visible to users?
• 6.5: Does Launch support parallelization? How can I limit the resources consumed by a job?
• 6.6: How can admins restrict which users have modify access?
• 6.7: How do I control who can push to a queue?
• 6.8: How do I fix a "permission denied" error in Launch?
• 6.9: How do I make W&B Launch work with Tensorflow on GPU?
• 6.10: How does W&B Launch build images?
• 6.11: I do not like clicking- can I use Launch without going through the UI?
• 6.12: I do not want W&B to build a container for me, can I still use Launch?
• 6.13: Is `wandb launch -d` or `wandb job create image` uploading a whole docker artifact and not pulling from a registry?
• 6.14: What permissions does the agent require in Kubernetes?
• 6.15: What requirements does the accelerator base image have?
• 6.16: When multiple jobs in a Docker queue download the same artifact, is any caching used, or is it re-downloaded every run?
• 7: Launch integration guides
• 7.1: Dagster
• 7.2: Launch multinode jobs with Volcano
• 7.3: NVIDIA NeMo Inference Microservice Deploy Job
• 7.4: Spin up a single node GPU cluster with Minikube

1 - Tutorial: W&B Launch basics

Launch 란 무엇인가요?

W&B Launch를 사용하면 데스크톱에서 Amazon SageMaker, Kubernetes 등과 같은 컴퓨팅 리소스로 트레이닝 runs을 쉽게 확장할 수 있습니다. W&B Launch가 구성되면 몇 번의 클릭과 코맨드만으로 트레이닝 스크립트, 모델 평가 스위트, 프로덕션 추론을 위한 모델 준비 등을 빠르게 실행할 수 있습니다.

작동 방식

Launch는 launch jobs, queues, agents의 세 가지 기본 구성 요소로 구성됩니다.

launch job은 머신러닝 워크플로우에서 작업을 구성하고 실행하기 위한 청사진입니다. launch job이 있으면 launch queue에 추가할 수 있습니다. launch queue는 Amazon SageMaker 또는 Kubernetes 클러스터와 같은 특정 컴퓨팅 대상 리소스에 작업을 구성하고 제출할 수 있는 선입선출 (FIFO) queue입니다.

작업이 queue에 추가되면 launch agents가 해당 queue를 폴링하고 queue가 대상으로 하는 시스템에서 작업을 실행합니다.

유스 케이스에 따라 귀하 (또는 팀의 누군가)는 선택한 컴퓨팅 리소스 대상 (예: Amazon SageMaker)에 따라 launch queue를 구성하고 인프라에 launch agent를 배포합니다.

launch jobs, queue 작동 방식, launch agents 및 W&B Launch 작동 방식에 대한 추가 정보는 용어 및 개념 페이지를 참조하십시오.

시작 방법

유스 케이스에 따라 다음 리소스를 탐색하여 W&B Launch를 시작하십시오.

• W&B Launch를 처음 사용하는 경우 워크쓰루 가이드를 살펴보는 것이 좋습니다.
• W&B Launch 설정 방법을 알아봅니다.
• launch job 만들기
• W&B Launch public jobs GitHub repository에서 Triton에 배포, LLM 평가 등과 같은 일반적인 작업 템플릿을 확인하십시오.
  • 이 리포지토리에서 생성된 launch jobs는 이 public wandb/jobs project W&B project에서 볼 수 있습니다.

워크쓰루

이 페이지에서는 W&B Launch 워크플로우의 기본 사항을 살펴봅니다.

필수 조건

시작하기 전에 다음 필수 조건을 충족했는지 확인하십시오.

1. https://wandb.ai/site에서 계정을 등록한 다음 W&B 계정에 로그인합니다.
2. 이 워크쓰루에는 작동하는 Docker CLI 및 엔진이 있는 시스템에 대한 터미널 엑세스가 필요합니다. 자세한 내용은 Docker 설치 가이드를 참조하십시오.
3. W&B Python SDK 버전 0.17.1 이상을 설치합니다.

pip install wandb>=0.17.1

4. 터미널 내에서 wandb login을 실행하거나 WANDB_API_KEY 환경 변수를 설정하여 W&B로 인증합니다.

• W&B에 로그인
• 환경 변수

터미널 내에서 다음을 실행합니다.

```bash
wandb login
```

```bash
WANDB_API_KEY=<your-api-key>
```

`<your-api-key>`를 W&B API 키로 바꿉니다.

launch job 만들기

다음 세 가지 방법 중 하나로 launch job을 만듭니다. Docker 이미지, git 리포지토리 또는 로컬 소스 코드를 사용합니다.

• Docker 이미지 사용
• git 리포지토리에서
• 로컬 소스 코드에서

wandb launch --docker-image wandb/job_hello_world:main --project launch-quickstart

wandb launch --uri https://github.com/wandb/launch-jobs.git \\
--job-name hello-world-git --project launch-quickstart \\ 
--build-context jobs/hello_world --dockerfile Dockerfile.wandb \\ 
--entry-point "python job.py"

import wandb

with wandb.init() as run:
    run.log({"hello": "world"})

wandb>=0.17.1

wandb launch --uri . --job-name hello-world-code --project launch-quickstart --entry-point "python train.py"

queue 만들기

Launch는 팀이 공유 컴퓨팅을 중심으로 워크플로우를 구축할 수 있도록 설계되었습니다. 지금까지의 예에서 wandb launch 코맨드는 로컬 시스템에서 컨테이너를 동기적으로 실행했습니다. Launch queues와 agents는 공유 리소스에서 비동기적으로 작업을 실행하고 우선 순위 지정 및 하이퍼파라미터 최적화와 같은 고급 기능을 활성화합니다. 기본 queue를 만들려면 다음 단계를 따르십시오.

1. wandb.ai/launch로 이동하여 queue 만들기 버튼을 클릭합니다.
2. queue와 연결할 Entity를 선택합니다.
3. Queue 이름을 입력합니다.
4. 리소스로 Docker를 선택합니다.
5. 지금은 구성을 비워 둡니다.
6. queue 만들기 :rocket:를 클릭합니다.

버튼을 클릭하면 브라우저가 queue 보기의 Agents 탭으로 리디렉션됩니다. agent가 폴링을 시작할 때까지 queue는 활성 상태 아님 상태로 유지됩니다.

고급 queue 구성 옵션은 고급 queue 설정 페이지를 참조하십시오.

agent를 queue에 연결

queue에 폴링 agent가 없으면 queue 보기는 화면 상단에 빨간색 배너로 agent 추가 버튼을 표시합니다. 버튼을 클릭하여 agent를 실행하는 코맨드를 복사하여 봅니다. 코맨드는 다음과 같아야 합니다.

wandb launch-agent --queue <queue-name> --entity <entity-name>

터미널에서 코맨드를 실행하여 agent를 시작합니다. agent는 실행할 작업을 위해 지정된 queue를 폴링합니다. 수신되면 agent는 wandb launch 코맨드가 로컬에서 실행된 것처럼 job에 대한 컨테이너 이미지를 다운로드하거나 빌드한 다음 실행합니다.

Launch 페이지로 다시 이동하여 queue가 이제 활성으로 표시되는지 확인합니다.

queue에 job 제출

W&B 계정에서 새 launch-quickstart project로 이동하여 화면 왼쪽의 탐색에서 jobs 탭을 엽니다.

Jobs 페이지에는 이전에 실행된 runs에서 생성된 W&B Jobs 목록이 표시됩니다. launch job을 클릭하여 소스 코드, 종속성 및 job에서 생성된 runs을 봅니다. 이 워크쓰루를 완료하면 목록에 세 개의 jobs이 있어야 합니다.

새 jobs 중 하나를 선택하고 다음 지침에 따라 queue에 제출합니다.

1. Launch 버튼을 클릭하여 job을 queue에 제출합니다. Launch drawer가 나타납니다.
2. 이전에 만든 Queue를 선택하고 Launch를 클릭합니다.

이렇게 하면 job이 queue에 제출됩니다. 이 queue를 폴링하는 agent는 job을 선택하여 실행합니다. job의 진행 상황은 W&B UI에서 모니터링하거나 터미널에서 agent의 출력을 검사하여 모니터링할 수 있습니다.

wandb launch 코맨드는 --queue 인수를 지정하여 jobs을 queue로 직접 푸시할 수 있습니다. 예를 들어 hello-world 컨테이너 job을 queue에 제출하려면 다음 코맨드를 실행합니다.

wandb launch --docker-image wandb/job_hello_world:main --project launch-quickstart --queue <queue-name>

2 - Launch terms and concepts

W&B Launch를 사용하면 jobs를 queues에 대기열에 추가하여 runs를 생성할 수 있습니다. Jobs는 W&B로 계측된 Python 스크립트입니다. Queues는 target resource에서 실행할 jobs 목록을 보관합니다. Agents는 queues에서 jobs를 가져와 target resource에서 jobs를 실행합니다. W&B는 W&B가 runs를 추적하는 방식과 유사하게 Launch jobs를 추적합니다.

Launch job

Launch job은 완료할 작업을 나타내는 특정 유형의 W&B Artifact입니다. 예를 들어 일반적인 Launch jobs에는 model 트레이닝 또는 model 평가 트리거가 포함됩니다. Job 정의에는 다음이 포함됩니다.

• 하나 이상의 실행 가능한 진입점을 포함하여 Python 코드 및 기타 파일 자산.
• 입력 (config parameter) 및 출력 (metrics 로깅)에 대한 정보.
• 환경에 대한 정보. (예: requirements.txt, 기본 Dockerfile).

Job 정의에는 세 가지 주요 종류가 있습니다.

프로젝트 workspace의 Jobs 탭 아래의 W&B App에서 생성한 jobs를 찾습니다. 여기에서 jobs를 구성하고 launch queue로 보내 다양한 target resource에서 실행할 수 있습니다.

Launch queue

Launch queues는 특정 target resource에서 실행할 jobs의 정렬된 목록입니다. Launch queues는 선입선출 (FIFO) 방식입니다. 가질 수 있는 queues 수에는 실제적인 제한이 없지만 target resource당 하나의 queue를 사용하는 것이 좋습니다. Jobs는 W&B App UI, W&B CLI 또는 Python SDK를 사용하여 대기열에 추가할 수 있습니다. 그런 다음 하나 이상의 Launch agents를 구성하여 queue에서 항목을 가져와 queue의 target resource에서 실행할 수 있습니다.

Target resources

Launch queue가 jobs를 실행하도록 구성된 컴퓨팅 환경을 target resource라고 합니다.

W&B Launch는 다음 target resources를 지원합니다.

• Docker
• Kubernetes
• AWS SageMaker
• GCP Vertex

각 target resource는 resource configurations라는 서로 다른 configuration parameter 집합을 허용합니다. Resource configurations는 각 Launch queue에서 정의한 기본값을 사용하지만 각 job에서 독립적으로 재정의할 수 있습니다. 자세한 내용은 각 target resource에 대한 설명서를 참조하십시오.

Launch agent

Launch agents는 실행할 jobs에 대해 Launch queues를 주기적으로 확인하는 가벼운 영구 프로그램입니다. Launch agent가 job을 수신하면 먼저 job 정의에서 이미지를 빌드하거나 가져온 다음 target resource에서 실행합니다.

하나의 agent가 여러 queues를 폴링할 수 있지만 agent는 폴링하는 각 queue에 대해 모든 지원 target resources를 지원하도록 적절하게 구성되어야 합니다.

Launch agent environment

Agent 환경은 Launch agent가 실행 중인 jobs를 폴링하는 환경입니다.

3 - Set up Launch

이 페이지는 W&B Launch 설정에 필요한 개략적인 단계를 설명합니다.

1. 대기열 설정: 대기열은 FIFO이며 대기열 설정을 갖습니다. 대기열의 설정은 대상 리소스에서 작업이 실행되는 위치와 방법을 제어합니다.
2. 에이전트 설정: 에이전트는 사용자 시스템/인프라에서 실행되며 Launch 작업을 위해 하나 이상의 대기열을 폴링합니다. 작업이 풀되면 에이전트는 이미지가 빌드되어 사용 가능한지 확인합니다. 그런 다음 에이전트는 작업을 대상 리소스에 제출합니다.

대기열 설정

Launch 대기열은 특정 대상 리소스를 가리키도록 구성해야 하며, 해당 리소스에 특정한 추가 구성도 함께 설정해야 합니다. 예를 들어 Kubernetes 클러스터를 가리키는 Launch 대기열은 환경 변수를 포함하거나 Launch 대기열 구성에 사용자 정의 네임스페이스를 설정할 수 있습니다. 대기열을 생성할 때 사용하려는 대상 리소스와 해당 리소스에 사용할 구성을 모두 지정합니다.

에이전트가 대기열에서 작업을 받으면 대기열 구성도 함께 받습니다. 에이전트가 작업을 대상 리소스에 제출할 때 작업 자체의 재정의와 함께 대기열 구성을 포함합니다. 예를 들어 작업 구성을 사용하여 해당 작업 인스턴스에 대해서만 Amazon SageMaker 인스턴스 유형을 지정할 수 있습니다. 이 경우 대기열 구성 템플릿이 최종 사용자 인터페이스로 사용되는 것이 일반적입니다.

대기열 생성

1. wandb.ai/launch에서 Launch App으로 이동합니다.
2. 화면 오른쪽 상단의 대기열 생성 버튼을 클릭합니다.

3. Entity 드롭다운 메뉴에서 대기열이 속할 Entity를 선택합니다.
4. 대기열 필드에 대기열 이름을 입력합니다.
5. 리소스 드롭다운에서 이 대기열에 추가할 작업에 사용할 컴퓨팅 리소스를 선택합니다.
6. 이 대기열에 대해 우선 순위 지정을 허용할지 여부를 선택합니다. 우선 순위 지정이 활성화되면 팀의 사용자가 작업을 대기열에 추가할 때 Launch 작업의 우선 순위를 정의할 수 있습니다. 우선 순위가 높은 작업은 우선 순위가 낮은 작업보다 먼저 실행됩니다.
7. 구성 필드에 JSON 또는 YAML 형식으로 리소스 구성을 제공합니다. 구성 문서의 구조와 의미는 대기열이 가리키는 리소스 유형에 따라 달라집니다. 자세한 내용은 대상 리소스에 대한 전용 설정 페이지를 참조하십시오.

Launch 에이전트 설정

Launch 에이전트는 하나 이상의 Launch 대기열에서 작업을 폴링하는 장기 실행 프로세스입니다. Launch 에이전트는 선입선출(FIFO) 순서 또는 대기열에서 가져오는 우선 순위에 따라 작업을 디큐합니다. 에이전트가 대기열에서 작업을 디큐하면 해당 작업에 대한 이미지를 선택적으로 빌드합니다. 그런 다음 에이전트는 대기열 구성에 지정된 구성 옵션과 함께 작업을 대상 리소스에 제출합니다.

에이전트 구성

launch-config.yaml이라는 YAML 파일로 Launch 에이전트를 구성합니다. 기본적으로 W&B는 ~/.config/wandb/launch-config.yaml에서 구성 파일을 확인합니다. Launch 에이전트를 활성화할 때 다른 디렉토리를 선택적으로 지정할 수 있습니다.

Launch 에이전트의 구성 파일 내용은 Launch 에이전트의 환경, Launch 대기열의 대상 리소스, Docker 빌더 요구 사항, 클라우드 레지스트리 요구 사항 등에 따라 달라집니다.

유스 케이스와 관계없이 Launch 에이전트에 대한 핵심 구성 가능 옵션은 다음과 같습니다.

• max_jobs: 에이전트가 병렬로 실행할 수 있는 최대 작업 수
• entity: 대기열이 속한 Entity
• queues: 에이전트가 감시할 하나 이상의 대기열 이름

다음 YAML 코드 조각은 핵심 Launch 에이전트 구성 키를 지정하는 방법을 보여줍니다.

# 수행할 동시 run의 최대 수입니다. -1 = 제한 없음
max_jobs: -1

entity: <entity-name>

# 폴링할 대기열 목록입니다.
queues:
  - <queue-name>

컨테이너 빌더 구성

Launch 에이전트는 이미지를 빌드하도록 구성할 수 있습니다. git 리포지토리 또는 코드 Artifacts에서 생성된 Launch 작업을 사용하려면 컨테이너 빌더를 사용하도록 에이전트를 구성해야 합니다. Launch 작업 생성 방법에 대한 자세한 내용은 Launch 작업 생성을 참조하십시오.

W&B Launch는 세 가지 빌더 옵션을 지원합니다.

• Docker: Docker 빌더는 로컬 Docker 데몬을 사용하여 이미지를 빌드합니다.
• Kaniko: Kaniko는 Docker 데몬을 사용할 수 없는 환경에서 이미지 빌드를 가능하게 하는 Google 프로젝트입니다.
• Noop: 에이전트는 작업을 빌드하려고 시도하지 않고 미리 빌드된 이미지만 가져옵니다.

이미지 빌더를 지정하려면 에이전트 구성에 빌더 키를 포함하십시오. 예를 들어 다음 코드 조각은 Docker 또는 Kaniko를 사용하도록 지정하는 Launch 구성(launch-config.yaml)의 일부를 보여줍니다.

builder:
  type: docker | kaniko | noop

컨테이너 레지스트리 구성

경우에 따라 Launch 에이전트를 클라우드 레지스트리에 연결할 수 있습니다. Launch 에이전트를 클라우드 레지스트리에 연결하려는 일반적인 시나리오는 다음과 같습니다.

• 강력한 워크스테이션 또는 클러스터와 같이 빌드한 환경 이외의 환경에서 작업을 실행하려는 경우.
• 에이전트를 사용하여 이미지를 빌드하고 이러한 이미지를 Amazon SageMaker 또는 VertexAI에서 실행하려는 경우.
• Launch 에이전트가 이미지 리포지토리에서 가져오기 위한 자격 증명을 제공하도록 하려는 경우.

에이전트가 컨테이너 레지스트리와 상호 작용하도록 구성하는 방법에 대한 자세한 내용은 고급 에이전트 설정 페이지를 참조하십시오.

Launch 에이전트 활성화

launch-agent W&B CLI 명령으로 Launch 에이전트를 활성화합니다.

wandb launch-agent -q <queue-1> -q <queue-2> --max-jobs 5

일부 유스 케이스에서는 Kubernetes 클러스터 내에서 Launch 에이전트가 대기열을 폴링하도록 할 수 있습니다. 자세한 내용은 고급 대기열 설정 페이지를 참조하십시오.

3.1 - Configure launch queue

다음 페이지에서는 Launch Queue 옵션을 구성하는 방법을 설명합니다.

Queue Config 템플릿 설정

Queue Config 템플릿으로 컴퓨팅 소비에 대한 안전 장치를 관리하세요. 메모리 소비, GPU, 런타임 지속 시간과 같은 필드에 대한 기본값, 최소값 및 최대값을 설정합니다.

Config 템플릿으로 Queue를 구성한 후에는 팀 구성원이 지정한 범위 내에서만 정의한 필드를 변경할 수 있습니다.

Queue 템플릿 구성

기존 Queue에서 Queue 템플릿을 구성하거나 새 Queue를 만들 수 있습니다.

1. https://wandb.ai/launch의 Launch App으로 이동합니다.
2. 템플릿을 추가할 Queue 이름 옆에 있는 Queue 보기를 선택합니다.
3. Config 탭을 선택합니다. 그러면 Queue 생성 시기, Queue Config, 기존 Launch 시 재정의와 같은 Queue에 대한 정보가 표시됩니다.
4. Queue Config 섹션으로 이동합니다.
5. 템플릿을 만들 Config 키-값을 식별합니다.
6. Config의 값을 템플릿 필드로 바꿉니다. 템플릿 필드는 {{variable-name}} 형식을 취합니다.
7. 구성 파싱 버튼을 클릭합니다. 구성을 파싱하면 W&B에서 생성한 각 템플릿에 대해 Queue Config 아래에 타일을 자동으로 만듭니다.
8. 생성된 각 타일에 대해 먼저 Queue Config에서 허용할 수 있는 데이터 유형(문자열, 정수 또는 부동 소수점)을 지정해야 합니다. 이렇게 하려면 유형 드롭다운 메뉴에서 데이터 유형을 선택합니다.
9. 데이터 유형에 따라 각 타일에 나타나는 필드를 완성합니다.
10. Config 저장을 클릭합니다.

예를 들어 팀에서 사용할 수 있는 AWS 인스턴스를 제한하는 템플릿을 만들려고 한다고 가정합니다. 템플릿 필드를 추가하기 전에 Queue Config는 다음과 유사하게 보일 수 있습니다.

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: ml.m4.xlarge
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

InstanceType에 대한 템플릿 필드를 추가하면 Config는 다음과 같이 표시됩니다.

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: "{{aws_instance}}"
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

다음으로 구성 파싱을 클릭합니다. aws-instance라는 새 타일이 Queue Config 아래에 나타납니다.

거기에서 유형 드롭다운에서 문자열을 데이터 유형으로 선택합니다. 그러면 사용자가 선택할 수 있는 값을 지정할 수 있는 필드가 채워집니다. 예를 들어 다음 이미지에서 팀의 관리자는 사용자가 선택할 수 있는 두 가지 다른 AWS 인스턴스 유형(ml.m4.xlarge 및 ml.p3.xlarge)을 구성했습니다.

Launch 작업을 동적으로 구성

Queue Config는 에이전트가 Queue에서 작업을 뺄 때 평가되는 매크로를 사용하여 동적으로 구성할 수 있습니다. 다음 매크로를 설정할 수 있습니다.

Launch 에이전트를 사용하여 가속기(GPU)에서 실행되는 이미지를 빌드합니다.

Launch를 사용하여 가속기 환경에서 실행되는 이미지를 빌드하는 경우 가속기 기본 이미지를 지정해야 할 수 있습니다.

이 가속기 기본 이미지는 다음 요구 사항을 충족해야 합니다.

• Debian 호환성(Launch Dockerfile은 apt-get을 사용하여 Python을 가져옴)
• 호환 가능한 CPU 및 GPU 하드웨어 명령어 세트(CUDA 버전이 사용하려는 GPU에서 지원되는지 확인)
• 제공하는 가속기 버전과 ML 알고리즘에 설치된 패키지 간의 호환성
• 하드웨어와의 호환성을 설정하기 위해 추가 단계가 필요한 설치된 패키지

TensorFlow와 함께 GPU를 사용하는 방법

TensorFlow가 GPU를 제대로 활용하는지 확인합니다. 이를 위해 Queue 리소스 구성에서 builder.accelerator.base_image 키에 대한 Docker 이미지와 해당 이미지 태그를 지정합니다.

예를 들어 tensorflow/tensorflow:latest-gpu 기본 이미지는 TensorFlow가 GPU를 제대로 사용하는지 확인합니다. 이는 Queue의 리소스 구성을 사용하여 구성할 수 있습니다.

다음 JSON 스니펫은 Queue Config에서 TensorFlow 기본 이미지를 지정하는 방법을 보여줍니다.

{
    "builder": {
        "accelerator": {
            "base_image": "tensorflow/tensorflow:latest-gpu"
        }
    }
}

3.2 - Set up launch agent

고급 에이전트 설정

본 가이드는 다양한 환경에서 컨테이너 이미지를 빌드하기 위해 W&B Launch 에이전트를 설정하는 방법에 대한 정보를 제공합니다.

빌더

Launch 에이전트는 Docker 또는 Kaniko를 사용하여 이미지를 빌드할 수 있습니다.

• Kaniko: 권한이 필요한 컨테이너로 빌드를 실행하지 않고 Kubernetes에서 컨테이너 이미지를 빌드합니다.
• Docker: 로컬에서 docker build 코맨드를 실행하여 컨테이너 이미지를 빌드합니다.

빌더 유형은 launch 에이전트 설정에서 builder.type 키를 docker, kaniko 또는 noop(빌드 해제)으로 설정하여 제어할 수 있습니다. 기본적으로 에이전트 helm chart는 builder.type을 noop로 설정합니다. builder 섹션의 추가 키는 빌드 프로세스를 구성하는 데 사용됩니다.

에이전트 설정에 빌더가 지정되지 않고 작동하는 docker CLI가 발견되면 에이전트는 기본적으로 Docker를 사용합니다. Docker를 사용할 수 없으면 에이전트는 기본적으로 noop를 사용합니다.

컨테이너 레지스트리에 푸시

Launch 에이전트는 빌드하는 모든 이미지에 고유한 소스 해시로 태그를 지정합니다. 에이전트는 builder.destination 키에 지정된 레지스트리에 이미지를 푸시합니다.

예를 들어, builder.destination 키가 my-registry.example.com/my-repository로 설정된 경우 에이전트는 이미지를 my-registry.example.com/my-repository:<source-hash>로 태그 지정하고 푸시합니다. 이미지가 레지스트리에 존재하면 빌드는 건너뜁니다.

에이전트 설정

Helm chart를 통해 에이전트를 배포하는 경우 에이전트 설정은 values.yaml 파일의 agentConfig 키에 제공되어야 합니다.

wandb launch-agent로 에이전트를 직접 호출하는 경우 --config 플래그를 사용하여 에이전트 설정을 YAML 파일 경로로 제공할 수 있습니다. 기본적으로 설정은 ~/.config/wandb/launch-config.yaml에서 로드됩니다.

launch 에이전트 설정(launch-config.yaml) 내에서 대상 리소스 환경의 이름과 environment 및 registry 키에 대한 컨테이너 레지스트리를 각각 제공합니다.

다음 탭은 환경 및 레지스트리를 기반으로 launch 에이전트를 구성하는 방법을 보여줍니다.

• AWS
• GCP
• Azure

environment:
  type: aws
  region: <aws-region>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 ECR 리포지토리의 URI입니다.
  # region이 환경에 구성한 region과 일치하는지 확인하십시오.
  destination: <account-id>.ecr.<aws-region>.amazonaws.com/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 S3 버킷을 지정합니다.
  build-context-store: s3://<bucket-name>/<path>

environment:
  type: gcp
  region: <gcp-region>
  project: <gcp-project-id>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Artifact Registry 리포지토리 및 이미지 이름의 URI입니다.
  # region 및 프로젝트가 환경에 구성한 것과 일치하는지 확인하십시오.
  uri: <region>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 GCS 버킷을 지정합니다.
  build-context-store: gs://<bucket-name>/<path>

environment:
  type: azure
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Azure Container Registry 리포지토리의 URI입니다.
  destination: https://<registry-name>.azurecr.io/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 Azure Blob Storage 컨테이너를 지정합니다.
  build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>

에이전트 권한

필요한 에이전트 권한은 유스 케이스에 따라 다릅니다.

클라우드 레지스트리 권한

다음은 클라우드 레지스트리와 상호 작용하기 위해 launch 에이전트에서 일반적으로 요구하는 권한입니다.

• AWS
• GCP
• Azure

{
  'Version': '2012-10-17',
  'Statement':
    [
      {
        'Effect': 'Allow',
        'Action':
          [
            'ecr:CreateRepository',
            'ecr:UploadLayerPart',
            'ecr:PutImage',
            'ecr:CompleteLayerUpload',
            'ecr:InitiateLayerUpload',
            'ecr:DescribeRepositories',
            'ecr:DescribeImages',
            'ecr:BatchCheckLayerAvailability',
            'ecr:BatchDeleteImage',
          ],
        'Resource': 'arn:aws:ecr:<region>:<account-id>:repository/<repository>',
      },
      {
        'Effect': 'Allow',
        'Action': 'ecr:GetAuthorizationToken',
        'Resource': '*',
      },
    ],
}

artifactregistry.dockerimages.list;
artifactregistry.repositories.downloadArtifacts;
artifactregistry.repositories.list;
artifactregistry.repositories.uploadArtifacts;

Kaniko의 스토리지 권한

에이전트가 Kaniko 빌더를 사용하는 경우 launch 에이전트는 클라우드 스토리지에 푸시할 수 있는 권한이 필요합니다. Kaniko는 빌드 job을 실행하는 pod 외부의 컨텍스트 저장소를 사용합니다.

• AWS
• GCP
• Azure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListObjectsInBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>"]
    },
    {
      "Sid": "AllObjectActions",
      "Effect": "Allow",
      "Action": "s3:*Object",
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>/*"]
    }
  ]
}

storage.buckets.get;
storage.objects.create;
storage.objects.delete;
storage.objects.get;

Kaniko 빌드 사용자 정의

에이전트 설정의 builder.kaniko-config 키에서 Kaniko job이 사용하는 Kubernetes Job 사양을 지정합니다. 예:

builder:
  type: kaniko
  build-context-store: <my-build-context-store>
  destination: <my-image-destination>
  build-job-name: wandb-image-build
  kaniko-config:
    spec:
      template:
        spec:
          containers:
          - args:
            - "--cache=false" # Args must be in the format "key=value"
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"

CoreWeave에 Launch 에이전트 배포

선택적으로 W&B Launch 에이전트를 CoreWeave Cloud 인프라에 배포합니다. CoreWeave는 GPU 가속 워크로드를 위해 특별히 구축된 클라우드 인프라입니다.

Launch 에이전트를 CoreWeave에 배포하는 방법에 대한 자세한 내용은 CoreWeave 설명서를 참조하세요.

3.3 - Tutorial: Set up W&B Launch on Kubernetes

W&B Launch 를 사용하여 ML 워크로드를 Kubernetes 클러스터로 푸시할 수 있습니다. 이를 통해 ML 엔지니어는 Kubernetes로 이미 관리하고 있는 리소스를 사용할 수 있는 간단한 인터페이스를 W&B 내에서 바로 이용할 수 있습니다.

W&B는 W&B가 관리하는 공식 Launch agent 이미지를 유지 관리하며, 이는 Helm chart를 통해 클러스터에 배포할 수 있습니다.

W&B는 Kaniko 빌더를 사용하여 Launch agent가 Kubernetes 클러스터에서 Docker 이미지를 빌드할 수 있도록 합니다. Launch agent용 Kaniko 설정 방법 또는 작업 빌드를 끄고 미리 빌드된 Docker 이미지만 사용하는 방법에 대한 자세한 내용은 고급 agent 설정을 참조하십시오.

Kubernetes용 대기열 설정

Kubernetes 대상 리소스에 대한 Launch 대기열 설정은 Kubernetes Job spec 또는 Kubernetes Custom Resource spec과 유사합니다.

Launch 대기열을 만들 때 Kubernetes 워크로드 리소스 spec의 모든 측면을 제어할 수 있습니다.

• Kubernetes job spec
• Custom resource spec

spec:
  template:
    spec:
      containers:
        - env:
            - name: MY_ENV_VAR
              value: some-value
          resources:
            requests:
              cpu: 1000m
              memory: 1Gi
metadata:
  labels:
    queue: k8s-test
namespace: wandb

kubernetes:
  kind: PyTorchJob
  spec:
    pytorchReplicaSpecs:
      Master:
        replicas: 1
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
      Worker:
        replicas: 2
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
    ttlSecondsAfterFinished: 600
  metadata:
    name: '${run_id}-pytorch-job'
  apiVersion: kubeflow.org/v1

보안상의 이유로 W&B는 지정되지 않은 경우 다음 리소스를 Launch 대기열에 삽입합니다.

• securityContext
• backOffLimit
• ttlSecondsAfterFinished

다음 YAML 스니펫은 이러한 값들이 Launch 대기열에 어떻게 나타나는지 보여줍니다.

spec:
  template:
    `backOffLimit`: 0
    ttlSecondsAfterFinished: 60
    securityContext:
      allowPrivilegeEscalation: False,
      capabilities:
        drop:
          - ALL,
      seccompProfile:
        type: "RuntimeDefault"

대기열 만들기

Kubernetes를 컴퓨팅 리소스로 사용하는 W&B App에서 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. 대기열 만들기 버튼을 클릭합니다.
3. 대기열을 만들려는 Entities를 선택합니다.
4. 이름 필드에 대기열 이름을 입력합니다.
5. 리소스로 Kubernetes를 선택합니다.
6. 설정 필드 내에서 이전 섹션에서 구성한 Kubernetes Job 워크플로우 spec 또는 Custom Resource spec을 제공합니다.

Helm으로 Launch agent 구성

W&B에서 제공하는 Helm chart를 사용하여 Launch agent를 Kubernetes 클러스터에 배포합니다. values.yaml 파일로 Launch agent의 행동을 제어합니다.

Launch agent 구성 파일(~/.config/wandb/launch-config.yaml)에 일반적으로 정의되는 내용을 values.yaml 파일의 launchConfig 키 내에 지정합니다.

예를 들어, Kaniko Docker 이미지 빌더를 사용하는 EKS에서 Launch agent를 실행할 수 있도록 하는 Launch agent 구성이 있다고 가정합니다.

queues:
	- <queue name>
max_jobs: <n concurrent jobs>
environment:
	type: aws
	region: us-east-1
registry:
	type: ecr
	uri: <my-registry-uri>
builder:
	type: kaniko
	build-context-store: <s3-bucket-uri>

values.yaml 파일 내에서 다음과 같이 보일 수 있습니다.

agent:
  labels: {}
  # W&B API 키.
  apiKey: ''
  # agent에 사용할 컨테이너 이미지.
  image: wandb/launch-agent:latest
  # agent 이미지에 대한 이미지 풀 정책.
  imagePullPolicy: Always
  # agent spec에 대한 리소스 블록.
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# Launch agent를 배포할 네임스페이스
namespace: wandb

# W&B api URL (여기에 설정하십시오)
baseUrl: https://api.wandb.ai

# Launch agent가 배포할 수 있는 추가 대상 네임스페이스
additionalTargetNamespaces:
  - default
  - wandb

# 이것은 Launch agent 구성의 리터럴 내용으로 설정해야 합니다.
launchConfig: |
  queues:
    - <queue name>
  max_jobs: <n concurrent jobs>
  environment:
    type: aws
    region: <aws-region>
  registry:
    type: ecr
    uri: <my-registry-uri>
  builder:
    type: kaniko
    build-context-store: <s3-bucket-uri>  

# git 자격 증명 파일의 내용. 이것은 k8s secret에 저장됩니다
# agent 컨테이너에 마운트됩니다. 비공개 리포를 복제하려면 이것을 설정하십시오.
gitCreds: |

# wandb 서비스 계정에 대한 어노테이션. gcp에서 워크로드 아이덴티티를 설정할 때 유용합니다.
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# azure와 함께 kaniko를 사용하는 경우 azure 스토리지에 대한 엑세스 키로 설정합니다.
azureStorageAccessKey: ''

레지스트리, 환경 및 필요한 agent 권한에 대한 자세한 내용은 고급 agent 설정을 참조하십시오.

3.4 - Tutorial: Set up W&B Launch on SageMaker

W&B Launch 를 사용하여 제공된 또는 사용자 지정 알고리즘을 사용하여 Amazon SageMaker 에 launch 작업을 제출하여 SageMaker 플랫폼에서 기계 학습 모델을 트레이닝할 수 있습니다. SageMaker 는 컴퓨팅 리소스를 가동 및 해제하는 작업을 처리하므로 EKS 클러스터가 없는 팀에게 적합한 선택이 될 수 있습니다.

Amazon SageMaker 에 연결된 W&B Launch 대기열로 전송된 Launch 작업은 CreateTrainingJob API를 통해 SageMaker 트레이닝 작업으로 실행됩니다. launch 대기열 설정을 사용하여 CreateTrainingJob API 로 전송되는 인수를 제어합니다.

Amazon SageMaker 는 Docker 이미지를 사용하여 트레이닝 작업을 실행합니다. SageMaker 가 가져오는 이미지는 Amazon Elastic Container Registry (ECR)에 저장해야 합니다. 즉, 트레이닝에 사용하는 이미지는 ECR 에 저장해야 합니다.

전제 조건

시작하기 전에 다음 전제 조건을 충족하는지 확인하십시오.

• Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정합니다.
• AWS 리소스를 설정하고 S3, ECR 및 Sagemaker IAM 역할에 대한 정보를 수집합니다.
• Launch 에이전트에 대한 IAM 역할을 만듭니다.

Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정

W&B Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정합니다. 다음 두 가지 옵션 중에서 선택할 수 있습니다.

• Launch 에이전트가 Docker 이미지를 빌드하고, 이미지를 Amazon ECR 에 푸시하고, 사용자를 위해 SageMaker 트레이닝 작업을 제출하도록 허용합니다. 이 옵션은 ML 엔지니어가 트레이닝 코드를 빠르게 반복하는 데 약간의 단순성을 제공할 수 있습니다.
• Launch 에이전트는 트레이닝 또는 추론 스크립트가 포함된 기존 Docker 이미지를 사용합니다. 이 옵션은 기존 CI 시스템과 잘 작동합니다. 이 옵션을 선택하는 경우 Docker 이미지를 Amazon ECR 의 컨테이너 레지스트리에 수동으로 업로드해야 합니다.

AWS 리소스 설정

선호하는 AWS 리전에서 다음 AWS 리소스가 구성되어 있는지 확인합니다.

1. 컨테이너 이미지를 저장할 ECR 레포지토리.
2. SageMaker 트레이닝 작업에 대한 입력 및 출력을 저장할 하나 이상의 S3 버킷.
3. SageMaker 가 트레이닝 작업을 실행하고 Amazon ECR 및 Amazon S3 와 상호 작용할 수 있도록 허용하는 Amazon SageMaker 에 대한 IAM 역할.

이러한 리소스에 대한 ARN 을 기록해 두십시오. Launch 대기열 설정을 정의할 때 ARN 이 필요합니다.

Launch 에이전트에 대한 IAM 정책 만들기

1. AWS 의 IAM 화면에서 새 정책을 만듭니다.
2. JSON 정책 편집기로 전환한 다음 사용 사례에 따라 다음 정책을 붙여넣습니다. <> 로 묶인 값을 자신의 값으로 대체합니다.

• 에이전트가 미리 빌드된 Docker 이미지 제출
• 에이전트가 Docker 이미지를 빌드하고 제출

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
     {
    "Effect": "Allow",
    "Action": [
      "ecr:CreateRepository",
      "ecr:UploadLayerPart",
      "ecr:PutImage",
      "ecr:CompleteLayerUpload",
      "ecr:InitiateLayerUpload",
      "ecr:DescribeRepositories",
      "ecr:DescribeImages",
      "ecr:BatchCheckLayerAvailability",
      "ecr:BatchDeleteImage"
    ],
    "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<repository>"
  },
  {
    "Effect": "Allow",
    "Action": "ecr:GetAuthorizationToken",
    "Resource": "*"
  },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

3. 다음을 클릭합니다.
4. 정책에 이름과 설명을 지정합니다.
5. 정책 생성을 클릭합니다.

Launch 에이전트에 대한 IAM 역할 만들기

Launch 에이전트는 Amazon SageMaker 트레이닝 작업을 생성할 수 있는 권한이 필요합니다. 아래 절차에 따라 IAM 역할을 만듭니다.

1. AWS 의 IAM 화면에서 새 역할을 만듭니다.
2. 신뢰할 수 있는 엔터티의 경우 AWS 계정(또는 조직의 정책에 적합한 다른 옵션)을 선택합니다.
3. 권한 화면을 스크롤하여 위에서 방금 만든 정책 이름을 선택합니다.
4. 역할에 이름과 설명을 지정합니다.
5. 역할 생성을 선택합니다.
6. 역할에 대한 ARN 을 기록해 둡니다. launch 에이전트를 설정할 때 ARN 을 지정합니다.

IAM 역할을 만드는 방법에 대한 자세한 내용은 AWS Identity and Access Management 설명서를 참조하십시오.

SageMaker 에 대한 Launch 대기열 구성

다음으로 SageMaker 를 컴퓨팅 리소스로 사용하는 W&B App 에서 대기열을 만듭니다.

1. Launch App으로 이동합니다.
2. 대기열 생성 버튼을 클릭합니다.
3. 대기열을 만들려는 Entities를 선택합니다.
4. 이름 필드에 대기열 이름을 제공합니다.
5. 리소스로 SageMaker 를 선택합니다.
6. 설정 필드 내에서 SageMaker 작업에 대한 정보를 제공합니다. 기본적으로 W&B 는 YAML 및 JSON CreateTrainingJob 요청 본문을 채웁니다.

{
  "RoleArn": "<REQUIRED>", 
  "ResourceConfig": {
      "InstanceType": "ml.m4.xlarge",
      "InstanceCount": 1,
      "VolumeSizeInGB": 2
  },
  "OutputDataConfig": {
      "S3OutputPath": "<REQUIRED>"
  },
  "StoppingCondition": {
      "MaxRuntimeInSeconds": 3600
  }
}

최소한 다음을 지정해야 합니다.

• RoleArn: SageMaker 실행 IAM 역할의 ARN ( 전제 조건 참조). launch 에이전트 IAM 역할과 혼동하지 마십시오.
• OutputDataConfig.S3OutputPath: SageMaker 출력이 저장될 Amazon S3 URI.
• ResourceConfig: 리소스 구성에 대한 필수 사양입니다. 리소스 구성에 대한 옵션은 여기에 설명되어 있습니다.
• StoppingCondition: 트레이닝 작업에 대한 중지 조건에 대한 필수 사양입니다. 옵션은 여기에 설명되어 있습니다.

7. 대기열 생성 버튼을 클릭합니다.

Launch 에이전트 설정

다음 섹션에서는 에이전트를 배포할 수 있는 위치와 배포 위치에 따라 에이전트를 구성하는 방법을 설명합니다.

Amazon SageMaker 에 대해 Launch 에이전트를 배포하는 방법에 대한 몇 가지 옵션이 있습니다. 대기열: 로컬 시스템, EC2 인스턴스 또는 EKS 클러스터에서. 에이전트를 배포하는 위치에 따라 Launch 에이전트를 적절하게 구성합니다.

Launch 에이전트를 실행할 위치 결정

프로덕션 워크로드 및 이미 EKS 클러스터가 있는 고객의 경우 W&B 는 이 Helm 차트를 사용하여 Launch 에이전트를 EKS 클러스터에 배포하는 것이 좋습니다.

현재 EKS 클러스터가 없는 프로덕션 워크로드의 경우 EC2 인스턴스가 좋은 옵션입니다. launch 에이전트 인스턴스가 항상 실행되지만 에이전트는 상대적으로 저렴한 t2.micro 크기의 EC2 인스턴스 이상이 필요하지 않습니다.

실험적 또는 단독 사용 사례의 경우 로컬 시스템에서 Launch 에이전트를 실행하는 것이 시작하는 빠른 방법이 될 수 있습니다.

사용 사례에 따라 다음 탭에 제공된 지침에 따라 Launch 에이전트를 올바르게 구성합니다.

• EKS
• EC2
• 로컬 시스템

sudo yum install python311 -y && python3 -m ensurepip --upgrade && pip3 install wandb && pip3 install wandb[launch]

sudo yum update -y && sudo yum install -y docker python3 && sudo systemctl start docker && sudo systemctl enable docker && sudo usermod -a -G docker ec2-user

newgrp docker

[profile SageMaker-agent]
role_arn = arn:aws:iam::<account-id>:role/<agent-role-name>
source_profile = default                                                                   

[default]
aws_access_key_id=<access-key-id>
aws_secret_access_key=<secret-access-key>
aws_session_token=<session-token>

Launch 에이전트 구성

launch-config.yaml 이라는 YAML 구성 파일로 launch 에이전트를 구성합니다.

기본적으로 W&B 는 ~/.config/wandb/launch-config.yaml 에서 구성 파일을 확인합니다. -c 플래그로 launch 에이전트를 활성화할 때 선택적으로 다른 디렉토리를 지정할 수 있습니다.

다음 YAML 스니펫은 핵심 구성 에이전트 옵션을 지정하는 방법을 보여줍니다.

max_jobs: -1
queues:
  - <queue-name>
environment:
  type: aws
  region: <your-region>
registry:
  type: ecr
  uri: <ecr-repo-arn>
builder: 
  type: docker

이제 wandb launch-agent 로 에이전트를 시작합니다.

(선택 사항) Launch 작업 Docker 이미지를 Amazon ECR 로 푸시

launch 작업이 포함된 Docker 이미지를 Amazon ECR 레포지토리로 업로드합니다. 이미지 기반 작업을 사용하는 경우 새 launch 작업을 제출하기 전에 Docker 이미지가 ECR 레지스트리에 있어야 합니다.

3.5 - Tutorial: Set up W&B Launch on Vertex AI

W&B Launch 를 사용하여 Vertex AI 트레이닝 작업으로 실행하기 위한 작업을 제출할 수 있습니다. Vertex AI 트레이닝 작업을 통해 Vertex AI 플랫폼에서 제공되거나 사용자 정의된 알고리즘을 사용하여 기계학습 모델을 트레이닝할 수 있습니다. Launch 작업이 시작되면 Vertex AI는 기본 인프라, 확장 및 오케스트레이션을 관리합니다.

W&B Launch 는 google-cloud-aiplatform SDK의 CustomJob 클래스를 통해 Vertex AI와 연동됩니다. CustomJob 의 파라미터는 Launch 대기열 설정으로 제어할 수 있습니다. Vertex AI는 GCP 외부의 개인 레지스트리에서 이미지를 가져오도록 구성할 수 없습니다. 즉, W&B Launch 와 함께 Vertex AI를 사용하려면 컨테이너 이미지를 GCP 또는 공용 레지스트리에 저장해야 합니다. Vertex 작업에 컨테이너 이미지를 엑세스할 수 있도록 설정하는 방법에 대한 자세한 내용은 Vertex AI 설명서를 참조하십시오.

전제 조건

1. Vertex AI API가 활성화된 GCP 프로젝트를 만들거나 엑세스합니다. API 활성화에 대한 자세한 내용은 GCP API Console 문서를 참조하십시오.
2. Vertex에서 실행하려는 이미지를 저장할 GCP Artifact Registry 저장소를 만듭니다. 자세한 내용은 GCP Artifact Registry 문서를 참조하십시오.
3. Vertex AI가 메타데이터를 저장할 스테이징 GCS 버킷을 만듭니다. 이 버킷은 스테이징 버킷으로 사용하려면 Vertex AI 워크로드와 동일한 리전에 있어야 합니다. 동일한 버킷을 스테이징 및 빌드 컨텍스트에 사용할 수 있습니다.
4. Vertex AI 작업을 시작하는 데 필요한 권한이 있는 서비스 계정을 만듭니다. 서비스 계정에 권한을 할당하는 방법에 대한 자세한 내용은 GCP IAM 문서를 참조하십시오.
5. Vertex 작업을 관리할 수 있는 권한을 서비스 계정에 부여합니다.

Vertex AI에 대한 대기열 구성

Vertex AI 리소스에 대한 대기열 구성은 Vertex AI Python SDK의 CustomJob 생성자와 CustomJob 의 run 메소드에 대한 입력을 지정합니다. 리소스 구성은 spec 및 run 키 아래에 저장됩니다.

• spec 키에는 Vertex AI Python SDK의 CustomJob 생성자의 명명된 인수에 대한 값이 포함되어 있습니다.
• run 키에는 Vertex AI Python SDK의 CustomJob 클래스의 run 메소드의 명명된 인수에 대한 값이 포함되어 있습니다.

실행 환경의 사용자 정의는 주로 spec.worker_pool_specs 목록에서 발생합니다. 작업자 풀 사양은 작업을 실행할 작업자 그룹을 정의합니다. 기본 구성의 작업자 사양은 가속기가 없는 단일 n1-standard-4 머신을 요청합니다. 필요에 따라 머신 유형, 가속기 유형 및 수를 변경할 수 있습니다.

사용 가능한 머신 유형 및 가속기 유형에 대한 자세한 내용은 Vertex AI 설명서를 참조하십시오.

대기열 만들기

Vertex AI를 컴퓨팅 리소스로 사용하는 W&B App 에서 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. 대기열 만들기 버튼을 클릭합니다.
3. 대기열을 만들려는 Entity 를 선택합니다.
4. 이름 필드에 대기열 이름을 입력합니다.
5. 리소스 로 GCP Vertex 를 선택합니다.
6. 설정 필드 내에서 이전 섹션에서 정의한 Vertex AI CustomJob 에 대한 정보를 제공합니다. 기본적으로 W&B는 다음과 유사한 YAML 및 JSON 요청 본문을 채웁니다.

spec:
  worker_pool_specs:
    - machine_spec:
        machine_type: n1-standard-4
        accelerator_type: ACCELERATOR_TYPE_UNSPECIFIED
        accelerator_count: 0
      replica_count: 1
      container_spec:
        image_uri: ${image_uri}
  staging_bucket: <REQUIRED>
run:
  restart_job_on_worker_restart: false

7. 대기열을 구성한 후 대기열 만들기 버튼을 클릭합니다.

최소한 다음을 지정해야 합니다.

• spec.worker_pool_specs : 비어 있지 않은 작업자 풀 사양 목록
• spec.staging_bucket : Vertex AI 자산 및 메타데이터를 스테이징하는 데 사용될 GCS 버킷

Launch 에이전트 구성

Launch 에이전트는 기본적으로 ~/.config/wandb/launch-config.yaml 에 있는 구성 파일을 통해 구성할 수 있습니다.

max_jobs: <n-concurrent-jobs>
queues:
  - <queue-name>

Launch 에이전트가 Vertex AI에서 실행되는 이미지를 빌드하도록 하려면 고급 에이전트 설정을 참조하십시오.

에이전트 권한 설정

이 서비스 계정으로 인증하는 방법은 여러 가지가 있습니다. 이는 Workload Identity, 다운로드된 서비스 계정 JSON, 환경 변수, Google Cloud Platform 코맨드라인 툴 또는 이러한 방법의 조합을 통해 수행할 수 있습니다.

3.6 - Tutorial: Set up W&B Launch with Docker

다음 가이드는 로컬 장치에서 Docker를 사용하도록 W&B Launch를 구성하여 Launch 에이전트 환경과 대기열의 대상 리소스 모두에 대해 설명합니다.

Docker를 사용하여 작업을 실행하고 동일한 로컬 장치에서 Launch 에이전트의 환경으로 사용하는 것은 컴퓨팅이 Kubernetes와 같은 클러스터 관리 시스템이 없는 장치에 설치된 경우에 특히 유용합니다.

Docker 대기열을 사용하여 강력한 워크스테이션에서 워크로드를 실행할 수도 있습니다.

W&B Launch와 함께 Docker를 사용하면 W&B는 먼저 이미지를 빌드한 다음 해당 이미지에서 컨테이너를 빌드하고 실행합니다. 이미지는 Docker docker run <image-uri> 코맨드로 빌드됩니다. 대기열 설정은 docker run 코맨드에 전달되는 추가 인수로 해석됩니다.

Docker 대기열 구성

Launch 대기열 설정(Docker 대상 리소스의 경우)은 docker run CLI 코맨드에 정의된 것과 동일한 옵션을 허용합니다.

에이전트는 대기열 설정에 정의된 옵션을 수신합니다. 그런 다음 에이전트는 수신된 옵션을 Launch 작업의 설정에서 가져온 재정의와 병합하여 대상 리소스(이 경우 로컬 장치)에서 실행되는 최종 docker run 코맨드를 생성합니다.

다음과 같은 두 가지 구문 변환이 수행됩니다.

1. 반복되는 옵션은 대기열 설정에 목록으로 정의됩니다.
2. 플래그 옵션은 대기열 설정에 값 true가 있는 부울로 정의됩니다.

예를 들어, 다음 대기열 설정은 다음과 같습니다.

{
  "env": ["MY_ENV_VAR=value", "MY_EXISTING_ENV_VAR"],
  "volume": "/mnt/datasets:/mnt/datasets",
  "rm": true,
  "gpus": "all"
}

다음과 같은 docker run 코맨드가 생성됩니다.

docker run \
  --env MY_ENV_VAR=value \
  --env MY_EXISTING_ENV_VAR \
  --volume "/mnt/datasets:/mnt/datasets" \
  --rm <image-uri> \
  --gpus all

볼륨은 문자열 목록 또는 단일 문자열로 지정할 수 있습니다. 여러 볼륨을 지정하는 경우 목록을 사용하세요.

Docker는 값이 할당되지 않은 환경 변수를 Launch 에이전트 환경에서 자동으로 전달합니다. 즉, Launch 에이전트에 환경 변수 MY_EXISTING_ENV_VAR가 있는 경우 해당 환경 변수를 컨테이너에서 사용할 수 있습니다. 이는 대기열 설정에서 게시하지 않고 다른 구성 키를 사용하려는 경우에 유용합니다.

docker run 코맨드의 --gpus 플래그를 사용하면 Docker 컨테이너에서 사용할 수 있는 GPU를 지정할 수 있습니다. gpus 플래그를 사용하는 방법에 대한 자세한 내용은 Docker 설명서를 참조하세요.

대기열 생성

W&B CLI를 사용하여 Docker를 컴퓨팅 리소스로 사용하는 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. Create Queue 버튼을 클릭합니다.
3. 대기열을 만들려는 Entity를 선택합니다.
4. Name 필드에 대기열 이름을 입력합니다.
5. Resource로 Docker를 선택합니다.
6. Configuration 필드에 Docker 대기열 설정을 정의합니다.
7. Create Queue 버튼을 클릭하여 대기열을 만듭니다.

로컬 장치에서 Launch 에이전트 구성

launch-config.yaml이라는 YAML 구성 파일로 Launch 에이전트를 구성합니다. 기본적으로 W&B는 ~/.config/wandb/launch-config.yaml에서 구성 파일을 확인합니다. Launch 에이전트를 활성화할 때 다른 디렉토리를 선택적으로 지정할 수 있습니다.

핵심 에이전트 구성 옵션

다음 탭은 W&B CLI와 YAML 구성 파일로 핵심 구성 에이전트 옵션을 지정하는 방법을 보여줍니다.

• W&B CLI
• Config file

wandb launch-agent -q <queue-name> --max-jobs <n>

max_jobs: <n concurrent jobs>
queues:
	- <queue-name>

Docker 이미지 빌더

장치의 Launch 에이전트를 구성하여 Docker 이미지를 빌드할 수 있습니다. 기본적으로 이러한 이미지는 장치의 로컬 이미지 리포지토리에 저장됩니다. Launch 에이전트가 Docker 이미지를 빌드할 수 있도록 하려면 Launch 에이전트 구성에서 builder 키를 docker로 설정합니다.

builder:
	type: docker

에이전트가 Docker 이미지를 빌드하지 않고 레지스트리에서 미리 빌드된 이미지를 대신 사용하려면 Launch 에이전트 구성에서 builder 키를 noop로 설정합니다.

builder:
  type: noop

컨테이너 레지스트리

Launch는 Dockerhub, Google Container Registry, Azure Container Registry 및 Amazon ECR과 같은 외부 컨테이너 레지스트리를 사용합니다. 빌드한 환경과 다른 환경에서 작업을 실행하려면 컨테이너 레지스트리에서 풀할 수 있도록 에이전트를 구성합니다.

Launch 에이전트를 클라우드 레지스트리에 연결하는 방법에 대한 자세한 내용은 고급 에이전트 설정 페이지를 참조하세요.

4 - Create and deploy jobs

4.1 - Add job to queue

다음 페이지에서는 launch queue에 launch job을 추가하는 방법을 설명합니다.

queue에 job 추가

W&B App을 사용하여 대화형으로 또는 W&B CLI를 사용하여 프로그래밍 방식으로 queue에 job을 추가합니다.

• W&B app
• W&B CLI

{
  "overrides": {
      "args": [],
      "run_config": {
          "learning_rate": 0,
          "epochs": 0
      },   
      "entry_point": []
  }
}

{
  "overrides": {
      "args": [],
      "run_config": {
          "learning_rate": 0,
          "epochs": 0
      },
      "entry_point": []
  },
  "resource_args": {
        "<resource-type>" : {
            "<key>": "<value>"
        }
  }
}

wandb launch -j <job> -q <queue-name> \ 
-e <entity-name> -c path/to/config.json

4.2 - Create a launch job

Launch 작업은 W&B run을 재현하기 위한 청사진입니다. 작업은 워크로드를 실행하는 데 필요한 소스 코드, 종속성 및 입력을 캡처하는 W&B Artifacts입니다.

wandb launch 코맨드를 사용하여 작업을 생성하고 실행하세요.

Git 작업

W&B Launch를 사용하여 원격 git 저장소의 특정 커밋, 브랜치 또는 태그에서 코드 및 기타 추적된 자산을 복제하는 Git 기반 작업을 만들 수 있습니다. 코드 URI를 지정하려면 --uri 또는 -u 플래그를 사용하고, 하위 디렉토리를 지정하려면 선택적으로 --build-context 플래그를 사용하세요.

다음 코맨드를 사용하여 git 저장소에서 “hello world” 작업을 실행합니다.

wandb launch --uri "https://github.com/wandb/launch-jobs.git" --build-context jobs/hello_world --dockerfile Dockerfile.wandb --project "hello-world" --job-name "hello-world" --entry-point "python job.py"

이 코맨드는 다음을 수행합니다.

1. W&B Launch 작업 저장소를 임시 디렉토리에 복제합니다.
2. hello 프로젝트에 hello-world-git이라는 작업을 만듭니다. 이 작업은 저장소의 기본 브랜치 헤드에 있는 커밋과 연결됩니다.
3. jobs/hello_world 디렉토리와 Dockerfile.wandb에서 컨테이너 이미지를 빌드합니다.
4. 컨테이너를 시작하고 python job.py를 실행합니다.

특정 브랜치 또는 커밋 해시에서 작업을 빌드하려면 -g, --git-hash 인수를 추가하세요. 전체 인수 목록을 보려면 wandb launch --help를 실행하세요.

원격 URL 형식

Launch 작업과 연결된 git 원격은 HTTPS 또는 SSH URL일 수 있습니다. URL 유형은 작업 소스 코드를 가져오는 데 사용되는 프로토콜을 결정합니다.

정확한 URL 형식은 호스팅 공급자에 따라 다릅니다. wandb launch --uri로 생성된 작업은 제공된 --uri에 지정된 전송 프로토콜을 사용합니다.

코드 Artifact 작업

W&B Artifact에 저장된 소스 코드에서 작업을 만들 수 있습니다. --uri 또는 -u 인수로 로컬 디렉토리를 사용하여 새 코드 아티팩트 및 작업을 만드세요.

시작하려면 빈 디렉토리를 만들고 다음 내용으로 main.py라는 Python 스크립트를 추가합니다.

import wandb

with wandb.init() as run:
    run.log({"metric": 0.5})

다음 내용으로 requirements.txt 파일을 추가합니다.

wandb>=0.17.1

다음 코맨드를 사용하여 디렉토리를 코드 Artifact로 기록하고 작업을 시작합니다.

wandb launch --uri . --job-name hello-world-code --project launch-quickstart --entry-point "python main.py"

위의 코맨드는 다음을 수행합니다.

1. 현재 디렉토리를 hello-world-code라는 코드 Artifact로 기록합니다.
2. launch-quickstart 프로젝트에 hello-world-code라는 작업을 만듭니다.
3. 현재 디렉토리와 Launch의 기본 Dockerfile에서 컨테이너 이미지를 빌드합니다. 기본 Dockerfile은 requirements.txt 파일을 설치하고 진입점을 python main.py로 설정합니다.

이미지 작업

또는 미리 만들어진 Docker 이미지에서 작업을 빌드할 수 있습니다. 이는 ML 코드에 대한 기존 빌드 시스템이 이미 있거나 작업에 대한 코드 또는 요구 사항을 조정할 필요는 없지만 하이퍼파라미터 또는 다른 인프라 규모를 실험하려는 경우에 유용합니다.

이미지는 Docker 레지스트리에서 가져와서 지정된 진입점 또는 지정되지 않은 경우 기본 진입점으로 실행됩니다. --docker-image 옵션에 전체 이미지 태그를 전달하여 Docker 이미지에서 작업을 생성하고 실행합니다.

미리 만들어진 이미지에서 간단한 작업을 실행하려면 다음 코맨드를 사용하세요.

wandb launch --docker-image "wandb/job_hello_world:main" --project "hello-world"           

자동 작업 생성

W&B는 추적된 소스 코드가 있는 모든 run에 대해 Launch로 생성되지 않은 경우에도 작업을 자동으로 생성하고 추적합니다. run은 다음 세 가지 조건 중 하나라도 충족되면 추적된 소스 코드가 있는 것으로 간주됩니다.

• run에 연결된 git 원격 및 커밋 해시가 있습니다.
• run이 코드 Artifact를 기록했습니다(자세한 내용은 Run.log_code 참조).
• run이 WANDB_DOCKER 환경 변수가 이미지 태그로 설정된 Docker 컨테이너에서 실행되었습니다.

Launch 작업이 W&B run에 의해 자동으로 생성되는 경우 Git 원격 URL은 로컬 git 저장소에서 유추됩니다.

Launch 작업 이름

기본적으로 W&B는 자동으로 작업 이름을 생성합니다. 이름은 작업이 생성된 방식(GitHub, 코드 Artifact 또는 Docker 이미지)에 따라 생성됩니다. 또는 환경 변수 또는 W&B Python SDK를 사용하여 Launch 작업의 이름을 정의할 수 있습니다.

다음 표는 작업 소스를 기반으로 기본적으로 사용되는 작업 명명 규칙을 설명합니다.

W&B 환경 변수 또는 W&B Python SDK로 작업 이름을 지정하세요.

• Environment variable
• W&B Python SDK

WANDB_JOB_NAME=awesome-job-name

settings = wandb.Settings(job_name="my-job-name")
wandb.init(settings=settings)

컨테이너화

작업은 컨테이너에서 실행됩니다. 이미지 작업은 미리 빌드된 Docker 이미지를 사용하는 반면 Git 및 코드 Artifact 작업에는 컨테이너 빌드 단계가 필요합니다.

작업 컨테이너화는 wandb launch에 대한 인수와 작업 소스 코드 내의 파일로 사용자 정의할 수 있습니다.

빌드 컨텍스트

빌드 컨텍스트라는 용어는 컨테이너 이미지를 빌드하기 위해 Docker 데몬으로 전송되는 파일 및 디렉토리 트리를 나타냅니다. 기본적으로 Launch는 작업 소스 코드의 루트를 빌드 컨텍스트로 사용합니다. 하위 디렉토리를 빌드 컨텍스트로 지정하려면 작업을 생성하고 시작할 때 wandb launch의 --build-context 인수를 사용하세요.

Dockerfile

Dockerfile은 Docker 이미지를 빌드하기 위한 지침이 포함된 텍스트 파일입니다. 기본적으로 Launch는 requirements.txt 파일을 설치하는 기본 Dockerfile을 사용합니다. 사용자 정의 Dockerfile을 사용하려면 wandb launch의 --dockerfile 인수로 파일 경로를 지정하세요.

Dockerfile 경로는 빌드 컨텍스트를 기준으로 지정됩니다. 예를 들어 빌드 컨텍스트가 jobs/hello_world이고 Dockerfile이 jobs/hello_world 디렉토리에 있는 경우 --dockerfile 인수를 Dockerfile.wandb로 설정해야 합니다. 공식 W&B Launch 작업 저장소와 함께 --dockerfile 인수를 사용하는 방법에 대한 데모는 위의 예를 참조하세요.

Requirements 파일

사용자 정의 Dockerfile이 제공되지 않은 경우 Launch는 설치할 Python 종속성에 대한 빌드 컨텍스트를 찾습니다. requirements.txt 파일이 빌드 컨텍스트의 루트에 있는 경우 Launch는 파일에 나열된 종속성을 설치합니다. 그렇지 않고 pyproject.toml 파일이 발견되면 Launch는 project.dependencies 섹션에서 종속성을 설치합니다.

4.3 - Manage job inputs

Launch의 핵심 경험은 하이퍼파라미터 및 데이터셋과 같은 다양한 작업 입력을 쉽게 실험하고 이러한 작업을 적절한 하드웨어로 라우팅하는 것입니다. 작업이 생성되면 원래 작성자 이외의 사용자도 W&B GUI 또는 CLI를 통해 이러한 입력을 조정할 수 있습니다. CLI 또는 UI에서 Launch할 때 작업 입력을 설정하는 방법에 대한 자세한 내용은 작업 대기열에 추가 가이드를 참조하세요.

이 섹션에서는 작업을 위해 조정할 수 있는 입력을 프로그래밍 방식으로 제어하는 방법에 대해 설명합니다.

기본적으로 W&B 작업은 전체 Run.config를 작업에 대한 입력으로 캡처하지만 Launch SDK는 run config에서 선택한 키를 제어하거나 JSON 또는 YAML 파일을 입력으로 지정하는 기능을 제공합니다.

Run 오브젝트 재구성

작업에서 wandb.init에 의해 반환된 Run 오브젝트는 기본적으로 재구성할 수 있습니다. Launch SDK는 작업을 시작할 때 Run.config 오브젝트의 어떤 부분을 재구성할 수 있는지 사용자 정의하는 방법을 제공합니다.

import wandb
from wandb.sdk import launch

# Required for launch sdk use.
wandb.require("core")

config = {
    "trainer": {
        "learning_rate": 0.01,
        "batch_size": 32,
        "model": "resnet",
        "dataset": "cifar10",
        "private": {
            "key": "value",
        },
    },
    "seed": 42,
}


with wandb.init(config=config):
    launch.manage_wandb_config(
        include=["trainer"], 
        exclude=["trainer.private"],
    )
    # Etc.

launch.manage_wandb_config 함수는 Run.config 오브젝트에 대한 입력 값을 허용하도록 작업을 구성합니다. 선택적 include 및 exclude 옵션은 중첩된 config 오브젝트 내에서 경로 접두사를 사용합니다. 예를 들어 작업이 최종 사용자에게 노출하고 싶지 않은 옵션이 있는 라이브러리를 사용하는 경우에 유용할 수 있습니다.

include 접두사가 제공되면 include 접두사와 일치하는 config 내의 경로만 입력 값을 허용합니다. exclude 접두사가 제공되면 exclude 목록과 일치하는 경로는 입력 값에서 필터링되지 않습니다. 경로가 include 및 exclude 접두사와 모두 일치하는 경우 exclude 접두사가 우선합니다.

이전 예에서 ["trainer.private"] 경로는 trainer 오브젝트에서 private 키를 필터링하고 ["trainer"] 경로는 trainer 오브젝트에 속하지 않은 모든 키를 필터링합니다.

위의 코드가 패키지되어 작업으로 실행되면 작업의 입력 유형은 다음과 같습니다.

{
    "trainer": {
        "learning_rate": "float",
        "batch_size": "int",
        "model": "str",
        "dataset": "str",
    },
}

W&B CLI 또는 UI에서 작업을 시작할 때 사용자는 4개의 trainer 파라미터만 재정의할 수 있습니다.

Run config 입력 엑세스

Run config 입력으로 시작된 작업은 Run.config를 통해 입력 값에 엑세스할 수 있습니다. 작업 코드에서 wandb.init에 의해 반환된 Run은 입력 값이 자동으로 설정됩니다. 작업 코드의 어디에서든 run config 입력 값을 로드하려면 다음을 사용하십시오.

from wandb.sdk import launch

run_config_overrides = launch.load_wandb_config()

파일 재구성

Launch SDK는 작업 코드의 config 파일에 저장된 입력 값을 관리하는 방법도 제공합니다. 이것은 이 torchtune 예제 또는 이 Axolotl config와 같은 많은 딥러닝 및 대규모 언어 모델 유스 케이스에서 일반적인 패턴입니다.

launch.manage_config_file 함수를 사용하여 config 파일을 Launch 작업에 대한 입력으로 추가하여 작업을 시작할 때 config 파일 내의 값을 편집할 수 있습니다.

기본적으로 launch.manage_config_file이 사용되면 run config 입력이 캡처되지 않습니다. launch.manage_wandb_config를 호출하면 이 동작이 재정의됩니다.

다음 예를 고려하십시오.

import yaml
import wandb
from wandb.sdk import launch

# Required for launch sdk use.
wandb.require("core")

launch.manage_config_file("config.yaml")

with open("config.yaml", "r") as f:
    config = yaml.safe_load(f)

with wandb.init(config=config):
    # Etc.
    pass

코드가 인접한 파일 config.yaml과 함께 실행된다고 상상해 보십시오.

learning_rate: 0.01
batch_size: 32
model: resnet
dataset: cifar10

launch.manage_config_file을 호출하면 config.yaml 파일이 작업에 대한 입력으로 추가되어 W&B CLI 또는 UI에서 시작할 때 재구성할 수 있습니다.

include 및 exclude 키워드 arugment는 launch.manage_wandb_config와 같은 방식으로 config 파일에 허용되는 입력 키를 필터링하는 데 사용할 수 있습니다.

Config 파일 입력 엑세스

Launch에서 생성된 Run에서 launch.manage_config_file이 호출되면 launch는 config 파일의 내용을 입력 값으로 패치합니다. 패치된 config 파일은 작업 환경에서 사용할 수 있습니다.

작업의 Launch drawer UI 사용자 정의

작업 입력에 대한 스키마를 정의하면 작업을 시작하기 위한 사용자 정의 UI를 만들 수 있습니다. 작업의 스키마를 정의하려면 launch.manage_wandb_config 또는 launch.manage_config_file 호출에 포함합니다. 스키마는 JSON 스키마 형식의 python dict이거나 Pydantic 모델 클래스일 수 있습니다.

• JSON schema
• Pydantic model

schema = {
    "type": "object",
    "properties": {
        "seed": {
          "type": "integer"
        }
        "trainer": {
            "type": "object",
            "properties": {
                "learning_rate": {
                    "type": "number",
                    "description": "Learning rate of the model",
                    "exclusiveMinimum": 0,
                },
                "batch_size": {
                    "type": "integer",
                    "description": "Number of samples per batch",
                    "enum": [16, 64, 256]
                },
                "dataset": {
                    "type": "string",
                    "description": "Name of the dataset to use",
                    "enum": ["cifar10", "cifar100"]
                }
            }
        }
    }
}

launch.manage_wandb_config(
    include=["seed", "trainer"], 
    exclude=["trainer.private"],
    schema=schema,
)

class DatasetEnum(str, Enum):
    cifar10 = "cifar10"
    cifar100 = "cifar100"

class Trainer(BaseModel):
    learning_rate: float = Field(gt=0, description="Learning rate of the model")
    batch_size: int = Field(ge=1, le=256, description="Number of samples per batch")
    dataset: DatasetEnum = Field(title="Dataset", description="Name of the dataset to use")

class Schema(BaseModel):
    seed: int
    trainer: Trainer

launch.manage_wandb_config(
    include=["seed", "trainer"],
    exclude=["trainer.private"],
    schema=Schema,
)

t = Trainer(learning_rate=0.01, batch_size=32, dataset=DatasetEnum.cifar10)
s = Schema(seed=42, trainer=t)
launch.manage_wandb_config(
    include=["seed", "trainer"],
    exclude=["trainer.private"],
    input_schema=s,
)

작업 입력 스키마를 추가하면 Launch drawer에 구조화된 양식이 만들어져 작업을 더 쉽게 시작할 수 있습니다.

4.4 - Monitor launch queue

대화형 Queue monitoring dashboard 를 사용하여 Launch 대기열의 사용량이 많은지 유휴 상태인지 확인하고, 실행 중인 워크로드를 시각화하고, 비효율적인 작업을 찾아보세요. Launch 대기열 대시보드는 컴퓨팅 하드웨어나 클라우드 리소스를 효과적으로 사용하고 있는지 여부를 결정하는 데 특히 유용합니다.

더 자세한 분석을 위해 페이지는 W&B experiment 추적 워크스페이스와 Datadog, NVIDIA Base Command 또는 클라우드 콘솔과 같은 외부 인프라 모니터링 제공업체에 대한 링크를 제공합니다.

대시보드 및 플롯

Monitor 탭을 사용하여 지난 7일 동안 발생한 대기열의 활동을 확인하세요. 왼쪽 패널을 사용하여 시간 범위, 그룹화 및 필터를 제어합니다.

대시보드에는 성능 및 효율성에 대한 자주 묻는 질문에 답변하는 다양한 플롯이 포함되어 있습니다. 다음 섹션에서는 대기열 대시보드의 UI 요소를 설명합니다.

작업 상태

작업 상태 플롯은 각 시간 간격으로 실행 중, 대기 중, 큐에 대기 중 또는 완료된 작업 수를 보여줍니다. 작업 상태 플롯을 사용하여 대기열의 유휴 기간을 식별합니다.

예를 들어 고정 리소스 (예: DGX BasePod)가 있다고 가정합니다. 고정 리소스로 유휴 대기열을 관찰하는 경우 스윕과 같은 우선 순위가 낮은 선점형 Launch 작업을 실행할 수 있는 기회를 제시할 수 있습니다.

반면에 클라우드 리소스를 사용하고 주기적인 활동 버스트가 표시된다고 가정합니다. 주기적인 활동 버스트는 특정 시간에 리소스를 예약하여 비용을 절약할 수 있는 기회를 제시할 수 있습니다.

플롯의 오른쪽에는 Launch 작업 상태를 나타내는 색상을 보여주는 키가 있습니다.

대기 시간

대기 시간 플롯은 지정된 날짜 또는 시간 범위에 대해 Launch 작업이 대기열에 있었던 시간 (초)을 보여줍니다.

x축은 사용자가 지정하는 시간 프레임을 보여주고 y축은 Launch 작업이 Launch 대기열에 있었던 시간 (초)을 보여줍니다. 예를 들어 특정 날짜에 10개의 Launch 작업이 큐에 있다고 가정합니다. 해당 10개의 Launch 작업이 평균 60초씩 기다리면 대기 시간 플롯은 600초를 보여줍니다.

왼쪽 막대의 Grouping 컨트롤을 사용하여 각 작업의 색상을 사용자 정의합니다.

이는 어떤 사용자와 작업이 부족한 대기열 용량으로 인해 어려움을 겪고 있는지 식별하는 데 특히 유용할 수 있습니다.

작업 Runs

이 플롯은 시간 간격으로 실행된 모든 작업의 시작과 끝을 보여주며 각 run에 대해 서로 다른 색상을 사용합니다. 이를 통해 특정 시간에 대기열에서 어떤 워크로드를 처리하고 있는지 한눈에 쉽게 알 수 있습니다.

패널 오른쪽 하단의 Select 툴을 사용하여 작업을 브러시하여 아래 표에 세부 정보를 채웁니다.

CPU 및 GPU 사용량

GPU use by a job, CPU use by a job, GPU memory by job 및 System memory by job을 사용하여 Launch 작업의 효율성을 확인합니다.

예를 들어 GPU memory by job을 사용하여 W&B run을 완료하는 데 시간이 오래 걸렸는지 여부와 CPU 코어의 낮은 비율을 사용했는지 여부를 확인할 수 있습니다.

각 플롯의 x축은 Launch 작업으로 생성된 W&B run의 지속 시간 (초)을 보여줍니다. 마우스를 데이터 포인트 위에 올려 놓으면 run ID, run이 속한 프로젝트, W&B run을 생성한 Launch 작업 등과 같은 W&B run에 대한 정보를 볼 수 있습니다.

오류

Errors 패널은 지정된 Launch 대기열에서 발생한 오류를 보여줍니다. 보다 구체적으로 Errors 패널은 오류가 발생한 타임스탬프, 오류가 발생한 Launch 작업의 이름, 생성된 오류 메시지를 보여줍니다. 기본적으로 오류는 최신순에서 가장 오래된 순으로 정렬됩니다.

Errors 패널을 사용하여 사용자를 식별하고 차단을 해제합니다.

외부 링크

대기열 관찰 가능성 대시보드의 보기는 모든 대기열 유형에서 일관되지만, 많은 경우 환경별 모니터로 직접 이동하는 것이 유용할 수 있습니다. 이를 위해 대기열 관찰 가능성 대시보드에서 직접 콘솔에서 링크를 추가합니다.

페이지 하단에서 Manage Links를 클릭하여 패널을 엽니다. 원하는 페이지의 전체 URL을 추가합니다. 다음으로 레이블을 추가합니다. 추가한 링크는 External Links 섹션에 나타납니다.

4.5 - View launch jobs

다음 페이지에서는 대기열에 추가된 Launch 작업에 대한 정보를 보는 방법을 설명합니다.

작업 보기

W&B 앱으로 대기열에 추가된 작업을 봅니다.

1. https://wandb.ai/home에서 W&B 앱으로 이동합니다.
2. 왼쪽 사이드바의 Applications 섹션에서 Launch를 선택합니다.
3. All entities 드롭다운을 선택하고 Launch 작업이 속한 entity를 선택합니다.
4. Launch Application 페이지에서 축소 가능한 UI를 확장하여 해당 특정 대기열에 추가된 작업 목록을 봅니다.

예를 들어 다음 이미지는 job-source-launch_demo-canonical이라는 작업에서 생성된 두 개의 run을 보여줍니다. 이 작업은 Start queue라는 대기열에 추가되었습니다. 대기열에 나열된 첫 번째 run은 resilient-snowball이라고 하고 두 번째 run은 earthy-energy-165라고 합니다.

W&B 앱 UI 내에서 Launch 작업에서 생성된 run에 대한 다음과 같은 추가 정보를 찾을 수 있습니다.

• Run: 해당 작업에 할당된 W&B run의 이름입니다.
• Job ID: 작업의 이름입니다.
• Project: run이 속한 project의 이름입니다.
• Status: 대기열에 있는 run의 상태입니다.
• Author: run을 생성한 W&B entity입니다.
• Creation date: 대기열이 생성된 타임스탬프입니다.
• Start time: 작업이 시작된 타임스탬프입니다.
• Duration: 작업을 완료하는 데 걸린 시간(초)입니다.

작업 나열

W&B CLI를 사용하여 project 내에 존재하는 작업 목록을 봅니다. W&B 작업 목록 코맨드를 사용하고 Launch 작업이 속한 project 및 entity의 이름을 각각 --project 및 --entity 플래그와 함께 제공합니다.

 wandb job list --entity your-entity --project project-name

작업 상태 확인

다음 표는 대기열에 있는 run이 가질 수 있는 상태를 정의합니다.

5 - Create sweeps with W&B Launch

W&B Launch를 사용하여 하이퍼파라미터 튜닝 작업( Sweeps)을 생성합니다. Launch에서 Sweeps를 사용하면 스윕 스케줄러가 스윕할 지정된 하이퍼파라미터와 함께 Launch Queue로 푸시됩니다. 스윕 스케줄러는 에이전트가 선택함에 따라 시작되어 선택한 하이퍼파라미터로 스윕 run을 동일한 Queue로 시작합니다. 이는 스윕이 완료되거나 중지될 때까지 계속됩니다.

기본 W&B 스윕 스케줄링 엔진을 사용하거나 자체 사용자 정의 스케줄러를 구현할 수 있습니다.

1. 표준 스윕 스케줄러: W&B Sweeps를 제어하는 기본 W&B 스윕 스케줄링 엔진을 사용합니다. 친숙한 bayes, grid 및 random 메소드를 사용할 수 있습니다.
2. 사용자 정의 스윕 스케줄러: 스윕 스케줄러가 작업으로 실행되도록 구성합니다. 이 옵션을 사용하면 완벽하게 사용자 정의할 수 있습니다. 표준 스윕 스케줄러를 확장하여 더 많은 로깅을 포함하는 방법의 예는 아래 섹션에서 찾을 수 있습니다.

W&B 표준 스케줄러로 스윕 생성

Launch로 W&B Sweeps를 생성합니다. W&B App을 사용하여 대화식으로 또는 W&B CLI를 사용하여 프로그래밍 방식으로 스윕을 생성할 수 있습니다. 스케줄러를 사용자 정의하는 기능을 포함하여 Launch 스윕의 고급 구성은 CLI를 사용하십시오.

• W&B app
• CLI

W&B App을 사용하여 대화식으로 스윕을 생성합니다.

1. W&B App에서 W&B 프로젝트로 이동합니다.
2. 왼쪽 패널에서 스윕 아이콘(빗자루 이미지)을 선택합니다.
3. 다음으로 스윕 생성 버튼을 선택합니다.
4. Launch 구성 🚀 버튼을 클릭합니다.
5. 작업 드롭다운 메뉴에서 스윕을 생성할 작업 이름과 작업 버전을 선택합니다.
6. Queue 드롭다운 메뉴를 사용하여 스윕을 실행할 Queue를 선택합니다.
7. 작업 우선 순위 드롭다운을 사용하여 Launch 작업의 우선 순위를 지정합니다. Launch Queue가 우선 순위 지정을 지원하지 않으면 Launch 작업의 우선 순위가 “보통"으로 설정됩니다.
8. (선택 사항) Run 또는 스윕 스케줄러에 대한 재정의 인수를 구성합니다. 예를 들어 스케줄러 재정의를 사용하여 스케줄러가 관리하는 동시 Run 수를 num_workers를 사용하여 구성합니다.
9. (선택 사항) 대상 프로젝트 드롭다운 메뉴를 사용하여 스윕을 저장할 프로젝트를 선택합니다.
10. 저장을 클릭합니다.
11. 스윕 시작을 선택합니다.

W&B CLI를 사용하여 프로그래밍 방식으로 Launch로 W&B 스윕을 생성합니다.

1. 스윕 구성을 만듭니다.
2. 스윕 구성 내에서 전체 작업 이름을 지정합니다.
3. 스윕 에이전트를 초기화합니다.

1단계와 3단계는 일반적으로 W&B 스윕을 생성할 때 수행하는 단계와 동일합니다.

예를 들어 다음 코드 조각에서는 작업 값으로 'wandb/jobs/Hello World 2:latest'를 지정합니다.

# launch-sweep-config.yaml

job: 'wandb/jobs/Hello World 2:latest'
description: launch jobs를 사용한 스윕 예제

method: bayes
metric:
  goal: minimize
  name: loss_metric
parameters:
  learning_rate:
    max: 0.02
    min: 0
    distribution: uniform
  epochs:
    max: 20
    min: 0
    distribution: int_uniform

# 선택적 스케줄러 파라미터:

# scheduler:
#   num_workers: 1  # 동시 스윕 Runs
#   docker_image: <스케줄러의 기본 이미지>
#   resource: <예: local-container...>
#   resource_args:  # Runs에 전달되는 리소스 인수
#     env: 
#         - WANDB_API_KEY

# 선택적 Launch 파라미터
# launch: 
#    registry: <이미지 풀링 레지스트리>

스윕 구성 생성 방법에 대한 자세한 내용은 스윕 구성 정의 페이지를 참조하십시오.

4. 다음으로 스윕을 초기화합니다. 구성 파일의 경로, 작업 Queue 이름, W&B 엔티티 및 프로젝트 이름을 제공합니다.

wandb launch-sweep <path/to/yaml/file> --queue <queue_name> --entity <your_entity>  --project <project_name>

W&B Sweeps에 대한 자세한 내용은 하이퍼파라미터 튜닝 챕터를 참조하십시오.

사용자 정의 스윕 스케줄러 생성

W&B 스케줄러 또는 사용자 정의 스케줄러로 사용자 정의 스윕 스케줄러를 생성합니다.

• W&B scheduler
• Custom scheduler
• Optuna scheduler

# launch-sweep-config.yaml  
description: 스케줄러 작업을 사용하여 Launch 스윕 구성
scheduler:
  job: wandb/sweep-jobs/job-wandb-sweep-scheduler:latest
  num_workers: 8  # 8개의 동시 스윕 Runs를 허용합니다.

# 스윕 Runs가 실행할 트레이닝/튜닝 작업
job: wandb/sweep-jobs/job-fashion-MNIST-train:latest
method: grid
parameters:
  learning_rate:
    min: 0.0001
    max: 0.1

...
scheduler:
  job: '<entity>/<project>/job-CustomWandbScheduler:latest'
...

  # optuna_config_basic.yaml
  description: 기본 Optuna 스케줄러
  job: wandb/sweep-jobs/job-fashion-MNIST-train:latest
  run_cap: 5
  metric:
    name: epoch/val_loss
    goal: minimize

  scheduler:
    job: wandb/sweep-jobs/job-optuna-sweep-scheduler:latest
    resource: local-container  # 이미지에서 제공되는 스케줄러 작업에 필요합니다.
    num_workers: 2

    # optuna 특정 설정
    settings:
      pruner:
        type: PercentilePruner
        args:
          percentile: 25.0  # Runs의 75% 종료
          n_warmup_steps: 10  # 처음 x단계에서는 가지치기가 꺼집니다.

  parameters:
    learning_rate:
      min: 0.0001
      max: 0.1

wandb launch-sweep <config.yaml> -q <queue> -p <project> -e <entity>

사용자 정의 스윕 스케줄러 작업으로 가능한 작업의 예는 jobs/sweep_schedulers 아래의 wandb/launch-jobs 리포지토리에서 확인할 수 있습니다. 이 가이드에서는 공개적으로 사용 가능한 Wandb 스케줄러 작업을 사용하는 방법과 사용자 정의 스윕 스케줄러 작업을 생성하는 프로세스를 보여줍니다.

Launch에서 스윕을 재개하는 방법

이전에 시작된 스윕에서 Launch 스윕을 재개할 수도 있습니다. 하이퍼파라미터와 트레이닝 작업은 변경할 수 없지만 스케줄러별 파라미터와 푸시되는 Queue는 변경할 수 있습니다.

1. 이전에 실행한 Launch 스윕의 스윕 이름/ID를 식별합니다. 스윕 ID는 W&B App의 프로젝트에서 찾을 수 있는 8자 문자열입니다(예: hhd16935).
2. 스케줄러 파라미터를 변경하는 경우 업데이트된 구성 파일을 구성합니다.
3. 터미널에서 다음 명령을 실행합니다. <와 >로 묶인 내용을 정보로 바꿉니다.

wandb launch-sweep <optional config.yaml> --resume_id <sweep id> --queue <queue_name>

6 - Launch FAQ

6.1 - Are there best practices for using Launch effectively?

1. 쉬운 설정을 위해 에이전트 를 시작하기 전에 먼저 대기열을 생성하세요. 이렇게 하지 않으면 대기열이 추가될 때까지 에이전트 가 작동하지 않게 하는 오류가 발생합니다.

2. 에이전트 를 시작하기 위해 W&B 서비스 계정을 생성하여 개별 user 계정에 연결되지 않도록 합니다.

3. wandb.config를 사용하여 하이퍼파라미터 를 관리하고 작업 재실행 중에 덮어쓸 수 있습니다. argparse 사용에 대한 자세한 내용은 이 가이드 를 참조하세요.

6.2 - Can I specify a Dockerfile and let W&B build a Docker image for me?

이 기능은 요구 사항은 안정적이지만 코드 베이스가 자주 변경되는 프로젝트에 적합합니다.

Dockerfile을 구성한 후에는 다음 세 가지 방법 중 하나로 W&B에 지정합니다.

• Dockerfile.wandb 사용
• W&B CLI 사용
• W&B App 사용

• Dockerfile.wandb
• W&B CLI
• W&B app

wandb launch --dockerfile path/to/Dockerfile

{
  "args": [],
  "run_config": {
    "lr": 0,
    "batch_size": 0,
    "epochs": 0
  },
  "entrypoint": [],
  "dockerfile": "./Dockerfile"
}

6.3 - Can Launch automatically provision (and spin down) compute resources for me in the target environment?

이 프로세스는 환경에 따라 달라집니다. 리소스는 Amazon SageMaker 및 Vertex에서 프로비저닝됩니다. Kubernetes에서는 autoscaler가 수요에 따라 자동으로 리소스를 조정합니다. W&B의 솔루션 설계자는 재시도, autoscaling, 스팟 인스턴스 노드 풀 사용을 가능하게 하도록 Kubernetes 인프라를 구성하는 데 도움을 줍니다. 지원이 필요하면 support@wandb.com으로 문의하거나 공유된 Slack 채널을 이용하세요.

6.4 - Can you specify secrets for jobs/automations? For instance, an API key which you do not wish to be directly visible to users?

예. 다음 단계를 따르세요:

1. 다음 코맨드를 사용하여 run에 지정된 네임스페이스에 Kubernetes secret을 생성합니다:
   kubectl create secret -n <namespace> generic <secret_name> <secret_value>

2. secret을 생성한 후, run이 시작될 때 secret을 삽입하도록 큐를 구성합니다. 클러스터 관리자만 secret을 볼 수 있으며, 최종 사용자는 볼 수 없습니다.

6.5 - Does Launch support parallelization? How can I limit the resources consumed by a job?

Launch는 여러 GPU 및 노드에서 작업 확장을 지원합니다. 자세한 내용은 이 가이드를 참조하세요.

각 Launch 에이전트는 실행할 수 있는 최대 동시 작업 수를 결정하는 max_jobs 파라미터로 구성됩니다. 여러 에이전트가 적절한 실행 인프라에 연결되어 있는 한 단일 대기열을 가리킬 수 있습니다.

리소스 설정에서 대기열 또는 작업 Run 수준에서 CPU, GPU, 메모리 및 기타 리소스에 대한 제한을 설정할 수 있습니다. Kubernetes에서 리소스 제한을 사용하여 대기열을 설정하는 방법에 대한 자세한 내용은 이 가이드를 참조하세요.

Sweeps의 경우 다음 블록을 대기열 설정에 포함하여 동시 Runs 수를 제한합니다.

  scheduler:
    num_workers: 4

6.6 - How can admins restrict which users have modify access?

대기열 구성 템플릿을 통해 팀 관리자가 아닌 사용자에 대해 특정 대기열 필드에 대한 엑세스를 제어합니다. 팀 관리자는 관리자가 아닌 사용자가 볼 수 있는 필드를 정의하고 편집 제한을 설정합니다. 팀 관리자만 대기열을 생성하거나 편집할 수 있습니다.

6.7 - How do I control who can push to a queue?

대기열은 특정 사용자 팀에 해당합니다. 대기열 생성 시 소유 엔티티를 정의하세요. 엑세스를 제한하려면 팀 멤버십을 수정하세요.

6.8 - How do I fix a "permission denied" error in Launch?

Launch Error: Permission denied 오류 메시지가 발생하면 원하는 프로젝트에 로그할 권한이 부족하다는 의미입니다. 가능한 원인은 다음과 같습니다.

1. 이 머신에 로그인하지 않았습니다. 커맨드라인에서 wandb login 을 실행하세요.
2. 지정된 엔티티가 존재하지 않습니다. 엔티티는 사용자 이름 또는 기존 팀 이름이어야 합니다. 필요한 경우 Subscriptions page에서 팀을 만드세요.
3. 프로젝트 권한이 없습니다. 프로젝트 생성자에게 프로젝트에 run을 로그할 수 있도록 개인 정보 보호 설정을 Open으로 변경하도록 요청하세요.

6.9 - How do I make W&B Launch work with Tensorflow on GPU?

GPU를 사용하는 TensorFlow 작업의 경우, 컨테이너 빌드를 위한 사용자 정의 기본 이미지를 지정하세요. 이렇게 하면 run 동안 적절한 GPU 활용이 보장됩니다. 리소스 설정에서 builder.accelerator.base_image 키 아래에 이미지 태그를 추가합니다. 예시:

{
    "gpus": "all",
    "builder": {
        "accelerator": {
            "base_image": "tensorflow/tensorflow:latest-gpu"
        }
    }
}

W&B 0.15.6 이전 버전에서는 base_image의 상위 키로 accelerator 대신 cuda를 사용하세요.

6.10 - How does W&B Launch build images?

이미지를 빌드하는 단계는 job 소스와 리소스 설정에 지정된 가속기 기본 이미지에 따라 달라집니다.

{
    "builder": {
        "accelerator": {
            "base_image": "image-name"
        }
    }
}

빌드 프로세스에는 job 유형 및 제공된 가속기 기본 이미지를 기반으로 다음 작업이 포함됩니다.

| | apt를 사용하여 Python 설치 | Python 패키지 설치 | 사용자 및 작업 디렉터리 생성 | 이미지를 코드에 복사 | 진입점 설정 | |

6.11 - I do not like clicking- can I use Launch without going through the UI?

예. 표준 wandb CLI에는 작업을 실행하는 launch 하위 코맨드가 포함되어 있습니다. 자세한 내용은 다음을 실행하세요.

wandb launch --help

6.12 - I do not want W&B to build a container for me, can I still use Launch?

미리 빌드된 Docker 이미지를 시작하려면 다음 코맨드를 실행하세요. <>의 자리 표시자를 특정 정보로 바꾸세요.

wandb launch -d <docker-image-uri> -q <queue-name> -E <entrypoint>

이 코맨드는 job을 생성하고 run을 시작합니다.

이미지에서 job을 생성하려면 다음 코맨드를 사용하세요.

wandb job create image <image-name> -p <project> -e <entity>

6.13 - Is `wandb launch -d` or `wandb job create image` uploading a whole docker artifact and not pulling from a registry?

아니요, wandb launch -d 코맨드는 이미지를 레지스트리에 업로드하지 않습니다. 이미지를 레지스트리에 별도로 업로드하세요. 다음 단계를 따르세요.

1. 이미지를 빌드합니다.
2. 이미지를 레지스트리에 푸시합니다.

워크플로우는 다음과 같습니다.

docker build -t <repo-url>:<tag> .
docker push <repo-url>:<tag>
wandb launch -d <repo-url>:<tag>

그러면 Launch 에이전트가 지정된 컨테이너를 가리키는 작업을 시작합니다. 컨테이너 레지스트리에서 이미지를 가져오기 위해 에이전트 엑세스를 구성하는 방법에 대한 예는 고급 에이전트 설정을 참조하세요.

Kubernetes의 경우 Kubernetes 클러스터 포드가 이미지가 푸시되는 레지스트리에 엑세스할 수 있는지 확인하세요.

6.14 - What permissions does the agent require in Kubernetes?

다음 Kubernetes 매니페스트는 wandb 네임스페이스에 wandb-launch-agent 라는 역할을 생성합니다. 이 역할은 에이전트가 wandb 네임스페이스에서 pod, configmap, secrets를 생성하고 pod 로그에 엑세스할 수 있도록 합니다. wandb-cluster-role 은 에이전트가 pod를 생성하고, pod 로그에 엑세스하고, secrets, jobs를 생성하고, 지정된 모든 네임스페이스에서 job 상태를 확인할 수 있도록 합니다.

6.15 - What requirements does the accelerator base image have?

가속기를 활용하는 작업의 경우, 필요한 가속기 구성 요소가 포함된 기본 이미지를 제공하세요. 가속기 이미지에 대한 다음 요구 사항을 확인하세요.

• Debian과의 호환성 (Launch Dockerfile은 apt-get을 사용하여 Python을 설치합니다)
• 지원되는 CPU 및 GPU 하드웨어 명령어 세트 (의도한 GPU 와 CUDA 버전 호환성을 확인합니다)
• 제공된 가속기 버전과 기계 학습 알고리즘의 패키지 간 호환성
• 하드웨어 호환성을 위해 추가 단계가 필요한 패키지 설치

6.16 - When multiple jobs in a Docker queue download the same artifact, is any caching used, or is it re-downloaded every run?

캐싱은 존재하지 않습니다. 각 Launch 작업은 독립적으로 작동합니다. 대기열 또는 에이전트가 대기열 설정에서 Docker 인수를 사용하여 공유 캐시를 마운트하도록 구성하세요.

또한 특정 유스 케이스에 대해 W&B Artifacts 캐시를 영구 볼륨으로 마운트하세요.

7 - Launch integration guides

7.1 - Dagster

Dagster 와 W&B (Weights & Biases) 를 사용하여 MLOps 파이프라인을 조정하고 ML 자산을 유지 관리합니다. W&B 와의 통합으로 Dagster 내에서 다음을 쉽게 수행할 수 있습니다.

• W&B Artifacts를 사용하고 생성합니다.
• W&B Registry에서 Registered Models를 사용하고 생성합니다.
• W&B Launch를 사용하여 전용 컴퓨팅에서 트레이닝 작업을 실행합니다.
• ops 및 assets에서 wandb 클라이언트를 사용합니다.

W&B Dagster 통합은 W&B 특정 Dagster 리소스 및 IO Manager를 제공합니다.

• wandb_resource: W&B API에 인증하고 통신하는 데 사용되는 Dagster 리소스입니다.
• wandb_artifacts_io_manager: W&B Artifacts를 소비하는 데 사용되는 Dagster IO Manager입니다.

다음 가이드에서는 Dagster에서 W&B 를 사용하기 위한 필수 조건을 충족하는 방법, ops 및 assets에서 W&B Artifacts를 생성하고 사용하는 방법, W&B Launch를 사용하는 방법 및 권장 모범 사례를 보여줍니다.

시작하기 전에

Weights & Biases 내에서 Dagster를 사용하려면 다음 리소스가 필요합니다.

1. W&B API 키.
2. W&B entity (user 또는 team): entity는 W&B Runs 및 Artifacts를 보내는 사용자 이름 또는 팀 이름입니다. Runs를 기록하기 전에 W&B App UI에서 계정 또는 팀 entity를 생성해야 합니다. entity를 지정하지 않으면 Run은 일반적으로 사용자 이름인 기본 entity로 전송됩니다. Project Defaults에서 설정에서 기본 entity를 변경합니다.
3. W&B project: W&B Runs가 저장되는 프로젝트 이름입니다.

W&B App에서 해당 사용자 또는 팀의 프로필 페이지를 확인하여 W&B entity를 찾으십시오. 기존 W&B 프로젝트를 사용하거나 새 프로젝트를 만들 수 있습니다. 새 프로젝트는 W&B App 홈페이지 또는 사용자/팀 프로필 페이지에서 만들 수 있습니다. 프로젝트가 존재하지 않으면 처음 사용할 때 자동으로 생성됩니다. 다음 지침은 API 키를 얻는 방법을 보여줍니다.

API 키를 얻는 방법

1. W&B에 로그인합니다. 참고: W&B Server를 사용하는 경우 관리자에게 인스턴스 호스트 이름을 문의하십시오.
2. 인증 페이지 또는 사용자/팀 설정에서 API 키를 수집합니다. 프로덕션 환경의 경우 해당 키를 소유할 서비스 계정을 사용하는 것이 좋습니다.
3. 해당 API 키에 대한 환경 변수 내보내기 WANDB_API_KEY=YOUR_KEY를 설정합니다.

다음 예제에서는 Dagster 코드에서 API 키를 지정할 위치를 보여줍니다. wandb_config 중첩 사전에 entity 및 프로젝트 이름을 지정해야 합니다. 다른 W&B 프로젝트를 사용하려는 경우 다른 wandb_config 값을 다른 ops/assets에 전달할 수 있습니다. 전달할 수 있는 가능한 키에 대한 자세한 내용은 아래의 Configuration 섹션을 참조하십시오.

• Config for @job
• Config for @repository using assets

# add this to your config.yaml
# alternatively you can set the config in Dagit's Launchpad or JobDefinition.execute_in_process
# Reference: https://docs.dagster.io/concepts/configuration/config-schema#specifying-runtime-configuration
resources:
 wandb_config:
   config:
     entity: my_entity # replace this with your W&B entity
     project: my_project # replace this with your W&B project


@job(
   resource_defs={
       "wandb_config": make_values_resource(
           entity=str,
           project=str,
       ),
       "wandb_resource": wandb_resource.configured(
           {"api_key": {"env": "WANDB_API_KEY"}}
       ),
       "io_manager": wandb_artifacts_io_manager,
   }
)
def simple_job_example():
   my_op()

from dagster_wandb import wandb_artifacts_io_manager, wandb_resource
from dagster import (
   load_assets_from_package_module,
   make_values_resource,
   repository,
   with_resources,
)

from . import assets

@repository
def my_repository():
   return [
       *with_resources(
           load_assets_from_package_module(assets),
           resource_defs={
               "wandb_config": make_values_resource(
                   entity=str,
                   project=str,
               ),
               "wandb_resource": wandb_resource.configured(
                   {"api_key": {"env": "WANDB_API_KEY"}}
               ),
               "wandb_artifacts_manager": wandb_artifacts_io_manager.configured(
                   {"cache_duration_in_minutes": 60} # only cache files for one hour
               ),
           },
           resource_config_by_key={
               "wandb_config": {
                   "config": {
                       "entity": "my_entity", # replace this with your W&B entity
                       "project": "my_project", # replace this with your W&B project
                   }
               }
           },
       ),
   ]

구성

다음 구성 옵션은 통합에서 제공하는 W&B 특정 Dagster 리소스 및 IO Manager의 설정으로 사용됩니다.

• wandb_resource: W&B API와 통신하는 데 사용되는 Dagster 리소스입니다. 제공된 API 키를 사용하여 자동으로 인증합니다. 속성:
  • api_key: (str, 필수): W&B API와 통신하는 데 필요한 W&B API 키입니다.
  • host: (str, 선택 사항): 사용하려는 API 호스트 서버입니다. W&B Server를 사용하는 경우에만 필요합니다. 기본적으로 퍼블릭 클라우드 호스트인 https://api.wandb.ai입니다.
• wandb_artifacts_io_manager: W&B Artifacts를 소비하는 Dagster IO Manager입니다. 속성:
  • base_dir: (int, 선택 사항) 로컬 스토리지 및 캐싱에 사용되는 기본 디렉토리입니다. W&B Artifacts 및 W&B Run 로그는 해당 디렉토리에서 쓰고 읽습니다. 기본적으로 DAGSTER_HOME 디렉토리를 사용합니다.
  • cache_duration_in_minutes: (int, 선택 사항) W&B Artifacts 및 W&B Run 로그를 로컬 스토리지에 보관해야 하는 시간(분)을 정의합니다. 해당 시간 동안 열리지 않은 파일 및 디렉토리만 캐시에서 제거됩니다. 캐시 제거는 IO Manager 실행이 끝나면 수행됩니다. 캐싱을 완전히 끄려면 0으로 설정할 수 있습니다. 캐싱은 동일한 시스템에서 실행되는 작업 간에 Artifact가 재사용될 때 속도를 향상시킵니다. 기본값은 30일입니다.
  • run_id: (str, 선택 사항): 재개를 위해 사용되는 이 Run에 대한 고유 ID입니다. 프로젝트에서 고유해야 하며 Run을 삭제하면 ID를 재사용할 수 없습니다. Runs 간에 비교하기 위해 하이퍼파라미터를 저장하려면 이름 필드를 짧은 설명 이름으로 사용하거나 config를 사용합니다. ID에는 다음 특수 문자를 포함할 수 없습니다. /\#?%:.. IO Manager가 Run을 재개할 수 있도록 Dagster 내부에서 실험 추적을 수행할 때 Run ID를 설정해야 합니다. 기본적으로 Dagster Run ID (예: 7e4df022-1bf2-44b5-a383-bb852df4077e)로 설정됩니다.
  • run_name: (str, 선택 사항) UI에서 이 Run을 식별하는 데 도움이 되는 이 Run의 짧은 표시 이름입니다. 기본적으로 dagster-run-[Dagster Run ID의 처음 8자] 형식의 문자열입니다. 예를 들어 dagster-run-7e4df022입니다.
  • run_tags: (list[str], 선택 사항): UI에서 이 Run의 태그 목록을 채울 문자열 목록입니다. 태그는 Runs를 함께 구성하거나 baseline 또는 production과 같은 임시 레이블을 적용하는 데 유용합니다. UI에서 태그를 쉽게 추가하고 제거하거나 특정 태그가 있는 Runs만 필터링할 수 있습니다. 통합에서 사용되는 모든 W&B Run에는 dagster_wandb 태그가 있습니다.

W&B Artifacts 사용

W&B Artifact와의 통합은 Dagster IO Manager에 의존합니다.

IO Managers는 asset 또는 op의 출력을 저장하고 다운스트림 assets 또는 ops에 대한 입력으로 로드하는 역할을 하는 사용자 제공 오브젝트입니다. 예를 들어 IO Manager는 파일 시스템의 파일에서 오브젝트를 저장하고 로드할 수 있습니다.

통합은 W&B Artifacts에 대한 IO Manager를 제공합니다. 이를 통해 모든 Dagster @op 또는 @asset이 W&B Artifacts를 기본적으로 생성하고 소비할 수 있습니다. 다음은 Python 목록을 포함하는 dataset 유형의 W&B Artifact를 생성하는 @asset의 간단한 예입니다.

@asset(
    name="my_artifact",
    metadata={
        "wandb_artifact_arguments": {
            "type": "dataset",
        }
    },
    io_manager_key="wandb_artifacts_manager",
)
def create_dataset():
    return [1, 2, 3] # this will be stored in an Artifact

Artifacts를 쓰기 위해 @op, @asset 및 @multi_asset에 메타데이터 구성을 주석으로 추가할 수 있습니다. 마찬가지로 Dagster 외부에서 생성된 경우에도 W&B Artifacts를 소비할 수 있습니다.

W&B Artifacts 쓰기

계속하기 전에 W&B Artifacts를 사용하는 방법을 잘 이해하는 것이 좋습니다. Artifacts 가이드를 읽어 보십시오.

Python 함수에서 오브젝트를 반환하여 W&B Artifact를 작성합니다. W&B에서 지원하는 오브젝트는 다음과 같습니다.

• Python 오브젝트 (int, dict, list…)
• W&B 오브젝트 (Table, Image, Graph…)
• W&B Artifact 오브젝트

다음 예제에서는 Dagster assets (@asset)로 W&B Artifacts를 쓰는 방법을 보여줍니다.

• Python objects
• W&B Object
• W&B Artifact

@asset(
    name="my_artifact",
    metadata={
        "wandb_artifact_arguments": {
            "type": "dataset",
        }
    },
    io_manager_key="wandb_artifacts_manager",
)
def create_dataset():
    return [1, 2, 3]

import wandb

@asset(
    name="my_artifact",
    metadata={
        "wandb_artifact_arguments": {
            "type": "dataset",
        }
    },
    io_manager_key="wandb_artifacts_manager",
)
def create_dataset_in_table():
    return wandb.Table(columns=["a", "b", "c"], data=[[1, 2, 3]])

import wandb

MY_ASSET = "my_asset"

@asset(
    name=MY_ASSET,
    io_manager_key="wandb_artifacts_manager",
)
def create_artifact():
   artifact = wandb.Artifact(MY_ASSET, "dataset")
   table = wandb.Table(columns=["a", "b", "c"], data=[[1, 2, 3]])
   artifact.add(table, "my_table")
   return artifact

구성

wandb_artifact_configuration이라는 구성 사전은 @op, @asset 및 @multi_asset에서 설정할 수 있습니다. 이 사전은 데코레이터 인수로 메타데이터로 전달되어야 합니다. 이 구성은 W&B Artifacts의 IO Manager 읽기 및 쓰기를 제어하는 데 필요합니다.

@op의 경우 Out 메타데이터 인수를 통해 출력 메타데이터에 있습니다. @asset의 경우 asset의 메타데이터 인수에 있습니다. @multi_asset의 경우 AssetOut 메타데이터 인수를 통해 각 출력 메타데이터에 있습니다.

다음 코드 예제에서는 @op, @asset 및 @multi_asset 계산에서 사전을 구성하는 방법을 보여줍니다.

• Example for @op
• Example for @asset
• Example for @multi_asset

@op(
   out=Out(
       metadata={
           "wandb_artifact_configuration": {
               "name": "my_artifact",
               "type": "dataset",
           }
       }
   )
)
def create_dataset():
   return [1, 2, 3]

@asset(
   name="my_artifact",
   metadata={
       "wandb_artifact_configuration": {
           "type": "dataset",
       }
   },
   io_manager_key="wandb_artifacts_manager",
)
def create_dataset():
   return [1, 2, 3]

@multi_asset(
   name="create_datasets",
   outs={
       "first_table": AssetOut(
           metadata={
               "wandb_artifact_configuration": {
                   "type": "training_dataset",
               }
           },
           io_manager_key="wandb_artifacts_manager",
       ),
       "second_table": AssetOut(
           metadata={
               "wandb_artifact_configuration": {
                   "type": "validation_dataset",
               }
           },
           io_manager_key="wandb_artifacts_manager",
       ),
   },
   group_name="my_multi_asset_group",
)
def create_datasets():
   first_table = wandb.Table(columns=["a", "b", "c"], data=[[1, 2, 3]])
   second_table = wandb.Table(columns=["d", "e"], data=[[4, 5]])

   return first_table, second_table

지원되는 속성:

• name: (str) 이 Artifact에 대한 사람이 읽을 수 있는 이름으로, UI에서 이 Artifact를 식별하거나 use_artifact 호출에서 참조하는 방법입니다. 이름에는 문자, 숫자, 밑줄, 하이픈 및 마침표가 포함될 수 있습니다. 이름은 프로젝트에서 고유해야 합니다. @op에 필요합니다.
• type: (str) Artifact의 유형으로, Artifact를 구성하고 구별하는 데 사용됩니다. 일반적인 유형에는 dataset 또는 model이 포함되지만 문자, 숫자, 밑줄, 하이픈 및 마침표를 포함하는 모든 문자열을 사용할 수 있습니다. 출력이 Artifact가 아닌 경우에 필요합니다.
• description: (str) Artifact에 대한 설명을 제공하는 자유 텍스트입니다. 설명은 UI에서 markdown으로 렌더링되므로 테이블, 링크 등을 배치하기에 좋은 위치입니다.
• aliases: (list[str]) Artifact에 적용하려는 하나 이상의 에일리어스를 포함하는 배열입니다. 통합은 설정 여부에 관계없이 “latest” 태그도 해당 목록에 추가합니다. 이는 모델 및 데이터셋의 버전 관리를 관리하는 효과적인 방법입니다.
• add_dirs: (list[dict[str, Any]]): Artifact에 포함할 각 로컬 디렉토리에 대한 구성을 포함하는 배열입니다. SDK에서 동종의 메소드와 동일한 인수를 지원합니다.
• add_files: (list[dict[str, Any]]): Artifact에 포함할 각 로컬 파일에 대한 구성을 포함하는 배열입니다. SDK에서 동종의 메소드와 동일한 인수를 지원합니다.
• add_references: (list[dict[str, Any]]): Artifact에 포함할 각 외부 참조에 대한 구성을 포함하는 배열입니다. SDK에서 동종의 메소드와 동일한 인수를 지원합니다.
• serialization_module: (dict) 사용할 직렬화 모듈의 구성입니다. 자세한 내용은 직렬화 섹션을 참조하십시오.
  • name: (str) 직렬화 모듈의 이름입니다. 허용되는 값: pickle, dill, cloudpickle, joblib. 모듈은 로컬에서 사용할 수 있어야 합니다.
  • parameters: (dict[str, Any]) 직렬화 함수에 전달되는 선택적 인수입니다. 해당 모듈의 덤프 메소드와 동일한 파라미터를 허용합니다. 예를 들어 {"compress": 3, "protocol": 4}입니다.

고급 예시:

@asset(
   name="my_advanced_artifact",
   metadata={
       "wandb_artifact_configuration": {
           "type": "dataset",
           "description": "My *Markdown* description",
           "aliases": ["my_first_alias", "my_second_alias"],
           "add_dirs": [
               {
                   "name": "My directory",
                   "local_path": "path/to/directory",
               }
           ],
           "add_files": [
               {
                   "name": "validation_dataset",
                   "local_path": "path/to/data.json",
               },
               {
                   "is_tmp": True,
                   "local_path": "path/to/temp",
               },
           ],
           "add_references": [
               {
                   "uri": "https://picsum.photos/200/300",
                   "name": "External HTTP reference to an image",
               },
               {
                   "uri": "s3://my-bucket/datasets/mnist",
                   "name": "External S3 reference",
               },
           ],
       }
   },
   io_manager_key="wandb_artifacts_manager",
)
def create_advanced_artifact():
   return [1, 2, 3]

asset은 통합 양쪽에서 유용한 메타데이터로 구체화됩니다.

• W&B 측: 소스 통합 이름 및 버전, 사용된 Python 버전, 피클 프로토콜 버전 등입니다.
• Dagster 측:
  • Dagster Run ID
  • W&B Run: ID, 이름, 경로, URL
  • W&B Artifact: ID, 이름, 유형, 버전, 크기, URL
  • W&B Entity
  • W&B Project

다음 이미지는 Dagster asset에 추가된 W&B의 메타데이터를 보여줍니다. 이 정보는 통합 없이는 사용할 수 없습니다.

다음 이미지는 제공된 구성이 유용한 메타데이터로 W&B Artifact에서 어떻게 보강되었는지 보여줍니다. 이 정보는 재현성 및 유지 관리에 도움이 되어야 합니다. 통합 없이는 사용할 수 없습니다.

from dagster_wandb import WandbArtifactConfiguration

파티션 사용

통합은 기본적으로 Dagster 파티션을 지원합니다.

다음은 DailyPartitionsDefinition을 사용하여 분할된 예입니다.

@asset(
    partitions_def=DailyPartitionsDefinition(start_date="2023-01-01", end_date="2023-02-01"),
    name="my_daily_partitioned_asset",
    compute_kind="wandb",
    metadata={
        "wandb_artifact_configuration": {
            "type": "dataset",
        }
    },
)
def create_my_daily_partitioned_asset(context):
    partition_key = context.asset_partition_key_for_output()
    context.log.info(f"Creating partitioned asset for {partition_key}")
    return random.randint(0, 100)

이 코드는 각 파티션에 대해 하나의 W&B Artifact를 생성합니다. asset 이름 아래의 Artifact 패널 (UI)에서 파티션 키가 추가된 Artifact를 봅니다. 예를 들어 my_daily_partitioned_asset.2023-01-01, my_daily_partitioned_asset.2023-01-02 또는 my_daily_partitioned_asset.2023-01-03입니다. 여러 차원으로 분할된 assets는 각 차원을 점으로 구분된 형식으로 표시합니다. 예를 들어 my_asset.car.blue입니다.

통합은 하나의 Run 내에서 여러 파티션의 구체화를 허용하지 않습니다. assets를 구체화하려면 여러 Runs를 수행해야 합니다. assets를 구체화할 때 Dagit에서 실행할 수 있습니다.

고급 사용법

• 파티션된 작업
• 단순 파티션된 asset
• 다중 파티션된 asset
• 고급 파티션된 사용법

W&B Artifacts 읽기

W&B Artifacts를 읽는 것은 쓰는 것과 유사합니다. wandb_artifact_configuration이라는 구성 사전은 @op 또는 @asset에서 설정할 수 있습니다. 유일한 차이점은 출력이 아닌 입력에 구성을 설정해야 한다는 것입니다.

@op의 경우 In 메타데이터 인수를 통해 입력 메타데이터에 있습니다. Artifact 이름을 명시적으로 전달해야 합니다.

@asset의 경우 Asset In 메타데이터 인수를 통해 입력 메타데이터에 있습니다. 상위 asset의 이름과 일치해야 하므로 Artifact 이름을 전달해서는 안 됩니다.

통합 외부에서 생성된 Artifact에 대한 종속성이 필요한 경우 SourceAsset을 사용해야 합니다. 항상 해당 asset의 최신 버전을 읽습니다.

다음 예제에서는 다양한 ops에서 Artifact를 읽는 방법을 보여줍니다.

• From an @op
• Created by another @asset
• Artifact created outside Dagster

@op(
   ins={
       "artifact": In(
           metadata={
               "wandb_artifact_configuration": {
                   "name": "my_artifact",
               }
           }
       )
   },
   io_manager_key="wandb_artifacts_manager"
)
def read_artifact(context, artifact):
   context.log.info(artifact)

@asset(
   name="my_asset",
   ins={
       "artifact": AssetIn(
           # if you don't want to rename the input argument you can remove 'key'
           key="parent_dagster_asset_name",
           input_manager_key="wandb_artifacts_manager",
       )
   },
)
def read_artifact(context, artifact):
   context.log.info(artifact)

my_artifact = SourceAsset(
   key=AssetKey("my_artifact"),  # the name of the W&B Artifact
   description="Artifact created outside Dagster",
   io_manager_key="wandb_artifacts_manager",
)


@asset
def read_artifact(context, my_artifact):
   context.log.info(my_artifact)

구성

다음 구성은 IO Manager가 데코레이팅된 함수에 대한 입력으로 수집하고 제공해야 하는 항목을 나타내는 데 사용됩니다. 다음과 같은 읽기 패턴이 지원됩니다.

1. Artifact 내에 포함된 명명된 오브젝트를 가져오려면 get을 사용합니다.

@asset(
   ins={
       "table": AssetIn(
           key="my_artifact_with_table",
           metadata={
               "wandb_artifact_configuration": {
                   "get": "my_table",
               }
           },
           input_manager_key="wandb_artifacts_manager",
       )
   }
)
def get_table(context, table):
   context.log.info(table.get_column("a"))

2. Artifact 내에 포함된 다운로드한 파일의 로컬 경로를 가져오려면 get_path를 사용합니다.

@asset(
   ins={
       "path": AssetIn(
           key="my_artifact_with_file",
           metadata={
               "wandb_artifact_configuration": {
                   "get_path": "name_of_file",
               }
           },
           input_manager_key="wandb_artifacts_manager",
       )
   }
)
def get_path(context, path):
   context.log.info(path)

3. 전체 Artifact 오브젝트를 가져오려면 (콘텐츠가 로컬에 다운로드됨):

@asset(
   ins={
       "artifact": AssetIn(
           key="my_artifact",
           input_manager_key="wandb_artifacts_manager",
       )
   },
)
def get_artifact(context, artifact):
   context.log.info(artifact.name)

지원되는 속성

• get: (str) Artifact 상대 이름에 있는 W&B 오브젝트를 가져옵니다.
• get_path: (str) Artifact 상대 이름에 있는 파일의 경로를 가져옵니다.

직렬화 구성

기본적으로 통합은 표준 pickle 모듈을 사용하지만 일부 오브젝트는 호환되지 않습니다. 예를 들어 yield가 있는 함수는 피클링하려고 하면 오류가 발생합니다.

더 많은 Pickle 기반 직렬화 모듈을 지원합니다 (dill, cloudpickle, joblib). 직렬화된 문자열을 반환하거나 Artifact를 직접 만들어 ONNX 또는 PMML과 같은 고급 직렬화를 사용할 수도 있습니다. 올바른 선택은 유스 케이스에 따라 달라집니다. 이 주제에 대한 사용 가능한 문헌을 참조하십시오.

Pickle 기반 직렬화 모듈

wandb_artifact_configuration에서 serialization_module 사전을 통해 사용된 직렬화를 구성할 수 있습니다. Dagster를 실행하는 시스템에서 모듈을 사용할 수 있는지 확인하십시오.

통합은 해당 Artifact를 읽을 때 사용할 직렬화 모듈을 자동으로 인식합니다.

현재 지원되는 모듈은 pickle, dill, cloudpickle 및 joblib입니다.

다음은 joblib로 직렬화된 “model"을 만들고 추론에 사용하는 단순화된 예입니다.

@asset(
    name="my_joblib_serialized_model",
    compute_kind="Python",
    metadata={
        "wandb_artifact_configuration": {
            "type": "model",
            "serialization_module": {
                "name": "joblib"
            },
        }
    },
    io_manager_key="wandb_artifacts_manager",
)
def create_model_serialized_with_joblib():
    # This is not a real ML model but this would not be possible with the pickle module
    return lambda x, y: x + y

@asset(
    name="inference_result_from_joblib_serialized_model",
    compute_kind="Python",
    ins={
        "my_joblib_serialized_model": AssetIn(
            input_manager_key="wandb_artifacts_manager",
        )
    },
    metadata={
        "wandb_artifact_configuration": {
            "type": "results",
        }
    },
    io_manager_key="wandb_artifacts_manager",
)
def use_model_serialized_with_joblib(
    context: OpExecutionContext, my_joblib_serialized_model
):
    inference_result = my_joblib_serialized_model(1, 2)
    context.log.info(inference_result)  # Prints: 3
    return inference_result

고급 직렬화 형식 (ONNX, PMML)

ONNX 및 PMML과 같은 교환 파일 형식을 사용하는 것이 일반적입니다. 통합은 이러한 형식을 지원하지만 Pickle 기반 직렬화보다 더 많은 작업이 필요합니다.

이러한 형식을 사용하는 두 가지 다른 방법이 있습니다.

1. 모델을 선택한 형식으로 변환한 다음 해당 형식의 문자열 표현을 일반 Python 오브젝트인 것처럼 반환합니다. 통합은 해당 문자열을 피클링합니다. 그런 다음 해당 문자열을 사용하여 모델을 다시 빌드할 수 있습니다.
2. 직렬화된 모델로 새 로컬 파일을 만든 다음 add_file 구성을 사용하여 해당 파일로 사용자 지정 Artifact를 빌드합니다.

다음은 ONNX를 사용하여 직렬화되는 Scikit-learn 모델의 예입니다.

import numpy
import onnxruntime as rt
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split

from dagster import AssetIn, AssetOut, asset, multi_asset

@multi_asset(
    compute_kind="Python",
    outs={
        "my_onnx_model": AssetOut(
            metadata={
                "wandb_artifact_configuration": {
                    "type": "model",
                }
            },
            io_manager_key="wandb_artifacts_manager",
        ),
        "my_test_set": AssetOut(
            metadata={
                "wandb_artifact_configuration": {
                    "type": "test_set",
                }
            },
            io_manager_key="wandb_artifacts_manager",
        ),
    },
    group_name="onnx_example",
)
def create_onnx_model():
    # Inspired from https://onnx.ai/sklearn-onnx/

    # Train a model.
    iris = load_iris()
    X, y = iris.data, iris.target
    X_train, X_test, y_train, y_test = train_test_split(X, y)
    clr = RandomForestClassifier()
    clr.fit(X_train, y_train)

    # Convert into ONNX format
    initial_type = [("float_input", FloatTensorType([None, 4]))]
    onx = convert_sklearn(clr, initial_types=initial_type)

    # Write artifacts (model + test_set)
    return onx.SerializeToString(), {"X_test": X_test, "y_test": y_test}

@asset(
    name="experiment_results",
    compute_kind="Python",
    ins={
        "my_onnx_model": AssetIn(
            input_manager_key="wandb_artifacts_manager",
        ),
        "my_test_set": AssetIn(
            input_manager_key="wandb_artifacts_manager",
        ),
    },
    group_name="onnx_example",
)
def use_onnx_model(context, my_onnx_model, my_test_set):
    # Inspired from https://onnx.ai/sklearn-onnx/

    # Compute the prediction with ONNX Runtime
    sess = rt.InferenceSession(my_onnx_model)
    input_name = sess.get_inputs()[0].name
    label_name = sess.get_outputs()[0].name
    pred_onx = sess.run(
        [label_name], {input_name: my_test_set["X_test"].astype(numpy.float32)}
    )[0]
    context.log.info(pred_onx)
    return pred_onx

파티션 사용

통합은 기본적으로 Dagster 파티션을 지원합니다.

asset의 하나, 여러 또는 모든 파티션을 선택적으로 읽을 수 있습니다.

모든 파티션은 파티션 키와 Artifact 콘텐츠를 각각 나타내는 키와 값으로 사전에서 제공됩니다.

• Read all partitions
• Read specific partitions

@asset(
    compute_kind="wandb",
    ins={"my_daily_partitioned_asset": AssetIn()},
    output_required=False,
)
def read_all_partitions(context, my_daily_partitioned_asset):
    for partition, content in my_daily_partitioned_asset.items():
        context.log.info(f"partition={partition}, content={content}")

@asset(
    partitions_def=DailyPartitionsDefinition(start_date="2023-01-01", end_date="2023-02-01"),
    compute_kind="wandb",
    ins={
        "my_daily_partitioned_asset": AssetIn(
            partition_mapping=TimeWindowPartitionMapping(start_offset=-1)
        )
    },
    output_required=False,
)
def read_specific_partitions(context, my_daily_partitioned_asset):
    for partition, content in my_daily_partitioned_asset.items():
        context.log.info(f"partition={partition}, content={content}")

구성 오브젝트인 metadata는 Weights & Biases (wandb)가 프로젝트의 다른 Artifact 파티션과 상호 작용하는 방식을 구성하는 데 사용됩니다.

오브젝트 metadata에는 중첩된 오브젝트 partitions를 추가로 포함하는 wandb_artifact_configuration이라는 키가 포함되어 있습니다.

partitions 오브젝트는 각 파티션의 이름을 해당 구성에 매핑합니다. 각 파티션의 구성은 해당 파티션에서 데이터를 검색하는 방법을 지정할 수 있습니다. 이러한 구성에는 각 파티션의 요구 사항에 따라 get, version 및 alias라는 여러 키가 포함될 수 있습니다.

구성 키

1. get: get 키는 데이터를 가져올 W&B 오브젝트 (Table, Image…)의 이름을 지정합니다.
2. version: Artifact에 대한 특정 버전을 가져오려는 경우 version 키가 사용됩니다.
3. alias: alias 키를 사용하면 에일리어스로 Artifact를 가져올 수 있습니다.

와일드카드 구성

와일드카드 "*"는 구성되지 않은 모든 파티션을 나타냅니다. 이는 partitions` 오브젝트에 명시적으로 언급되지 않은 파티션에 대한 기본 구성을 제공합니다.

예를 들어,

"*": {
    "get": "default_table_name",
},

이 구성은 명시적으로 구성되지 않은 모든 파티션에 대해 default_table_name이라는 테이블에서 데이터를 가져온다는 것을 의미합니다.

특정 파티션 구성

키를 사용하여 특정 구성을 제공하여 특정 파티션에 대한 와일드카드 구성을 재정의할 수 있습니다.

예를 들어,

"yellow": {
    "get": "custom_table_name",
},

이 구성은 yellow라는 파티션의 경우 custom_table_name이라는 테이블에서 데이터를 가져와 와일드카드 구성을 재정의한다는 것을 의미합니다.

버전 관리 및 에일리어싱

버전 관리 및 에일리어싱을 위해 구성에서 특정 version 및 alias 키를 제공할 수 있습니다.

버전의 경우,

"orange": {
    "version": "v0",
},

이 구성은 orange Artifact 파티션의 v0 버전에서 데이터를 가져옵니다.

에일리어스의 경우,

"blue": {
    "alias": "special_alias",
},

이 구성은 에일리어스 special_alias가 있는 Artifact 파티션의 테이블 default_table_name에서 데이터를 가져옵니다 (구성에서 blue라고 함).

고급 사용법

통합의 고급 사용법을 보려면 다음 전체 코드 예제를 참조하십시오.

• assets에 대한 고급 사용법 예제
• 파티션된 작업 예제
• 모델을 Model Registry에 연결

W&B Launch 사용

계속하기 전에 W&B Launch를 사용하는 방법을 잘 이해하는 것이 좋습니다. Launch 가이드: /guides/launch를 읽어보십시오.

Dagster 통합은 다음을 지원합니다.

• Dagster 인스턴스에서 하나 이상의 Launch 에이전트를 실행합니다.
• Dagster 인스턴스 내에서 로컬 Launch 작업을 실행합니다.
• 온프레미스 또는 클라우드에서 원격 Launch 작업을 실행합니다.

Launch 에이전트

통합은 run_launch_agent라는 가져올 수 있는 @op를 제공합니다. Launch Agent를 시작하고 수동으로 중지할 때까지 장기 실행 프로세스로 실행합니다.

에이전트는 Launch 대기열을 폴링하고 작업을 실행하거나 실행할 외부 서비스에 디스패치하는 프로세스입니다.

구성에 대한 참조 문서를 참조하십시오.

Launchpad에서 모든 속성에 대한 유용한 설명을 볼 수도 있습니다.

간단한 예:

# add this to your config.yaml
# alternatively you can set the config in Dagit's Launchpad or JobDefinition.execute_in_process
# Reference: https://docs.dagster.io/concepts/configuration/config-schema#specifying-runtime-configuration
resources:
 wandb_config:
   config:
     entity: my_entity # replace this with your W&B entity
     project: my_project # replace this with your W&B project
ops:
 run_launch_agent:
   config:
     max_jobs: -1
     queues: 
       - my_dagster_queue

from dagster_wandb.launch.ops import run_launch_agent
from dagster_wandb.resources import wandb_resource

from dagster import job, make_values_resource

@job(
   resource_defs={
       "wandb_config": make_values_resource(
           entity=str,
           project=str,
       ),
       "wandb_resource": wandb_resource.configured(
           {"api_key": {"env": "WANDB_API_KEY"}}
       ),
   },
)
def run_launch_agent_example():
   run_launch_agent()

Launch 작업

통합은 run_launch_job이라는 가져올 수 있는 @op를 제공합니다. Launch 작업을 실행합니다.

Launch 작업은 실행을 위해 대기열에 할당됩니다. 대기열을 만들거나 기본 대기열을 사용할 수 있습니다. 해당 대기열을 수신하는 활성 에이전트가 있는지 확인하십시오. Dagster 인스턴스 내에서 에이전트를 실행할 수 있지만 Kubernetes에서 배포 가능한 에이전트를 사용하는 것도 고려할 수 있습니다.

구성에 대한 참조 문서를 참조하십시오.

Launchpad에서 모든 속성에 대한 유용한 설명을 볼 수도 있습니다.

간단한 예:

# add this to your config.yaml
# alternatively you can set the config in Dagit's Launchpad or JobDefinition.execute_in_process
# Reference: https://docs.dagster.io/concepts/configuration/config-schema#specifying-runtime-configuration
resources:
 wandb_config:
   config:
     entity: my_entity # replace this with your W&B entity
     project: my_project # replace this with your W&B project
ops:
 my_launched_job:
   config:
     entry_point:
       - python
       - train.py
     queue: my_dagster_queue
     uri: https://github.com/wandb/example-dagster-integration-with-launch


from dagster_wandb.launch.ops import run_launch_job
from dagster_wandb.resources import wandb_resource

from dagster import job, make_values_resource


@job(resource_defs={
       "wandb_config": make_values_resource(
           entity=str,
           project=str,
       ),
       "wandb_resource": wandb_resource.configured(
           {"api_key": {"env": "WANDB_API_KEY"}}
       ),
   },
)
def run_launch_job_example():
   run_launch_job.alias("my_launched_job")() # we rename the job with an alias

모범 사례

1. IO Manager를 사용하여 Artifacts를 읽고 씁니다. Artifact.download() 또는 Run.log_artifact()를 직접 사용할 필요가 없습니다. 이러한 메소드는 통합에서 처리합니다. Artifact에 저장하려는 데이터를 반환하고 통합에서 나머지를 처리하도록 합니다. 이렇게 하면 W&B에서 Artifact에 대한 더 나은 계보가 제공됩니다.

2. 복잡한 유스 케이스에 대해서만 Artifact 오브젝트를 직접 빌드합니다. Python 오브젝트 및 W&B 오브젝트는 ops/assets에서 반환되어야 합니다. 통합은 Artifact 번들링을 처리합니다. 복잡한 유스 케이스의 경우 Dagster 작업에서 Artifact를 직접 빌드할 수 있습니다. 소스 통합 이름 및 버전, 사용된 Python 버전, 피클 프로토콜 버전 등과 같은 메타데이터 보강을 위해 Artifact 오브젝트를 통합에 전달하는 것이 좋습니다.

3. 메타데이터를 통해 파일, 디렉토리 및 외부 참조를 Artifacts에 추가합니다. 통합 wandb_artifact_configuration 오브젝트를 사용하여 파일, 디렉토리 또는 외부 참조 (Amazon S3, GCS, HTTP…)를 추가합니다. 자세한 내용은 Artifact 구성 섹션의 고급 예제를 참조하십시오.

4. Artifact가 생성되면 @op 대신 @asset을 사용합니다. Artifacts는 assets입니다. Dagster가 해당 asset을 유지 관리하는 경우 asset을 사용하는 것이 좋습니다. 이렇게 하면 Dagit Asset Catalog에서 더 나은 가시성을 제공합니다.

5. SourceAsset을 사용하여 Dagster 외부에서 생성된 Artifact를 소비합니다. 이를 통해 통합을 활용하여 외부에서 생성된 Artifacts를 읽을 수 있습니다. 그렇지 않으면 통합에서 생성된 Artifacts만 사용할 수 있습니다.

6. W&B Launch를 사용하여 대규모 모델에 대한 전용 컴퓨팅에서 트레이닝을 오케스트레이션합니다. Dagster 클러스터 내부에서 작은 모델을 트레이닝할 수 있으며 GPU 노드가 있는 Kubernetes 클러스터에서 Dagster를 실행할 수 있습니다. 대규모 모델 트레이닝에는 W&B Launch를 사용하는 것이 좋습니다. 이렇게 하면 인스턴스 과부하를 방지하고 더 적절한 컴퓨팅에 액세스할 수 있습니다.

7. Dagster 내에서 실험 추적을 수행할 때 W&B Run ID를 Dagster Run ID 값으로 설정합니다. Run을 재개 가능하게 만들고 W&B Run ID를 Dagster Run ID 또는 원하는 문자열로 설정하는 것이 좋습니다. 이 권장 사항을 따르면 Dagster 내부에서 모델을 트레이닝할 때 W&B 메트릭 및 W&B Artifacts가 동일한 W&B Run에 저장됩니다.

W&B Run ID를 Dagster Run ID로 설정합니다.

wandb.init(
    id=context.run_id,
    resume="allow",
    ...
)

또는 자체 W&B Run ID를 선택하고 IO Manager 구성에 전달합니다.

wandb.init(
    id="my_resumable_run_id",
    resume="allow",
    ...
)

@job(
   resource_defs={
       "io_manager": wandb_artifacts_io_manager.configured(
           {"wandb_run_id": "my_resumable_run_id"}
       ),
   }
)

8. 대규모 W&B Artifacts의 경우 get 또는 get_path로 필요한 데이터만 수집합니다. 기본적으로 통합은 전체 Artifact를 다운로드합니다. 매우 큰 Artifacts를 사용하는 경우 필요한 특정 파일 또는 오브젝트만 수집할 수 있습니다. 이렇게 하면 속도와 리소스 활용도가 향상됩니다.

9. Python 오브젝트의 경우 유스 케이스에 맞게 피클링 모듈을 조정합니다. 기본적으로 W&B 통합은 표준 pickle 모듈을 사용합니다. 그러나 일부 오브젝트는 호환되지 않습니다. 예를 들어 yield가 있는 함수는 피클링하려고 하면 오류가 발생합니다. W&B는 다른 Pickle 기반 직렬화 모듈을 지원합니다 (dill, cloudpickle, joblib).

직렬화된 문자열을 반환하거나 Artifact를 직접 만들어 ONNX 또는 PMML과 같은 고급 직렬화를 사용할 수도 있습니다. 올바른 선택은 유스 케이스에 따라 달라집니다. 이 주제에 대한 사용 가능한 문헌을 참조하십시오.

7.2 - Launch multinode jobs with Volcano

이 튜토리얼에서는 Kubernetes에서 W&B와 Volcano를 사용하여 멀티 노드 트레이닝 작업을 시작하는 과정을 안내합니다.

개요

이 튜토리얼에서는 W&B Launch를 사용하여 Kubernetes에서 멀티 노드 작업을 실행하는 방법을 배웁니다. 따라할 단계는 다음과 같습니다.

• Weights & Biases 계정과 Kubernetes 클러스터가 있는지 확인합니다.
• volcano 작업을 위한 Launch 대기열을 만듭니다.
• Launch 에이전트를 Kubernetes 클러스터에 배포합니다.
• 분산 트레이닝 작업을 만듭니다.
• 분산 트레이닝을 시작합니다.

필수 조건

시작하기 전에 다음이 필요합니다.

• Weights & Biases 계정
• Kubernetes 클러스터

Launch 대기열 만들기

첫 번째 단계는 Launch 대기열을 만드는 것입니다. wandb.ai/launch로 이동하여 화면 오른쪽 상단에서 파란색 대기열 만들기 버튼을 누릅니다. 대기열 생성 창이 화면 오른쪽에서 밀려 나옵니다. 엔티티를 선택하고 이름을 입력한 다음 대기열 유형으로 Kubernetes를 선택합니다.

설정 섹션에서 volcano 작업 템플릿을 입력합니다. 이 대기열에서 시작된 모든 run은 이 작업 사양을 사용하여 생성되므로 필요에 따라 이 설정을 수정하여 작업을 사용자 정의할 수 있습니다.

이 설정 블록은 Kubernetes 작업 사양, volcano 작업 사양 또는 시작하려는 다른 사용자 정의 리소스 정의 (CRD)를 허용할 수 있습니다. 설정 블록에서 매크로를 사용할 수 있습니다를 사용하여 이 사양의 내용을 동적으로 설정할 수 있습니다.

이 튜토리얼에서는 volcano의 pytorch 플러그인을 사용하는 멀티 노드 pytorch 트레이닝에 대한 설정을 사용합니다. 다음 구성을 YAML 또는 JSON으로 복사하여 붙여넣을 수 있습니다.

• YAML
• JSON

kind: Job
spec:
  tasks:
    - name: master
      policies:
        - event: TaskCompleted
          action: CompleteJob
      replicas: 1
      template:
        spec:
          containers:
            - name: master
              image: ${image_uri}
              imagePullPolicy: IfNotPresent
          restartPolicy: OnFailure
    - name: worker
      replicas: 1
      template:
        spec:
          containers:
            - name: worker
              image: ${image_uri}
              workingDir: /home
              imagePullPolicy: IfNotPresent
          restartPolicy: OnFailure
  plugins:
    pytorch:
      - --master=master
      - --worker=worker
      - --port=23456
  minAvailable: 1
  schedulerName: volcano
metadata:
  name: wandb-job-${run_id}
  labels:
    wandb_entity: ${entity_name}
    wandb_project: ${project_name}
  namespace: wandb
apiVersion: batch.volcano.sh/v1alpha1

{
  "kind": "Job",
  "spec": {
    "tasks": [
      {
        "name": "master",
        "policies": [
          {
            "event": "TaskCompleted",
            "action": "CompleteJob"
          }
        ],
        "replicas": 1,
        "template": {
          "spec": {
            "containers": [
              {
                "name": "master",
                "image": "${image_uri}",
                "imagePullPolicy": "IfNotPresent"
              }
            ],
            "restartPolicy": "OnFailure"
          }
        }
      },
      {
        "name": "worker",
        "replicas": 1,
        "template": {
          "spec": {
            "containers": [
              {
                "name": "worker",
                "image": "${image_uri}",
                "workingDir": "/home",
                "imagePullPolicy": "IfNotPresent"
              }
            ],
            "restartPolicy": "OnFailure"
          }
        }
      }
    ],
    "plugins": {
      "pytorch": [
        "--master=master",
        "--worker=worker",
        "--port=23456"
      ]
    },
    "minAvailable": 1,
    "schedulerName": "volcano"
  },
  "metadata": {
    "name": "wandb-job-${run_id}",
    "labels": {
      "wandb_entity": "${entity_name}",
      "wandb_project": "${project_name}"
    },
    "namespace": "wandb"
  },
  "apiVersion": "batch.volcano.sh/v1alpha1"
}

대기열 생성을 완료하려면 창 하단의 대기열 만들기 버튼을 클릭합니다.

Volcano 설치

Kubernetes 클러스터에 Volcano를 설치하려면 공식 설치 가이드를 따르십시오.

Launch 에이전트 배포

대기열을 만들었으므로 대기열에서 작업을 가져와 실행할 Launch 에이전트를 배포해야 합니다. 가장 쉬운 방법은 W&B의 공식 helm-charts 리포지토리에서 launch-agent 차트를 사용하는 것입니다. README의 지침에 따라 차트를 Kubernetes 클러스터에 설치하고 에이전트가 앞에서 만든 대기열을 폴링하도록 구성해야 합니다.

트레이닝 작업 만들기

Volcano의 pytorch 플러그인은 pytorch 코드가 DDP를 올바르게 사용하는 한 MASTER_ADDR, RANK 및 WORLD_SIZE와 같이 pytorch DPP가 작동하는 데 필요한 환경 변수를 자동으로 구성합니다. 사용자 정의 python 코드에서 DDP를 사용하는 방법에 대한 자세한 내용은 pytorch 설명서를 참조하십시오.

Launch 🚀

이제 대기열과 클러스터가 설정되었으므로 분산 트레이닝을 시작할 때입니다. 먼저 volcano의 pytorch 플러그인을 사용하여 임의의 데이터에 대해 간단한 다층 퍼셉트론을 트레이닝하는 작업을 사용합니다. 작업에 대한 소스 코드는 여기에서 찾을 수 있습니다.

이 작업을 시작하려면 작업 페이지로 이동하여 화면 오른쪽 상단에서 Launch 버튼을 클릭합니다. 작업을 시작할 대기열을 선택하라는 메시지가 표시됩니다.

1. 원하는 대로 작업 파라미터를 설정합니다.
2. 앞에서 만든 대기열을 선택합니다.
3. 리소스 구성 섹션에서 volcano 작업을 수정하여 작업의 파라미터를 수정합니다. 예를 들어 worker 작업에서 replicas 필드를 변경하여 작업자 수를 변경할 수 있습니다.
4. Launch 🚀를 클릭합니다.

W&B UI에서 진행 상황을 모니터링하고 필요한 경우 작업을 중지할 수 있습니다.

7.3 - NVIDIA NeMo Inference Microservice Deploy Job

W&B의 모델 아티팩트를 NVIDIA NeMo Inference Microservice에 배포합니다. 이를 위해 W&B Launch를 사용합니다. W&B Launch는 모델 아티팩트를 NVIDIA NeMo Model로 변환하고 실행 중인 NIM/Triton 서버에 배포합니다.

W&B Launch는 현재 다음과 같은 호환 가능한 모델 유형을 지원합니다.

1. Llama2
2. StarCoder
3. NV-GPT (출시 예정)

퀵스타트

1. Launch queue 생성 아직 없는 경우. 아래 예제 queue 구성을 참조하십시오.

   net: host
   gpus: all # can be a specific set of GPUs or `all` to use everything
   runtime: nvidia # also requires nvidia container runtime
   volume:
     - model-store:/model-store/
   

   

2. 다음 작업을 프로젝트에 생성합니다.

   wandb job create -n "deploy-to-nvidia-nemo-inference-microservice" \
      -e $ENTITY \
      -p $PROJECT \
      -E jobs/deploy_to_nvidia_nemo_inference_microservice/job.py \
      -g andrew/nim-updates \
      git https://github.com/wandb/launch-jobs
   

3. GPU 머신에서 에이전트를 실행합니다.

   wandb launch-agent -e $ENTITY -p $PROJECT -q $QUEUE
   

4. Launch UI에서 원하는 구성으로 배포 Launch 작업을 제출합니다.

   1. CLI를 통해 제출할 수도 있습니다.

      wandb launch -d gcr.io/playground-111/deploy-to-nemo:latest \
        -e $ENTITY \
        -p $PROJECT \
        -q $QUEUE \
        -c $CONFIG_JSON_FNAME
      

      

5. Launch UI에서 배포 프로세스를 추적할 수 있습니다.

6. 완료되면 엔드포인트를 즉시 curl하여 모델을 테스트할 수 있습니다. 모델 이름은 항상 ensemble입니다.

    #!/bin/bash
    curl -X POST "http://0.0.0.0:9999/v1/completions" \
        -H "accept: application/json" \
        -H "Content-Type: application/json" \
        -d '{
            "model": "ensemble",
            "prompt": "Tell me a joke",
            "max_tokens": 256,
            "temperature": 0.5,
            "n": 1,
            "stream": false,
            "stop": "string",
            "frequency_penalty": 0.0
            }'
   

7.4 - Spin up a single node GPU cluster with Minikube

GPU 워크로드를 예약하고 실행할 수 있는 Minikube 클러스터에 W&B Launch를 설정합니다.

배경

Nvidia container toolkit을 사용하면 Docker에서 GPU 지원 워크플로우를 쉽게 실행할 수 있습니다. 한 가지 제한 사항은 볼륨별 GPU 예약을 기본적으로 지원하지 않는다는 것입니다. docker run 코맨드로 GPU를 사용하려면 ID별로 특정 GPU를 요청하거나 모든 GPU를 요청해야 하므로 많은 분산 GPU 지원 워크로드가 비실용적입니다. Kubernetes는 볼륨 요청별로 예약을 지원하지만 GPU 예약을 통해 로컬 Kubernetes 클러스터를 설정하는 데 상당한 시간과 노력이 필요할 수 있습니다. 가장 인기 있는 단일 노드 Kubernetes 클러스터 실행 툴 중 하나인 Minikube는 최근에 GPU 예약 지원을 출시했습니다. 🎉 이 튜토리얼에서는 다중 GPU 시스템에서 Minikube 클러스터를 생성하고 W&B Launch 🚀를 사용하여 클러스터에 동시 안정 확산 추론 작업을 실행합니다.

전제 조건

시작하기 전에 다음이 필요합니다.

1. W&B 계정.
2. 다음이 설치 및 실행 중인 Linux 시스템:
   1. Docker 런타임
   2. 사용하려는 GPU 드라이버
   3. Nvidia container toolkit

Launch 작업 대기열 생성

먼저 Launch 작업에 대한 Launch 대기열을 만듭니다.

1. wandb.ai/launch (또는 개인 W&B 서버를 사용하는 경우 <your-wandb-url>/launch)로 이동합니다.
2. 화면 오른쪽 상단에서 파란색 대기열 생성 버튼을 클릭합니다. 대기열 생성 서랍이 화면 오른쪽에서 밀려 나옵니다.
3. 엔티티를 선택하고 이름을 입력한 다음 대기열 유형으로 Kubernetes를 선택합니다.
4. 서랍의 설정 섹션은 Launch 대기열에 대한 Kubernetes 작업 사양을 입력할 위치입니다. 이 대기열에서 실행되는 모든 run은 이 작업 사양을 사용하여 생성되므로 필요에 따라 이 설정을 수정하여 작업을 사용자 정의할 수 있습니다. 이 튜토리얼에서는 아래 샘플 설정을 YAML 또는 JSON으로 대기열 설정에 복사하여 붙여넣을 수 있습니다.

• YAML
• JSON

spec:
  template:
    spec:
      containers:
        - image: ${image_uri}
          resources:
            limits:
              cpu: 4
              memory: 12Gi
              nvidia.com/gpu: '{{gpus}}'
      restartPolicy: Never
  backoffLimit: 0

{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "image": "${image_uri}",
            "resources": {
              "limits": {
                "cpu": 4,
                "memory": "12Gi",
                "nvidia.com/gpu": "{{gpus}}"
              }
            }
          }
        ],
        "restartPolicy": "Never"
      }
    },
    "backoffLimit": 0
  }
}

대기열 설정에 대한 자세한 내용은 Kubernetes에서 Launch 설정 및 고급 대기열 설정 가이드를 참조하십시오.

${image_uri} 및 {{gpus}} 문자열은 대기열 설정에서 사용할 수 있는 두 가지 종류의 변수 템플릿의 예입니다. ${image_uri} 템플릿은 에이전트가 실행하는 작업의 이미지 URI로 대체됩니다. {{gpus}} 템플릿은 작업을 제출할 때 Launch UI, CLI 또는 SDK에서 재정의할 수 있는 템플릿 변수를 만드는 데 사용됩니다. 이러한 값은 작업에서 사용하는 이미지 및 GPU 리소스를 제어하기 위해 올바른 필드를 수정하도록 작업 사양에 배치됩니다.

5. 구성 구문 분석 버튼을 클릭하여 gpus 템플릿 변수 사용자 정의를 시작합니다.
6. 유형을 정수로 설정하고 기본값, 최소값 및 최대값을 원하는 값으로 설정합니다. 템플릿 변수의 제약 조건을 위반하는 이 대기열에 run을 제출하려는 시도는 거부됩니다.

7. 대기열 생성을 클릭하여 대기열을 만듭니다. 새 대기열의 대기열 페이지로 리디렉션됩니다.

다음 섹션에서는 생성한 대기열에서 작업을 가져와 실행할 수 있는 에이전트를 설정합니다.

Docker + NVIDIA CTK 설정

이미 시스템에 Docker 및 Nvidia container toolkit이 설정되어 있는 경우 이 섹션을 건너뛸 수 있습니다.

시스템에 Docker 컨테이너 엔진을 설정하는 방법에 대한 지침은 Docker 설명서를 참조하십시오.

Docker를 설치한 후 Nvidia 설명서의 지침에 따라 Nvidia container toolkit을 설치합니다.

컨테이너 런타임이 GPU에 엑세스할 수 있는지 확인하려면 다음을 실행할 수 있습니다.

docker run --gpus all ubuntu nvidia-smi

시스템에 연결된 GPU를 설명하는 nvidia-smi 출력이 표시됩니다. 예를 들어 설정에서 출력은 다음과 같습니다.

Wed Nov  8 23:25:53 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.105.17   Driver Version: 525.105.17   CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla T4            Off  | 00000000:00:04.0 Off |                    0 |
| N/A   38C    P8     9W /  70W |      2MiB / 15360MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  Tesla T4            Off  | 00000000:00:05.0 Off |                    0 |
| N/A   38C    P8     9W /  70W |      2MiB / 15360MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   2  Tesla T4            Off  | 00000000:00:06.0 Off |                    0 |
| N/A   40C    P8     9W /  70W |      2MiB / 15360MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   3  Tesla T4            Off  | 00000000:00:07.0 Off |                    0 |
| N/A   39C    P8     9W /  70W |      2MiB / 15360MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Minikube 설정

Minikube의 GPU 지원에는 v1.32.0 이상의 버전이 필요합니다. 최신 설치 도움말은 Minikube 설치 설명서를 참조하십시오. 이 튜토리얼에서는 다음 코맨드를 사용하여 최신 Minikube 릴리스를 설치했습니다.

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

다음 단계는 GPU를 사용하여 Minikube 클러스터를 시작하는 것입니다. 시스템에서 다음을 실행합니다.

minikube start --gpus all

위의 코맨드 출력은 클러스터가 성공적으로 생성되었는지 여부를 나타냅니다.

Launch 에이전트 시작

새 클러스터에 대한 Launch 에이전트는 wandb launch-agent를 직접 호출하거나 W&B에서 관리하는 헬름 차트를 사용하여 Launch 에이전트를 배포하여 시작할 수 있습니다.

이 튜토리얼에서는 호스트 시스템에서 직접 에이전트를 실행합니다.

에이전트를 로컬로 실행하려면 기본 Kubernetes API 컨텍스트가 Minikube 클러스터를 참조하는지 확인하십시오. 그런 다음 다음을 실행합니다.

pip install "wandb[launch]"

에이전트의 종속성을 설치합니다. 에이전트 인증을 설정하려면 wandb login을 실행하거나 WANDB_API_KEY 환경 변수를 설정합니다.

에이전트를 시작하려면 다음 코맨드를 실행합니다.

wandb launch-agent -j <max-number-concurrent-jobs> -q <queue-name> -e <queue-entity>

터미널 내에서 Launch 에이전트가 폴링 메시지를 인쇄하기 시작하는 것을 볼 수 있습니다.

축하합니다. Launch 대기열을 폴링하는 Launch 에이전트가 있습니다. 작업이 대기열에 추가되면 에이전트가 작업을 선택하고 Minikube 클러스터에서 실행되도록 예약합니다.

작업 실행

에이전트에 작업을 보내 보겠습니다. W&B 계정에 로그인한 터미널에서 다음을 사용하여 간단한 “hello world"를 실행할 수 있습니다.

wandb launch -d wandb/job_hello_world:main -p <target-wandb-project> -q <your-queue-name> -e <your-queue-entity>

원하는 작업 또는 이미지로 테스트할 수 있지만 클러스터에서 이미지를 가져올 수 있는지 확인하십시오. 자세한 내용은 Minikube 설명서를 참조하십시오. 공개 작업 중 하나를 사용하여 테스트할 수도 있습니다.

(선택 사항) NFS를 사용한 모델 및 데이터 캐싱

ML 워크로드의 경우 여러 작업에서 동일한 데이터에 엑세스해야 하는 경우가 많습니다. 예를 들어 데이터셋 또는 모델 가중치와 같은 대규모 아티팩트를 반복적으로 다운로드하지 않도록 공유 캐시를 사용하고 싶을 수 있습니다. Kubernetes는 영구 볼륨 및 영구 볼륨 클레임을 통해 이를 지원합니다. 영구 볼륨은 Kubernetes 워크로드에서 volumeMounts를 생성하는 데 사용할 수 있으며 공유 캐시에 대한 직접 파일 시스템 엑세스를 제공합니다.

이 단계에서는 모델 가중치에 대한 공유 캐시로 사용할 수 있는 네트워크 파일 시스템 (NFS) 서버를 설정합니다. 첫 번째 단계는 NFS를 설치하고 구성하는 것입니다. 이 프로세스는 운영 체제에 따라 다릅니다. VM이 Ubuntu를 실행 중이므로 nfs-kernel-server를 설치하고 /srv/nfs/kubedata에 내보내기를 구성했습니다.

sudo apt-get install nfs-kernel-server
sudo mkdir -p /srv/nfs/kubedata
sudo chown nobody:nogroup /srv/nfs/kubedata
sudo sh -c 'echo "/srv/nfs/kubedata *(rw,sync,no_subtree_check,no_root_squash,no_all_squash,insecure)" >> /etc/exports'
sudo exportfs -ra
sudo systemctl restart nfs-kernel-server

호스트 파일 시스템에서 서버의 내보내기 위치와 NFS 서버의 로컬 IP 어드레스를 기록해 두십시오. 다음 단계에서 이 정보가 필요합니다.

다음으로 이 NFS에 대한 영구 볼륨 및 영구 볼륨 클레임을 만들어야 합니다. 영구 볼륨은 고도로 사용자 정의할 수 있지만 단순성을 위해 여기서는 간단한 구성을 사용합니다.

아래 yaml을 nfs-persistent-volume.yaml이라는 파일에 복사하고 원하는 볼륨 용량과 클레임 요청을 채우십시오. PersistentVolume.spec.capcity.storage 필드는 기본 볼륨의 최대 크기를 제어합니다. PersistentVolumeClaim.spec.resources.requests.stroage는 특정 클레임에 할당된 볼륨 용량을 제한하는 데 사용할 수 있습니다. 유스 케이스의 경우 각각에 대해 동일한 값을 사용하는 것이 좋습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 100Gi # 원하는 용량으로 설정하십시오.
  accessModes:
    - ReadWriteMany
  nfs:
    server: <your-nfs-server-ip> # TODO: 이 부분을 채우십시오.
    path: '/srv/nfs/kubedata' # 또는 사용자 정의 경로
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi # 원하는 용량으로 설정하십시오.
  storageClassName: ''
  volumeName: nfs-pv

다음을 사용하여 클러스터에서 리소스를 만듭니다.

kubectl apply -f nfs-persistent-volume.yaml

run이 이 캐시를 사용하려면 Launch 대기열 설정에 volumes 및 volumeMounts를 추가해야 합니다. Launch 설정을 편집하려면 wandb.ai/launch (또는 wandb 서버의 사용자의 경우 <your-wandb-url>/launch)로 돌아가서 대기열을 찾고 대기열 페이지를 클릭한 다음 설정 편집 탭을 클릭합니다. 원래 설정을 다음과 같이 수정할 수 있습니다.

• YAML
• JSON

spec:
  template:
    spec:
      containers:
        - image: ${image_uri}
          resources:
            limits:
              cpu: 4
              memory: 12Gi
              nvidia.com/gpu: "{{gpus}}"
					volumeMounts:
            - name: nfs-storage
              mountPath: /root/.cache
      restartPolicy: Never
			volumes:
        - name: nfs-storage
          persistentVolumeClaim:
            claimName: nfs-pvc
  backoffLimit: 0

{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "image": "${image_uri}",
            "resources": {
              "limits": {
                "cpu": 4,
                "memory": "12Gi",
                "nvidia.com/gpu": "{{gpus}}"
              },
              "volumeMounts": [
                {
                  "name": "nfs-storage",
                  "mountPath": "/root/.cache"
                }
              ]
            }
          }
        ],
        "restartPolicy": "Never",
        "volumes": [
          {
            "name": "nfs-storage",
            "persistentVolumeClaim": {
              "claimName": "nfs-pvc"
            }
          }
        ]
      }
    },
    "backoffLimit": 0
  }
}

이제 NFS가 작업 실행 컨테이너의 /root/.cache에 마운트됩니다. 컨테이너가 root가 아닌 다른 사용자로 실행되는 경우 마운트 경로를 조정해야 합니다. Huggingface의 라이브러리와 W&B Artifacts는 모두 기본적으로 $HOME/.cache/를 사용하므로 다운로드는 한 번만 발생해야 합니다.

안정 확산으로 플레이하기

새 시스템을 테스트하기 위해 안정 확산의 추론 파라미터를 실험해 보겠습니다. 기본 프롬프트와 정상적인 파라미터를 사용하여 간단한 안정 확산 추론 작업을 실행하려면 다음을 실행합니다.

wandb launch -d wandb/job_stable_diffusion_inference:main -p <target-wandb-project> -q <your-queue-name> -e <your-queue-entity>

위의 코맨드는 컨테이너 이미지 wandb/job_stable_diffusion_inference:main을 대기열에 제출합니다. 에이전트가 작업을 선택하고 클러스터에서 실행되도록 예약하면 연결에 따라 이미지를 가져오는 데 시간이 걸릴 수 있습니다. wandb.ai/launch (또는 wandb 서버의 사용자의 경우 <your-wandb-url>/launch)의 대기열 페이지에서 작업 상태를 확인할 수 있습니다.

run이 완료되면 지정한 프로젝트에 작업 아티팩트가 있어야 합니다. 프로젝트의 작업 페이지 (<project-url>/jobs)에서 작업 아티팩트를 찾을 수 있습니다. 기본 이름은 job-wandb_job_stable_diffusion_inference여야 하지만 작업 페이지에서 이름을 원하는 대로 변경할 수 있습니다. 작업 이름 옆에 있는 연필 아이콘을 클릭합니다.

이제 이 작업을 사용하여 클러스터에서 더 많은 안정 확산 추론을 실행할 수 있습니다. 작업 페이지에서 오른쪽 상단 모서리에 있는 실행 버튼을 클릭하여 새 추론 작업을 구성하고 대기열에 제출할 수 있습니다. 작업 구성 페이지는 원래 run의 파라미터로 미리 채워지지만 재정의 섹션에서 값을 수정하여 원하는 대로 변경할 수 있습니다. Launch 서랍.