Index
2026-09-04 — Engineering

LingBot-VA 학습: worker 컴파일러 부재 디버깅 및 해결

FurnitureBench | job 108687 → 108903 → 108915 (2 GPU, sbmr)

TL;DR

2
연속 즉시-종료 job
13.3s
it (2 GPU)
56~58%
GPU util (108915)
0.13
action_loss @ step 35

1 배경 / 목적

LingBot-VA(video-action world model) 본 학습을 2 GPU sbmr job으로 제출했는데, 시작 직후 바로 종료되는 문제가 두 차례 발생했다. 이 클러스터는 worker pod에 컴파일러/빌드 도구를 넣지 않는 정책(§13)이라, gymtorch(C++ ext)에 이어 FlexAttention의 Triton 런타임 JIT도 같은 종류의 문제를 일으킬 위험이 있었고 실제로 그랬다.

2 작업 내용

2.1 첫 번째 원인 — 런처의 set -e + ls 실패

108687이 [cfg] 로그 출력 후 10초 만에 COMPLETED. 스모크 이후 추가한 자동 재개 로직이 원인이었다:

LATEST=$(ls -d .../checkpoint_step_* | sed ... | sort | tail) # 체크포인트가 없을 때 ls 실패 → set -euo pipefail 하에서 command substitution 실패 → 스크립트가 에러 없이 조용히 종료 수정: LATEST=$({ ls -d .../checkpoint_step_* 2>/dev/null || true; } | sed ... | sort | tail)

2.2 두 번째 원인 — worker에 C 컴파일러 없음 (Triton JIT)

수정 후 재제출한 108903은 시작 직후 다음 에러로 죽었다:

RuntimeError: Failed to find C compiler. Please specify via CC environment variable or set triton.knobs.build.impl.

LingBot-VA는 attn_mode="flex"(FlexAttention)를 쓰는데, FlexAttention은 Triton으로 커널을 런타임에 JIT 컴파일한다. 로그인 노드는 시스템 gcc가 있어 스모크 테스트를 통과했지만, worker 기본 이미지(ubuntu:22.04)에는 컴파일러가 없어 worker에서만 재현되는 환경 차이였다.

2.3 수정 (venv-only 정책 유지, --container 미사용)

옵션은 (a) --container=python:3.11(gcc 포함 이미지) vs (b) conda-forge 컴파일러를 venv에 설치. gymtorch 때와 동일한 이유로 (b)를 택함 — sbm/sbmr 래퍼에 --container를 끼워 넣지 않아도 되고 env가 self-contained.

conda install -c conda-forge gcc_linux-64 gxx_linux-64 # lingbot-b200 env → activation 시 CC=x86_64-conda-linux-gnu-cc, CXX=...-c++ 자동 export train_lingbot.sh 추가: export CC=${CC:-x86_64-conda-linux-gnu-cc} CXX=${CXX:-x86_64-conda-linux-gnu-c++} export CPATH="$CONDA_PREFIX/include" export TRITON_CACHE_DIR=$HOME/.triton/cache_b200 # Triton은 CC env를 최우선으로 사용하므로 worker에서도 conda 컴파일러로 JIT 가능 검증(로그인, conda CC로): torch.compile(flex_attention) 512-token causal block mask, B200 → 12.8 s 컴파일 후 정상 출력 (1,4,512,64) 재제출: sbmr 10 "bash scripts/lingbot/train_lingbot.sh 2 furniture_train" \ -J fb_lingbot_train_one_leg --gres=gpu:2 -c 16 --mem 400GB --qos=extra --time 24:00:00 → 108915 (FurnitureBench dir, env lingbot-b200)

3 결과

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 시작
108915 학습 곡선 (2 GPU, batch 1 × grad_accum 10): step 35 시점 latent_loss≈0.23, action_loss≈0.13, grad_norm≈0.4, lr 1e-5 (스모크 6 step 때 action_loss 0.53→0.39에서 이어짐). 속도 13.3 s/it → 5000 step ≈ 18.5 h. wandb: 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분)마다 저장되어 중간 평가 가능.

4 Takeaway

의미

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만으로는 실제 성공 여부를 판별할 수 없고 로그 확인이 필수.

5 Next Steps

GPU util 원인 확인

56~58% util이 FSDP sync 오버헤드인지 grad-accum 루프 자체의 idle time인지 profiling으로 확인. 확인되면 accum 스텝 수·batch 조정으로 처리량 개선 여지.

학습 곡선 추적

200 step 간격 체크포인트로 중간 평가(별도 카드: LingBot-VA 평가 파이프라인) 반복, 5000 step 완주까지 preempt 시 sbmr 자동 재개 확인.