GGUF Q4_K_M의 K와 M은 무슨 뜻일까

GGUF 모델을 받다 보면 Q4_K_M, Q4_K_S, Q5_K_M처럼 비슷한 파일명이 반복해서 보인다. 앞의 Q4나 Q5는 대략적인 양자화 정밀도를 나타낸다는 점이 비교적 직관적이지만, 뒤의 K와 M은 처음 보면 의미를 짐작하기 어렵다.

결론부터 말하면 Q4_K_M에서 K는 llama.cpp의 K-quant 계열을 뜻하고, M은 Medium 변형을 의미한다. 특히 M은 단순히 “중간 크기 파일”이라는 표시라기보다, 어떤 텐서를 더 높은 정밀도로 남길지까지 포함한 양자화 구성의 차이라고 보는 편이 정확하다.

GGUF의 K와 M에서 가장 먼저 볼 변화

Q4_K_M은 Q4 + K + M으로 읽으면 된다

Q4_K_M은 크게 Q4 + K + M으로 읽으면 된다.

Q4는 양자화 비트 계열이다

Q4의 4는 기본적으로 4비트 계열 양자화를 나타낸다. 다만 실제 GGUF 파일 전체가 모든 가중치를 정확히 4 bit per weight로 저장한다는 뜻은 아니다.

예를 들어 현재 llama.cpp의 벤치마크 기준 Q4_K_M은 실질적으로 약 4.89 bits/weight 수준으로 나타난다. 일부 텐서는 다른 형식이나 더 높은 정밀도를 사용할 수 있고, 스케일 같은 추가 데이터도 필요하기 때문이다.

따라서 Q4는 “전체 파일이 정확히 4비트”라는 의미보다는 어떤 양자화 계열을 중심으로 구성됐는지를 나타내는 이름으로 보는 것이 좋다.

같은 이유로 Q5_K_M 역시 단순히 파일 전체가 정확히 5비트인 것은 아니다. llama.cpp의 현재 Llama-3 8B 테스트에서는 Q5_K_M이 약 5.70 bits/weight로 측정된다.

K는 llama.cpp의 K-quant 계열을 뜻한다

GGUF의 K와 M가 ComfyUI 워크플로우에 미치는 영향

Q4 뒤에 붙는 _K는 기존 Q4_0이나 Q4_1과 구분되는 K-quant 방식이라는 뜻이다. llama.cpp의 K-quant는 여러 가중치를 더 큰 super-block 단위로 묶고, 그 안을 다시 작은 block으로 나누어 scale과 minimum 같은 양자화 정보까지 압축하는 구조를 사용한다.

기존 방식과 비교해야 할 부분

Q4_K와 Q5_K의 경우 256개 값으로 구성된 super-block 안에서 더 작은 단위로 양자화를 수행한다. 이런 방식은 단순한 기존 block quantization보다 저장 효율과 정확도 사이의 균형을 개선하기 위해 도입됐다.

K의 어원을 외울 필요는 없다

인터넷에서는 K를 K-means라고 설명하거나 특정 단어의 약자로 단정하는 경우가 있다. 하지만 실제 파일을 선택하는 입장에서는 그 어원을 외우는 것이 중요하지 않다.

_K가 붙으면 llama.cpp의 K-quant 계열이라는 점만 이해하면 충분하다. Q4_0과 Q4_K_M은 둘 다 4비트 계열이라고 해도 내부 양자화 구조가 동일한 방식은 아니다.

특히 최근 GGUF 저장소에서는 Q4_K_M이 사실상 대표적인 4비트 선택지처럼 제공되는 경우가 많다. llama.cpp 자체에서도 Q4_K라는 이름을 입력하면 현재 Q4_K_M의 별칭으로 처리한다.

M과 S는 Medium과 Small을 구분한다

성능과 결과 품질에서 확인할 차이

가장 헷갈리는 부분은 마지막 글자다. llama.cpp는 현재 파일 형식을 직접 Q4_K - Small, Q4_K - Medium처럼 표시한다.

워크플로우 구성에서 놓치기 쉬운 부분

즉 Q4_K_S의 S는 Small, Q4_K_M의 M은 Medium이다. Q3 계열에는 여기에 L까지 있어 Q3_K_S, Q3_K_M, Q3_K_L처럼 Small·Medium·Large로 구분된다.

M은 단순한 파일 크기 표기가 아니다

그렇다고 M을 단순히 “파일 크기가 중간”이라고만 이해하면 핵심을 놓치게 된다. 실제로 S와 M의 차이는 중요한 일부 텐서에 어떤 양자화 타입을 적용하느냐에서도 나타난다.

예를 들어 일반적인 Q4_K_S 구성에서는 대부분의 대상 텐서를 Q4_K 수준으로 처리하는 반면, Q4_K_M은 일부 attention value나 FFN down 관련 텐서를 더 높은 정밀도의 Q6_K로 처리할 수 있다. 그래서 같은 Q4_K 계열 안에서도 M이 조금 더 커지는 대신 품질 손실을 줄이는 방향으로 구성된다.

Q4_K_S와 Q4_K_M은 실제로 얼마나 다른가

llama.cpp가 현재 제공하는 Llama-3 8B 기준 수치를 보면 차이가 더 명확하다.

Q4_K_S는 약 4.37GB이며 기준 모델 대비 perplexity 증가가 +0.2689로 측정된다. Q4_K_M은 약 4.58GB로 조금 더 크지만 perplexity 증가는 +0.1754로 더 낮다.

즉 같은 Q4_K라도 M 쪽이 저장 공간을 조금 더 사용하는 대신 정보 손실을 줄이는 방향이다. Q5_K에서도 비슷하게 Q5_K_S와 Q5_K_M이 구분된다.

실제로 적용할 때 체크할 점

다만 이 수치를 ComfyUI의 이미지 품질 차이로 그대로 환산해서는 안 된다. 해당 벤치마크는 LLM을 기준으로 한 값이며, diffusion model이나 video model에서는 모델 구조와 양자화 방식에 따라 체감 차이가 달라질 수 있다.

ComfyUI에서 Q4_K_M을 선택하는 기준

ComfyUI에서 CITY96 등의 GGUF 모델을 선택할 때는 먼저 앞의 Q 숫자로 메모리 수준을 좁히고, 그다음 S와 M을 선택하는 방식이 이해하기 쉽다.

같은 Q4 계열이라면 파일 크기를 조금이라도 더 줄여야 할 때 Q4_K_S를 검토할 수 있다. 반대로 약간의 추가 용량을 허용하면서 더 보수적으로 양자화된 구성을 원한다면 Q4_K_M이 자연스러운 후보가 된다.

여유가 있다면 Q5_K_M이나 Q6_K처럼 더 높은 정밀도도 선택할 수 있다. 중요한 것은 M = 무조건 최고, S = 품질이 나쁨처럼 절대적인 등급으로 해석하지 않는 것이다. 실제 선택은 모델 종류와 VRAM, 실행 속도, 원하는 결과 품질을 함께 봐야 한다.

Q4_K_M은 어렵게 볼 필요가 없다. Q4는 4비트 중심의 양자화 계열, K는 K-quant 방식, M은 Medium 구성을 의미한다.

GGUF 파일을 받을 때는 먼저 Q4·Q5 같은 앞부분으로 메모리와 정밀도 수준을 정하고, 같은 계열 안에서는 S와 M의 차이를 확인하면 된다. ComfyUI에서 처음 선택한다면 Q4_K_M을 기준점으로 잡고, VRAM이 부족하면 더 작은 구성으로 내려가거나 여유가 있다면 Q5 계열로 올리는 방식이 가장 이해하기 쉽다.