로컬 LLM을 처음 접하는 사람들이 가장 흔히 하는 실수 중 하나는 “더 큰 모델이 무조건 낫다”는 전제로 접근하는 것이다. 70B 파라미터 모델을 맥북에서 돌릴 수 있다는 사실 자체가 일종의 도전 과제처럼 느껴지기도 하고, 벤치마크 수치만 보면 70B가 27B보다 당연히 앞서 보인다. 그런데 실제로 써보면 이야기가 달라지는 경우가 적지 않다.
“억지로 돌린다”는 표현이 다소 거칠게 들릴 수 있지만, 기술적으로 보면 꽤 정확한 묘사다. 70B 모델을 Q4_K_M 양자화로 실행하려면 약 40GB의 메모리가 필요하다. 맥북 프로 M2 Max나 M3 Max처럼 통합 메모리가 96GB에 달하는 최상위 기종이라면 여유 있게 올라가지만, 36GB나 48GB 모델이라면 이야기가 다르다. 메모리가 부족할 때 흔히 선택하는 방법이 Q2_K나 Q3_K 같은 저비트 양자화다. Q2_K는 원본 모델 대비 약 2비트 수준으로 가중치를 압축하는 방식인데, 이 과정에서 모델의 표현 능력이 상당히 손상된다. 단순히 조금 느려지거나 가끔 틀리는 정도가 아니라, 일관성 있는 추론 자체가 흔들리기 시작한다.
속도도 문제다. 48GB 맥북에서 70B Q3_K를 돌리면 토큰 생성 속도가 3~5 tok/s 정도에 머무는 경우가 많다. 300~400 토큰짜리 응답 하나에 1분 이상이 걸린다는 뜻이고, 대화 흐름 자체가 끊긴다. 생각의 연속성이 중요한 작업이라면 이 대기 시간이 체감 피로도를 크게 높인다.
반면 27B 모델을 Q4_K_M으로 돌리면 상황이 달라진다. 27B Q4_K_M의 메모리 요구량은 약 16~18GB 수준이다. 36GB 맥북이라면 시스템 메모리와 겹쳐도 넉넉하게 실행된다. 그리고 이 조건에서 속도는 보통 10~20 tok/s, 기종에 따라서는 그 이상이 나온다. 생각을 이어가면서 대화할 수 있는 속도다.
양자화 수준이 모델 크기보다 품질에 더 큰 영향을 주는 경우
이 부분이 처음 들으면 직관에 반하는 이야기처럼 느껴지지만, 실제 사용자 경험과 커뮤니티 테스트 결과들은 같은 방향을 가리킨다. Llama 3 70B를 Q2_K로 압축하면, 같은 패밀리의 Llama 3.1 8B를 Q8_0으로 돌리는 것보다 오히려 성능이 떨어지는 상황이 생긴다. 특히 명령 따르기, 형식 준수, 코드 정확성처럼 정밀도가 요구되는 작업에서 이 역전 현상이 두드러진다.
양자화는 가중치를 압축하는 과정에서 정보 손실이 발생하는데, 저비트 양자화일수록 손실이 커진다. Q4_K_M을 기준으로 삼으면, 이 수준부터는 FP16(완전 정밀도) 모델과 품질 차이가 거의 느껴지지 않는다는 것이 일반적인 평가다. Q3_K부터 눈에 띄는 저하가 시작되고, Q2_K는 꽤 심각한 수준의 저하가 나타난다. 따라서 실사용에서 의미 있는 최저선은 Q4_K_M이고, 이 기준을 맞추지 못하는 모델 크기라면 처음부터 작은 모델을 고르는 편이 합리적이다.
이미지 출처: Unsplash
사실 어떤 작업을 하느냐도 모델 선택에 크게 영향을 준다. 코딩 작업이라면 70B 범용 모델이 오히려 불리할 수도 있다. CodeLlama나 Qwen2.5-Coder 같은 코딩 특화 7B~13B 모델은 프로그래밍 관련 데이터로 집중 훈련되어 있어서, 일반 목적의 70B보다 실제 코드 생성 품질이 높은 경우가 많다. 코드 완성, 버그 수정, 함수 생성처럼 정형화된 출력이 요구되는 작업은 파라미터 수보다 훈련 데이터의 질과 방향성이 더 결정적이다.
일상적인 대화나 간단한 질의응답, 요약 작업은 7B~13B 모델로도 충분하다. 실제로 일상 사용 시나리오에서 13B 모델의 응답과 70B 모델의 응답을 구분하기 어려운 경우가 많다. 체감 차이가 생기는 구간은 장문의 복잡한 추론, 긴 맥락 유지, 다단계 논리 전개 같은 작업에서다. 수천 단어짜리 문서를 분석하거나 복잡한 인과관계를 따라가는 작업이라면 70B가 분명한 차이를 만든다. 단, 이 경우에도 “Q4_K_M 이상으로 쾌적하게 돌아가는” 70B여야 의미가 있다.
결국 실용적인 기준은 하나다. 내 기기에서 Q4_K_M 이상으로 실행했을 때 10 tok/s 이상이 나오는 최대 크기의 모델을 고르는 것. 48GB 맥북이라면 27B Q4_K_M이 그 기준에 딱 들어맞고, 64GB라면 34B 혹은 일부 40B 모델까지 여유 있게 올라간다. 96GB 기종에서야 비로소 70B Q4_K_M이 쾌적하게 돌아간다.
앞으로 모델 양자화 기술이 더 발전하면 이 공식이 바뀔 수도 있다. 이미 GGUF 포맷의 K-quant 계열은 이전 세대 양자화보다 훨씬 좋은 품질-용량 균형을 보여주고 있고, 비트넷(BitNet) 같은 연구 방향은 아예 처음부터 저비트 학습을 전제로 한 아키텍처를 탐구하고 있다. 하지만 지금 당장 쓸 수 있는 모델로 판단하면, 큰 숫자를 좇다가 억지로 실행하는 것보다 자기 기기에서 쾌적하게 돌아가는 모델을 택하는 편이 거의 언제나 더 나은 경험을 준다.
출처
- TheBloke GGUF Model Collection — Quantization Descriptions (Hugging Face)
- llama.cpp GitHub — Performance benchmarks and quantization guide
- Ollama Model Library — Model size and memory requirements
- Qwen2.5-Coder Technical Report (Alibaba DAMO Academy)
- LocalLLaMA community — r/LocalLLaMA quantization comparison threads (Reddit)