모델을 불러온 뒤 첫 응답이 늦고, 문장이 길어질수록 생성이 더뎌집니다.
빠른 판단: CPU만으로는 GPU 추론처럼 즉각적인 응답을 기대하기 어렵습니다. 모델 크기와 문맥 길이, 메모리 교환, 스레드와 컨테이너 제한을 먼저 점검한 뒤 같은 조건으로 다시 측정하세요. 저지연이나 높은 동시성이 필수라면 CPU 서버 교체만으로 해결된다고 가정하지 말고 GPU 추론이나 외부 모델 API를 검토해야 합니다.
이 글은 CPU만 사용하는 Ollama 추론의 응답 시간이 만족스럽지 않은 개발자에게 적합합니다.
자체 호스팅 AI 서비스나 지식 기반을 운영하는 소규모 팀은 서비스를 나눠 배치할 필요가 있는지 확인할 수 있습니다.
VPS에서 독립 서버로 옮기려는 담당자는 자원 사용 기록으로 증설 효과를 먼저 판단할 수 있습니다.
마지막 확인: 2026년 10월 23일. Ollama 공식 블로그와 문서, 공개된 릴리스 기록을 기준으로 검토했습니다. 공식 블로그의 0.30 및 GGUF 안내와 Ollama 릴리스 기록을 확인하세요. 해당 업데이트는 성능 보증이나 최신 버전 판정을 뜻하지 않습니다.
증상을 나눠 병목부터 찾기
CPU 추론이 느리다는 한 가지 증상만으로 코어 수 부족을 결론 내리면 안 됩니다. 모델 적재가 늦는 경우, 첫 토큰까지 오래 걸리는 경우, 생성 중에만 느린 경우, 요청이 겹칠 때 대기하는 경우는 원인이 다를 수 있습니다. 메모리가 부족해 디스크 교환이 발생하는 상황도 CPU 연산 부족과 구분해야 합니다.
Ollama를 CPU만으로 실행하면 왜 느릴까요? GPU와 다른 연산 경로를 사용하기 때문입니다. 다만 이 차이만으로 현재 속도가 정상인지 판정할 수는 없습니다. 먼저 모델 이름과 양자화 형식, 입력 문장, 문맥 길이를 기록하고 조건을 고정해 비교하세요. 같은 모델이라도 긴 입력과 큰 문맥을 처리하면 작업량이 달라집니다.
Ollama 공식 API 응답에는 입력과 출력 토큰 수, 입력 평가 시간, 생성 시간 등의 측정 정보가 포함될 수 있습니다. 생성 API 문서의 응답 항목을 참고해 첫 토큰 대기와 생성 구간을 따로 기록하세요. 한 번의 실행으로 결론 내리지 말고, 같은 조건의 반복 실행을 비교하는 편이 안전합니다.
모델 크기와 메모리 요구량 계산
모델 파일 크기는 메모리 요구량의 출발점일 뿐입니다. 추론 중에는 실행에 필요한 메모리와 KV 캐시도 사용됩니다. 따라서 파일 크기만큼의 메모리가 있으면 충분하다고 판단하지 마세요. 작업에 필요하지 않은 큰 모델이나 지나치게 긴 문맥부터 줄여 같은 테스트를 다시 해보는 것이 우선입니다.
대략적인 모델 가중치 용량은 매개변수 수 × 양자화 비트 수 ÷ 8로 추정할 수 있습니다. 이 계산은 가중치만 단순 환산한 값입니다. 실제 요구량에는 모델 형식의 추가 정보, 실행 오버헤드와 KV 캐시가 더해집니다. 모델 형식과 양자화 설명을 확인하고, 파일 크기를 전체 메모리 요구량으로 오해하지 마세요.
모델을 작게 바꿀지 메모리를 늘릴지 어떻게 판단할까요? 현재 모델이 메모리에 온전히 올라오지 않거나 시스템에서 교환 공간 사용이 관찰되면 메모리 압박부터 살피세요. 반면 메모리에 여유가 있고 모델 적재도 안정적인데 생성만 오래 걸린다면, 더 작은 모델이나 다른 양자화 형식을 시험하는 것이 먼저일 수 있습니다. Ollama의 메모리와 모델 관련 자주 묻는 질문도 함께 확인하세요.
문맥 길이와 메모리 교환 확인
요청에 포함되는 입력이 실제 업무보다 길다면 모델이 처리할 분량도 늘어납니다. 대화 전체를 매번 넣거나 불필요한 문서를 함께 전달하는 구조인지 살펴보세요. 긴 문맥은 메모리 사용량을 키울 수 있고, CPU만 사용하는 환경에서는 처리 시간에도 영향을 줍니다. 문맥 길이를 줄여 나머지 조건을 그대로 둔 채 재측정하면 영향 범위를 파악하기 쉽습니다.
문맥 길이가 CPU 추론 속도에 영향을 줄 수 있나요? 영향을 줄 수 있습니다. 다만 느려진 원인이 문맥 길이라고 단정하지 말고 입력 길이와 생성 분량을 분리해 기록하세요. Ollama API의 생성 요청 및 응답 항목을 이용하면 입력 평가와 출력 생성에 걸린 시간을 구분하는 데 도움이 됩니다.
아래 항목을 함께 확인하세요.
- [ ]
free -h로 사용 가능한 메모리와 여유량을 확인합니다. - [ ]
swapon --show로 스왑 사용 여부를 확인합니다. - [ ]
ollama ps로 실행 중인 모델을 확인합니다. - [ ] 모델이 메모리에 올라온 상태와 새로 불러오는 상태를 구분해 시험합니다.
- [ ] 불필요한 대화 기록이나 검색 문서를 줄인 뒤 같은 요청으로 재측정합니다.
스왑이 쓰인다는 사실만으로 모든 지연이 메모리 부족 때문이라고 단정할 수는 없습니다. 측정할 때 스왑 변화와 CPU 사용률, 모델 적재 상태를 함께 기록해야 원인을 나눌 수 있습니다.
Docker 자원과 스레드 제한 점검
컨테이너에서 실행한다고 호스트의 CPU와 메모리를 모두 쓸 수 있는 것은 아닙니다. 컨테이너에 CPU 할당량이나 CPU 집합 제한이 적용됐는지 확인하고, 호스트와 컨테이너가 인식하는 CPU 범위가 다른지도 비교하세요. Ollama에 지정한 스레드 수가 컨테이너에서 사용할 수 있는 자원보다 크면 기대한 처리량을 얻지 못할 수 있습니다.
Docker에서 실행할 때는 무엇을 확인해야 할까요? docker stats로 컨테이너 자원 사용을 관찰하고, docker inspect로 CPU 제한 설정을 확인하세요. CPU 할당량과 CPU 집합은 서로 다른 제한 방식입니다. Docker의 컨테이너 자원 제한 문서에서 사용 중인 설정의 의미를 확인한 뒤 하나씩 바꿔 비교해야 합니다. 커뮤니티에서 공유된 특정 스레드 값은 다른 CPU와 컨테이너 설정에 그대로 적용할 수 있는 보편적인 권장값이 아닙니다.
체크 순서는 다음과 같습니다.
- [ ] 컨테이너가 호스트의 CPU 중 실제로 몇 개를 사용할 수 있는지 확인합니다.
- [ ] CPU 할당량과 CPU 집합 설정이 의도치 않게 좁혀져 있지 않은지 살핍니다.
- [ ] 컨테이너 메모리 제한과 호스트의 사용 가능 메모리를 각각 확인합니다.
- [ ] 스레드 설정을 바꿀 때 모델과 문맥, 입력을 고정해 전후 결과를 기록합니다.
Ollama의 컨테이너 실행 방법은 공식 Docker 안내를 기준으로 확인하세요. 실행 옵션과 설정 이름은 사용 중인 Ollama 버전 및 배포 방식에 맞춰야 합니다.
단일 요청과 여러 서비스 부하 분리
응답 지연이 항상 모델 추론에서 발생하는 것은 아닙니다. 모델을 처음 적재하는 시간, 여러 요청이 겹쳐 기다리는 시간, 벡터 검색과 임베딩 작업이 CPU를 함께 쓰는 상황을 따로 살펴보세요. 웹 애플리케이션, 지식 검색, 임베딩 처리와 모델 생성을 한 서버에서 운영한다면, 각 서비스를 별도로 측정하는 것이 증설 판단의 전제입니다.
다음 비교로 조치를 고르세요.
| 선택지 | 관찰되는 조건 | 먼저 할 일 |
|---|---|---|
| 현재 서버에서 최적화 | 모델이나 문맥이 불필요하게 크거나 컨테이너 제한이 확인됨 | 모델, 입력, 문맥과 자원 설정을 하나씩 조정합니다. |
| 메모리 용량 검토 | 모델 적재와 다른 서비스 사용이 겹치며 메모리 압박이나 스왑이 관찰됨 | 서비스 분리와 메모리 사용량을 확인한 뒤 필요한 용량을 산정합니다. |
| CPU 자원 증설 검토 | 메모리 여유와 자원 설정을 확인했는데도 CPU 포화와 요청 대기가 반복됨 | 동일 조건 측정이 반복되는지 확인하고, 허용 지연과 비교합니다. |
| GPU 추론 또는 외부 API 검토 | 짧은 응답 시간이나 높은 동시성이 필수 조건임 | CPU 서버 교체를 해답으로 간주하지 말고 다른 추론 방식을 평가합니다. |
반복 측정으로 서버 교체 판단
고정된 CPU 사용률이나 대기 시간을 모든 서비스에 적용할 수 있는 교체 기준은 없습니다. 허용 가능한 지연은 사용 목적과 요청량에 따라 달라집니다. 모델과 문맥, 입력을 고정하고 첫 토큰 대기, 생성 시간, 메모리 압박, 스왑 변화, CPU 포화 지속 시간, 요청 대기를 함께 기록하세요. 최적화 전후에도 같은 시험 조건을 유지해야 비교가 의미 있습니다.
참고: Ollama는 2026년 6월 5일 공개한 0.30 안내에서 llama.cpp를 통한 성능 개선과 GGUF 호환성 개선을 설명했습니다. 이는 해당 업데이트의 안내이며, 모든 CPU 환경의 속도 개선을 보장하지 않습니다. 공식 안내
측정 결과를 정리한 뒤에만 서버 자원을 검토하세요. SFP Cloud 요금 및 선택 항목에서 현재 제공 구성을 확인하고, 구매 전에는 필요한 메모리와 저장 공간, 결제 주기를 실제 제품 정보와 대조해야 합니다. 특정 CPU 모델이나 가격, 추론 속도는 확인되지 않은 채 추정해서는 안 됩니다.
문서가 외부 서비스로 전송되는 것이 우려되는 팀은 자체 호스팅을 검토할 수 있지만, 서버를 직접 운영하면 접근 권한 관리와 백업, 업데이트 책임도 운영자에게 생깁니다. 이 점은 개인정보 안내를 확인하는 것과 별개로 자체 운영 설계에 반영해야 합니다.
현재 VPS에서 CPU 자원 경합이나 제한된 메모리 때문에 작업이 밀리고, 반복 측정에서도 독립 자원이 병목 해소에 도움이 될 것으로 보인다면 SFP Cloud의 AMD 물리 서버 임대를 비교할 수 있습니다. 공유 환경에서 생길 수 있는 이웃 부하 경쟁, CPU 할당 제한, 메모리와 저장 공간 선택의 제약은 독립 서버로 옮길 이유가 될 수 있습니다. 다만 GPU가 필요한 학습이나 저지연·고동시성 추론은 CPU 물리 서버로 대체할 수 없습니다. 먼저 기준 측정표를 작성하고 제품 페이지의 실제 옵션과 맞춰 보세요. GPU 추론이 요구사항이라면 CPU 서버 계약을 서두르기보다 GPU 추론이나 외부 모델 API를 검토하는 편이 타당합니다.