https://yennj12.js.org/yennj12_blog_V4/tags/caching/Recent content in Caching on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-17-context-caching-eviction-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-17-context-caching-eviction-zh/核心定義：Vertex AI Context Caching 將大型 prompt prefix 的 KV activations 固定在 TPU 記憶體，後續呼叫跳過 prefill 階段，token 成本降至 1/4——但按小時計費的機制讓閒置快取成為最隱蔽的成本炸彈，正確的驅逐策略是區分工程師與初學者的分水嶺。 一、為什麼面試官問這個 LLM 系統的推論成本往往由「重複處理相同 prefix」所主導。面試官問 Context Cache Eviction，真正在測三件事： 成本意識：你是否理解 Vertex AI 計費模型的按小時收費邏輯，以及如何在活躍用戶與閒置用戶之間動態調配快取資源。不懂計費細節的候選人，設計出的系統往往在上線後讓帳單暴增 3-5 倍。 架構判斷力：你能否設計出跨越 L1/L2/L3 三層的快取驅逐策略，而不只是「開快取就好」這種淺層答案。強候選人能說清楚每層的觸發條件、成本邊界、以及在什麼情況下應該主動驅逐而不是等 TTL 過期。 數字感：1M token context 每小時值多少錢？32K token 閾值的意義是什麼？Break-even 點在哪裡？面試官期待聽到具體數字，不是模糊的「可以節省很多」。 弱答案長這樣： 「我會用 Vertex AI Context Cache 減少 token 費用，設定 TTL 讓它自動過期就好。」這個答案暴露了兩個問題：不知道 TTL 最長 24 小時（閒置快取繼續燒錢），也不知道應該主動驅逐而非被動等待。 強答案長這樣： 「Context Cache 按小時計費，閒置用戶繼續計費是主要陷阱。我會用 Redis sliding window 判斷活躍度——超過 32K token 且每 10 分鐘 >5 次請求才升級到 L2 快取；閒置 15 分鐘後，觸發 Gemini Flash 非同步壓縮，把 1M token 壓縮到 1K 存入 Firestore，再呼叫 CachedContent.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/redis-sentinel-high-availability-setup-guide/Mon, 29 Sep 2025 07:54:22 +0800https://yennj12.js.org/yennj12_blog_V4/posts/redis-sentinel-high-availability-setup-guide/🎯 Introduction Redis Sentinel provides high availability and monitoring for Redis deployments. It’s a distributed system that monitors Redis master and replica instances, performs automatic failover, and acts as a configuration provider for clients. This comprehensive guide covers Redis Sentinel architecture, setup procedures, Java integration, and production best practices. Redis Sentinel solves critical production challenges including automatic failover, service discovery, and configuration management, making it essential for mission-critical applications that require high availability and minimal downtime.