쿠버네티스 환경에서 LLM 운영 시작.md

2026년 01월 04일 2 분 소요

매주 일요일마다 온라인으로 “Generative AI on Kubernetes” 라는 책을 읽으면서 현업에서 일하는 분들과 스터디를 하고 있으며, 저도 관련해서 발표를 맡아서 진행했다. 오늘은 1장의 내용을 요약해서 정리하도록 하겠다.

1. 개요

전통적인 소프트웨어 개발에서는 “내 컴퓨터에서는 정상적으로 실행된다”라는 말이 흔히 발생한다. 개발자의 로컬 환경에서는 애플리케이션이 정상적으로 동작하지만, 운영 환경으로 이동하면 라이브러리 버전, 운영체제 차이, 네트워크 설정, 데이터베이스 환경 등의 차이 때문에 문제가 발생한다.

대규모 언어 모델(LLM) 배포에서는 이러한 문제가 더욱 복잡해진다. LLM은 일반적인 웹 애플리케이션과 근본적으로 다르다. 일반적인 애플리케이션은 다음과 같은 구조를 가진다.

사용자 요청
    ↓
Application Server
    ↓
Business Logic
    ↓
Database

하지만 LLM 기반 애플리케이션은 다음과 같은 구조가 된다.

사용자 요청
    ↓
API Gateway
    ↓
LLM Application
    ↓
Model Server
    ↓
   GPU
    ↓
Model Weights

여기에는 새로운 운영 요소가 추가된다.

수십 GB~수백 GB 크기의 모델 파일
GPU 메모리 관리
CUDA Driver
CUDA Runtime
Tensor 연산 최적화
KV Cache 관리
Token 생성 속도 관리
동시 사용자 요청 처리

즉 LLM은 단순한 애플리케이션 프로세스가 아니라 거대한 계산 워크로드이다.

2. 기존 컨테이너 배포와 LLM 배포의 차이

Kubernetes는 원래 컨테이너 기반 애플리케이션 운영을 위해 만들어졌다. 일반적인 웹 서비스는 다음 특징을 가진다.

컨테이너 이미지 크기: 수백 MB 수준
시작 시간: 수 초
CPU와 Memory 중심
Stateless 구조

예:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server

하지만 LLM 서비스는 다르다. 예를 들어 70B 파라미터 모델은 다음과 같은 요구사항을 가진다.

모델 파일: 수백 GB
GPU Memory: 수십~수백 GB
초기 Loading 시간: 수십 초~수 분
GPU Scheduling 필요
Stateful Resource 관리 필요

따라서 Kubernetes에서 LLM을 운영하려면 기존 Deployment 방식만으로는 부족하다.

3. Model Server

LLM을 실제 서비스하기 위해서는 Model Server가 필요하다. Model Server의 역할은 단순히 모델을 실행하는 것이 아니다.

주요 기능은 다음과 같다.

3.1 모델 로딩

LLM 모델은 일반적으로 다음 단계를 거친다.

Model Repository
        |
        ↓
Download Model Weights
        |
        ↓
Load GPU Memory
        |
        ↓
Initialize Runtime
        |
        ↓
Accept Requests

예:

Llama-3-70B
        |
        ↓
safetensors files
        |
        ↓
GPU VRAM Loading
        |
        ↓
Inference Ready

3.2 Token 생성 관리

LLM은 기존 REST API와 다르게 동작한다.

일반 API:

Request
   |
Processing
   |
Response

LLM:

Prompt
 |
Tokenizer
 |
Model Inference
 |
Token 1
 |
Token 2
 |
Token 3
 |
...
 |
Final Response

따라서 Model Server는 Token Throughput, First Token Latency, Batch Scheduling, KV Cache, GPU Utilization 과 같은 요소를 관리해야 한다.

4. 왜 Kubernetes에서 Model Server가 필요한가?

Kubernetes 자체는 컨테이너를 관리하는 플랫폼이다. 하지만 LLM 운영에서는 다음 기능이 필요하다.

4.1 Scaling

사용자가 증가하면:

1 GPU Pod

    ↓

Multiple GPU Pods

으로 확장해야 한다.

4.2 Resource Management

GPU는 CPU와 다르다.

CPU:

Core
Core
Core

처럼 비교적 쉽게 분배한다. 하지만 GPU는:

NVIDIA H100 80GB

Memory:
80GB HBM

Compute:
Tensor Core

Bandwidth:
3TB/s+

처럼 매우 제한적인 자원이다. 따라서 Kubernetes Scheduler가 GPU 상태를 이해해야 한다.

4.3 장애 복구

LLM 서버가 실패하면:

Pod Crash
    ↓
Kubernetes Detect
    ↓
Restart Pod
    ↓
Reload Model
    ↓
Service Recovery

과정이 필요하다. 하지만 일반 Pod 재시작과 달리 LLM은 모델 Loading 시간이 길기 때문에 운영 전략이 필요하다.

4. Model Server 선택

대표적인 Model Server를 비교하고 주요 대상은 다음과 같다.

Model Server	특징
vLLM	고성능 LLM Serving 표준으로 자리잡는 오픈소스
Hugging Face TGI	Hugging Face 생태계 기반
KServe	Kubernetes Native Model Serving
Ray Serve	분산 Python Serving Framework

5. 개발자가 이해해야 할 핵심

LLM 운영은 기존 Web Application 운영과 다르다.

기존:

Application Scaling = Pod 개수 증가