Looking Ahead의 1.3B 이미지-투-비디오(image-to-video) 예제는 추론(inference)이 시작되기 전에 제 Windows 컴퓨터에서 중단되었습니다:
ModuleNotFoundError: No module named 'fcntl'
이 장치에는 RTX 5090이 탑재되어 있었고, FlashAttention 4가 설치되어 있었습니다. 하지만 이 두 가지로는 임포트(import) 단계를 통과하기에 충분하지 않았습니다.
제가 적용한 수정 사항(TencentARC/Looking-Ahead PR #2)은 2026년 10월 23일(UTC)에 병합되었습니다. 이 패치를 통해 테스트된 1.3B 예제는 PyTorch의 스케일드 점곱 어텐션 폴백(scaled dot-product attention fallback)을 사용하여 Windows 11에서 768×432 해상도의 80프레임을 성공적으로 생성했습니다.
이 변경 사항은 여섯 개의 파일을 걸쳐 이루어졌습니다. 흥미로운 점은, 실제로 폴백 방식이 엔드투엔드로 작동하기 위해서는 세 가지 별개의 가정이 제거되어야 했다는 것입니다.
제가 Looking Ahead를 실행하고 싶었던 이유
Looking Ahead는 Nanjing University, Tencent ARC Lab, Zhejiang University 연구원들이 진행한 비디오 생성 연구 프로젝트입니다.
이 프로젝트의 방법론인 **Future Chunk Prediction (FCP)**은 자기회귀(autoregressive) 비디오 학습 과정에서 발생하는 단축 경로(shortcut) 문제를 해결합니다. 즉, 인접한 비디오 청크(video chunks)가 너무 유사할 경우 모델이 장면 변화에 대해 많이 학습하기보다는 국부적 연속성(local continuity)에 의존하게 되는 현상입니다.
FCP는 현재 청크의 중간 특징(intermediate features)으로부터 더 먼 미래의 청크를 예측하는 보조 훈련 브랜치(auxiliary training branches)를 추가합니다. 이 과정에서 개입되는 청크들은 볼 수 없습니다. 이러한 보조 브랜치는 추론 시 제거됩니다. 저자들은 물리적 일관성(physical consistency) 측면에서 개선이 있었다고 보고했으며, 프로젝트 페이지에서는 방법론을 설명하고 비교 결과를 보여줍니다.
공개된 코드는 1.3B 및 5B 모델을 포함합니다. 이 프로젝트의 문서화된 테스트 환경은 NVIDIA H200이 장착된 Linux였습니다. 저의 기여는 업스트림 코드(upstream code)를 통해 테스트 가능한 Windows 추론 경로를 접근 가능하게 만들었습니다. 이는 FCP 자체를 변경하거나, 모델을 재훈련시키거나, 모든 구성에 대한 Windows 지원을 확립하는 것은 아닙니다.
이것이 제가 이 병합 사항에 중요성을 느끼는 이유입니다. 이제 호환성 수정(compatibility fix)이 연구 저장소에 존재하게 되었으며, 다음으로 이 모델을 시도하려는 사람이 이를 활용할 수 있게 되었습니다.
1. 설치되었다고 해서 가져올 수 있다는 의미는 아니다
어텐션 모듈은 flash_attn.cute를 가져오기 전에 is_flash_attn_4_available()을 사용했습니다.
테스트 환경에서 이 가용성 확인(availability check)은 설치된 패키지를 보고했지만, 실제로 가져오는 것은 여전히 실패했습니다. 그 이유는 해당 패키지의 quack 종속성이 Unix 전용 모듈인 fcntl을 가져오려고 했기 때문이며, 이는 Windows에서는 사용할 수 없습니다.
병합된(merged) 코드는 이모트(import)를 시도하고, ImportError를 사용 불가능한 선택적 백엔드(optional backend)로 처리합니다:
FLASH_ATTN_4_AVAILABLE = is_flash_attn_4_available()
if FLASH_ATTN_4_AVAILABLE:
try:
...
두 어텐션 모듈 모두 이 처리를 받습니다. 공유 헬퍼(shared helper)는 선택된 백엔드를 기록하고, 각기 다른 임포트 실패를 한 번만 보고합니다.
경고문은 성능과 수치 결과가 다를 수 있음을 명시적으로 언급합니다. 이는 중요한데, 백엔드가 조용히 전환되는 실행은 재현하거나 비교하기 어렵기 때문입니다.
이 헬퍼는 예외 유형(exception type)과 메시지를 문자열로 받습니다. 경고를 중복 제거하기 위해 예외 객체와 트레이스백을 캐시하지 않습니다.
이 확인 절차는 임포트 가능성만을 확립할 뿐이며, 이후의 모든 커널 호출이 모든 장치에서 작동한다는 보장은 아닙니다. 또한, 이는 ImportError를 구체적으로 포착하며, 임의의 런타임 실패(runtime failures)를 조용한 폴백(silent fallbacks)으로 변환하지는 않습니다.
2. 크로스 어텐션이 폴백을 우회했다
임포트를 통과하는 과정에서 다음 문제가 노출되었습니다.
코드는 이미 FlashAttention 4와 PyTorch SDPA 사이를 선택하는 attention() 함수를 가지고 있었습니다. 하지만 크로스 어텐션(cross-attention)은 FA4 전용인 flash_attention()을 직접 호출했습니다. 따라서 환경에서 FA4를 제거하면 임포트 오류는 피할 수 있었지만, 실행 후반부에 대기하고 있는 단언문(assertion)은 그대로 남아있게 되었습니다.
관련 변경 사항은 작습니다:
- x = flash_attention(q, k, v, k_lens=context_lens)
+ x = attention(q, k, v, k_lens=context_lens)
이제 크로스 어텐션도 동일한 백엔드 선택 경계(backend-selection boundary)를 사용합니다.
해당 편집에는 의미론적 조건(semantic condition)이 있습니다. PR에서 다루는 호출 경로 내에서 context_lens가 None이기 때문에, 폴백(fallback) 기능은 전체 어텐션(full attention)을 계산합니다. SDPA 브랜치는 임의의 가변 길이 패딩 마스크를 구현하지 않습니다. 마스킹된 어텐션 호출을 이 경로로 라우팅하려면 추가 작업이 필요합니다.
FA4가 사용 가능한 경우, 디스패처는 동일한 인수를 기존 FA4 구현에 전달합니다.
일반적인 교훈은 호출자(callers)를 추적하는 것입니다. 선택적 백엔드(optional backend)는 해당 기능을 실제로 거쳐야 하는 실행 경로가 있을 때만 선택적입니다.
3. 모델 로딩 과정 자체의 Unix 의존성
남아있던 fcntl 의존성은 어텐션과 관련이 없었습니다.
프로젝트는 파일 잠금(file locking)을 위해 fcntl을 사용하여 기본 모델 파일 및 체크포인트를 로컬 캐시로 스테이징(staging)합니다. 기본 스테이징 경로는 동일한 플랫폼 가정을 다시 실행에 가져왔습니다.
패치는 두 로딩 유틸리티 모두에서 임포트(import)를 선택 사항으로 만듭니다. fcntl을 사용할 수 없는 경우, 스테이징은 건너뛰어지고 모델이나 체크포인트는 원래 경로에서 로드됩니다.
이는 Unix 잠금 메커니즘이 존재하는 것처럼 가장하는 것 없이 근본적인 작동 방식(가중치 읽기)을 보존합니다. 또한 캐시 최적화를 위해 새로운 크로스 플랫폼 잠금 구현을 추가하는 것도 피할 수 있게 합니다.
fcntl이 존재하는 시스템에서는 기존 스테이징 경로를 사용할 수 있습니다. FA4 임포트가 성공하는 시스템에서도 해당 어텐션 경로는 계속 사용 가능합니다.
Windows 실행을 통해 확인된 사항
해당 PR은 다음 구성을 기록하고 있습니다:
- Windows 11 및 RTX 5090.
- Python 3.12 및 PyTorch 2.10.0+cu128.
- 프로젝트의
uv.lock에 명시된 기타 패키지 버전.
- FCP 1.3B EMA 체크포인트, sailboat 예제, 시드 42, 그리고 5초 길이 요청.
패치 적용 전에는 실행이 임포트 단계에서 중단되었습니다. 하지만 패치와 SDPA를 사용하자 768×432 해상도의 프레임 80개가 생성되었고, 샘플링에 209초, 전체 실행에 231초가 소요되었으며, 최대 할당된 GPU 메모리는 16.4 GiB였습니다.
한 가지 세부 사항은 그 결과들과 나란히 놓여야 합니다. 보고된 모든 실행에서 load_diffusion_pretrained=false가 사용되었습니다. PR에서는 EMA 체크포인트가 백본(backbone) 가중치를 엄격하게 대체하므로, 기본 DiT 초기화로는 최종 출력을 결정하지 않는다고 설명합니다. 이는 모든 모델 파일이나 로딩 단계가 생략될 수 있다는 주장은 아니었습니다.
이 숫자들은 테스트된 한 가지 예시와 환경을 기술한 것입니다. 이것은 훈련 전체 과정, 모든 체크포인트 또는 모든 GPU에 대한 종단 간(end-to-end) 검증은 아닙니다.
FA4 보존과 SDPA 비교는 서로 다른 확인 절차입니다
폴백(fallback)이 작동하도록 하는 것이 필요했지만, 원래의 빠른 경로(fast path) 역시 회귀 점검(regression check)이 필요했습니다.
통제된 실험을 위해, 저는 triton-windows와 테스트 전용 No-Op인 fcntl 모듈을 사용하여 FA4를 가져올 수 있도록 만들었습니다. 이 셔임(shim)은 PR에 포함되어 있지 않으며 설치 권장 사항도 아닙니다—실제 파일 잠금 기능을 제공하지 않습니다.
FA4가 사용 가능해지자, 원래 브랜치와 패치된 브랜치는 비트 단위로 동일한 디코딩 프레임을 생성했습니다. 이 비교는 패치가 기존 FA4 경로를 변경했는지 확인합니다.
SDPA와 FA4를 비교하는 것은 다른 질문에 답합니다. 같은 예시에서 첫 번째 컨디셔닝 프레임은 동일했지만, 프레임 PSNR(Peak Signal-to-Noise Ratio)은 평균 33.5 dB, 최소 31.6 dB였습니다. 생성된 결과는 비트 단위로 동일하지 않았습니다.
FA4 샘플링에는 154초가 걸렸으며, SDPA에는 209초가 걸렸습니다. 폴백 방식은 측정 가능한 속도 트레이드오프를 가지고 예시를 실행 가능하게 만들었습니다. 이는 FA4의 정확한 수치적 출력을 재현하지는 못했습니다.
이것들은 PR의 검증 노트에 기록된 비교이며, 이 글을 위해 수행된 새로운 실험은 아닙니다.
5B 후속 작업에서 다음 경계를 발견하다
저는 또한 페이퍼 팬(paper-fan) 예시를 사용하여 5B 모델을 확인하고 그 결과를 후속 댓글에 문서화했습니다.
샘플링 완료: 231초 동안 30개의 잠재 프레임을 생성했으며, 최대 할당 GPU 메모리는 24.3 GiB였습니다.
바로 다음에 오는 VAE 디코드는 테스트된 32GB GPU / 64GB RAM 장치에서 동일한 프로세스 내에 적합하지 않았습니다. 생성기(generator)와 두 개의 KV 캐시 모두 GPU에 남아 있었고, Windows 커밋 차지(commit charge)가 104 GiB를 초과하여 실행을 중단했습니다.
저장된 라텐트(latents)를 개별적으로 디코딩하는 데는 8.2 GiB와 11초가 소요되었습니다. 이 결과는 현재 PR에서 다룬 포팅성 수정 사항을 넘어서는, 페이즈 수명 주기 및 메모리 관리 문제임을 시사합니다.
따라서 정확한 결과는 다음과 같습니다: 1.3B 예제는 엔드투엔드(end to end)로 완료되었고; 5B 예제는 디코딩을 별도의 프로세스에서 확인하며 샘플링(sampling)까지 완료되었습니다. 이 병합에는 결합된 5B 메모리 피크에 대한 해결책이 포함되어 있지 않습니다.
다음 포팅성 수정 사항에 반영할 점
이 패치는 세 가지를 연결했습니다: 선택적 백엔드(optional-backend) 감지, 해당 백엔드를 선택하는 호출자(callers), 그리고 모델 로딩의 플랫폼별 최적화입니다.
다른 연구 구현의 경우에도 동일한 검사를 따를 것입니다: 선택적 임포트(optional import)를 시도하고, 모든 호출자를 추적하며, 폴백(fallback)이 필요한 어텐션 의미론(attention semantics)을 보존하는지 확인하고, 선택된 경로를 기록하며, 전체 워크로드를 테스트할 것입니다. 성공적인 임포트는 시작에 불과합니다.
병합된 변경 사항은 모델의 설정 및 추론 지침과 함께 읽기에 충분히 작습니다. FCP와 출시된 모델들은 연구 저자들의 작업이며, 제 기여는 기존 FA4 경로를 대체하지 않고 이 테스트된 추론 경로를 Windows로 가져오는 것입니다.
다른 호출 지점(call site)을 통해 필수적인 것으로 밝혀진 "선택적" 종속성(dependency)에 부딪힌 적이 있습니까?
병합된 diff, 프로젝트 문서 및 기록된 PR 검증 결과를 AI의 도움을 받아 초안 작성함. 병합 커밋: 15f90becc4d37f4f8c74cb0c868b6d855a7c605d.