On-Premise vLLM × 쿠버네티스 확장을 위한 llm-d
작성: 나무기술 CAIO 고우주
들어가며
생성형 AI가 단순 응답형을 넘어 에이전틱(Agentic) AI로 진화하면서, 엔터프라이즈는 이제 모델의 품질이 아닌 “어떻게 온프레미스에서 안정적·경제적으로 서빙할 것인가”라는 인프라 질문에 직면했다. 특히 GPU 한두 장으로는 담을 수 없는 중·대형 SLM(Small/Medium Language Model)을 수백~수천 명이 동시에 사용하는 업무 환경에서는, 인퍼런스 엔진과 이를 확장하는 쿠버네티스 오케스트레이션 레이어가 TCO를 결정짓는 핵심 요소가 됐다.
이번 호에서는 나무기술 NAA(NAMU Agentic AI) 플랫폼이 어떻게 vLLM과 llm-d를 엔터프라이즈 급으로 제공하는지, 그리고 실제 GPU 구성(L40S / H200 / B300)별 가용 범위와 양자화 전략을 데이터 기반으로 살펴본다.
1. NAMU GPU Calculator(https://gpu.namu.ai.kr) — 과소/과잉 투자를 피하는 사이징 도구
1-1. 왜 별도 도구가 필요한가
SLM 온프레미스 배포에서 가장 빈번한 실패는 사이징 실수다. 두 가지 방향 모두 치명적이다.
- 과소 투자 — VRAM이 모자라 모델이 올라가지도 않는다. 가중치는 올라가도 KV 캐시가 부족해 컨텍스트가 8K로 잘린다.
- 과잉 투자 — H200 8장 $200K 서버를 깔았는데 실제로는 7B 모델만 서빙해서 GPU 활용률이 10% 수준에 머문다.
이 둘 사이의 “정확한 사이즈”를 찾으려면 모델 파라미터 크기, 양자화 정밀도, 런타임 오버헤드, KV 캐시 요구량, 목표 컨텍스트 길이, 목표 동시 배치 크기를 모두 계산해야 한다. 나무기술은 이 계산을 웹 도구로 공개했다.
1-2. LLM GPU Calculator
LLM GPU Calculator (https://gpu.namu.ai.kr)는 나무기술이 공개한 오픈 액세스 사이징 도구다. 사용 흐름은 다음과 같다.
- 모델 선택 — Qwen3.5-122B, Llama-3.3-70B, DeepSeek-V3.2, Mistral-Large-3 등 주요 OSS 모델을 프리셋으로 제공한다.
- 정밀도 선택 — BF16 원본, FP8 공식판, Q4 GGUF, NVFP4(Blackwell Ultra 전용) 중 선택한다.
- 목표 컨텍스트동시성 입력 — 예: 32K 컨텍스트 × 16 배치.
- GPU 구성 추천 — L40S · H200 · B300 각각에 대해 최소 필요 장수, 권장 구성, llm-d 멀티 서버 확장 시나리오를 산출한다.
1-3. 계산의 근간이 되는 공식
도구 내부의 핵심 계산식은 투명하게 공개돼 있다.
1-4. 실전 활용 패턴
| 상황 | 도구 사용 팁 |
| 신규 PoC 제안 | “Qwen3.5-122B FP8, 128K 컨텍스트” 입력 → “H200 × 4장” 권장값으로 제안서 작성 |
| 기존 자산 최대 활용 | 보유 GPU(예: L40S 8장)를 고정 → “가능한 최대 모델/컨텍스트” 역산 |
| 스케일 플랜 | 1서버 구성 → 2서버 llm-d DP 확장 시 처리량 증가율 시뮬레이션 |
| 양자화 ROI 판단 | BF16 대비 FP8 전환 시 GPU 장수 절감 효과를 수치로 확인 |
2. SLM 서빙에서 vLLM과 llm-d가 왜 필요한가
2-1. LLM 서빙은 전통적인 웹 서빙이 아니다
엔터프라이즈 AI 팀이 가장 먼저 부딪히는 현실은 “LLM 서빙은 REST API 서빙과 본질이 다르다”는 것이다. LLM 워크로드에는 전통적 서빙과 구분되는 네 가지 특성이 있다.
| 특성 | 전통적 웹 서빙 | LLM 서빙 |
| 상태(State) | Stateless | KV 캐시를 유지해야 효율이 나옴 |
| 지연 시간 | 밀리초 단위 응답 | 수백 ms ~ 수십 초(토큰 스트리밍) |
| 컴퓨트 패턴 | 균일한 요청 처리 | Prefill과 Decode의 비대칭 |
| 부하 분산 | 라운드-로빈으로 충분 | 프리픽스 캐시·GPU 상태 인식 라우팅 필수 |
전통적 쿠버네티스 Service의 라운드-로빈 라우팅으로 vLLM 파드를 묶으면 동일한 프롬프트(긴 시스템 프롬프트·RAG 컨텍스트)가 매번 재계산되며, GPU 한 대는 한가하고 다른 한 대는 OOM(Out of Memory)에 빠지는 현상이 실제 운영에서 반복된다.
2-2. vLLM — 엔진(자동차)의 역할
vLLM은 PagedAttention, 연속 배칭(Continuous Batching), 텐서 병렬화 같은 깊은 기술 혁신으로 원초적 속도와 효율을 제공하는 엔터프라이즈급 인퍼런스 엔진이다. 2026년 4월 기준 최신 안정 버전은 0.19.1이며, 4월에 릴리스된 0.18 / 0.19에서는 gRPC 서빙, GPU 가속 스펙큘레이티브 디코딩, 고도화된 KV 캐시 오프로딩, 비동기 스케줄링의 기본화가 도입됐다.
vLLM이 지원하는 핵심 기능은 다음과 같다.
- PagedAttention — KV 캐시를 OS의 가상 메모리처럼 블록 단위로 관리하여 메모리 낭비를 4% 미만으로 억제한다.
- 다양한 병렬화 — Tensor / Pipeline / Data / Expert / Context Parallel을 모두 지원하여 단일 GPU부터 멀티 노드까지 커버한다.
- 폭넓은 양자화 — FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ/AWQ, GGUF, compressed-tensors, ModelOpt, TorchAO 등 주요 양자화 포맷을 모두 지원한다.
- 하드웨어 플러그인 — NVIDIA·AMD GPU는 물론 TPU, Intel Gaudi, Huawei Ascend, Rebellions NPU, Apple Silicon 등 200+ 모델 아키텍처와 이종 가속기를 커버한다.
2-3. llm-d — 오케스트레이터(피트 크루)의 역할
그러나 아무리 빠른 F1 머신(vLLM)도 피트 크루와 레이스 전략 없이는 챔피언이 될 수 없다. vLLM이 머신이라면 llm-d는 피트 크루이자 레이스 스트래티지스트, 그리고 텔레메트리 시스템이 결합된 존재다.
llm-d는 Red Hat이 2026년 KubeCon Europe에서 CNCF 샌드박스 프로젝트로 공식화한 쿠버네티스 네이티브 분산 인퍼런스 엔진이며, 현재 인퍼런스 서빙 스택이 해결하지 못한 문제를 처음부터 다시 설계한 결과물이다. Google, NVIDIA, IBM Research, CoreWeave가 함께 만들었고 오픈소스 커뮤니티가 업데이트를 기여한다.
llm-d가 해결하는 문제는 정확히 네 가지다.
- Prefill/Decode 분리(Disaggregated Serving) — 프롬프트 처리(GPU 컴퓨트 바운드)와 토큰 생성(메모리 바운드)을 별도 파드 풀로 분리하여 각각 독립 스케일 한다.
- KV 캐시 인식 라우팅 — Endpoint Picker(EPP)가 어떤 파드가 해당 프리픽스를 이미 캐시하고 있는지 실시간 추적하여 최적 파드로 라우팅 한다.
- 계층형 KV 오프로딩 — v0.5에서는 계층형 KV 오프로딩, 캐시 인식 LoRA 라우팅, active-active HA, UCCL 기반 전송 회복력, 스케일-투-제로 오토스케일링이 도입됐고, B200 디코드 GPU 당 약1k tok/s, 16×16 B200 prefill/decode 토폴로지에서 최대 50k output tok/s를 검증했다.
- 이기종 가속기 지원 — NVIDIA·AMD GPU와 Google TPU 등 다양한 가속기 하드웨어를 지원하며, 어떤 쿠버네티스 기반 인프라에서도 동작한다.
실운영 효과도 구체적으로 보고되고 있다. 2025년 12월 v0.4 릴리스는 H200 GPU에서 DeepSeek V3.1 출력 토큰당 지연 시간을 40% 감축했다.
2-4. 한눈에 보는 역할 분담
| 계층 | 담당 컴포넌트 | 무엇을 하는가 |
| 인프라 | Kubernetes / OpenShift | 리소스 스케줄링, 네트워킹, 보안 |
| 오케스트레이션 | llm-d (Gateway + EPP) | 요청 라우팅, P/D 분리, KV-cache awareness |
| 모델 서빙 | vLLM | 실제 토큰 생성, 메모리 관리, 양자화 |
| 가속기 | L40S / H200 / B300 | 수학 연산 수행 |
결론: vLLM과 llm-d는 경쟁 관계가 아닌 레이어드 아키텍처의 서로 다른 층을 담당한다. SLM을 수십 명 규모로 쓰면 vLLM 단독으로 충분하지만, 수백~수천 동시 접속의 엔터프라이즈 환경에서 경제적 TCO를 확보하려면 llm-d가 반드시 필요하다.
3. NAA: NAMU Agentic AI의 통합 지원
3-1. NAA에서 제공하는 5-레이어 수직 통합
나무기술의 NAA는 이 Red Hat 스택 위에 에이전트 애플리케이션 레이어를 얹어 수직 통합된 풀스택을 완성한다. 구조는 다음 6개 레이어로 정리된다.
| 레이어 | 담당 | 구성 요소 |
| 5. 사용자 경험 | NAA Workflow | Doc Chat · DB Chat · Generate Report · MCP · Agents · Memory |
| 4. 에이전트 플랫폼 | NAA | Model Registry · Context Engineering · RAG · Guardrails · 에이전트 오케스트레이션 |
| 3. 분산 인퍼런스 | llm-d + vLLM | P/D 분리 · KV-cache 라우팅 · 분산 서빙 |
| 2. 엔터프라이즈 쿠버네티스 | K8S Kubernetes | 컨테이너/VM 통합 · RBAC · 보안 공급망 |
| 1. 하드웨어 가속 | NVIDIA · AMD · Intel | GPU / NPU 물리 레이어 |
3-2. 기존 AI 솔루션과 NAA의 비교
| 기존 AI 에이전트 접근 | NAAO (NAA on OpenShift AI) |
| 고비용 클로즈드 소스 API 의존 | SLM + vLLM 기반 비용 효율 추론 |
| AI 모델·프레임워크 선택의 복잡성 | 검증된 풀스택 LLMOps 제공 |
| 분절된 멀티 벤더 공급 체계 | 단일 벤더 수직 통합 공급 |
| SaaS 전용 또는 온프레미스 제한 | 온프레미스·하이브리드 동일 방식 배포 |
| 에이전트 운영 역량 내재화 부담 | 에이전트 운영 LLMOps 포함 |
이 수직 통합의 실무적 가치는 “PoC부터 프로덕션까지의 시간 단축”으로 요약된다. 평가·계획 1~2주, 스택 배포 1~2주, 파일럿 에이전트 구축·검증 2~4주의 총 4~8주 내 파일럿 완료가 나무기술의 참조 아키텍처로 보장된다.
4. GPU 활용 예시 — L40S / H200 / B300 가용 범위와 양자화
이번 레터에서는 나무기술이 실제로 PoC·도입에서 다루는 Qwen3.5-122B-A10B (MoE, 활성 파라미터 10B)를 예시로 벤치마크 모델로 삼아 3 세대 GPU의 실질 가용 범위를 비교한다.
4-1. 세 GPU의 핵심 스펙 비교
| 항목 | NVIDIA L40S | NVIDIA H200 SXM | NVIDIA B300 (Blackwell Ultra) |
| 아키텍처 | Ada Lovelace | Hopper (GH100) | Blackwell Ultra |
| VRAM | 48 GB GDDR6 | 141 GB HBM3e | 288 GB HBM3e (12-high) |
| 메모리 대역폭 | 864 GB/s | 4.8 TB/s | 8 TB/s |
| FP4 Tensor Core | 미지원 | 미지원 | 15 PFLOPS (dense) |
| FP8 Tensor Core | 지원 (4세대) | 지원 (4세대) | 지원 (5세대) |
| NVLink | 미지원 (PCIe Only) | NVLink 4.0 (900 GB/s) | NVLink 5 (1.8 TB/s) |
| TDP | 350 W (공냉) | 700 W (액냉 권장) | 1,400 W (액냉 필수) |
| 폼팩터 | PCIe Gen4 듀얼슬롯 | SXM5 / NVL PCIe | SXM6 / NVL |
| 출시 | 2023 | 2024 | 2026년 1월 |
| 주 포지셔닝 | 경제형 · 엣지 | 엔터프라이즈 표준 | AI Factory 인퍼런스 전용 |
B300은 2026년 1월 출하가 시작됐고, NVIDIA가 말하는 Blackwell Ultra는 단일 GPU에서 70B 파라미터 모델을 FP16으로 KV 캐시와 배치 처리 여유까지 포함해 올릴 수 있는 첫 GPU이다. Blackwell Ultra는 NVFP4 정밀도 포맷을 도입하여 FP8 대비 메모리 풋프린트를 약 1.8배 줄이면서도 거의 FP8 수준의 정확도를 유지한다.
4-2. 양자화 레벨별 모델 VRAM 요구량 (Qwen3.5-122B 기준)
동일 모델을 정밀도만 바꿨을 때의 VRAM 요구량이다.
| 정밀도 | 바이트/param | 가중치 | 런타임 오버헤드 | 최소 필요 VRAM | 특징 |
| BF16 원본 | 2.0 | ~244 GB | +35 GB | ~280 GB | 최고 품질, VRAM 부담 큼 |
| FP8 (공식) | 1.0 | ~122 GB | +18 GB | ~140 GB | HW 가속, MMLU-Pro 1% 미만 손실 |
| Q4 GGUF | 0.5 | ~62 GB | +12 GB | ~75 GB | 최저 VRAM, 혼합 추론 가능 |
| NVFP4 (B300) | 0.5 | ~62 GB | +12 GB | ~75 GB | Blackwell Ultra 네이티브 가속 |
FP8이 현재 표준이 되고 있는 이유: 가중치가 BF16 대비 정확히 절반이면서, L40S·H200·B300 모두에서 Tensor Core 하드웨어 가속을 받는다. vLLM에는 LLM Compressor가 내장돼 있어 가중치·활성 양자화 또는 가중치 전용 양자화로 압축 모델을 만들 수 있고, Marlin과 Machete 같은 커스텀 커널로 양자화 성능을 최적화한다.
4-3. 구성별 가용 범위 (Qwen3.5-122B · gpu_memory_utilization=0.90)
| 구성 | 총 VRAM | 가용 KV | 최대 컨텍스트 (FP8) | 권장 용도 |
| L40S × 4 | 192 GB | 33 GB | ~8K | 경량 챗봇 (FP8 필수) |
| L40S × 8 | 384 GB | 206 GB | 32K~64K | 경제형 표준 구성 |
| L40S × 16 (2서버) | 768 GB | 551 GB | 64K+ | 고처리량 L40S 경제형 |
| H200 × 4 | 564 GB | 368 GB | 128K+ | 엔터프라이즈 균형 구성 |
| H200 × 8 | 1,128 GB | 875 GB | 262K 풀 컨텍스트 | Thinking 모드 최적 |
| H200 × 16 (2서버) | 2,256 GB | 875 GB × 2 | 262K 풀 | 엔터프라이즈 프로덕션 |
| B300 × 2 | 576 GB | 436 GB | 128K+ | 차세대 표준 최소 구성 |
| B300 × 4 | 1,152 GB | 1,012 GB | 262K 풀 + 대배치 | AI Factory 단일 노드 |
| B300 × 8 (DGX) | 2,304 GB | ~2.1 TB | 1M+ 토큰 (YaRN) | 400B+ 모델 단일 노드 |
H200 / L40S 수치는 나무기술 내부 벤치마크 기준이고, B300 관련 처리량은 llm-d v0.5 벤치마크(B200 디코드 GPU당 ~3.1k tok/s, 16×16 B200 토폴로지에서 50k output tok/s)를 Blackwell Ultra 스펙 배율로 보정한 추정치다.
4-4. 세대 간 성능 점프 — 메모리 대역폭 기준
메모리 대역폭이 토큰 생성 속도(TPOT)에 직결된다는 점을 고려한 이론 처리량 배율이다.
| 비교 | 메모리 대역폭 | 상대 배율 |
| L40S × 8 | 6.9 TB/s | 기준 1.0× |
| H200 × 8 | 38.4 TB/s | ~5.6× |
| B300 × 8 | 64.0 TB/s | ~9.3× (FP4 활용 시 더 큼) |
NVIDIA 주장에 따르면 GB300 NVL72 rack은 50배 높은 처리량/메가와트와 35배 낮은 토큰당 비용을 저지연 에이전틱 워크로드에서 Hopper 대비 달성한다.
4-5. 실전 vLLM 서버 실행 서빙 명령어
L40S × 8 / FP8 (경제형 표준 구성, LS-A)
H200 × 8 / FP8 / 풀 컨텍스트 (엔터프라이즈 이상형, H2-C)
H200 2서버 llm-d DP 구성 (각 서버 동일 명령, 처리량 2×)
4-6. llm-d InferencePool (H200 2서버 DP 예시)
4-7. 운영 주의사항
- L40S — NVLink 미지원으로 TP=8의 통신 오버헤드가 있으니 32K 이하 컨텍스트에서 가장 경제적이다.
- H200 — 700W TDP로 수냉 인프라(DGX H200 또는 HGX H200)가 필요하다. 표준 공냉 랙에는 H200 NVL PCIe 형태 사용을 검토한다.
- B300 — 1,400W TDP로 액냉이 필수이며, GB300 NVL72 rack은 132~140 kW의 운영 전력 범위와 직접 액냉(DLC) 옵션을 요구한다. 국내에서는 당분간 DGX B300 8-GPU 노드 위주의 도입이 현실적이다.
- vLLM 버전 — Qwen3.5 안정 지원은 vLLM 0.8.0+, Blackwell Ultra(NVFP4) 최적화는19+에서 가능하다. –trust-remote-code 플래그를 반드시 추가한다.
- KV 캐시 모니터링 — vllm:gpu_cache_usage_perc를 상시 모니터링하고 85% 초과 시 max-model-len을 낮추거나 llm-d DP 레플리카를 추가한다.
5. 결론 — 엔터프라이즈 AI의 새로운 기준선
이번 AI 기술 포스티에서 다룬 네 가지 축을 한 문장으로 정리한다.
“엔터프라이즈는 이제 더 큰 모델이 아닌, 같은 모델을 더 효율적으로 서빙하는 인프라로 경쟁한다.”
세 가지 핵심 메시지는 다음과 같다.
1. vLLM + llm-d는 선택이 아닌 표준이다
vLLM이 엔진이고 llm-d가 오케스트레이터라는 역할 분담은 경쟁이 아니라 레이어드 아키텍처의 필연이다. 특히 llm-d가 CNCF 샌드박스로 공식화되면서 KV 캐시 라우팅과 P/D 분리는 향후 18개월 내 쿠버네티스 LLM 서빙의 사실상 표준이 될 가능성이 높다.
2. 수직 통합이 TCO를 결정한다
분절된 멀티 벤더 스택은 PoC 단계에서는 가능해도 프로덕션에서는 관리 비용이 급증한다. NAA 의 Metal-to-Agent 수직 통합은 4~8주 파일럿 배포와 단일 벤더 지원 체계로 실현 시간과 운영 리스크를 동시에 압축한다. 바이오·헬스케어의 500페이지 임상 보고서 자동화, 금융권의 실시간 DB 기반 보고서 자동 생성, 제조업의 GPU 할당 최적화는 이미 실제로 가동 중인 적용 사례다.
3. 하드웨어는 양자화 전략과 함께 설계된다
L40S 8장 FP8은 비용 최우선·32K 컨텍스트 시나리오로 활용가능하며, H200 4~8장은 128K 이상 컨텍스트를 요구하는 에이전틱 워크로드의 균형점이고, B300은 400B+ 모델과 NVFP4 네이티브 가속을 필요로 하는 AI Factory 워크로드의 차세대 기준이 된다.
나무기술의 AI 인프라 서빙 활용 제안
| 상황 | 권장 액션 |
| SLM 도입을 처음 검토 중인 고객 | gpu.namu.ai.kr에서 GPU 사이징 시뮬레이션 → 나무기술 컨설팅 |
| 기존 vLLM 단독 운영 중인 고객 | llm-d 도입을 통한 처리량 2~5× 증가 가능성 PoC 제안 |
| H200 8장 이상 인프라 보유 고객 | NAA Unified Workflow를 얹어 즉시 에이전틱 AI 업무 자동화 |
| B300 도입을 고려 중인 고객 | NVFP4 양자화 기반 400B+ SLM PoC 상담 |
참고자료
- llm-d GitHub: https://github.com/llm-d/llm-d
- vLLM Release Notes: https://github.com/vllm-project/vllm/releases
- Red Hat AI Enterprise (2026.02): https://www.redhat.com/en/products/ai
NAMU GPU Calculator: https://gpu.namu.ai.kr
