GGUF 양자화본을 받을 때 뭘 고를지가 늘 애매했습니다. 작으면 빠르고 화질이 떨어진다는 정도로만 알고 있었는데, 정말 그런지 재본 적은 없더군요. FLUX.1-dev로 네 단계를 같은 조건에서 돌려봤습니다. 결과가 예상과 꽤 달랐습니다.

결론

  • Q6_K가 Q8_0보다 느립니다. 파일은 2.7GB 더 작은데요. 두 번 돌려 재현했습니다.

  • Q4_K_S가 의외로 잘 버팁니다. Q8_0보다 13% 빠르고 VRAM을 7.3GB 덜 쓰는데, 이 이미지에서는 차이를 못 찾았습니다.

  • 다만 비트 수가 높으면 정밀도도 실제로 높습니다. 제 화질 비교는 프롬프트 하나·시드 하나라, 차이가 없다는 증명은 못 됩니다. 여유가 되면 높은 쪽이 안전한 선택인 건 그대로입니다.

  • Q2_K는 흐릿해지는 게 아니라 프롬프트를 못 따라갑니다. 있어야 할 물건이 사라집니다.

  • 작은 양자화가 빠를 거라는 기대는 절반만 맞습니다. 파일이 3배 차이나도 생성은 20%밖에 안 벌어집니다.

  • 로딩은 양자화로 못 줄입니다. IO를 걷어내면 19~25초로 평평합니다.

환경과 조건

R9700(gfx1201, 31.86GiB), ROCm 7.2.4, ComfyUI 0.28.0 + ComfyUI-GGUF, Proxmox VM(16코어/94GB), 모델은 NAS에 두고 NFS로 읽습니다.

FLUX.1-dev 1024×1024, 20스텝, euler/simple, guidance 3.5, cfg 1.0, 시드 고정. UNet만 바꾸고 t5xxl fp8·clip_l·ae는 넷 다 같은 걸 씁니다. 양자화본은 city96/FLUX.1-dev-gguf.

양자화본마다 ComfyUI를 재시작했습니다. 앞서 확인한 대로 큰 작업이 남긴 VRAM이 반납되지 않아서, 이어서 재면 뒤 양자화본이 앞의 잔여물을 뒤집어씁니다. 그러면 양자화 차이가 아니라 실행 순서를 재는 셈이 됩니다.

전체를 두 번 돌렸고, 생성 시간이 0.3초 안에서 일치했습니다. 같은 시드라 출력 PNG도 바이트 단위로 같았고요.

결과

양자화

파일

생성(20스텝)

VRAM 피크

순수 로드

GPU 사용률

Q2_K

3.76 GiB

30.50 s

17.89 GiB

21.5 s

95.5%

Q4_K_S

6.34 GiB

31.19 s

20.47 GiB

24.3 s

94.4%

Q6_K

9.18 GiB

37.54 s

23.75 GiB

25.1 s

93.3%

Q8_0

11.84 GiB

35.76 s

27.81 GiB

19.3 s

80.3%

생성 시간은 3회 중앙값입니다. "순수 로드"는 1회차에서 생성 시간을 뺀 값이고요.

속도는 사다리가 아니라 두 계단입니다

Q2_K와 Q4_K_S가 30~31초, Q6_K와 Q8_0이 36~38초. 파일 크기는 3.76GB에서 11.84GB로 3배 벌어지는데 생성 시간은 20%밖에 차이가 안 납니다. GGUF는 연산할 때마다 역양자화를 거치니까요. 작게 만든 만큼 그대로 빨라지지는 않습니다.

그리고 Q6_K가 Q8_0보다 느립니다. 처음엔 측정 오차인가 싶어 단정을 미뤘는데, 전체를 두 번 돌린 6회를 합치니 Q6_K의 최소값(37.18초)이 Q8_0의 평균(35.6초)보다 높았습니다. Q8_0 6회 중 5회가 Q6_K의 최소값보다 빨랐고요.

K-quant는 블록마다 스케일과 최소값을 따로 들고 있어서 푸는 과정이 여러 단계입니다. Q8_0은 8비트에 스케일 하나를 곱하면 끝이고요. 파일은 더 작은데 푸는 게 더 비싼 겁니다.

Q8_0만 GPU 사용률이 80%대인 것도 같은 이야기의 뒷면으로 보입니다. 역양자화 부담이 적으니 연산기가 아니라 메모리 대역을 기다리는 쪽에 가까워지는 거죠.

Q2_K는 화질 문제가 아닙니다

"낮은 양자화는 흐릿해진다"고 알고 있었는데 실제로는 그렇지 않았습니다. 프롬프트는 a weathered brass compass on a folded nautical chart였습니다.

  • Q8_0 — 해도 위에 나침반. 유리 덮개, 방위 눈금 각인, 창가 빛, 배경의 시계까지 다 나옵니다.

  • Q6_K, Q4_K_S — 이 이미지에서는 구분하지 못했습니다. 나란히 놓고 봐도 어느 쪽이 위인지 모르겠더군요. 다른 프롬프트에서도 그럴지는 모릅니다.

  • Q2_K — 해도가 통째로 사라집니다. 백지 질감만 남고, 나침반은 형태가 뭉개지고 유리도 각인도 없습니다.

흐릿해진 게 아니라 다른 그림이 나옵니다. 프롬프트에 적은 물건이 화면에서 없어지는 건 화질 저하와는 다른 종류의 실패라, 후처리로 살릴 수도 없습니다.

절벽은 Q2_K와 Q4_K_S 사이에 있습니다. 그 위로는 이 이미지에서 눈으로 못 가렸습니다. 가늘고 반복적인 무늬, 손, 글자처럼 양자화 오차가 드러나기 쉬운 대상은 안 재봤으니, "차이가 없다"가 아니라 "여기서는 못 봤다"가 정확한 표현입니다. 화질을 숫자로 재지는 않았습니다 — 기준을 어떻게 잡느냐에 따라 결론이 바뀌는 종류라, 같은 시드로 뽑은 이미지를 직접 비교하는 편이 정직하다고 봤습니다.

로딩은 양자화로 못 줄입니다

처음 잰 로드 시간이 크기 순서와 전혀 안 맞았습니다.

Q2_K 111.8s   Q4_K_S 54.9s   Q6_K 61.0s   Q8_0 190.6s

방금 받은 파일만 RAM에 남아 있고 Q8_0은 예전 파일이라 차가웠던 탓입니다. 그대로 실었으면 양자화가 아니라 다운로드 순서를 잰 표가 될 뻔했습니다. root가 없어 캐시를 비울 수는 없으니 반대로 넷 다 캐시에 올려 조건을 맞추고 다시 쟀습니다.

Q2_K 21.5s    Q4_K_S 24.3s   Q6_K 25.1s   Q8_0 19.3s

IO를 걷어내니 19~25초로 평평합니다. 파일이 3배 차이나는데도요. 스토리지 글에서 로드 시간은 스토리지가 지배한다고 적었는데, GGUF에서도 그대로입니다. 모델을 작게 받아서 로딩을 줄이려는 건 방향이 틀렸습니다. 그건 스토리지를 바꿔야 하는 문제입니다.

그래서 뭘 받으면 되나

하나를 찍기보다 목적에 따라 갈리는 쪽이 맞다고 봅니다.

  • 정밀도를 우선한다면 Q8_0. 비트 수가 제일 높고, 이 카드에서는 Q6_K보다 빠르기까지 합니다. VRAM 27.8GB를 감당할 수 있으면 굳이 낮출 이유가 없습니다.

  • VRAM을 아껴야 한다면 Q4_K_S. 20.5GB로 7.3GB를 남기고 속도도 제일 빠릅니다. 남긴 자리에 ControlNet이나 LoRA를 얹을 수 있고요. 화질은 제가 본 범위에서는 멀쩡했습니다.

  • Q6_K는 자리가 애매합니다. 위의 Q8_0보다 느리고, 아래 Q4_K_S보다 VRAM을 더 먹습니다. 정밀도는 Q8_0에 못 미치고요. 굳이 고를 이유를 이 측정에서는 못 찾았습니다.

  • Q2_K는 마지막 수단. 프롬프트에 적은 물건이 빠질 수 있다는 걸 알고 쓰셔야 합니다.

한계

  • 카드 하나, ROCm 하나, 모델 하나(FLUX.1-dev)입니다. WAN 같은 영상 모델은 구조가 달라서 그대로 옮겨 적용하기 어렵습니다.

  • 프롬프트 하나, 시드 하나로 화질을 봤습니다. Q2_K가 다른 프롬프트에서는 덜 무너질 수도 있습니다.

  • K-quant 계열 중 Q4_K_S와 Q6_K만 봤습니다. Q5_K_S나 Q4_K_M은 안 재봤습니다.

  • 화질은 눈으로만 비교했습니다.

같이 재주실 분

NVIDIA에서도 Q6_K가 Q8_0보다 느린지가 제일 궁금합니다. 역양자화 비용 이야기라면 카드와 무관하게 나와야 하는데, 실제로 그런지 확인해보고 싶습니다. 같은 시드로 20스텝만 재서 두 숫자만 남겨주셔도 비교가 됩니다.

Q5_K_S가 두 계단 중 어디에 붙는지도 궁금합니다. 30초대면 Q4_K_S 쪽, 37초대면 Q6_K 쪽일 텐데 그 경계가 어디인지 아직 모릅니다.