AI 的快取：為什麼重複問題回得快
這四層省下來的東西不一樣，命中的條件也不一樣。接下來我們就一層一層拆開來看。
二、快取不是一個東西，而是好幾層
很多討論 AI 快取的文章會把「快取」講成單一技術，但實際上它是一整套分層架構。用一個比較生活化的比喻：你打電話去問一家餐廳的營業時間，接電話的可能不是廚師本人，而是櫃檯、是語音總機、甚至是你手機裡存好的通訊錄。AI 服務也是一樣，越靠外層的快取越便宜、越快，但越不「聰明」；越靠內層的快取越精準，但成本越高。
第一層：瀏覽器與 CDN 的傳輸快取
最外層是大家最熟悉的 HTTP 快取。當你開啟一個 AI 網頁服務，介面的 HTML、CSS、JavaScript、圖示這些靜態資源，都會被瀏覽器按照 Cache-Control、ETag 等標頭快取起來。第二次進站時，這些東西不用重新下載，頁面自然開得快。
但要注意，真正的 AI 對話內容通常不會被這層快取。原因很簡單：對話是即時生成、且與你的帳號綁定的個人化內容，還涉及隱私，服務商會明確設定不快取。所以如果你的「AI 變快」感受是發生在回答內容上，那多半不是這一層的功勞。
CDN 層則主要負責靜態資源與部分公開內容的分發。有些論壇或內容網站會把 AI 生成的公開摘要、常見問答放在 CDN 上，這時候重複訪客看到的就是快取版本，速度和穩定性都會好很多。
第二層：應用層的語意快取（Semantic Cache）
這是近年最受關注的一層，也是「重複問題回得快」最直觀的解釋之一。語意快取的核心概念是：不看字面是否完全一樣，而是看意思是否足夠接近。
實作方式通常是這樣：使用者送出問題後，系統先用一個嵌入模型（Embedding Model）把問題轉成一條高維向量，然後去向量資料庫裡找「歷史上問過的問題中，有沒有向量距離很近的」。如果相似度超過某個閾值（例如 0.95），系統就直接把當初那個問題的答案回傳給你，完全不呼叫大型語言模型。
這種快取的延遲是毫秒級的，因為它只做了一次向量搜尋，沒有跑推論。開源專案如 GPTCache 就是在做這件事，商業服務中也常見類似設計，尤其是客服機器人、FAQ 助手這類問題重複率極高的場景。
第三層：模型推論層的 KV Cache 與前綴快取
這一層是真正藏在「引擎蓋底下」的技術，也是本文的重點。Transformer 模型在處理一段文字時，會為每個詞元計算出 Key 與 Value 兩個向量，這些向量是後續注意力計算的基礎。問題是：當模型逐字生成回答時，它每一輪都要重新看一次前面所有的內容，如果每次都重算，等於把同一段文字算了幾十次。
KV Cache 的作法就是：算過的就存起來。已經處理過的詞元，其 Key 與 Value 張量會被保留在 GPU 記憶體中，下一輪生成時直接取用，不必重算。這也是為什麼長對話越聊越慢、越聊越吃記憶體——KV Cache 會隨著上下文長度線性膨脹。
而「前綴快取」（Prefix Caching）更進一步：如果兩個不同使用者的請求，開頭有完全相同的片段（例如同一段系統提示詞、同一份長文件），伺服器可以共享這段前綴的 KV Cache。這就是為什麼供應商會建議你把「固定的指令」放在提示詞最前面，把「會變動的內容」放在後面。
第四層：供應商層級的 Prompt Caching
最近一年多，主流模型供應商紛紛把前綴快取包裝成對外開放的產品功能，通稱 Prompt Caching 或上下文快取。它的運作邏輯是：開發者可以把提示詞中「穩定不變」的部分標記出來，供應商會把這部分的處理結果存起來，下一次相同前綴進來時直接複用。
以目前公開的機制來看，這類功能通常有幾個共同特徵：
有最小長度門檻，太短的提示詞不划算，供應商不會幫你快取。
通常要求前綴完全一致，差一個字元就可能整段失效。
換句話說，供應商賣的不只是模型，還在賣「記憶體裡的空間」。而這正是為什麼你反覆問同一份文件相關問題時，後面的問題會明顯變快——那份文件的前綴已經被算好、存好了。
三、KV Cache 為什麼是關鍵：把「讀過的話」記在腦裡
如果說語意快取是「抄答案」，那 KV Cache 就是「抄筆記」。它不改變答案的內容，只是讓模型不必把同樣的計算重做一遍。要理解它為什麼這麼重要，得稍微碰一下注意力機制的成本結構。
注意力機制的二次成本
標準的自注意力計算，複雜度大約與序列長度的平方成正比。意思是說，上下文長度變成兩倍，計算量可能變成四倍；長度變成十倍，計算量可能變成一百倍。這就是為什麼超長上下文的推論又慢又貴。
而 KV Cache 的存在，讓「生成階段」不必每一輪都重算前面所有詞元的 Key 與 Value。沒有 KV Cache 的話，生成第一百個字時要重算前九十九個字，生成第一百零一個字時又要重算前一百個字，成本會爆炸性成長。有了 KV Cache，每一輪只要算「最新那個詞元」的注意力就好，複雜度從平方級降回線性級。
所以嚴格來說，KV Cache 不是「進階優化」，而是現代 LLM 推論的基本配備。你今天能用合理的價格跟 AI 聊天，很大一部分要感謝它。
PagedAttention 與 KV 記憶體管理
既然 KV Cache 這麼重要，那它的大小就成了問題。以一個常見規模的模型來說，單一請求的 KV Cache 可能就要吃掉數百 MB 到數 GB 的顯示記憶體，而且會隨著對話變長持續增長。GPU 記憶體是稀缺資源，怎麼管理這些快取，直接決定了伺服器能同時服務多少使用者。
這方面最有名的技術是 vLLM 提出的 PagedAttention，靈感來自作業系統的虛擬記憶體分頁。傳統做法是為每個請求預先配置一大塊連續記憶體，容易造成碎片與浪費；PagedAttention 則把 KV Cache 切成固定大小的「頁」，需要時才配置，不需要時立刻釋放，還能讓多個請求共享相同的頁（例如同一段系統提示詞）。
成果是什麼？在相同的硬體上，吞吐量可以提升數倍。對使用者的體感來說，就是「排隊變短了」、「回應變快了」。這也是為什麼同樣的模型，透過不同的推論框架部署，速度可以有天壤之別。
四、語意快取：不是字一樣，意思一樣也能命中
回到使用者最有感的那一層。語意快取的魅力在於「寬容」：你打字打錯、換句話說、加了幾個語助詞，它都還認得出來。但這種寬容同時也是它最大的風險來源。
向量相似度與閾值
語意快取的判斷依據是向量距離。實務上常見的做法是使用餘弦相似度，把問題轉成向量後，與快取庫中的向量逐一比較，取最相似的一筆。如果相似度高於設定閾值，就視為命中。
問題在於，這個閾值該設多少？設得太低（例如 0.80），會出現大量誤命中，使用者問「台北今天天氣」卻拿到「台中今天天氣」的答案；設得太高（例如 0.99），幾乎只有字面完全一樣才會命中，快取形同虛設。
因此，成熟的系統通常不會只用單一閾值，而是會搭配其他策略，例如：
對問題做意圖分類，不同類別用不同閾值。
保留人工回饋機制，讓使用者可以標記「這答案不對」，系統據此調整。
誤命中與幻覺風險
語意快取最可怕的不是「沒命中」，而是「命中錯」。當系統自信滿滿地回傳一個看似合理、實際上張冠李戴的答案時，使用者往往不會察覺，因為它來得太快、太順暢，反而更容易被信任。
這在技術上與「幻覺」是不同的問題——幻覺是模型自己編的，誤命中是系統把別人的答案塞給你。但對使用者的傷害是一樣的，甚至更隱蔽。因此在任何對正確性有要求的場景（醫療、法律、金融、客服理賠），語意快取都必須非常保守，寧可多算幾次，也不要錯一次。
一個實用的原則是：語意快取只適合「答案與個人化無關、且時效性低」的問題。例如「你們的營業時間是什麼」、「產品保固幾年」、「怎麼重設密碼」這類問題，命中錯誤的代價可控；但「我上個月的訂單到哪了」這種涉及個人資料的問題，就絕對不能走語意快取。
五、快取帶來的好處與代價
天下沒有白吃的午餐，快取也一樣。它是一組明確的取捨，而不是無條件的優化。
好處：延遲、成本、穩定度、吞吐量
先說好處，這也是最直接的誘因：
對開發者來說，還有一個隱形好處：行為可預測。當你知道某段提示詞會被快取，你就能更精確地估算延遲與費用，這在規劃 SLA 時非常有用。
代價：時效性、隱私、可解釋性
但快取也有它的陰暗面：
把好處與代價放在一起看，就會得到一個結論：快取不是「要不要用」的問題，而是「在哪裡用、用多積極」的問題。這需要針對場景逐項設計。
快取層級
命中條件
延遲改善
主要風險
瀏覽器／CDN
網址、標頭一致
極大（免傳輸）
內容過期
語意快取
向量相似度超過閾值
極大（免推論）
誤命中、張冠李戴
KV Cache／前綴快取
提示詞前綴完全一致
中等（省 Prefill）
記憶體佔用、隔離問題
供應商 Prompt Caching
標記區塊一致且未過 TTL
中等至大
寫入費用、TTL 控管
六、實務設計：怎麼讓快取真的幫上忙
知道原理之後，接下來是最實用的部分：如果你正在開發 AI 應用，該怎麼設計才能吃到快取的紅利，又不會踩到地雷？
提示詞結構化：把穩定的放前面
這是最簡單也最有效的一招。由於前綴快取要求「前綴完全一致」，你應該把提示詞拆成兩段：
後段（變動區）：使用者這次的實際問題、當下的時間、個人化資料。
很多人的錯誤寫法是「先講使用者的問題，再貼一大段規則」，這樣每次問題一變，前綴就變了，整段快取全部失效。把順序調過來，同樣的規則可以服務成千上萬個不同問題，命中率自然高。
另外，避免在前段放入時間戳記、隨機 ID、使用者的暱稱這類每次都不同的內容，因為那會讓快取永遠對不上。
快取鍵與失效策略
快取鍵（Cache Key）的設計是一門學問。太寬鬆會誤命中，太嚴格則命中率低。實務上，一個好的快取鍵通常會包含：
正規化後的問題文字（去除多餘空白、統一全半形、轉小寫）。
問題的意圖標籤或分類。
影響答案的關鍵參數（語言、地區、方案等級）。
模型版本與提示詞版本。
最後一項特別重要：當你更新了系統提示詞或換了模型版本，務必讓舊快取失效。否則使用者會拿到用舊邏輯生成的答案，而你在後台怎麼改都改不動，這種 bug 非常難查。
至於失效策略，常見的有三種：時間導向（TTL 到期即失效）、事件導向（資料更新時主動清除）、版本導向（版本號變更即整批失效）。成熟的系統通常三者並用。
觀測指標：命中率、節省 Token、TTFT 改善
快取有沒有用，不能靠感覺，要靠數據。建議至少監控以下幾個指標：
節省的 Token 數：這直接換算成金額，是最有說服力的數字。
一個健康的系統，命中率與誤命中率應該一起看。命中率 80% 但誤命中率 5%，很可能比命中率 40% 但誤命中率 0.1% 更糟，因為前者會慢慢侵蝕使用者的信任。
七、常見誤解與破解
在論壇上，關於 AI 速度的討論經常出現一些似是而非的說法。以下挑兩個最常見的來釐清。
誤解一：AI 有記憶，所以記得我問過什麼
這是最大的誤會。大多數語言模型在單次推論中是無狀態的，它之所以「記得」你前面說過的話，是因為客戶端每一輪都把整段對話歷史重新塞進提示詞裡。换句话说，不是它記得，是你（或你的應用程式）一直在提醒它。
至於「跨對話的記憶」功能，那是應用層額外做的：把重要資訊存進資料庫，下次對話時檢索出來放進提示詞。這本質上是一種個人化的 RAG，跟模型本身的記憶無關。
所以，當你覺得「AI 記得我」，更準確的描述是「快取與檢索系統在幫我複習」。
誤解二：重複問同一個問題，答案一定一樣
不一定，而且經常不一樣。原因有幾個：
理解這一點很重要：快取保證的是「速度」，不是「一致性」。如果你需要一致性（例如自動化測試、資料標註），應該把溫度設為零，並在應用層自行做結果快取，而不是依賴模型端的隨機性。
八、未來趨勢：從快取到「推理記憶」
快取技術這幾年演進得非常快，而且方向越來越有趣。它正在從「省時間的工具」變成「AI 系統的核心架構元件」。
跨會話的長期記憶
目前的 Prompt Caching 多半是短期的，TTL 以分鐘計。但業界正在往「更長壽的快取」走：把使用者的偏好、專案背景、常用文件長期快取起來，每次對話只需載入增量。這聽起來很像「AI 真的記住你了」，但本質上仍是快取與檢索的組合技。
隨之而來的是新的工程問題：記憶要存多久？誰有權刪除？如何避免記憶被污染？這些問題目前還沒有標準答案，但可以預期會出現類似「記憶體管理 API」的產品形態。
快取與隱私的平衡
快取越深、越久，隱私風險就越高。尤其是當快取內容涉及個人資料、商業機密時，服務商必須在「效能」與「隔離」之間取得平衡。目前主流做法是嚴格的租戶隔離加上加密儲存，但這也意味著跨使用者的快取共享（那種最省錢的做法）在敏感場景中是行不通的。
對企業使用者來說，這是一個必須在合約中問清楚的問題：我的提示詞會被快取嗎？快取多久？會不會被用來服務其他客戶？ 這些答案會直接影響合規性。
另一個值得關注的方向是「可驗證的快取」——讓使用者能查詢某個回應是否來自快取、來自哪一層快取。這在需要稽核的產業（金融、醫療、政府）會越來越重要。
九、結語：快取是 AI 的「肌肉記憶」
回到最初的問題：為什麼重複的問題回得快？
因為在你看不到的地方，有一整套系統正在幫你「複習」。你的瀏覽器快取了介面，CDN 快取了資源，語意快取可能直接抄了上次的答案，GPU 的顯示記憶體裡存著剛剛算過的 Key-Value 張量，而供應商的伺服器則把你那段固定的系統提示詞牢牢記著，等你下次再來。
這些機制加起來，讓 AI 看起來像是「記得你」、「反應很快」，甚至有點像有經驗的助理。但拆開來看，每一層都是工程上的取捨：用空間換時間，用一致性換速度，用隔離換隱私。
對一般使用者來說，理解這件事的實用價值在於：當你發現 AI 突然給出奇怪的答案，或是一直回得快得不太對勁，你可以開始懷疑「是不是快取惹的禍」，而不是一味怪模型變笨。對開發者來說，理解這件事的價值更直接：把提示詞結構調好、把失效策略設計好、把觀測指標建起來，你就能在同樣的預算下，讓應用快上一大截。
快取不會讓 AI 變聰明，但它會讓 AI 變得更像一個「用得起、用得順」的工具。而這，往往才是產品能不能活下來的關鍵。
下次你再問同一個問題、發現它秒回的時候，不妨在心裡偷笑一下：這次不是模型變強了，是它終於學會抄捷徑了。
—— 本文同步發表於 雅寶社區 · 頂客論壇 🤖 AI 趨勢 分類，歡迎在下方留言討論你遇過的「快取靈異事件」。
```