https://yennj12.js.org/yennj12_blog_V4/tags/eviction-policy/Recent content in Eviction Policy on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part51-kv-cache-memory-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part51-kv-cache-memory-zh/大多數工程師的做法：把 KV Cache 設一個固定 TTL，讓它自動過期，再出問題就加更多 GPU。 資深 FDE 的思維：把快取當分層財務決策——什麼時候該升層、什麼時候該壓縮、什麼時候主動驅逐， 每一個決策節點都有精確的數字閾值，而不是「看狀況再說」。 差距不在技術知識，在於你能不能把顯存、計費週期、對話語義三個維度同時管住。 面試情境 你的 B2B 對話式 AI 平台服務 5 萬名企業用戶，平均每位用戶每天與 Agent 進行 20–40 輪對話。 隨著上下文長度增長，GPU 顯存使用率持續攀升，高峰期 OOM（Out of Memory）崩潰率達到 3%， 同時 Vertex AI 帳單每月 $120K，CFO 要求兩個月內把成本降低 50%。 你被要求在不降低對話品質的前提下，重新設計快取架構。你的方案是什麼？ 一、核心問題：為什麼 KV Cache 管理會讓 B2B SaaS 崩潰 1.1 KV Cache 的本質與代價 大型語言模型在推理時，Attention 機制需要存取所有歷史 Token 的 Key/Value 向量。每一輪新對話都要「看過」所有先前的 Token，這個快取（KV Cache）讓模型不需要重新計算，代價是它活在 GPU 顯存（VRAM）裡。 以 Gemini 1.5 Pro 為例： 每 1K tokens 的 KV Cache 佔用約 0.