Skip to main content

Ollama & Open WebUI 최적화 가이드

등록일: 2026-05-07

본 문서는 AMD Ryzen 7 5825U CPU와 DDR4 32GB RAM 환경의 홈서버에서 Ollama와 Open WebUI를 사용해 exaone3.5:2.4b 모델을 조금 더 가볍고 빠르게 쓰기 위한 실전 설정 가이드임.
목표는 기능을 많이 켜는 것이 아니라, 작은 로컬 모델을 CPU 기준으로 안정적이고 빠르게 응답시키는 데 있음.

이 가이드는 아래 최종 상태를 기준으로 작성함.

  • Ollama는 호스트에 직접 설치되어 systemd 서비스로 실행됨.
  • Open WebUI는 Docker Compose로 실행됨.
  • 기본 모델은 exaone3.5:2.4b가 아니라, 최적화 파라미터를 넣어 새로 만든 sleepzz-exaone3.5:2.4b-fast:latest를 사용함.
  • 웹 검색, 이미지 생성 같은 부가 기능은 끄고, 일반 채팅 응답 속도 위주로 사용함.

1. 적용할 최종 설정 요약​

먼저 어떤 설정을 만들 건지부터 짧게 정리하면 아래와 같음.

Ollama 서비스 환경 변수​

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=24h

Open WebUI 환경 변수​

OLLAMA_BASE_URL=http://172.17.0.1:11434
ENABLE_WEB_SEARCH=False
ENABLE_IMAGE_GENERATION=False

Ollama 전용 모델 파라미터​

FROM exaone3.5:2.4b
PARAMETER num_thread 8
PARAMETER num_ctx 4096

2. Ollama 서비스 최적화​

이 단계는 Ollama 서버 자체의 동작 방식을 바꾸는 단계임.
Open WebUI보다 먼저 적용해야 함.

2-1. 서비스 override 파일 열기​

터미널에서 아래 명령어 실행함.

sudo systemctl edit ollama.service

에디터가 열리면 아래 내용을 그대로 넣음.

[Service]
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_KEEP_ALIVE=24h"

저장 후 종료함.

2-2. 서비스 재적용​

아래 명령어를 순서대로 실행함.

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl status ollama

status 결과에서 서비스가 active (running)이면 정상임.

2-3. 왜 이렇게 설정하는가​

  • OLLAMA_NUM_PARALLEL=1 CPU 환경에서는 여러 요청을 동시에 처리할수록 전체 처리량보다 체감 응답 속도가 더 나빠지는 경우가 많음. 홈서버에서 혼자 쓰거나 소수만 쓰는 환경이면 1로 두는 게 가장 무난함.

  • OLLAMA_MAX_LOADED_MODELS=1 한 번에 여러 모델을 메모리에 올리지 않게 막아서 RAM 낭비를 줄임. 32GB RAM이어도 CPU 추론에서는 모델 여러 개를 동시에 유지하는 것보다 하나에 집중하는 쪽이 보통 더 낫다.

  • OLLAMA_KEEP_ALIVE=24h 모델을 메모리에 오래 남겨서 첫 질문 때 발생하는 재로딩 지연을 줄임. -1처럼 사실상 무기한으로 박아두는 방식보다 관리가 편하고, 체감상 거의 상주시킨 것처럼 쓸 수 있음.

3. Open WebUI 컨테이너 최적화​

이 단계는 Open WebUI가 Ollama를 어떻게 바라보고, 어떤 부가 기능을 켤지 정하는 단계임.

3-1. docker-compose.yml 수정​

Open WebUI용 docker-compose.yml에서 해당 서비스를 아래처럼 맞춤.
아래 예시는 최적화용 변수만 따로 떼어낸 것이 아니라, 실제로 사용할 수 있는 서비스 예시를 통으로 적은 것임.

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    ports:
      - "8083:8080"
    volumes:
      - - /data001/open-webui/data:/app/backend/data
    environment:
      # - "OLLAMA_BASE_URL=https://ollama-api.sleepzz.xyz"
      - "OLLAMA_BASE_URL=http://172.17.0.1:11434"
      - "VECTOR_DB=pgvector"
      - "PGVECTOR_DB_URL=postgresql://sleepzz:******@postgres:5432/postgres"
      - "ENABLE_WEB_SEARCH=False"
      - "ENABLE_IMAGE_GENERATION=False"
    networks:
      - serverzz-net

networks:
  serverzz-net:
    external: true

위 예시에서 VECTOR_DB, PGVECTOR_DB_URL, volumes, networks 같은 항목은 기존 구성을 유지한 것이고, 최적화 목적상 새로 신경 쓸 부분은 아래 항목들임.

3-2. 설정 적용​

수정 후 아래 명령어 실행함.

docker compose up -d
docker compose restart open-webui

3-3. 왜 이렇게 설정하는가​

  • OLLAMA_BASE_URL=http://172.17.0.1:11434 컨테이너 안의 Open WebUI가 호스트에 설치된 Ollama에 안정적으로 붙도록 하기 위함임.

  • VECTOR_DB=pgvector 이 값 자체가 속도를 빠르게 만드는 핵심 설정은 아님.
    기존에 PostgreSQL과 PGVector를 사용 중이면 그대로 유지하면 됨.

  • PGVECTOR_DB_URL=... 기존 PGVector 연결 문자열을 그대로 넣는 자리임.
    실제 문서나 Git 저장소에는 비밀번호를 그대로 적지 말고 마스킹된 형태로 관리하는 것을 권장함.

  • ENABLE_WEB_SEARCH=False 웹 검색 기능은 작은 CPU 기반 로컬 모델과 조합했을 때 응답 지연을 크게 늘릴 수 있음. 일반 채팅 위주라면 끄는 게 낫다.

  • ENABLE_IMAGE_GENERATION=False 이미지 생성은 지금 목표와 무관하고 UI 기능도 불필요하게 넓어짐. 끄고 가는 게 맞다.

  • volumes: - - /data001/open-webui/data:/app/backend/data Open WebUI 내부 데이터와 설정 저장용 볼륨임.
    최적화 항목은 아니지만, 컨테이너를 다시 띄울 때 데이터가 날아가지 않게 유지하려면 보통 같이 둠.

  • networks: - serverzz-net 기존 Docker 네트워크 구성을 유지하는 항목임.
    이것도 성능 최적화용은 아니고, 현재 서버 구성에 맞춰 붙여두는 값임.

3-4. Open WebUI 화면에서 같이 확인할 것​

컨테이너를 다시 띄운 뒤 Open WebUI 관리자 화면에서 아래만 확인하면 됨.

  1. Admin Panel > Settings > Web Search에 들어감.
  2. 웹 검색이 꺼져 있는지 확인함.
  3. Admin Panel > Settings > Images에 들어감.
  4. 이미지 생성이 꺼져 있는지 확인함.

환경변수를 넣었는데도 UI가 다르게 보이면, 기존 DB에 저장된 설정이 남아있을 수 있음.
이 경우에는 관리자 화면에서 한 번 직접 꺼주고 다시 확인하면 됨.

4. EXAONE 전용 빠른 모델 만들기​

이 단계가 가장 중요함.
기본 exaone3.5:2.4b를 그대로 쓰지 말고, CPU 환경에 맞는 파라미터를 넣은 새 모델을 만들어서 Open WebUI에서 그 모델명을 선택해서 써야 함.

4-1. 작업 디렉터리 만들기​

아무 경로에 만들어도 되지만, 보통 홈 디렉터리 아래에 별도 폴더를 하나 만드는 게 관리하기 편함.

mkdir -p ~/ollama-profiles/sleepzz-exaone3.5-2.4b-fast
cd ~/ollama-profiles/sleepzz-exaone3.5-2.4b-fast

4-2. Modelfile 생성​

현재 디렉터리에 Modelfile이라는 이름으로 파일을 만듦. 모델별로 디렉터리를 따로 만들고 파일명은 Modelfile로 통일하는 것이 권장됨.

아래처럼 micro로 파일을 열어서 작성하면 됨.

micro Modelfile

열리면 아래 내용을 그대로 넣고 저장함.

FROM exaone3.5:2.4b
PARAMETER num_thread 8
PARAMETER num_ctx 4096

micro 기준으로는 내용 입력 후 아래처럼 하면 됨.

  • 저장: Ctrl + S
  • 종료: Ctrl + Q

파일명은 꼭 Modelfile일 필요는 없지만, 그대로 쓰는 게 가장 헷갈리지 않음.
여러 모델을 운영할 때도 파일명을 바꾸기보다 디렉터리명과 ollama create 모델명을 바꿔서 관리하는 쪽을 권장함.

4-3. 모델 생성​

아래 명령어 실행함.

ollama create sleepzz-exaone3.5:2.4b-fast -f Modelfile

정상 완료되면 sleepzz-exaone3.5:2.4b-fast:latest라는 새 모델이 생김.

4-4. 생성 결과 확인​

ollama list

목록에 sleepzz-exaone3.5:2.4b-fast가 보이면 성공임.

원하면 아래 명령어로 바로 테스트해도 됨.

ollama run sleepzz-exaone3.5:2.4b-fast

4-5. Open WebUI에서 새 모델 선택​

Open WebUI에 접속한 뒤 아래 순서로 확인함.

  1. 모델 선택 드롭다운을 열어봄.
  2. sleepzz-exaone3.5:2.4b-fast가 보이는지 확인함.
  3. 앞으로는 기본 exaone3.5:2.4b 대신 sleepzz-exaone3.5:2.4b-fast를 선택해서 사용함.

모델이 안 보이면 아래 순서로 다시 확인하면 됨.

  1. 호스트에서 ollama list로 모델이 실제 생성됐는지 확인함.
  2. Open WebUI 컨테이너를 한 번 재시작함.
  3. Open WebUI 화면을 새로고침함.

4-6. 왜 num_thread 8, num_ctx 4096인가​

  • num_thread 8 5825U는 8코어 16스레드 CPU라서, 시작값으로 8이 가장 무난함.
    CPU 기반 LLM은 논리 스레드를 끝까지 다 쓰는 것보다 물리 코어 기준으로 주는 쪽이 오히려 반응성이 나은 경우가 많음.

  • num_ctx 4096 일반 채팅에서는 컨텍스트를 너무 크게 잡을수록 CPU 부담이 빠르게 커짐.
    문서 분석이나 긴 대화 이력 보존보다 “짧고 빠른 답변”이 목표라면 4096이 균형이 좋음.

  • 다른 파라미터는 왜 안 넣는가 num_thread, num_ctx 외에도 temperature, top_k, top_p, repeat_last_n, num_predict 같은 값을 넣을 수는 있음.
    다만 이 문서의 목적은 답변 스타일 제어가 아니라 5825U 환경에서 체감 응답 속도와 메모리 사용량을 안정적으로 잡는 것이므로, 성능 영향이 큰 핵심값만 남기고 나머지는 기본값을 유지함.

4-7. 나중에 추가 실험할 때 기준​

지금 문서는 따라 하기 쉬운 기본값을 제시하는 것이 목적이라 8 / 4096으로 고정했지만, 나중에 성능을 더 보고 싶으면 아래 정도만 비교하면 됨.

  • num_thread 6
  • num_thread 8
  • num_thread 12
  • num_ctx 2048
  • num_ctx 3072
  • num_ctx 4096

짧은 일반 채팅만 빠르게 쓰는 목적이라면 num_ctx 3072나 2048이 더 잘 맞을 수도 있음.
반대로 현재 문서처럼 범용성과 속도의 균형을 같이 보려면 4096이 가장 무난함.

그리고 문서 분석 비중이 커지면 별도 프로필을 하나 더 만들어서 아래처럼 분리해도 됨.

FROM exaone3.5:2.4b
PARAMETER num_thread 8
PARAMETER num_ctx 8192

예시 모델명:

ollama create sleepzz-exaone3.5:2.4b-doc -f Modelfile

즉, 빠른 일반 채팅은 sleepzz-exaone3.5:2.4b-fast, 문서 입력이 긴 작업은 sleepzz-exaone3.5:2.4b-doc처럼 역할별로 나누면 편함.

4-8. 이 문서 기준 권장 결론​

새로 세팅해서 바로 쓸 목적이라면 아래 Modelfile 그대로 시작하면 됨.

FROM exaone3.5:2.4b
PARAMETER num_thread 8
PARAMETER num_ctx 4096

이 설정은 아래 기준으로 잡은 값임.

  • 5825U CPU에서 과하게 무거워지지 않을 것
  • Open WebUI에서 일반 채팅 용도로 무난하게 쓸 수 있을 것
  • 메모리 사용량과 응답 속도 사이 균형이 맞을 것
  • 나중에 num_ctx만 줄이거나 늘려서 추가 실험하기 쉬울 것

5. 기능 복구 및 자원 회수​

평소에는 위 설정 그대로 쓰고, 필요할 때만 기능을 다시 켜거나 메모리를 회수하면 됨.

5-1. RAG나 문서 검색 기능이 다시 필요한 경우​

이 문서는 일반 채팅 속도 최적화가 목적이라 웹 검색과 이미지 생성은 꺼두는 구성을 기준으로 설명했음.
문서 분석이나 검색 기반 작업이 다시 필요해지면 아래처럼 대응하면 됨.

  1. Open WebUI 관리자 화면에서 필요한 기능만 다시 켬.
  2. 웹 검색이 필요하면 Admin Panel > Settings > Web Search에서 다시 활성화함.
  3. 문서 분석이 필요하면 전체 검색 기능을 상시로 켜기보다, 채팅창에 필요한 파일만 직접 업로드해서 분석하는 방식으로 사용하는 것을 권장함.

CPU 기반 홈서버에서는 모든 부가 기능을 항상 켜두는 것보다, 필요할 때만 잠깐 쓰는 방식이 체감 속도에 더 유리함.

5-2. RAM 자원을 즉시 회수하고 싶은 경우​

모델을 메모리에서 내리고 싶으면 아래 명령어를 사용함.

ollama stop sleepzz-exaone3.5:2.4b-fast

원본 모델을 직접 실행 중이었다면 해당 모델명을 넣으면 됨.

ollama stop exaone3.5:2.4b

5-3. Ollama가 이상하게 버티거나 CPU를 계속 먹는 경우​

아래 순서로 정리하면 됨.

sudo pkill -9 ollama
docker compose restart open-webui

이 방식은 정상 종료가 아니라 강제 정리이므로, 정말 멈추지 않거나 CPU를 비정상적으로 계속 먹을 때만 사용하면 됨.

6. 그대로 따라 하면 되는 권장 순서​

처음 세팅하는 사람 기준으로는 아래 순서대로 하면 됨.

  1. Ollama 서비스에 OLLAMA_NUM_PARALLEL=1, OLLAMA_MAX_LOADED_MODELS=1, OLLAMA_KEEP_ALIVE=24h를 넣고 재시작함.
  2. Open WebUI docker-compose.yml에 172.17.0.1과 불필요한 기능 비활성화 환경변수를 넣고 컨테이너를 재시작함.
  3. ~/ollama-profiles/sleepzz-exaone3.5-2.4b-fast/Modelfile을 만들고 ollama create sleepzz-exaone3.5:2.4b-fast -f Modelfile을 실행함.
  4. Open WebUI에서 모델을 sleepzz-exaone3.5:2.4b-fast로 선택함.

여기까지만 해도 5825U + 32GB 홈서버에서 EXAONE 2.4B를 “무난하게 빠른 단일 사용자용 로컬 챗봇”으로 쓰는 기본 세팅은 끝난 거라고 보면 됨.