Efficient Memory Management for Large Language Model Serving with PagedAttention

Introduction

GPT $_[$$_{5}$$_,$$_{37}$$_]$, PaLM $_[$$_{9}$$_]$과 같은 large language models (LLMs)의 등장으로 programming assistant $_[$$_{6}$$_,$$_{18}$$_]$와 범용적인 chatbot $_[$$_{19}$$_,$$_{35}$$_]$과 같은 새로운 applications로 인해 우리의 일과 일상에 큰 영향을 미치기 시작했다.
다양한 cloud 회사들 $_[$$_{34}$$_,$$_{44}$$_]$이 hosted services로 이러한 applications를 제공하기 위해 경쟁 중이지만, 매우 비싸고 GPU와 같은 hardware 가속기가 매우 많이 필요하다.
최근 추정에 따르면 LLM 요청 처리 비용은 기존 keyword query보다 10$\times$ 더 비쌀 수 있다 $_[$$_{43}$$_]$.
따라서 이러한 높은 비용을 고려했을 때, LLM serving system의 throughput을 높이고 요청당 비용을 줄이는 것이 더욱 중요해지고 있다.

LLM의 core에는 autoregressive Transformer model $_[$$_{53}$$_]$이 있고, 이 model은 입력 (prompt)과 지금까지 생성한 출력 tokens의 이전 sequence를 기반으로 한 번에 하나씩 단어들 (tokens)을 생성한다.
매 요청마다 이러한 값비싼 process는 termination token을 출력하기 전까지 반복되며 이러한 순차적 생성 process는 workload를 memory에 집중시켜 GPU의 연산 능력을 충분히 활용하지 못하고 throughput을 제한한다.

pie
    "Parameters (26GB, 65%)" : 65
    "KV Cache (>30%)" : 30
    "Others" : 5

Figure 1. Memory layout when serving an LLM with 13B parameters on NVIDIA A100. The parameters persist in GPU memory throughout serving. The memory for the KV cache is (de)allocated per serving request

Throughput은 다수의 요청을 batching하여 개산할 수 있지만 batch 내에서 다수의 요청을 처리하려면 각 요청을 위한 memory가 효율적으로 관리되어야한다.
예를 들어, Fig. 1은 40GB RAM을 가지는 NVIDIA A100 GPU에서 130억 (13B) parameter
LLM의 memory 분포를 보여준다.
약 65%의 memory가 serving 중 고정적이게 model 가중치로 할당되고, 약 30%의 memory가 요청에 대한 동적인 상태 (dynamic states)를 저장하기 위해 사용될 것이다.
Transformers에서 이러한 상태는 KV cache $_[$$_{41}$$_]$라고 불리는 attention mechanism과 관련된 key와 value tensors로 구성되며, 이는 이전 tokens의 context를 나타내어 순서대로 새 출력 token을 생성한다.
그리고 남아있는 나머지 memory는 LLM을 평가할 때 생성되는 일시적인 tensor인 activation을 포함한 다른 data에서 사용된다.
Model의 가중치는 고정되어있고, activations는 GPU memory의 작은 부분만 차지하므로 KV cache가 관리되는 방식은 최대 batch size를 결정하는데 중요하며 비효율적으로 관리될 경우 KV cache memory는 batch size를 크게 제한하고, 결과적으로 LLM의 throughput을 제한할 수 있다.

Read more »

Introduction

In the previous article, I explored why vLLM is gaining popularity and the process of setting up an OpenAI-compatible server when using vllm serve.
While the first article focused on the architectural foundations and server initialization process, in this article, I want to dive deeper into the runtime behavior and request processing pipeline.

The /v1/chat/completions endpoint has become the de facto standard for conversational AI applications, powering everything from customer service chatbots to sophisticated AI assistants.
Unlike the legacy /v1/completions endpoint, which operates on simple text completion, the chat completions endpoint provides structured message handling, role-based conversations, and built-in context management.

Through this deep dive, I’ll walk you through:

  • Endpoint Comparison: Detailed comparison between /v1/completions and /v1/chat/completions
  • Request Processing: Step-by-step breakdown of how chat messages are preprocessed and transformed
  • Chat Template System: How vLLM applies model-specific chat templates to structure conversations
  • Internal Pipeline: Deep dive into the inference process, from message parsing to response generation
  • Performance Considerations: Understanding token efficiency and memory management in chat contexts

By examining vLLM’s implementation of the OpenAI-compatible chat completions endpoint, I’ll uncover the sophisticated engineering that enables high-performance conversational AI serving while maintaining full API compatibility.

Read more »

Introduction

vLLM $_[$$_{1}$$_,$$_{2}$$_]$ is a fast and easy-to-use library for LLM inference and serving.
Originally developed in the Sky Computing Lab at UC Berkeley, vLLM has evolved into a community-driven project with contributions from both academia and industry. $_[$$_{3}$$_]$

The rapid advancement of Large Language Models (LLMs) has brought efficient model serving and inference optimization to the forefront of MLOps concerns.
In response to these challenges, vLLM has emerged as a leading solution, garnering significant attention with 49.2k stars on GitHub as of June 9, 2025.
As demonstrated in the star history graph below, vLLM has established itself as the most prominent LLM serving framework among various competing solutions.

star-history-202569

A particularly noteworthy aspect is the standardized API interface provided by OpenAI’s GPT series.
With countless developers already building applications based on this API specification, ensuring compatibility has become crucial for any LLM serving solution.
This article provides a comprehensive analysis of vLLM’s core technological foundations and examines the internal implementation processes that enable OpenAI-compatible server deployment when executing the vllm serve command.

Read more »

결제 시스템

결제 (payment) system: 금전적 가치의 이전을 통해 금융 거래를 정산하는 데 사용되는 모든 system

1단계: 문제 이해 및 설계 범위 확정

  • 기능 요구사항
    • 대금 수신 (pay-in) 흐름: 결제 system이 판매자를 대신하여 고객으로부터 대금 수령
    • 대금 정산 (pay-out) 흐름: 결제 system이 전 세계의 판매자에게 제품 판매 대금 송금
  • 비기능 요구사항
    • 신뢰성 및 내결함성: 결제 실패는 신중하게 처리
    • 내부 service (결제 system, 회계 system)와 외부 service (결제 servcice 제공업체) 간의 조정 process: System 간의 결제 정보가 일치하는지 비동기적으로 확인
  • 개략적인 규모 추정
    • 하루에 100만 건의 transaction 처리
    • $1,000,000/10^5=10TPS$
    • 10TPS는 일반적 database로 문제 없이 처리 가능하기 때문에 처리 대역폭 대신 결제 transaction의 정확한 처리에 초점
Read more »

실시간 게임 순위표

순위표: Leaderboard of an online mobile game

1단계: 문제 이해 및 설계 범위 확정

  • 기능 요구사항
    • 순위표에 상위 10명의 player 표시
    • 특정 사용자의 순위 표시
    • 어떤 사용자보다 4순위 위와 아래에 있는 사용자 표시
  • 비기능 요구사항
    • 점수 update는 실시간으로 순위표에 반영
    • 일반적인 확장성, 가용성 및 안정성 요구사항
  • 개략적 규모 추정
    • Game을 하는 사용자가 24시간 동안 고르게 분포 가정
      • DAU가 5,000,000명인 경우 초당 평균 50명 game play
      • $\because\frac{5,000,000DAU}{10^5sec}\simeq50$
    • 하지만 그렇게 균등한 경우는 존재하지 않고 북미 지역 기준 저녁 시간이 peak 시간대일 가능성이 높음
      • 최대 부하는 평균의 5배라 가정
      • $\therefore$ 초당 최대 250명의 사용자를 감당할 수 있어야 함
    • 사용자 점수 획득 QPS
      • 한 사용자가 하루 평균 10개 game play 가정
      • $\therefore 50\times10\times5=2,500$
    • 상위 10명 순위표 가져오기 QPS
      • 각 사용자가 하루에 한 번 game을 열고 상위 10명 순위표는 사용자가 처음 게임을 열 때만 표시한다고 가정
      • 초당 평균 50명이 game play하기 때문에 QPS는 약 50
Read more »