Ollama가 긴 문서를 까먹는 이유 — 컨텍스트 길이(num_ctx)와 VRAM 비용

Ollama에 긴 문서를 넣고 요약을 시켰더니 앞부분을 통째로 무시한 답이 돌아온 적이 있다면, 모델이 멍청해서가 아닙니다.

입력이 잘려 나갔을 가능성이 큽니다. 그것도 조용히요.

무슨 일이 일어나는가

Ollama는 모델이 한 번에 기억하는 분량(컨텍스트 길이)을 기본값으로 제한해 둡니다. 이 기본값이 2048 또는 4096 토큰으로, 버전에 따라 다릅니다. 공식 문서끼리도 표기가 어긋날 정도라, 본인 설치본의 값은 아래에서 직접 확인하는 편이 확실합니다.

4096 토큰이 어느 정도냐면, 이 사이트 계산기의 라벨로 "파일 한 개 정도 — A4 두세 장"입니다. 그 이상을 넣으면 Ollama는 오류를 내지 않고 넘치는 앞부분을 잘라낸 뒤 그냥 실행합니다.

화면에는 아무 표시가 없습니다. 잘렸다는 사실은 서버 로그에만 남습니다.

truncating input prompt          ← 서버 로그에 이 문구가 있으면 잘린 겁니다

그래서 증상이 이상하게 나타납니다. 문서 뒷부분 질문에는 답을 잘 하는데 앞부분을 물으면 딴소리를 하고, 대화가 길어지면 처음에 정한 규칙을 잊습니다. 모델 품질 문제로 보이지만 실제로는 설정 문제입니다.

늘리는 방법 — 네 가지

어디서 쓰느냐에 따라 넣는 자리가 다를 뿐, 늘리는 값은 같은 num_ctx입니다.

① 대화 중 임시로 — ollama run 안에서:

/set parameter num_ctx 16384

그 세션에서만 적용됩니다. 시험해 보기에 가장 간단합니다.

② API로 쓸 때 — 요청에 옵션을 넣습니다:

{ "model": "llama3.1:8b", "options": { "num_ctx": 16384 }, ... }

③ 모델에 고정 — Modelfile로 설정을 박은 변형을 만듭니다:

FROM llama3.1:8b
PARAMETER num_ctx 16384

ollama create llama3.1-16k -f Modelfile 로 만들어두면 매번 지정할 필요가 없습니다.

④ 서버 전체 기본값 — 환경 변수:

OLLAMA_CONTEXT_LENGTH=16384

서버가 띄우는 모든 모델의 기본값이 바뀝니다.

늘리는 건 공짜가 아닙니다

여기가 이 글의 본론입니다. 컨텍스트는 VRAM을 먹습니다.

모델이 기억하는 내용은 KV 캐시라는 별도 메모리에 쌓이는데, 이건 토큰 수에 정비례합니다. 가중치(모델 파일)와 달리 양자화(Q4)의 영향도 받지 않습니다 — 기본 설정에서는 f16 그대로 쌓입니다.

Q4 기준, 가중치 + KV 캐시 + 오버헤드를 합친 필요량입니다.

읽는 법이 중요합니다.

• 8GB 카드에서 8B 모델: 기본 컨텍스트면 여유(6.5GB)지만, 16K로 올리는 순간 8GB에 닿고, 32K면 10GB — 일부가 CPU로 넘어가 눈에 띄게 느려집니다.
• 12GB 카드에서 8B 모델: 32K(10.0GB)까지 여유입니다. 컨텍스트를 크게 쓰고 싶을 때 VRAM 여유분이 어디에 쓰이는지 보여주는 조합입니다.
• 128K는 급이 다릅니다. 8B 모델도 KV 캐시만 16GB가 붙어 총 22GB — 24GB급 카드의 영역입니다. "모델이 128K를 지원한다"와 "내 카드로 128K를 쓸 수 있다"는 전혀 다른 문제입니다.

내 카드 기준으로는 아래에서 바로 확인됩니다. 모델과 길이를 바꿔보면 판정이 어디서 뒤집히는지 보입니다.

num_ctx를 올렸는데 갑자기 느려졌다면

십중팔구 KV 캐시가 VRAM을 넘긴 것입니다.

num_ctx를 올리면 잘림은 사라지지만, 필요 메모리가 위 표만큼 늘어납니다. VRAM을 넘긴 몫은 시스템 램으로 밀려나고, 속도가 뚝 떨어집니다. 잘리는 것과 느려지는 것 사이의 트레이드오프인 셈입니다.

경계선에 걸렸다면 선택지는 셋입니다.

1. num_ctx를 필요한 만큼만 — 32K가 필요 없는데 습관으로 크게 잡지 않기
2. 모델을 한 단계 내리기 — 가중치가 줄어든 만큼 컨텍스트에 쓸 자리가 생깁니다. 8GB에서 버티는 법에서 이 방향을 자세히 다뤘습니다
3. VRAM이 큰 카드로 — 표에서 보듯 컨텍스트를 크게 쓰는 용도일수록 VRAM 용량이 대역폭보다 먼저입니다

알아둘 한계 두 가지

num_ctx는 모델의 최대치를 넘지 못합니다. 모델마다 학습된 컨텍스트 상한이 있습니다(예: Llama 3.1 계열은 128K). 그 이상으로 설정해도 의미가 없고, 상한이 4K·8K인 구형 모델은 num_ctx를 올려도 그 벽에서 멈춥니다.

컨텍스트를 늘린다고 긴 문서를 "잘" 읽게 되는 건 아닙니다. 잘리지 않게 될 뿐입니다. 아주 긴 입력의 중간 부분을 소홀히 다루는 경향은 컨텍스트가 충분해도 남습니다. 잘림 문제와 품질 문제는 별개입니다.

자주 묻는 질문

기본값은 왜 이렇게 작은가요

위 표가 답입니다. 기본값을 32K로 잡으면 8GB 카드에서 8B 모델이 설치 직후부터 느려집니다. 낮은 기본값은 "일단 어디서든 돌아가게"를 고른 결과입니다. 대신 잘림이 조용히 일어나는 게 대가입니다.

지금 설정이 얼마인지 어떻게 확인하나요

ollama show 모델명으로 모델의 컨텍스트 상한과 설정된 파라미터를 볼 수 있습니다. 실제로 잘렸는지는 서버 로그의 truncating 문구로 확인하는 게 확실합니다.

KV 캐시도 양자화하면 줄지 않나요

실행기에 KV 캐시를 q8·q4로 줄이는 실험적 옵션이 있고, 켜면 위 표의 KV 몫이 절반~4분의 1로 줄어듭니다. 다만 기본값은 f16이고, KV를 줄이면 긴 컨텍스트에서 품질이 깎일 수 있어 표는 기본 기준으로 잡았습니다. 양자화가 가중치에 어떻게 작용하는지는 양자화 Q4·Q5·Q8 차이에 있습니다.

VRAM이 모자라면 시스템 램으로라도 늘릴 수 있나요

돌아는 갑니다. KV 캐시가 램으로 밀려나면 그만큼 느려질 뿐입니다. 어디까지가 VRAM 문제이고 어디부터가 램 문제인지는 램과 VRAM의 차이에 정리해 뒀습니다.

대화가 길어져도 잘리나요

같은 원리로 잘립니다. 문서를 안 넣어도 주고받은 대화 전체가 컨텍스트에 쌓이므로, 긴 대화 끝에 초반 내용을 잊는 것도 같은 증상입니다.

정리

1. Ollama 기본 컨텍스트는 2048~4096 토큰 — A4 두세 장이면 찹니다
2. 넘치면 오류 없이 조용히 잘립니다. "앞부분을 까먹는" 증상의 정체입니다
3. num_ctx로 늘립니다 — 대화 중 /set parameter, API 옵션, Modelfile, 환경 변수
4. 늘리면 VRAM이 듭니다. 8B 모델도 32K면 10GB, 128K면 22GB
5. 올린 뒤 느려졌다면 KV 캐시가 VRAM을 넘긴 겁니다 — 길이·모델·카드 중 하나를 조정해야 합니다

처음 설치부터라면 Ollama 설치 가이드, 카드별 한계는 Ollama 최소 사양 정리에 있습니다.

수치나 명령이 실제와 다르면 알려주세요. 확인 후 갱신합니다.