저장소는 GitHub의 ComfyUI-Fantastic-MiniMaxH3-PromptBuilder에서 찾을 수 있다. 다시 돌아왔다. RefMod를 더 잘 작동하게 만들고 아이덴티티/블리딩 문제를 상당수 해결했다. 물론 시간과 메모리를 대가로 치렀다. 이것이 하는 일은 다음과 같다. 원조 바닐라 refmod는 미디어를 .safetensors 파일에 잠재(latent)로 저장하고 그 모든 것을 참조 없이 MiniMax H3 DiT에 직접 넣었으며, 텍스트 인코더는 그것을 본 적이 없었다. 이 방식은 refmod가 하나일 때는 잘 작동했다. 모델이 그 참조들로 무언가는 해야 한다는 것을 알았고 놀랍도록 잘 해냈기 때문이다. 하지만 그로 인해 사람들이 좋은 닮음을 얻으려고 여러 refmod를 쌓아 올리는 식으로 사용하게 되었다.

이전 구현은 그 잠재의 일부를 텍스트 인코더에 넣었는데, 몇 프레임을 다시 인코딩하는 비용이 들었다(매 4번째 프레임이 2개 묶음 블록으로 비전 모델에 제시됨). 그리고 텍스트 인코더가 그것을 보게 했다. 이것은 프롬프팅할 때 모델에 참조 앵커를 주기 위한 것이었다(예: Subject 1은 Video 1 속 인물이라는 식). 이 때문에 그 프레임들이 매 생성마다 텍스트 인코더를 위해 인코딩되면서 속도가 느려졌다. GitHub의 한 사용자가 이를 불평했기에 속도 개선과 캐싱을 알아보았다. 그런데 .safetensors는 mp4나 mkv처럼 그저 래퍼(wrapper)일 뿐이라 잠재 데이터와 함께 여러 종류의 데이터를 저장할 수 있다는 것을 알게 되었다. 그래서 속도 개선은 쉬웠다. refmod 사진을 실제 jpeg 데이터로 저장해 같은 파일 안의 잠재와 함께 담는 것이다. 비디오 파일 안에 자막이 들어있는 것처럼, 비디오와 오디오에 다른 종류의 데이터가 함께 포장되어 있는 셈이다. 실제 jpeg 데이터를 담으면 VAE를 거치지 않고 텍스트 인코더에 직접 넣을 수 있고, 텍스트 인코더의 컨디셔닝은 실행 간에 캐시되어 refmod의 순서나 강도를 바꾸지 않는 한 매 실행마다의 처리가 모두 생략된다. 그리고 jpeg 데이터는 모델에 전달되지 않고 포장된 잠재만 전달되므로 기존 refmod와 같은 방식으로 기능한다.

하지만 여기서 생각이 시작되었다. 왜 프레임을 텍스트 인코더에 제시하는 방식을 바꿔 더 나은 컨디셔닝을 얻지 않는가? Fantastic H3 RefMod Text Encode 노드에 stack_pictures 함수가 등장했다. 기본값인 every 4th는 기존 동작대로 매 4번째 프레임을 2개 묶음으로 보내며, 가장 가볍게 실행되고 refmod 1개에 적합하다. up to 8은 데이터셋 전반에 걸쳐 최대 8개 프레임을 샘플링해 묶음 대신 개별적으로 넣으며, 8프레임 제한이 대규모 데이터셋 전체를 실행하는 것보다 가볍고 전반적인 디테일은 늘지만 처리 시간이 더 든다. 마지막으로 all은 모든 프레임을 텍스트 인코더에 보내는데, 시간이 상당히 늘어나지만 최대 디테일을 제공하고 예시에서 볼 수 있듯이 캐릭터 블리딩이 거의 또는 전혀 없다. 적어도 내가 보기에는 그렇다. 예시는 캐릭터당 이미지 6개와 각 목소리당 몇 초 분량의 오디오로 만들었다. 데이터셋은 모두가 사랑하는 파일 공유의 수상한 구글 드라이브 링크로 올려두었다(당연히 Jackie Chan의 Chun Li가 가장 형편없는데, 찾을 수 있는 소스가 모두 상당히 저품질이었기 때문이다).

기본적으로 refmod를 로드하고 subject_definitions와 retention_analysis 섹션을 작성했다(내 RefMod 라이브러리에 디테일을 설정하고 프롬프트 빌더의 Draft from Refmods를 사용하면 이 모든 것이 자동으로 로드된다). 또한 속도 개선을 위해 comfy-kitchen과 함께 8스텝 hyperflow를 사용했고, 최종 결과를 다듬기 위해 내 오디오 리파이너 스위트를 사용했다. 3개의 refmod를 함께 사용했을 때(약 14,900 토큰) 5090에서 0.98mp 기준 반복당 약 32초가 걸렸다. 목소리는 여전히 이상할 수 있고 어떤 이유에서인지 사람을 서로 바꿔치기하는 경우가 있다는 점에 유의하라. 그리고 피사체를 정의할 때는 다른 캐릭터와 구별되는 더 고유한 특징을 말하도록 조정하는 것이 좋다. 예컨대 Callina Liang은 타원형 얼굴, Ming-Na Wen은 더 각진 턱으로 묘사했다. 평소라면 쓰지 않을 묘사지만 다른 인물과의 구별점으로는 잘 작동했다. H3는 증류 모델이라 네거티브를 처리하지 못한다는 점도 기억하라. 따라서 이 사람은 보조개가 없다고 말해도 아무 효과가 없으니 프롬프트에서 no와 not 표현은 모두 빼야 한다.

기존 RefMod로 이것을 쓰는 데 특별한 준비가 필요한가? 아니다. 텍스트 인코더는 safetensors에 이미지 데이터가 저장되어 있는지 감지하고, 없다면 설정한 동작에 따라 VAE 디코딩을 수행한 뒤 그 디코딩된 이미지를 텍스트 인코더에 넣고 워크플로에서 refmod를 바꿀 때까지 결과를 캐시한다. 그래서 기존 refmod도 잘 작동한다. 다만 내 refmod 노드로 새로 만들거나 다시 만들면 이미지 데이터가 올바른 해상도로 잘려 파일에 직접 저장된다. 텍스트 인코더에 더 깨끗한 이미지가 전달되고 항상 디코딩 단계를 건너뛴다. 또한 기본 해상도를 1024에서 768로 바꿨는데, 토큰을 크게 절약할 수 있고 H3의 네이티브 해상도이기 때문이다. 아, 그리고 Media Loader에 마스킹 기능도 이제 생겼다. 비디오를 편집하고 싶을 때를 위해 Media Loader에 레이어 마스킹 시스템을 추가했다. 우클릭하면 바꾸고 싶은 부분을 자동으로 마스킹할 수 있다.