로컬 LLM TCO 분석: 온프레미스 전환 손익분기점 계산법과 GPU 활용률 최적화 전략

클라우드 LLM API 청구서를 받아들고 한숨 쉬어본 적 있을 것이다. "그냥 우리 서버에 올리면 싸지 않나?"라는 생각, 저도 꽤 오래 해왔다. 그런데 막상 계산해보면 API 요금과 온프레미스 TCO는 전혀 다른 구조를 갖고 있고, 어느 쪽이 유리한지는 의외로 단순한 기준 몇 가지로 갈린다. API 청구서만 보고 온프레미스로 전환했다가 예상치 못한 인건비와 운영 복잡도에 당황하는 팀도 있고, 반대로 손익분기점 계산 없이 계속 API 요금을 내는 팀도 있다.

이 글에서는 로컬 LLM의 TCO를 어떻게 구조화하고, 어느 시점에 온프레미스 전환이 경제적으로 유리해지는지 실제 수치와 함께 짚어본다. GPU 활용률, 양자화, 추론 엔진 선택까지 비용에 직접 영향을 주는 기술 결정들을 같이 살펴볼 예정이다.

이 글을 읽고 나면 자신의 워크로드를 기준으로 30분 안에 손익분기점을 직접 계산할 수 있을 것이다. "로컬이 싸다, 비싸다" 이분법이 아니라, 내 상황에 맞는 판단 기준을 갖추는 게 목표다.

핵심 개념

TCO: API 요금만 보면 계산이 틀리는 이유

TCO(Total Cost of Ownership): 시스템을 도입·운영하는 데 드는 모든 비용의 합산. 하드웨어 구매비, 인건비, 전력비, 감가상각까지 포함한다.

클라우드 API 요금은 직관적이다. "이번 달 토큰 몇 개 썼으니 얼마"로 끝난다. 온프레미스는 비용 구조가 여러 레이어에 분산돼 있어서 처음에 전체 그림을 잡기 어렵다. 대략적인 비율로 보면 이렇다.

여기서 놓치기 가장 쉬운 게 인건비다. GPU 서버 구매는 일회성이지만, 24/7 모니터링과 모델 업데이트·장애 대응을 담당하는 MLOps 엔지니어 인건비는 매달 발생한다. 소규모 팀에서 이걸 겸업으로 처리하려다 운영 부담이 예상보다 훨씬 커지는 경우가 많다. 저도 팀 내에서 "인건비 빼고 하드웨어 비용만 API랑 비교했더니 싸 보이더라"는 이야기를 꽤 들어봤는데, 그게 가장 흔한 계산 실수다.

손익분기점: 핵심 변수는 일일 토큰 처리량

솔직히 저도 처음엔 "GPU 한 대 사면 API보다 싸지 않을까?" 수준으로 막연하게 생각했다. 실제로 계산해보니 일일 토큰 처리량이 핵심 변수고, 거기에 GPU 활용률이 결합되면 결론이 확연하게 달라진다.

일 토큰 처리량 < 3M     → 클라우드 API가 경제적
일 토큰 처리량 3M~10M   → 하이브리드 접근 검토
일 토큰 처리량 > 10M    → 온프레미스 전환 권장
GPU 활용률 목표 ≥ 80%  → TCO 최적화 달성 가능

GPU 활용률이 80% 이상 지속될 때 3년 기준으로 온프레미스가 클라우드 대비 토큰당 비용에서 상당한 우위를 보인다는 분석이 여러 TCO 비교 리포트(SitePoint, Spheron)에서 공통으로 나온다. 반대로 활용률이 70% 미만이면 클라우드가 더 경제적이다. GPU가 놀고 있어도 감가상각은 계속 진행되니까.

감가상각(Depreciation): 고정자산의 가치가 시간이 지남에 따라 감소하는 것을 비용으로 인식하는 회계 처리. H100 서버를 3년에 걸쳐 비용으로 분산 계상할 경우, 월별 하드웨어 비용을 실제 구매가와 다르게 인식하게 된다.

비용을 크게 바꾸는 기술 결정들

모델 운영 방식에서 몇 가지 기술 선택이 TCO에 직접 영향을 준다. 여기서 두 생태계를 구분해두는 게 나중에 혼란을 줄인다.

• llama.cpp + GGUF: CPU 환경, 개인 개발자나 엣지 배포에 적합. GPU VRAM 없이도 동작한다.
• vLLM + AWQ/FP8: GPU 프로덕션 서빙 전용. 고처리량이 필요한 서비스 환경에서 쓴다.

두 도구는 같은 목적으로 교환 가능한 게 아니라, 배포 맥락 자체가 다르다.

양자화(Quantization)

원본 FP16 모델을 INT4(GGUF)나 AWQ(GPU 최적화 4bit)로 양자화하면 메모리와 에너지 사용량을 크게 줄일 수 있다. 품질 손실은 대부분의 실무 태스크에서 무시할 수 있는 수준이다.

VRAM 요구량을 직접 계산하고 싶다면 다음 공식이 유용하다.

FP16 기준 최소 VRAM(GB) ≈ 모델 파라미터 수(B) × 2
AWQ/INT4 기준         ≈ 모델 파라미터 수(B) × 0.5

예를 들어 7B 모델은 FP16으로 약 14GB, AWQ로 약 4GB가 필요하다. RTX 4090(24GB)이면 7B AWQ는 여유 있게, 14B AWQ도 타이트하게 올라간다.

# [llama.cpp 생태계] CPU/엣지 환경: GGUF INT4 변환
# llama.cpp 저장소를 클론하고 의존성을 먼저 설치한다
git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements.txt
 
python llama.cpp/convert_hf_to_gguf.py ./model_hf \
  --outtype q4_k_m \
  --outfile model-q4_k_m.gguf
 
# [vLLM 생태계] GPU 프로덕션 환경: AWQ 모델 서빙 (공식 권장 방식)
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --quantization awq \
  --dtype half \
  --gpu-memory-utilization 0.9

연속 배칭(Continuous Batching)

정적 배칭은 요청 하나가 끝날 때까지 다음 요청이 GPU를 쓰지 못한다. 연속 배칭은 진행 중인 배치에 새 요청을 끼워넣어 GPU 활용률을 극대화한다. vLLM이 이를 기본으로 지원하고, 짧은 시퀀스가 혼합된 고동시성 환경에서는 정적 배칭 대비 처리량이 최대 수십 배까지 차이 나기도 한다. 이 과정에서 GPU 메모리를 효율적으로 관리하기 위해 vLLM은 내부적으로 PagedAttention이라는 기법을 사용한다.

KV 캐시와 프리픽스 캐싱

같은 시스템 프롬프트를 반복해서 쓰는 경우 — RAG 시스템에서 매번 동일한 컨텍스트를 앞에 붙이는 패턴이 대표적이다 — 프리픽스 캐싱을 활성화하면 반복 구간의 연산 비용을 대폭 줄일 수 있다.

from vllm import LLM, SamplingParams
 
llm = LLM(
    model="Qwen/Qwen2.5-14B-Instruct",
    enable_prefix_caching=True,
    gpu_memory_utilization=0.9,
    max_model_len=8192,
)

실전 적용

세 가지 예시를 워크로드 규모와 복잡도에 따라 점층적으로 살펴본다. 단순 고용량 처리 → 하이브리드 라우팅 → 소형 모델 선택 순서로, 자신의 상황에 가장 가까운 것부터 보면 빠르다.

예시 1: 금융권 문서 처리 — 고용량·고보안 워크로드

대출 심사서 분류, 계약서 요약, 규정 준수 검토처럼 하루에도 수백만 건씩 처리해야 하는 워크로드다. 이런 경우 외부 API로 보내는 것 자체가 데이터 보안 이슈가 되기도 해서, 온프레미스 전환 이유가 비용보다 보안인 경우도 많다.

환경변수로 모델 경로를 관리하면 스테이징/프로덕션 환경 전환이 편해진다. vLLM 서버는 CLI 방식이 현재 공식 권장 방식이다.

# vLLM 서버 기동 (프로덕션 권장 방식)
export MODEL_PATH=/models/qwen2.5-14b-awq
 
vllm serve $MODEL_PATH \
  --quantization awq \
  --gpu-memory-utilization 0.85 \
  --enable-prefix-caching \
  --max-num-seqs 256 \
  --tensor-parallel-size 2 \
  --host 0.0.0.0 \
  --port 8000

--tensor-parallel-size: 모델 가중치를 여러 GPU에 나눠 적재하는 옵션. --tensor-parallel-size 2는 GPU 2장에 분산한다. 단일 GPU VRAM으로 모델이 올라가지 않을 때 사용한다.

# 클라이언트 측: 기존 OpenAI SDK를 그대로 로컬 엔드포인트에 연결
from openai import AsyncOpenAI
 
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed",  # 로컬 서버라 인증 불필요
)
 
async def classify_document(text: str) -> str:
    response = await client.chat.completions.create(
        model="qwen2.5-14b-awq",
        messages=[
            {"role": "system", "content": COMPLIANCE_SYSTEM_PROMPT},  # 반복 프리픽스 → 캐싱됨
            {"role": "user", "content": text},
        ],
        max_tokens=512,
        temperature=0.1,
    )
    return response.choices[0].message.content

OpenAI 호환 API를 그대로 로컬 엔드포인트로 연결할 수 있다는 점이 이전 마찰을 최소화해준다. api_key="not-needed" 같은 작은 디테일도 실제 연동할 때 꽤 도움이 된다.

예시 2: 하이브리드 RAG — 비용과 품질의 균형점

모든 트래픽을 온프레미스로 처리하는 게 항상 최적은 아니다. 임베딩, 검색, 1차 요약은 로컬 소형 모델로 처리하고, 복잡한 추론이 필요한 최종 답변 생성만 클라우드 프론티어 모델로 라우팅하는 방식이 현실적이다. 일반 기업에서 로컬 90% + 클라우드 10% 구성이 점점 표준으로 자리잡고 있다.

여기서 사용하는 LiteLLM은 OpenAI, Anthropic, 로컬 모델 등 다양한 LLM 제공자를 단일 인터페이스로 호출할 수 있게 해주는 Python 라이브러리다. 라우팅 로직을 한 곳에 모아두기가 편해서 하이브리드 구성에 잘 맞는다.

from litellm import completion
from prometheus_client import Counter
 
local_requests = Counter("llm_local_requests_total", "로컬 처리 요청 수")
cloud_requests = Counter("llm_cloud_requests_total", "클라우드 처리 요청 수")
 
def route_by_complexity(query: str, context_length: int) -> str:
    is_complex = (
        context_length > 4000 or
        any(kw in query for kw in ["추론", "분석", "비교", "평가"])
    )
 
    if is_complex:
        model = "gpt-4o"
        cloud_requests.inc()
    else:
        model = "openai/local-qwen-7b"  # 로컬 vLLM 엔드포인트
        local_requests.inc()
 
    response = completion(
        model=model,
        messages=[{"role": "user", "content": query}],
        api_base="http://localhost:8000/v1" if "local" in model else None,
    )
    return response.choices[0].message.content

키워드 매칭 방식의 한계도 있다. "단순한 질문인데 '분석'이라는 단어가 들어가면 클라우드로 라우팅된다"는 식의 오분류가 생길 수 있다. 더 정교하게 가려면 임베딩 기반 유사도나 토큰 수 기반 분류를 고려해볼 수 있다. 팀 내에서도 처음엔 이 키워드 방식으로 시작해서 로그를 쌓고, 오분류 케이스가 누적되면 개선하는 방식으로 점진적으로 접근했다.

예시 3: 소형 모델 선택 — 20B 미만으로도 충분한 경우

Ptolemay의 TCO 분석에 따르면 기업 LLM 워크로드의 상당 부분은 소형 모델로 처리 가능하다. 소형 모델로 전환하면 에너지 비용도 크게 줄어드는데, 막상 팀 내에서 "작은 모델로 과연 될까?"라는 우려 때문에 오버스펙 모델을 계속 쓰는 경우가 많다. 저도 처음엔 그랬다. 실제로 태스크별 벤치마크를 돌려보니 7B로 충분한 케이스가 생각보다 많았다.

VRAM 계산 공식을 기억해두면 모델 선택 전에 빠르게 가능 여부를 체크해볼 수 있다.

# AWQ 기준: 파라미터 수(B) × 0.5 ≈ 최소 VRAM(GB)
 
# 7B AWQ → 약 4GB VRAM, RTX 4090 1장으로 충분
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --host 0.0.0.0 --port 8000 \
  --gpu-memory-utilization 0.85
 
# 14B AWQ → 약 8GB VRAM, RTX 4090 1장에 타이트하게 가능
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
  --host 0.0.0.0 --port 8000 \
  --gpu-memory-utilization 0.90
 
# 70B FP8 → H100 2장 또는 RTX 4090 4장
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --quantization fp8 \
  --tensor-parallel-size 2

FP8: 8비트 부동소수점 양자화. FP16 대비 메모리를 절반으로 줄이면서 AWQ(INT4)보다 정밀도 손실이 적다. 대형 모델(70B+)을 프로덕션에서 서빙할 때 정밀도와 메모리 효율의 균형점으로 자주 선택된다.

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

1. GPU 활용률을 모니터링하지 않는 것 — 비싼 H100을 30% 활용률로 운영하면서 "온프레미스가 더 싸다"고 믿는 경우가 있다. dcgm-exporter(NVIDIA GPU의 활용률·온도·전력을 Prometheus가 수집할 수 있는 형식으로 노출하는 컨테이너)를 띄우고 Grafana 대시보드를 연결하는 것만으로도 문제를 바로 발견할 수 있다.

2. 인건비를 TCO에서 제외하는 것 — 하드웨어 비용만 API 요금과 비교하는 계산은 반드시 틀린다. MLOps 엔지니어 1명의 연봉이 GPU 서버 한두 대 값과 맞먹는 경우가 많다.

3. 소형 모델 검증 없이 대형 모델부터 도입하는 것 — 7B 모델로 충분히 처리되는 태스크에 70B를 쓰는 건 비용 낭비다. 실제 태스크별로 모델 크기 벤치마크를 먼저 돌려보는 것을 권장한다.

마치며

로컬 LLM의 TCO 최적화는 기술 선택 이전에 워크로드 측정에서 시작된다. 일일 토큰 처리량, GPU 활용률, 보안 요구사항, 운영 인력 여건을 먼저 숫자로 파악하면, 클라우드 vs 온프레미스 vs 하이브리드 중 어떤 조합이 맞는지 스스로 계산할 수 있다.

지금 바로 시작해볼 수 있는 3단계:

1. 현재 API 비용과 토큰 처리량을 측정해볼 수 있습니다. OpenAI 대시보드나 로그에서 최근 30일 토큰 사용량을 뽑아보면 된다. 일 평균 처리량이 3M 토큰을 넘는지 여부가 온프레미스 검토를 시작하는 첫 기준이 된다.

2. 소형 모델 로컬 테스트를 해볼 수 있습니다. ollama pull qwen2.5:7b 한 줄로 로컬 환경에 모델을 띄우고, 실제 서비스 데이터 샘플 100건을 넣어 출력 품질을 비교해보면 좋다. 생각보다 작은 모델로도 충분한 경우가 많다.

3. Prometheus로 GPU 활용률 추적 체계를 갖춰볼 수 있습니다. GPU 서버가 있다면 dcgm-exporter를 컨테이너로 띄우고 Grafana 대시보드를 연결해 활용률이 80%에 근접하는지 모니터링해보는 것을 권장한다. 이 숫자 하나가 TCO 최적화의 핵심 지표다.

참고 자료

• Local LLMs vs Cloud APIs: 2026 Total Cost of Ownership Analysis | SitePoint
• LLM Total Cost of Ownership 2025: Build vs Buy Math | Ptolemay
• On-Premise vs Cloud: Generative AI TCO 2026 Edition | Lenovo Press
• LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis | Spheron Blog
• The True Cost of Running Open-Source LLMs: A TCO Analysis | CloudAtler
• LLM Inference Benchmarking: How Much Does Your LLM Inference Cost? | NVIDIA Technical Blog
• Ollama vs vLLM: Local vs Production LLM Inference Compared (2026) | Spheron Blog
• Speculative Decoding: Achieving 2-3x LLM Inference Speedup | Introl Blog
• LLM Inference Optimization: Quantization, KV Cache, and Serving at Scale
• 로컬 LLM 시대 완전 가이드: Llama, Qwen, Mistral, vLLM, 양자화, Apple Silicon | youngju.dev
• 프롬프트 캐싱 인프라: LLM 비용과 지연 시간 절감 | Introl Blog
• LLM Inference Trilemma: Throughput, Latency, Cost | DigitalOcean
• 5 Best Open-Source LLM Inference Engines in 2026 | DEV Community
• Enterprise Local LLM Deployment: vLLM, GPUs | SitePoint