docs/training-log.md

CERBERUS Stage-1 — Training Log & Decisions

Chunk-by-chunk history of the Stage-1 core pretrain (runs/core), and why the schedule was changed on 2026-08-09. Companion to training_plan.md (the plan) and MIGRATION.md (how to move servers).

Every relaunch appends provenance to runs/core/run_info.txt (git commit, dirty count, GPUs, resume source) and a git_diff_<ts>.patch. This file is the human-readable summary.

---

Chunk history

#	Window	Server	GPUs	eff. batch	Epochs	Ended by
1	2026-07-30 15:51 → 07-31 08:33	/data/pia (local disk)	2 (0,1)	8	0 → 25	host reboot
2	2026-08-03 12:02 → 08-04 07:16	/data/pia (local disk)	2 (0,1)	8	24 → 54*	manual stop
3	2026-08-09 ~02:00 →	Backend.AI container, /home/work/seoik (NFS)	3 (0,1,2)	12	53 → 107	(running)

* epoch 54 reached iter 1264/1500 and was discarded — resume granularity is per-epoch, so checkpoint_53 is the real continuation point.

State at the end of chunk 2 (the resume point)

• Total loss: 8.0 at start → ~2.9 plateau from ~epoch 10 onward (ep30 2.94, ep50 2.92, ep54 2.90 smoothed)
• Complementarity LOSS terms middleloss (= 1 − cos(z_a,z_m)) and middleloss_bg (= (1 + cos(z_m,z_b))/2) → ≈ 0 (converged, as designed). NOTE: these are losses, not cosines — inverting them gives cos(z_a,z_m) → +1 (alignment) and cos(z_m,z_b) → −1 (anti-correlation). See base_task.py:264-270.
• LR: 1e-5 → 8.53e-6 — i.e. only 15% decayed after 53 epochs
• Checkpoints: local 0..53; HF backup backseollgi/Cerberus/stage1_core/ 0..45 (+50)
• Samples consumed: 79,500 step × 8 = 636,000

---

Decision (2026-08-09): max_epoch 200 → 107, GPUs 2 → 3

Why the plateau was not a convergence problem

hawk/common/optims.py:99 anneals cosine over max_epoch × iters_per_epoch total steps:

lr = (init_lr - min_lr) * 0.5 * (1 + cos(pi * total_step / (max_epoch * iters_per_epoch))) + min_lr

So max_epoch is the schedule length, not a harmless cap. It was set to 200 as a "generous cap — stop anytime after ~3 days" (commits e11860c, 95eda28), which stretched the cosine over 300,000 steps. After 53 epochs we were only 26.5% into the schedule, LR was still 8.53e-6, and the late-cosine decay that actually drives convergence had not begun. Continuing under max_epoch: 200 meant 95 more hours at a near-constant high LR.

Why 107 specifically — match the sample budget, not the epoch count

Epoch numbers are not comparable between HAWK and CERBERUS; the units differ:

	original HAWK stage-1	CERBERUS (chunk 3)
iters_per_epoch	2,500	1,500
batch (per GPU)	1	4
GPUs	4	3
samples per "epoch"	10,000	18,000

Copying max_epoch: 160 from HAWK would therefore train 20% longer, not equally. Matching samples instead:

HAWK stage-1 plan  : 160 ep × 2500 it × 4  = 1.60M samples   (ran to checkpoint_127 = 1.27M)
CERBERUS target    : 107 ep × 1500 it × 12 = 1.60M samples   ← equivalent budget

Consequences at resume:

	under max_epoch: 200	under max_epoch: 107
position of checkpoint_53	26.5% of schedule	49.5%
LR on resume	8.53e-6	5.57e-6
remaining wall-clock	95.5 h (2 GPU)	34.6 h (3 GPU)
LR at finish	~5e-6 (never annealed)	1e-6 = min_lr

Why 3 GPUs actually saves time here (and why it isn't automatic)

iters_per_epoch is fixed at 1500, so an "epoch" is a 39-minute checkpoint interval, not a pass over the data (one real pass over 2.63M samples would be ~329k iters). Adding a GPU therefore does not shrink epoch wall-clock — it raises samples/step from 8 to 12.

The speedup only materialises because we lowered max_epoch to match: reaching the same 1.60M-sample budget needs 133,333 steps at 12/step instead of 200,000 at 8/step.

	2 GPU	3 GPU
steps to 1.60M samples	200,000	133,333
required max_epoch	133	107
remaining wall-clock	52.2 h	34.6 h

Known discontinuities at epoch 54 (expected, recorded here on purpose)

1. LR steps down 8.53e-6 → 5.57e-6. Downward, so it does not fight the restored Adam moments (raising LR mid-run is the dangerous direction) and it helps leave the plateau.
2. Effective batch 8 → 12. Gradients get less noisy from epoch 54 on. Report Stage-1 as "epochs 0–53 at effective batch 8, 54–107 at 12" rather than a single number.
3. Both land at the same point on the curve, so a small step in the loss/TensorBoard trace at epoch 54 is expected and is not a bug.

init_lr, min_lr, warmup_steps, iters_per_epoch, batch_size_train and seed were left untouched, so the only intended changes are the two above.

---

Environment notes for chunk 3 (new server)

Moved from /data/pia (local disk) to a Backend.AI container with /home/work/seoik on NFS. Nothing else about the run changed. Gotchas hit during setup, recorded so they are not re-discovered:

• /home/work/seoik is the only persistent volume. $HOME (/home/work) is container scratch and disappears with the session. Conda, caches and data must live under seoik/. train_run.sh now pins TORCH_HOME / HF_HOME there.
• The container ships its own conda at /home/work/miniconda3, active as base, and its envs_dirs does not include ours — so conda run -n cerberus silently resolves to the wrong prefix and fails with No module named 'torch'. train_run.sh now addresses the env by absolute prefix (conda run -p /home/work/seoik/miniconda3/envs/cerberus).
• NFS is the throughput bottleneck, not CPU/RAM (83 cores, 676 GB idle). Measured: 25.8 MB/s sequential, 35 ms per small-file write, and saturated at ~50 files/s regardless of parallelism (8 / 32 / 64 workers all measured the same). Extracting 2.66M mp4 files took ~3 h; raising worker count does not help.
• scripts/extract_all_webvid.py (new) replaces build_webvid_split.py here: one 9.1T volume means no big/small split or union symlinks are needed. It is resumable per shard via <out>/.done/<page_dir> markers.
• TensorBoard is NOT a complete record of this run. chunk 1-2's event files stayed on the old server, so runs/core/main/tensorboard/ starts at step 81,005. train.log is the only source covering epoch 0 onward (it is appended across chunks and travelled via HF). Use scripts/plot_training_curves.py to rebuild the full curves + a CSV from the log; it handles the re-run epochs at the resume points (25, 54) by letting the later record win.
• Model build verified before training with python scripts/smoke_test.py --cfg configs/train_configs/stage1_main.yaml → all three streams (appearance / motion / background) forward OK on H100 (sm_90), torch 2.11+cu128, transformers 4.28.

---

Stage-2 finetune (anomaly instruction tuning) — 이 서버, 2026-08-10 착수

설정과 그 근거

항목	값	근거
ckpt	runs/core/main/checkpoint_106.pth	stage1 최종 (LR이 min_lr까지 annealing 완료)
max_epoch	160 (원본 그대로)	아래 예산 계산 참조
batch_size_train	2 (원본 1)	GPU가 4장→2장이라 effective batch를 맞추기 위해
iters_per_epoch	2500 (원본 그대로)
num_workers	8 (원본 16)	실측 data: 지연 0.0000 — 8로 충분, NFS 부하 절감
GPU	H100 2장 (stage1은 3장)	세션 재할당으로 변경됨

샘플 예산 — 원본과 동일하게 통제:

원본 HAWK stage2 : 160 ep x 2500 it x batch 1 x 4 GPU = 1.60M 샘플 (effective batch 4)
이 서버           : 160 ep x 2500 it x batch 2 x 2 GPU = 1.60M 샘플 (effective batch 4)

GPU 장수가 절반이 된 만큼 batch를 2배로 올려, 샘플 예산과 effective batch를 둘 다 원본과 일치시켰다. 그 결과 max_epoch은 원본 값 160을 그대로 쓸 수 있다 (stage1에서 107로 재계산해야 했던 것과 다른 점 — stage1은 iters_per_epoch도 1500으로 바꿨기 때문).

batch를 더 키우지 않은 이유 (2026-08-10 실측, 150 iter 공정 비교, H100 2장):

batch	정상상태 s/it	max mem	처리량	1.6M 샘플 소요
2	1.369	45.7 GB	2.92 samples/s	6.3일
4	2.773	56.6 GB	2.89 samples/s	6.4일
6	4.31	69.0 GB	2.78 samples/s	6.7일
8	—	OOM (75.9 GB 할당 후 실패)	—	—

batch에 비례해 iter 시간이 같이 늘어 처리량이 평평하다 = 32프레임 x 3스트림 조합이 이미 샘플당 연산 포화. VRAM을 더 채워도 이득이 없고 batch 6부터는 오히려 저하되므로, 여유 34GB를 남겨 다일 학습의 OOM 위험을 줄이는 batch 2를 택했다. data: 지연은 모든 설정에서 0.0000이라 NFS는 병목이 아니다. PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True도 batch 6의 저하를 해소하지 못했다(4.72 s/it) — 단편화가 아니라 연산 한계라는 근거.

착수 전 처리한 이관 문제 (다른 서버에서 재현할 때도 필요)

1. annotation의 비디오 경로가 원저자 서버 절대경로였다. 배포본 JSON의 video 필드가 /remote-home/share/jiaqitang/Data/...인데, 로더는 os.path.join(vis_root, sample['video']) (video_instruct_dataset.py:128)를 쓴다. 두 번째 인자가 절대경로면 vis_root가 통째로 무시되므로 config의 videos_dir를 고쳐도 소용이 없다. 게다가 데이터셋 이름이 실제 배포본 디렉토리명과 다르다(UCF-Crime↔UCF_Crime, avenue/avenue/↔CUHK_Avenue/, ped1/ped1/↔Ped1/, ShanghaiTechDataset↔ShanghaiTech). → scripts/localize_anomaly_annotations.py가 videos_dir 기준 상대경로로 변환해 *.local.json을 만든다(원본 보존). train 7066 / test 786 / all 7852 전부 매칭 확인.
2. config에 남아 있던 외부 경로 6곳(llama_model, tokenizer_name, prompt_path, ckpt, anno_dir, videos_dir)을 이 서버 기준으로 교체. output_dir도 레포 안(output/)을 가리키던 것을 runs/ 절대경로로 옮겼다(train_run.sh 사용 시에는 run별로 덮어써짐).

stage2의 손실 구조는 stage1과 다르다 (논문 서술 시 주의)

instruct 데이터는 conv_type='multi' 경로(video_llama.py:738-806)를 타는데, 여기서는 세 스트림의 임베딩을 토큰으로 concat해 LLaMA를 한 번만 통과시키고 loss_motion·loss_background에 같은 loss 값을 복사해 반환한다. 따라서 stage2 총손실은 실질적으로

total = 1.2 x LM손실 + 0.1 x middleloss + 0.1 x middleloss_bg

이며, stage1처럼 스트림별 독립 LM 손실이 존재하지 않는다. 이는 원본 HAWK 설계 그대로이고 버그가 아니다. 로그의 motionloss/backgroundloss가 oriloss와 동일하게 찍히는 것은 정상이다.

논문 작성에 필요한 산출물 — 학습 완료 시 아래가 전부 수집되어야 한다

train_run.sh가 runs/stage2/에 자동으로 남기는 것:

• main/checkpoint_{0..159}.pth — epoch별 체크포인트 (약 2GB x 160 = 320GB)
• main/tensorboard/ — 스칼라 7종: Loss/total, Loss/ori, Loss/motion, Loss/background, Loss/middle, Loss/middle_bg, Learning Rate (global step = epoch x 2500 + i)
• train.log — 전 구간 append. TB보다 이쪽이 권위 있는 기록이다(chunk 재개 시 TB는 끊길 수 있음)
• run_info.txt — chunk별 provenance: config 경로, GPU, git commit + dirty 여부, resume 지점
• config.yaml — 실행 시점 config 사본
• git_diff_<ts>.patch — 실행 시점 워킹트리 diff

학습 완료 후 추가로 만들어야 하는 것:

• scripts/plot_training_curves.py로 stage2 곡선 + CSV 생성 → figs/stage2_curves.{png,pdf,csv}
• HF backseollgi/Cerberus/stage2_finetune/에 체크포인트(마일스톤+최종)·train.log·config.yaml· 곡선 백업 (stage1과 동일한 방식)
• E1/E2 실측: scripts/extract_representations.py + experiments/disentanglement.py로 CDS 산출. stage1 체크포인트와 stage2 체크포인트 양쪽에서 뽑아야 분리도가 finetune으로 어떻게 변했는지 비교할 수 있다.
• Table-1용 VAD 정량 수치 (scripts/run_eval.sh, test split은 all_videos_test.local.json)

---

NaN epoch 평균의 정체 (2026-08-12, 실측)

abl_flow arm의 로그에서 Averaged stats의 totalloss가 28 epoch 중 9회 nan 으로 찍혔고, 26–28에서 3연속으로 나타났다. 학습 실패로 읽힐 수 있는 형태이므로 원인을 확정했다.

실측. 출력된 iteration 7,032개 중 NaN은 1개(0.014%)다. epoch 평균은 2,500 iteration의 평균이므로 NaN 하나가 섞이면 평균 전체가 NaN이 된다. 즉 로그의 nan은 "이 epoch이 실패했다"가 아니라 "이 epoch에 NaN iteration이 적어도 하나 있었다"는 뜻이다.

실제 발생률은 epoch당 약 0.4회다. 그러면 P(epoch에 NaN ≥ 1) = 9/28 = 0.32이고, 3연속이 나타날 확률은 28 epoch 구간에서 약 60%다. 3연속은 악화의 증거가 아니라 이 발생률에서 예상되는 사건이다.

가중치 확인. checkpoint_27.pth의 학습 파라미터 231개 전부 NaN/Inf 없음. AMP GradScaler가 NaN 손실에서 옵티마이저 스텝을 건너뛰므로 가중치가 오염되지 않는다. 정상 epoch의 loss는 단조 하강한다(1.537 → 0.983).

감시 기준 교체. "연속 3 epoch NaN"은 이 발생률에서 우연과 악화를 구별하지 못하므로 폐기한다.

폐기	대체
연속 3 epoch NaN	출력 iteration의 NaN 비율 > 1% (현재 0.014%)
	체크포인트에 NaN/Inf 파라미터 (현재 없음)
	정상 epoch loss가 3회 연속 상승 (현재 단조 하강)

논문 표기. arm별 NaN epoch 수를 보고할 때 이 각주가 함께 가야 한다. 수치만 제시하면 심사자가 9/28을 학습 불안정으로 읽는다. 보고 형식은 "NaN epoch 9/28 (iteration 수준 NaN 비율 0.014%; epoch 평균은 단일 NaN에 의해 오염된다)"로 한다.

재현:

$CERBERUS_PY - <<'EOF'
import re, collections
tot = collections.Counter(); nan = collections.Counter()
for l in open('/home/work/seoik/runs/abl_flow/train.log', errors='ignore'):
    m = re.search(r'Train: data epoch: \[(\d+)\].*?totalloss: (nan|[0-9.]+)', l)
    if m:
        e = int(m.group(1)); tot[e] += 1
        if m.group(2) == 'nan': nan[e] += 1
print(f'출력 {sum(tot.values())}개 중 NaN {sum(nan.values())}개')
EOF

---

random_mask arm 중단과 러너의 실패 미감지 (2026-08-13)

abl_random_mask 가 epoch 5, iteration 320 부근에서 다음과 같이 죽었다.

RuntimeError: DataLoader worker (pid 3751766) is killed by signal: Killed.
[ablation] arm=random_mask 종료 (exit 1)
[ablation] arm=duplicate 시작              ← 러너가 실패를 무시하고 진행

자원 문제가 아니다. 사후 확인: RAM 2,015GB 중 1,898GB 여유, /dev/shm 64GB(사용 276KB), GPU 46.8/81.6GB. 같은 데이터로 flow 는 40 epoch 완주했고 duplicate 는 문제없이 진행 중이다. 일시적 메모리 스파이크로 보이며 재현되지 않았다.

복구 가능. checkpoint_4.pth 에 model·optimizer·scaler·epoch 이 모두 있어 epoch 5 부터 이어갈 수 있다(train_run.sh 가 최신 체크포인트를 자동으로 찾아 resume_ckpt_path 로 넘긴다).

러너의 결함과 대응

run_ablation_arms.sh 는 train_run.sh 의 종료 코드를 확인하지 않는다. arm 하나가 5 epoch 에서 죽어도 다음 arm 으로 넘어가므로, 동일 예산 통제가 조용히 깨진다.

실행 중인 스크립트는 편집하지 않았다 — bash 는 스크립트를 바이트 오프셋으로 읽으므로 진행 중 파일을 고치면 남은 부분을 잘못 해석한다. 대신 run_ablation_followup.sh 를 새로 두고, 완료 epoch 수를 확인해 목표에 못 미치면 재시도하도록 했다.

검증하려다 실제 학습을 띄운 사고

ABL_ARMS="" bash scripts/run_ablation_followup.sh 로 "arm 없이 상태만 보자"고 실행했는데 학습이 시작되어 duplicate 와 GPU 를 다투었다. 원인은 ${ABL_ARMS:-기본값} 의 :- 가 빈 문자열도 기본값으로 치환한다는 점이다. 즉시 종료하여 피해는 없었다(duplicate 정상 진행, random_mask 체크포인트·로그 불변).

세 가지 안전장치를 넣었다.

장치	효과
--check 플래그	상태만 출력하고 종료. 검증 시 학습이 시작될 수 없다
${ABL_ARMS-...} (: 제거)	빈 문자열을 "arm 없음"으로 존중
실행 중 프로세스 감지	다른 절제 학습이 있으면 거부(ABL_FORCE=1 로만 무시)

남은 일정

flow          40/40  완주
random_mask    5/40  재개 필요
duplicate     12/40  진행 중
zero           0/40  대기
flow_reinit    0/40  대기

zero 종료 후 bash scripts/run_ablation_followup.sh 로 random_mask 재개 + flow_reinit 실행. 약 144 epoch × 75분 ≈ 7.5일.

---

duplicate arm 발산 (2026-08-13)

abl_duplicate 가 epoch 16, iteration 1430 부근에서 발산했다. 이전의 산발적 NaN 과 성격이 전혀 다르다.

epoch 15 까지 : middleloss 0.0001, 정상
epoch 16      : iteration ~1430 이후 totalloss·oriloss·middleloss 전부 nan (출력 250 중 116)
epoch 17      : 시작부터 전부 nan

모델이 죽었다. checkpoint_16.pth 의 학습 파라미터 231개 중 193개가 비유한이다 (llama_proj_0.weight, video_query_tokens_* 등). 전수 스캔 결과 epoch 15 가 마지막 정상 체크포인트다(13·14·15 전부 0/231).

회복 불가. AMP GradScaler 는 NaN 손실에서 옵티마이저 스텝을 건너뛰는데, 가중치가 이미 NaN 이면 모든 forward 가 NaN 이고 모든 스텝이 건너뛰어진다. 스스로 빠져나올 경로가 없다. 따라서 계속 두는 것은 순수한 낭비이며(arm 당 약 2일), 중단했다. 러너는 다음 arm(zero)으로 진행했다.

이전 NaN 과의 구별

	산발적 NaN (flow arm)	발산 (duplicate arm)
iteration NaN 비율	0.014% (7,032 중 1)	46% (250 중 116), 이후 100%
지속성	단발, 다음 iteration 정상	시작 후 되돌아오지 않음
가중치	전부 유한	193/231 비유한
epoch 평균이 NaN 인 이유	단일 NaN 이 평균을 오염	실제로 전부 NaN

새 감시 기준이 이것을 잡았다. "연속 3 epoch NaN" 기준은 두 경우를 구별하지 못했으나, 교체한 기준(iteration NaN 비율 > 1% · 체크포인트 비유한 파라미터)은 발산만 발동했다.

원인 미확정

epoch 16 전까지 middleloss 가 0.0001 → 0.0003 으로 움직이기 시작했고(정류점 이탈의 초기 신호), 그 직후 발산했다. flow arm 에서도 epoch 28 에 이탈이 있었으나 발산하지 않고 회복했다. 두 사건이 같은 기제인지, duplicate 의 정적 입력(원본 프레임 복제)이 이탈을 더 불안정하게 만드는지는 확정하지 못했다.

표현 손실을 끄면 이 실패 양식이 사라질 가능성이 높다. 논문은 L_sim·L_dis 를 기여로 주장하지 않으므로 t_1 = t_4 = 0 으로 두는 데 손실이 없고, 통제 실험에서 켜 둘 이유도 없다. 재실행 시 이 설정을 검토할 것.

남은 상태

flow         40/40  완주
random_mask   5/40  OOM kill (checkpoint_4 에서 재개 가능)
duplicate    17/40  발산 (checkpoint_15 에서 재개 가능)
zero          0/40  진행 시작 2026-08-13 22:23
flow_reinit   0/40  대기