MLSys 2024 · Sheng, Cao et al. (UC Berkeley · Stanford · SJTU) · arXiv 2311.03285v3 · code github.com/S-LoRA/S-LoRA

S-LoRA: base 모델 하나로 LoRA adapter 수천 개를 동시에 서비스하기

원문 papers/slora-mlsys24.pdf (16쪽) · 인용 표기 §5.1 p.5 = 논문 절·쪽 · 논문에 없음 = 이해를 돕기 위해 덧붙인 설명

0한눈에 보기

LoRA 를 base 모델에 merge 해서 서비스하면 adapter 마다 모델 사본이 필요하고, 서로 다른 adapter 요청을 한 batch 로 묶을 수 없다.
S-LoRA 는 base 계산(xW)은 모두 묶고 adapter 계산(xAB)만 따로 하며, adapter 와 KV cache 를 한 paged pool 에 넣어 A100 한 장에서 adapter 2,000 개를 서비스한다.

0.1
0.1.1기 (상황)
한 base LLM 에서 작업·사용자별 LoRA adapter 가 수백~수천 개 생긴다. 이것들을 한 서버에서 동시에 서비스해야 한다 §1 p.1.
0.1.2승 (문제)
merge 방식은 adapter 간 batch 불가, 모델 사본 방식(vLLM-packed)은 GPU 메모리 부족으로 adapter 100 개에서 OOM 이다 (본문은 "fewer than 5" 라고 씀) §7.2 p.8. adapter 를 동적으로 올리면 KV cache 와 섞여 fragmentation 이 생긴다.
0.1.3전 (기법)
① base·LoRA 계산 분리 + 모든 adapter 는 CPU main memory, 현재 batch 것만 GPU 로 ② Unified Paging: adapter weight 와 KV cache 를 H 크기 page 로 한 pool 에 ③ 비연속 메모리용 custom kernel (MBGMM·MBGMV) ④ LoRA 용 tensor parallelism.
0.1.4결 (결과)
Llama-7B~70B, A10G·A100. vLLM-packed 대비 throughput 최대 4×, HuggingFace PEFT 대비 최대 30×, adapter 5 → 2,000 개로 늘려도 throughput 은 거의 그대로 §7.2 p.7–8.
0.2
0.2.1
2,000
A100 80GB 한 장에서 동시 서비스한 adapter 수
0.2.2
4×
throughput, vLLM-packed 대비 (최대)
0.2.3
30×
throughput, HuggingFace PEFT 대비 (최대)
0.2.4
−5.5%
S1 에서 adapter 5 → 2,000 개일 때 throughput 감소 (8.05 → 7.61 req/s, Table 3 에서 계산 논문에 없음)

1배경 용어 먼저

이 논문을 읽으려면 6 가지만 알면 된다: LoRA, KV cache, PagedAttention, continuous batching, fragmentation, tensor parallelism.
각 용어는 그림으로 먼저 보고, 논문이 그것을 어디에 쓰는지 한 줄로 잇는다.

1.1

LoRA (Low-Rank Adaptation)

원래 weight W(h×d) 는 얼리고, 작은 행렬 A(h×r) · B(r×d) 만 학습한다. W' = W + AB, 그래서 xW' = xW + xAB Eq.1–2 §2 p.2. r 은 8~64 로 h(4096~8192)보다 훨씬 작다. 보통 attention 의 q·k·v·o projection 에만 붙인다. Wh×d (모두 공유) + A B h×r · r×d (adapter 마다) merge: W+AB 를 미리 더해 새 모델 1 벌을 만든다 on-the-fly: xW 와 xAB 를 따로 계산해 더한다 ← S-LoRA 논문에서의 역할: adapter 가 여러 개면 merge 는 adapter 수만큼 모델 사본이 필요하므로, S-LoRA 는 on-the-fly 로 계산한다.
1.2

KV cache 와 PagedAttention

LLM 은 token 을 하나씩 만든다(decode). 매번 앞 token 전부를 다시 보므로 앞 token 의 Key·Value 를 GPU 에 저장해 둔다 = KV cache §2.1 p.2–3. 길이가 요청마다 달라 크기가 계속 변한다. vLLM 의 PagedAttention 은 OS 의 paging 처럼 KV 를 고정 크기 page 로 쪼개 흩어진 자리에 저장한다. 요청 1 의 KV → page 단위로 빈자리 어디에나 → 연속 공간 불필요 논문에서의 역할: S-LoRA 는 이 page 개념을 adapter weight 에도 적용한다 (Unified Paging).
1.3

batching · continuous batching

여러 요청을 한 번의 GPU 연산으로 묶는 것. decode 는 memory-bound 라 batch 가 커질수록 공짜로 throughput 이 오른다. Orca 의 iteration-level (continuous) batching 은 token 한 step 마다 끝난 요청을 빼고 새 요청을 넣는다 §2.1 p.3.

memory fragmentation (단편화)

크기가 제각각인 덩어리를 할당·해제하다 보면 빈 공간이 잘게 흩어져, 총량은 충분해도 큰 덩어리를 못 넣는 상태 논문에 없음. adapter 는 rank 마다, KV 는 길이마다 크기가 달라 둘을 섞으면 심해진다 §5 p.4.

GEMM · GEMV · custom kernel

GEMM = 행렬×행렬 (prefill 처럼 token 여럿), GEMV = 행렬×벡터 (decode 처럼 token 하나). BLAS 의 batch GEMM 은 모든 문제가 같은 크기여야 해서 rank·길이가 다르면 padding(0 채우기)이 필요하다 §4.1 p.4.

tensor parallelism · all-reduce · all-gather

행렬 하나를 여러 GPU 에 열(column)·행(row) 방향으로 나눠 계산 §6 p.5. all-gather = 각 GPU 조각을 모아 모두가 전체를 갖기, all-reduce = 각 GPU 부분합을 더해 모두가 합을 갖기 논문에 없음. Megatron-LM 방식이 표준.

SLO · first token latency

SLO (Service Level Objective) = 지켜야 할 지연 목표. 이 논문은 "첫 token 이 6 초 안에 나온 요청 비율" 을 SLO attainment 로 쓴다 §7.1 p.7.

admission control

부하가 용량을 넘으면 어떤 요청을 받고 어떤 요청을 버릴지 정하는 것. 다 받으면 결국 모든 요청이 SLO 를 놓친다 §4.3 p.4.

2문제: 왜 기존 방식으로는 수천 개를 못 싣나

원래 LoRA 논문 방식(merge 후 adapter 를 더했다 뺐다 교체)은 한 번에 adapter 하나만 돌아 서로 다른 adapter 요청을 batch 로 묶을 수 없다.
그렇다고 adapter 마다 merge 된 모델 사본을 두면 GPU 메모리가 곧 바닥난다 (vLLM-packed 는 adapter 100 개에서 OOM).

2.1 ① merge + 교체 (원 LoRA 논문 · PEFT) W+A1B1 → 교체 → W+A2B2 adapter 하나씩 순서대로 · batch 작음 ② 모델 사본 (vLLM-packed) 모델 n 벌 → GPU 메모리 n 배 → n ≥ 100 OOM ③ S-LoRA: base 공유 + LoRA 따로 W (1 벌, 모두 batch) 서로 다른 adapter 도 한 batch · 추가 비용은 xAB
2.1.c세 방식을 나란히 그린 그림 논문에 없음. 논문 근거는 §1 p.1, §4.1 p.3–4, §7.1 p.7 의 baseline 설명.
"merging the weights into the base model leads to multiple weight copies and missed batching opportunities."§4.1 p.3
on-the-fly 로 가면 새로 생기는 세 가지 어려움
2.2
어려움왜 생기나S-LoRA 의 답
2.2.1메모리 관리adapter 를 GPU 밖에 두고 필요할 때 올리면, 크기가 다른 adapter 와 KV 가 섞여 fragmentation · I/O 지연Unified Paging + prefetch (§5.1–5.2)
2.2.2batch 연산rank 가 다른 adapter 들이 비연속 메모리에 있어 BLAS batch GEMM 으로는 padding 이 필요MBGMM · MBGMV kernel (§5.3)
2.2.3multi-GPULoRA 가 새 행렬·곱셈을 더해 기존 tensor parallelism 분할에 맞지 않음S-LoRA TP (§6)

§1 p.2

3기법: 네 부품

① base 계산은 GEMM 으로 묶고 LoRA 계산은 custom kernel 로 따로 ② 모든 adapter 는 main memory, 현재 batch 의 adapter 만 GPU 로.
③ adapter 와 KV 를 H 크기 page 로 한 pool 에 ④ multi-GPU 에서는 LoRA 통신을 base 통신에 합쳐 추가 비용을 거의 0 으로.

3.1① 계산 분리: xW 는 묶고 xAB 는 따로

3.1.1 Fig.1
3.1.1.cFigure 1. Separated batched computation for the base model and LoRA computation. (p.3) 요청 x1·x2·x3 가 서로 다른 adapter 를 써도 W 는 하나라 한 번의 GEMM 으로 묶인다. adapter 별 xAB 만 따로 계산해 더한다. xAB 는 xW 보다 훨씬 싸서, 묶어서 얻는 이득이 추가 비용보다 크다 §4.1 p.4.

3.2② 메모리 배치: adapter 는 main memory, 필요한 것만 GPU

3.2.1 Fig.2
3.2.1.cFigure 2. Overview of memory allocation in S-LoRA. (p.3) adapter 1~6… 은 모두 CPU main memory 에 있고, 지금 batch 가 쓰는 Adapter 2·5 만 GPU 의 unified memory pool 로 올라온다. batch 크기는 GPU 메모리로 제한되므로 한 batch 에 필요한 adapter 수도 제한된다 → 서비스 가능한 adapter 수의 상한은 main memory 크기 §4.1 p.4.

prefetch: 현재 decode batch 를 돌리는 동안 대기열(waiting queue)을 보고 다음 batch 에 필요한 adapter 를 미리 GPU 로 올려 I/O 를 계산 뒤에 숨긴다 §5.2 p.5.

3.3③ Unified Paging: adapter 와 KV 를 같은 page 에

3.3.1 Fig.3
3.3.1.cFigure 3. Unified memory pool. The page size is H elements. (p.5) pool 의 한 줄(page) = 길이 H 벡터 하나. KV cache 와 adapter weight 가 줄 단위로 섞여 흩어져 있다. 빈 줄이 어디 있든 쓸 수 있어 fragmentation 이 줄어든다 §5.1 p.5.
3.3.2 KV cache (한 요청 · 한 layer) shape (S, H) S = 3 token → page 3 개 LoRA weight (한 adapter) shape (R, H) R = 2 rank → page 2 개 두 텐서 모두 한 변이 H → "H 벡터 하나 = page 하나" 로 같은 pool 에 담는다 pool
3.3.2.cKV 는 (S,H), LoRA 는 (R,H) 라 공통 차원 H 가 있다는 관찰이 Unified Paging 의 핵심 §5.1 p.5. pool 은 base weight·activation 을 뺀 GPU 공간 전부를 처음에 한 번에 잡는다. (그림 논문에 없음)
3.3.3보강 KV 저장 방식은 바뀌지 않는다. KV 는 PagedAttention 그대로 token 1개 = page 1개(길이 H)로 저장되고, 새로 바뀐 것은 LoRA weight 도 같은 pool 에 rank 1줄 = page 1개로 넣는다는 점뿐이다 §5.1 p.5.
왜 이렇게 하나
KV cacheLoRA weight
3.3.3.1shape(S, H)(R, H)
3.3.3.2크기가 변하는 이유요청마다 S 가 다르고 decode 로 자람adapter 마다 R 이 다르고 batch 마다 load·offload
3.3.3.3page 수S 개R 개
pool 을 KV 용·adapter 용으로 따로 나누면 한쪽이 남아도 다른 쪽이 못 쓴다. 둘 다 H 벡터 단위라 한 pool 에 섞어 두면 빈 page 를 누구나 쓸 수 있어 fragmentation 이 줄어든다 §5.1 p.5.
참고: 같은 prompt 라도 adapter 가 다르면 Wk·Wv 에 LoRA 가 붙어 KV 값 자체는 달라질 수 있다. 이것은 저장 방식이 아니라 값의 차이다 논문에 없음.

3.4custom kernel: MBGMM · MBGMV

3.4.1
kernel단계하는 일구현
3.4.1.1MBGMMprefillMulti-size Batched Gather Matrix-Matrix: token 여럿 × pool 에서 모은(gather) 서로 다른 rank 의 adapterTriton, tiling
3.4.1.2MBGMVdecodeMulti-size Batched Gather Matrix-Vector: token 하나 × 서로 다른 rank adapterPunica kernel 을 고쳐 비연속 메모리·여러 rank 지원 (Triton 판보다 빨라 실험에 사용)

§5.3 p.5 padding 없이 page 주소를 따라가며 읽으므로 BLAS batch GEMM 의 낭비가 없다.

3.5④ S-LoRA TP: LoRA 통신을 base 통신에 얹기

3.5.1 Fig.4
3.5.1.cFigure 4. Tensor parallelism partition strategy for batched LoRA computation. B = token 수, h = 입력 차원, N = GPU 수, d = hidden size, r = rank. (p.6) 위 상자는 Megatron 방식 base MLP (W1 column, W2 row 분할 → all-reduce 1 번). 아래 상자가 LoRA: A1·B1 은 column 분할 + 작은 (B,r) 텐서 all-gather, A2 는 row·B2 는 column 분할 + (B,r) all-reduce. 마지막 matmul_4 의 all-gather 를 base 의 all-reduce 와 합쳐(빨간 상자) 큰 텐서 통신은 base 것 한 번뿐이다 §6.1 p.6.
3.5.2 base 통신 = 2(N−1)·B·h / N§6.2
LoRA 추가 통신 = 3(N−1)·B·r / N + 2(N−1)·B·r / N = 5(N−1)·B·r / N§6.2 p.6
비율 = LoRA / base = 5r / (2h)논문에 없음
3.5.3
항목뜻
3.5.3.13(N−1)Br/Nq·k·v projection 세 개의 all-gather (크기 B×r)
3.5.3.22(N−1)Br/Noutput projection 의 all-reduce (크기 B×r)
3.5.3.3r ≪ h그래서 LoRA 통신은 무시할 만하다. 메모리 면에서도 모든 weight 를 나눠 복제가 없어 최적 §6.2 p.6
3.5.4
통신 비율 계산기 — rank 와 hidden size 로 LoRA 추가 통신 비율 보기 논문에 없음
scheduling: adapter clustering · early abort admission control
    3.5.5
  • 3.5.5.1adapter clustering: 같은 adapter 요청을 우선 묶어 batch 안 adapter 수(d)를 줄이면 KV 에 메모리를 더 줄 수 있다. 대신 평균 latency·adapter 간 공정성이 나빠질 수 있다 §4.2 p.4, App.A.2 p.15.
  • 3.5.5.2early abort: 사용자 만족도 reward r(t) (first token latency t 가 SLO 를 넘으면 0) 의 합을 최대화. r'(t) ≤ 0 이면 "가장 최근 l 개를 도착 순서대로" 가 최적 (Theorem B.1) App.B p.15–16.
  • 3.5.5.3실제 heuristic: 현재시각 − 도착시각 + 최대 prefill 시간 > SLO 인 요청은 먼저 버린다. 도착률 R1 > 처리율 R2 (과부하) 면 최신 요청부터, 아니면 오래된 요청부터 넣는다 App.B p.16.

4구현

LightLLM (PyTorch + Triton 기반 단일 모델 serving 시스템) 위에 만들었다 §7 p.6–7.
scheduling 은 Orca 식 iteration-level batching, 기본은 FCFS. decode kernel 은 Punica 를 고친 MBGMV.

실험 구성 (Table 1 · 하드웨어 · baseline)
4.1Table 1
4.1.cTable 1. Model and adapter configurations. (p.7)S2·S4 처럼 한 설정 안에 rank 가 섞여 있어 heterogeneous batching 을 시험한다. Llama-70B 는 공식과 다른 구조로 GQA 를 쓰지 않았다 (각주 1).
4.2
baseline무엇
4.2.1HuggingFace PEFT한 adapter 요청만 묶고 batch 사이에 adapter 교체. KV cache·continuous batching 없음
4.2.2vLLM-packed당시 vLLM 은 LoRA 미지원 → merge 된 모델마다 vLLM worker 하나, NVIDIA MPS 로 한 GPU 공유
4.2.3S-LoRA-no-unify-memUnified Paging 제거
4.2.4S-LoRA-bmmUnified Paging + custom kernel 제거. adapter 를 연속 메모리에 복사하고 padding 한 batch matmul

GPU: A10G 24GB, A100 40/80GB (1·2·4 장). host memory 64~670 GB §7.1 p.7.

5평가

합성 workload (Gamma 도착, adapter 인기도 power-law α) 와 LMSYS Chatbot Arena trace 로 throughput · latency · SLO attainment 를 잰다.
좋아진 이유는 세 가지: 서로 다른 adapter 도 한 batch (vs PEFT·vLLM-packed), 흩어진 page 로 메모리 효율 (vs no-unify-mem), padding 없는 kernel (vs bmm).

5.1Table 3
5.1.cTable 3. Throughput (req/s) comparison between S-LoRA, vLLM-packed, and PEFT. A100 (80GB). (p.8) S-LoRA 는 adapter 2,000 개에서도 7.61 req/s (S1). vLLM-packed 는 n=100 부터 OOM, PEFT 는 0.13~0.88 req/s.
vLLM-packed 는 모델 사본을 n 벌 둬야 해 n=5 에서 이미 느리고 (8.05 vs 2.04 → 약 4×) n=100 이면 OOM 이며, 사본끼리 batch 를 못 묶는다. PEFT 는 KV cache 가 없어 최대 batch 가 6 (S-LoRA 30) 이고 continuous batching 이 없어 짧은 요청이 긴 요청을 기다린다 → 최대 30× §7.2 p.8, App.A.1 p.15.
5.2Fig.5
5.2.cFigure 5. The throughput and average request latency of S-LoRA and its variants under different numbers of adapters. (p.8) adapter 수를 늘리면 S-LoRA(파랑) throughput 은 처음에 조금 내려가다가 약 100 개부터 평평하다. no-unify-mem(초록)은 더 낮고 latency 가 크며, bmm(주황)은 훨씬 낮다.
adapter 가 아무리 많아도 한 batch 에서 동시에 쓰이는 adapter 수는 batch 크기로 묶여 있어 LoRA overhead 가 일정해진다. no-unify-mem 과의 차이 = Unified Paging 효과, bmm 과의 차이 = custom kernel 효과 §7.2 p.8.
Table 2 · Fig.6 · Fig.7 — 요청률을 올리면, 실제 trace 에서는
5.3Table 2
5.3.cTable 2. Default parameters for generating the synthetic workloads. (p.7)n = adapter 수, α = 인기도 power-law 지수, R = 총 요청률 (req/s), cv = 도착 간격 변동계수, 입출력 길이는 U[8,512]. 한 번에 한 변수만 바꿔 본다.
5.4Fig.6
5.4.cFigure 6. The throughput, first token latency, and SLO attainment of S-LoRA and its variants under different request rates. (p.9) 요청률을 올리면 no-unify-mem 의 SLO attainment 가 먼저 무너진다 (A10G 는 1.5, A100 은 4 에서 급락). S-LoRA 는 한 단계 더 버틴다 (plot 읽음). page 단위 할당으로 같은 메모리에 KV 를 더 많이 담아 batch 가 커지므로, 처리 용량이 높아 대기열이 늦게 쌓인다 §7.2 p.8.
5.5Fig.7
5.5.cFigure 7. The throughput of S-LoRA and its variants on real workload traces with different request rates. S2 on an A10G (24GB). (p.9) Chatbot Arena trace (평균 입력 85 · 출력 165 token, adapter 약 26 개) 에서도 합성 workload 와 같은 순서가 나온다 §7.3 p.9. Arena 의 "서로 다른 base 모델" 분포를 "한 base 의 서로 다른 adapter" 분포로 간주한 trace 다. 원인은 Fig.5–6 과 같다.
Fig.8 — multi-GPU tensor parallelism
5.6Fig.8
5.6.cFigure 8. Throughput with tensor parallelism. (p.9) 파랑(S-LoRA)과 주황(LoRA 통신 제외)의 차이가 작다 = LoRA 통신 overhead 가 작다. 주황과 초록(base only)의 차이가 더 크다 = LoRA 비용은 통신보다 계산 쪽. 2 → 4 GPU 에서 throughput 이 2 배 넘게 오른다. §6 에서 LoRA 통신을 (B,r) 작은 텐서에만 두고 큰 통신은 base all-reduce 와 합쳤기 때문. 초선형 증가는 memory-bound 상황에서 GPU 를 늘리면 KV 공간이 늘어 batch 가 커지기 때문 §7.4 p.9.
Fig.9 · Fig.10 — ablation: merge vs on-the-fly, early abort
5.7Fig.9
5.7.cFigure 9. Ablation study comparing adapter merging and on-the-fly compute for S2 on A10G (24GB). (p.10) adapter 1 개면 merge(점선)가 on-the-fly(실선)보다 빠르지만 2 개부터 역전되고 5 개에서 크게 떨어진다. α 가 작을수록(요청이 고르게 분산) merge 가 더 나빠진다. merge 는 LoRA 계산이 없지만 adapter 를 바꿀 때마다 weight 를 고치는 동안 GPU 가 논다. on-the-fly 는 교체가 없다 §7.5 p.9–10.
5.8Fig.10
5.8.cFigure 10. Ablation study for early abort scheduling strategy. (p.10) S-LoRA-Abort(초록)가 SLO attainment · user satisfaction 모두 가장 높고 cv 가 커질수록 차이가 벌어진다. FCFS 가 가장 낮다. FCFS 는 이미 SLO 를 놓친 요청까지 처리하느라 시간을 쓴다. LCFS 는 최신만 챙겨 cv 가 크면 나빠진다. Abort 는 놓칠 요청을 먼저 버리고 과부하 여부에 따라 순서를 바꾼다 §7.5 p.10.
부록 — PEFT 분석 (Table 4·5) · adapter clustering (Fig.11·12)
5.9Table 4
5.9.cTable 4. PEFT results on the synthetic workload S1 against number of adapters. (p.15)adapter 1 개에서도 0.26 req/s, 200 개면 0.17. attainment 는 전부 0.
5.10Table 5
5.10.cTable 5. PEFT results on the synthetic workload S1 against request rate. (p.15)가장 낮은 요청률 1 req/s 에서도 평균 latency 1,165 s. 요청률이 PEFT 용량을 이미 넘었다 App.A.1 p.15.
5.11Fig.11
5.11.cFigure 11. Ablation study for different number of clusters on A100 (40GB) with different α. (p.15)cluster 수 d 를 1~32 로 바꿔도 차이는 작지만, 대체로 작은 d 가 약간 낫다.
5.12Fig.12
5.12.cFigure 12. Ablation study for different number of clusters on S2 (Llama-7b) A100 (80GB) with different cv. (p.15)cv 가 클수록 d 의 영향이 보인다 (cv 4·6·8 에서 d=32 의 SLO attainment 가 가장 낮음). 논문은 작은 d 의 요동을 scheduler overhead 와 random noise 로 설명한다 App.A.2 p.15.

6결론과 한계

논문의 결론: unified memory pool, tensor parallelism, adapter batching, CUDA kernel 로 한 머신에서 LoRA adapter 수천 개를 높은 throughput 으로 서비스한다 §9 p.11.
향후 과제로 다른 adapter 방식 지원, 더 fused 된 kernel, base·LoRA 계산을 여러 CUDA stream 으로 병렬화를 든다. limitation 절은 없어 아래는 읽으며 정리했다 논문에 없음.

6.1
한계근거
6.1.1KV cache 는 요청이 끝나면 해제된다. 같은 prefix·다회 대화의 history KV 재사용이 없다"KV caches are allocated when requests arrive and deallocated once the requests are completed" (§5.1 p.5)
6.1.2adapter 수가 적으면 on-the-fly 계산 overhead 때문에 merge 보다 느리다Fig.9 (adapter 1 개), Fig.5 초반 하락
6.1.3prefetch 는 대기열만 보고 예측한다. 대기열에 없던 cold adapter 가 오면 로딩을 기다린다. 로딩 지연을 따로 측정한 결과는 없다§5.2 p.5
6.1.4vLLM baseline 은 당시 LoRA 미지원이라 merge 사본 + MPS 로 만든 것. 이후 vLLM·Punica 의 native multi-LoRA 와의 비교는 없다§7.1 p.7, Punica 는 concurrent work (§8 p.10)
6.1.5실제 LoRA 서비스 trace 가 아니다. 합성 Gamma 과정과 Arena 의 "base 모델 분포" 를 adapter 분포로 간주한 trace§7.2–7.3 p.7–9
6.1.6Llama-70B 는 공식과 다른 구조, GQA 미사용. 실제 70B 에서 KV·통신 비율이 달라진다Table 1 각주 1 (p.7)
6.1.7early abort 는 SLO 를 놓칠 요청을 버린다. 버린 요청 비율은 따로 보고하지 않는다App.B p.16

7관련 연구

가장 가까운 것은 Punica (base·adapter 계산 분리, concurrent work) 와 PetS (BERT 급 encoder 전용). S-LoRA 의 차별점은 Unified Paging 과 LoRA tensor parallelism §8 p.10.
quantization·sparsification 같은 알고리즘 기법과는 직교해 함께 쓸 수 있다.

관련 연구 한 줄씩
7.1
연구한 일S-LoRA 와 차이
7.1.1Punicamulti-LoRA 에서 base·adapter 계산 분리, SGMV kernelS-LoRA decode kernel 의 바탕. 메모리 관리·TP 는 없음
7.1.2PetSparameter-efficient transformer 통합 serving작은 encoder-only BERT 만. 생성·대량 adapter·multi-GPU 없음
7.1.3Orca · vLLMiteration-level batching · PagedAttentionS-LoRA 가 가져다 쓰고 paging 을 adapter 로 확장
7.1.4Clipper · AlpaServe 등일반 모델 serving (batching, placement, 다중화)autoregressive 특성과 adapter 를 고려하지 않음
7.1.5Prefix-tuning · (IA)³ 등 PEFTLoRA 외 적은 parameter fine-tuning대부분 기법을 쉽게 적용 가능하다고 주장