HPC는 익숙해지면 강력한데, 모르면 진짜 불친절하다. 아래는 “모르면 꼭 한 번은 당하는 실수들”이다. 나도 다 해봤고, 주변에서도 계속 본다.
1. conda env를 프로젝트마다 안 나눔
하나의 env에 이것저것 설치하다가 어느 날 갑자기 import 에러가 난다. 버전 충돌이 터지면 원인 추적이 거의 불가능해진다. 프로젝트 1개 = env 1개. 이거 안 지키면 언젠가 반드시 터진다.
2. Python 버전 안 보고 env 생성
로컬은 3.11인데 서버는 3.8이고, 패키지는 3.10 기준인 경우가 많다. 결과는 보통 이렇다. pip install은 되는데 실행이 안 된다. env 만들 때 Python 버전부터 고정해야 한다. 특히 torch/transformers 계열은 여기서부터 꼬이기 시작한다.
3. partition 안 보고 job 제출
GPU 없는 partition에 제출해놓고 “왜 안 빨라지지?” 한다. queue는 도는데 GPU는 안 잡히고, nvidia-smi는 안 보인다. 먼저 항상 이거부터 본다.
sinfo파티션이 여러 개면, 내가 들어가야 하는 곳이 따로 있는 경우가 많다. 특히 “gpu 파티션”이랑 “cpu 파티션”이 분리돼 있으면 여기서 초보가 한 번씩 넘어간다.
4. time limit 너무 짧게 잡음
학습 잘 돌아가다가 조용히 종료된다. 로그엔 에러도 없다. 이건 대부분 time limit 초과로 Slurm이 kill한 거다. 처음엔 넉넉하게 잡는 게 맞다. 시간 아끼려다가 실험 날리는 게 더 손해다.
5. Slurm 로그 경로 안 만들어둠
스크립트에 이렇게 써놓고
#SBATCH --output=logs/%j.outlogs 디렉토리를 안 만들어둔다. 그러면 로그가 안 남거나(혹은 Slurm이 바로 에러로 잡을 끝내거나), 남아도 찾기 힘든 위치로 간다. 디버깅 지옥이 시작된다. logs는 무조건 미리 만들어두는 게 편하다.
6. sbatch랑 srun을 헷갈림
테스트도 sbatch로 하고, 본 실험도 srun으로 한다. 그리고 세션 끊기면 다 날아간다. 정리하면 이거다. 테스트/디버깅은 srun, 학습/장시간 작업은 sbatch. 이거 하나만 지켜도 사고가 확 줄어든다.
7. nvidia-smi가 안 보이는데 당황함
이건 대부분 GPU 노드가 아니라 로그인 노드에 있는 거다. GPU는 그냥 보이는 게 아니라 요청해야 보인다. 그래서 GPU 확인은 보통 “GPU를 잡고 난 뒤”에 하는 게 맞다. 로그인 노드에서 nvidia-smi 안 뜬다고 GPU가 없는 게 아니다.
8. GPU 남아 있는데 job이 안 도는 경우
분명 sinfo 보면 GPU가 남아 있는데 내 job은 계속 PENDING이다. 이건 코드 문제가 아니라 운영 정책 문제일 확률이 높다. QoS 제한, 사용자별 GPU 제한, 우선순위 밀림 같은 것들이다. 여기서 초보가 제일 많이 하는 착각은 “내 코드가 뭔가 잘못됐나?”인데, 대부분 아니다. 그냥 기다려야 하는 상황일 때가 많다.
9. GPU 여러 개 요청했는데 코드가 1개만 씀
스크립트에 이렇게 써놓고
#SBATCH --gres=gpu:4코드는 single-GPU로만 돈다. 그러면 GPU 3개는 그냥 낭비다. 멀티 GPU는 요청만으로 되는 게 아니다. 코드에서 DDP를 쓰든, accelerate를 쓰든, 분산 설정을 해야 한다. 그리고 클러스터 입장에서는 이런 job이 제일 싫다. 자원은 먹는데 효율이 안 나온다.
10. ipynb로 학습 돌림
셀 여러 번 실행하면서 메모리 파편화가 생기고, 커널이 죽고, 재실행하면 더 빨리 죽는다. HPC에서는 ipynb는 기록/실험 메모용이고, 학습은 .py + Slurm이 제일 안정적이다. 특히 OOM 한 번 나면 커널이 메모리를 깔끔하게 못 돌려줘서 계속 이상해지는 경우가 많다.
11. requirements.txt 충돌 방치
버전을 안 박아둔다. 어제 되던 게 오늘 안 된다. 재현이 불가능해진다. 최소한 torch/transformers/lightning 같은 핵심 패키지는 버전 고정해두는 게 맞다. HPC는 “오늘 되는 환경”이 내일도 된다는 보장이 없다. 특히 누군가가 같은 env에 패키지 하나만 올려도 갑자기 깨진다.
12. nohup + python으로 버팀
로컬 습관 그대로 nohup python train.py & 이런 걸로 버티면 HPC에선 최악의 선택이 된다. 로그 뒤섞이고, job 관리가 안 되고, 자원 추적이 안 된다. 무엇보다 관리자 입장에서는 누가 뭘 돌리는지 감이 안 잡혀서 진짜 싫어한다. HPC에서는 Slurm이 정답이다. 그냥 sbatch로 돌리는 게 깔끔하다.
13. (보너스) 디렉토리 구조 안 지킴
처음엔 대충 해도 되는데, 한 번 실험이 늘어나기 시작하면 바로 지옥이 열린다.
project/
├─ env.yml
├─ notebooks/
├─ src/
├─ scripts/
└─ logs/이 정도만 지켜도 나중에 자기가 고마워진다. 특히 scripts랑 logs 분리해두면 “어떤 설정으로 돌렸는지”가 남아서, 실험이 쌓여도 덜 무너진다.
14. (추가) 한글 요약이 갑자기 같은 음절만 뱉는 현상
이것도 진짜 한 번쯤 겪는다. 모델이 갑자기 특정 음절만 반복해서 뱉는다. 처음 보면 데이터가 깨졌나, 토크나이저가 망가졌나, GPU가 맛이 갔나 싶다. 근데 대부분은 학습이 불안정해지면서 생성이 붕괴된 케이스다.
주로 이런 상황에서 잘 나온다. learning rate가 과하게 높거나, fp16에서 overflow가 나거나, 너무 긴 입력을 억지로 넣어서 attention이 터지거나, 체크포인트가 깨졌거나, decoding 설정이 이상한 경우(예: beam/temperature 조합)다. 그리고 이게 무서운 점은, 학습이 “완전히 망한 것처럼” 보여도 로그 loss는 멀쩡하게 내려가는 척할 때가 있다는 거다. 그래서 inference 결과를 꼭 중간중간 확인해야 한다.
이 현상이 보이면 보통은 이 순서로 본다. 최근 체크포인트로 다시 추론해보기, decoding 파라미터(temperature/top-p/beam) 기본값으로 되돌리기, fp16이면 bf16이나 fp32로 잠깐 확인해보기, learning rate 낮추기, 입력 길이 줄이기. 대부분 여기서 정상으로 돌아온다.
HPC는 실수에 관대하지 않다. 하지만 위에 적은 것들만 피해도 실험 날릴 확률이 내려가고, 디버깅 시간이 줄고, 멘탈 소모가 확 줄어든다. 결국 HPC는 “잘 쓰는 사람만 빠른 시스템”이 아니라, “안 망하게 쓰는 사람이 끝까지 가는 시스템”이다.
