모델 서빙 시스템 설계 (2)
첫번째 블로그에 이어서, [Hands-On LLM Serving and Optimization] (https://www.oreilly.com/library/view/hands-on-llm-serving/9798341621480/ch03.html) 책에서 모델 서빙 시스템 설계 두번째 블로그 내용은 vLLM 과 멀티 모델 서빙에 대한 핵심 질문과 답변을 작성해 보았다.
이것은 실제 운영 상의 LLM 서빙 운영 관점의 핵심 내용이다.
- vLLM은 단순 Library가 아니라 Serving Engine이다.
- Multi-model Serving은 Memory Management 문제이다.
- Triton은 운영 복잡성을 줄이지만 Lifecycle 관리 책임을 만든다.
- Kubernetes 환경에서는 Model Health Check가 필수이다.
LLM 서빙은 모델 실행보다 리소스 스케줄링(Resource Scheduling)과 라이프사이클 관리가 중요한 시스템 설계 문제이다.
1. vLLM을 사용하면 배칭 문제가 자동으로 해결되는가?
아니다. vLLM은 연속 배칭(Continuous Batching), 페이지 방식 KV 캐시(Paged KV Cache), 스케줄러(Scheduler) 등 핵심 기능을 제공하지만 애플리케이션 레이어 설계가 잘못되면 성능 저하가 발생한다. 좋은 추론 엔진과 좋은 서빙 아키텍처가 함께 필요하다.
2. vLLM = Continuous Batching이라고 설명하면 충분한가?
충분하지 않다. 현대 LLM 서빙 성능은 연속 배칭, KV 캐시 관리, Paged Attention, Prefix Caching, CHunked Prefill, 모델 병렬화(Parallelism), 양자화(Quantization), 커널 최적화과 같은 요소의 결합이다.
3. vLLM이 GPU Memory를 90% 사용하는 것은 비효율인가?
반드시 그렇지 않다. LLM 서빙에서는 남는 GPU Memory를 KV Cache Pool로 활용하여 더 많은 동시 요청을 처리할 수 있다. 중요한 것은 GPU 사용률 자체가 아니라 처리 가능한 요청 수, tokens/sec, latency SLO 만족 여부이다.
4. Frontend와 Inference Backend는 항상 분리해야 하는가?
항상 그런 것은 아니다. 작은 서비스에서는 FastAPI와 vLLM을 함께 구성할 수 있다. 규모가 커지면, Gateway → Router → Scheduler → Inference Server 구조가 필요하다. 분리 기준은 스케일링 요구사항, 장애 격리, 멀티 모델 지원, 멀티 GPU 환경 등이다.
5. LRU가 좋은 모델 축출(Model Eviction) 정책인가?
먼저 LRU가 무엇인가 설명하자면, 영어로 Least Recently Used이다. 가장 오랫동안 참조(사용)되지 않은 항목을 먼저 제거하는 교체 정책을 뜻한다. 따라서, 우리가 교육용으로는 적합하지만 실제 운영(Production)에서는 부족하다. 운영 상에서는, 모델 크기, 로딩 비용, 사용 빈도, 예상 트래픽 등을 함께 고려해야 한다.
6. max_models=2가 리소스 관리 방법인가?
아니다. LLM 서빙에서는 모델 개수보다 실제 메모리 사용량이 중요하다. 고려 요소로 모델 가중치 메모리(Model Weight Memory), KV 캐시 메모리, 런타임 워크스페이스, GPU HBM 가용량 등이다.
7. Cold Start 문제는 LRU보다 Prediction이 더 중요한가?
상황에 따라 그렇다. 해결 방법은 Pre-warming, Traffic Prediction, Hot Model 유지 등이다. 하지만 잘못된 예측은 GPU 비용 증가를 만든다.
8. 멀티 모델 서빙은 항상 비용을 절감하는가?
아니다. 잘못 설계하면 모델 캐시 트래싱(Model Cache Thrashing, 멀티 모델 서빙 환경에서 한정된 GPU/호스트 메모리 용량보다 빈번하게 서로 다른 모델 요청이 들어올 때, 모델을 메모리에 로드(Load)하고 축출(Evict)하는 작업이 쉼 없이 반복되어 실제 추론 연산보다 입출력 및 적재 오버헤드가 시스템 전체를 잠식하는 현상)이 발생한다. 예를 들어, Model A Load → Model B Load → Model A Eviction → Reload이 반복되면 Loading 비용이 증가한다.
9. Triton을 도입하면 복잡도가 사라지는가?
사라지는 것이 아니라 운영 영역으로 이동한다. Triton 제공 기능은 Backend 관리, Model Lifecycle, Batch 처리, Metrics 등이다. 운영자가 관리할 부분은 Model Repository, Version 관리, Deployment, Health Check 등이다.
10. del()에서 Triton Model Unload는 안전한가?
Production에서는 권장하지 않는다. Python destructor 호출 시점은 보장되지 않는다. 명시적인 Lifecycle Manager가 필요하다. 예를 들어, load(), infer(), unload(), shutdown() 등이다.
11. Triton Explicit Loading과 Kubernetes Readiness 연결
Pod Running 상태와 Model Ready 상태는 다르다. 예를 들어, Pod Running = Yes Triton Ready = Yes Model Loaded = No 이면 요청을 처리하면 안 된다. Readiness 조건은 Server Ready AND Required Model Ready 이며, Infrastructure Health와 Model Health는 구분해야 한다.
댓글남기기