ComfyUI v0.33.1에서 MiniMax Music 3 오류가 수정된 이유
ComfyUI에서 MiniMax Music 3 워크플로우를 구성했는데 모델은 정상적으로 불러온 뒤 생성 단계에서 멈춘다면, 모델 파일부터 다시 받을 필요는 없다. 특히 ComfyUI를 --disable-dynamic-vram 옵션으로 실행하고 있다면 먼저 버전을 확인하는 편이 빠르다.
comfyui에서 가장 먼저 볼 변화
ComfyUI v0.33.1 릴리스에는 MiniMax Music이 non-dynamic VRAM 환경에서 동작하지 않던 문제를 수정하는 변경 #15588이 포함됐다. 현재 안정 릴리스가 더 올라간 환경이라면 이 수정 역시 이후 버전에 포함되므로, 구버전에서 같은 증상을 겪고 있다면 업데이트 여부가 첫 번째 체크 포인트다. GitHub
MiniMax Music 3에서 무엇이 바뀌었나
MiniMax Music 3 지원은 ComfyUI 코어에 들어오면서 전용 텍스트 인코딩과 오디오 생성 경로를 사용한다. MiniMax Music3 Text Encode 노드는 caption과 lyrics를 받아 음악 생성에 필요한 conditioning sequence를 만드는 구조다. GitHub
문제는 이 모델의 DAV와 메모리 처리 방식이 일반적인 이미지 생성용 VAE처럼 단순하지 않다는 점이다. 현재 ComfyUI 코드에서도 MiniMax Music3 DAV는 별도 모델로 판별되며, float32를 작업 dtype으로 사용하고 오프로딩 방식에도 별도 처리가 적용된다. GitHub
--disable-dynamic-vram 사용자가 먼저 확인할 조건
이번 수정의 검색 의도는 명확하다. ComfyUI를 기본 메모리 관리 방식이 아니라 dynamic VRAM을 끈 상태에서 MiniMax Music 3를 사용하는 경우다.
v0.33.1 변경 내역에는 이 조건을 직접 지목해 “MiniMax Music이 non dynamic vram에서 작동하지 않는 문제”를 수정했다고 기록되어 있다. 따라서 MiniMax Music 3 자체가 실행되지 않는다고 판단하기 전에 현재 ComfyUI가 v0.33.1 이전인지 확인해야 한다. GitHub
업데이트 전후를 비교할 때는 워크플로우 JSON보다 먼저 ComfyUI 시작 로그를 보는 것이 좋다. 실행 옵션과 ComfyUI 버전을 동시에 확인하면 모델 문제인지 메모리 관리 경로 문제인지 빠르게 범위를 좁힐 수 있다.
comfyui가 ComfyUI 워크플로우에 미치는 영향
왜 단순한 VRAM 부족 문제와 다른가
기존 방식과 비교해야 할 부분
non-dynamic VRAM 오류라고 해서 곧바로 “GPU 메모리가 부족하다”는 뜻은 아니다. ComfyUI에는 HIGH_VRAM, NORMAL_VRAM, LOW_VRAM, NO_VRAM처럼 여러 메모리 상태가 있으며, dynamic 방식과 non-dynamic 방식에서는 모델을 GPU에 올리고 내리는 내부 경로도 달라진다. GitHub
MiniMax Music3 DAV에는 현재 코드상 non-dynamic caster가 그대로 처리하기 어려운 Parameters와 Buffers가 존재한다는 설명도 남아 있다. 그래서 ComfyUI는 dynamic VRAM이 활성화되지 않은 경우 이 모델에 별도 처리를 적용한다. GitHub
MiniMax Music 3 실행 오류에서 먼저 확인할 세 가지
문제가 발생하면 아래 순서면 충분하다.
ComfyUI 버전이 v0.33.1 이상인지 확인
실행 옵션에 --disable-dynamic-vram이 들어가 있는지 확인
MiniMax Music 3 관련 모델이 정상적으로 인식되는지 시작 로그 확인
성능과 결과 품질에서 확인할 차이
특히 오래된 portable 설치를 계속 업데이트하지 않고 사용했다면 워크플로우만 새로 받아도 코어 수정은 적용되지 않는다. 노드를 다시 연결하기 전에 ComfyUI 자체 버전을 확인해야 하는 이유다.
워크플로우 구성에서 놓치기 쉬운 부분
버전을 올린 뒤에는 기존 워크플로우에서 동일한 caption과 lyrics로 짧은 길이부터 다시 테스트하는 편이 좋다. 한 번에 긴 음악을 생성하면 로딩 단계와 실제 생성 단계 중 어디에서 문제가 발생했는지 구분하기 어려워진다.
ComfyUI v0.34.0의 GGUF·Dynamic VRAM 오류는 별개다
2026년 8월 26일 공개된 v0.34.0이 현재 GitHub 릴리스 페이지에서 최신 안정 버전으로 표시되고 있다. 따라서 지금 새로 설치한다면 굳이 v0.33.1에 머무를 이유는 없고 최신 안정판을 기준으로 테스트하는 것이 낫다. GitHub
다만 여기서 주의할 부분이 하나 있다. MiniMax Music 3 + GGUF text encoder + Dynamic VRAM + CUDA Graph 조합에서는 v0.34.0에서도 별도의 충돌 사례가 보고되어 있다.
해당 이슈에서는 Q4_0 GGUF 텍스트 인코더를 Dynamic VRAM 로더로 사용할 때 CUDA Graph capture 과정에서 CPU와 CUDA 간 tensor 이동 오류가 발생했다. 반대로 CUDA Graph 관련 경로를 비활성화하면 같은 모델이 실행된다는 재현 결과가 제시됐다. GitHub
즉 --disable-dynamic-vram에서 MiniMax Music 자체가 작동하지 않던 #15588과, 최신 버전에서 GGUF Dynamic VRAM 조합으로 발생하는 CUDA Graph 문제는 같은 오류로 보면 안 된다. 증상이 비슷해 보여도 실행 옵션과 사용하는 text encoder 형식에 따라 원인이 달라진다.
실제로 적용할 때 체크할 점
업데이트 후에도 안 된다면 ComfyUI 로그를 이렇게 본다
v0.33.1 이상인데도 실패한다면 먼저 오류가 모델 로딩 이전인지, MiniMax Music3 Text Encode 단계인지, 실제 AR sampling 단계인지를 구분해야 한다.
모델을 불러오자마자 실패한다면 파일 경로나 모델 형식을 먼저 확인한다. 반면 AR sampling이 시작된 뒤 GGUF dequantization이나 CUDA Graph 관련 오류가 나타난다면 #15588과 다른 문제일 가능성이 높다.
CUDA Graph·Q4_0·ComfyUI-GGUF 로그가 보일 때
특히 에러 로그에 CUDA graph capture, CPU and CUDA tensors, Q4_0, ComfyUI-GGUF 같은 내용이 함께 보인다면 단순히 ComfyUI를 재설치하는 식으로 접근하기보다 사용 중인 GGUF 로더와 Dynamic VRAM 조합부터 확인하는 편이 낫다. 현재 이 조합은 별도의 공개 이슈로 추적되고 있다. GitHub
마지막 확인
MiniMax Music 3를 --disable-dynamic-vram으로 실행하다 실패했다면 가장 먼저 ComfyUI를 최신 안정판으로 업데이트하고 같은 워크플로우를 다시 실행하면 된다. v0.33.1에는 해당 조건을 직접 대상으로 한 수정 #15588이 이미 들어갔다.
반대로 최신 버전에서도 GGUF와 CUDA Graph 관련 오류가 나온다면 다른 문제다. 이 경우 시작 로그의 ComfyUI 버전, VRAM 모드, text encoder 종류와 오류가 발생한 단계를 함께 확인해야 원인을 정확히 좁힐 수 있다.