LLM 서빙의 병목: KV 캐시, 배치, GPU

답 하나가 나오기까지

LLM에 질문하면 다섯 단계가 토큰마다 반복된다.

flowchart TB
  n1["① 입력 텍스트"] --> n2["② 토큰화: 텍스트를 토큰(단어나 단어 조각)으로 자른다"]
  n2 --> n3["③ 임베딩: 토큰마다 숫자 벡터로 바꾼다"]
  n3 --> n4["④ 가중치 곱: 임베딩을 수천억 개의 가중치와 곱한다<br/>← 연산이 몰리는 곳"]
  n4 --> n5["⑤ 샘플링: 다음 토큰의 확률에서 하나를 골라 사용자에게 보낸다"]
  n5 -->|"고른 토큰을 입력 끝에 붙여 ②~⑤를 다시 (초당 여러 번)"| n2

모델이 무엇을 계산하는지는 LLM은 무엇을 하고 왜 작동하나에 있다. 이 노트는 그 계산을 많은 사람에게 빠르게 돌리는 일, 즉 서빙(serving)을 다룬다. 사용자가 수억 명 규모로 늘 때 부딪히는 문제는 아래 다섯 가지로 모인다.

어텐션과 KV 캐시

새 토큰을 만들 때 어텐션은 앞의 모든 토큰을 참고한다. 토큰마다 앞 토큰 전부와 계산하므로 전체 비용은 컨텍스트 길이의 제곱으로 커진다. 대화가 길수록 비싸다.

어텐션은 토큰마다 Query·Key·Value 세 벡터를 쓴다. 앞 토큰들의 Key와 Value는 다음 토큰을 만들 때도 그대로이므로 저장해 두고 다시 쓴다. 이것이 KV 캐시다. Query는 매 단계 새 토큰의 것이라 캐시하지 않는다.

사실	결과
KV 캐시는 GPU의 HBM(고대역폭 메모리)에 둔다	HBM은 초당 수 TB를 옮기지만, PCIe로 CPU 메모리를 오가면 약 100배 느리다
캐시가 없으면 대화 전체를 다시 계산한다	긴 대화일수록 캐시 미스가 비싸다
GPU 메모리는 여러 사용자가 나눠 쓴다	오래 쉬는 대화의 캐시는 내보내(evict) 자리를 만든다

그래서 대규모 서빙에서 가장 자주 부딪히는 병목은 연산이 아니라 GPU 메모리다.

산술 강도와 배치 크기

GPU가 일하는 속도는 두 가지 중 느린 쪽에 묶인다. 연산 장치가 계산하는 속도, 그리고 메모리에서 데이터를 가져오는 속도다. 메모리에서 가져온 1바이트당 몇 번 계산할 수 있어야 연산 장치가 쉬지 않는지가 산술 강도(arithmetic intensity) 다.

GPU	FP8 연산 (dense)	메모리 대역폭	바이트당 연산
H100 SXM	약 1,979 TFLOPS	3.35 TB/s	약 591
H200	약 1,979 TFLOPS	4.8 TB/s	약 412
B200	약 4,500 TFLOPS	약 8 TB/s	약 562

가중치 하나를 메모리에서 읽어 와 요청 하나에만 쓰면 연산 장치는 대부분 논다. 여러 요청을 묶어 같은 가중치로 한꺼번에 계산하면 바이트당 연산이 늘어난다. 동시에 처리하는 요청 수가 배치 크기이고, 산술 강도를 채우는 주된 손잡이다. 배치를 키우면 KV 캐시도 그만큼 많이 필요하므로, 배치 크기와 메모리 사이의 균형이 서빙 성능을 정한다.

사양서의 최대 FLOPS는 실제로는 거의 낼 수 없다. 최적점은 계산만으로 정해지지 않아 운영 중에 실험하며 찾는다.
칩 세대가 바뀌면 연산이 메모리보다 빨리 는다. H100은 A100보다 연산이 약 6배지만 메모리 대역폭은 약 1.6배였다. 늘어난 연산을 쓰지 못하는 경우가 많아 H200은 메모리를 키웠다.
프롬프트를 한꺼번에 읽는 prefill은 연산에, 토큰을 하나씩 만드는 decode는 메모리 대역폭에 묶이기 쉽다. 그래서 두 단계를 서로 다른 GPU에 나눠 돌리기도 한다.

메모리 접근이 연산보다 비싸다는 원리 자체는 CPU에서도 같다. 캐시를 고려한 코드를 참고한다.

지금의 서빙 기법

위의 문제들은 이제 서빙 엔진과 API가 기본 기능으로 다룬다.

기법	푸는 문제
PagedAttention (vLLM)	KV 캐시를 운영체제의 가상 메모리처럼 고정 크기 블록으로 나눠 필요할 때 할당한다. 연속 공간을 미리 잡지 않아 메모리 낭비가 줄고 배치를 키울 수 있다
연속 배치(continuous batching)	배치 전체가 끝나기를 기다리지 않고, 요청 하나가 끝나는 즉시 새 요청을 끼워 넣는다
접두사 캐싱(prefix caching)	같은 시스템 프롬프트·문서로 시작하는 요청끼리 KV 블록을 공유해 prefill을 건너뛴다. API 제공자의 프롬프트 캐싱이 같은 원리로 반복되는 앞부분의 비용과 지연을 줄인다
양자화	가중치를 FP8·FP4처럼 적은 비트로 저장해 메모리와 대역폭을 아낀다

지표: GPU 사용률이 속인다

흔히 보는 GPU 사용률은 GPU가 무언가 하고 있었는지만 알려 준다. 산술 강도를 채웠는지, KV 캐시가 바닥나고 있는지는 말해 주지 않는다. 사용률이 높아도 메모리를 기다리며 놀고 있을 수 있다.

배치 크기와 KV 캐시 사용률을 주 지표로 삼는다.
그 밖의 병목으로 메모리 대역폭, GPU 사이와 노드 사이의 네트워크 대역폭이 있다. GPU는 노드당 8개씩 묶고, 노드 안은 NVLink, 노드 사이는 InfiniBand로 잇는다.
병목은 작업에 따라 옮겨 간다. 긴 글을 요약하는 요청(입력이 김)과 긴 글을 쓰는 요청(출력이 김)은 시스템에 주는 부담이 다르다.

GPU가 있는 곳으로 간다

GPU 공급이 수요를 따라가지 못하면 여러 지역·데이터 센터에서 GPU가 있는 곳마다 클러스터를 띄운다.

처음부터 다중 지역·다중 클러스터로 설계하고, Kubernetes 클러스터를 하나하나 돌보는 애완동물(pet)이 아니라 언제든 갈아 끼우는 가축(cattle)으로 다룬다.
사용자와 가까운 곳보다 GPU 전체를 고르게 쓰는 것이 중요하다. 응답 시간은 토큰을 만들어 흘려보내는 속도가 지배하므로 네트워크 거리는 상대적으로 작다. 엣지에 가까이 두라는 웹 서비스의 상식이 그대로 통하지 않는다.

오토스케일이 안 된다

웹 서버는 트래픽이 늘면 클라우드에서 서버를 더 빌린다(웹 확장성의 구성 요소). LLM 서빙에서는 빌릴 GPU 자체가 없는 경우가 많다. 큰 모델은 CPU로 돌리면 몇 자릿수 느려 대안이 되지 못한다. 수요를 줄이거나(대기, 사용량 제한) 같은 GPU로 더 많이 처리하는 효율 작업밖에 길이 없다.

교훈

교훈	내용
모든 층에서 일한다	KV 캐시 최적화나 CUDA 커널 같은 저수준 작업과 전 세계 데이터 센터 전략이 똑같이 중요하다
제약에 맞춰 상식을 버린다	CPU 사용률 80% 목표, 클라우드 용량은 무한하다는 가정, 엣지 우선 같은 관례가 맞지 않는다. 모델 구조가 바뀌면 방법도 바뀐다
깊이 판다	모델이 어떻게 동작하는지 세부까지 이해해야 서빙 최적화 지점이 보인다
수학으로 풀리는 문제가 있다	적절한 배치 크기는 연산량과 메모리 대역폭의 비로 구할 수 있다
메모리와 연산을 맞바꾼다	KV 캐시처럼 메모리를 써서 연산을 아끼거나, 그 반대로 간다

하드웨어가 모자라면 효율을 짜내는 기법이 나온다. 가상화가 그랬듯, LLM 서빙도 GPU 부족이 PagedAttention·연속 배치 같은 기법을 낳았다. 컴퓨트 부족이 AI 산업에 주는 의미는 스케일과 지능 유틸리티에 있다.

정리

LLM은 토큰마다 수천억 개의 가중치를 곱하고, 어텐션 비용은 컨텍스트 길이의 제곱으로 커진다.
KV 캐시가 반복 계산을 없애지만 GPU 메모리를 차지해, 연산보다 메모리가 먼저 병목이 된다.
배치 크기로 산술 강도를 채우고, 배치와 KV 캐시 사이의 균형을 맞춘다.
GPU 사용률 대신 배치 크기와 KV 캐시 사용률을 본다.
GPU가 모자라면 오토스케일도 엣지 배치도 통하지 않는다. 남는 길은 효율이다.

버그 제보