프로덕션 환경에서 LLM 배포하기: 단계별 가이드
성공적인 데모에서 신뢰할 수 있고 확장 가능하며 비용 효율적인 대규모 언어 모델(LLM) 애플리케이션으로 가는 길은 데모에서는 절대 드러나지 않는 예상치 못한 사용자 입력, 성능 병목 현상, 연쇄적인 시스템 장애, 그리고 통제 불능의 비용 등 수많은 도전 과제로 가득합니다. 이 가이드는 이러한 복잡성을 헤쳐 나가기 위한 포괄적이고 단계별 프레임워크를 제공하여 프로덕션 수준의 LLM 시스템을 구축할 수 있도록 도와줍니다.
학습 내용
이 가이드를 마치면 적절한 모델과 인프라 선택부터 강력한 테스트, 모니터링 및 보안 관행 구현까지 LLM 배포의 전체 수명 주기를 이해하게 됩니다. 프로토타입에서 신뢰할 수 있는 고성능 프로덕션 서비스로 LLM 프로젝트를 전환하기 위한 명확하고 실행 가능한 계획을 얻을 수 있으며, 특히 Kubernetes 기반 배포의 중요한 단계에 중점을 둡니다.
1단계: 기반 - 모델 선택 및 인프라 계획
코드를 작성하기 전에 모델과 이를 실행할 인프라에 대한 중요한 결정을 내려야 합니다. 이 초기 계획 단계는 나중에 비용이 많이 드는 재설계를 피하는 데 중요합니다.
모델 및 하드웨어 선택
오픈 모델의 세계는 방대하며, 올바른 모델을 선택하는 것이 첫 번째 주요 장애물입니다. 추측하지 말고 큐레이션된 허브를 사용하세요. Google Cloud의 Vertex AI Model Garden과 같은 클라우드 제공업체는 최적의 성능을 위한 권장 하드웨어(GPU 유형 및 크기)와 같은 중요한 정보와 함께 200개 이상의 검증된 모델(Gemma, Qwen, Llama 포함)을 제공하는 중앙 집중식 저장소를 제공합니다. 이는 단일 테스트를 실행하기 위해 환경을 설정하는 시간 소모적인 과정을 없애줍니다. 최적화된 서빙 컨테이너(vLLM 또는 SGLang 활용)를 사용하는 "원클릭 배포" 옵션을 자주 찾을 수 있습니다.
하드웨어의 경우 모델의 규모에 따라 GPU 요구 사항이 직접적으로 결정됩니다. 다음은 DigitalOcean과 같은 제공업체의 일반적인 GPU 옵션을 기반으로 한 일반적인 가이드입니다.
| GPU 유형 | 일반적인 사용 사례 | 적합한 모델 크기 |
|---|---|---|
| RTX 4000 Ada | 비용 효율적인 추론 | 소형 모델(7B-13B 파라미터) |
| RTX 6000 Ada | 균형 잡힌 성능 | 중형 모델(13B-34B 파라미터) |
| L40S | 대규모 워크로드를 위한 최대 성능 | 대형 모델(70B+ 파라미터) |
⚠️ 모델 접근 경고: Meta의 Llama와 같은 많은 인기 모델은 다운로드하기 전에 HuggingFace 계정을 보유하고, 액세스를 요청하며, 라이선스 계약에 동의해야 합니다. 프로젝트 일정에 이 승인 시간을 반드시 포함시키세요.
Google AdInline article slot
인프라 선택: Kubernetes 표준
프로덕션 수준의 LLM 배포를 위해 Kubernetes는 사실상의 표준이 되었습니다. 이는 복잡하고 리소스 집약적인 워크로드를 관리하는 데 필수적인 확장성, 복원력 및 클라우드 네이티브 도구를 제공합니다. Google Kubernetes Engine(GKE), Amazon EKS 또는 DigitalOcean Kubernetes(DOKS)와 같은 관리형 Kubernetes 서비스를 사용하든 원칙은 동일합니다.
- GPU 지원: Kubernetes 클러스터에는 GPU 노드가 있어야 합니다. 여기에는 GPU를 포드에서 사용할 수 있도록 NVIDIA 디바이스 플러그인을 설치하는 작업이 포함됩니다.
- 스케줄링: 다중 노드 배포의 경우 Volcano와 같은 고급 스케줄러를 "갱 스케줄링"에 사용하여 분산 학습 또는 추론 작업의 모든 포드가 함께 시작되도록 할 수 있습니다.
2단계: 핵심 배포 - 모델 서빙
가중치를 다운로드하고 requirements.txt와 씨름하는 "구식 방식"은 프로덕션에 적합하지 않습니다. 강력하고 고성능의 서빙 프레임워크가 필요합니다.
vLLM 프로덕션 스택
vLLM은 선도적인 오픈소스 LLM 추론 엔진으로 부상했습니다. 버클리-시카고 대학 협업에서 탄생한 프로덕션 스택은 업스트림 vLLM을 래핑하여 사용 편의성과 고성능을 위해 설계된 프로덕션 최적화 코드베이스를 제공합니다. 주요 기능으로는 다중 모델 지원, 모델 인식 라우팅 및 KV 캐시 오프로딩이 있습니다.
Kubernetes 클러스터에 vLLM 프로덕션 스택을 배포하려면:
- GPU 서버에 Helm이 설치되어 있는지 확인하세요. Helm은 Kubernetes용 패키지 관리자입니다.
- vLLM Helm 저장소를 추가하세요:
sudo helm repo add vllm https://vllm-project.github.io/production-stack - 차트를 설치하세요:
이 명령은 개념 증명으로 소형 예제 모델(sudo helm install vllm vllm/vllm-stack -f tutorials/assets/values-01-minimal-example.yamlfacebook/opt-125m)을 배포합니다.
배포의 핵심 구성은 모델 URL, 복제본 수, CPU, 메모리 및 GPU에 대한 리소스 요청을 지정하는 YAML 파일을 통해 관리됩니다.
배포 검증
설치 후 상태를 모니터링하세요:
sudo kubectl get pods
모든 포드가 Running 상태가 될 때까지 기다리세요. Docker 이미지와 모델 가중치가 다운로드되므로 시간이 걸릴 수 있습니다.
서비스 쿼리
실행 중이면 로컬 포트를 포워딩하고 OpenAI 호환 API 엔드포인트를 쿼리할 수 있습니다:
sudo kubectl port-forward svc/vllm-router-service 30080:80
curl -o- http://localhost:30080/v1/models
이를 통해 모델 서빙 스택이 작동 중인지 확인할 수 있습니다.
3단계: 고급 아키텍처 및 최적화
진정으로 확장 가능하고 프로덕션에 바로 사용할 수 있는 시스템을 위해서는 단일 모델 인스턴스를 넘어서야 합니다. 최신 프레임워크는 더 나은 성능과 리소스 활용을 위해 추론 프로세스를 분리합니다.
llm-d를 사용한 분리형 추론
llm-d는 LLM 추론 파이프라인을 프리필(컨텍스트 처리)과 디코드(토큰 생성)의 두 가지 별도 단계로 분리하는 분산 추론 프레임워크입니다. 이를 통해 각 단계를 독립적으로 최적화하고 확장할 수 있어 더 높은 처리량과 더 나은 GPU 활용이 가능합니다.
Kubernetes에서 분리형 시스템을 배포하려면 Kthena와 같은 특수 연산자를 사용하여 이러한 복잡한 분산 워크로드의 수명 주기와 스케줄링을 관리할 수 있습니다. Kthena는 Volcano를 활용한 갱 스케줄링을 위해 다중 노드 vLLM 서비스를 선언적으로 배포하는 ModelServing 사용자 정의 리소스 정의(CRD)를 제공합니다. 프로세스는 다음과 같습니다:
- 클러스터에 Volcano와 Kthena를 설치합니다.
- 프리필 및 디코드 역할에 대한 엔트리(리더) 및 워커 포드를 정의하는
ModelServing매니페스트를 적용합니다. - 연산자가 포드를 오케스트레이션하면 포드는 Ray를 사용하여 분산 클러스터를 형성합니다.
이 접근 방식은 대규모의 높은 처리량, 낮은 지연 시간 애플리케이션에 이상적이지만 상당한 운영 복잡성을 초래합니다.
4단계: 프로덕션 마인드셋 - 안정성, 관찰 가능성 및 안전
LLM이 서빙되면 실제 작업이 시작됩니다. 프로덕션으로 전환하려면 "작동하게 만들기"에서 "계속 작동하게 유지하기"로의 상당한 마인드셋 전환이 필요합니다.
현실을 위한 테스트
데모의 해피 패스는 프로덕션 현실이 아닙니다. 체계적인 테스트 전략을 채택해야 합니다:
- 견고성 테스트: LLM은 놀라울 정도로 취약합니다. 입력의 사소한 변화가 출력의 큰 변화를 초래할 수 있습니다. 다양한 교란 하에서 모델 동작을 체계적으로 평가하는 자동화된 테스트 프레임워크가 필수적입니다.
- 골든 데이터셋: 대표적인 사용자 쿼리와 예상 출력의 "골든 데이터셋"을 만드세요. 이는 평가 자동화의 기초입니다. 새 모델 버전이나 프롬프트 변경 사항은 배포 전에 이 데이터셋을 기준으로 벤치마킹해야 합니다. 이것 없이 배포하지 마세요.
- RAG 평가: 검색 증강 생성(RAG)을 사용하는 경우 최종 답변뿐만 아니라 컨텍스트 정밀도 및 재현율과 같은 메트릭을 사용하여 검색 품질도 평가하세요.
프로덕션 체크리스트 구현
프로덕션 체크리스트는 규율을 유지하기 위한 필수 도구입니다. 주요 항목은 다음과 같습니다:
- 클라이언트 위생: 타임아웃을 설정하고, 지터를 포함한 재시도를 구현하며, 재시도된 작업에 멱등성 키를 사용하세요.
- 서버 설정: 사용자별로 엄격한 토큰 인식 속도 제한을 구현하세요. 모델의 최대값이 아닌 실제 비즈니스 요구 사항에 따라 컨텍스트 및 출력 상한을 설정하세요.
- 안정성 패턴: 상태 프로브, 회로 차단기 및 정상 종료를 사용하세요. 시스템이 예상대로 복구되는지 확인하기 위해 장애 훈련(예: 메모리 부족 오류 시뮬레이션)을 연습하세요.
사용자가 느끼는 것을 측정
관찰 가능성은 협상의 대상이 아닙니다. 사용자 경험에 직접적인 영향을 미치는 메트릭을 추적하세요:
- 첫 번째 토큰까지의 시간(TTFT) 및 초당 토큰 수(TPS): 인지된 속도의 핵심 지표입니다. p95 백분위수에서 TTFT가 800ms 이하가 되도록 목표를 세우세요.
- 대기열 길이 및 GPU 메모리 여유 공간: 과부하를 방지하고 리소스 사용을 최적화하기 위해 이를 모니터링하세요.
- 유형별 오류율: OOM 오류, 타임아웃 및 클라이언트 오류를 구분하세요.
보안 및 비용
- 보안: 모든 곳에서 TLS를 적용하고, 서비스별 API 키를 사용하며, 기본적으로 원시 프롬프트를 기록하지 마세요.
- 비용: 토큰을 유한한 리소스로 취급하세요. 기능 및 테넌트별 토큰 소모량을 모니터링하고 응답을 적극적으로 캐싱하세요. 더 간단한 작업에는 더 작고 효율적인 모델을 사용하여 비용을 절감하세요.
출처
- vLLM 프로덕션 스택 문서: Helm 차트를 사용하여 Kubernetes에 vLLM을 배포하고 구성을 이해하기 위한 출처.
- Etiq AI – 프로덕션 LLM 시스템: 견고성 테스트, RAG 평가 및 "프로덕션 현실"의 원칙에 대한 출처.
- DigitalOcean – Kubernetes에 llm-d 배포: Kubernetes에 분산 LLM 추론을 배포하고 GPU를 선택하기 위한 실용적인 단계에 대한 출처.
- Google Cloud 블로그 – Vertex AI 오픈 모델 가이드: 관리형 플랫폼에서 모델 검색, 미세 조정 및 최적화된 서빙에 대한 출처.
- vLLM Kthena 문서: Kthena 및 Volcano를 사용하여 다중 노드 vLLM 서비스를 배포하기 위한 출처.
- Hivenet – LLM API를 위한 프로덕션 체크리스트: 클라이언트 위생, 서버 설정, 안정성 및 모니터링을 다루는 실용적인 체크리스트에 대한 출처.
- Deepchecks – 팀은 어떻게 LLMOps를 구현하고 있나요?: LLMOps 참조 아키텍처, 구현 단계 및 운영 모범 사례에 대한 출처.
— Editorial Team
아직 댓글이 없습니다.