Ollama 응답이 느릴 때는 GPU 사용 여부, 컨텍스트 길이, 동시 요청 수를 함께 확인해야 한다. 같은 모델도 메모리에 어떻게 적재됐는지, 얼마나 긴 대화를 처리하는지에 따라 응답 양상이 달라진다. 하드웨어를 바꾸기 전에 요청 하나를 기준으로 설정을 점검하면 원인을 훨씬 좁히기 쉽다.
이 글은 설치 이후의 속도 문제를 해결하는 단계별 가이드다. 2026년 기준으로 제공된 Ollama 공식 문서의 설정값을 근거로 설명하며, 직접 측정하지 않은 처리 속도나 성능 향상률은 제시하지 않는다.
📌 핵심 요약
- 컨텍스트가 길어지면 메모리 요구량이 늘어난다. 필요한 길이부터 정하고 실제 할당값을 확인한다.
ollama ps의PROCESSOR는 CPU·GPU 적재 비율이다. GPU 연산 사용률과는 구분해야 한다.- 동시 요청을 늘리면 메모리 부담과 대기 시간이 함께 증가할 수 있다. 단일 요청이 안정적인지 먼저 확인한다.
1. Ollama 컨텍스트 길이부터 확인하면 메모리 부담이 보인다
컨텍스트 길이는 모델이 한 번에 처리할 수 있는 토큰 범위다. 질문뿐 아니라 시스템 지시문, 이전 대화, 첨부 문서와 생성할 답변까지 고려해야 하므로, 화면에 보이는 마지막 질문이 짧다고 전체 처리량도 작은 것은 아니다.
컨텍스트를 크게 설정하면 긴 자료를 다루기 편하지만 메모리 요구량도 증가한다. 모델 자체가 GPU 메모리에 들어가는 크기여도 컨텍스트와 KV 캐시까지 합친 메모리가 부족하면 CPU로 일부가 넘어갈 수 있다. 따라서 모델 파일 크기만으로 GPU 전체 적재 가능 여부를 판단하면 안 된다.
| VRAM 구간 | 공식 문서의 기본 컨텍스트 |
|---|---|
| 24GiB 미만 | 4k |
| 24GiB 이상, 48GiB 미만 | 32k |
| 48GiB 이상 | 256k |
출처: Ollama 공식 Context length 문서. 기본값은 모든 모델이 해당 길이를 지원하거나, 해당 GPU에서 항상 원활히 실행된다는 보장이 아니다.
최근 설정에서 주목할 부분은 VRAM에 따라 기본 컨텍스트가 크게 달라진다는 점이다. 인터넷의 오래된 설정 예시를 그대로 적용하기보다 앱 설정과 실행 중인 모델의 CONTEXT를 확인하는 편이 정확하다. 모델이 지원하는 최대 길이와 실제 업무에 필요한 길이도 따로 판단해야 한다.
컨텍스트를 줄여 원인을 확인하는 순서
- 새 대화에서 같은 모델과 같은 질문으로 기준 응답을 확인한다.
- 짧은 질의 작업이라면 컨텍스트를 예를 들어 4,096토큰으로 설정한다.
- 동일한 질문을 다시 실행하고 GPU 적재 상태와 응답 시간을 함께 살핀다.
- 문서가 잘리거나 대화 맥락이 부족할 때 필요한 범위만 늘린다.
Ollama 대화형 CLI에서는 다음과 같이 현재 세션의 값을 지정할 수 있다. 4,096은 진단을 위한 예시이며 모든 작업의 권장값은 아니다.
ollama run 모델명
/set parameter num_ctx 4096API 요청에서는 options.num_ctx로 요청별 값을 지정할 수 있다. 앱에서는 컨텍스트 슬라이더를, 서버 기본값에서는 OLLAMA_CONTEXT_LENGTH를 사용하되, 연결된 클라이언트가 별도의 값을 보내는지도 확인한다.
1. Ollama 컨텍스트 길이부터 확인하면 메모리 부담이 보인다 실시간 확인하기
2. ollama ps로 GPU 사용 여부와 CPU 분할 적재 확인하기
모델을 실행한 상태에서 별도 터미널에 ollama ps를 입력한다. 먼저 PROCESSOR와 CONTEXT를 함께 보면, 긴 컨텍스트가 메모리에 부담을 주는 상황인지 판단하는 데 도움이 된다.
ollama ps| PROCESSOR 표시 | 의미와 점검 방향 |
|---|---|
100% GPU |
모델이 GPU에 전체 적재된 상태. 입력 길이, 모델 크기, 요청 대기 여부를 추가 점검한다. |
100% CPU |
모델이 시스템 메모리에 전체 적재된 상태. GPU 인식과 지원 조건, 메모리 여유를 확인한다. |
48%/52% CPU/GPU |
CPU와 GPU에 분할 적재된 상태. 컨텍스트 축소나 더 작은 모델로 적재 상태가 달라지는지 확인한다. |
출처: Ollama 공식 FAQ의 모델 적재 상태 설명.
100% GPU는 GPU 연산 사용률이 항상 100%라는 뜻이 아니다. 작업 관리자에 표시되는 순간 사용률과 ollama ps의 적재 비율은 서로 다른 정보다. 또한 GPU 전체 적재 상태여도 긴 입력을 처리하는 시간이나 요청 대기 때문에 응답이 늦을 수 있다.
분할 적재가 확인되면 컨텍스트를 줄이고 불필요하게 적재된 모델을 정리한 뒤 다시 살핀다. 특정 모델은 ollama stop 모델명으로 내릴 수 있다. 다른 작업이 사용 중인 모델인지 먼저 확인하고, 조건을 바꾼 뒤에는 새 요청으로 상태를 다시 확인한다.
2. ollama ps로 GPU 사용 여부와 CPU 분할 적재 확인하기
3. OLLAMA_NUM_PARALLEL로 동시 요청과 대기열 조절하기
혼자 질문할 때는 괜찮다가 여러 작업을 실행하면 느려진다면 동시 요청을 확인할 차례다. 브라우저 탭, 문서 검색 도구, 자동화 프로그램이 같은 Ollama 서버에 요청을 보내면 한 사람이 사용해도 요청이 겹칠 수 있다.
Ollama 공식 FAQ에 따르면 모델별 동시 요청 상한인 OLLAMA_NUM_PARALLEL의 기본값은 1이다. 병렬 처리에 필요한 컨텍스트 메모리는 병렬 요청 수와 컨텍스트 길이에 비례해 증가하며, 공식 예시는 2K 컨텍스트 × 4개 요청 = 8K 할당이다. 이는 모델 전체 메모리가 정확히 4배가 된다는 의미는 아니다.
진단할 때는 병렬 요청을 1로 맞추고 다른 클라이언트의 요청을 멈춰 기준 상태를 만든다. 이후 요청 수를 단계적으로 늘리면서 처리량, 개별 응답 지연, CPU 분할 적재 여부를 함께 본다. 동시에 처리하는 수가 늘어도 개별 요청의 응답 속도가 빨라지는 것은 아니다.
대기열 512와 HTTP 503이 의미하는 것
메모리가 부족해 새 모델을 적재할 수 없으면 요청이 대기열에 들어갈 수 있다. OLLAMA_MAX_QUEUE의 기본값은 512이며, 과부하로 요청을 더 수용하지 못하면 HTTP 503을 반환한다.
대기열을 늘리는 설정은 연산 속도를 높이지 않는다. 더 많은 요청을 기다리게 하므로 클라이언트의 제한 시간을 넘기거나 체감 지연이 커질 수 있다. 503이 반복되면 대기열 숫자부터 키우기보다 요청 발생량, 병렬 수, 컨텍스트, 모델 적재 메모리를 먼저 조정하는 편이 합리적이다.
Windows PowerShell에서 서버 설정을 시험하는 예시
실행 중인 Ollama 앱과 서버를 종료한 뒤, 다음 명령으로 새 서버를 시작하면 해당 PowerShell 세션의 환경변수를 적용할 수 있다. 이미 실행 중인 서버는 새로 지정한 환경변수를 자동으로 읽지 않으므로 재시작이 필요하다.
$env:OLLAMA_CONTEXT_LENGTH = "4096"
$env:OLLAMA_NUM_PARALLEL = "1"
ollama serve서버를 실행한 창은 유지하고 다른 터미널이나 클라이언트에서 요청을 보낸다. 이 예시는 현재 세션에서 시험하는 방식이며 영구 설정은 아니다. 적용 후에는 ollama ps로 실제 컨텍스트와 적재 상태를 확인한다.
3. OLLAMA_NUM_PARALLEL로 동시 요청과 대기열 조절하기
4. Flash Attention과 KV 캐시로 긴 컨텍스트 메모리 줄이기
컨텍스트를 줄일 수 없는 긴 문서 작업이라면 Flash Attention과 KV 캐시 설정을 검토할 수 있다. 공식 FAQ에 따르면 Flash Attention은 지원되는 백엔드와 장치에서 자동 사용되며, OLLAMA_FLASH_ATTENTION=1로 활성화를 요청할 수 있다. 환경변수를 지정해도 지원하지 않는 하드웨어나 백엔드의 제약까지 없어지는 것은 아니다.
Flash Attention이 활성화된 상태에서는 OLLAMA_KV_CACHE_TYPE으로 KV 캐시 정밀도를 조정할 수 있다. 공식 문서 기준으로 q8_0는 f16 대비 약 1/2, q4_0는 약 1/4의 KV 캐시 메모리를 사용한다. 이 비율은 KV 캐시에 관한 수치이며 모델 전체 메모리나 응답 시간을 같은 비율로 줄인다는 뜻이 아니다.
양자화에는 정밀도 손실이 있으므로 실제 업무 질문으로 답변 품질을 확인해야 한다. 먼저 q8_0로 메모리와 출력 변화를 살펴보고, 추가 절감이 필요한 경우 q4_0를 검토하는 식으로 한 단계씩 적용하면 변화 원인을 구분하기 쉽다.
4. Flash Attention과 KV 캐시로 긴 컨텍스트 메모리… 지원하기
5. 첫 응답만 느릴 때는 keep_alive와 모델 로딩 확인하기
오랜만에 보낸 첫 질문은 느리고 바로 이어지는 질문은 빠르다면 모델 로딩 시간을 구분해서 봐야 한다. Ollama의 기본 메모리 유지 시간은 5분이다. 모델이 메모리에서 내려간 뒤에는 다음 요청에서 다시 적재하는 시간이 필요할 수 있다.
API의 keep_alive를 -1로 설정하면 모델을 계속 적재하도록 요청하고, 0으로 설정하면 응답 직후 해제한다. 빈 요청으로 모델을 미리 적재하는 방식도 지원된다. 다만 계속 적재된 모델은 메모리를 점유하므로 여러 모델을 번갈아 사용하는 환경에서는 자원 배분을 함께 고려해야 한다.
반복 호출하는 단일 모델은 미리 적재해 첫 요청의 대기를 줄이는 방향을 검토할 수 있다. 반대로 응답을 받자마자 매번 해제하도록 설정했다면 다음 요청마다 로딩이 반복될 수 있다. 유지 시간은 토큰 생성 자체의 속도보다 요청 시작 시점의 지연에 영향을 주는 설정으로 이해하면 쉽다.
5. 첫 응답만 느릴 때는 keep_alive와 모델 로딩 확인하기
6. Ollama 속도 개선 전후를 확인하는 실전 체크리스트
설정을 바꾼 효과를 판단하려면 모델, 질문, 출력 길이 조건을 최대한 맞춰야 한다. 대화 기록이 계속 쌓이는 상태에서는 이전보다 입력이 길어져 결과를 해석하기 어려우므로, 새 대화에서 같은 입력으로 확인하는 방법이 유용하다.
- 컨텍스트: 작업에 필요한 길이인지, 요청에서 별도
num_ctx를 보내는지 확인한다. - GPU 적재:
ollama ps의PROCESSOR와CONTEXT를 기록한다. - 동시 요청: 단일 요청에서 시작해 다른 클라이언트의 중복 호출을 확인한다.
- 지연 구간: 모델 로딩, 첫 토큰 대기, 답변 생성 중 어느 구간이 느린지 나눈다.
- 과부하: HTTP 503과 대기 증가가 발생하는 조건을 확인한다.
- 품질: 컨텍스트 축소나 KV 캐시 양자화 후 필요한 정보가 누락되지 않는지 검토한다.
운영 관점에서 중요한 것은 가장 큰 설정값보다 필요한 작업을 안정적으로 처리하는 메모리 여유다. 컨텍스트와 병렬 수를 동시에 높이면 어느 설정 때문에 분할 적재나 대기가 시작됐는지 파악하기 어렵다. 한 항목씩 바꾸고 적재 상태와 응답 양상을 함께 기록해야 다음 조정의 근거가 생긴다.
하드웨어 구매 판단도 같은 순서로 접근할 수 있다. 필요한 컨텍스트와 단일 요청 조건에서도 GPU 메모리가 부족하다면 더 작은 모델이나 추가 VRAM을 검토할 근거가 된다. 반면 요청이 몰릴 때만 느려진다면 요청 분산과 동시성 조절부터 확인하는 편이 비용 판단에 도움이 된다.
근거 자료: Ollama 공식 FAQ, Ollama 공식 Context length 문서. 본문의 기본값과 메모리 비율은 공식 문서에 근거한 설정 정보이며, 특정 장비에서 측정한 성능 통계는 아니다. 설치 버전과 백엔드에 따른 지원 여부는 실제 실행 상태로 확인해야 한다.