> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-docs-weave-byob-note.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > 이 페이지에서는 로깅 패턴이 W&B 성능에 미치는 영향을 설명하고, 대규모 프로젝트에서 실험 추적을 확장하기 위한 지침을 제공합니다. # 대규모 로깅과 성능 성능은 일반적으로 다음 요소가 복합적으로 작용해 영향을 받습니다. * 프로젝트의 run 수 * 각 run의 step 수 * 로깅하는 고유 메트릭 수 * `wandb.Run.log()`를 호출하는 빈도 * 각 log 호출에서 전송하는 데이터 양 * 워크스페이스 구성 방식 대부분의 경우 성능 문제는 step을 너무 많이 로깅해서보다 고유 메트릭을 너무 많이 로깅해서 발생하는 경우가 더 많습니다.
## 주요 용어
다음 용어는 이 페이지 전반에서 사용됩니다.
### Steps
**step**은 run에서 메트릭의 단일 논리적 행을 의미합니다. `wandb.Run.log()`가 `commit=True`로 호출되면 step이 확정되며, `commit`과 `step`을 둘 다 지정하지 않은 경우에도 암묵적으로 확정됩니다. ```python theme={null} import wandb with wandb.init() as run: run.log({"loss": 0.42}, commit=True) ```
### 메트릭 카디널리티
**메트릭 카디널리티**는 중첩된 딕셔너리의 키를 포함해, 프로젝트에 로깅된 서로 다른 메트릭 키의 개수입니다. 예를 들어, 다음과 같이 로깅하면 서로 다른 메트릭 키 `a`, `b.c`, `b.d.e`, `b.d.f` 4개가 생성됩니다. ```python theme={null} import wandb with wandb.init() as run: run.log( { "a": 1, "b": { "c": 2, "d": { "e": 3, "f": 4, }, }, } ) ``` W\&B는 중첩된 딕셔너리를 펼쳐 점(.)으로 구분된 메트릭 이름으로 변환합니다.
### 로깅된 포인트
**로깅된 포인트**는 기록된 메트릭 값의 총 개수입니다. 예를 들어, 다음 두 코드 예시는 모두 로깅된 포인트를 3개 생성합니다: ```python theme={null} import wandb with wandb.init() as run: run.log({"a": 1, "b": 2, "c": 3}) ``` ```python theme={null} import wandb with wandb.init() as run: run.log({"a": 1}) run.log({"a": 2}) run.log({"a": 3}) ```
### 로그 빈도
**로그 빈도**는 분당 `wandb.Run.log()` Call 횟수입니다. ```text theme={null} log frequency = wandb.Run.log() calls per minute ```
### 처리량
**처리량**은 분당 로깅된 포인트의 총개수입니다. 처리량은 다음과 같이 생각할 수 있습니다: ```text theme={null} throughput = logged points per minute ``` 또는 다음과 같이 쓸 수 있습니다: ```text theme={null} throughput = logged points × log frequency ```
## 대규모 환경에서의 권장 사항
이 section에 설명된 권장 사항은 W\&B Multi-tenant Cloud에만 적용됩니다. 다른 W\&B 배포 유형을 사용하는 경우, 배포별 지침이나 limits는 관리자에게 확인하세요. 다음 표는 대규모 로깅에 권장되는 운영 범위를 요약한 것입니다. | Dimension | Guidance at scale | | --------------- | ----------------- | | 프로젝트당 Runs | 10,000 | | run당 step 수 | 500,000 | | 프로젝트당 메트릭 카디널리티 | 100,000 | | 로그 빈도 | 분당 1,000행 | | 처리량 | 분당 100,000개 값 | | 비디오 처리량 | 분당 40 MB | 이 값은 대규모 환경에서 우수한 성능을 유지하기 위한 가이드라인입니다. W\&B는 이러한 권장 범위를 초과하는 데이터도 계속 수용할 수 있지만, 페이지 로드 및 사용 속도가 느려질 수 있습니다.
## 처리량 예시
로깅 방식이 달라도 동일한 처리량이 나올 수 있습니다.
### 스칼라 로깅 예시
표에 나열된 값은 W\&B Multi-tenant Cloud에만 적용됩니다. 다른 W\&B 배포 유형을 사용하는 경우, 배포별 지침이나 제한 사항은 관리자에게 문의하세요. | 로그 호출당 메트릭 수 | 로그 빈도(분당 호출 수) | 처리량(분당 값 수) | | ------------ | -------------- | ----------- | | 100 | 1,000 | 100,000 | | 1,000 | 100 | 100,000 | | 10,000 | 10 | 100,000 | | 20,000 | 5 | 100,000 |
### 비디오 로깅 예시
표에 나열된 값은 W\&B Multi-tenant Cloud에만 적용됩니다. 다른 W\&B 배포 유형을 사용하는 경우, 해당 배포에 맞는 지침이나 제한 사항은 관리자에게 문의하세요. | 비디오 크기 (MB) | 로그 빈도 (분당) | 비디오 처리량 (MB/분) | | ----------- | ---------- | -------------- | | 1 | 46 | 46 | | 5 | 8 | 40 | | 10 | 4 | 40 | | 50 | 1 | 50 | | 100 | 0.3 | 30 | | 250 | 0.1 | 25 | | 500 | 0.07 | 35 |
## 로깅 시 고려 사항
실험 메트릭을 추적하려면 `wandb.Run.log()`를 사용하세요.
### 메트릭 카디널리티
프로젝트의 전체 메트릭 카디널리티(고유한 메트릭 수)는 워크로드에 권장되는 범위 내로 유지하세요. 메트릭 카디널리티가 높으면 워크스페이스가 느려지는 가장 흔한 원인 중 하나가 됩니다. 성능 문제는 step을 너무 많이 로깅해서가 아니라, 서로 다른 메트릭을 너무 많이 로깅해서 발생하는 경우가 많습니다. W\&B는 중첩된 키를 점으로 구분된 메트릭 이름으로 평탄화하므로, 메트릭 카디널리티가 예상보다 더 많이 증가할 수 있습니다. 예를 들어, 다음은 `a`, `b.c`, `b.d`라는 3개의 고유한 메트릭 키를 로깅합니다. ```python theme={null} import wandb with wandb.init() as run: run.log( { "a": 1, "b": { "c": "hello", "d": [1, 2, 3], }, } ) ``` 워크스페이스가 갑자기 느려졌다면, 최근 run에서 새로운 metric 키가 대량으로 생성되었는지 확인하세요. 이런 경우에는 run이 한두 개만 표시되는 plot이 많이 나타나는 경우가 많습니다. 의도치 않게 이런 일이 발생했다면, metric 이름 집합을 더 적고 안정적으로 구성해 해당 run을 삭제한 뒤 다시 생성하는 것을 고려해 보세요.
### 값 크기
단일 로깅 값의 크기는 1 MB 미만으로 유지하고, 단일 `wandb.Run.log()` 호출의 총 크기는 25 MB 미만으로 유지하세요. 이 권장 사항은 `wandb.Image` 및 `wandb.Audio`와 같은 `wandb.Media` 유형에는 적용되지 않습니다. 이러한 유형은 별도로 처리됩니다. ```python theme={null} import json import wandb with wandb.init(project="wide-values") as run: # 권장하지 않음 run.log({"wide_key": list(range(10000000))}) # 권장하지 않음 with open("large_file.json", "r") as f: large_data = json.load(f) run.log(large_data) ``` 큰 값은 해당 값을 포함한 메트릭뿐 아니라 전체 run의 플롯 로딩 속도도 늦출 수 있습니다. W\&B는 이러한 권장 사항을 초과해 로깅된 데이터도 계속 저장하지만, 페이지가 더 느리게 로드될 수 있습니다.
### 로그 빈도와 처리량
수집하는 데이터의 가치에 맞는 로깅 빈도를 선택하세요. 너무 자주 로깅하면 SDK 오버헤드가 증가하고 앱이 느려질 수 있으며, 특히 메트릭 카디널리티가 높거나 페이로드가 큰 경우 그 영향이 더 커집니다. 시작할 때는 다음 가이드라인을 기준으로 로깅하세요. * 로그 빈도: 분당 `wandb.Run.log()` Call 1,000회 미만 * 처리량: 분당 로깅된 값 100,000개 미만 * 비디오 처리량: 분당 40 MB 미만 가능하면 관련 메트릭을 같은 step에 묶어 로깅하세요. 예를 들어, 다음 코드 스니펫은 세 개의 메트릭을 동일한 step에 로깅하므로 각각 따로 로깅하는 것보다 더 효율적입니다. ```python theme={null} import wandb with wandb.init(project="metric-frequency") as run: # 권장: 관련 스칼라 메트릭을 함께 묶어서 기록 run.log( { "loss": 0.12, "accuracy": 0.98, "lr": 1e-4, }, commit=True, ) ```
### 설정 크기
run 설정의 전체 크기를 10MB 미만으로 유지하세요. 큰 설정은 프로젝트 워크스페이스와 Runs table 오퍼레이션을 느리게 할 수 있습니다. ```python theme={null} import json import wandb # 권장 with wandb.init( project="config-size", config={ "lr": 0.1, "batch_size": 32, "epochs": 4, }, ) as run: pass # 권장하지 않음 with wandb.init( project="config-size", config={ "large_list": list(range(10000000)), "large_string": "a" * 10000000, }, ) as run: pass # 권장하지 않음 with open("large_config.json", "r") as f: large_config = json.load(f) wandb.init(config=large_config) ```
## 워크스페이스 성능
워크스페이스 성능은 기반이 되는 프로젝트 데이터와 워크스페이스 설정 모두에 따라 달라집니다.
### 프로젝트당 Runs
규모가 큰 프로젝트의 경우 최적의 성능을 위해 프로젝트 내 Runs 수를 10,000개 미만으로 유지하세요. 팀에서 정기적으로 Runs의 일부만 사용하는 경우, 오래되었거나 사용 빈도가 낮은 Runs를 별도의 아카이브 프로젝트로 옮기는 것을 고려하세요. [Runs 관리](/ko/models/runs/manage-runs/)를 참조하세요.
### 패널 수
기본적으로 자동 모드의 워크스페이스는 로깅된 각 키에 대해 표준 패널을 생성합니다. 규모가 큰 Projects에서는 이로 인해 패널이 지나치게 많이 생성되어 워크스페이스가 느려질 수 있습니다. 성능을 개선하려면: 1. 워크스페이스를 수동 모드로 재설정하세요. 2. [Quick add](/ko/models/app/features/panels/#quick-add)를 사용해 필요한 패널만 추가하세요. 사용하지 않는 패널을 하나씩 삭제해도 대개 효과가 거의 없습니다. 워크스페이스를 재설정한 후 원하는 패널만 다시 추가하세요. 자세한 내용은 [Panels](/ko/models/app/features/panels/)를 참조하세요.
### 섹션 수
워크스페이스에 섹션이 수백 개 있으면 성능이 저하될 수 있습니다. 메트릭마다 섹션을 하나씩 만드는 대신, 메트릭을 상위 수준으로 그룹화해 섹션을 만드세요. 섹션이 너무 많다면, 관련 메트릭이 더 적은 수의 섹션으로 그룹화되도록 접미사 대신 접두사를 기준으로 섹션을 만드는 것을 고려하세요. 섹션 생성 표시/숨기기
### run당 많은 메트릭
run당 수천 개의 메트릭을 로깅하는 경우, 시각화할 메트릭을 선택할 수 있도록 수동 워크스페이스를 사용하세요. 더 집중된 플롯 집합을 사용하면 워크스페이스가 더 빠르게 로드됩니다. 플롯되지 않은 메트릭도 평소와 같이 계속 수집되고 저장됩니다. 워크스페이스를 수동 모드로 재설정하려면, 워크스페이스의 **작업 ()** 메뉴를 클릭한 다음 **워크스페이스 재설정**을 클릭합니다. 워크스페이스를 재설정해도 run에 저장된 메트릭에는 영향을 주지 않습니다. [워크스페이스 패널 관리](/ko/models/app/features/panels/)를 참조하세요.
### 파일 수
단일 run에 업로드하는 파일 수는 1,000개 미만으로 유지하세요. 많은 파일을 log해야 하는 경우에는 대신 W\&B Artifacts를 사용하세요. 단일 run에서 파일 수가 1,000개를 초과하면 run 페이지가 느려질 수 있습니다.
### Reports 및 워크스페이스
Report는 커뮤니케이션과 프레젠테이션용으로 설계되었습니다. 워크스페이스는 많은 Runs와 메트릭 전반에 걸쳐 밀도 높은 대화형 분석을 수행하도록 설계되었습니다. 많은 수의 Runs를 비교하거나 여러 plot을 함께 봐야 할 때는 워크스페이스를 사용하세요. 선별한 결과를 제시하려는 경우에는 Report를 사용하세요.
## Python 스크립트 성능
로깅은 트레이닝 스크립트에 오버헤드를 유발할 수 있습니다. 주요 원인은 다음과 같습니다. 1. 큰 페이로드 2. 네트워크 속도 및 백엔드 설정 3. `wandb.Run.log()`를 매우 자주 호출하는 경우 `wandb.Run.log()`를 너무 자주 호출하면 호출할 때마다 트레이닝 루프에 약간의 지연이 추가될 수 있습니다. 여러 메트릭을 더 적은 횟수의 log 호출로 묶으면 일반적으로 성능이 개선됩니다. 잦은 로깅 때문에 트레이닝 run이 느려지고 있나요? 로깅 패턴을 조정해 성능을 개선하는 전략은 [이 Colab](https://wandb.me/log-hf-colab)에서 확인하세요. W\&B는 API 요청 속도 제한 외에는 이러한 권장 사항에 대해 엄격한 제품 제한을 강제 적용하지 않습니다. 이 페이지의 가이드를 초과하더라도 W\&B가 데이터를 계속 수집할 수는 있지만, 앱 또는 SDK가 느려질 수 있습니다.
## 요청 속도 제한
W\&B Multi-tenant Cloud API는 서비스 안정성과 가용성을 유지하기 위해 요청 속도 제한을 적용합니다. 요청 속도 제한은 변경될 수 있습니다. 요청 속도 제한에 걸리면 서버는 HTTP `429 Rate limit exceeded`를 반환하며, 응답에는 요청 속도 제한 헤더가 포함됩니다.
### 요청 속도 제한 HTTP 헤더
| Header name | 설명 | | --------------------- | ----------------------------------------- | | `RateLimit-Limit` | 현재 시간 창에서 사용 가능한 할당량으로, 0\~1000 범위로 조정됩니다 | | `RateLimit-Remaining` | 현재 창에서 남아 있는 할당량으로, 0\~1000 범위로 조정됩니다 | | `RateLimit-Reset` | 현재 할당량이 재설정될 때까지 남은 초 수 |
### 메트릭 로깅 API 요청 속도 제한
`wandb.Run.log()`는 트레이닝 데이터를 W\&B로 전송합니다. 온라인에서 직접 전송하거나 나중에 [오프라인 동기화](/ko/models/ref/cli/wandb-sync)를 통해 전송할 수 있습니다. 메트릭 로깅에 대한 요청 속도 제한은 프로젝트 수준에서 적용되며, 일정 시간 동안의 요청 속도와 총 요청 크기를 모두 기준으로 합니다. 유료 플랜은 무료 플랜보다 한도가 더 높습니다. 요청 속도 제한을 초과하면 W\&B SDK가 자동으로 백오프를 적용해 요청을 재시도합니다. 경우에 따라 요청 속도 제한 기간이 재설정될 때까지 `run.finish()`가 지연될 수 있습니다. 요청 속도 제한에 걸릴 가능성을 줄이려면 다음을 수행하세요. * 최신 W\&B SDK 버전을 사용하세요. * 로깅 빈도를 줄이세요. * 관련 메트릭을 묶어 `log` 호출 횟수를 줄이세요. * 적절한 경우 오프라인 로깅을 사용하고 나중에 동기화하세요. ```python theme={null} import random import wandb with wandb.init(project="basic-intro") as run: for epoch in range(10): accuracy = 1 - 2 ** -epoch - random.random() / (epoch + 1) loss = 2 ** -epoch + random.random() / (epoch + 1) if epoch % 5 == 0: run.log({"acc": accuracy, "loss": loss}) ``` 수동으로 동기화하려면 `wandb sync ` 명령을 사용하세요. [`wandb sync`](/ko/models/ref/cli/wandb-sync)를 참조하세요.
### GraphQL API 요청 속도 제한
W\&B App과 [public API](/ko/models/ref/python/public-api/api)는 GraphQL 요청을 사용해 데이터를 쿼리하고 수정합니다. Multi-tenant Cloud의 경우: * 인증되지 않은 요청에는 IP 주소별로 요청 속도 제한이 적용됩니다 * 인증된 요청에는 사용자별로 요청 속도 제한이 적용됩니다 * 프로젝트 경로를 지정하는 일부 SDK 요청에는 데이터베이스 쿼리 시간을 기준으로 프로젝트별 제한이 추가로 적용될 수도 있습니다 Teams 및 Enterprise 플랜은 Free 플랜보다 한도가 더 높습니다. public API 요청을 대량으로 보내는 경우, 가능하면 요청 사이에 최소 1초 이상 기다리세요. HTTP `429 Rate limit exceeded`를 받거나 `RateLimit-Remaining=0`이 표시되면, 다시 시도하기 전에 `RateLimit-Reset`에 지정된 초 수만큼 기다리세요.
## 느린 프로젝트 문제 해결
프로젝트 또는 워크스페이스가 느리다고 느껴진다면, 먼저 다음 사항을 확인하세요. 1. 최근 run에서 새로운 메트릭 이름이 대량으로 추가되었나요? 2. 로그를 너무 자주 남기고 있나요? 3. 개별 `run.log()` Call의 크기가 매우 큰가요? 4. 워크스페이스가 자동 모드이고 패널이나 섹션이 너무 많나요? 5. 프로젝트에 팀이 실제로 활발히 사용하는 것보다 더 많은 run이 포함되어 있나요? 대부분의 경우 메트릭 카디널리티를 줄이고, log Call을 배치로 처리하고, 큰 워크스페이스를 수동 모드로 전환하면 성능이 향상됩니다.
## 브라우저 관련 참고 사항
W\&B 앱은 메모리를 많이 사용할 수 있으며 Chrome에서 가장 원활하게 작동합니다. 컴퓨터의 메모리 용량에 따라 W\&B를 탭 3개 이상에서 동시에 열어 두면 성능이 저하될 수 있습니다. 예상보다 느리게 작동한다면 다른 탭이나 애플리케이션을 닫아 보세요.
## W\&B에 성능 문제 보고하기
W\&B는 성능 문제를 गंभीर하게 다루며, 지연 관련 보고는 모두 조사합니다. 조사를 더 빠르게 진행할 수 있도록, 로딩 속도가 느릴 때는 주요 메트릭과 성능 이벤트를 캡처하는 W\&B의 내장 성능 로거를 실행해 주세요. 로딩이 느린 페이지의 URL에 `&PERF_LOGGING` 매개변수를 추가한 다음, 콘솔 출력을 account team 또는 지원팀과 공유하세요. PERF_LOGGING 추가