스토리지 벤치마크는 가장 큰 숫자가 정답이 아닐 때 더 유용해진다. MLPerf Storage 2.0에는 26개 기관이 제출한 200건 이상의 성능 결과가 실렸다[1]. 로컬 드라이브, 공유 파일시스템, 블록과 객체 스토리지, 소프트웨어 정의형 시스템, 스토리지 내부 가속까지 구성이 다양하다. 이들을 한 줄로 세워 우승자를 고르는 것은 의미가 없다. 대신 이 벤치마크는 운영자가 실제로 궁금해하는 두 질문을 일정한 조건으로 바꾼다. 이 스토리지는 몇 개의 가속기를 쉬지 않게 만들 수 있는가. 장애가 난 학습 작업의 상태를 얼마나 빨리 저장하고 복구할 수 있는가.
순차 대역폭 사양만으로는 답하기 어려운 질문이다. 학습에서는 여러 프레임워크 데이터 로더가 많은 파일을 읽고, 수천 개 worker가 보조를 맞춰 전진한다. 체크포인트를 만들 때는 방향이 바뀌어 모든 rank가 거의 동시에 상태를 쓴다. 한 경로에서 빠른 시스템이 다른 경로에서도 빠르다는 보장은 없다. 그래서 2.0은 학습과 체크포인트 시험을 분리하고, 각 결과의 설정과 로그, 시스템 설명을 함께 공개한다[2].
GPU를 모사해야 더 큰 스토리지를 시험할 수 있다
학습 시험에서 제출자가 결과에 적힌 GPU를 실제로 보유할 필요는 없다. Argonne National Laboratory가 개발한 DLIO는 프레임워크의 데이터 경로를 그대로 실행하되, 각 batch의 가속기 연산 시간을 측정값에 맞춘 sleep()으로 대신한다. PyTorch나 TensorFlow는 실제처럼 스토리지에서 호스트 메모리까지 파일을 읽는다. A100 또는 H100이 계산했을 시간만 모사하는 방식이다. 호스트 메모리에서 가속기 메모리로 옮기는 구간은 측정 대상이 아니다.
이 설계 덕분에 가속기 수를 장비 구매비가 아니라 시험 변수로 쓸 수 있다. 모사 가속기 수를 늘리다가 I/O가 목표 이용률을 유지하지 못하는 지점을 찾는다. 결과에는 연속된 다섯 번의 실행이 필요하며 최종값은 그 평균이다. 여러 실행 가운데 좋은 결과만 골라 중간 실패를 버릴 수 없다. 따라서 가속기 수는 순간 최고점이 아니라 일정 시간 유지한 동작점이다.
통과 기준도 워크로드마다 다르다. 작은 ImageNet 계열 레코드를 읽는 ResNet-50은 가속기 이용률 90% 이상을 요구한다. 큰 의료 영상 샘플을 다루는 3D U-Net도 90%다. 반면 CosmoFlow는 자체 연산과 I/O 특성을 반영해 70%를 기준으로 쓴다[2]. 모든 결과에 90% 기준을 적용하면 정상적인 CosmoFlow 제출 결과를 잘못 탈락시키게 된다.
대역폭과 확장 규모는 서로 다른 답이다
공개된 CSV 결과는 두 축을 함께 봐야 하는 이유를 보여준다[3]. 제출된 학습 구성 가운데 가장 큰 규모는 ResNet-50에서 모사 H100 3,120개, CosmoFlow에서 608개, 3D U-Net에서 336개였다. 하지만 가장 높은 평균 I/O 대역폭은 세 워크로드 모두 이 최대 규모에서 나오지 않았다. ResNet-50은 H100 2,160개에서 약 384 GB/s, CosmoFlow는 528개에서 약 280 GB/s, 3D U-Net은 176개에서 약 490 GB/s였다.
이 수치를 제품 순위 세 줄로 읽으면 안 된다. 레코드 크기, 배치, 모사 연산 시간, 이용률 기준이 워크로드마다 다르다. 같은 워크로드 안에서도 가장 많은 가속기를 유지한 실행과 가장 높은 대역폭을 낸 실행이 다를 수 있다. 확장 규모는 이용률 하한을 지키며 어디까지 갈 수 있는지를 말한다. 대역폭은 그 곡선의 특정 지점에서 이동한 데이터 양이다. 구매 검토에는 둘 다 필요하다.
세 학습 워크로드는 1.0과 2.0 사이의 비교 가능성도 유지했다. MLCommons는 이번에 제출된 시스템이 이전 버전보다 대략 두 배 많은 가속기를 지원했다고 설명한다[1]. 다만 이는 전체 결과군의 관찰이지 모든 스토리지 구조가 두 배 빨라졌다는 뜻은 아니다. 소프트웨어 버전, 클라이언트 수, 네트워크 토폴로지, 제출 시스템의 크기는 각 공개 자료에서 따로 확인해야 한다.
1조 매개변수 체크포인트는 모두가 함께 멈추는 사건이다
새 체크포인트 시험은 Llama 8B, 70B, 405B, 1T의 네 규모를 모사한다. 8B, 70B, 405B의 전체 상태는 각각 105GB, 912GB, 5.29TB로 적혀 있다. 1T는 문서 버전까지 붙여 말해야 한다. 공개 당시 기술 설명은 15TB(이 중 옵티마이저 상태 13.2TB), 현재 규칙 표는 18TB로 표시한다[2][4]. 비교 조건을 고정한 closed 부문에서는 프로세스 수가 각각 8, 64, 512, 1,024개다. 전체(default) 모드는 분산 체크포인트 전체를 쓰고 읽는다. 한 호스트가 자기 몫만 시험하는 부분(subset) 모드도 있지만 이동하는 데이터 양이 다르므로 같은 조건처럼 비교할 수 없다.
각 제출 결과는 체크포인트를 열 번 쓰고, 필요하면 파일시스템 캐시를 비운 뒤, 다시 열 번 읽는다. 쓰기가 끝난 데이터가 영구 스토리지에 도달하도록 fsync도 켠다. 실행시간은 모든 프로세스 가운데 가장 늦은 값으로, 처리량은 가장 느린 프로세스의 속도로 정한다. 분산 작업은 마지막 프로세스가 준비돼야 재개할 수 있으므로 의도적으로 보수적인 집계다.
전체 규모 결과는 사건의 크기를 보여준다. 한 closed 405B 결과는 5.29TB 체크포인트를 평균 5.69초, 930.2GB/s로 썼다. 다른 결과는 같은 모델 규모를 8.01초, 660.9GB/s로 복구했다. 1T closed 결과 하나는 쓰기 34.82초와 444.6GB/s, 읽기 22.29초와 692.4GB/s를 보고한다. 해당 CSV의 checkpoint_size_GB는 15,426.6이다. 제출 처리량을 재계산할 때는 이 원시 필드를 분모로 써야 한다. 공식 설명의 15TB와 현재 규칙의 18TB는 서로 다른 문서에 붙은 명목값이지, 계산할 때 임의로 바꿔 넣을 숫자가 아니다. 이런 문서 변화 때문에 벤치마크 결과에는 규칙 버전과 원시 파일을 함께 붙여야 한다.
숫자마다 네 개의 꼬리표가 필요하다
MLPerf Storage 수치는 워크로드, 부문, 모드, 시스템 범위를 떼는 순간 오해하기 쉽다. open 부문은 변경 내용을 공개하면 지정 설정을 바꿀 수 있다. closed 부문은 비교 가능성을 위해 변경을 제한한다. 로컬 부분 체크포인트는 한 노드에 배정된 샤드만 측정하지만 전체 모드는 분산 상태 전부를 포함한다. 클라이언트 노드와 네트워크도 제출 시스템의 일부이므로 스토리지 장비 이름만으로는 결과를 재현할 수 없다.
캐시 처리도 중요하다. 클라이언트별 체크포인트 몫이 메모리에 남을 만큼 작으면 규칙에 따라 읽기 전에 캐시를 비워야 한다. 다른 호스트가 체크포인트를 읽기 전에 스토리지 재매핑이 필요하다면 그 시간도 복구 결과에 더한다. “저장은 끝났다”와 “다른 호스트에서 복구할 수 있다”가 서로 다른 주장이 되지 않게 만든 규정이다.
빠진 범위도 분명하다. 학습 연산은 모사되며 호스트와 가속기 메모리 사이의 전송은 제외된다. 2.0은 온라인 또는 오프라인 전처리도 측정하지 않는다. 실제 애플리케이션의 버스트 정렬, 메타데이터 부하, 장애 양상을 모두 재현하는 시험도 아니다. 그러므로 이 결과만으로 구매 결정을 끝낼 수는 없다. 대신 스토리지가 확장을 멈추는 지점을 반복 가능한 방법으로 찾아, 다음 단계의 애플리케이션 시험을 어디서 시작할지 알려준다.
출처와 저작권 안내
이 글은 Silicon & Systems가 MLPerf Storage 2.0 규칙, 체크포인트 기술 설명, 발표 자료, 공개 결과 파일을 분석해 작성한 편집 글이다. 설명과 도판은 모두 새로 만들었으며 원문의 표나 도판을 옮기지 않았다. MLPerf는 MLCommons의 상표다. 벤치마크 코드와 결과 저장소는 Apache License 2.0으로 배포되며, 공개 배경은 공식 결과 발표에서 확인할 수 있다. 업체별 보충 설명은 독립 평가가 아니라 제출자의 공개 자료로 취급했다.