엔터프라이즈를 위한 로컬 LLM 확장: 다중 사용자·다중 GPU 프로덕션 배포

단일 머신에서 분산 시스템으로 어떻게 확장하십니까?

로드 밸런싱을 어떻게 구현하십니까?

# 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

이중화와 페일오버를 어떻게 구현하십니까?

무엇을 모니터링해야 하십니까?

• 지연 시간: 요청별 처리 시간 (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 로컬 LLM -- 단일 머신 다중 GPU 설정.
• 로컬 LLM 전력 소비 -- 하드웨어 및 인프라 비용.
• 기업용 RAG 로컬 LLM -- 규모에서의 문서 Q&A.
• 엔터프라이즈 컴플라이언스 로컬 LLM -- 확장된 배포에서의 컴플라이언스 제어.

출처

• Kubernetes Documentation -- kubernetes.io/docs
• vLLM Deployment Guide -- docs.vllm.ai/en/serving/distributed_serving.html
• Prometheus Monitoring -- prometheus.io