概念位置

GQA 是 multi-head attention 的推論友善變體。MHA 是每個 query head 都有自己的 K/V；MQA 是所有 query head 共用一組 K/V；GQA 則把 query head 分組，每組共用 K/V。

可觀察訊號與例子

在 model config 裡看到 num_attention_heads: 32、num_key_value_heads: 8，代表 32 個 Q head 共用 8 組 K/V head，group size 是 4。這會讓 KV cache 約縮到 MHA 的四分之一，長 context 與高併發更友善。

設計責任

選模型或估算 serving 成本時，要看 num_key_value_heads，而不是只看總參數。GQA 對本地推論特別重要，因為 context window 與併發數常被 KV cache 卡住。

概念位置

Prefix Cache 在推論流程中的角色：

1傳統推論：
2  Request A：system prompt + user A → 完整 prefill → 生成
3  Request B：system prompt + user B → 完整 prefill → 生成
4                                       ↑ 重複算 system prompt
5
6開啟 Prefix Cache：
7  Request A：system prompt + user A → prefill 整段、cache 共用 prefix
8  Request B：system prompt + user B → 重用 cache 的 system prefix + 只 prefill user B → 生成
9                                       ↑ 省下 system prompt 的 prefill 算力

效益對應的場景：

主流推論引擎的支援度（依版本變化）：vLLM、SGLang、llama.cpp 等都有 prefix cache 機制、命名各異。

事實查核註：prefix cache 的命名、設定方式、tenant 隔離預設行為依推論引擎跟版本差異大、引用前以對應引擎的官方文件為準（如 vLLM Automatic Prefix Caching、SGLang RadixAttention 等）。

設計責任

理解 prefix cache 後可以解釋兩個現象：為什麼 production LLM 服務的 latency 在啟用 prefix cache 後大幅下降（system prompt 不再每次重算）、為什麼 prefix cache 在多租戶場景是隱私風險（A 租戶的 prefix 可能被 B 看到、見 llm-multi-tenant-isolation）。

production 設計時、prefix cache 應該按 tenant 分桶、同 tenant 內可共用、跨 tenant 必須隔離。隔離邊界對齊 tenant-boundary 卡片的設計。

讀完本章後、你應該能對自己的工作流回答：KV cache 量化的好處能換到什麼、品質代價落在什麼範圍、K 跟 V 為什麼建議不同等級、跟 context 長度跟併發數怎麼搭配。

本章目標

1. 理解 KV cache 為什麼會隨 context 線性膨脹、為什麼 PC 場景常需要量化。
2. 區分 K 跟 V 在 attention 計算中的角色、解釋為何兩者對量化的容忍度不同。
3. 判讀「該不該量化 KV cache」的工作流類型。
4. 認識 llama.cpp 的 --cache-type-k / --cache-type-v 旗標與相關限制（如 flash attention 要求）。
5. 知道調參時的觀察訊號跟取捨方向。

KV cache 為什麼會膨脹

LLM 推論時、每處理一個 token 都會把該 token 的 key 跟 value 向量算出來、暫存進 KV cache、供後續 token 的 attention 計算複用（不重算）。KV cache 的體積跟下面幾個變數線性相關：

1KV cache 體積 ≈ 2 × n_layers × n_heads × head_dim × bytes_per_value × context_長度 × batch

• 2：分別是 K cache 跟 V cache
• n_layers / n_heads / head_dim：模型結構參數
• bytes_per_value：fp16 是 2 bytes、Q8_0 約 1 byte、Q4_0 約 0.5 byte
• context_長度：context 開多大、KV cache 就放多大
• batch：併發處理多少 sequence

實際 KV cache 體積依模型 attention 變體（MHA / GQA / MLA）、head 數設計、量化方式而變。比起背公式、更實用的做法是看 llama.cpp 啟動時的 log、它會列出實際 KV cache 配置的記憶體：

1llm_load_print_meta: n_layer    = 48
2llm_load_print_meta: n_head     = 32
3llama_kv_cache_init: KV self size = 2048.00 MiB, K (q8_0): 1024.00 MiB, V (q8_0): 1024.00 MiB

事實查核註：上面的 log 格式跟欄位名稱依 llama.cpp 版本變動、實際輸出以執行時為準。常見模型的 KV cache 估算工具可參考 llama.cpp 官方文件 或社群維護的 calculator。

K 跟 V 為什麼適合用不同量化等級

K 跟 V 在 attention 計算中扮演不同角色、對量化的容忍度也不同。K 參與內積比較（量化容忍度通常較高）、V 是被加權平均的輸出內容（量化誤差會線性累積）、社群常見做法是 K 用較激進的量化、V 保留較高精度。

attention 的計算流程簡化為：

1attention(Q, K, V) = softmax(Q · K^T / √d) · V

K 跟 V 在這個流程中的角色差異：

1. K（key）：用來跟 Q 算內積、產生 attention score。內積本質是「相對量級的比較」、量化造成的微小誤差容易在 softmax 後被吸收。
2. V（value）：是被 softmax 加權平均後直接輸出的內容、量化誤差會線性累積進輸出。

社群多數回報指出：

• K 用 Q8_0 或 Q4_0 對品質影響相對小：因為 softmax 對輸入量級的敏感度集中在最大值附近、其他位置的小幅誤差會被指數壓縮。
• V 用 Q4_0 在長 context 末尾較易出現品質下降：因為 V 是被加權平均的內容、累積誤差會在輸出中可見。

事實查核註：K 跟 V 對量化敏感度不同的論述、來自社群常見回報跟若干針對 KV cache 量化的論文（如 KIVI、KVQuant 等）。具體影響因模型架構、量化方法（symmetric / asymmetric、per-head / per-channel scale 等）變化、不同模型的表現可能不一致；建議用自己工作流的任務跟自己選定的量化版本實測校準。

KV cache 量化等級對照

llama.cpp 支援的常見 KV cache 量化等級：

常見組合（社群回報、需自行校準）：

• 保守（品質優先）：K=fp16、V=fp16。完全不量化、VRAM 用量最大。
• 平衡起點：K=Q8_0、V=Q8_0。體積約一半、品質衰減社群多數回報為小幅或不明顯。
• 激進（context 優先）：K=Q8_0、V=Q4_0。體積約 fp16 的 35%、社群回報短 prompt 影響小、長 prompt 末尾可能出現品質下降。
• 極限：K=Q4_0、V=Q4_0。體積約 fp16 的 25%、用於開超大 context 或極高併發、品質風險最高。

何時值得量化、何時不該量化

KV cache 量化的主要用途是「VRAM 不足以同時放下模型權重 + 目標 context 長度 + 目標併發數」的場景。當 VRAM 已有充裕餘量、量化省下的 VRAM 沒有對應的用途時、保留 fp16 通常較合適。下表整理常見的判讀情境：

判讀原則：先確認瓶頸是「VRAM 不夠」還是「品質不夠」。前者量化是解法、後者量化通常會惡化問題。

跟 context 長度、併發數的協調

KV cache 量化的好處要跟其他 VRAM 用量一起評估。常見的取捨方向：

1. 量化 → 開更大 context：把省下的 VRAM 用在加大 -c、能開長 prompt（如 RAG、長對話、跨檔案分析）。
2. 量化 → 加併發：把省下的 VRAM 用在加 --parallel、能同時服務多個 client（如多個編輯器視窗、多 agent）。
3. 量化 → 載入更大模型：把省下的 VRAM 用在降 --n-cpu-moe、減少卸載、提升生字速度。

三者通常不能同時極大化、需要依工作流挑主軸。

實務上的常見搭配（社群回報、需校準）：

llama.cpp 的相關旗標

跑 KV cache 量化時、常用的旗標：

flash attention 的關係

部分 KV cache 量化組合（特別是 V=Q4_0 / Q4_1）在 llama.cpp 上需要同時啟用 flash attention（-fa）才能正常運作；沒啟用時可能載入失敗或 fallback 到 fp16。具體要求依 llama.cpp 版本變化、以實際 llama-server --help 跟 llama.cpp 官方 issue / PR 為準。

事實查核註：flash attention 對 KV cache 量化組合的限制、是 llama.cpp 實作層面的演進議題、不是模型本身的限制。新版 llama.cpp 可能放寬或改變要求、引用前以最新版的 release notes 為準。

給讀者的調參步驟

實際設定 KV cache 量化時、可以照下面的步驟調：

1. 先用 fp16 基準跑一次：用實際工作流的代表性任務、記錄補完品質、執行時間、VRAM 用量。這是後續比較的基準。
2. 切到 K=Q8 / V=Q8：跑同樣的任務、比較品質。社群多數回報差異不明顯、但需以自己工作流確認。
3. 進一步切到 V=Q4：再跑同樣任務、特別注意長 prompt 末尾、推理鏈、複雜邏輯任務的輸出品質。
4. 若品質可接受、評估省下的 VRAM 怎麼用：加大 -c、提高 --parallel、或減少 --n-cpu-moe。
5. 建立可重複的校準腳本：把代表性任務寫成 prompt 集、做為日後升級模型或調參時的回歸測試。

下一章

下一章：5.3 llama.cpp 在 PC 上、把本章跟 5.1 MoE 卸載 的旗標放進完整的 llama.cpp 調參工作流。

本章寫作邊界

本章聚焦 production LLM 推論的多租戶 isolation 特殊性。team / 個人 dev 場景的「多人共用本地 server」見 llm/6.5 跨進 production 的 routing 中樞；通用 IAM / 服務間信任邊界見 7.2。

本章 threat scope

In-scope：KV cache 跨租戶洩漏、prompt log 隔離、模型 artifact 訪問權、batch 推論的順序敏感性、tenant-scoped rate limit、共用 GPU 上的記憶體殘留。

Out-of-scope（路由到他章）：

• 通用 IAM / 服務間信任 → 7.2 identity-access-boundary
• workload identity → 7.7 workload-identity-and-federated-trust
• log / PII 治理 → llm-log-and-pii-governance
• model artifact 供應鏈 → llm-deployment-supply-chain
• 入口治理 → 7.3 entrypoint-and-server-protection

從本章到實作

• Mechanism：問題節點表 → knowledge-card → 看具體機制。
• Delivery：交接路由 → 05-deployment-platform / 06-reliability / 08-incident-response。

LLM 多租戶隔離的三個 LLM-specific 層

跟一般 service 的多租戶隔離（compute / network / data）相比、LLM 推論服務多了三個層次：

1. KV cache 層：KV cache 是推論時的 attention 暫存、跨 request 可能重用（prefix cache、shared prefix optimization）；跨租戶共用 cache 是直接的資料洩漏面。
2. prompt log 層：production LLM 服務通常會 log prompt + response 用於 debug / billing / abuse detection；log 的隔離與保留期限直接影響跨租戶洩漏風險。
3. model artifact 訪問權：production 可能部署多個 fine-tuned 模型（如 customer-specific 模型）、模型本身是 sensitive artifact、訪問權要對齊 IAM。

分析模型

production LLM 推論的多租戶隔離依四個層次分析：

1. memory 層：GPU VRAM、CPU RAM 中的 KV cache 跟模型權重、跨 request / 跨租戶的殘留與共享邊界。
2. storage 層：模型 artifact、prompt log、context cache 在儲存層的隔離。
3. identity 層：tenant identity 怎麼帶到 inference call、rate limit / quota 怎麼按租戶分。
4. observability 層：metric / log / trace 中的 tenant tag、跨租戶分析的允許範圍。

判讀流程

判讀流程的責任是把「能服務多個租戶的 LLM 服務」轉成「租戶間資料不互相洩漏的 LLM 服務」。

1. 先確認 tenant identity 從 API gateway 到 inference call 的傳遞路徑。
2. 再確認 KV cache、prompt log、model artifact 各自的隔離邊界。
3. 接著確認 GPU 記憶體中的跨 request 殘留是否清理。
4. 最後交接到偵測流程、確認跨租戶異常能被識別。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM 多租戶 isolation 已進入高壓狀態。

• KV cache 共用範圍跨越 tenant 邊界時、代表記憶體層 isolation 失效。
• prompt log 沒帶 tenant tag、或 tag 後仍可跨 tenant 查時、代表 log 層 isolation 不足。
• 模型 artifact 訪問權跟 IAM 解耦時、代表 identity 層 isolation 不足。
• 推論 batch 對 tenant boundary 不敏感時、代表 batch 層的 noisy-neighbor 風險上升。

LLM 場景的特殊判讀

LLM 多租戶 isolation 相對一般 multi-tenant 服務的特殊性：

1. KV cache 是有用但敏感的優化：shared prefix cache（如多 tenant 用同一 system prompt）能省大量 prefill 算力、但跨 tenant 共用就是洩漏。判讀：可以 share 同 tenant 內的 prefix、不能 share 跨 tenant。
2. prompt log 含豐富使用者意圖：相比一般 API log 主要記 endpoint / status code、LLM prompt log 記的是「使用者實際在問什麼」、隱私敏感度高得多。
3. GPU 是稀缺資源、共用比 CPU 多：production LLM 服務常多 tenant 共用同卡、isolation 比一般 multi-tenant 服務（每 tenant 跑獨立 pod）更難做、需要更細的 batch 跟 memory 管理。
4. fine-tuned 模型本身是 customer asset：模型訓練成本高、權重是客戶 IP、訪問權混亂直接是 IP 外洩。
5. 「LLM 記住 cross-tenant 資訊」的疑慮：使用者常擔心 LLM 把 A tenant 的 prompt「記住」洩漏給 B tenant；對 inference-only 服務（無 fine-tune）這不發生（模型權重 immutable）、有 fine-tune 時要看 training data 隔離。

案例觸發參考

LLM 多租戶 isolation 的公開案例累積中、本章先沿用通用 multi-tenant 案例：

• 一般 multi-tenant 隔離案例見 7.2 身分授權邊界。
• LLM-specific 案例累積後會補入 red-team/cases/llm-multi-tenant/。

事實查核註：LLM 多租戶 isolation 的公開事件案例還在早期、社群上有些「LLM A 的 system prompt 被 B 看到」等報告、多數屬 prompt injection 範疇而非 cache 洩漏。建議引用前以最新的 OWASP LLM Top 10 跟具體 vendor 的 incident 公告為準。

引用標準

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 身份授權邊界：7.2 identity-access-boundary
• log 治理：llm-log-and-pii-governance
• agent prompt injection 後果：llm-prompt-injection-in-agent
• 部署平台：05-deployment-platform
• 可靠性：06-reliability