이 글은 누구를 위한 것인가
- AI 서비스를 운영 중인데 API 비용이 생각보다 많이 나오는 팀
- 오픈소스 LLM을 직접 서빙하려는 MLOps 엔지니어
- LLM 추론 비용과 성능 사이의 트레이드오프를 이해하고 싶은 분
들어가며
"AI 기능을 출시했더니 인프라 비용이 세 배가 됐어요."
AI 서비스를 운영하는 팀에서 자주 듣는 말이다. ChatGPT나 Claude API를 쓰는 것이 편리하지만, 사용자가 늘수록 비용이 선형적으로 올라간다. 월 수백만 원이 수천만 원이 되는 것은 순식간이다.
더 큰 문제는 응답 속도다. 긴 텍스트를 생성하는 AI 기능에서 사용자가 10~20초를 기다리면 이탈한다. 비용과 속도, 이 두 가지가 AI 서비스 확장의 벽이다.
LLM 추론 최적화는 이 두 문제를 동시에 해결한다. 같은 결과를 더 빠르게, 더 싸게 얻는 방법이다.
1. LLM 추론 비용이 왜 이렇게 비싼가
LLM이 텍스트를 생성하는 방식을 이해해야 비용을 줄일 수 있다.
토큰 단위 생성
LLM은 한 번에 전체 텍스트를 생성하지 않는다. 단어 하나하나(정확히는 토큰 하나하나)를 순서대로 생성한다. "안녕하세요. 저는..." 이 8자를 생성하려면 8번의 추론 연산이 필요하다.
LLM 생성 과정:
1단계: [입력] → "안"
2단계: [입력 + "안"] → "녕"
3단계: [입력 + "안녕"] → "하"
... (계속)
각 단계가 GPU 연산을 필요로 하고, 생성 길이가 길수록 비용이 올라간다.
GPU 비용의 현실
A100 80GB GPU 1장: 클라우드 기준 시간당 약 34달러
LLaMA-3 70B 모델 서빙: 48장의 A100 필요
→ 시간당 $12~$32의 GPU 비용
이를 토큰 비용으로 환산하면, 자체 서빙은 GPT-4o API보다 저렴할 수 있지만 운영 인력과 인프라 관리 비용이 추가된다.
2. 양자화(Quantization): 모델을 압축하는 방법
가장 즉각적인 비용 절감 방법이다. 양자화는 모델의 수치 정밀도를 낮춰 파일 크기와 메모리 사용량을 줄이는 기술이다.
비유하자면, 고화질 사진(원본 모델)을 압축 저장하는 것과 같다. 사진이 약간 흐려지지만(성능 약간 저하), 파일 크기가 훨씬 작아진다(메모리/비용 절감).
양자화 레벨 비교
| 정밀도 | 비트 수 | 메모리 | 성능 저하 | 적합한 케이스 |
|---|---|---|---|---|
| FP32 (원본) | 32bit | 100% | 없음 | 학습, 파인튜닝 |
| FP16 / BF16 | 16bit | 50% | 거의 없음 | 프로덕션 기본 |
| INT8 | 8bit | 25% | 1~2% | 속도/비용 균형 |
| INT4 | 4bit | 12.5% | 3~5% | 최대 압축 |
| GGUF (Q4_K_M) | ~4.5bit | ~15% | 2~4% | CPU/소형 서버 |
INT4 양자화를 적용하면 원본 대비 메모리 사용량이 약 87.5% 줄어든다. 즉, GPU 한 장에서 처리 가능한 모델 크기가 8배 커진다.
국내에서 많이 쓰는 양자화 방법
GPTQ: GPU에서 빠른 추론, INT4/INT8 지원. 한 번 양자화하면 재사용. AWQ: GPTQ보다 품질 손실 적음. 최근 더 선호되는 추세. GGUF: CPU에서도 실행 가능. Ollama가 이 형식 사용.
3. Speculative Decoding: 두 모델이 협력해 속도 높이기
앞서 설명했듯 LLM은 토큰을 하나씩 생성한다. 이것이 근본적인 속도 제한이다. Speculative Decoding은 이 제약을 영리하게 우회한다.
아이디어: 작은 모델이 초안을 빠르게 쓰고, 큰 모델이 검토한다.
[일반 추론]
큰 모델이 토큰 하나 생성 → 큰 모델이 다음 토큰 생성 → ...
(느리지만 품질 높음)
[Speculative Decoding]
1. 작은 모델이 N개 토큰을 빠르게 생성 (초안)
2. 큰 모델이 초안 N개를 한 번에 검토 (병렬 처리)
3. 큰 모델이 동의하면 통과, 틀리면 그 지점부터 다시
→ 평균 2~3배 속도 향상, 품질 손실 없음
비유하자면, 주니어가 빠르게 초안을 작성하고 시니어가 검토하는 것과 같다. 대부분 초안이 괜찮으면 빠르게 통과되고, 문제있는 부분만 수정된다.
Claude API에서는 이미 내부적으로 유사한 최적화가 적용되어 있다. 오픈소스 모델을 자체 서빙할 때 vLLM 등의 프레임워크에서 활성화할 수 있다.
4. KV Cache: 반복 계산을 피하는 방법
LLM이 토큰을 생성할 때, 이전에 생성한 모든 토큰에 대한 계산을 매번 반복한다. KV Cache는 이 중간 계산 결과를 저장해두고 재사용한다.
[KV Cache 없음]
1번째 토큰 생성: [입력 전체] 계산
2번째 토큰 생성: [입력 전체 + 1번째 토큰] 다시 계산
3번째 토큰 생성: [입력 전체 + 1,2번째 토큰] 다시 계산
[KV Cache 있음]
1번째 토큰 생성: [입력 전체] 계산 + 결과 저장(캐시)
2번째 토큰 생성: [캐시 재사용 + 새 토큰만] 계산
3번째 토큰 생성: [캐시 재사용 + 새 토큰만] 계산
KV Cache는 이미 대부분의 프레임워크에 기본 탑재되어 있다. 중요한 것은 캐시 메모리 관리다. vLLM의 PagedAttention은 KV Cache를 메모리 페이지 단위로 동적 관리해 GPU 메모리 활용률을 크게 높인다.
5. vLLM: 오픈소스 LLM 서빙의 표준
vLLM은 UC Berkeley에서 만든 오픈소스 LLM 추론 라이브러리다. 현재 오픈소스 LLM 자체 서빙에서 사실상 표준이 됐다.
vLLM의 주요 기능
- PagedAttention으로 GPU 메모리 효율 최대화
- 연속 배칭(Continuous Batching): 여러 요청을 동시에 처리
- Speculative Decoding 지원
- OpenAI API 호환 인터페이스
# vLLM으로 LLaMA-3 8B 모델 서빙
pip install vllm
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Meta-Llama-3-8B-Instruct \
--tensor-parallel-size 1 \
--quantization awq
이 명령 하나로 OpenAI API 호환 서버가 실행된다. 기존 OpenAI API를 쓰는 코드를 vLLM 서버로 전환하는 데 코드 변경이 거의 없다.
6. 배포 환경별 최적화 선택 기준
모든 상황에 맞는 단일 해법은 없다. 환경에 따라 최적 전략이 다르다.
| 환경 | 권장 전략 | 이유 |
|---|---|---|
| 스타트업 초기 (트래픽 낮음) | Claude/GPT API 그대로 사용 | 자체 인프라 운영 비용이 더 높음 |
| 월 API 비용 500만원+ | 오픈소스 모델 + vLLM 검토 | ROI 시작 |
| 응답 속도 중요 | Speculative Decoding + 소형 모델 | 품질 유지하며 속도 2배 향상 |
| 메모리 제한 | INT4 양자화 | GPU 메모리 87% 절감 |
| CPU만 있는 환경 | GGUF + llama.cpp | GPU 없이도 서빙 가능 |
| 엣지/모바일 | 온디바이스 모델 (LiteRT) | 클라우드 의존 없음 |
7. 2026년 추론 비용 트렌드
지난 2년간 LLM 추론 비용은 극적으로 하락했다.
- GPT-4 (2023년): 1M 토큰당 $30
- GPT-4o (2024년): 1M 토큰당 $2.5
- 최신 모델들 (2026년): 유사 성능에 $0.1~0.5 수준
하드웨어와 소프트웨어 최적화의 결합으로 비용이 10배 이상 하락했다. 이 추세는 계속될 전망이다. 지금 당장 최대 최적화에 투자하는 것보다, 서비스를 키우면서 단계별로 최적화를 도입하는 접근이 현명하다.
맺으며
LLM 추론 최적화는 AI 서비스가 규모를 키울 때 반드시 마주치는 문제다. 양자화로 메모리를 줄이고, Speculative Decoding으로 속도를 높이고, vLLM으로 GPU 활용률을 최대화하는 것이 기본 조합이다.
하지만 처음부터 모든 것을 최적화할 필요는 없다. 서비스가 성장해서 비용이 실질적인 문제가 될 때 단계적으로 도입하는 것이 맞다. 지금 가장 중요한 건 서비스를 키우는 것이다.