Ollama로 로컬 LLM 서빙 — deepseek-r1 14B를 실제 프로덕션에 쓰는 법

OpenAI API 비용이 아까워서 로컬 LLM으로 전환한 건 아닙니다. 제 동기는 두 가지였어요. 첫째, 외부 API 장애 시에도 검색/임베딩이 죽지 않게 하려고. 둘째, 한국어 정책 문서라는 도메인 특성상 큰 모델보다 임베딩 품질이 더 중요해서입니다.

왜 Ollama인가

Ollama는 설치와 운영이 직관적입니다. ollama pull nomic-embed-text 한 줄로 모델을 받고, HTTP 11434 포트로 REST 요청을 날리면 됩니다. llama.cpp를 직접 빌드하는 것보다 훨씬 덜 귀찮습니다. 공식 문서는 github.com/ollama/ollama에 잘 정리되어 있습니다.

사용 중인 모델

• nomic-embed-text — 768차원 임베딩. 정책 검색 용도.
• llama3.2:3b — 빠른 추천/요약용. Oracle에서도 초당 15~20 tokens.
• deepseek-r1:14b — 주간 심층 분석 배치. 체감 느리지만 추론 품질이 확연히 좋음.

3-Tier Fallback 구조

제 설정은 임베딩 요청을 다음 순서로 시도합니다. Oracle이 가장 가까운 배치 경로라 1순위이지만 자원이 제일 적고, New Mac은 자원이 많지만 낮 시간에는 개발 작업이 겹칩니다.

1. Oracle(168.107.1.170:11434, Cloudflare Tunnel 경유)
2. Old Mac(10.200.0.2:11434, TB5 사설망)
3. New Mac(10.200.0.1:11434, TB5 사설망)

각 tier는 타임아웃 3초, 실패 시 다음 tier로 즉시 전환합니다. 세 곳이 모두 죽으면 그때 429를 리턴합니다. 2026년 운영 중 3-tier 전체 실패는 0회였습니다.

HTTP 요청 예시

curl http://10.200.0.2:11434/api/embeddings \
  -d '{"model":"nomic-embed-text","prompt":"청년도약계좌 자격"}'

응답은 768차원 float 배열입니다. 평균 지연 50~120ms(Mac M4), Oracle ARM에서는 180~250ms 정도 나옵니다.

운영하면서 배운 것

• 메모리 계산은 FP16 기준 — 14B 모델은 FP16으로 약 28GB가 필요합니다. Q4 양자화 버전이면 10GB 정도로 줄지만 품질이 체감될 만큼 떨어집니다. 배치 용도라면 Q5 권장.
• Keep-alive 설정 — OLLAMA_KEEP_ALIVE=30m으로 모델을 메모리에 오래 유지해야 첫 요청 지연(cold load 4~8초)을 피할 수 있습니다.
• 동시성 제한 — 기본 num_parallel은 4지만, Oracle ARM에서는 2로 낮추는 게 안전합니다. 초과하면 OOM으로 프로세스가 죽습니다.
• 로그 회전 — Ollama 로그는 기본 회전이 없어 한두 달 두면 수 GB까지 쌓입니다. logrotate 필수.

임베딩 일관성

3개 tier가 같은 모델 버전을 써야 임베딩 벡터가 호환됩니다. 저는 모델 업그레이드 시 3개 노드 동시 배포 후, 기존 11,600건을 전량 재임베딩합니다. 이 작업은 Oracle 야간 배치로 3~4시간에 끝납니다. pgvector로 검색하는 쪽 이야기는 하이브리드 검색 글에 이어집니다.

OpenAI와 비교

품질은 분명 OpenAI text-embedding-3-small이 더 좋습니다. 하지만 비용(월 0원 vs 월 수만 원)과 장애 격리 측면에서 로컬 Ollama가 제 유스케이스에는 맞았습니다. 사용자 대면 실시간 채팅은 Groq의 llama-3.3-70b를 씁니다 — 초당 300+ tokens로 체감이 압도적이라서요.

주의할 점

Ollama는 보안 측면에서 기본값이 느슨합니다. 11434 포트는 반드시 내부망이나 Cloudflare Tunnel 뒤에만 노출하세요. 공용 인터넷에 직접 열면 즉시 악용됩니다. 전체 인프라 구성은 소개 페이지, Oracle 세팅은 Oracle ARM 운영기에서 이어집니다.

문의는 연락처로 부탁드립니다.