LLM 최적화 : 논문리뷰 : SpotServe: Serving Generative Large Language Models on Preemptible Instances

Abstract

Generative LLM의 높은 연산 및 메모리 요구 사항으로 인해 저렴하게 서비스를 제공하기가 어려움.

 

이 논문에서는 일반 인스턴스보다 훨씬 저렴한 가격으로 여분의 GPU 리소스에 대한 액세스를 제공하지만 언제든지 클라우드 제공업체에 의해 선점될 수 있는 최신 클라우드의 preemptible GPU 인스턴스를 활용하여 LLM 서비스의 비용을 절감하는 것을 목표로 합니다.

 

Preemptible 인스턴스에서 LLM을 서비스하려면 빈번한 인스턴스 선점으로 인한 문제와 이러한 선점을 처리하기 위해 인스턴스를 마이그레이션해야 하는 문제를 해결해야 합니다.

 

이 논문에서는 preemptible 인스턴스에서 최초의 분산 LLM 서비스 시스템인 SpotServe를 제시합니다. SpotServe의 몇 가지 주요 기술은 저렴한 preemptible 인스턴스에서 generative LLM의 빠르고 안정적인 서비스를 실현합니다.

 

 

막간 용어 설명

preemptible GPU 인스턴스 : 저렴한 가격의 GPU 인스턴스입니다. 일반 인스턴스보다 훨씬 저렴하게 사용할 수 있는 대신, 언제든지 클라우드 제공업체에 의해 회수될 수 있다는 특징

인스턴스 마이그레이션  : 실행 중인 인스턴스를 다른 물리적 머신으로 이동하는 것

 

Workload : 시스템이 처리해야 하는 작업량

- SpotServe에서의 중요성: SpotServe는 workload 변화에 따라 LLM parallelization configuration을 동적으로 조정하여 효율적인 리소스 활용을 목표

 

LLM Parallelization Configuration : LLM을 여러 GPU에 분산하여 실행하기 위한 설정

- SpotServe에서의 중요성: SpotServe는 preemptible 인스턴스의 가용성과 workload 변화에 따라 LLM parallelization configuration을 동적으로 조정

 

동적 reparallelization : 실행 중에 LLM parallelization configuration을 변경하는 것을 의미

- SpotServe에서의 활용: preemptible 인스턴스가 회수되는 경우, SpotServe는 동적 reparallelization을 통해 남아있는 인스턴스에 모델을 재분배하여 서비스를 계속 제공

 

Kuhn-Munkres 알고리즘 : 이분 그래프에서 최대 가중치 매칭을 찾는 알고리즘입니다. 즉, 두 그룹 간의 연결에서 최적의 쌍을 찾아 연결하는 데 사용

- SpotServe에서의 활용: SpotServe는 인스턴스 마이그레이션 시 Kuhn-Munkres 알고리즘을 사용하여 통신 비용을 최소화하는 최적의 마이그레이션 계획을 찾음

 

On-demand 인스턴스 : 클라우드 제공업체에서 제공하는 일반적인 인스턴스 유형으로, 사용자가 원하는 만큼 사용하고 비용을 지불하는 방식

- SpotServe에서의 활용: SpotServe는 on-demand 인스턴스와 preemptible 인스턴스를 함께 사용하여 비용 효율성과 안정성을 모두 확보

 

Stateful Inference Recovery : SpotServe에서의 역할: preemptible 인스턴스의 유예 기간을 활용하여 inference 진행 상황을 더 자주 저장하고, 선점 발생 시 이전 상태를 복구하여 inference를 재개하는 메커니즘

 

Inference latency : 머신러닝 모델이 입력 데이터를 받아서 출력 결과를 생성하는 데 걸리는 시간

 

첫째, SpotServe는 전체 throughput, inference latency 및 비용 간의 trade-off의 균형을 맞추면서 동적 인스턴스 가용성 및 변동하는 workload에 맞게 LLM parallelization configuration을 동적으로 조정합니다.

 

둘째, 동적 reparallelization을 위한 인스턴스 마이그레이션 비용을 최소화하기 위해 SpotServe에서 인스턴스 마이그레이션 작업을 이분 그래프 매칭 문제로 공식화하여 Kuhn-Munkres 알고리즘을 사용하여 통신 비용을 최소화하는 최적의 마이그레이션 계획을 식별합니다.

 

마지막으로 최신 클라우드 플랫폼에서 제공하는 유예 기간을 활용하기 위해 훨씬 더 세분화된 단위로 inference 진행 상황을 커밋하고 SpotServe가 선점 시 저렴하게 inference를 재개할 수 있도록 하는 새로운 inference 메커니즘인 stateful inference recovery를 도입합니다.

 

 

실제 spot 인스턴스 선점 추적 및 다양한 인기 LLM에서 SpotServe를 평가하고 SpotServe는 기존 최고의 LLM 서빙 시스템에 비해 P99 테일 지연 시간을 2.4~9.1배 단축할 수 있음을 보여줍니다. 

또한 SpotServe가 preemptible 인스턴스의 가격 이점을 활용하여 on-demand 인스턴스만 사용하는 것에 비해 54%의 금전적 비용을 절감할 수 있음을 보여줍니다.

 

 

introduction

용어 설명

 

dedicated GPU : 특정 작업이나 애플리케이션에만 할당된 GPU를 의미합니다. 다른 작업과 GPU 리소스를 공유하지 않으므로, 해당 작업에 최대한의 GPU 성능을 활용

 

SpotServe에서의 활용: SpotServe는 preemptible 인스턴스를 사용하지만, 각 sub-model은 dedicated GPU에서 실행되어 성능을 최대화

 

단정밀도 부동 소수점 (Single-precision floating-point) : 컴퓨터에서 실수를 표현하는 방식 중 하나로, 32비트를 사용하여 실수를 저장

 

여러 DNN serving 시스템 : DNN 모델을 효율적으로 서비스하기 위한 다양한 시스템들을 의미합니다. (예: TensorFlow Serving, TorchServe, Triton Inference Server)

 

request rerouting : 들어오는 요청을 다른 서버로 재전송하는 것을 의미. 

- SpotServe: SpotServe는 request rerouting 대신 동적 reparallelization을 사용하여 preemptible 인스턴스의 선점에 대응

 

redundant computation : 동일한 계산을 여러 번 수행하는 것을 의미

- SpotServe는 redundant computation 대신 stateful inference recovery를 사용하여 preemptible 인스턴스의 선점에 대응

 

data, tensor model, pipeline model parallelism을 결합해야 하는 LLM으로 확장

의미: LLM은 모델의 크기가 매우 크기 때문에, 효율적인 학습 및 inference를 위해 다양한 병렬화 기법을 결합해야 합니다.

• Data Parallelism: 동일한 모델을 여러 GPU에 복사하여 각 GPU가 데이터의 일부를 처리하도록 합니다.
• Tensor Model Parallelism: 모델의 가중치를 여러 GPU에 분산하여 저장하고 계산합니다.
• Pipeline Model Parallelism: 모델의 레이어를 여러 GPU에 분산하여 순차적으로 실행합니다.

inference granularity : 하나의 inference 작업을 수행하는 데 필요한 최소 단위를 의미

SpotServe에서의 중요성: SpotServe는 stateful inference recovery를 통해 inference granularity를 줄여 preemptible 인스턴스의 선점으로 인한 손실을 최소화합니다.

 

 

 

 

ChatGPT와 GPT-4와 같은  LLM의 높은 연산 및 메모리 요구 사항으로 인해 최신 하드웨어 플랫폼에서 효율적으로 서비스를 제공하기가 어렵습니다.

 

이러한 문제를 해결하기 위해 최근 연구에서는 LLM을 여러 개의 sub-model로 분할하여 각 sub-model을 dedicated GPU에 배포함으로써 LLM inference를 parallelizing하는 다양한 접근 방식을 도입했습니다. 

 

최신 클라우드는 LLM을 서비스하기 위한 보다 저렴한 접근 방식을 제공하는 다양한 preemptible GPU 인스턴스를 제공합니다. 이러한 인스턴스는 on-demand 인스턴스보다 최대 낮은 가격으로 최신 클라우드의 여분 용량에서 실행됩니다. 그러나 on-demand 인스턴스와 달리 spot 인스턴스는 다른 인스턴스에서 용량이 필요할 때 언제든지 선점될 수 있습니다. spot 인스턴스가 선점되면 최신 클라우드는 인스턴스가 실행 중인 작업을 완료하고 정상적으로 중지할 수 있도록 유예 기간 (예: AWS spot 인스턴스의 경우 30초)을 제공합니다.

 

기존 연구에서는 DNN inference의 비용을 절감하기 위해 spot 인스턴스를 활용하는 여러 DNN serving 시스템을 소개했습니다. 이러한 시스템의 대부분 (예: MArk, Cocktail)은 하나 또는 여러 개의 GPU를 사용하는 단일 spot 인스턴스에 적합할 수 있는 소규모 DNN 모델을 대상으로 하며, request rerouting 또는 redundant computation을 사용하여 선점을 처리합니다. 이러한 접근 방식은 data parallelism을 사용하여 소규모 모델을 효과적으로 서비스할 수 있지만, data, tensor model, pipeline model parallelism을 결합해야 하는 LLM으로 확장할 수 없습니다. Model parallelism은 최소 inference granularity를 단일 GPU 인스턴스에서 인스턴스 그룹 (즉, inference pipeline)으로 확장하기 때문에 선점이 더 이상 독립적이지 않고 각 선점이 동일한 inference pipeline의 다른 모든 인스턴스에 영향을 미치므로 rerouting 및 redundant computation보다 선점을 처리하는 더 효율적인 방법이 필요합니다.

 

이 논문에서는 spot 인스턴스에서 최초의 분산 generative LLM serving 시스템인 SpotServe를 제시합니다. SpotServe는 data, tensor model, pipeline model parallelism을 결합하여 여러 spot GPU 인스턴스에서 LLM inference를 parallelizing하고 on-demand 인스턴스를 사용하여 LLM을 서비스하는 것과 동일한 결과를 생성합니다. spot GPU 인스턴스에서 LLM을 서비스하려면 가지 주요 과제, 즉

(1) LLM inference를 동적으로 reparallelizing,

(2) 인스턴스를 저렴하게 마이그레이션,

(3) 유예 기간을 효과적으로 활용하는 문제를 해결해야 합니다. 이러한 과제와 SpotServe가 이를 극복하기 위해 사용하는 주요 아이디어에 대해 자세히 설명.

 

 

정리하면 기존에는 요청이 들어오고 그게 선점되면 다른 서버로 보내서 다시 계산을 하거나 redundant computation이 많이 발생했는데. 그게 문제니까 스팟서브에서는 동적으로 할당해서 해결하려는것.

 

 

용어 설명

Intra-operator : 하나의 연산 (operator) 내에서 병렬 처리를 수행하는 전략.

Data Parallelism: 동일한 모델을 여러 GPU에 복사하여 각 GPU가 데이터의 일부를 처리.

Tensor Model Parallelism: 모델의 가중치를 여러 GPU에 분산하여 저장하고 계산.

SpotServe에서의 활용: SpotServe는 tensor model parallelism을 사용하여 큰 LLM 모델을 여러 GPU에 분산시켜 메모리 부담을 줄이고, data parallelism을 사용하여 여러 요청을 동시에 처리.

 

 

Inter-operator Parallelization 전략 : 여러 연산을 여러 GPU에 분산하여 파이프라인처럼 순차적으로 실행하는 전략 Pipeline Model Parallelism: 모델의 레이어를 여러 GPU에 분산하여 순차적으로 실행.

SpotServe에서의 활용: SpotServe는 pipeline model parallelism을 사용하여 LLM inference를 여러 단계로 나누어 각 단계를 다른 GPU에서 실행합니다.

 

Hybrid Optimization 알고리즘 : 여러 목표를 동시에 최적화하는 알고리즘

SpotServe에서의 활용: SpotServe는 throughput과 latency를 모두 고려하여 최적의 parallelization configuration을 찾기 위해 hybrid optimization 알고리즘을 사용

 

 

 

Key/Value Cache : LLM의 Attention 메커니즘에서 이전 토큰의 정보를 저장하는 캐시

SpotServe에서의 활용: SpotServe는 stateful inference recovery를 위해 key/value cache를 사용. 선점 발생 시, key/value cache를 다른 인스턴스로 마이그레이션하여 inference를 재개.

 

Just-In-Time (JIT) 배열 : 필요한 시점에 작업을 수행하는 방식

SpotServe에서의 활용: SpotServe는 key/value cache를 마이그레이션할 시기를 JIT 방식으로 결정. 즉, 선점이 임박했을 때 key/value cache를 마이그레이션하여 유예 기간을 최대한 활용

 

 

 

 

Challenge #1: Dynamic Reparallelization

LLM을 서비스하려면 intra-operator (예: data and tensor model) 및 inter-operator (예: pipeline model) parallelization 전략의 조합을 사용하여 여러 GPU에서 모델 매개변수와 계산을 parallelizing해야 합니다. SpotServe가 해결해야 하는 첫 번째 과제는 인스턴스 선점 및 획득으로 인해 사용 가능한 spot 인스턴스 수가 자주 변경된다는 것입니다. 이는 최적화된 LLM 서비스 성능을 달성하기 위해 parallelization configuration을 동적으로 조정해야 하는 문제이며, 이를 dynamic reparallelization이라고 합니다.

이 문제를 해결하기 위해 SpotServe의 parallelization controller는 spot 인스턴스 가용성의 변화에 따라 LLM 서비스를 위한 parallelization 전략을 동적으로 조정합니다. SpotServe는 parallelization 전략의 inference latency와 서비스 throughput을 모두 고려하고, hybrid optimization 알고리즘을 사용하여 throughput과 latency 간의 trade-off의 균형을 맞춥니다. LLM inference를 동적으로 reparallelizing하면 SpotServe가 spot 인스턴스의 가용성과 요청의 도착률 변화에 빠르게 적응할 수 있습니다.

 

 

Challenge #2: Instance Migration

SpotServe가 해결해야 하는 두 번째 과제는 reparallelization을 위한 GPU 인스턴스 마이그레이션 비용을 최소화하는 것입니다. 특히 다른 parallelization 전략으로 전환할 때 SpotServe는 새로운 모델 매개변수를 통합하고 새로운 통신 그룹을 설정하기 위해 모든 spot 인스턴스를 다시 초기화해야 합니다. spot 인스턴스에서 소규모 DNN 모델을 서비스하는 것에 대한 기존 연구에서는 spot 인스턴스를 다시 초기화하는 데 드는 오버헤드가 무시할 만하다고 가정했습니다. 그러나 처음부터 LLM 서비스를 다시 시작하면 상당한 오버헤드가 발생하기 때문에 LLM의 경우 이러한 가정이 유효하지 않다는 것을 확인했습니다. 예를 들어, persistent storage에서 개의 매개변수가 있는 GPT 모델을 로드하는 데 AWS에서 분 이상이 걸립니다.

Reparallelization을 위한 마이그레이션 비용을 최소화하기 위해 SpotServe는 인스턴스 간의 불필요한 통신을 방지하기 위해 모델 매개변수와 inference request의 key/value cache와 같은 중간 결과를 기회주의적으로 재사용합니다. 사용 가능한 spot 인스턴스를 parallelization 전략의 device mesh에 매핑하는 작업은 SpotServe에서 이분 그래프 매칭 문제로 공식화되며, Kuhn-Munkres (KM) 알고리즘을 활용하여 reparallelization을 위한 spot 인스턴스 마이그레이션 비용을 최소화하는 최적의 device 매핑을 식별합니다. 또한 인스턴스를 마이그레이션할 순서를 결정하기 위해 SpotServe의 migration planner는 pipeline stage의 순차적 실행 순서를 활용하여 인스턴스 마이그레이션을 inference 계산과 겹칩니다.

 

 

Challenge #3: Grace Period

최신 클라우드에서 제공하는 유예 기간을 활용하는 것은 LLM의 inference 시간이 유예 기간을 초과하여 미완료 요청으로 이어질 수 있으므로 또 다른 과제를 제시합니다. 기존 spot 인스턴스 서비스 시스템에서 이러한 미완료 요청은 일반적으로 다른 inference pipeline으로 rerouting되며, 여기서 이러한 요청의 inference 계산이 처음부터 다시 시작됩니다. 이 접근 방식은 유예 기간을 효율적으로 사용하지 않고 redundant computation을 초래합니다.

유예 기간을 활용하기 위해 SpotServe는 LLM의 autoregressive 특성을 활용하고 stateful inference recovery를 도입합니다. 이를 통해 SpotServe의 inference engine은 기존 연구에서 볼 수 있듯이 request level이 아닌 token level에서 진행 상황을 커밋할 수 있습니다. SpotServe의 inference engine은 just-in-time (JIT) 배열을 사용하여 커밋된 token의 key/value cache를 다른 사용 가능한 인스턴스로 마이그레이션할 시기를 결정하고, 캐시된 결과를 사용하여 inference를 재개합니다.

위의 기술을 통해 SpotServe는 기존 접근 방식보다 훨씬 뛰어난 성능을 발휘할 수 있습니다. 실제 추적 및 다양한 LLM에서 SpotServe를 평가한 결과 기존 LLM 서비스 시스템에 비해 P99 tail latency를 2.4~9.1배 줄이는 것으로 나타났습니다. 또한 SpotServe는 spot 인스턴스를 활용하여 평균 inference latency를 유지하면서 on-demand 인스턴스에 비해 LLM 서비스 비용을 최대 54%까지 절감할 수 있습니다.

 

 

Background and Related Work

2.1 Generative LLM Inference

 

Generative LLM은 일반적으로 여러 개의 동일한 Transformer layer를 쌓고 각 layer는 주로 multi-head attention 메커니즘과 feed-forward network (FFN)으로 구성됩니다 (그림 1a 참조).

 

 

Generative LLM은 autoregressive decoding 메커니즘을 채택하여 여러 iteration으로 구성된 incremental inference process를 생성합니다. Generative LLM inference를 더 잘 이해하기 위해 iterative process를 자세히 살펴보겠습니다. 입력 request batch가 주어지면 해당 실행 latency 𝑙𝑒𝑥𝑒는 E.q.(1)에서 두 가지 구성 요소로 나뉩니다.

𝑙𝑒𝑥𝑒 (𝑆𝑜𝑢𝑡 |𝑆𝑖𝑛) = 𝑡𝑒𝑥𝑒 (𝑆𝑖𝑛) + 𝑆𝑜𝑢𝑡∑𝑖=1𝑡𝑒𝑥𝑒 (𝑆𝑖𝑛 + 𝑖) (1)

                          ≈ 𝑡𝑒𝑥𝑒 (𝑆𝑖𝑛) + 𝑆𝑜𝑢𝑡 × 𝑡𝑒𝑥𝑒 (1) (2)

 

 

l_exe는 LLM inference의 전체 실행 latency

여기서 𝑡𝑒𝑥𝑒는 decoding sequence 길이의 함수로서 LLM의 실행 시간 비용을 나타내고,

𝑆𝑖𝑛은 사용자가 제공한 input token의 sequence 길이이며,

𝑆𝑜𝑢𝑡은 LLM에서 생성된 output token의 sequence 길이입니다.

첫 번째 iteration은 모든 input token을 가져와 병렬로 처리하고 첫 번째 output token을 생성하는 initial phase입니다.

 

그런 다음 각 incremental decoding iteration은 현재 생성된 token과 함께 모든 input을 고려하고 하나의 output token을 생성합니다. 그림 1a는 generative LLM이 "ABCD"를 input sequence (즉, 𝑆𝑖𝑛 = 4)로 사용하고 각 iteration에서 하나의 output token을 생성하는 예를 보여줍니다.

기존 generative inference 시스템 (예: FasterTransformer, Orca, FairSeq, Megatron-LM)은 모든 Transformer layer의 key와 value를 GPU device 메모리에 캐싱하는 key-value (KV) caching 최적화를 사용합니다. KV cache는 attention 계산 중에 이전 token을 다시 계산하지 않도록 하여 거의 일정한 per-iteration 오버헤드를 발생시킵니다 (즉, E.q.(2) 및 그림 1a의 𝑡𝑒𝑥𝑒 (1)). 그러나 output sequence가 길어짐에 따라 KV cache의 메모리 공간이 계속 확장되어 실제 workload에서 매우 커질 수 있습니다 (즉, LLaMA-13B에서 per-sequence 1.7GB, OPT-175B에서 테라바이트).

 

 

 

2.2 Distributed Inference of DNNs

 

용어설명

 

NVIDIA Triton : NVIDIA에서 개발한 오픈소스 inference serving 소프트웨어. 다양한 딥러닝 모델을 배포하고 실행할 수 있도록 지원.

-SpotServe와의 관계: SpotServe는 Triton과 같은 inference serving 시스템을 기반으로 구축될 수 있음. Triton이 제공하는 기능들을 활용하여 LLM 모델을 효율적으로 관리하고 서비스할 수 있음.

 

concurrent inference pipeline : 동시에 실행되는 여러 개의 inference pipeline입니다. 각 pipeline은 독립적으로 inference 요청을 처리.

-SpotServe에서의 활용: SpotServe는 여러 개의 concurrent inference pipeline을 사용하여 여러 요청을 동시에 처리하고 throughput을 높임.

 

FasterTransformer : NVIDIA에서 개발한 Transformer 모델 inference를 위한 라이브러리. Transformer 모델의 inference 속도를 높이기 위한 다양한 최적화 기법을 제공

- SpotServe에서의 활용: SpotServe는 FasterTransformer를 사용하여 LLM inference를 가속화

 

Inference server : inference 요청을 받아 처리하고 결과를 반환하는 서버.

- SpotServe에서의 활용: SpotServe는 inference server를 사용하여 LLM 모델을 서비스합니다. Inference server는 클라이언트로부터 요청을 받아 적절한 inference pipeline에 전달하고, 결과를 클라이언트에게 반환

 

inference pipeline에 dispatch : inference 요청을 적절한 inference pipeline에 할당하는 것을 의미

SpotServe에서의 활용: SpotServe는 inference server가 inference 요청을 적절한 inference pipeline에 dispatch하도록 하여 효율적인 리소스 활용을 가능하게 함.

 

end-to-end inference latency( l_req ) :  의미: 클라이언트가 inference 요청을 보낸 시점부터 결과를 받는 시점까지 걸리는 총 시간

SpotServe에서의 중요성: SpotServe는 l_req를 줄이기 위해 노력합니다. 즉, 사용자에게 빠른 응답을 제공하는 것을 목표

 

arrival rate : 단위 시간당 inference server에 도착하는 요청의 수.

SpotServe에서의 고려 사항: SpotServe는 arrival rate 변화에 따라 동적으로 리소스를 할당하고 parallelization configuration을 조정하여 효율적인 서비스를 제공합니다.

 

 

peak serving rate : inference 시스템이 처리할 수 있는 최대 요청 수.

SpotServe에서의 고려 사항: SpotServe는 peak serving rate를 높이기 위해 여러 개의 concurrent inference pipeline을 사용하고, 각 pipeline의 성능을 최적화

 

scheduling overhead( l_sch ) : inference 요청을 스케줄링하는 데 걸리는 시간. 즉, 요청을 받아서 적절한 inference pipeline에 할당하고, 결과를 반환하는 데 드는 시간.

SpotServe에서의 최소화: SpotServe는 효율적인 스케줄링 알고리즘을 사용하여 l_sch를 최소화하고, 전체 inference latency를 줄임.

 

 

overall throughput : 단위 시간당 inference 시스템이 처리할 수 있는 요청의 수.

SpotServe에서의 중요성: SpotServe는 preemptible 인스턴스를 효율적으로 사용하기 위해 overall throughput을 높이는 데 노력

 

 

burst request : 짧은 시간 동안 갑자기 많은 요청이 들어오는 현상.

SpotServe에서의 처리: SpotServe는 burst request에도 안정적인 서비스를 제공할 수 있도록 동적으로 리소스를 할당하고 parallelization configuration을 조정

 

 

 

 

• l_req: End-to-end inference latency (총 inference 시간)
• l_sch: Scheduling overhead (스케줄링에 걸리는 시간)
• l_exe: Execution latency (실제 inference 계산에 걸리는 시간)

 

 

NVIDIA Triton과 같은 기존 분산 DNN 서비스 시스템은 일반적으로 여러 개의 concurrent inference pipeline을 유지 관리하며, 각 pipeline은 여러 GPU device에서 FasterTransformer와 같은 inference engine을 독립적으로 서비스합니다.

 

Inference server는 input request를 수신하고, 작은 batch로 분할하고, 이를 inference pipeline에 dispatch합니다. 각 inference pipeline의 모든 GPU는 DNN inference를 수행하고 output을 inference server로 다시 보내기 위해 협력적으로 작동합니다. 각 inference request에 대해 end-to-end inference latency 𝑙𝑟𝑒𝑞는 scheduling overhead 𝑙𝑠𝑐ℎ와 execution latency 𝑙𝑒𝑥𝑒의 두 부분으로 나뉩니다. 전자는 input request의 도착률과 inference 시스템의 peak 서비스율에 의해 결정됩니다.

 

도착률이 peak 서비스율을 초과하면 input request를 제때 처리할 수 없으므로 scheduling overhead가 증가합니다.

이 경우 inference 시스템은 overall throughput을 개선하여 서비스 기능을 향상시켜야 합니다.

 

도착률이 peak 서비스율보다 낮은 경우에도 request의 도착 간격이 균일하지 않을 수 있으므로 𝑙𝑠𝑐ℎ가 여전히 존재합니다. 이 경우 burst request는 scheduling overhead를 유발합니다.

 

그림 2에서 볼 수 있듯이 inference pipeline 내의 모든 GPU는 두 가지 범주의 병렬 패러다임을 결합하여 inference 계산을 parallelizing합니다.

 

 

그림 2. 다양한 모델 병렬 처리의 예시

 

 

용어 설명

operator : 딥러닝 모델을 구성하는 기본 연산 단위입니다. 행렬 곱셈, 활성화 함수, 정규화 등이 이에 속함.

 

stage : Pipeline model parallelism에서 연산들을 그룹화한 단계. 각 stage는 데이터 종속성을 가진 여러 operator들로 구성

 

stage overlapping : Pipeline model parallelism에서 여러 stage의 연산을 동시에 실행하는 기법. 한 stage에서 다음 stage로 데이터를 전송하는 동시에 다음 stage의 연산을 시작하여 유휴 시간을 줄임.

SpotServe에서의 활용: SpotServe는 stage overlapping을 통해 LLM inference 속도를 높임.

 

cross-stage : Pipeline model parallelism에서 서로 다른 stage 간의 통신을 의미

SpotServe에서의 활용: SpotServe는 cross-stage 통신을 효율적으로 관리하여 LLM inference 성능을 높임.

 

pipeline scheduling 메커니즘  : Pipeline model parallelism에서 stage들의 실행 순서를 결정하는 메커니즘입니다. stage overlapping, cross-stage 통신 등을 고려하여 최적의 실행 순서를 결정합니다.

SpotServe에서의 활용: SpotServe는 효율적인 pipeline scheduling 메커니즘을 사용하여 LLM inference 속도를 높입니다.

 

 

Pipeline model parallelism vs Tensor model parallelism

Pipeline Model Parallelism: 모델을 여러 stage로 나누어 각 stage를 다른 GPU에서 순차적으로 실행하는 inter-operator 병렬화 기법입니다.

Tensor Model Parallelism: 각 operator의 연산을 여러 GPU에 분산하여 병렬로 실행하는 intra-operator 병렬화 기법입니다.

SpotServe에서의 활용: SpotServe는 두 가지 병렬화 기법을 모두 사용하여 LLM inference를 효율적으로 수행합니다. Pipeline model parallelism을 통해 모델의 레이어를 여러 GPU에 분산하고, tensor model parallelism을 통해 각 레이어의 연산을 여러 GPU에 분산합니다.

 

 

 

shard 및 shard로 분할

Shard: 데이터 또는 모델의 일부분입니다.

Shard로 분할: 데이터 또는 모델을 여러 shard로 나누는 것을 의미합니다.

SpotServe에서의 활용: SpotServe는 tensor model parallelism에서 모델의 가중치를 여러 shard로 분할하여 여러 GPU에 분산

 

 

 

데이터 레이아웃 : 데이터를 메모리에 배치하는 방식입니다.

SpotServe에서의 활용: SpotServe는 tensor model parallelism에서 효율적인 데이터 레이아웃을 사용하여 통신량을 줄이고 inference 속도를 높임.

 

 

collective 통신 : 여러 GPU가 데이터를 동기화하는 통신 방식. All-Reduce 연산이 대표적인 예.

 

chain crashing 문제 : 하나의 GPU 인스턴스에 장애가 발생하면 해당 인스턴스와 연결된 다른 인스턴스들도 연쇄적으로 장애가 발생하는 문제입니다.

SpotServe에서의 해결: SpotServe는 동적 reparallelization을 통해 chain crashing 문제를 해결합니다. 장애가 발생한 인스턴스를 제외하고 남은 인스턴스들로 inference pipeline을 재구성하여 inference를 계속 수행

 

 

 

유휴 상태 : GPU가 아무런 작업도 수행하지 않고 있는 상태입니다. SpotServe에서의 최소화: SpotServe는 동적 reparallelization을 통해 유휴 상태에 있는 GPU를 최소화하고 효율적인 리소스 활용을 가능하게 합

 

 

 

 

 

Inter-operator Parallelism

Pipeline model parallelism은 가장 대표적인 inter-operator parallelism 전략으로, operator를 데이터 종속성이 있는 stage로 그룹화합니다. 그림 2a는 모델을 두 개의 stage로 분할하는 예를 보여주며 각 stage에는 절반의 연속적인 Transformer layer가 있습니다. 이러한 stage는 stage overlapping과 cross-stage 통신을 가져오는 특정 pipeline scheduling 메커니즘을 기반으로 pipeline을 형성할 수 있습니다.

 

 

Intra-operator Parallelism

Tensor model parallelism은 각 DNN operator를 device 간에 여러 shard로 분할합니다. 그림 2b에 표시된 것처럼 해당 tensor는 특정 분산 데이터 레이아웃을 기반으로 shard됩니다. 참여하는 device는 병렬로 계산하고 필요한 경우 데이터 레이아웃을 변환하기 위해 collective 통신 (즉, All-Reduce)을 수행합니다.

pipeline model parallelism의 데이터 종속성과 tensor model parallelism의 collective 통신은 자연스럽게 fault tolerance를 제공하지 않습니다. 단일 GPU 인스턴스의 선점은 잠재적으로 동일한 inference pipeline의 다른 모든 인스턴스를 중단시킬 수 있습니다. 또한 이러한 pipeline이 동일한 선점된 인스턴스에 있는 다른 GPU에서 지원되는 경우 선점으로 인해 여러 inference pipeline이 중단될 수 있습니다. 이러한 chain crashing 문제는 단일 인스턴스 선점의 영향을 자체에서 여러 pipeline으로 확대합니다. 영향을 받는 인스턴스는 물리적으로 종료되지 않지만 새 인스턴스가 할당되어 새 inference pipeline을 설정할 때까지 유휴 상태로 유지됩니다.

 

 

 

 

 

 

 

 

2.3 Preemptible LLM Inference

 

용어 설명

spot 인스턴스 : 클라우드 제공업체 (AWS, Google Cloud, Azure 등) 에서 제공하는 저렴한 가격의 가상 머신 인스턴스

 

hybrid data : 데이터 병렬 처리와 모델 병렬 처리를 결합한 방식입니다.

SpotServe에서의 활용: SpotServe는 hybrid data parallelism을 사용하여 LLM inference를 효율적으로 수행

 

 

redundancy 기반 선점 복구 메커니즘 : 동일한 작업을 여러 인스턴스에서 중복 실행하여 선점으로 인한 작업 중단을 방지하는 메커니즘입니다.

SpotServe에서의 활용: SpotServe는 redundancy 기반 선점 복구 메커니즘 대신 stateful inference recovery를 사용합니다.

 

 

request 𝑟0, request 𝑟1 :LLM inference 요청입니다.

SpotServe에서의 활용: SpotServe는 여러 요청 (𝑟0, 𝑟1 등) 을 동시에 처리하여 throughput을 높임.

 

 

inference state : LLM inference의 현재 상태입니다. Key-Value Cache, 모델 파라미터 등이 이에 속합니다.

SpotServe에서의 활용: SpotServe는 stateful inference recovery를 통해 inference state를 저장하고, 선점 발생 시 이를 복구하여 inference를 재개

 

 

request latency : LLM inference 요청을 처리하는 데 걸리는 시간입니다.

SpotServe에서의 중요성: SpotServe는 request latency를 줄이기 위해 다양한 기술을 사용

 

 

 

 

최근 연구에서는 저렴한 spot 인스턴스를 DNN 계산에 사용할 때 인스턴스 선점을 처리하는 방법에 대한 다양한 기술을 소개했습니다. 예를 들어 Varuna는 각 인스턴스 선점 후 hybrid data 및 pipeline parallel configuration을 동적으로 변경하여 training throughput을 극대화합니다. Bamboo는 다른 spot 인스턴스에서 각 인스턴스의 계산을 복제하여 pipeline parallel training에서 redundancy 기반 선점 복구 메커니즘을 사용합니다. 그러나 이러한 기술은 분산 DNN training을 위해 설계되었으며 generative LLM 서비스에는 적용되지 않습니다. 분산 LLM inference는 실제로 엄청난 새로운 수요와 함께 중요하고 시기적절한 연구 주제이기 때문에 spot 인스턴스를 통해 LLM을 서비스하는 것이 가치 있는 시도가 될 수 있음은 분명합니다. FasterTransformer와 같은 기존 LLM 서비스 시스템은 분산 LLM inference에 대한 선점 처리 기능을 제공하지 않습니다.

 

 

 

그림 1b는 preemptible 인스턴스에서 LLM을 서비스할 때 기존 시스템의 장애물을 보여줍니다. 2-way pipeline model parallelism과 2-way tensor model parallelism의 조합을 통해 4개의 인스턴스 (인스턴스당 하나의 GPU)에 배포된 하나의 분산 LLM inference pipeline의 예를 보여줍니다. Inference process는 시스템 초기화 후 시작되며 request 𝑟0에 대해 잘 진행됩니다. 그러나 request 𝑟1의 incremental decoding process 중에 GPU 1이 특정 timestamp에 선점되고 다른 세 개의 GPU는 그 동안 중지되어야 합니다. 선점으로 인해 𝑟1의 inference state (즉, KV cache)가 손실됩니다. 새 GPU 인스턴스가 시작되면 inference pipeline에 참여할 수 있으며 이러한 4개의 GPU는 𝑟1의 inference process를 다시 초기화하고 다시 시작합니다. 결과적으로 인스턴스 선점 처리로 인해 request latency가 크게 증가할 수 있습니다.

 

 

SpotServe의 효율성: SpotServe는 동적 reparallelization과 stateful inference recovery를 통해 preemption에 효과적으로 대응합니다. 선점된 GPU를 제외하고 남은 GPU들로 inference pipeline을 재구성하고, Key-Value Cache를 마이그레이션하여 inference를 계속 수행합니다. 이를 통해 request latency를 최소화하고, preemptible 인스턴스를 사용하더라도 안정적인 LLM 서비스를 제공할 수 있습니다.

 

 

 

3 SpotServe Design

 

인스턴스 선점으로 인해 증가된 request inference latency는 주로 세 가지 측면에서 나타납니다.

 

첫째, 선점이 발생하면 전체 inference pipeline이 중단되어 request waiting overhead 및/또는 추가 request scheduling overhead (즉, 다른 inference pipeline으로 rerouting)가 발생할 수 있습니다.

 

둘째, 새 인스턴스가 참여한 후에는 분산 inference engine을 시작하고 모델 매개변수를 로드하는 것과 같은 시스템 재초기화 비용이 필요합니다.

 

마지막으로 이 프로세스 전반에 걸쳐 시스템 throughput의 전반적인 감소는 잠재적으로 후속 들어오는 request의 누적을 초래하여 inference latency를 증폭시킬 수 있습니다.

 

end-to-end inference latency에 대한 이러한 문제의 영향을 완화하기 위해 SpotServe를 개발했습니다.

 

첫째, 새 인스턴스 통합으로 인한 대기 시간을 줄이기 위해 SpotServe는 on-demand 인스턴스 통합을 용이하게 하여 신속한 인스턴스 획득을 보장합니다.

 

둘째, 시스템 재초기화의 런타임 오버헤드를 줄이기 위해 SpotServe는 인스턴스 간 네트워크 링크를 활용하여 inference 진행 상황 (KV cache 형태)을 유지하고 값비싼 모델 매개변수를 다시 로드할 필요성을 없애는 효율적인 context management 메커니즘을 도입했습니다.

 

셋째, 노드 가용성 변동 중에 서비스 throughput, latency 및 비용 간의 더 나은 균형을 맞추기 위해 SpotServe는 workload를 인식하는 adaptive configuration 최적화 알고리즘을 통합합니다. 이 알고리즘은 최적의 병렬 구성을 동적으로 선택하여 실시간 동적 context 마이그레이션을 가능하게 하고 구성 전환을 원활하게 합니다.

 

 

 

 

정리 및 용어 설명

SpotServe의 adaptive configuration 최적화 알고리즘은 preemptible 인스턴스 환경에서 LLM을 효율적으로 서비스하기 위해 LLM parallelization configuration을 동적으로 조정하는 알고리즘

 

context migration : Context 정보는 LLM이 이전에 처리한 정보를 기억하고 다음 토큰을 예측하는 데 사용하는 정보입니다. Key-Value Cache, 모델 파라미터, 활성화 값 등이 이에 속합니다.

 

context daemon: context 정보를 관리하고 마이그레이션하는 역할을 담당하는 프로세스일 가능성이 높

 

SpotServe의 해결 방안

SpotServe는 위에서 언급한 문제점들을 해결하기 위해 다음과 같은 세 가지 기술을 사용합니다.

1. 빠른 인스턴스 확보: 선점으로 인한 대기 시간을 줄이기 위해 on-demand 인스턴스를 활용하여 빠르게 새로운 인스턴스를 확보합니다. 즉, preemptible 인스턴스와 on-demand 인스턴스를 함께 사용하는 hybrid 방식을 통해 비용 효율성과 안정성을 모두 확보합니다.
2. 효율적인 context 관리: 시스템 재초기화 비용을 줄이기 위해 인스턴스 간 네트워크 링크를 활용하여 KV 캐시를 새로운 GPU로 전송합니다. 이를 통해 모델 파라미터를 다시 로드하지 않고도 inference를 재개할 수 있습니다. 또한, 모든 인스턴스가 시작 시점에 모델 파라미터를 CPU 메모리에 로드하고, 새로운 GPU가 할당될 때 CPU 메모리에서 GPU RAM으로 모델 파라미터를 복사하여 재사용함으로써 모델 로딩 시간을 최소화합니다.
3. Adaptive configuration 최적화: workload 변화에 따라 LLM parallelization configuration을 동적으로 조정하여 시스템 처리량 감소 및 latency 증폭 문제를 해결합니다. workload를 인식하는 adaptive configuration 최적화 알고리즘을 통해 최적의 병렬 구성을 선택하고, 실시간 동적 context 마이그레이션을 수행하여 구성 전환을 원활하게 합니다.

 

 

1. Save

• LLM 모델은 크기가 매우 크기 때문에 (수십 GB에서 수백 GB) 효율적인 관리와 배포를 위해 클라우드 스토리지에 저장됩니다.
• SpotServe는 AWS S3, Azure Blob, GCP GCS 등 다양한 클라우드 스토리지를 지원합니다.
• 모델 개발자 또는 관리자는 학습된 LLM 모델을 클라우드 스토리지에 저장합니다.

2. Deploy

• SpotServe는 클라우드 스토리지에 저장된 LLM 모델을 Spot GPU Instance에 배포합니다.
• 즉, Spot GPU Instance가 LLM inference를 수행할 수 있도록 모델 파일을 다운로드하고, 필요한 환경을 설정합니다.
• SpotServe는 인스턴스 시작 시 또는 런타임에 동적으로 모델을 배포할 수 있습니다.

전체 과정을 순서대로 설명하면,

1. 모델 학습: LLM 모델을 학습하고 저장합니다.
2. Save: 학습된 모델을 클라우드 스토리지에 저장합니다.
3. SpotServe 설정: SpotServe를 설정하고, 서비스할 LLM 모델을 지정합니다.
4. Deploy: SpotServe는 클라우드 스토리지에서 LLM 모델을 다운로드하고 Spot GPU Instance에 배포합니다.
5. Inference: SpotServe는 배포된 모델을 사용하여 inference 요청을 처리합니다.

 

1. Application

• 사용자가 LLM을 이용하는 애플리케이션입니다.
• 예를 들어, 챗봇, 번역기, 요약 도구 등이 있습니다.
• 애플리케이션은 SpotServe에 inference 요청(input request)을 보내고, SpotServe는 LLM을 사용하여 결과(output response)를 생성하여 애플리케이션에 반환합니다.

2. LLM Model

• SpotServe가 서비스하는 LLM 모델입니다.
• 예를 들어, GPT-3, LLaMA, OPT 등이 있습니다.
• 모델은 클라우드 스토리지(Cloud Storage)에 저장되어 있으며, SpotServe는 필요에 따라 모델을 로드하여 사용합니다.

3. Cloud VM Instance

• LLM inference를 실행하기 위한 클라우드 가상 머신 인스턴스입니다.
• SpotServe는 AWS, Azure, GCP 등 다양한 클라우드 플랫폼을 지원합니다.
• SpotServe는 비용 절감을 위해 preemptible 인스턴스 (spot instance) 를 주로 사용하며, 필요에 따라 on-demand 인스턴스를 사용하기도 합니다.

4. Inference Server

• SpotServe의 핵심 구성 요소로, LLM inference 요청을 관리하고 처리하는 역할을 합니다.
• Inference Server는 다음과 같은 세 가지 주요 컴포넌트로 구성됩니다.
  • Request Manager: 애플리케이션에서 들어오는 inference 요청을 받아서 관리합니다. 요청을 큐에 저장하고, 적절한 inference pipeline에 할당합니다.
  • Meta-context Manager: LLM inference의 context 정보 (KV 캐시 등) 를 관리합니다. Context migration을 수행하고, context 정보를 안전하게 저장하고 로드합니다.
  • Instance Manager: preemptible 인스턴스와 on-demand 인스턴스를 관리합니다. 인스턴스 생성, 삭제, 선점 감지, GPU 할당 등을 수행합니다.

5. Parallelization Controller

• LLM parallelization configuration을 동적으로 조정하는 역할을 합니다.
• preemptible 인스턴스의 가용성 변화와 workload 변화에 따라 최적의 병렬 구성을 선택합니다.

6. Device Mapper

• 사용 가능한 GPU를 LLM parallelization configuration에 매핑하는 역할을 합니다.
• Kuhn-Munkres 알고리즘을 사용하여 최적의 GPU 매핑을 찾고, context migration 비용을 최소화합니다.

7. Migration Planner

• Context migration 계획을 수립하고 실행하는 역할을 합니다.
• 어떤 context 정보를 어떤 GPU로 옮길지, 어떤 순서로 마이그레이션할지 결정합니다.

8. Inference Engine

• LLM inference를 실제로 수행하는 엔진입니다.
• NVIDIA CUDA를 사용하여 GPU에서 LLM 연산을 가속화합니다.
• FasterTransformer와 같은 최적화된 inference 라이브러리를 사용할 수 있습니다.

9. Context Daemon

• Context 정보를 관리하고 마이그레이션하는 역할을 합니다.
• 선점 감지를 수행하고, context 정보를 안전하게 저장하고 로드합니다.

10. Interruption Arranger

• preemptible 인스턴스의 선점으로 인한 inference 중단을 처리하는 역할을 합니다.
• 선점 발생 시 context migration을 수행하고, inference engine이 새로운 GPU에서 작업을 재개할 수 있도록 합니다.

11. Spot GPU Instance

• LLM inference를 실행하는 preemptible GPU 인스턴스입니다.
• 여러 개의 Spot GPU Instance가 협력하여 하나의 LLM inference를 수행합니다.

전체 흐름

1. 애플리케이션에서 inference 요청을 Inference Server로 보냅니다.
2. Request Manager는 요청을 큐에 저장하고, Parallelization Controller는 현재 상황에 맞는 최적의 LLM parallelization configuration을 선택합니다.
3. Device Mapper는 사용 가능한 GPU를 선택된 configuration에 매핑하고, Migration Planner는 context migration 계획을 수립합니다.
4. Inference Engine은 GPU에서 LLM inference를 수행합니다.
5. preemptible 인스턴스 선점이 발생하면 Interruption Arranger는 context migration을 수행하고, inference engine은 새로운 GPU에서 inference를 재개합니다.
6. Inference Engine은 결과를 생성하여 Inference Server로 보내고, Inference Server는 결과를 애플리케이션에 반환합니다.

이처럼 SpotServe는 다양한 컴포넌트들이 협력하여 preemptible 인스턴스 환경에서 LLM을 효율적이고 안정적으로 서비스합니다.

 

 

이 알고리즘은 preemptible 인스턴스 환경에서 LLM inference를 효율적으로 수행하기 위해 상황에 맞춰 최적의 GPU 구성을 동적으로 선택하는 역할을 합니다. 마치 교통 상황에 따라 내비게이션 앱이 최적의 경로를 실시간으로 업데이트하는 것과 비슷합니다.

알고리즘 작동 방식

1. 입력:
   • Nt: 현재 사용 가능한 GPU 인스턴스 수
   • Ct: 현재 LLM parallelization configuration (GPU 구성 방식)
   • αt: 목표 throughput (단위 시간당 처리할 수 있는 요청 수)
2. 조건 확인:
   • ∃𝐶.𝜙(𝐶) ≥ αt and cloud has enough instances for C: 목표 throughput을 달성하면서 현재 클라우드 환경에서 사용 가능한 GPU 구성 (C) 이 존재하는지 확인합니다.
3. Configuration 선택:
   • 조건 만족 시: 목표 throughput을 달성하는 구성 중에서 inference latency (lreq(C)) 가 가장 낮은 구성 (Ct+1) 을 선택합니다. (3번째 줄)
   • 조건 불만족 시: 현재 사용 가능한 GPU 인스턴스 수 (Nt) 에서 최대 throughput (𝜙(C)) 을 달성하는 구성 (Ct+1) 을 선택합니다. (5번째 줄)
4. 인스턴스 조정:
   • Δ: 새로운 구성 (Ct+1) 에 필요한 인스턴스 수와 현재 인스턴스 수 (Nt) 의 차이를 계산합니다. (6번째 줄)
   • Δ > 0: 인스턴스가 더 필요한 경우, Δ 만큼의 인스턴스를 추가합니다. 이때 on-demand 인스턴스와 spot 인스턴스를 함께 사용합니다. (8번째 줄)
   • Δ < 0: 인스턴스가 남는 경우, Δ 만큼의 인스턴스를 삭제합니다. 이때 on-demand 인스턴스를 우선적으로 삭제합니다. (10번째 줄)
5. Configuration 업데이트:
   • ConfigUpdate(Ct, Ct+1): 새로운 구성 (Ct+1) 을 적용하고, context migration 등 필요한 작업을 수행합니다. (11번째 줄)

쉽게 풀어서 설명하면,

• SpotServe는 현재 상황 (사용 가능한 GPU 수, workload) 과 목표 throughput을 고려하여 최적의 GPU 구성을 선택합니다.
• 만약 목표 throughput을 달성할 수 있는 GPU 구성이 여러 개 있다면, inference latency가 가장 낮은 구성을 선택합니다.
• 만약 목표 throughput을 달성할 수 없다면, 현재 GPU 환경에서 최대 throughput을 낼 수 있는 구성을 선택합니다.
• 새로운 GPU 구성에 따라 인스턴스를 추가하거나 삭제하고, context migration을 수행하여 inference를 계속 이어갑니다.

이 알고리즘 덕분에 SpotServe는 preemptible 인스턴스 환경에서도 효율적이고 안정적인 LLM 서비스를 제공할 수 있습니다.

• preemptible 인스턴스의 가용성 변화에 유연하게 대응하고,
• workload 변화에 따라 GPU 구성을 최적화하며,
• 비용 효율성을 유지하면서도 높은 성능을 달성합니다.

 

3.1 System Overview

 

그림 3은 SpotServe의 개요를 보여줍니다. Inference server는 dedicated on-demand CPU 인스턴스에 배포되고 request manager, meta-context manager 및 instance manager를 호스팅합니다. Request manager는 input request를 수신하고, 동적으로 batch로 분할하고, 이러한 batch를 spot GPU 인스턴스에서 실행되는 inference 인스턴스에 할당하고, 궁극적으로 inference 인스턴스에서 생성된 output을 수집하여 결과를 사용자에게 다시 보내는 역할을 합니다. Instance manager는 클라우드와 상호 작용하고 인스턴스 선점/획득 알림을 수신합니다.

 

SpotServe의 inference engine은 각 spot 또는 on-demand GPU 인스턴스에 배포되어 LLM inference를 서비스합니다. 각 inference engine에는 특정 GPU 내에서 여러 request에 대한 모델 매개변수 (즉, model context)와 중간 활성화 (즉, cache context)를 관리하는 context daemon이 포함됩니다.

 

Inference engine은 context daemon에서 제공하는 proxy를 통해 이러한 context 정보에 액세스할 수 있습니다. 종속 인스턴스의 선점으로 인해 inference engine이 중단되어야 하는 경우 context daemon process는 여전히 활성 상태이며 inference를 다시 시작할 때 context를 GPU로 다시 로드하지 않습니다.

 

시스템의 서비스 기능이 workload와 호환되지 않거나 곧 호환되지 않게 되면 meta-context manager는 모든 GPU 인스턴스에 context 마이그레이션 지침을 보내 병렬 구성 조정을 관리합니다. 새 구성은 parallelization controller에서 제안하고 device mapper 및 migration planner에서 구체화합니다. 또한 각 inference engine은 interruption arranger를 시작하여 더 낮은 inference latency를 위해 stateful inference recovery를 지원합니다.

 

이 논문의 나머지 부분에서는 먼저 §3.2의 parallelization controller, §3.3의 device mapper, §3.4의 migration planner, §4의 interruption arranger를 포함한 SpotServe의 디자인을 소개합니다. 마지막으로 §5에서 SpotServe의 구현을 소개하고 §6에서 성능을 평가합니다.

 

 

SpotServe의 전체적인 구조와 작동 방식을 3.1 System Overview를 바탕으로 쉽게 설명해 드릴게요! 😊

SpotServe는 크게 세 부분으로 나눌 수 있습니다.

1. Inference Server: 모든 LLM inference 작업을 관리하고 제어하는 핵심적인 부분입니다. on-demand CPU 인스턴스에서 실행됩니다.
2. Inference Engine: 실제로 LLM inference를 수행하는 엔진입니다. spot GPU 인스턴스 또는 on-demand GPU 인스턴스에서 실행됩니다.
3. Context Daemon: inference engine 내에서 context 정보 (모델 파라미터, 중간 활성화 값) 를 관리하는 프로세스입니다.

SpotServe의 작동 방식

1. 사용자의 요청: 사용자가 애플리케이션 (챗봇, 번역기 등) 을 통해 LLM inference를 요청합니다.
2. Inference Server: inference server는 요청을 받아서 적절한 inference engine에 할당합니다.
3. Inference Engine: inference engine은 GPU를 사용하여 LLM inference를 수행합니다.
4. Context Daemon: context daemon은 inference engine이 필요로 하는 context 정보를 제공하고 관리합니다.
5. 결과 반환: inference engine은 inference 결과를 생성하여 inference server로 보내고, inference server는 결과를 사용자에게 반환합니다.

SpotServe의 특징

• Preemptible 인스턴스 활용: 비용 절감을 위해 spot GPU 인스턴스를 사용합니다.
• 선점 대응: spot 인스턴스가 회수되더라도 context daemon이 context 정보를 유지하고, 새로운 GPU에 빠르게 inference 작업을 이전하여 inference 중단을 최소화합니다.
• 동적 구성: workload 변화에 따라 LLM parallelization configuration을 동적으로 조정하여 효율적인 inference를 수행합니다.
• Hybrid 방식: 평소에는 저렴한 spot 인스턴스를 사용하고, 필요에 따라 on-demand 인스턴스를 사용하여 안정성을 확보합니다.

 

 

Figure 4a는 SpotServe가 유예 기간 내에 context 마이그레이션을 통해 parallel configuration을 (1, 2, 8)에서 (1, 3, 4)로 변경하고 request 𝑟3의 이전 디코딩 진행 상황을 계속하는 예를 보여줍니다.

Figure 4b는 6개의 사용 가능한 인스턴스 (즉, 𝑢0 ~ 𝑢5)와 새 구성 (2, 3, 1)의 토폴로지 위치 간의 이분 그래프 예를 보여줍니다. 여기서는 𝑢1에서 시작하는 가중치 edge만 그립니다.

 

 

 

3.2 Parallelization Controller

 

SpotServe는 여러 GPU 인스턴스에서 LLM 서비스를 병렬화하는 전략을 식별하기 위해 parallel configuration을 사용합니다. Parallel configuration은 튜플 𝐶 = (𝐷, 𝑃, 𝑀, 𝐵)로 표현됩니다. 여기서 𝐷, 𝑃 및 𝑀은 data, pipeline-model 및 tensor-model parallelism degree를 나타내고 𝐵는 최대 mini-batch 크기입니다. SpotServe와 기존 spot 인스턴스 서비스 시스템의 주요 차이점은 SpotServe가 인스턴스 선점 및 획득을 처리하기 위해 클라우드에서 제공하는 ahead-of-time 알림을 활용하여 parallel configuration을 사전에 조정할 수 있다는 것입니다. 각 선점 및 획득 알림에 대해 SpotServe의 parallelization controller는 LLM 서비스 성능을 향상시키기 위해 기회주의적으로 parallel configuration을 조정합니다. 이러한 reparallelization 메커니즘은 이전 접근 방식에서 광범위하게 연구된 변동하는 inference workload에도 적응할 수 있습니다.

Spot 인스턴스의 유예 기간. 최신 클라우드는 일반적으로 spot 인스턴스가 인스턴스를 선점하기 전에 실행 중인 작업을 완료할 수 있도록 유예 기간 (예: Azure에서 30초)을 제공합니다. 새 인스턴스를 할당하는 데는 유예 기간이 없지만 inference engine을 초기화하는 데에도 짧은 시간 (예: 평가에서 시작 및 초기화하는 데 2분)이 걸립니다. 이는 사전에 측정하여 SpotServe에서 획득 유예 기간으로 처리할 수 있습니다.

Adaptive configuration optimizer. SpotServe는 throughput, latency 및 비용 간의 trade-off의 균형을 맞추기 위해 adaptive optimization 알고리즘을 사용합니다. 시간 단계 𝑡에서 parallel configuration과 사용 가능한 인스턴스 수를 나타내기 위해 두 개의 time-varying 변수 𝐶𝑡와 𝑁𝑡를 사용합니다. 𝑁𝑡는 새로 할당된 인스턴스를 포함하고 선점될 인스턴스를 제외하는 유예 기간의 인스턴스를 고려합니다. 병렬 구성 𝐶을 사용한 서비스 throughput을 𝜙(𝐶)로, 시간 단계 𝑡에서 request 도착률을 𝛼𝑡라고 하겠습니다. 알고리즘 1은 optimizer의 workflow를 보여줍니다. optimizer는 주로 인스턴스 가용성 또는 서비스 workload의 변화로 인해 현재 서비스 기능이 𝛼𝑡와 호환되지 않을 때 작동합니다.

 

전반적으로 optimizer는 𝛼𝑡보다 높은 throughput을 유지하면서 end-to-end inference latency 𝑙𝑟𝑒𝑞(𝐶)를 최소화합니다 (3행). 특히 유사한 최소 inference latency를 달성할 수 있는 구성이 여러 개 있는 경우 SpotServe는 더 낮은 비용 (즉, 더 적은 인스턴스 사용)의 구성을 선택합니다. 𝑙𝑟𝑒𝑞(𝐶)를 최소화하는 것 외에도 사전 정의된 SLO (즉, 𝑙𝑟𝑒𝑞(𝐶) ≤ 𝑙𝑆𝐿𝑂)의 요구 사항을 충족하는 것과 같은 다른 목표도 가능합니다. SpotServe의 peak 서비스 throughput이 request 도착률 𝛼𝑡를 초과할 수 없는 경우 (즉, 𝐶.𝜙(𝐶) ≥ 𝛼𝑡), SpotServe는 overall 서비스 throughput을 극대화하기 위해 parallel configuration을 업데이트합니다 (5행). 제안된 구성 𝐶𝑡+1에는 이전보다 더 많거나 적은 인스턴스가 필요할 수 있습니다 (6행). Spot 인스턴스 할당이 항상 성공하는 것은 아니므로 SpotServe는 서비스 throughput을 더욱 향상시키기 위해 선택적으로 on-demand 인스턴스를 할당할 수 있도록 지원합니다. 특히 instance manager는 spot 인스턴스 할당이 실패할 때 대기 오버헤드를 방지하기 위해 동시에 on-demand 및 spot 인스턴스를 할당합니다 (8행). 또한 instance manager는 할당된 인스턴스를 해제 (10행)하여 over-provision을 완화하는 책임이 있습니다. 여기서 on-demand 인스턴스는 비용 때문에 더 높은 우선 순위를 갖습니다. 인스턴스 가용성의 빈번한 방해의 영향을 완화하기 위해 SpotServe는 종종 더 부드러운 인스턴스 대체를 위한 후보 풀로 몇 가지 추가 인스턴스 (예: §6 실험에서 2개)를 유지합니다.

마지막으로 SpotServe는 parallel configuration을 업데이트합니다 (11행). interruption arranger (§4)는 특히 인스턴스 가용성 변경으로 인해 트리거된 경우 reparallelization을 완료할 시기를 결정합니다. 인스턴스 선점 및 획득은 인스턴스의 멤버십을 업데이트하기 때문에 𝐶𝑡+1 = 𝐶𝑡인 경우에도 이 단계가 여전히 필요합니다.

 

Optimizer는 온라인으로 실행되며 여러 구성의 latency 추정이 사전에 오프라인에서 수행되기 때문에 오버헤드가 무시할 수 있습니다 (즉, 1초 미만). SpotServe의 구성 탐색 공간은 data 및 pipeline parallelism만 고려하는 Varuna와 같은 이전 접근 방식보다 훨씬 큽니다. 또한 SpotServe를 더 복잡한 model parallelism으로 확장할 수도 있습니다. 이는 향후 작업으로 남겨둡니다.

 

3.2 Parallelization Controller 요약 및 설명

SpotServe의 Parallelization Controller는 preemptible 인스턴스 환경에서 LLM inference를 효율적으로 수행하기 위해 LLM 병렬화 구성(parallel configuration)을 동적으로 조정하는 핵심 컴포넌트입니다. 마치 교통 상황에 따라 내비게이션 앱이 최적의 경로를 실시간으로 업데이트하는 것처럼, Parallelization Controller는 preemptible 인스턴스의 가용성 변화와 workload 변화에 따라 LLM 실행 방식을 재구성합니다.

Parallelization Controller의 주요 기능

1. Parallel Configuration:
   • LLM을 여러 GPU에서 병렬로 실행하기 위한 설정을 정의합니다.
   • 데이터 병렬성(Data Parallelism), 파이프라인 모델 병렬성(Pipeline Model Parallelism), 텐서 모델 병렬성(Tensor Model Parallelism) 등의 조합을 사용합니다.
   • C = (D, P, M, B) 튜플로 표현됩니다. (D: 데이터 병렬성, P: 파이프라인 모델 병렬성, M: 텐서 모델 병렬성, B: 최대 미니 배치 크기)
2. 선점 및 획득 알림:
   • 클라우드 제공업체로부터 preemptible 인스턴스의 선점 및 획득 알림을 수신합니다.
   • 이러한 알림을 통해 인스턴스 가용성 변화를 감지하고, proactive하게 parallel configuration을 조정합니다.
3. Adaptive Configuration Optimizer:
   • throughput, latency, 비용 간의 균형을 맞추기 위해 adaptive optimization 알고리즘을 사용합니다.
   • 현재 사용 가능한 인스턴스 수 (Nt), 현재 parallel configuration (Ct), 목표 throughput (αt) 을 입력으로 받습니다.
   • 목표 throughput을 달성하면서 latency를 최소화하는 최적의 configuration (Ct+1) 을 선택합니다.
   • 필요에 따라 on-demand 인스턴스와 spot 인스턴스를 적절히 조합하여 사용합니다.
   • 새 configuration에 따라 인스턴스를 추가하거나 삭제하고, context migration을 수행합니다.
4. Configuration 탐색 공간:
   • SpotServe는 data parallelism과 pipeline parallelism뿐만 아니라 tensor model parallelism까지 고려하여 더 넓은 configuration 탐색 공간을 갖습니다.
   • 이는 Varuna와 같은 기존 시스템보다 더욱 유연하고 효율적인 LLM parallelization을 가능하게 합니다.

Parallelization Controller의 장점

• Preemptible 인스턴스 환경 적응: preemptible 인스턴스의 불안정성에도 불구하고 안정적인 LLM 서비스를 제공합니다.
• Workload 변화 대응: 다양한 workload에 유연하게 대응하여 최적의 성능을 유지합니다.
• 비용 효율성: preemptible 인스턴스를 효율적으로 활용하여 LLM inference 비용을 절감합니다.
• Latency 최소화: 최적의 configuration을 통해 inference latency를 최소화합니다.
• Throughput 극대화: 최적의 configuration을 통해 throughput을 극대화합니다.

SpotServe는 Parallelization Controller를 통해 preemptible 인스턴스 환경에서 LLM을 효율적이고 안정적으로 서비스합니다. 끊임없이 변화하는 환경에 맞춰 LLM 실행 방식을 최적화함으로써, 비용 효율성을 유지하면서도 높은 성능과 안정성을 제공합니다.

 

3.3 Device Mapper

 

 

 

 

 

목표 구성 𝐶𝑡+1이 주어지면 인스턴스를 마이그레이션하는 간단한 방법은 현재 인스턴스에서 inference engine을 다시 시작하고 사용 가능한 모든 GPU 인스턴스를 처음부터 다시 초기화하는 것입니다. 그러나 이 방법은 기존 GPU 인스턴스에서 사용 가능한 모델 매개변수와 KV 캐시를 재사용할 수 있는 기회를 활용하지 않으므로 불필요한 마이그레이션 비용과 inference 지연이 발생합니다. 그림 4a에 표시된 것처럼 이러한 context를 파괴하고 다시 빌드하는 대신 SpotServe는 더 가벼운 context 마이그레이션 메커니즘을 채택하고 중단된 request의 inference를 재개할 수 있습니다. GPU 인스턴스 간에 이러한 context 정보를 마이그레이션하면 latency가 증가할 수도 있으므로 SpotServe가 해결해야 하는 주요 과제는 이전 context를 기회주의적으로 재사용하기 위해 사용 가능한 GPU 인스턴스를 새 병렬 구성에서 식별된 논리적 device mesh에 매핑하는 것입니다. 배치 크기를 무시하고 (𝐷, 𝑃, 𝑀)을 사용하여 병렬 구성을 나타냅니다. 여기서 𝐷, 𝑃 및 𝑀은 data, pipeline model 및 tensor model parallelism degree를 나타냅니다. SpotServe는 각 GPU 인스턴스를 pipeline-stage-shard 토폴로지 위치 (𝑑, 𝑝, 𝑚)에 바인딩합니다. 이는 𝑑번째 pipeline (1 ≤ 𝑑 ≤ 𝐷)의 𝑝번째 stage (1 ≤ 𝑝 ≤ 𝑃)의 𝑚번째 shard (1 ≤ 𝑚 ≤ 𝑀)를 나타냅니다.

 

여러 병렬 구성 간에 전환하기 위해 SpotServe는 device 매핑을 이분 그래프 매칭 문제로 공식화하고 Kuhn-Munkres (KM) 알고리즘을 사용하여 context 마이그레이션 중에 총 데이터 전송을 최소화하는 최적의 device 매핑을 찾습니다.

 

이분 그래프 매칭. SpotServe는 이분 그래프 𝒢 = (𝒱𝑎, 𝒱𝑡, ℰ)를 사용하여 device 매핑을 설명합니다. 여기서 각 노드 𝑢 ∈ 𝒱𝑎는 GPU device이고, 각 노드 𝑣 ∈ 𝒱𝑡는 병렬 구성의 pipeline-stage-shard 위치를 나타내며, 가중치 edge 𝑒𝑢𝑣 (𝑢 ∈ 𝒱𝑎, 𝑣 ∈ 𝒱𝑡)는 GPU 𝑢를 병렬 구성의 위치 𝑣에 매핑할 때 재사용 가능한 모델 매개변수와 key/value 캐시의 양을 나타냅니다. 그림 4b에 표시된 것처럼 각 GPU의 context daemon의 현재 상태 (즉, (𝐷 = 2, 𝑃 = 2, 𝑀 = 2)로 구성됨)와 목표 병렬 구성 (𝐷 = 2, 𝑃 = 3, 𝑀 = 1)이 주어지면 SpotServe는 완전한 이분 그래프를 빌드하고 교차 context의 크기를 사용하여 모든 (𝑢, 𝑣) 쌍 간의 edge 가중치를 계산합니다. 예를 들어 𝑢1은 첫 번째 pipeline의 첫 번째 stage의 절반 shard context를 보유하고 새 pipeline의 첫 번째 stage를 담당하기 때문에 𝑣0 및 𝑣3과 대부분의 model context가 겹칩니다. 새 pipeline 0'이 pipeline 0에서 중단된 inference request를 상속한다고 가정하면 재사용할 캐시 context가 더 많으므로 𝑢1을 𝑣0과 일치시키는 것을 선호할 수 있습니다. SpotServe는 최적의 device 매핑 문제를 이분 그래프 매칭 작업으로 변환하고 KM 알고리즘을 사용하여 최대 가중치 일치를 찾습니다. 이는 사용 가능한 GPU 인스턴스에서 모델 매개변수와 KV 캐시를 최대한 재사용하고 총 데이터 전송을 최소화합니다.

 

SpotServe는 또한 각 인스턴스에 GPU 간 대역폭이 더 높은 (예: NVLink) 여러 GPU가 있는 경우를 고려합니다. 최적의 솔루션을 찾기 위해 2단계 매칭 (즉, 인스턴스 내 및 인스턴스 간)을 수행하여 계층적 아키텍처를 용이하게 합니다. 자세한 내용은 보충 자료에서 확인할 수 있습니다.

 

새 병렬 구성 𝐶𝑡+1이 원래 구성 𝐶𝑡보다 더 적은 concurrent inference request를 처리하는 경우 (즉, 𝐷𝑡 ×𝐵𝑡 ≥ 𝐷𝑡+1×𝐵𝑡+1), SpotServe는 새 병렬 구성의 메모리 용량을 초과하지 않도록 캐시된 결과의 일부를 삭제합니다. 재계산 비용을 최소화하기 위해 SpotServe는 디코딩 진행 상황 (즉, iteration)이 더 많은 request batch를 유지합니다.

 

 

 

 

가중치 계산 방법

1. 교차 context 크기 측정: 각 GPU 인스턴스와 각 역할 간에 공유하는 모델 파라미터와 Key/Value 캐시의 크기를 측정합니다. 즉, GPU 인스턴스가 가지고 있는 context 정보와 새로운 역할에서 필요로 하는 context 정보의 교집합 크기를 계산합니다.
2. 가중치 계산: 교차 context 크기를 기반으로 가중치를 계산합니다. 교차 context 크기가 클수록 가중치가 높아집니다. 즉, GPU 인스턴스가 새로운 역할에서 필요로 하는 context 정보를 많이 가지고 있을수록 가중치가 높아집니다.

예시

• GPU 인스턴스 u1은 첫 번째 pipeline의 첫 번째 stage의 절반 shard context를 가지고 있습니다.
• 역할 v0과 v3은 새 pipeline의 첫 번째 stage를 담당합니다.
• u1은 v0과 v3 모두와 model context가 겹치지만, v0과 더 많은 cache context를 공유합니다.
• 따라서 u1과 v0 간의 가중치가 u1과 v3 간의 가중치보다 높습니다.

 

3.3 Device Mapper 쉽게 설명하기

SpotServe의 Device Mapper는 마치 퍼즐 조각 맞추기와 같습니다.

• 퍼즐 조각: 사용 가능한 GPU 인스턴스들
• 퍼즐 판: 새로운 병렬 구성 (parallel configuration) 에 따른 GPU 배치

Device Mapper는 퍼즐 조각 (GPU 인스턴스) 들을 퍼즐 판 (새로운 GPU 배치) 에 가장 효율적으로 맞추는 방법을 찾습니다. 퍼즐 조각을 함부로 끼워 넣으면 (무작위로 GPU를 할당하면) 퍼즐이 완성되지 않거나 (LLM inference가 제대로 실행되지 않거나), 시간이 오래 걸릴 수 있습니다 (inference 속도가 느려질 수 있습니다).

Device Mapper가 하는 일

1. GPU 인스턴스 정보 파악: 현재 사용 가능한 GPU 인스턴스들의 상태를 파악합니다. 각 인스턴스가 어떤 모델 파라미터와 KV 캐시를 가지고 있는지 확인합니다.
2. 새로운 GPU 배치: 새로운 병렬 구성에 따라 GPU를 어떻게 배치해야 하는지 결정합니다.
3. 최적의 매핑: GPU 인스턴스들을 새로운 GPU 배치에 가장 효율적으로 매핑하는 방법을 찾습니다. 이때 Kuhn-Munkres 알고리즘이라는 최적화 알고리즘을 사용합니다.
4. Context Migration: 최적의 매핑에 따라 필요한 context 정보 (모델 파라미터, KV 캐시) 를 GPU 간에 이동시킵니다.

Device Mapper의 목표

• Context 재사용 극대화: 이미 GPU에 로드되어 있는 모델 파라미터와 KV 캐시를 최대한 재사용하여 불필요한 데이터 전송을 줄입니다.
• Context Migration 비용 최소화: context 정보를 이동시키는 데 드는 시간과 비용을 최소화합니다.
• 빠른 inference 재개: GPU 선점으로 인해 inference가 중단되더라도 빠르게 새로운 GPU에서 inference를 재개할 수 있도록 합니다.

Device Mapper의 효과

• Inference 속도 향상: 불필요한 모델 로딩을 방지하고, context migration 시간을 줄여 inference 속도를 높입니다.
• 비용 절감: 데이터 전송량을 줄여 네트워크 비용을 절감합니다.
• 안정적인 LLM 서비스: preemptible 인스턴스 환경에서 LLM inference를 안정적으로 수행할 수 있도록 합니다.

비유를 다시 사용하여 설명하면,

• Device Mapper: 퍼즐 조각을 맞추는 퍼즐 전문가
• GPU 인스턴스: 퍼즐 조각
• 새로운 GPU 배치: 완성된 퍼즐 그림
• Context 정보: 퍼즐 조각의 모양과 색깔

퍼즐 전문가는 퍼즐 조각들을 보고 가장 효율적으로 퍼즐을 맞추는 방법을 알고 있습니다. 마찬가지로 Device Mapper는 GPU 인스턴스들의 상태를 파악하고, 최적의 매핑을 통해 빠르고 효율적으로 LLM inference를 수행할 수 있도록 합니다.

 

 

 

 

3.4 Migration Planner

사용 가능한 device를 논리적 병렬 위치에 매핑한 후 다음 과제는 구성 조정을 완료하기 위한 정확한 마이그레이션 계획을 결정하는 것입니다. Naive한 접근 방식은 모든 인스턴스가 default tensor 전송 순서를 따르고 모든 인스턴스의 context가 성공적으로 전송될 때까지 기다리도록 하는 것입니다. 이 솔루션에는 주로 두 가지 단점이 있습니다.

 

한 가지 문제는 모든 context를 보내는 데 특히 대규모 모델의 경우 시간이 오래 걸릴 수 있다는 것입니다. Context 마이그레이션 오버헤드를 줄이기 위해 pipeline 구조를 활용하고 front model layer의 context 마이그레이션을 우선시하는 progressive 마이그레이션 schedule을 제안합니다. 그러면 front pipeline stage의 인스턴스가 서비스를 시작할 수 있으며 잠재적으로 다음 stage의 마이그레이션과 겹칠 수 있습니다. 이상적으로 context 마이그레이션 오버헤드는 단일 stage의 context 전송 비용으로 줄일 수 있습니다. 또한 interruption fault-tolerance를 고려하여 모든 layer의 캐시 context 전송을 우선시합니다. 최대 overlapping을 달성하지는 못하지만 디코딩 진행 상황이 손실될 가능성을 최소화할 수 있습니다.

 

또 다른 문제는 context 통신을 위한 buffer 공간의 메모리 소비입니다. 모든 context tensor의 마이그레이션은 런타임 메모리 사용량을 변경합니다. 특히 sender의 메모리는 해제할 수 있지만 receiver의 메모리 소비는 증가합니다. 부적절한 마이그레이션 계획은 peak 메모리 사용량을 크게 증가시키고 latency가 더 높은 최적이 아닌 inference 구성 (예: 모델을 더 많은 stage로 분할)으로 이어질 수 있습니다. 메모리 효율적인 마이그레이션 계획을 제공하기 위해 progressive 마이그레이션 프로세스 중에 메모리 사용량을 고려하는 것을 제안합니다. 알고리즘 2에 표시된 것처럼 layer index의 순차적 순서 (12행)로 naive 계획에서 시작하여 각 layer의 context 마이그레이션을 적용하고 (13행) 각 인스턴스의 buffer 메모리 사용량을 추적합니다 (14행). 알고리즘에는 모든 인스턴스에 대한 buffer 메모리 소비의 최대 threshold를 나타내는 default hyperparameter 𝑈𝑚𝑎𝑥가 필요합니다. 먼저 context 마이그레이션이 buffer 메모리 상한을 초과할 수 있는 layer를 건너뜁니다 (17행). 그런 다음 min-max 문제를 해결하여 나머지 layer의 순서를 생성합니다 (19행). 특히 context 마이그레이션이 최대 인스턴스 buffer 메모리 사용량을 최소화할 수 있는 layer를 선택하는 것을 선호합니다. 이러한 방식으로 결합된 layer context 마이그레이션 순서는 메모리 소비가 적으며 최종 마이그레이션 계획을 생성하는 데 사용할 수 있습니다 (3행).

 

 

Migration Planner의 역할

• SpotServe에서 Device Mapper가 GPU 인스턴스와 새로운 역할을 매칭하면, Migration Planner는 context 정보 (모델 파라미터, KV 캐시) 를 GPU 간에 이동시키는 계획을 수립하고 실행합니다.
• 효율적인 context migration을 통해 GPU 선점으로 인한 inference 중단을 최소화하고, 빠르게 inference를 재개할 수 있도록 돕습니다.

Migration Planner의 주요 기능

1. Progressive 마이그레이션: 모든 context 정보를 한꺼번에 이동시키는 대신, 단계적으로 이동시킵니다.
   • 먼저 앞쪽 레이어의 context 정보를 우선적으로 이동시켜 front pipeline stage의 인스턴스가 먼저 서비스를 시작할 수 있도록 합니다.
   • 이후 stage의 context 정보는 inference와 동시에 이동시켜 시간을 절약합니다.
2. Cache context 우선순위: 모든 레이어의 cache context를 우선적으로 이동시켜 선점으로 인한 디코딩 진행 상황 손실을 최소화합니다.
3. 메모리 사용량 관리: context migration 과정에서 buffer 메모리 사용량을 고려하여 메모리 부족 현상을 방지합니다.
   • 각 인스턴스의 buffer 메모리 사용량이 설정된 threshold를 초과하지 않도록 migration 순서를 조정합니다.
   • min-max 문제를 해결하여 최대 인스턴스 buffer 메모리 사용량을 최소화하는 layer의 context를 우선적으로 이동시킵니다.
4. 최적화된 마이그레이션 계획: 위에서 설명한 요소들을 고려하여 가장 효율적인 context migration 계획을 생성합니다.

Migration Planner의 효과

• 빠른 inference 재개: 빠른 context migration을 통해 GPU 선점으로 인한 inference 중단 시간을 최소화하고, 신속하게 inference를 재개할 수 있도록 합니다.
• 메모리 효율: context migration 과정에서 메모리 사용량을 효율적으로 관리하여 메모리 부족 현상을 방지합니다.
• 안정적인 마이그레이션: context 정보가 손실되지 않도록 안정적으로 마이그레이션합니다.

결론

Migration Planner는 SpotServe에서 context migration을 효율적으로 수행하고, preemptible 인스턴스 환경에서 LLM inference를 안정적으로 수행하는 데 중요한 역할을 합니다.

 

 

 

 

 

3전체 정리

3. SpotServe Design 쉽고 깔끔하게 정리

SpotServe는 preemptible 인스턴스를 사용하여 LLM inference를 효율적으로 수행하는 시스템입니다. preemptible 인스턴스는 저렴하지만 언제든 회수될 수 있다는 단점이 있는데, SpotServe는 이러한 단점을 극복하고 안정적인 서비스를 제공하기 위해 다음과 같은 세 가지 핵심 기술을 사용합니다.

1. 빠른 인스턴스 확보

• preemptible 인스턴스가 회수되면 즉시 새로운 인스턴스를 확보해야 합니다.
• SpotServe는 on-demand 인스턴스를 활용하여 빠르게 새로운 인스턴스를 확보하고, inference 중단 시간을 최소화합니다.
• 평소에는 저렴한 preemptible 인스턴스를 사용하고, 필요에 따라 on-demand 인스턴스를 사용하는 hybrid 방식을 통해 비용 효율성과 안정성을 모두 확보합니다.

2. 효율적인 context 관리

• 새로운 인스턴스가 시작될 때 모델 파라미터를 다시 로드하는 것은 시간이 오래 걸립니다.
• SpotServe는 모든 인스턴스가 시작 시점에 모델 파라미터를 CPU 메모리에 로드하고, 새로운 GPU가 할당될 때 CPU 메모리에서 GPU RAM으로 모델 파라미터를 복사하여 재사용합니다.
• 또한, 인스턴스 간 네트워크 링크를 활용하여 KV 캐시를 새로운 GPU로 전송하여 이전 inference 결과를 유지합니다.
• 이를 통해 모델 로딩 시간을 최소화하고 빠르게 inference를 재개할 수 있습니다.

3. Adaptive configuration 최적화

• preemptible 인스턴스의 가용성 변화와 workload 변화에 따라 LLM parallelization configuration (데이터 병렬성, 파이프라인 모델 병렬성, 텐서 모델 병렬성) 을 동적으로 조정합니다.
• SpotServe는 throughput, latency, 비용을 종합적으로 고려하여 최적의 병렬 구성을 선택합니다.
• Adaptive Configuration Optimizer 알고리즘을 사용하여 preemptible 인스턴스 환경에 맞춰 LLM inference를 효율적으로 수행합니다.

추가적으로,

• Device Mapper: 이분 그래프 매칭을 사용하여 사용 가능한 GPU를 최적의 역할에 배정하고, context migration 비용을 최소화합니다.
• Migration Planner: context migration 계획을 수립하고 실행합니다. 앞쪽 레이어의 context 정보와 모든 레이어의 cache context를 우선적으로 이동시켜 inference 중단 시간을 최소화합니다.

SpotServe는 이러한 기술들을 통해 preemptible 인스턴스 환경에서 발생하는 다양한 문제들을 해결하고, 비용 효율적인 LLM 서비스를 가능하게 합니다.

 

 

 

 

4 Stateful Inference Recovery

 

이 섹션에서는 SpotServe가 재계산 없이 중단된 inference request를 복구할 수 있도록 하는 새로운 inference 메커니즘인 stateful inference recovery를 소개합니다. 또한 빈번한 중단을 처리하는 SpotServe의 메커니즘에 대해 설명합니다.

 

4.1 Just-in-time Arrangement

인스턴스 선점 또는 획득 알림이 reparallelization을 트리거할 때 SpotServe는 각 GPU 인스턴스에 대해 inference engine을 종료하고 context 마이그레이션을 시작할 시기를 결정해야 합니다. 보수적인 접근 방식은 context 마이그레이션을 위한 충분한 시간을 확보하기 위해 inference engine을 즉시 중단하는 것입니다. 그러나 이 접근 방식은 인스턴스의 모든 활성 request를 중단시킵니다. 이러한 미완료 request는 다른 inference pipeline으로 rerouting되어 다시 시작해야 하므로 end-to-end inference latency가 높아집니다. 공격적인 대안은 먼저 모든 활성 request를 완료하는 것입니다. 이렇게 하면 인스턴스가 선점 전에 마이그레이션을 완료하지 못할 수 있습니다.

이러한 문제를 방지하기 위해 SpotServe는 클라우드에서 제공하는 유예 기간을 활용하여 token level에서 inference 진행 상황을 기회주의적으로 커밋합니다. 이를 통해 모든 incremental decoding iteration에서 inference request를 중단할 수 있습니다. SpotServe의 context daemon은 inference request의 state (즉, cache context)를 유지 관리하므로 request를 다른 inference pipeline으로 rerouting할 수 있으며, 캐시된 state를 사용하여 이전에 생성된 output token을 다시 계산하지 않고 inference를 직접 계속할 수 있습니다.

 

유예 기간 동안 실행할 iteration 수를 결정하기 위해 SpotServe는 just-in-time (JIT) 배열을 채택하고 inference engine이 디코딩을 중지할 시기를 결정하도록 합니다. 특히 각 spot GPU 인스턴스에는 유예 기간이 시작될 때 알림을 수신하는 interruption arranger가 포함됩니다. 이 알림을 기반으로 interruption arranger는 새 request batch를 inference engine에 공급하기 전에 남은 시간을 확인합니다. 시간 𝑡에 서비스할 준비가 된 input request batch가 있다고 가정하면 SpotServe는 중단 유형에 따라 디코딩 iteration 수 𝑆𝑡를 다르게 결정합니다. 인스턴스 선점의 경우 𝑆𝑡 = arg max0≤𝑆≤𝑆𝑜𝑢𝑡{𝑙𝑒𝑥𝑒(𝑆 | 𝐶𝑡) < 𝑇− − 𝑇𝑚𝑖𝑔}입니다. 여기서 𝑙𝑒𝑥𝑒(𝑆 | 𝐶𝑡)는 𝐶𝑡를 사용하여 𝑆 token을 생성하기 위한 execution latency이고, 𝑇−는 선점을 위한 남은 유예 기간이며, 𝑇𝑚𝑖𝑔는 reparallelization을 위한 인스턴스 마이그레이션 비용입니다. 인스턴스 획득의 경우 𝑆𝑡 = arg min0≤𝑆≤𝑆𝑜𝑢𝑡{𝑙𝑒𝑥𝑒(𝑆 | 𝐶𝑡) ≥ 𝑇+}입니다. 여기서 𝑇+는 획득 (즉, 초기화)을 위한 남은 유예 기간입니다. 이러한 두 가지 배열의 주요 차이점은 선점 전에 배열된 iteration을 최대화하고 획득 전에 최소화한다는 것입니다. 그 이유는 사전 선점 처리와 달리 context 마이그레이션이 인스턴스 획득 후에 발생하기 때문입니다. 게다가 두 경우 모두 배열이 request의 latency를 증가시키지 않도록 해야 합니다 (즉, 𝑇𝑚𝑖𝑔 < 𝑙𝑒𝑥𝑒(𝑆𝑡 | 𝐶𝑡)). 예를 들어 남은 시간이 몇 개의 token만 생성할 수 있는 경우 단순히 rerouting하는 것이 특히 도착 request가 여유가 있을 때 context 마이그레이션 오버헤드를 추가하지 않으므로 더 나을 수 있습니다.

 

 

4.1 Just-in-time Arrangement 정리 노트

목표

• 인스턴스 선점 또는 획득 시, inference engine을 언제 중단하고 context migration을 시작할지 결정하는 효율적인 방법 제시

기존 방식의 문제점

• 보수적 방식: 즉시 inference engine 중단 → 활성 request 중단, rerouting, 높은 latency 발생
• 공격적 방식: 모든 활성 request 완료 후 migration → 선점 전 migration 완료 못할 위험

SpotServe의 JIT Arrangement

• 유예 기간 활용: 클라우드 제공 유예 기간 동안 token level에서 inference 진행 상황 commit
• Context Daemon: inference request의 state (cache context) 유지 → 중단된 request를 다른 pipeline에서 재개 가능
• JIT (Just-In-Time) 결정: inference engine이 적절한 시점에 디코딩 중단 결정
  • 선점 시: 최대한 많은 iteration 수행 (argmax) → l_exe(S | C_t) < T^- - T_mig 조건 만족 (남은 유예 기간 - migration 시간)
  • 획득 시: 최소한의 iteration 수행 (argmin) → l_exe(S | C_t) ≥ T^+ 조건 만족 (남은 유예 기간)
• Latency 증가 방지: T_mig < l_exe(S_t | C_t) 조건 만족 (migration 시간 < iteration 실행 시간)
• Rerouting: 남은 시간이 적으면 context migration 없이 rerouting 수행 (특히 request가 적을 때)

핵심 아이디어

• 유예 기간 동안 최대한 inference 진행 → 선점으로 인한 재계산 최소화
• JIT 방식으로 inference engine 중단 시점 결정 → latency 증가 방지
• Context Daemon을 통해 중단된 request 재개 → 안정적인 inference 보장

장점

• 효율적인 유예 기간 활용
• 낮은 end-to-end inference latency
• 안정적인 inference 수행

 

 

 

4.2 Interruption Fault-tolerance

복구 접근 방식의 한 가지 문제는 이전 배열이 단일 중단 사례만 고려한다는 것입니다. 여러 개의 연속적이고 compact한 중단의 경우 유예 기간이 서로 겹쳐 배열된 iteration을 완료하거나 context를 마이그레이션하기에 충분하지 않을 수 있습니다. 또 다른 문제는 예상치 못한 이유 (예: 네트워크 진동)로 인해 마이그레이션 비용을 과소평가하는 경우 남은 시간이 인스턴스가 배열을 따르기에 충분하지 않을 수 있다는 것입니다.

안정적인 서비스 시스템을 구축하기 위해 SpotServe에는 장애를 처리하기 위한 여러 fault-tolerance 메커니즘이 있습니다. 첫째, SpotServe는 획득한 인스턴스 joining을 지연시키고 이전 중단에 대한 배열을 실현 가능하도록 관리합니다. 둘째, 한 인스턴스가 실제로 예상보다 먼저 선점되는 경우 SpotServe는 cache context를 포기하고 나머지 인스턴스를 사용하여 model context만 마이그레이션해야 합니다. 특히 예상치 못한 장애로 인해 동일한 model context 조각의 모든 replica가 손실되는 경우 마이그레이션이 작동하지 않고 SpotServe는 로컬 (예: 디스크) 또는 원격 클라우드 스토리지 (예: S3)에서 가중치를 로드하여 필요한 model 매개변수를 가져와 다시 시작해야 합니다.

 

 

 

4.2 Interruption Fault-tolerance 정리

문제 상황

• 단일 중단 고려: 기존 방식은 단일 선점/획득만 고려, 연속적인 중단 발생 시 문제 발생 가능
• 유예 기간 부족: 연속적인 중단으로 인해 유예 기간이 겹쳐, iteration 완료 또는 context migration 실패 가능
• 예상치 못한 상황: 네트워크 문제 등으로 migration 비용 과소평가 → 유예 기간 내 작업 완료 실패

SpotServe의 Fault-tolerance 메커니즘

• 인스턴스 joining 지연: 새로운 인스턴스 joining 지연 → 이전 중단 처리 위한 시간 확보
• Cache context 포기: 선점 전 migration 완료 불가능 시, cache context 포기, model context만 migration
• Model context 손실: 예상치 못한 장애로 model context 손실 시, 로컬 또는 원격 스토리지에서 모델 파라미터 로드하여 재시작

핵심 아이디어

• 다중 중단 대비: 연속적인 선점/획득 상황 고려, 안정적인 서비스 제공
• 유연한 처리: 예상치 못한 상황 발생 시, cache context 포기 등 유연한 전략으로 대응
• 최악의 상황 대비: model context 손실 시, 모델 파라미터 재로드를 통해 inference 재개 보장

장점

• 안정성 향상: 다양한 장애 상황에 대한 fault-tolerance 제공
• 신뢰도 향상: 예상치 못한 상황에도 안정적인 inference 수행 보장
• 서비스 연속성 보장: 장애 발생 시에도 최대한 빠르게 서비스 복구 및 재개

 

 

주요 내용 정리

• 동적 reparallelization: preemptible 인스턴스의 가용성 변화와 workload 변화에 따라 LLM parallelization configuration을 동적으로 조정합니다.
• 효율적인 context 관리: 모델 파라미터를 CPU 메모리에 미리 로드하고, KV 캐시를 새로운 GPU로 전송하여 모델 로딩 시간을 최소화하고 빠르게 inference를 재개합니다.
• Stateful inference recovery: 유예 기간을 활용하여 token level에서 inference 진행 상황을 commit하고, 중단된 inference를 재개합니다.
• Just-in-time arrangement: 유예 기간 동안 inference를 계속 수행할지, context migration을 수행할지, 아니면 rerouting을 수행할지 지능적으로 결정합니다.
• Interruption fault-tolerance: 연속적인 중단 상황에 대비하고, 예상치 못한 장애 발생 시에도 안정적인 inference를 수행할 수 있도록 다양한 fault-tolerance 메커니즘을 제공합니다.

이러한 기술들을 통해 SpotServe는 preemptible 인스턴스의 장점 (저렴한 비용) 을 활용하면서 단점 (불안정성) 을 극복하고, 높은 성능과 안정성을 갖춘 LLM 서비스를 제공할 수 있습니다.

 

 

 

5 Implementation

SpotServe의 inference server를 C++로 5.6K LoC, Python으로 2.2K LoC로 구현했습니다. 여기에는 request manager, instance manager 및 meta-context manager를 담당하는 세 가지 resident process가 포함됩니다. 생성된 마이그레이션 계획은 JSON 형식으로 구성되고 TCP 연결을 사용하여 실행 중인 인스턴스로 전송됩니다. CUDA, cuBLAS 및 C++ 위에 구축된 고도로 최적화된 Transformer inference framework인 FasterTransformer를 기반으로 SpotServe의 inference engine을 구축합니다. Inference engine 내부에 context daemon과 interruption arranger를 구현합니다. 특히 FasterTransformer에서 model context와 cache context의 메모리 할당은 context daemon에서 해당 GPU tensor를 가져오는 것으로 대체되었습니다.

Context 마이그레이션 작업은 batched asynchronous NCCL send/recv primitives에 의해 구현됩니다. Context 마이그레이션에는 GPU 메모리에 추가 통신 buffer 공간이 필요하며 마이그레이션 계획에 따라 동적으로 할당 및 해제됩니다. Context daemon과 FasterTransformer는 두 개의 서로 다른 process에 속하기 때문에 context 포인터를 공유하기 위해 CUDA Inter-Process Communications (IPC)를 사용합니다. Progressive 마이그레이션에서 overlapping을 지원하기 위해 각 context tensor에 mutex lock을 추가하여 마이그레이션이 완료되기 전에 inference를 차단합니다.

또한 SpotServe를 통해 필요한 inference latency, 시스템 throughput 및 context 마이그레이션 오버헤드를 사전에 추정하기 위해 cost model을 설계하고 오프라인 profiler를 구현합니다. 추정을 더 정확하게 하기 위해 cost profiling 및 모델링 중에 몇 가지 실제 요인 (예: 매우 작은 배치 크기, 단일 input token, 과도하게 shard된 intra-op 병렬 처리, GPU 메모리 액세스 및 너무 작은 통신 데이터 볼륨)으로 인한 리소스 under-utilization 영향 (즉, GPU, 네트워크, PCIe)을 신중하게 고려합니다.

 

 

 

이 챕터에서는 SpotServe 시스템을 어떻게 실제로 구현했는지 설명합니다.

1. Inference Server

• 언어: C++ (5.6K LoC), Python (2.2K LoC)
• 구성:
  • Request Manager: inference 요청 수신 및 관리
  • Instance Manager: 인스턴스 관리 (생성, 삭제, 선점 감지 등)
  • Meta-context Manager: context 정보 관리 및 마이그레이션
• 통신: Migration Plan을 JSON 형식으로 생성하여 TCP 연결을 통해 인스턴스에 전송

2. Inference Engine

• 기반: FasterTransformer (NVIDIA의 최적화된 Transformer inference framework)
• 구성:
  • Context Daemon: 모델 파라미터 및 cache context 관리
  • Interruption Arranger: 선점/획득 시 inference 중단 및 재개 관리
• 메모리 관리:
  • Context Daemon을 통해 모델 및 cache context 메모리 할당
  • Context migration을 위한 buffer 공간 동적 할당 및 해제

3. Context Migration

• 구현: NCCL send/recv primitives (비동기, 배치)
• 프로세스 간 통신: CUDA IPC (Inter-Process Communication) 사용 (Context Daemon과 FasterTransformer 간 context 포인터 공유)
• Overlapping 지원: Mutex lock을 사용하여 migration 완료 전 inference 차단

4. Cost Model 및 Profiler

• Cost Model: inference latency, throughput, migration overhead 예측
• Offline Profiler: 실제 환경에서 cost profiling 수행
• 정확도 향상: GPU, 네트워크, PCIe 등 리소스 under-utilization 영향 고려 (배치 크기, input token, 메모리 접근 등 요인 고려)

요약

SpotServe는 C++, Python, FasterTransformer, CUDA 등을 사용하여 구현되었으며, 효율적인 context 관리, 빠른 context migration, 정확한 cost 예측을 위한 다양한 기술을 사용합니다.

 

 

 

6.1 Experiment Setup

Baseline. 우리가 아는 한 SpotServe는 spot 인스턴스를 위한 최초의 분산 LLM inference 시스템입니다. 따라서 이전 접근 방식의 두 가지 대표적인 아이디어를 각각 일반화하여 FasterTransformer 위에 두 개의 baseline 시스템을 구축합니다. 한 가지 접근 방식은 선점이 발생할 때 중단된 request를 사용 가능한 다른 pipeline으로 동적으로 rerouting하는 request rerouting입니다. 고정된 사전 정의된 최적의 model parallel configuration을 사용하고 inference pipeline을 적응적으로 삭제/추가합니다. 또 다른 baseline은 우리 것과 같이 병렬 구성을 변경하지만 context 마이그레이션 없이 모든 인스턴스를 다시 시작하고 다시 초기화해야 하는 model reparallelization입니다. 둘 다 현재 request의 inference를 중단하고 나중에 다시 계산해야 하는 reactive 방식으로 선점을 처리합니다. 백본 시스템에서 불공정을 피하기 위해 SpotServe와 동일한 inference engine으로 구현됩니다. 동시에 여러 model replica를 서비스하는 redundancy 기반 접근 방식은 LLM의 막대한 비용으로 인해 포함되지 않습니다.

Model. OPT-6.7B, GPT-20B 및 LLaMA-30B를 포함하여 서로 다른 scale의 세 가지 LLM에서 SpotServe를 평가합니다. 표 1에는 이러한 model을 서비스하는 데 필요한 최소 GPU 수와 해당 model 병렬 전략 및 단일 request execution latency가 요약되어 있습니다.

설정. AWS g4dn spot 인스턴스를 사용하여 12시간 실제 가용성 추적을 수집하고 서로 다른 동적 동작을 가진 두 개의 대표적인 20분 세그먼트 (즉, 그림 5의 𝐴𝑆 및 𝐵𝑆)를 추출합니다. 재현 가능한 비교를 위해 평가에서 AWS g4dn.12xlarge 인스턴스 (인스턴스당 4개의 NVIDIA Tesla T4 GPU)에서 추적을 재생합니다. 안정적이고 변동하는 inference request 도착 workload를 모두 포함합니다. 정적 workload의 경우 model마다 계산 요구 사항이 다르다는 점을 고려하여 서로 다른 request 도착률을 설정합니다 (즉, 기본적으로 OPT-6.7B, GPT-20B 및 LLaMA-30B의 경우 각각 1.5, 0.35 및 0.2 request/s). 실제 workload에서 bursty를 시뮬레이션하기 위해 분산 계수 (CV)가 6인 Gamma request 도착 process를 사용합니다. 또한 on-demand 인스턴스와 혼합할지 여부에 따라 시스템 성능을 별도로 연구했습니다. 이를 위해 알고리즘 1에 따라 기회주의적으로 on-demand 인스턴스를 할당하고 spot 인스턴스와 혼합하여 두 개의 추가 추적 (즉, 그림 5의 𝐴𝑆+𝑂 및 𝐵𝑆+𝑂)을 생성합니다. 동적 workload의 경우 Microsoft에서 공개적으로 출시한 production 추적 MAF를 포함하고 §6.3에서 설명합니다. 최적화 중에 최대 배치 크기 𝐵는 {1, 2, 4, 8}에서 선택되고 𝑆𝑖𝑛은 512이고 𝑆𝑜𝑢𝑡은 128입니다.

 

 

 

6.2 Comparison on Stable Workload

End-to-end inference latency. 그림 6은 안정적인 workload에서 세 가지 model 모두의 latency 성능을 보여줍니다. SpotServe는 네 가지 서로 다른 추적에서 모든 latency 메트릭 측면에서 Rerouting과 Reparallelization을 모두 능가합니다. P99 latency를 예로 들면 SpotServe는 가장 큰 LLaMA-30B model에서 Reparallelization과 Rerouting을 각각 약 1.34-2.43배, 2.14-9.13배 능가합니다. 개선 사항은 주로 동적 reparallelization, 효율적인 사전 마이그레이션 및 stateful inference recovery의 세 가지 측면에서 비롯됩니다.

Reparallelization과 비교하여 SpotServe의 가장 큰 장점은 가벼운 context 마이그레이션 메커니즘입니다. Varuna와 같은 이전 접근 방식에서는 각 reparallelization에 대해 시스템을 다시 시작해야 하며 context가 손실될 수밖에 없습니다. 모든 model 매개변수를 다시 로드한 다음 중단된 모든 request를 다시 계산하면 긴 tail latency가 발생합니다.

Rerouting과 비교하여 SpotServe는 전체 inference pipeline을 삭제하는 대신 더 세분화된 선점 처리를 지원할 수 있습니다. 그림 6의 많은 Rerouting 사례는 과부하를 나타내는 점선으로 표시됩니다 (즉, 시스템 서비스 기능이 request 도착률보다 낮아지고 request 누적이 발생합니다). GPT-20B를 예로 들면 인스턴스 가용성이 높은 경우 (≥ 8 인스턴스) Rerouting은 최소 inference latency와 충분한 시스템 throughput (즉, 0.35 request/s보다 큼)으로 (𝐷 = 2, 𝑃 = 2, 𝑀 = 8) 구성을 지원합니다. 인스턴스가 선점되면 Rerouting은 하나의 inference pipeline을 삭제하고 (𝐷 = 1, 𝑃 = 2, 𝑀 = 8)으로 축소해야 하므로 예정된 request가 누적되고 제때 서비스될 수 없습니다. 그러나 SpotServe는 과부하를 방지하기 위해 (𝐷 = 2, 𝑃 = 3, 𝑀 = 4)를 사용하여 서비스합니다. SpotServe는 때때로 Rerouting과 동일한 구성을 제안할 수 있지만 KV 캐시 복구로 인해 SpotServe의 성능이 여전히 우수해야 합니다. 또 다른 관찰은 on-demand 인스턴스를 혼합하면 faithful 인스턴스 획득으로 인해 과부하가 완화된다는 것입니다.

비용 비교. Inference latency 외에도 preemptible 인스턴스를 사용하여 LLM을 서비스하는 것이 비용 효율적인지 확인하기 위해 비용을 연구합니다. 그림 7은 모든 baseline 시스템의 per-token 비용과 GPT-20B model에서의 latency를 보여줍니다. 또한 spot 인스턴스보다 비싼 on-demand 인스턴스만 사용하는 결과 (점선으로 표시)도 보여줍니다 (즉, 3.9 USD/h 대 1.9 USD/h). 비용이 감소함에 따라 on-demand 인스턴스의 latency는 더 적은 on-demand 인스턴스로 필요한 서비스 기능을 충족할 수 없기 때문에 크게 증가합니다. 반대로 경제적인 spot 인스턴스를 사용한 서비스는 inference latency와 비용 간의 균형을 맞춥니다. SpotServe는 평균 latency에서 18% 미만, P99 tail latency에서 90%의 비교적 적당한 증가를 허용하면서 최대 54%의 비용을 절감합니다. 이러한 비용 이점은 on-demand/spot 가격 비율이 더 높은 다른 유형의 인스턴스에서 더욱 중요합니다.

Ablation study. 그림 9는 서로 다른 SpotServe 구성 요소를 사용하는 두 가지 추적에서 GPT-20B의 P99 tail latency와 평균 latency를 보여줍니다. SpotServe에서 시작하여 각 시스템 최적화를 하나씩 점진적으로 비활성화합니다. Parallelization controller를 제거하면 추적 𝐵𝑆에서 tail latency가 179% 향상됩니다. 이는 parallelization controller가 누적된 request를 처리하기 위해 더 높은 throughput을 가진 새 구성으로 전환할 것을 제안하기 때문입니다. Migration planner를 추가로 비활성화하면 추적 𝐴𝑆와 𝐵𝑆에서 tail latency가 각각 1.4배, 3.1배 향상됩니다. 또 다른 중요한 점은 메모리 효율적인 migration planner가 GPT-20B model을 서비스하는 데 필요한 최소 GPU 수를 16개에서 12개로 줄여 이전 parallelization 구성 탐색 공간을 확장한다는 것입니다. 또한 interruption arranger는 마이그레이션 중에 cache context를 전송하고 중단된 request에 대한 중복 계산을 방지하므로 추적 𝐵𝑆에서 29%의 tail latency 감소에 기여합니다. 마지막으로 device mapper를 제거하면 시스템은 다른 최적화 없이 model context 유지 관리만 가능한 일반적인 접근 방식으로 저하됩니다. 전반적으로 이러한 모든 최적화는 SpotServe가 추적 𝐴𝑆에서 tail latency를 1.61배, 추적 𝐵𝑆에서 3.41배 줄이는 데 도움이 됩니다.

 

 

 

6.3 Comparison on Fluctuating Workload

SpotServe의 auto-scaling 성능을 연구하기 위해 MAF trace를 재생하고 이전 접근 방식과 같이 도착 강도를 조정하여 실험 설정과 호환되도록 합니다. 그림 8a 및 8b는 선택한 trace에 실제 환경에서 대표적인 변동 및 bursty workload가 포함되어 있음을 보여줍니다. 이 실험에서 on-demand 인스턴스와의 혼합을 활성화하고 생성된 인스턴스 가용성 추적 (즉, 𝐴′𝑆+𝑂 및 𝐵′𝑆+𝑂)은 그림 8c 및 8d에 나열됩니다. End-to-end inference latency 통계는 그림 8e 및 8f에 나와 있으며 SpotServe는 Reparallelization 및 Rerouting과 비교하여 각각 최대 2.94배, 1.73배의 P99 tail latency를 줄입니다.

Per-request latency study. 그림 8g 및 8h는 두 추적 모두에 대해 시간 경과에 따른 각 도착 request의 inference latency를 보여줍니다. SpotServe는 유연한 병렬 구성 최적화와 가벼운 context 마이그레이션으로 인해 전체 추적에서 거의 항상 가장 낮은 latency를 수행합니다. 다음에서는 심층 분석을 위해 그림 8h를 예로 들어 보겠습니다. 먼저 모든 접근 방식은 𝑡 = 0s에 10개의 spot 인스턴스를 사용할 수 있으므로 (𝐷 = 2, 𝑃 = 2, 𝑀 = 8)의 실행 가능한 구성으로 시작합니다. 선점은 𝑡 = 120s 및 𝑡 = 240s에서 처음 발생하지만 총 사용 가능한 인스턴스는 여전히 (𝐷 = 2, 𝑃 = 2, 𝑀 = 8)을 지원하기에 충분합니다. 𝑡 = 270s부터 증가하는 도착률이 시스템 처리 용량을 압도합니다. 30초 후 이러한 과부하가 감지되고 SpotServe와 Reparallelization 모두 구성을 (𝐷 = 3, 𝑃 = 3, 𝑀 = 4)로 변경합니다. 인스턴스 획득은 𝑡 = 450s에 완료되므로 latency를 낮추기 위해 (𝐷 = 3, 𝑃 = 2, 𝑀 = 8)로 변경합니다. 그러나 Reparallelization은 값비싼 다시 시작 오버헤드로 인해 가장 높은 peak latency를 겪습니다. Rerouting은 pipeline 수만 변경하고 일부 request 대기 오버헤드가 발생합니다. 𝑡 = 600s 이후 도착률 감소가 감지되고 on-demand 인스턴스가 해제되기 시작하면 SpotServe와 Rerouting 모두 (𝐷 = 2, 𝑃 = 2, 𝑀 = 8)로 돌아갑니다. 결과적으로 SpotServe는 변동하는 workload에 대해 다른 두 baseline보다 훨씬 뛰어난 성능을 보입니다.

 

 

 

 

6. Evaluation 깔끔하게 정리

이 챕터에서는 SpotServe의 성능을 평가하고, 기존 방법들과 비교 분석합니다.

6.1 실험 설정

• Baseline:
  • Request Rerouting: 선점 발생 시 다른 pipeline으로 request 재전송
  • Model Reparallelization: context migration 없이 전체 인스턴스 재시작 및 재초기화
  • 두 baseline 모두 FasterTransformer 기반 구현
• 모델: OPT-6.7B, GPT-20B, LLaMA-30B
• 환경: AWS g4dn.12xlarge 인스턴스 (4 NVIDIA Tesla T4 GPUs)
• Trace:
  • 12시간 실제 AWS spot 인스턴스 가용성 trace (𝐴𝑆, 𝐵𝑆)
  • On-demand 인스턴스 혼합 trace (𝐴𝑆+𝑂, 𝐵𝑆+𝑂)
  • Microsoft MAF production trace (변동 workload)
• Workload:
  • Stable workload: 고정된 request 도착률 (모델별 상이)
  • Fluctuating workload: Gamma 분포 기반 request 도착 (CV=6)
• 평가 지표: P99 latency, 평균 latency, 비용

6.2 Stable Workload 비교

• Inference Latency: SpotServe는 모든 모델, 모든 trace에서 Rerouting, Reparallelization보다 낮은 latency 기록 (P99 latency 기준 최대 9.13배 향상)
  • 동적 re-parallelization, 효율적인 context migration, stateful inference recovery 덕분
  • Reparallelization: 모델 파라미터 재로드 및 재계산으로 인한 높은 latency
  • Rerouting: 전체 pipeline 삭제로 인한 과부하 발생, SpotServe는 과부하 방지
• 비용: SpotServe는 on-demand 인스턴스만 사용하는 것보다 최대 54% 비용 절감 (평균 latency 18% 증가, P99 latency 90% 증가)
• Ablation Study:
  • 각 컴포넌트 비활성화 실험 → Parallelization Controller, Migration Planner, Interruption Arranger 모두 성능 향상에 기여

6.3 Fluctuating Workload 비교

• MAF trace: 변동 및 bursty workload 사용
• Latency: SpotServe는 Reparallelization, Rerouting보다 낮은 P99 tail latency 기록 (최대 2.94배, 1.73배 향상)
• Per-request Latency: 전체 trace에서 SpotServe가 가장 낮은 latency 유지
  • 유연한 parallel configuration 최적화 및 가벼운 context migration 덕분
  • Reparallelization: 높은 재시작 오버헤드
  • Rerouting: request 대기 오버헤드

결론

SpotServe는 preemptible 인스턴스를 사용하여 LLM inference 비용을 절감하면서도, 기존 방법들보다 뛰어난 성능 (낮은 latency, 높은 throughput) 과 안정성을 제공합니다. 동적 reparallelization, 효율적인 context migration, stateful inference recovery 등 핵심 기술들을 통해 preemptible 인스턴스 환경의 어려움을 극복하고 효과적인 LLM 서비스를 가능하게 합니다.

 

 

 

7 Related Work

DNN inference system. 널리 보급된 DL 애플리케이션은 큰 시장 가치를 가져오고 상당한 DL 서비스 트래픽을 유발합니다. 몇 가지 이전 접근 방식 (예: Clipper, Clockwork, Nexus 등)은 temporal multiplexing을 고려하고 batching 및 더 나은 스케줄링을 통해 GPU 활용도를 높입니다. INFaaS는 여러 model의 inference 효율성 또는 정확성이 다를 때 model 선택 문제를 연구합니다. Shepherd는 리소스 활용률과 서비스 시스템 effective throughput을 모두 고려하고 request 스케줄링을 개선합니다. 또한 TurboTransformer 및 LightSeq와 같이 Transformer model에 대한 customized GPU kernel 최적화를 수행하는 일부 inference 시스템이 있습니다. 몇 가지 최근 inference 시스템 (예: FasterTransformer, Orca, FairSeq, DeepSpeed, AlpaServe)은 분산 training 접근 방식의 병렬화 기술을 활용하여 LLM inference를 지원합니다. 이 중 AlpaServe는 리소스 multiplex 시나리오를 위해 설계되었으며 단일 LLM inference에 대한 실증 연구에서 성능 우위를 보이지 않습니다 (즉, FasterTransformer C++ 버전보다 약 3배 낮음). 이러한 모든 이전 작업은 거의 dedicated 인스턴스를 위해 설계되었으며 인스턴스 선점을 허용하지 않습니다.

Spot 인스턴스를 통한 ML 서비스. 이전 접근 방식에서는 소규모 ML model을 위한 ML inference 시스템에 spot 인스턴스를 포함했습니다. Cocktail은 저렴한 spot 인스턴스를 활용하여 ensembling model 수를 늘리고 인스턴스 선점으로 인해 정확도가 간헐적으로 손실될 수 있습니다. MArk는 ML 서비스를 위한 이전 auto-scaling 시스템 (예: SageMaker)의 over-provisioning 문제를 연구하고 SLO 인식 리소스 제공 알고리즘을 사용하여 비용 효율성을 개선합니다. 또한 더 많은 비용 절감을 위해 spot 인스턴스를 포함하는 것을 고려하지만 인스턴스 중단 중에 미해결 request를 처리하기 위해 burstable CPU 인스턴스가 필요합니다. 이러한 접근 방식은 preemptible 인스턴스를 사용하여 ML model을 서비스하고 LLM의 분산 inference에 대한 접근 방식에 동기를 부여하는 첫 번째 단계를 수행합니다.

Serverless 컴퓨팅 및 ML 서비스. 더 나은 비용 효율성을 위해 serverless 컴퓨팅을 적용하여 ML inference workload를 지원하는 몇 가지 최근 접근 방식이 있습니다. 그러나 serverless 함수는 제한된 계산 능력, 메모리 및 스토리지로 가볍게 설계되었으며 GPU로 프로비저닝하기 어렵습니다. 또한 serverless 함수는 서로 직접 통신할 수 없으며 이는 LLM의 분산 inference를 지원하는 데에도 필요합니다. 결과적으로 소규모 model에서는 잘 작동하지만 하드웨어 제약으로 인해 LLM을 쉽게 서비스할 수 없습니다.

 

8 Limitations and Future Work

우리 접근 방식의 한계를 소개하고 SpotServe에서 향후 연구 방향을 간략하게 설명합니다. 첫째, SpotServe의 핵심 아이디어는 유예 기간에 크게 의존하는 인스턴스 가용성 변경을 사전에 처리하는 것입니다. 현재 모든 클라우드 제공업체에서 이 기능을 제공하지만 inference workload 예측 또는 인스턴스 가용성 예측과의 조합과 같이 시스템 성능을 향상시키기 위해 더 비전 있는 솔루션을 모색할 가치가 있습니다. 둘째, 우리의 접근 방식은 주로 단일 유형의 GPU 인스턴스에 중점을 둡니다. 비용 이점을 위해 heterogeneous spot 인스턴스 또는 다른 클라우드의 인스턴스 (예: SkyPilot)를 통합할 수도 있습니다. 이러한 시나리오는 SpotServe의 context 마이그레이션에 새로운 과제를 안겨줍니다. 마지막으로 현재 접근 방식은 최적화 목표로 inference latency 최소화를 사용합니다. §3.2에서 언급했듯이 여러 inference 시나리오의 요구 사항을 충족하기 위해 다른 목표 (예: 엄격한 SLO, 높은 throughput)를 탐색하는 것도 의미가 있습니다. 또한 병렬 구성의 탐색 공간을 확장하여 향후 새로운 유형의 대규모 model (예: mixutre-of-experts)을 지원할 수 있습니다. SpotServe는 spot 인스턴스에 중점을 두지만 우리의 기술은 다른 preemptible 리소스로 쉽게 일반화할 수 있습니다. 예를 들어 리소스 스케줄러는 switching 오버헤드가 있는 긴급 작업을 위해 리소스를 선점할 수 있습니다. 우리는 우리의 접근 방식이 preemptible 인스턴스에 대한 분산 inference를 위한 새로운 패러다임을 고무시키고 SpotServe의 디자인에서 얻은 통찰력이 이 방향을 따라 다양한 후속 연구에 동기를 부여할 수 있다고 믿습니다.

9 Conclusion

이 논문에서는 preemptible 인스턴스에서 최초의 분산 LLM 서비스 시스템인 SpotServe를 제시합니다. SpotServe의 여러 핵심 기술은 preemptible 인스턴스에서 generative LLM의 빠르고 안정적인 서비스를 가능하게 합니다. 첫째, SpotServe는 시스템 서비스 기능이 workload와 호환되도록 병렬 구성을 동적으로 조정합니다. 구성 최적화는 throughput, latency 및 비용 간의 trade-off를 고려합니다. 둘째, reparallelization 오버헤드를 최소화하기 위해 효율적인 context 마이그레이션을 달성하는 device 매핑 알고리즘과 마이그레이션 계획 메커니즘을 설계합니다. 마지막으로 클라우드 제공업체에서 제공하는 유예 기간을 활용하기 위해 SpotServe가 훨씬 더 세분화된 단위로 inference 진행 상황을 커밋할 수 있도록 하는 stateful inference recovery를 도입합니다. 실제 추적과 다양한 규모의 인기 LLM에서 SpotServe를 평가하고 SpotServe가 on-demand 인스턴스에 비해 54%의 비용을 절감하고 기존 접근 방식에 비해 P99 tail latency를 2.4 - 9.1배 줄일 수 있음을 보여줍니다.

감사의 말

익명의 검토자와 셰퍼드인 Todd Mytkowicz에게 의견과 유용한 피드백을 제공해 주셔서 감사합니다. 이 자료는 NSF 상 CNS-2147909, CNS-2211882 및 CNS-2239351과 Amazon, Cisco, Google, Meta, Oracle, Qualcomm 및 Samsung의 연구 상을 기반으로 합니다.

 

 

 

 

 

7. Related Work 정리

기존 연구와 SpotServe의 차별점

• DNN Inference System:
  • 기존 연구: 대부분 dedicated 인스턴스 (안정적인 GPU) 기반, 인스턴스 선점 고려 X
  • SpotServe: preemptible 인스턴스 (저렴하지만 불안정한 GPU) 활용, 선점 대응 및 효율적인 자원 관리
• Spot 인스턴스 활용:
  • 기존 연구: 소규모 ML 모델에만 적용, 선점 시 정확도 손실 발생 가능, burst request 처리 어려움
  • SpotServe: LLM (대규모 모델) 에 적용, 선점 시에도 안정적인 inference, 동적 자원 할당으로 burst request 대응
• Serverless 컴퓨팅:
  • 기존 연구: GPU 지원 부족, 함수 간 통신 어려움 → LLM inference에 부적합
  • SpotServe: GPU 기반 인스턴스 활용, 분산 inference 지원 → LLM에 적합

8. Limitations and Future Work 정리

SpotServe의 한계점 및 향후 연구 방향

• 유예 기간 의존성: 선점 예측, workload 예측 등 추가적인 기술과의 결합을 통한 성능 향상
• 단일 GPU 유형: heterogeneous GPU 인스턴스, 다중 클라우드 환경 지원
• 최적화 목표: latency 최소화 외에 SLO 준수, throughput 극대화 등 다양한 목표 설정
• 모델 확장: mixture-of-experts 등 새로운 LLM 모델 지원
• Preemptible 리소스: GPU 외 다른 preemptible 리소스 (CPU, 메모리 등) 에 대한 적용

9. Conclusion 정리

SpotServe의 핵심 기여

• Preemptible 인스턴스 기반 LLM inference 시스템 최초 개발
• 동적 reparallelization, 효율적인 context migration, stateful inference recovery 등 핵심 기술 제시
• 실제 환경에서 on-demand 인스턴스 대비 54% 비용 절감, 기존 방법 대비 P99 tail latency 2.4-9.1배 감소

요약

SpotServe는 preemptible 인스턴스를 효율적으로 활용하여 LLM inference 비용을 절감하면서도, 높은 성능과 안정성을 제공하는 시스템입니다. 이 논문은 SpotServe의 설계 및 구현, 성능 평가 결과를 제시하며, 향후 preemptible 인스턴스 기반 분산 inference 연구에 중요한 기반을 제공합니다.