https://yennj12.js.org/yennj12_blog_V4/tags/kv-cache/Recent content in KV Cache on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 15:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/Sun, 21 Jun 2026 15:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/大多數人覺得 Transformer 就是「注意力機制加上前饋網路」，說完就結束了。 真正的工程師知道：矩陣分塊如何影響 GPU 記憶體帶寬，KV Cache 如何讓首 token 延遲從 8s 降到 400ms， 為什麼 GQA 能在保持 95% 品質的前提下省掉 75% 的快取記憶體。 架構不是魔法——它是一系列在硬體限制下做出的工程取捨。 面試情境：「你負責將一個 7B 參數的 LLM 部署到生產環境，P99 首 token 延遲必須 < 500ms，批次吞吐量 > 200 req/s，GPU 記憶體預算 40GB。請說明你會在 Transformer 架構層面做哪些優化決策，以及你如何取捨精度與速度。」 一、核心問題：為什麼 Transformer 取代了一切 1.1 RNN/LSTM 的根本瓶頸 在 Transformer 出現之前，序列模型靠 RNN 與 LSTM。它們有一個無法繞開的硬傷：序列依賴（sequential dependency）。 時間步 t=1 → t=2 → t=3 → ... → t=n 每步必須等上一步完成，無法並行 後果： 訓練速度隨序列長度線性增長 梯度消失導致長距依賴難以學習 GPU 大量計算資源閒置（利用率 < 30%） 1.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part15-scale-cache-zh/Wed, 03 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part15-scale-cache-zh/把 Agent 從 1 個用戶擴展到 10 萬個用戶， 傳統 Web 的直覺在這裡會讓你踩坑。 LLM 系統的瓶頸不在 CPU，而在 token 計算成本 和 推理延遲。 一、核心問題：LLM 系統的規模化為什麼不一樣 傳統 Web 服務的規模化直覺： 流量增加 → 多加幾台 server → 問題解決 成本模型：主要是 infra 成本，基本線性 LLM 系統的規模化現實： 流量增加 → 每個請求都要花錢叫 LLM API 成本模型：token 按量計費，和傳統 infra 的成本結構完全不同 10K req/day × avg 3,000 tokens × $0.002/1K tokens = $60/day = $1,800/month 100K req/day = $18,000/month 1M req/day = $180,000/month ← 沒有 cache，就是這個數字 三個讓 LLM 系統難以規模化的特性：https://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.