KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까

KV 캐시는 어텐션 층마다 컨텍스트 속 토큰의 키와 값을 저장해 두는 메모리입니다. 크기가 정해진 모델 파일과 달리, 설정한 컨텍스트 길이에 비례해 커집니다. 예를 들어 Llama 3.1 8B를 4비트급 양자화인 Q4_K_M으로 받으면 파일은 4.9GB입니다. 그런데 컨텍스트를 128k로 잡으면 기본 형식(f16)의 KV 캐시만 17.2GB로, 파일의 세 배가 넘습니다. 얼마나 커지는지는 어텐션 설계에 따라 다릅니다. 슬라이딩 윈도나 하이브리드 구조를 쓰는 모델은 같은 컨텍스트에서 훨씬 적게 씁니다. KV 캐시를 8비트(q8_0)나 4비트(q4_0)로 양자화하면 캐시가 대략 절반, 4분의 1로 줄지만 그만큼 정밀도가 떨어집니다.

컨텍스트를 늘리면 메모리가 왜 더 드나

필요한 메모리는 세 가지로 나뉩니다. 모델 파일은 가중치 양자화 등급(Q4_K_M 등)에 따라 크기가 정해지고, 컨텍스트와는 상관이 없습니다. KV 캐시는 컨텍스트 길이에 비례해 커집니다. 연산 버퍼는 계산 중간값을 담는 작은 작업 공간입니다. CanRun은 llama.cpp 로그를 바탕으로 만든 근사식을 써서, 컨텍스트가 길어질수록 연산 버퍼도 조금씩 늘려 잡습니다.

KV 캐시는 이미 컨텍스트에 들어온 토큰의 키(key)와 값(value)을 모아 두는 공간입니다. 어텐션 층마다 토큰의 키와 값을 KV 헤드별로 저장해 두기 때문에, 새 토큰을 만들 때 앞 토큰의 키와 값을 다시 계산하지 않아도 됩니다. KV 헤드는 키와 값을 만드는 헤드이고, 쿼리 헤드 여러 개가 KV 헤드 하나를 나눠 쓰기도 합니다. 토큰 하나가 차지하는 KV 크기는 2(키와 값) × 층 수 × KV 헤드 수 × 헤드 크기 × 값 하나의 바이트 수입니다. 기본 형식인 f16은 값 하나를 16비트로 저장합니다.

전체 KV 크기는 토큰당 크기에 컨텍스트 길이를 곱한 값입니다. 그래서 컨텍스트를 두 배로 늘리면 KV 캐시도 두 배가 됩니다. 아래 표는 컨텍스트를 4k부터 32k까지 두 배씩 늘려 가며 보여 줍니다.

모델 카드와 config를 보면 세 모델은 KV 헤드 구성이 같습니다. 그래서 토큰당 KV 크기는 층 수에 비례합니다. 층 수는 Llama 3.1 8B가 32개, Qwen3 14B가 40개, Qwen3 32B가 64개입니다. 32k에서 f16 KV 캐시도 같은 비율로 커져 각각 4.3GB, 5.4GB, 8.6GB입니다. 128k에서는 Llama 3.1 8B의 f16 KV 캐시가 Q4_K_M 파일의 세 배를 넘습니다.

CanRun 표는 KV 캐시가 대화에 실제로 쓴 길이가 아니라 설정한 컨텍스트 길이만큼 자리를 차지한다고 보고 계산합니다. Ollama 컨텍스트 길이 문서도 컨텍스트 길이를 늘리면 필요한 메모리가 늘어난다고 설명합니다. 모델이 학습한 최대 길이보다 길게 잡아도, 그 너머는 제대로 쓰지 못합니다. 최대 길이는 Llama 3.1 8B가 128k, Qwen3 14B·32B가 32k입니다. 모델 카드에 나오는 YaRN 확장은 이 글에서 다루지 않습니다.

모델마다 토큰당 KV 비용이 다른 이유

토큰당 KV 크기는 파라미터 수가 아니라 어텐션 구조가 정합니다. 아래 표는 카탈로그의 모든 모델을 토큰당 KV가 큰 순서로 늘어놓고, 8k·32k·128k에서 f16 KV 캐시 크기를 보여 줍니다. 대시(—)로 표시한 칸은 모델이 지원하는 최대 길이를 넘는 컨텍스트입니다. 맨 위 Llama 3.3 70B와 맨 아래 Qwen3.5 35B-A3B는 열 배 넘게 차이 납니다.

그룹 쿼리 어텐션(GQA)

GQA는 쿼리 헤드 여러 개가 KV 헤드 하나를 나눠 쓰게 해서 KV 캐시를 줄입니다. Llama 3.1 모델 카드에 따르면 모든 버전에 GQA가 적용돼 있습니다. 모든 층이 컨텍스트 전체를 보는 전체 어텐션 모델이라면, 토큰당 KV 크기는 총 파라미터가 아니라 층 수 × KV 헤드 수 × 헤드 크기로 정해집니다. 그래서 위 표에서 보듯 같은 14B급이라도 Phi-4가 Qwen3 14B보다 토큰당 KV가 큽니다. 한국 모델도 마찬가지입니다. HyperCLOVA X SEED Think 14B는 토큰당 KV가 Qwen3 14B와 비슷하고, Kanana 1.5 8B는 Llama 3.1 8B와 같습니다.

슬라이딩 윈도 어텐션

Gemma 3·Gemma 4, gpt-oss, EXAONE 4.0 32B·EXAONE 4.5 33B는 두 종류의 층을 섞어 씁니다. 최근 토큰의 일정 구간만 보는 로컬 층과, 컨텍스트 전체를 보는 글로벌 층입니다. 로컬 층이 쓰는 방식을 슬라이딩 윈도(sliding window) 어텐션이라고 합니다. 두 층 가운데 컨텍스트 길이에 따라 KV 캐시가 커지는 쪽은 글로벌 층뿐입니다. Gemma와 이 두 EXAONE 모델은 로컬 층이 대부분이고, gpt-oss는 두 층이 절반씩입니다. Gemma 3 기술 보고서에 따르면 Gemma 3는 글로벌 층 하나에 딸린 로컬 층 수를 늘리고 로컬 구간을 짧게 해서 KV 메모리를 줄였습니다. gpt-oss-20b의 config를 보면 윈도가 128토큰인 슬라이딩 층과 전체 어텐션 층이 번갈아 나옵니다. 모델 카드에 따르면 EXAONE 4.0 32B는 로컬 층과 글로벌 층을 3:1로 섞습니다. 같은 4.0 세대라도 1.2B 모델은 모든 층이 전체 어텐션입니다. 위 표에서 Gemma 3 12B의 토큰당 KV는 크기가 비슷한 Qwen3 14B의 절반도 안 됩니다.

32B급 한국 모델에서도 차이가 뚜렷합니다. CanRun 계산으로는 LG EXAONE 4.0 32B의 f16 KV 캐시가 32k에서 2.1GB입니다. Qwen3 32B(8.6GB)의 4분의 1 수준입니다. 다만 이 값은 슬라이딩 층의 윈도 부분을 빼고 센 것이라, 실제로는 이보다 더 쓰고 두 모델의 차이도 그만큼 줄어듭니다. 자세한 내용은 아래 ‘CanRun이 슬라이딩 윈도·하이브리드 모델을 세는 방법’에 있습니다.

하이브리드 선형 어텐션(Qwen3.5)

Qwen3.5 9B 모델 카드에 따르면 Gated DeltaNet 층 3개 뒤에 Gated Attention 층 1개가 오는 묶음이 8번 반복됩니다. 다른 Qwen3.5 모델도 같은 3:1 묶음을 쓰고, 묶음 수만 다릅니다. 묶음의 네 층 가운데 KV 캐시를 두는 층은 Gated Attention 하나뿐입니다. 선형 어텐션 층인 Gated DeltaNet은 컨텍스트 길이와 상관없이 크기가 일정한 내부 상태만 저장합니다. 그래서 32k에서 Qwen3.5 9B의 f16 KV 캐시는 1.1GB로, 크기가 비슷한 Qwen3 8B(4.8GB)의 4분의 1 정도입니다.

MoE 여부와 파라미터 수로는 알 수 없다

MoE(전문가 혼합) 구조라고 KV 캐시가 줄지는 않습니다. KV 크기는 활성 파라미터가 아니라 어텐션 구조에 따라 정해지기 때문입니다. MoE 모델인 Kanana 1.5 15.7B-A3B는 토큰당 KV 크기가 dense 모델인 Llama 3.1 8B와 같습니다. Qwen3 30B-A3B (2507)은 같은 MoE 모델인 gpt-oss-20b의 네 배입니다. 총 파라미터 수도 기준이 되지 못합니다. 32k에서 gpt-oss-120b의 f16 KV 캐시는 1.2GB로, Llama 3.1 8B(4.3GB)보다 한참 작습니다.

CanRun이 슬라이딩 윈도·하이브리드 모델을 세는 방법

CanRun은 이 모델들의 KV 캐시를 계산할 때 전체 어텐션을 쓰는 글로벌 층만 셉니다. 슬라이딩 층의 윈도 부분과 선형 어텐션 층의 상태는 컨텍스트와 상관없이 크기가 일정하다고 보고 계산에서 뺍니다. 그래서 이 수치는 실제보다 낮게 나옵니다. 특히 EXAONE 4.0 32B처럼 윈도가 넓은 모델은 짧은 컨텍스트에서 차이가 큽니다. config를 보면 이 모델의 윈도는 4k 토큰으로, gpt-oss보다 훨씬 넓습니다. 그래도 글로벌 층의 KV 캐시는 컨텍스트에 비례해 커지므로, 전체 KV가 일정한 크기에서 멈추지는 않습니다. 예를 들어 Gemma 3 12B의 f16 KV 캐시는 128k에서 8.6GB입니다.

내 그래픽카드에서 컨텍스트를 얼마나 늘릴 수 있나

모델이 들어가는지는 파일, KV 캐시, 연산 버퍼를 더한 합계로 판단합니다. 이 합계를 카드에 적힌 VRAM이 아니라 사용 가능 메모리와 비교합니다. Windows에서 화면 출력을 맡은 그래픽카드는 OS가 VRAM 일부를 쓰기 때문입니다. 자세한 설명은 메모리 표 아래에 있습니다.

128k에서는 파일이 작다고 필요한 메모리도 작지는 않습니다. 아래 표의 다섯 모델 가운데 Llama 3.1 8B는 파일이 가장 작은데도 합계가 23.8GB입니다. Gemma 3 12B(17.6GB)보다 크고, 파라미터가 두 배 반가량 많은 gpt-oss-20b(17.0GB)보다도 큽니다. 표의 gpt-oss-20b는 기본 양자화인 MXFP4 기준입니다. Qwen3.5 9B는 11.9GB로 Llama 3.1 8B의 절반 정도입니다. Qwen3 30B-A3B (2507)은 128k에서 f16 KV 기준으로 33.1GB가 필요합니다. RTX 5090의 사용 가능 메모리(31.4GB)보다도 많습니다.

16GB 카드 예시: 슬라이딩 윈도 모델과 전체 어텐션 모델

GeForce RTX 5060 Ti 16GB에서 Gemma 3 12B는 8k 컨텍스트, f16 KV 기준으로 쾌적하게 돌릴 수 있습니다. 국내에서도 많이 쓰는 이 카드의 사용 가능 메모리는 15.4GB입니다. 64k에서도 f16 KV 기준 필요량이 12.7GB라 여유 있게 들어갑니다. 128k에서는 17.6GB로 사용 가능 메모리를 넘기 때문에, 표는 부분 오프로드로 계산합니다. 같은 128k라도 KV 캐시를 q8_0으로 양자화하면 13.6GB로 들어갑니다. KV 캐시 양자화는 아래 ‘KV 캐시 양자화’ 절에서 설명합니다. 다른 모델 결과는 GeForce RTX 5060 Ti 16GB 페이지에 있습니다.

전체 어텐션 모델은 사정이 다릅니다. GeForce RTX 5060 Ti 16GB에서 Qwen3 14B도 8k 컨텍스트, f16 KV 기준으로는 쾌적하게 돌릴 수 있습니다. 하지만 이 모델이 지원하는 최대 길이인 32k에서는 f16 KV 기준으로 15.2GB가 필요합니다. CanRun 계산으로는 사용 가능 메모리에 아슬아슬하게 들어갑니다. 실제로 돌릴 때는 ollama ps의 PROCESSOR 열이 100% GPU인지 확인합니다. 64k까지 여유가 있던 Gemma 3 12B와는 대조적입니다.

컨텍스트와 속도

모델이 VRAM에 다 들어가더라도, 표의 아래 행으로 갈수록 추정 속도는 조금씩 떨어집니다. CanRun은 토큰을 하나 만들 때마다 KV 캐시 전체를 읽는다고 보고 속도를 계산합니다. 그리고 표의 각 행은 컨텍스트가 그 길이까지 꽉 찼다고 가정합니다. 속도가 크게 떨어지는 것은 필요량이 사용 가능 메모리를 넘어 부분 오프로드로 바뀔 때입니다. 위 Gemma 3 12B 표의 128k f16 칸이 그 예입니다.

Ollama에서 컨텍스트를 따로 정하지 않으면, 모델이 지원하는 최대 길이가 아니라 Ollama 기본값을 씁니다. Ollama는 감지한 GPU 메모리가 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 토큰을 기본 컨텍스트 길이로 씁니다 (Ollama 문서, 2026-09-29 확인). 바꾸는 방법은 ‘Ollama가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값’에 정리했습니다.

KV 캐시 양자화 — q8_0·q4_0

KV 캐시 양자화는 키와 값을 16비트 대신 8비트(q8_0)나 4비트(q4_0) 블록으로 저장합니다. 블록마다 스케일 값도 함께 저장하므로 크기가 조금 더 나옵니다. CanRun 표에서는 q8_0이 f16의 약 54%, q4_0이 약 29%입니다. Ollama FAQ가 말하는 대략 절반, 4분의 1보다 조금 큰 값입니다.

KV 캐시 양자화는 가중치 양자화와 다른 설정입니다. 대문자 Q4_K_M·Q8_0은 모델 파일의 양자화 등급으로, 파일 크기를 정합니다. 소문자 q8_0·q4_0은 실행할 때 KV 캐시에 거는 설정으로, 컨텍스트가 쓰는 메모리만 줄입니다. 커뮤니티 글에서는 둘 다 ‘Q8’이라고 부르기도 하니 구분해서 읽어야 합니다. 둘은 함께 쓸 수 있고, KV 양자화로 아끼는 메모리는 컨텍스트가 길수록 커집니다. 모델 파일 양자화는 ‘GGUF 양자화 등급 정리 — Q4_K_M·IQ4_XS·Q8_0 무엇을 받을까’에서 다룹니다.

KV 캐시를 양자화하면 정밀도가 떨어집니다. Ollama FAQ에 따르면 q8_0은 정밀도 손실이 아주 작습니다. q4_0은 작거나 중간 정도의 손실이 있고, 컨텍스트가 길수록 더 두드러질 수 있습니다. 영향은 모델과 작업에 따라 다릅니다. FAQ는 GQA 수가 높은 모델이 영향을 더 크게 받을 수 있다며 Qwen2를 예로 듭니다. GQA 수가 높다는 것은 KV 헤드 하나를 나눠 쓰는 쿼리 헤드가 많다는 뜻입니다. CanRun은 품질을 측정하지 않습니다. 메모리만 보면 순서는 이렇습니다. f16으로 넘치면 q8_0을 먼저 써 보고, q8_0으로도 넘칠 때만 q4_0을 씁니다. 컨텍스트 길이를 줄이는 것도 방법입니다.

12GB 카드 예시: 들어가느냐 넘치느냐

GeForce RTX 3060 12GB에서 Qwen3 14B는 8k 컨텍스트, f16 KV 기준으로 쾌적하게 돌릴 수 있습니다. 국내에서 흔한 이 카드의 사용 가능 메모리는 11.4GB입니다. 8k에서도 필요량이 10.9GB라 여유가 1GB도 안 됩니다. 16k에서는 f16 KV 기준으로 12.3GB가 필요해 사용 가능 메모리를 넘습니다. 그래서 표는 16k f16 조합을 부분 오프로드로 계산합니다. 같은 16k라도 KV 캐시를 q8_0으로 양자화하면 11.1GB로 들어갑니다. 최대 길이인 32k에서는 q8_0으로도 12.7GB가 필요해 넘칩니다. q4_0이면 11.3GB로, 사용 가능 메모리 안에 간신히 들어갑니다. 8k f16, 16k q8_0, 32k q4_0 세 설정은 모두 아슬아슬하게 들어가므로 ollama ps의 PROCESSOR 열이 100% GPU인지 확인합니다. 다른 카드에서의 결과는 Qwen3 14B 페이지에, 이 카드에서 다른 모델의 결과는 GeForce RTX 3060 12GB 페이지에 있습니다.

켜는 방법

Ollama는 서버를 띄울 때 OLLAMA_KV_CACHE_TYPE(f16·q8_0·q4_0)을 지정하고 플래시 어텐션을 켜야만 KV 캐시를 양자화합니다. 이 설정은 그 서버가 돌리는 모든 모델에 적용됩니다 (Ollama 문서, 2026-09-29 확인). Windows에서는 먼저 작업 표시줄 알림 영역의 Ollama 아이콘에서 앱을 종료합니다. 그다음 PowerShell에서 $env:OLLAMA_CONTEXT_LENGTH="16384"; $env:OLLAMA_FLASH_ATTENTION="1"; $env:OLLAMA_KV_CACHE_TYPE="q8_0"; ollama serve를 실행합니다. 위 12GB 예시의 16k q8_0 칸과 같은 설정입니다. 이 설정은 그 PowerShell 창에서 띄운 서버에만 적용됩니다. 모델은 PowerShell 창을 하나 더 열어 ollama run hf.co/unsloth/Qwen3-14B-GGUF:Q4_K_M로 불러옵니다.

창을 닫은 뒤에도 설정을 유지하려면 시작 메뉴 검색으로 ‘계정의 환경 변수 편집’을 엽니다. 관리자 권한은 필요 없습니다. 사용자 변수에 OLLAMA_FLASH_ATTENTION(값 1)과 OLLAMA_KV_CACHE_TYPE(값 q8_0 또는 q4_0)을 추가하고, 필요하면 OLLAMA_CONTEXT_LENGTH도 넣습니다. 그다음 Ollama를 다시 실행합니다.

llama.cpp의 llama-server에서는 -fa on --cache-type-k q8_0 --cache-type-v q8_0처럼 키와 값의 형식을 따로 지정합니다. 서버 README에 따르면 둘 다 기본값은 f16입니다. 조합 페이지가 q8_0·q4_0 칸에 보여 주는 명령도 이 형태입니다.

GPU에 다 들어가는 조합끼리 비교하면 q8_0·q4_0 칸의 속도가 f16보다 높게 나옵니다. 이 차이는 CanRun의 대역폭 공식에서 읽어야 할 KV가 줄어서 생긴 계산 결과이고, 측정한 값이 아닙니다. KV 캐시 양자화는 속도를 올리려고 쓰는 설정이 아니라 메모리를 아끼려고 쓰는 설정입니다.

이 숫자는 얼마나 확실한가

메모리 수치 가운데 파일 크기는 실제 GGUF 파일 크기를 그대로 씁니다. KV 캐시는 각 모델이 공개한 config로 공식에 따라 계산한 값입니다. 토큰당 KV 공식은 CanRun 엔진 테스트에서 일곱 가지 구조의 공개값과 일치합니다. 연산 버퍼는 llama.cpp 로그를 바탕으로 한 근삿값입니다.

슬라이딩 윈도·하이브리드 모델의 KV 수치는 윈도 부분과 선형 어텐션 층의 상태를 뺀 만큼 실제보다 낮게 나옵니다. 윈도가 넓은 EXAONE 4.0 32B는 짧은 컨텍스트에서 이 차이가 큽니다. llama.cpp 서버의 --swa-full 옵션은 기본으로 꺼져 있습니다. 이 옵션을 켜면 슬라이딩 윈도 층도 컨텍스트 전체만큼 캐시를 잡아서, 슬라이딩 윈도 모델은 CanRun 수치보다 메모리를 훨씬 많이 씁니다. 예를 들어 Gemma 3 12B는 이때 캐시를 잡는 층이 CanRun이 세는 글로벌 층의 여섯 배라, KV 캐시도 CanRun 수치의 여섯 배쯤 됩니다.

CanRun 계산이 런타임의 실제 동작과 같지는 않습니다. Ollama는 자체 메모리 추정으로 GPU와 CPU에 나눠 올릴 양을 정합니다. 내 PC에서 모델이 실제로 어떻게 올라갔는지는 ollama ps의 SIZE·PROCESSOR·CONTEXT 열로 확인합니다. 표는 Windows에서 그 카드로 화면을 출력하고, 시스템 RAM이 32GB(DDR5)라고 가정합니다. 모델은 하나만 올리고 요청도 한 번에 하나씩 처리한다고 봅니다. Ollama FAQ에 따르면 필요한 메모리는 OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH에 따라 늘어납니다.

속도는 오차 범위와 신뢰 라벨을 붙인 추정치입니다. 보정된 추정의 오차 범위는 NVIDIA·AMD 그래픽카드에서 dense 모델을 GPU에만 올릴 때 ±12%입니다. 부분 오프로드, MoE, 그 밖의 하드웨어에서는 ±20%이고, 이론 추정은 ±30%입니다. 이 글에 나온 컨텍스트 표 두 개의 속도는 모두 보정된 추정입니다. 다만 q8_0·q4_0 칸은 KV 양자화 효과를 공식으로만 반영했습니다. CanRun이 보정에 쓰는 공개 측정 가운데 KV 캐시를 양자화한 기록은 없습니다.

MoE 모델의 조합 페이지에서 전문가를 시스템 RAM에 두는 구성(MoE 전문가 RAM 배치)의 속도는 이론 추정입니다. 실제보다 느리게 나올 가능성이 큽니다. 컨텍스트를 늘리면 이 방식으로 바뀌는 조합이 생기는데, 이런 조합의 속도는 참고용으로만 보시기 바랍니다.

본문에서 쾌적하게 돌릴 수 있다고 한 곳은 모두 8k 컨텍스트, f16 KV 기준입니다. 다른 컨텍스트 결과는 표에서 확인할 수 있습니다.

더 읽을거리:

• 컨텍스트 길이를 설정하는 방법: Ollama가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값
• 카드 VRAM별로 들어가는 모델: 로컬 LLM 사양 — VRAM 8~32GB로 돌릴 수 있는 모델 (2026)
• 모델 파일을 줄여 컨텍스트에 쓸 메모리를 확보하는 방법: GGUF 양자화 등급 정리 — Q4_K_M·IQ4_XS·Q8_0 무엇을 받을까
• 맥에서 모델과 KV 캐시가 통합 메모리를 나눠 쓰는 방식: 맥에서 로컬 LLM 돌리기 — M4·M5 통합 메모리는 얼마나 필요할까

자주 묻는 질문

대화가 짧아도 컨텍스트를 길게 잡으면 메모리를 더 쓰나요?

네. Ollama 컨텍스트 길이 문서도 컨텍스트 길이를 늘리면 필요한 메모리가 늘어난다고 설명합니다. CanRun 표 역시 대화에 실제로 쓴 길이가 아니라 설정한 길이만큼 KV 캐시 자리를 잡아서 계산합니다. Llama 3.1 8B의 f16 KV 캐시는 8k에서 1.1GB, 128k에서 17.2GB입니다. 컨텍스트는 필요한 만큼만 설정하고, ollama ps의 CONTEXT·SIZE 열로 확인합니다. 컨텍스트가 덜 차 있어도 메모리는 그만큼 차지합니다. 다만 속도는 컨텍스트가 끝까지 찼다고 가정한 표보다 덜 떨어집니다.

왜 큰 모델이 작은 모델보다 컨텍스트 메모리를 덜 쓰기도 하나요?

KV 캐시 크기가 파라미터 수가 아니라 어텐션 설계로 정해지기 때문입니다. 층 수, KV 헤드 수, 슬라이딩 윈도나 선형 어텐션 층이 있는지가 크기를 좌우합니다. CanRun 계산으로 32k에서 f16 KV 캐시는 gpt-oss-120b가 1.2GB로, Llama 3.1 8B(4.3GB)보다 작습니다. EXAONE 4.0 32B는 2.1GB로 Qwen3 32B(8.6GB)의 4분의 1 수준입니다. EXAONE 값은 슬라이딩 층의 윈도 부분을 빼고 센 것이라 실제로는 이보다 더 씁니다. MoE 구조라고 KV 캐시가 줄지도 않습니다. Qwen3 30B-A3B (2507)과 gpt-oss-20b는 둘 다 MoE지만 어텐션 구조가 달라서, 토큰당 KV 크기는 Qwen3 30B-A3B (2507)이 네 배 큽니다. 컨텍스트 길이를 정하기 전에 위 KV 표에서 쓰려는 모델의 행을 먼저 확인해 두면 좋습니다.

KV 캐시 양자화는 Q4_K_M 모델 파일을 고르는 것과 같은 건가요?

아닙니다. Q4_K_M 같은 가중치 양자화는 모델 파일 크기를 정하고, KV 캐시 양자화(q8_0·q4_0)는 실행할 때 컨텍스트가 차지하는 메모리를 정합니다. 둘은 서로 별개라서 함께 쓸 수 있습니다. KV 양자화로 아끼는 메모리는 컨텍스트가 길수록 커집니다. 예를 들어 RTX 3060 12GB의 사용 가능 메모리는 11.4GB입니다. 여기서 Qwen3 14B를 16k로 돌리면 f16 KV로는 12.3GB, q8_0으로는 11.1GB가 필요합니다. f16으로는 사용 가능 메모리를 넘고, q8_0이면 아슬아슬하게 들어가므로 ollama ps로 확인합니다. Ollama에서는 OLLAMA_KV_CACHE_TYPE으로 켜는데, 서버 전체에 적용되고 플래시 어텐션도 함께 켜야 합니다. llama.cpp에서는 -fa on --cache-type-k q8_0 --cache-type-v q8_0처럼 지정합니다.

q8_0·q4_0 KV 캐시는 품질을 얼마나 떨어뜨리나요?

Ollama FAQ에 따르면 q8_0은 정밀도 손실이 아주 작습니다. q4_0은 작거나 중간 정도의 손실이 있고, 컨텍스트가 길수록 더 두드러질 수 있습니다. 영향은 모델과 작업에 따라 다릅니다. KV 헤드 하나를 나눠 쓰는 쿼리 헤드가 많은 모델, 즉 Qwen2처럼 GQA 수가 높은 모델은 영향을 더 크게 받을 수 있습니다. CanRun은 품질을 측정하지 않습니다. 메모리만 보면 f16으로 넘칠 때 q8_0을 쓰고, q8_0으로도 넘칠 때만 q4_0을 씁니다. 품질은 쓰려는 컨텍스트 길이에서 평소 프롬프트로 직접 시험해 봐야 알 수 있습니다.

출처

• Ollama FAQ: KV 캐시 양자화(f16·q8_0·q4_0의 메모리와 정밀도, 플래시 어텐션이 필요한 서버 전체 설정, 모델·작업마다 다른 영향, GQA 수가 높은 모델이 영향을 더 받을 수 있다는 주의와 Qwen2 예), OLLAMA_FLASH_ATTENTION, OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH에 따라 늘어나는 메모리
• Ollama 문서: 컨텍스트 길이: 컨텍스트 길이를 늘리면 필요한 메모리도 늘어난다는 설명, VRAM별 기본 컨텍스트, ollama ps의 열(SIZE·PROCESSOR·CONTEXT), CPU 오프로드를 피하라는 권고
• llama.cpp 서버 README: --cache-type-k/-ctk·--cache-type-v/-ctv(허용 형식, 기본 f16), -fa(on·off·auto), -c/--ctx-size, --swa-full(기본 꺼짐), --fit/--fit-ctx
• Llama 3.1 8B Instruct 모델 카드: 모든 버전에 적용된 GQA, 128k 컨텍스트
• Qwen3-8B 모델 카드: 층 수, 쿼리·KV 헤드 수, 네이티브 32k와 YaRN 확장 설명
• Qwen3-14B 모델 카드: 층 수, 쿼리·KV 헤드 수, 네이티브 32k와 YaRN 확장 설명
• Qwen3-32B 모델 카드: 층 수, 쿼리·KV 헤드 수, 네이티브 32k
• Qwen3-30B-A3B-Instruct-2507 모델 카드: 층 수, 쿼리·KV 헤드 수, 전문가 구성, 네이티브 256k
• Qwen3.5-9B 모델 카드: Gated DeltaNet 층 3개와 Gated Attention 층 1개를 한 묶음으로 반복하는 하이브리드 구성, 어텐션 층의 KV 헤드 수, 네이티브 256k
• Gemma 3 기술 보고서: 글로벌 층에 비해 로컬 층의 비율을 높이고 로컬 구간을 짧게 해서 긴 컨텍스트의 KV 캐시 메모리를 줄인 설계
• gpt-oss-20b config.json: 윈도가 128토큰인 슬라이딩 층과 전체 어텐션 층이 번갈아 놓인 배치, KV 헤드 수와 헤드 크기, 최대 128k
• EXAONE 4.0 32B 모델 카드: 32B 모델에 적용된 로컬(슬라이딩 윈도) 층과 글로벌 층의 3:1 혼합, 층 수, GQA, 최대 128k
• EXAONE 4.0 32B config.json: 슬라이딩 윈도 크기(4k 토큰), 로컬·글로벌 층 배치 패턴