상태: 초안 (2026-10-07), 지도 글입니다. 이 글은 새 측정을 하지 않고, 같은 연재의 다른 글에서 필자가 직접 잰 값과 문서로 확인한 내용을 한 장으로 엮은 것입니다. 숫자 옆에는 어느 글에서 어떤 조건으로 쟀는지를 적었습니다. 측정은 모두 작은 모델 한두 개, GPU 한 장(8GB급), 일회용 단일 노드 클러스터에서 했으므로 절대값보다 모양과 원리를 가져가시기 바랍니다. 문서 기준이거나 잰 적이 없는 내용은 「문서 기준」, 「미실측」으로 표시했습니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.
1. 이 글을 어떻게 읽으면 되는가
ML·AI 인프라는 한 분야가 아니라 여러 층이 겹친 분야입니다. GPU 메모리 대역폭을 모르면 서빙 숫자를 설명할 수 없고, 쿠버네티스 스케줄러를 모르면 GPU 작업이 왜 멈추는지 모르고, 관측을 모르면 둘 다 고칠 수 없습니다. 이 글은 층마다 「이것만은 알아야 한다」를 정리하고, 깊이 읽을 글을 연결합니다.
읽는 순서는 두 가지입니다.
- ML·AI 인프라 엔지니어: 2~5절(하드웨어, 스택, 스케줄링, 서빙)을 먼저 보고 9절의 측정 방법으로 넘어갑니다.
- 쿠버네티스 엔지니어: 3, 4, 8절(스택, 스케줄링, 컨트롤러)을 먼저 보고, GPU 가 일반 자원과 어디서 다른지를 2절과 5절로 채웁니다.
2. 한 장 지도: 여덟 개 층
| 층 | 핵심 질문 | 대표 도구와 개념 | 깊이 읽을 글 |
|---|---|---|---|
| 1. GPU 와 하드웨어 | 무엇이 속도의 상한을 정하는가 | 메모리 대역폭, 연산 처리량, VRAM 구성 | 21편, 11편 |
| 2. 쿠버네티스의 GPU 스택 | GPU 는 어떻게 파드에 닿는가 | 드라이버, 툴킷, 디바이스 플러그인, GPU Operator, 패스스루 | 3편, 13편 |
| 3. 스케줄링과 멀티테넌시 | 여러 팀과 작업이 GPU 를 어떻게 나누는가 | Kueue, Volcano, 갱 스케줄링, 쿼터, 선점 | 10편, 9편 |
| 4. LLM 서빙 엔진 | 처리량과 지연은 무엇이 정하는가 | 연속 배칭, KV 캐시, 접두사 캐시, 청크 프리필, 양자화, LoRA | 4편, 5편, 14편, 15편 |
| 5. 네트워크 | 서비스 확장과 GPU 간 통신 | CNI, kube-proxy 대 Cilium, 서비스 메시, RDMA, NCCL | 2편, 7편 |
| 6. 스토리지와 모델 배포 | 가중치와 KV 를 어디에 두는가 | 모델 캐시, 콜드 스타트, KV 오프로드, 가중치 보호 | 8편, 16편 |
| 7. 관측과 장애 진단 | 무엇을 보고 언제 깨우는가 | DCGM, XID, TTFT·ITL 분위수, 서버 지표 | 17편, 18편, 11편 |
| 8. 컨트롤러와 배포 자동화 | 선언한 상태를 어떻게 유지하는가 | CRD, 오퍼레이터, GitOps | 9편 |
3. 층 1: GPU 와 하드웨어, 속도의 상한은 어디서 오는가
알아야 할 것
- 토큰 생성은 메모리 대역폭이 상한을 정합니다. 토큰 하나를 만들 때마다 모든 층의 가중치를 한 번 읽으므로
초당 토큰 수 ≤ 메모리 대역폭 ÷ 가중치 바이트입니다. - 입력(프롬프트) 처리는 연산이 상한을 정합니다. 한꺼번에 많은 토큰을 계산하면 같은 가중치를 여러 토큰이 재사용합니다.
- VRAM 은 가중치, KV 캐시, 활성화, CUDA 그래프가 나눠 씁니다. 서빙에서 처리량을 정하는 것은 보통 KV 캐시에 남는 몫입니다.
- 소비자용 GPU 와 데이터센터 GPU 는 진단 기능이 다릅니다. ECC, 행 리매핑, 프로파일링 지표가 없을 수 있습니다.
- 컨테이너의 CUDA 버전은 호스트 드라이버가 정한 상한을 넘을 수 없습니다. 이미지를 올렸더니 시작이 실패하면 드라이버 버전부터 봅니다.
직접 재 본 숫자 (21편, 11편)
| 확인한 것 | 결과 |
|---|---|
| 크기·정밀도가 다른 모델 네 개의 생성 속도 × 가중치 | 잰 대역폭(250GB/s)의 86~98% |
| 정밀도를 반으로 줄이면(bf16에서 fp8) | 가중치 1.7배 작아졌지만 속도는 1.54배(토큰마다 드는 고정 비용만큼 이득이 줄어듦) |
| 입력 처리(1,024토큰 이상) | 잰 행렬곱 처리량의 약 75~80%, 같은 모델의 생성보다 65~127배 빠름 |
| 소비자용 GPU 세 종의 ECC·페이지 리타이어 | 모두 N/A |
| 행 리매핑 | 세 종 중 한 종만 값을 돌려줌(0 과 N/A 를 구별해야 함) |
흔한 함정
- 측정값을 하드웨어 한계와 대 보지 않는 것. 입력 처리 속도가 GPU 연산 한계의 20배로 나왔을 때 접두사 캐시 적중이라는 오류를 알아챘습니다(14편, 21편).
- PCIe 세대가 유휴에서 내려가 있는 것을 강등으로 오해하는 것. 부하를 걸고 다시 읽어야 합니다(11편).
grep Xid가 틀린 줄을 잡는 것. 네트워크 카드 드라이버의 칩 개정 줄과 Xid 가 아닌 GPU 드라이버 오류를 함께 잡습니다.NVRM: Xid로 좁힙니다(11편).
4. 층 2: 쿠버네티스의 GPU 스택
알아야 할 것
- GPU 는 확장 자원입니다. 정수로만 요청하고, 요청과 한도가 같아야 하며, 과약정과 공유가 안 됩니다.
- 스택은 아래에서 위로 쌓입니다. 호스트 커널 모듈(드라이버), 컨테이너 런타임용 툴킷, 디바이스 플러그인(자원 광고), 노드 라벨(GFD), 모니터링(DCGM exporter). GPU Operator 가 이를 한꺼번에 설치합니다.
- 공유 방식은 격리 수준이 다릅니다. 시간 분할은 메모리를 격리하지 않고, MIG 는 지원 GPU 에서만 하드웨어로 나누고, 소프트웨어 방식(HAMi 등)은 CUDA 호출을 가로챕니다(문서 기준, 3편과 10편).
- GPU 를 가상 머신에 통째로 넘길 수도 있습니다. 이때 호스트는 GPU 를 쓸 수 없어서 컨테이너용과 가상 머신용을 노드 단위로 가릅니다(13편).
- 드라이버, 툴킷, 오퍼레이터의 책임을 가르면 장애 분석이 빨라집니다. 어느 층에서 실패했는지가 증상(
nvidia-smi실패, 파드 Pending, 컨테이너 시작 실패)에 따라 나뉩니다.
흔한 함정
- 호스트 드라이버를 오퍼레이터가 설치하는지 호스트에 이미 있는지를 정하지 않은 채 오퍼레이터를 올리는 것. 둘이 충돌합니다(3편).
- 새 CUDA 이미지가 오래된 드라이버에서 시작하지 못하는 것. 실제로 CUDA 13 이미지가 CUDA 12 계열 드라이버에서 초기화 오류(Error 804)로 실패했습니다(필자의 시험, 이 글에서는 일반 원리만).
- GPU 파드가 노드 메모리 요청 합 때문에 Pending 이 되는 것. GPU 는 비어 있어도 일반 자원(메모리)이 모자라면 스케줄되지 않습니다. 대기 사유 메시지를 먼저 읽습니다.
5. 층 3: 스케줄링과 멀티테넌시
알아야 할 것
- 기본 스케줄러는 파드 하나씩 결정합니다. 파드 여러 개가 함께 떠야 의미 있는 작업(분산 학습, 다중 노드 추론)은 일부만 자리를 얻고 서로를 기다립니다.
- 갱 스케줄링은 두 가지 방식이 있습니다. Kueue 는 작업 단위로 쿼터를 확인해 받아들일 때까지 파드를 만들지 않고, Volcano 는 별도 스케줄러가 파드 그룹의 최소 개수를 채울 수 있을 때만 한꺼번에 자리를 줍니다.
- 쿼터, 차용, 반환, 선점은 설계 문제입니다. 누가 남는 자원을 빌릴 수 있고, 주인이 돌아오면 누가 쫓겨나는지를 정책으로 정합니다.
- LeaderWorkerSet 은 그룹 단위 복구를 줍니다. 다중 노드 서빙에서 랭크 하나가 사라지면 나머지가 쓸모없어지므로 그룹 전체를 다시 만드는 것이 기본입니다.
직접 재 본 숫자 (10편, 9편)
| 확인한 것 | 결과 |
|---|---|
| 파드 4개가 필요한 작업 둘이 자원 8개를 두고 경쟁(기본 스케줄러) | 60초 동안 각각 2개씩 쥐고 멈춤(교착) |
| 같은 상황에서 Kueue, Volcano | 한 작업만 받아들여 약 2~4초 안에 4개 실행, 일부만 실행된 순간 없음 |
| 받아들여진 작업을 지운 뒤 대기 작업이 뜨는 시간 | Kueue 3.0~3.6초, Volcano 3.6~4.2초 |
| LeaderWorkerSet 에서 워커 하나를 지우면 | 같은 그룹의 파드 3개가 모두 새로 만들어지고 다른 그룹은 그대로(약 2초) |
| LeaderWorkerSet 만으로 자원이 모자라면 | 리더만 Running 이고 워커는 Pending, 갱 스케줄링이 없음 |
흔한 함정
- 갱 스케줄링 없이 큰 작업을 올리는 것. 자원을 쥔 채로 서로를 기다려 클러스터가 놀게 됩니다.
- 종료 유예 시간을 모르고 선점·반환 시간을 재는 것. 쫓겨나는 파드가 종료 신호를 무시하면 유예 시간(기본 30초)을 다 채우고 끝나, 측정값이 유예 시간이 됩니다(10편에서 실제로 겪음).
- 「같은 우선순위로 동시에 제출하면 순서가 정해진다」고 믿는 것. 어느 작업이 먼저 받아들여지는지는 매번 같지 않았습니다.
6. 층 4: LLM 서빙 엔진, 숫자로 이해하기
이 층이 가장 많이 묻고, 가장 많이 잰 곳입니다. 8GB급 GPU 한 장에서 1.7B 모델로 vLLM 과 SGLang 을 쟀습니다(5편, 14편, 15편).
알아야 할 것
- 연속 배칭이 동시 요청의 가중치 읽기 비용을 나눠 갖게 합니다. 그래서 동시성을 올리면 총 처리량이 거의 비례해서 늘다가, KV 캐시 용량에서 꺾입니다.
- 토큰당 KV 크기는 식으로 계산합니다.
2 × 층 × KV 헤드 × head_dim × 바이트. 동시성 한도는KV 용량 ÷ 요청당 토큰으로 어림합니다. - 접두사 캐시는 공통 앞부분의 입력 처리를 건너뜁니다. 시스템 프롬프트와 문서를 앞에 고정하는 서비스에서 가장 값싼 최적화입니다.
- 청크 프리필은 긴 입력이 다른 사용자의 토큰을 끊는 시간을 정합니다.
- 양자화는 두 가지입니다. 가중치 양자화는 속도(읽는 바이트)를, KV 양자화는 용량(담는 토큰 수)을 바꿉니다.
- LoRA 는 기본 모델 하나에 작은 어댑터를 얹어 서빙합니다. 동시에 쓰이는 어댑터 수와 슬롯 수의 관계가 성능을 정합니다.
직접 재 본 숫자
| 확인한 것 | 결과 | 글 |
|---|---|---|
| 서버 로그의 KV 용량 ÷ 토큰 수 | 토큰당 약 114,900바이트, 식의 114,688바이트와 0.2~0.3% 이내 | 14편 |
| 동시 요청 1에서 16 | 총 처리량이 14~15배, 요청 하나의 속도는 8~14% 감소 | 21편 |
| 동시 32에서 64(입력 512) | 처리량 831에서 787 tok/s 로 감소, 첫 토큰까지 시간(TTFT)은 666ms에서 5.7초로 8.6배 | 14편 |
| KV 8비트 | 같은 메모리에 1.9배의 토큰, 긴 입력(2,048토큰) 동시 16의 TTFT 4.0초에서 0.94초 | 14편 |
| 접두사 캐시(공통 3,000토큰) | 첫 토큰 394ms에서 28ms, 끄면 393ms | 14편 |
| 긴 입력(3,500토큰)이 끼어들 때의 최대 토큰 간격 | 청크 512토큰에서 69ms, 2,048토큰 약 227ms, 8,192토큰 445ms | 14편 |
| 같은 시험에서 SGLang 의 기본 동작 | 청크를 512로 줄여도 472ms(입력 전체를 처리하는 시간), 혼합 청크를 켜야 69ms | 5편 |
| 두 엔진의 순수 처리량 | 동시 1~64에서 ±5% 안(대역폭에 묶인 작은 모델) | 5편 |
| LoRA 어댑터를 쓰는 요청의 처리량 | 요청 48개 기준 약 10%(어댑터 하나)에서 12.5%(둘을 섞음) 감소(5회 반복 중앙값, 한 번 잰 17.9% 는 예열이 섞인 값), LoRA 를 켜 두는 것 자체는 무료 | 15편 |
| 어댑터 3개를 슬롯 2개로 서빙 | 슬롯 4개일 때의 56% 로 처리량 감소 | 15편 |
| 서버 재기동 | 35~55초(가중치 적재 4~6초), 첫 기동은 컴파일 때문에 71초 | 14편 |
현장에서 쓰는 규칙
- 동시성 한도는 KV 가 담는 요청 수 근처에 둡니다. 넘기면 처리량은 늘지 않고 TTFT 만 늡니다.
- TTFT 는 p95, 토큰 간격(ITL)은 p99 를 봅니다. 중앙값은 멀쩡해도 꼬리가 큽니다(ITL p99 223ms).
- 엔진을 비교하기 전에 기본 설정을 맞춥니다. 같은 이름의 옵션도 기본값이 다릅니다(청크 크기, 혼합 청크, 메모리 설정).
- 접두사가 겹치는 요청을 같은 인스턴스로 보냅니다. 캐시는 인스턴스 안에 있습니다(8편, 문서 기준).
7. 층 5: 네트워크
알아야 할 것
- 서비스 수가 많아지면 iptables 규칙이 늘어납니다. Cilium 의 eBPF 는 규칙 대신 맵 조회로 서비스 부하 분산을 합니다.
- 서비스 메시는 요청마다 프록시 홉을 더합니다. LLM 서빙에서는 첫 토큰까지 수백 ms 라서 작지만, 토큰마다 스트리밍하는 응답이나 짧은 호출에서는 보일 수 있습니다.
- GPU 간 통신은 별도 계층입니다. NCCL 이 집합 연산을 하고, 노드 사이에서는 RDMA(InfiniBand 또는 RoCE)가 CPU 를 우회합니다.
- RDMA 의 흔한 장애는 설정입니다. 고정 메모리 한도(memlock), MTU 불일치, GID 선택, PFC·ECN.
직접 재 본 숫자 (2편, 7편)
| 확인한 것 | 결과 |
|---|---|
| Istio 사이드카(mTLS) | 요청 한 번에 약 2.2ms 추가. 암호화는 약 8%, 나머지가 프록시이고 그중 HTTP 해석이 약 39%(해석 없는 L4 로 두어도 +1.35ms 가 남음). gRPC 는 +3.4ms, 100MiB 응답은 처리량 3.5~4.5배 저하, 스트리밍 이벤트 간격(20ms)은 영향 없음 |
| conntrack 한도를 넘는 동시 연결 4,000개 | 한도 2,048 에서 1,913개 성공(= 한도 - 기존 항목), 나머지는 거절 없이 조용히 드롭 |
| 서비스 1만 개 직후 새 서비스 연결 | kube-proxy 쪽에서 45초(두 번 중 한 번), Cilium 쪽 0.25초 |
| iptables 규칙이 11만 줄 | 같은 노드 안 새 연결의 평균 지연은 약 0.05ms 증가에 그침(통념보다 작음) |
| 소프트웨어 RDMA(rxe) | 같은 머신의 TCP 가 RDMA 쓰기보다 약 8배 빠름(개념 확인용), 이더넷 MTU 1500 에서 active_mtu 1024 |
| 일반 사용자의 고정 메모리 한도 64·1,024KiB | 1MiB 메모리 등록이 Failed to create MR 로 실패, 8,192KiB 부터 성공 |
흔한 함정
- 「iptables 는 서비스가 많으면 느리다」를 데이터패스 지연으로만 이해하는 것. 이 환경에서 차이가 컸던 것은 규칙을 한꺼번에 갱신하는 시점이었습니다.
- 같은 값이 반복해서 나오는 표를 믿는 것. 연결 시도 제한이 측정값을 두 값으로 굳힌 적이 있습니다(도구의 해상도를 의심합니다).
8. 층 6: 스토리지와 모델 배포
알아야 할 것
- 가중치 크기는
파라미터 수 × 바이트입니다. 70B bf16 이면 140GB 이므로 노드마다 내려받지 않도록 공유 캐시나 이미지 전략이 필요합니다. - 콜드 스타트는 이미지 받기, 모델 받기, 적재, 컴파일, 워밍업의 합입니다. 오토스케일링 설계에서는 이 합이 새 파드가 트래픽을 받는 시간입니다.
- KV 를 GPU 밖(CPU, 디스크, 원격)으로 내리면 접두사를 더 오래 재사용합니다. 단, 불러오는 시간이 재계산보다 짧아야 이득입니다.
- 가중치 암호화는 저장소 유출과 변조를 막지만 실행 중 메모리는 못 막습니다.
직접 재 본 숫자 (8편, 16편, 14편)
| 확인한 것 | 결과 |
|---|---|
| GPU 에 다 안 들어가는 문서 10개(약 5만 토큰)를 같은 순서로 다시 읽기 | LMCache(CPU 오프로드)로 TTFT 576ms에서 48.6ms, 처음 읽을 때 저장 비용 약 4% |
| LMCache 의 CPU 용량이 작업 집합(약 1.49GB)보다 작으면 | 이득 0(0.5GB, 1.0GB 에서 적중 0), 1.5GB 에서 600ms 가 39ms(적중 98%). 문맥이 길수록 이득이 커서 6,414토큰은 약 19배 |
| 손익분기 적중률 | 약 4%(그 시험의 값으로 계산) |
| AES-256-GCM 으로 가중치 파일 암호화 | 파일 크기 증가 약 0.00005%, 복호화 0.78~0.95 GB/s(순수 계산 1.8~2.2 GB/s) |
| 암호문 1바이트 변조, 청크 순서 바꿔치기 | 둘 다 복호화 거부(InvalidTag). AAD 가 없으면 바꿔치기와 잘라내기, 파일 간 청크 바꿔치기를 탐지하지 못함 |
| AES 하드웨어 가속을 끄면 | 복호화가 4~7배 느림(2.0에서 0.47, 0.29 GB/s). 스레드는 2개에서 멈추나 프로세스는 8개까지 확장 |
| 복호화한 가중치를 메모리 볼륨에 놓고 서버 기동(0.6B 모델) | 복호화 약 2.3초가 서버 준비(약 28초) 앞에 더해짐. 변조 파일은 서버를 띄우기 전에 거부됨 |
| 실행 중에 LoRA 어댑터 적재(6.4MB) | 서버 재시작 없이 0.2초 안(문서는 운영 사용을 경고) |
9. 층 7: 관측과 장애 진단
알아야 할 것
- GPU 지표는 세 층입니다. 하드웨어(DCGM: 사용률, 전력, 온도, 클럭 제한 사유, XID), 서버(대기열, KV 사용률, 선점 수), 서비스(TTFT, ITL, 오류율).
- 사용률만 보면 속습니다. 메모리 대역폭에 묶인 서버는 사용률이 높아도 연산을 거의 못 쓸 수 있습니다.
- XID 는 GPU 드라이버가 커널 로그에 남기는 오류 번호입니다. 일반 계정은
dmesg가 막혀 있을 수 있어journalctl -k를 씁니다. - Cilium 과 DCGM 의 지표는 많고, 카디널리티가 비용입니다. 레이블 조합이 시계열 수를 정합니다(17편, 18편).
- 알림은 증상(TTFT 꼬리)과 원인(VRAM 추세, 클럭 제한)을 따로 둡니다.
흔한 함정
- N/A 와 0 을 같게 보는 것. 지원하지 않는 지표는 0 이 아니라 N/A 로 나옵니다(11편).
- 서버 재기동 때마다 KV 용량이 달라지는 것을 모르고 메모리 숫자로 비교하는 것. 토큰당 바이트로 비교합니다(14편).
10. 층 8: 컨트롤러와 배포 자동화 (쿠버네티스 엔지니어의 도구)
알아야 할 것
- 레벨 기반 조정. 이벤트가 아니라 현재 상태를 읽어서 원하는 모습과 비교하고 맞춥니다. 이벤트를 놓쳐도 다음 조정이 고칩니다.
- 멱등성. 이미 맞으면 아무것도 쓰지 않아야 합니다.
- 소유 참조와 finalizer. 자식은 소유자가 지워질 때 함께 정리되고, finalizer 는 정리를 끝낸 뒤에야 삭제를 허용합니다.
- CRD 는 스키마와 검증이 설계입니다. 단순 규칙은 CEL, 복잡한 규칙은 웹훅.
- GitOps 는 Git 에 적은 필드를 다른 컨트롤러가 바꾸면 충돌합니다. HPA 와
replicas,ignoreDifferences(9편).
직접 재 본 숫자 (9편)
| 확인한 것 | 결과 |
|---|---|
| CEL 검증 | 빈 문자열 모델 이름은 생성 단계에서 model must not be empty 로 거절 |
| LWS 롤링 업데이트 | 서수가 큰 그룹부터 한 그룹씩(maxUnavailable 1 기본) |
오퍼레이터가 실제로 도는 동작(자식을 지웠을 때 복구 시간, 멱등성, finalizer, 중복 실행, 재시도)은 9편에 직접 시험한 결과를 이어서 반영할 예정입니다.
11. 측정하는 법: 모든 층을 관통하는 기술
연재에서 가장 값진 것은 숫자보다 숫자를 의심한 순간들이었습니다.
| 겪은 일 | 교훈 |
|---|---|
| 입력 처리가 GPU 연산 한계의 20배로 나옴 | 하드웨어 한계와 대 봅니다. 같은 문장을 반복해 접두사 캐시가 적중한 탓이었습니다 |
| 「동시 1, 16」이 실제로는 3배, 48개 요청 | 도구의 인자가 무엇을 하는지 확인합니다. 표기와 실제 요청 수를 맞춥니다 |
| 같은 값이 반복해서 나오는 표 | 측정 도구의 해상도를 의심합니다 |
| 종료 유예 30초가 선점 시간에 섞임 | 측정하려는 시간이 아닌 시간이 섞이지 않았는지 봅니다 |
헤더 줄만 남기는 grep 으로 결과가 안 보임 |
결과를 가리는 필터를 쓰지 않습니다 |
| root 로 한 시험이 장애를 재현하지 못함 | 재현하려는 조건(일반 사용자)으로 시험합니다 |
| 두 엔진의 같은 이름 옵션의 기본값이 다름 | 비교 전에 설정을 로그로 맞춥니다 |
그리고 세 가지를 습관으로 둡니다. 요청마다 다른 입력, 반복과 분산(한 번의 값은 단정하지 않습니다), 환경과 방법을 값 옆에 적기.
12. 4주 학습 경로
혼자 공부한다면 이 순서를 권합니다. 각 주의 산출물은 자기 손으로 잰 표 하나입니다.
| 주 | 주제 | 해 볼 것 | 산출물 |
|---|---|---|---|
| 1 | GPU 와 서빙 엔진 | 작은 모델(1~2B)을 vLLM 으로 띄우고, 크기·정밀도별 생성 속도에 가중치 바이트를 곱해 대역폭과 대 보기 | 「속도 × 가중치 대 대역폭」 표 |
| 2 | 부하와 캐시 | 동시성을 1에서 64까지 올리며 처리량, TTFT p95, ITL p99 를 재고, KV 용량 식과 꺾이는 지점을 맞춰 보기, 접두사 캐시 켬·끔 | 동시성 곡선과 KV 계산 |
| 3 | 쿠버네티스 GPU 와 스케줄링 | 일회용 클러스터에서 가짜 확장 자원으로 갱 교착을 만들고 Kueue 와 Volcano 로 풀기, 컨트롤러(kopf 등)를 직접 짜서 자식 삭제 복구 시간 재기 | 교착 재현과 해결, 복구 시간 |
| 4 | 관측과 장애, 보안 | DCGM 지표를 읽고 N/A 와 0 을 구별하는 대시보드, XID 알림 규칙, 가중치 암호화·복호화 속도 재기 | 지표 목록과 알림 규칙 초안 |
일회용 환경(가상 머신의 k3s, 임시 파드)에서만 하고, 끝나면 지웁니다. 서비스가 쓰는 클러스터에서 처음 해 보지 않습니다.
13. 현장과 면접에서 자주 나오는 질문
- LLM 토큰 생성 속도의 상한은 어떻게 어림하는가? 메모리 대역폭 ÷ 가중치 바이트. 모델 네 개에서 잰 대역폭의 86~98% 가 나왔다.
- 서버의 동시 요청 한도는? KV 캐시 토큰 수 ÷ 요청당 토큰. 넘으면 처리량은 늘지 않고 TTFT 가 8배로 뛴다.
- 접두사 캐시는 언제 효과가 큰가? 공통 앞부분이 긴 서비스. 3,000토큰에서 첫 토큰이 394ms 에서 28ms 로 줄었다.
- 긴 입력이 다른 요청을 끊는 것을 어떻게 줄이는가? 청크 프리필의 청크를 줄이고, 엔진의 기본 동작(혼합 청크 여부)을 확인한다.
- GPU 작업이 멈춰 있는데 GPU 는 비어 있다. 왜? 갱 스케줄링 없이 일부 파드만 자리를 얻었거나(교착), 일반 자원(메모리)이 모자라 Pending 이다.
- 갱 스케줄링을 어떻게 구현하는가? Kueue 는 작업 단위 승인, Volcano 는 파드 그룹 최소 개수.
- GPU 공유 방식은? 시간 분할(메모리 격리 없음), MIG(하드웨어 분할, 지원 GPU), 소프트웨어 방식(호출 가로채기).
- 컨테이너가 시작하지 않는다. CUDA 이미지와 드라이버는? 컨테이너의 CUDA 는 호스트 드라이버 상한을 넘을 수 없다.
- 서비스 메시의 지연 비용은? 이 환경에서 요청당 약 2.2ms, 그중 암호화가 약 8%.
- LoRA 어댑터 여러 개를 서빙할 때 주의할 것은? 동시에 쓰이는 어댑터 수와 슬롯 수. 슬롯이 모자라면 처리량이 절반 수준.
- 가중치를 암호화하면 무엇이 보호되는가? 저장소 유출과 변조. 실행 중 메모리는 막지 못한다.
- 오퍼레이터에서 이벤트를 놓치면 어떻게 되는가? 레벨 기반 조정이 현재 상태를 다시 읽어 맞춘다(타이머나 재동기화가 되살린다).
- 성능 시험 결과가 이상할 때 가장 먼저 하는 일은? 하드웨어 한계와 대 본다.
14. 이 지도가 다루지 않는 것
- 학습(트레이닝) 인프라. 분산 학습(데이터 병렬, 텐서·파이프라인 병렬), 체크포인트, 데이터 로더, 학습 중 장애 복구는 이 연재에서 재지 않았습니다(미실측).
- 데이터센터 GPU, NVLink·NVSwitch, InfiniBand 실장비, 수백 노드 규모의 스케줄러 처리량.
- 큰 모델(수십 B 이상)과 다중 GPU 서빙의 숫자. 이 글의 서빙 숫자는 1.7B 한 모델입니다.
- 서빙 외 ML 플랫폼(피처 스토어, 실험 관리, 파이프라인 오케스트레이션).
참고: 이 지도의 근거가 된 글
2편(하이브리드 GPU 클러스터와 네트워크), 3편(GPU Operator), 4편(LLM 추론과 vLLM), 5편(vLLM 과 SGLang), 6편(분산 추론), 7편(RDMA), 8편(스토리지와 KV 오프로드), 9편(CRD와 오퍼레이터), 10편(멀티테넌트 스케줄링), 11편(GPU 장애 진단), 13편(GPU 패스스루), 14편(vLLM 부하와 KV 캐시), 15편(LoRA 서빙), 16편(가중치 보호), 17편(DCGM 지표), 18편(Cilium 지표), 21편(속도의 원리).
확인한 날짜
2026-10-07 기준. 숫자는 각 글의 「확인한 버전과 날짜」를 따릅니다(vLLM 0.31.0, SGLang 0.5.21, Kueue 0.20.0, Volcano 1.15.3, LeaderWorkerSet 0.11.1 등).