An Analysis of Technology to Improve LLM Inference Throughput-Latency Tradeoff Using Sarathi-Serve

 

https://arxiv.org/pdf/2403.02310

 

Summary

대규모 언어 모델(LLM)의 추론 서비스에서는 높은 처리량(throughput)과 낮은 지연 시간(latency)을 동시에 달성하는 데 어려움이 따르는 상충 관계가 존재합니다. 각 요청은 프리필(prefill) 단계와 디코드(decode) 단계를 거치게 됩니다. 프리필 단계에서는 입력 프롬프트 전체를 일괄적으로 처리하여 첫 번째 출력 토큰을 생성하므로 GPU 활용도는 높으나 지연 시간이 길어지는 반면, 디코드 단계에서는 매 반복마다 하나의 토큰만을 생성하기 때문에 개별 반복 지연 시간은 짧지만 GPU 자원 활용도가 낮다. 이로 인해 디코드 단계에서는 배치(batch) 크기를 확대하여 병렬 처리를 수행하면 처리량이 크게 향상되는 반면, 프리필 단계에서는 배치 효과가 미미하게 나타납니다. 문제는 다수의 요청을 동시에 처리하기 위해 배치를 적용할 경우, 프리필 작업과 디코드 작업이 상호 교차적으로 발생하면서 자원 스케줄링에 따라 높은 처리량을 확보하면 지연 시간이 악화되고, 지연 시간을 단축하면 처리량이 저하되는 딜레마가 발생한다는 점입니다. 

 

기존의 LLM Serving 시스템들은 이러한 상충 관계를 해결하기 위해 요청 단위(batch-by-request) 스케줄링 또는 반복 단위(iteration-level) 스케줄링 정책을 채택해 왔으나, 각 정책에는 한계점이 존재합니다. 예를 들어, NVIDIA의 FasterTransformer와 같은 요청 단위 배치 방식은 모든 요청의 프리필이 완료될 때까지 새로운 요청을 대기시켜 첫 토큰까지 시간(TTFT, time-to-first-token)을 최소화하지만, 디코드 단계에서 작은 배치로 처리해야 하므로 GPU 자원이 유휴 상태가 되어 처리량이 낮아집니다. 반대로, vLLM이나 Orca와 같은 반복 단위 배치 시스템은 각 토큰 생성 반복(iteration)마다 동적으로 배치를 구성하여 GPU를 지속적으로 활용하므로 처리량은 높으나, 이 때 프리필을 우선시하는 정책(prefill-prioritizing)을 사용하는 경우 진행 중인 디코드를 중단하고 새로운 프리필을 삽입하여 “생성 정지(generation stall)” 현상이 발생, 토큰 간 대기 시간(TBT, time-between-tokens)의 최악 지연이 매우 길어질 수 있습니다. 실제로 vLLM의 기본 스케줄러는 프리필 작업을 최우선으로 실행하여 디코드 토큰 생성을 지연시키기 때문에 수 초 이상의 긴 생성 정지가 발생할 수 있음이 보고된 바 있습니다. 

 

Sarathi-Serve는 대규모 언어 모델(LLM) 추론 과정에서 발생하는 문제점을 해결하기 위해 제안된 효율적인 LLM 추론 스케줄러로서, "청크드 프리필(chunked-prefill)" 및 "스톨-프리(stall-free) 스케줄링" 기술을 도입하여 처리량과 지연 시간을 동시에 최적화합니다. Sarathi-Serve는 긴 프롬프트 입력을 여러 청크(chunk)로 분할하여 프리필 작업을 반복적으로 수행하고, 프리필 작업과 디코드 작업을 하나의 배치로 통합(coalesce)하여 실행하되 디코드 진행에 지연이 발생하지 않도록 스케줄링합니다. 이러한 방식을 통해 디코드 반복 시마다 GPU 자원을 최대한 활용하면서도 각 반복 실행 시간을 제어하여 토큰 간 지연 시간(TBT)을 서비스 수준 목표(SLO, Service Level Objective) 범위 내로 유지합니다. 더불어 Sarathi-Serve는 각 반복 배치의 토큰 수를 균일하게 조정(유니폼 배칭)하여 파이프라인 병렬화 환경에서의 파이프라인 버블을 최소화하고 효율성을 극대화합니다.

 

평가 결과, Sarathi-Serve는 다양한 모델 및 하드웨어 환경에서 엄격한 지연 시간 요구 조건하에서도 탁월한 추론 처리 성능을 보였으며, 기존 최신 시스템 대비 크게 향상된 서비스 수용량(serving capacity)을 달성했습니다. 예를 들어, Mistral-7B 모델을 단일 A100 GPU에서 구동 시 vLLM 대비 2.6배 높은 처리량을 동일 지연 시간 조건에서 제공하고, Yi-34B 모델을 2×A100 구성에서 최대 3.7배 높은 처리량을 달성했습니다. 파이프라인 병렬화 방식으로 Falcon-180B (8×A100) 모델을 서비스하는 경우에도 Sarathi-Serve는 최대 5.6배의 종단간 처리량 향상을 나타냈습니다. 이러한 결과는 Sarathi-Serve가 지연 시간 SLO를 충족하면서도 GPU 자원을 최대한 활용하여 고효율 LLM 서비스 인프라를 구축할 수 있음을 입증합니다.

 

Key Contributions and Features

Sarathi-Serve 논문은 LLM 추론 시 발생하는 처리량과 지연 시간 간의 상충 관계를 체계적으로 개선하기 위한 새로운 스케줄링 알고리즘 및 시스템 아키텍처를 제시하는 데 핵심적인 기여를 합니다. 주요 기법 및 특징은 다음과 같습니다.

 

• 청크 분할 프리필(Chunked Prefills) - 프롬프트 입력 전체를 일괄 처리하는 대신 입력 토큰을 여러 개의 청크로 분할하여 순차적인 반복 과정을 통해 프리필을 수행합니다. 이는 개별 프리필 연산의 길이를 제한함으로써 현재 진행 중인 디코드 작업의 지연을 방지합니다. 실험 결과, 프리필 작업은 약 512 토큰 길이만으로도 GPU를 포화시킬 수 있으며, 수천 토큰의 긴 입력도 수백 토큰 단위의 청크로 나누어 처리할 경우 GPU 산술 장치가 지속적으로 작동하면서도 각 청크 처리 시간이 단축되어 지연 시간 영향이 감소하는 것으로 확인되었습니다. Sarathi-Serve는 이러한 청크 분할 프리필 개념을 도입하여 프리필 작업과 디코드 작업을 동시에 배치할 수 있는 기반을 마련합니다(스톨-프리 스케줄링 참조).

 

• 스톨-프리 배치(Stall-Free Batching) - Sarathi-Serve의 가장 큰 혁신은 진행 중인 디코드 작업을 중단하지 않고 새로운 프리필 작업을 배치에 추가할 수 있는 스케줄링 알고리즘입니다. 기존 시스템(vLLM 등)에서는 새로운 요청의 프리필을 처리하기 위해 현재 배치를 종료하거나 디코드를 중단하여 토큰 생성이 일시적으로 멈추는 현상(Generation Stall)이 발생했으나, Sarathi-Serve는 디코드 연산의 유휴 연산 자원(slack)을 활용하여 디코드와 프리필을 하나의 배치 내에 공존시키면서 디코드 토큰 생성 주기를 유지합니다. 이를 위해 한 번의 배치(iteration)에서 처리할 총 토큰 개수(토큰 예산)를 미리 계산하고, 이 예산 내에서 모든 진행 중인 디코드 요청의 다음 토큰을 우선 배치에 포함시킨 후, 남는 여력을 활용하여 프리필 청크를 추가합니다. 이때 남은 토큰 예산 내에서 허용되는 최대 청크 크기를 산정하여 프리필 작업에 할당함으로써, 디코드 토큰 출력 간 시간(TBT)이 사용자가 요구한 상한을 초과하지 않도록 보장합니다. 이러한 혼합 배치(hybrid batch)를 GPU에 제출하면 GPU 메모리 대역폭에 제약되는 디코드 연산과 연산 장치를 활용하는 프리필 연산이 효율적으로 결합되어 디코드 작업은 중단 없이 진행되고 프리필 작업은 백그라운드로 처리되는 효과를 얻습니다. Sarathi-Serve의 스톨-프리 알고리즘(논문 Algorithm 3)은 매 반복마다 이러한 방식으로 배치를 편성하여 프리필로 인한 디코드 지연을 제거하고 배치 크기 증대를 통한 처리량 향상 효과를 극대화합니다. 결과적으로 Sarathi-Serve에서는 vLLM 등에서 관찰되던 수 초 길이의 생성 정지가 사라지고 높은 부하에서도 일정한 토큰 출력 주기를 유지할 수 있습니다.

 

• 동적 토큰 예산 및 SLO 기반 제어: Sarathi-Serve 스케줄러는 사용자가 명시한 지연 시간 SLO(예: P99 토큰 간 지연 시간 상한)에 부합하도록 단일 반복(iteration)에서 처리 가능한 최대 작업량을 토큰 수로 표현되는 예산(token budget)으로 산정합니다. 토큰 예산 결정 시에는 다음과 같은 두 가지 상반된 요소가 고려됩니다. (1) 배치 내 프리필 토큰 수가 적을수록 디코드 지연이 감소하여 지연 시간 측면에서 유리하며, (2) 프리필 청크를 과도하게 세분화할 경우 동일한 프롬프트에 대해 중복된 메모리 접근 및 커널 실행 오버헤드가 누적되어 효율성이 저하될 수 있다는 점입니다. 예를 들어, 프롬프트를 소규모 청크로 분할하면 각 청크마다 이전에 처리된 KV캐시를 재로드해야 하는 등의 비용이 발생하며, 지나치게 작은 청크는 이와 같은 HBM 메모리 재활용 오버헤드로 인해 전체 프리필 시간을 증가시킬 수 있습니다. 이에 Sarathi-Serve는 청크 크기에 따른 프리필 오버헤드와 디코드 지연 간의 균형점을 정량화하기 위해 모델별 프로파일링을 수행한 후, 주어진 지연 SLO를 충족하는 최대 토큰 수를 예산으로 설정하는 방안을 제시합니다. 이는 배치별 처리 토큰 수를 적절히 제한하여 지연 시간 목표를 준수하면서도, 가능한 한 많은 토큰을 한 번에 처리하여 GPU 활용률을 극대화하는 것을 목표로 합니다. 실험 결과에 따르면, Sarathi-Serve는 청크 단위 프리필을 수행하더라도 프리필 작업이 여전히 계산 중심(Compute-bound) 특성을 유지하며, 작은 청크로 인한 추가 오버헤드가 과도하지 않음을 입증했습니다. 따라서 SLO 범위 내에서 최대한 큰 청크를 사용하여 처리량을 증대시키고, 필요한 경우 약간 작은 청크로 조정하여 지연 시간을 맞추는 방식으로 운용됩니다.

 

• 균일 배치(Uniform Batching) 및 파이프라인 효율 개선: Sarathi-Serve는 각 반복에서 배치에 포함되는 전체 토큰 수를 최대한 일정하게 유지함으로써 파이프라인 병렬화 환경에서 단계 간 작업량 불균형으로 인해 발생하는 파이프라인 버블(pipeline bubble) 현상을 최소화합니다. 일반적으로 거대 모델을 여러 GPU에 계층별로 분할하여 병렬 처리할 때, 반복마다 배치에 포함된 시퀀스/토큰 수가 가변적일 경우 일부 단계는 작업이 조기에 완료되어 대기하고 다른 단계는 여전히 처리 중인 버블 현상이 발생합니다. 특히 전통적인 마이크로-배치(micro-batch) 기반 파이프라인에서는 각 마이크로배치 크기가 고정되어 있으나, LLM 생성은 토큰별 반복 길이가 상이하므로 이러한 문제를 피하기 어렵습니다. Sarathi-Serve 스케줄러는 매 반복마다 유사한 규모의 토큰 작업을 구성하고, 프리필 청크와 디코드 토큰을 함께 배치함으로써 각 GPU 단계가 균등하게 작업을 분배받아 처리하도록 합니다. 그 결과, 파이프라인 전체에 걸쳐 유휴 시간이 거의 없는 연속적인 토큰 생성이 가능해지며, 복잡한 파이프라인 동기화로 인한 성능 저하를 완화합니다. 실험 결과에 따르면 Sarathi-Serve는 파이프라인 병렬화된 180B 모델 실험에서 파이프라인 버블을 최소화하여 기존 대비 현저히 향상된 처리량을 나타냈습니다. 이는 대규모 모델의 다중 GPU 배치에 Sarathi-Serve 기법이 효과적으로 적용될 수 있음을 시사합니다.

Sarathi-Serve는 오픈소스 vLLM 코드베이스를 확장하여 개발되었으며, vLLM이 제공하는 PagedAttention 기반 메모리 관리 및 PyTorch 연산 최적화 기능을 활용하면서 다양한 스케줄링 정책 설정, 파이프라인 병렬화, 정밀한 모니터링 기능을 자체적으로 추가하여 연구 실험을 수행할 수 있도록 하였습니다. 

즉, Sarathi-Serve는 (a) LLM 추론의 근본적인 처리량-지연 시간 상충 관계를 분석하고, (b) 청크드 프리필과 stall-free 스케줄링이라는 실용적인 해결책을 제시하였으며, (c) 이를 구현 및 실증하여 LLM 서비스 시스템의 성능 한계를 크게 향상시킨 것입니다. 

 

Background and Related Work

LLM(대규모 언어 모델) 추론의 효율성을 제고하기 위한 기존 시스템들과 그 한계점을 이해하는 것은 Sarathi-Serve의 맥락을 파악하는 데 있어 매우 중요합니다. 이어서 처리량과 지연 시간 간의 상충 관계와 관련된 주요 기존 접근 방식을 상세히 설명하겠습니다.

 

• 요청 단위 일괄 처리 및 디코드 우선 스케줄링: 초기 LLM 서버들은 주로 전통적인 요청 레벨(batch-per-request) 방식을 채택하여, 여러 요청을 일괄적으로 취합하여 프롬프트부터 모든 토큰 생성까지 일괄 처리한 후 다음 배치를 처리하는 형태였습니다. NVIDIA의 FasterTransformer 라이브러리가 이러한 접근 방식의 대표적인 예시입니다. 각 배치 내 요청들은 동시에 처리되지만, 배치 간에는 상호 간섭이 존재하지 않습니다. 이러한 방식은 디코드 중간에 새로운 요청이 삽입되지 않으므로 지연 시간 측면에서 유리하며, 먼저 접수된 요청들은 완료될 때까지 방해받지 않고 처리되어 토큰 간 지연(TBT)이 작고 예측 가능성이 높습니다. 그러나 GPU 자원 활용 측면에서는 비효율성이 두드러집니다. 한 배치의 일부 요청이 조기에 완료되더라도 다음 요청을 대기하느라 GPU가 유휴 상태가 되거나, 디코드 단계에서 배치 크기가 감소하면서 계산 유닛이 활용되지 못하는 문제가 발생합니다. 결과적으로 처리량을 증대시키기 위해 배치 크기를 확대하면 개별 요청 지연 시간이 길어지는 딜레마에 직면하게 되며, 반대로 지연 시간을 단축시키기 위해 배치를 축소하면 GPU가 충분히 활용되지 못하여 처리량이 저하되는 문제가 발생합니다. FasterTransformer 등의 디코드 우선(요청 단위) 접근 방식은 낮은 지연 시간 보장은 가능하지만, 다중 요청 동시 처리 효율성이 낮아 Orca와 같은 최신 시스템 대비 성능 면에서 열위에 놓이는 경향이 있습니다.

 

• 반복 단위 일괄 처리 및 프리필 우선 스케줄링: 2022년 OSDI에서 발표된 Orca 시스템은 LLM 추론에서 반복(iteration) 단위로 배치를 유동적으로 변경하는 Continuous Batching(동적 일괄 처리) 개념을 도입했습니다. Orca의 스케줄러는 한 번에 한 토큰 생성 iteration만을 실행하고, 다음 iteration 시 새로운 요청을 배치에 추가하거나 완료된 요청을 배치에서 제외하는 방식으로 작동하여 토큰 생성 중에도 배치 구성이 변경될 수 있도록 하였습니다. 또한 Selective Batching이라는 기법을 활용하여 Transformer 레이어 내 일부 연산에만 배치를 적용함으로써 불필요한 동기화 지연을 최소화하였습니다. Orca는 이러한 기법들을 통해 GPT-3 175B 모델 추론 실험에서 동일 지연 시간 수준에서 NVIDIA FasterTransformer 대비 36.9배의 처리량 향상을 달성했다고 보고하였습니다. Orca의 등장은 LLM 서비스에서 Iteration-level scheduling의 우수성을 입증하였으며, 이후 여러 시스템에 지대한 영향을 미쳤습니다. 대표적으로, UC Berkeley 등에서 개발한 vLLM은 Orca와 유사한 연속 배치 아이디어에 더하여 PagedAttention이라는 혁신적인 메모리 관리 기법을 도입하여 대용량 KV 캐시를 효율적으로 관리함으로써 대형 모델의 배치 크기 한계를 극복한 시스템입니다. vLLM은 KV 캐시를 가상 메모리 페이지처럼 블록화하여 메모리 단편화 및 중복을 방지함으로써 동일 지연 시간에서 기존 시스템(FasterTransformer, Orca 등) 대비 2~4배 높은 처리량을 달성했다고 보고되었습니다. 이는 곧 vLLM이 처리량과 지연 시간 양면에서 당시 state-of-the-art였음을 의미합니다. 다만, Orca나 vLLM의 기본 스케줄링 정책은 처리량 최적화를 위해 프리필 요청을 신속하게 배치에 포함시키는 방향(prefill-prioritized)이었으며, 이는 앞서 언급한 Generation Stall 문제를 완전히 해소하지는 못했습니다. 예를 들어, vLLM은 첫 토큰 출력 지연(TTFT)을 최소화하기 위해 새로운 프리필이 도착하면 즉시 실행하도록 설계되었는데, 그 결과 진행 중이던 디코드 토큰 생성을 일시 중단하게 되어 토큰 출력 간격의 tail 지연(P99 TBT)이 길어질 수 있었습니다. Orca 또한 혼합 배치(hybrid batch)를 지원하지만, 긴 프리필이 포함된 배치는 완료까지 상당한 시간이 소요되어 그 동안 다른 디코드 요청들을 대기하게 만드는 것으로 지적됩니다. 이러한 한계로 인해 순수 프리필-우선 정책이나 순수 디코드-우선 정책만으로는 높은 처리량과 낮은 tail 지연을 동시에 만족시키기 어렵다는 것이 일반적인 견해입니다.기존의 다양한 연구들은 LLM 추론 성능 개선을 위해 병행되어 왔습니다. LightLLM과 같은 경량화 기법은 분산 메모리 활용 및 연산 최적화를 통해 추론 속도를 향상시켰으며, Disted나 SplitServe 등은 LLM 서비스를 다중 노드 분산으로 확장하여 지연 시간과 처리량 간 균형점을 찾고자 하였습니다. FastServe는 클라이언트 요청 간 프리엠션을 도입, 짧은 요청이 긴 요청 뒤에서 대기하는 상황을 방지하는 스케줄링 개선 방안을 제시하였습니다. 이러한 기법들은 Sarathi-Serve의 접근 방식과 상호 보완적으로 적용 가능하다고 논문에서 언급됩니다. 응답 길이 예측 기반 스케줄링 연구에서는 LLM 자체의 응답 길이 예측 능력을 활용, 유사한 길이의 요청들을 그룹핑함으로써 짧은 요청이 긴 요청으로 인해 블로킹되는 현상을 방지하였습니다. 한편, 추론 가속 엔진 측면에서는 TensorRT-LLM(NVIDIA)이나 Huawei’s MindSpore 등에서 디코드 스트리밍, 연속 배치, 양자화 등의 기능을 제공하여 낮은 수준에서 GPU 활용 효율을 극대화하려는 노력이 있었습니다. 예를 들어, TensorRT-LLM은 In-Flight Batching(실시간 동적 배치)을 지원하여 vLLM과 유사하게 요청들을 끊김 없이 처리하고, 고성능 커스텀 커널을 통해 지연 시간을 최소화합니다. 이러한 상향식 최적화와 Sarathi-Serve와 같은 스케줄러 차원의 최적화는 상호 보완적인 관계를 가지며, 궁극적으로 LLM 서비스의 성능 한계를 지속적으로 확장하고 있습니다.

 

LLM 추론 성능을 논할 때 Llama.cpp로 대표되는 로컬 경량화 엔진을 빼놓을 수 없습니다. Llama.cpp는 Meta의 LLaMA 모델을 대상으로 C++로 구현된 초경량 추론 엔진으로, 4-bit, 8-bit 양자화 등을 통해 거대 모델을 일반 CPU나 모바일 장치에서도 실행 가능하게 하여 큰 반향을 일으켰습니다. Llama.cpp 자체는 대규모 동시 서비스보다는 단일/저수준 하드웨어 환경에서의 최적화에 초점을 맞추고 있습니다. 예를 들어, 30억~70억 매개변수 모델을 Apple M1 칩 등에서 수십 토큰/초 정도로 생성하는 데 성공하여 경량화에 따른 성능 향상을 보여주었으나, GPU를 활용한 대규모 동시 처리 환경의 절대 성능과는 차이가 있습니다. 다만 Llama.cpp를 통해 입증된 극단적 양자화에 따른 메모리/속도 개선은 상용 시스템에도 영향을 주어, PyTorch 기반 추론에서도 4비트 Quantization (GPTQ 등) 기법이 도입되는 등 모델 경량화와 스케줄링 최적화의 접목이 이루어지고 있습니다. Sarathi-Serve는 모델 자체 성능(속도)은 주어진 상태에서 스케줄링을 통해 효율을 극대화하는 접근 방식이므로, 장래에 Llama.cpp 수준의 경량화 모델을 Sarathi-Serve와 함께 사용하면 한정된 자원으로도 매우 높은 효율의 서비스가 가능할 것입니다.

 

System Architecture of Sarathi-Serve

전체 아키텍처를 구성하는 주요 컴포넌트는 다음과 같습니다.

• 스케줄러 (Scheduler): Sarathi-Serve의 핵심인 Stall-Free 배치 스케줄러가 이 모듈에 해당합니다. 스케줄러는 매 시각 새로운 요청과 진행 중인 요청들을 관리하며, 앞서 설명한 토큰 예산 계산과 배치 구성 알고리즘을 수행합니다. 구체적으로, 요청 대기열에서 새로운 입력이 들어오면 이를 추적하고, 현재 진행 중인 대화 세션들의 상태(각 요청이 프리필 단계인지 디코드 단계인지, 남은 프롬프트 토큰이 얼마나 있는지 등)를 관리합니다. Sarathi-Serve 스케줄러는 각 iteration 루프마다 다음을 수행합니다:

1. 토큰 예산 확인: 사용자 지정 지연 SLO로부터 계산된 이번 iteration의 토큰 처리 한도(t_max)와 현재까지 사용된 토큰 수(n_t) 등을 갱신합니다.
2. 디코드 토큰 배치: 현재 디코드 단계에 있는 모든 요청을 배치에 포함시킵니다. 각 요청은 이번 iteration에 1개씩의 디코드 토큰을 생성해야 하므로, 해당 토큰들을 배치로 예약하고 n_t를 증가시킵니다.
3. 진행 중인 프리필 청크 배치: 아직 프리필을 완료하지 못한 요청들(이전에 일부 청크만 처리된 상태)이 있다면, 이들 각각에 대해 다음 프리필 청크를 하나씩 배치에 추가합니다. 단, 남은 토큰 예산을 초과하지 않도록 각 청크의 크기를 조정하며(get_next_chunk_size 연산) 추가합니다. 이렇게 함으로써 이전 iteration에서 분할해둔 프리필 작업을 점진적으로 완수해나갑니다.
4. 신규 요청 프리필 배치: 현재 배치에 여유가 있고 추가 토큰 예산이 남아 있다면, 대기 중인 새로운 요청의 프리필을 배치에 포함시킵니다. 이때도 leftover token budget 내에서 허용되는 최대 청크 길이를 계산하여 해당 크기만큼만 프리필을 실행합니다. 만약 어떤 신규 요청의 프리필이 매우 길어 현재 예산으로는 일부만 처리 가능하다면, 그 요청은 분할되어 처리되며 남은 부분은 다음 iteration으로 넘어갑니다 (청크드 프리필).
5. 배치 실행 및 마무리: 이렇게 구성된 배치를 GPU 상에서 실행합니다 (process_hybrid_batch). GPU에서는 이 배치 내에 포함된 모든 토큰에 대한 전방 패스(forward pass)를 병렬로 수행하며, PyTorch/XFormers 커널이 내부적으로 각 요청의 컨텍스트 길이에 맞춰 처리를 진행합니다. 실행 완료 후 배치에 완료된 요청(예: 디코드 토큰으로 응답이 종료되었거나 프리필+지정된 출력 길이 완료)이 있다면 배치 목록에서 제거하고 결과를 응답으로 반환합니다. 그리고 다음 iteration을 위해 토큰 예산 누적치(n_t)를 0으로 재설정하고 루프를 반복합니다.

이와 같은 스케줄러 동작은 비동기 이벤트 루프 형태로 구현되어 지속적으로 작동하며, 들어오는 요청과 나가는 응답 스트림을 관리합니다. Sarathi-Serve의 스케줄러는 vLLM의 기본 스케줄러를 확장하여 여러 정책을 실험할 수 있도록 설계되었으며, 논문에서 소개된 Algorithm 1 (요청 레벨), Algorithm 2 (vLLM 반복 레벨), Algorithm 3 (Stall-free)을 선택적으로 구현하여 비교했다고 합니다. Sarathi-Serve는 기본적으로 Algorithm 3를 사용하지만, 실험 목적으로 다른 모드를 활성화하여 공정한 비교를 수행했습니다.

 

• 모델 실행기 (Model Execution Engine): 스케줄러가 구성한 배치를 실제로 GPU에서 실행하는 컴포넌트입니다. vLLM 기반으로, 모델은 FP16/BF16 Tensor 연산으로 추론합니다. Sarathi-Serve는 최신 고속화 기법들을 활용하기 위해 FlashAttention 2와 FlashFiller 커널 등을 도입했다고 밝히고 있는데, FlashAttention 2는 Tri Dao 등이 발표한 메모리 접근 최적화된 어텐션 구현으로, 긴 시퀀스 처리 시 속도를 향상시킵니다. FlashFiller는 논문에서 구체적으로 설명되지는 않았으나 KV 캐시를 패딩/정리하는 커널로 추측되며, paged KV 관리(vLLM의 PagedAttention)와 청크드 프리필을 결합하는 역할을 수행할 것입니다. 실행 엔진은 배치 내 각 요청마다 서로 다른 시퀀스 길이와 상태(KV 캐시) 유무를 가지고 있어도 이를 효율적으로 처리해야 합니다.

Sarathi-Serve는 vLLM의 메모리 관리 기능을 활용하여 다수의 요청에 대한 KV 캐시를 연속적인 메모리 공간에 배치하고 관리합니다. 이 과정에서 새로운 프리필 청크를 포함하는 시퀀스는 초기 상태가 없으므로 처음부터 계산하여 KV 캐시를 채우고, 디코드 토큰 요청은 이전 KV 캐시를 참조하여 다음 토큰을 추가 연산합니다. 이 모든 연산은 동일한 모델 파라미터를 대상으로 하므로 단일 병렬 매트릭스 연산으로 가능하며, PyTorch Xformers 라이브러리는 이러한 가변 길이 배치의 병렬 처리를 지원합니다. Sarathi-Serve는 멀티-GPU 파이프라인 병렬화를 지원하므로, Execution Engine은 단일 GPU뿐 아니라 모델이 분할된 여러 GPU에서 순방향 연산을 수행합니다. 이때 각 GPU에서 처리하는 배치 토큰 수를 동일하게 유지하도록 스케줄링하여 기존 파이프라인 엔진 대비 추가적인 동기화 지연 없이 높은 효율로 동작합니다. 

 

• 메모리 관리 및 KV 캐시: vLLM으로부터 계승된 PagedAttention 기법이 Sarathi-Serve의 핵심 기술로 활용됩니다. LLM 디코딩 과정에서 각 입력에 대해 계층별 KV 캐시 메모리가 생성되는데, 기존 시스템은 이를 연속된 거대한 배열에 할당하고 고정 크기로 사용함으로써 메모리 낭비 및 조각화 문제를 야기했습니다. vLLM은 KV 캐시를 작은 페이지 블록으로 분할하여 동적으로 할당 및 해제하는 방식으로 이러한 문제를 해결하여 메모리 활용 효율을 거의 100%에 가깝게 향상시켰습니다. Sarathi-Serve 또한 동일한 방식을 채택하여 동시 수백 개 요청의 KV 캐시를 메모리 과사용 없이 효율적으로 관리합니다. 이는 Sarathi-Serve가 대형 배치를 구성할 수 있는 기반을 제공합니다. 또한, Sarathi-Serve는 프리필 청크 분할에 따른 KV 캐시 처리도 지원합니다. 예를 들어, 프롬프트를 3개의 청크로 분할한 경우, 첫 번째 청크 처리 후 KV 캐시가 일부 채워진 상태에서 다음 청크를 처리해야 하며, 이때 이전 KV 캐시를 참조하여 연산을 이어가야 합니다. Sarathi-Serve는 이를 위해 FlashFiller 등의 커널을 사용하여 청크 간 KV 캐시를 효율적으로 연결하고, 필요한 경우 반복적인 메모리 접근을 빠르게 수행하도록 최적화했습니다. 

 

• 통신 및 스트리밍: LLM 서비스에서는 토큰이 생성되는 즉시 스트리밍 응답을 전송하는 경우가 많습니다. Sarathi-Serve는 vLLM 기반이므로 토큰 스트리밍 인터페이스를 지원하며, 각 반복 단계에서 완료된 토큰들을 수집하여 클라이언트에 스트림 형태로 전송합니다. 

 

Performance Evaluation and Comparison

Sarathi-Serve 논문은 광범위한 실험을 통해 제안된 기법의 효용성을 입증하였습니다. 주요 실험 결과는 다음과 같이 요약될 수 있습니다.

 

• 처리량-지연 시간 개선: Sarathi-Serve는 동일한 지연 시간 SLO 조건 하에서 기존 시스템 대비 현저히 높은 처리량을 달성했습니다. 예를 들어, Mistral-7B (7억 파라미터) 모델을 단일 A100 GPU로 추론할 때 P99 토큰 지연 0.5초를 충족하는 최대 처리량을 비교한 결과, vLLM이 약 0.55 QPS(초당 쿼리)의 한계를 보인 반면 Sarathi-Serve는 약 1.0 QPS까지 처리량을 증대시켜 약 1.8배의 향상을 나타냈습니다. 더욱 심각한 부하 상황에서는 vLLM의 tail 지연이 수 초까지 증가하였으나, Sarathi-Serve는 1초 미만으로 억제하여 안정적인 서비스 품질을 유지했습니다. 이는 생성 정지 현상이 제거되어 토큰 출력 주기가 일정하게 유지되기 때문입니다. 반면 처리량만을 강조한 vLLM은 새로운 요청을 과도하게 수용하여 batch 크기를 늘린 결과, 토큰 간 간격이 현저히 느려지는 양상을 보였습니다. Sarathi-Serve는 이처럼 높은 부하 조건에서도 낮은 지연 시간을 유지함으로써 트레이드오프 곡선 자체를 상향 이동시켰습니다.

 

• Serving Capacity 증가: 논문에서는 특정 지연 SLO(예: P99 TBT 1초 등)를 만족하며 처리할 수 있는 최대 QPS를 Serving Capacity로 정의하고 비교하였습니다. Sarathi-Serve는 Mistral-7B@A100 환경에서 기존 대비 2.6배의 서빙 용량 증가를 보였으며, Yi-34B (34억 파라미터) 모델을 2×A100으로 구동한 실험에서는 최대 3.7배의 향상을 나타냈습니다. 특히 Yi-34B 실험은 Arxiv 요약 작업 시나리오의 실제 요청 패턴(트레이스)을 사용하여 128개의 동시 요청을 가정한 결과인데, 이 시나리오에서 vLLM은 여러 차례 수 초에 달하는 정체 구간이 발생한 반면, Sarathi-Serve는 일관되고 원활한 토큰 스트림을 제공했습니다. 논문 내 실험 그림에서 vLLM의 토큰 생성은 중간중간 멈추는 구간이 불규칙하게 나타난 반면, Sarathi-Serve는 지속적으로 토큰을 생성하여 동일 시간 내에 훨씬 많은 토큰을 출력했습니다. 이러한 정성적 개선은 대화형 서비스에서 사용자의 체감 품질을 향상시키는 데 매우 중요합니다.

 

• 배치 효과 분석: Sarathi-Serve가 도입한 기법들의 효과를 세부적으로 검증하기 위한 동기 부여 실험도 수행되었습니다. 그림 3은 배치 크기에 따른 프리필 및 디코드 처리량을 보여줍니다.

 프리필의 경우, 배치를 1개에서 8개로 늘려도 초당 처리 토큰 수가 4천~5천 토큰 수준에서 거의 증가하지 않았지만, 디코드는 배치 1에서 약 50 tok/s에 불과했던 것이 배치 64에서는 800 tok/s까지 거의 선형적으로 증가함을 확인할 수 있습니다. 이는 앞서 설명한 바와 같이 디코드 단계는 배치 병렬화를 통해 상당한 이점을 얻지만, 프리필 단계는 이미 GPU를 최대한 활용하고 있어 추가적인 배치 효과가 미미함을 실증합니다. Sarathi-Serve는 바로 이러한 특성을 활용하여 프리필을 세분화하고 디코드 배치와 혼합하여 처리함으로써 디코드의 병렬 효율성을 확보하면서도 프리필로 인한 지연 시간을 줄였습니다. 한편, 그림 4는 프리필 및 디코드 단계의 연산 소요 시간 구성을 보여줍니다.

 Linear 레이어 연산(매트릭스 곱)이 두 단계 모두 대부분의 시간을 차지하며, 특히 디코드 단계에서는 한 토큰에 대한 linear 연산 비용이 128개 토큰에 대한 프리필 linear 연산 비용과 거의 동일할 정도로 비효율적임을 보여줍니다. 이는 디코드 시 메모리 대역폭 병목 현상으로 인해 GPU가 충분히 활용되지 못하기 때문인데, Sarathi-Serve의 청크드 프리필 동시 실행은 이러한 유휴 연산 자원을 활용하여 전체 처리량을 증대시키는 원리를 설명합니다.

 

Sarathi-Serve는 청크 분할 프리필로 인한 오버헤드가 지연 시간에 미치는 영향을 평가하였습니다. Figure 9에서는 혼합 배치 환경에서 프리필 청크 사용 유무에 따른 TBT 지연 시간을 비교하였습니다. 

 

프리필을 일괄 처리하는 경우 TBT(p99)가 최대 28.3배까지 악화되었으나, 청크 분할 프리필을 적용했을 때는 지연 시간이 매우 낮은 수준으로 유지되었습니다. 즉, 프리필과 디코드를 동시에 배치하되 프리필을 분할하지 않는 나이브한 혼합 배칭 방식은 오히려 최악의 지연을 초래할 수 있습니다. 반면 Sarathi-Serve 방식(stall-free + 청크 분할)은 지연 시간을 디코드 전용 배치 수준으로 억제하면서 처리량을 증대시킬 수 있음을 입증하였습니다. 또한 Figure 14에서는 다양한 청크 크기에 따른 프리필 오버헤드를 측정하였습니다. 

Yi-34B 모델에서 프롬프트 길이를 2048로 고정하고 청크 크기를 32부터 2048까지 변경하며 프리필 총 시간을 측정한 결과, 청크 크기가 작아질수록(청크 개수 증가) 프리필 시간에 약간의 오버헤드가 추가되는 양상이 나타났습니다. 하지만 그 증가폭은 완만하여, 작은 청크 크기에서도 프리필이 여전히 연산 중심적(compute-bound)임을 확인하였습니다. 이는 적절히 작은 크기로 청크를 분할하여도 GPU가 연산 작업을 지속적으로 수행하며, 메모리 재활용에 따른 추가 비용은 비교적 미미하여 Sarathi-Serve 접근 방식이 유효함을 뒷받침합니다. Sarathi-Serve는 내부적으로 시뮬레이터와 프로파일러를 활용하여 이러한 데이터를 바탕으로 최적 토큰 예산을 결정하였다고 밝혔으며, 이는 실제 서비스 환경에 적용 시 오프라인 측정을 통해 파라미터 튜닝이 가능함을 시사합니다.

 

Sarathi-Serve는 경량 7B 모델부터 초대형 180B 모델까지 실험하여 기법의 범용성을 입증하였습니다. 특히 Falcon-180B(약 1800억 파라미터) 모델을 8-GPU (A100 80GB × 8)로 파이프라인 병렬화하여 추론한 실험에서, Sarathi-Serve는 Orca 및 vLLM 대비 최대 5.6배 높은 처리량을 보였습니다. 절대적인 수치로도, 예를 들어 1초 내 95% 응답 보장 조건 하에서 vLLM이 처리할 수 있는 QPS 대비 Sarathi-Serve는 5배 이상의 QPS를 처리하여, 동일 하드웨어로 훨씬 많은 부하를 감당할 수 있음을 의미합니다. 이는 곧 운영 비용 절감 효과로 이어집니다. Sarathi-Serve는 모델 크기가 클수록 더 높은 이득을 보이는 경향이 있는데, 이는 모델 크기가 클수록 디코드 단계의 비효율성(메모리 병목 현상)이 심화되어 Sarathi-Serve의 이점이 더욱 부각되기 때문으로 해석됩니다. 또한 프롬프트 길이 또는 응답 길이가 긴 시나리오일수록 프리필과 디코드 단계의 불균형이 커지므로 Sarathi-Serve의 청크 분할 프리필 방식이 더욱 유용할 것입니다.

결론적으로, ‘Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve’ 논문은 LLM 서비스 인프라의 핵심적인 성능 문제를 정확히 지적하고, 청크드 프리필과 스톨-프리 스케줄링이라는 독창적인 아이디어를 통해 기존에는 상호 배타적인 관계로 인식되었던 높은 처리량과 짧은 응답 지연이라는 두 가지 목표를 동시에 달성할 수 있음을 입증했습니다. 이는 기업이 LLM 서비스를 운영할 때 동일한 GPU 자원을 활용하여 더 많은 사용자 요청을 처리하면서도 사용자 경험을 크게 향상시킬 수 있음을 의미합니다. 궁극적으로, 총소유비용(TCO) 절감과 서비스 품질 향상이라는 두 가지 중요한 목표를 동시에 달성할 수 있게 됩니다.

마지막으로, Sarathi-Serve 도입 시 시스템 복잡성을 유의해야 합니다. Stall-Free 스케줄링은 구현 및 튜닝 난이도가 높고, 모든 상황에서 최적임을 보장할 수 없습니다. 예컨대 매우 간단하고 짧은 요청만 처리하는 서비스라면 기존 방식이 더 단순하고 효율적일 수 있습니다. 또한 Sarathi-Serve가 최대 성능을 발휘하려면 충분한 부하가 필요하므로, GPU가 제한적이고 QPS가 낮은 경우에는 효과가 미미할 수 있습니다. 따라서 사용 패턴을 면밀히 분석하여 Sarathi-Serve 도입 타당성을 판단해야 합니다.

 

끝