16GB GPU에서 KV 캐시: 긴 컨텍스트를 실제로 처리하기

모델은 128K 컨텍스트 윈도우를 표방하면서도 16 GB GPU에서 40K 토큰 단계에서 실패할 수 있습니다. 아키텍처의 한계는 웨이트, KV 캐시, 계산 버퍼, 그리고 데스크톱 compositor가 모두 동시에 해당 카드에 맞을 것이라고 약속한 적이 없습니다.

KV 캐시는 보통 장문 컨텍스트 계획이 물리적 한계에 부딪히는 곳입니다. 활성 토큰과 시퀀스가 늘어날 때마다 함께 커지므로, 시작 시에는 부담 없어 보인 설정이 급격히 느려지거나, 시스템 메모리로 넘쳐나거나, 대규모 prefill 과정에서 실패할 수 있습니다.

이 가이드는 해당 문제를 VRAM 예산으로 전환합니다. 캐시 공식, 재현 가능한 32K에서 128K 크기 테이블, 그리고 llama.cpp의 --cache-type-k와 --cache-type-v, vLLM의 paged 및 prefix caching, Ollama의 컨텍스트 제어에 대한 작동하는 설정들을 다룹니다. 또한 관심을 가져야 하지만 맹신해야 할 것은 아닌 실험적 adaptive-cache 포크들도 포함됩니다. 이러한 수치 이면의 더 넓은 처리량, 지연 시간, 벤치마크 맥락을 알기 시작하려면 LLM 성능 허브를 참고하세요.

16 GB GPU를 위한 짧은 답변

하나의 시퀀스, 현실적인 최대 컨텍스트, Flash Attention, 그리고 8-bit KV 캐시에서 시작하십시오. 4-bit 캐시, CPU 오프로드, 여러 병렬 슬롯, 또는 실험적 포크를 시도하기 전에 해당 설정을 측정하십시오.

제 견해는 단순합니다: OOM(메모리 부족) 실패의 경계에서 작동하는 명목상의 128K 설정보다 안정적인 64K 설정이 보통 더 유용합니다. 컨텍스트 용량은 트로피가 아니라, 지연 시간, 품질, 동시 처리성에 대한 결정입니다.

KV 캐시는 무엇을 저장하는가

자동 회귀 생성(autoregressive generation) 동안, 모든 attention 레이어는 처리된 각 토큰에 대해 키(key)와 밸류(value) 텐서를 생성합니다. 런타임은 이전 토큰에 대해 전체 prefix를 다시 계산하지 않고 다음 토큰이 attend할 수 있도록 해당 텐서를 유지합니다.

캐시는 막대한 계산 비용을 절감하지만, 유지되는 토큰 수에 비례하여 메모리를 소비합니다. 그룹 쿼리 어텐션(grouped-query attention)을 사용하는 전통적인 트랜스포머에 대해 유용한 베이스라인은 다음과 같습니다:

KV bytes = sequences * tokens * layers * 2 * KV heads * head dimension * bytes per value

계수 2는 키와 밸류를 나타냅니다. 멀티 헤드 어텐션(Multi-head attention)은 쿼리 헤드와 동일한 수의 KV 헤드를 사용하며, 그룹 쿼리 어텐션은 더 적은 수의 KV 헤드를 사용합니다. 그리고 멀티 헤드 잠재 어텐션(Multi-head latent attention) 또는 하이브리드 순환 아키텍처는 다른 계산이 필요합니다.

왜 파라미터 개수만으로는 부족한가

두 8B 모델은 KV 캐시 비용이 매우 다를 수 있습니다. 하나는 32개의 레이어와 8개의 KV 헤드를 사용할 수 있고, 다른 하나는 더 적은 수의 KV 헤드, 공유 KV 레이어, 슬라이딩 윈도우 어텐션, 또는 압축된 잠재 상태를 사용할 수 있습니다.

파라미터 개수는 주로 웨이트 메모리를 예측합니다. KV 기하학은 attention 아키텍처에서 나오므로, 8B, 27B, 또는 GGUF 파일 크기에서 추측하기보다 모델 메타데이터를 읽어보십시오. 가장 명확한 설명은 어텐션 설계가 단순한 멀티 헤드 어텐션(MHA)을 벗어나 얼마나 이동했는지입니다:

• 멀티 쿼리 어텐션 (Multi-Query Attention, MQA): 모든 쿼리 헤드가 단일 K/V 헤드를 공유합니다 — 최대의 캐시 절약을 제공하지만, 가장 공격적인 품질 타협이며 현재 프론티어 모델에서 단독으로 사용되는 경우는 드뭅니다.
• 그룹 쿼리 어텐션 (Grouped-Query Attention, GQA): 쿼리 헤드를 클러스터로 묶어 각각이 하나의 K/V 헤드를 공유합니다 — 대부분의 오픈 소스 dense 모델이 사용하는 주류 타협이며, 위 공식이 가정한 기하학입니다.
• 멀티 헤드 잠재 어텐션 (Multi-Head Latent Attention, MLA): DeepSeek-V2에서 도입되어 DeepSeek-V3와 Kimi K2로 이어졌습니다. 완전히 다른 접근 방식을 취합니다: 헤드를 가로질러 K/V를 공유하는 대신, 키와 밸류를 압축된 저랭크(low-rank) 잠재 벡터로 투영하고, attention 시점에 온디맨드로 전체 해상도의 K/V를 재구성합니다. DeepSeek는 동등한 크기의 dense MHA 모델에 대해 대략 93%의 KV 캐시 감소를 보고했으며, 동일한 메모리 예산에서 GQA와 경쟁적이거나 때로는 앞서는 품질을 유지했습니다.

실용적인 결과는 “27B GQA 모델"과 “27B MLA 모델"은 동일한 컨텍스트 길이에 대해 KV 캐시 footprint가 10배 차이가 날 수 있다는 것입니다. 위 공식이 잠재 어텐션, DeltaNet 스타일 상태, 또는 슬라이딩 윈도우 레이어를 사용한다고 문서화된 모델에 적용된다고 가정하지 마십시오. 먼저 모델 카드의 아키텍처 섹션을 확인하십시오.

Ollama의 경우, ollama show MODEL --verbose는 포맷이 이를 제공하면 레이어 수, 어텐션 헤드, KV 헤드, 컨텍스트 길이를 포함한 모델 메타데이터를 노출합니다. llama.cpp의 경우, 시작 시 출력되는 모델 로더 출력은 동등한 GGUF 메타데이터와 런타임의 실제 캐시 할당을 보통 포함합니다.

모델 한계, 할당된 컨텍스트, 사용된 컨텍스트

이것은 세 가지 별개의 숫자입니다. 모델 한계는 그 훈련과 위치 인코딩이 지원하는 최대치이고, 할당된 컨텍스트는 런타임이 예약하거나 허용하는 것이며, 사용된 컨텍스트는 현재 시퀀스를 위해 유지되는 토큰입니다.

엔진 플래그를 높이는 것은 모델을 지원되는 위치 스킴을 넘어 안전하게 확장할 수 없습니다. RoPE 스케일링은 일부 아키텍처를 확장할 수 있지만, 이는 모델 품질 실험이지 KV 메모리 최적화가 아닙니다.

KV 캐시 크기 테이블: 32K, 64K, 128K 컨텍스트 예산

32개의 레이어, 8개의 KV 헤드, 128의 헤드 차원을 가진 대표적인 GQA 모델을 고려해 보겠습니다. 이 차원들은 각 요소의 저장 크기로 곱하기 전에 토큰당 65,536개의 키와 밸류 요소를 생성합니다.

해당 테이블은 2진 GiB와 llama.cpp의 f16, q8_0, q4_0과 일반적으로 연관된 물리적 블록 크기를 사용합니다. 이는 전체 프로세스 메모리에 대한 약속이 아닌, 베이스라인 계산입니다; 정렬(Alignment), 메타데이터, 하이브리드 레이어, 백엔드 워크스페이스는 오버헤드를 추가합니다.

이제 다른 차원은 그대로 두면서 레이어 수를 64로 두 배로 늘려 보겠습니다. FP16 캐시는 32K에서 8 GiB, 64K에서 16 GiB, 128K에서 32 GiB가 되며, 이는 왜 단일 컨텍스트 권장 사항이 모든 모델을 커버할 수 없는지를 보여줍니다.

실제 16 GB 방정식

실용적인 예산은 KV 공식보다 더 광범위합니다:

usable VRAM = total VRAM - desktop and driver reserve

KV budget = usable VRAM
          - GPU-resident model weights
          - graph and activation buffers
          - runtime workspace
          - speculative-decoding state
          - safety margin

디스플레이에 연결된 16 GB 카드에서, 16 GiB 전체가 사용 가능하다고 계획하지 마십시오. 데스크톱과 드라이버를 위해 적어도 수백 MiB를 예약하고, 워크로드에 의존적인 버퍼를 위해 또 다른 마진을 남겨 두십시오. 총 1.0에서 1.5 GiB의 여유 공간은 합리적인 시작 가정이지만, 당신의 로그가 최종 결정권자입니다.

GGUF 모델이 GPU에서 10.8 GiB를 차지하고 런타임 오버헤드가 약 1.2 GiB까지 치솟는다고 가정해 보십시오. 1 GiB의 안전 마진 후, KV를 위해 약 3 GiB만 남으므로, 엔진-specific 오버헤드 전에 대표 모델은 Q8_0으로 약 45K 토큰 또는 Q4_0으로 87K를 처리합니다.

그것이 자동으로 Q4_0이 정답이라는 것을 의미하지는 않습니다.如果你的 워크로드에서 장문 컨텍스트 정확도가 떨어지면, Q8_0 캐시를 가진 더 작거나 더 공격적으로 양자화된 모델이 취약한 캐시와 짝지어진 더 큰 웨이트보다 나을 수 있습니다. 정확히 이 산술을 위한 측정 앵커는 16 GB VRAM llama.cpp 벤치마크 테이블에 있으며, 모델별 VRAM이 19K, 32K, 64K 컨텍스트에서 기록되어 있습니다. 동일한 클래스의 카드에서 Ollama 하에 어떤 모델 크기와 양자화 레벨이 잘 작동하는지에 대한 더 넓은 조사를 보려면, Ollama 16GB VRAM GPU에서 LLM 성능 비교를 참조하십시오.

나만의 모델에 대한 KV 캐시 예산 계산하기

다음 파이썬 스니펫은 전통적인 풀 어텐션 GQA 캐시를 추정합니다. 기하학을 모델 구성 또는 GGUF 메타데이터의 값으로 교체하십시오.

def kv_gib(tokens, layers, kv_heads, head_dim, bytes_per_value, sequences=1):
    total = (
        sequences
        * tokens
        * layers
        * 2
        * kv_heads
        * head_dim
        * bytes_per_value
    )
    return total / (1024 ** 3)


model = {
    "layers": 32,
    "kv_heads": 8,
    "head_dim": 128,
}

types = {
    "f16": 2.0,
    "q8_0": 34 / 32,
    "q4_0": 18 / 32,
}

for tokens in (32768, 65536, 131072):
    row = {
        name: round(kv_gib(tokens=tokens, bytes_per_value=size, **model), 2)
        for name, size in types.items()
    }
    print(tokens, row)

Q8_0과 Q4_0의 비율은 단순한 블록 메타데이터를 포함하므로, 값당 정확히 1바이트와 반 바이트보다 약간 더 큽니다. 런타임의 시작 보고서는 모델-specific 캐시 레이아웃을 알고 있으므로 여전히 더 정확합니다.

이 공식이 잘못된 경우: 하이브리드 및 슬라이딩 윈도우 아키텍처

하이브리드 아키텍처를 전통적인 GQA 방정식에 억지로 끼워 맞추지 마십시오. 슬라이딩 윈도우 레이어는 최근 윈도우만 유지하고, 공유 KV 레이어는 중복을 줄이며, 순환 레이어는 고정 크기 상태를 유지할 수 있고, 멀티 헤드 잠재 어텐션은 헤드별 K/V 텐서 대신 압축된 표현을 저장합니다 — 위에서 MLA의 사례가 가장 극적인 예입니다.

최신 엔진은 이러한 혼합 레이아웃을 점점 더 명시적으로 관리합니다. 공식을 우세한 항을 설명하는 데 사용하고, 배포하려는 정확한 엔진 빌드와 백엔드가 보고하는 할당을 확인하십시오.

llama.cpp: K와 V 정밀도의 직접 제어

llama.cpp는 현재 인자 파서에서 --cache-type-k와 --cache-type-v 옵션을 분리하여 노출합니다. 이는 캐시 정밀도와 컨텍스트 용량 사이에서 타협해야 할 때 하나의 글로벌 프리셋을 수용하는 대신 가장 유용한 로컬 추론 인터페이스입니다. 먼저 주위 설치 및 서빙 설정이 필요하다면, llama.cpp 가이드가 llama-cli, llama-server, 주요 VRAM 플래그를 다룹니다.

보수적인 64K 단일 사용자 설정은 다음과 같습니다:

./llama-server \
  --model /models/model.gguf \
  --n-gpu-layers 999 \
  --ctx-size 65536 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --batch-size 1024 \
  --ubatch-size 256

플래그 문법과 백엔드 지원은 빠르게 변하므로, 설치된 빌드에 대해 llama-server --help를 실행하십시오. 더 중요하게, 시작 로그를 검토하십시오: 의도된 컨텍스트, 캐시 타입, GPU 오프로드, 할당된 K와 V 버퍼가 표시되어야 합니다.

어떤 llama.cpp 캐시 타입을 시도해야 하는가

K와 V 모두 Q8_0으로 시작하십시오. 이는 F16에 비해 KV 메모리를 대략 절반으로 줄이며, 20B 이상 모델(Qwen3.6-27B, Nemotron-30B)에 대한 독립적인 퍼플렉시티 테스트는 F16과의 총체적인 품질 차이가 측정 잡음 범위 내에 있음을 보여줍니다 — Q4_0으로 직접 이동하는 것보다 덜 극적인 도박으로, 동일한 테스트는 작은 모델에서 장문 컨텍스트에서 디코딩 속도와 정확도가 붕괴됨을 보여주었습니다.

Q8_0이 맞지 않는다면, 양쪽을 모두 Q4_0으로 양자화하기 전에 Q8_0 키와 Q4_0 밸류를 테스트하십시오. 이 순서는 folklore뿐만 아니라 연구의 뒷받침을 받고 있습니다: Llama, Phi-4, Qwen3, Mistral 체크포인트에 대한 통제된 비트 할당 연구는 키 텐서가 밸류 텐서보다 일관되게 2배에서 10배 더 양자화 오류에 민감하고, 키에 더 큰 비트 예산을 주는 것(예: 2-bit 밸류와 함께 4-bit 키)은 완전 정밀도의 정확도의 94–98%까지 회복할 수 있지만, 반대 분할(2-bit 키, 4-bit 밸류)은 GSM8K와 같은 작업에서 30%p(백분점)를 잃을 수 있음을 발견했습니다. 키는 어텐션이 실제로 매칭하는 이전 토큰을 결정하므로, 그것들을 우선 보호하는 것이 더 안전한 소리가 나기 때문이 아니라 아키텍처적으로 타당한 선택입니다.

내재화할 가치가 있는 한 가지 주의 사항: 집계 벤치마크에서 “낮은 품질 위험"은 토큰 레벨에서 제로 위험을 의미하지 않습니다. Flash Attention을 일정하게 유지하고 그리디(결정론적) 디코딩 하에 KV 정밀도만 변경한 통제된 테스트는, Q8_0 캐시가 대다수의 프롬프트에서 생성된 정확한 텍스트를 변경했고, Q4_0은 본질적으로 모든 프롬프트에서 이를 변경했으며 — 한 번 토큰이 뒤집히면 나머지 연속 생성이 분기될 수 있음을 발견했습니다. 퍼플렉시티와 다운스트림 작업 점수는 평균적으로 괜찮아 보일 수 있지만, 개별 출력은 여전히 F16 베이스라인과 다를 수 있습니다. 애플리케이션이 바이트 단위 재현 가능성(회귀 테스트, 캐시된 응답, 결정론적 에이전트)이 필요하다면, KV 양자화를 단순히 메모리 최적화가 아닌 행동 변경으로 취급하고, 나만의 고정 프롬프트 세트에 대해 검증하십시오.

양자화 V 캐시는 Flash Attention 또는 호환 백엔드 경로를 필요로 할 수 있습니다. 다른 타입으로 조용히 폴백하는 서버는 실험을 무효화하므로, 시작 로그가 복사된 명령줄보다 더 중요한 이유입니다.

컨텍스트, 병렬 슬롯, 통합 캐시

--ctx-size는 엔진 용량을 설명하며, 모든 병렬 슬롯이 독립적으로 그 수만큼의 토큰을 받는다는 보장ではありません. llama.cpp에서 캐시 관리가 진화했으며, 통합 캐시(unified-cache) 행동을 포함하므로, 단순히 컨텍스트를 슬롯 수로 나누는 오래된 규칙에 의존하기보다 정확한 빌드를 테스트하십시오.

용량 방정식은 여전히 구현 변경을生き延びます: 동시 고유 토큰은 어딘가에 저장소가 필요합니다. 두 에이전트 세션이 각각 48K에 도달할 수 있다면, 워크로드가 prefix를 공유하거나 evict 및 재계산을 허용하지 않는 한, 약 96K의 라이브 토큰을 예산하십시오.

배치 크기는 저장된 KV를 줄이지 않음

--batch-size와 --ubatch-size는 프롬프트 처리와 임시 메모리에 영향을 미칩니다. 이것들을 낮추면 활성화 메모리 스파이크로부터 대규모 prefill을 구할 수 있지만, 각 유지된 토큰에 필요한 영속 바이트는 변경하지 않습니다.

이 구별은 일반적인 실패 패턴을 설명합니다: 모델이 시작되고 빈 요청은 작동하지만, 60K 프롬프트는 ingesting 중 실패합니다. 임시 피크를 진단하기 위해 마이크로-배치를 줄이십시오; 영속 용량을 변경하려면 컨텍스트, 캐시 정밀도, 병렬성, 또는 웨이트 거주지를 줄이십시오.

vLLM: Paged 용량도 여전히 용량임

vLLM은 이를 서빙 엔진으로 접근합니다. 사용 가능한 메모리를 프로파일링하고, KV 캐시 풀을 예약하며, 캐시를 블록으로 할당하여 동시 시퀀스가 각각 하나씩의 큰 연속 영역을 요구하지 않도록 합니다. vLLM으로의 전환 자체를 결정하고 있다면, Ollama에서 vLLM으로의 마이그레이션 가이드가 워크로드 신호를 다룹니다. 여기서 문제는 순수하게 풀이 얼마나 많은 캐시를 보유할 수 있는지에 관한 것이며, vLLM 퀵스타트가 아래 용량 레버를 넘어 설치와 일반 서빙 플래그를 다룹니다.

PagedAttention은 가변 시퀀스 길이를 둘러싼 단편화와 낭비를 줄입니다 — paged 할당은 단편화를 제거할 뿐, 토큰당 저장 비용을 제거하지는 않으므로, 하나의 고유한 128K 요청은 여전히 그 KV 상태를 위한 충분한 블록이 필요합니다.

공식 vLLM 메모리 절약 가이드는 메모리가 타이트할 때 max_model_len과 max_num_seqs를 제한할 것을 권장하며, CUDA 그래프가 추가적인 GPU 메모리를 소비한다고 언급합니다. 16 GB 카드에서, 두 설정 모두 모델의 최대 구성에서 상속된 것이 아니라 의도적으로 설정되어야 합니다.

집중된 단일 시퀀스 서버는 여기서부터 시작할 수 있습니다:

vllm serve MODEL_ID \
  --max-model-len 65536 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching

모든 16 GB GPU, 모델, 양자화 방법, 또는 어텐션 백엔드가 그 정확한 조합을 지원하지는 않습니다. 이를 설정 형태로 취급하십시오: 길이와 동시성을 제약하고, 여유 공간을 예약하고, 지원되는 캐시 dtype을 선택하고, 초기화 보고서를 검증하십시오.

vLLM의 FP8 KV 캐시

현재 vLLM 양자화 KV 캐시 문서는 호환되는 CUDA 및 ROCm 경로에서 FP8 캐시 포맷을 지원합니다. FP8은 BF16 또는 FP16에 비해 원본 캐시 저장 공간을 대략 절반으로 줄일 수 있으므로 토큰 용량이나 동시성을 증가시킬 수 있습니다.

스케일링이 중요합니다. 문서는 기본 스케일, 워밍업 계산, 데이터셋 캘리브레이션을 구별하며, 가장 높은 정확도를 위해 데이터셋 기반 캘리브레이션을 권장합니다; 단순히 scale 1.0으로 FP8을 설정하는 것은 편리하지만 자동으로 가장 신뢰할 수 있는 품질 선택은 아닙니다.

Prefix Caching은 재사용 최적화임

자동 prefix 캐싱은 새 요청이 동일한 캐시된 prefix에 대해 KV 블록을 재사용하게 합니다. 동일한 긴 문서에 대한 반복 조회, 공유 시스템 프롬프트, 다중 라운드 대화에 훌륭하며, 매칭되는 prefill을 다시 계산하는 것을 피하기 때문입니다.

독창적인 긴 요청을 더 작게 만들지 않으며, 새 토큰의 생성을 가속하지도 않습니다. vLLM prefix-caching 문서는 그 이익을 명시적으로 공유-prefix prefill 작업으로 제한합니다.

GPU 메모리 활용도는 무료 메모리가 아님

--gpu-memory-utilization을 높이면 vLLM에게 더 큰 예약 목표를 제공하지만, VRAM을 생성하지는 않습니다. 1.0에 너무 가깝게 밀면 디스플레이, 다른 프로세스, 변하는 활성화 피크, 또는 PyTorch가 아닌 할당을 위한 공간이 부족해질 수 있습니다.

전용 16 GB GPU에서 0.88에서 0.92 정도에서 시작하고, 프로파일을 검사하고, 워크로드가 안정적이지 한해서만 증가시키십시오. 초기화가 성공하지만 실제 프롬프트가 실패하면, 할당자가 고장 나 있다고 가정하기 전에 배치된 토큰, 시퀀스 동시성, CUDA 그래프 캡처, 또는 최대 컨텍스트를 줄이십시오.

Ollama: 더 쉬운 제어, 덜 세밀한 진단

Ollama는 의도적으로 더 작은 운영 표면을 제공합니다. 현재 컨텍스트 길이 문서는 24 GiB 미만의 GPU를 기본 4K 컨텍스트로 설정하며, 에이전트 및 코딩 워크로드에 최소 64K를 권장하고, 더 큰 컨텍스트가 더 많은 메모리를 소비한다고 경고합니다.

서버 전체 기본값을 설정하고 로드된 모델을 다음과 같이 확인하십시오:

OLLAMA_CONTEXT_LENGTH=65536 ollama serve

ollama ps

요청별 또는 모델별로 num_ctx를 설정할 수도 있습니다. ollama ps는 중요하며, 그 PROCESSOR와 CONTEXT 열은 모델이 GPU에 완전히 남아 있는지, 요청된 컨텍스트가 실제로 할당되었는지를 보여주기 때문입니다. 그 숫자 뒤의 스케줄링 행동을 주의하십시오; Ollama 버전 사이에서 변경되었습니다. Ollama v0.12.1 메모리 할당 비교는 새 스케줄러가 16 GB 카드에서 일부 모델을 CPU로 더 밀어내는 것을 보여주므로, 측정하신 버전을 고정하십시오.

Ollama의 양자화 KV 캐시

Ollama는 현재 FAQ에서 f16, q8_0, q4_0 옵션과 함께 OLLAMA_KV_CACHE_TYPE을 노출합니다. 양자화 KV는 Flash Attention을 필요로 하며, Ollama는 지원되는 백엔드에서 자동으로 사용하거나 OLLAMA_FLASH_ATTENTION=1로 요청할 수 있습니다.

따라서 16 GB 장문 컨텍스트 서비스는 다음과 같이 시작할 수 있습니다:

OLLAMA_CONTEXT_LENGTH=65536 \
OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
OLLAMA_NUM_PARALLEL=1 \
ollama serve

Q8_0은 Ollama가 F16의 권장 대안으로 제시합니다. FAQ는 Q4_0이 더 눈에 띄는 품질 손실을 유발할 수 있으며, 특히 컨텍스트가 높을 때 그렇다고 경고하므로, 자동적인 16 GB 프리셋이 아니라 측정된 폴백이어야 합니다.

Ollama 병렬성은 컨텍스트 예산을 곱셈

Ollama는 특히 명확한 규칙을 문서화합니다: 필요한 메모리는 OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH에 비례하여 스케일링됩니다. 32K 설정에서 병렬 요청 4개는 해당 모델에 대해 128K의 집계 컨텍스트 할당을 의미할 수 있습니다.

16 GB 개인 에이전트에 대해, 하나의 긴 세션이 안정해질 때까지 OLLAMA_NUM_PARALLEL=1을 유지하십시오. 두 번째 요청을 큐에 넣는 것이 보통 첫 번째 모델을 일부 CPU로 밀어 넣고 두 요청을 모두 느리게 만드는 것보다 선호됩니다. 그 선택 이면의 큐잉, 503, 모델 언로딩 메커니즘은 Ollama가 병렬 요청을 처리하는 방법에 문서화되어 있습니다.

CPU 오프로드: 가격이 있는 유효한 탈출구

모델 레이어나 KV 상태의 일부가 시스템 RAM으로 이동하면 할당 실패를 작동하는 프로세스로 전환할 수 있습니다. 또한 PCIe 대역폭과 호스트 메모리 지연 시간을 디코딩 경로에 배치하며, 여기서 각 생성된 토큰이 그 비용을 지불할 수 있습니다. PCIe가 실제로 영향을 미칠 때의 레인 및 생성 증거는 LLM 성능과 PCIe 레인에 있습니다.

오프로드는 가끔적인 배치 작업에 합리적일 수 있지만, 대화형 코딩 에이전트의 가장 좋은 기본값은 거의 아닙니다. 먼저 더 작은 웨이트 양자화, Q8 KV, 줄어든 동시성, 현실적인 컨텍스트 상한을 비교하십시오; 용량이 지연 시간보다 더 중요할 때 오프로드를 사용하십시오.

평균이 아닌 절벽(cliff)을 관찰하십시오. 서버는 8K에서 빠르게 디코딩할 수 있지만, 작업 집합의 일부가 넘쳐나면 심각하게 느려질 수 있으므로, 빈 컨텍스트 토큰 비율만 보고하지 말고 32K, 64K, 의도된 최대치에서 벤치마크하십시오.

슬라이딩 윈도우 및 적응형 KV 캐시

슬라이딩 윈도우 어텐션은 선택된 레이어에 대해 최근 윈도우만 유지함으로써 예산을 변경합니다. 하이브리드 모델은 이러한 레이어를 가끔적인 글로벌 어텐션 또는 순환 상태와 결합할 수 있어, 평탄한 풀 컨텍스트 계산이 메모리를 상당하게 과대 추정하거나 잘못 배치할 수 있습니다.

최적화는 엔진가 레이어 패턴, evict 규칙, 위치, 그리고 모든 글로벌 토큰을 올바르게 이해해야 하는 모델 아키텍처의 일부이며, 결과 없이 적용할 수 있는 일반적인 스위치가 아닙니다.

적응형 KV가 개선하려는 것

실험적 포크는 레이어별 및 컨텍스트 깊이별로 캐시 정밀도 또는 레이아웃을 선택함으로써 더 나아갑니다. 목표는 매력적입니다: 중요한 곳에서 더 높은 정밀도를 유지하고, 덜 민감한 레이어를 압축하고, VRAM 압력이 하드 스피일을 일으키기 전에 믹스를 변경합니다 — 위에서 설명된 키 민감성이 밸류 민감성보다 우세하다는 발견은 정확히 적응형 할당기가 자동으로 활용하기를 원하는 신호의 종류이며, 수동 --cache-type-k/--cache-type-v 튜닝에 맡기는 대신입니다.

2026년 8월의 다운스트림 프로젝트 중 하나인 llama.cpp-adaptive-turboquant은 몇몇 레이어-적응형 모드에 대한 자동 선택기를 보고하며, RTX 5080 16 GB에서 장문 깊이 테스트를 게시합니다. 이 수치는 전문 포크의 저자 보고된 결과이며, upstream llama.cpp가 동일한 방식으로 작동한다는 증거가 아닙니다.

왜 여전히 실험적인가

해당 포크는 사용자 지정 캐시 타입, CUDA 커널, 모델-specific 경로, 그리고 도구 체인 제약을 결합합니다. 이는 F16에서 Q8_0으로 upstream 캐시 스토리지를 전환하는 것보다 훨씬 더 많은 코드를 신뢰해야 함을 의미합니다.

upstream이 실제 요구 사항을 충족할 수 없고, 나만의 모델에서 품질, 안정성, 속도를 재현할 수 있을 때만 그러한 포크를 사용하십시오. 커밋과 CUDA 버전을 기록하십시오, 결과의 유일한 연결이 프로젝트 이름에만 있으면 재현 불가능하기 때문입니다.

공정한 적응형 캐시 테스트

포크를 동일한 GGUF, 프롬프트, 샘플러, 컨텍스트 깊이, 출력 길이와 함께 upstream Q8_0 베이스라인과 비교하십시오. 시작 VRAM, 피크 prefill VRAM, 프롬프트 처리 속도, 디코딩 속도, 그리고 컨텍스트의 가장 오래된 부분에서 증거가 실제로 필요한 품질 작업을 측정하십시오.

성공적인 할당을 완전한 결과로 받아들이지 마십시오. 캐시는 128K에 맞을 수 있지만, 초기 사실은 잃을 수 있고, 시퀀스의 후반에서 출력을 손상시키거나, 유용할 정도로 빠르게 디코딩하지 못할 수 있습니다.

적용된 16 GB 튜닝 절차: 한 번에 하나의 변수

안정적인 설정으로 가는 가장 빠른 방법은 메모리 차원을 한 번에 하나씩 변경하는 것입니다. 캐시 타입, 배치 크기, 레이어 오프로드, 병렬성, 컨텍스트를 무작위로 함께 변경하면 설명 없는 작동 명령만 생성됩니다.

Step 1: 웨이트 바닥(Establish the Weight Floor) 확립

모델을 8K 컨텍스트, 시퀀스 1개, 의도된 GPU 오프로드로 로드하십시오. 워밍업 후 프로세스 VRAM을 기록하고, 레이어가 의도치 않게 CPU로 이동하지 않았는지 확인하십시오.

웨이트와 런타임이 이미 약 14.5에서 15 GiB보다 더 많이 소비한다면, 장문 컨텍스트에는 건강한 마진이 없습니다. 캐시를 튜닝하기 전에 더 작은 웨이트 양자화나 모델을 선택하십시오.

Step 2: F16 또는 BF16 KV를 품질 베이스라인으로 측정

테스트를 지원할 수 있는 가장 작은 컨텍스트를 실행하고 기본 높은 정밀도 캐시를 유지하십시오. 검색, 코드 편집, 도구 선택, 장문 지시 작업에서 출력을 저장하십시오.

이 베이스라인은 나중에 오류가 캐시 양자화에서 오는지 알려줍니다. 이것 없이는, 채팅 템플릿 문제나 약한 모델이 쉽게 Q4 KV 탓으로 돌릴 수 있습니다.

Step 3: Q8 또는 FP8으로 이동

필요한 곳에서 Flash Attention을 활성화하고, llama.cpp 또는 Ollama에서 Q8_0을 선택하거나, vLLM에서 지원되는 FP8 모드를 선택하십시오. 동일한 토큰 깊이에서 동일한 프롬프트를 반복하고, 로그가 의도된 캐시 타입을 표시하는지 확인하십시오.

많은 16 GB 배포에서, 이것이 유용한 정지점입니다. 캐시 압축을 스택에서 가장 공격적인 양자화로 만들지 않으면서 원본 KV 용량을 대략 두 배로 증가시킵니다.

Step 4: 컨텍스트를 단계별로 높이

광고된 최대치로 직접 건너뛰지 말고 32K, 64K, 96K, 128K를 테스트하십시오. 각 단계에서, 초당 프롬프트 처리 토큰, 초당 디코딩 토큰, 피크 VRAM, 그리고 시작 부분 근처의 증거가 여전히 복구될 수 있는지 기록하십시오.

메모리가 맞더라도 장문 컨텍스트 디코딩은 어텐션이 더 많은 캐시된 상태를 읽기 때문에 종종 느려집니다. 용량과 성능은 별개의 축입니다.

Step 5: 임시 메모리 튜닝

초기화 대신 prefill 중 실패가 발생하면, 마이크로-배치 또는 최대 배치 토큰을 줄이십시오. 실패가 동시 요청에서만 발생하면, 시퀀스 동시성 또는 병렬 슬롯을 줄이십시오.

그 제어들을 이해한 후에만 혼합 Q8/Q4 캐시, 전체 Q4 캐시, CPU 오프로드, 또는 적응형 포크를 시도하십시오. upstream Q8 실행을 비교 베이스라인으로 유지하십시오. 나중에 스펙ulative 디코딩이나 MTP를 추가한다면, 그 드래프트 버퍼가 예산 방정식의 또 다른 행이며 무료 속도가 아니라는 것을 기억하십시오 — 스펙ulative 디코딩 가이드가 메커니즘과 VRAM 비용을 다루고, 제 Qwen 3.6 27B와 35B MTP vs Standard 벤치마크는 16 GB 카드에서 MTP 헤드의 추가 상태가 얼마나 컨텍스트를 비용으로 만들 수 있는지를 정확히 보여줍니다.

장문 컨텍스트 벤치마크에서 기록할 것

단일 tokens/s 수치는 이 기사가 해결하려고 하는 정확한 문제를 숨깁니다. 장문 컨텍스트 테스트는 다른 운영자가 메모리 경계를 재현할 수 있도록 충분한 디테일을 보존해야 합니다.

prefill과 디코딩 동안 nvidia-smi 샘플링 또는 동등한 벤더 도구 사용을 사용하십시오. 엔진의 할당 보고서는 필수적이지만, 실제 프롬프트 동안 피크 디바이스 메모리가 안정성을 결정하는 숫자입니다.

16 GB GPU에서 일반적인 KV 캐시 실수

128K 지원을 하드웨어 약속으로 취급

모델 구성의 컨텍스트 필드는 아키텍처 한계입니다. 그것은 특정 엔진에서 특정 양자화를 로드한 후 남은 메모리에 대해 아무것도 말하지 않습니다.

캐시를 계산하고 런타임을 검증하십시오. 마케팅-sized 컨텍스트는 VRAM 예산이 없으면 단순히 첫 번째 심각한 프롬프트까지 OOM이 지연된 것에 불과합니다.

웨이트는 양자화하지만 KV는 잊는

4-bit GGUF는 모델 웨이트를 줄이지, F16 KV 캐시를 줄이지 않습니다. 장문 컨텍스트에서, 캐시는 전체 절약을 지우고 결국 웨이트 footprint를 초과할 수 있습니다.

두 양자화를 모두 보고하십시오. Q4_K_M model, Q8_0 KV는 의미 있습니다; 4-bit model은 불완전합니다.

Paged Attention이 토큰을 압축한다고 가정

Paging은 할당과 공유 행동을 개선합니다. 그것은 텐서 정밀도를 변경하지도 않고, 하나의 고유 시퀀스가 요구하는 KV 상태를 제거하지도 않습니다.

Paged 할당을 사용하여 가변 워크로드를 효율적으로 서빙하십시오. 용량을 제어하려면 캐시 정밀도, 모델 아키텍처, 컨텍스트 상한, 동시성 제한을 사용하십시오.

Prefix Caching이 모든 긴 프롬프트에 도움이 된다고 가정

Prefix 캐싱은 요청이 정확한 prefix를 공유할 때 반복된 prefill 계산을 절약합니다. 100K 저장소 덤프는 prefix 캐싱이 활성화되었기 때문에 마법적인 메모리 할인 없이도 1회성으로 제공됩니다.

이것은 워크로드 최적화이지, 예산 방정식의 대체재가 아닙니다. 멀티-유저 서빙에서 히트 레이트와 유지된 캐시 압력을 측정하십시오.

품질 테스트 없이 Q4 KV 사용

저비트 캐시는微妙하게 실패할 수 있습니다. 모델은 여전히 유창한 텍스트를 작성하지만, 먼 증거, 정확한 이름, 도구 인자, 또는 코드 의존성에 대한 어텐션이 열화될 수 있습니다 — 그리고 위 토큰 분기 연구가 보여주듯, 결정론적 디코딩 하에서 “안전한” Q8_0 설정조차 정확한 F16 출력을 재현할 것이라고 보장되지 않으며, 집계에서 정확성을 보존하는 것에 불과합니다.

목표 깊이에 대해 목표 작업을 테스트하십시오. 짧은 채팅 벤치마크는 장문 컨텍스트 캐시를 검증하는 데 거의 무용합니다.

병렬성을 Auto로 둔 채 두기

엔진是通过 처리량을 위해 합리적이지만 나만의 장문 컨텍스트 목표에는 불가능한 동시성을 선택할 수 있습니다. 16 GB에서, 하나의 깊은 시퀀스와 여러 짧은 시퀀스는 근본적으로 다른 워크로드입니다.

제한을 명시적으로 설정하고, 측정된 트래픽으로 점차 높여가십시오. 그렇지 않으면 두 번째 요청이 안정적인 64K 설정을 할당 또는 지연 시간 놀이로 바꿀 수 있습니다.

권장 16 GB 프로파일

이러한 프로파일은 시작 위치이지 보편적 프리셋이 아닙니다. 특이한 KV 기하학 — 특히 MLA 또는 하이브리드 슬라이딩 윈도우 설계 — 을 가진 모델은 전통적인 GQA 예시보다 훨씬 더 저렴하거나 비쌀 수 있습니다.

대화형 코딩 에이전트

시퀀스 1개, 48K에서 64K 컨텍스트, Q8 캐시, Flash Attention, 그리고 가능하면 완전한 GPU 웨이트 거주지를 사용하십시오. 이 프로파일은 인상적이지만 드물게 유용한 최대치보다 예측 가능한 지연 시간과 좋은 캐시 정밀도를 선호합니다.

코딩 턴이 대개 큰 저장소 또는 대화 prefix를 공유하므로 엔진이 지원하면 prefix 재사용을 활성화하십시오. 여전히 도구 출력과 오래된 트랜스크립트를 압축하십시오; 캐시 엔지니어링이 관련 없는 토큰을 가치 있게 만들지는 않습니다.

장문 문서 분석

더 작은 모델과 64K에서 128K 용량, Q8 또는 캘리브레이션된 FP8 캐시, 그리고 여러 질문이 동일한 문서를 대상으로 할 때 반복 prefix 캐싱을 사용하십시오. 디코딩이 여전히 허용 가능하더라도 prefill이 지배할 수 있으므로 첫 토큰까지의 시간(Time to first token)을 측정하십시오.

오직 하나만 질문할 것이라면, 16 GB 카드를 통해 전체 코퍼스를 밀어 넣는 것보다 검색 또는 청크된 요약이 더 빠르고 신뢰할 수 있을 수 있습니다. 장문 컨텍스트는 도구이지, 정보 아키텍처의 대체재가 아닙니다.

소형 멀티-유저 서버

모델 최대치를 모든 클라이언트에게 광고하기보다, 요청별 컨텍스트와 총 활성 시퀀스를 상한으로 설정하십시오. vLLM의 paged 할당은 여기서 유용하며, Ollama와 llama.cpp도 집계 라이브 토큰에 대한 명시적인 주의를 요구합니다.

무통제 스피일보다 큐잉을 선호하십시오. 느린 입원 정책이 모든 요청이 갑자기 디코딩 중 PCIe를 건너는 것보다 덜 손상적입니다.

16 GB 장문 컨텍스트를 위한 최종 권장 사항

16 GB에서 장문 컨텍스트를 위해, Q8 KV와 활성 시퀀스 1개가 올바른 베이스라인입니다.它们是 저비트 캐시 품질, 병렬 할당, 오프로드 지연 시간이 한 번에 실패하지 않도록 실제 한계를 노출합니다.

어텐션 기하학에서 계산하고, 웨이트와 런타임 오버헤드를 뺀 후, 그리고 엔진 로그와 피크 메모리 측정에서 결과를 확인하십시오. 128K가 여전히 맞지 않는다면, 더 작은 모델이 종종 가장 깔끔한 최적화입니다; 맞지만 기어간다면, 컨텍스트를 줄이는 것이 종종 정직한 선택입니다.

Paged 어텐션, prefix 캐싱, 슬라이딩 윈도우, 적응형 정밀도는 모두 유용하지만 다른 문제를 해결합니다. 승리하는 설정은 GPU에 남아 있고, 오래된 증거를 올바르게 검색하며, 실제로 사용하는 컨텍스트 깊이에서 허용 가능한 디코딩 속도를 유지하는 것입니다.

참고 문헌

• vLLM: conserving GPU memory
• vLLM: quantized KV cache (FP8)
• vLLM: automatic prefix caching
• Ollama: context length documentation
• Ollama FAQ: OLLAMA_KV_CACHE_TYPE and Flash Attention
• llama.cpp-adaptive-turboquant — 실험적 레이어-적응형 캐시 포크 (저자 보고된 결과)
• Raschka, S. “Multi-Head Latent Attention (MLA).” LLM Architecture Gallery. https://sebastianraschka.com/llm-architecture-gallery/mla/
• “Decoding Multi-Head Latent Attention: The KV Cache Memory Bottleneck, Solved.” Vizuara. https://vizuara.substack.com/p/decoding-multi-head-latent-attention
• “Quantize What Counts: Bit Allocation Insights Informed by Spectral Gaps in Keys and Values.” arXiv:2502.15075. https://ar5iv.labs.arxiv.org/html/2502.15075
• v-code01. “kvdivergence — does KV cache quantization change the generated text under greedy decoding?” GitHub. https://github.com/v-code01/kvdivergence
• Ollama 16GB VRAM GPU에서 LLM 성능 비교
• 16GB GPU에서 Qwen 3.6 27B와 35B MTP vs Standard