set -euo pipefail 하에서 ls 실패로 조용히 죽음. (2) 수정 후 108903은 시작하자마자 FlexAttention Triton JIT가 C 컴파일러를 못 찾아 크래시.--container 없이 conda-forge 컴파일러(gcc_linux-64/gxx_linux-64) + CC/CXX env로 우회(gymtorch C++ 확장 JIT 때와 동일 패턴).LingBot-VA(video-action world model) 본 학습을 2 GPU sbmr job으로 제출했는데, 시작 직후 바로 종료되는 문제가 두 차례 발생했다. 이 클러스터는 worker pod에 컴파일러/빌드 도구를 넣지 않는 정책(§13)이라, gymtorch(C++ ext)에 이어 FlexAttention의 Triton 런타임 JIT도 같은 종류의 문제를 일으킬 위험이 있었고 실제로 그랬다.
set -e + ls 실패108687이 [cfg] 로그 출력 후 10초 만에 COMPLETED. 스모크 이후 추가한 자동 재개 로직이 원인이었다:
수정 후 재제출한 108903은 시작 직후 다음 에러로 죽었다:
LingBot-VA는 attn_mode="flex"(FlexAttention)를 쓰는데, FlexAttention은 Triton으로 커널을 런타임에 JIT 컴파일한다. 로그인 노드는 시스템 gcc가 있어 스모크 테스트를 통과했지만, worker 기본 이미지(ubuntu:22.04)에는 컴파일러가 없어 worker에서만 재현되는 환경 차이였다.
--container 미사용)옵션은 (a) --container=python:3.11(gcc 포함 이미지) vs (b) conda-forge 컴파일러를 venv에 설치. gymtorch 때와 동일한 이유로 (b)를 택함 — sbm/sbmr 래퍼에 --container를 끼워 넣지 않아도 되고 env가 self-contained.
| job | 결과 | 수치 / 원인 |
|---|---|---|
| 108687 | 즉시 COMPLETED (10 s) | 런처 ls 실패 → set -e로 조용히 종료 (exit 0으로 위장) |
| 108903 | 즉시 크래시 | Failed to find C compiler (FlexAttention Triton JIT) |
| 108915 | 정상 학습 진행 | PENDING(119/120 GPU 사용 중) → 23:02 시작 |
davian-cv/lingbot_va_furniture run v55s1cdb.sjob 확인: GPU util 56~58%, 77 GB/GPU, CPU 12% → 완전 GPU-bound는 아님(FSDP sync + grad-accum 루프 오버헤드로 추정, 원인 미확정). 체크포인트는 200 step(≈45분)마다 저장되어 중간 평가 가능.worker의 "컴파일러 없음" 제약은 conda 컴파일러 + CC/CXX env로 우회 가능하다는 것이 두 번째 사례(gymtorch C++ 확장, FlexAttention Triton JIT)로 재확인됐다. 클러스터 가이드가 deprecated로 두는 것은 "로그인에서 prewarm한 캐시를 worker로 옮기는" 방식이고, 여기서 쓴 방식은 worker 안에서 직접 컴파일하는 것이라 해당 문제와 무관하다. LingBot/FlexAttention 계열 학습은 --container 없이 sbmr만으로 가능함이 실증됨.
부수적으로, set -euo pipefail 스크립트에서 command substitution 실패는 exit code를 위장할 수 있다는 점도 확인됨 — sacct의 COMPLETED 0:0만으로는 실제 성공 여부를 판별할 수 없고 로그 확인이 필수.
56~58% util이 FSDP sync 오버헤드인지 grad-accum 루프 자체의 idle time인지 profiling으로 확인. 확인되면 accum 스텝 수·batch 조정으로 처리량 개선 여지.
200 step 간격 체크포인트로 중간 평가(별도 카드: LingBot-VA 평가 파이프라인) 반복, 5000 step 완주까지 preempt 시 sbmr 자동 재개 확인.