部落格列表

2026.09.22

提示快取如何降低 LLM 成本並穩定函數工具呼叫

提示快取是降低重複輸入 Token 成本與回應等待時間的直接方法，尤其適合反覆傳送系統指令、長篇規範、工具定義與知識文件的企業應用。若同一段穩定前綴被持續送往模型，卻每次都重新計費與推理，成本會隨流量放大，也會讓使用者感受到不必要的延遲。

實務上，快取不是單純「把回答存起來」。脈絡快取處理的是模型讀取提示詞的重複工作；語意快取則可能直接回覆相近問題。兩者若沒有把租戶、權限、模型版本、工具 Schema 與資料版本納入設計，雖然短期省錢，卻可能造成越權回覆、舊知識殘留或工具呼叫失敗。

本篇會從快取命中原理、隱含與明確快取、成本計算、TTL 與失效機制切入，再說明它如何支援函數呼叫開發。最後以 PoC 的方式建立可測試指標，讓團隊能根據命中率、p95 延遲、工具成功率與投資效益，判斷是否值得擴大導入。

提示快取的原理：先理解命中條件與適用工作

工程師檢視大型語言模型提示詞快取命中紀錄

可重用前綴是快取效益的核心

答案很明確：只有每次請求都一致且夠長的前綴，才有穩定命中機會。常見前綴包括系統角色、品牌語氣規範、輸出格式、長篇產品手冊、檢索基礎文件與工具定義；每位使用者當下提問、訂單編號或即時日期，則應放在提示詞尾端。

以客服助理為例，可將「回答規則、禁止事項、退換貨制度、函數工具 JSON Schema」固定排序在最前面，再附上使用者問題。這種做法讓模型能重複使用既有脈絡，同時也讓版本差異集中在少數區塊，避免每次 API 請求因欄位順序不同而失去命中。

設計時不要只看提示詞總長度，而要盤點重複比例。若固定內容僅占很小部分，快取收益有限；若固定內容占大多數，快取通常更有價值。將靜態政策、工具說明與大型文件序列化為固定格式，也能減少 JSON 空白、陣列順序或時間戳記造成的非預期差異。

  • 固定內容置前，使用者與交易資料置後
  • 統一 JSON 序列化、欄位排序與語言版本
  • 以內容版本號辨識可安全重用的前綴

隱含快取與明確快取解決不同問題

答案是：隱含快取適合低維護、由平台自動判定重複前綴的情境；明確快取則適合需要精準控制資料、生命週期與跨請求重用的系統。前者降低工程負擔，後者可明確建立、取得、更新與刪除快取資源，較適合大型文件與多租戶服務。

在支援隱含快取的服務上，相較於標準輸入符記，隱含快取可為快取符記提供 90% 的折扣。這不代表每次請求都必定命中；平台仍會依模型、前綴長度、請求結構與當前快取狀態判斷，因此必須從 usage 欄位驗證，而不是只從程式碼推測。

明確快取更適合需要可稽核資料生命週期的案例，例如法規手冊、內部 SOP 或定版知識包。團隊可把文件版本寫進快取名稱與資料表，發布新版本時建立新快取、切換流量，確認正常後再清除舊資源，避免直接覆寫導致線上請求讀到不一致內容。

  • 隱含快取：部署快、控制較少
  • 明確快取：可指定內容、TTL 與刪除時機
  • 兩者都要以實際 usage 與成本資料驗證

快取命中不等於直接回覆答案

答案是：脈絡快取只減少模型重新處理輸入脈絡的負擔，模型仍可能針對每個新問題生成不同答案。它與「把問答答案直接存起來」不同，因此特別適合共享規則與長文件、但使用者問題仍持續變化的工作流程。

第一次請求通常要建立可重用內容，第二次才有命中可能。實作驗證可觀察這組結果：第一次請求创建缓存 Token：1605 第一次请求命中缓存 Token：0；第二次请求创建缓存 Token：0 第二次请求命中缓存 Token：1605。若第二次仍為零，應先檢查前綴是否被動態值改寫。

另一個常見誤解是把語意快取與脈絡快取混用。語意快取會用嵌入向量比對相似問題，可能直接取回既有答案；脈絡快取則保留模型生成彈性。涉及金額、訂單、權限或即時庫存的情境，不宜僅因語意相似就沿用舊答案，仍需重新查詢權威資料來源。

  • 脈絡快取：重用輸入脈絡
  • 語意快取：比對相似問題與既有回覆
  • 高風險資料必須重新驗證即時狀態

成本、限制與平台選型：不要只看折扣比例

先用輸入量、命中率與寫入成本估算損益

答案是：成本評估要拆成首次寫入、後續命中、未命中與儲存期限四項，而不是只宣稱「有快取就會省」。部分服務通常按输入 Token 标准单价的 125% 计费，但后续命中通常仅需支付 10% 的费用；因此重複使用次數不足時，建立快取可能反而不划算。

Gemini 的折扣條件也與模型世代有關：如果是 Gemini 2.5 以上版本，折扣為 90%；如果是 Gemini 2.0 版本，折扣為 75%。採購或架構團隊應將模型選擇、提示詞長度、請求頻率與 TTL 一起放入試算，才能避免只因單價較低卻忽略實際命中率。

下表可作為初步選型清單，而非最終承諾。不同帳戶、地區、API 版本與模型部署可能有差異，正式上線前應以目標專案的官方文件與測試結果覆核。特別是模型更新後，最小 Token 數與快取欄位名稱可能改變，監控程式也要同步調整。

此表可快速比較常見快取控制項與觀測欄位。
平台或模式 已知門檻或期限 折扣或計費線索 主要觀測欄位
Gemini 隱含快取 Gemini 3：4,096 Token Gemini 2.5 以上：90% cachedContentTokenCount
OpenAI 斷點快取 預設 TTL：30m 最多四個斷點 cached_tokens
阿里雲快取 最少 1024 Token 命中後 5分鐘重置 cache_write_tokens
實際支援範圍請以各供應商帳戶、模型與區域文件為準。
  • 將快取寫入費與命中折扣一起計算
  • 分別統計固定前綴與動態內容的 Token
  • 以實測請求取代估算的命中率假設

Token 門檻與內容結構會決定能否命中

答案是：內容再有價值，未達平台最小門檻仍可能無法產生效益。Gemini 3 系列模型：4,096 個權杖；Gemini 2 系列模型：2,048 個權杖。若固定前綴短於門檻，應先確認是否值得為了湊長度硬塞內容，因為多餘規則也會增加模型理解負擔。

部分快取機制的限制更細緻，例如缓存最少 Token 数為 1024、缓存块的内容最少为 1024 Token、最多 20 个 `content` 块，而且單次請求最多支持加入4 个缓存标记。這些限制會影響大型文件應切幾段、工具定義是否獨立成區塊，以及動態檢索結果應放在何處。

工程團隊可把靜態脈絡拆成「全域規範、部門規範、工具 Schema、文件內容」四個可版本化區塊，再依請求需要組合。這比把所有資料塞成單一巨型提示詞更容易追蹤失效原因，也便於在文件更新或權限調整時，精準撤銷受影響的快取。

  • 先確認模型的最小可快取 Token 門檻
  • 內容區塊數與快取標記數要納入設計
  • 不要以無關內容填滿提示詞換取快取資格

TTL 應由資料新鮮度與風險決定

答案是：TTL 不是越長越好，而是要和資料變動速度、錯誤影響與清除能力相符。若文件相對穩定，可將脈絡快取的到期時間 (存留時間或 TTL) 更新為超過預設的 60 分鐘；若內容涉及價格、庫存、權限或事件狀態，則應採取更短期限或主動失效。

不同平台的預設也不相同。GPT-5.6及后续版本暴露了`prompt_cache_options`，当前文档记录的TTL值为`30m`，30分钟是默认值。另有服務採用缓存有效期為 5分钟（命中后重置）的模式，意味著高頻流量可延長存活，低頻資料則會自然到期。

TTL 只是一道安全網，不能取代事件驅動的清除。知識庫更新、工具 Schema 改版、員工離職、角色撤銷或敏感文件誤上傳時，系統應依資料版本與租戶範圍主動刪除快取，並留下操作紀錄，確保後續能追查誰在何時讀取過哪些內容。

  • 穩定規範可用較長 TTL，動態業務資料採短 TTL
  • 以資料版本與權限異動觸發主動清除
  • 記錄建立、命中、過期與刪除事件

快取鍵與生命週期：把一致性做成可管理的規則

快取鍵必須納入租戶、權限與版本

答案是：企業快取鍵至少要能區分租戶、模型、系統提示詞版本、工具版本、語言與權限範圍。若只以「問題文字」或「文件名稱」當鍵，兩個客戶可能讀到彼此的規則，或是同一使用者在權限調整後仍命中舊脈絡，形成難以察覺的資料外洩。

一個可維護的鍵可概念化為 tenant_id、role_scope、model_id、prompt_version、tool_schema_version、knowledge_version 與 locale 的組合。使用者姓名、一次性驗證碼、訂單號等高變動或敏感資料不宜直接放入共享前綴；必要時應留在動態尾段，並以應用程式層的權限查詢處理。

快取鍵不需要暴露可識別資訊。建議以雜湊或內部識別碼保存分區資訊，同時在安全日誌中保留可追溯的對照。這能兼顧故障排查與資料最小化，也讓資安團隊能在發生權限異動時，快速定位需要撤銷的快取群組。

  • 共享快取一定要有租戶隔離
  • 模型與工具版本必須成為快取維度
  • 敏感動態資料不應寫入共用前綴

失效策略要覆蓋更新、撤權與故障

答案是：最可靠的策略是「短 TTL 加上事件主動失效」，並預先定義每種事件的責任人與復原動作。單靠自然過期會讓錯誤內容存活太久；只靠人工刪除又容易在夜間部署、緊急撤權與跨區故障時漏掉關鍵快取。

知識庫文件更新時，可先建立新版本快取，讓新請求改用新版本鍵；舊版本保留到觀測確認後清除。工具 API 變更時則應同步提高 tool_schema_version，避免模型沿用已刪除參數。這種不可變版本策略比原地修改安全，也更容易回滾。

遇到敏感資料外洩疑慮時，處置順序應是停用讀取路徑、依租戶與版本範圍刪除快取、撤銷相關憑證、稽核存取紀錄，最後再恢復服務。若有跨區副本，刪除作業要等待各區完成回報，否則單一區域的清除不代表風險已消失。

  • 文件更新：切換新版本後清除舊版本
  • Schema 變更：提升工具版本並保留回滾路徑
  • 資安事件：先阻擋讀取，再清除與稽核

命中率需搭配延遲與正確性共同判讀

答案是：高命中率不必然代表系統更好，因為過度共享或過長 TTL 可能提高錯誤內容被重用的風險。建議同時追蹤快取命中率、cache write rate、輸入 Token、p50 與 p95 延遲、首 Token 延遲、錯誤率及人工轉接率，才能看到完整效益。

在 OpenAI 類型的回應中，應檢查 `usage.input_tokens_details.cached_tokens` 和 `cache_write_tokens`。在 Gemini 類型的回應中，則可觀察 `cachedContentTokenCount` 與 `cacheTokensDetails[]`。將這些欄位寫入 trace 後，才能對照特定提示詞版本、模型版本與工具版本的變化。

基準測試可使用同一批代表性問題，依序測量首次建立、第二次相同請求、僅修改動態尾段，以及修改固定前綴四種情境。每組至少記錄 Token、延遲、工具呼叫結果與成本，避免只用單次成功回應就宣告快取有效。

  • 把 cached token 與寫入 token 寫進 trace
  • 比較首次、命中、尾段變動與前綴變動
  • 以 p95 和錯誤率防止平均值掩蓋問題

函數呼叫開發如何與快取協作而不失控

工具定義應成為穩定且可快取的前綴

答案是：函數呼叫開發最適合被快取的部分，通常是工具名稱、用途、參數 Schema、權限說明與錯誤規則。這些內容常在每一輪對話重複傳送，且改動頻率低；使用者要求查詢的訂單、庫存或個人資料則必須維持動態，不能共用。

工具呼叫的責任分工應清楚：第一次是分析使用者的意圖。模型選出工具與參數後，應用程式負責驗證、授權與執行；第二次是把函數回傳值轉換成人類語言。模型不應被授權直接執行資料庫刪除、付款或外部連線等高風險動作。

例如 `get_current_weather(location: string, unit: ‘celsius’ | ‘fahrenheit’)` 的 Schema 可固定放在前綴，並將 `”required”: [“location”]` 明確宣告。工具說明越精準，模型越容易產生可驗證的參數；但 Schema 每次調整都要提高版本，否則快取的舊定義可能讓工具執行層收到不相容欄位。

  • 固定快取工具 Schema，動態保留使用者參數
  • 模型負責選擇，後端負責授權與執行
  • Schema 改版必須同步改變快取版本

模型、介面與工具版本要一起測試

答案是：不能假設不同模型對同一工具定義會有相同行為。測試矩陣至少應包含 `gpt-4o`、`gpt-4o-2024-08-06`、`gpt-4o-2024-05-13`，以及實際候選模型；模型升版後可能影響工具選擇、平行呼叫、參數格式與快取前綴處理。

舊介面常見 functions/function_call，新介面則多使用 tools/tool_calls。`tool_choice` 的預設行為是 `”auto”`，但在關鍵流程中，團隊仍要決定何時允許自動選擇、何時指定 `”any”`、何時採用 `”none”`，避免模型在不該呼叫外部工具時執行不必要操作。

測試記錄應保留可重現的設定，例如 `model=”gpt-3.5-turbo-1106″, temperature=0, max_tokens=300`，或在另一組實驗使用 `model=”gemini-3.6-flash”`。設定固定後，才能辨識工具成功率的差異是來自模型版本、提示詞快取，還是後端工具本身的延遲與錯誤。

  • 模型版本是工具回歸測試的必要維度
  • 新舊工具介面要規劃遷移與相容期
  • 固定測試參數，保留可重現請求紀錄

執行層必須防止錯參數、重複與越權

答案是：模型產生的函數參數一律視為未受信任輸入。後端應以 JSON Schema、型別驗證或 Pydantic 驗證欄位，再重新查詢呼叫者的權限。即使模型正確選到工具，也不能因為使用者在文字中說「幫我刪除」就略過審核或授權。

對會改變狀態的工具，必須使用冪等鍵、逾時、有限重試與補償交易。若模型或網路重送同一筆請求，系統要能辨識是否已完成，避免重複退款、重複建立工單或重複發送通知。對平行呼叫則需標示依賴關係，防止先執行後續動作。

快取也不能跨越權限邊界。工具定義可以共享，但函數結果應依租戶與使用者隔離；包含個人訂單、健康資訊或薪資的結果不應進入共用語意快取。高風險工具宜加入人工覆核、稽核事件與最小權限 Token，降低提示注入導向越權工具呼叫的風險。

  • 所有工具參數都要做後端驗證
  • 狀態變更工具需要冪等與補償設計
  • 工具結果依租戶與權限隔離，不做共用快取

從 PoC 到正式營運：用數據證明快取與工具整合價值

以最小範圍建立可判斷的 PoC

答案是：先挑一個高重複脈絡、可量化成本且工具風險可控的流程做 PoC，例如內部知識問答加上工單查詢。不要一開始把所有文件、所有部門與所有工具接入；範圍過大會使快取效益、模型品質與流程問題互相混雜，難以判斷真正成因。

ALION 的做法是先透過現場調查與訪談設定目的與 KPI，再以實際資料、實際環境驗證原型。驗證結束後不只看模型是否能回答，也整理正式開發所需的費用、ROI 與 Go／No-Go 依據；若結果顯示不適合推進，及早停止本身就是降低投資風險的成果。

若企業尚未具備專職 AI 架構角色，可採月費 20 萬日圓起的上游工程訂閱方式，小規模完成需求梳理、設計文件與示範製作。以 1,000 萬日圓規模的開發案而言，上游工程約需 3 個月（約 60 萬日圓），更適合作為正式投資前的決策材料。

  • 先選固定前綴高、資料風險可控的流程
  • KPI 同時涵蓋成本、延遲、正確性與採用率
  • PoC 的目標是取得 Go／No-Go 證據

建立可重現的效能、品質與安全測試

答案是：正式導入前至少要有一份固定測試集，包含正常提問、模糊意圖、錯誤參數、權限不足、工具逾時、提示注入與資料更新後的請求。每次模型、工具 Schema、快取 TTL 或提示詞版本調整，都應在相同測試集上重新比較。

測試不應只看回答是否順暢，而要量測工具選擇正確率、參數正確率、工具端到端成功率、幻覺工具率、人工介入率與 p95 延遲。若快取提高速度卻讓使用者讀到舊版政策，或讓模型選到已棄用工具，則節省的 Token 成本不足以抵銷營運風險。

對外部 API 工具，可在閘道層設定速率限制與保護規則，例如 ``。對語意快取則應明確設定相似度門檻與存活時間，例如 `score-threshold=”0.15″`、`max-message-count=”10″`、``，並以業務資料驗證誤命中比例。

  • 固定測試集涵蓋品質、資安與故障情境
  • 版本變更後比較工具與快取的端到端指標
  • 速率限制與語意門檻要以實測校正

持續維運需要觀測、文件與可信來源

答案是：快取與工具整合上線後，仍要持續檢視命中率下滑、成本異常、TTL 到期、Schema 不相容與權限失敗。每週一次定期會議可將業務端回饋、監控儀表板與待辦事項對齊，避免問題只停留在工程日誌，卻未被轉成產品或流程決策。

在模型路由、成本與可觀測性如何共同設計方面，可延伸閱讀企業 LLM 營運指南：從模型路由、成本控管到可觀測性的架構設計。快取不應獨立優化；它必須與模型選擇、流量分級、重試策略及服務等級目標一起檢視。

建議優先查閱官方文件：Google Gemini API 文件 https://ai.google.dev/gemini-api/docs/caching 、OpenAI Prompt Caching 文件 https://platform.openai.com/docs/guides/prompt-caching 、Azure API Management 語意快取文件 https://learn.microsoft.com/azure/api-management/llm-semantic-cache 、以及 OWASP LLM Top 10 https://owasp.org/www-project-top-10-for-large-language-model-applications/ 。官方規格更新時，應同步更新內部測試與操作手冊。

  • 以監控異常觸發快取、權限與版本檢查
  • 把模型路由與快取策略視為同一個營運議題
  • 以官方文件與安全準則維護內部規格

總結

快取的真正價值不只在 Token 折扣，而在於把重複脈絡、工具定義與知識版本變成可治理的資產。從前綴排序、Token 門檻、TTL、快取鍵到工具權限，任何一個環節缺乏版本與觀測設計，都可能讓成本優化演變成資料或營運風險。

重點整理

  • 先將穩定規範、文件與工具 Schema 放在提示詞前綴，動態資料置後。
  • 以 cached token、寫入 token、p95 延遲與工具成功率共同評估成效。
  • 快取鍵要區分租戶、權限、模型、提示詞、工具與知識版本。
  • 工具定義可快取，但函數結果與敏感資料必須嚴格隔離。
  • 用小範圍 PoC 驗證成本、品質與安全，再決定是否正式擴大。

若您的團隊正在評估長提示詞、企業知識庫或工具整合是否值得投入，建議先選定一條高頻流程，建立首次請求、快取命中、資料更新與工具失敗四類測試。透過實際資料測得命中率、成本與業務 KPI 後，再決定最合適的模型、TTL 與正式開發範圍。

常見問題 FAQ

Q1. 提示快取和一般的回應快取有什麼不同？

提示快取重用的是模型讀取系統指令、文件與工具定義等輸入脈絡，模型仍會針對新問題生成答案。一般回應快取或語意快取則可能直接回傳既有答案，因此需要更嚴格處理資料新鮮度、權限與相似度誤判。

Q2. 快取命中率多少才值得導入？

沒有通用門檻，應以固定前綴 Token 占比、首次寫入成本、後續命中折扣、請求頻率與延遲目標一起計算。最可靠的方法是在 PoC 中比較首次請求、重複請求與前綴變更後請求的實際 usage、成本與 p95 延遲。

Q3. 函數工具定義可以放進快取嗎？

可以，而且工具名稱、描述與 JSON Schema 通常是很適合的固定前綴。不過工具 Schema、權限規則或參數欄位變更時，必須提高版本並讓舊快取失效；模型產生的參數仍要由後端重新驗證與授權。

Q4. 敏感資料可以使用提示詞快取嗎？

可否使用取決於平台設定、合約、資料分類與企業控管能力，但原則是避免把個資、祕密、一次性憑證與高敏感交易內容放入共享前綴。若必須處理，應採租戶隔離、最小權限、短 TTL、加密、稽核與主動撤銷機制。

Q5. 快取未命中時應優先檢查什麼？

先比對系統提示詞、文件排序、工具 Schema、模型名稱、語言、序列化格式與動態欄位是否完全一致，再查看 cached token 與 cache write token。許多未命中並非平台故障，而是時間戳記、隨機識別碼或 JSON 欄位順序被放進固定前綴。



返回部落格列表