PagedAttention - 태그 - lee's bloghttps://ken-0913.github.io/myblog/tags/pagedattention/PagedAttention - 태그 - lee's blogHugo -- gohugo.ioko-krhyeonjae0913@gmail.com (ken-0913)hyeonjae0913@gmail.com (ken-0913)Sat, 22 Aug 2026 02:49:06 +0900LLM 스터디 3주차 - PagedAttention 직접 증명하기 — vLLM 블록 테이블 꺼내 보기https://ken-0913.github.io/myblog/posts/llm/llm-paged-attention-verify/Sat, 22 Aug 2026 02:49:06 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-paged-attention-verify/

LLM은 도중에 계산 결과를 어딘가 보관해야한다. GPU 메모리에 보관하며 토큰이 커질 수록 역시 커진다. 

  • 일반적인 최대치를 상정하여 대비한다. 최대 512토큰이 들어 올 수 있으니 32칸을 비워두세요. (하나의 KV블락당 16이라 가정)
  • 실제로 6 토큰만 들어오면 나머지 31블락은 쓸모가 없어지는 경우가 생긴다
  • 이 쓸모없어진 블락은 사용할 수 없다.

그림으로 보면 이렇다.

연속 할당의 낭비 — 최대치를 미리 잡아 둔다

512칸을 예약해 놓고 6칸만 쓴다. 나머지 506칸(98.8%)은 비어 있는데도 다른 요청이 가져다 쓸 수 없다.

]]>LLM 스터디 3주차 - LLM 서빙 최적화 기법 — 배칭·어텐션·양자화·prefix 캐싱https://ken-0913.github.io/myblog/posts/llm/llm-essential-llm-optimization-techniques/Fri, 21 Aug 2026 21:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-essential-llm-optimization-techniques/

앞 글에서 병목이 어디에 있는지를 봤다. 이번에는  병목을 실제로 풀어보자. 

prefill은 프롬프트 토큰을 한꺼번에 처리해 연산 강도가 높다. (앞서 말했듯이 연산강도가 높다는 것은 같은 가중치를 한 번 읽고 그것으로 훨씬 많은 토큰을 처리한다)

문제는 decode다. 토큰 하나를 만들려고 수십억 개 파라미터를 전부 읽어야 하니 대역폭만 축내고 연산 유닛은 유휴상태이다. 

여기서 배칭이 들어간다. 요청 세 개를 묶으면 가중치는 여전히 한 번만 읽으면서 토큰은 세 개를 만든다. 연산 강도를 인위적으로 끌어올린다.

]]>LLM 스터디 3주차 - vLLM은 왜 빠른가 — PagedAttention과 연속 배칭 직접 재현하기https://ken-0913.github.io/myblog/posts/llm/llm-vllm-lab/Tue, 18 Aug 2026 20:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-vllm-lab/

2주차 실습들은 서빙 시스템을 어떻게 구성하는지를 다뤘다. 이번에는 질문이 안쪽으로 향한다. vLLM은 정확히 무엇 때문에 빠른가.

CPU만 있는 4GB VM에서 SmolLM-135M을 8단계로 굴린다. HuggingFace 베이스라인을 재고, vLLM과 비교하고, KV 캐시가 낭비되는 과정을 숫자로 본 뒤 PagedAttention이 그것을 어떻게 되돌리는지 확인한다.

결론부터 말하면 단일 요청에서 vLLM은 1.1배밖에 빠르지 않다. 진짜 차이는 동시 사용자가 붙을 때 나온다. 이 글의 8단계는 그 격차가 어디서 오는지를 따라가는 순서다.

GPU가 없다. vLLM의 CPU 빌드를 쓰고, 4GB 메모리 제한 때문에 엔진을 in-process로 띄운다.

]]>