GPT-4o나 Claude를 매일 쓰다 보면 월말 청구서가 예상을 벗어나는 경험을 하게 된다. 그렇다고 무조건 로컬 모델로 옮기면 품질 저하나 하드웨어 한계에 부딪힌다. 정답은 중간 어딘가에 있다 — 작업 유형에 따라 로컬과 클라우드를 구분하고, 라우팅을 자동화해 비용을 실질적으로 줄이는 것이다.
내 LLM 비용은 어디서 발생하는가
월간 청구액은 세 변수가 결정한다. 토큰 단가, 모델 선택, 호출 빈도. 이 셋 중 하나만 잘못 잡아도 비용이 쉽게 2~3배 뛴다.
비용이 조용히 쌓이는 패턴이 있다. 긴 문서를 여러 번 요약에 반복 투입하거나, 코드 생성 루프에서 같은 맥락을 매번 재전송하거나, 실험적 프롬프트를 고가 모델로 여러 번 돌리는 경우다. 이런 호출은 개별 비용이 작아 눈에 잘 안 띄지만 월간으로 합산하면 전체의 60~70%를 차지하는 경우가 많다.
하이브리드 전략이 효과적인 사용자 프로필은 명확하다. 월 $20 이상 API 비용을 지출하고, 전체 호출 중 반복 작업(요약, 분류, 번역, 형식 변환)이 50%를 넘는다면 로컬 전환만으로도 청구액을 절반 이하로 줄일 수 있다.
로컬 vs 클라우드: 워크로드 분류 기준
모든 작업을 로컬로 돌리려는 시도는 대부분 실패한다. 장비 한계와 품질 문제가 동시에 발생하기 때문이다. 작업 유형을 먼저 분류하는 것이 핵심이다.
로컬 처리에 적합한 작업은 반복·일괄 요약, 코드 포매팅, 단순 분류, 개인 정보가 포함된 텍스트 처리, 인터넷 연결 없이 실행 가능한 작업이다. 응답 품질보다 처리량이 중요하고, 출력이 약간 거칠어도 수용 가능한 경우에 해당한다.
클라우드가 필요한 작업은 다르다. 최신 정보를 기반으로 한 답변, 복잡한 다단계 추론, 멀티모달 입력(이미지·코드 혼합), 고품질 코드 리뷰, 그리고 단 한 번의 응답이 중요한 의사결정에 쓰일 경우다.
판단 기준을 세 질문으로 좁힐 수 있다.
- 데이터에 민감 정보가 있는가? → 있다면 로컬 우선
- 컨텍스트가 4K 토큰을 넘는가? → 넘는다면 로컬 처리 부담 증가, 클라우드 고려
- 출력 품질이 중요한 작업인가? → 중요하다면 클라우드
이 세 질문만으로 대부분의 호출을 분류할 수 있다.
로컬 환경 현실 점검: 내 장비로 뭘 돌릴 수 있나
로컬 AI를 고려할 때 가장 먼저 해야 할 일은 VRAM 확인이다. 모델 홍보 문구보다 양자화 기준 실제 메모리 요구량이 중요하다.
Llama 4 Scout 공식 발표에 따르면 Q4_K_M 양자화 기준 약 61GB VRAM이 필요하다. RTX 3090(24GB)은 물론 RTX 4090(24GB)으로도 전체 모델 실행이 불가능하다. 일반 맥북이나 RTX 3080 이하 환경에서는 Llama 4 Scout 대신 Gemma 4 27B 또는 Qwen3 14B 이하를 로컬 베이스라인으로 선택하는 것이 현실적이다.
주의: Meta는 2026년 4월 클로즈드소스 Muse Spark를 출시하며 Llama 오픈소스 플래그십 후속 개발을 사실상 중단했다. Llama 4 기반으로 로컬 인프라를 구성하기 전에 Meta 모델 의존도를 재평가할 필요가 있다.
VRAM 구간별 현실적인 선택지는 다음과 같다.
| 환경 | 권장 모델 |
|---|---|
| 8GB VRAM | Qwen3 4B, Gemma 4 4B |
| 16GB VRAM | Qwen3 8B, Gemma 4 12B |
| 24GB VRAM | Qwen3 14B, Gemma 4 27B |
| Apple Unified Memory 32GB+ | Gemma 4 31B, Qwen3 30B |
Ollama v0.23(2026-05 배포)은 Llama 4·Gemma 4 공식 지원을 안정화했다. Apple Silicon에서는 Gemma 4 MTP speculative decoding이 적용되어 31B 모델 기준 약 2배 이상 추론 속도 향상을 제공한다. 맥에서 로컬 모델을 돌린다면 Ollama v0.23 이상으로 업데이트하는 것만으로도 체감 속도가 달라진다.
저비용 클라우드 API 조합: 가격-성능 현황
로컬 배포를 고집할 이유가 예전보다 줄었다. API 가격이 빠르게 내려오고 있어서다.
OpenRouter에서 제공하는 DeepSeek V3.2 기준으로 입력 $0.252/M 토큰, 출력 $0.378/M 토큰(OpenRouter 마켓플레이스 기준, 2025-12 시점)이다. 단, 마켓플레이스 가격은 DeepSeek 공식 API 가격과 다를 수 있고 수시로 변동하므로, 실제 사용 전 반드시 최신 가격을 확인하길 권장한다.
이 수준의 가격이면 반복 요약처럼 로컬 처리를 고려했던 작업도 API로 돌려도 비용 부담이 크지 않다. 중요한 것은 작업 복잡도에 따라 모델 tier를 나누는 것이다.
- 경량 요약·분류·번역: 로컬 소형 모델(Qwen3 4B, Gemma 4 4B) 또는 저비용 API
- 중간 코드 생성·구조화 출력: DeepSeek V3.2 수준의 중간 tier API
- 복잡 추론·아키텍처 설계·고품질 리뷰: 상위 플랜 클라우드 모델
OpenRouter를 쓰면 모델별 가격을 실시간으로 비교하면서 적절한 모델을 선택할 수 있다. 단일 공급사 API에 묶이지 않는다는 것도 장점이다.
하이브리드 라우팅 실전 구성
가장 실용적인 방법은 LiteLLM 프록시로 Ollama와 클라우드 API를 단일 엔드포인트로 통합하는 것이다. 기존 앱 코드를 거의 수정하지 않고 라우팅 규칙만 바꿀 수 있다.
LiteLLM 설치 후 litellm_config.yaml을 만든다.
model_list:
- model_name: local-fast
litellm_params:
model: ollama/gemma4:27b
api_base: http://localhost:11434
- model_name: cloud-mid
litellm_params:
model: openrouter/deepseek/deepseek-v3.2
api_key: os.environ/OPENROUTER_API_KEY
router_settings:
routing_strategy: simple-shuffle
fallbacks:
- {"local-fast": ["cloud-mid"]}
context_window_fallbacks:
- {"local-fast": ["cloud-mid"]}
num_retries: 2
timeout: 30이 설정으로 litellm --config litellm_config.yaml을 실행하면 http://localhost:4000에 OpenAI 호환 엔드포인트가 열린다.
라우팅 규칙을 더 세밀하게 잡으려면 앱 코드에서 모델명만 환경 변수로 지정한다.
import os
model = os.getenv("LLM_MODEL", "local-fast")
# 기존 openai.ChatCompletion 호출 그대로 유지컨텍스트 4K 이하 + 오프라인 처리 가능한 작업은 LLM_MODEL=local-fast, 그 외는 LLM_MODEL=cloud-mid로 전환한다. 로컬 추론이 30초 이상 걸리거나 실패하면 fallbacks 설정에 의해 클라우드로 자동 전환된다.
비용 모니터링과 월간 최적화 루프
라우팅을 설정했다면 실제 절감 효과를 측정해야 한다. 측정 없이는 최적화가 없다.
LiteLLM 프록시는 기본적으로 http://localhost:4000/ui에 대시보드를 제공한다. 여기서 모델별 호출 횟수, 토큰 수, 추정 비용을 확인할 수 있다. OpenRouter도 마이 계정의 Activity 탭에서 모델별 지출 내역을 제공한다.
월간 리뷰 시 확인할 항목은 세 가지다.
- 로컬 처리 비율: 전체 호출 대비
local-fast로 처리된 비율. 50% 미만이면 분류 기준을 재점검한다. - 클라우드 폴백 빈도:
local-fast에서cloud-mid로 자동 전환된 비율. 20%를 넘으면 로컬 장비 성능이나 타임아웃 설정을 조정한다. - 모델별 비용 효율: 호출당 평균 토큰 수와 비용. 로컬에서 처리했다면 절감됐을 추정 비용을 계산한다.
‘로컬 처리 절감 추정액’ 계산식은 단순하다.
절감 추정액 = 로컬 처리 토큰 수 × 클라우드 동급 모델 단가예를 들어 로컬에서 월 500만 토큰을 처리했고, 클라우드 동급 모델이 $0.252/M이라면 월 $1.26 절감이다. 처리 규모가 커질수록 이 수치도 비례해서 커진다.
단계별 실행 가이드
1단계. 현재 API 지출 현황 파악
지난 30일 청구 내역에서 모델별·작업별 지출을 뽑는다. OpenAI 대시보드의 Usage 탭, Anthropic Console의 Usage 페이지에서 확인할 수 있다. 전체 호출 중 반복 작업(요약, 분류, 번역)이 차지하는 비율을 추정한다.
2단계. 장비 VRAM 확인 후 로컬 모델 선정
nvidia-smi(NVIDIA GPU) 또는 macOS 시스템 정보에서 VRAM을 확인한다. 앞서 제시한 VRAM 구간 표를 기준으로 로컬에서 실행할 모델을 선정한다. Apple Silicon 32GB 이상이라면 Gemma 4 31B가 가장 실용적인 선택이다.
3단계. Ollama 설치 및 모델 풀
# macOS
brew install ollama
ollama serve &
# 모델 다운로드 (예시)
ollama pull gemma4:27b
ollama pull qwen3:14bollama run gemma4:27b로 로컬 추론이 정상 동작하는지 확인한다.
4단계. LiteLLM 프록시 설정
pip install litellm위의 litellm_config.yaml을 작성하고 litellm --config litellm_config.yaml로 프록시를 실행한다. 기존 앱의 api_base를 http://localhost:4000으로 변경하는 것만으로 통합이 완료된다.
5단계. 라우팅 규칙 적용 및 검증
첫 1~2주는 전체 호출을 로컬로 먼저 보내고 폴백 로그를 확인한다. 폴백이 잦다면 타임아웃을 늘리거나 해당 작업 유형을 클라우드 기본으로 조정한다. 2주 후 대시보드에서 모델별 처리 비율과 추정 절감액을 확인하고, 로컬 처리 비율이 40% 미만이면 분류 기준을 다시 조정한다.
자주 묻는 질문
Q. Ollama와 LiteLLM 없이 단순하게 로컬 모델만 써도 되지 않나요?
가능하지만 유연성이 떨어진다. Ollama만 쓰면 로컬 모델로 처리하기 어려운 작업에서 수동으로 클라우드 API를 바꿔야 한다. LiteLLM 프록시를 쓰면 앱 코드 수정 없이 환경 변수나 설정 파일 변경만으로 모델을 전환할 수 있고, 폴백도 자동화된다. 작업 규모가 작다면 단순 Ollama만으로도 충분하지만, 여러 앱에서 LLM을 쓴다면 프록시 레이어를 한 번 설정해두는 것이 장기적으로 낫다.
Q. DeepSeek V3.2가 OpenRouter에서 가장 저렴한 선택인가요?
2025-12 시점 기준으로는 경쟁력 있는 가격대였지만, API 시장은 빠르게 변한다. OpenRouter에서 같은 작업 유형에 쓸 수 있는 모델들의 가격을 직접 비교하는 것이 더 정확하다. 특히 출력 토큰 단가가 입력보다 보통 높으므로, 긴 응답이 필요한 작업이라면 출력 단가 위주로 비교해야 한다. OpenRouter 모델 목록에서 실시간 가격을 확인하길 권장한다.
Q. 로컬 모델 품질이 너무 낮아서 실용적이지 않은 것 같은데, 어떤 작업에서 가장 차이가 적나요?
구조화된 출력(JSON 형식 변환, 표 정리), 단순 요약, 짧은 텍스트 분류, 코드 포매팅은 14B~27B 모델도 클라우드 대형 모델과 거의 차이가 없다. 반면 복잡한 다단계 수학 문제, 긴 코드베이스 전체를 이해하는 리팩토링, 뉘앙스가 중요한 번역은 여전히 클라우드 상위 모델이 우월하다. 작업 유형을 이 두 그룹으로 나눠 처음에는 단순 작업만 로컬로 보내는 것이 실패 없이 시작하는 방법이다.