🎬 원본 릴스 보기 →

릴스 해설

[릴스 해설] 27B 모델을 16GB에 넣은 GGUF 양자화

한 줄 요약: 27B 모델이 16GB 노트북에 돌아간 비밀은 GGUF 양자화다 — 비트 축소·코드북·imatrix·하이브리드 어텐션으로 13.8GB까지 줄이고도 원본과 다음 토큰 92.4%가 일치한다.

한 릴스가 눈에 띄었습니다. 27B(270억) 매개변수짜리 AI 모델을 16GB 노트북에서 돌린다는 내용입니다. 모델은 Alibaba의 Qwen3.8-27B, 빌드를 만든 곳은 Atomic Chat입니다. Atomic은 Qwen3.8-27B용 Dynamic GGUF를 공개하면서 8-bit 28.9GB부터 1-bit 8.5GB까지 열여섯 가지 크기로 내놓았고, 그 가운데 AD-IQ3_S(13.8GB)가 16GB MacBook에서 돌아간다고 설명했습니다. “BF16과의 다음 토큰 일치율 92.4%“라는 숫자도 붙어 있었습니다.

이 릴스는 단순히 “작아진 모델이 나왔다”는 소식이 아니라, 로컬 AI를 가능하게 하는 **양자화(quantization)**라는 기술 전체를 압축해 보여줍니다. 27B 모델이 어떻게 16GB에 들어가는지, 그리고 92.4%라는 숫자가 무엇을 의미하는지 풀어 설명하겠습니다.

27B 모델은 왜 16GB에 안 들어가나: 원래 크기의 문제

Qwen3.8-27B는 270억 개의 매개변수(weight)를 가진 dense(밀집) 모델입니다. 모델을 학습할 때는 각 매개변수를 16-bit 부동소수점으로 저장합니다. 이 정밀도를 BF16(bfloat16)이라 부릅니다. 보통 16-bit 부동소수점은 2바이트를 쓰므로, 270억 매개변수는 대략 54.7GB가 됩니다. 16GB 노트북은커녕 24GB 그래픽카드에도 들어가지 않는 크기입니다.

여기에 **문맥(context)**까지 더해야 합니다. 모델이 대화를 이어갈 때, 이전 토큰들의 계산 결과를 KV 캐시(key-value cache)라는 메모리에 보관합니다. 문맥이 길어질수록 이 캐시도 커집니다. 일반적인 27B 트랜스포머라면 26만 토큰 문맥만으로도 캐시가 수십 GB에 달합니다. 그래서 “모델 무게 + 문맥 캐시”를 합치면 16GB는 턱없이 부족합니다.

이 문제를 푸는 첫 단계가 양자화입니다.

양자화: 정밀도를 줄여서 용량을 줄인다

양자화는 매개변수를 더 적은 비트로 표현해서 파일 크기와 메모리 사용량을 줄이는 기술입니다. 16-bit(BF16) 대신 8-bit, 4-bit, 3-bit, 심지어 1-bit까지 줄입니다. 비트가 절반으로 줄면 용량도 거의 절반으로 줄어듭니다.

  • 8-bit(Q8_0): 28.9GB — 원본에 거의 근접한 품질
  • 4-bit(Q4_K_M): 약 17GB — 가장 널리 쓰이는 기본값
  • 3-bit(IQ3_S): 13.8GB — 16GB 기기의 목표 지점
  • 1-bit(IQ1_M): 8.5GB — 가장 작지만 품질 손실이 뚜렷

비트를 줄일수록 용량은 작아지지만, 매개변수를 더 적은 값으로 반올림해야 하므로 정보가 손실됩니다. 그래서 양자화의 핵심 질문은 “어디까지 줄여도 모델이 망가지지 않는가?“입니다. 이 릴스의 92.4%는 바로 그 한계선을 보여주는 숫자입니다.

GGUF: 로컬 AI의 단일 파일 포맷

양자화된 모델을 담는 그릇이 GGUF(GPT-Generated Unified Format)입니다. llama.cpp(로컬에서 AI 모델을 돌리는 C/C++ 추론 엔진)가 쓰는 파일 형식으로, 하나의 .gguf 파일 안에 다음이 모두 들어갑니다.

  • 양자화된 가중치(모델 본체)
  • 토크나이저(텍스트를 토큰으로 쪼개는 사전)
  • 아키텍처 메타데이터(층 수, 어텐션 헤드 수, 문맥 길이 등)
  • 채팅 템플릿(대화 형식을 모델이 이해하도록 포장하는 규칙)

즉 파일 하나만 있으면 Ollama, LM Studio, llama.cpp 어디서든 모델이 그대로 돌아갑니다. 외부 설정 파일이나 파이썬 환경이 필요 없습니다. 게다가 mmap(메모리 매핑)으로 파일을 가상 메모리에 올려두면, 운영체제가 필요한 부분만 RAM으로 불러오므로 로딩이 빠릅니다. GGUF가 로컬 AI 배포의 사실상 표준이 된 이유입니다.

K-quant와 I-quant: 같은 비트라도 품질이 다르다

GGUF 파일 이름에 붙는 Q4_K_M, IQ3_S 같은 접미사는 양자화 방식을 가리킵니다. 비트 수가 같아도 방식에 따라 품질이 다릅니다.

K-quant(Q4_K, Q5_K, Q6_K 등)는 256개 매개변수를 한 묶음(슈퍼블록)으로 묶어, 두 단계로 스케일을 저장하는 방식입니다. 단순히 32개마다 스케일을 하나씩 두는 옛 방식보다 메타데이터 오버헤드를 줄이면서도 국소 분포에 더 잘 맞습니다. 뒤의 _S/_M/_L은 섞기 정책을 뜻합니다. 민감한 층(어텐션 출력 투영, FFN 다운 투영 등)은 더 높은 비트로 올리고 나머지는 기본 비트로 두는 식으로, 파일 전체를 같은 비트로 통일하지 않고 중요도에 따라 섞습니다. Q4_K_M가 일반적인 기본값인 이유입니다.

I-quant(IQ2, IQ3, IQ4 등)는 3비트 아래에서 빛을 발합니다. 매개변수를 하나씩 반올림하는 대신, 4~8개를 묶어 코드북(미리 정해둔 패턴 목록)의 인덱스로 저장합니다. 수학적으로 가장 조밀한 격자(E8 격자)에서 패턴을 뽑아 쓰기 때문에, 같은 비트 수에서 K-quant보다 품질 손실이 적습니다. 대신 디코딩이 조금 더 복잡하고, 안정적인 품질을 위해 imatrix(다음 섹션)가 거의 필수입니다. IQ3_S가 3비트급에서 Q3_K보다 같은 크기에 더 나은 품질을 내는 이유가 여기에 있습니다.

Dynamic GGUF와 AD-IQ3_S: 16GB의 sweet spot

릴스가 말하는 Dynamic GGUF는, 파일 안의 모든 텐서를 같은 비트로 양자화하지 않고 텐서별·층별로 다른 비트를 섞는 빌드를 뜻합니다. Atomic은 자신들의 방식을 AD(Atomic Dynamic)라고 부르며, 각 텐서가 얼마나 민감한지 측정(KL 다이버전스 기준)해서 가장 품질 손실이 적은 조합을 찾습니다.

이 릴스의 주인공 AD-IQ3_S는 13.8GB입니다. 16GB 기기에서 모델 무게(13.8GB)를 올리고 나면 약 2GB가 남는데, 이 여분으로 약 8K 토큰의 문맥을 돌릴 수 있습니다. Atomic이 16GB 메모리 추천 빌드로 AD-IQ3_S를 꼽은 근거입니다. 더 작은 빌드(AD-IQ2_S 11.1GB)는 12GB 기기용, 더 큰 빌드(AD-Q4_K_M 17.1GB)는 24GB 카드용으로 대응합니다.

비고: Atomic이 공개한 16가지 빌드와 “BF16 대비 92.4% 일치”라는 수치는 Atomic 자체 측정값입니다. 기준 모델은 원본 BF16 가중치, 측정 방법은 공개 코퍼스로 공개되어 있어 재현 가능하지만, 벤더가 직접 낸 숫자라는 점은 염두에 두어야 합니다.

92.4%가 의미하는 것: 품질을 어떻게 재는가

“BF16과의 다음 토큰 일치율 92.4%“는 양자화된 모델이 원본과 얼마나 같은 답을 내는가를 보여주는 지표입니다. 구체적으로는, 원본 BF16 모델이 고르는 다음 토큰(top-1)을 양자화 모델도 같은 토큰으로 고르는 위치의 비율입니다. 92.4%면 열 번 중 아홉 번은 원본과 같은 토큰을 고른다는 뜻입니다.

이런 지표가 왜 필요할까요? 전통적인 perplexity(언어 모델이 텍스트를 얼마나 잘 예측하는지의 척도)는 숫자가 전체적으로는 괜찮아 보여도, 특정 분포에서만 망가지는 손상을 숨길 수 있습니다. 그래서 Atomic은 perplexity와 함께 KL 다이버전스(양자화 출력 분포와 원본 분포의 거리)와 top-1 match(같은 토큰을 고르는 비율)를 함께 씁니다. AD-IQ3_S의 KL 다이버전스는 0.03247로, 같은 13.8GB급에서 가장 낮다고 Atomic은 주장합니다. 요약 지표 하나를 보면 top-1 match가 가장 직관적입니다.

다만 “92.4% 일치 = 품질 92.4%“는 아닙니다. 나머지 7.6%가 어디서 빗나가는지가 중요합니다. 빗나감이 무작위 노이즈면 대화 품질에는 거의 영향이 없지만, 특정 작업(코드 생성, 수학 등)에서만 일관되게 빗나가면 그 작업은 눈에 띄게 나빠집니다. 그래서 Atomic뿐 아니라 여러 빌드를 비교하는 독립 측정도 같이 참고하는 게 안전합니다.

imatrix: 저비트에서 품질을 지키는 열쇠

3비트 이하로 줄이면 “어떤 매개변수를 더 정밀하게 보존할까”가 품질을 가릅니다. 여기에 쓰는 도구가 imatrix(importance matrix, 중요도 행렬)입니다.

imatrix는 원본 모델을 캘리브레이션 코퍼스(보통 위키텍스트 같은 대표적인 텍스트)로 돌려서, 각 매개변수가 만나는 활성값의 제곱 평균을 모읍니다. 활성값이 큰 채널의 매개변수는 출력에 큰 영향을 주므로 더 정밀하게 보존하고, 활성값이 작은 채널은 과감히 줄입니다. 즉 “모든 매개변수를 똑같이 취급”하는 단순 반올림의 한계를 넘어, 출력에 미치는 영향을 기준으로 비트를 배분합니다.

I-quant 계열(IQ3_S, IQ2 등)은 이 imatrix 없이는 제대로 만들 수 없을 정도로 imatrix에 의존합니다. 다만 캘리브레이션 데이터가 품질 변수가 되므로, 영어 위키텍스트로 만든 imatrix는 한국어나 코드 작업에서는 살짝 안 맞을 수 있습니다. 이것이 “같은 IQ3_S라도 누가 만들었느냐에 따라 다르다”는 현상의 원인입니다.

하이브리드 어텐션: Qwen3.8-27B가 16GB에 들어가는 구조적 이유

양자화만으로는 16GB에 들어가기 부족합니다. 모델 무게를 13.8GB로 줄여도 문맥 캐시가 크면 남는 2GB로 긴 대화를 버틸 수 없습니다. Qwen3.8-27B는 하이브리드 어텐션 구조로 이 문제를 줄입니다.

64개 층 가운데 48개는 Gated DeltaNet(선형 어텐션의 일종)으로, 문맥이 길어져도 캐시 크기가 고정입니다. 나머지 16개 층만 일반적인 Gated Attention을 써서 KV 캐시를 키웁니다. 결과적으로 토큰당 캐시가 약 256KB로, 비슷한 크기의 일반 27B 모델(약 1MB/토큰)의 약 1/4에 그칩니다. 그래서 8K 문맥이 약 2GB, 32K 문맥이 약 8GB로 들어옵니다. 16GB에서 AD-IQ3_S(13.8GB) + 8K 문맥(약 2GB) 조합이 성립하는 것은 양자화와 이 구조적 이점이 함께 작용하기 때문입니다.

어떻게 연결되는가

한 줄로 요약하면: 27B 모델을 BF16의 약 1/4 크기(13.8GB)로 줄여 16GB 노트북에 올리는 데는, GGUF 양자화(비트 축소)와 imatrix(중요도 기반 배분)와 하이브리드 어텐션(캐시 절감) 세 기술이 겹쳐 작용한다는 이야기입니다.

릴스의 92.4%는 “13.8GB로 줄였는데도 열 번 중 아홉 번은 원본과 같은 토큰을 고른다”는 뜻이며, 이 숫자가 의미를 가지려면 비트 축소·코드북 양자화·imatrix·층별 섞기(Dynamic)가 함께 받쳐주어야 합니다. 로컬 AI의 메모리 문턱을 낮추는 선택지라는 릴스의 핵심 메시지는, 단순히 “작은 파일이 나왔다”가 아니라 이 기술 스택 전체가 만들어낸 결과입니다.

다만 16GB는 이 모델의 최소 동작선이지 여유 있는 환경은 아닙니다. 24GB 카드라면 AD-Q4_K_M(17.1GB) 정도에서 더 넓은 문맥과 더 안정적인 품질을 얻을 수 있고, 12GB 이하에서는 2-bit급까지 내려가야 하는데 이 구간은 품질 손실이 눈에 띄게 커집니다. 자신의 기기 메모리에 맞춰 빌드를 고르는 것이 이 생태계를 쓰는 실질적인 출발점입니다.

출처: Atomic Chat — How to Run Qwen 3.8 27B Locally · llama.cpp quantize 문서 · GGUF 파일 포맷 문서 · Qwen3.8-27B 모델 카드 · llama.cpp imatrix 문서