이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

Launch integration guides

1: Dagster
2: Launch multinode jobs with Volcano
3: NVIDIA NeMo Inference Microservice Deploy Job
4: Spin up a single node GPU cluster with Minikube

1 - Dagster

W&B를 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를 사용하려면 다음 리소스가 필요합니다.

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

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

API 키를 얻는 방법

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

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

@job에 대한 구성 예시

# 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()

assets를 사용하는 @repository에 대한 구성 예시

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
                   }
               }
           },
       ),
   ]

@job에 대한 예제와는 달리 이 예제에서는 IO Manager 캐시 지속 시간을 구성합니다.

구성

다음 구성 옵션은 통합에서 제공하는 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를 쓰는 방법을 보여줍니다.

pickle 모듈로 직렬화할 수 있는 모든 항목이 피클링되고 통합에서 생성된 Artifact에 추가됩니다. 콘텐츠는 Dagster 내부에서 해당 Artifact를 읽을 때 피클링 해제됩니다 (자세한 내용은 Artifacts 읽기 참조).

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

W&B는 여러 Pickle 기반 직렬화 모듈을 지원합니다 (pickle, dill, cloudpickle, joblib). ONNX 또는 PMML과 같은 고급 직렬화를 사용할 수도 있습니다. 자세한 내용은 직렬화 섹션을 참조하십시오.

모든 기본 W&B 오브젝트 (예: Table, Image 또는 Graph)가 통합에서 생성된 Artifact에 추가됩니다. 다음은 Table을 사용하는 예입니다.

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]])

복잡한 유스 케이스의 경우 자체 Artifact 오브젝트를 빌드해야 할 수 있습니다. 통합은 여전히 통합 양쪽에서 메타데이터를 보강하는 것과 같은 유용한 추가 기능을 제공합니다.

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 계산에서 사전을 구성하는 방법을 보여줍니다.

@op의 예시:

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

@asset의 예시:

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

@asset에는 이미 이름이 있으므로 구성을 통해 이름을 전달할 필요가 없습니다. 통합은 Artifact 이름을 asset 이름으로 설정합니다.

@multi_asset의 예시:

@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에서 어떻게 보강되었는지 보여줍니다. 이 정보는 재현성 및 유지 관리에 도움이 되어야 합니다. 통합 없이는 사용할 수 없습니다.

mypy와 같은 정적 유형 검사기를 사용하는 경우 다음을 사용하여 구성 유형 정의 오브젝트를 가져옵니다.

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에서 실행할 수 있습니다.

고급 사용법

W&B Artifacts 읽기

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

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

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

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

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

@op에서 Artifact 읽기

@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에서 생성한 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)

Dagster 외부에서 생성한 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가 데코레이팅된 함수에 대한 입력으로 수집하고 제공해야 하는 항목을 나타내는 데 사용됩니다. 다음과 같은 읽기 패턴이 지원됩니다.

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"))

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)

전체 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 기반 직렬화 모듈

피클링은 안전하지 않은 것으로 알려져 있습니다. 보안이 우려되는 경우 W&B 오브젝트만 사용하십시오. 데이터를 서명하고 해시 키를 자체 시스템에 저장하는 것이 좋습니다. 더 복잡한 유스 케이스의 경우 주저하지 말고 저희에게 연락하십시오. 기꺼이 도와드리겠습니다.

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 기반 직렬화보다 더 많은 작업이 필요합니다.

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

모델을 선택한 형식으로 변환한 다음 해당 형식의 문자열 표현을 일반 Python 오브젝트인 것처럼 반환합니다. 통합은 해당 문자열을 피클링합니다. 그런 다음 해당 문자열을 사용하여 모델을 다시 빌드할 수 있습니다.
직렬화된 모델로 새 로컬 파일을 만든 다음 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 콘텐츠를 각각 나타내는 키와 값으로 사전에서 제공됩니다.

업스트림 @asset의 모든 파티션을 읽습니다. 이는 사전으로 제공됩니다. 이 사전에서 키와 값은 각각 파티션 키와 Artifact 콘텐츠와 관련됩니다.

@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}")

AssetIn의 partition_mapping 구성을 통해 특정 파티션을 선택할 수 있습니다. 이 경우 TimeWindowPartitionMapping을 사용합니다.

@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라는 여러 키가 포함될 수 있습니다.

구성 키

get: get 키는 데이터를 가져올 W&B 오브젝트 (Table, Image…)의 이름을 지정합니다.
version: Artifact에 대한 특정 버전을 가져오려는 경우 version 키가 사용됩니다.
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라고 함).

고급 사용법

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

W&B Launch 사용

활발히 개발 중인 베타 제품 Launch에 관심이 있으십니까? W&B Launch에 대한 고객 파일럿 프로그램에 참여하는 것에 대해 논의하려면 계정 팀에 문의하십시오. 파일럿 고객은 베타 프로그램에 참여하려면 AWS EKS 또는 SageMaker를 사용해야 합니다. 궁극적으로 추가 플랫폼을 지원할 계획입니다.

계속하기 전에 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

모범 사례

IO Manager를 사용하여 Artifacts를 읽고 씁니다. Artifact.download() 또는 Run.log_artifact()를 직접 사용할 필요가 없습니다. 이러한 메소드는 통합에서 처리합니다. Artifact에 저장하려는 데이터를 반환하고 통합에서 나머지를 처리하도록 합니다. 이렇게 하면 W&B에서 Artifact에 대한 더 나은 계보가 제공됩니다.
복잡한 유스 케이스에 대해서만 Artifact 오브젝트를 직접 빌드합니다. Python 오브젝트 및 W&B 오브젝트는 ops/assets에서 반환되어야 합니다. 통합은 Artifact 번들링을 처리합니다. 복잡한 유스 케이스의 경우 Dagster 작업에서 Artifact를 직접 빌드할 수 있습니다. 소스 통합 이름 및 버전, 사용된 Python 버전, 피클 프로토콜 버전 등과 같은 메타데이터 보강을 위해 Artifact 오브젝트를 통합에 전달하는 것이 좋습니다.
메타데이터를 통해 파일, 디렉토리 및 외부 참조를 Artifacts에 추가합니다. 통합 wandb_artifact_configuration 오브젝트를 사용하여 파일, 디렉토리 또는 외부 참조 (Amazon S3, GCS, HTTP…)를 추가합니다. 자세한 내용은 Artifact 구성 섹션의 고급 예제를 참조하십시오.
Artifact가 생성되면 @op 대신 @asset을 사용합니다. Artifacts는 assets입니다. Dagster가 해당 asset을 유지 관리하는 경우 asset을 사용하는 것이 좋습니다. 이렇게 하면 Dagit Asset Catalog에서 더 나은 가시성을 제공합니다.
SourceAsset을 사용하여 Dagster 외부에서 생성된 Artifact를 소비합니다. 이를 통해 통합을 활용하여 외부에서 생성된 Artifacts를 읽을 수 있습니다. 그렇지 않으면 통합에서 생성된 Artifacts만 사용할 수 있습니다.
W&B Launch를 사용하여 대규모 모델에 대한 전용 컴퓨팅에서 트레이닝을 오케스트레이션합니다. Dagster 클러스터 내부에서 작은 모델을 트레이닝할 수 있으며 GPU 노드가 있는 Kubernetes 클러스터에서 Dagster를 실행할 수 있습니다. 대규모 모델 트레이닝에는 W&B Launch를 사용하는 것이 좋습니다. 이렇게 하면 인스턴스 과부하를 방지하고 더 적절한 컴퓨팅에 액세스할 수 있습니다.
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"}
       ),
   }
)

대규모 W&B Artifacts의 경우 get 또는 get_path로 필요한 데이터만 수집합니다. 기본적으로 통합은 전체 Artifact를 다운로드합니다. 매우 큰 Artifacts를 사용하는 경우 필요한 특정 파일 또는 오브젝트만 수집할 수 있습니다. 이렇게 하면 속도와 리소스 활용도가 향상됩니다.
Python 오브젝트의 경우 유스 케이스에 맞게 피클링 모듈을 조정합니다. 기본적으로 W&B 통합은 표준 pickle 모듈을 사용합니다. 그러나 일부 오브젝트는 호환되지 않습니다. 예를 들어 yield가 있는 함수는 피클링하려고 하면 오류가 발생합니다. W&B는 다른 Pickle 기반 직렬화 모듈을 지원합니다 (dill, cloudpickle, joblib).

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

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으로 복사하여 붙여넣을 수 있습니다.

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 설명서를 참조하십시오.

Volcano의 pytorch 플러그인은 PyTorch Lightning Trainer를 통한 멀티 노드 트레이닝과도 호환됩니다.

Launch 🚀

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

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

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

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

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는 현재 다음과 같은 호환 가능한 모델 유형을 지원합니다.

Llama2
StarCoder
NV-GPT (출시 예정)

배포 시간은 모델 및 머신 유형에 따라 다릅니다. 기본 Llama2-7b 구성은 GCP의 a2-ultragpu-1g에서 약 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/

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

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

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

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

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

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

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

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

완료되면 엔드포인트를 즉시 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
         }'

4 - Spin up a single node GPU cluster with Minikube

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

이 튜토리얼은 여러 개의 GPU가 있는 시스템에 직접 엑세스할 수 있는 사용자를 안내하기 위한 것입니다. 클라우드 시스템을 임대하는 사용자에게는 적합하지 않습니다.

클라우드 시스템에 Minikube 클러스터를 설정하려면 클라우드 공급자를 사용하여 GPU를 지원하는 Kubernetes 클러스터를 만드는 것이 좋습니다. 예를 들어 AWS, GCP, Azure, Coreweave 및 기타 클라우드 공급자에는 GPU를 지원하는 Kubernetes 클러스터를 생성하는 툴이 있습니다.

단일 GPU가 있는 시스템에서 GPU 예약을 위해 Minikube 클러스터를 설정하려면 Launch Docker queue를 사용하는 것이 좋습니다. 재미로 튜토리얼을 따라 할 수는 있지만 GPU 예약은 그다지 유용하지 않습니다.

배경

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

전제 조건

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

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

이 튜토리얼을 테스트하고 만드는 데 4개의 NVIDIA Tesla T4 GPU가 연결된 n1-standard-16 Google Cloud Compute Engine 인스턴스를 사용했습니다.

Launch 작업 대기열 생성

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

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

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

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

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

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 에이전트를 배포하여 시작할 수 있습니다.

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

컨테이너 외부에서 에이전트를 실행한다는 것은 로컬 Docker 호스트를 사용하여 클러스터에서 실행할 이미지를 빌드할 수 있음을 의미합니다.

에이전트를 로컬로 실행하려면 기본 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)로 돌아가서 대기열을 찾고 대기열 페이지를 클릭한 다음 설정 편집 탭을 클릭합니다. 원래 설정을 다음과 같이 수정할 수 있습니다.

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 서랍.