AI 모델을 서비스에 얹는 순간, 엔지니어는 불편한 진실 하나와 마주하게 된다. Throughput(처리량)을 높이려 할수록 Latency(지연)가 나빠지고, Latency를 줄이려 하면 GPU가 놀게 된다는 것이다. 이 둘은 단순히 설정값을 조정하면 해결되는 문제가 아니라, GPU가 동작하는 방식 자체에서 비롯된 구조적 긴장관계다.
GPU는 수천 개의 코어가 동시에 동일한 연산을 처리하는 병렬 프로세서다. 이 구조가 최대 효율을 낼 수 있는 조건은, 처리할 데이터가 충분히 많아서 코어들이 쉬지 않고 돌아갈 때다. 요청 하나를 단독으로 처리하면 대부분의 코어가 유휴 상태가 된다. 그래서 여러 요청을 묶어 배치(batch)로 처리하면 GPU 활용률이 올라가고 단위 시간당 처리 토큰 수, 즉 Throughput이 증가한다. 하지만 배치가 커질수록 각 요청이 줄을 기다려야 하고, 결과가 돌아오는 시간도 늘어난다. Latency가 악화되는 것은 이 대기 시간이 쌓이기 때문이다.
이 트레이드오프는 어느 정도까지는 설정으로 완화할 수 있지만, 그 이상으로 해결하려면 서버 아키텍처 자체를 다르게 설계해야 한다.
Prefill과 Decode: 같은 GPU인데 병목이 다른 두 단계
LLM 추론은 두 단계로 나뉜다는 사실이 이 복잡성의 출발점이다. 이전 글에서 TTFT(Time To First Token)와 tokens/sec를 측정 관점에서 다뤘다면, 여기서는 이 비대칭성이 서버 설계에 어떤 구조적 함의를 갖는지에 집중한다.
Prefill 단계는 입력 프롬프트 전체를 한 번에 처리해 KV(Key-Value) 캐시를 구성한다. 입력 토큰이 많을수록 더 많은 행렬 곱셈이 동시에 발생한다. 이것은 전형적인 compute-bound 연산이다. GPU의 FLOPS 수치가 직접적인 속도를 결정하며, 코어를 얼마나 조밀하게 쓰느냐가 관건이다.
Decode 단계는 다르다. 이미 구성된 KV 캐시를 참조하면서 토큰을 하나씩 순차적으로 생성한다. 매 스텝마다 수십억 개의 가중치 파라미터 전체를 메모리에서 읽어와야 한다. 70B(70억 파라미터) 모델을 FP16으로 올리면 가중치만 140GB다. 토큰 하나를 만들 때마다 이 덩어리를 훑는다. 연산량보다 메모리에서 데이터를 얼마나 빨리 퍼올리느냐, 즉 memory bandwidth가 병목이 되는 이유다.
같은 GPU 위에서 돌아가지만 두 단계는 서로 다른 자원을 포화시킨다. Prefill을 처리하는 동안 메모리 대역폭은 여유가 있고, Decode 중에는 연산 코어가 한가하다. 이 비대칭성이 하나의 서버 인스턴스에 두 역할을 동시에 맡기는 전통적 배포 방식의 비효율을 만들어낸다.
Static Batching의 한계와 Continuous Batching
초기 LLM 서빙 시스템은 Static Batching, 즉 고정 배치 방식으로 동작했다. N개의 요청을 모아 동시에 처리를 시작하고, 배치 안의 모든 요청이 완료될 때까지 새 요청을 받지 않는다. 문제는 LLM 출력 길이가 요청마다 다르다는 것이다. “안녕”이라는 두 글자 응답이 끝난 요청이 있어도, 같은 배치에 포함된 긴 에세이 작성 요청이 끝날 때까지 GPU 자원 일부가 그 짧은 요청 자리에 묶여 낭비된다. 배치가 클수록, 출력 길이 편차가 클수록 이 낭비가 심해진다.
vLLM이 2023년에 소개한 PagedAttention과 함께 도입된 Continuous Batching(또는 Iteration-level Batching)은 이 문제를 근본부터 다르게 접근한다. 매 디코딩 스텝(iteration)마다 완료된 요청을 배치에서 제거하고 대기 중인 새 요청을 즉시 집어넣는다. 배치가 요청 단위가 아니라 스텝 단위로 재구성되는 셈이다. 덕분에 GPU가 유휴 상태에 빠지는 구간이 크게 줄어들고, 동일한 하드웨어에서 처리 가능한 동시 요청 수가 수배 증가한다.
PagedAttention은 여기에 메모리 관리 혁신을 더했다. KV 캐시를 OS의 가상 메모리처럼 페이지 단위로 나눠 불연속적으로 저장함으로써, 기존 방식에서 발생하던 KV 캐시 메모리 단편화를 없앴다. 이 두 가지가 결합되면서 vLLM은 등장과 동시에 LLM 서빙 분야의 표준 레퍼런스가 되었다.
KV 캐시 재사용: Prefix Caching의 실용적 위력
KV 캐시를 한번 계산했다면, 다음에 똑같은 입력이 들어올 때 다시 계산할 필요가 없다. 이것이 Prefix Caching(Prompt Caching)의 핵심이다. Anthropic, OpenAI 같은 API 공급자들이 prompt caching이라는 이름으로 서비스에 적용하고 있으며, vLLM과 SGLang 같은 오픈소스 서버에서도 Automatic Prefix Caching 기능으로 구현되어 있다.
실용적인 효과는 두 방향으로 나타난다. 첫째, TTFT가 극적으로 줄어든다. 긴 시스템 프롬프트가 반복적으로 쓰이는 챗봇 시나리오나, 동일한 문서에 대해 여러 질문을 던지는 RAG 파이프라인에서 Prefill 비용이 거의 없어지기 때문이다. 둘째, 비용이 낮아진다. Anthropic의 경우 캐시 히트 시 입력 토큰 비용을 최대 90%까지 할인한다. 서버 운영자 입장에서는 GPU 시간을 절약하는 것과 같다.
캐시 히트율을 높이려면 요청 구조 설계가 중요하다. 변하지 않는 공통 부분(시스템 프롬프트, 문서 본문)을 앞에 배치하고 매번 달라지는 사용자 질문을 뒤에 붙이는 패턴이 일관되어야 한다. 순서만 바뀌어도 캐시 미스가 발생한다.
Disaggregated Serving: Prefill과 Decode를 물리적으로 분리한다
Continuous Batching이 단일 인스턴스 내의 효율을 높이는 방식이라면, Disaggregated Serving(분리 서빙)은 한 단계 더 나아가 Prefill 전담 노드와 Decode 전담 노드를 아예 다른 머신으로 분리한다. 요청이 들어오면 Prefill 노드에서 KV 캐시를 생성한 후, 그것을 Decode 노드로 전송해 토큰 생성을 이어간다.
이 아키텍처가 매력적인 이유는 두 단계를 각각의 하드웨어에 최적화할 수 있기 때문이다. Prefill 노드는 고FLOPS 연산에 강한 GPU를 쓰고, Decode 노드는 메모리 대역폭이 넓은 GPU를 고를 수 있다. 또 트래픽 패턴에 따라 두 노드의 수를 독립적으로 스케일할 수 있다. 짧은 프롬프트 요청이 급증하면 Prefill 노드를 늘리고, 긴 출력이 많아지면 Decode 노드를 늘리는 식이다.
현실적인 과제도 있다. Prefill이 완료된 KV 캐시를 네트워크로 Decode 노드에 전달해야 하는데, 70B 모델의 KV 캐시는 시퀀스 길이에 따라 수백 MB에서 수 GB에 달한다. 이것을 지연 없이 전송하려면 노드 간 고속 네트워크가 필수다. NVIDIA NVLink는 같은 서버 내 GPU 간에 최대 900GB/s의 대역폭을 제공하지만, 서버 간 통신은 InfiniBand나 RoCE(RDMA over Converged Ethernet)에 의존한다. 최신 InfiniBand HDR는 200Gb/s 수준인데, 이는 NVLink 대비 현저히 낮다. 분리 서빙이 이론적으로는 효율적이지만 실제 운용에서 네트워크 비용과 복잡성이 상당한 부담으로 작용하는 이유다.
Mooncake(Kimi AI), DistServe(UC Berkeley) 같은 연구 프로젝트들이 이 방향을 실험하고 있으며, 클라우드 환경에서 고대역폭 네트워크 패브릭이 성숙해지면서 점차 실용화 가능성이 높아지고 있다.
이미지 출처: Unsplash
Speculative Decoding: 배치가 작을 때의 지름길
Speculative Decoding(투기적 디코딩)은 작은 Draft 모델이 여러 토큰을 미리 예측하고, 큰 Target 모델이 그것을 한번에 검증하는 방식으로 동작한다. Draft 모델의 예측이 맞으면 한 번의 검증 스텝으로 여러 토큰을 확정할 수 있어, 사용자 입장에서 체감 생성 속도가 빨라진다.
여기에는 중요한 전제 조건이 있다. 배치 크기가 충분히 작아야 효과가 있다. 이유는 직관적이다. GPU는 배치 크기가 작을 때 사실 연산 코어가 많이 놀고 있다. Speculative Decoding은 이 여유 자원을 활용해 Draft 모델과 Target 모델을 동시에 돌릴 수 있기 때문에 지연을 줄일 수 있다. 반면 배치가 이미 크면 GPU가 포화 상태이므로 Draft 모델을 추가로 돌릴 자원이 없고, 오히려 오버헤드가 생긴다. Throughput 최대화가 목표인 배치 처리 환경에서 Speculative Decoding이 역효과를 내는 이유가 바로 이것이다.
적합한 환경은 실시간 대화형 서비스다. 동시 접속자가 많지 않고 요청 하나하나의 응답 속도가 사용자 경험에 직결되는 상황에서 Speculative Decoding은 체감 속도를 20~50%까지 향상시킬 수 있다. Draft 모델의 선택도 중요한데, 너무 작으면 예측 정확도가 낮아 수락률이 떨어지고, 너무 크면 실행 비용이 커진다. 일반적으로 Target 모델의 1/7~1/10 크기 정도가 균형점으로 알려져 있다.
Tensor Parallelism과 Pipeline Parallelism: 멀티 GPU 분산의 갈림길
모델이 GPU 한 장에 올라가지 않을 만큼 크면 분산 추론이 필요하다. 이때 두 가지 큰 방향이 있다.
Tensor Parallelism(TP)은 각 레이어의 행렬 연산 자체를 여러 GPU에 수평으로 쪼개는 방식이다. 70B 모델을 4장의 GPU에 TP=4로 배포하면 각 GPU가 행렬의 1/4씩 담당하고, 연산 결과를 AllReduce 통신으로 합친다. 매 레이어마다 통신이 발생하기 때문에 GPU 간 대역폭이 결정적이다. NVLink로 연결된 동일 노드 내 GPU에서는 효율적이지만, 노드를 넘어가면 InfiniBand 대역폭 제약이 즉시 병목이 된다. Tensor Parallelism은 단일 노드 안에서 쓰는 것이 사실상 정석이다.
Pipeline Parallelism(PP)은 모델 레이어를 수직으로 잘라 각 GPU(또는 노드)가 일정 개수의 레이어를 담당하는 방식이다. 레이어 그룹 간 통신은 활성화값(activation) 전달뿐이므로 데이터 크기가 TP의 AllReduce보다 작다. 이 덕분에 노드 간 통신, 즉 InfiniBand가 연결된 멀티노드 환경에 더 적합하다. 대신 파이프라인 버블(pipeline bubble) 문제가 있다. 각 스테이지가 앞 스테이지의 출력을 기다리는 동안 유휴 상태가 생기는 것인데, 마이크로배치 기법으로 완화할 수 있지만 완전히 없애기는 어렵다.
실무 기준으로 요약하면 이렇다. 단일 노드 내 멀티 GPU: TP 우선. 멀티 노드로 넘어갈 때: PP를 노드 간에 적용하고 노드 내부에서 TP를 병용하는 TP+PP 혼합 전략이 표준이다. Megatron-LM이나 DeepSpeed가 이 조합을 지원하는 이유도 여기에 있다.
서비스 시나리오별로 전략이 달라진다
| 시나리오 | 우선 지표 | 핵심 전략 |
|---|---|---|
| 실시간 챗봇 | 낮은 TTFT, 낮은 Latency | 소규모 배치, Speculative Decoding, Prefix Caching |
| 코드 생성 / 긴 출력 | Throughput | Continuous Batching, 큰 배치, TP |
| 배치 오프라인 처리 | GPU 활용률 최대화 | 최대 배치 크기, Disaggregated Serving 검토 |
| RAG 파이프라인 | TTFT + Throughput 균형 | Prefix Caching 적극 활용, 중간 배치 크기 |
챗봇처럼 한 사용자와 주고받는 대화가 중심이라면 각 요청은 짧고 빠른 응답이 핵심이다. 배치를 키우는 것보다 Speculative Decoding으로 단일 요청의 토큰 생성 속도를 높이고, 반복되는 시스템 프롬프트를 Prefix Caching으로 KV 캐시에 상주시키는 것이 효과적이다. 반면 코드 생성 서비스는 출력이 길고 사용자가 첫 토큰보다 전체 완성 시간을 더 중요시하는 경향이 있다. 이런 환경에서는 Continuous Batching으로 GPU를 최대한 포화시키는 것이 단위 비용당 처리량을 극대화하는 길이다.
배치 처리, 예를 들어 수백만 건의 문서를 야간에 임베딩하거나 요약하는 작업이라면 Latency는 무관하다. GPU 활용률을 100%에 가깝게 유지하는 것만이 목표다. 이 경우 가능한 최대 배치 크기로 돌리고, 메모리가 허용하는 범위에서 Tensor Parallelism을 최소화해 통신 오버헤드를 줄이는 것이 유리하다.
멀티 GPU, 멀티 노드로 넘어갈 때 가장 자주 간과되는 것이 네트워크 계층이다. H100 8장이 NVLink로 연결된 노드 안에서는 최대 900GB/s의 양방향 대역폭을 활용할 수 있다. 같은 클러스터 안의 다른 노드와 통신할 때 InfiniBand HDR를 쓰면 200Gb/s(약 25GB/s)로 뚝 떨어진다. 이 차이가 무려 36배다. TP를 노드 경계에 걸치는 순간 매 레이어마다 이 좁은 파이프를 통과해야 하고, 모델이 클수록 그 비용이 추론 지연의 주요 원인이 된다. “GPU 스펙만 보고 멀티노드 확장을 낙관하는” 실수가 실제 시스템에서 반복되는 이유다.
LLM 서빙 인프라는 지금 빠르게 성숙하고 있다. vLLM, SGLang, TensorRT-LLM이 Continuous Batching과 Prefix Caching을 기본으로 탑재한 지 이미 2년이 넘었고, Disaggregated Serving은 연구 단계에서 클라우드 대규모 서비스로 이행 중이다. 하드웨어 측면에서는 NVIDIA의 NVLink Switch 시스템이 노드 간 대역폭 격차를 좁히는 방향으로 발전하고 있으며, Groq나 Cerebras처럼 메모리 대역폭을 극단적으로 높인 전용 추론 칩도 Decode 병목에 직접 도전하고 있다. 결국 어떤 기법을 선택하느냐보다, 지금 내가 서빙하는 서비스가 어떤 병목을 갖고 있는지를 정확히 진단하는 것이 출발점이다. 같은 모델, 같은 GPU라도 설계 선택에 따라 비용과 사용자 경험이 몇 배씩 달라지는 것이 LLM 서빙 아키텍처의 현실이다.
출처
- Continuous Batching: A Critical Performance Optimization for LLMs (Anyscale Blog)
- vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention (SOSP 2023)
- DistServe: Disaggregating Prefill and Decoding for Goodput-Optimized LLM Serving (OSDI 2024)
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (Kimi AI)
- Speculative Decoding: Lossless Speedup of Autoregressive Translation (Google Research)
- Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism (NVIDIA)
- SGLang: Efficient Execution of Structured Language Model Programs (UC Berkeley)
- LLM Inference Performance Engineering: Best Practices (Anyscale)