모델 서빙은 학습된 모델을 GPU 서버에 올리고 API로 열어 많은 요청에 실시간으로 답하게 하는 일로, 핵심은 응답 속도, 처리량, 비용의 균형을 맞추는 것이다. 상용 API 대신 오픈 모델을 쓰거나 데이터를 밖으로 보낼 수 없을 때 직접 운영한다.
| 방식 | 이럴 때 고른다 | 부담 |
|---|---|---|
| 상용 API 호출 | 빨리 시작하고 싶을 때, 트래픽이 적을 때 | 운영 부담 없음 |
| 직접 서빙 | 오픈 모델 사용, 데이터 외부 반출 불가, 대량 트래픽 | GPU 비용과 운영 인력 필요 |
| 내 PC에서 실행 | 개인 실험, 오프라인 사용 | 작은 모델만 가능 |
LLM은 요청마다 만들어 내는 토큰 수가 다르고, 답을 한 글자씩 흘려보내는 스트리밍이 필요하다. 그래서 요청을 묶어 한 번에 처리하기 어렵다. 이를 풀려고 끝난 요청 자리에 새 요청을 바로 끼워 넣는 연속 배칭, 앞서 계산한 결과(KV 캐시)를 GPU 메모리에 효율적으로 쌓는 기술이 쓰인다.
| 지표 | 뜻 | 중요한 상황 |
|---|---|---|
| 첫 토큰까지 시간 | 답이 나오기 시작하는 속도 | 채팅처럼 사람이 기다릴 때 |
| 토큰 생성 속도 | 답이 흘러나오는 속도 | 긴 답변, 코드 생성 |
| 처리량 | GPU 한 대가 동시에 감당하는 양 | 대량 일괄 처리, 비용 절감 |
LLM 전용 프레임워크를 쓰면 위 최적화가 기본으로 들어 있다. 일반 머신러닝 모델까지 함께 운영한다면 범용 서빙 도구가 맞다.
| 도구 | 특징 | 맞는 경우 |
|---|---|---|
| vLLM | Paged Attention으로 메모리 효율이 좋음 | 오픈 모델 LLM 서빙의 기본 선택 |
| TGI | Hugging Face 생태계와 잘 맞음 | Hugging Face 모델 위주 운영 |
| TensorRT-LLM | NVIDIA GPU에 맞춘 최적화 | 속도를 끝까지 끌어올릴 때 |
| Ray Serve, TorchServe | 범용 모델 서빙, 여러 모델 조합 | LLM 외 모델도 함께 운영 |
vLLM을 설치하거나 Docker로 실행한 뒤 vllm serve meta-llama/Llama-3.1-8B-Instruct처럼 모델을 지정하면 OpenAI 호환 API 서버가 열린다. 기존 OpenAI SDK 코드에서 접속 주소(base URL)만 내 서버로 바꾸면 그대로 동작한다.
운영 단계에서는 Kubernetes 같은 환경에 올려 트래픽에 따라 GPU 수를 늘리고 줄인다. 채팅 서비스는 첫 토큰 속도를, 야간 일괄 요약은 처리량을 우선으로 설정을 맞추면 같은 GPU로 비용을 아낄 수 있다.
모델 크기만큼의 메모리에 더해, 동시 요청과 긴 입력이 늘수록 KV 캐시가 메모리를 크게 차지한다. 메모리가 모자라면 양자화로 모델을 줄이거나 최대 입력 길이를 제한한다. 트래픽이 적고 들쭉날쭉하면 GPU가 놀아도 비용이 나가므로, 직접 서빙보다 API가 더 싼 경우가 많다.
가장 흔한 건 데이터를 밖으로 보낼 수 없는 사내 서비스에 오픈 모델을 직접 띄우는 방식이다. OpenAI 호환 API로 열어 두면 기존 앱 코드를 거의 바꾸지 않고 여러 팀이 같은 서버를 함께 쓸 수 있다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 사내 문서 검색·챗봇 | 사내 서버에 오픈 모델을 띄워 내부 문서로 답하게 하고, 첫 토큰 속도를 우선으로 설정 |
| 사내 코딩 어시스턴트 | 소스 코드를 외부로 보내지 않고 내 서버의 모델에 코드 작성·리뷰를 맡김 |
| 대량 일괄 처리 | 야간에 문서 요약·분류를 몰아서 돌리고, 처리량을 우선으로 맞춰 GPU 비용을 아낌 |
| 개인 PC 실험 | 작은 모델을 내 PC에 띄워 오프라인으로 프롬프트나 기능을 미리 시험 |