Tessera: MiniMax H3용 타일드 4K 및 8K 비디오 업스케일링

H3는 544p의 짧은 클립에 강하지만 그 이상에서는 비용이 크게 늘어납니다. 더 높은 해상도로 가는 기존 경로는 더 큰 크기에서 프레임을 다시 생성하고 느리고 덜 안정적인 패스를 감수하거나, 픽셀을 업스케일한 뒤 디테일을 잃는 방식입니다. Tessera는 세 번째 경로를 택합니다. 소스 클립을 모델이 이미 이해하는 참조로 유지하고, 중립적인 리샘플러로 그림을 업스케일한 다음, H3가 정확한 로컬 조건화 아래에서 그 플레이트의 각 타일을 다시 렌더링하도록 합니다.

이 팩은 추가 의존성이 없는 순수 ComfyUI 노드로 제공되며, 버전 1.0.0이고, pyproject.toml에 Comfy Registry 게시를 위한 [tool.comfy] 블록(DisplayName = "Tessera", PublisherId = "hashu786")이 포함되어 있습니다.

544p 소스 클립	프로젝트 홍보 영상에서 추출한 3840x2176 렌더

타일은 서로가 아니라 플레이트에 고정됩니다

큰 잠재 데이터를 조각별로 정교화하는 가장 명백한 방법은 타일을 순서대로 순회하면서 각 타일이 이웃의 완료된 경계를 물려받게 하는 것입니다. Tessera의 작성자는 H3에서 이 방식이 왜 실패하는지 측정했습니다. 타일 네 개에 걸쳐 행을 따라 정합 드리프트가 +1.5, -2.1, -9.3, -15.5 px만큼 누적되는데, 이는 모든 타일이 소스가 아니라 이전 타일의 추측을 조건으로 삼기 때문입니다.

Tessera는 이 의존 관계를 뒤집습니다. 각 타일은 동일한 정답(ground truth)에서 잘라낸 자기 자신의 크롭을 기준으로 디노이즈됩니다.

• DiT 참조는 타일 창으로 크롭되어 해당 창의 잠재 그리드에 매핑되므로, 비디오 참조와 선택적 이미지 참조는 전체 샷이 아니라 프레임에서 해당 타일이 차지하는 부분을 보여줍니다.
• 텍스트는 clip 입력이 연결된 경우 타일 자체의 크롭에서 다시 인코딩됩니다. 연결하지 않으면 기본 참조 노드가 Qwen에 전체 프레임을 넘기고 모든 타일에 해당 타일에 포함되지 않을 수도 있는 피사체에 대한 정보가 전달되는데, 노트에서는 이를 유령 피사체 실패라고 부릅니다.
• 가이드는 플레이트의 정확한 그리드에 유지되며, 일치하지 않으면 노드는 즉시 실패합니다.

또한 타일은 타일별 노이즈를 뽑는 대신 하나의 전역 노이즈 필드를 공유하며, 이음새를 따라 있는 스트립은 32 px seam_regen 밴드로 양쪽 이웃이 모두 생성한 뒤 가중치 정규화 누적으로 블렌딩됩니다. 스트립을 모두 본 두 타일은 고스팅된 블렌드 대신 정확한 렌더 간 크로스페이드를 만들어냅니다.

스케줄은 헤드 단계 하나와 테일 단계 두 개입니다

기본 시그마는 1.0, 0.7, 0.4, 0.0입니다. 증류된 터보 헤드로 한 단계를 수행한 다음, 세밀한 테일에서 euler 단계를 두 번 수행합니다. 인밴드 가이드는 스펙트럼 클램프로 처리되므로 전체 실행 동안이 아니라 테일에서만 노이즈가 적용됩니다(guide_release 0.8). 헤드는 완전한 증거 아래에서 구조를 결정하고, 테일은 자유도 아래에서 질감을 추가하며, 핸드오프 시점에는 콘텐츠가 움직일 수 없을 만큼 충분한 신호가 확정됩니다.

작성자의 참조 클립에서 측정했을 때, 이 조합은 거의 기준선 수준의 시머에서 고정 경계 기준선 대비 **타일 국소 디테일 +67%**를 제공했으며, 동일한 스케줄을 LMS에서 euler로 전환하면 **디테일 +56%**를 얻으면서 시머를 약 3분의 1 줄였습니다. 헤드 단계를 두 번 수행하는 것은 더 나아지는 것이 아니라 더 나쁩니다. 상태를 소프트 가이드로 수렴시켜 디테일 21%를 손실하며, 증류된 터보 모델을 중간 시그마 구간에서 두 번 스텝핑한 한 측정 실행에서는 잠재 데이터에 NaN이 발생했습니다.

특징이 없는 타일은 샘플링되지 않고 건너뜁니다. 평평한 플레이트 크롭은 모델에 증거를 전혀 주지 않고 완전한 자유를 주며, 작성자는 모델이 참조 얼굴을 빈 하늘과 연기에 그려 넣는 것을 목격했습니다. 타일별 텍스트 재인코딩이 켜져 있을 때는 더 심했습니다. flat_skip(기본값 4.0)은 해당 윈도우에서 플레이트를 그대로 유지하고 샘플링 시간을 돌려줍니다. 결정은 소스 픽셀 에너지를 기준으로 타일별 및 청크별로 내려집니다. 잠재 공간 지표 두 개가 연속으로 반증되었기 때문입니다.

맞지 않는 부분을 스트리밍하기

4배 기준에서 15초 클립은 float32의 ComfyUI IMAGE로 복사본당 약 36 GB이며, 일반 그래프는 복사본 세 개와 전체 클립 인코딩 두 개를 함께 보유합니다. 이 정도면 어떤 GPU에서도 OOM이 발생하기 때문에 Tessera는 작업을 분할합니다:

• Streamed Encode는 H3의 17-px 블록 그리드에서 소스를 시간 창 단위로 업스케일하고 VAE 인코딩하며, 창마다 22-px 워밍업 재인코딩을 수행한 뒤 그 결과를 버립니다. 검증된 544p에서 4K로의 실행에서 인코딩 측 픽셀 버퍼 최대치는 약 5.2 GB였으며, 일반 그래프에서 OOM을 일으킨 전체 클립 복사본은 57.6 GB였습니다.
• Streamed Decode는 하나의 스트리밍 디코드를 통해 출력을 조립하며, 4 GB를 넘으면 디스크 기반 버퍼를 사용합니다. 이전에 124프레임 8K 캔버스는 단일 디코드에서 49.7 GB를 할당하다가 실패한 적이 있습니다.
• 디스크 사전 점검은 첫 타일 샘플링 이전에 실행되는데, 디코드에 필요한 임시 공간은 계획 단계에서 파악할 수 있기 때문입니다. 한 8K 샘플링 실행은 67.6 GB 버퍼 할당에 실패하기까지 이미 8시간 49분을 소비한 적이 있습니다.
• 크래시 대비책: 그래도 출력 단계가 실패하면 정제된 잠재 데이터가 tessera_rescue_<timestamp>.latent로 저장되고 그래프는 여전히 잠재 데이터를 반환하므로, LoadLatent와 스트리밍 디코더로 다시 샘플링하지 않고 렌더를 복구할 수 있습니다.

빠른 움직임이 있는 긴 클립은 Temporal Dilate / Decimate를 거치며, 이는 구간당 프레임 속도를 높이고 되돌아오는 과정에서 출력의 시간을 다시 맞춥니다. 청크 창은 실제 콘텐츠 초 단위로 예산이 책정됩니다. dilation은 모든 창에서 콘텐츠를 나누므로, 창당 동일한 양의 모션 구조를 유지하기 위해 시간 창이 dilation 계수에 비례해 조정됩니다. 또한 플래너는 모든 중간 구간 창의 시작을 잠재 데이터 5의 배수로 맞추는데, 이는 H3 자체의 토큰 타이밍(헤드 토큰 하나에 이어 토큰당 4프레임)과 일치합니다. 15초 테스트에서 정렬되지 않은 모든 청크에서 17-px 프레임 깜박임 메트로놈 현상이 나타난 이후 반영된 것입니다.

측정된 실행

작성자가 544p에서 4K 경로에 대해 수행한 참조 실행은 15초 클립, 617개의 dilated 프레임, 18개 윈도, 3개의 스냅된 청크에 걸친 24개 타일로, 단일 GPU에서 총 3시간이 걸렸습니다. 프레임 간 진동은 **평균 2.44%, 피크 16.1%**를 기록했으며, 이는 동일 클립의 2x 참조인 2.32%, 12.3%와 비교되는 수치입니다. 자기상관에서는 17프레임 시그니처가 남지 않았습니다.

출시 다음 날 Banodoco Discord에 게시된, 작성자가 아닌 사용자들의 실행 결과:

• LDWorks David, BF16 가중치를 사용한 RTX 6000 Pro: 121프레임, 2K에서 4K, 84회 리파인 스텝을 약 32초/스텝으로 수행, 93% 도달까지 44분.
• seitanism: 1344x768, 362프레임을 시간적으로 dilated 처리해 583프레임으로 만들고 2688x1536에서 46:58에 렌더링했습니다. 두 번째 클립은 1920x1088에서 3840x2176으로 53:08, 세 번째는 Qwen-Image 2.1 스틸을 프레임 앵커로 사용해 27:48이었습니다. 그의 평가: 모든 모션 아티팩트를 해결하지는 못하지만, 충분히 제 역할을 합니다.
• mdkb는 12GB RTX 3060에서 자신이 정한 20분 예산을 기준으로 테스트하고 저VRAM 레시피를 요청했습니다. 작성자는 아직 준비 중이라고 답했습니다. 배포된 기본값은 고VRAM 카드를 대상으로 하기 때문입니다.

ComfyUI 사용법

저장소를 ComfyUI/custom_nodes/에 클론하여 설치하세요. 모든 항목이 등록되면 시작 콘솔에 [Tessera] loaded 9 node(s)가 출력됩니다.

함께 제공되는 워크플로는 소스 클립을 H3 참조로, 선택한 크기 조절 배율의 Lanczos 플레이트를, 선택 사항인 Qwen-Image 2.1 첫 프레임 앵커를, 그리고 작성자가 하우스 레시피로 사용하는 LoRA 조합(Alissonerdx의 H3 팩의 LMS 디테일 LoRA와 3스텝 터보 LoRA)을 연결합니다. 544p 소스에서 4배를 목표로 하며, 최종 출력은 3840x2176입니다.

홍보 영상에 등장하는 Tile Plan 노드: 실행 전에 확인하는 그리드, 청크, 예상 비용.

예제에서 사용하는 모델: MiniMax H3 ref2va(작성자 환경에서는 pruned int8 빌드), H3 비디오 및 오디오 VAE, Qwen3-VL 텍스트 인코더, 그리고 앵커 스틸을 위한 선택 사항인 Qwen-Image 2.1 checkpoint와 그에 맞는 터보 LoRA 및 texture-fix VAE입니다. 이 워크플로는 선택 사항인 히어로 마스크와 미리보기 노드를 위해 SAM3 및 KJ 노드 팩도 필요로 합니다.

알아 두면 좋은 한계

• 예제는 하나의 대상에 맞춰 배선되어 있습니다. 예상 출력 크기와 배율은 별개의 위젯이며, 둘 다 로드한 클립과 일치해야 합니다. 한 Discord 테스터는 제공된 워크플로를 다른 클립에 2배를 기대하고 실행했다가, 자신의 소스보다 못하다고 판단한 4K 캔버스를 얻었습니다.
• 스틸 앵커는 2배 도구입니다. 4배 이상에서는 이음매가 동일한 텍스처의 서로 다른 두 렌더링 사이를 크로스페이드하기 때문에, 노트에서는 플러그를 빼고 모델이 헤드를 렌더링하도록 두라고 권장합니다.
• 소스의 흔들림은 그대로 이어집니다. 자체적인 미세 대역이 요동치는 저해상도 소스는 확대 시 증폭된 물결로 나타납니다. 정제는 일관성을 대략 0.75까지 끌어올리지만 그 이상은 넘어설 수 없습니다.
• 장면 컷은 권고 사항입니다. 컷 오라클은 발견한 프레임을 출력하고 해당 지점에서 클립을 분할하라고 권장합니다. 하나의 창 안에 있는 짧은 샷은 헤드 타이밍 규칙과 콘텐츠 시간 예산을 동시에 만족할 수 없습니다.
• 두 번째 홉은 감소된 시그마로 입력됩니다. 예를 들어 1.0, 0.923, 0.55, 0.0이며, 두 번째 홉의 플레이트는 다시 부드럽게 만든 중간 결과가 아니라 첫 번째 홉의 출력이어야 합니다.

사용 가능 여부

• GitHub의 hashu786/ComfyUI-Tessera에서 확인할 수 있으며, example_workflows/tessera_upscaler.json과 전체 엔지니어링 노트는 docs/LAWS.md에 있습니다.
• pyproject.toml에는 Comfy Registry용 [tool.comfy] 블록(DisplayName = "Tessera")이 포함되어 있습니다. 검사 시점에는 해당 패키지가 아직 레지스트리에 등록되지 않았으므로 저장소에서 설치하세요.
• 이 글의 참조 프레임은 프로젝트 홍보 비디오의 프레임이며, 544p 소스와 4x 렌더 결과를 비교합니다.