작은 인코더와 양자화·가중치 스트리밍으로 소비자 GPU에서 대화형 확산 생성 구현하기

무엇인가

이 논문은 소비자용 GPU에서 확산(diffusion) 이미지 생성을 실제 제품 수준으로 배포하는 문제를 다룬다. 언어 모델 추론은 루프가 표준화되어 온디바이스 배포가 빠르게 늘었지만, 확산 파이프라인은 텍스트 인코더(임베더), 디노이징 트랜스포머, 디코더(VAE), 그리고 표준화되지 않은 추가 후처리 모델을 함께 조율해야 한다. 게다가 메모리를 많이 먹고 지연에 민감해서 제한된 비디오 메모리 안에 모든 모델을 넣고 대화형 지연 예산 안에서 돌려야 한다. 저자들은 이를 속도·품질·메모리 삼각형(speed/quality/memory triangle)으로 규정하고, 가장 큰 GPU 한 대가 아니라 최대한 많은 클라이언트 기기에서 동작시키는 것을 목표로 세 가지 기여를 제시한다. 임베딩 번역기, 속도/품질/메모리 삼각형을 탐색하는 재현 가능한 스윕 레시피, 그리고 최신 GPU에서 1초 미만의 TTFI(첫 이미지 반복까지의 시간)를 내는 온디바이스 대화형 이미지 생성 편집기다.

어떻게 동작하나

첫 번째 기여인 임베딩 번역기는 확산 모델의 조건화(conditioning) 공간을 그대로 두고 그 앞단의 텍스트 인코더만 작은 것으로 바꾸는 장치다. 확산 모델은 보통 Qwen 같은 대형 언어 모델에서 가져온 큰 텍스트 임베더로 학습되는데, 저자들은 단순한 프롬프트라면 훨씬 작은 임베딩으로 충분하다고 주장한다. 번역기는 작은 임베더의 특징을 원래 큰 임베더가 만들던 조건화로 매핑하도록 메인 파이프라인이 완성된 뒤에 사후 학습된다. 확산 트랜스포머와 VAE는 동결(frozen)해 두고 특징 회귀 손실로 0.6B 인코더의 토큰별 특징을 4B 조건화에 회귀시키는 방식이라, 재학습이 아니라 작은 애드온이다. Qwen3 모델들이 토크나이저를 공유하기 때문에 토큰이 정렬되어 토큰 단위 매핑이 가능하다. 번역기 크기는 은닉 폭과 깊이로 이름 붙여지며(예: d3072는 단일 3072 폭 MLP, d2048×8은 2048 폭 블록 8개), 어텐션 블록 변형도 실험했다. 부수 효과로 기기에 이미 있는 임베더를 재사용할 수 있다는 점도 강조한다. 예컨대 애플 온디바이스 LLM 같은 OS 탑재 파운데이션 모델의 텍스트 특징을 쓰면 이미지 모델이 자체 텍스트 인코더를 배포할 필요가 없다.

무엇과 다른가

실험은 FLUX.2-klein에서 4B Qwen3 인코더를 Qwen3-0.6B와 번역기로 교체하는 방식으로 진행됐다. 번역기 크기를 3.5M에서 187M 파라미터까지 스윕하고, PartiPrompts에서 1024×1024 해상도, 동일 시드의 4B 결과를 기준으로 LPIPS와 CLIPScore를 측정했다. 흥미로운 결과는 번역기가 4B 특징을 얼마나 잘 맞추는지가 이미지 품질을 예측하지 못한다는 점이다. 특징 유사도는 모든 크기에서 0.73~0.77로 평평했지만 LPIPS는 0.514~0.717로 벌어졌다. 중요한 것은 용량(capacity)으로, 번역기가 클수록 이미지가 꾸준히 좋아졌다. 가장 큰 187M은 LPIPS 0.514로 4B를 다른 시드로 다시 돌렸을 때의 0.553보다 낮았고, CLIPScore 0.306으로 4B의 0.328에 근접했다. 가장 작은 3.5M은 명확히 더 나빴다. 비용은 크기와 무관하게 낮게 유지된다. Mac M3 Max 48GB의 PyTorch/MPS에서 0.6B 패스가 88ms, 번역기가 최대 19ms를 더해 인코딩이 약 90~107ms였고 4B는 435ms였다. 다만 실제 배포된 TensorRT-RTX 파이프라인에서는 인코더가 4~12ms로 임계 경로 밖에 있어, GPU 위에서 번역기의 이득은 주로 메모리다. 인코더 경로 가중치 메모리는 8GB에서 1.4~1.8GB로 줄고, 이는 번역기가 아니라 공유되는 0.6B 베이스가 지배한다. 같은 크기의 MLP와 비교해 어텐션 번역기가 더 낫지는 않았다.

어떻게 쓰나

두 번째 축은 디노이징 트랜스포머에 적용하는 양자화다. 세 축(속도·품질·메모리) 모두를 지배하는 컴포넌트가 트랜스포머라 여기에 집중한다. 양자화는 학습이 필요 없는 PTQ(학습 후 양자화)만 사용해 어떤 사전학습 체크포인트에도 바로 적용한다. 가중치 정밀도를 낮추면 VRAM이 줄고, FP8/NVFP4 텐서 코어에서 활성값을 양자화하면 계산 시간이 줄며, 품질은 BF16 대비 약간 영향을 받는다. FP16과 FP8은 BF16에 가깝게 유지됐고, NVFP4는 시각적 거리가 가장 컸으며(LPIPS 0.23, CLIP 유사도 0.92) 프롬프트별 분산도 가장 커서 그 정밀도의 품질 저하가 콘텐츠 의존적임을 보였다. SVDQuant 같은 4비트 가중치 양자화 기법은 이 파이프라인과 조합 가능하다고 언급한다. RTX PRO 6000 Blackwell에서 저비트 양자화는 스텝당 지연을 105ms에서 57ms로 줄여(1.84배) TTFI를 150ms 아래로 끌어내렸다. 트랜스포머 엔진의 VRAM 요구량은 BF16 8.4GiB에서 Blackwell의 NVFP4 3.3GiB로, Ada 세대는 FP8로 4.8GiB까지 내려간다. 또한 GeForce 하드웨어에서는 FP32 누적을 쓰는 BF16/FP16 텐서 코어 처리량이 최대 FP16 처리량의 절반에 불과하므로 FP16을 BF16과 함께 평가할 가치가 있다고 지적한다.

전제와 한계

세 번째 축은 가중치 스트리밍이다. 디노이저 가중치의 일부만 VRAM에 상주시키고 나머지는 필요할 때 고정된(pinned) RAM에서 전송하며, PCIe 전송을 계산과 겹친다. 상주 여부만 바뀌므로 출력은 완전 상주 실행과 비트 단위로 동일하고 품질은 손상되지 않는다. 대신 호스트가 전체 모델을 RAM에 들고 있어야 하므로 전체 메모리 압박은 줄지 않고, VRAM과 RAM이 하나의 풀을 공유하는 통합 메모리(UMA) 시스템에는 맞지 않는다. 이산 GPU에서는 VRAM 부족을 지연 비용으로 바꾸는데, 그 비용은 λ = L·M/W로 결정된다. L은 연속된 행렬 곱 사이의 실행 지연, M은 호스트-디바이스 PCIe 속도, W는 레이어 가중치 크기다. λ가 1 이상이면 모든 전송이 계산 뒤에 숨겨져 추가 지연이 0이고, λ가 1보다 작으면 저수지가 채워지는 것보다 빨리 소진되어 대기 가중치가 Δ = (N−K)·W/M 만큼 오버헤드를 더한다(N개 레이어 중 K개가 완전히 겹쳐진 경우). 중요한 점은 M이 호스트 플랫폼에 고정된다는 것이다. 고급 RTX 5090과 모바일 RTX 5070이 같은 PCIe Gen5 슬롯을 공유하는 반면 계산 처리량은 한 자릿수 이상 차이 나므로, 느리고 VRAM이 적은 GPU에서 λ가 1에 훨씬 가깝다. 즉 스트리밍이 가장 필요한 기기에서 스트리밍이 가장 싸다. 스트리밍은 최소 가용 디바이스 메모리 T_min = 2·W_max + A_max 아래로는 내려갈 수 없다. W_max는 네트워크에서 가장 큰 단일 레이어 가중치 텐서, A_max는 순전파 중 가중치와 공존해야 하는 최대 활성화 텐서다. 12GB RTX 4070 Ti 실험에서 4B 인코더를 쓰면 75% 상주와 완전 상주 모두 페이징이 발생해(λ≪1, 약 40배 느려짐) 인코더만 약 8GB를 차지해 여유가 없었다. 0.6B와 번역기로 바꾸면 25%에서 75% 상주까지 모두 λ≈1 구간에 들어 서로 3% 이내 지연을 보였고, 스트리밍을 완전히 끌 때만 페이징 절벽을 넘었다. 25% 상주에서 피크 VRAM은 6.7GB로 8GB 등급 아래로 내려가면서 스텝 시간 비용은 3%뿐이었다. FP16은 모든 스트리밍 수준에서 BF16보다 23~25% 빨랐다. 반대로 모델 전체가 VRAM에 들어가는 RTX PRO 6000 Blackwell에서는 낮은 예산의 스트리밍이 완전 상주보다 느렸는데, 빠른 Ada 연산이 PCIe가 채우는 속도보다 저수지를 빨리 소진하기 때문이다. 스트리밍은 모델이 애초에 들어가지 않을 때만 이득이라는 뜻이다. 두 기법은 자유롭게 조합되며, 양자화는 스트리밍이 옮기는 가중치를 압축하고 PTQ 엔진은 단일 가중치 세트로 배포되어 정밀도 형식이 달라도 추가 저장 공간이 필요 없다.

이 세 요소를 합친 것이 온디바이스 대화형 이미지 생성 편집기다. ONNX Runtime의 TensorRT-RTX 프로바이더 위에 올린 네이티브 C++ 애플리케이션으로, 각 컴포넌트 엔진을 한 번 컴파일해 캐시하므로 런타임에 인코더, 정밀도, 스트리밍 예산을 바꿔도 재빌드가 필요 없다. 편집기에서 이 세 가지는 단계별 타이밍과 GPU 메모리와 함께 실시간 컨트롤로 노출된다. 12GB RTX 4070 Ti에서도 0.6B와 번역기 경로로 가중치 절반 상주 상태에서 1024×1024를 약 3초에 렌더링하고 여유가 남는다. RTX PRO 6000 Blackwell Workstation Edition에서 TensorRT-RTX로 4단계 증류 샘플링을 돌린 측정에서는, 4B 인코더를 0.6B와 번역기로 바꾸면 VRAM이 15.1GB에서 10.6GB로 줄고 스텝당 지연은 변하지 않았다(인코더가 12ms에서 4ms로 줄었지만 임계 경로가 아니기 때문). 여기에 양자화를 더하면 FP8이 VRAM을 7.2GB로 절반으로 줄이고 스텝 시간을 74ms로 낮추며, NVFP4는 5.7GB와 스텝당 57ms에 도달해 4스텝 전체가 0.27초, TTFI 약 100ms가 된다.

개발자 관점에서 이 논문의 실용적 메시지는 온디바이스 확산 배포를 세 개의 독립적인 손잡이로 다룰 수 있다는 것이다. 텍스트 인코더는 품질을 조금 내주고 메모리와 지연을 크게 줄이는 교체 대상이고, 양자화는 속도와 메모리를 동시에 건드리지만 NVFP4에서는 콘텐츠 의존적 품질 저하가 나타나므로 프롬프트 다양성이 큰 제품에서는 검증이 필요하다. 스트리밍은 품질을 전혀 건드리지 않지만 UMA 기기에서는 이득이 없고, 모델이 VRAM에 들어가는 고급 GPU에서는 오히려 손해다. 따라서 대상 기기 목록을 먼저 정하고, VRAM 등급별로 어떤 조합이 λ≈1 구간에 들어오는지 확인하는 것이 핵심이다. 코드는 github.com/NVIDIA/din-deploy에 공개되어 있고 FLUX.2-klein, 두 Qwen3 인코더, PartiPrompts가 모두 Apache-2.0이며 추론은 전부 온디바이스에서 실행된다.

저자들이 밝힌 한계와 전제는 다음과 같다. 가장 좋은 번역기조차 프롬프트 추종은 4B보다 약간 나쁘다(CLIPScore 0.306 대 0.328). 어떤 구성도, 4B를 포함해서도 읽을 수 있는 텍스트를 렌더링하지 못했는데, 저자들은 이를 인코더가 아니라 4단계 샘플러 탓으로 돌린다. 번역기 주장은 단순한 프롬프트라는 전제에 기대고 있다. 양자화는 PTQ만 사용하므로 QAT처럼 매우 낮은 비트폭에서 정확도를 회복하지는 못하며, NVFP4의 품질 저하는 콘텐츠에 따라 달라진다. 스트리밍은 전체 메모리 압박을 줄이지 못하고 호스트 RAM에 전체 모델이 있어야 하며, T_min = 2·W_max + A_max 아래로는 어떤 축출 정책으로도 내려갈 수 없다. 또한 인코더 경로 메모리 감소분은 번역기가 아니라 공유 0.6B 베이스가 지배하므로, 번역기 크기를 키우는 것은 품질과 메모리를 맞바꾸는 거의 무료에 가까운 선택이라는 점도 기억할 필요가 있다.