PagedAttention是什麼？Block Table、KV碎片與vLLM記憶體管理

PagedAttention是什麼？Block Table、KV碎片與vLLM記憶體管理

先講結論：PagedAttention把每個Sequence的KV Cache切成固定Token Block，再用Block Table映射Logical與Physical Memory，降低連續預留與碎片。本文解析Block Pool、Reference Count、Eviction、Copy-on-write、Kernel與vLLM記憶體管理。

PagedAttention是什麼？Block Table、KV碎片與vLLM記憶體管理在講什麼？ PagedAttention把每個Sequence的KV Cache切成固定Token Block，再用Block Table映射Logical與Physical Memory，降低連續預留與碎片。本文解析Block Pool、Reference Count、Eviction、Copy-on-write、Kernel與vLLM記憶體管理。

先記住哪個結論？ 核心是把「PagedAttention是什麼？Block Table、KV碎片與vLLM記憶體管理」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：PagedAttention把每個Sequence的KV Cache切成固定Token Block，再用Block Table映射Logical與Physical Memory，降低連續預留與碎片。本文解析Block Pool、Reference Count、Eviction、Copy-on-write、Kernel與vLLM記憶體管理。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「PagedAttention是什麼 Block Table KV碎片與vLLM記憶…」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：PagedAttention把每個Sequence的KV Cache切成固定Token Block，再用Block Table映射Logical與Physical Memory，降低連續預留與碎片。本文解析Block Pool、Reference Count、Eviction、Copy-on-write、Kernel與vLLM記憶體管理。

PagedAttention是vLLM用來管理KV Cache的核心方法。它把每個請求的KV切成固定Token數的Block，讓邏輯上連續的上下文可以放在不連續的GPU記憶體位置，再由Block Table把Sequence對應到實際Physical Blocks。

它解決的主要問題是記憶體預留與碎片，不是改變模型注意力公式。高併發服務中的請求長度很難預測；若每個請求一開始就預留最大連續空間，大量未使用容量會限制Batch和Throughput。PagedAttention改成按需分配Block，使KV生命週期更接近作業系統分頁。

• 每個Block保存固定Token數的Key與Value。
• Logical Block順序和Physical GPU位置由Block Table分開。
• 按需分配降低最大長度預留與External Fragmentation。
• vLLM v1以預先建立的Block Pool與Free Block Queue管理容量。
• Reference Count避免仍被Request使用的Block被驅逐。
• Prefix Cache只快取完整Block，部分Block通常不能直接命中。
• 共享和Fork可透過Reference及Copy-on-write思路降低複製。
• PagedAttention主要提高記憶體利用和Throughput，不保證單一請求更快。

PagedAttention、Block Table 與 vLLM 記憶體管理

PagedAttention 解決的是 LLM 推論時 KV cache 的記憶體浪費：把連續配置改成分頁／區塊管理，並用 Block Table 對應邏輯序列與實體記憶體。文章將 attention、KV cache、碎片與 vLLM 排程分開。

推論記憶體如何被管理

• KV cache：自回歸生成需要保存過往 token 的 key／value，序列越多，容量壓力越大。
• Block Table：把邏輯 token 區塊映射到不連續的實體區塊，減少預留與碎片。
• 系統端：vLLM 透過排程、共享前綴與記憶體回收提高吞吐，但仍受 GPU 容量與工作負載限制。

本文以「PagedAttention、Block Table 與 vLLM 記憶體管理」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

傳統連續配置為什麼浪費？

推論服務在請求開始時不知道最後會生成多少Token。若為每個Request預留完整最大Context，短回答會留下大量空間；若只按目前長度分配連續記憶體，後續擴張又可能找不到足夠大的連續區域。

問題	連續配置	PagedAttention
未知輸出長度	先預留或搬移	需要時追加Block
外部碎片	空洞難重新利用	固定Block可由不同Request回收
共享Prefix	常需複製完整區段	可共享相同Block
Preemption	回收粒度較粗	按Block管理

Logical Block與Physical Block

Request A logical blocks: [0, 1, 2, 3]
Block Table:             [17, 4, 31, 9]

Request B logical blocks: [0, 1, 2]
Block Table:              [17, 4, 22]

兩個Request在邏輯上都從Block 0開始，實際GPU位置可以完全不同。若A和B共享相同Prefix，前兩個Physical Blocks甚至可以相同；分歧後才配置新的Block。

Attention Kernel不能假設KV在連續地址，必須先讀Block Table，再從對應Block取得Key與Value。這是PagedAttention帶來的主要Kernel工程成本。

vLLM v1的Block Pool

vLLM目前在KV Cache Manager初始化時預先建立所有KVCacheBlock，形成Block Pool，並使用Free Block Queue追蹤可分配Block。Block物件包含Block ID、Hash、Reference Count和Free Queue Pointer。

KVCacheBlock:
  block_id: immutable
  block_hash: optional
  ref_count: integer
  prev_free_block: pointer
  next_free_block: pointer

• 預先建立Block避免高頻Python物件建立。
• 雙向Linked List使Free Queue移動接近O(1)。
• Request Blocks保存每個Request使用哪些Block。
• Cached Blocks從Hash對應可重用Block ID。
• Allocation不足時Scheduler決定等待、Preempt或拒絕。

Allocation與Append

1. Scheduler計算已經命中的Computed Blocks。
2. 確認新Prompt與預計Token需要多少Block。
3. 命中Block增加Reference Count並離開Free Queue。
4. 新Block從Free Queue頭部取出。
5. 每生成Token，KV寫入目前Block Slot。
6. Block填滿後可以加入Prefix Cache。
7. 需要更多Context時再追加Block。

Prefix Cache通常只處理完整Block。假設Block Size為16，兩個Prompt只有前10個Token相同，該部分不一定能直接命中；Prefix Match Granularity和Physical Block Size也可能依引擎版本與模型配置不同。

Reference Count與共享

同一個KV Block可能被目前Request、另一個共享Prefix的Request或多個Beam同時使用。Reference Count用來避免Block在仍被引用時回收到Free Queue。

• 新Request命中Cache時增加Reference。
• Request完成或取消時降低Reference。
• Reference歸零後Block可回到Free Queue。
• 仍有Hash的Block可以保留為可重用Cache。
• 需要覆寫共享Block時分配新Block，避免修改其他Sequence。

這種Copy-on-write思路在Beam Search、Parallel Sampling和Forked Session中特別有價值，因為多條路徑在分歧前共享相同歷史。

Eviction與Free Queue

已完成Request的Block可以回到Free Queue，但其中的Hash與KV可能暫時保留，等待Prefix命中。當新請求需要容量時，系統從Free Queue取得Block；若該Block仍是Cached Block，就同時從Cache Mapping驅逐。

• 優先不能驅逐Reference大於零的Block。
• LRU或相近策略決定舊Cache回收順序。
• 取消與Timeout要立即釋放Reference。
• Cache Hit Block在Allocation前要先Touch。
• 多租戶要防止跨Tenant共享和Timing Side Channel。

PagedAttention Kernel在做什麼？

Decode階段通常只有一個新Query Token，要和整段歷史KV計算Attention。vLLM的Paged Attention Kernel依Sequence、Head與Partition組成Grid；Warp讀取不同KV Blocks，計算Query-Key分數、Softmax與Value聚合。

• Block Size決定每個KV Block包含多少Token。
• Thread Group協作載入Query和Key向量。
• Warp可輪流處理同一Context的多個Block。
• Vectorized Load降低不對齊與指令數。
• Long Context可能使用Partition Reduction。
• 不同Head Size、資料型別與GPU需要不同Kernel路徑。

PagedAttention不是單一Python資料結構。Scheduler、KV Manager、Block Table與GPU Kernel必須一起支援，否則非連續Block會讓讀取效率抵消記憶體收益。

PagedAttention和Automatic Prefix Caching

PagedAttention提供可共享Block；Automatic Prefix Caching決定如何辨識相同Prefix。vLLM目前以Parent Hash、Block Tokens與Extra Hash建立Block Key，Extra Hash可包含LoRA ID、Multimodal Input Hash和Cache Salt。

Prefix Cache的Hash、命中、Security Salt與Eviction不屬於PagedAttention本身。共同前綴策略可以閱讀RadixAttention怎麼運作？；KV全貌可閱讀KV Cache是什麼？。

Block Size怎麼選？

較小Block	較大Block
內部浪費較少	Metadata和Block Table較小
Prefix Match粒度較細	連續讀取較容易最佳化
管理與Hash次數較多	Partial Block浪費較高
Kernel與Scheduler壓力較高	短序列可能利用不足

最佳值依模型、Attention Backend、Head Size、Context分布與GPU而定。不要只用官方預設或單一Microbenchmark決定。

評估指標

• KV Block使用率與Free Block數。
• Internal／External Fragmentation。
• Preemption、Swap和Recompute次數。
• Prefix Cache Hit Tokens。
• 同顯存下可承載Sequence數。
• TTFT、TPOT、Throughput與P99。
• Block Allocation和Scheduler CPU時間。
• 不同Block Size的Kernel效率。

最有價值的結果通常不是單一Request快幾毫秒，而是同一GPU能在SLO內服務更多並發請求。

常見問題

PagedAttention會降低模型品質嗎？

正確實作只改變KV儲存與讀取位置，不應改變模型數學結果。量化、錯誤Block Mapping或Kernel問題才可能影響品質。

PagedAttention和FlashAttention可以一起用嗎？

可以。PagedAttention主要處理Serving KV配置；FlashAttention處理Attention計算與記憶體I/O。引擎可在不同Prefill／Decode路徑組合相容Backend。

它會讓單一回答一定更快嗎？

不一定。主要收益是記憶體利用與高併發Throughput；單一請求仍受Kernel、模型、排程和硬體影響。

官方資料

• vLLM Paged Attention設計
• vLLM Automatic Prefix Caching
• vLLM KV Cache Manager API

PagedAttention把KV Cache從大塊連續預留，轉成可分配、共享、引用和回收的Block。真正收益來自Block Manager、Scheduler與Kernel共同降低浪費，而非「分頁」這個名稱本身。

本文配圖取自 vLLM 官方 Paged Attention 設計文件中的 Key memory layout 圖，用來對照 Block、Token 與 GPU memory 的配置關係；實際 kernel 版本與參數仍應以官方文件及程式碼版本為準。

若想把記憶體最佳化延伸到 vLLM 的研究與產品脈絡，可接著閱讀 vLLM與Chatbot Arena脈絡。

增量觀察｜PagedAttention解的是服務記憶體管理，不是把模型變小

PagedAttention的核心問題是自回歸生成時，Key／Value Cache會隨序列長度動態增長；若要求每條序列連續配置記憶體，容易出現預留過多與碎片。vLLM官方說明把KV Cache拆成可管理的區塊，讓邏輯區塊不必對應連續的實體記憶體。這改善的是推論服務的配置與批次效率，不等於模型參數變少，也不保證所有硬體與工作負載都得到同樣的速度。

• Block Table：記錄邏輯區塊到實體記憶體區塊的映射。
• KV Cache：保存生成所需的注意力鍵值，大小受序列與批次影響。
• 服務：要和continuous batching、排程、量化與硬體一起評估。
• 基準：吞吐量與延遲取決於模型、輸入長度、併發與硬體，不能直接套用單一宣傳數字。

可參考vLLM官方PagedAttention說明與官方kernel文件，再用自己的工作負載重新測量。