GPU Operator · 바닥
GPU node의 software stack을 설치하고 맞춘다.
결과: Kubernetes가 nvidia.com/gpu와 GPU label·metric을 본다.
0. 먼저 큰 그림부터
제품 이름을 외우기 전에 요청의 길과 운영의 길을 나눈다
이 장에서 처음 나오는 말3개
desired state원하는 상태- 모델 image·replica·GPU 요구처럼 운영자가 계속 유지하고 싶은 상태다.
control plane제어 평면- 원하는 상태를 읽고 실제 상태를 계속 맞추는 controller 쪽이다.
data plane데이터 평면- 실제 API 요청을 받아 추론 계산을 수행하는 Gateway·model Pod·GPU 쪽이다.
같은 플랫폼에 두 개의 흐름이 있다
섹션 제목: “같은 플랫폼에 두 개의 흐름이 있다”
사용자 요청은 KServe controller를 거치지 않는다. 이미 만들어진 Service와 모델 Pod로 간다. 반대로
운영자가 InferenceService를 바꾸면 KServe controller가 Deployment·Service를 조정한다. GPU Operator도
요청마다 관여하지 않는다. 노드에 driver·toolkit·device plugin을 갖추고 GPU 상태를 노출해 둔다.
세 제품을 한 문장씩만 기억한다
섹션 제목: “세 제품을 한 문장씩만 기억한다”KServe · 모델 운영
모델 서버의 image·replica·resource·route를 선언형 객체로 관리한다.
결과: 죽은 Pod가 복구되고 endpoint가 유지된다.
LiteLLM · 이용자 입구
API key·team quota·공개 model alias·provider fallback을 관리한다.
결과: 이용자는 실제 GPU와 Pod 주소를 몰라도 된다.
KServe가 Kubernetes 위에 더하는 것
섹션 제목: “KServe가 Kubernetes 위에 더하는 것”Kubernetes만으로도 Deployment와 Service를 직접 만들 수 있다. KServe를 쓰는 이유는 “모델 하나”라는 운영 단위를 상위 API로 만들기 위해서다.
| 직접 Kubernetes를 쓸 때 | KServe를 쓸 때 |
|---|---|
| Deployment·Service·HTTPRoute를 따로 관리 | InferenceService 하나에서 하위 객체를 생성 |
| 실행 image와 model format의 관계를 매번 작성 | ServingRuntime으로 검증된 실행 template 재사용 |
| 여러 상태를 찾아 모델 준비 여부를 판단 | InferenceService.status에서 Ready 조건 확인 |
| 팀마다 배포 형식이 달라지기 쉬움 | 공통 runtime catalog와 policy 적용 |
KServe가 GPU memory를 보고 최적 장비를 골라 주는 것은 아니다. Spark·A100·B300 중 어디에 놓을지는 검증된 runtime, resource request, node label·taint로 플랫폼 팀이 계약을 만든다.
왜 Kubernetes-native로 가는가
섹션 제목: “왜 Kubernetes-native로 가는가”가장 큰 변화는 docker run이 Pod가 되는 것이 아니다. 모델 배포의 원본이 제품 DB·수동 명령에서
Kubernetes 객체와 Git으로 바뀌는 것이다.
| 질문 | 별도 GPU manager | Kubernetes-native |
|---|---|---|
| 모델 A의 원하는 replica는 어디에 있나 | 제품 DB·UI | InferenceService와 Git |
| 누가 변경을 승인했나 | 제품 audit log | pull request·GitOps 기록 |
| 장애 시 누가 재생성하나 | 제품 agent·controller | Kubernetes·KServe controller |
| secret·certificate·network policy는 | 제품별 체계 | 사내 Kubernetes 체계 재사용 |
| GPU driver와 metric은 | host별 운영 | GPU Operator와 DCGM 기준선 |
GPUStack을 사이에 넣지 않는 이유
섹션 제목: “GPUStack을 사이에 넣지 않는 이유”GPUStack은 빠른 inference 배치에 유용하지만, 목표 구조가 이미 Kubernetes-native라면 별도 model DB·
scheduler·gateway가 두 번째 제어 평면이 된다. 이 덱은 Git의 InferenceService, 검증된 ServingRuntime,
Kubernetes placement, DCGM 관측을 직접 운영하는 쪽을 택한다.
이번 범위의 성공 조건
섹션 제목: “이번 범위의 성공 조건”- Git에서 model revision과 replica를 보고 되돌릴 수 있다.
- Spark·A100·B300용 image가 잘못된 pool에 배치되지 않는다.
- full GPU·MIG·full-node 요청의 의미가 runtime catalog에 고정돼 있다.
- LiteLLM request ID를 Gateway·KServe service·vLLM log·GPU metric까지 연결할 수 있다.
- streaming·timeout·rollout 중 기존 연결이 어떻게 끝나는지 검증했다.
- node drain·driver 변경·model rollback을 실제로 리허설했다.
참고 자료
섹션 제목: “참고 자료”- KServe 개념 — Kubernetes CRD로 구성하는 inference control plane.
- GPU Operator 개요 — GPU node 기반을 만드는 component.
1. 세 종류의 GPU를 자원 섬으로 보기Spark·A100·B300을 GPU 개수 하나로 세지 않고 architecture·topology·운영 단위로 나눈다.