https://yennj12.js.org/yennj12_blog_V4/tags/cost-optimization/Recent content in Cost-Optimization on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Sun, 09 Nov 2025 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Part 2 of the Kubernetes Autoscaling series: Comprehensive guide to cluster-level autoscaling covering Cluster Autoscaler, Karpenter, cloud provider-specific solutions (EKS, GKE, AKS), and emerging technologies for intelligent node provisioning and cost optimization.https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part5-vpa-resource-optimization/Sun, 09 Nov 2025 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part5-vpa-resource-optimization/Part 5 of the Kubernetes Autoscaling series: Deep dive into Vertical Pod Autoscaler (VPA), resource right-sizing strategies, combining VPA with HPA, and production-grade resource optimization techniques for cost-effective Kubernetes operations.https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part6-advanced-patterns/Sun, 09 Nov 2025 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part6-advanced-patterns/Part 6 of the Kubernetes Autoscaling series: Advanced autoscaling patterns for stateful applications, multi-cluster deployments, cost optimization strategies, batch job scaling, and emerging technologies. Real-world architectures and production-grade implementations.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part18-memory-cost-tuning-zh/Thu, 04 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part18-memory-cost-tuning-zh/「把所有歷史對話塞進 Context 再問 LLM」 ——這個方案在 demo 時可以，在生產環境裡三個月後會讓你的帳單嚇一跳。 三層記憶體設計的核心不是「記更多」，而是「用最低的 token 成本，讓 Agent 感覺上記得一切」。 面試情境 面試官： 「這個 Agent 需要維護與大客戶長達三個月的商務對話。如果把所有歷史對話和工具調用結果全部當 Context 塞給 Gemini，Cost-per-request 會暴增，Tokens/sec 吞吐量大幅下滑。請設計一個三層記憶體架構平衡成本與延遲。」 一、核心問題：Context 成本為什麼會失控 先量化問題的規模： 典型企業客戶的對話規模估算： 每輪對話約 500 tokens（user + assistant + tool calls） 每天溝通 10 輪 三個月（90 天）= 900 輪 = 450,000 tokens 的歷史對話 如果全部塞入 Context： 每次請求的 input tokens： ├── System Prompt: 500 tokens ├── 三個月歷史對話: 450,000 tokens ├── 當次查詢: 100 tokens └── 總計: ~450,600 tokens 成本（Gemini 1.5 Pro，$1.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part24-hybrid-model-routing-zh/Thu, 04 Jun 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part24-hybrid-model-routing-zh/為什麼用 Gemini Pro 回答「你好！」？ 用 Gemma-2b 回答「你好！」，品質幾乎一樣，成本低 20 倍。 問題不是「要不要用小模型」，而是「如何設計一個系統，讓正確的問題找到正確的模型」。 面試情境 面試官： 「客戶希望設計一個 Hybrid Model Routing 系統：70% 的簡單日常問候和格式轉換自動路由到 GKE 部署的 Gemma-7b；複雜推理和多步驟 Tool-calling 才路由到 Gemini 1.5 Pro。你如何設計這個路由器？如何用統計評估確保路由器不會因為誤判讓整體品質下滑？」 一、核心問題：路由器要解決什麼問題 不路由的世界（所有請求 → Gemini Pro）： 成本：$1.25/1M input tokens（Gemini 1.5 Pro） 延遲：平均 2~5 秒 路由後的世界： 70% 簡單請求 → Gemma-7b（自托管 GKE） 成本：近乎零（只有 GKE 運算成本，約 $0.05/1M tokens 等效） 延遲：0.2~0.5 秒（本地推理） 30% 複雜請求 → Gemini Pro 成本：$1.25/1M tokens 延遲：2~5 秒 整體節省：70% × 95% cost reduction = ~66% 成本降低 代價（路由器的風險）： 如果路由器誤判，把複雜問題送給 Gemma-7b → Gemma-7b 無法回答 → 錯誤答案 → 業務影響 → 品質下滑的代價 > 成本節省的收益 結論：路由器的設計核心是「確保誤判率在可接受範圍內」 二、路由器設計的三種方案 方案比較： Embedding-based LLM-based Router Rule-based Semantic Router (Gemini Flash) ────────────────────────────────────────────────────────────────────────── 決策速度 ~50ms ~300ms < 1ms 準確性 中等（依賴相似度） 高（LLM 理解語意） 低（規則有限） 維護成本 中（需要更新範例向量） 低（Few-shot 更新） 高（規則越來越多） 對新場景適應 差（未見過的範例命中率低） 好（LLM 泛化能力強） 差 成本 Embedding 費用（低） Gemini Flash 費用（低） 零 可解釋性 中（相似度分數） 高（可要求 LLM 解釋） 高（規則清楚） 適用場景 路由決策需要極快速度 品質優先 非常簡單的場景 推薦：雙層架構 Layer 1: Rule-based（極快速，處理明顯的情況） Layer 2: Semantic Router（處理 Layer 1 通過的請求） 三、完整路由架構設計 ┌──────────────────────────────────────────────────────────────┐ │ 用戶請求 │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Layer 1：Rule-based 快速路由（< 1ms） │ │ │ │ 明確路由到小模型（Gemma）： │ │ ├── 請求長度 < 50 tokens AND 無 Tool-calling 歷史 │ │ ├── 純問候語（pattern match） │ │ └── 格式轉換任務（JSON → CSV 等） │ │ │ │ 明確路由到大模型（Gemini Pro）： │ │ ├── 請求含 tool_calls 欄位（需要工具能力） │ │ ├── 請求長度 > 5,000 tokens（複雜上下文） │ │ └── 用戶明確標記為「高精度模式」 │ │ │ │ 不確定 → 進入 Layer 2 │ └──────────────────────────┬───────────────────────────────────┘ │ 不確定的請求 ▼ ┌──────────────────────────────────────────────────────────────┐ │ Layer 2：Semantic Router（~50ms） │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Embedding Model（text-embedding-004，輕量） │ │ │ │ → 將當前 Query 轉為向量 │ │ │ └─────────────────────────┬────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ In-memory Vector Index（FAISS 或小型向量快取） │ │ │ │ │ │ │ │ 「簡單任務」黃金範例： │ │ │ │ ├── "今天天氣怎樣？" │ │ │ │ ├── "幫我把這段文字翻譯成英文" │ │ │ │ └── "這個 JSON 格式對嗎？" │ │ │ │ │ │ │ │ 「複雜任務」黃金範例： │ │ │ │ ├── "分析這份合約的法律風險並給出建議" │ │ │ │ ├── "根據這些數據建立一個財務預測模型" │ │ │ │ └── "找出這段程式碼的 bug 並修復" │ │ │ └─────────────────────────┬────────────────────────────┘ │ │ │ │ │ ▼ │ │ 相似度分數： │ │ ├── 與「簡單任務」相似度 > 0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part29-tco-roi-zh/Thu, 04 Jun 2026 20:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part29-tco-roi-zh/工程師說：「這個架構非常優雅。」 財務長說：「一個月要多少錢？」 FDE 說：「我來幫你們算。如果這個系統每個月省下 X 小時的人力， 以你們現在的薪資結構，大概幾個月可以回收建置成本。」 這個對話，決定了 POC 之後有沒有預算繼續做。 面試情境 面試官：「客戶問你：我們要在 Vertex AI 上部署一個 RAG-based 客服 Agent，每天大概 10,000 個 query，一個 query 平均 2,000 input token 和 500 output token。一個月的 API 成本是多少？如果我們加了一個 Embedding 服務和向量資料庫，總體的 TCO 是什麼？我要拿這個數字去說服 CFO。」 一、為什麼 FDE 必須會算成本 技術架構決定成本結構： 你選 Gemini 1.5 Pro vs Gemini 1.5 Flash → 成本差 5 倍 你選 Vertex AI Vector Search vs pgvector → 成本和維護方式不同 你選 Cloud Run vs GKE → Infra 成本和工程複雜度不同 如果 FDE 說不出成本，客戶只能靠自己估算。 自己估出來的數字通常是錯的（太高或太低）， 都可能導致預算批不下來，或者上線後超支被投訴。 FDE 的價值之一，就是幫客戶算出一個可信的數字， 並且告訴他怎麼優化。 二、AI 系統的 TCO 三個層次 Layer 1：LLM API 成本（最容易算） ├── Input token 成本 ├── Output token 成本 └── Embedding token 成本 Layer 2：Infra 成本（第二容易算） ├── Vector Database（託管服務 or 自建） ├── Compute（Cloud Run / GKE for orchestration） ├── Storage（GCS for documents） └── Network（Egress fees） Layer 3：人力成本（最容易被忽略） ├── 建置成本（Engineer 時間） ├── 維護成本（每月運維時間） └── Prompt 維護成本（調整和迭代） 三、實際試算：10,000 queries/day RAG Agent Step 1：LLM API 成本 Gemini 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/Mon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/大多數團隊看到 AI 帳單飆升，第一反應是「換便宜的模型」。 但換模型只是換藥不換病：根本問題是沒有成本工程的思維。 正確答案是把 AI 推論視為可測量、可分解、可優化的工程系統—— 從 Token 單位經濟學到快取命中率，每個數字都是槓桿點。 面試情境 你的 RAG 系統每月 AI API 費用從 $3,000 暴增到 $47,000，只花了 90 天。VP 問你：「不砍功能、不降品質，能把成本壓回 $15,000 以內嗎？」你會從哪裡下手？ 一、核心問題：AI 成本為什麼是工程問題而不是採購問題 1.1 成本爆炸的根因 AI API 成本爆炸通常不是因為「用太多功能」，而是因為工程決策累積的結構性浪費： 重複計算：相同或語義近似的 prompt 反覆打到 API，沒有任何快取層 模型過配（Over-provisioning）：用旗艦大模型處理「幫我把這段文字轉成 JSON」這種任務 無邊界的 Context Window：每次請求塞入整個對話歷史，Context 長度隨時間線性增長 同步阻塞推論：本可批次離線的任務強行走即時路徑，佔用高單價的即時算力 1.2 成本的三個維度 成本 = Token 數量 × 單價 × 請求頻率 ─────── ──── ──────── 工程可控 模型選擇 業務需求 採購談判只能影響「單價」，而且通常邊際效益有限（折扣上限約 20–30%）。 真正的槓桿在「Token 數量」和「請求頻率」——兩者都是純工程問題。 1.3 為什麼 FinOps 思維不夠用 傳統雲端 FinOps 的核心是「Resource Right-sizing」：把過大的 VM 換小。 但 AI 成本的結構完全不同：https://yennj12.js.org/yennj12_blog_V4/posts/model-tiering-cost-optimization-guide-zh/Thu, 12 Mar 2026 18:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/model-tiering-cost-optimization-guide-zh/多 Agent Token 優化系列 pt.4：深入探索模型分層策略，從任務分類、智能路由到動態選擇，提供完整實作範例，幫助你在保持品質的同時大幅降低 AI 應用成本。https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/Thu, 12 Mar 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/多 Agent Token 優化系列 pt.2：深入探索 Prompt Caching 的實際應用，從 Claude API 原生快取、應用層記憶體快取、到 RAG 系統整合，提供完整程式碼範例，幫助你打造高效低成本的 AI 應用。https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/Thu, 12 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/多 Agent Token 優化系列總覽：深入解析 Token 用量優化策略，涵蓋 Prompt Caching、Context 壓縮、Agent 專責化、模型分層、選擇性 Context 傳遞等方法，幫助你建構高效且低成本的多 Agent 系統。