Qwen3-VL 라인업의 크기 축을 8B → 32B로 올린 실험에서 확인된 서사는 "규모는 읽기만 개선하고 메모리 쓰기 병목은 그대로 남는다"(오라클 restore .236→.425·resume .441→.522, 메모리 전략은 ±.05, 32B rf-v3 재작성은 이전 문장을 지우는 '리셋'으로 변질)였다. 프런티어급 오픈 모델(235B-A22B MoE, 시리즈 최상위)에서도 같은 패턴이면 "규모로는 안 된다"는 결론이 더 강해지고, 오르면 "규모가 결국 해결한다"는 반대 서사가 성립한다.
Qwen3VLMoeForConditionalGeneration이 네이티브 등록돼 --trust-remote-code 불필요.1차 q235_dl이 huggingface_hub Xet 전송에서 RuntimeError로 5초만에 죽었는데 잡 상태는 COMPLETED로 위장했다(실제 캐시는 1.7MB). 재제출(HF_HUB_DISABLE_XET=1, share QOS, CPU)로 108/108 파일·96 safetensors·439GB·.incomplete 0개, 1시간46분에 성공.
.incomplete 수로 확인해야 한다. 스모크 1차는 이 위장 완료 상태에 의존성(afterok)이 걸려 있어 빈 캐시로 돌 뻔했고, 직접 취소했다.재제출한 스모크가 extra QOS에서 7시간 동안 시작조차 못 함(AssocGrpGRES). 같은 시간대 다른 extra 잡들이 실제로 PREEMPTED되는 것을 목격 → share로 전환해 재제출.
share로 예약된 시각에 시작했지만 COMPLETED / ExitCode 0:0인데 결과 디렉터리가 없었다. 실제로는 serve_eval_vllm.sh의 기동 대기가 seq 1 120 × sleep 10 = 정확히 20분 고정이었고, 235B는 그 시점 59/96 샤드(61%) 로딩 중이라 vLLM health timeout으로 죽었다(잡 Elapsed도 00:20:10으로 정확히 일치). 8B·32B는 20분 안에 뜨니 지금껏 안 드러난 결함이다.
수정: VLLM_WAIT_S(초) env 추가, 미설정 시 1200(=기존 20분과 동일)이라 다른 모델 잡 동작은 불변. VLLM_WAIT_S=3600으로 재제출.
산출물로 확인(잡 상태가 아니라): results.json 74KB · 30행 · error 0 · parse_fail 0. 로드 ≈18.5분(1차 시도 ~30분보다 빠름, GPFS 경합 차이로 추정), 평가 wall 165.8s / 78 calls. TP=4 서빙 정상, Qwen3VLMoeForConditionalGeneration 네이티브 로드(--trust-remote-code 불필요) 실측 확인.
78 calls = 읽기 30(36.0s) + 쓰기 48(129.8s/편, rf-v3·vis-pure 2전략) → 쓰기 전략당 64.9s/편, 읽기 1.20s/행. 쓰기가 지배적이고 편 수에 비례한다.
| 가족 | 행/전략 | 읽기 | 쓰기(5전략) | 합(순차) |
|---|---|---|---|---|
| find | 589 | 1.0h | 3.6h | 4.6h |
| restore | 575 | 1.0h | 3.6h | 4.6h |
| resume | 161 | 0.3h | 3.6h | 3.9h |
| routine | 314 | 0.5h | 3.6h | 4.1h |
5전략(tagmem 제외): 17.2h 순차 → 4샤드 병렬 ≈4.3h + 로드 1.2h → ≈22 GPU·h. 6전략(tagmem 포함): 25.1h 순차 → ≈30 GPU·h. API 비용은 오픈 모델 자체 서빙이라 $0, 비용은 전부 GPU 시간.
모델이 커질수록 먼저 터지는 곳은 평가 코드가 아니라 기동 대기라는 새로운 실패 유형을 발견했다 — 8B·32B에서는 20분이 충분해 드러나지 않던 하드코딩 한도가 235B에서 처음 노출됐다. 또한 잡 스케줄링에서 두 가지 교훈이 재확인됐다: ① 잡 상태(COMPLETED)는 완료의 증거가 아니다(다운로드 사고와 기동 타임아웃 둘 다 COMPLETED로 위장했다), ② 대기 중인 잡은 squeue --start로 스케줄 계획을 먼저 확인해야 reason 문자열만 보고 영구 차단으로 오해하지 않는다.
본 런 범위(4가족 6전략 / 5전략 / find만)와 QOS 선택. share는 이번엔 실제로 자리를 받았지만 preempt 대상이고, own은 다른 잡(zw_eval_lang 7장)이 빠져야 4장이 확보된다. 체크포인트(partial_*.json)가 있어 preempt돼도 이어받는다.
스모크 통과 확인됐으므로 표·보관소는 태그만 추가하면 된다(grid_v1final.py finalv2 · grid_resume_v2.py · grid_routine.py · archive_final_results.py). 표 각주 후보: MoE(활성 22B) vs dense 32B — "총 파라미터 7배지만 토큰당 연산은 22B급".