파라미터, 컨텍스트, KV Cache, 다운로드 용량은 어떻게 연결되는가

로컬 LLM을 고를 때 가장 많이 헷갈리는 부분은 파라미터, 컨텍스트, 메모리, 다운로드 용량의 관계다. “4bit 모델이면 메모리가 4분의 1만 필요한가?”, “A3B면 3B만 다운로드하면 되는가?”, “128K 컨텍스트 모델이면 파일이 더 큰가?” 같은 질문이 여기서 나온다.

정확히 보려면 네 축을 분리해야 한다. 전체 파라미터는 모델 파일과 기본 메모리 사용량에 가깝고, active parameter는 토큰당 계산량에 가깝다. 컨텍스트 길이는 한 번에 넣을 수 있는 토큰 수이고, KV cache는 긴 문맥을 처리하기 위해 실행 중 별도로 잡아먹는 메모리다.

다운로드 용량은 전체 파라미터와 양자화가 결정한다

모델 다운로드 용량은 대략 전체 파라미터 수 × 양자화 bit / 8로 추정할 수 있다. 27B 모델을 4bit로 저장하면 이론적으로 13.5GB 근처가 된다. 35B 모델을 4bit로 저장하면 17.5GB 근처가 된다. 실제 파일은 메타데이터, 스케일 값, 일부 고정밀 레이어, 포맷 차이 때문에 더 커질 수 있다.

중요한 점은 MoE 모델의 다운로드도 전체 파라미터 기준이라는 것이다. 35B-A3B-4bit는 3B 4bit 모델처럼 작지 않다. 전체 35B 파라미터가 파일에 들어 있고, 실행 중 어떤 expert가 선택될지 모르므로 전체를 보유해야 한다. A3B는 계산량 힌트이지 파일 크기 힌트가 아니다.

초소형 대시보드에 있는 SmolLM2 135M Q4_K_M이 100MB 안팎이고, TinyLlama 1.1B Q4_K_M이 수백 MB인 이유도 같은 원리다. 전체 파라미터가 작기 때문에 파일도 작다.

실행 메모리는 모델 가중치만이 아니다

실제로 모델을 돌릴 때 필요한 메모리는 모델 파일 크기와 같지 않다. 실행 메모리는 대략 다음 항목을 합친 것이다.

• 모델 가중치 메모리
• KV cache 메모리
• 런타임 오버헤드
• GPU/CPU 버퍼
• 배치와 동시 요청 처리 공간
• OS와 다른 앱이 쓰는 여유 메모리

그래서 14GB짜리 4bit 모델이라고 해서 16GB 장비에서 항상 안정적으로 도는 것은 아니다. 짧은 대화는 가능해도 긴 컨텍스트를 열거나 다른 앱을 같이 쓰면 메모리가 부족할 수 있다.

Mac의 Apple Silicon은 unified memory 구조라 CPU와 GPU가 같은 메모리 풀을 공유한다. NVIDIA GPU가 있는 PC는 RAM과 VRAM이 분리된다. 이 차이 때문에 “24GB”라는 숫자도 장비 종류에 따라 체감이 다르다. NVIDIA에서는 모델이 VRAM에 얼마나 올라가는지가 중요하고, Mac에서는 전체 unified memory와 메모리 대역폭이 중요하다.

컨텍스트는 책상 크기다

컨텍스트 길이는 모델이 한 번에 볼 수 있는 토큰 수다. 32K, 128K, 256K 같은 숫자로 표시된다. 컨텍스트가 길면 긴 문서, 회의록, 코드, 이전 대화를 더 많이 넣을 수 있다. 하지만 컨텍스트가 길다고 모델이 더 똑똑해지는 것은 아니다. 책상이 커져서 자료를 많이 펼칠 수 있을 뿐, 그 자료를 잘 읽고 추론하는 능력은 모델 품질과 별개다.

컨텍스트는 다운로드 용량과 직접적인 관계가 작다. 128K 컨텍스트를 지원한다고 파일이 그만큼 커지는 것은 아니다. 하지만 실행 중 메모리에는 큰 영향을 준다. 이유는 KV cache 때문이다.

긴 문맥을 넣으면 모델은 이전 토큰들의 key/value 정보를 저장해 둔다. 그래야 다음 토큰을 만들 때 매번 모든 입력을 처음부터 다시 계산하지 않아도 된다. 이 저장 공간이 KV cache다.

KV Cache는 긴 문서에서 메모리를 크게 먹는다

KV cache는 컨텍스트 길이에 거의 비례해서 늘어난다. 4K 대화에서는 작게 느껴질 수 있지만, 32K, 128K, 256K로 갈수록 무시할 수 없는 메모리가 된다. 특히 대형 모델은 레이어 수와 hidden size가 커서 토큰당 KV cache 비용도 커진다.

여기서 중요한 오해가 있다. 모델 가중치를 4bit로 양자화했다고 해서 KV cache까지 자동으로 4bit가 되는 것은 아니다. 많은 런타임은 KV cache를 FP16, BF16, Q8, Q4 등 별도 설정으로 다룬다. 그래서 “4bit 모델인데 왜 긴 컨텍스트에서 메모리를 많이 쓰지?”라는 상황이 생긴다.

일부 런타임은 KV cache quantization을 제공한다. Q8 또는 Q4 KV cache를 쓰면 긴 컨텍스트의 메모리 부담을 줄일 수 있다. 대신 품질 손실이나 호환성 문제가 생길 수 있으므로 중요한 작업에서는 테스트가 필요하다.

하드웨어와 연결되는 지점

전체 파라미터와 양자화는 RAM/VRAM 용량과 직접 연결된다. 모델을 올릴 공간이 부족하면 CPU로 일부를 넘기거나 디스크 스와핑이 생겨 속도가 크게 떨어진다. Active parameter는 GPU/CPU 연산량, tokens/sec, 전력 사용과 더 직접적으로 연결된다. 컨텍스트 길이는 KV cache 메모리와 prompt eval 시간에 연결된다.

GPU에서 중요한 것은 VRAM 용량, 메모리 대역폭, INT4/INT8/FP16 연산 성능, CUDA나 Metal 같은 런타임 지원이다. 개인 로컬 채팅에서는 메모리 대역폭이 매우 중요하다. 매 토큰마다 큰 가중치를 읽어야 하기 때문이다. CPU도 쓸 수 있지만 대형 모델에서는 보통 느리다. CPU는 GPU가 부족할 때 보조하거나, 서버 운영과 토크나이징, 일부 offload에 관여한다.

실행 체크리스트

• 다운로드 용량은 active parameter가 아니라 전체 파라미터와 양자화 bit를 기준으로 본다.
• 실행 메모리는 모델 가중치, KV cache, 런타임 오버헤드를 모두 더해서 생각한다.
• 컨텍스트 길이는 파일 크기보다 실행 중 KV cache 메모리에 더 큰 영향을 준다.
• 4bit 모델이라도 KV cache는 별도 정밀도로 저장될 수 있다.
• 긴 문서를 다룰수록 RAM/VRAM 여유가 중요하다.
• MoE 모델은 저장은 전체 파라미터 기준, 속도는 active parameter 기준에 가깝다.
• 실제 사용 전에는 원하는 context 길이로 테스트해야 한다.

결론적으로 로컬 LLM의 “무거움”은 하나의 숫자로 결정되지 않는다. 다운로드는 전체 파라미터와 bit, 속도는 active parameter와 하드웨어, 긴 문서 처리 능력은 context와 KV cache가 좌우한다. 이 네 축을 분리해서 보면 대시보드의 숫자들이 훨씬 정확하게 읽힌다.