사례1건

1건 중 1~1번째

1. IL-0129 SmolLM3 사전 학습에서 공유 Weka 스토리지가 데이터셋 샤드를 S3 로 내보내고 Nanotron 데이터로더의 인덱스가 스텝마다 커지면서, 학습을 시작한 지 몇 시간 만에 처리량이 거듭 급락했다.

   Hugging Face2025

   증상

   Hugging Face 팀은 SmolLM3 본 학습을 시작했다. 48개 노드의 H100 GPU 384개로 11T 토큰을 학습하는 일정이었다. 시작하고 몇 시간 안에 처리량이 가파르게 떨어졌고, 이런 급락이 여러 번 되풀이됐다. 처리량은 학습 중 초당 처리하는 토큰 수다. 처리량이 50% 떨어지면 한 달짜리 학습이 두 달짜리가 된다.

   처리량 저하

   촉발

   팀은 약 24 TB 전체 데이터셋을 여러 팀이 함께 쓰는 Weka 스토리지에 두고, 11T 토큰에 맞춘 실제 스텝 수로 본 학습을 시작했다.

   원인

   용량 한계

   구성 요소

   공유 네트워크 파일 시스템학습 데이터 로더

   기여 요인

   장애 중첩스테이징 불일치미검증 가정

   감지

   팀은 학습 중 초당 토큰 처리량을 기록하고 있었다. 학습을 시작하고 몇 시간 안에 이 값이 급락하는 것이 보였다. SmolLM3 에서 기대한 처리량은 초당 13,500에서 14,000 토큰이었다. 팀은 처리량이 이 범위를 계속 벗어나면 위험 신호로 보았다. 그리고 노드 모니터링 지표에서 처리량이 떨어진 시점과 디스크 읽기 지연이 급증한 시점이 겹치는 것을 보고 스토리지를 원인으로 짚었다.

   조치

   • 데이터셋을 Weka 에서 빼서 각 노드의 로컬 NVMe RAID 스크래치 스토리지에 올렸다.
   • 교체한 노드에 데이터를 채울 때 S3 에서 s5cmd 로 24 TB 를 받으면 3시간이 걸렸다. 그래서 같은 데이터센터의 정상 노드에서 fpsync 로 복사해 1.5시간으로 줄였다.
   • 데이터셋을 미리 올려 둔 예비 노드 하나를 Slurm 예약에 넣어 두고, 노드가 죽으면 바로 예비 노드로 바꿨다.
   • 노드 하나에서도 급락을 재현해 하드웨어를 원인에서 뺐고, 약 3M 스텝과 32k 스텝으로 각각 돌려 원인을 스텝 수로 좁혔다.
   • Nanotron 의 nanosets 데이터로더를 SmolLM2 에서 쓰던 TokenizedBytes 데이터로더로 바꿔 넣자 급락이 사라졌다.
   • TokenizedBytes 로 바꾼 뒤 손실이 거칠어진 문제를 고치려고, 토큰화된 시퀀스를 에포크마다 다른 시드로 오프라인에서 미리 섞었다. 이 작업에 약 1시간이 걸렸다.

   교훈

   마감이 급할 때는 자기 구현을 디버깅하는 것보다 검증된 해법이나 빠른 우회책을 가져오는 편이 빠를 수 있다. 팀은 nanosets 의 인덱스 구현을 고치는 대신 TokenizedBytes 데이터로더를 가져왔다. 손실 문제도 데이터로더에 손대지 않고 오프라인에서 시퀀스를 미리 섞어 풀었다. 다만 임시방편을 너무 많이 쓰면 유지보수와 최적화가 어려운 누더기 시스템이 된다. 팀은 어블레이션과 본 학습 사이에 무엇이 바뀌었는지 정확히 알고 있었기 때문에 데이터셋 크기, 스텝 수, 하드웨어 상태를 하나씩 지워 가며 원인을 좁힐 수 있었다. 두 번째 문제는 처리량이 안정됐던 SmolLM2 의 데이터로더를 대규모로 검증하지 않은 데이터로더로 바꾸면서 생겼다.

   사례 보기

원인별1