<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CostOptimization on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/costoptimization/</link><description>Recent content in CostOptimization on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/costoptimization/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE core topic - Context Cache Eviction：硬體級上下文快取驅逐策略與計費陷阱</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-17-context-caching-eviction-zh/</link><pubDate>Mon, 08 Jun 2026 10:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-17-context-caching-eviction-zh/</guid><description>核心定義：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 分鐘 &amp;gt;5 次請求才升級到 L2 快取；閒置 15 分鐘後，觸發 Gemini Flash 非同步壓縮，把 1M token 壓縮到 1K 存入 Firestore，再呼叫 CachedContent.</description></item><item><title>FDE core topic - Semantic Model Routing：置信度熵值驅動的智能模型分流</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-18-semantic-model-routing-zh/</link><pubDate>Mon, 08 Jun 2026 10:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-18-semantic-model-routing-zh/</guid><description>核心定義：Semantic Model Routing 不是事前分類查詢，而是在生成過程中即時讀取 logprobs 熵值，一旦本地模型表現出高不確定性就立刻中斷並升級至雲端，用最低成本完成每一個請求。
一、為什麼面試官問這個 面試官問 Model Routing 時，真正想測試的是三件事：
成本意識：你是否理解「全送雲端」和「全跑本地」都是錯誤極端，能否量化混合策略的 blended cost，並在面試現場即席算出數字。 信號工程：你是否知道從哪裡取得可靠的路由信號，而不是直覺性地「加一個分類器」——那個分類器本身就帶來額外延遲和誤差。 隱私架構：在決定路由之前，你是否先問「這個請求能不能出境？」這個問題的順序比路由演算法本身更重要。 弱答案長什麼樣
「我會訓練一個路由分類器，根據查詢長度和關鍵字複雜度決定用大模型還是小模型。」
這個答案的問題：沒有具體信號來源、沒有量化閾值、分類器本身的誤差率和延遲完全未提、隱私保護缺席、沒有任何成本數字。面試官會認為你沒有生產經驗，只有理論印象。
強答案長什麼樣
「我從 vLLM logprobs 抽取前 10 個 token 的 Shannon 熵值，H &amp;lt; 1.5 本地結束，H &amp;gt; 2.5 立刻 TCP RST 中斷本地串流並升級 Vertex AI。PII 偵測在熵值路由之前執行，命中則強制留在 on-premise，數據絕不出境。75% 本地處理的混合成本約 $0.00388/query，比全雲端 $0.015 節省 74%，這個數字我是用加權平均即席算出的。」
這個回答展示了信號來源、具體閾值、隱私保護順序、生產層面的成本計算，面試官會繼續深挖細節，而不是換題。
二、核心原理與技術深度 2.1 為什麼不用預分類器 最直覺的做法：訓練一個二元分類器（simple / complex），根據分類結果決定呼叫哪個模型。這個方案看起來合理，但有四個結構性問題：
問題一：額外 RTT 不可避免。 分類器是一次獨立推理，即使是輕量 BERT 也需要 20–80 ms。對話場景的 P50 延遲目標通常 &amp;lt; 500ms，20–80ms 已是 4–16% 的預算。</description></item></channel></rss>