{"id":"IL-0137","org":"Lablup Inc","date":"2026-06-15","docs":[],"title":{"en":"Training initialisation on a 60-node NVIDIA B200 cluster took more than 8 hours instead of minutes because fragmented small random I/O from all nodes saturated the metadata service of the VAST Data NFS storage","ko":"60노드 B200 학습 클러스터에서 노드들의 작은 랜덤 I/O 가 VAST 스토리지의 메타데이터 서비스를 포화시켜 학습 초기화가 8시간 넘게 걸렸다"},"domain":["ai-infra"],"impact":{"scope":"Solar Open pre-training job on 60 nodes of a 63-node NVIDIA B200 cluster: training initialisation took more than 8 hours instead of minutes","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Storage behaviour measured on 2 to 4 nodes did not predict behaviour on 60 nodes: a metadata bottleneck of this kind appears only at production scale, so small pre-tests cannot find it. Per-node network rates can look normal while the combined access pattern of all nodes overwhelms the storage metadata path. Finding the cause took metrics from the application, scheduler, network and storage on one shared timeline; monitoring by any single team was not enough. The report concludes that GPU capacity has to be provisioned together with a matching storage path.","ko":"2~4노드 규모에서 본 성능 특성으로는 60노드에서 어떻게 동작할지 예측할 수 없었다. 이런 스토리지와 메타데이터 병목은 운영 규모에서만 드러나므로 작은 규모의 사전 시험으로는 찾기 어렵다. 이 규모에서는 한 팀이 따로 하는 모니터링만으로 근본 원인을 찾을 수 없었고, 조직 경계를 넘어 지표를 공유하는 파이프라인이 있어야 했다. GPU 용량을 늘리면서 그에 맞는 스토리지 처리 경로를 갖추지 않으면 운영 규모에서만 보이는 급격한 성능 저하가 생긴다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2605.09370","kind":"paper","license":"unknown","archived":null}],"summary":{"en":"The cluster has 63 NVIDIA HGX B200 nodes (504 GPUs; 60 nodes for training, 3 spare) and is run jointly by SK Telecom (cloud operations), Upstage (model development), Lablup (the Backend.AI infrastructure), NVIDIA (hardware) and VAST Data (storage). Training data and checkpoints live on a 2 PiB VAST Data E-Box mounted over NFS through a dedicated 200G RoCE storage network; the storage's cluster-wide maximum bandwidth is 700 GB/s for reads and 250 GB/s for writes.\n\nWhen Upstage's Solar Open pre-training was deployed at 60 nodes, training initialisation from the storage took more than 8 hours. A joint diagnosis by the model-development, infrastructure, hardware and storage teams found that the application meant to do large sequential reads, but what actually reached the storage was fragmented small random I/O. With 60 nodes doing this at the same time, the combined access pattern saturated the storage's distributed metadata service, even though each node's own traffic looked normal.\n\nThe fix came from both sides. The application side sharded its Arrow files by rank, and the storage side replaced synchronous rm/unlink with asynchronous deletion and tuned readahead. Together these cut initialisation from more than 8 hours to less than 8 minutes. The report uses this case to argue that a storage and metadata bottleneck of this kind appears only at production scale and that root-cause analysis at this scale needs a metrics pipeline shared across organisations.","ko":"SKT, Upstage, Lablup, NVIDIA Korea, VAST Data 다섯 조직이 함께 운영하는 63노드 NVIDIA B200 클러스터에서 Upstage 의 Solar Open 사전 학습이 돌았다. Lablup 은 Backend.AI 인프라를 맡았다. 스토리지는 VAST Data E-Box 2 PiB 를 NFS 로 마운트해 썼고, 데이터를 읽고 체크포인트를 저장할 때는 전용 200G RoCE 네트워크로 이 스토리지에 접근했다. 60노드 학습 구성을 배포하는 과정에서, 초기 검증 때는 없던 I/O 병목이 운영 규모에서 생겼다. 몇 분 안에 끝나야 할 학습 초기화가 8시간 넘게 걸렸다.\n\n모델 개발, 인프라, 하드웨어, 스토리지 팀이 함께 진단했다. 다섯 조직의 지표를 모니터링 파이프라인 하나에 모아 같은 타임라인에서 조회할 수 있었기 때문에 가능했다. 애플리케이션은 큰 순차 I/O 를 기대했지만 스토리지 계층에 닿은 것은 잘게 쪼개진 작은 랜덤 I/O 였다. 이 작은 랜덤 I/O 가 분산 메타데이터 서비스를 포화시켰다. 노드 하나의 NIC 수신 속도는 4~10 GiB/s 로 평범했지만, 60개 노드가 동시에 만든 접근 패턴을 메타데이터 경로가 감당하지 못했다. Solar Open 기술 보고서도 공동 검증에서 I/O 락 경합을 주된 원인 가운데 하나로 꼽았다.\n\n애플리케이션 쪽에서는 Arrow 파일을 분산 학습 프로세스 번호인 rank 별로 나누는 파일 샤딩을 적용했다. 스토리지 쪽에서는 동기 rm/unlink 대신 비동기 삭제를 쓰고 readahead 를 조정했다. 이 변경으로 8시간이 넘던 초기화 시간이 8분 아래로 줄었다."},"trigger":{"en":"Scaling the training job from 2 to 4 nodes in validation to the full 60-node configuration.","ko":"학습 구성을 2~4노드 시험 규모에서 60노드 운영 규모로 늘렸다."},"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The problem showed up as training initialisation taking hours after the job was scaled to 60 nodes; application logs showed only the delayed initialisation.","ko":"운영 규모로 늘린 뒤 학습 초기화가 몇 분이 아니라 8시간 넘게 걸리면서 드러났다. 애플리케이션 로그로는 초기화 지연만 보였다. 원인은 다섯 조직이 함께 쓰는 모니터링 파이프라인에서 애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 맞춰 본 뒤에야 찾았다."},"components":["shared-filesystem"],"root_cause":"capacity","remediation":[{"text":{"en":"Sharded the Arrow training data files by rank on the application side","ko":"애플리케이션 쪽에서 Arrow 파일을 rank 별로 나누는 파일 샤딩을 적용했다."}},{"text":{"en":"Switched the storage to asynchronous deletion instead of synchronous rm/unlink","ko":"스토리지 쪽에서 동기 rm/unlink 대신 비동기 삭제를 쓰도록 바꿨다."}},{"text":{"en":"Tuned readahead","ko":"readahead 설정을 조정했다."}}],"action_items":[],"contributing":["staging-not-representative","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"The 60-node NVIDIA B200 training configuration for the Solar Open pre-training run showed no major problem during initial validation on 2 to 4 nodes. Once the job ran at its full size of 60 nodes, training initialisation, which reads from the VAST Data storage and should have finished within minutes, took more than 8 hours, and storage throughput stayed far below the theoretical limit.\n\nNo single layer explained the delay. The application logs only showed that training initialisation was slow, and the storage metrics on their own did not show which access pattern was to blame. The storage NIC of each node received about 4 to 10 GiB/s, which looked unremarkable when each node was examined alone.\n\nThe cause became visible only when the application, scheduler, network and storage metrics of the five organisations running the cluster were lined up on one timeline. The Solar Open technical report, which describes the same problem, names I/O lock contention as a primary cause.","ko":"60노드 B200 학습 구성을 운영 규모로 늘리자 VAST 스토리지에서 학습을 초기화하는 단계가 몇 분이 아니라 8시간 넘게 걸렸다. 그동안 처리량은 이론상 한계보다 훨씬 낮게 머물렀다. 2~4노드 규모로 한 초기 검증에서는 큰 문제가 없었다.\n\n처음에는 어느 한 계층의 신호만으로 원인을 설명할 수 없었다. 애플리케이션 로그에는 학습 초기화가 늦어진다는 사실만 나왔다. 스토리지 지표만 봐서는 어떤 접근 패턴이 문제인지 알 수 없었다. 노드마다 스토리지 NIC 수신 속도는 4~10 GiB/s 정도로, 따로 보면 이상할 것이 없었다.\n\n애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 놓고 맞춰 본 뒤에야 병목이 드러났다. 애플리케이션은 큰 순차 I/O 를 의도했지만, 스토리지 계층에 실제로 닿은 것은 잘게 쪼개진 작은 랜덤 I/O 였다."},"updated_at":"2026-11-09T11:55:50.362241Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0137","org_slug":"lablup-inc"}