Kubernetes에 vLLM 올렸더니 Pod가 계속 죽는다면 — GPU 할당·모델 로딩 Probe·/dev/shm·KV 캐시·대기열 오토스케일링, LLM 서빙 매니페스트 7가지 함정
로컬에서 vllm serve 한 줄이면 잘 돌던 모델을 Kubernetes에 올리는 순간 이야기가 달라집니다. Pod는 Running인데 GPU를 못 잡고, 모델 가중치를 반쯤 읽다가 재시작되고, 겨우 뜬 서버는 첫 요청에서 CUDA OOM을 냅니다. 오토스케일링을 걸었더니 CPU 사용률이 안 올라서 영원히 1대로 버팁니다. 이 블로그에서는 그동안 맥·DGX Spark 같은 로컬 LLM 서빙 하드웨어 를 주로 비교했는데, 이번에는 반대편, 쿠버네티스 GPU 노드에서 vLLM을 운영할 때 실제로 터지는 지점 을 정리합니다. 앞서 쓴 CrashLoopBackOff 점검 가이드 의 LLM 서빙 실전편이라고 보면 됩니다. 0. 출발점: 최소 매니페스트 vLLM은 OpenAI 호환 API 서버를 내장하고 있어서, 공식 이미지( vllm/vllm-openai )에 모델 이름만 넘기면 8000번 포트로 /v1/chat/completions 를 제공합니다. 아래가 이 글에서 계속 고쳐 나갈 출발점입니다. apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen spec: replicas: 1 selector: matchLabels: { app: vllm-qwen } template: metadata: labels: { app: vllm-qwen } spec: containers: - name: vllm image: vllm/vllm-openai:latest # 운영에서는 버전 태그 고정 args: ["--model", "Qwen/Qwen3-8B", "--port", "8000"] ports: - containerPort: 8000 이대로 배포하면 거의 확실하게 아래 7가지 중 몇 개를 만납니다. 1. ...