只要你跑過本地 LLM，一定遇過這個情況：
「模型還沒開始聊天，VRAM 就快爆了。」
甚至：
- 13B 模型一載入就 OOM
- context 一拉長，顯示卡直接掛
- GPU 核心明明沒跑滿，記憶體卻滿了
這不是你用錯，而是 LLM 的設計本質，就非常吃記憶體。
這篇文章會帶你搞懂：
👉 LLM 的 VRAM 到底被誰吃掉？為什麼省不下來？
先給結論（一句話版）
LLM 吃顯示卡記憶體，不是因為「算得快」，
而是因為「要同時記住太多東西」。
一個關鍵觀念：LLM ≠ 傳統程式
傳統程式：
- 資料進來
- 算完
- 丟掉中間結果
LLM 完全不是這樣。
👉 LLM 在推論時，必須「一路記住過去的內容」，才能接著講下去。
LLM 在 VRAM 裡到底放了什麼？
LLM 的 VRAM 消耗，至少來自 四大類。
① 模型權重（Weights）—— 最大宗
這是什麼？
- 神經網路裡所有的參數
- 每一層的矩陣、向量
為什麼這麼大？
- 7B = 70 億參數
- 13B = 130 億參數
假設：
- FP16（2 bytes）
那光是權重就要：
- 7B ≈ 14 GB
- 13B ≈ 26 GB
📌 權重是「固定成本」，一載入就要全付。
② KV Cache —— 吃記憶體的隱形殺手
KV Cache 是什麼？
- Attention 機制要用到的
- Key / Value 的歷史紀錄
👉 每產生一個 token，就要存一次。
為什麼 KV Cache 很可怕？
KV Cache 的大小跟三件事成正比：
- 模型層數
- 隱藏維度（hidden size）
- Context length（token 數）
📌 這代表：
- context 從 2k → 8k
- KV Cache 不是 4 倍，是「線性堆高」
👉 這就是為什麼「聊越久，越容易爆 VRAM」。
③ 中間計算結果（Activations）
在推論過程中：
- 每一層都會產生中間結果
- 雖然比訓練少
- 但在 forward pass 時仍然存在
📌 這些 activations 也是 VRAM 的即時消耗。
④ Framework / Runtime Buffer（常被忽略）
即使模型很小，你仍然會看到：
- CUDA buffer
- Metal buffer
- Runtime workspace
- Kernel 暫存區
👉 這些是：
- PyTorch
- llama.cpp
- MLX
- TensorRT
運作時 一定會保留的空間。
為什麼「推論」也這麼吃記憶體？
很多人會問：
「不是只有訓練才吃記憶體嗎？」
事實是：
- 訓練：
- 權重
- Activations
- Gradients
- Optimizer state
- 推論：
- 權重
- KV Cache
- Activations
👉 雖然少了 gradient，但 KV Cache 補了上來。
Context length 為什麼是 VRAM 殺手？
因為：
- 每一個 token
- 在每一層
- 都會留下 Key / Value
📌 所以：
- 模型不變
- token 越多
- 記憶體一定線性上升
👉 沒有魔法可以免費增加 context。
那量化（Quantization）幫助多大？
量化能：
- 大幅減少 權重大小
- 例如 16-bit → 8-bit / 4-bit
但請注意：
- KV Cache 通常還是 FP16
- Activations 也未必能量化
- 長 context 仍然會吃爆 VRAM
👉 量化解的是「載得進來」，不是「永遠不會爆」。
為什麼 GPU 核心看起來很閒？
因為在推論時：
- token 是一個一個生成
- Attention 需要等資料
- 記憶體頻寬常是瓶頸
👉 GPU 在等記憶體，不是在狂算。
一句話總結（請直接記）
LLM 吃 VRAM，
是因為它同時要記住：
模型本身 + 你講過的所有話。
實務上的重要結論
- VRAM 是本地 LLM 的地板
- 核心數影響的是「快不快」，不是「能不能跑」
- Context length 比你想像中更貴
- 長時間聊天 ≈ 記憶體累積炸彈
最後結論
LLM 的顯示卡記憶體消耗，
來自「設計本質」，不是實作失誤。
如果你理解這一點，你就會知道：
- 為什麼 24GB 比 12GB 好用太多
- 為什麼 context 一拉就 OOM
- 為什麼本地 LLM 的硬體選型，永遠先看 VRAM