양자화

모델 가중치의 숫자를 16비트에서 8비트·4비트처럼 덜 정밀하게 적어 모델 크기를 절반이나 4분의 1로 줄이는 기법이다. 메모리가 모자라 큰 모델이 노트북이나 GPU 한 장에 안 올라갈 때, 또는 서버에서 더 많은 요청을 처리하고 싶을 때 가장 먼저 꺼내는 방법이다.

70B 모델의 가중치 크기. 실제로 돌릴 때는 KV 캐시와 여유분이 더 필요하다. 4비트 파일은 부가 정보가 붙어서 가중치 하나당 4.5~5비트쯤 된다.

사진을 적당히 압축한 JPG로 저장해도 눈으로는 차이를 거의 못 느끼듯, 정밀도를 어느 정도 깎아도 답변 품질은 대부분 유지된다.

로컬에서는 GGUF 이름표만 보면 된다

내 컴퓨터에서 돌릴 때는 GGUF 형식이 사실상 표준이다. Ollama에서 ollama run을 하면 보통 4비트 버전을 받아 오고, Hugging Face에서 직접 받을 때는 파일 이름의 숫자를 보면 된다. 숫자가 비트 수라서 클수록 파일이 크고 정확하다. 4비트가 오히려 더 빠른데, 토큰 하나를 만들 때마다 메모리에서 읽어 올 데이터가 적기 때문이다.

직접 만들 때는 16비트 원본에서 llama-quantize로 변환한다. 이때 imatrix 파일을 같이 주면 같은 비트에서도 품질 손실이 줄어든다. 이미 양자화된 파일을 또 양자화하면 품질이 크게 떨어지니 하지 않는다.

서버에서는 vLLM 옵션 하나로 바뀐다

vLLM 같은 추론 서버에서는 AWQ나 GPTQ로 이미 양자화한 모델을 많이 쓴다. 둘 다 학습이 끝난 모델을 나중에 압축하는 방식이라 다시 학습할 필요가 없다. 아낀 GPU 메모리만큼 요청을 더 많이 묶어서 처리할 수 있다.

최신 GPU는 FP8이나 4비트 NVFP4·MXFP4 같은 저정밀 형식을 하드웨어에서 바로 지원한다. 그래서 정수 대신 이런 형식이 많이 쓰이는 추세다. gpt-oss처럼 처음부터 MXFP4로 공개된 모델은 120B인데도 80GB GPU 한 장에 올라간다.

수학·코드에서 먼저 티가 난다

일상 대화에서는 4비트도 차이를 느끼기 어렵다. 하지만 긴 문맥 추론, 수학, 코드처럼 작은 오차가 쌓이는 작업에서는 먼저 품질이 떨어진다. 작은 모델일수록, 3비트 아래로 갈수록 손상이 커진다.

그래서 퍼플렉시티나 KL 발산 같은 지표로 먼저 대략 확인한다. 최종 판단은 내 서비스의 실제 질문으로 원본 모델과 나란히 비교해서 내리는 게 안전하다. 모델 제작사가 학습 단계부터 낮은 정밀도에 맞춰 만든 공식 양자화본(QAT)이 있다면 그것을 먼저 고려한다.

내 PC부터 추론 서버까지 기본값이 됐다

오픈 모델을 직접 돌리는 곳이라면 거의 어디서나 양자화본이 기본이다. 원본 16비트는 품질 비교용으로 남겨 두고, 실제로 돌리는 건 8비트나 4비트인 경우가 많다.