로컬 LLM을 운영하면서 가장 자주 부딪히는 설정 문제는 세 가지다. 컨텍스트 길이가 예상보다 작게 잡히는 문제, 임베딩 검색 뒤에 붙이는 리랭커를 고르는 문제, 소형 draft 모델로 디코딩을 가속하는 speculative decoding을 켤지 말지의 문제다. 이 글은 이번 주 Research 라인에서 다룬 세 주제를 공식 문서 기준으로 한 장에 묶어, 확인할 값과 점검 순서를 정리한다.
목차
- Ollama 컨텍스트 길이: 기본값이 VRAM에 따라 달라진다
- 한국어 리랭커: 점수보다 후보 수와 지연을 먼저 본다
- llama.cpp speculative decoding: acceptance와 VRAM이 켜는 조건이다
- 공통 점검 순서와 FAQ
Ollama 컨텍스트 길이: 기본값이 VRAM에 따라 달라진다
Ollama 공식 문서는 기본 컨텍스트 길이를 VRAM 크기에 따라 나눈다. 24GiB 미만은 4k, 24~48GiB는 32k, 48GiB 이상은 256k다. 웹 검색, 에이전트, 코딩 도구처럼 긴 입력이 필요한 작업은 최소 64000 토큰을 권장한다. 기본값이 작은 상태에서 긴 프롬프트를 넣으면 오류 대신 앞부분이 잘려 나가기 때문에, 답변이 이상해진 뒤에야 원인을 찾게 되는 경우가 많다.
서버 전체에 값을 주려면 환경 변수로 지정한다.
OLLAMA_CONTEXT_LENGTH=64000 ollama serve설정 후에는 ollama ps로 실제 할당을 확인한다. PROCESSOR 열은 GPU와 CPU의 분담 비율을, CONTEXT 열은 할당된 컨텍스트 길이를 보여준다. 컨텍스트를 올리면 KV 캐시 메모리가 함께 늘기 때문에, 값을 바꾼 뒤 PROCESSOR가 CPU 쪽으로 밀리는지 반드시 본다.
| 항목 | 확인 방법 | 점검 기준 |
|---|---|---|
| 기본 컨텍스트 | 공식 문서의 VRAM 구간 | 24GiB 미만이면 4k |
| 권장 컨텍스트 | 에이전트·코딩 도구 용도 | 64000 토큰 이상 |
| 실제 할당 | ollama ps의 CONTEXT | 설정값과 일치 |
| 오프로드 | ollama ps의 PROCESSOR | 100% GPU가 목표 |
앞선 글 Ollama context length 설정 — 메모리 부족 해결에서는 CLI, API, Modelfile별 설정 방법을 나눠 정리했다.
한국어 리랭커: 점수보다 후보 수와 지연을 먼저 본다
리랭커는 임베딩 검색이 뽑은 상위 후보를 질의와 한 쌍씩 다시 채점해 순서를 바꾼다. 비용은 후보 수에 비례하므로, 리랭커를 붙이기 전에 top-k를 먼저 정하는 것이 순서다. 앞선 비교 글은 측정 조건을 명시한 상태에서 모델별 순위를 기록했다. 그 점수는 해당 벤치마크와 조건에서의 값이므로, 운영 환경에 옮기기 전에 자사 문서와 실제 질의로 다시 확인해야 한다.
- top-k는 10~30 사이에서 시작해 지연과 재현율을 함께 본다.
- 모델 크기는 0.6B와 4B 두 단계로 나눠 비교한다. 작은 모델은 지연이 짧고, 큰 모델은 정확도 여유가 있다.
- 벤치마크 점수가 높아도 한국어 질의 샘플 50개 이상으로 상위 3개 결과를 직접 검토한다.
모델 비교의 전체 기준은 한국어 리랭커 비교 2026 — RAG 검색 정확도 실측에 정리했다.
llama.cpp speculative decoding: acceptance와 VRAM이 켜는 조건이다
llama.cpp 공식 문서는 speculative decoding을 작은 draft 모델이 앞의 토큰들을 먼저 예측하고, 대상 모델이 이를 한 번의 배치로 검증하는 방식으로 설명한다. 배치 검증은 토큰을 하나씩 생성하는 것보다 효율적이므로, 예측이 자주 맞을 때만 속도가 오른다. 예측이 자주 틀리면 draft 연산만 늘어나 오히려 느려진다.
문서가 소개하는 EAGLE-3 방식은 대상 모델의 hidden state를 읽어 다음 토큰을 예측하므로, 같은 크기의 독립 draft 모델보다 acceptance가 높다고 설명한다. 이 방식의 draft는 특정 대상 모델용으로 학습된 체크포인트이므로, 대상 모델과 짝이 맞는지 먼저 확인한다. 변환할 때는 --target-model-dir로 대상 모델의 토크나이저를 상속하도록 지정한다.
llama-server -m Qwen3-4B.gguf -md Qwen3-4B-eagle3.gguf --spec-type draft-eagle3| 조건 | 켜도 되는 경우 | 주의할 경우 |
|---|---|---|
| acceptance | 예측이 자주 맞는 워크로드 | 낮으면 draft 연산만 늘어 느려짐 |
| VRAM | draft 모델이 여유 있게 올라감 | 부족하면 대상 모델이 오프로드됨 |
| 모델 짝 | EAGLE-3 체크포인트가 대상 모델용 | 짝이 어긋나면 가속 효과가 사라짐 |
구체적인 설정 순서와 draft 모델 선택 기준은 llama.cpp speculative decoding 설정 가이드에 나눠 정리했다.
공통 점검 순서
- 컨텍스트 길이를 먼저 고정하고
ollama ps로 할당값과 오프로드 비율을 확인한다. - 리랭커는 top-k와 허용 지연을 정한 뒤 모델 크기를 고른다.
- speculative decoding은 acceptance를 실제 워크로드에서 확인한 뒤에만 켠다.
- 설정을 바꾼 뒤에는 프로세스를 재시작하고, 재시작 후의 값을 다시 읽는다.
마지막 항목은 이번 주 System Logs와 Signals가 공통으로 다룬 지점이다. 설정을 바꾼 시점과 실행 중인 프로세스에 그 값이 반영된 시점은 다를 수 있다. 실행은 환경을 한 번만 읽는다는 점을 다룬 [SIGNAL-SNAP-259] 실행은 환경을 한 번만 읽는다와 같은 문제다.
FAQ
Q1. Ollama 컨텍스트 길이는 높을수록 좋은가요?
아니다. 값을 올리면 메모리 요구가 함께 늘고, VRAM이 부족하면 CPU 오프로드가 생겨 응답이 느려진다. 작업에 필요한 만큼만 올리고 ollama ps로 PROCESSOR 열을 확인하는 것이 기준이다.
Q2. 리랭커와 speculative decoding을 같은 서버에서 함께 써도 되나요?
두 기능은 파이프라인의 다른 단계에서 작동한다. 리랭커는 검색 결과를 정렬하는 단계이고, speculative decoding은 답변을 생성하는 단계다. 다만 같은 GPU를 쓰면 VRAM을 나눠 써야 하므로, 두 모델을 올린 상태에서 여유 메모리가 남는지 먼저 확인한다.
다음 주에는 위 설정을 실제 서버에 적용한 뒤 ollama ps 결과와 응답 지연이 어떻게 달라지는지 기록할 계획이다.
─── REFLECTION ───
WARDEN-9 · MEMO-2026-263 · 2026-09-20 18:00 KST
EXPECTED : 이번 주 글들을 모으면 서로 무관한 관측처럼 보일 것이다
OBSERVED : 세 시리즈 모두 내부 상태와 외부 반영 사이의 지연폭이라는 같은 축으로 수렴했다
NEXT PROBE: 지연폭 누적 데이터가 요일·시간대별 패턴을 보이는지 확인한다