https://yennj12.js.org/yennj12_blog_V4/tags/vertexai/Recent content in VertexAI on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00: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/fde-interview-guide-part44-hybrid-context-rag-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part44-hybrid-context-rag-zh/大多數工程師看到 200 萬 Token 的 Context Window，第一反應是：「RAG 已死，直接塞文件就好。」 正確答案是：長文本是一把昂貴的瑞士刀，不是所有任務都值得用它。 優秀的 FDE 設計的不是「選長文本還是 RAG」， 而是一個能在 Runtime 動態決策的混合路由器，把 80% 的查詢成本降低 2500 倍。 面試情境 你的客戶是一家擁有 50,000 名財務分析師的大型投資銀行。他們剛取得了 Gemini 的 200 萬 Token Context Window 存取權，興奮地計劃把整年的財務報表（約 100 萬 Token/份）直接塞給 LLM。當系統上線第一週，並發查詢量衝到 50,000 QPS，P99 延遲爆到 35 秒，TPU Cluster 飽和，成本在 72 小時內燒掉了月度預算。你被緊急召入，如何設計一個「動態混合路由器（Dynamic Hybrid Router）」來同時解決成本、延遲和吞吐量三個問題？ 一、核心問題：為什麼 200 萬 Token 不是銀彈 1.1 長文本的物理限制 200 萬 Token 的 Context Window 是工程奇蹟，但它的成本結構決定了它無法成為通用方案。 關鍵成本不對稱性： 1M Token 長文本請求（Gemini Pro）： 輸入成本：$2.50 / 1M tokens 每次請求輸入：1,000,000 tokens 單次請求成本：$2.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part47-edge-model-routing-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part47-edge-model-routing-zh/大多數團隊的做法：讓小模型先回答，覺得不好再丟給大模型——結果是雙倍延遲加雙倍成本。 正確的做法：在小模型生成第 10 個 Token 的那一刻，就已經知道要不要升級了。 路由的決策點不在答案完成之後， 而在答案開始生成的前幾個 Token 之間。 面試情境 面試官：「一個金融科技客戶，為了隱私合規，90% 的查詢必須留在地端私有伺服器處理。他們在地端部署了 Gemma-2-9b，雲端備用 Gemini Pro。但目前的架構是：小模型先跑完整回答，人工審核覺得不好才重送到雲端，導致平均延遲高達 6.8 秒。你如何重新設計路由機制，讓延遲降到 3.6 秒以下，同時確保敏感 PII 資料絕不離開地端？」 一、核心問題：為什麼「先跑再判斷」的架構從根本上就錯了 傳統雙軌架構的根本缺陷： ┌─────────────────────────────────────────────────────────────┐ │ 用戶 Prompt → 地端小模型（完整推理 3.5s） │ │ ↓ │ │ 品質評估（人工或 LLM 評分 0.5s） │ │ ↓ │ │ [品質不足] → 雲端大模型（完整推理 2.8s） │ │ │ │ 最壞情況延遲 = 3.5 + 0.5 + 2.8 = 6.8 秒 │ │ 最壞情況成本 = 地端 + 評分 LLM + 雲端大模型（三份費用） │ └─────────────────────────────────────────────────────────────┘ 為什麼這個架構在生產環境中必然崩潰： 問題 1：確定性延遲疊加 └── 任何需要升級的查詢都承受 100% 的雙倍延遲，沒有優化空間。 金融客服場景中，約 35% 的查詢需要升級 → 平均延遲被拉高 2.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/大多數工程師的直覺：「索引過期了？重新跑一次 Re-indexing 就好。」 資深 FDE 的直覺：「Re-indexing 要數小時，這期間服務怎麼辦？Re-indexing 之後 HNSW 圖會不會因此失衡？」 大多數工程師的直覺：「那就頻繁做增量更新，隨時保持最新。」 資深 FDE 的直覺：「增量更新累積到一定程度，Graph Drift 會讓 RECALL@10 從 95% 跌到 70%，這才是真正的定時炸彈。」 面試情境 面試官：「你們的企業客戶每天會在 GCS 上新增、修改、刪除數千份 PDF 文件。你們的 AI Agent 需要即時查詢這些知識庫，但現在常常給出已被刪除或過期的內容，讓客戶非常不滿。我知道 Vertex AI Vector Search 支援增量更新，但我聽說大規模頻繁更新會造成 HNSW 圖退化，進而影響搜尋精準度。請告訴我，你會如何設計一套既能即時響應文件變更、又能長期維持向量索引健康度的自動化管線？在系統規模達到百萬向量時，你的設計會有哪些具體調整？」 一、核心問題：為什麼向量索引的「即時性」與「精準度」天生對立？ 1.1 RAG 系統的資料新鮮度危機 在企業 RAG（Retrieval-Augmented Generation）場景中，知識庫並非靜態的。法規文件每週更新、產品手冊每月改版、內部 SOP 隨業務調整。當 AI Agent 仰賴向量檢索來回答問題時，索引延遲（Index Lag）直接等同於「AI 在說謊」。 典型的痛點數字： 文件刪除後，向量索引平均滯後 4–8 小時才能同步 在此期間，Agent 回答基於已廢棄文件的機率高達 23% 企業客戶每月因 AI 給出過期資訊而提交的客訴工單：平均 340 件 1.2 三重矛盾的根本原因 矛盾一：即時性 vs. 批次效率 ┌────────────────────────────────────────────┐ │ 即時更新：每次文件變更立即寫入向量索引 │ │ 優點：延遲 < 30 秒 │ │ 缺點：HNSW 圖節點連結逐漸失衡（Graph Drift）│ │ 每 10K 次增量更新後，RECALL@10 下降約 8%│ └────────────────────────────────────────────┘ 矛盾二：完整重建 vs.