LLM 서빙 트레이드오프 고찰
LLM 서비스를 운영한다는 것은 끊임없는 선택의 연속이다.
- 빠르게 할 것인가 VS 많이 처리할 것인가.
- 품질을 지킬 것인가 VS 비용을 낮출 것인가.
- 쉽게 구축할 것인가 VS 성능을 극한까지 뽑을 것인가.
이 세 가지 트레이드오프는 LLM 서빙의 핵심 딜레마이며, 정답은 서비스의 성격에 따라 달라진다.
1. 지연 시간 vs. 처리량 (Latency vs. Throughput)
개념 정리
Latency는 사용자가 체감하는 속도다.
- TTFT(Time To First Token): 요청 후 첫 토큰이 출력되기까지의 시간
- TBT(Time Between Tokens): 토큰과 토큰 사이의 생성 간격
- TPOT (Time per output Token) : 모든 사용자에 대해 출력 토큰을 생성하는 데 걸리는 시간
Throughput은 서버가 단위 시간 안에 처리할 수 있는 양이다.
- 초당 생성 토큰 수(TPS)
- 초당 처리 요청 수(RPS)
LLM 추론의 과제
LLM 추론 최적화는 다음과 같은 일반적인 기술의 이점을 얻는다.
- 연산자 융합: 서로 인접한 다른 연산자를 결합하면지연 시간 개선.
- 양자화: 활성화 및 가중치가 더 적은 비트를 사용하도록 압축.
- 압축: 희소성 또는 증류.
- 병렬화: 여러 장치에 걸친 텐서 병렬화 또는 더 큰 모델을 위한 파이프라인 병렬화.
트레이드오프의 본질
LLM의 계산은 주로 행렬-행렬 곱셈 연산에 의해 결정된다. 작은 차원을 가진 이러한 연산은 대부분의 하드웨어에서 일반적으로 메모리 대역폭에 의해 제한된다.
순환 방식으로 토큰을 생성할 때, 활성화 행렬 차원 중 하나(배치 크기와 시퀀스의 토큰 수로 정의됨)는 작은 배치 크기에서 작다.
처리량을 높이는 가장 직접적인 방법은 배치 사이즈를 키우는 것이다. 여러 요청을 묶어서 GPU에 한 번에 던지면 GPU 활용률이 높아지고 TPS가 올라간다.
그러나 배치를 구성하려면 요청을 모을 때까지 기다려야 한다. 이 대기 시간이 TTFT에 그대로 더해진다.
Batch Size ↑
├── GPU 활용률 ↑ → TPS ↑ → 비용 ↓
└── 요청 대기 시간 ↑ → TTFT ↑ → UX ↓이것이 Latency와 Throughput이 본질적으로 반비례 관계인 이유다. 둘을 동시에 극대화하는 것은 원리적으로 불가능하다.
서비스 유형별 판단 기준
실시간 챗봇 → Low Latency 우선
사용자는 첫 글자가 빠르게 나오는 것을 가장 중요하게 느낀다. 응답 전체 길이보다 반응 시작 속도가 체감 만족도를 결정한다.
배치 사이즈를 작게 유지하고, queue 대기를 최소화하는 방향으로 설계해야 한다. TPS가 다소 낮아지더라도 TTFT를 100ms 이내로 유지하는 것이 목표가 된다.
대량 문서 요약, 배치 처리 → High Throughput 우선
사용자가 실시간으로 결과를 기다리지 않는 작업이다. 수천 건의 문서를 처리하는 파이프라인에서는 개별 요청의 TTFT보다 전체 작업이 끝나는 시간이 중요하다.
배치 사이즈를 최대로 키우고 GPU를 최대한 활용하는 것이 유리하다.
결론
Latency와 Throughput 중 무엇을 우선할지는 기술적 문제가 아니라 비즈니스 문제다. 서비스가 사용자에게 무엇을 약속하느냐에 따라 설계 방향이 결정된다.
2. 모델 품질 vs. 서빙 비용 (모델 크기 및 양자화)
개념 정리
모델 품질은 파라미터 수에 비례하는 경향이 있다. 175B, 405B처럼 파라미터가 많을수록 추론 품질이 높아지지만, 그만큼 VRAM을 많이 차지하고 연산량도 늘어난다.
양자화(Quantization)는 GPU - #5 데이터타입 글 에서 설명한 정밀도 타입 중에서
모델의 가중치를 더 낮은 정밀도로 압축하는 기술이다.
| 원본 타입 | 압축 타입 | 메모리 절감 |
|---|---|---|
| FP32 | FP16 | 50% 절감 |
| FP16 | INT8 | 추가 50% 절감 |
| FP16 | INT4 | 추가 75% 절감 |
트레이드오프의 본질
양자화는 모델을 압축하는 과정에서 수치 정밀도를 희생한다. FP16의 실수를 INT8의 정수로 표현하면 소수점 이하 정보가 손실된다. 이 손실이 모델 출력에 미치는 영향은 작업의 성격에 따라 크게 달라진다.
양자화 강도 ↑ (FP16 → INT8 → INT4)
├── VRAM 사용량 ↓ → 더 큰 배치 가능 → TPS ↑
├── 추론 속도 ↑ → TTFT ↓
├── 서버 비용 ↓ → Cost per 1K Tokens ↓
└── 모델 품질 ↓ → 출력 정확도 미세 손실INT8 수준에서는 대부분의 작업에서 품질 손실이 거의 체감되지 않는다. 그러나 INT4로 내려가면 복잡한 추론이나 수학 문제에서 눈에 띄는 품질 저하가 발생할 수 있다.
서비스 유형별 판단 기준
정확도가 최우선인 서비스 → 원본 모델 유지
법률 문서 검토, 의료 정보 분석, 금융 리포트 생성처럼 오답의 비용이 매우 큰 서비스에서는 품질 손실을 감수하기 어렵다. 이 경우 비용이 높더라도 FP16 원본 모델을 유지하는 것이 합리적이다.
비용 효율이 중요한 서비스 → 양자화 적용
일반 사용자 대상의 챗봇, 콘텐츠 생성 도구처럼 약간의 품질 손실이 허용되는 서비스에서는 INT8 양자화만으로도 서버 비용을 절반 이하로 낮출 수 있다. 동일한 GPU 예산으로 두 배의 사용자를 수용할 수 있게 된다.
결론
양자화는 공짜 점심이 아니다. 그러나 대부분의 일반 서비스에서 INT8 수준의 품질 손실은 사용자가 체감하기 어려운 수준이다. 무조건 원본 모델을 고집하는 것이 능사가 아니며, 실제 서비스 요구사항에 맞는 품질 기준선을 먼저 정하고 그 기준을 만족하는 선에서 최대한 압축하는 것이 현실적인 전략이다.
3. 서빙 프레임워크 선택 (성능 vs. 편의성)
주요 프레임워크 비교
vLLM
PagedAttention을 핵심 기술로 채택하여 KV cache 메모리 효율을 극대화한다. 동일한 GPU 메모리로 더 많은 요청을 동시에 처리할 수 있어 Throughput이 높다. 프로덕션 환경에서 성능을 최우선으로 할 때 가장 많이 선택된다. 다만 설정과 튜닝에 대한 이해가 필요하며, 운영 난이도가 있다.
TensorRT-LLM
NVIDIA가 자사 GPU에 최적화하여 만든 추론 엔진이다. 커널 퓨전, 양자화, 배치 최적화 등을 하드웨어 수준에서 적용하여 이론적 최고 성능에 가장 가깝다. 그러나 NVIDIA GPU에 종속적이며, 모델을 TensorRT 포맷으로 변환하는 과정이 복잡하다. 한 번 구축하면 성능은 최상이지만 모델 교체나 업데이트 시 다시 변환 과정을 거쳐야 한다.
Hugging Face TGI (Text Generation Inference)
Hugging Face 생태계와 자연스럽게 연동되어 모델 교체가 간편하다. 도커 이미지 하나로 빠르게 서빙 환경을 구축할 수 있어 초기 프로토타이핑이나 소규모 서비스에 적합하다. 성능은 vLLM이나 TensorRT-LLM에 비해 낮지만, 운영 편의성과 생태계 지원이 강점이다.
Ollama
로컬 환경 또는 단일 서버에서 빠르게 LLM을 띄우는 데 특화되어 있다. CLI 명령어 하나로 모델을 내려받고 실행할 수 있어 진입 장벽이 매우 낮다. 개발 및 테스트 환경에서 유용하지만, 대규모 트래픽을 감당하는 프로덕션 환경에는 적합하지 않다.
트레이드오프의 본질
성능 최적화
└── TensorRT-LLM > vLLM > TGI > Ollama
운영 편의성 / 빠른 구축
└── Ollama > TGI > vLLM > TensorRT-LLM
모델 교체 유연성
└── TGI > vLLM > Ollama > TensorRT-LLM
하드웨어 종속성
└── TensorRT-LLM (NVIDIA 전용) vs 나머지 (비교적 범용)전체 트레이드오프 구조 정리
세 가지 트레이드오프는 독립적으로 존재하지 않는다. 서로 맞물려 있다.
┌──────────────────────────────────────────────────────────┐
│ │
│ 모델 품질 ↑ → 모델 크기 ↑ → VRAM ↑ │
│ → Batch Size ↓ → TPS ↓ → 비용 ↑ │
│ │
│ 양자화 적용 → VRAM ↓ → Batch Size ↑ → TPS ↑ │
│ → 비용 ↓ but 품질 미세 손실 │
│ │
│ 프레임워크 최적화 → 동일 VRAM으로 더 많은 처리 │
│ → TPS ↑ but 구현/운영 복잡도 ↑ │
│ │
└──────────────────────────────────────────────────────────┘결국 LLM 서빙의 핵심은 세 가지 질문으로 압축된다.
첫째, 사용자에게 무엇을 약속하는가. (Latency vs. Throughput)
둘째, 품질 손실을 어디까지 허용할 수 있는가. (Quality vs. Cost)
셋째, 팀이 얼마나 복잡한 인프라를 운영할 수 있는가. (Performance vs. Operability)
이 세 질문에 대한 답이 서빙 전략 전체를 결정한다.
정답은 없다.
서비스의 성격, 팀의 역량, 비즈니스 목표에 따라 최적의 균형점이 달라진다. 중요한 것은 트레이드오프를 인식하지 못한 채 선택하는 것이 아니라, 무엇을 포기하고 무엇을 얻는지 명확히 이해한 상태에서 결정을 내리는 것이다.
