ComfyUI 영상 사양, VRAM 숫자에 붙은 조건
Wan의 TI2V는 텍스트로 영상을 만들거나 입력 이미지를 출발점으로 영상을 만드는 계열이다. 공식 문서는 이 혼합형과 텍스트 전용·이미지 전용의 큰 모델을 따로 나열한다. 따라서 파일 이름에 Wan이 들어 있다는 이유만으로 같은 워크플로에 바꿔 끼울 수는 없다. 이 글에서 고르는 것은 wan2.2_ti2v_5B_fp16.safetensors를 불러오는 공식 혼합형 템플릿이다. 고화질 사례를 보고 다른 계열의 파일을 섞으면 사양 비교의 출발점이 달라진다.
ComfyUI의 안내에는 자체 오프로딩이라는 단서가 붙는다. 반면 Wan README의 예시 명령은 --offload_model True, --convert_model_dtype, --t5_cpu를 포함한 상태에서 24GB 이상인 GPU를 제시한다. 같은 README는 80GB 이상 GPU라면 이 세 옵션을 빼고 실행 속도를 높일 수 있다고 덧붙인다. 24GB라는 숫자도 메모리를 아끼는 옵션을 이미 켠 상태의 값이라는 뜻이다. 이것은 원본 파이썬 실행기의 예시다. 그 옵션 문자열을 ComfyUI 노드의 빈 입력칸에 넣는 사용법으로 옮길 수 없으며, 원본의 체크포인트 폴더와 ComfyUI용 분리 파일도 구별해야 한다.
파일이 들어갈 공간과 실행할 공간은 다르다
Wan의 실제 실행 소스에서 t5_cpu 분기는 텍스트 인코더를 CPU에서 계산하고 결과를 장치로 옮긴다. 오프로딩이 켜진 경로는 생성 모델을 GPU로 올렸다가 샘플링 뒤 CPU로 내린 다음 VAE 디코딩으로 넘어간다. 이런 이동은 모델 전체를 계속 GPU에 둔 채 실행하는 경우와 다른 메모리 배치를 만든다. 다만 해당 코드는 Wan 원본 구현이므로, ComfyUI가 모든 단계를 똑같이 수행한다고 단정할 근거는 아니다.
ComfyUI 쪽 load_models_gpu도 모델에 필요한 공간만 세지 않는다. 추론용 공간과 예약 여유를 함께 계산하고, 장치의 남은 메모리와 로딩 상태를 고려해 낮은 VRAM용 로딩 범위를 정한다. 모델 파일이 디스크에 들어갔다는 사실은 계산 중에도 여유가 남는다는 뜻이 아니다. 영상의 잠재 데이터와 디코딩 결과까지 담을 공간이 별도로 필요하므로, 다운로드 크기 하나로 그래픽카드의 합격선을 정할 수 없다.
모델 파일의 저장 공간은 별도로 셀 수 있다. 공식 배포 목록에서 이 조합의 생성 모델은 9,999,658,848바이트, VAE는 1,409,400,960바이트, 텍스트 인코더는 6,735,906,897바이트다. 합계는 18,144,966,705바이트로, 십진 단위 약 18.15GB다. 이는 모델 파일만 합한 값이며 앱·출력·임시 공간을 포함한 권장 여유 디스크가 아니다. 목록에 적힌 파일 크기와 탐색기의 표시가 다르면 바이트를 기준으로 비교할 수 있다.
파일 목록의 숫자를 실행 VRAM으로 그대로 옮겨서는 안 된다. 반대로 메모리를 다른 곳으로 옮길 수 있다는 말만으로 시스템 RAM이 얼마든지 작아도 된다고 읽을 수도 없다. 이번에 대조한 공식 안내에는 이 ComfyUI 템플릿에 대한 확정 RAM 최저치나 모든 GPU의 속도표가 없다. 그래서 메모리 용량별 완료 시간이나 특정 카드의 성공 여부를 표로 만들어 붙이지 않았다. 기존 모델별 VRAM 설명도 영상 템플릿의 실측표를 대신하지는 않는다.
ComfyUI 영상 워크플로, 모델과 입력을 맞추는 순서
시작점은 공식 문서의 템플릿이다. 템플릿 목록에서 Wan2.2 5B를 찾거나 공식 JSON을 불러온 뒤, 화면에 저장된 모델 이름부터 맞춘다. 노드를 손으로 닮게 그리는 것보다 파일명과 연결을 함께 가져오는 편이 원인을 좁히기 쉽다. 불러오기 방식은 워크플로 파일과 PNG 편에서 다뤘다. 영상 파일을 열면 언제나 원래 그래프가 복원된다고 가정할 필요는 없다.
같은 Wan2.2라도 큰 모델의 템플릿은 모양이 다르다. 공식 문서의 14B 텍스트 투 비디오 예제는 Load Diffusion Model 노드 두 개에 high noise와 low noise 모델을 하나씩 불러오고, VAE도 wan_2.1_vae.safetensors를 쓴다. 5B 혼합형은 생성 모델 하나와 wan2.2_vae.safetensors 조합이다. 다른 계열의 예시 화면을 보고 파일만 바꿔 넣으면 로더 수와 VAE부터 어긋나는 이유다. 파일 목록이 빈 증상과 노드 종류를 찾지 못하는 증상도 나눠 보면, 모델 폴더를 볼지 본체 버전과 시작 기록을 볼지 달라진다.
이 템플릿의 로더는 생성 모델, 텍스트 인코더, VAE를 각각 읽는다. 생성 모델은 움직임을 샘플링하는 경로에, 인코더는 프롬프트를 조건으로 바꾸는 경로에, VAE는 잠재 데이터와 이미지 사이를 오가는 경로에 연결돼 있다. 어느 파일 하나가 빠져도 남은 로더가 같은 역할을 맡아 주지 않는다. 모델 메뉴가 비었다면 우선 파일을 둔 폴더 종류와 실제 파일 이름이 문서의 조합에 맞는지 살펴볼 근거가 된다.
이미지 입력을 켜기 전, 텍스트 경로를 이해한다
공식 문서가 지정한 위치는 생성 모델의 models/diffusion_models, 텍스트 인코더의 models/text_encoders, VAE의 models/vae다. 생성 모델과 VAE 파일은 Wan2.2 배포에서 받지만, 문서와 템플릿이 연결한 텍스트 인코더 다운로드는 Wan2.1 재포장 저장소를 가리킨다. 주소의 계열 이름이 다르다는 이유만으로 임의의 다른 인코더를 고르는 것은 공식 조합을 바꾸는 일이다.
템플릿의 Load CLIP는 UMT5 파일을 선택하고 타입을 wan으로 저장해 두었다. Load VAE는 wan2.2_vae.safetensors를 고른다. 같은 Wan 안내 페이지에 등장하는 큰 모델용 VAE 이름과 섞지 않도록 실제 선택값을 볼 필요가 있다. 로더 이름이 CLIP이라고 해서 다른 이미지 모델에서 쓰던 CLIP 파일을 그대로 가져오는 구성은 아니다.
처음 불러온 공식 JSON에서 LoadImage는 우회 상태다. 텍스트만으로 만드는 경로를 먼저 사용할 수 있고, 입력 그림에서 이어지는 영상을 원하면 해당 노드의 우회를 풀고 이미지를 넣는다. 문서는 이 전환에 Ctrl+B를 안내한다. 프롬프트에 그림을 묘사한 문장만 적는 것과 실제 start_image가 연결된 상태는 다르다. 이미지가 바뀌어도 결과에 반영되지 않는다면 우회 여부와 소켓 연결부터 볼 이유가 된다.
노드 소스도 이 차이를 보여 준다. start_image가 없으면 빈 잠재 데이터를 돌려주지만, 입력이 있으면 지정한 폭과 높이로 가운데 기준 리사이즈를 하고 VAE로 인코딩한 값을 잠재 데이터 앞부분에 넣는다. 원본과 출력의 화면 비율이 다르면 가장자리 구도가 달라질 수 있다. 모서리에 중요한 물체가 있는 그림이라면 출력 화면 비율에 맞춘 구도를 먼저 준비하는 편이 비교에 유리하다. 이는 코드의 전처리 방식에서 도출한 조언이며, 입력 그림 전체를 그대로 보존한다는 보장은 아니다.
문서가 소개한 TI2V 해상도는 가로형 1280×704 또는 세로형 704×1280이다. 흔히 붙는 720P라는 계열 표시만 보고 높이를 임의로 바꾸기보다, 가져온 템플릿의 실제 폭과 높이를 기준점으로 삼을 수 있다. 처음부터 다른 VAE나 추가 보정 노드를 겹치면 입력 처리와 생성 결과 중 무엇이 달라졌는지 가르기 어려워진다. 기본 경로가 저장까지 이어진 뒤에 확장할 이유가 생긴다.
인용 — Comfy Org. Wan2.2 공식 문서The Wan2.2 5B version should fit well on 8GB vram with the ComfyUI native offloading.
Wan2.2 5B는 ComfyUI 자체 오프로딩을 쓰면 8GB VRAM에 들어갈 것으로 안내한다는 뜻이다. 이 문장의 실행 조건까지 함께 읽어야 한다.
로컬 AI 영상 길이, 프레임과 재생 속도를 따로 보기
길이를 다루는 입력은 생성할 프레임 수와 그 프레임을 재생할 속도로 나뉜다. 공식 템플릿은 Wan22ImageToVideoLatent의 길이를 121, CreateVideo의 재생 속도를 24fps로 저장해 두었다. 프레임 수를 재생 속도로 나누면 이 설정은 약 5.04초 분량이다. 이 시간은 결과물의 재생 길이이며 컴퓨터가 계산을 마칠 때까지 걸리는 시간이 아니다. 짧은 영상이라는 말만으로 대기 시간이 짧다고 예상할 근거는 없다.
여기에는 화면에서 놓치기 쉬운 차이가 있다. 같은 이름의 노드를 새로 추가할 때 소스에 적힌 길이 기본값은 49이고, 공식 JSON을 불러올 때는 저장된 121이 들어온다. 같은 24fps로 재생하면 49프레임은 약 2.04초다. 다른 화면의 설정을 따라 했는데 생성 부담이나 길이가 달라졌다면, 노드 이름보다 그 안의 실제 값을 비교할 차례다. 기본값이라는 말은 코드 기본값과 배포 예시 저장값을 구별해서 써야 한다.
프레임을 줄이면 어디가 줄어드는가
Wan 원본 실행 인자의 설명은 프레임 수를 4n+1 꼴로 두라고 적는다. ComfyUI 노드도 길이 입력의 간격을 4로 잡고, 시간축 잠재 길이를 ((length - 1) // 4) + 1로 계산한다. 그래서 비교용 길이를 줄일 때에도 템플릿과 같은 계열의 값을 유지할 근거가 있다. 소스에 입력 최대치가 크게 열려 있다는 사실은 그 길이의 영상이 학습 범위 안에서 잘 나오거나 메모리에 들어간다는 보증이 아니다.
이 식에 따라 121프레임은 시간축 잠재 칸 31개, 49프레임은 13개가 된다. 폭과 높이는 각각 나누기 16으로 잠재 배열의 공간축에 들어간다. 길이를 줄이는 일은 단순히 마지막 저장 파일을 짧게 자르는 일과 다르다. 샘플링이 다룰 데이터 자체가 달라진다. 다만 이 칸 수의 비율을 실제 총 VRAM이나 완료 시간의 비율이라고 말할 수는 없다. 가중치와 다른 계산 공간도 함께 필요하기 때문이다.
재생 속도만 낮추는 것은 별개의 조작이다. CreateVideo는 전달받은 이미지와 fps로 영상 구성요소를 만들며, 이 경로에 프레임을 새로 생성하는 샘플러는 없다. 같은 이미지를 더 오래 보여 줄 수는 있어도 동작 사이를 메워 주지는 않는다. 움직임을 길게 만들고 싶다는 요청을 fps 변경만으로 해결하면 느리게 재생되는 결과와 새 움직임이 추가된 결과를 혼동하게 된다.
샘플링 설정도 서로 다른 기본값을 가진다. 공식 ComfyUI 템플릿에는 20스텝, CFG 5, uni_pc, simple, shift 8이 저장돼 있고, Wan 원본 설정 파일은 50스텝과 shift 5.0을 둔다. 한쪽의 수치를 다른 쪽에 옮겼다고 같은 품질이나 시간이 재현되는 것은 아니다. 비교 메모에는 실행기와 템플릿을 함께 남겨야 «기본 설정으로 만들었다»는 말의 범위가 분명해진다.
처음 비교할 때는 원래 설정을 남긴 뒤 길이나 해상도 중 바꾼 항목이 무엇인지 적어 두는 편이 낫다. 시드까지 계속 무작위로 바뀌면 움직임의 차이를 설정 효과로 오해하기 쉽다. 시드와 프롬프트를 고정하는 이유는 시드·CFG 비교 편과 같다. 이 과정은 조건을 줄이는 비교 방법이며, 같은 시드만으로 장치나 소프트웨어가 다른 결과까지 일치시킨다는 주장은 아니다.
공식 JSON의 KSampler 저장값에는 시드 뒤에 randomize가 들어 있다. 따라서 템플릿을 가져왔다는 사실만으로 반복 비교의 시드가 고정돼 있다고 생각할 수 없다. 시드 숫자를 남기는 일과 다음 실행 때도 같은 숫자를 쓰도록 두는 일은 별개다. 후보를 탐색할 때는 변화를 줄 수 있지만, 길이 설정의 영향을 비교하는 동안에는 실제 실행에 쓰인 시드와 프레임 수를 함께 기록해야 비교 조건이 드러난다.
ComfyUI 영상이 멈추거나 기대와 다를 때
오류를 읽는 순서는 실패한 단계에 따라 달라진다. 모델 목록에서 파일을 못 고르는 상태와, 샘플링이 진행되다 메모리 오류가 난 상태, 마지막 영상 저장에서 실패한 상태는 서로 다른 경로다. 공식 템플릿에도 로더, KSampler, VAE Decode, CreateVideo, SaveVideo가 나뉘어 있다. 결과가 없다는 이유로 전부 프롬프트 문제로 돌리면 파일 경로와 저장 처리의 문제를 건드리지 못한다.
샘플링은 끝났는데 디코딩에서 메모리가 부족할 수도 있다. Wan 원본 소스는 생성 모델을 CPU로 내리는 분기 뒤에 VAE 디코딩을 수행한다. 계산 단계를 갈라 메모리를 쓰는 구조임을 보여 주는 대목이다. ComfyUI에서도 로딩 여유를 따로 계산하므로, 진행 막대가 끝에 가까워졌다는 사실만으로 영상 파일까지 만들어졌다고 판단할 수 없다. 오류가 난 노드와 실행 기록을 남기면 다음 비교에서 길이를 줄일지, 파일 선택을 고칠지 구별할 수 있다.
무음 출력과 움직임의 한계를 나눠 평가한다
이 TI2V 템플릿은 디코딩된 이미지를 CreateVideo로 보내고, 그 VIDEO 출력을 SaveVideo에 연결한다. CreateVideo의 선택 오디오 입력은 연결돼 있지 않다. 따라서 이 구성에서 만들어진 영상이 무음인 것은 오디오 모델이 실패했다는 뜻이 아니다. 소리를 넣을 수 있는 소켓이 있다는 사실과 소리 자체를 만들어 내는 기능이 있다는 말은 다르다. Wan 원본 저장소에서도 음성 파일을 입력으로 받는 작업은 Wan2.2-S2V-14B라는 별도 모델로 나뉘어 있다. 말하는 장면이나 효과음까지 필요하다면 5B 템플릿 밖의 모델과 편집 경로가 작업 범위에 들어간다.
저장 위치도 노드 역할에 붙어 있다. SaveVideo는 ComfyUI의 출력 폴더를 기준으로 파일을 쓰며, 템플릿의 접두사는 video/ComfyUI다. 파일을 찾을 때는 실행한 ComfyUI의 출력 폴더 아래 영상 하위 폴더를 볼 수 있다. 모델 파일이 있는 폴더나 워크플로 JSON을 받은 폴더에 결과가 생긴다고 가정하면 저장에 성공하고도 놓치기 쉽다.
현재 대조한 SaveVideo 소스는 컨테이너와 코덱을 구별한다. 자동 형식은 AV1 코덱이면 WebM, 그 외에는 MP4를 고르는 분기가 있다. 재생기에서 파일이 안 열린다면 확장자와 선택한 형식도 확인할 대상이다. 다만 파일명이 정상이라고 생성 품질까지 평가된 것은 아니다. 저장 성공은 전달받은 영상을 파일로 썼다는 뜻이고, 장면의 형태와 움직임이 요청에 맞는지는 결과를 재생해 봐야 알 수 있다.
모델 카드는 텍스트·이미지 조건의 영상 생성과 고압축 VAE를 설명한다. 이것만으로 특정 입력의 물체가 끝까지 같은 모양을 유지하거나, 지시한 동작이 정확하게 끝난다는 보장은 되지 않는다. 평가할 때는 멋진 첫 화면뿐 아니라 뒤쪽에서 물체가 이어지는지, 화면 비율을 바꾼 탓에 구도가 잘렸는지, 의도한 움직임이 보이는지를 따로 볼 필요가 있다. 이는 품질을 살피기 위한 편집 기준이며 실패율이나 모델 순위를 측정한 결과가 아니다.
여러 후보가 필요하더라도 처음부터 배치 크기를 키우는 방법만 있는 것은 아니다. 이 공식 템플릿의 배치 크기는 1이다. 메모리 여유가 불분명한 상태라면 같은 설정에서 후보를 순서대로 비교하는 방법을 생각할 수 있다. 이미지 생성 때도 배치 크기와 반복 실행은 다른 개념이므로 배치와 대기열 편이 이어진다. 어떤 후보가 더 나은지와 한 번에 얼마나 계산할지는 별도의 판단이다.
자주 묻는 것
VRAM 8GB면 Wan 영상을 만들 수 있나?
ComfyUI 공식 문서는 자체 오프로딩을 전제로 Wan2.2 5B가 8GB VRAM에 들어갈 것으로 안내한다. 이 문장만으로 모든 해상도·길이·GPU의 성공을 확정할 수는 없다. Wan 원본 실행기의 24GB 안내는 다른 구성의 예시이므로, 사용할 실행기와 템플릿을 먼저 맞춰 읽어야 한다.
같은 노드인데 영상 길이가 다른 이유는 무엇인가?
노드 소스의 길이 기본값은 49지만 공식 템플릿에는 121이 저장돼 있다. 템플릿의 24fps를 적용하면 각각 약 2.04초와 5.04초다. 노드를 새로 만든 화면과 JSON을 가져온 화면의 실제 값을 비교하면 차이가 드러난다.
fps를 낮추면 더 긴 움직임을 생성하나?
CreateVideo는 받은 이미지에 재생 속도를 지정한다. fps만 낮추면 같은 프레임 묶음을 오래 재생할 뿐 새 움직임을 계산하지 않는다. 생성할 프레임 수는 잠재 노드의 length 쪽 설정이다.
입력 이미지를 넣었는데 가장자리 구도가 달라지는 이유는 무엇인가?
Wan22ImageToVideoLatent는 이미지를 출력 폭·높이에 맞춰 가운데 기준으로 리사이즈한 뒤 인코딩한다. 입력과 출력의 화면 비율이 다르면 전처리로 구도가 달라질 수 있다. 생성 중 형태 변화와 입력 시점의 잘림을 나누어 살펴보면 원인을 좁히기 쉽다.
영상은 저장됐는데 소리가 없는 이유는 무엇인가?
이 공식 TI2V 템플릿에는 오디오를 생성하거나 CreateVideo에 전달하는 연결이 없다. CreateVideo는 선택 오디오를 받아 영상에 넣을 수 있지만 자체 음성 생성기 역할은 아니다. 기본 구성의 출력은 무음으로 이해하면 된다.
정리 — 실행 조건과 저장값을 먼저 남긴다
ComfyUI 로컬 영상은 모델 이름만 고르는 작업으로 끝나지 않는다. 공식 템플릿의 생성 모델·텍스트 인코더·VAE 조합을 맞추고, 오프로딩이 붙은 메모리 안내를 해당 실행기의 조건으로 읽어야 한다. 디스크에 받을 파일 크기는 계산할 수 있지만, 실행 중 메모리와 완료 시간은 그 합계로 대체되지 않는다.
실제로 비교를 시작할 때 남길 것은 사용한 템플릿, 파일명, 폭·높이, 프레임 수, fps, 샘플러 설정이다. 특히 노드 기본값과 JSON 저장값이 다른 길이 설정은 확인할 이유가 분명하다. 짧은 시험이 파일 저장까지 이어지면 이미지 입력과 움직임을 평가하고, 실패했다면 멈춘 단계부터 좁혀 가면 된다. 이 글의 숫자는 공식 자료와 코드의 값 또는 그 값으로 계산한 재생 시간이며, 장비별 생성 속도나 품질을 실측한 결과는 아니다.
참고 자료
- Comfy Org. Wan2.2 공식 사용 문서 — 자체 오프로딩의 8GB 안내, 모델 종류·폴더, 이미지 입력 활성화(2026-10-31 확인). docs.comfy.org
- Wan-Video. Wan2.2 README — TI2V 실행 명령의 24GB 조건과 실제 해상도(2026-10-31 확인). raw.githubusercontent.com
- Comfy Org. Wan2.2 5B 공식 워크플로 — 로더·121프레임·24fps·샘플러 저장값·이미지 우회·소리 미연결(2026-10-31 확인). raw.githubusercontent.com
- ComfyUI. Wan22ImageToVideoLatent 소스 — 49프레임 기본값, 길이 간격, 잠재 배열과 이미지 전처리(2026-10-31 확인). raw.githubusercontent.com
- ComfyUI. CreateVideo·SaveVideo 소스 — 재생 속도·선택 오디오·저장 위치·출력 컨테이너(2026-10-31 확인). raw.githubusercontent.com
- Wan-Video. TI2V 5B 설정 파일 — 24fps·121프레임·50스텝·VAE 압축 축 설정(2026-10-31 확인). raw.githubusercontent.com
- Wan-Video. generate.py 소스 — 프레임 수의 4n+1 조건과 CPU·형식 변환 옵션(2026-10-31 확인). raw.githubusercontent.com
- Wan-Video. textimage2video.py 소스 — 텍스트 인코더 CPU 분기·생성 모델 이동·디코딩 순서(2026-10-31 확인). raw.githubusercontent.com
- Wan-AI. Wan2.2 TI2V 5B 모델 카드 — 텍스트·이미지 조건의 영상 생성과 VAE 압축 설명(2026-10-31 확인). huggingface.co
- ComfyUI. model_management.py 소스 — 모델 상주 메모리와 추론·예약 메모리를 나눠 다루는 로딩 처리(2026-10-31 확인). raw.githubusercontent.com
- Comfy Org. 생성 모델·VAE 파일 목록 — 생성 모델과 VAE의 파일 바이트 수, 조사표에 개별 API 주소 기록(2026-10-31 확인). huggingface.co
- Comfy Org. UMT5 인코더 파일 목록 — 텍스트 인코더의 파일 바이트 수(2026-10-31 확인). huggingface.co
