IL-0137 Lablup Inc · 2026-06-15 (게시일)ai-infra
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시간 넘게 걸렸다.
모델 개발, 인프라, 하드웨어, 스토리지 팀이 함께 진단했다. 다섯 조직의 지표를 모니터링 파이프라인 하나에 모아 같은 타임라인에서 조회할 수 있었기 때문에 가능했다. 애플리케이션은 큰 순차 I/O 를 기대했지만 스토리지 계층에 닿은 것은 잘게 쪼개진 작은 랜덤 I/O 였다. 이 작은 랜덤 I/O 가 분산 메타데이터 서비스를 포화시켰다. 노드 하나의 NIC 수신 속도는 4~10 GiB/s 로 평범했지만, 60개 노드가 동시에 만든 접근 패턴을 메타데이터 경로가 감당하지 못했다. Solar Open 기술 보고서도 공동 검증에서 I/O 락 경합을 주된 원인 가운데 하나로 꼽았다.
애플리케이션 쪽에서는 Arrow 파일을 분산 학습 프로세스 번호인 rank 별로 나누는 파일 샤딩을 적용했다. 스토리지 쪽에서는 동기 rm/unlink 대신 비동기 삭제를 쓰고 readahead 를 조정했다. 이 변경으로 8시간이 넘던 초기화 시간이 8분 아래로 줄었다.
60노드 B200 학습 구성을 운영 규모로 늘리자 VAST 스토리지에서 학습을 초기화하는 단계가 몇 분이 아니라 8시간 넘게 걸렸다. 그동안 처리량은 이론상 한계보다 훨씬 낮게 머물렀다. 2~4노드 규모로 한 초기 검증에서는 큰 문제가 없었다.
처음에는 어느 한 계층의 신호만으로 원인을 설명할 수 없었다. 애플리케이션 로그에는 학습 초기화가 늦어진다는 사실만 나왔다. 스토리지 지표만 봐서는 어떤 접근 패턴이 문제인지 알 수 없었다. 노드마다 스토리지 NIC 수신 속도는 4~10 GiB/s 정도로, 따로 보면 이상할 것이 없었다.
애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 놓고 맞춰 본 뒤에야 병목이 드러났다. 애플리케이션은 큰 순차 I/O 를 의도했지만, 스토리지 계층에 실제로 닿은 것은 잘게 쪼개진 작은 랜덤 I/O 였다.
증상 ? 처리량 저하
원인 ? 용량 한계
운영 규모로 늘린 뒤 학습 초기화가 몇 분이 아니라 8시간 넘게 걸리면서 드러났다. 애플리케이션 로그로는 초기화 지연만 보였다. 원인은 다섯 조직이 함께 쓰는 모니터링 파이프라인에서 애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 맞춰 본 뒤에야 찾았다.
–
2~4노드 규모에서 본 성능 특성으로는 60노드에서 어떻게 동작할지 예측할 수 없었다. 이런 스토리지와 메타데이터 병목은 운영 규모에서만 드러나므로 작은 규모의 사전 시험으로는 찾기 어렵다. 이 규모에서는 한 팀이 따로 하는 모니터링만으로 근본 원인을 찾을 수 없었고, 조직 경계를 넘어 지표를 공유하는 파이프라인이 있어야 했다. GPU 용량을 늘리면서 그에 맞는 스토리지 처리 경로를 갖추지 않으면 운영 규모에서만 보이는 급격한 성능 저하가 생긴다.
같은 원인 · 공통 공유 네트워크 파일 시스템