【2026 最新】Granite 4.2 8B 本機教學：5.3GB 為何吃到 27GB？Context、KV Cache 與 Runtime 拆解

Granite 4.2 8B 本機部署最近出現一個很反直覺的案例：Ollama 頁面明明顯示模型約 5.3GB，一位使用 RTX 5060 Ti 16GB 的讀者卻看到載入需求膨脹到約 27GB。這不是「5.3GB 解壓成 27GB」那麼簡單，也不是每台電腦都會固定吃掉 27GB；真正要看的，是權重之外又分配了多少 Context、KV Cache、運算緩衝與平行請求空間。

這篇教學會先建立一個可以自己重算的記憶體帳本，再用 Ollama 與 LM Studio 的版本、Context 與 KV Cache 設定做 A/B Test。你最後會知道：為什麼 128K 是能力上限而不是免費配額、3B 與 8B 應該怎麼選，以及 8GB／16GB／24GB 顯卡該從哪一組設定起跑。

先記住這條式子：模型檔案大小不等於執行記憶體

先把整篇文章濃縮成一條式子：

載入記憶體 ≈ 模型權重 + KV Cache + Runtime／運算緩衝 + 系統餘量

模型權重是你下載的主要檔案。Ollama 的官方 Granite 4.2 頁面目前列出 3B 約 2.2GB、8B 約 5.3GB、30B 約 18GB；其中 8B tag 的詳細頁標示為 Q4_K_M、8.79B。量化把權重從 BF16／FP16 壓成較少位元，所以 8B 參數模型不需要以原始精度常駐，但它沒有順手把所有其他記憶體也變小。

KV Cache是模型為已讀 token 保存的注意力中間結果。它讓下一個 token 不必重算整段對話，代價是 Context 越長、同時處理的對話越多，Cache 就越大。這也是本文最重要的變數。

Runtime／運算緩衝包含推論引擎、計算圖、batch、工作區與不同後端需要的暫存。最後還要替作業系統、桌面、其他程式與記憶體碎片留餘量。統一記憶體的 Apple Silicon 會由 CPU 與 GPU 共用同一池；獨立顯卡則要分開看系統 RAM 與 VRAM，因此兩台機器顯示的「總記憶體」不能直接互比。若想先補齊通用概念，可以搭配 本機 LLM 顯存選擇指南 與 GGUF 量化完整教學。

Granite 4.2 8B 本機的 KV Cache 到底多大？

IBM 的 Granite 4.2 8B 官方模型卡列出這組關鍵結構：40 層、32 個 attention heads、8 個 KV heads、每個 head 128 維，原始推論精度是 bfloat16，原生 Context 上限為 131,072 tokens。用標準 dense KV Cache 帳本，可以寫成：

KV bytes
= tokens × layers × 2（K 與 V）× KV heads × head dimension × 每元素 bytes

Granite 4.2 8B、F16/BF16 KV：
= tokens × 40 × 2 × 8 × 128 × 2 bytes
= 每 token 163,840 bytes（160 KiB）

代入 4K、32K 與 128K，得到的不是某個 Runtime 在特定裝置跑出的數值，而是由公開架構推導、單一序列的密集 KV 理論量：F16／BF16 KV 約為 0.625GiB、5GiB、20GiB。若 Runtime 確實使用 q8_0 KV，Ollama 文件說它約為 f16 的一半；實際仍會有量化區塊與對齊差異，所以比較適合把它視為預算級估算，而不是保證值。

現在就能解開「5.3GB 為何可能接近 27GB」：原始回報截圖中的 ollama ps 明列 CONTEXT 131072；參與修正的 Ollama repo contributor 也在後續 issue 確認，當時發布的模型 manifest 帶有 model-level num_ctx。IBM 帳號目前的 8B tag 也仍明列 num_ctx: 131072。這份 Q4_K_M 權重的精確檔案約 4.98GiB；完整 128K F16 KV 正好 20GiB，兩者下限相加約 24.98GiB，也就是 26.82GB 十進位，尚未計入較小的 Runtime 緩衝，與畫面上的約 27GB 相符。這是架構與設定推導，並非 AlphaLab 在裝置上跑出的 benchmark。反過來說，若你明確只開 4K，KV 理論量約 0.625GiB；若仍與完整 128K 相近，才值得往版本、設定是否生效、平行度與記憶體統計口徑追查。

27GB 是永久特性嗎？先把「回報」與「已確認修正」分開

27GB 來自 2026 年 8 月 25 日的一則 r/LocalLLaMA 使用者回報：Linux、RTX 5060 Ti 16GB、Docker 內的 Ollama。截圖中的舊模型 short ID 是 efbf7a204b67，ollama ps 顯示 SIZE 27GB、CONTEXT 131072，以及 46%／54% CPU／GPU；所以 27GB 是載入總量，並非全部塞進 16GB VRAM。發文者先前曾把環境 Context 設到 250K，後來降至 10K，但 model-level 參數在當時的優先序高於環境值。這是設定明確的故障線索，不是跨平台基準，更不是每個 Granite 4.2 8B 的固定占用。

更接近可追蹤工程證據的是 Ollama 的 GitHub issue #18074。回報者記錄 Ollama 0.33.1、16GB 以下整合式 GPU，以及 Granite 3B／8B 的 131,072 Context OOM。參與修正的 repo contributor 隨後確認問題出在發布模型攜帶的 num_ctx，並示範 request-level 4096 override；在其 3B 環境中，4096 約 2.6GB、完整 Context 約 13GB。這些是該 contributor 針對事件提供的量測，不應外推成 8B 或所有硬體的數字。

2026 年 8 月 27 日，參與修正的 Ollama repo contributor 表示已重發 Ollama Library 的全部 Granite 4.2 模型，移除 PARAMETER num_ctx；重新 pull 無 namespace 的 tag，才會換掉本機舊 manifest。這不是 Ollama v0.33.2 的程式修正：該版 release notes 只列出介面、macOS app handoff 與 Claude Desktop proxy 修正，沒有 Granite Context。換句話說，更新二進位、重拉模型、切換 tag 是三件不同的事。每次比較都要記下精確版本、完整 tag／digest、實際 Context 與載入設定；這也是為什麼 本機 LLM A/B Test 教學把 Runtime 版本列為第一級變數。

名稱也不能省略：截至 2026 年 9 月 1 日，IBM 帳號的 ibm/granite4.2:8b 詳細頁明列 num_ctx: 131072；維護者重發後、無 namespace 的 granite4.2:8b 則不再列出這個參數。兩者不能只因模型名稱相似就當成同一份 manifest；A/B 記錄必須保留完整 tag。

Ollama A/B Test：把 Context 從猜測變成收據

不要一開始就挑 128K。先用 4K 建立可載入的基線，再逐步升到 32K；只有當估算與可用記憶體都允許時，才跑 128K。每輪都固定同一個模型、同一段 prompt、同一個 KV 精度、同一平行度與同一 GPU offload，避免一次改五件事。

步驟 1：記錄版本與載入狀態

ollama --version
ollama pull granite4.2:8b
ollama show --modelfile granite4.2:8b
ollama ps

Ollama 官方 FAQ 說，ollama ps 會列出模型的 SIZE 與 PROCESSOR：100% GPU、100% CPU，或 CPU／GPU 混合比例。它是判斷載入位置的第一張收據，但最好再搭配 NVIDIA 的 nvidia-smi、作業系統記憶體監視器或 Apple 的 Activity Monitor，分別記錄空載、載入完成與第一個 token 生成時的峰值。

步驟 2：明確傳入 4K，而不是相信預設值

curl http://localhost:11434/api/chat -d '{
  "model": "granite4.2:8b",
  "messages": [{"role": "user", "content": "用三點解釋 KV Cache。"}],
  "options": {"num_ctx": 4096},
  "keep_alive": -1
}'

ollama ps

Ollama 文件目前有一個需要正面處理的不一致：FAQ 寫一般預設為 4096 tokens；獨立的 Context length 頁則寫硬體感知預設，低於 24GiB VRAM 為 4K、24–48GiB 為 32K、至少 48GiB 為 256K。不要押注哪一頁代表你的版本。互動模式可以輸入 /set parameter num_ctx 4096；API 則能在 options 明確傳入 num_ctx，且 request-level 設定在這次事件對應的 v0.33.2 程式碼中優先於 model 與 environment。重啟後再用 ollama ps 的 CONTEXT 與實際記憶體增量驗證，而不是只相信 UI 或環境變數。

步驟 3：只改一個數字，重跑 32K 與 128K

• 將 num_ctx 改成 32768，先停止並重新載入模型，再記錄同三個時間點。
• 若 32K 已接近可用 RAM／VRAM 上限，就到此停止；OOM 不是必要的測試結果。
• 只有在記憶體帳本保留足夠系統餘量時，才改成 131072。不要用 16GB 顯卡硬驗一個理論 F16 KV 就約 20GiB 的設定。
• 每輪另記 prompt tokens、輸出 tokens、首 token 延遲與 tokens/s；能塞入記憶體不等於使用體驗合格。

步驟 4：記憶體不夠，再單獨測 KV 量化

OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
OLLAMA_NUM_PARALLEL=1 \
ollama serve

Ollama 文件列出的 KV 預設是 f16；q8_0 約用一半記憶體，通常品質影響很小，但實際影響仍依模型與任務而變。KV 量化需要 Flash Attention，且這是全域設定，所以正式比較時要先停止舊服務、用同一版本重啟，再重送步驟 2 那個明確含 options.num_ctx: 4096 的 API 請求；不要只靠 OLLAMA_CONTEXT_LENGTH 覆蓋可能存在的 model-level 參數。官方文件也明載所需記憶體會隨 NUM_PARALLEL × CONTEXT_LENGTH 增長。

LM Studio A/B Test：先估算，再決定要不要載入

LM Studio 的優點是 CLI 提供 --estimate-only。先用 lms ls 找到本機下載模型的 model_key，把下方的占位文字換掉；估算器會考慮 Context、GPU offload、Flash Attention 等因素，但它仍是預估，不是實際峰值。

lms ls

lms load --estimate-only <model_key> --context-length 4096 --gpu max
lms load --estimate-only <model_key> --context-length 32768 --gpu max
lms load --estimate-only <model_key> --context-length 131072 --gpu max

選出安全設定後，再真正載入：

lms load <model_key> --context-length 4096 --gpu max --identifier granite-42-8b
lms ps

若要把設定做成機器可核對的收據，LM Studio 的 REST API 可在 POST /api/v1/models/load 傳入 context_length、flash_attention 與 offload_kv_cache_to_gpu，並以 echo_load_config: true 回傳最後實際採用的載入設定。後兩個欄位只對 LM Studio 的 llama.cpp-based 引擎生效，不能直接套到 MLX。這比只截一張記憶體監視器更有診斷價值：一張圖告訴你「用了多少」，load config 告訴你「為什麼這樣用」。

Granite 4.2 3B 還是 8B？不要只比下載大小

IBM 模型卡顯示，3B 與 8B 都是 40 層、8 個 KV heads；差別在 hidden size 與 head size：3B 的 head dimension 是 64，8B 是 128。因此在相同 tokens 與 F16／BF16 KV 下，3B 的理論 KV 正好約為 8B 的一半：每 token 約 80KiB，完整 128K 約 10GiB。再加上 Ollama 預設量化權重約 2.2GB 對 5.3GB，3B 的容量優勢不只出現在下載時間。

但模型選擇不能只靠 IBM 自家 benchmark。你真正要跑的是自己的三組收據：

1. 聊天：準備 10 個會用到繁體中文、長指令與格式限制的問題，匿名交換 3B／8B 答案，記錄遵循率、錯誤與偏好。
2. RAG：固定同一批文件、切塊、檢索結果與 prompt，檢查答案是否引用正確段落、是否把文件外資訊混進來。RAG 不熟可以先讀 RAG 新手完整解說。
3. Tool Calling：提供固定 JSON schema，測試是否選對工具、參數是否通過驗證、失敗後能否修正。若要把模型接進完整代理流程，可延伸到 AI Agent Harness 實作教學。

每題同時記錄成功／失敗、首 token 延遲、生成速度與峰值記憶體。若 3B 已通過你的任務門檻，它省下的記憶體可以換成更長 Context、更多 RAG 文件或更穩定的系統餘量；若工具參數、長指令或複雜推理常失敗，才升到 8B。這比問「哪個 benchmark 比較高」更接近部署決策。

Granite 4.2 8B 本機：8GB／16GB／24GB 顯卡起跑決策樹

8GB：先選 3B，從 4K 開始

3B 預設量化權重約 2.2GB，4K F16 KV 理論上約 0.3125GiB，較能替 Runtime 與系統留下空間。8B 的 5.3GB 檔案看似能塞，但載入後還要容納 KV 與緩衝；若顯卡同時負責桌面，餘量更緊。8GB 應先把「穩定完成任務」當目標，不要把 128K 標示當預設。

16GB：8B Q4 從 4K／8K 起跑，再看任務加長

這是一組保守的 8B 起跑設定，但不是「5.3GB 所以隨便開」的許可。先固定單一請求、4K Context，確認模型與 KV 都放在哪裡；再升 8K、16K。若長文件是主力需求，3B 加較長 Context 有時比 8B 加短 Context 更符合工作流，應用前一節的 RAG／工具呼叫題庫決勝。

24GB：8B 可挑戰 32K，但 128K 仍不是預設

8B Q4_K_M 權重約 4.98GiB，加上 32K F16 KV 的 5GiB，簡化帳本約 9.98GiB，尚未計入 Runtime 與系統占用；是否完整 GPU offload，仍取決於後端與其他程式。完整 128K 的 F16 KV 約 20GiB，權重加 KV 的下限已約 24.98GiB，因此即使 Runtime 能以 CPU offload、統一記憶體或 KV 量化運作，也不代表它是速度與穩定性都合理的設定。

遇到 OOM，照這個順序修，不要先換顯卡

1. 把 Context 明確鎖到 4096：先證明小基線可載入，確認設定真的生效。
2. 把平行度鎖到 1：排除多請求讓 Context 預算倍增。
3. 確認實際載入位置：用 ollama ps、lms ps 與硬體監視工具區分 RAM、VRAM、CPU／GPU offload。
4. 再試 q8_0 KV：同一版本、同一 prompt 重跑品質與記憶體，不要只看能否載入。
5. 核對 Flash Attention：它會影響長 Context 的記憶體與速度，也影響 Ollama KV 量化能否啟用。
6. 記錄 Runtime 精確版本：不要用「最新版」當實驗條件；更新後重新跑 4K 基線，不能沿用舊結論。
7. 最後才考慮換 3B 或 CPU offload：offload 能避開 VRAM OOM，卻可能把問題變成 RAM 壓力或速度瓶頸。

還有一個常見誤會：Context 上限不等於每次都需要分配到上限。聊天與短工具呼叫通常用不到 128K；RAG 也應先改善切塊、檢索與引用，再用更長 Context 硬塞全部文件。推論引擎在中間做了哪些工作，可接著讀 LLM 推論引擎白話解析。

最後判斷：先買到「可驗證」，再買更多 Context

Granite 4.2 8B 的 5.3GB 沒有騙你，但它只描述量化權重檔案；128K Context、F16 KV、Runtime 緩衝與平行請求是另一張帳。對 8B 而言，完整 128K 的理論 F16 KV 就約 20GiB，這足以解釋為什麼某些設定會從「看似能放進 16GB」變成二十多 GB。

真正可靠的做法不是記住 27GB，而是記住測試順序：鎖版本 → 4K 基線 → 32K 漸進 → 固定平行度 → 單獨比較 KV 精度 → 用聊天、RAG、Tool Calling 驗收 3B／8B。如此一來，Runtime 更新或模型量化改變時，你仍能用同一套收據重做決策。