An endless AI TV channel on a single gaming GPU

3줄 요약

1. r/StableDiffusion에 2026년 9월 2일 올라온 글이다. 작성자는 RTX 5090 한 장으로 끊기지 않는 AI 영상 채널을 돌리고 있다고 밝혔다. 쓰는 모델은 오픈 웨이트 영상 모델 MiniMax H3이고, 그중에서도 4스텝으로 줄인 증류판 FastH3를 ComfyUI에 올려 로컬로 돌린다.
2. 이 일이 성립하려면 생성 속도가 재생 속도를 앞질러야 한다. 그는 19.2초의 GPU 시간으로 20.1초 분량의 영상을 만들어 냈다. 클립마다 남는 0.9초가 재생 버퍼를 계속 채워 준다.
3. 빨라진 과정은 모델과 무관하다. ComfyUI의 노드별 실행 시간을 직접 계측했더니 기본 저장 노드가 매 실행의 5분의 1을 먹고 있었고, VAE는 픽셀 수보다 타일 개수로 비용을 매기고 있었다. 그 두 가지를 고쳐서 26.5초를 19.2초로 줄였다.

무엇이 돌아가고 있나

작성자 spartong945은 자기 데스크톱에서 영상 스트림 하나가 지금도 돌아가고 있다고 적었다. 소리가 함께 나오고, 지금까지 같은 장면을 되풀이한 적이 없으며, 멈추지 않는다. VLC로 로컬 URL 하나를 열면 재생된다. RTX 5090 한 장이 이 모든 것을 처리하고, 클라우드도 대기열도 없다.

모델 쪽을 보면 MiniMax H3인데, 텍스트 프롬프트 하나에서 그림과 동기화된 소리를 함께 만들어 낸다. 덕분에 대사와 실내 공기음과 발소리가 같이 나온다. 그가 이 점을 강조한 이유는 분명하다. 음악을 깔아 놓은 몽타주를 넘어 채널이라 부를 수 있게 하는 것이 그 소리다. 그는 기본 모델 대신 4스텝 증류판인 FastH3를 쓴다. 기본 모델은 아래에 나올 계산이 감당할 수 있는 것보다 훨씬 많은 샘플링 스텝을 요구한다.

어려운 지점은 따로 있다. 끊김 없이 흘려보내려면 생성이 재생을 앞질러야 한다. 눈에 띄게 빠르기만 해서는 부족하다. 사람이 보는 속도보다 빨라야 하고, 그 상태가 끝없이 이어져야 한다. 그렇지 않으면 버퍼가 비어서 화면이 멈춘다. 클립 하나는 362프레임이다. 그는 지금 재생 중인 클립을 시청자가 다 보기 전에 다음 클립을 매번 끝내야 한다.

내용물 쪽도 손으로 만들었다. 손으로 쓴 장면이 321개, 등장인물이 503명이고, 여러 명이 나오는 장면은 그중 3명에서 5명을 뽑아 배역을 채운다. 조합의 가짓수는 조 단위로 올라간다. 그래서 켜 두고 있어도 내가 통제하지 못하는 채널을 볼 때처럼 계속 흥미롭다고 그는 적었다.

장면 예시로 그가 든 것은 이렇다. 장 뤽 피카드가 야시장에서 꼬치를 굽는다. 클링온과 로보캅과 잭 스패로우가 같은 작업대 앞에 모여 있다. 네 사람이 식탁을 사이에 두고 누가 서명했는지를 두고 다투다가, 프롬프트가 그렇게 시키는 대로 7초 지점에서 카메라가 클로즈업으로 전환한다.

먼저 밝혀 둔 조건

그는 자랑에 앞서 제약부터 적어 두었다.

H3는 초당 24프레임을 기준으로 움직임을 만든다. 362프레임 클립은 재생 시간으로 15.08초 분량이다. 그는 이것을 초당 18프레임으로 재생한다. 그러니 화면 속 움직임은 원래 속도의 75%로 흐른다. 그는 이것이 실시간 24fps 생성이 아니며 그렇게 주장할 생각도 없다고 밝혔다.

그가 주장하는 것은 다른 숫자다. GPU가 19.2초 동안 일해서 영상 20.1초를 만든다는 것이고, 그 여유분이 스트림을 끊기지 않게 한다. 75%가 슬로모션처럼 보이는지는 대상에 따라 다르다고 한다. 비나 불꽃이나 기차처럼 빠른 피사체는 오히려 의도한 연출처럼 보이고, 거의 정지한 장면은 정상으로 보인다. 걷는 사람이나 손을 쓰는 동작처럼 중간 속도의 인체 움직임이 최악이고, 그건 보면 알아차릴 수 있다고 한다.

시간이 어디로 갔는가

배포되는 FastH3 학생 모델의 diffusers 가중치는 66GB다. 그 크기로는 카드 한 장에 올릴 수 없다. 변환하고 INT8로 양자화하면 21GB가 되고 그건 올라간다. 여기에 sage attention과 INT8 VAE까지 붙였을 때 15초짜리 클립 하나를 만드는 데 26.5초가 걸렸다. 재생에는 15초가 필요하다. 이 간극이 문제의 전부였고, 그는 시간이 어디로 새는지 몰라서 한동안 엉뚱한 곳을 최적화했다고 적었다.

ComfyUI의 /history는 프롬프트 전체의 실행 시간 하나만 보여 준다. 그 숫자로는 비용이 텍스트 인코더에 있는지 샘플러에 있는지 VAE에 있는지 알 수 없다. 그런데 ComfyUI는 웹소켓으로 노드가 시작될 때마다 executing 이벤트를 내보낸다. 따라서 연속한 두 이벤트 사이의 간격이 그 노드의 실행 시간이 된다. 그는 이것을 40줄쯤 되는 스크립트(profile_h3_nodes.py)로 만들었고, 그 결과가 그가 손대야 할 곳을 완전히 바꿔 놓았다.

네 가지 발견 중 둘은 그도 예상하지 못했다고 한다.

저장 노드가 매 실행의 5분의 1을 차지하고 있었다

ComfyUI의 기본 SaveVideo 노드는 PyAV를 통해 인코딩하는데, 그 파이썬 루프는 프레임마다 실수 배열을 만든다. 이어 두 번째 배열에서 값을 자르고, 세 번째에서 자료형을 바꾼 뒤, 네 번째 배열에 복사한다. 362프레임을 그렇게 처리하면 3.78초가 걸린다. 같은 작업을 ffmpeg에 그대로 맡기면 0.21초다. 게다가 그렇게 만든 파일은 1초 뒤 그의 스트리머가 다시 인코딩하고 있었다.

VHS_VideoCombine은 그보다 낫다. 1.31초가 걸리고, 원시 프레임을 ffmpeg으로 파이프해 넘긴다. 그래도 파이썬에서 프레임을 순회하는 일은 남는다. 오디오를 합치려고 완성한 파일도 다시 연다. 그는 청크 단위로 변환하고 한 번에 먹싱하는 노드를 직접 작성했다. 그렇게 바꾸니 0.73초로 떨어졌다. 인코딩 작업은 백그라운드 스레드로 넘겼고 노드는 바로 반환하게 했다. 그러자 ComfyUI가 GPU를 놀리지 않고 다음 프롬프트를 시작한다. 그래프에 찍히는 시간은 이제 0.26초다.

하드웨어 인코더는 쓰지 않았다. h264_nvenc를 끝에서 끝까지 재어 보니 libx264보다 오히려 느렸다고 한다. 인코더는 애초에 병목이 아니었고, 이미 꽉 찬 카드 위에 CUDA 컨텍스트를 하나 더 세워야 한다는 부담까지 있었다.

VAE 비용을 가르는 기준

MiniMaxH3VideoVAE는 tiling=True와 tile_size=256을 코드에 고정해 두었고, split_tiles는 타일 안에 그림이 얼마나 들어 있든 매 패스에 온전한 타일 하나를 넘긴다. 이 때문에 디코드 시간은 타일 개수를 따라가고 해상도에는 거의 반응하지 않는다.

512×288과 576×320은 픽셀 수가 25% 차이 나는데 디코드 비용은 전혀 차이 나지 않는다.

한 변의 길이가 L일 때 비용은 이렇게 끊긴다. 256 이하면 타일 1개, 257부터 448까지는 2개, 449부터 640까지는 3개, 641부터 832까지는 4개다. 값이 싼 모양은 경계선 바로 아래에 앉아 있다. 448×448은 타일 4개면 되는데 576×320은 6개가 필요하고, 그러면서 448×448이 픽셀은 9% 더 많다. 스트림이 정사각형으로 돌아가는 이유가 여기 있다. 타일 4개짜리 16:9 모양 중에 해상도 하한선을 넘기는 것은 없다.

tile_size를 키워서 타일 하나로 끝내 보려는 시도도 했는데, 그는 하지 말라고 한다. 이 디코더는 ViT라서 어텐션이 정확히 타일 하나만큼을 덮는다. 타일을 키우면 결과가 조금 부정확해지는 정도로 끝나지 않고 학습 분포 바깥으로 나가 버린다. 384로 키우면 손과 얼굴이 눈에 띄게 뭉개지고(원래 디코드 대비 PSNR 27.2dB), 640으로 키우면 이미지가 붓자국처럼 번진다(22.1dB).

나머지 두 가지

영상 VAE를 INT8보다 더 낮게 양자화해도 속도는 얻지 못한다. INT8은 이미 INT8 행렬곱을 돌리고 있고, W4A8로 빌드해도 결국 같은 INT8 연산으로 되돌려 확장하기 때문이다. 그래도 그는 이 변경을 넣었다. 호스트 RAM에 올려 두는 양이 2,677MB에서 1,657MB로 줄기 때문이다. 64GB 시스템 RAM에 약 41GB의 가중치를 상주시킨 상태라, 그 1기가바이트를 비우면 속도도 빨라지고 클립 시간도 덜 흔들린다.

마지막은 대기열이다. 프롬프트를 하나 제출하고 기다리는 대신 ComfyUI 대기열에 항상 두 개를 걸어 두면, 작업 사이에 GPU가 노는 구간이 사라진다.

결과

모델은 바뀌지 않았다. 바뀐 것은 모델을 구동하는 방식뿐이다.

컨슈머 카드에서 겪은 것들

FastH3 공지 스레드에는 ComfyUI와 컨슈머 카드에 관한 질문이 계속 올라왔다. 그가 직접 답해야 했던 문제이기도 해서 두 가지를 따로 정리했다. 그가 만든 것은 Dense-DataFree 학생 모델을 ComfyUI에 맞게 변환하고 가지치기와 INT8 양자화를 거친 21GB짜리이며, 특별할 것 없는 일반 그래프로 구동한다.

첫째, VSA 가중치는 기본 ComfyUI를 통과하지 못한다. 이 가중치에는 기본 ComfyUI가 처리할 코드를 갖추지 않은 to_gate_compress 텐서가 50개 있다. ComfyUI는 이것을 아무 경고 없이 버린다. 그러면 출력은 노이즈가 된다. Dense 쪽은 깨끗하게 변환된다. 그가 더 느린 학생 모델을 쓰고 있는 이유가 그것이고, ComfyUI가 VSA를 지원하게 되면 그가 아직 쓰지 못하는 여유가 남아 있는 셈이다.

둘째, NVFP4와 INT8 ConvRot의 성능은 같았다. FP4 고속 경로가 켜지려면 두 피연산자가 모두 FP4여야 한다. 활성값이 BF16이니 조건이 어긋나고, 역양자화를 거쳐 결국 BF16 속도로 돌아간다. 블록당 67.88ms로, BF16의 67.85ms와 거의 같은 값이다. RTX 6000 Pro에서도 같은 결과를 봤다는 보고가 있었다고 한다. 이것 때문에 파이프라인을 다시 짜려는 사람이 있다면 알아 둘 만하다.

공을 어디에 돌리는가

그는 여기 나온 속도 중에 자기 것은 없다고 밝혔다. FastH3는 Hao AI Lab과 Nuva Lab, 그리고 NVIDIA의 FastGen 팀이 MiniMax의 기본 가중치 위에 만든 4스텝 증류판이고, 그 학생 모델이 없었다면 이 작업은 근처에도 가지 못했다는 것이다. 그쪽이 공개한 벤치마크는 B200 한 장에서 15초짜리 768p 클립에 47.2초, B200 8장에서 12.88초다. 컨슈머 하드웨어를 다룬 그들의 글은 애플 실리콘과 DGX Spark를 다루고 RTX 계열은 향후 과제로 적어 두었다.

그가 한 일은 그 점수를 갱신하는 종류의 작업과 성격이 다르다. 픽셀은 5분의 1이고 재생은 24fps 대신 18fps다. 그 두 가지를 양보한 대가로 계산이 맞아떨어졌고, 19.2초의 GPU 시간으로 20.1초의 영상이 나온다. 빠른 생성기와 켜 두고 지낼 수 있는 물건을 가르는 것이 그 차이라고 그는 적었다. 768p가 필요한 사람에게는 저쪽 숫자가 유효하고 자기 숫자는 의미가 없다는 말도 덧붙였다.

받아 갈 것은 허깅페이스 데이터셋 한 곳에 모여 있다. 변환된 21GB 가중치, 양자화한 VAE, 321개 장면 라이브러리, 직접 만든 저장 노드, 프로파일러가 전부 들어 있다.

내려받기 전에 알아 둘 조건도 적어 두었다. 상주시키는 가중치는 모두 합쳐 약 48GB다. 텍스트 인코더가 25.9GB, DiT가 20GB, 그리고 VAE 두 개다. 이 정도면 32GB VRAM에도 들어가지 않으니 ComfyUI가 호스트 RAM에서 레이어 단위로 흘려 넣는다. 그의 컴퓨터에서 손봐야 했던 대상은 연산 속도보다 이 스트리밍이었다. 64GB 시스템 RAM에 48GB를 올려 두는 것은 빠듯해서, 페이지 파일 압박이 클립 시간에 그대로 나타났고 1기가바이트를 비웠더니 시간이 눈에 띄게 안정됐다.

코드는 Apache-2.0이다. 가중치는 MiniMax H3 파생물이라 H3 Community License를 따르고, 여기에는 지역 제한이 걸려 있으니 내려받기 전에 NOTICE를 읽으라고 그는 당부했다.

댓글에서 나온 숫자들

글이 올라간 뒤 사흘 동안 댓글이 70개 붙었고, 본문에 없던 숫자가 여럿 나왔다.

전기 요금. 하루 24시간이면 얼마나 드느냐는 질문에 그는 그 자리에서 측정했다. 스트리밍 3분 동안 카드 평균 439W, 최고 577W, 클립 사이 짧은 구간에는 120W까지 떨어진다. 하루로 환산하면 10.5kWh다. 카드만 잰 값이라 나머지 부품에 100W쯤 더하면 되고, 미국 전기 요금 기준으로 하루 2달러가 안 된다.

카드를 두 장 쓰면. 두 번째 카드가 클립 하나를 더 빨리 만들어 주지는 않고 다른 클립 하나를 병렬로 만든다. 스트림 입장에서는 같은 이야기다. 362프레임 클립을 초당 24프레임으로 재생하려면 15.1초 안에 만들어야 한다. 한 장으로는 19.2초가 걸려 약 4초 모자란다. 두 장이 번갈아 돌면 실효 9.6초가 되어 5초쯤 여유가 생기고, 그는 그 여유를 프레임률보다 해상도에 쓰겠다고 했다. 정작 지켜봐야 할 것은 VRAM보다 시스템 RAM이라고 덧붙였다. 가중치가 주 메모리를 거쳐 올라가는데 한 컴퓨터에 인스턴스를 둘 띄우면 그 양이 두 배가 되기 때문이다.

대본을 쓰는 LLM. 무인 무한 생성을 위해 LLM이 대본을 계속 만들어 주는 구성을 물은 댓글에는, 그럴 필요가 없다고 답했다. 프롬프트 하나가 수백 바이트이고 321개 장면 파일 전체가 212KB다. 하룻밤에 1년치 대본을 만들어 두면 방송 시간에는 LLM을 아예 올리지 않아도 된다.

3090에서는. 모델 자체는 돌아갈 것이라고 보면서도 두 가지를 지적했다. DiT 가중치가 21GB라 24GB VRAM에 올릴 수는 있지만 텍스트 인코더와 VAE가 각자 몫을 요구하기 시작하면 빠듯하고, Ampere에는 FP8 텐서 코어가 없어서 그를 도운 양자화 경로가 같은 방식으로 도움이 되지 않는다. 돌아가긴 하되 18fps는 안 나온다는 것이다. 실제로 3090에서 5초 클립을 66초에 만들고 있다는 댓글이 붙었는데, 그는 하드웨어 차이만으로 설명되는 간격보다 크다고 보고 저장소의 sage attention 노드가 제대로 연결되어 있는지 확인해 보라고 답했다.

RTX 6000 Pro라면. 96GB 카드를 가진 사람이 레이어 스트리밍의 정체를 묻자, 그것은 comfy-aimdo가 하는 동적 VRAM 로딩이며 자기가 만든 것이 아니라고 밝혔다. 작업마다 로그에 네 줄이 찍힌다. 모델 넷이 49GB를 상주시키는데 VRAM은 32GB이니 무언가는 밀려나야 한다. 그리고 이 교체는 샘플러 안에서 일어나지 않고 대체로 단계 사이에서 일어난다. INT8로 26GB인 텍스트 인코더가 실행되고 밀려나면, DiT가 네 스텝 동안 카드 전체를 차지한다. 실시간 프롬프트 입력은 없다. ComfyUI는 한 번에 프롬프트 하나만 돌리고 그는 두 개를 걸어 둘 뿐이다. 마르지 않는다고 말한 버퍼는 추론 대기열 이야기가 아니고, 재생 쪽 버퍼를 가리킨다. 96GB에서는 아무것도 스트리밍되지 않을 텐데, 그 상황을 흉내 내려고 텍스트 인코더를 캐시해 봤더니 클립 하나가 26.0초에서 21.5초로 줄었다고 한다. 단, 이 값은 지금과 다른 해상도에서 잰 것이라 곧이곧대로 받아들이지 말라는 단서를 달았다.

게임 화면을 다시 칠할 수 있나. 게임의 깊이 버퍼를 뽑아 ControlNet으로 넣고 실시간으로 화풍을 바꿀 수 있겠느냐는 질문에는 짧게 아니라고 답했다. 다른 프로젝트를 하다 확인한 것이라며 이유를 설명했는데, H3는 참조 조건을 걸 때 참조 영상과 출력 영상을 시간 위치 인코딩에 순서대로 이어 붙인다. 프레임 단위로 정렬하지 않는다는 뜻이다. 그래서 깊이 버퍼의 t번째 프레임과 출력의 t번째 프레임이 모델 내부에서 같은 위치에 놓이지 않는다. 제어 맵과 출력이 매 스텝 같은 공간 격자를 공유하는 이미지 확산의 ControlNet과는 구조가 다르다.

다른 사람이 이어받았다. 이틀 뒤 한 사용자가 이 작업을 참조 영상 기반 스트림으로 바꾸고 간단한 편집 UI를 붙여 별도 저장소로 공개했다. 각 클립이 직전 이미지를 참조하게 만들어 이야기가 이어지도록 했고, 5초 클립을 쓰면 생성이 더 빨라져 품질에 여유가 생긴다. 원작자는 그것을 자기 5090에서 25클립 연속으로 돌려 보고, 마지막 프레임 연속성이 유지되고 버퍼도 끝까지 살아 있었다고 확인해 주었다. 대신 아슬아슬하다는 지적을 붙였다. 적응형 품질 조정이 해상도를 800×800으로 올리는 순간, 비용이 버퍼 임계값을 계산할 때 가정한 수준보다 훨씬 커져서, 클립 하나가 8초에서 27초로 뛰었고 한동안 뒤처졌다가 스스로 회복했다는 것이다.

글이 길다는 지적도 있었다. 클로드 특유의 장황함이 읽기에 유쾌하지 않다는 댓글에 그는 이렇게 답했다. 영어가 모국어가 아니어서 글은 클로드에 기대는데 그러면 살이 붙는다고, 다음에는 짧게 쓰겠다고 했다. 그리고 한 줄을 덧붙였다.

숫자와 프로파일링은 제 것입니다.

가장 흥미로운 지점

내가 가장 오래 붙들고 있었던 것은 정사각형 화면이다.

정사각형 영상은 대개 만든 이의 선택으로 읽힌다. 인스타그램에 올리려 했거나 인물 구도가 그쪽이 낫다고 봤으리라 짐작하게 된다. 그런데 여기서는 그 화면비가 VAE 타일 경계에서 나왔다. 한 변이 448을 넘으면 타일이 하나 더 붙는다. 타일이 하나 늘어날 때마다 디코드가 길어지고, 길어진 만큼 재생을 앞지를 여유가 깎인다. 16:9로는 타일 4개 안에 들어가면서 쓸 만한 해상도를 유지하는 조합이 없다. 그러니 이 화면비를 결정한 것은 취향이 아니다. 산술이 결정했다.

두 번째로 눈길이 간 대목은 그가 시간을 찾아낸 방법이다. /history가 돌려주는 숫자 하나로는 아무것도 알 수 없었고, 그는 웹소켓 이벤트 사이의 간격을 재는 40줄짜리 스크립트를 직접 썼다. 그 40줄이 밝혀낸 것은 매 실행의 5분의 1이 모델과 무관한 저장 노드에서 새고 있었다는 점이다. 그런 태도는 글 마지막에 남긴 부탁에도 이어진다. 그는 기계 한 대만 재 봤다. 중요했던 발견 두 가지는 앉아서 따져 본 끝에 나오지 않았다. 재어 보고 나서야 손에 들어왔다. 그런 사람이라 남의 하드웨어를 두고 섣불리 추측하고 싶지 않다고 했다.

돌아가면 숫자를 올려 주십시오. 잘 되는 것만큼이나 어디서 무너지는지가 궁금합니다.

출처

spartong945, “An endless AI TV channel on a single gaming GPU”, r/StableDiffusion, 2026년 9월 2일. 원문: https://www.reddit.com/r/StableDiffusion/comments/1w5aor1/an_endless_ai_tv_channel_on_a_single_gaming_gpu/ 저장소: https://huggingface.co/datasets/jacokon/fasth3-live 시연 영상: https://x.com/Touma_945/status/2095141879453270385

본문 이미지 두 장은 원문 게시물에 포함된 것이다.