쿠버네티스 환경에서 LLM 추론 최적화

Ask a Question
, ,
1

LLM 모델을 쿠버네티스에 배포할 때, TensorRT, vLLM, 또는 DeepSpeed와 같은 추론 최적화 도구들을 활용해 latency를 줄이기 위한 구성 전략은 무엇인가요?
Kubernetes 리소스 요청/제한 설정과 PodAffinity, GPU sharing 전략은 어떻게 조정해야 하는가요?

1 Like
2

[CloudBro AI Bot Response]
LLM 모델을 쿠버네티스에 배포하면서 TensorRT, vLLM, DeepSpeed 같은 추론 최적화 도구를 활용해 latency를 줄이려면, 다음과 같은 구성 전략과 리소스 조정 방안을 고려해야 합니다.

1. 추론 최적화 도구 활용 전략

  • TensorRT
    • NVIDIA GPU 환경에서 모델을 INT8/FP16으로 변환하여 추론 속도를 크게 향상시킵니다.
    • 쿠버네티스에서는 GPU 할당이 필수이며, TensorRT가 지원하는 GPU 아키텍처를 확인해야 합니다.
    • TensorRT 엔진 생성 시간을 고려해, 모델 빌드 단계를 미리 수행하거나 초기화 시점에 캐싱하는 방식을 권장합니다.
  • vLLM
    • 대규모 LLM을 효율적으로 배치 처리하고 GPU 메모리 사용을 최적화하는 라이브러리입니다.
    • 멀티-스레딩과 배치 크기 조절로 throughput과 latency를 균형 있게 맞출 수 있습니다.
    • 쿠버네티스에서는 Pod 내에서 여러 worker 프로세스를 병렬로 실행하거나, 여러 Pod 간 분산 추론을 고려합니다.
  • DeepSpeed
    • ZeRO 최적화와 같은 메모리 분산 기법으로 대형 모델을 여러 GPU에 걸쳐 효율적으로 추론합니다.
    • DeepSpeed inference 모드를 사용해 latency 최적화가 가능하며, GPU 간 통신 비용을 줄이기 위해 RDMA나 NVLink 지원 환경이 좋습니다.
    • 쿠버네티스에서는 GPU가 충분히 연결된 노드에 Pod를 스케줄링하는 것이 중요합니다.

2. Kubernetes 리소스 요청/제한 설정

  • GPU 요청(request) 및 제한(limit)
    • GPU는 쿠버네티스에서 엄격히 할당되므로, 정확한 GPU 수량 요청이 필수입니다.
    • resources.requests와 resources.limits에 동일한 GPU 수를 명시하여 스케줄링 안정성을 확보합니다.
    • CPU 및 메모리도 모델과 최적화 도구 요구사항에 맞게 충분히 할당해야 합니다.
  • CPU/메모리 설정
    • TensorRT나 DeepSpeed는 CPU 오버헤드가 적지만, vLLM은 CPU 스레드를 많이 사용할 수 있으므로 CPU 요청량을 넉넉히 잡는 것이 좋습니다.
    • 메모리는 GPU 메모리 외에도 Pod의 전체 메모리 제한에 영향을 미치므로, OOM 발생 방지를 위해 충분히 할당합니다.

3. PodAffinity 및 GPU 공유 전략

  • PodAffinity / AntiAffinity
    • DeepSpeed 같은 분산 추론은 GPU가 빠르게 연결된 노드(예: NVLink 지원 노드)에 Pod를 모아서 배치하는 것이 유리합니다.
    • 반대로 GPU 리소스가 부족하거나 노드별 과부하를 막기 위해 anti-affinity를 설정할 수도 있습니다.
    • 노드 레이블과 토폴로지 도메인을 활용해 GPU 네트워크 대역폭과 지연시간을 고려한 스케줄링 정책을 만듭니다.
  • GPU Sharing
    • 기본적으로 쿠버네티스는 GPU를 exclusive하게 할당하지만, NVIDIA의 MIG(Multi-Instance GPU) 기능을 활용하면 GPU를 여러 Pod가 나눠 쓸 수 있습니다.
    • TensorRT와 DeepSpeed는 보통 exclusive GPU 사용을 권장하지만, vLLM 같은 경우는 GPU 메모리와 코어 활용에 따라 MIG나 GPU 가상화를 활용할 여지가 있습니다.
    • GPU 공유 시에는 성능 저하와 리소스 경합을 반드시 모니터링해야 합니다.

4. 추가 고려사항

  • Auto-scaling
    • 추론 부하에 따라 Horizontal Pod Autoscaler(HPA) 또는 Vertical Pod Autoscaler(VPA)를 설정해 리소스를 자동 조절합니다.
    • GPU 리소스는 HPA가 직접 조절하기 어렵지만, Custom Metrics와 연동해 Pod 수를 조절할 수 있습니다.
  • 모니터링 및 로깅
    • GPU 사용량, 메모리, latency 지표를 Prometheus + Grafana 등으로 모니터링해 병목 구간을 파악합니다.
    • 추론 최적화 도구별 로그와 메트릭을 수집해 문제 발생 시 빠르게 대응할 수 있도록 합니다.

요약하면, LLM 추론 최적화 도

3

우선 TensorRT, vLLM, DeepSpeed 같은 도구는 역할이 조금씩 다릅니다. 추론 속도만 놓고 보면 TensorRT-LLM이 가장 강력하다는 의견이 많고, 동시 요청이 많을 때 안정적인 처리를 원하시면 vLLM이 적합하다는 이야기가 자주 등장합니다. DeepSpeed는 “속도 향상”보다는 “큰 모델을 여러 GPU에 나눠 얹을 때” 도움이 되는 도구에 가깝습니다. 어떤 도구를 쓰느냐가 latency에 직접 영향을 주기 때문에, 사용 목적을 먼저 정하는 것이 중요하다는 인상이 강했습니다.

Kubernetes 설정에서는 몇 가지 단순한 원칙만 기억해도 성능 차이가 꽤 난다고 합니다.
첫 번째로는 GPU를 되도록 독점시키는 방식입니다. MIG나 time-slicing처럼 쪼개 쓰는 방식은 GPU 메모리 대역폭이 분산되기 때문에 LLM 추론 속도가 느려지는 경우가 많습니다. 가능하면 “1 Pod = 1 GPU” 구조로 배치하는 것이 단순하면서도 효과적인 전략으로 자주 언급되었습니다.

두 번째는 CPU와 메모리를 안정적으로 고정시키는 방식입니다. 추론 과정에서 토크나이저나 전처리·후처리 작업이 CPU에서도 꽤 이뤄지기 때문에, 리소스 요청/제한을 동일하게 맞추고(예: request=limit), CPU Manager의 core pinning을 사용하면 지연 편차가 크게 줄어든다는 사례가 많았습니다. 모델은 GPU에서 돌지만 “느린 것은 CPU”라는 말이 나온 이유도 이 부분 때문입니다.

세 번째는 Pod가 어떤 노드에 배치되는지 신경 쓰는 방식입니다. GPU마다 NVLink 유무, NUMA 구성, 메모리 대역폭이 다르기 때문에 Kubernetes가 임의로 스케줄링하도록 두면 성능 차이가 생길 수 있습니다. 그래서 “특정 라벨이 붙은 노드에만 LLM Pod를 배치”하는 식의 NodeSelector나 PodAffinity가 실무에서 자주 사용된다고 합니다. 쉽게 말하면 “성능 좋은 GPU가 있는 노드에만 모델 서버를 올린다” 정도입니다.

마지막으로 모델을 미리 예열(Warm-up) 해두는 전략이 있습니다. LLM의 첫 요청은 항상 느린데, vLLM이나 TensorRT는 초기 로딩 과정이 길어서 “Ready로 뜬 뒤에도 실제로는 준비가 안 된 상태”일 때가 있습니다. 그래서 Pod가 기동되자마자 특정 입력으로 warm-up을 미리 한 번 돌려두면, 이후 부하 상황에서 훨씬 안정적으로 응답한다는 조언이 많았습니다. 오토스케일링을 쓰는 환경이라면 특히 효과가 크다고 합니다.

정리하면, LLM을 Kubernetes에서 빠르게 돌리기 위한 현실적인 접근은 (1) 최적화 엔진 선택, (2) GPU 독점, (3) CPU 고정, (4) 노드 배치 전략, (5) 사전 예열 정도가 핵심이었습니다. 제가 직접 운영해본 내용은 아니지만, 여러 기술 자료에서 공통적으로 언급된 부분을 정리해보면 이 정도가 가장 단순하면서도 효과적인 조합으로 보였습니다.