6장. 컨텍스트와 KV Cache

이 장의 목표 “컨텍스트 길이가 128K” “32K context window” 같은 표기를 정확히 읽게 됩니다.

그리고 왜 긴 문서를 넣으면 갑자기 느려지는지, 그 정체를 알게 됩니다.

6.1 컨텍스트 윈도우 = 모델의 “단기 기억”

모델은 한 번에 볼 수 있는 토큰 양이 정해져 있습니다.

이걸 컨텍스트 윈도우(context window) 라고 합니다.

예를 들어 “컨텍스트 8K” 라면 이 안에 들어와야 할 게:

시스템 프롬프트       ← "너는 ~한 어시스턴트야"
+ 이전 대화 기록
+ 내가 방금 넣은 질문/문서
+ 모델이 만들 답변(생성 예정 토큰까지 포함)
─────────────────────
≤ 8,000 토큰

전부 합쳐서 8,000토큰을 넘으면 앞 내용이 잘려나가거나, 모델이 “이전 대화를 기억 못 함” 같은 일이 발생합니다.

컨텍스트는 “한 번의 대화에서 모델이 볼 수 있는 양” 입니다. 영구 기억이 아닙니다. 새 대화를 시작하면 다 잊습니다.

6.2 흔한 컨텍스트 길이

요즘 모델들의 표준입니다.

컨텍스트 = 클수록 좋다, 는 절대 아닙니다.

이유를 다음 절에서 봅니다.

6.3 KV Cache — 컨텍스트의 “메모리 비용”

모델은 답변을 한 토큰씩 만듭니다. 매 토큰을 만들 때마다 이전 토큰 전부를 다시 참고합니다.

그런데 매번 처음부터 계산하면 너무 느립니다.

그래서 이전 토큰들에 대한 계산 중간 결과를 메모리에 저장해둡니다.

이게 KV Cache 입니다.

(K, V는 Key, Value의 약자입니다. 이름은 외우지 않아도 됩니다.)

문제는 이것입니다.

KV Cache는 컨텍스트가 길어질수록 메모리를 더 잡아먹습니다.

거친 어림셈입니다.

(정확한 값은 모델 구조·양자화에 따라 달라집니다)

즉 컨텍스트를 키우는 건 공짜가 아닙니다. 모델 가중치 외에 별도 메모리 가 추가됩니다.

6.4 그래서 실제로 메모리 계산은?

4장 어림셈을 보강합니다.

실사용 메모리 ≈ 가중치 + KV Cache + 런타임 + 시스템

예시. 64GB 맥에서 32B Q4를 128K 컨텍스트로 돌리고 싶다면?

가중치 16GB
+ KV Cache 32GB
+ 런타임 4GB
+ 시스템 6GB
────────────
≈ 58GB

가능은 하지만 거의 한계입니다. 브라우저·IDE까지 켜놓으면 swap이 터집니다.

같은 모델을 16K 컨텍스트로 돌리면?

16 + 4 + 4 + 6 ≈ 30GB

훨씬 여유롭습니다.

결론 일반 대화나 코드 질문 정도면 16K~32K 면 충분합니다. 128K는 정말 필요할 때만.

6.5 Prefill vs Decode — 두 종류의 속도

긴 문서를 넣었을 때 느림에는 두 단계가 있습니다.

1단계: Prefill (입력 읽기)

내가 넣은 입력을 모델이 처음 통째로 읽어들이는 단계.

2만 토큰짜리 문서를 붙여넣음
       ↓
모델이 "이 2만 토큰을 다 읽어야" 답을 시작할 수 있음
       ↓
사용자 화면에서 보기엔 "한참 멈춰있는 시간"

이 시간이 prefill 시간 입니다.

2단계: Decode (답변 생성)

읽기를 마친 뒤 한 토큰씩 답을 뱉어내는 단계.

여기서 우리가 보는 초당 토큰 수(tokens/sec) 가 측정됩니다.

[Prefill: 8초]  [Decode: 첫 토큰부터 흐름]
████████░ → 안녕하세요. 회의록을 요약해드릴게요. ...

“이 모델 30 tokens/sec야” 라는 말은 거의 항상 decode 속도 입니다. Prefill 속도는 그것보다 보통 더 빠르지만, 입력이 크면 그 빠른 속도로도 시간이 꽤 걸립니다.

6.6 그럼 컨텍스트를 어떻게 잡아야 하나?

목적별 권장값입니다.

도구별 기본 컨텍스트

• Ollama: 메모리에 따라 자동으로 다르게 잡습니다. 64GB 맥이면 보통 32K~256K 사이로 시작합니다.
• LM Studio: 모델 로드 시 슬라이더로 직접 설정합니다. 처음에는 8K나 16K 권장.

도구별 설정 방법은 16~17장에서 다룹니다.

6.7 “긴 컨텍스트인데 왜 모델이 까먹지?”

128K 컨텍스트라고 표시된 모델이라도, 긴 입력을 주면 중간 내용을 놓치는 일이 자주 있습니다.

이를 “lost in the middle” 현상이라고 부릅니다.

입력:
  앞부분 (잘 기억함)
  ...
  중간 부분 (자주 잊음)   ← ★
  ...
  뒷부분 (잘 기억함)

원인은 단순합니다.

모델이 학습할 때 본 데이터는 대부분 짧은 글이었기 때문입니다.

긴 입력에서 핵심을 끝까지 잘 다루는 능력은 모델마다 편차가 큽니다.

이걸 측정하는 벤치마크가 따로 있습니다: Needle in a Haystack(NIAH) 같은 것들. 13장(벤치마크 읽는 법)에서 다시 봅니다.

이 장에서 기억할 한 가지

컨텍스트는 공짜가 아닙니다.

길게 잡으면 KV Cache 메모리가 그만큼 늘고, 긴 입력은 prefill 시간 도 길어집니다.

일반 업무라면 16K~32K 에서 시작하고, 정말 필요할 때만 늘리세요.

손으로 해볼 것

1. 컨텍스트 1K 차이가 만드는 KV Cache 차이 계산

내 후보 모델(예: 32B Q4)을 가정하고, 다음 컨텍스트에서 KV Cache 메모리를 어림셈 해보세요.

• 8K
• 32K
• 128K

각 경우 가중치 + KV Cache 합계가 내 맥 메모리의 몇 %인지 계산해보세요.

2. 토크나이저 사이트로 “내 회의록 한 편“이 몇 토큰인지 확인

평소에 자주 쓰는 회의록 한 편을 tiktokenizer.vercel.app 에 붙여넣어 보세요.

회의록 한 편이 약 몇 토큰인지 알면, 앞으로 “컨텍스트 몇 K가 필요한지” 직감으로 잡힙니다.

다음 장에서는 “이 모델 몇 tokens/sec 나와요?” 의 진짜 정체를 봅니다.

메모리 대역폭이 왜 속도를 좌우하는지, 같은 32B 모델이 맥마다 왜 다른 속도가 나오는지, 이유가 보입니다.