Experiments limits and performance

다음과 같은 권장 범위 내에서 로깅하면 W&B에서 페이지를 더 빠르고 응답성 좋게 유지할 수 있습니다.

로깅 고려 사항

wandb.log를 사용하여 실험 메트릭을 추적합니다. 한 번 로깅되면 이러한 메트릭은 차트를 생성하고 테이블에 표시됩니다. 너무 많은 데이터를 로깅하면 앱이 느려질 수 있습니다.

고유한 메트릭 수

더 빠른 성능을 위해 프로젝트의 총 고유 메트릭 수를 10,000개 미만으로 유지하십시오.

import wandb

wandb.log(
    {
        "a": 1,  # "a"는 고유한 메트릭입니다.
        "b": {
            "c": "hello",  # "b.c"는 고유한 메트릭입니다.
            "d": [1, 2, 3],  # "b.d"는 고유한 메트릭입니다.
        },
    }
)

워크스페이스가 갑자기 느려지면 최근의 runs이 의도치 않게 수천 개의 새로운 메트릭을 로깅했는지 확인하십시오. (수천 개의 플롯이 있는 섹션에 하나 또는 두 개의 runs만 표시되는지 확인하면 가장 쉽게 알 수 있습니다.) 그렇다면 해당 runs을 삭제하고 원하는 메트릭으로 다시 만드는 것을 고려하십시오.

값 너비

단일 로깅된 값의 크기를 1MB 미만으로 제한하고 단일 wandb.log 호출의 총 크기를 25MB 미만으로 제한합니다. 이 제한은 wandb.Image, wandb.Audio 등과 같은 wandb.Media 유형에는 적용되지 않습니다.

# ❌ 권장하지 않음
wandb.log({"wide_key": range(10000000)})

# ❌ 권장하지 않음
with f as open("large_file.json", "r"):
    large_data = json.load(f)
    wandb.log(large_data)

넓은 값은 넓은 값이 있는 메트릭뿐만 아니라 run의 모든 메트릭에 대한 플롯 로드 시간에 영향을 줄 수 있습니다.

메트릭 빈도

로깅하는 메트릭에 적합한 로깅 빈도를 선택하십시오. 일반적으로 메트릭이 넓을수록 로깅 빈도를 줄여야 합니다. W&B는 다음을 권장합니다.

• 스칼라: 메트릭당 로깅된 포인트 <100,000개
• 미디어: 메트릭당 로깅된 포인트 <50,000개
• 히스토그램: 메트릭당 로깅된 포인트 <10,000개

# 총 1백만 단계의 트레이닝 루프
for step in range(1000000):
    # ❌ 권장하지 않음
    wandb.log(
        {
            "scalar": step,  # 스칼라 100,000개
            "media": wandb.Image(...),  # 이미지 100,000개
            "histogram": wandb.Histogram(...),  # 히스토그램 100,000개
        }
    )

    # ✅ 권장
    if step % 1000 == 0:
        wandb.log(
            {
                "histogram": wandb.Histogram(...),  # 히스토그램 10,000개
            },
            commit=False,
        )
    if step % 200 == 0:
        wandb.log(
            {
                "media": wandb.Image(...),  # 이미지 50,000개
            },
            commit=False,
        )
    if step % 100 == 0:
        wandb.log(
            {
                "scalar": step,  # 스칼라 100,000개
            },
            commit=True,
        )  # 일괄 처리된 단계별 메트릭을 함께 커밋합니다.

config 크기

run config의 총 크기를 10MB 미만으로 제한하십시오. 큰 값을 로깅하면 프로젝트 워크스페이스 및 runs 테이블 작업 속도가 느려질 수 있습니다.

# ✅ 권장
wandb.init(
    config={
        "lr": 0.1,
        "batch_size": 32,
        "epochs": 4,
    }
)

# ❌ 권장하지 않음
wandb.init(
    config={
        "steps": range(10000000),
    }
)

# ❌ 권장하지 않음
with f as open("large_config.json", "r"):
    large_config = json.load(f)
    wandb.init(config=large_config)

워크스페이스 고려 사항

Run 수

로드 시간을 줄이려면 단일 프로젝트의 총 run 수를 다음 미만으로 유지하십시오.

• SaaS Cloud에서 100,000개
• 전용 클라우드 또는 자체 관리에서 10,000개

이러한 임계값을 초과하는 Run 수는 프로젝트 워크스페이스 또는 runs 테이블과 관련된 작업 속도를 늦출 수 있습니다. 특히 runs을 그룹화하거나 runs 중에 많은 수의 고유한 메트릭을 수집하는 경우에 그렇습니다. 메트릭 수 섹션도 참조하십시오.

팀이 최근 runs 집합과 같이 동일한 runs 집합에 자주 액세스하는 경우 덜 자주 사용하는 runs을 대량으로 이동하는 것을 고려하여 새로운 “보관” 프로젝트로 이동하고 작업 프로젝트에 더 작은 runs 집합을 남겨두십시오.

워크스페이스 성능

이 섹션에서는 워크스페이스의 성능을 최적화하기 위한 팁을 제공합니다.

패널 수

기본적으로 워크스페이스는 _자동_이며 로깅된 각 키에 대해 표준 패널을 생성합니다. 대규모 프로젝트의 워크스페이스에 많은 로깅된 키에 대한 패널이 포함되어 있으면 워크스페이스 로드 및 사용 속도가 느려질 수 있습니다. 성능을 향상시키려면 다음을 수행할 수 있습니다.

1. 워크스페이스를 수동 모드로 재설정합니다. 수동 모드에는 기본적으로 패널이 포함되어 있지 않습니다.
2. 빠른 추가를 사용하여 시각화해야 하는 로깅된 키에 대한 패널을 선택적으로 추가합니다.

워크스페이스 구성에 대한 자세한 내용은 패널을 참조하십시오.

섹션 수

워크스페이스에 수백 개의 섹션이 있으면 성능이 저하될 수 있습니다. 메트릭의 상위 수준 그룹화를 기반으로 섹션을 만들고 각 메트릭에 대해 하나의 섹션을 만드는 안티 패턴을 피하십시오.

섹션이 너무 많고 성능이 느린 경우 접미사가 아닌 접두사로 섹션을 만드는 워크스페이스 설정을 고려하십시오. 이렇게 하면 섹션 수가 줄어들고 성능이 향상될 수 있습니다.

메트릭 수

Run당 5000~100,000개의 메트릭을 로깅하는 경우 W&B는 수동 워크스페이스를 사용하는 것이 좋습니다. 수동 모드에서는 다양한 메트릭 집합을 탐색하도록 선택할 때 패널을 대량으로 쉽게 추가하고 제거할 수 있습니다. 더 집중적인 플롯 집합을 사용하면 워크스페이스 로드 속도가 빨라집니다. 플롯되지 않은 메트릭은 평소와 같이 계속 수집 및 저장됩니다.

워크스페이스를 수동 모드로 재설정하려면 워크스페이스의 작업 ... 메뉴를 클릭한 다음 워크스페이스 재설정을 클릭합니다. 워크스페이스를 재설정해도 runs에 대한 저장된 메트릭에는 영향을 미치지 않습니다. 워크스페이스 관리에 대해 자세히 알아보십시오.

파일 수

단일 run에 대해 업로드된 총 파일 수를 1,000개 미만으로 유지하십시오. 많은 수의 파일을 로깅해야 하는 경우 W&B Artifacts를 사용할 수 있습니다. 단일 run에서 1,000개가 넘는 파일을 초과하면 run 페이지 속도가 느려질 수 있습니다.

리포트 대 워크스페이스

리포트는 패널, 텍스트 및 미디어를 임의로 배열하여 동료와 통찰력을 쉽게 공유할 수 있는 자유 형식의 컴포지션입니다.

대조적으로 워크스페이스는 수백에서 수십만 개의 runs에 걸쳐 수십에서 수천 개의 메트릭을 고밀도로 효율적으로 분석할 수 있습니다. 워크스페이스는 리포트에 비해 최적화된 캐싱, 쿼리 및 로드 기능을 제공합니다. 워크스페이스는 주로 프레젠테이션보다는 분석에 사용되는 프로젝트에 권장되거나 20개 이상의 플롯을 함께 표시해야 하는 경우에 권장됩니다.

Python 스크립트 성능

Python 스크립트의 성능이 저하되는 몇 가지 방법이 있습니다.

1. 데이터 크기가 너무 큽니다. 데이터 크기가 크면 트레이닝 루프에 >1ms의 오버헤드가 발생할 수 있습니다.
2. 네트워크 속도와 W&B 백엔드 구성 방법
3. wandb.log를 초당 몇 번 이상 호출합니다. 이는 wandb.log가 호출될 때마다 트레이닝 루프에 작은 대기 시간이 추가되기 때문입니다.

W&B는 속도 제한 외에는 어떠한 제한도 주장하지 않습니다. W&B Python SDK는 제한을 초과하는 요청에 대해 지수 “백오프” 및 “재시도"를 자동으로 완료합니다. W&B Python SDK는 커맨드라인에 “네트워크 실패"로 응답합니다. 유료 계정이 아닌 경우 W&B는 사용량이 합리적인 임계값을 초과하는 극단적인 경우에 연락할 수 있습니다.

속도 제한

W&B SaaS Cloud API는 시스템 무결성을 유지하고 가용성을 보장하기 위해 속도 제한을 구현합니다. 이 측정은 단일 사용자가 공유 인프라에서 사용 가능한 리소스를 독점하는 것을 방지하여 모든 사용자가 서비스에 액세스할 수 있도록 보장합니다. 다양한 이유로 더 낮은 속도 제한이 발생할 수 있습니다.

속도 제한 HTTP 헤더

이전 표에서는 속도 제한 HTTP 헤더에 대해 설명합니다.

메트릭 로깅 API의 속도 제한

스크립트의 wandb.log 호출은 메트릭 로깅 API를 사용하여 트레이닝 데이터를 W&B에 로깅합니다. 이 API는 온라인 또는 오프라인 동기화를 통해 사용됩니다. 두 경우 모두 롤링 시간 창에서 속도 제한 할당량을 부과합니다. 여기에는 총 요청 크기 및 요청 속도에 대한 제한이 포함되며, 후자는 시간 기간 내의 요청 수를 나타냅니다.

W&B는 W&B 프로젝트당 속도 제한을 적용합니다. 따라서 팀에 3개의 프로젝트가 있는 경우 각 프로젝트에는 자체 속도 제한 할당량이 있습니다. 팀 및 엔터프라이즈 요금제 사용자는 무료 요금제 사용자보다 더 높은 속도 제한을 받습니다.

메트릭 로깅 API를 사용하는 동안 속도 제한에 도달하면 표준 출력에 오류를 나타내는 관련 메시지가 표시됩니다.

메트릭 로깅 API 속도 제한을 초과하지 않기 위한 제안

속도 제한을 초과하면 속도 제한이 재설정될 때까지 run.finish()가 지연될 수 있습니다. 이를 방지하려면 다음 전략을 고려하십시오.

• W&B Python SDK 버전 업데이트: 최신 버전의 W&B Python SDK를 사용하고 있는지 확인하십시오. W&B Python SDK는 정기적으로 업데이트되며 요청을 정상적으로 재시도하고 할당량 사용량을 최적화하기 위한 향상된 메커니즘이 포함되어 있습니다.
• 메트릭 로깅 빈도 줄이기: 할당량을 보존하기 위해 메트릭 로깅 빈도를 최소화합니다. 예를 들어, 모든 에포크 대신 5개의 에포크마다 메트릭을 로깅하도록 코드를 수정할 수 있습니다.

if epoch % 5 == 0:  # 5개의 에포크마다 메트릭 로깅
    wandb.log({"acc": accuracy, "loss": loss})

• 수동 데이터 동기화: 속도 제한이 있는 경우 W&B는 run 데이터를 로컬에 저장합니다. 커맨드 wandb sync <run-file-path>를 사용하여 데이터를 수동으로 동기화할 수 있습니다. 자세한 내용은 wandb sync 참조를 참조하십시오.

GraphQL API의 속도 제한

W&B Models UI 및 SDK의 공용 API는 서버에 GraphQL 요청을 보내 데이터를 쿼리하고 수정합니다. SaaS Cloud의 모든 GraphQL 요청에 대해 W&B는 권한이 없는 요청에 대해 IP 어드레스당, 권한이 있는 요청에 대해 사용자당 속도 제한을 적용합니다. 제한은 고정 시간 창 내의 요청 속도(초당 요청)를 기반으로 하며, 요금제에 따라 기본 제한이 결정됩니다. 프로젝트 경로(예: 리포트, runs, 아티팩트)를 지정하는 관련 SDK 요청의 경우 W&B는 데이터베이스 쿼리 시간으로 측정하여 프로젝트당 속도 제한을 적용합니다.

팀 및 엔터프라이즈 요금제 사용자는 무료 요금제 사용자보다 더 높은 속도 제한을 받습니다. W&B Models SDK의 공용 API를 사용하는 동안 속도 제한에 도달하면 표준 출력에 오류를 나타내는 관련 메시지가 표시됩니다.

GraphQL API 속도 제한을 초과하지 않기 위한 제안

W&B Models SDK의 공용 API를 사용하여 많은 양의 데이터를 가져오는 경우 요청 사이에 최소 1초 이상 기다리는 것을 고려하십시오. 429 상태 코드를 받거나 응답 헤더에 RateLimit-Remaining=0이 표시되면 재시도하기 전에 RateLimit-Reset에 지정된 시간(초) 동안 기다리십시오.

브라우저 고려 사항

W&B 앱은 메모리 사용량이 많을 수 있으며 Chrome에서 가장 잘 작동합니다. 컴퓨터의 메모리에 따라 W&B가 3개 이상의 탭에서 동시에 활성화되어 있으면 성능이 저하될 수 있습니다. 예기치 않게 느린 성능이 발생하는 경우 다른 탭이나 애플리케이션을 닫는 것을 고려하십시오.

W&B에 성능 문제 보고

W&B는 성능을 중요하게 생각하고 지연에 대한 모든 리포트를 조사합니다. 조사를 신속하게 처리하기 위해 로드 시간이 느린 경우 주요 메트릭 및 성능 이벤트를 캡처하는 W&B의 기본 제공 성능 로거를 호출하는 것을 고려하십시오. 로드 속도가 느린 페이지에 URL 파라미터 &PERF_LOGGING을 추가한 다음 콘솔 출력을 계정 팀 또는 지원팀과 공유하십시오.