LLM Inference (11) - LLM Serving

이도연·2026년 7월 28일

AI LLM LLM Serving inference llm inference

AI 이론 공부해보기

목록 보기

67/76

좋은 아침입니다.

Speculative Decoding은 Target Model의 반복 실행 횟수를 줄여 하나의 요청에서 토큰이 생성되는 속도를 높이는 방법이었습니다.

하지만 실제 서비스에서는 하나의 요청만 빠르게 처리하는 것으로는 충분하지 않습니다.
여러 사용자의 요청을 동시에 받아야 하며, 제한된 GPU 메모리와 연산 자원을 효율적으로 사용해야 합니다.
이번 글에서는 LLM을 서버에 배포하고 여러 사용자의 요청을 처리하는 LLM Serving에 대해 알아보겠습니다.

LLM Serving

LLM Serving은 학습이 완료된 LLM을 서버에 배포하고, 사용자의 요청을 받아 추론 결과를 제공하는 과정입니다.

1. 사용자가 Prompt 전송

2. 서버가 요청을 대기열에 추가

3. LLM이 Prompt 처리

4. 새로운 토큰 생성

5. 생성된 결과를 사용자에게 전달

Chatbot이나 AI 서비스에서는 여러 사용자가 동시에 Prompt를 전송할 수 있습니다.
Serving System은 이러한 요청을 관리하고 GPU에서 효율적으로 처리해야 합니다.

사용자 A 요청
사용자 B 요청
사용자 C 요청

       ↓

LLM Serving System

       ↓

GPU에서 모델 추론

       ↓

각 사용자에게 결과 전달

따라서 LLM Serving은 단순히 모델을 실행하는 것뿐만 아니라 요청 관리, 메모리 관리, Batch 구성과 결과 전달까지 포함합니다.

LLM Serving의 어려움

LLM은 일반적인 딥러닝 모델보다 Serving하기 어렵습니다.
먼저 모델의 파라미터 수가 많기 때문에 GPU 메모리에 모델을 올리는 것부터 많은 메모리가 필요합니다.
또한 사용자의 입력과 출력 길이가 서로 다릅니다.

요청 A: 짧은 Prompt + 짧은 응답

요청 B: 긴 Prompt + 긴 응답

요청 C: 짧은 Prompt + 긴 응답

LLM은 출력 토큰을 한 번에 생성하지 않고 하나씩 순차적으로 생성합니다.
따라서 하나의 요청을 처리하는 동안 모델이 여러 번 실행되며, 요청마다 종료되는 시점도 달라집니다.
KV Cache도 토큰이 생성될 때마다 증가하기 때문에 여러 요청을 동시에 처리할수록 많은 GPU 메모리가 필요합니다.
LLM Serving System은 이러한 특징을 고려하여 요청과 GPU 자원을 관리해야 합니다.

Prefill과 Decode

LLM의 추론 과정은 크게 Prefill과 Decode로 나눌 수 있습니다.

Prefill

Prefill은 사용자가 입력한 Prompt 전체를 처리하는 단계입니다.

사용자 Prompt : "오늘 서울의 날씨를 알려줘"

        ↓

모든 입력 토큰을 한 번에 처리

        ↓

KV Cache 생성

Prefill 단계에서는 입력된 여러 토큰을 병렬로 계산하기 때문에 GPU의 연산량이 많습니다.
또한 입력 토큰에 대한 Key와 Value를 계산하여 KV Cache에 저장합니다.

Decode

Decode는 새로운 출력 토큰을 하나씩 생성하는 단계입니다.

첫 번째 출력 토큰 생성

        ↓

KV Cache에 추가

        ↓

두 번째 출력 토큰 생성

        ↓

문장이 끝날 때까지 반복

Decode 단계에서는 이전에 생성된 KV Cache를 사용하여 다음 토큰을 생성합니다.

Prefill은 Prompt 전체를 처리하고, Decode는 출력 토큰을 하나씩 생성한다는 차이가 있습니다. LLM Serving에서는 두 단계의 연산 특성이 다르기 때문에 각각의 성능을 따로 살펴보기도 합니다.

LLM Serving의 주요 성능 지표

LLM Serving의 성능은 단순히 전체 응답 시간만으로 평가하기 어렵습니다.
사용자가 첫 번째 토큰을 얼마나 빨리 받는지와 이후 토큰이 얼마나 빠르게 생성되는지도 중요합니다.

Latency

Latency는 하나의 요청이 서버에 전달된 시점부터 전체 응답이 완료될 때까지 걸리는 시간입니다.

요청 전송

   ↓

모델 추론

   ↓

전체 응답 완료

Latency가 짧을수록 사용자는 전체 응답을 빠르게 받을 수 있습니다.

Throughput

Throughput은 일정 시간 동안 처리할 수 있는 요청이나 토큰의 양을 의미합니다.

초당 처리한 요청 수

또는

초당 생성한 토큰 수

Batch에 더 많은 요청을 포함하면 GPU를 효율적으로 사용하여 Throughput을 높일 수 있습니다.
하지만 너무 많은 요청을 동시에 처리하면 각 요청이 기다리는 시간이 길어질 수 있습니다.
따라서 LLM Serving에서는 Latency와 Throughput 사이의 균형이 중요합니다.

TTFT

TTFT는 Time To First Token의 약자입니다.
사용자가 요청을 보낸 시점부터 첫 번째 출력 토큰을 받을 때까지 걸리는 시간입니다.

요청 전송

   ↓

대기 시간

   ↓

Prefill

   ↓

첫 번째 토큰 생성

TTFT가 짧으면 사용자는 모델이 빠르게 응답하기 시작한다고 느낄 수 있습니다.

TPOT

TPOT는 Time Per Output Token의 약자입니다.
첫 번째 토큰이 생성된 이후, 다음 출력 토큰이 생성될 때마다 걸리는 시간을 의미합니다.

첫 번째 토큰

   ↓ TPOT

두 번째 토큰

   ↓ TPOT

세 번째 토큰

TTFT는 주로 Prefill 단계와 관련이 있으며, TPOT는 Decode 단계의 생성 속도와 관련이 있습니다.

LLM Serving의 동작 방식

사용자의 요청이 들어오면 먼저 Request Queue에 저장됩니다.
Scheduler는 대기 중인 요청과 GPU 메모리 상태를 확인하여 처리할 요청을 선택합니다.

1. 사용자의 요청 수신

2. Request Queue에 저장

3. Scheduler가 처리할 요청 선택

4. Batch 구성

5. GPU에서 모델 추론

6. 생성된 토큰 전달

요청이 처리되는 동안 새로운 토큰이 생성되면 사용자에게 바로 전달할 수 있습니다.
이를 Streaming이라고 합니다.

전체 문장이 완성된 후 전달 X


토큰이 생성될 때마다 전달

오늘 → 날씨는 → 맑습니다

Streaming을 사용하면 전체 응답이 완성되기 전부터 사용자가 결과를 확인할 수 있습니다.

Serving System은 요청이 완료되면 사용하던 KV Cache를 해제하고, 해당 GPU 메모리를 다른 요청에서 사용할 수 있도록 합니다.

LLM Serving Engine

LLM Serving Engine은 LLM 추론에 필요한 여러 작업을 관리하는 소프트웨어입니다.

사용자 요청

    ↓

Serving Engine

    ├── 요청 대기열 관리
    ├── Batch 구성
    ├── KV Cache 관리
    ├── 모델 실행
    └── 결과 전달

    ↓

GPU

대표적인 LLM Serving Engine으로는 sglang, vLLM, TensorRT-LLM과 Text Generation Inference가 있습니다.

sglang : RadixAttention을 통한 지능형 캐시 재사용과 복잡한 LLM 파이프라인 처리를 가속하는 고성능 추론 엔진입니다.
vLLM : PagedAttention을 이용한 KV Cache 관리와 Continuous Batching을 지원합니다.
TensorRT-LLM : NVIDIA GPU에서 LLM 추론을 최적화하기 위한 Runtime과 In-flight Batching 등의 기능을 제공합니다.
Text Generation Inference: Continuous Batching, FlashAttention과 PagedAttention 등의 최적화 기능을 제공하는 LLM Serving 도구입니다.

각 Serving Engine은 지원하는 모델과 하드웨어, 사용 방법과 최적화 방식에서 차이가 있습니다.

LLM Serving의 장단점

장점

LLM Serving을 사용하면 하나의 모델을 서버에 배포하고 여러 사용자가 API를 통해 사용할 수 있습니다.

Serving Engine은 요청을 Batch로 구성하고 GPU 자원을 효율적으로 사용합니다.

또한 KV Cache와 메모리를 관리하여 여러 요청을 동시에 처리할 수 있습니다.

Streaming을 사용하면 전체 응답이 완성되기 전에 생성된 토큰을 사용자에게 전달할 수 있습니다.

단점

큰 LLM을 Serving하려면 많은 GPU 메모리와 연산 자원이 필요합니다.

동시에 처리하는 요청이 증가하면 Throughput은 높아질 수 있지만 각 요청의 대기 시간도 증가할 수 있습니다.

또한 요청의 길이와 트래픽이 계속 변하기 때문에 적절한 Batch 크기와 Scheduling 방식을 설정하기 어렵습니다.

여러 GPU를 사용하는 경우에는 모델을 분산하고 GPU 사이의 통신도 관리해야 합니다.

따라서 LLM Serving에서는 모델의 성능뿐만 아니라 Latency, Throughput과 운영 비용을 함께 고려해야 합니다.

요약

이번 글에서는 LLM Serving에 대해 알아보았습니다.

핵심 내용을 정리하면 다음과 같습니다.

LLM Serving은 학습된 LLM을 서버에 배포하고 사용자의 요청을 처리하는 과정입니다.
Serving System은 요청 관리, Batch 구성, 메모리 관리, 모델 실행과 결과 전달을 담당합니다.
LLM의 추론 과정은 Prompt를 처리하는 Prefill과 출력 토큰을 생성하는 Decode로 나눌 수 있습니다.
Latency는 하나의 요청이 완료될 때까지 걸리는 시간입니다.
Throughput은 일정 시간 동안 처리할 수 있는 요청이나 토큰의 양입니다.
TTFT는 요청을 보낸 뒤 첫 번째 토큰을 받을 때까지 걸리는 시간입니다.
TPOT는 첫 번째 토큰 이후 각 출력 토큰이 생성되는 데 걸리는 시간입니다.
Streaming은 토큰이 생성될 때마다 결과를 사용자에게 전달하는 방식입니다.
LLM Serving Engine은 요청 대기열, Batch, KV Cache와 GPU 실행을 관리합니다.
대표적인 LLM Serving Engine으로는 vLLM, TensorRT-LLM과 Text Generation Inference가 있습니다.
Quantization, KV Cache, FlashAttention, PagedAttention, Continuous Batching과 Speculative Decoding은 LLM Serving 과정에서 함께 사용될 수 있습니다.
LLM Serving에서는 Latency, Throughput, GPU 메모리와 운영 비용 사이의 균형이 중요합니다.

지금까지 배운 추론 기술

지금까지 알아본 LLM Inference 기술들은 LLM Serving 과정에서 함께 사용됩니다.

Quantization : 모델의 가중치와 계산값을 낮은 비트로 표현하여 모델이 사용하는 메모리를 줄입니다.

KV Cache : 이전에 계산한 Key와 Value를 저장하여 토큰 생성 과정의 중복 계산을 줄입니다.

FlashAttention : Attention 연산 중 HBM과 SRAM 사이의 데이터 이동을 줄입니다.

PagedAttention : KV Cache를 작은 Block으로 나누어 GPU 메모리를 효율적으로 관리합니다.

Continuous Batching : 완료된 요청의 자리에 새로운 요청을 추가하여 GPU의 빈자리를 줄입니다.

Speculative Decoding : 작은 모델이 생성한 후보 토큰을 큰 모델이 검증하여 토큰 생성 속도를 높입니다.

LLM Serving Engine : 이러한 기술들을 조합하여 제한된 GPU에서 더 많은 요청을 빠르게 처리합니다.

이번 글을 마지막으로 LLM Inference 시리즈를 마무리하겠습니다.

다음 글에서는 LLM이 외부 데이터를 검색하여 답변 생성에 활용하는 RAG에 대해 알아보겠습니다.
RAG는 사용자의 질문과 관련된 정보를 외부 데이터에서 검색하고, 검색된 정보를 LLM에 함께 전달하여 답변을 생성하는 방법입니다.

부족한 글 읽어주셔서 감사합니다.

틀린 내용이나 피드백은 댓글로 남겨주시면 감사하겠습니다.

감사합니다.

이도연

저희.서이.하실래요?

이전 포스트

LLM Inference (10) - Speculative Decoding

다음 포스트