🔹 前言

在過去幾天的章節中，我們逐步建立起一套可觀測、安全可靠、有效率的 LLM 應用基礎：

• Day 19 — 延遲、Token 與成本觀測：透過指標化（metrics）與儀表板，讓推理效能與成本透明化。
• Day 20 — 品質保障：引入自動化評測與品質檢核，確保輸出結果能符合業務需求。
• Day 21 — 快取機制：以結果快取與嵌入快取，避免重複計算，降低延遲與重複開銷。
• Day 22–25 — 版本治理、安全防護與路由機制：建立模型版本管理、輸入／輸出防護，以及多模型路由策略，讓系統更穩健且可控。

在這些基礎之上，今天我們要進一步思考如何系統性地把 推理成本[註1] 壓下來。

[註1] 推理成本 = 讓大語言模型（LLM）執行一次推理（inference），從輸入到產生輸出的過程中，所需要消耗的各種資源與金錢 = 每次「問模型 → 得到答案」所花的錢 + 資源。

🔹 成本是怎麼長出來的？

雖然單就 LLM 的觀點，我們可以知道：

每次推論請求（Inference Request）的成本 ~= PromptTokens * 單價_in + CompletionTokens * 單價_out

但實際上：

總成本 = 所有推論請求成本之和 +（檢索、工具、資料搬運、資料庫等基礎架構等間接成本）

以上面這張圖來說，可以舉例幾個常見成本變多的情境：

1. 上下文膨脹：RAG 把太多段落塞進去
2. 重複問題重複算：沒做快取或預先生成
3. 模型使用未分級：沒有路由或升級策略，FAQ 與複雜推理一律走同一個大模型，殺雞用牛刀
4. 幻覺成本：模型答錯需要人工校正，衍生額外人力成本

這其實和 SRE 工作上常見到的費用浪費情境很像：

• 上下文膨脹 ≈ log 裡塞滿無用雜訊
• 重複計算 ≈ 打包 Images 或是 artifacts 沒用 build cache
• 過度配置（Overprovisioning） ≈ 線上服務明明只有 100 QPS，卻硬是配 100 台 VM，造成大部分資源閒置。
• 誤觸警報：誤報雖不耗機器成本，但會耗盡工程師時間和精力🫠🤌🏻

所以在評估成本時，需要以系統設計的想法去檢視各個層面的費用。

🔹 成本評估框架

在討論具體改善手段之前，我們需要先釐清「成本」的全貌。這裡可以借用 Economic Evaluation of LLMs (2025) [註1]的觀點，把 LLM 應用成本 拆成三個層級：

1. 商業層（Business Impact）

   • 錯誤成本：錯誤答案需要人工補救，甚至可能帶來客訴或信任流失。
   • 延遲成本：回覆過慢導致使用者放棄或體驗下降。
   • 放棄成本：系統直接拒絕或丟給人工處理，增加人力成本。

2. 系統層（System Cost）

   • 推理成本：模型計算（API Token 或 GPU 運算）
   • 檢索成本：RAG 查詢、向量檢索、資料搬運
   • 快取／治理開銷：維護 cache、policy、registry 的成本

3. 請求層（Request Cost）

   • 單次請求的 Token 成本（PromptTokens * 單價_in + CompletionTokens * 單價_out）
   • 是否命中快取、是否需要升級到大模型
   • 該請求的實際花費（可量測，適合做日／週／月的統計）

[註1] Economic Evaluation of LLMs - Michael J. Zellinger

根據上面小節提到的成本評估框架來分析本次鐵人賽最常提到的情境 - FAQ，可以看到能夠採取的行動有離線生成（Offline Precompute）、快取以及路由。

🔹 快速起步：只做這 3 件事就省 40%

在深入節省步驟介紹之前，如果團隊時間有限，可以先專注在這三個「高 CP 值」改善項目：

實施順序建議：

1. Week 1：導入 Result Cache
2. Week 2：調整 RAG Top-k 與 Reranker
3. Week 3-4：建立路由機制

為什麼是先做這三項？

• 這三項涵蓋「避免重複計算」、「減少輸入」、「模型分級」三大核心
• 組合效果可達 40-60% 成本降低
• 技術複雜度漸進，不會一次性增加太多維護負擔

🔹 五條主要降低成本路徑

1) Prompt / Context 精煉（Refinement）

LLM 的計價方式幾乎都與 Token 數量 直接掛鉤，因此「上下文精煉」往往是最能立刻見效的降本手段。

• 模板片段化：把系統提示中會重複的部分切成小模組（module），集中管理，讓 Token Cache 能發揮作用。[註1]
• RAG 精簡輸入：調整 chunk_size 與 top_k，先用 reranker 排序，再只餵給模型最相關的 2–3 段，而不是整包丟進去。 （Day10 的文章有提到）[註2]
• 指令結構化：刪掉冗詞與贅述，不要強制「逐步推理」；若需要嚴格輸出結構，用 JSON schema 或表格取代自然語言。[註3]
• 兩段式流程：遇到長上下文任務，先做摘要 (summarization)，再進行生成；整體 Token 消耗通常比直接丟大上下文更低。[註4]

💡 在進 LLM 之前本機估算 token 數量，超過閾值就走降階方案（改用較小模型 / 縮短上下文 / 轉人工處理）。

[註1] A Practical Guide to Reducing Latency and Costs in Agentic AI Applications
[註2] Chunking for RAG: best practices
[註3] Learning to Generate Structured Output with Schema Reinforcement Learning
[註4] LazyLLM: Dynamic Token Pruning for Efficient Long Context LLM Inference

2) Cache 策略

許多 LLM 應用的高額成本來自「重複計算」。快取策略的核心概念是：對重複的上下文片段或查詢做指紋 (hash)，命中後直接重用，不必再重新推理或計算。

• 片段快取（Segment / Token Cache）：將「固定 System Prompt + 常駐說明」指紋化，命中即回放，避免每次重新送入 LLM。[註1]
• 檢索段落快取（Retrieval Cache）：對 RAG 檢索回來的文段做指紋；若命中則直接拼接，不需再次摘要或清洗。[註2]
• 回應快取（Result Cache）：以 hash(full_prompt) 為 Key，命中後直接回傳答案，特別適合 FAQ 或重複查詢。
• Embedding Cache：對輸入文本做 hash(text)，避免重複生成向量嵌入，對文件更新率低的情境尤其有效。[註3]
• 動態 TTL （有效期限）策略：根據熱門度調整快取有效時間，熱門查詢延長快取，冷門查詢較快失效，以保持新鮮度。

💡 實務上可以追蹤 token_cache_hit_ratio、result_cache_hit_ratio 等指標。快取命中率越高，延遲與成本都會同步下降。

部分可以參考 Day21 - 快取機制（Caching）— 回應加速與重複檢索成本改善 的實作

[註1] PROMPT CACHE: MODULAR ATTENTION REUSE FOR LOW-LATENCY INFERENCE
[註2] GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching
[註3] Advancing Semantic Caching for LLMs with Domain-Specific Embeddings and Synthetic Data

3) Hybrid 路由

不同任務對延遲、品質、成本的需求不同，一律丟大模型（LLM）會造成浪費。Hybrid 路由就是讓「簡單任務交小模型（Lightweight Model）、複雜任務交大模型」，同時保證品質與效率。

• 規則 / 分類器路由：FAQ、短問句就丟給小模型；需要推理、風險高、條約或是合規驗證的問題讓大模型來處理。[註1]
• 信號驅動 (Signal-based Routing)：用檢索信號（例如 top-k 相似度、覆蓋率、上下文字數）判斷是否足以直接回答，若格式錯、可信度不足、缺少關鍵詞就升級到大模型。[註2]
• 級聯式 (Cascade Routing)：任務一率先經小模型處理，若不滿足 → 再交中等模型，最後才是大模型，逐層保險。[註3]
• 延遲 / SLA Routing：根據服務等級協議 (SLA) 選模型：延遲要求高就丟給小模型；允許高延遲再給大模型。
• 領域專屬模型 (Domain-specific Routing)：根據不同專業丟給不同專攻類型的模型。

路由系統流程圖

💡 觀測上可追蹤 escalation_rate（升級比例）、route_success_rate（正確路由率），來評估成本與品質平衡。

[註1] Deploying LLMs Across Hybrid Cloud-Fog Topologies Using Progressive Model Pruning
[註2] LLM Semantic Router: Intelligent request routing for large language models
[註3] Cascadia: A Cascade Serving System for Large Language Models

4) 離線生成（批次處理／預先生成）

在許多應用場景中，不必所有內容都即時生成。把「重複、常見、可預測」的部分先處理好，就能省下大量 Token 成本並加快回應。

• FAQ 預先生成: 對 Top-N 常見問題，離線生成標準答案並存到 KV Store / Redis。命中時直接回傳。這個方法成本趨近於零，回應速度也快一個數量級，重點是這個方法也是最快見效的。[註1]
• 文件摘要 / 去重複 : 文件在進入知識庫之前，先批次清洗與摘要，避免線上多餘 Token 消耗。這類工作離線處理一次，線上就能反覆受益。（Day08 的文章有提到）
• 自動化評估 / 標註: 將模型表現的正確性、風格一致性、合規檢查，放到離線批次完成，避免在即時查詢時浪費推理成本。（Day29 我們會提到）[註3]

離線生成流程決策圖

💡 建議：實務上搭配 版本號 (doc_version)，當文件或 FAQ 更新時才重算，避免不必要的重複生成。

[註1] A Practical Guide to Reducing Latency and Costs in Agentic AI Applications

5) 預算護欄

光靠最佳化還不夠，還需要事前設定邊界，避免因錯誤或濫用導致成本暴衝。預算護欄的目的就是在「錢被花掉之前」就阻止異常情境發生。

• 請求限額（Quota / Rate Limit） : 設定每日／每用戶的最大 Token 數或請求次數，超過就拒絕或降級。[註1]
• 成本警示（Cost Alerting）: 即時監控 Token 使用量與花費，當接近閾值時透過 Slack / PagerDuty 觸發警報。
• 降階策略（Fallback / Graceful Degradation）: 當月度預算或每日額度用盡時，自動切換到小模型、僅回 FAQ、或直接提示「請聯絡管理員」，這種作法需要評估系統的重要度。
• 隔離高風險任務 : 針對長上下文、批量生成等高成本操作，強制要求審批或走專門的工作流，而非直接放給即時查詢。[註2]
• 沙盒（Sandbox）測試額度: 在上線前或做新功能測試時，使用「低額度 / 測試金鑰」來跑，避免一開始就把真實預算燒掉。

💡 預算護欄和 SRE 的「熔斷機制（Circuit breaker）」很像：與其事後救火，不如事前把耗費控制在安全範圍。

🔹 成本雷達圖：你可以盯這些指標？

表格中的金額僅為範例，請讀者自行參考實際情形訂立標準。

[註1] LLM Cost Tracking Solution: Observability, Governance & Optimization
[註2] How Unbounded Consumption Attacks on LLMs Cost Companies Millions

🔹 成本試算範例

在 Day 21 - 快取實戰 中，我們用表格呈現了快取機制的成本改善：

完整計算過程請參考 Day21 - LLM 應用快取實戰：成本改善 × 加速回應

補充：單次查詢的完整成本結構

Day 21 專注在「快取效果」，這裡補充「一次查詢的成本組成」。

假設：

• 基準成本結構（每次請求）：LLM 推理 NT$0.78、Reranker NT$0.13、向量檢索 NT$0.03、基礎設施 NT$0.02 → NT$0.96/次。月量：1,000/日 × 30 天。
• Prompt/Context 精煉：僅影響 LLM Token（-25%），其他維持。
• Result/Embedding Cache 60%：命中請求成本以 NT$0.06/次 估（KV/Redis 攤提 + 中介層 I/O）；未命中 40% 仍用「精煉後」成本。
• Hybrid 路由：在未命中流量中，70% 交小模型（視為 LLM 成本折半）、30% 交原模型；Reranker/檢索/基建成本維持。
• 離線生成：有效命中 75%（含 FAQ/摘要預生成 + 熱門題），命中成本 NT$0.03/次；其餘 25% 走上一行的混合路由成本。
• 預算護欄：對重試率與誤升級做熔斷/配額，保守估 -10% 月總支出。

典型企業知識庫問答（1,000 次/日）：

每月成本基準：1,000 × 30 × NT$0.96 = NT$28,800

計價單位為美金（USD）

套用本文「五條路徑」的綜合效果

結合多個策略後的成本模擬：

1. 以上為同一情境的「逐步疊加」效果；基準假設 1,000 次/日 × 30 天、cost_per_request = NT$0.96。
2. 結算數字為「可審核的估算模型」，用於示範套用本文節省成本路徑的量級效果；可依照實際價表替換單價與命中率，實際結果請依自己環境為準。

🔹 成本改善落地藍圖

成本試算後，我們就要來看如何 實際落地。這邊提供一個參考藍圖，實際時程請依團隊資源與現有基礎調整：

理想情境（4-6 週）：基礎架構與功能已建置完成、新功能與改善可平行開發
現實情境（10-12 週）： 從零開始、單人或三人內小團隊
最快路徑（2 週見效 - 依照專案的規模) ：文章前面提到的 MVP 三步驟（Cache → Prompt → Routing）先做

💡 若團隊人力有限，可將 Phase 1+2 合併同步進行（2-3 週完成）

Phase 1：建立專案 Baseline

目標：確立現況，建立可量測的指標系統
關鍵任務：部署觀測工具、記錄基準指標、建立儀表板
驗收標準：能即時查看 cost_per_request、avg_tokens、p95_latency、query_count
系列文參考：

• Day 19 - 掌握 LLM 應用可觀測性：監控延遲、Token 與成本
• Day 18 - 用 FastAPI 實作 LLM API Gateway：驗證、限流、觀測

Phase 2：Prompt 以及 Context 精煉

目標：減少 20-30% Token 成本
關鍵任務：分析 Prompt 結構、刪除冗詞、調整 RAG top-k、結構化輸出
驗收標準：avg_prompt_tokens ↓ ≥ 20%，品質不降
系列文參考：

• Day 08 - 文件清洗與切片策略 - 源頭控制文本長度
• Day 10 - RAG 查詢實作：Retriever + Reranker - 改善檢索精度
• Day 11 - 上下文組裝：四種策略實測 - 降低上下文冗餘
• Day 15 - Prompt Generation：模板與版本管理 - 模板片段化
• Day 16 - LangChain × Guidance：可組合 Prompt 工作流

Phase 3：Cache 機制

目標：FAQ 場景命中率達 60%+
關鍵任務：部署 Redis、實作 Result/Embedding Cache、設定 TTL
驗收標準：result_cache_hit_rate ≥ 60%，延遲 < 200ms（命中時）
系列文參考：

• Day 21 - LLM 應用快取實戰：成本改善 × 加速回應

Phase 4：Hybrid 路由

目標：50-70% 查詢走小模型
關鍵任務：建立分類器、定義路由規則、實作升級機制
驗收標準：escalation_rate 10-30%，小模型準確率 ≥ 90%
系列文參考：

• Day 24 - LLM 應用分流：用任務分類做到省錢可靠
• Day 20 - LLM 回應品質監控：幻覺偵測與三層防護 - 驗證機制

Phase 5：離線生成

目標：Top 50-100 FAQ 預先生成
關鍵任務：分析熱門查詢、批次生成答案、建立版本管理
驗收標準：offline_hit_rate ≥ 75%，熱門問題延遲 < 50ms
系列文參考：

• Day 14 - LLMOps Pipeline 自動化：Prefect 與 Dagster - 批次處理流程
• Day 12 - 知識庫資料管理：多來源整合 × 版本控制 - 版本管理
• Day 22 - LLM 與知識庫的版本控制中心：Model Registry

Phase 6：預算護欄

目標：避免成本暴衝
關鍵任務：設定請求/用戶/團隊層級配額、建立警報與熔斷
驗收標準：異常流量被攔截，成本控制在預算內
系列文參考：

• Day 18 - FastAPI 實作 LLM API Gateway：驗證、限流、觀測 - 限流機制
• Day 19 - 監控延遲、Token 與成本 - 成本警報
• Day 25 - LLM 應用安全：OWASP Guardrails - 防護機制

Phase 7：回顧改善成果

目標：驗收整體成效，規劃下階段
關鍵任務：產出前後對比報告、檢視指標達成率、調整策略
驗收標準：確認成本降幅 ≥ 70%，品質維持 ≥ 4.0/5，完成書面報告

🔹 小結

在 LLMOps 觀念系列的最後一天，我們理解到了：

• 成本不是只有 Token：推理成本只是冰山一角，還包含檢索、資料搬運、治理與隱藏的人力／維運開銷。
• 五條主要降本路徑：上下文精煉、Cache 策略、Hybrid 路由、離線生成、預算護欄
• 建立長期機制：靠指標監控（如 cost_per_request、cache_hit_rate、escalation_rate）持續迭代，才能把降本內化成日常工程實踐。
• 延伸 DevOps 觀念：就像 SRE 看重可觀測性、容量規劃、資源利用率，LLM 應用也需要同樣的治理邏輯，才能規模化且可持續。

👉 明天（Day 27）我們將進入 RAG FAQ Chatbot 實戰案例 I：功能開發與驗收，把快取、觀測、RAG、路由、安全與降本全部串起來，驗證完整上線藍圖。

📚 引用來源文章 / 延伸閱讀

• Economic Evaluation of LLMs - Michael J. Zellinger
• A Practical Guide to Reducing Latency and Costs in Agentic AI Applications
• Chunking for RAG: best practices
• Learning to Generate Structured Output with Schema Reinforcement Learning
• LazyLLM: Dynamic Token Pruning for Efficient Long Context LLM Inference
• PROMPT CACHE: MODULAR ATTENTION REUSE FOR LOW-LATENCY INFERENCE
• GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching
• Advancing Semantic Caching for LLMs with Domain-Specific Embeddings and Synthetic Data
• Deploying LLMs Across Hybrid Cloud-Fog Topologies Using Progressive Model Pruning
• LLM Semantic Router: Intelligent request routing for large language models
• Cascadia: A Cascade Serving System for Large Language Models
• LLM Cost Tracking Solution: Observability, Governance & Optimization
• How Unbounded Consumption Attacks on LLMs Cost Companies Millions