![[1주차-LLMSO]CH1. Introduction to Model Serving and Optimization (2026.08.02)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FccajsD%2FdJMcaij1QUb%2FAAAAAAAAAAAAAAAAAAAAAK5QMbEhcVCURGcPXm7hGmajSHHxWhFk0Dr35A8LFv8b%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1788188399%26allow_ip%3D%26allow_referer%3D%26signature%3D15Z0lS4BnrpSDLyNlk%252BnS1NlVBY%253D)
학습이 끝난 모델을
진짜 서비스로 만드는 일.
Introduction to Model Serving and Optimization — 모델이 무엇으로 이루어져 있는지부터, 그것을 API로 내보내고 빠르고 싸게 굴리는 네 가지 방법까지.
수학은 거의 나오지 않습니다. 나오는 것은 전부 접는 상자 안에 넣었고, 본문은 덧셈과 곱셈만으로 따라갈 수 있게 썼습니다.
① 전문 용어는 영어 그대로. throughput을 억지로 번역하지 않습니다. 대신 뜻을 한국어로 풀어둡니다.
② 용어는 나오기 전에 뜻풀이. 모르는 단어로 설명하지 않습니다.
③ 그림 11개 전부 조작 가능. 슬라이더를 끝까지 밀어보는 게 이 자료의 핵심입니다.
④ 장마다 세 줄 요약. 거기만 읽어도 넘어갈 수 있게.
들어가며
"모델을 배포했다"는 말을 처음 들었을 때, 저는 그게 scp로 파일 하나 올리는 일인 줄 알았습니다.
실제로 해보니 아니었습니다. 파일은 올라갔는데 실행이 안 됐고, 실행은 되는데 느렸습니다.
기존 ML 자료들은 대부분 학습(training) 이야기였습니다. 손실 함수가 어떻고 옵티마이저가 어떻고 — 정작 학습이 끝난 다음에 무슨 일이 벌어지는지는 잘 안 나옵니다. 이 글은 그 "다음"만 다룹니다.
다루는 범위는 모델의 구조 · 서빙의 정의 · 최적화가 왜 필수인지 · 서빙 방식 네 가지입니다.
- 모델은 파일 하나가 아니라 model data + model architecture + model execution code 세 덩어리가 합쳐진 실행 가능한 소프트웨어입니다.
- 모델 서빙은 알고리즘 문제가 아니라 시스템 엔지니어링 문제입니다. latency · throughput · cost 이 셋을 저울질하는 일이고, 모든 상황에 맞는 정답 하나는 없습니다.
- LLM에서는 최적화가 선택이 아닙니다. 하드웨어를 하나도 안 늘리고 설정값 몇 개만 바꿔서 처리량이 몇 배씩 달라집니다.
읽는 방법
· 굵은 글씨만 따라가도 흐름이 이어집니다.
· 회색으로 접힌 상자(▸ 숫자로도 보고 싶다면)는 안 열어도 됩니다. 열지 않아도 본문은 완결됩니다.
· 그림은 전부 슬라이더를 밀고 버튼을 눌러보는 용도입니다. 특히 슬라이더를 끝까지 밀었을 때 무슨 일이 나는지가 이 자료에서 제일 중요합니다.
· 각 장 끝의 세 줄 요약만 읽고 넘어가도 괜찮습니다.
· 영어 용어는 일부러 영어로 뒀습니다. 실무 문서와 에러 메시지가 전부 영어이기 때문입니다.
— Part 1. Introduction to Model Serving and Optimization —
01모델은 무엇으로 이루어져 있나
한 줄 요약: 모델은 데이터 파일이 아니라, 세 덩어리가 모여야 겨우 돌아가는 소프트웨어입니다.
모델을 다운로드하면 model.safetensors 같은 파일이 하나 나옵니다.
그런데 그 파일만 있으면 실행되지 않습니다. 뭔가가 더 필요합니다.
이 장에서는 그 "뭔가"가 정확히 무엇인지, 그리고 왜 세 덩어리로 나눠서 보관하는지를 알게 됩니다. 이걸 알면 배포할 때 무엇을 같이 챙겨 보내야 하는지가 보입니다.
- Inference (인퍼런스)
- 학습이 끝난 모델에 입력을 넣어 답을 하나 뽑아내는 것. 우리가 흔히 "모델을 돌린다"고 말하는 그 동작입니다.
- Model Data
- 학습으로 얻어낸 숫자 덩어리와 설정값. weight, bias, embedding, 클래스 목록, 입출력 tensor 정의 같은 것들이 여기 들어갑니다.
- Weight (가중치) · Bias (편향)
- 모델이 학습하면서 조금씩 고쳐 나간 그냥 숫자들입니다. weight는 "입력을 얼마나 크게 반영할지", bias는 "결과를 얼마나 밀어 올릴지"를 정합니다.
- Model Architecture
- 모델 내부의 설계도. layer가 몇 개고 어떤 종류이며 어떤 순서로 연결되는지. 숫자는 안 들어 있고 구조만 들어 있습니다.
- Model Execution Code
- 설계도대로 모델을 조립하고, 숫자를 채워 넣고, 실제로 돌리는 코드. 우리가 직접 쓰는 부분입니다.
- Tensor (텐서)
- 숫자를 여러 겹으로 쌓아놓은 상자. 숫자 한 줄이면 1차원, 표 모양이면 2차원 — 그 이상도 됩니다. 모델이 주고받는 데이터의 기본 단위입니다.
state_dict- PyTorch에서 weight와 bias만 모아둔 사전(dictionary). "레이어 이름 → 숫자 뭉치" 형태입니다.
safetensors- weight를 저장하는 최신 표준 파일 형식. 예전
.bin(pickle 기반)과 달리 불러올 때 임의 코드가 실행될 위험이 없고, 로딩도 더 빠릅니다.
비유 먼저 — 악보 · 연주 지시 · 연주자
오케스트라 공연을 생각해 봅시다. 공연이 성립하려면 세 가지가 다 있어야 합니다.
악보의 구조는 "1악장 다음에 2악장, 여기서 현악기가 들어온다"는 순서와 배치입니다. 이게 model architecture입니다. 소리는 안 나지만 순서를 정합니다.
각 음표에 적힌 숫자는 "이 음은 얼마나 세게, 얼마나 길게"입니다. 이게 model data, 즉 weight와 bias입니다. 학습이란 이 숫자들을 조금씩 고쳐 나가는 과정이었습니다.
연주자는 악보를 펼치고, 숫자를 읽고, 실제로 소리를 냅니다. 이게 model execution code입니다. 셋 중 하나라도 없으면 공연은 열리지 않습니다.
"모델 = 큰 파일 하나"라고 생각하면, 배포했는데 실행이 안 되는 이유를 영영 못 찾습니다.
Hugging Face에서 모델을 받으면 config.json(architecture), model.safetensors(data),
tokenizer.json(입력 변환 규칙)이 따로따로 들어 있는 것도 이 때문입니다.
작은 숫자로 한 번
세상에서 제일 작은 모델을 만들어 봅시다. 입력 숫자 2개를 받아서 결과 1개를 내놓는 모델입니다. layer는 딱 하나, 하는 일은 곱하고 더하기가 전부입니다.
입력 2개 → layer 1개 → 출력 1개
── model data (학습으로 얻은 숫자) ──
weight = [0.5, -1.2] // 입력 두 개에 각각 곱할 수
bias = 0.3 // 마지막에 더할 수
── model execution code (실행) ──
입력 = [4, 1]
0.5 × 4 = 2.0
-1.2 × 1 = -1.2
합 = 0.8
+ bias = 0.3
출력 = 1.1
GPT급 모델이라고 원리가 달라지지 않습니다. 곱하고 더하는 일이 수천억 번 반복될 뿐입니다.
weight가 1,750억 개라는 말은, 위 0.5와 -1.2 같은 숫자가 1,750억 개 있다는 뜻입니다.
세 덩어리 조립기 — 하나라도 빠지면 무슨 일이 나는가
↔ 버튼 + 슬라이더세 개가 다 켜져 있을 때만 초록색 출력이 나옵니다. 하나라도 끄면 실무에서 실제로 만나는 에러 문구가 뜹니다.
왜 굳이 따로 저장하나
전체 모델을 파일 하나로 통째로 저장할 수도 있습니다. 그런데 현장에서는 대부분 나눠서 저장합니다.
- 버전을 갈아끼우기 쉽습니다 architecture는 그대로 두고 weight만 새것으로 교체하면 됩니다. 반대도 됩니다.
- 일부만 골라 불러올 수 있습니다 새 구조와 기존 checkpoint 사이에 이름이 안 맞는 부분이 있어도, 맞는 것만 골라 로드할 수 있습니다.
- fine-tuning과 layer 추가가 쉬워집니다 기존 weight를 그대로 두고 뒤에 layer를 붙이는 식의 작업이 자연스러워집니다.
Hugging Face 모델 폴더를 열어보면 이 원칙이 그대로 보입니다.
| 파일 | 어느 덩어리 | 담고 있는 것 |
|---|---|---|
config.json | architecture | layer 수, hidden size, attention head 수 등. 이 파일만으로 구조를 다시 세울 수 있습니다. |
generation_config.json | architecture | 텍스트 생성 기본값 — max_length, temperature, top_p |
model.safetensors | data | weight 본체. 최신 표준 형식이고, 로딩이 빠르며 안전합니다. |
pytorch_model.bin | data | 예전 형식. pickle 기반이라 불러올 때 코드가 실행될 위험이 있습니다. |
tokenizer.json | data | 글자를 숫자로 바꾸는 규칙(vocab + merge rules). LLM에서는 필수입니다. |
PyTorch 코드로도 보고 싶다면
이 한 줄이 model data만 뽑아 저장합니다. state_dict()는
"레이어 이름 → weight 숫자 뭉치" 형태의 사전입니다. 구조는 여기 안 들어갑니다.
model.load_state_dict(torch.load("model_weights.pt", weights_only=True))
model.eval()
pred = model(inputs)
읽는 법 — 1줄: architecture로 빈 모델을 만듭니다(숫자는 아직 랜덤).
2줄: 저장해둔 data를 부어 넣습니다. 3줄: eval()은 "이제 학습 안 하고 예측만 한다"는 스위치입니다.
4줄: inference 실행. 이 네 줄이 model execution code 전부입니다.
서빙 환경에는 TheModelClass 정의가 반드시 같이 있어야 합니다.
weight 파일만 복사해 놓고 실행이 안 되는 사고는 거의 전부 이것 때문입니다.
- 정의 — 모델은 model data(숫자) + model architecture(설계도) + model execution code(실행 코드) 세 덩어리로 이루어진 실행 가능한 소프트웨어입니다.
- 성질 — 셋은 따로 저장합니다. 그래야 버전 교체, 부분 로딩, fine-tuning이 가능해집니다.
- 쓰임 — 배포할 때 "weight 파일만 올리면 되겠지"라고 생각하면 반드시 막힙니다. 세 덩어리를 다 챙겨야 합니다.
— 여기까지: 모델은 세 덩어리다. 다음은 그 모델이 만들어져서 서비스에 도달하기까지의 전체 경로 —
02모델 생명주기 — 학습에서 서빙까지
한 줄 요약: 학습과 서빙은 같은 모델을 다루지만, 신경 쓰는 지표가 완전히 다릅니다.
ML 자료는 대부분 "정확도 92% 달성!"에서 끝납니다. 그런데 회사에서 그 다음에 벌어지는 일이 실은 훨씬 길고, 그 구간을 담당하는 게 개발자입니다.
이 장에서는 전체 경로에서 모델 서빙이 정확히 어디에 놓이는지, 그리고 앞 단계(학습)와 무엇이 다른지를 알게 됩니다.
- Training (학습)
- 데이터를 보여주면서 weight 숫자를 조금씩 고쳐 나가는 단계. 1장의 슬라이더를 자동으로 돌리는 일입니다.
- Loss (손실)
- 모델의 답이 정답에서 얼마나 빗나갔는지를 나타내는 하나의 숫자. 작을수록 좋습니다.
- Benchmark (벤치마크)
- 여러 모델을 같은 시험지로 채점해 비교하는 표준 문제 모음.
- Deployment (배포)
- 모델을 버전이 붙은 소프트웨어 산출물로 포장하는 단계. 컨테이너 이미지로 만드는 작업이 여기 속합니다.
- Serving (서빙)
- 포장된 모델이 실제 요청을 받아 예측을 돌려주는 운영 단계. 이 글의 주제입니다.
- Latency (지연시간)
- 요청 하나가 답을 받기까지 걸린 시간. 사용자가 체감하는 "느림"입니다.
- Throughput (처리량)
- 일정 시간에 처리한 요청 수. 서버가 얼마나 많이 감당하는지를 나타냅니다.
- Retraining (재학습)
- 운영하면서 쌓인 실제 데이터를 다시 학습에 넣는 것. 생명주기가 "주기"인 이유입니다.
비유 먼저 — 신입 요리사
학습은 요리 학교에서 수천 번 연습하는 기간입니다. 재료를 낭비해도 되고, 시간이 오래 걸려도 됩니다. 중요한 건 얼마나 잘하게 되었는가 하나뿐입니다.
서빙은 점심시간 매장에 배치된 상태입니다. 실력은 이미 정해졌습니다. 이제 중요한 건 주문이 몰릴 때 몇 분 만에 나가는가, 하루 인건비가 얼마인가, 한 명이 쓰러져도 매장이 돌아가는가입니다.
같은 사람인데 평가 기준이 통째로 바뀝니다. 학습과 서빙의 관계가 정확히 이렇습니다.
생명주기 링 — 지금 어느 단계이고 무엇을 신경 쓰는가
↔ 슬라이더 + 클릭Deployment를 기점으로 지표가 정확도 계열 → 시간·비용 계열로 완전히 바뀝니다.
학습과 서빙은 무엇이 다른가
| 구분 | Training | Serving |
|---|---|---|
| 목표 | 정확도를 올리는 것 | 정해진 시간·비용 안에 답을 내놓는 것 |
| 핵심 지표 | accuracy, loss, benchmark 점수 | latency, throughput, 안정성, cost, 보안 |
| 실패의 모습 | 정확도가 안 오름 | 느려짐 · 터짐 · 비용 폭증 |
| 시간 감각 | 며칠~몇 주 걸려도 됨 | 밀리초 단위로 따짐 |
| 주 담당 | ML 엔지니어 · 리서처 | 개발자 · 인프라 엔지니어 |
생명주기의 마지막 Retraining은 서빙에서 나온 실제 요청 데이터를 다시 학습에 넣는 단계입니다. 그래서 서빙 단계에서 무엇을 로그로 남길지를 잘 설계해두면, 그게 다음 모델의 재료가 됩니다.
- 정의 — 생명주기는 데이터 수집 → training → evaluation → deployment → serving → monitoring → retraining으로 돌아갑니다.
- 성질 — serving은 학습된 모델이 실제 요청을 받아 예측을 반환하는 운영 단계입니다.
- 쓰임 — training은 accuracy를 보고, serving은 latency·throughput·안정성·cost·보안을 봅니다. 지표가 바뀐다는 걸 알면 대화가 통합니다.
— 여기까지: 서빙은 생명주기의 운영 구간이다. 다음은 그 안에서 요청 하나가 실제로 어떻게 흘러가는지 —
03모델 서빙이란 무엇인가
한 줄 요약: 요청을 받고 → 모델을 돌리고 → 결과를 돌려주는 것. 다만 그 사이에 신경 쓸 게 아주 많습니다.
절반은 맞습니다. 하지만 일반 API 서버와 결정적으로 다른 점이 하나 있습니다. LLM은 답을 한 번에 만들지 않고, 토큰을 한 개씩 순서대로 뱉습니다.
이 장에서는 요청 하나가 지나가는 경로와, LLM 특유의 지연시간 구조 TTFT와 TPOT를 알게 됩니다. 이 둘을 알면 "느리다"는 말을 숫자로 쪼갤 수 있습니다.
- Token (토큰)
- LLM이 글을 다루는 최소 단위. 대략 단어 조각 하나라고 생각하면 됩니다. 한국어는 보통 한 글자에 1~2 토큰입니다.
- Endpoint (엔드포인트)
- 모델을 부를 수 있는 주소.
POST /v1/chat/completions같은 것. - gRPC
- HTTP 대신 쓰는 더 빠른 통신 규약. 내부 서비스끼리 부를 때 자주 씁니다.
- TTFT (Time To First Token)
- 요청을 보낸 뒤 첫 글자가 화면에 뜨기까지의 시간. 사용자가 "반응이 있다"고 느끼는 순간입니다.
- TPOT (Time Per Output Token)
- 토큰 하나를 더 뱉는 데 걸리는 시간. 글자가 흘러나오는 속도를 정합니다.
- Streaming (스트리밍)
- 다 만든 뒤 한 번에 주지 않고, 만들어지는 대로 조금씩 흘려보내는 방식.
- KV Cache
- 이미 계산한 중간 결과를 메모장에 적어두고 다시 안 계산하는 장치. 이름만 기억해 두세요. 6장에서 다시 나옵니다.
비유 먼저 — 주문이 주방까지 가는 길
손님이 주문하면 홀 직원이 받아 적고(API server), 주방에 전달하고(routing), 요리사가 만들고(model), 서빙 직원이 가져다줍니다(response).
여기서 LLM이 특이한 점은, 요리가 한 접시씩 완성되어 나온다는 것입니다. 파스타 한 그릇을 통째로 주는 게 아니라 면 한 가닥씩 계속 내보냅니다. 첫 가닥이 나오기까지 걸린 시간이 TTFT, 그 뒤 한 가닥 간격이 TPOT입니다.
작은 숫자로 한 번
답변이 토큰 12개짜리라고 해봅시다. 첫 토큰까지 0.4초, 그 뒤로는 토큰 하나에 0.03초라면?
남은 토큰 = 12 - 1 = 11개
TPOT = 0.03초
──────────────────
11 × 0.03 = 0.33초
전체 = 0.40 + 0.33 = 0.73초
여기서 중요한 건, 같은 0.73초라도 체감이 다르다는 점입니다. TTFT가 0.1초이고 TPOT가 길면 "빠르게 시작해서 천천히 흐르는" 느낌이고, TTFT가 0.7초이고 나머지가 순식간이면 "한참 멈췄다가 확 나오는" 느낌입니다. 뒤쪽이 훨씬 답답하게 느껴집니다.
요청 하나의 여정 — TTFT와 TPOT를 눈으로 보기
↔ 재생 버튼 + 슬라이더전체 시간이 같아도 TTFT가 큰 쪽이 훨씬 답답합니다. 그래서 두 지표를 나눠서 측정합니다.
서빙이 실제로 챙기는 것들
"요청 받고 모델 돌리고 응답" 사이에 실제로는 이런 것들이 들어갑니다.
- 입력 검증과 전처리 텍스트를 토큰으로 바꾸고(tokenize), 길이 제한을 넘지 않는지 확인합니다.
- 배치 묶기와 스케줄링 여러 요청을 한 번에 GPU로 보내면 훨씬 효율적입니다. 누구를 언제 묶을지 정하는 게 scheduler입니다.
- 실행과 스트리밍 GPU에서 토큰을 하나씩 만들고, 만들어지는 대로 흘려보냅니다.
- 관측과 방어 지연시간·에러율을 기록하고, 과도한 요청을 막고, 인증을 확인합니다.
LLM 서빙에서는 일반 모델 서빙 지식만으로 부족합니다. 토큰 생성 방식 · KV Cache · attention 비용 · batching · decoding · GPU memory 병목 같은 LLM 고유의 성질을 알아야 성능과 비용을 제어할 수 있습니다. 그래서 Transformer에 대한 탄탄한 이해가 사실상 전제 조건입니다.
뒤집어 말하면 — LLM 서빙 기술의 발전은 전부 "LLM을 돌릴 때 생기는 병목을 어떻게 없앨까"에서 나왔습니다. 구조를 알면 왜 그 기법이 생겼는지가 자연스럽게 보입니다.
- 정의 — 모델 서빙은 입력 요청 수신 → 모델 실행 → 예측 반환을 API·웹 서비스 형태로 제공하는 과정입니다.
- 성질 — LLM은 토큰을 하나씩 뱉기 때문에 지연시간이 TTFT와 TPOT 둘로 쪼개집니다.
- 쓰임 — "느리다"는 민원이 오면 둘 중 어느 쪽인지부터 봅니다. 원인도 해법도 완전히 다릅니다.
— 여기까지: 요청 하나가 지나가는 길. 다음은 "그걸 클라우드가 다 해주는데 왜 알아야 하나"에 대한 답 —
04왜 모델 서빙을 공부해야 하는가
한 줄 요약: 모든 상황에 맞는 서빙 정답은 없습니다. 그래서 원리를 알아야 고를 수 있습니다.
managed endpoint를 쓰면 확실히 편합니다. 그런데 편한 건 배포까지입니다. 그 뒤에 "왜 이렇게 느리죠?" "이번 달 청구서가 왜 이렇죠?"라는 질문이 오면, 버튼 몇 개로는 답이 안 나옵니다.
이 장에서는 서빙에서 반드시 저울질해야 하는 세 가지가 무엇이고, 왜 셋을 동시에 만족시킬 수 없는지를 알게 됩니다.
- Managed Endpoint
- 클라우드가 서버·확장·모니터링을 대신 관리해 주는 모델 주소. SageMaker Inference Endpoint 같은 것.
- Autoscaling (오토스케일링)
- 트래픽이 늘면 서버 대수를 자동으로 늘리고 줄면 다시 줄이는 기능.
- Routing (라우팅)
- 들어온 요청을 어느 서버로 보낼지 정하는 일. 8장에서 자세히 다룹니다.
- SLA (Service Level Agreement)
- "응답의 99%는 2초 안에" 같은 지켜야 할 약속. 못 지키면 계약·신뢰 문제가 됩니다.
- Cost per request
- 요청 1건을 처리하는 데 드는 돈. 서빙의 성적표 중 가장 냉정한 숫자입니다.
- Vendor lock-in
- 특정 업체 기술에 너무 묶여서 나중에 옮기기 어려워지는 상태.
- GPU Utilization
- 비싼 GPU가 실제로 일한 시간의 비율. 낮으면 돈을 태우면서 놀리고 있는 겁니다.
비유 먼저 — 자동변속기
자동변속기 차는 평지에서는 아무 생각 없이 몰아도 됩니다. 그런데 급경사에서 엔진이 울부짖을 때, 변속기가 어떻게 동작하는지 아는 사람은 기어를 낮춰 해결합니다. 모르는 사람은 그냥 액셀만 더 밟습니다.
managed endpoint도 같습니다. 평상시엔 몰라도 됩니다. 문제가 생긴 그날, 아는 사람과 모르는 사람의 차이가 몇 배로 벌어집니다.
클라우드를 써도 결국 내가 정해야 하는 것들
- 어떤 모델을 어떤 인프라에 올릴지 7B 모델을 A100에 올릴지 L4 여러 대에 올릴지 — 이건 아무도 대신 정해주지 않습니다.
- latency와 throughput 목표를 어떻게 맞출지 둘은 서로 잡아당깁니다. 어느 쪽을 얼마나 포기할지는 서비스마다 다릅니다.
- GPU · CPU · memory 비용을 어떻게 통제할지 GPU 활용률이 20%면 요금의 80%를 버리고 있는 것입니다.
- autoscaling과 routing을 어떻게 설계할지 기준을 잘못 잡으면 늘 부족하거나 늘 남습니다.
- 모니터링 · 보안 · 장애 대응을 어떻게 구성할지 터졌을 때 어디를 볼지 미리 정해두지 않으면, 터진 다음엔 늦습니다.
세 개의 저울 — latency · throughput · cost는 동시에 못 잡는다
↔ 슬라이더 3개"모든 상황에 맞는 하나의 서빙 솔루션은 없다." 모델 크기, 트래픽 패턴, 보안 요구사항, 비용 구조, 지연시간 목표 — 이 다섯 개가 다르면 설계가 달라집니다.
그리고 기술은 계속 바뀝니다. 작년의 최적해가 올해는 아닙니다. 기본기를 알아야 새 기술이 나왔을 때 장단점을 스스로 판단할 수 있고, 특정 프레임워크나 벤더에 묶이지 않은 채 비즈니스에 유리한 선택을 할 수 있습니다.
- 정의 — 서빙 설계는 latency · throughput · cost 세 개를 저울질하는 일입니다.
- 성질 — 셋은 서로 잡아당깁니다. 하나를 좋게 하면 대개 다른 하나가 나빠집니다. 정답은 서비스마다 다릅니다.
- 쓰임 — 클라우드를 쓰더라도 원리를 알아야 비용·보안·성능에서 최적의 판단을 내리고 vendor lock-in을 피할 수 있습니다.
— 여기까지: 저울질이 서빙의 본질이다. 다음은 LLM에서 그 저울이 왜 유독 무섭게 기울어지는지 —
05LLM 서빙 최적화가 중요한 이유
한 줄 요약: 데모에서 잘 돌던 시스템이 실제 유저 앞에서 무너지는 건, 대기줄이 쌓이는 속도 때문입니다.
서버 성능이 갑자기 나빠진 게 아닙니다. 모델도 그대로입니다. 달라진 건 줄을 서는 사람의 수 하나뿐입니다.
이 장에서는 왜 부하가 조금만 늘어도 지연시간이 완만하게가 아니라 절벽처럼 나빠지는지를 직접 만져보며 확인합니다. 이걸 보고 나면 "최적화는 나중에"라는 말이 안 나옵니다.
- Queue (큐) · 대기열
- 처리되기를 기다리는 요청들이 서 있는 줄.
- Arrival rate (도착률)
- 1초에 몇 건이 들어오는가. 손님이 오는 속도입니다.
- Service rate (처리율)
- 1초에 몇 건을 처리할 수 있는가. 계산대의 속도입니다.
- Tail latency · p99
- 느린 쪽 상위 1%가 겪은 지연시간. 평균은 멀쩡한데 일부 사용자만 30초 기다리는 상황을 잡아냅니다.
- Cost per request
- 요청 1건당 드는 돈. 4장에서 나왔습니다.
- Saturation (포화)
- 도착률이 처리율을 넘어 줄이 영원히 줄지 않는 상태. 여기 들어가면 지연시간은 시간이 갈수록 계속 커집니다.
비유 먼저 — 계산대 하나짜리 마트
계산에 1인당 6초가 걸리는 계산대가 하나 있습니다. 1분에 최대 10명입니다.
손님이 1분에 8명 오면 줄은 짧게 유지됩니다. 9명이면 조금 길어지지만 버팁니다. 그런데 11명이 오는 순간, 줄은 영원히 줄어들지 않습니다. 1분마다 1명씩 계속 쌓이기 때문입니다. 10명과 11명의 차이는 10%인데, 결과는 "괜찮음"과 "붕괴"입니다.
작은 숫자로 한 번
── 경우 A: 초당 1.5건 도착 ──
2 - 1.5 = 0.5 // 여유가 남음 → 줄이 안 쌓임
── 경우 B: 초당 3건 도착 ──
3 - 2 = 1 // 매초 1건씩 밀림
60초 뒤 대기 = 60건
대기시간 = 60 ÷ 2 = 30초
// 5분 뒤에는? 150초. 계속 커집니다.
도착률이 처리율의 1.5배가 되었을 뿐인데, 지연시간은 시간이 갈수록 무한히 커집니다. 이게 "데모는 됐는데 런칭하면 무너진다"의 정체입니다.
대기열 절벽 — 부하 10%가 지연시간 10배가 되는 순간
↔ 드래그 + 슬라이더곡선이 치솟기 직전 지점이 실제 운영 한계입니다. 여기에 여유를 안 두면 트래픽이 조금만 튀어도 무너집니다.
그래서 최적화란 무엇을 뜻하나
모델 서빙 최적화는 지연시간을 줄이고, 처리량을 늘리고, 자원 활용도를 높여 서빙 성능을 끌어올리는 작업입니다. 구체적으로는 이 여섯 개를 봅니다.
| 지표 | 좋은 방향 |
|---|---|
| latency | 낮게 — 사용자가 덜 기다림 |
| throughput | 높게 — 같은 장비로 더 많이 처리 |
| GPU utilization | 높게 — 비싼 장비를 안 놀림 |
| cost per request | 낮게 — 요청 1건당 원가 |
| tail latency (p99) | 안정적으로 — 일부 사용자만 오래 기다리는 일 없게 |
| memory 사용 | 효율적으로 — 같은 메모리로 더 많은 요청 수용 |
목표는 하나입니다. 비용을 통제하면서 서빙 효율을 최대로 끌어올리는 것.
LLM은 연산 요구량이 압도적으로 커서 운영 비용 부담이 큽니다. Alphabet 회장 John Hennessy는 2023년 로이터 인터뷰에서 "LLM 요청 1건 처리 비용이 전통적인 키워드 검색보다 10배 비쌀 수 있고, 이는 수십억 달러 규모의 추가 비용으로 이어질 수 있다"고 말했습니다.
그래서 LLM에서 최적화는 "성능을 조금 더 짜내는 선택지"가 아니라 서비스를 유지할 수 있느냐의 문제에 가깝습니다.
- 정의 — 최적화는 latency를 낮추고 throughput과 자원 활용도를 높여 비용 대비 효율을 끌어올리는 작업입니다.
- 성질 — 도착률이 처리율에 가까워지면 지연시간은 완만하게가 아니라 절벽처럼 나빠집니다. 그래서 여유를 남겨야 합니다.
- 쓰임 — LLM은 요청 1건 원가가 크기 때문에, 최적화가 곧 서비스의 지속 가능성입니다.
— 여기까지: 절벽이 왜 생기는가. 다음은 그 절벽을 오른쪽으로 밀어내는 실제 도구 —
06vLLM — 설정값 하나가 성능을 바꾼다
한 줄 요약: 같은 GPU, 같은 모델인데 설정 두 개만 바꿔서 15배가 나온 사례가 있습니다.
모델도 같고 GPU도 같은데 결과가 다르면, 남은 변수는 어떻게 돌렸는가뿐입니다. 그 "어떻게"를 담당하는 게 serving engine이고, 대표 주자가 vLLM입니다.
이 장에서는 vLLM이 무엇을 다르게 하는지, 그리고 서버를 띄울 때 넣는 옵션 하나하나가 성능을 어떻게 바꾸는지를 직접 밀어보며 확인합니다.
- vLLM
- LLM 전용 추론·서빙 엔진. "높은 throughput과 메모리 효율"을 목표로 만들어진 오픈소스입니다.
- KV Cache
- 이미 계산한 토큰의 중간 결과를 저장해두고 재사용하는 메모리. 대화가 길어질수록 이게 커지고, GPU 메모리를 제일 많이 잡아먹습니다.
- PagedAttention
- KV Cache를 작은 조각(page)으로 쪼개서 관리하는 기법. 빈 공간 낭비를 크게 줄입니다. vLLM에서 기본으로 켜져 있습니다.
- Continuous Batching (동적 배칭)
- 먼저 온 요청들이 다 끝날 때까지 기다리지 않고, 끝난 자리에 새 요청을 바로 끼워 넣는 방식.
- dtype · fp16 / bf16 / fp8
- 숫자 하나를 몇 비트로 표현할지. 비트가 적을수록 메모리를 덜 쓰고 빨라지지만, 정밀도를 조금 잃습니다.
--gpu-memory-utilization- GPU 메모리를 몇 %까지 쓸 것인가. 높이면 KV Cache 공간이 늘어 더 많은 요청을 담지만, 너무 높이면 터집니다.
--max-num-seqs- 동시에 처리할 요청(sequence) 최대 개수. 사실상 batch size입니다.
- Tensor Parallelism ·
--tensor-parallel-size - 모델 하나를 GPU 여러 장에 쪼개 나눠 싣는 것. 혼자서는 안 들어가는 큰 모델을 올릴 때 씁니다.
- OOM (Out Of Memory)
- 메모리가 모자라서 프로세스가 죽는 것. 서빙에서 제일 자주 만나는 사고입니다.
비유 먼저 — 버스와 사물함
Continuous batching은 버스입니다. 승객 한 명당 택시를 부르면 도로가 마비됩니다. 버스에 여럿을 태우면 한 번에 옮길 수 있습니다. 다만 버스를 꽉 채우려고 기다리면 먼저 탄 사람이 오래 기다립니다. 그래서 vLLM은 정류장에 서서 기다리지 않고, 내린 자리에 바로 다음 사람을 태웁니다.
PagedAttention은 사물함입니다. 짐 크기가 제각각인데 사물함을 큰 것 하나만 주면, 작은 짐을 넣은 칸은 대부분 빈 공간이 됩니다. 칸을 잘게 나눠서 필요한 만큼만 쓰게 하면 같은 벽면에 훨씬 많은 짐이 들어갑니다. KV Cache를 이렇게 관리하는 게 PagedAttention입니다.
vLLM은 실제로 어떻게 띄우나
파이썬에서 직접 부르는 방법과, OpenAI 호환 서버로 띄우는 방법 두 가지가 있습니다.
llm = LLM(
model="Qwen/Qwen3-7B-Instruct",
dtype="float16",
max_model_len=32768,
gpu_memory_utilization=0.8,
)
outputs = llm.generate(prompts, sampling)
# ② OpenAI 호환 서버 — 기존 코드를 그대로 재사용
vllm serve Qwen/Qwen3-7B-Instruct \
--dtype bfloat16 \
--max-model-len 32768 \
--gpu-memory-utilization 0.8
# 그러면 이렇게 부를 수 있습니다
curl http://localhost:8000/v1/chat/completions ...
②가 실무에서 특히 유용합니다. OpenAI SDK를 쓰던 코드에서 주소만 바꾸면 그대로 우리 GPU의 모델을 부르게 됩니다.
vLLM 설정 놀이터 — 옵션을 밀면 무슨 일이 나는가
↔ 슬라이더 + 버튼--max-num-seqs를 키우면 throughput이 올라가는 대신 요청 하나의 latency도 같이 올라갑니다.
② --gpu-memory-utilization을 0.98까지 밀어보세요. KV Cache 공간은 커지지만 여유가 사라져 OOM 경고가 뜹니다.
③ dtype을 fp16 → fp8로 바꿔보세요. 같은 GPU에 두 배 가까이 담깁니다. ④ tensor-parallel을 올리면 큰 모델이 들어가지만 GPU 간 통신 비용이 붙습니다.vLLM 내부는 어떻게 생겼나
이름만 훑어두면 됩니다. 책 8장에서 다시 만납니다. (이 페이지의 8장이 아니라 원서 8장입니다.)
| 구성 요소 | 하는 일 |
|---|---|
| LLMEngine | 사용자가 부르는 API와 엔진 속을 이어주는 조율 계층 |
| EngineCore | scheduler · KV cache manager · model executor를 조율 |
| Scheduler | 어떤 요청을 이번 회차에 넣을지 결정 — continuous batching의 두뇌 |
| ModelExecutor | worker 프로세스 관리와 분산 실행 담당 |
| GPUWorker / GPUModelRunner | GPU에서 실제 계산을 수행 |
숫자로 확인된 차이
vLLM 팀이 2023년에 공개한 실험(A10G의 Llama-7B, A100 40GB의 Llama-13B)에서는 HF Transformers 대비 최대 24배, HF TGI 대비 최대 3.5배 처리량이 나왔습니다. (그래프 기준으로는 HF 대비 8.5~15배, TGI 대비 3.3~3.5배입니다.)
책 저자들의 DeepSeek R1 실험은 더 극적입니다. 설정을 두 개만 바꿔서 — FP8 MLA 커널을 켜고 batch size를 키운 것 — 38 TPS에서 600 TPS로 15배가 되었습니다.
GPU는 비쌉니다. 인프라를 하나도 안 늘리고 설정만으로 처리량이 몇 배가 된다면, 그건 성능 튜닝이 아니라 예산 결정입니다. 서빙 프레임워크의 설정값 하나하나가 잠재적 최적화 포인트입니다.
실제 실행 명령을 통째로 보고 싶다면
--model openai/gpt-oss-20b \
--dtype bf16 \
--gpu-memory-utilization 0.9 \
--max-num-seqs 16 \
--max-num-batched-tokens 16384 \
--tensor-parallel-size 2
읽는 법 — gpt-oss 20B 모델을 H100 80GB 두 장에 올리는 설정입니다.
--dtype bf16은 계산 정밀도, --max-num-batched-tokens는
한 배치에 담을 토큰 수 상한, --tensor-parallel-size 2는 GPU 두 장에 모델을 쪼갠다는 뜻입니다.
PagedAttention은 옵션이 없습니다 — 기본으로 켜져 있습니다.
각 값의 자세한 조정법은 책 6~7장에서 다룹니다.
- 정의 — vLLM은 높은 throughput과 메모리 효율을 목표로 만든 LLM 전용 inference·serving engine입니다.
- 성질 — PagedAttention(메모리 조각 관리)과 continuous batching(빈 자리에 즉시 투입)이 핵심이고, 나머지는 설정값으로 조율합니다.
- 쓰임 — 하드웨어를 늘리기 전에 설정부터 봅니다. 설정 두 개로 15배가 나온 사례가 실제로 있습니다.
— Part 2. 모델 서빙 방안 — 여기서부터는 "어디에, 어떻게 올릴 것인가" 네 가지 —
07On-Device Serving — 서버 없이 기기에서
한 줄 요약: 모델을 서버가 아니라 사용자의 폰·드론·카메라 안에서 직접 돌리는 방식입니다.
서버를 못 부르는데도 동작한다면, 모델이 기기 안에 있다는 뜻입니다. 지연시간이 0에 가깝고 데이터가 밖으로 나가지 않는 대신, 대가가 분명히 있습니다.
이 장에서는 온디바이스가 언제 정답이고 언제 함정인지를 구분하는 기준을 얻습니다.
- On-Device / Edge Serving
- 모델을 서버가 아니라 사용자 기기(스마트폰·드론·카메라·로봇) 안에서 직접 실행하는 방식.
- Model Runtime
- 기기와 OS가 제각각이어도 모델이 돌아가게 가운데서 맞춰주는 소프트웨어 층. LiteRT, ONNX Runtime(ORT), Core ML 등이 있습니다.
- Delegate
- 계산의 일부를 GPU나 NPU 같은 전용 하드웨어에 넘기는 기능.
- NPU (Neural Processing Unit)
- AI 계산 전용 칩. 아이폰의 Neural Engine, 안드로이드의 Snapdragon 계열 등 기기마다 다릅니다.
- Model Wrapper
- 개발자가 직접 만드는 층. 입력 전처리 → 모델 로딩 → 실행 → 출력 후처리를 감싸서, 앱은 한 줄로 모델을 부르게 됩니다.
- Convert (변환)
- 학습용 형식을 기기용 형식으로 바꾸는 것. 예: PyTorch ResNet →
.tflite
비유 먼저 — 공구를 집에 둘 것인가
드라이버가 필요할 때마다 공구 대여점에 다녀오면, 왕복 시간이 듭니다. 대신 집에 두면 즉시 쓸 수 있습니다. 그게 온디바이스입니다.
단점도 같습니다. 집이 좁으면 큰 공구는 못 둡니다(메모리 제약). 더 좋은 신제품이 나와도 집집마다 배달해야 바뀝니다(업데이트 문제). 그리고 집마다 콘센트 규격이 달라서 어떤 집에선 잘 안 돌아갑니다(하드웨어 파편화).
온디바이스 앱은 두 층으로 되어 있다
- Model Runtime — 아래층 기기와 OS 차이를 흡수합니다. GPU·NPU에 계산을 넘기는 delegate도 여기서 담당합니다. 우리가 만드는 게 아니라 가져다 쓰는 것입니다.
- Model Wrapper — 윗층
우리가 직접 만듭니다. 앱 로직이
predict(image)한 줄로 부를 수 있게, 전처리와 후처리를 안쪽에 숨깁니다.
흐름은 이렇습니다. 앱 로직 → model wrapper 호출 → (데이터 변환) → model runtime 실행 → 기기 하드웨어에서 inference.
모델을 기기용으로 준비하는 과정은 네 단계입니다. Qualcomm AI Hub 같은 도구가 이 과정을 자동화해 줍니다.
- Convert학습 형식 → 런타임 전용 형식으로 변환합니다.
- 정확도 검증서버와 기기에서 같은 입력을 넣고 출력 차이를 비교합니다. 변환하면서 품질이 떨어지지 않았는지 확인하는 단계입니다.
- 성능 측정실제 기기에서 요구 속도가 나오는지 잽니다.
- 패키징 · 배포앱 설치·업데이트에 포함해서 내보냅니다.
On-Device vs Cloud — 어느 쪽이 빠른지는 상황이 정한다
↔ 슬라이더 3개언제 쓰고, 무엇을 포기하나
| 구분 | 온디바이스가 적합한 경우 | 온디바이스의 제약 |
|---|---|---|
| 프라이버시 | 생체 인증, 건강 데이터처럼 원본이 기기 밖으로 나가면 안 되는 경우 |
① 연산·저장 공간 제약 — 대형 모델은 아예 안 들어갑니다. (Gemma 3 270M처럼 온디바이스를 노리고 만든 경량 모델은 예외) ② 전력 소모 — 배터리를 빠르게 씁니다. 저해상도를 고해상도로 실시간 변환하는 작업 같은 건 전력 때문에 로컬에서 잘 안 합니다. ③ 업데이트가 어려움 — 모델을 고치면 모든 기기에 앱 업데이트를 뿌려야 합니다. 은행 앱 사기 탐지 모델을 자주 고쳐야 한다면 큰 부담입니다. ④ 하드웨어 파편화 — 기기마다 NPU 지원이 다릅니다. iPhone Neural Engine에 최적화한 모델이 Android Snapdragon에서는 비효율적일 수 있습니다. |
| 초저지연 | 제스처 인식, 로봇 제어, AR/VR, 실시간 오디오처럼 밀리초가 중요한 경우 | |
| 불안정한 연결 | 산업 장비, 원격 센서, 차량, 드론 | |
| IoT · 로봇 | 특정 작업에 맞춘 저전력 경량 모델이면 충분한 경우 |
- 정의 — On-device serving은 모델을 사용자 기기 안에서 직접 실행하는 방식이고, model runtime + model wrapper 두 층으로 구성됩니다.
- 성질 — 지연시간과 프라이버시에서 강하고, 메모리·전력·업데이트·하드웨어 파편화에서 약합니다.
- 쓰임 — 모델이 기기에 들어가고, 자주 안 고쳐도 되고, 네트워크를 못 믿을 때 고릅니다.
— 여기까지: 기기 안에서 돌리기. 다음은 반대편 — 서버에 올리는 가장 기본적인 방식 —
08Single-model Service — 모델 하나에 서비스 하나
한 줄 요약: 가장 단순하고 가장 성능이 좋습니다. 대신 모델이 많아지면 감당이 안 됩니다.
맞습니다. 클라우드 모델 서빙에서 가장 널리 쓰이는 고전적인 패턴이고, 특별한 이유가 없으면 이걸 고릅니다. 이유는 성능과 격리입니다.
이 장에서는 이 방식의 내부 구조, 요청을 어느 서버로 보낼지 정하는 라우팅 전략, 그리고 트래픽이 늘 때 어느 방향으로 키우는지를 알게 됩니다.
- Single-model Service
- 모델 하나(또는 모델 버전 하나)를 독립된 웹 서비스로 배포하는 방식.
- API Server · Model Management · Inference Backend
- 서빙 컨테이너 안의 세 부품. 각각 외부에 노출 / 모델 파일 관리 / 실제 실행을 맡습니다.
- Round Robin
- 요청을 순서대로 돌아가며 서버에 나눠주는 가장 단순한 방식. c1 → c2 → c3 → c1 …
- Least Connections
- 지금 처리 중인 요청이 가장 적은 서버로 보내는 방식.
- Least Response Time
- 최근에 가장 빨리 답한 서버로 보내는 방식.
- Horizontal Scaling (Scale Out)
- 같은 컨테이너를 여러 대로 늘리는 것. 옆으로 키웁니다.
- Vertical Scaling (Scale Up)
- 더 큰 GPU를 쓰거나 여러 GPU에 모델을 쪼개는 것. 위로 키웁니다.
- HPA (Horizontal Pod Autoscaler)
- Kubernetes에서 지표를 보고 컨테이너 수를 자동 조절하는 장치.
- NVLink · InfiniBand(IB) · RoCEv2
- 각각 같은 기계 안 GPU끼리, 기계와 기계 사이를 잇는 통신 방식. 속도 차이가 큽니다.
- Bin Packing
- 남는 공간이 없게 차곡차곡 채워 배치하는 스케줄링 전략. 상자에 짐을 빈틈없이 담는 그림을 떠올리면 됩니다.
비유 먼저 — 창구가 여러 개인 은행
창구마다 같은 업무를 하는 직원이 앉아 있습니다. 손님이 오면 안내 직원이 어느 창구로 갈지 정해줍니다. 이 안내 직원이 라우터입니다.
가장 단순한 안내는 "1번, 2번, 3번, 다시 1번" 순서대로입니다(round robin). 손님 업무가 다 비슷하면 잘 굴러갑니다. 그런데 어떤 손님은 대출 상담 40분, 어떤 손님은 입금 1분이라면? 순서대로 보내는 순간 1번 창구만 지옥이 됩니다.
작은 숫자로 한 번
요청 1: 5000토큰 (10초) → c1
요청 2: 100토큰 (0.2초) → c2
요청 3: 100토큰 (0.2초) → c3
요청 4: 5000토큰 (10초) → c1 // 또 c1!
요청 5: 100토큰 → c2
요청 6: 100토큰 → c3
──────────────────
c1이 짊어진 시간 = 20초
c2 = 0.4초 c3 = 0.4초 // 두 대는 거의 놀고 있음
그래서 가중 round robin(성능 좋은 서버에 더 많이), least connections(지금 한가한 서버로), least response time(최근 빨랐던 서버로), 동적 로드 밸런싱(CPU·GPU·큐 길이 실시간 지표 기반) 같은 전략이 나옵니다. LLM에 특화된 더 똑똑한 라우팅(예: 같은 프롬프트 앞부분을 캐시해둔 서버로 보내는 cache-aware routing)은 뒤 장에서 다룹니다.
라우팅 전략 비교 — 순서대로 보내면 왜 망가지는가
↔ 버튼 + 재생LLM 요청은 길이 편차가 매우 큽니다. 그래서 round robin이 특히 잘 안 맞습니다.
컨테이너 하나의 속은 세 부품
| 부품 | 하는 일 |
|---|---|
| API Server | HTTP/gRPC로 추론 기능을 외부에 노출 |
| Model Management | 모델 다운로드 → 로컬 저장 → 백엔드에 로딩. 새 모델이 올라오면 감지해 자동 갱신 |
| Inference Backend | 실제 실행 담당. TensorFlow Serving, TorchServe, vLLM, TensorRT-LLM 등을 씁니다 |
트래픽이 늘면 어느 방향으로 키우나
- Horizontal — 옆으로 같은 컨테이너를 여러 대 추가합니다. Kubernetes HPA가 CPU·메모리·지연시간·요청 수를 보고 자동 조정합니다. 모델이 GPU 한 장에 들어갈 때의 기본 선택입니다.
- Vertical — 위로
모델이 너무 커서 GPU 한 장에 안 들어갈 때(Llama-2-70B 같은 경우), 더 큰 GPU를 쓰거나 여러 GPU에 쪼개 싣습니다. vLLM에서는
--tensor-parallel-size 4한 줄이면 됩니다.
여러 기계에 걸쳐 나누는 것(inter-node)보다 한 기계 안의 여러 GPU(intra-node)가 낫습니다. 기계를 넘어가면 네트워크 지연과 동기화 복잡도가 붙기 때문입니다.
숫자로 보면 확실합니다. 같은 기계 안의 NVLink는 900GB/s, 기계 사이의 IB/RoCEv2는 400Gbps = 50GB/s. 약 18배 차이입니다. 모델을 쪼개면 GPU끼리 계속 중간 결과를 주고받아야 하는데, 그 통로가 18배 좁아지는 셈입니다.
기본 스케줄러는 파드를 골고루 분산합니다. GPU 노드가 5개이고 1 GPU짜리 파드가 5개면, 노드마다 하나씩 흩어 놓습니다. 그러면 각 노드에 애매하게 남은 GPU 조각이 생깁니다(파편화).
Bin packing은 반대로 한 노드를 빈틈없이 채우고 다음 노드로 넘어갑니다. 그러면 완전히 비어 있는 노드가 생겨서, 큰 워크로드를 넣거나 노드를 꺼서 비용을 줄일 수 있습니다.
왜 이게 기본 선택지인가, 그리고 한계
| 구분 | 내용 |
|---|---|
| 장점 | 자원 경쟁이 없어 최고 성능·최저 지연시간 · 모델별 독립 확장 · 로그와 지표가 격리돼 디버깅이 쉬움 · 한 모델이 죽어도 다른 모델 무사 · 모델별 하드웨어 최적화로 비용 통제 용이 |
| 한계 | 자원 효율이 나쁩니다. 고객 100명이 각자 모델 10개를 쓰는 에이전트 플랫폼이면 1,000개의 독립 서비스가 됩니다. 유지보수·패치·모니터링 부담이 압도적이고, 거의 안 쓰이는 모델도 GPU를 붙잡고 있습니다. |
이 한계를 풀기 위해 나온 것이 다음 장의 Multi-Model Service입니다.
- 정의 — 모델(또는 모델 버전) 하나를 독립된 웹 서비스로 배포하고, 컨테이너 안은 API Server + Model Management + Inference Backend로 구성됩니다.
- 성질 — 성능과 격리가 최고입니다. 라우팅은 요청 길이 편차 때문에 round robin만으로는 부족하고, 확장은 horizontal이 기본, vertical은 모델이 클 때입니다.
- 쓰임 — 트래픽이 꾸준하고 저지연이 필요한 모델의 기본 선택. 모델 개수가 폭증하면 비용이 무너집니다.
— 여기까지: 모델 하나에 서비스 하나. 다음은 모델 1,000개를 어떻게 감당하는가 —
09Multi-Model Service — 컨테이너 하나에 여러 모델
한 줄 요약: 모든 모델을 항상 올려두지 않고, 요청이 올 때만 올렸다 내립니다.
8장 마지막의 그 문제입니다. 그런데 실제로는 1,000개 중 지금 이 순간 쓰이는 건 몇십 개뿐입니다. 나머지는 GPU를 붙잡은 채 놀고 있습니다.
이 장에서는 그 낭비를 없애는 방법과, 그 대가로 생기는 두 가지 새로운 골칫거리를 알게 됩니다.
- Multi-Model Service
- 서빙 컨테이너 하나가 여러 모델을 함께 호스팅하고 GPU·CPU·메모리를 나눠 쓰는 방식.
- Load / Unload
- 모델을 메모리에 올리기 / 내리기.
- LRU (Least Recently Used)
- 자리가 부족하면 가장 오랫동안 안 쓰인 것부터 내보내는 규칙.
- Cold start (콜드 스타트)
- 메모리에 없는 모델이 요청받아서 다운로드·로딩을 기다리는 시간. 몇 초에서 몇십 초까지 갑니다.
- Model swapping
- 자리를 만들려고 기존 모델을 내리고 새 모델을 올리는 것. 잦으면 그것만 하다 끝납니다.
- Route map
- "어느 모델이 어느 컨테이너에 올라가 있는지"를 적어둔 표.
- Replica (복제본)
- 한 모델을 몇 개 컨테이너에 올려둘지. 인기 모델은 이 수를 늘립니다.
- AI Gateway
- 모델 라우팅·인증·한도 관리를 맡는 앞단 관문 제품군. Envoy AI Gateway, LiteLLM 등이 있습니다.
- Triton Inference Server
- NVIDIA의 대표적인 멀티 모델 추론 백엔드. TensorFlow·ONNX·PyTorch 모델을 한 곳에서 다룹니다.
비유 먼저 — 책상과 책장
책상 위에는 책 세 권만 올라갑니다. 책장에는 1,000권이 있습니다.
지금 읽을 책을 책상에 올려놓고 읽습니다(load). 네 번째 책이 필요하면? 가장 오랫동안 안 펼친 책을 책장에 도로 꽂고 자리를 만듭니다(LRU unload). 책장에서 꺼내오는 그 시간이 cold start입니다.
대부분의 시간에는 잘 굴러갑니다. 문제는 세 권을 번갈아 가며 읽어야 할 때입니다. 꽂았다 뺐다만 반복하고 정작 읽는 시간이 없습니다. 이게 model swapping 지옥입니다.
모델 캐시 — 직접 요청을 보내 LRU가 도는 걸 보기
↔ 모델 버튼 클릭hit rate가 곧 사용자 체감 속도입니다. 슬롯을 늘리면 올라가지만, 그만큼 GPU 값을 더 냅니다.
컨테이너 안은 두 부품
- Model Server Inference Backend 모델마다 프레임워크가 달라도(TensorFlow · ONNX · PyTorch) 하나의 예측 API로 감싸주는 블랙박스. 안쪽에 프레임워크별 백엔드를 여러 개 갖고 있습니다. 대표 오픈소스가 NVIDIA Triton Inference Server입니다.
- Model Cache Management 저장소에서 모델을 받아 백엔드에 올리고, 자원 사용량이 임계치(예: 80%)를 넘으면 LRU로 가장 안 쓰인 모델을 내려 자리를 만듭니다.
요청이 오면 이렇게 처리합니다. ① 이미 로드돼 있으면 바로 실행. ② 없으면 저장소에서 받아 로드한 뒤 실행. ③ 메모리·디스크가 임계치를 넘으면 가장 덜 쓰인 모델을 언로드.
대가로 생기는 두 가지 문제
- 라우팅이 어려워집니다 모델이 어느 컨테이너에 있을지 모릅니다. 이미 그 모델이 올라간 컨테이너로 보내야 하는데, 잘못 보내면 cold start나 model swapping이 붙습니다.
- 모델별 스케일링이 어려워집니다 모델마다 트래픽이 다릅니다. 인기 있는(hot) 모델은 더 많은 인스턴스가 필요한데, 컨테이너 단위로만 늘리면 조절이 안 됩니다.
① replica 속성 — 각 모델을 몇 개 컨테이너에 올려둘지 정의합니다.
② route map — 어느 모델이 어느 컨테이너에 있는지 추적합니다.
모델 A의 replica가 2라면, 라우터가 A를 C1과 C3에 배치하고 이후 A 요청을 둘에 나눠 보냅니다. 트래픽이 변하면 replica 수를 실시간으로 조정하고, 새 replica를 어느 컨테이너에 넣을지도 라우터가 정합니다 — 8장에서 본 그 bin packing 문제입니다.
요즘은 이 역할을 AI Gateway 제품군이 맡습니다. Envoy AI Gateway, LiteLLM 같은 것들입니다.
· 모델이 너무 커서 GPU 하나에 여러 개를 얹을 여지가 아예 없는 경우
· 언로드가 잦아 cold start 오버헤드가 이득을 잡아먹는 경우
· 개별 모델 트래픽이 많고 저지연이 필요해 항상 올라가 있어야 하는 경우 → 8장의 single-model이 낫습니다
· 모델마다 보안 정책이 다른 경우
· 캐시 관리, 모델별 라우팅·스케일링, 프레임워크 호환성, 의존성 충돌로 운영 복잡도가 감당이 안 되는 경우
정리하면 single-model과 multi-model은 경쟁 관계가 아니라 상호 보완입니다. 실무에서는 둘을 섞어 씁니다. 그리고 그 "섞어 쓰는 틀"이 다음 장의 Model Serving Platform입니다.
- 정의 — 컨테이너 하나가 여러 모델을 함께 호스팅하고, 요청이 올 때 동적으로 load/unload합니다.
- 성질 — LRU 캐시로 자리를 관리하며 비용을 크게 아끼는 대신, 라우팅과 모델별 스케일링이라는 두 문제가 생깁니다. 해법은 route map + replica 수를 아는 라우터입니다.
- 쓰임 — 모델 수가 많고 개별 트래픽이 낮거나 불규칙할 때. 항상 뜨거운 모델은 single-model로 빼둡니다.
— 여기까지: 두 가지 서빙 방식. 다음은 그 둘을 한 지붕 아래 묶는 큰 그림 —
10Model Serving Platform — 여러 모델이 협업할 때
한 줄 요약: 요청 하나가 모델 다섯 개를 순서대로 거쳐야 한다면, 그걸 관리하는 층이 따로 필요합니다.
실제 서비스는 모델 하나로 안 끝납니다. 음성 비서는 음성 인식 → 자연어 이해 → 추천 → 음성 합성을 한 번의 명령에 다 돌립니다.
이 장에서는 여러 모델을 순서대로 또는 동시에 엮는 구조와, 앱마다 자원을 갈라 쓰는 방법을 알게 됩니다. 여기까지 오면 CH1의 그림이 완성됩니다.
- Gateway
- 외부 요청이 맨 처음 들어오는 문. 인증·한도 확인이 여기서 이뤄집니다.
- Graph Execution (그래프 실행)
- 여러 모델 호출을 정해진 순서와 갈래대로 실행하는 것. 순서도를 그대로 돌린다고 보면 됩니다.
- Workflow (워크플로우)
- "이 요청은 이 순서로 처리한다"고 미리 정의해 둔 절차. Airflow, Ray 같은 도구로 만듭니다.
- Resource Group (리소스 그룹)
- 앱·비즈니스별로 CPU·GPU·메모리 몫을 갈라 놓은 칸. 한 앱이 다 써버리는 걸 막습니다.
- Quota (쿼터)
- 그 칸에 배정된 한도.
- KServe
- Kubernetes 네이티브 서빙 플랫폼(구 KFServing). autoscaling(scale-to-zero 포함)과 멀티 프레임워크를 지원합니다.
- Scale-to-zero
- 요청이 없으면 인스턴스를 0개까지 줄이는 기능. 안 쓰는 동안 돈이 안 나갑니다. 대신 첫 요청에 cold start가 붙습니다.
- Ray Serve
- Ray 기반 서빙. 다단계 추론 그래프를 짜는 데 강합니다.
- MLflow
- 모델 레지스트리·실험 추적과 서빙을 함께 관리하는 도구.
비유 먼저 — 공항
비행기 한 대가 뜨려면 체크인 → 보안 → 게이트 → 활주로 배정 → 관제가 순서대로 돌아가야 합니다. 각 단계는 독립된 조직이지만, 누군가는 전체 순서를 관리해야 합니다. 그 역할이 graph execution입니다.
그리고 공항에는 항공사마다 배정된 게이트 수가 있습니다. 한 항공사가 게이트를 다 쓰면 다른 항공사가 마비되니까요. 이 배분이 resource group입니다.
플랫폼을 이루는 네 부품
- Gateway 외부 요청의 진입점. 접근 제어와 보안이 붙습니다.
- Routing 어떤 모델과 어떤 serving group으로 보낼지 고릅니다. 8·9장에서 본 그 라우터입니다.
- Graph Execution 한 요청이 여러 모델을 순차 또는 병렬로 쓰게 해줍니다. 각 앱 팀이 자기 워크플로우를 정의해 올려두면, 요청이 올 때 엔진이 그대로 실행하며 단계마다 라우팅을 부릅니다.
- Resource Groups 앱·시나리오별로 워크로드를 분리합니다. 예를 들어 App1 그룹 안에 single-model 서비스 2개와 multi-model 서비스 1개가 같이 삽니다. 그룹마다 자체 CPU/GPU/메모리 쿼터를 받습니다.
전체 흐름은 이렇습니다. 요청 → Gateway → Graph Execution(다단계 실행) → 단계마다 Routing 호출 → 해당 Resource Group의 single/multi 모델 서비스. 실제 제품에는 여기에 접근 제어·보안·metric/monitoring·배포 파이프라인 통합이 더 붙습니다.
Graph Execution — 다섯 모델을 순서대로 vs 겹쳐서
↔ 재생 + 토글 + 슬라이더총 지연시간의 대부분을 한 단계가 차지한다면, 나머지를 아무리 다듬어도 체감이 거의 안 바뀝니다.
실제로 쓰는 플랫폼들
| 이름 | 강점 |
|---|---|
| KServe 구 KFServing | Kubernetes 네이티브. autoscaling(scale-to-zero 포함)과 멀티 프레임워크 지원 |
| Ray Serve | Ray 기반. 다단계 추론 그래프(graph execution) 구성에 강점 |
| MLflow | 모델 레지스트리와 연동된 서빙. 실험 추적까지 통합 관리 |
- 정의 — Model serving platform은 Gateway + Routing + Graph Execution + Resource Groups로, 여러 앱·모델·워크플로우를 한 지붕 아래 묶습니다.
- 성질 — graph execution이 여러 모델을 순차·병렬로 엮고, resource group이 앱마다 자원 몫을 갈라 경합을 막습니다.
- 쓰임 — 대규모 조직이나 여러 모델이 협업하는 복잡한 AI 서비스에서 고릅니다. KServe · Ray Serve · MLflow가 대표적입니다.
— 여기까지: 서빙 방안 네 가지를 다 봤습니다. 마지막으로 전체를 한 장에 —
11전체 정리 — 그래서 무엇을 고를까
한 줄 요약: 네 방식은 우열이 아니라 조건입니다. 조건이 바뀌면 답도 바뀝니다.
1장부터 10장까지 부품을 하나씩 봤습니다. 이제 그 부품들이 어떤 조건에서 어떻게 조합되는지를 한 화면에서 확인할 차례입니다.
이 장을 마치면, 새 프로젝트를 받았을 때 어떤 질문부터 던져야 하는지를 알게 됩니다.
- Radix Attention
- 여러 요청이 공통으로 쓰는 프롬프트 앞부분을 나눠 쓰게 하는 기법. SGLang이라는 엔진에서 씁니다. 발상은 6장의 PagedAttention과 같은 계열입니다 — 같은 걸 두 번 계산하지 말자.
- SGLang
- vLLM과 함께 자주 비교되는 또 다른 LLM serving engine.
- On-premises (온프레미스)
- 클라우드가 아니라 회사가 직접 소유한 서버실에서 돌리는 것.
네 가지 방식 한눈에
| 방식 | 핵심 특징 | 적합한 상황 |
|---|---|---|
| On-device | 단말 안에서 직접 실행 | 초저지연, 오프라인, 개인정보 보호가 최우선일 때 |
| Single-model | 컨테이너 하나에 모델 하나 | 높은 성능과 독립적 확장이 필요할 때 — 기본 선택지 |
| Multi-model | 컨테이너 하나에 여러 모델 | 모델 수가 많고 트래픽이 낮거나 불규칙할 때 |
| Serving platform | 여러 앱·모델·워크플로 통합 | 대규모 조직, 여러 모델이 협업하는 복잡한 AI 서비스 |
서빙 방식 고르기 — 조건을 바꾸면 답이 바뀐다
↔ 슬라이더 4개이 추천기는 이 글에서 설명한 규칙들을 제가 임의의 점수로 옮겨 놓은 것입니다. 업계 표준 공식이 아니고, 실제 벤치마크에서 뽑은 수치도 아닙니다. 조건이 바뀌면 답이 바뀐다는 감각을 얻는 용도로만 쓰세요. 실제 결정은 반드시 본인 워크로드로 측정해야 합니다.
CH1이 전달하려던 것
이 장에서는 모델을 엔지니어링 관점에서 다뤘습니다. 모델은 정적인 데이터 파일이 아니라 실행 가능한 구성요소이고, model data · model architecture · model execution code 세 가지로 이루어집니다.
모델 서빙은 실제 운영 환경에서 모델을 배포해 실시간 데이터를 처리하고 예측을 생성하는 과정입니다. 배포 위치로는 on-device · on-premises · cloud 세 가지가 있고, 어디에 두든 확장성 · 지연시간 · 모니터링 · 보안 · 비용을 챙겨야 합니다.
그리고 클라우드 벤더 솔루션이나 LLM API를 쓰더라도 서빙 이해는 여전히 필요합니다. 클라우드는 편하지만 복잡한 통합 · 비용 트레이드오프 · 보안 문제는 여전히 우리 몫이고, LLM은 강력하지만 실무에 넣으려면 다중 모델 파이프라인 · 파인튜닝 · 비용 효율적 배포 전략이 필요합니다.
KV Cache + PagedAttention(vLLM), Radix Attention(SGLang) 같은 기법을 쓰면 추가 인프라 비용 없이 처리량을 6배 높이고 지연시간을 1/3로 줄일 수 있습니다. LLM 추론은 연산 비용이 크기 때문에, 서빙 최적화는 선택이 아니라 비용 효율적인 AI 배포를 위한 필수 요소입니다.
- 정의 — 서빙 방식은 On-device · Single-model · Multi-model · Serving platform 네 가지이고, 각각 지연시간·비용·확장성·복잡도에서 다른 장단점을 가집니다.
- 성질 — 네 방식은 배타적이지 않습니다. 실무에서는 섞어서 씁니다. 뜨거운 모델은 single-model, 롱테일은 multi-model, 전체는 platform 위에.
- 쓰임 — 새 프로젝트에서 던질 첫 질문은 "모델이 몇 개이고, 각각 얼마나 뜨겁고, 얼마나 크고, 데이터가 나가도 되는가"입니다.
마치며
이번 챕터에서는, 모델 서빙의 정의와 성질, 그리고 실제 적용 방법에 대해 다뤘습니다. 단순히 모델을 배포하는 것뿐만 아니라, 다양한 서빙 방식과 그에 따른 장단점을 이해하고, 실제 상황에 맞는 최적의 선택을 할 수 있는 능력을 기르는 것이 중요합니다.
또한, 모델 서빙은 단순한 기술적 문제를 넘어, 비용 효율성과 사용자 경험을 동시에 고려해야 하는 복합적인 과제임을 알 수 있었습니다. 또한 모델의 구조를 이해하고, 배포전략을 잘 구성해야 인프라 비용을 절감하고, 서빙하는 모델의 성능을 극대화 할 수 있다는 점을 배웠습니다.
댓글을 달아주세요. 제가 확인 후 수정하겠습니다. CH1은 CloudNet@ 『CH1. Introduction to Model Serving and Optimization』 스터디 자료를 바탕으로 재구성했습니다.
'AI > [LLMSO] Hands-On LLM 서빙과 최적화 스터디' 카테고리의 다른 글
| [1주차-LLMSO]LLM 기초 동작 원리 (2026.08.02) (0) | 2026.08.08 |
|---|---|
| [1주차-LLMSO]CH2. Large Language Model Serving (2026.08.02) (0) | 2026.08.08 |
| [1주차-LLMSO]트랜스포머 모델을 이해하기 위한 기초 수학 정리 (0) | 2026.08.07 |