로컬 LLM

지도 위치 : 3일차 · ③추론 엔진 층의 내부 · vLLM이 동시 요청을 견디는 이유 | 이전: 20차시 OpenAI 호환 API 활용 | 다음: 22차시 LLM Serving 성능 측정 키워드 : PagedAttention, KV Cache, Continuous Batching, 동시 요청 처리

이 차시를 다 읽으면

1. KV 캐시를 요청마다 최대 길이만큼 미리 잡으면 생기는 두 가지 낭비를 말할 수 있다.
2. PagedAttention 을 유와 종차로 정의하고, OS의 가상 메모리 · 페이징과 칸칸이 대응시킬 수 있다.
3. 정적 배칭과 연속 배칭 의 차이를 그림으로 설명할 수 있다.
4. 연속 배칭이 "한 건을 빠르게"가 아니라 "처리량을 늘리는" 기술인 이유를 "비동기는 빠른 게 아니라 처리량이다"와 같은 구조로 설명할 수 있다.
5. 프리픽스 캐싱 이 무엇을 재사용하는지, 그리고 왜 "서버 쪽 상태"인지 말할 수 있다.
6. KV 캐시가 꽉 찼을 때의 선점(preemption) 을 증상으로 알아볼 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 2차시 2.2에서 KV 캐시를 정의했고, 9차시에서 크기를 계산했고, 19차시에서 로그의 "Maximum concurrency"를 봤습니다. 그때 "실제 요청은 짧으면 더 많이 들어간다 "고 했습니다. 왜 그런지가 이 차시입니다.

---

1. 문제 — KV 캐시를 어디에 어떻게 담을 것인가

1.1 KV 캐시는 자라고, 얼마나 자랄지 모른다

앞에서 배운 대로 KV 캐시는 토큰 하나를 만들 때마다 한 칸씩 늘어납니다(2차시 2.2). 그런데 답이 몇 토큰이 될지는 생성이 끝나기 전엔 모릅니다. 문의 요약은 40토큰에서 끝날 수도, 300토큰까지 갈 수도 있습니다.

1.2 순진한 방법 — 최대 길이만큼 미리 잡기

모르니까 최대치(max-model-len)만큼 연속된 자리 를 요청마다 예약해 두는 방법이 가장 단순합니다.

KV 풀 (VRAM)
요청 A (실제 1,200 토큰) [■■■■■■□□□□□□□□□□□□□□□□□□□□□□□□□□□□]  ← 8192칸 예약
요청 B (실제   600 토큰) [■■■□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□]  ← 8192칸 예약
요청 C                    들어갈 연속 공간이 없어 대기
                                                   ■ 사용  □ 예약만 하고 빈 자리

숫자로 보면 심각합니다. 19차시 2.3의 이론 계산에서 KV 풀은 약 2.2만 ~ 2.8만 토큰이었습니다. 요청마다 8192씩 잡으면 3개 남짓 이지만, 실제 문의가 평균 1,500토큰이라면 같은 풀에 이론상 십수 개 가 들어갈 자리입니다(단순 나눗셈, 실측 아님). 차이는 전부 □입니다.

---

2. PagedAttention — 쓴 만큼만, 블록 단위로

2.1 정의

PagedAttention — [KV 캐시 메모리 관리 기법]인데, [ KV 캐시를 고정 크기 블록(페이지)으로 잘라 필요할 때마다 할당하고, 흩어진 블록을 블록 테이블로 이어 붙여 읽는다 ]는 점에서 요청마다 최대 길이의 연속 공간을 미리 잡는 방식과 구별된다.

요청 A의 블록 테이블:  논리 0 → 물리 7 │ 논리 1 → 물리 2 │ 논리 2 → 물리 9
요청 B의 블록 테이블:  논리 0 → 물리 4 │ 논리 1 → 물리 1

GPU의 KV 블록 풀 (블록 하나 = 토큰 여러 개, 크기는 버전 · 설정에 따름)
[0 빈] [1 B] [2 A] [3 빈] [4 B▒] [5 빈] [6 빈] [7 A] [8 빈] [9 A▒]
                                              ▒ = 마지막 블록, 일부만 참

• 요청은 자기 KV가 이어져 있다고 봅니다 (논리 0, 1, 2…). 실제로는 풀 여기저기에 흩어져 있습니다.
• 토큰이 블록 하나를 다 채우면 그때 새 블록 을 받습니다.
• 낭비는 요청마다 마지막 블록의 빈칸 하나 뿐입니다. 끝난 요청의 블록은 바로 풀로 돌아가고, 어느 자리든 재사용됩니다(외부 단편화 없음).

2.2 ⭐ OS 가상 메모리 · 페이징과 같은 발상

PagedAttention이라는 이름의 "Paged"는 운영체제(OS)가 RAM을 프로그램들에게 나눠 주는 방식에서 왔습니다. 그 방식을 먼저 짧게 봅니다.

가상 메모리 (Virtual Memory) — [메모리 관리 방식]인데, [ 프로그램(프로세스)마다 "0번지부터 쭉 이어진 나만의 메모리"가 있는 것처럼 보여 주고, 실제 RAM의 어느 자리를 쓸지는 OS가 뒤에서 따로 정한다 ]는 점에서 프로그램이 실제 RAM 주소를 직접 쓰는 방식과 구별된다.

페이징 (Paging) — [가상 메모리를 구현하는 방식]인데, [ 메모리를 같은 크기의 작은 조각(페이지)으로 잘라, 필요할 때마다 아무 빈 조각이나 내주고 "가상 주소 → 실제 위치" 대응표(페이지 테이블)로 이어 붙인다 ]는 점에서 연속된 큰 덩어리를 통째로 내주는 방식과 구별된다. 이 번역은 CPU 안의 MMU (메모리 관리 장치)가 하드웨어로 합니다.

프로세스가 보는 주소                                   실제 RAM
(가상 · 이어져 있음)                                   (물리 · 흩어져 있음)
  페이지 0  ──▶ ┌──────────────┐ ──▶  RAM 칸 3
  페이지 1  ──▶ │ 페이지 테이블 │ ──▶  RAM 칸 8
  페이지 2  ──▶ └──────────────┘ ──▶  RAM 칸 1
                 (MMU가 번역)

프로세스가 보는 "이어진 주소"는 추상 (약속)이고, 실제 RAM의 흩어진 자리는 구상 (실물)입니다. README 축 ②의 모양이 하드웨어 안에 들어가 있는 셈입니다. 그리고 1.2의 두 낭비 중 외부 단편화 가 이 방식으로 사라집니다. 연속 공간이 필요 없으니까요. PagedAttention은 같은 발상을 KV 캐시에 가져온 것 입니다.

2.3 반례 — PagedAttention이 하지 않는 것

💡 비유는 기억 보조로만 — 단체 손님마다 최대 인원만큼 붙은 자리 를 통째로 비워 두는 극장 ↔ 빈자리에 아무 데나 앉히고 좌석표로 일행을 이어 주는 극장.

---

3. 연속 배칭 — 스텝마다 들고 난다

3.1 왜 묶으면 이득인가

앞에서 배운 대로 Decode는 메모리 병목 입니다. 토큰 하나를 만들 때마다 가중치 전체를 메모리에서 읽어야 합니다(2차시 4절, 15차시). 요청 여러 개를 한 스텝에 묶으면 가중치를 한 번 읽어 여러 요청의 다음 토큰을 함께 계산합니다. 같은 읽기 비용으로 더 많은 토큰이 나옵니다. 이것이 배칭 (README 6장)의 이득입니다.

3.2 ⭐ 정적 배칭 ↔ 연속 배칭

[정적 배칭]  A·B·C·D를 한 배치로 묶어 시작. 배치가 다 끝나야 다음 배치
스텝 →  1  2  3  4  5  6  7  8  9  10
A       ■  ■  ■  ✓  ·  ·  ·  ·  ·  ·     ← 끝났는데 자리가 빈 채로 남음
B       ■  ■  ■  ■  ■  ■  ■  ■  ■  ✓
C       ■  ■  ✓  ·  ·  ·  ·  ·  ·  ·
D       ■  ■  ■  ■  ■  ✓  ·  ·  ·  ·
E       대기 ………………………………………………………… 11스텝부터 시작

[연속 배칭]  스텝마다 끝난 요청은 빼고 기다리던 요청을 넣음
스텝 →  1  2  3  4  5  6  7  8  9  10
A       ■  ■  ■  ✓
B       ■  ■  ■  ■  ■  ■  ■  ■  ■  ✓
C       ■  ■  ✓
D       ■  ■  ■  ■  ■  ✓
E                ■  ■  ■  ■  ■  ✓         ← C가 빠진 자리에 바로 들어감
F                   ■  ■  ■  ■  ✓         ← A가 빠진 자리에
G                         ■  ■  ■  ■ …   ← D가 빠진 자리에
                                  ■ 생성 중  ✓ 끝  · 빈 자리

연속 배칭 (Continuous Batching) — [배칭 방식]인데, [ 생성 스텝마다 끝난 요청을 빼고 기다리던 요청을 바로 넣는다 ]는 점에서 배치 전체가 끝날 때까지 구성원을 바꾸지 않는 정적 배칭과 구별된다.

두 기술은 짝입니다. 연속 배칭이 "아무 때나 들어오고 나가게" 하려면, 들어오는 요청에게 아무 데나 빈 블록을 줄 수 있어야 합니다. 그것이 PagedAttention입니다.

3.3 ⭐ 처리량이지, 한 건의 속도가 아니다

README 5.1에서 축 ⑥(동기 ↔ 비동기)에 붙여 둔 경고와 같은 구조입니다. 비동기 (결과를 기다리는 동안 멈춰 있지 않고 다른 일을 하는 방식)는 한 건을 빠르게 하지 않습니다. 한 건의 처리 시간은 동기든 비동기든 똑같고, 기다리는 시간에 다른 일을 하므로 같은 시간에 처리하는 양(처리량)이 늘어날 뿐입니다. 연속 배칭은 비동기와는 다른 기술이지만 효과의 모양이 같습니다. GPU가 놀던 빈자리(3.2 그림의 ·)를 다른 요청으로 채워 처리량 을 늘릴 뿐, 한 건을 빠르게 하지는 않습니다.

⚠️ 그래서 "vLLM으로 바꾸면 내 답이 빨라진다"는 기대는 틀릴 수 있습니다. 혼자 쓰면 Ollama와 비슷하거나 더 무거울 수 있습니다(24차시). vLLM이 이기는 곳은 여럿이 동시에 쓰는 곳입니다. 축 ⑤의 오른쪽.

💡 최신 vLLM은 새 요청의 Prefill을 잘게 나눠 진행 중인 Decode와 같은 스텝에 섞기도 합니다. 한 스텝에 처리할 토큰 수 상한이 --max-num-batched-tokens이고, 한 스텝에 함께 도는 요청 수 상한이 --max-num-seqs입니다. 손잡이는 23차시에서 봅니다.

---

4. 프리픽스 캐싱 — 같은 앞부분을 다시 계산하지 않는다

4.1 정의와 문의봇

문의봇의 모든 요청은 같은 시스템 프롬프트 (역할 · 분류 규칙 · 출력 형식 · 예시 몇 개)로 시작합니다. 수백 ~ 수천 토큰입니다. 요청마다 이 부분의 Prefill을 처음부터 다시 하는 것은 낭비입니다.

프리픽스 캐싱 (Prefix Caching) — [KV 캐시 재사용 기법]인데, [ 앞부분 토큰이 똑같은 요청끼리 이미 계산해 둔 KV 블록을 공유한다 ]는 점에서 응답 자체를 저장해 두는 웹 캐시와 구별된다.

설정은 --enable-prefix-caching인데, 최신 버전은 기본으로 켜져 있을 수 있습니다 (버전 확인).

4.2 ⭐ 무상태 API인데 서버가 기억한다? — 축 ⑦

20차시 2.1에서 "API는 무상태, 서버는 이전 대화를 기억하지 않는다" 고 했습니다. 그런데 프리픽스 캐시는 분명 서버가 쥐고 있는 상태 입니다. 모순일까요?

앞에서 배운 무상태 (8차시 1.1)의 정의가 답입니다. 무상태는 [ 요청 하나하나를 그 요청 안에 담긴 정보만으로 처리하고, 이전 요청을 기억해 주지 않는다 ]는 성질이었고, 그때 짚은 대로 무상태인 것은 통신 구간뿐 입니다. 서버 안에 아무것도 없다는 뜻이 아닙니다.

⭐ 캐시는 정답성이 아니라 속도 에 쓰이는 상태입니다. 그래서 서버를 재시작해 캐시가 날아가도 앱은 아무것도 고칠 필요가 없습니다.

4.3 캐시가 잘 맞게 프롬프트를 놓는 법

프리픽스 캐싱은 앞에서부터 글자 하나까지 똑같아야 맞습니다.

앞으로 다시 만납니다 — 28차시(프롬프트 설계)에서 시스템 프롬프트를 파일로 관리할 때, 27차시(대화형)에서 대화 기록이 길어질 때 이 표를 다시 씁니다. 대화형에서는 같은 대화의 이전 턴 이 그대로 프리픽스가 됩니다.

---

5. KV 캐시가 꽉 차면 — 선점 (Preemption)

요청들이 생성을 이어 가며 블록을 계속 요구하다 보면 풀이 바닥날 수 있습니다. 그러면 vLLM은 일부 요청을 잠시 빼서(선점) 뒤로 미루고 , 자리가 나면 다시 이어 갑니다. 다시 이을 때 KV를 재계산 하거나 다른 곳에 옮겨 둔 것을 되가져옵니다(방식은 버전마다 다름). 로그에 preempt 관련 경고가 찍힙니다.

2.2 표 마지막 줄의 스왑 과 같은 모양입니다. 스왑 은 RAM이 모자랄 때 OS가 당장 안 쓰는 페이지를 디스크로 내렸다가, 다시 필요해지면 올려 오는 동작입니다. 디스크는 RAM보다 훨씬 느리므로 스왑이 잦은 컴퓨터는 갑자기 아주 느려집니다. 선점이 잦은 vLLM도 그렇습니다.

⭐ 축 ⑤ 하나 ↔ 여럿으로 정리하면, vLLM은 여럿을 받기 위해 메모리를 블록으로 쪼개고(2절), 스텝마다 섞고(3절), 앞부분을 나누고(4절), 넘치면 밀어냅니다(5절). 네 장치 모두 한 건의 속도가 아니라 동시 수용량 을 위한 것입니다.

---

6. 실습 — 맡기고 검수하기

이 차시는 관찰 입니다. 정식 측정은 22차시에서 합니다.

지시

19차시의 vLLM 서버(127.0.0.1:8000, munuibot)로 아래 관찰을 해줘.
맥락: vLLM 공식 문서의 PagedAttention · prefix caching · metrics 설명을 근거로. 기억으로 쓰지 마.
제약: 기동 옵션은 바꾸지 말고, 사용한 기동 명령 원문을 함께 보고. temperature 0, max_tokens 200 고정. 워밍업 1회는 버릴 것.
할 일:
1. 요청 1건만 보냈을 때: 그 요청의 출력 토큰/초.
2. 같은 요청 8건을 동시에 보냈을 때: 요청별 출력 토큰/초, 그리고 서버 전체 처리량(출력 토큰 합 ÷ 전체 경과 시간).
3. 긴 공통 시스템 프롬프트(약 1,500토큰)로 같은 요청을 2번 연속: 각 TTFT.
   이어서 시스템 프롬프트 맨 앞에 현재 시각(초 단위)을 넣고 2번 연속: 각 TTFT.
4. 2번을 하는 동안 /metrics에서 실행 중 요청 수, 대기 요청 수, KV 캐시 사용률 값을 1초마다 기록.
   (지표 이름은 내 버전의 /metrics 출력에서 직접 찾아 그대로 써.)
5. 서버 로그에 preempt 관련 줄이 있었는지.
보고 형식: [실험 | 조건 | 측정값 | 출력 원문] 표. 추측하지 말고 실행 출력 원문을 붙여.

받을 증거

• 실험 1~3의 측정값과 측정 스크립트 출력 원문
• /metrics에서 뽑은 시계열 (시각 | 실행 중 | 대기 | KV 사용률)
• 서버 로그의 preempt 줄 (없으면 "없음")

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 21차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"PagedAttention과 OS 페이징의 대응", "정적 배칭 vs 연속 배칭", "연속 배칭은 처리량이지 한 건의 속도가 아니다", "프리픽스 캐시와 무상태 API"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.