https://yennj12.js.org/yennj12_blog_V4/tags/pagedattention/Recent content in PagedAttention on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 11 Sep 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part1-architecture-overview-zh/Fri, 11 Sep 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part1-architecture-overview-zh/大多數人部署 LLM 的方式，是 pipeline("text-generation") 加一台 A100，跑得動就上線，跑不動就換 H100。 真正的答案是：LLM 推論的瓶頸幾乎從來不是算力，而是記憶體頻寬與記憶體管理；一張卡能同時服務 3 個人還是 300 個人，差別不在 GPU 型號，在你有沒有一個引擎。 generate() 只需要一行。引擎需要一整套子系統。 這個系列拆解的是後者。 前言：這個系列要做什麼 vLLM （UC Berkeley Sky Computing Lab 起家，Apache-2.0，2023-02 開源，現由社群與 PyTorch Foundation 生態共同維護）是目前部署量最大的開源 LLM 推論引擎：GitHub 上約 9.1 萬顆星、2.2 萬 fork，官方定位是「a high-throughput and memory-efficient inference and serving engine for LLMs」。 它值得逐層讀完，理由不是星星數，而是：它把「LLM 推論」這件事從一個模型函式呼叫，重新定義成一個作業系統問題。 分頁、換頁、排程、搶佔、快取、共享——這些名詞你在 vLLM 裡看到的全部是本義，不是比喻。讀它等於讀一份「把 OS 概念套用到 GPU 記憶體」的完整實作。 這個系列分成五篇： Part 主題 對應原始碼 Part 1（本篇） 全景架構、請求生命週期、記憶體帳本、V0→V1 vllm/v1/engine/、vllm/config.py Part 2 PagedAttention 與 KV Cache 管理、Prefix Caching vllm/v1/core/kv_cache_manager.https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part2-paged-attention-kv-cache-zh/Fri, 11 Sep 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part2-paged-attention-kv-cache-zh/大多數人理解 KV cache 的方式，是「把算過的 K 和 V 存起來，下次不用重算」，然後就不再想這件事。 真正的答案是：KV cache 不是一個快取，它是一個動態成長、生命週期不可預測、大小可達模型權重數倍的堆積區——它是 GPU 上的 malloc 問題，而不是 memoization 問題。 把它當快取寫，你會浪費 70% 的記憶體。 把它當作業系統的虛擬記憶體寫，你會拿回那 70%。 前言 Part 1 建立了地圖，也留下一個結論：記憶體就是吞吐量。這一篇把那句話展開成機制。 主角是 vLLM 論文的同名貢獻——PagedAttention。它的核心洞見用一句話講完：KV cache 的記憶體管理問題，和作業系統管理虛擬記憶體的問題，是同一個問題。 因此 OS 五十年來的答案——分頁、頁表、寫入時複製、換頁、LRU——可以整套搬過來。 本篇的目標：讀完之後，你知道一個 block 裡實際躺著什麼、block table 長什麼樣、前綴命中怎麼判定不會出錯、以及在你的硬體上該把 --block-size 和 --kv-cache-dtype 設成什麼。 一、核心問題：連續配置的三種浪費 先看清楚被 PagedAttention 取代的東西。傳統推論框架為每個序列配一段連續的 KV 空間，長度是 max_model_len： GPU KV 記憶體（連續配置） 序列 A：max_len=2048，實際只生成 120 個 token ┌──────────────────────────────────────────────────────────┐ │████████│░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░│ │ 已用 │ 預留但永遠用不到 │ │ 120 │ 1928 │ └──────────────────────────────────────────────────────────┘ ↑ 內部碎片（internal fragmentation）：94% 浪費 序列 B 結束後釋放，留下一個 2048 的洞： ┌────────┬──────────────┬────────┬──────────────┬──────────┐ │ 序列 C │ ░░ 空洞 ░░ │ 序列 D │ ░░ 空洞 ░░ │ 未配置 │ └────────┴──────────────┴────────┴──────────────┴──────────┘ ↑ 外部碎片：總量夠但沒有夠大的連續段 序列 E 要做 n=4 的平行取樣，共用同一個 prompt： ┌──────────────┬──────────────┬──────────────┬──────────────┐ │ prompt KV ×1 │ prompt KV ×2 │ prompt KV ×3 │ prompt KV ×4 │ └──────────────┴──────────────┴──────────────┴──────────────┘ ↑ 完全相同的內容存了 4 份：無法共享 vLLM 論文對既有系統的量測結論是：60%–80% 的 KV 記憶體因碎片化與過度預留而浪費。也就是說，一張 80 GB 的卡上，實際承載有效 KV 的可能只有 15 GB。