<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>FinOps on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/finops/</link><description>Recent content in FinOps on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 22 Jun 2026 03:30:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/finops/feed.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Autoscaling Complete Guide (Part 5): Vertical Pod Autoscaler &amp; Resource Optimization</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part5-vpa-resource-optimization/</link><pubDate>Sun, 09 Nov 2025 20:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part5-vpa-resource-optimization/</guid><description>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.</description></item><item><title>Kubernetes Autoscaling Complete Guide (Part 6): Advanced Autoscaling Patterns</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part6-advanced-patterns/</link><pubDate>Sun, 09 Nov 2025 22:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part6-advanced-patterns/</guid><description>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.</description></item><item><title>AI 工程從零開始｜Phase 17 Part 3：AI 成本優化與規模化 — 把每美元壓榨到極限</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/</link><pubDate>Mon, 22 Jun 2026 03:30:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/</guid><description>大多數團隊看到 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 成本的結構完全不同：</description></item></channel></rss>