개요
GPU Operator는 GPU를 Pod가 쓸 수 있게 만들고, KServe는 모델 서버를 원하는 상태로 유지한다
이 덱은 학습이나 batch queue를 설계하지 않는다. 사내 앱이 LLM·embedding·reranker·FastAPI 모델을 안정된 API로 호출하게 만드는 상시 inference 경로만 따라간다.
먼저 보는 전체 지도
섹션 제목: “먼저 보는 전체 지도”
그림을 위에서 아래로 읽는다. 요청은 앱 → LiteLLM → Gateway/Service → 모델 Pod로 흐른다. 반면
운영 명령은 Git → KServe → Kubernetes 객체로 흐른다. GPU Operator는 요청을 처리하지 않고, 맨 아래에서
노드의 GPU를 Kubernetes 자원으로 보이게 만든다.
이 구분만 잡으면 제품 이름이 덜 헷갈린다.
| 궁금한 것 | 답을 맡는 구성요소 |
|---|---|
| 누가 이 API를 얼마나 호출할 수 있나 | LiteLLM |
| 모델 서버를 몇 개 띄우고 죽으면 누가 복구하나 | KServe + Kubernetes |
| 어떤 image·명령으로 모델을 실행하나 | ServingRuntime 또는 custom predictor |
| 어느 GPU pool에 놓이나 | Kubernetes label·taint·resource request |
| Pod 안에서 GPU가 보이게 누가 준비하나 | GPU Operator |
| GPU가 아픈지 어떻게 아나 | DCGM Exporter + Prometheus |
- 2장GPU Operator
driver·Container Toolkit·device plugin·GFD·MIG·DCGM이 이어지는 과정
GPU가 어떻게 Pod가 요청할 수 있는 자원이 되는가
- 3장KServe
InferenceService·ServingRuntime·controller·Standard mode와 LLMInferenceService
한 줄의 선언이 어떻게 실행 중인 모델 서버가 되는가
- 6장데이터와 연결
model artifact·local cache · Gateway·RDMA · 요청과 GPU 관측 연결
빠른 GPU를 다운로드와 network가 굶기지 않게 하는 법
- 7장전환
Spark PoC → B300 greenfield → A100 한 대씩 · traffic과 node rollback
기존 inference endpoint를 잃지 않고 어떻게 옮기는가
- 8장운영 카드
전체 지도 · 구성요소 선택표 · 도입 체크리스트 · 장애 확인 순서
이 덱의 결론을 먼저 말하면
섹션 제목: “이 덱의 결론을 먼저 말하면”- 첫 서비스는 KServe Standard
InferenceService로 만든다. - 지능형 routing·다중 노드 추론·prefill/decode 분리가 실제로 필요할 때만
LLMInferenceService를 붙인다. - LiteLLM에는 Pod IP가 아니라 KServe가 유지하는 안정된 endpoint를 등록한다.
- GPU Operator가 설치됐다는 사실보다 실제 CUDA Pod, node label, DCGM metric까지 이어지는지가 중요하다.
- Spark·A100·B300은 label·taint·runtime image가 다른 pool로 둔다.
- 공통 GitOps·인증·registry·관측을 사용하되 Spark와 datacenter GPU는 별도 실행 cluster도 허용한다.
기준 시점
섹션 제목: “기준 시점”2026년 8월 18일 기준으로 KServe와 NVIDIA 공식 문서를 확인했다. 특히 LLMInferenceService의 API와
의존성, B300 driver 지원은 변화가 빠르므로 실제 도입 때 선택한 release 문서를 다시 확인한다.
참고 자료
섹션 제목: “참고 자료”- KServe 개념 — control plane과 data plane, 주요 CRD.
- NVIDIA GPU Operator — Kubernetes GPU node의 software stack.