11-868 用兩講回答同一個問題：一台推論伺服器怎麼同時服務大量請求，又不浪費 GPU 上的 KV cache。第 22 講（Lei Li）從 SGLang 的排程迴圈講起：ORCA 的 continuous batching、用 radix tree 管 KV 的 RadixAttention、依前綴命中率排序與分流、把 CPU 排程藏到 GPU 計算後面。第 24 講由 vLLM 作者 Woosuk Kwon 主講：PagedAttention 把 KV cache 切成固定大小的 block，用 block table 做虛擬化，讓同一張 A100 的 batch 從 8 撐到 40；後半講 vLLM 怎麼壓 CPU overhead、用 piecewise CUDA graph、切模型平行與管理混合架構的記憶體。
11-868 最後一組講義有五份：DistServe 的 Hao Zhang、NVIDIA Dynamo 的 Vikram Mailthody、LMCache 的 Junchen Jiang、Mooncake／KTransformers 的 Mingxing Zhang，加上 Lei Li 的框架地圖。它們回答同一個問題：服務規模從一台機器擴到一座資料中心之後，算力和 KV cache 要放在哪裡。主線有三步：量尺從 throughput 換成符合 SLO 的 goodput；prefill 與 decode 拆到不同 GPU；KV cache 從 GPU 記憶體擴張到 CPU、SSD 與遠端儲存。
第 15 講分四段。延長上下文：RoPE 內插可以把 LLaMA 從 2k 拉到 32k，LongLoRA 用 shifted sparse attention 讓長上下文微調變便宜。評估：lost-in-the-middle、Needle-in-a-Haystack 與 LongBench。高效 attention：KV cache 隨長度線性長大，StreamingLLM 發現開頭幾個 token 是 attention sink，保留它們加上最近視窗就能穩定生成；DuoAttention 只讓少數 retrieval head 保留完整 KV cache；Quest 保留全部 KV、依 query 只讀最關鍵的幾頁。最後一段跳出 Transformer：Mamba 用選擇性 SSM 取代 attention，Jamba 把兩者混在一起。
6.5940 在第 12 講從 CNN 轉到 Transformer，但重點不在原理，而在哪裡會吃掉記憶體與算力：attention 是 O(N²)；Llama-2-70B 若用 MHA，batch 16、長度 4096 的 KV cache 要 160GB；GQA 把它縮 8 倍、MQA 縮 64 倍；MoE 讓總參數變多但每個 token 的計算不變。這篇是進入 L13 LLM 部署前的橋接。
HW3 是 20 題選擇題（每題 0.5 分），不交程式，只在 NTU COOL 上作答。前 10 題讀論文：四篇 speculative decoding（Leviathan、DeepMind 的 Speculative Sampling、Inference with Reference、SpecInfer）加上 FlashAttention 1–3；後 10 題照 Colab 填 TODO 後分析結果：手寫 speculative decoding 的接受率、兩種 prompt regime 下 assistant 模型與 n-gram 的加速曲線、用 T4 規格估 FlashAttention 的 HBM 讀取量與理論加速、vLLM 的 prefix caching 多輪測試與失效實驗，以及 CPU offload 對 throughput 的影響。題目中英雙語全部印在作業 PDF 裡，校外可以完整自學，只是拿不到官方解答。
KV Cache 把已經算過的 key 和 value 存起來，decode 時就不必重算，但它每個 token 都要佔一份記憶體：以 Gemma 2 27B 為例，一個 token 約 0.72MB，A100 80GB 只夠放約 11.4 萬個 token。李宏毅接著整理了一串瘦身法：讓多個 query 共用 key/value（MQA、GQA）、把 key/value 壓成一個向量又不必解壓（MLA）、只看一段範圍（Sliding Window、StreamingLLM）、把沒人理的 key/value 丟掉（Scissorhands、H2O），最後講跨對話的 prompt caching：只有前綴完全相同才會命中，所以 system prompt 要把穩定的內容放前面。
2026 版 CME295 第 5 講「LLM systems」（10 月 30 日）課表列了 7 個主題：分散式訓練、推論最佳化、KV caching、speculative decoding、高效 kernel、FlashAttention、硬體取捨。本篇在開課前，用 2025 版第 3、4 講約 70 頁投影片加原始論文，把它們串成同一本帳：H100 每搬 1 byte 大約要做 295 次運算才吃得滿算力，而逐字生成時每讀 1 byte 權重只做約 1 次，所以多數加速手法都在想辦法少搬資料。
Agent 每一步都把整段歷史重新送進模型，五次呼叫就累積 80K token 的輸入；OpenHands 的 1,500 個 session 平均 7.8 萬 token，其中 37% 是工具結果。Neubig 分兩層處理：模型層靠「多層局部 + 一層全域」的混合注意力與長度課程撐起百萬 context；harness 層靠穩定前綴吃到便宜約十倍的 cache，再用保留錨點、外存證據的 compaction 撐過上限，而且 compaction 要用接續任務來評。
HW6 Problem 4（20 分）用三個問題拆解「一個 token 接一個 token 生成」的代價：逐步挑最大機率不等於整句最可能、每步重算所有 key 讓成本變成平方級而 KV cache 把它壓回線性、speculative decoding 用小模型先猜再讓大模型一次驗證。全部是紙筆題，但每一題都對應到今天 LLM 推論系統的真實設計。
omp 用 StablePrefix 凍結 system prompt + tool specs，用 AppendOnlyLog 讓 messages 只增不改，配合 digest-based 的 longestStablePrefix 算法，在 prune/shake/steering 重寫歷史時，只重送 divergence point 之後的尾巴。這讓 Anthropic/DeepSeek 的 prompt cache 命中率最大化，解決了舊版每輪強制 ~40k token re-prefill 的問題（issue #3406）。
70B 模型原本需要 140GB VRAM，但量化到 4-bit 只需要 ~35GB，再用 llama.cpp 的部分卸載就能在消費級硬體上跑。GGUF 格式的命名規則（Q4_K_M、Q5_K_S）告訴你精度和大小的取捨。KV cache 是長對話變慢的主因。
第十講把 prefill 與 decode 分開：前者能平行、常受算力限制，後者逐 token 且常受記憶體頻寬限制；GQA/MLA、量化、speculative decoding、continuous batching 與 PagedAttention 都在改寫這條成本。
Chroma 測了 18 個前沿模型，全部隨輸入變長而跳崖式退化。記憶失效多半是檢索失效偽裝的。而 KV cache 的真正成本是頻寬不是儲存——decoding 每產生一個 token 都要讀過整個 cache。
TurboQuant+ 是 Google Research ICLR 2026 論文的開源實作，用 PolarQuant + QJL 兩階段量化壓縮 KV cache 達 3.8-6.4x，讓消費級硬體跑更大模型和更長上下文。