HPCA 2026 · Shi et al. (SJTU · PolyU · Huawei Cloud · HKUST) · DOI 10.1109/HPCA68181.2026.11408492

ELORA: Multi-LoRA serving 에서 adapter weight 와 KV cache 를 한 pool 에서, usage dependency 를 지키며 관리하기

원문 papers/elora-hpca26.pdf (14쪽) · §III-D p.4 = 논문이 그렇게 쓴 절·쪽 · 해석 = 논문 내용에서 요약자가 끌어낸 설명 · 논문에 없음 = 배경지식·예시 · 용어는 1 절 용어표의 뜻으로만 쓴다 · 그림은 누르면 크게 열린다

0한눈에 보기

한 base 모델에 LoRA adapter 여러 개를 붙여 서비스하면, KV cache 는 그것을 계산한 adapter 마다 따로 생기고 그 adapter 의 adapter weight 가 GPU HBM 에 있어야 쓸 수 있다 §I p.1 §III-A p.3.
vLLM 은 adapter weight 와 KV cache 를 고정 분할한 두 영역에서 따로 swap 하며, 이때 invalid KV 가 평균 42.4% 관측됐다. ELORA 는 둘을 한 dependency tree 와 한 cost model 로 관리해 vLLM 대비 TTFT 를 평균 45.7% 줄였다 §VIII-B p.9.

0.1
0.1.1기 상황
하나의 base 모델에 작업별 LoRA adapter 여러 개를 붙여 서비스한다(Multi-LoRA serving). 논문 주 실험은 adapter 20·50·100 개, 확장성 실험은 1,000·2,000 개다 §III-C p.4 §VIII-I p.12. adapter weight 와 KV cache 가 GPU HBM 을 두고 다툰다 §III-A p.3.
0.1.2승 문제
vLLM 은 GPU HBM 을 adapter 영역과 KV 영역으로 고정 분할하고 영역마다 LRU 로 swap 한다(실험 설정은 adapter 영역 0.2). 부하가 바뀌면 한 영역만 가득 차 TTFT 가 수 초로 오른다 §III-C p.4. 또 adapter weight 없이 남은 invalid KV 가 GPU HBM 을 차지한다 §III-D1 p.4–5.
0.1.3전 기법
① dependency tree 는 virtual root → LoRA node → 그 adapter 의 KV node 순으로 잇는다. GPU HBM 의 leaf 부터 swap-out 하고 host main memory 쪽 subtree 의 맨 위 node 부터 swap-in 해, GPU HBM 의 KV cache 를 모두 valid 하게 유지한다 §V-B p.7. ② cost model 은 adapter 개수 충족률 × swap 비용 × 방문 빈도 × 최근성 점수로 GPU HBM 에 남길 node 를 정한다 §VI-B p.7–8.
0.1.4결 결과
H800 에서 Llama3-8B·Llama2-34B·Llama3-70B × adapter 20·50·100 개 × 3 시나리오, 27 조합 평균으로 vLLM 대비 TTFT −45.7%, TPOT −37.8%, peak load +78.9% 다 §VIII-B p.9.
0.2보강 dependency tree 는 이렇게 생겼다
0.3 virtual root LoRA-1 LoRA-2 in "To" "be" "or" out "the" in "not" "best" "Hi" "there" 1 층 ← 2 층: LoRA node ← 3 층~: KV node
LoRA node (GPU HBM)KV node (GPU HBM)점선 = host main memory굵은 선 = query "To be or" 의 match 경로
0.3.cvirtual root 아래 2 층에 adapter 마다 LoRA node 가 하나씩 있고, 그 아래로 그 adapter 로 계산한 KV node 가 token 순서대로 이어진다. "To be" 뒤에 "or …" 와 "the best" 처럼 다른 문장이 오면 가지가 갈라진다 §V-A p.6. 이 그림의 token 과 GPU HBM·host main memory 배치는 예시다 논문에 없음.
0.4
그림 요소뜻근거
0.4.10.2.1virtual rootadapter 별 subtree 를 한 tree 로 묶으려고 둔 가상 node. 데이터는 없다§V-A p.6
0.4.20.2.2LoRA nodeadapter 하나(label = LoRA ID). query 는 여기서 자기 adapter 를 먼저 match 한다§V-A p.6
0.4.30.2.3KV nodetoken 열의 KV cache(label = token 열의 hash). 부모 node 가 있어야 쓸 수 있다§V-A p.6
0.4.40.2.4굵은 선query 는 LoRA-1 을 match 한 뒤 DFS 로 "To" → "be" → "or" 순서로 가장 긴 prefix 를 찾는다§V-B p.6–7
0.4.50.2.5outswap-out 은 GPU HBM 의 leaf 에서 시작한다. "or" 는 GPU HBM 쪽 가지의 끝이라 후보다§V-B p.7 · 후보 판정은 해석
0.4.60.2.6inswap-in 은 host main memory 쪽 subtree 의 맨 위 node 에서 시작한다. "the" 와 LoRA-2 가 후보다. "Hi" 는 LoRA-2 가 올라오기 전에는 올라올 수 없다§V-B p.7 · 예시는 해석

그림을 보면 GPU HBM 에 있는 node 가 항상 가지의 위쪽에 모여 있다. 아래에서만 빼고 위에서부터만 넣으니, GPU HBM 의 KV node 는 부모 node(LoRA node 포함)도 GPU HBM 에 있다. 논문은 이 규칙으로 GPU HBM 의 KV cache 가 모두 valid 하다고 쓴다 §V-B p.7.

0.5
0.5.1
42.4%
vLLM 의 invalid KV 비율 (§VIII 평가 평균)
0.5.2
−45.7%
TTFT (vLLM 대비, 27 조합 평균)
0.5.3
−37.8%
TPOT (vLLM 대비, 27 조합 평균)
0.5.4
+78.9%
peak load (TTFT < 500 ms 유지 최대 QPS, vLLM 대비)

1배경: LoRA adapter 와 KV cache 의 관계

LoRA 는 base weight $W$ 는 고정하고 작은 행렬 한 쌍 $A_t$, $B_t$ 만 학습하는 fine-tuning 기법이다. 이 한 쌍(adapter $t$)이 $W_K$·$W_V$ 에 더해지면 Key·Value 계산식이 바뀐다 §III-A p.3.
그래서 같은 token 이라도 adapter 마다 KV cache 가 다르고, 그 KV cache 로 query 를 실행하려면 같은 adapter 의 adapter weight 가 GPU HBM 에 있어야 한다 §I p.1.

1.1용어표

1.1.1
용어정확한 뜻 (이 요약에서)기호논문 원문 표기
1.1.1.1LoRAbase weight 는 고정하고 low-rank 행렬 한 쌍만 학습하는 fine-tuning 기법. 이 요약은 기법 이름으로만 쓴다–"LoRA [20] is a popular method" (§III-A p.3). 원문은 "LoRA" 를 adapter 한 벌("LoRA for short", §I p.1)과 adapter weight("caching hot LoRAs")에도 쓴다
1.1.1.2adapter $t$작업 $t$ 용으로 학습된 행렬 한 쌍 $A_t$, $B_t$ 한 벌. LoRA adapter 라고도 쓴다$A_t$, $B_t$"a unique pair of low-rank matrices $A_t$ and $B_t$" (§III-A p.3), "LoRA adapters"
1.1.1.3LoRA-$i$ · KV$i$-$j$논문 그림의 label. LoRA-$i$ = adapter $i$, KV$i$-$j$ = adapter $i$ branch 의 $j$ 번째 KV node–Fig.1·3·6·8
1.1.1.4adapter weightadapter $t$ 의 $A_t$, $B_t$ 가 GPU HBM 또는 host main memory 에 차지하는 data. swap·cache 의 대상–"LoRAs" ("swap in LoRAs", "LoRA cold-start")
1.1.1.5base weight모든 adapter 가 공유하는 원래 weight. GPU HBM 에 한 벌 상주한다$W$, $W_K$, $W_V$"original weight matrix", "Resident Base Model" (Fig.1)
1.1.1.6KV cachehidden state $h$ 에 adapter $t$ 를 적용해 계산한 Key·Value. 계산한 adapter 가 정해져 있다$K_t$, $V_t$"KV caches", "KVs"
1.1.1.7history KV이전 query 가 남긴 KV cache. prefix 가 맞으면 재사용한다–"history KV caches"
1.1.1.8running KV지금 실행 중인 query 의 KV cache–"running KV caches" (§II p.2, Fig.14)
1.1.1.9invalid KVGPU HBM 에 있지만 그것을 계산한 adapter 의 adapter weight 가 GPU HBM 에 없어 query 가 쓸 수 없는 KV cache–"invalid KV caches" (§I p.1). 비율의 분모(전체 KV 인지 history KV 인지)는 원문에 명시 없음
1.1.1.10usage dependencyKV cache 는 자기 adapter weight 가, 뒤 token 의 KV cache 는 앞 token 의 KV cache 가 먼저 있어야 쓸 수 있다는 관계–"usage dependencies" (§I p.1, §V-A p.6)
1.1.1.11GPU HBM / host main memoryGPU 메모리(H800 한 장 80 GB) / CPU 쪽 DRAM(256 GB)–"GPU memory" / "main memory", "host memory". "HBM" 은 요약의 표기
1.1.1.12adapter 영역 / KV 영역vLLM 이 GPU HBM 을 고정 비율로 나눈 두 구역. 실험 설정은 0.2 / 0.8–"GPU memory space for LoRAs / KVs" (§III-C p.4)
1.1.1.13unified caching pool · blockadapter weight 와 KV cache 를 같은 고정 크기 block 에 담는 하나의 pool. block 예시 크기 16 MB–"unified caching pool", "memory block" (§VII p.8, §VIII-L p.12)
1.1.1.14nodedependency tree 의 원소. LoRA node 와 KV node 가 있다$i$§V-A p.6 은 "block 1 개 = node 1 개" 라 쓰고, Fig.7 은 adapter 하나를 LoRA node 하나로 그린다
1.1.1.15virtual root · 2nd layer · leaf · branchvirtual root = LoRA node 별 subtree 들을 잇는 가상 node, 2nd layer = LoRA node 층, leaf = 자식 없는 node, branch = LoRA node 하나 아래 subtree–"virtual root node", "second layer", "leaves", "LoRA branch". 원문은 swap-in 후보도 "root nodes of each subtree in the main memory" 라 불러 virtual root 와 이름이 겹친다 (§V-B p.7)
1.1.1.16swap-in / swap-outhost main memory → GPU HBM 으로 올리기 / 그 반대–"swap in/out", "load", "offload", "evict" 혼용
1.1.1.17cold-start필요한 adapter weight 나 KV cache 를 GPU HBM 으로 다시 올리는 동안의 지연. LoRA cold-start / KV cold-start 로 나눈다–"cold starts" (§III-A p.3), Fig.12
1.1.1.18TTFT · TPOTquery 의 첫 output token 까지 시간 · 그 뒤 token 하나당 시간. 논문 수치는 query 평균–"Time-To-First-Token", "Time-Per-Output-Token" (§I p.2, §VIII-A p.9)
1.1.1.19peak loadTTFT < 500 ms 를 지키는 최대 QPS–"supported peak load" (§VIII-A p.9)
1.1.1.20Evalnode $i$ 를 GPU HBM 에 남겼을 때의 TTFT 이득 점수 (Eq.6)$\mathrm{Eval}_i$"benefits to TTFT" (§VI-B p.7). 원문의 "access benefits" 는 assess 의 오기로 보인다

1.2LoRA adapter 는 어디에 붙나

1.2.1
$W$ = base weight 행렬 (모든 adapter 가 공유) · $t$ = 작업 번호 = adapter 번호 · $A_t$, $B_t$ = adapter $t$ 의 low-rank 행렬 한 쌍 · $r$ = rank, 실험에서 32 또는 64 §III-B p.3 · 크기 $d\times r$, $r\times d$ 는 요약의 표기 논문에 없음
$$W'_t = W + \Delta W_t = W + A_t B_t$$Eq.1 · §III-A p.3
작업 $t$ 용 weight 는 base weight $W$ 에 $A_t B_t$ 를 더한 것이다. base 모델은 한 번만 load 하고, 작업마다 $A_t$, $B_t$ 한 쌍만 따로 둔다 §III-A p.3.
1.2.2보강 LoRA 의 rank $r$ 은 $A_t$ 와 $B_t$ 가 공유하는 안쪽 차원의 크기다 논문에 없음
1.2.3 A dr × B rd = ΔWₜd × d 검은 줄 = rank 방향으로 자른 조각 (그림은 r = 4)
1.2.3.c$A_t$ 는 $d\times r$, $B_t$ 는 $r\times d$ 이고, 둘이 맞닿는 차원이 $r$ 이다. 곱 $A_t B_t$ 는 $d\times d$ 크기지만 행렬의 rank(서로 독립인 행의 수)가 $r$ 을 넘지 않는다. 그래서 "low-rank" 라 부르고 $r$ 을 rank 라 한다.

크기 예시: $d = 4096$, $r = 32$ 이면 $W$ 하나는 $4096^2 \approx 1{,}680$ 만 개 값이고, $A_t$ 와 $B_t$ 는 합쳐 $2 \times 4096 \times 32 \approx 26$ 만 개 값으로 약 1.6% 다. 그래서 작업마다 adapter 를 따로 두어도 GPU HBM 을 적게 쓴다. ELORA 가 adapter weight 를 "rank 방향으로 자른다" 는 말은 그림의 검은 줄처럼 $A_t$ 를 길이 $d$ 의 열 $r$ 개, $B_t$ 를 길이 $d$ 의 행 $r$ 개로 나눈다는 뜻이다 §VII p.8. tensor parallel 의 rank(GPU 번호)와는 관계가 없다.

1.2.4보강 rank $r$ 은 요청마다 바꾸는 값이 아니다. adapter 를 학습할 때 정해져 그 adapter 에 고정된다 논문에 없음
1.2.5 요청등록된 adapter (r 은 학습 때 고정) Q1 Q2 Q3 adapter-1 · r = 32 adapter-2 · r = 32 adapter-3 · r = 64 요청이 고르는 것은 adapter 다. r 은 고른 adapter 에 딸려 온다
1.2.5.cQ1 과 Q3 는 adapter-1 을 골라 $r=32$ 인 $A_t$, $B_t$ 로 계산하고, Q2 는 adapter-3 을 골라 $r=64$ 로 계산한다. 요청이 $r$ 을 바꾸지는 못한다.

adapter 는 작업별로 따로 학습한 $A_t$, $B_t$ 한 쌍이고, $r$ 은 학습을 시작할 때 정하는 크기다. 학습이 끝나면 $A_t$, $B_t$ 의 값과 $r$ 이 함께 파일로 저장된다. 서버는 이 파일들을 등록해 두고, 요청은 그중 하나를 지정한다 §III-A p.3. 그래서 같은 서버에서 $r$ 이 다른 adapter 가 함께 쓰일 수 있다. 논문 실험의 adapter 는 $r$ 이 32 또는 64 였고 §III-B p.3, ELORA 는 $r$ 이 다른 adapter 를 쓰는 요청을 한 batch 로 묶으려고 SGMV 를 쓴다 §VII p.8.

1.2.6 Transformer layer 1 개 (모든 layer 에 반복) h W_Q W_K W_V +A·B +A·B +A·B Q K V KVcache W_O · MLP 에도 붙일 수 있다 (생략)
base weight (모든 query 공유)adapter $t$ 의 $A_t B_t$ (query 가 지정한 것)K·V = KV cache 로 저장되는 값
1.2.6.cadapter 는 모델 앞이나 뒤에 붙는 별도 layer 가 아니다. projection weight 옆에 low-rank branch 로 붙어 그 출력을 바꾼다 §III-A p.3. 논문 Eq.2 는 $W_K$·$W_V$ 에 붙는 경우만 적었다. 그림처럼 모든 layer 와 $W_Q$·$W_O$·MLP 에도 붙이는 것은 일반적인 LoRA 설정이다 논문에 없음.

1.3한 projection 을 확대하면

1.3.1
$h$ = 특정 layer 의 hidden state · $W_K$, $W_V$ = base weight 의 Key·Value 행렬 · $A_{t,K} B_{t,K}$ = adapter $t$ 가 $W_K$ 에 더하는 항 · $K_t$, $V_t$ = adapter $t$ 를 적용해 계산한 Key·Value
$$\begin{aligned} K_t &= (W_K + A_{t,K} B_{t,K})\,h \\ V_t &= (W_V + A_{t,V} B_{t,V})\,h \end{aligned}$$Eq.2 · §III-A p.3
같은 $h$ 라도 adapter 가 다르면 더해지는 $AB$ 가 달라 $K_t$, $V_t$ 가 달라진다. 논문은 그래서 adapter 마다 KV cache 를 따로 저장해야 한다고 쓴다 §III-A p.3.
1.3.2 h W_Kd×d A B d×r · r×d (r ≪ d) + K_t LoRA t전용
1.3.2.c$h$ 는 두 길로 갈라진다. 위는 모든 query 가 공유하는 $W_K$, 아래는 query 가 지정한 adapter $t$ 의 $A_{t,K}$·$B_{t,K}$ 다. 둘을 더한 $K_t$ 는 adapter $t$ 의 adapter weight 가 있어야 계산된다 §III-A p.3.

1.4같은 문장인데 adapter 마다 KV cache 가 다르다

1.4.1 같은 prompt "To be or" 의 K (token "be": h = [1, 2]) Tobeor base … [1,2] … LoRA-1 … [3,2] … LoRA-2 … [1,3] …
1.4.1.c한 문장을 adapter 두 개로 처리하면 KV cache 도 두 벌 생기고, 따로 저장해야 한다 §III-A p.3. 숫자는 $d=2$, $r=1$ 로 줄인 예시다 논문에 없음.
1.4.2
$A$ ($2\times1$)$B$ ($1\times2$)$W_K + AB$$K = (W_K + AB)\,h$
1.4.2.1base weight 만––$\begin{bmatrix}1&0\\0&1\end{bmatrix}$$[1,\ 2]$
1.4.2.2LoRA-1$[1,\ 0]^\top$$[0,\ 1]$$\begin{bmatrix}1&1\\0&1\end{bmatrix}$$[3,\ 2]$
1.4.2.3LoRA-2$[0,\ 1]^\top$$[1,\ 0]$$\begin{bmatrix}1&0\\1&1\end{bmatrix}$$[1,\ 3]$

앞 layer 에서 adapter 가 출력을 바꾸면 다음 layer 에 들어가는 $h$ 부터 달라지므로, LoRA-1 로 계산한 KV cache 를 LoRA-2 query 에 그대로 쓸 수 없다 해석. 또 history KV 를 재사용해도 새 token 을 계산하려면 그 adapter 의 adapter weight 가 GPU HBM 에 있어야 한다 §III-A p.3. 논문은 이 관계를 usage dependency 라 부르고, adapter weight 가 GPU HBM 에 없는 KV cache 를 invalid KV 라 부른다 §I p.1.

1.5query 마다 adapter 는 누가 정하나

논문은 query 의 task 에 따라 해당 adapter 의 $A_t$, $B_t$ 를 GPU HBM 에 load 한다고 쓴다 §III-A p.3. 실험에서는 dataset 의 속성(model 이름·언어 쌍·task scene)으로 query 마다 adapter 를 정했다 §III-B p.3. 모델이 adapter 를 자동으로 고르는 routing 은 논문이 다루지 않는다 해석. vLLM 에서는 --lora-modules name=path 로 adapter 를 등록하고 요청의 "model": "name" 으로 고른다 논문에 없음.

1.5.1
실험 시나리오query 내용 → adapter 대응도착 시각
1.5.1.1chatbotLMSYS-33k 대화. trace 의 model 이름으로 adapter 를 정한다 §III-B p.3LMSYS timestamp 를 비율대로 scale
1.5.1.2번역OPUS-100 문장 쌍. 언어 쌍 하나당 adapter 하나 (예: French→English) §III-B p.3MAFT 호출 빈도 상위 $n$ 개 함수의 도착 패턴을 adapter $n$ 개에 대응
1.5.1.3personal agentTaskmaster 대화. task scene 하나당 adapter 하나 §III-B p.3번역과 같은 MAFT 방식

1.6나머지 용어

1.6.1

swap · cold-start

GPU HBM(H800 80 GB)이 모자라면 adapter weight 나 KV cache 를 host main memory(256 GB)로 내리고(swap-out), 필요할 때 PCIe 로 다시 올린다(swap-in). 다시 올릴 때의 지연을 cold-start 라 하고, 논문은 LoRA cold-start 와 KV cold-start 로 나눠 잰다 §III-A p.3 §VIII-C p.10.

TTFT · TPOT · peak load

TTFT 는 query 의 첫 output token 까지 시간, TPOT 는 그 뒤 token 하나당 시간이고, 논문 수치는 query 평균이다. peak load 는 TTFT < 500 ms 를 지키는 최대 QPS 다 §VIII-A p.9. 논문은 queue 대기·LoRA cold-start·KV cold-start 가 TTFT 와 TPOT 모두에 영향을 준다고 쓴다 §III-A p.3.

LRU (Least Recently Used)

가장 오래 안 쓴 것부터 내보내는 교체 규칙이다 논문에 없음. vLLM 은 adapter 영역과 KV 영역에서 LRU 를 따로 쓴다 §III-C p.4. 논문은 LRU 순위와 방문 빈도·swap 비용 순위 사이에 뚜렷한 상관이 없음을 보인다 (Fig.5) §III-D2 p.5.

tree · root · leaf

root 에서 가지가 갈라지는 자료구조이고, 자식이 없는 node 를 leaf 라 한다 논문에 없음. ELORA 는 virtual root → LoRA node(2nd layer) → 앞 token KV node → 뒤 token KV node 순서를 tree 로 적는다 §V-A p.6.

2문제: vLLM 에서 TTFT 가 높아지는 이유

① intra-LoRA: adapter weight 가 swap-out 돼도 그 adapter 의 KV cache 는 GPU HBM 에 남아 invalid KV 가 된다 (vLLM 평균 42.4%) §I p.1.
② inter-LoRA: adapter 영역과 KV 영역이 고정 분할이라 부하가 바뀌면 한 영역만 가득 차고, LRU 순위는 방문 빈도·swap 비용과 뚜렷한 상관이 없다 §III-D2 p.5.

2.1① invalid KV: adapter weight 없이 남은 KV cache

2.1.1 vLLM 의 GPU memory (고정 분할) LoRA 칸 20% LoRA-2 LoRA-3 KV 칸 80% KV1-1 KV1-2 KV2-1 KV3-1 빈칸 CPU main memory LoRA-1 ← Query-1 은 LoRA-1 이 필요 KV1 은 GPU 에 있어도 대기
invalid KV (adapter weight 가 GPU HBM 에 없음)host main memory 로 swap-out 된 adapter weight
2.1.1.c여러 adapter 로 query 가 몰리면 adapter 영역이 모자라 자주 쓰이는 adapter weight 까지 swap-out 되고, 여유가 있는 KV 영역에는 그 adapter 의 KV cache 가 남는다 §III-D1 p.4. Query-1 은 KV1 이 GPU HBM 에 있어도 LoRA-1 의 adapter weight 가 PCIe 로 다시 올라올 때까지 기다린다. KV 영역의 빈 자리는 고정 분할이라 adapter weight 에 쓸 수 없다 §III-C p.4. 논문은 Query-1 이 쓰지 않는 invalid KV(Fig.1 의 KV1-3) 자리에 LoRA-1 을 두었다면 Query-1 이 바로 실행됐을 것이라고 쓴다 §I p.1 (그림 논문에 없음).
2.1.2 Fig.1
2.1.2.cFig. 1: An example caching state to show the Usage Dependencies between LoRAs and KV caches. (p.1) 위 그림의 원본이다. LoRA-1 의 adapter weight 는 main memory 로 swap-out 됐는데 KV1-1·KV1-2·KV1-3 은 GPU HBM 에 남아 있다. Query-1 은 LoRA-1 과 prefix KV1-1·KV1-2 가 필요하다. 그 사이 LoRA-2 의 KV2-2 는 GPU HBM 에 올라오지 못한다 §I p.1.
"In this case, the cached KVs are actually 'invalid', because the query cannot run without the required LoRA, showing their inherent usage dependencies."§I p.1 · invalid KV 평균 42.4% 는 §I p.1, §III-D1 p.5 (§VIII 평가에서 측정)
2.1.3 Fig.3
2.1.3.cFig. 3: Examples of serving two queries under (a) without usage dependencies, (b) maintaining usage dependencies. (p.4) (a) GPU HBM 에 LoRA-2 의 adapter weight 없이 KV2-1 만 남아 있다. Q1 은 KV1-1 을 swap-in 하려고 KV2-1 을 먼저 swap-out 해야 해서 기다리고, Q2 는 나중에 LoRA-2 와 KV2-1 을 다시 swap-in 해야 한다. KV2-1 이 내려갔다 다시 올라오는 중복 swap 이다. (b) usage dependency 를 지키면 Q1 은 바로 실행되고, Q2 는 Q1 이 끝난 뒤 LoRA-1·KV1-1 을 내리고 LoRA-2·KV2-1 을 한 번 올린다. 논문은 두 query 의 응답 시간이 모두 준다고 쓴다 §III-D1 p.4–5.

2.2② 고정 분할과 LRU

2.2.1 Fig.2
2.2.1.cFig. 2: The TTFT of the vLLM for different scenarios. (p.4) Llama2-34B, adapter 50 개 조건에서 부하가 바뀌는 구간마다 vLLM 의 TTFT 가 수천 ms 로 오른다. 평균 TTFT 는 chatbot / 번역 / agent 순으로 1,353.4 / 2,548.9 / 2,339.6 ms 다. 논문은 고정 분할이 부하 변화에 맞춰 바뀌지 못하는 것을 원인으로 든다 §III-C p.4.
2.2.2 Fig.4
2.2.2.cFig. 4: The utilization rate of the GPU memory space allocated to LoRAs and KV caches over time in the translation scenario. (p.5) 번역 시나리오(Fig.2 와 같은 조건)에서 650–1200 s 에는 KV 영역이 가득 찼는데 adapter 영역 사용률은 평균 59.2% 다. 1200 s 이후에는 query 가 쓰는 adapter 가 29 → 48 개로 늘어 반대로 adapter 영역이 가득 찬다 §III-D2 p.5. vLLM 은 두 영역의 block 크기가 달라 남는 영역을 다른 쪽에 쓸 수 없다 §III-C p.4.
Fig.5 — LRU 만으로 부족한 이유
2.2.3 Fig.5
2.2.3.cFig. 5: The relationships among the visited frequency, swap costs, and LRU of the KV caches or LoRAs. (p.5) 점 하나가 adapter weight 또는 KV cache 하나다. LRU 순위·방문 빈도 순위·swap 비용 순위를 짝지어 찍으면 무작위로 흩어져 뚜렷한 상관이 없다. 논문은 그래서 LRU 만으로는 방문 빈도·swap 비용을 반영하지 못한다고 보고, 이를 cost model 의 근거로 든다 §III-D2 p.5.

3기법: ELORA 의 두 부품

① Cache manager: adapter weight 와 KV cache 를 같은 크기 block 의 unified caching pool 에 담고, virtual root → LoRA node → KV node tree 로 usage dependency 를 유지해 GPU HBM 에 invalid KV 가 남지 않게 한다 §V-B p.7.
② Cache swapper: 100 ms 마다 모든 node 의 Eval 을 갱신하고, GPU HBM 이 가득 차면 Eval 이 낮은 leaf 부터 swap-out, 사용률이 낮으면(원문 예: 70% 미만) Eval 이 높은 subtree 맨 위 node 부터 swap-in 한다 §VI-C p.8.

3.0.1 vLLM: 칸막이 LoRA 20% KV 80% ELORA: 같은 크기 block 한 pool
adapter weight blockKV cache block
3.0.1.cELORA 는 adapter weight 도 rank 방향으로 잘라 KV cache 와 같은 크기 block 에 담는다 §VII p.8. 그래서 adapter weight 와 KV cache 의 비율이 시점마다 바뀔 수 있다 §VIII-D p.10. S-LoRA 도 이런 pool 을 쓰지만 history KV 는 담지 않고, ELORA 는 pool 을 history KV 까지 넓혔다 §VII p.8 (그림 논문에 없음).
3.0.2 Fig.6
3.0.2.cFig. 6: Design overview of ELORA. (p.5) ① GPU HBM 이 가득 차면 cache swapper 가 cost model 로 가장 cold 한 KV2-1 을 고르고 ② cache manager 가 swap-out 한다. ③ 새 query 가 오면 tree 에서 LoRA-1 → KV1-1 순으로 match 하고 ④ 새로 만든 KV cache 를 LoRA-1 branch 의 leaf 에 붙인다 §IV p.5–6.
3.0.3보강 Fig.6 을 읽기 전에: 누가 무엇을 swap 하나

ELORA 는 일을 두 부품에 나눈다. cache swapper 는 tree 의 node 마다 "GPU HBM 에 남길 가치" 점수 $\mathrm{Eval}_i$ 를 계산하고 swap 순서를 정한다. cache manager 는 GPU HBM 이 얼마나 찼는지 보고 swap 을 요청하고, 정해진 순서대로 실제 memory 이동을 한다 §IV p.5–6. swap 하는 대상은 node 하나, 즉 adapter weight 또는 KV cache 의 고정 크기 block 하나다 §V-A p.6.

3.0.4 cache manager cache swapper ① 모든 node 의 Eval 을다시 계산 (100 ms 마다) ② GPU HBM 가득 참→ swap-out 요청 요청 받음 ③ 후보 = GPU HBM 에있는 leaf node 들 ④ 후보를 Eval오름차순으로 정렬 ⑤ Eval 낮은 node 부터하나씩 swap-out
3.0.4.cswap-out 의 순서다. adapter weight node 하나를 내보낼 때마다 GPU HBM 의 adapter 수가 바뀌므로 Eval 을 다시 계산한다 §VI-C p.8 (그림 논문에 없음, 순서는 Fig.10).
3.0.5
swap-outswap-in
3.0.5.13.0.3.1언제GPU HBM 이 가득 찼을 때GPU HBM 이 비었을 때 (원문 예: 사용률 70% 미만)
3.0.5.23.0.3.2후보GPU HBM 에 있는 leaf nodehost main memory 쪽 subtree 의 맨 위 node
3.0.5.33.0.3.3순서$\mathrm{Eval}_i$ 낮은 것부터$\mathrm{Eval}_i$ 높은 것부터
3.0.5.43.0.3.4Fig.6 예② KV2-1 (가장 cold 한 leaf)Fig.6 에는 없음

출처: §VI-C p.8 · §V-B p.7

3.0.6
$i$ = tree 의 node 하나 · $\mathrm{NowLoRA}_i$ = node $i$ 를 swap 한 뒤 GPU HBM 에 남는 adapter 수 · $\mathrm{Low}_{lora}$ = 최근 batch 에 필요할 것으로 기대되는 adapter 수 · $cost_i$ = node $i$ 를 PCIe 로 옮기는 시간 · $visit_i$ = query 가 node $i$ 를 사용한 빈도 확률 · $t_i$ = 지금 − query 가 node $i$ 를 마지막으로 사용한 시각
$$\begin{aligned} \mathrm{Eval}_i &= \min\!\left(1,\ \frac{\mathrm{NowLoRA}_i}{\mathrm{Low}_{lora}}\right) \\ &\quad \times cost_i \times visit_i \\ &\quad \times \bigl(1 - \mathrm{sigmoid}(t_i)\bigr) \end{aligned}$$Eq.4–6 · §VI-B p.7–8
첫 항은 GPU HBM 의 adapter 수가 기대치보다 모자라지 않게 하는 보정이다. 나머지는 다시 올리기 비싸고, 자주 쓰이고, 최근에 쓰인 node 일수록 남길 가치가 크다는 뜻이다. Fig.6 의 INPUT(LRU · Frequency · LoRA Quantity)이 이 항들이다. 각 항의 자세한 설명은 아래 "Cache swapper" 소절에 있다.
3.0.7보강 Eval 은 어디에 쓰이나: 후보가 여럿일 때 무엇부터 내보낼지 정한다

tree 규칙은 "어떤 node 를 내보내도 되는가" 만 정한다. swap-out 은 GPU HBM 의 leaf 만 할 수 있다 §V-B p.7. 그런데 GPU HBM 에는 leaf 가 여러 개 있으므로, 그중 무엇을 먼저 내보낼지는 tree 규칙이 정하지 못한다. cache swapper 는 이 순서를 정하려고 후보 leaf 들을 $\mathrm{Eval}_i$ 오름차순으로 정렬하고, cache manager 는 $\mathrm{Eval}_i$ 가 가장 낮은 leaf 부터 swap-out 한다 §VI-C p.8.

3.0.8 virtual root LoRA-1 LoRA-2 "To be" "Hi there" 0.4 "or not" 0.9 "the best" 0.1 Eval 오름차순 1 "the best" 0.1 2 "Hi there" 0.4 3 "or not" 0.9 → 1 번부터 swap-out 노란 테두리 = 후보(GPU HBM 의 leaf), 아래 숫자 = Eval LoRA-1 · "To be" 는 leaf 가 아니어서 후보가 아니다
3.0.8.cGPU HBM 이 가득 찬 상황이다. 후보 leaf 세 개 중 $\mathrm{Eval}_i$ 가 가장 낮은 "the best" 를 먼저 swap-out 하고, 그래도 자리가 모자라면 "Hi there" 를 swap-out 한다. tree 와 Eval 숫자는 예시다 논문에 없음.

$\mathrm{Eval}_i$ 를 LRU 순서 하나로 대신하지 않는 이유는 Fig.5 의 관측 때문이다. node 의 마지막 사용 시각 순위는 node 의 방문 빈도 순위·swap 비용 순위와 뚜렷한 상관이 없었다 §III-D2 p.5. 그래서 논문은 마지막 사용 시각·방문 빈도·swap 비용·GPU HBM 의 adapter 수를 Eq.4~6 으로 한 점수에 합치고, 그 점수로 후보 순서를 정한다 §VI-B p.7–8. swap-in 도 같은 방식이고, 후보가 host main memory 쪽 subtree 의 맨 위 node 이며 $\mathrm{Eval}_i$ 가 높은 것부터 올린다는 점만 다르다 §VI-C p.8.

3.1① Cache manager: dependency tree

3.1.1 virtual root LoRA-1 LoRA-2 KV1-1 KV2-1 KV1-2 KV1-3 채움 = GPU HBM · 점선 = host main memory
3.1.1.c규칙은 두 개다. swap-out 은 GPU HBM 의 leaf 에서만, swap-in 은 host main memory 쪽 subtree 의 맨 위 node 에서만 한다. 논문은 match 때 위 node 가 먼저 쓰이고 자식 node 가 부모에 의존하기 때문이라고 설명하고, 이 규칙으로 GPU HBM 의 KV cache 가 모두 valid 하다고 쓴다 §V-B p.7. 예를 들어 KV2-1 은 LoRA-2 보다 먼저 GPU HBM 에 올라올 수 없다 해석 (그림 논문에 없음).
Fig.7 · Fig.8 — tree 를 만들고 유지하는 법
3.1.2Fig.7
3.1.2.cFig. 7: The construction process of the usage dependencies among LoRAs and KV caches. (p.6) (a) adapter 마다 "LoRA node → KV node → KV node …" 사슬(subtree)이 생긴다. "To be" 뒤에 "or not to be" 와 "the best" 가 올 수 있듯 가지가 갈라진다. (b) virtual root 아래 2nd layer 에 모든 LoRA node 를 두어 한 tree 로 합친다. 서로 다른 LoRA branch 의 KV node 는 독립이다 §V-A p.6.
3.1.3Fig.8
3.1.3.cFig. 8: Maintaining the usage dependencies among LoRAs and KV caches during the query inference. (p.6) (a) query 가 오면 2nd layer 에서 LoRA node 를 찾고(main memory 에 있으면 비동기 swap-in), 그 branch 를 DFS 로 내려가며 가장 긴 prefix 의 KV node 를 match 한다. main memory 에 있는 KV cache 는 먼저 swap-in 하고, 새 KV cache 는 마지막으로 match 된 node 아래에 붙인다. (b) swap-out 은 GPU HBM 의 leaf 에서, swap-in 은 main memory 쪽 subtree 맨 위 node 에서만 일어난다 §V-B p.6–7.
    3.1.4
  • 3.1.4.1node 1 개는 고정 크기 memory block 1 개다 §V-A p.6. adapter weight 는 rank 방향으로 잘라 KV cache 와 같은 크기 block 에 담는다 §VII p.8. Fig.7 은 adapter 하나를 LoRA node 하나로 그려, adapter weight 가 여러 block 일 때 node 구성은 원문에 명시가 없다 해석.
  • 3.1.4.2KV node label 은 token 열의 hash, LoRA node label 은 LoRA ID 다. node 마다 방문 빈도·마지막 사용 시각·크기를 기록한다 §V-A p.6.
  • 3.1.4.3SGLang 의 RadixAttention tree 와 비슷하지만 RadixAttention 은 adapter 를 고려하지 않는다 §V-B p.7.

3.2② Cache swapper: GPU HBM 에 남길 node 를 점수로

3.2.1보강 Eval 식을 차근차근: 두 항의 곱이고, 두 번째 항은 다시 세 값의 곱이다

전제. $\mathrm{Eval}_i$ 는 tree 의 node $i$ 하나에 붙는 점수다. cache swapper 는 swap 후보 node 들의 순서를 정할 때만 이 점수를 쓴다. swap-out 은 점수가 낮은 node 부터, swap-in 은 점수가 높은 node 부터 한다 §VI-C p.8. 점수의 절댓값에는 뜻이 없고 node 사이의 크기 비교만 쓴다 §VI-B p.8.

3.2.2 Evalᵢ (Eq.6) ① adapter 개수 충족률Eq.4 (Eq.3 을 씀) × ② 지연 감소 기대값Eq.5 지금 adapter 수 ÷ 필요 수 cost × visit × 최근성 ① 은 최대 1 로 잘린다 (min) × 는 곱셈. 곱하는 값 하나라도 작으면 Evalᵢ 도 작아진다

1 단계: 전체 식 (Eq.6). $\mathrm{Eval}_i = ① \times ②$ 다. ① adapter 개수 충족률은 node $i$ 를 swap 한 뒤 GPU HBM 에 남는 adapter 개수가 최근 batch 에 필요한 adapter 개수에 얼마나 미치는지를 나타내는 비율이며, 최대 1 이다. ② 지연 감소 기대값은 node $i$ 를 GPU HBM 에 남겨 두었을 때 이후 query 의 cold-start 지연이 얼마나 줄어들지를 나타내는 값이다. ① 은 adapter 가 선택될 확률이 아니다. GPU HBM 의 adapter 수가 충분하면 ① 이 1 이라 순서는 ② 로만 정해진다. adapter 수가 모자랄 때만 ① 이 1 보다 작아져 점수에 끼어든다 해석.

2 단계: ① adapter 개수 충족률 (Eq.4, 안에서 Eq.3 을 씀). ① 을 계산하려면 먼저 Eq.3 으로 "최근 batch 에 필요한 adapter 수" $\mathrm{Low}_{lora}$ 를 구한다. adapter $i$ 가 batch 의 query $BS$ 개 중 한 번이라도 쓰일 확률 $1-(1-prob_i)^{BS}$ 를 모든 adapter 에 대해 더한 값이다 §VI-A p.7.

예시 논문에 없음: adapter 세 개의 $prob$ 가 0.5, 0.3, 0.2 이고 $BS=4$ 이면 다음과 같다.

$$\begin{aligned} \mathrm{Low}_{lora} &= (1-0.5^4) + (1-0.7^4) + (1-0.8^4) \\ &= 0.94 + 0.76 + 0.59 \approx 2.29 \end{aligned}$$

그다음 Eq.4 로 node $i$ 를 swap 한 뒤 GPU HBM 에 남는 adapter 수 $\mathrm{NowLoRA}_i$ 를 $\mathrm{Low}_{lora}$ 로 나누고, 1 을 넘으면 1 로 자른다 §VI-B p.7. 예를 들어 swap 뒤에도 adapter 가 3 개 있으면 $\min(1, 3/2.29) = 1$ 이라 ① 은 점수를 바꾸지 않는다. adapter 가 2 개로 줄면 $2/2.29 \approx 0.87$ 이라 점수가 13% 깎인다.

3 단계: ② 지연 감소 기대값 (Eq.5). 세 값을 곱한다. 세 값 모두 node $i$ 하나에 대해 잰다 §VI-B p.8.

3.2.3
값node $i$ 에 대해 재는 것클수록 남기는 이유
3.2.3.13.2.1.1$cost_i$node $i$ 를 PCIe 로 GPU HBM 에 다시 올리는 시간 (node 크기와 PCIe 대역폭으로 계산)내보냈다가 다시 필요해지면 그만큼 query 가 기다린다
3.2.3.23.2.1.2$visit_i$query 가 node $i$ 를 사용한 빈도 확률 (tree 기록으로 계산)다음 query 도 node $i$ 를 쓸 가능성이 높다
3.2.3.33.2.1.3$1-\mathrm{sigmoid}(t_i)$$t_i$ = 지금 − query 가 node $i$ 를 마지막으로 사용한 시각. $t_i=0$ 이면 0.5, $t_i$ 가 커질수록 0 으로 줄어든다최근에 쓰인 node 일수록 또 쓰인다고 본다 (LRU 성분)

예시 논문에 없음: KV node X 와 Y 는 크기가 같은 block 이라 $cost$ 를 둘 다 1 로 둔다. X 는 $visit=0.3$, 방금 사용($t=0$)이고, Y 는 $visit=0.05$, 사용한 지 2 단위 시간이 지났다($t=2$).

$$\begin{aligned} \text{X}:&\ 1 \times 0.3 \times 0.5 = 0.15 \\ \text{Y}:&\ 1 \times 0.05 \times 0.119 \approx 0.006 \end{aligned}$$

X 의 점수가 Y 보다 크므로, 둘 다 swap-out 후보이면 Y 를 먼저 내보낸다.

원문만으로 확정하지 못한 점: swap-out 때 ① 의 방향

원문 식을 글자 그대로 적용하면, swap-out 후보가 adapter node 일 때 그 node 를 내보낸 뒤의 adapter 수 $\mathrm{NowLoRA}_i$ 가 1 줄어 ① 이 작아지고 $\mathrm{Eval}_i$ 도 작아진다. 점수가 낮을수록 먼저 내보내므로, adapter 가 모자랄 때 adapter node 가 오히려 먼저 내보내지는 방향이 된다. 논문이 밝힌 의도(adapter 수를 $\mathrm{Low}_{lora}$ 근처로 유지)와 반대로 읽힌다 해석. swap-in 에서는 adapter node 를 올리면 $\mathrm{NowLoRA}_i$ 가 늘어 ① 이 커지므로 의도와 맞다. 원문은 swap-out 때 ① 을 어떻게 적용하는지 따로 설명하지 않으며, 이 차이의 원인은 미규명이다.

Eval 은 두 항의 곱이다. 하나는 "GPU HBM 에 adapter weight 가 충분한 수만큼 있나"(Eq.3–4), 다른 하나는 "이 node 를 GPU HBM 에 남기면 이후 query 의 cold-start 지연을 얼마나 줄이나"(Eq.5) 이다. 두 값을 곱한 Eq.6 이 클수록 GPU HBM 에 남긴다 §VI-B p.7–8.

3.2.4
$\mathrm{Eval}_i$ = node $i$ 를 GPU HBM 에 남겼을 때의 TTFT 이득 점수
$$\mathrm{Eval}_i = \mathrm{LoRA\_Eval}_i \times \mathrm{Retain\_Eval}_i$$Eq.6 · §VI-B p.8
GPU HBM 이 가득 차면 GPU HBM 의 leaf 를 Eval 오름차순으로 swap-out 하고, 사용률이 낮으면(원문 예: 70% 미만) main memory 쪽 subtree 맨 위 node 를 Eval 내림차순으로 swap-in 한다 §VI-C p.8. 논문은 Eval 을 node 사이의 상대 순서를 정하는 데 쓴다고 쓴다 §VI-B p.8.
3.2.5
$\mathrm{NowLoRA}_i$ = node $i$ 를 swap 한 뒤 GPU HBM 에 있는 adapter 수 · $\mathrm{Low}_{lora}$ = Eq.3 의 기댓값
$$\mathrm{LoRA\_Eval}_i = \min\!\left(1,\ \frac{\mathrm{NowLoRA}_i}{\mathrm{Low}_{lora}}\right)$$Eq.4 · §VI-B p.7
swap 뒤 GPU HBM 의 adapter 수가 기댓값보다 적어지면 점수를 깎아, adapter 수를 $\mathrm{Low}_{lora}$ 근처로 유지하게 한다. 평가에서 94.8% 의 시간 동안 $\mathrm{Low}_{lora}$ 대비 ±5% 안이었다 §VI-B p.7.
3.2.6
$n$ = adapter 수 · $prob_i$ = adapter $i$ 의 사용 빈도 확률 (tree 기록에서 계산) · $BS$ = 최근 5 초의 inference batch size · $fe_i$ = adapter $i$ 가 최근 batch 에 있을 확률
$$\begin{aligned} \mathrm{Low}_{lora} &= \sum_{i=1}^{n} fe_i \\ &= \sum_{i=1}^{n} \left[\, 1 - (1 - prob_i)^{BS} \right] \end{aligned}$$Eq.3 · §VI-A p.7
$(1 - prob_i)^{BS}$ 는 batch 의 $BS$ 개 query 중 아무도 adapter $i$ 를 쓰지 않을 확률이고, 1 에서 빼면 $fe_i$ 다. 이를 모든 adapter 에 대해 더한 $\mathrm{Low}_{lora}$ 는 inference 에 필요한 adapter 수의 기댓값이다 §VI-A p.7.
3.2.7
$cost_i$ = node $i$ 의 transfer cost, PCIe 대역폭과 node 크기로 계산 · $visit_i$ = node $i$ 의 방문 빈도 확률 · $t_i$ = 현재 시각 − 마지막 사용 시각
$$\begin{aligned} \mathrm{Retain\_Eval}_i &= cost_i \times visit_i \\ &\quad \times \bigl(1 - \mathrm{sigmoid}(t_i)\bigr) \end{aligned}$$Eq.5 · §VI-B p.7–8
swap 비용이 크고, 자주 쓰이고, 최근에 쓰인 node 일수록 남길 가치가 크다. 논문은 마지막 항을 LSTM forget gate 와 비슷한 time decay 이자 LRU 를 반영하는 항이라고 설명한다 §VI-B p.8. $cost_i$ 를 "크기 ÷ 대역폭" 으로 계산한다는 구체식은 원문에 없다 해석.
왜 곱셈인가, 왜 1 − sigmoid 는 0.5 에서 시작하나

곱셈이면 한 항이라도 0 에 가까울 때 전체 점수가 0 에 가까워진다. 예를 들어 다시 쓰일 확률이 0 인 node 는 swap 비용이 커도 남길 이유가 없다. 또 단위가 다른 항끼리 가중치를 맞출 필요가 없다 해석. 논문은 곱셈을 고른 이유를 따로 적지 않았다.

$t_i \ge 0$ 이고 $\mathrm{sigmoid}(0) = 0.5$ 이므로, 방금 쓴 node 도 이 항은 1 이 아니라 0.5 다. $1 - \mathrm{sigmoid}(t) = 1/(1+e^{t})$ 라서 0.5 에서 0 으로 줄어든다. 최대값이 모든 node 에 같으므로 순서 비교에는 영향이 없다 해석. 논문은 $t_i$ 의 단위(초·ms)를 밝히지 않았다.

3.2.8
$t_i$$\mathrm{sigmoid}(t_i)$$1 - \mathrm{sigmoid}(t_i)$
3.2.8.100.5000.500
3.2.8.210.7310.269
3.2.8.320.8810.119
3.2.8.430.9530.047
3.2.8.550.9930.007
3.2.9
점수 계산기: 값을 바꿔 Eval 이 어떻게 움직이는지 보기 논문에 없음
$prob_i$ 를 Zipf 분포로, $cost_i$ 를 크기 ÷ 128 GB/s 로 가정한다. 출력 줄의 "LoRA 수" 는 GPU HBM 의 adapter 수다.
Fig.9 · Fig.10 — adapter 수가 왜 중요한가, swapper 가 도는 순서
3.2.10Fig.9
3.2.10.cFig. 9: The TTFT of vLLM in the chatbot scenario under different GPU memory allocation ratios for LoRAs. (p.7) vLLM, chatbot, 평균 5 QPS 조건이다. adapter 영역 비율을 0.05 → 0.3 으로 늘리면 TTFT 가 target ratio 까지 크게 줄고, query 가 쓰는 adapter 가 20 → 50 개로 늘면 target ratio 도 커진다. 논문은 필요한 adapter weight 가 GPU HBM 에 있어야 query 가 시작되기 때문이라고 설명하고, 이를 Eq.3–4 의 근거로 든다 §VI-A p.7. target ratio 뒤로 TTFT 는 그림에서 조금씩 오른다 해석.
3.2.11Fig.10
3.2.11.cFig. 10: The execution workflow of the cache swapper with the swap-out instruction as examples. (p.8) ① 100 ms 마다 모든 node 의 Eval 을 갱신한다. ② GPU HBM 이 가득 차면 cache manager 가 swap-out 을 요청한다. ③ GPU HBM 의 leaf 들이 후보가 된다. ④ Eval 오름차순으로 정렬하고 ⑤ 낮은 것부터 swap-out 한다. LoRA node 를 하나 swap 할 때마다 GPU HBM 의 adapter 수가 바뀌므로 Eval 을 다시 계산한다 §VI-C p.8.

4구현

vLLM 위에 Python 7,856 줄 + C++ 1,766 줄로 구현했다. vLLM 의 BlockManager 를 확장해 GPU HBM 과 host main memory 를 같은 크기 block 으로 나누고, S-LoRA 식 pool 에 history KV 까지 담는다 §VII p.8.
tree 는 block 주소만 기록하는 trie 로 host main memory 에 두고(최대 676.5 KB, match·갱신 1 ms 미만), swap 은 torch stream 으로 비동기라 다른 query 의 inference 를 막지 않는다 §VII p.8.

구현 세부와 오버헤드
4.1
항목값근거
4.1.1Eval 갱신 비용최대 3.1 μs§VI-C p.8
4.1.2비동기 swap 오버헤드최대 0.47 ms§VI-C p.8
4.1.3query 1 개 inference 중 swap 오버헤드5 ms 이내§VIII-L p.12
4.1.4tree match·갱신 (query 당 평균, tree 최대 크기일 때)< 0.5 ms§VIII-L p.12
4.1.5block 당 메타데이터232 B / 16 MB (0.0014%)§VIII-L p.12
4.1.6Eval 저장24 B / block (0.0001%)§VIII-L p.12
    4.2
  • 4.2.1rank 가 다른 adapter 를 쓰는 query 들을 한 batch 로 묶기 위해 SGMV 를 쓰고, tensor parallelism 으로 여러 GPU 에 나눈다 §VII p.8.
  • 4.2.2GPU HBM 과 host main memory 가 모두 차면 cold KV block 을 버리고 tree 에서도 지운다 §VII p.8.

5평가

H800 ×8 (Llama3-8B 는 1 장, Llama2-34B 는 4 장, Llama3-70B 는 8 장), adapter 20·50·100 개, chatbot·번역·agent 세 시나리오로 실험했다. baseline 은 vLLM(adapter 영역 0.2 고정, LRU)과 S-LoRA(unified pool, history KV 재사용 없음)다 §VIII-A p.9.
27 조합 모두에서 ELORA 의 평균 TTFT·TPOT 가 가장 낮고 peak load 가 가장 높으며 §VIII-B p.9, 시나리오별 TTFT 의 queue·LoRA cold-start·KV cold-start 지연도 가장 짧다 §VIII-C p.10.

5.1Table II
5.1.cTABLE II: Experiment specifications (p.4)host main memory 256 GB 와 GPU 가 PCIe 5.0 (128 GB/s) 으로 연결된다. Eq.5 의 $cost_i$ 는 이 PCIe 대역폭과 node 크기로 계산한다 §VI-B p.8.
5.2Fig.11
5.2.cFig. 11: The average TTFT, TPOT, and supported peak load of ELORA, vLLM, and S-LoRA in various scenarios. (p.9) 27 조합(모델 3 × adapter 수 3 × 시나리오 3) 전부에서 ELORA 의 평균 TTFT·TPOT 가 가장 낮고 peak load 가 가장 높다 §VIII-B p.9.
27 조합 평균으로 vLLM 대비 TTFT −45.7%, TPOT −37.8%, peak load +78.9%, S-LoRA 대비 −43.3%, −31.4%, +49.9% 다. P99 TTFT 는 vLLM 대비 −73.8% 이고, 조합마다 20 회 반복한 표준오차는 평균 1.7% 다. 논문은 개선이 usage dependency 유지와, 이득이 큰 adapter weight·KV cache 를 GPU HBM 에 남겨 cold-start 를 줄인 데서 온다고 쓴다. vLLM 대비 TTFT 감소가 번역에서 평균 49.4% 로 다른 시나리오(43.8%)보다 큰 것은 adapter 분포 변화가 가장 커서이고, S-LoRA 대비 agent 에서 53.2%(다른 시나리오 38.4%)인 것은 대화가 가장 길어 history KV 를 남기지 않는 S-LoRA 의 약점이 커져서라고 설명한다 §VIII-B p.9–10.
5.4Fig.12
5.4.cFig. 12: The breakdown of the latency in TTFT. (p.10) TTFT 를 queue · LoRA cold-start · KV cold-start 지연으로 나눈 그림이다. 세 시나리오 모두 ELORA 의 세 항이 가장 짧다 §VIII-C p.10. 논문은 이를 GPU HBM 사용 효율이 가장 높다는 뜻으로 보고 근거로 Fig.13 을 든다. unified pool 의 동적 swap 으로 GPU HBM 사용률이 오르고, usage dependency 로 invalid KV 가 없어지며, swap 정책이 적절한 adapter weight·KV cache 를 미리 올려(prefetch) hit rate 가 오른다는 설명이다 §VIII-C p.10.
Fig.13 · Fig.14 — GPU HBM 을 실제로 어떻게 쓰나
5.5Fig.13
5.5.cFig. 13: The average GPU memory usage and cache hit rate. (p.10) (a) 평균 GPU HBM 사용률이 vLLM 대비 1.2×, S-LoRA 대비 2.6× 다. (b) hit rate(adapter weight + KV cache)는 1.3× · 3.4× 다 §VIII-C p.10. 논문 설명에 따르면 S-LoRA 는 history KV 를 남기지 않아 GPU HBM 을 덜 쓰고 hit rate 가 가장 낮다. vLLM 은 고정 분할이라 부하가 바뀌면 한 영역이 덜 쓰인다. ELORA 는 unified pool 에서 adapter weight 와 KV cache 를 동적으로 swap 한다 §VIII-C p.10.
5.6Fig.14
5.6.cFig. 14: GPU memory usage over time of different systems. (p.10) Llama2-34B, adapter 100 개 chatbot 의 1,800 s 다. (a) 0–400 s GPU HBM 여유가 있을 때 ELORA 는 cost model 에 따라 모든 adapter weight 를 미리 올린다. (b) 400–900 s 부하가 늘자 일부 adapter weight 를 내리고 세 시스템 중 history KV 를 가장 많이 남긴다. (c) 900–1300 s 에는 history KV 를 모두 내려 running KV 에 자리를 준다. (d) 1300 s 이후 query 가 쓰는 adapter 수가 늘자 adapter weight 에 더 많은 GPU HBM 을 준다 §VIII-D p.10. 같은 구간에서 vLLM 은 (c) KV 영역 80%, (d) adapter 영역 20% 가 가득 차 TTFT 가 오른다. 고정 분할이 없어 adapter weight·history KV·running KV 의 비율이 시점마다 바뀌는 것을 시간축으로 보인 그림이다 §VIII-D p.10.
Fig.15 · Fig.16 · Fig.17 — 부품을 하나씩 빼 보기 (ablation)
5.7Fig.15
5.7.cFig. 15: The TTFT and TPOT of ELORA's variants normalized to ELORA. (p.11) ELORA 대비 정규화한 27 조합 평균이다. WOM(usage dependency 를 유지하지 않고 cache swapper 만 사용)은 TTFT 1.51×, TPOT 1.34×, invalid KV 48.6%, peak load −19.3% 다 §VIII-E p.10–11. WOS(dependency tree 는 두고 Eq.6 대신 LRU)는 TTFT 1.42×, TPOT 1.29×, peak load −18.6% 다 §VIII-F p.11. 두 부품 중 어느 쪽을 빼도 모든 조합에서 TTFT·TPOT 가 늘었다.
5.8Fig.16
5.8.cFig. 16: The TTFT and TPOT when eliminating different components of ELORA's cost model under the chatbot. (p.11) chatbot, ELORA 대비 정규화 평균이다. cost model 항을 하나씩 빼면 TTFT 가 adapter 개수 충족률(Eq.4) 제거 1.21×, $cost_i$ 제거 1.19×, $visit_i$ 제거 1.25×, $1-\mathrm{sigmoid}(t_i)$ 제거 1.21× 다. 네 변형 모두 모든 경우에서 TTFT·TPOT 가 늘었다 §VIII-G p.11.
5.9Fig.17
5.9.cFig. 17: The TTFT and TPOT of other caching policies. (p.11) Llama2-34B chatbot, ELORA 대비 평균이다. BFS(LoRA branch 를 통째로 swap)는 TTFT 2.29×, TPOT 1.54× 다. 논문은 branch 하나가 GPU HBM 의 최대 35.6% 를 차지해 단위가 너무 크고 PCIe overhead 가 ELORA 의 9.71× 라고 설명한다. RRIP · Hawkeye · HALP 를 cost model 대신 넣으면 TTFT 1.35 · 1.38 · 1.41× 다. 논문은 이 정책들이 다른 caching 상황(예: YouTube CDN)용이라 적재된 adapter 수 같은 Multi-LoRA 지표를 쓰지 않기 때문이라고 설명한다 §VIII-H p.11.
Fig.18 · Fig.19 · Fig.20 — 확장성과 oracle 비율의 vLLM
5.10Fig.18
5.10.cFig. 18: The TTFT and TPOT of ELORA and baselines with different combinations of LoRA numbers and distributions. (p.12) Llama2-34B chatbot, adapter 1,000 · 2,000 개, 분포 distinct / random / skewed 에서 모든 경우 ELORA 의 TTFT·TPOT 가 가장 낮고, 평균 감소는 TTFT 48.7%, TPOT 21.9% 다. 원문은 어느 baseline 대비인지 밝히지 않는다. 논문은 실제 서비스의 adapter 수는 수십 개라고 쓴다 §VIII-I p.11–12.
5.11Fig.19
5.11.cFig. 19: The TTFT and TPOT of vLLM under different GPU memory allocation ratios for LoRAs in the chatbot scenario. (p.12) Llama2-34B chatbot 이다. vLLM 의 adapter 영역 비율을 0.05 간격으로 brute-force profile 해 가장 좋은 값(oracle)을 골라도 ELORA 보다 TTFT +38.7%, TPOT +24.4% 다. 논문은 oracle vLLM 이 vLLM 과 S-LoRA 를 합친 것과 같고, 실제 동적 서빙에서 이런 profile 은 불가능하다고 쓴다 §VIII-J p.12. 비율 조정만으로는 ELORA 와의 차이가 메워지지 않는다는 근거로 읽힌다 해석.
5.12Fig.20
5.12.cFig. 20: The TTFT and TPOT of baselines normalized to ELORA's for the Llama2-34B when evaluating on NPUs. (p.12) Llama2-34B, in-house NPU 4 장(각 256 TFLOPS FP16, 64 GB)에서 vLLM 대비 TTFT −69.8%, TPOT −38.4%, S-LoRA 대비 −49.4%, −26.2% 다 §VIII-K p.12.

6결론과 한계

논문의 결론은 cache manager 가 tree 로 usage dependency 를 유지해 invalid KV 를 없애 GPU HBM 사용률을 올리고, cache swapper 가 query 성능 이득을 반영한 cost model 로 swap 을 정해, 기존 시스템 대비 평균 TTFT −45.7%, TPOT −37.8% 를 얻었다는 것이다 §IX p.12–13.
논문에 limitation 절은 없다. 아래는 요약자가 정리한 한계다 논문에 없음.

6.1
한계근거
6.1.1메모리 계층이 GPU HBM ↔ host main memory 두 단계뿐이다. SSD·원격 KV store 나 여러 노드 사이 공유는 다루지 않는다둘 다 차면 cold KV block 을 버림 (§VII p.8)
6.1.2cost model 은 곱셈 형태의 수작업 식이고, 100 ms 주기 · 70% 기준 · 5 초 $BS$ 창의 민감도 분석이 없다§VI-A·C p.7–8 에 값만 제시
6.1.3KV cache 를 adapter 사이에 공유할 수 없다는 전제다. 같은 문서를 adapter 여러 개로 처리하면 KV cache 를 adapter 수만큼 저장한다 (1 절 숫자 예시 참고)Eq.2 (§III-A p.3)
6.1.4workload 는 공개 dataset 을 adapter 에 대응시켜 만들었고 adapter 는 HuggingFace 에서 무작위로 골랐다. 실제 Multi-LoRA 서비스 trace 는 아니다§III-B p.3
6.1.5baseline 이 vLLM · S-LoRA 둘이다. SGLang 은 Multi-LoRA 사용 시 history KV 를 재사용하지 못하고 평균 TTFT 가 9,568.9 ms 여서, TensorRT-LLM 은 adapter 를 미리 compile 해야 해서 제외했다§III-C p.4, §VIII-A p.9
6.1.6TPOT 개선은 논문 설명상 prefill 재계산 감소의 간접 효과다. decode 연산 자체를 바꾸는 기법은 제시되지 않았다§VIII-B p.9

7관련 연구

Table I 은 비교한 네 시스템 중 "Multi-LoRA serving + online adapter (un)loading + history KV 재사용 + KV cache·adapter weight 동적 관리" 넷을 모두 하는 것은 ELORA 뿐이라고 보인다.
vLLM 은 앞의 세 개, S-LoRA 는 앞의 두 개를 한다. TensorRT-LLM 은 Multi-LoRA serving 과 history KV 재사용은 하지만 adapter 를 base 모델과 미리 compile 해야 해 online loading 이 안 된다 §II p.2–3.

7.1Table I
7.1.cTABLE I: Comparisons between ELORA and other works. (p.2)
관련 연구 한 줄씩
7.2
연구한 일ELORA 와 차이
7.2.1SGLang RadixAttentionglobal prefix tree + LRU 로 KV cache 재사용adapter 를 고려하지 않는다. ELORA tree 구현의 바탕 operator (§II p.2)
7.2.2AttentionStore · Pensieve다단 KV caching 으로 다회 대화의 재계산 제거adapter weight 와 통합 관리 없음 (§II p.2)
7.2.3Punica · S-LoRAbase 모델과 adapter 연산 분리(Punica), adapter weight·running KV 의 unified pool(S-LoRA)history KV 재사용 없음. S-LoRA pool 은 ELORA 의 바탕 operator (§II p.2)
7.2.4dLoRAadapter 를 base 모델에 merge·unmerge, replica 간 query·adapter 이동논문은 직교한다고 쓴다 (§II p.2)

8세미나 발표 대본 (약 18 분)

Fig.1~20 을 슬라이드 순서대로 놓고, 슬라이드마다 말할 내용을 2~4 문장으로 적었다. 세부 수식과 구현 수치는 빼고, 문제 → 설계 → 실험 환경 → 평가 흐름만 남겼다.
발화문은 요약자가 쓴 것이고 논문에 없음, 수치와 주장은 원문에서 확인한 것만 넣었다. 각 슬라이드 옆 시간은 권장 분량이다.

펼치기: 슬라이드별 그림과 발화 (Fig.1~20)

도입 · 40 초

오늘 소개할 논문은 HPCA 2026 의 ELORA 입니다. 하나의 base 모델에 작업별 LoRA adapter 를 여러 개 붙여 서비스할 때, adapter weight 와 KV cache 를 GPU 메모리에서 어떻게 함께 관리할지를 다룹니다. 결론부터 말하면, 둘 사이의 의존 관계를 tree 로 지키고 점수로 swap 순서를 정해서 vLLM 대비 TTFT 를 평균 45.7% 줄였습니다.

1 부 · 문제 (약 4 분)

8.1Fig.1
8.1.cFig. 1: An example caching state to show the Usage Dependencies between LoRAs and KV caches. (p.1) · 60 초
한 장짜리 그림으로, 핵심 관찰을 보여 줍니다. 왼쪽 GPU memory 에는 LoRA-1 의 KV1-1·KV1-2·KV1-3 이 남아 있지만, LoRA-1 자신은 아래 main memory 로 쫓겨나 있습니다. KV cache 는 그것을 계산한 adapter 가 GPU 에 있어야만 쓸 수 있으므로 Query-1 은 실행되지 못하고, 그 KV 들은 자리만 차지합니다. 논문은 이런 KV 를 invalid KV 라 부르고, vLLM 에서 평균 42.4% 를 관측했습니다.
8.2Fig.2
8.2.cFig. 2: The TTFT of the vLLM for different scenarios. (p.4) · 50 초
vLLM 을 30 분 돌리며 TTFT 를 시간순으로 그린 그림이고, 세 줄은 시나리오입니다. 위 chatbot 과 아래 agent 는 650~750 초쯤부터 KV 영역이 가득 차면서 TTFT 가 수천 ms 로 오릅니다. 가운데 번역은 두 구간으로 나뉩니다. 앞 구간은 KV 영역이, 1200 초 이후는 adapter 영역이 가득 찬 구간입니다. 세 줄 모두 고정 분할한 두 영역 중 한쪽이 먼저 차는 순간 지연이 튄다는 같은 이야기를 합니다.
8.3Fig.3
8.3.cFig. 3: Examples of serving two queries under (a) without usage dependencies, (b) maintaining usage dependencies. (p.4) · 70 초
두 상황을 나란히 비교합니다. history KV 를 둘 자리가 하나뿐이라고 가정합니다. (a) 는 의존 관계를 무시한 경우입니다. 그 자리에 adapter 가 없는 KV2-1 이 있어서, Q1 은 KV2-1 을 내리고 KV1-1 을 올릴 때까지 기다립니다. Q2 는 나중에 내려간 KV2-1 을 다시 올립니다. (b) 는 의존 관계를 지킨 경우입니다. 자리에 KV1-1 이 있어 Q1 은 바로 실행되고, Q2 도 한 번만 올리면 되어 둘 다 더 일찍 끝납니다.
8.4Fig.4
8.4.cFig. 4: The utilization rate of the GPU memory space allocated to LoRAs and KV caches over time in the translation scenario. (p.5) · 45 초
번역 시나리오에서 두 영역의 사용률을 시간순으로 그린 그림입니다. 파란 선은 KV 영역, 초록 선은 adapter 영역입니다. 650~1200 초에는 KV 영역이 100% 인데 adapter 영역은 평균 59% 만 씁니다. 1200 초 이후에는 쓰이는 adapter 종류가 29 개에서 48 개로 늘어 반대로 adapter 영역이 가득 찹니다. 필요한 비율이 시간에 따라 바뀐다는 것이 요점입니다.
8.5Fig.5
8.5.cFig. 5: The relationships among the visited frequency, swap costs, and LRU of the KV caches or LoRAs. (p.5) · 30 초
세 패널은 모두 같은 데이터의 다른 짝입니다. 점 하나가 adapter weight 나 KV cache 하나이고, 왼쪽은 마지막 사용 시각 순위와 사용 빈도 순위, 가운데는 마지막 사용 시각 순위와 다시 올리는 비용 순위, 오른쪽은 사용 빈도와 비용입니다. 세 패널 모두 점이 흩어져 서로 상관이 없습니다. 그래서 LRU 하나로는 자주 쓰이거나 비싼 것을 지키지 못합니다.

2 부 · 설계 (약 5 분)

8.6Fig.6
8.6.cFig. 6: Design overview of ELORA. (p.5) · 80 초
설계 전체 그림이고, 번호가 두 흐름으로 나뉩니다. ①② 는 GPU 메모리 상태에 따라 미리 swap 하는 흐름입니다. GPU 가 가득 차면 오른쪽 cache swapper 가 점수로 가장 덜 중요한 KV2-1 을 고르고, 왼쪽 cache manager 가 그것을 내보냅니다. ③④ 는 query 가 왔을 때의 흐름입니다. tree 에서 LoRA-1, KV1-1 순으로 찾아 쓰고, 새로 만든 KV 를 그 가지 끝에 붙입니다. 두 부품이 각각 앞의 두 문제, 즉 invalid KV 와 고정 분할을 맡습니다.
8.7Fig.7
8.7.cFig. 7: The construction process of the usage dependencies among LoRAs and KV caches. (p.6) · 45 초
tree 를 만드는 과정을 두 단계로 나눠 그렸습니다. 동작 중에 바뀌는 것이 아니라 설명을 위한 단계입니다. (a) 는 adapter 하나만 떼어 본 모습입니다. LoRA node 아래로 그 adapter 로 계산한 KV 가 token 순서대로 이어지고, "To be" 뒤에 다른 말이 오면 가지가 갈라집니다. (b) 는 adapter 별 subtree 들을 가상의 root 하나로 묶은 모습입니다. 그래서 2 층에는 adapter, 그 아래로 KV 가 옵니다.
8.8Fig.8
8.8.cFig. 8: Maintaining the usage dependencies among LoRAs and KV caches during the query inference. (p.6) · 60 초
두 패널이 서로 다른 상황입니다. (a) 는 on-demand, 즉 query 가 도착했을 때입니다. query 는 2 층에서 자기 adapter 를 찾고, 그 가지를 따라 가장 긴 prefix 의 KV 를 찾습니다. 필요한 것이 main memory 에 있으면 그때 올리고, 새 KV 는 가지 끝에 붙입니다. (b) 는 GPU 메모리 상태에 따라 미리 swap 하는 상황입니다. 가득 차면 GPU 쪽 가지 끝의 leaf 부터 내보내고, 비면 main memory 쪽 가지의 맨 위부터 올립니다. 이 규칙 덕분에 GPU 에 있는 KV 는 항상 자기 adapter 도 GPU 에 있습니다.
8.9Fig.9
8.9.cFig. 9: The TTFT of vLLM in the chatbot scenario under different GPU memory allocation ratios for LoRAs. (p.7) · 40 초
vLLM 에서 adapter 영역 비율을 바꿔 가며 TTFT 를 잰 그림이고, 두 선은 필요한 adapter 종류가 20 개일 때와 50 개일 때입니다. 두 선 모두 비율을 늘리면 TTFT 가 어느 지점까지 급격히 떨어집니다. 그 지점은 50 개일 때가 더 오른쪽입니다. 필요한 adapter 수가 바뀌면 필요한 메모리도 바뀐다는 뜻이고, 그래서 점수에 "GPU 에 adapter 가 충분한가" 를 보는 항이 들어갑니다.
8.10Fig.10
8.10.cFig. 10: The execution workflow of the cache swapper with the swap-out instruction as examples. (p.8) · 50 초
Fig.8(b) 의 미리 swap 하는 흐름을 swap-out 기준으로 펼친 그림입니다. ① cache swapper 가 100 ms 마다 모든 node 의 점수를 다시 계산합니다. ② GPU 가 가득 차면 cache manager 가 swap-out 을 요청하고, ③ GPU 의 leaf 들을 후보로 넘깁니다. ④ swapper 가 후보를 점수 오름차순으로 정렬하면, ⑤ manager 가 낮은 것부터 하나씩 내보냅니다. 점수는 GPU 의 adapter 개수가 충분한지, 그리고 다시 올리는 비용·사용 빈도·최근성을 곱해 만듭니다.

실험 환경 · 70 초

8.11Table II
8.11.cTABLE II: Experiment specifications (p.4) · 70 초
평가로 넘어가기 전에 실험 환경입니다. 서버 한 대에 GPU 는 NVIDIA H800 80 GB 8 장, CPU 는 Intel Xeon Platinum 8480CL, host 메모리는 256 GB 이고, GPU 와 host 는 PCIe 5.0 으로 연결됩니다. 논문은 이 연결 대역폭을 128 GB/s 로 적었는데, PCIe 5.0 x16 의 한 방향은 약 64 GB/s 라서 양방향 합으로 보입니다. 모델은 Llama3-8B, Llama2-34B, Llama3-70B 세 개이고, 크기에 맞춰 GPU 를 각각 1 장, 4 장, 8 장 씁니다. 모델마다 LoRA adapter 를 20·50·100 개 붙였고, adapter 는 HuggingFace 에서 무작위로 골랐으며 rank 는 32 또는 64 입니다.
요청은 세 가지 실제 trace 로 만듭니다. chatbot 은 LMSYS-33K 대화 데이터를 시각 정보 그대로 쓰고, model 이름별로 adapter 를 정합니다. 번역은 OPUS-100 의 언어 쌍 하나를 adapter 하나에 대응시키고, 요청 도착 시각은 Microsoft Azure Function trace 를 따릅니다. personal agent 는 Google Taskmaster 의 다회 대화를 같은 Azure trace 시각으로 보냅니다. 비교 대상은 vLLM(adapter 영역 0.2 고정, LRU)과 S-LoRA(통합 pool, history KV 재사용 없음)이고, 모두 continuous batching 으로 돌립니다. 요청 전송률은 0 부터 ELORA 의 peak load 까지 10 단계로 바꿔 평균을 냈습니다.

3 부 · 평가 (약 7 분)

8.12Fig.11
8.12.cFig. 11: The average TTFT, TPOT, and supported peak load of ELORA, vLLM, and S-LoRA in various scenarios. (p.9) · 70 초
주 결과이고, 세 줄을 따로 읽습니다. 맨 위 줄은 평균 TTFT, 가운데는 평균 TPOT, 아래는 TTFT 500 ms 를 지키며 받을 수 있는 최대 요청량인 peak load 입니다. 가로로는 chatbot·번역·agent 세 시나리오이고, 각 칸의 x 축은 모델과 adapter 개수 9 가지입니다. 27 조합 모두에서 노란 막대인 ELORA 가 TTFT 와 TPOT 는 가장 낮고 peak load 는 가장 높습니다. vLLM 대비 평균으로 TTFT 45.7%, TPOT 37.8% 가 줄고, peak load 는 78.9% 늘었습니다. TPOT 감소에 대해 논문은 KV 재사용이 늘어 prefill 재계산이 줄고, 그만큼 다른 요청의 decode 가 덜 방해받기 때문이라고 설명합니다.
8.13Fig.12
8.13.cFig. 12: The breakdown of the latency in TTFT. (p.10) · 40 초
세 묶음은 시나리오이고, 묶음 안에 vLLM, S-LoRA, ELORA 막대가 있습니다. 막대 하나는 TTFT 중 기다린 시간을 세 조각으로 나눈 것입니다. 회색은 줄 서기, 진한 초록은 adapter 를 올리는 시간, 연한 초록은 KV 를 올리는 시간입니다. 세 시나리오 모두 ELORA 의 세 조각이 가장 짧습니다. S-LoRA 에 KV 조각이 없는 것은 끝난 요청의 KV 를 재사용하지 않아 올릴 KV 가 없기 때문입니다.
8.14Fig.13
8.14.cFig. 13: The average GPU memory usage and cache hit rate. (p.10) · 45 초
두 패널이 원인을 나눠 보여 줍니다. (a) 는 GPU 메모리를 평균 얼마나 채워 썼는지로, ELORA 가 vLLM 의 1.2 배, S-LoRA 의 2.6 배입니다. 칸막이가 없어 남는 자리를 서로 빌려 쓰기 때문입니다. (b) 는 필요한 adapter 와 KV 가 이미 GPU 에 있던 비율로, 분홍이 adapter, 파랑이 KV 입니다. ELORA 가 vLLM 의 1.3 배이고 늘어난 몫은 대부분 KV 쪽입니다. (a) 는 얼마나 채웠는지, (b) 는 채운 것이 실제로 쓰였는지를 보여 줍니다.
8.15Fig.14
8.15.cFig. 14: GPU memory usage over time of different systems. (p.10) · 70 초
한 실행을 시간축으로 따라가는 그림이고, 네 줄과 네 구간을 나눠 봅니다. 위 세 줄은 GPU 메모리 중 history KV, 실행 중인 요청의 KV, adapter 가 차지한 비율이고, 맨 아래는 TTFT 입니다. (a) 한가한 처음에는 ELORA 가 adapter 를 미리 모두 올립니다. (b) 부하가 늘면 adapter 를 일부 내리고 history KV 를 가장 많이 남깁니다. (c) 실행 중인 KV 가 더 필요해지면 history KV 를 모두 내려 자리를 넘깁니다. (d) 쓰이는 adapter 가 늘면 adapter 에 30% 넘게 줍니다. 같은 구간에서 vLLM 은 80%·20% 한도에 막혀 맨 아래 TTFT 가 급증합니다.
8.16Fig.15
8.16.cFig. 15: The TTFT and TPOT of ELORA's variants normalized to ELORA. (p.11) · 45 초
세 묶음은 시나리오이고, 막대는 TTFT, 선은 TPOT 를 ELORA 로 나눈 값입니다. 파랑은 의존 관계 유지를 뺀 변형, 초록은 점수 대신 LRU 를 쓴 변형입니다. 의존 관계를 빼면 invalid KV 가 48.6% 생기고 TTFT 가 평균 1.51 배가 됩니다. 점수를 빼면 1.42 배입니다. 모든 조합에서 1 보다 커서, 두 부품이 각자 기여한다는 결과입니다.
8.17Fig.16
8.17.cFig. 16: The TTFT and TPOT when eliminating different components of ELORA's cost model under the chatbot. (p.11) · 25 초
chatbot 에서 점수식의 네 항을 하나씩 뺀 결과입니다. 막대는 TTFT, 선은 TPOT 입니다. 어느 항을 빼도 TTFT 가 1.19~1.25 배로 나빠집니다. 어느 항도 빼서는 안 된다는 그림으로 짧게 넘어가겠습니다.
8.18Fig.17
8.18.cFig. 17: The TTFT and TPOT of other caching policies. (p.11) · 35 초
왼쪽은 TTFT, 오른쪽은 TPOT 이고, x 축은 adapter 개수입니다. 노란 점선 ELORA 를 1 로 놓았습니다. 파란 막대는 adapter 가지를 통째로 옮기는 방식으로, 단위가 너무 굵어 TTFT 가 2.29 배입니다. 나머지 세 막대는 CPU cache 나 CDN 에서 쓰는 교체 정책을 점수 대신 넣은 것으로, 1.35~1.41 배입니다. adapter 개수 같은 Multi-LoRA 고유 정보를 보지 않기 때문입니다.
8.19Fig.18
8.19.cFig. 18: The TTFT and TPOT of ELORA and baselines with different combinations of LoRA numbers and distributions. (p.12) · 25 초
위는 TTFT, 아래는 TPOT 이고, x 축은 adapter 1,000 개와 2,000 개에 요청 분포 네 가지를 조합한 것입니다. 모든 조합에서 ELORA 가 가장 낮습니다. 다만 논문도 실제 서비스는 adapter 가 수십 개 수준이라고 밝히고 있어, 극단 조건 확인으로 보시면 됩니다.
8.20Fig.19
8.20.cFig. 19: The TTFT and TPOT of vLLM under different GPU memory allocation ratios for LoRAs in the chatbot scenario. (p.12) · 50 초
가장 강한 반론에 대한 답입니다. 세 열은 adapter 20·50·100 개, 위 줄은 TTFT, 아래 줄은 TPOT 입니다. 파란 선은 vLLM 의 adapter 비율을 0.05 간격으로 바꾼 결과이고, 빨간 상자가 가장 좋은 비율입니다. 여섯 칸 모두 그 최적점조차 노란 점선 ELORA 보다 높아, TTFT 기준 평균 38.7% 차이가 남습니다. 이런 탐색은 부하가 계속 바뀌는 실제 서빙에서는 할 수도 없습니다. 비율을 잘 고르는 것만으로는 부족하다는 뜻입니다.
8.21Fig.20
8.21.cFig. 20: The TTFT and TPOT of baselines normalized to ELORA's for the Llama2-34B when evaluating on NPUs. (p.12) · 20 초
GPU 가 아닌 저자들의 자체 NPU 4 장에서 같은 비교를 한 그림입니다. 막대와 선은 baseline 을 ELORA 로 나눈 값이고, vLLM 대비 TTFT 를 69.8% 줄였습니다. 하드웨어가 바뀌어도 통한다는 확인으로 짧게 넘어갑니다.

마무리 · 45 초

정리하겠습니다. Multi-LoRA 서빙에서 KV cache 는 자기 adapter 가 있어야만 쓸모가 있는데, 기존 시스템은 둘을 따로 관리해 쓸모없는 KV 가 메모리를 차지했습니다. ELORA 는 tree 로 이 의존 관계를 지키고, query 가 올 때는 tree 를 따라 찾아 쓰며, 메모리 상태에 따라 점수로 무엇을 남길지 정해 TTFT 를 크게 줄였습니다. 한계로는 GPU 와 host 두 단계 메모리만 다루고, 점수식의 주기와 임계값에 대한 민감도 분석이 없다는 점을 들 수 있습니다.