Key Takeaways
- 단일 머신: GPU 1개, 동시 사용자 10~50명, 간단한 설정.
- 다중 GPU: GPU 2~8개, 사용자 50~200명, Kubernetes 오케스트레이션.
- 엔터프라이즈: GPU 5~50개, 사용자 500명 이상, 분산·고가용성 구성.
- 로드 밸런싱: 라운드 로빈 방식으로 GPU 파드 전반에 요청을 분산.
- 모니터링: 지연 시간, 큐 깊이, GPU 사용률, 오류율을 추적.
- 2026년 4월 기준, Kubernetes는 엔터프라이즈 LLM 배포의 표준입니다.
단일 머신에서 분산 시스템으로 어떻게 확장하십니까?
단일 머신에서 프로덕션으로의 발전 단계:
| 배포 단계 | GPU 수 | 동시 사용자 수 | SLA 가동률 | 인프라 설정 |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
로드 밸런싱을 어떻게 구현하십니까?
로드 밸런서는 요청을 가장 여유로운 인퍼런스 파드로 라우팅합니다.
라운드 로빈: 파드 전반에 균등하게 분산합니다 (가장 단순).
최소 부하: 큐가 가장 짧은 파드로 전송합니다 (더 낮은 지연 시간).
고정 세션: 동일 사용자가 항상 동일 파드를 사용합니다 (컨텍스트 유지에 유용하나 파드 장애 시 위험).
# Kubernetes Service with load balancing
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # Round-robin across pods이중화와 페일오버를 어떻게 구현하십니까?
고가용성은 이중화된 구성 요소를 필요로 합니다:
파드 복제본: 여러 인퍼런스 파드를 구성합니다. 하나가 중단되어도 나머지 파드가 요청을 처리합니다.
헬스 체크: Kubernetes가 비정상 파드를 자동으로 제거합니다.
스토리지 이중화: 모델 파일이 노드 전반에 복제됩니다.
DNS 페일오버: 전체 데이터센터가 장애를 일으킬 경우, 트래픽을 백업 시설로 라우팅합니다.
무엇을 모니터링해야 하십니까?
엔터프라이즈 배포에서 반드시 모니터링해야 할 항목:
- 지연 시간: 요청별 처리 시간 (p50, p95, p99 백분위수).
- 큐 깊이: 대기 중인 요청 수. 10 초과 시 과부하 상태.
- GPU 사용률: 70~90% 유지를 목표로 합니다. 50% 미만 시 과잉 프로비저닝, 95% 초과 시 부족 프로비저닝.
- 오류율: 실패한 요청의 비율. 0.1% 미만이어야 합니다.
- 처리량: 전체 파드에서의 초당 토큰 수.
- 가동률: 서비스 이용 가능 시간의 비율 (목표: 99.9%).
- 쿼리당 비용: 요청당 비용 (하드웨어 상각 포함).
규모에서 비용을 어떻게 최적화하십니까?
규모에서는 다음 사항에 집중하십시오:
- GPU 사용률: 높을수록 요청당 비용이 낮아집니다. 80~90% 목표.
- 모델 양자화: Q4 vs FP16은 VRAM을 4배 절약하며 속도는 동일합니다. 필요한 GPU 수가 줄어듭니다.
- 배치 크기: 배치가 클수록 요청당 비용이 낮아집니다 (단, 지연 시간 증가).
- 오토스케일링: 야간에는 축소하고 낮에는 확장합니다 (클라우드 비용 30~50% 절감).
- 멀티 테넌시: GPU당 2~3개의 모델을 실행합니다 (VRAM이 허용하는 경우). 사용률이 높아집니다.
흔한 엔터프라이즈 확장 실수
- 지연 시간 요건을 무시하는 것. 배포 전에 p99 지연 시간 SLA를 합의하십시오. 2초의 지연 시간은 사용자가 불만을 제기하기 전까지는 괜찮아 보일 수 있습니다.
- 피크에 맞춰 과잉 프로비저닝하는 것. 하루 2시간만 100명의 동시 사용자가 접속한다면 종일 100명에 맞는 하드웨어를 구매할 필요가 없습니다. 오토스케일링을 활용하십시오.
- 장애 격리가 미흡한 것. 파드 하나의 충돌이 로드 밸런서 전체를 중단시킨다면 아키텍처가 잘못된 것입니다. 장애 시나리오를 반드시 테스트하십시오.
- 올바른 메트릭을 모니터링하지 않는 것. GPU 사용률만 모니터링하고 지연 시간을 모니터링하지 않는 것은 잘못된 접근입니다. 지연 시간이 사용자 경험에 직접적인 영향을 미칩니다.
- 오픈소스 도구가 엔터프라이즈 규모로 확장된다고 가정하는 것. Ollama는 1명의 사용자에게는 훌륭하게 작동합니다. 500명의 동시 사용자에게는 엔터프라이즈 모니터링과 오케스트레이션이 필요합니다.
로컬 LLM 확장에 대한 자주 묻는 질문
엔터프라이즈 배포에 GPU가 몇 개나 필요합니까?
동시 접속 수와 지연 시간 요건에 따라 다릅니다. 7B 모델에서 동시 사용자 100명: GPU 약 5~8개. 동시 사용자 500명: GPU 20~30개. 공식: (동시 사용자 수 × 예상 지연 시간) / (GPU당 토큰/초).
로드 밸런싱과 오토스케일링의 차이는 무엇입니까?
로드 밸런싱은 기존 파드 전반에 요청을 분산합니다. 오토스케일링은 부하에 따라 파드를 추가하거나 제거합니다. 두 가지 모두 필요합니다. 로드 밸런싱은 현재 작업을 분산하고, 오토스케일링은 용량을 조정합니다.
GPU 장애를 어떻게 처리합니까?
Kubernetes가 파드를 정상 GPU로 자동 재스케줄링합니다. GPU 하나가 장애를 일으키면 Kubernetes가 이를 사용 불가 상태로 표시하고 트래픽을 다른 GPU로 라우팅합니다. 이중화를 확보하십시오. GPU 8개가 필요하다면 10개를 프로비저닝하십시오.
어떤 지연 시간 SLA를 목표로 해야 합니까?
챗봇의 경우 p99 지연 시간 2초 미만이 표준입니다. 실시간 자동완성의 경우 p99 500ms 미만. 사용자 경험을 기반으로 SLA를 정의한 후, 이를 충족하는 하드웨어와 배치 크기를 선택하십시오.
분산 인퍼런스 클러스터를 어떻게 모니터링합니까?
파드별 및 클러스터 전체 단위로 모니터링하십시오: GPU 사용률, 큐 깊이, 지연 시간 (p50/p95/p99), 오류율, 처리량, 가동률. Prometheus + Grafana 또는 동급 도구를 활용하십시오.
온프레미스 확장이 클라우드보다 저렴합니까?
규모에서는 그렇습니다. 손익분기점은 월 약 50만 토큰입니다. 온프레미스: 초기 비용이 높고 ($500k~200만 달러 하드웨어), 요청당 비용은 낮습니다. 클라우드: 초기 비용 없음, 요청당 비용 높음 ($0.15~60/100만 토큰).
출처
- Kubernetes Documentation -- kubernetes.io/docs
- vLLM Deployment Guide -- docs.vllm.ai/en/serving/distributed_serving.html
- Prometheus Monitoring -- prometheus.io