Prompt Cache

3 秒看懂

Prompt Caching 是一種在大型語言模型（LLM）推論中，跨請求複用注意力計算結果（KV Cache）的機制。當多個請求共享相同或高度重疊的提示字首時，系統只計算一次字首的鍵值快取，後續請求直接複用，跳過重複的“預填充”計算，從而顯著降低首 token 延遲與 GPU 算力消耗。

3 分鐘產業解釋

LLM 每次生成回答前，都必須對整段輸入文本執行完整的注意力計算，生成 KV Cache（Key‑Value 快取）。在 API 呼叫、多輪對話、固定指令模板等場景中，大量請求包含相同的系統提示、上下文文件或工具描述，例如“你是一位金融分析師，請根據以下財報回答：……”後面接上不同的使用者問題。如果每次都要為這些共同部分重新計算 KV Cache，相當於用昂貴的 GPU 重複做無用功。

Prompt Caching 將這些中間結果按字首內容索引，並快取到視訊記憶體或主機記憶體中。後續請求一旦匹配到已快取的字首，就能直接從快取池中載入 KV 張量，預填充階段只需處理剩餘的新增 token。帶來的直接效果是：

• 首 token 延遲（Time‑To‑First‑Token）下降 50%–90%（具體取決於字首與新增 token 的比例，各廠商揭露範圍不一）；
• 同等硬體下可承載的併發請求數明顯上升，推論叢集總吞吐提升；
• 雲端 API 對快取命中的重複 token 往往提供計費折扣（如 Anthropic 對快取命中的輸入 token 僅收取原價 10%，OpenAI 對符合條件的請求給予自動折扣），降低使用成本。

該技術於 2023–2024 年在學術與工程上快速成熟，已被 vLLM、SGLang、TensorRT‑LLM 等主流推論引擎內建為自動字首快取，並被 Anthropic、OpenAI、Google Cloud 等雲端廠商轉化為可計費的 API 能力，是當前 LLM 推論降本的核心手段之一。

技術原理

Transformer 推論的兩階段與 KV Cache

LLM 推論分為 預填充（prefill） 和 逐 token 生成（decoding）。預填充階段一次性將整個輸入序列送入模型，平行計算每一層中每個位置的 Key 和 Value 投影，產生第一步的 logits，並儲存所有位置的 K 和 V 矩陣到快取。該階段計算密集，輸入越長延遲越高。隨後的解碼階段每一步只處理新增的一個 token，計算其注意力時需要讀取之前全部的 KV Cache，並追加新 token 的 K、V。解碼階段的每一步計算量很小，但需反覆訪問完整的 KV Cache，對記憶體頻寬與容量敏感。

自注意力機制中，給定查詢 Q、鍵 K、值 V，輸出為：

text(Attention)(Q,K,V) = text(softmax)\left(frac(QK^T){sqrt(d_k)}\right)V

在因果（自迴歸）模型中，每一個 token 只能注意到之前的位置。推論時，已處理 token 的 K、V 儲存在 K_cache 和 V_cache 中，後續 token 只需計算與這些快取的注意力，無需重新投影歷史 token。

跨請求字首複用

Prompt Caching 的核心在於不同請求之間共享 KV Cache。假設請求 A 和請求 B 擁有完全相同的提示字首 [SysPrompt]，其後跟隨不同的使用者問題 [UserQ_A]、[UserQ_B]。首次處理 [SysPrompt] 後，其所有層的 K、V 被存入全域性快取池，並以字首內容的雜湊或區塊序號作為索引。請求 B 到達時，系統計算其字首雜湊，發現命中後直接“掛載”已快取的 KV 塊，後續預填充僅需處理 [UserQ_B] 部分，而該部分的注意力計算可以完整看到 [SysPrompt] 的快取內容，完全等價於從零計算的語義。整個流程如下圖所示：

請求A: [SysPrompt] + [UserQ_A] → 生成答案A
請求B: [SysPrompt] + [UserQ_B] → 生成答案B

快取複用流程：
1. 首次處理 [SysPrompt] 時，其 KV Cache 存入快取池，索引為 hash([SysPrompt])
2. 請求B到達，計算 hash([SysPrompt])，命中 → 僅預填充 [UserQ_B]，其注意力可訪問全部 SysPrompt KV
3. 解碼階段兩個請求各自追加自身的新增 KV，互不干擾

在更先進的實現中，快取可以基於 token 塊（如每 16 個 token 一個塊）進行管理，不僅匹配嚴格字首，還能識別請求中任意位置的公共子序列，進一步擴大命中範圍。這類方法常藉助基樹（Radix Tree）或雜湊表來快速定位已快取塊。

工程挑戰：視訊記憶體、一致性與索引效率

實現跨請求快取複用時面臨三大挑戰：

• 記憶體膨脹：每快取一個字首，就需要在 GPU 視訊記憶體（HBM）或主機記憶體中儲存完整的 K、V 張量。長序列模型（如 100k token 上下文）中，一個字首可能佔用數 GB 視訊記憶體。設計合理的換入換出（swap）策略、淘汰演算法（如 LRU），以及與 PagedAttention 等塊狀記憶體管理機制配合，才能平衡命中率與記憶體壓力。
• 一致性約束：任何模型權重更新、量化模式改變或採樣超引數（如 temperature）影響計算路徑時，此前儲存的 KV Cache 都將失效，需要全部沖刷重建。雲端服務在模型升級時必須通知客戶快取失效，或提供透明的切換過渡。
• 索引與命中判斷：系統需在微秒級判斷新請求的字首是否已被快取。常用手段包括維護字首的雜湊表，或允許使用者在 API 中顯式標記“可快取邊界”（如 Anthropic 的 cache_control 引數）。自動字首快取則通過交易記憶體開銷換取無縫命中，無需使用者感知。

Prompt Caching 將計算去重與記憶體複用繫結在一起，通過系統級最佳化提升整個推論管線的可用性與經濟性。

關鍵引數

Prompt Caching 的效果與代價由以下引數刻畫，但目前行業內尚缺乏統一公開基準，各廠商與研究機構公佈的數字因場景而異，此處僅作定性說明，部分給出已知的參考範圍（均註明來源或說明“公開資料未見”）：

• 快取命中率（Hit Rate）：啟用快取後，命中請求佔總請求的比例。直接決定節省的計算量。該指標高度依賴請求字首的重合度與快取容量。在聊天應用、RAG 問答等強模板場景中，內部測試命中率可超過 80%；而在使用者隨意提問的低重合場景下，命中率可能低於 10%（據 Anthropic 工程部落格 2024 年定性描述，未公佈精確基準）。
• 首 token 延遲改善比（TTFT Reduction Ratio）：命中時首 token 延遲與無快取首 token 延遲的比值。典型資料：當快取字首佔輸入總 token 的 90% 時，預填充計算量降至原來的 10%，TTFT 可下降約 80%–90%（理論估算，受通訊和排程開銷影響）。
• 等效吞吐提升（Throughput Uplift）：在相同硬體和尾延遲 SLO 下，啟用快取後可額外支援的併發請求數或每秒生成 token 數。公開資料未見統一測試套，部分推論架構在部落格中提及吞吐提升 30%–100%（如 SGLang 針對特定工作負載的案例，2024 年）。
• 記憶體開銷（快取壓力）：快取佔用 GPU 視訊記憶體或主機記憶體的總量，通常以每百萬 token 字首所需 GB 數表示。對於 70B 引數模型（FP16），每個 token 的 KV Cache 大小約為 2 * 層數 * 頭數 * 頭維度 * 2位元組，典型值約 2–4 MB/1k token。快取 100 萬 token 的字首約需 2–4 GB 視訊記憶體。該開銷會擠佔可用於批處理（batching）的視訊記憶體空間，若命中率不足，反而降低整體吞吐。
• 快取失效比例：因模型權重更新、重啟或顯式重新整理導致的快取不可用頻次。在多模型部署的叢集中，頻繁切換模型可能導致失效比例上升。雲端服務商通常建議將快取用於穩定的模型版本。
• 計費折扣力度：影響使用者採納的經濟引數。截至 2025 年初，Anthropic Claude API 對快取命中的輸入 token 提供 90% 成本減免（即收費為原價的 10%，來源：Anthropic 官方文件 2024 年 5 月）；OpenAI 對 GPT‑4o 和 GPT‑4o‑mini 在部分條件下提供 50% 的輸入 token 折扣（自動快取，來源：OpenAI 平台文件 2024 年 8 月更新）；Google Cloud Vertex AI 上下文快取功能對命中 token 提供折扣，具體比例未公開。其他廠商未充分揭露統一折扣比率。

追蹤這些引數可幫助使用者評估 Prompt Caching 在其工作負載中的實際淨收益，但尚無行業通用揭露標準，公開可比資料有限。

技術路線

當前產業落地的主流技術路線可歸類為四層，從無快取到高度自動化的廣義共享，形成遞進關係：

方案	快取匹配方式	典型粒度	記憶體佔用	實現複雜度	主要效果
1. 完全無快取	無	–	僅本請求 KV	最低	每次請求完整預填充，延遲與成本最高
2. 顯式字首快取（會話級）	使用者通過 API 標記可快取邊界	整段系統提示或對話歷史	按會話隔離，重複字首可能產生多份複製	低	減少同會話內重複預填充；需應用改造
3. 自動字首快取（推論引擎內建）	字首雜湊自動匹配，基於 token 塊（如 16 個 token）	Token 塊級	共享記憶體池，跨請求共享，減少冗餘	中	大幅提高全域性命中率，無需使用者感知，已成為開源引擎標配
4. 廣義共享 / 近似匹配	編輯距離、區域性敏感雜湊（LSH）、基樹索引等	任意公共子序列塊	更大，索引後設資料開銷增加	高	進一步提升非字首公共子序列的命中率，但可能引入近似精度偏差和一致性風險

目前應用最廣泛的是路線 3 自動字首快取。vLLM 的 PagedAttention 實現了塊級記憶體管理，並原生支援 enable_prefix_caching 引數（vLLM 0.4.0 以上版本提供，0.5.0 後穩定）。SGLang 的 RadixAttention 利用基樹（Radix Tree）管理跨請求 KV Cache 塊，可以精確匹配任意長度的公共字首，並在部分場景中展示出比常規字首雜湊更高的命中率。NVIDIA TensorRT‑LLM 同樣提供了“KV Cache Reuse”功能，支援以 session 為粒度的快取複用。

路線 4 下的各實驗性方案（如 LSH‑based 近似匹配）多處於學術探索階段，尚未在商業雲端中大規模部署。未來如果使用者場景極度碎片化，近似匹配技術可能會與現行自動字首快取融合，但仍需解決精度可控性和額外計算開銷的問題。

上游

Prompt Caching 的上游由模型資產、記憶體管理中介軟體、推論執行時和硬體層構成：

• 模型權重：快取有效的前提是模型權重不變。因此上游包括 LLM 權重提供商（Meta、Mistral、AI21 Labs、阿里雲端等開源模型釋出方，以及閉源模型商如 OpenAI、Anthropic），它們的版本穩定性直接影響快取可用期。一旦模型微調或升級，下游快取全部失效。
• KV Cache 記憶體管理中介軟體：以 PagedAttention、RadixAttention 為代表的記憶體管理技術，支撐物理塊級別的分配、回收和跨請求複用。這些中介軟體通常內嵌於推論引擎，如 vLLM 的塊表管理、SGLang 的 Radix Tree 快取池。
• 推論執行時：將上述中介軟體與 CUDA kernel、注意力運算元最佳化結合的完整棧，包括 vLLM、SGLang、TensorRT‑LLM、Hugging Face TGI 等。它們對快取的排程、換入換出（offload）與請求排程策略（如 continuous batching）緊密耦合。
• 硬體與互聯：GPU 的 HBM 容量與頻寬（如 NVIDIA H100 80GB HBM3、H200 141GB HBM3e）直接決定可快取字首的總規模；高頻寬主機 DRAM（DDR5）和 NVMe SSD 可作為溢位儲存層。CXL 記憶體池化等新技術若成熟，有望在節點間擴充套件低延遲快取層，但截至 2025 年初尚未大規模部署於推論叢集。

下游

下游是直接使用 Prompt Caching 的推論服務消費者和最終應用：

• LLM API 平台：Anthropic、OpenAI、Google Cloud Vertex AI、AWS Bedrock、Azure OpenAI Service 等向開發者提供已整合快取的推論 API，開發者無需關心底層實現，只需通過引數（如 cache_control）宣告可快取範圍。
• 私域部署企業：在自己資料中心或私有雲端中部署 vLLM、SGLang 或 TensorRT‑LLM 的企業，通過開啟自動字首快取來降低內部應用的推論成本，服務於智慧客服、知識庫問答、文件分析、程式碼生成等場景。大型企業（金融、醫療、法律）需要呼叫 LLM 處理大量結構同理但資料不同的請求，是快取的高價值場景。
• 多智慧代理/工具呼叫應用：在 Agent 架構（如 LangChain、AutoGen）中，每次呼叫 LLM 都可能重複載入工具描述、歷史對話摘要等，Prompt Caching 可有效壓低這類架構的邊際推論成本。
• 邊緣推論：部分混合推論架構將部分可複用字首快取儲存在邊緣裝置，雲端端僅傳遞增量請求，減少延遲和頻寬消耗，但目前仍處早期驗證階段，公開案例有限。

受益公司

Prompt Caching 的推廣使以下環節的公司直接或間接獲益（此處僅描述業務邏輯，不構成任何投資建議）：

• 推論架構商業支援公司：提供高效能推論引擎企業版與託管服務的公司，如 Anyscale（基於 Ray 和 vLLM 的推論服務），以及 SGLang 背後的初創團隊等。它們將 Prompt Caching 作為降本增效的關鍵賣點，通過提供最佳化實施和運維支援獲得營收。
• 雲端推論服務提供商：擁有大視訊記憶體 GPU 叢集的公有雲端廠商（微軟 Azure、AWS、Google Cloud）以及獨立 AI 推論雲端（Together AI、Fireworks AI、Groq*），通過提供緩存摺扣吸引客戶，提升其平台競爭力，並憑藉快取帶來的更高硬體利用率改善自身單位經濟模型。 注：Groq 使用 LPU 架構，KV Cache 管理方式不同，但也提供類似的快取複用能力。
• GPU 與儲存硬體廠商：NVIDIA（提供高 HBM 容量 GPU）、AMD（MI300X 等大視訊記憶體加速卡）和儲存/記憶體廠商（SK 海力士、三星、美光等 HBM 供應商）從推論擴容需求中受益，因為更大快取池要求更高視訊記憶體容量。
• 重度 LLM 呼叫方：SaaS 企業（如客服自動化、程式碼助手、法律文件審閱系統）如果自行部署推論引擎或使用雲端服務，Unit Economics 將因 Prompt Caching 改善，有利於降低服務成本、擴充套件獲利率。這部分企業是需求的最終受益者。

市場規模

截至 2025 年初，尚無第三方研究機構釋出 Prompt Caching 的獨立市場規模資料。其經濟價值蘊含在 LLM 推論市場的膨脹之中，難以單獨剝離。以下通過相關推論市場資料給予間接參考（數字均標註來源與估算口徑）：

• 據 SemiAnalysis 2024 年 7 月的估算，全球 LLM 推論的總擁有成本（TCO，含晶片、電力、基礎設施）在 2024 年約為 200–250 億美元，並預計 2028 年將突破 1000 億美元（口徑為服務提供商和自建推論支出的總和）。Prompt Caching 作為降低單位 token 成本的關鍵技術，可節省的算力比例在工作負載高度重合時可達 30%–70%，但其整體滲透率受制於字首重合度。
• 從雲端服務商的計費結構調整可窺見一斑：Anthropic 在實行緩存摺扣後，部分客戶的平均推論成本下降超過 50%（來源：Anthropic 官方部落格 2024 年 5 月案例）。這表明快取機制正在實質性影響雲端推論的營收模式，但至今沒有公開的細分市場報告。
• 根據多家雲端廠商產品公告，2024 年下半年起 Prompt Caching 幾乎成為 LLM API 的標準配置，反映供給端已將其視為基礎競爭力。可預見隨著多模態長上下文模型（數百萬 token）的普及，重複計算開銷急劇增加，Prompt Caching 的採納率與隱含經濟價值將繼續擴大，但公開可引用的具體金額或份額仍缺失。

玩家對比

下表對比了主流推論引擎與雲端推論服務在 Prompt Caching 方面的實現差異（資訊截至 2025 年 3 月）：

玩家	型別	快取方式	匹配粒度	是否需要使用者宣告	計費折扣 / 成本優勢	備註
vLLM	開源推論引擎	自動字首快取（基於 token 塊）	Token 塊（預設 16 token）	否	無計費，僅節省自建硬體算力	0.4.0 引入自動字首快取，0.5.0 穩定，需配合 PagedAttention
SGLang	開源推論引擎	RadixAttention（基樹管理）	任意長度字首，可合併公共塊	否	同上	相同字首識別效率更高，適合高併發、多共享字首場景
TensorRT‑LLM	NVIDIA 推論架構	KV Cache 複用（會話級）	整段 KV 塊	否（會話 ID 關聯）	同上	需在 Triton Inference Server 環境中使用，整合度高
Anthropic (Claude)	閉源雲端 API	顯式快取（cache_control）	使用者指定的提示字首	是	命中輸入 token 收取原價 10%（來源：Anthropic 2024.5）	快取有效期 5 分鐘不活躍則過期，支援多條快取斷點
OpenAI	閉源雲端 API	自動快取（系統自動識別公共字首）	未公開細節	否（自動）	GPT‑4o 系列命中輸入 token 折扣 50%（來源：OpenAI 文件 2024.8）	僅對符合條件的請求自動啟用，無需使用者修改程式碼
Google Cloud Vertex AI	閉源雲端 API	上下文快取（Context Cache）	使用者指定的上下文內容	是	折扣比例未公開，計費文件提及“降低計算成本”	適合超長上下文（如 Gemini 1.5 Pro 的 1M token 上下文）
AWS Bedrock	閉源雲端 API	底層模型引擎支援（視模型而定）	取決於模型	因模型而異	未公開統一折扣，計費體現複用優勢	一部分模型通過底層 vLLM/TensorRT 實現自動快取

說明：開源引擎的“成本優勢”指通過降低預填充計算量來節約 GPU 時租金和功耗，不涉及 API 計費。雲端服務商的折扣資訊基於各廠商截至 2025 年 3 月的官方文件。部分雲端廠商（如 Azure OpenAI Service）雖未單獨公佈緩存摺扣，但其底層 API 可能繼承 OpenAI 快取策略。

風險

• 命中率不及預期：若應用場景中請求字首高度隨機化（如使用者自由提問無重複模板），快取命中率可能極低，額外佔用的快取記憶體會擠佔批次處理空間，反而降低整體吞吐。部署前需基於真實流量評估命中率。
• 記憶體壓力與成本：快取在 GPU 視訊記憶體中駐留大量 KV 塊，可能導致能同時處理的請求批大小下降。大容量主機記憶體解除安裝雖可緩解，但帶來 PCIe 傳輸延遲，削弱部分增益。
• 模型更新導致快取失效：頻繁微調、Base Model 升級或權重切換時，所有已快取 KV 塊必須丟棄。多模型部署的叢集可能面臨“快取抖動”，降低其淨效益。
• 精度與一致性風險：採用近似匹配演算法時，若複用不完全一致的 KV 快取，注意力計算偏差可能影響下游生成質量。當前主流雲端服務均採用嚴格精確匹配，但未來若引入近似方案需謹慎驗證。
• 安全與資料隔離：在多租戶推論叢集中，必須確保不同客戶間的 KV Cache 完全隔離，避免側通道洩露。雲端廠商宣告會進行租戶間嚴格隔離，但部署自建叢集時需確保權限與名稱空間設計。
• 計費透明度：自動快取的計費折扣規則可能較複雜（如僅當重複超過一定次數後觸發），開發者可能難以準確預估成本，需關注雲端廠商文件細節。

誤讀糾偏

• 誤讀 1：Prompt Caching 等同於普通 KV Cache KV Cache 是所有自迴歸 LLM 推論過程中自然產生的中間結果，每個生成請求都會建立；而 Prompt Caching 特指跨不同請求之間共享和複用這些快取的系統性機制。僅在單請求內儲存和讀取 KV 不是 Prompt Caching。

• 誤讀 2：啟用快取總能省錢 快取本身佔用額外視訊記憶體。若命中率過低，這部分視訊記憶體可能原本可用於更大的批處理，反而降低硬體利用率和吞吐，導致單位 token 成本上升。收益取決於請求字首重疊度。

• 誤讀 3：只有完全相同的提示才能複用 只要請求字首相同（哪怕只是系統提示的前半部分或共享文件的開頭），即可複用字首的 KV。自動字首快取甚至可以識別任意位置的公共子序列（如多文件 QA 中不同請求攜帶部分相同的長上下文），進一步提升命中率。

• 誤讀 4：快取對解碼階段沒有幫助 雖然快取主要加速預填充，但快速完成預填充可以讓解碼階段更早開始，並且減少預填充佔據的計算資源，允許 GPU 同時處理更多請求的解碼步驟，間接提高解碼階段的通量。

最新事件

• 2024 年 5 月：Anthropic 宣佈為 Claude API 推出 Prompt Caching 功能，使用者可通過 cache_control 標記可快取字首；快取命中的輸入 token 價格降至原價的 10%，快取有效期 5 分鐘。此舉大幅降低了多輪對話和長文件重複查詢的成本（來源：Anthropic 官方部落格）。
• 2024 年 8 月：OpenAI 在 Chat Completions API 中為 GPT‑4o 和 GPT‑4o‑mini 啟用自動 Prompt Caching，系統自動識別請求中的公共字首並對命中 token 提供 50% 折扣，無需使用者修改任何程式碼（來源：OpenAI 平台文件更新）。
• 2024 年 10 月：Google Cloud Vertex AI 正式推出“上下文快取（Context Caching）”能力，適用於 Gemini 模型，允許使用者提交可快取的上下文內容，減少對超長上下文的重複計算成本（來源：Google Cloud 部落格）。
• 2024 年 Q4：vLLM 0.6.0 版本釋出，自動字首快取（automatic prefix caching）經進一步最佳化後轉為預設開啟，並在多節點部署中支援基於 NCCL 的 KV 傳輸，提升了分散式快取命中率。SGLang 同期釋出了 RadixAttention 的自動快取淘汰策略，降低視訊記憶體碎片。
• 2025 年 1 月：DeepSeek、阿里通義千問等國產 LLM API 服務商相繼上線或最佳化 Prompt Caching 功能，為長上下文應用提供折扣計費與更低延遲（來源：各廠商官方公告）。海外 Together AI 推出“Caching API” beta 版，允許使用者主動管理快取會話。公開資料可見 Prompt Caching 已成為主流 LLM 服務的標準能力。

追蹤指標

使用者或市場參與者可關注以下維度的公開與非公開指標，以追蹤 Prompt Caching 的進展與受益情況：

• 雲端服務商計費報告中的快取命中比例：部分雲端平台（如 Anthropic Console）提供每請求級別的快取命中資訊與成本節省明細，可用於評估工作負載的快取收益。若無報表，可通過對比輸入 token 計費量與傳送 token 量估算折扣。
• 推論引擎效能監控：自建部署中，vLLM、SGLang 等的叢集面板輸出 prefix_cache_hit_rate、gpu_cache_usage_percent 等指標。理想情況下，命中率應穩定在 60% 以上（來源：vLLM 維護者建議，非硬性標準），同時需觀察視訊記憶體用量和請求佇列深度是否因快取發生負向變化。
• 開源基準與部落格：關注 vLLM、SGLang 釋出的效能報告，以及雲端廠商工程部落格中的案例研究，留意其公佈的吞吐提升倍數和 TTFT 改善資料，這些通常來自典型負載測試，可作為部署前參考。
• 硬體負載率：如果看到 GPU 叢集的預填充計算單元（如 FP16 TFLOPs 利用率）明顯下降，而同等請求量下解碼批次增大，可能側面印證快取有效性。
• 新模型適配進度：每當有重要新模型釋出（如 Llama 4、GPT‑5 等），追蹤主流引擎對其 Prompt Caching 的支援狀態，將影響快取功能的持續可用性。
• 計費折扣政策變動：雲端服務商偶爾調整緩存摺扣或有效期，直接影響 API 使用者的成本模型，需定期查閱官方文件。

信源

以下為撰寫本概念頁時參考的公開來源（均可在相應的學術資料庫、官方文件庫或程式碼倉庫中檢索獲取，此處不提供 URL）：

1. “Prompt Cache: Modular Attention Reuse for Low‑Latency Inference” (A. Asai et al., 2023) —— 提出模組化提示快取架構的學術論文。
2. “Efficient Memory Management for Large Language Model Serving with PagedAttention” (Kwon et al., SOSP 2023) —— 提出 PagedAttention 的 vLLM 原始論文，跨請求塊級 KV 快取複用的基礎。
3. “SGLang: Efficient Execution of Structured Language Model Programs” (Zheng et al., arXiv 2024) —— 介紹 RadixAttention 與系統級快取複用。
4. Anthropic 開發者文件 “Prompt Caching” 章節（2024 年 5 月釋出，持續更新）—— 快取功能 API 規範與計費政策。
5. OpenAI 平台文件 “Prompt caching”（2024 年 8 月更新）—— GPT‑4o 自動緩存摺扣說明。
6. Google Cloud Vertex AI 文件 “Context caching” （2024 年 10 月）—— Gemini 上下文快取功能描述。
7. vLLM 官方文件與 GitHub 倉庫中的 automatic_prefix_caching 相關部分 —— 引擎實現細節與引數指南。
8. NVIDIA TensorRT‑LLM 文件 “KV Cache Reuse” 部分 —— 會話級快取複用說明。
9. SemiAnalysis 研究報告 “AI Datacenter TCO Model” （2024 年 7 月） —— LLM 推論 TCO 估算資料。
10. 各雲端廠商 2024–2025 年官方部落格與產品公告（Anthropic、OpenAI、Google Cloud、AWS、Together AI、DeepSeek、阿里雲端等），用於確認最新事件與計費變更。