"Serving" 태그 — 3개 게시물

TL;DR​

vLLM Korea Meetup에 참석하여 LLM 서빙이 "좋은 모델을 띄우는 것"에서 **"클러스터 레벨에서 효율적으로 서빙하는 것"**으로 패러다임이 이동하고 있음을 체감했습니다. Production Stack(스퀴즈비츠), CXL 기반 KV Cache 공유(XCENA), On-Prem GPU 서빙(삼성전자), 오픈소스 모델 공개 노하우(Upstage), HyperCLOVAX 서빙기(네이버클라우드) 등 실전 경험을 들을 수 있었고, 특히 KV Cache 관리가 서빙 성능의 핵심 병목이라는 점이 모든 세션을 관통하는 키워드였습니다.

컨퍼런스 개요​

• 행사명: vLLM Korea Meetup (2nd)
• 일시: 2026년 4월 2일 18:00~22:00
• 장소: 오프라인 (메인홀 + 멀티룸 트랙)
• 주요 테마: vLLM 기반 Production-Level LLM 서빙
• 스폰서: 리벨리온, 스퀴즈비츠

트랙 구성:

시간	Track 1: vLLM with Open Source	Track 2: vLLM in Business
19:00-19:30	vLLM overall update (리벨리온, 레드햇)	-
19:30-20:00	vLLM Production Stack (스퀴즈비츠)	-
20:20-20:50	LMCache & CXL 통합 여정 (XCENA)	온프레미스 GPU x vLLM 서빙기 (삼성전자)
21:00-21:30	오픈소스 모델 공개하기 with vLLM (Upstage)	HyperCLOVAX 옴니 모델 서빙기 (네이버클라우드)

인상 깊었던 세션​

1. vLLM Overall Update (리벨리온 + 레드햇)​

• 핵심 메시지: 지난 6개월간 vLLM 코어에 대규모 변화가 있었으며, v0에서 v1으로의 전환이 완전히 완료됨
• 주요 업데이트:
  • v0 deprecation 완료 (v0.11.0, 2025년 10월) — 디폴트 엔진을 v1으로 전환하고 v0 완전 제거
  • Async Scheduling 도입 — 스케줄링과 실행을 비동기적으로 분리하여 성능 향상
  • Model Runner V2 — 코어 컴포넌트 재설계로 연산·메모리 효율성 개선
• 리벨리온 업데이트: PyTorch 2.0 네이티브 지원으로 NPU 통합 강화, PyTorch RBLN 4월 10일 오픈 예정, Rebel 100 신제품 출시 (H200급 성능)
• Red Hat 업데이트: vLLM 0.18.2 릴리스, Semantic Router v0.2, GuideLLM(벤치마킹 도구), vLLM-Playground(개발 환경)
• 시사점: vLLM의 코어 아키텍처가 성숙 단계에 접어들면서, 이제는 에코시스템(Production Stack, Semantic Router 등)으로 관심이 이동하고 있음

2. vLLM Production Stack (스퀴즈비츠 김태수 CTO)​

• 핵심 메시지: 단일 vLLM 인스턴스만으로는 production-level 서빙이 불가능. Request Router + Shared KV Cache를 얹어야 클러스터 레벨 성능 확보 가능

• 3 Layer 아키텍처:
  1. Inference Amplification: vLLM 엔진의 코어 성능 (PagedAttention 등)
  2. Platform Layer: Observability, 쉬운 배포, Auto-scaling
  3. System Intelligence: Semantic Router를 통한 intelligent routing

• Router가 핵심: Round-robin이 아닌 prefix-aware, KV cache-aware, disaggregation-aware한 전략적 라우팅

• Cluster-level Cache Reuse: LMCache를 통해 다양한 tier storage 지원, Long context에서 prefix 재사용으로 TTFT 극적 단축

• Observability: Jaeger + OpenTelemetry 기반 트레이싱, W3C Propagation 지원 (v0.1.9~), 사전 정의된 대시보드 제공
• Auto-scaling: CPU/GPU 사용량이 아닌 inference-specific metrics(queue depth, latency) 기반
• 성능: 캐시 활용 시 310배 latency 개선, 23배 throughput 향상 (런칭 블로그 기준)

• 시사점: "모델이 아무리 좋아도 serving quality가 중요하다"는 메시지가 인상적. 우리 팀도 단일 인스턴스를 넘어 클러스터 레벨 서빙을 고려할 시점이 올 수 있음

3. LMCache & CXL 통합 여정 (XCENA 이주호님)​

• 핵심 메시지: KV Cache의 2대 과제는 "용량이 너무 크다"와 "빠르게 전송해야 한다". CXL이 이 두 가지를 동시에 해결할 수 있는 기술

• KV Cache 규모감:

  • 70B 모델, 128K context → 40GB
  • 5M context → 320GB
  • 클로드/GPT 급 서비스에서는 500GB 이상 추정

• CXL이란: PCIe 슬롯을 통해 DRAM을 확장하고, 여러 서버가 동일한 메모리에 나노초 레이턴시로 직접 접근(load/store)할 수 있는 프로토콜

• Maru: XCENA가 개발한 CXL 기반 KV Cache 스토리지 엔진 오픈소스 (GitHub)

  • LMCache에 스토리지 백엔드로 통합
  • 네트워크 전송 없이 메모리 주소만 공유하여 KV Cache 공유
  • 벤치마크: CXL 백엔드가 TCP 기반 P2P 대비 우수한 TTFT 성능

• 시사점: CXL은 아직 에코시스템이 초기 단계(스위치 비용 높음)이지만, KV Cache 공유 문제의 근본적 해결책이 될 수 있음. VectorDB에서도 CXL 활용 사례가 늘고 있다고 하니 주시할 필요 있음

업계 트렌드 & 시사점​

• "좋은 모델" → "좋은 서빙"으로 관심 이동: 작년까지는 모델 성능이 화두였지만, 올해는 서빙 품질(latency, throughput, scale-out)이 핵심 키워드
• KV Cache가 모든 세션을 관통하는 주제: Cache 압축(KV-Compress), Cache 공유(LMCache), Cache 저장(CXL) 등 다양한 레이어에서 연구 활발
• Kubernetes 네이티브 inference: Gateway Inference Extension, CRDs 등 K8s 생태계와의 깊은 통합이 진행 중
• PD Disaggregation 확산: Prefill과 Decode를 분리하는 아키텍처가 production 환경에서 실질적으로 도입되기 시작
• Observability의 중요성: 대규모 서빙에서 모니터링/메트릭 수집이 "있으면 좋은 것"에서 "필수"로 격상

팀 적용 포인트​

• LMCache 스터디: Prompt Caching 전략을 이미 다루고 있으니, LMCache를 통한 클러스터 레벨 KV Cache 공유 방안 검토
• Production Stack 테스트: 멀티 인스턴스 서빙이 필요한 시점에 vLLM Production Stack을 레퍼런스로 활용 가능. Helm Chart로 빠르게 PoC 가능
• Inference 메트릭 기반 Auto-scaling: GPU 사용률이 아닌 queue depth, latency 기반 스케일링 방식을 On-Prem 프로젝트에 적용 검토
• CXL 동향 모니터링: 당장 적용은 어렵지만, VectorDB + CXL 조합은 우리 RAG 파이프라인과 직결되는 주제. Maru 프로젝트 워치

전체 후기​

vLLM을 production level에서 실제로 사용해본 경험이 없어서 구체적으로 고민해본 적은 없었는데, 실제 서비스 단계에서 사용하려면 단순히 좋은 모델이 있는 것을 넘어서 latency를 줄이고 throughput도 고려하면서 효율적으로 좋은 성능을 내기 위한 노력이 필요하다는 것을 알게 되었다.

K8s, Helm, CXL, NPU, DRAM 등 인프라/하드웨어 레벨의 내용도 많이 등장해서 공부할 게 많다는 생각이 들었다.

References​

• vLLM Korea Meetup 이벤트 페이지
• vLLM GitHub Releases
• vLLM Production Stack
• Maru - CXL KV Cache Engine (XCENA)
• vLLM-RBLN 문서 (리벨리온)
• LMCache

TL;DR​

AWS EC2에서 GPU 인스턴스를 프로비저닝하는 실무 가이드입니다. P/G/Inf 시리즈 등 인스턴스 타입 선택부터 AMI 설정, 네트워크 구성, 스토리지 최적화까지 GPU 워크로드 배포 시 필수적으로 고려해야 할 사항들을 단계별로 다룹니다. 특히 리전별 가용성, Deep Learning AMI 활용, 캐퍼시티 블록 구매 시 주의사항, 인스턴스 스토어의 임시성 등 실제 운영에서 마주칠 수 있는 함정들을 강조합니다.

Key Takeaways​

• 인스턴스 타입 선택의 중요성: P 시리즈(학습용), G 시리즈(추론/렌더링), Inf 시리즈(추론 최적화)를 목적에 맞게 선택해야 하며, 리전별 가용성 사전 확인 필수 (예: 서울 리전에서는 H100 인스턴스 불가)
• Deep Learning AMI 활용: NVIDIA 드라이버, CUDA, cuDNN이 사전 설치된 AMI를 사용하면 초기 설정 시간을 대폭 절약 가능
• 캐퍼시티 블록 구매 주의: GPU 경쟁 과열 시 1시간 단위 즉시 예약이며 환불 불가이므로 신중한 검토 필요
• 스토리지 전략: gp3/io2 EBS를 기본으로 사용하되, 인스턴스 스토어(NVMe)는 인스턴스 중지 시 데이터 손실되므로 임시 데이터(캐시, 버퍼)에만 활용
• 자원 최소화 원칙: GPU 인스턴스는 고비용 리소스이므로 사용 전 리뷰 프로세스를 거치고, 불필요한 가동 시간 최소화 필요

상세 내용​

GPU 리소스 사용 승인 프로세스​

GPU 인스턴스는 높은 비용이 발생하는 리소스이므로, 사용 전 내부 리뷰 프로세스를 통해 적절한 타입과 용량을 검증받아야 합니다. 이는 불필요한 자원 낭비를 방지하고 비용 효율성을 확보하기 위한 필수 단계입니다.

GPU 인스턴스 타입 이해​

AWS는 용도에 따라 구분된 GPU 인스턴스 패밀리를 제공합니다:

• P 시리즈 (P3, P4, P5): 머신러닝 학습 및 고성능 컴퓨팅(HPC)에 최적화. 대규모 모델 학습이나 분산 학습 워크로드에 적합
• G 시리즈 (G4dn, G5, G6): 그래픽 렌더링, 게임 스트리밍, ML 추론 등 그래픽 집약적 작업에 특화
• Inf 시리즈: Amazon 자체 Inferentia 칩을 사용한 ML 추론 최적화 인스턴스. 비용 대비 추론 성능이 우수

리전별 가용성 사전 확인​

모든 AWS 리전에서 모든 GPU 인스턴스 타입을 사용할 수 있는 것은 아닙니다. 특히 최신 GPU를 탑재한 인스턴스의 경우 제한적입니다.

중요 예시: ap-northeast-2(서울) 리전에서는 H100 1EA 인스턴스(p5.4xlarge) 사용이 불가능합니다. 프로젝트 시작 전 목표 리전에서 필요한 인스턴스 타입의 가용성을 반드시 확인해야 합니다.

AMI 선택 전략​

GPU 워크로드를 위한 인스턴스는 적절한 NVIDIA 드라이버, CUDA 툴킷, cuDNN 등이 사전 설치된 AMI를 사용하는 것이 권장됩니다.

권장 AMI:

• Deep Learning AMI (Ubuntu/Amazon Linux): NVIDIA 드라이버, CUDA, cuDNN이 사전 설치되어 있어 즉시 딥러닝 프레임워크 사용 가능
• AWS Marketplace의 GPU 최적화 AMI: PyTorch, TensorFlow 등 특정 프레임워크가 미리 설정된 이미지

일반 AMI를 선택하는 경우 NVIDIA 드라이버를 수동으로 설치해야 하므로 초기 설정 시간이 증가합니다.

인스턴스 생성 프로세스​

1. 인스턴스 타입 및 용량 결정​

GPU 리소스 검토 과정에서 승인받은 내역을 바탕으로 적절한 인스턴스 유형, VRAM 용량을 선택합니다.

![인스턴스 설정 4](https://prod-files-secure.s3.us-west-2.amazonaws.com/bb84b169-cb88-81fc-90c3-00032f05f905/576f9463-ab24-45ae-a26b-081dc9018a46/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=ASIAZI2LB466XOL2RWTI%2F20260325%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20260325T064504Z&X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEN%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLXdlc3QtMiJHMEUCIQDqPcWww2%2FpQ%2Be1RS0GoLH2PqRGairWhkf5VAqDzJjrDgIgDFxY3LBTm2DChRO06qiqQORa%2BTwwwAGB4Irhokw2nnkqiAQIp%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARAAGgw2Mzc0MjMxODM4MDUiDHWk54hH51hF8rmCtCrcA8SybE%2Bcehb2%2Bxjqq9d6ZrsWnzwPaWhd310kPdYge9qDhfuTquJLhuwQcydhVE3LkJeo8LjYfrE1noL6PPxX5KdYBS2OsUe822kgvtmslCvNWwl897%2Bdlw6A%2FKYpXBadSwsUbtdCmDM2CWy9UnqSPvc1MVuX26RJ7grJzCZ3FwJ%2BN0RioHjzyyQpgHNnBjzCOc5T0P639oKy%2F5%2B9vNAYW4BZqW5X5U50nf%2BhCk8%2F0It2nYhZm2fxi0jHp%2BybPeI2xY1lrcGM%2BB4M1dljm7C%2BdWI2CLLDe1%2FMwhQo5GX10j1ALiHiEBNN8aMePUlAek4CtbmJ7MxtRN1cPhkFfO7pqB1JLKI5PHvDlycWmHih%2BWftE6eJ3Es5DmY8zJ2GlrL6llNGp%2FujdYfYXfszKydwMys5s5FeurJ6IfhXC%2F24QdVJQnLjVJF6SSC29%2B1tF5Iy1gwSQr4K2bgHNkW6qBK%2FNG32gESCN9X6e2adDdyxh3Pe%2B99nKzDAZP9R72XRiOT2GYrwf9tmnGynn3cIQSn2Oc3f16V1srluXAUxx19tmZk39KFjMccQGUO37wfn5dfg6qcm%2BEHlqr3sS7aVdWgrWLKnx%2BN5tkREfAA0DRwnHAXJbwSgcbwIXb7iPkukMLv9jc4GOqUB%2BeM2AI%2BAgNC%2FLYyXnjFoaBm1dUwt%2FtgqITp8E8GcmhAxjiHbWr%2FBsOJShvWO2evdkrG8rq8Wo1o1kFTQBrkPgJGsf%2BSJSvM%2BSZvU1f9XQXFeR%2Bs%2B2oNARyVNv3RFxSbvy9pc84q8KCpgKOIL%2FidQ%2FWiTrZ7MK8ddm6oGiwh%2BheLj3BOrdd9mImjLSbeJBeG%2BcpT38ig

TL;DR​

LLM 서빙에 필요한 GPU 메모리는 M = (P × 4B × Q) / 32 × 1.2 공식으로 계산할 수 있습니다. 여기서 P는 파라미터 수, Q는 정밀도(16 or 32bit), 1.2는 추론 시 활성화 함수 등을 위한 20% 오버헤드입니다. 예를 들어 70B 파라미터 모델을 16-bit로 서빙하려면 약 168GB GPU 메모리가 필요하며, 이는 80GB A100 GPU 2대에 해당합니다. 프로덕션 환경에서 LLM 배포 시 하드웨어 리소스를 정확히 예측하는 것은 비용 최적화와 서비스 안정성 확보에 필수적입니다.

Key Takeaways​

• 메모리 추정 공식 숙지: M = (P × 4B × Q) / 32 × 1.2를 이해하면 모델 배포 전 필요한 GPU 리소스를 정확히 예측하여 인프라 비용을 최적화할 수 있습니다
• 정밀도 선택의 중요성: 16-bit precision을 사용하면 32-bit 대비 메모리 사용량을 절반으로 줄이면서도 대부분의 경우 충분한 정확도를 유지할 수 있습니다
• 20% 오버헤드는 필수: 추론 중 활성화 함수, 중간 결과물, KV 캐시 등을 위한 추가 메모리를 반드시 고려해야 실제 운영 환경에서 OOM 에러를 방지할 수 있습니다
• 멀티-GPU 전략 필요: 대규모 모델(70B+)은 단일 GPU로 서빙이 불가능하므로, 모델 병렬화(Model Parallelism)나 텐서 병렬화(Tensor Parallelism) 전략을 미리 계획해야 합니다

상세 내용​

GPU 메모리 추정이 중요한 이유​

LLM 인터뷰에서 가장 자주 등장하는 질문 중 하나는 "LLM 서빙에 얼마나 많은 GPU 메모리가 필요한가?"입니다. 이는 단순한 암기 문제가 아니라, 프로덕션 환경에서 모델의 배포 가능성과 확장성을 이해하고 있는지를 평가하는 핵심 지표입니다.

GPT, LLaMA 등의 대규모 언어 모델을 다룰 때, 필요한 GPU 메모리를 정확히 예측하는 능력은 필수적입니다. 7B 파라미터 모델이든 그 이상의 대규모 모델이든, 하드웨어 리소스를 올바르게 산정하는 것은 성공적인 배포의 핵심입니다.

GPU 메모리 추정 공식​

LLM 서빙에 필요한 GPU 메모리는 다음 공식으로 계산할 수 있습니다:

공식 구성 요소:

• M: GPU 메모리 (Gigabytes)
• P: 모델의 파라미터 수
• 4B: 파라미터당 4바이트
• Q: 모델 로딩 시 사용하는 비트 수 (16-bit 또는 32-bit)
• 1.2: 20% 오버헤드

공식의 각 구성 요소 상세 분석​

파라미터 수 (P)​

모델의 크기를 나타내는 핵심 지표입니다. 예를 들어 LLaMA 70B 모델은 700억 개의 파라미터를 가지고 있으므로 P = 70,000,000,000이 됩니다. 모델 크기가 클수록 더 많은 메모리가 필요합니다.

파라미터당 바이트 (4B)​

각 파라미터는 일반적으로 4바이트의 메모리를 차지합니다. 이는 부동소수점 연산에서 표준적으로 사용되는 32비트(4바이트) 정밀도를 기반으로 합니다. Half-precision(16비트)을 사용할 경우 이 값은 조정됩니다.

비트 정밀도 (Q)​

• 32-bit (Full Precision): 가장 높은 정확도를 제공하지만 메모리 사용량이 큽니다
• 16-bit (Half Precision): 메모리 사용량을 절반으로 줄이면서도 대부분의 LLM 배포에서 충분한 정확도를 유지합니다
• 많은 LLM 배포에서 16-bit precision이 표준으로 사용되는 이유는 메모리 효율성과 정확도 사이의 최적 균형점이기 때문입니다

오버헤드 (1.2)​

1.2 배수는 단순한 안전 버퍼가 아닙니다. 이는 추론 과정에서 실제로 필요한 추가 메모리를 고려한 것입니다:

• 활성화 함수(Activations): 각 레이어를 통과하며 생성되는 중간 결과물
• KV 캐시: Attention 메커니즘에서 사용되는 Key-Value 캐시
• 그래디언트 및 옵티마이저 상태: 파인튜닝 시 추가로 필요
• 기타 시스템 오버헤드: CUDA 컨텍스트, 드라이버 메모리 등

실전 계산 예시: LLaMA 70B 모델​

70B 파라미터를 가진 LLaMA 모델을 16-bit precision으로 서빙하는 경우를 계산해보겠습니다:

이를 단순화하면:

결과: 약 168GB의 GPU 메모리가 필요합니다.

실무적 함의와 하드웨어 선택​

이 계산은 단순한 이론이 아니라 실제 배포에서 중요한 의사결정 근거가 됩니다:

• 단일 GPU 한계: NVIDIA A100 80GB 단일 GPU로는 이 모델을 서빙할 수 없습니다
• 멀티-GPU 필요: 최소 80GB A100 GPU 2대가 필요합니다
• 대안적 접근:
  • 모델 병렬화(Model Parallelism)를 통한 분산 배포
  • 양자화(Quantization)를 통한 메모리 사용량 감소 (예: 8-bit, 4-bit)
  • 효율적인 Attention 메커니즘 적용 (Flash Attention 등)

비용 최적화를 위한 고려사항​

이 공식을 마스터하면:

1. 인터뷰에서 자신감 있게 답변 가능
2. 배포 전 정확한 하드웨어 요구사항 산정으로 예산 낭비 방지
3. 확장 가능한 아키텍처 설계를 위한 기반 마련
4. 프로덕션 환경에서 OOM 에러 등 치명적인 병목 현상 사전 방지

다음 LLM 배포를 계획할 때, 이 공식을 활용하여 필요한 GPU 메모리를 정확히 추정하고, 효율적이고 안정적인 서비스를 구축할 수 있을 것입니다.

References​

• How Much GPU Memory is Needed to Serve a Large Language Model (LLM)? - Mastering LLM