Skip to main content

5장. 양자화, 컨텍스트, MoE 이해하기

5.1 Q4, Q5, Q8 양자화란 무엇인가​

양자화는 모델을 더 낮은 정밀도로 표현해 메모리 사용량과 계산 비용을 줄이는 기술입니다. 원래 모델 가중치가 16비트나 32비트 부동소수점으로 저장되어 있다면, 이를 8비트, 5비트, 4비트 같은 더 작은 표현으로 바꾸는 식입니다. Hugging Face Transformers 문서도 양자화를 낮은 정밀도 데이터 타입으로 표현해 메모리와 계산 비용을 줄이는 기술로 설명합니다.

GGUF 모델 파일을 보면 Q4, Q5, Q8 같은 표기를 자주 봅니다. 대략적으로 Q4는 4비트 계열, Q5는 5비트 계열, Q8은 8비트 계열 양자화라고 이해하면 됩니다. 숫자가 낮을수록 파일 크기와 메모리 사용량이 줄어드는 경향이 있지만, 품질 손실 가능성이 커집니다. 숫자가 높을수록 원본에 가까운 품질을 기대할 수 있지만 더 많은 메모리가 필요합니다.

초보자에게는 Q4 또는 Q5 계열이 현실적인 출발점입니다. Q8은 품질은 좋을 수 있지만 로컬 장비에서는 부담이 큽니다. 반대로 너무 낮은 비트 양자화는 코드 정확도에 영향을 줄 수 있습니다. 코딩 작업에서는 작은 오류가 실행 실패로 이어질 수 있으므로, 단순 대화보다 양자화 품질에 더 민감할 수 있습니다.

[표 5-1] Q4, Q5, Q8의 비교.

5.2 모델 크기와 품질 사이의 타협점​

로컬 모델 선택은 타협의 연속입니다. 큰 모델은 더 좋은 답을 할 가능성이 있지만 느립니다. 작은 모델은 빠르지만 실수할 수 있습니다. 높은 정밀도는 품질에 유리하지만 메모리를 많이 씁니다. 낮은 정밀도는 가볍지만 품질 손실이 있을 수 있습니다.

타협점을 찾는 가장 좋은 방법은 작업별로 기준을 다르게 두는 것입니다. 자동완성은 속도 우선입니다. 코드 리뷰나 리팩터링은 품질 우선입니다. 문서 요약은 컨텍스트 우선입니다. 테스트 생성은 정확성과 출력 형식이 중요합니다. 하나의 모델을 고를 때도 “내가 가장 많이 하는 작업이 무엇인가”를 먼저 봐야 합니다.

개인 개발자라면 7B급 Q4/Q5 모델에서 시작하는 것이 무난합니다. 장비가 약하면 1.5B~3B 자동완성 모델을 먼저 써 봅니다. 장비가 좋으면 14B 이상도 비교합니다. 중요한 것은 처음부터 최고 모델을 찾으려 하지 않는 것입니다. “내 장비에서 안정적으로 도는 기준 모델”을 먼저 정하고, 그보다 더 큰 모델을 하나씩 비교하면 됩니다.

5.3 컨텍스트 길이가 코딩에서 중요한 이유​

코드는 주변 맥락과 함께 읽어야 합니다. 함수 하나를 고치려면 타입 정의를 봐야 할 수 있습니다. API 호출을 바꾸려면 백엔드 스펙을 봐야 할 수 있습니다. 테스트를 만들려면 기존 테스트 스타일을 봐야 합니다. 이 모든 정보가 모델의 컨텍스트 안에 들어갈수록 답변이 좋아질 가능성이 높습니다.

그러나 컨텍스트 길이는 무료가 아닙니다. 길게 잡을수록 메모리 사용량과 처리 시간이 늘어납니다. 또한 모델이 긴 컨텍스트를 지원한다고 해서 모든 토큰을 같은 품질로 이해하는 것은 아닙니다. 긴 입력 안에서 중요한 정보를 찾지 못하거나, 앞부분과 뒷부분의 제약을 충돌시킬 수 있습니다.

코딩에서 좋은 컨텍스트 설계는 관련 파일을 선별하는 능력입니다. 현재 파일, 호출하는 함수, 타입 정의, 테스트 파일, README의 관련 부분 정도면 충분한 경우가 많습니다. 프로젝트 전체를 무작정 넣는 것보다, 작업에 필요한 파일을 작게 묶어 주는 것이 좋습니다.

[이미지 5-1] 컨텍스트 윈도우 구성 그림.

5.4 긴 파일, 여러 파일, 전체 프로젝트를 다룰 때의 한계​

긴 파일을 모델에게 통째로 넣으면 편해 보입니다. 하지만 실제로는 문제가 생깁니다. 토큰이 너무 많아져 응답이 느려집니다. 모델이 파일 중간의 중요한 조건을 놓칠 수 있습니다. 수정 범위가 커져서 사람이 리뷰하기 어려워집니다. 특히 로컬 모델은 컨텍스트와 속도의 균형이 더 중요합니다.

여러 파일을 다룰 때는 파일 선택이 핵심입니다. 예를 들어 프론트엔드 컴포넌트를 수정할 때는 컴포넌트 파일, 타입 정의, API 클라이언트, 관련 테스트 정도가 필요할 수 있습니다. 백엔드 API를 수정할 때는 라우터, 서비스, 모델, 테스트, 마이그레이션 파일이 필요할 수 있습니다. 모델이 자동으로 다 찾아 주기를 기대하기보다, 개발자가 먼저 관련 후보를 좁혀 주면 품질이 올라갑니다.

전체 프로젝트를 이해시키고 싶다면 코드베이스 인덱싱이나 RAG가 필요합니다. Continue 문서에서도 코드 RAG를 만들 때 chunking, embedding, vector database 같은 단계를 설명합니다. 하지만 RAG는 마법이 아닙니다. 검색이 잘못되면 엉뚱한 파일이 들어가고, 모델은 그 컨텍스트를 바탕으로 잘못된 결론을 낼 수 있습니다. 그래서 RAG 결과도 사람이 확인해야 합니다.

5.5 MoE 모델은 왜 빠르면서도 똑똑해 보이는가​

MoE는 Mixture of Experts의 줄임말입니다. 여러 전문가 네트워크를 두고, 입력마다 일부 전문가만 활성화하는 구조로 이해하면 됩니다. 모든 파라미터를 매번 다 쓰지 않으므로, 전체 파라미터 수에 비해 계산량을 줄일 수 있습니다. 그래서 MoE 모델은 “파라미터 수는 큰데 활성화되는 부분은 일부라서 상대적으로 빠르다”는 식으로 설명됩니다.

로컬 환경에서 MoE 모델은 매력적입니다. 큰 모델처럼 똑똑해 보이면서도 계산량은 덜할 수 있기 때문입니다. 그러나 실제 실행에서는 메모리 배치가 중요합니다. 활성화되지 않는 전문가 가중치도 어딘가에는 저장되어야 합니다. VRAM이 부족하면 속도가 떨어질 수 있고, 설정에 따라 CPU와 GPU 사이 병목이 생길 수 있습니다. LM Studio도 MoE expert weights를 CPU나 GPU에 두는 고급 설정을 도입한 바 있습니다.

초보자는 MoE를 “무조건 빠른 큰 모델”로 이해하면 안 됩니다. 내 장비와 런타임에서 실제로 빠른지 테스트해야 합니다. MoE 모델이 어떤 작업에서는 훌륭하고, 어떤 작업에서는 일반 dense 모델보다 불안정할 수 있습니다. 모델 선택은 항상 실험으로 마무리해야 합니다.

[표 5-2] Dense 모델과 MoE 모델 비교.

5.6 코딩용 모델을 고를 때 봐야 할 체크리스트​

코딩용 모델을 고를 때는 다음 순서로 봅니다.

  • 첫째, 라이선스입니다. 개인 실험인지, 회사 업무인지, 상업 제품에 포함할 가능성이 있는지에 따라 허용 범위가 달라집니다.
  • 둘째, 모델 목적입니다. 코딩 특화인지, 일반 대화용인지, 추론용인지 봅니다.
  • 셋째, 모델 크기와 양자화입니다. 내 장비에 맞는지 확인합니다.
  • 넷째, 컨텍스트 길이입니다. 내 작업에 충분한지 봅니다.
  • 다섯째, 자동완성 지원 여부입니다. IDE 자동완성에 쓸 모델이라면 fill-in-the-middle 성능이 중요합니다.
  • 여섯째, 한국어 지시 이해력입니다. 한국어로 일하는 팀이라면 무시할 수 없습니다.
  • 일곱째, 실제 테스트 결과입니다. 벤치마크보다 내 코드에서의 결과가 중요합니다.

체크리스트는 모델을 고르는 데만 쓰지 말고, 팀의 표준을 만들 때도 활용할 수 있습니다. 예를 들어 팀에서 “로컬 채팅 기본 모델”, “자동완성 기본 모델”, “보안 민감 코드 분석 모델”을 따로 정하고, 각 모델의 라이선스와 성능 테스트 결과를 문서화해 두면 좋습니다.

[표 5-3] 로컬 코딩 모델 선택 체크리스트.

5.7 로컬 LLM 초보자를 위한 모델 선택 공식​

먼저 내 장비의 RAM과 GPU/VRAM을 확인합니다. 그다음 7B급 Q4 또는 Q5 코딩 모델을 하나 고릅니다. 장비가 약하면 3B 이하로 내려갑니다. 장비가 좋으면 14B 이상을 비교합니다. 자동완성은 별도로 더 작은 모델을 테스트합니다. 마지막으로 내 프로젝트에서 자주 하는 작업 5개로 모델을 평가합니다.

모델 선택에서 가장 나쁜 방식은 인터넷에서 본 “최고 모델”을 무작정 받아 설치하는 것입니다. 내 장비에서 느리면 좋은 모델도 쓸 수 없습니다. 반대로 너무 작은 모델만 쓰면 로컬 AI의 가능성을 제대로 느끼기 어렵습니다.

처음에는 한가지 모델로 다양한 테스트를 해보는 것을 권장합니다. 모델을 자주 바꾸면 어떤 문제가 모델 때문인지, 프롬프트 때문인지, 컨텍스트 때문인지 알기 어렵습니다. 기준 모델을 정하고 사나흘 정도 써 봅니다. 그다음 더 작은 모델, 더 큰 모델, 다른 양자화 버전을 하나씩 비교합니다.

다음 Part에서는 LM Studio를 설치하고 실제로 로컬 모델 서버를 만들어 보겠습니다.