2.5GB 로컬 LLM이 7.6GB를 쓰는 이유, 긴 글에서 느려지는 이유

파일에는 지금 나눈 대화가 들어 있지 않다

모델 파일에 담긴 가중치는 학습으로 얻은 값이다. 양자화는 이 값을 더 적은 비트로 저장해 용량을 줄이는 방법이다. 이번에 사용한 Qwen3 4B Q4_K_M 파일의 크기는 정확히 2,497,280,256바이트였다.

실행을 시작하면 파일 밖에서도 공간이 필요하다. 모델은 입력을 읽고 다음 토큰을 만들면서 앞선 문맥을 참조한다. 이때 계산한 키와 밸류를 저장해 재사용하는 공간이 KV 캐시다. 같은 앞부분을 반복 계산하는 비용을 줄이는 대가가 메모리 사용이다. 토큰은 모델이 글을 나누어 처리하는 단위이며, 한 토큰이 언제나 한 글자나 한 단어인 것은 아니다.

캐시에 대화문을 텍스트 그대로 넣는 것도 아니다. 모델의 여러 층에서 계산한 숫자 배열을 보관한다. 모델 파일이 작더라도 문맥을 길게 준비하면 캐시가 파일보다 커질 수 있다. 여기에 연산에 필요한 작업 버퍼 등이 더해진다.

자료: 모델 양자화의 개념 · Hugging Face의 KV 캐시 설명

캐시 4.8GB는 모델 구조로도 계산된다

이번 모델은 36개 층에서 키와 밸류를 저장한다. KV 헤드는 8개, 헤드 차원은 128이며 FP16 저장에는 값 하나당 2바이트가 든다. 한 요청에 32,768토큰의 문맥을 준비했을 때 캐시 계산은 다음과 같다.

키·밸류 2개 × 36층 × 8개 KV 헤드 × 128차원 × 32,768토큰 × 2바이트 = 4,831,838,208바이트. 십진 단위로 약 4.83GB다.

실제 실행 로그의 CUDA KV 버퍼는 4,608MiB였다. 같은 양을 다른 단위로 쓴 값이다. 위 계산과 일치하므로 2.50GB 모델 파일과 별도로 약 4.83GB의 문맥 공간을 확보했음을 알 수 있다. 로그에 나온 MiB를 숫자 그대로 MB나 GB로 바꾸면 계산이 어긋난다.

자료: Qwen3 4B 모델 구조 · Hugging Face의 KV 캐시 설명

최대 문맥을 크게 잡는 것과 긴 글을 넣는 것은 다르다

이번 llama.cpp 설정은 최대 문맥에 맞춰 캐시 공간을 미리 확보했다. 실제 입력이 짧아도 최대 문맥을 키우면 로딩 직후 메모리 보고값이 커졌다. 관측한 약 7.6GB를 모든 요청이 실제로 가득 채워 쓰는 대화량으로 해석하면 안 된다.

같은 짧은 입력 1,024토큰을 넣어 비교하자 최대 문맥이 4,096·16,384·32,768토큰일 때 생성 속도는 각각 초당 약 72.7·72.6·72.5토큰이었다. 공간을 크게 예약한 것만으로 짧은 요청이 크게 느려지지는 않았다.

로컬 LLM 설정 화면의 문맥 길이를 볼 때는 두 질문을 나눠야 한다. 얼마나 긴 요청을 받아들이도록 공간을 준비했는가. 지금 요청에는 실제로 얼마나 긴 문맥이 들어 있는가. 두 숫자가 같은 뜻은 아니다. 다른 실행기는 캐시를 필요에 따라 늘리거나 관리하는 방식도 다를 수 있다.

자료: Hugging Face의 KV 캐시 설명

메모리 숫자는 그대로인데 생성 속도는 절반 가까이 줄었다

다음에는 최대 문맥을 32,768토큰으로 고정하고 실제 입력을 늘렸다. 1,024토큰을 넣었을 때 초당 약 72.5토큰이던 생성 속도는 24,576토큰에서 약 35.2토큰으로 내려갔다. 두 조건 모두 출력은 128토큰으로 맞췄다.

이때 실행 중 메모리 보고값은 같았다. 캐시 공간을 앞서 확보해 둔 상태였기 때문이다. 다음 토큰을 만들 때 참조하는 문맥은 길어졌다. 공간의 크기는 그대로여도 처리할 일은 늘어난 것이다.

입력 처리 시간도 0.205초에서 8.429초로 늘었다. 답변이 나오기 전에 입력을 읽는 단계와 답변 토큰을 하나씩 생성하는 단계를 따로 볼 필요가 있다. 생성 속도만 표시한 성능표에서는 첫 단계에 쓴 시간이 잘 드러나지 않는다.

자료: Hugging Face의 KV 캐시 설명

캐시를 줄였더니 생성은 빨라지고 입력 처리는 느려졌다

모델 파일을 바꾸지 않고 KV 캐시 형식을 FP16에서 q8_0로 바꿨다. 최대 문맥은 32,768토큰으로 유지했다. 캐시 할당량은 약 4.83GB에서 2.57GB로 46.875% 줄었고, 로딩 직후 프로세스 메모리는 약 7.58GB에서 5.43GB로 내려갔다. 캐시 감소율과 전체 프로세스 메모리 감소율은 다르다.

실제 입력 24,576토큰 조건에서 생성 속도는 초당 35.25토큰에서 40.38토큰으로 올랐다. 여기까지만 보면 메모리도 절약하고 속도도 얻은 선택이다. 입력 처리 시간은 8.429초에서 9.813초로 늘었다.

입력 처리와 128토큰 생성을 합친 실행기 기록은 FP16에서 약 12.06초, q8_0에서 약 12.98초였다. 짧게 반올림하면 12.1초에서 13.0초로 늘어난 셈이다. 이번 요청에서는 생성 단계가 빨라진 이득보다 입력 단계의 추가 시간이 컸다.

이 결과를 모든 길이의 답변에 적용할 수는 없다. 출력이 길어지면 생성 단계가 차지하는 비중도 달라진다. 이전 문맥을 재사용하는 작업은 입력 처리 조건 자체가 달라질 수 있다. 이번 비교에서는 캐시 형식과 함께 실행 커널 경로도 바뀌므로 저장 비트 수 하나만의 효과로 단정하지 않았다.

내 컴퓨터에 적용하려면 조건을 함께 봐야 한다

GB10은 CPU와 GPU가 메모리를 공유하는 통합 메모리 장비다. 여기서 읽은 GPU 프로세스 보고값을 일반 그래픽카드에 필요한 전용 VRAM 용량으로 그대로 옮길 수는 없다. 시스템 전체 물리 메모리 사용량과도 구분해야 한다.

답변 정확도는 이번에 평가하지 않았으므로 캐시가 작아졌다고 품질까지 그대로라고 말할 근거는 없다. 메모리에 들어가는지, 원하는 시간 안에 끝나는지, 결과가 쓸 만한지는 각각 확인할 문제다.

로컬 모델을 비교할 때 파일 크기 옆에는 최대 문맥과 실제 입력 길이를, 속도 옆에는 입력 처리 시간과 출력 길이를 함께 놓는 편이 낫다. 캐시 형식까지 맞춰야 같은 수치를 비교할 수 있다. 자신의 작업에 필요하지 않은 긴 문맥을 무조건 확보하거나, 가장 작은 캐시 형식을 무조건 고르는 식으로는 이번 실험의 결과를 활용하기 어렵다.

자료: NVIDIA DGX Spark의 통합 메모리

이번에 어떻게 측정했나

2026년 9월 8일 GB10에서 Qwen3 4B Q4_K_M 파일 하나를 사용했다. 최대 문맥·실제 입력 길이·KV 캐시 형식을 나눈 8개 조건을 각각 3회 실행해 24회 응답을 모았고, 별도 워밍업 4회는 집계에서 제외했다. 모든 조건의 출력 길이는 128토큰으로 맞췄다.

이전 요청의 프롬프트 캐시는 재사용하지 않았다. 실제 응답의 입력·출력 토큰 수와 잘림 여부, 캐시 재사용 값, 조건별 반복 횟수를 확인했다. KV 캐시 산식도 실행 로그와 대조했다. 본문의 시간과 생성 속도는 3회 평균이며, 로딩 직후 메모리는 설정별 시작 시점의 관측값이다.

파일과 장비, 실행기 조건을 고정한 비교이므로 이번 글은 최신 모델의 지능 순위나 제품별 구매 추천표가 아니다. 작은 파일이 실행할 때 어떤 공간과 계산을 추가로 요구하는지 확인한 기록이다.