如何利用提示詞壓縮技術將 API Token 成本降低 50%

在許多工作負載中，將 LLM API 帳單減少 50% 是可行的，但這並非普遍保證。結果取決於您的支出來源：未緩存的輸入 token、已緩存的輸入 token、輸出 token、推理 token、工具呼叫或重試。當長篇或重複的輸入佔帳單的顯著比例時，提示詞壓縮的效果最佳。因此，實際目標並非「讓每個提示詞長度減半」，而是「移除不會改變答案的 token，保留會改變答案的 token，並在真實流量上驗證節省效果」。

本指南採用四個實施步驟：測量基準、移除冗餘輸入、組織提示詞以促進緩存重用，以及在 API 支援的情況下，將冗長的輸出指令移至結構化控制中。範例僅供說明，並非基準測試聲明。供應商定價和緩存行為會隨時間變化，因此在進行生產環境估算前，請先驗證當前費率。

API 成本降低 50% 實際上需要什麼？

從您模型的計費公式開始。對於簡單的文本工作負載，總請求成本約等於未緩存輸入加上已緩存輸入加上輸出的成本。某些模型或功能會增加其他計費類別。OpenAI 當前的 API 回應會暴露輸入和輸出 token 使用量，包括緩存 token 的詳細資訊，且其模型頁面會發布輸入、已緩存輸入和輸出的單獨費率。

作為具體的當前範例，官方 GPT-5.6 Sol 模型頁面在 2026 年 9 月 11 日列出的費率為：每百萬輸入 token 4 美元，每百萬已緩存輸入 token 0.40 美元，每百萬輸出 token 20 美元。按照這些費率，一個 10,000 輸入/1,000 輸出的請求成本約為 0.06 美元（不含其他費用）。僅將輸入減少到 5,000 個 token 會使該範例降至約 0.04 美元，減少 33%。將輸入和輸出均減半會使其降至約 0.03 美元，減少 50%。這些價格可能會變動，因此請將此算術視為一種方法，而非永久報價。請參閱 官方 GPT-5.6 Sol 模型頁面 以獲取當前定價。

快速參考：四個最高價值的舉措

步驟 1：在更改提示詞之前測量真實的 Token 基準

圖說：一個說明性的 token 審計介面記錄了原始提示詞大小和壓縮前的樣本成本估計；這些數字並非當前的供應商定價。

收集生產請求的代表性樣本，而不是優化一個手動挑選的提示詞。至少記錄輸入 token、可用的已緩存輸入 token、輸出 token、模型名稱、延遲、重試次數，以及最終答案是否通過您的業務品質檢查。如果您的供應商提供輸入 token 計數端點，在需要確定性預算時，請在發送請求前使用它。OpenAI 目前在其 官方 API 參考文件 中記錄了 Responses 輸入 token 計數端點。

計算每個成功任務的成本，而不仅仅是每個 API 呼叫的成本。導致更多重試的壓縮提示詞即使每個請求更短，也可能更昂貴。同時按任務類型對基準進行分段：摘要、提取、RAG 問答、代理工具使用和長對話通常具有不同的 token 分佈。

步驟 2：移除冗餘而不刪除決策關鍵資訊

圖說：一個說明性的前後對比提示詞在移除重複措辭和不必要的流程指令的同時，保留了相同的請求輸出。

最安全的第一次壓縮通過是語義去重。刪除重複的角色描述、重複的約束條件、禮貌性填充詞、對明顯格式的解释，以及多次教授相同模式的範例。將重疊的規則合併為單一指令。優先使用一句精確的句子，而不是幾句重述相同要求的句子。

之前

You are a helpful assistant who is an expert in product analysis.
I need you to analyze the following customer feedback and provide
a detailed summary. Please identify the key themes, overall sentiment,
notable quotes, and recommendations for our product team. Make sure
your response is professional, clear, concise, and well structured.

之後

Analyze the customer feedback.
Return: key themes, overall sentiment, notable quotes, and product recommendations.
Be concise and factual.

不要僅僅因為例外情況、政策邊界、領域定義、工具安全規則或證據要求很長就將其壓縮掉。這些通常是高價值的 token。一個有用的測試是問：「如果我刪除這句話，可接受的輸出會改變嗎？」如果是，請保留它，除非 API 控制或架構可以更可靠地強制執行相同的行為。

步驟 3：將穩定內容放在前面，動態內容放在後面

圖說：一個說明性的提示詞佈局將穩定指令放置在可重用的前綴中，並在後面附加請求特定的上下文。

提示詞緩存不會減少原始 token 數量，但可以減少按正常輸入費率計費的金額並降低提示詞處理延遲。這使得提示詞佈局成為成本優化的一部分。將系統指令、共享範例、工具指南和其他穩定內容分組在一起。將請求特定的事實、檢索到的段落、用戶數據和當前問題放在後面。

OpenAI 的模型指南明確建議將靜態內容放在前面，動態內容放在後面，以改善提示詞緩存重用，且其回應使用對象暴露緩存 token 資訊以供測量。請參閱 官方模型指南 和 Responses API 參考文件。

避免在否則可重用的前綴內更改無害的空格、範例順序、時間戳、隨機 ID 或每用戶文本，除非供應商的緩存語義表明這些更改是安全的。從 API 回應中測量緩存命中，而不是假設提示詞正在被重用。

步驟 4：用結構化輸出控制取代關於格式的散文

圖說：一個說明性的結構化輸出視圖顯示架構如何取代許多重複描述相同回應形狀的散文行。

提取和分類提示詞經常浪費 token 用自然語言描述 JSON 欄位、允許值、嵌套、順序和驗證規則。當 API 支援結構化輸出或類型化工具參數時，盡可能將該契約移至結構化介面中，並讓自然語言指令專注於意義。

當前的 OpenAI 指南特別建議在可能的情況下從提示詞中移除輸出架構定義，並改用結構化輸出（Structured Outputs）。這可以減少提示詞文本，也可以減少格式錯誤輸出的重試。確切機制因供應商而異，因此在未檢查該供應商文件的情況下，不要將 OpenAI 特定的請求格式複製到另一個 API。

針對 RAG、長文件和對話的高級壓縮

在四個基本步驟穩定後，更大的節省通常來自減少上下文而不是潤飾句子措辭。在 RAG 系統中，檢索更少但更相關的段落，對近乎相同的塊進行去重，並避免附加無法影響答案的文件。對於長對話，保留持久事實和未解決的決策，但摘要或刪除不再影響當前任務的輪次。對於代理系統，當您的架構安全允許時，僅暴露與當前階段相關的工具和工具描述。

學習型提示詞壓縮器是超長上下文的另一個選項。Microsoft 的開源 LLMLingua 專案 實現了 token 級提示詞壓縮。原始的 LLMLingua 論文 報告在其評估設定中，壓縮率高達 20 倍，且基準測試退化有限。LongLLMLingua 針對長上下文任務，而 LLMLingua-2 使用任務無關的學習壓縮器。這些是研究結果，並非保證相同比率能在您的數據上保留品質。在部署激進壓縮之前，請對您自己的任務、語言、模型和提示詞類型進行基準測試。

如何證明優化確實更好

在相同的代表性請求上運行 A/B 評估。基準和壓縮版本應使用相同的模型、推理設定、工具、檢索輸入和成功標準。盡可能一次更改一種壓縮技術，以便識別導致回歸的原因。

不要因為提示詞短了 50% 就宣稱勝利。更強的接受條件是：壓縮配置在保持預定義的品質、延遲和可靠性容差範圍內的同時，將測量成本降低大約您的目標金額。

何時應該停止壓縮？

當下一次減少刪除正確決策所需的事實、增加幻覺、導致工具呼叫錯誤、削弱政策合規性，或增加重試次數以至於抵消節省時，請停止或退縮。如果您運行單獨的模型來壓縮每個提示詞，壓縮也可能增加延遲。一項 2026 年關於真實世界推理環境中提示詞壓縮的研究 發現，在有利於提示詞長度和硬體機制之外，預處理開銷可能會抵消推理增益，這是另一個測量端到端性能而非僅測量 token 數量的原因。

對於小提示詞，手動清理和緩存友好組織通常比添加專用壓縮模型更容易證明其合理性。對於大型 RAG 負載或多文件工作流，上下文選擇和學習壓縮變得更有吸引力，因為可移除的 token 量大得多。

快速實施檢查清單

• 捕獲包含輸入、已緩存輸入、輸出、延遲、重試和任務成功率的生產基準。
• 首先移除重複指令、低價值散文和冗餘範例。
• 保留領域定義、例外情況、證據要求和安全約束。
• 當緩存語義獎勵可重用前綴時，將穩定提示詞內容放在動態請求特定內容之前。
• 使用結構化輸出或工具架構，而不是在散文中重複描述固定回應格式。
• 對於 RAG，在嘗試 token 級壓縮之前，先減少無關和重複的上下文。
• 僅在任務仍能正確完成時限制輸出長度。
• 比較每個成功任務的成本，而不仅仅是提示詞 token 數量。
• 在每次有意義的壓縮更改前後運行回歸測試。
• 每當更改模型或 API 版本時，重新檢查供應商定價和緩存規則。

結論

對於某些冗長、上下文密集的工作負載，降低 50% 是一個合理的工程目標，但應將其視為需要驗證的結果，而非預設期望。最可靠的路徑是先測量，移除語義冗餘文本，最大化安全緩存重用，使用結構化控制縮短輸出契約，然後使用檢索剪枝、摘要或經過測試的提示詞壓縮器攻擊剩餘的最大上下文塊。如果每個成功任務的最終成本下降，而品質保持在您的接受範圍內，則壓縮正在起作用。如果品質或重試惡化，請恢復遺失的資訊並優化請求的另一部分。

主要參考資料

• OpenAI: GPT-5.6 Sol 模型和定價 — 檢查於 2026 年 9 月 11 日。
• OpenAI: 模型指南、提示詞緩存和結構化輸出建議 — 檢查於 2026 年 9 月 11 日。
• OpenAI: 輸入 token 計數 API 參考文件 — 檢查於 2026 年 9 月 11 日。
• Microsoft: LLMLingua 原始碼儲存庫。
• Jiang 等人: LLMLingua 原始論文。
• Jiang 等人: LongLLMLingua 原始論文。
• Pan 等人: LLMLingua-2 原始論文。
• Kummer 等人: Prompt Compression in the Wild。